|
Персональные инструменты |
![]() |
||
|
![]() |
![]() TestLink (версия 1.6)Материал из CustisWikiКороткая ссылка: 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). Создание конфигурирование продуктов и компонент, категорий в них делает администратором.
Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion». |
![]() |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
![]() |