Текущая версия на 04:08, 10 февраля 2011

Внимание! В нашей компании Testlink более не используется (экспериментировали с его использованием в 2006 году, нашли его неудобным и неправильным). Наш взгляд на правильные системы управления тестами — Управление тестами с Testopia — недостающее звено? (SECR-2009)

Введение

Testlink — инструмент управления тест кейсами(test case managment)

• сайт www.teamst.org
• лицензия GPL

Основные объекты

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

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

Обьекты системы

Продукт

Продукт («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, согласно документации имеет такое определение: все компоненты, категории, тест кейсы внутри плана тестирования.

Пользователь

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

Гость

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

Тестер

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

Тест-аналитик

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

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

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

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

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

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). Создание конфигурирование продуктов и компонент, категорий в них делает администратором.