|
Персональные инструменты |
![]() |
||
|
![]() |
![]() TestLink (версия 1.6)Материал из CustisWiki(перенаправлено с «TestLink»)
Короткая ссылка: TestLink
ВведениеTestlink — инструмент управления тест кейсами(test case managment)
Основные объектыОсновные объекты системы:
Обьекты системы
ПродуктПродукт («Product») — главный объект системы. Содержит компоненты, а компоненты содержат категории. Есть удобная функция отправления продукта в архив, после чего он престает быть виден пользователям, но все данные по нему сохраняются. КомпонентУровень организации тест кейсов. Атрибуты включают название и несколько полей текста:
КатегорияВложенный в компонент уровень организации тест кейсов. Имеет атрибуты название и поля текста:
В них уже находятся тест кейсы. Тест кейсСтроительный материал тестирования. Атрибуты:
опционально имеет несколько ключевых слов(keyword) и опционально привязан к требованиям как многие ко многим. Каждый тест кейс храниться с контролем версий, они нумеруются целыми числами начиная с единицы. Когда тест кейс добавляют в план тестирования (Test Suite) туда копируется текущего версия. При увеличении версии тест кейс в плане можно проапдейтить до самого свежего или не менять. План ТестированияХотя он и назван основным объектов в TestLink, но такого объекта, как план тестирования нет. План тестирования везде в TestLink называется Test Suite. Каждый продукт может иметь несколько планов тестирования. Test Suite, согласно документации имеет такое определение: все компоненты, категории, тест кейсы внутри плана тестирования. ПользовательКлассификация ролей пользователей и выполняемые ими функции представлены ниже: ГостьИмеет права только на просмотр всего. ТестерМожет просматривать все и записывать результаты тестирования по тем планам, на которые ему выданы права. Тест-аналитикИмеет права на все, что и тестер и дополнительно:
Руководитель тестированияМожет то же, что и тест-аналитик и тестер и еще:
AdministratorВ принципе может выполнять все функции, что и другие пользователи. Но подразумевается, что должен:
Дополнительные объектыКлючевое словоДополнительный инструмент организации тест кейсов. Список ключевых слов можно редактировать. Одному тест кейсу можно поставить в соответствие несколько ключевых слов. По ключевому слову можно проводить поиск тест кейса. Спецификация требованияДокумент описывающий требования, метод организации требований. Имеет атрибуты название, область применения (scope), список требований. ТребованиеСобственно требование к продукту, с идентификатором документа (строковое поле), названием, текстовым описанием, статусом (верно или не тестируемо). Так же к требованию привязан список тест кейсов которые его проверяют. MilestoneMilestone можно создавать, дополнительно имеет атрибуты процент задач разного приоритета (A,B,C) на выполнение. Т.е. подразумевает что из выполненного (протестированного) к Milestone часть будет иметь заданный приоритет. СборкаОбозначает тестируемую сборку продукта. Сборки создаются как-бы "внутри" плана тестирования (Test Suite), то есть сборка созданная в одном плане не существует в другом. При тестировании (заполнении результатов) можно выбрать сборку которую тестируешь. Если создана новая сборка все результаты тестирования по предыдущей сборке фиксируются и их изменение невозможно. Сборка используется в отчетах, например метрика текущей сборки, статистика тест кейсов по всем сборкам плана тестирования(Test suite). ФункциональностьОтчеты и метрикиTestLink умеет создавать фиксированный набор отчетов для каждого плана тестиорвания(Test suite) в отдельности, т. е. нельзя получить отчет по нескольким палнам сразу. Набор отчетов включает:
Интеграция c BugzillaПри описании результатов проверки тест кейсов есть возможность завести новый баг(ссылка на Bugzilla). Список багов «полученных» из данного тест кейса ведется через запятую в специальном поле, TestLink вытаскивает из базы Bugzilla summary этих багов и отображает их список. Управление требованиямиТребования организованы в двух уровневую структуру «Спецификация требований»-->"Требования". Спецификация требований имеет поля название (Title), облать применимости (Scope), количество требований и их список. Количество требований считается автоматически или если уже есть документ описывающий требования его можно задать самому. Требование имеет поля: идентификатор документа(DOC-ID), название(Title), область действия (Scope), статус(Status), покрытие (Coverage). Первые три это текстовые поля, статус показывает тип требования тестируемое(Valid) или его протестировать невозможно(Not testable). Поле покрытие показывает тест кейсы привязанные к данному требованию. Подразумевается, что эти тест кейсы проверяют выполнение данного требования. Для требований внутри одной спецификации предусмотрены действия:
Контроль версийКонтролю версий подвержены только тест кейсы. Инструмента сравнения версий (вроде cvs diff) нет. Все преимущества контоля версий можно описать таким use case:
Т.е. если мы со временем поменяли тест кейс, то все старые результаты не связаны с новыми версиями тест кейса, что правильно и удобно. АдминистрированиеЕсть роли обладающие разными правами. Планы тестирования (Test Suite) имеют отдельные права, которые надо выдавать, в этом случае права чтение/запись зависят от роли пользователя. Права на Test Suite могут выдавать администраторы или лидеры(роли admin, leader). Создание конфигурирование продуктов и компонент, категорий в них делает администратором. Репликация: База Знаний «Заказных Информ Систем» → «TestLink (версия 1.6)» Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion». |
![]() |
![]() |
![]() |