TestLink

Материал из свободной русской энциклопедии «Традиция»
Перейти к: навигация, поиск

Testlink — инструмент управления тест-кейсами (test case management), распространяемый по лицензии GPL.

Основные объекты[править]

Основные объекты системы:

  • продукт («Product»);
  • план тестирования («Test Plan»);
  • пользователь («User»).

Обьекты системы[править]

Graph image creation requires permission to upload.


Продукт[править]

Продукт («Product») — главный объект системы. Содержит компоненты, а компоненты содержат категории. Есть удобная функция отправления продукта в архив, после чего он перестает быть виден пользователям, но все данные по нему сохраняются.

Компонент[править]

Уровень организации тест кейсов. Атрибуты включают название и несколько полей текста:

  • Intro,
  • Scope,
  • Reference,
  • Methodology,
  • Limitations

Категория[править]

Вложенный в компонент уровень организации тест кейсов. Имеет атрибуты название и поля текста:

  • Scope and Objective,
  • Configuration,
  • Data,
  • Tools.

В них уже находятся тест кейсы.

Тест кейс[править]

Строительный материал тестирования. Атрибуты:

  • название,
  • Summary,
  • Steps,
  • Expected Results,

опционально имеет несколько ключевых слов(keyword) и опционально привязан к требованиям как многие ко многим.

Каждый тест кейс хранится с контролем версий, они нумеруются целыми числами начиная с единицы. Когда тест кейс добавляют в план тестирования (Test Suite) туда копируется текущего версия. При увеличении версии тест кейс в плане можно проапдейтить до самого свежего или не менять.

План Тестирования[править]

Хотя он и назван основным объектом в TestLink, но такого объекта, как план тестирования нет. План тестирования везде в TestLink называется Test Suite. Каждый продукт может иметь несколько планов тестирования. Test Suite, согласно документации имеет такое определение: все компоненты, категории, тест кейсы внутри плана тестирования.

Пользователь[править]

Классификация ролей пользователей и выполняемые ими функции представлены ниже:

Graph image creation requires permission to upload.

Гость[править]

Имеет права только на просмотр всего.

Тестер[править]

Может просматривать все и записывать результаты тестирования по тем планам, на которые ему выданы права.

Тест-аналитик[править]

Имеет права на все, что и тестер и дополнительно:

  • создавать тест кейсы
  • присваивать ключевые слова тест кейсам
  • писать требования
  • привязывать требования к тест кейсам

Руководитель тестирования[править]

Может то же, что и тест-аналитик и тестер и еще:

  • создавать план тестирования
  • добавлять/удалять тест кейсы из плана
  • создавать сборки
  • определять приоритеты тест кейсов
  • определять владение тест кейсами, то есть кто, что должен сделать

Administrator[править]

В принципе может выполнять все функции, что и другие пользователи. Но подразумевается, что должен:

  • управлять пользователями
  • управлять продуктами

Дополнительные объекты[править]

Ключевое слово[править]

Дополнительный инструмент организации тест кейсов. Список ключевых слов можно редактировать. Одному тест кейсу можно поставить в соответствие несколько ключевых слов. По ключевому слову можно проводить поиск тест кейса.

Спецификация требования[править]

Документ описывающий требования, метод организации требований. Имеет атрибуты название, область применения (scope), список требований.

Требование[править]

Собственно требование к продукту, с идентификатором документа (строковое поле), названием, текстовым описанием, статусом (верно или не тестируемо). Так же к требованию привязан список тест кейсов которые его проверяют.

Milestone[править]

Milestone можно создавать, дополнительно имеет атрибуты процент задач разного приоритета (A,B,C) на выполнение. То есть подразумевает что из выполненного (протестированного) к Milestone часть будет иметь заданный приоритет.

Сборка[править]

Обозначает тестируемую сборку продукта. Сборки создаются как-бы «внутри» плана тестирования (Test Suite), то есть сборка созданная в одном плане не существует в другом. При тестировании (заполнении результатов) можно выбрать сборку которую тестируешь. Если создана новая сборка все результаты тестирования по предыдущей сборке фиксируются и их изменение невозможно. Сборка используется в отчетах, например метрика текущей сборки, статистика тест кейсов по всем сборкам плана тестирования(Test suite).

Функциональность[править]

Отчеты и метрики[править]

TestLink умеет создавать фиксированный набор отчетов для каждого плана тестиорвания(Test suite) в отдельности, то есть нельзя получить отчет по нескольким планам сразу.

Набор отчетов включает:

  • метрики выбранной сборки
в метрики входят таблицы результаты-по-приоритету, результаты-по-компоненту, результаты-по-категории (почему-то ошибочно назван Results by Test Suite), результаты-по-ключевому-слову

отчеты по пройденным тест кейсам для каждого билда, компонента, ключевого слова. Отчет для каждого тест кейса по выявленным багам. Отчет о выполнении требований: какие тест кейсы каких требований прошли, какие не проверялись, какие провалились, какие заблокированы.

Интеграция c Bugzilla[править]

При описании результатов проверки тест кейсов есть возможность завести новый баг(ссылка на Bugzilla). Список багов «полученных» из данного тест кейса ведется через запятую в специальном поле, TestLink вытаскивает из базы Bugzilla summary этих багов и отображает их список.

Управление требованиями[править]

Требования организованы в двух уровневую структуру «Спецификация требований»-->"Требования". Спецификация требований имеет поля название (Title), облать применимости (Scope), количество требований и их список. Количество требований считается автоматически или если уже есть документ описывающий требования его можно задать самому.

Требование имеет поля: идентификатор документа(DOC-ID), название(Title), область действия (Scope), статус(Status), покрытие (Coverage). Первые три это текстовые поля, статус показывает тип требования тестируемое(Valid) или его протестировать невозможно(Not testable). Поле покрытие показывает тест кейсы привязанные к данному требованию. Подразумевается, что эти тест кейсы проверяют выполнение данного требования. Для требований внутри одной спецификации предусмотрены действия:

  • печать
генерируется HTML файл с заголовком спецификации и описанием ее требований
  • импортировать из CSV
формат файла 'title','description'
или формат DOORS с заголовками
  • анализировать
генерируется HTML файл содержащий статистику по требованиям: покрыты, не покрыты, не проверяемы.

Контроль версий[править]

Контролю версий подвержены только тест кейсы. Инструмента сравнения версий (вроде cvs diff) нет. Все преимущества контоля версий можно описать таким use case:

  1. создали тест кейс версии 1
  2. получи результат тестирования по тест кейсу версии 1 в сборке 1
  3. сделали новую сборку 2
  4. предположим, что поменяли тест кейс согласно новой сборке 2, получили тест кейс версии 2
  5. получи результат тестирования по тест кейсу версии 2 в сборке 2
  6. захотели проверить какой там результат по тест кейсу был в сборке 1
  7. в архивах отражен правильный тест кейс версии 1 (не версии 2) и его результат

То есть если мы со временем поменяли тест кейс, то все старые результаты не связаны с новыми версиями тест кейса, что правильно и удобно.

Администрирование[править]

Есть роли обладающие разными правами. Планы тестирования (Test Suite) имеют отдельные права, которые надо выдавать, в этом случае права чтение/запись зависят от роли пользователя. Права на Test Suite могут выдавать администраторы или лидеры(роли admin, leader). Создание конфигурирование продуктов и компонент, категорий в них делает администратором.

Ссылки[править]


По крайней мере часть этого текста взята с ресурса http://lib.custis.ru/ под лицензией GDFL.Список авторов доступен на этом ресурсе в статье под тем же названием.