Просмотр исходного текста страницы TestLink (версия 1.6)

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

= Введение =
Testlink — инструмент управления тест кейсами(test case managment)
* сайт [http://www.teamst.org/ www.teamst.org]
* лицензия GPL

= Основные объекты =
Основные объекты системы: 
* продукт («''Product''»); 
* план тестирования («''Test Plan''»); 
* пользователь («''User''»).


== Обьекты системы ==
<graph>
digraph G{
 node[shape="box", style="filled", fillcolor="yellow"]; 
 edge[arrowhead="crow"]; 


 Product [label="Продукт", URL="#Продукт"]; 
 Component [label="Компонент", URL="#Компонент"]; 
 Category [label="Категория", URL="#Категория"]; 
 TestCase [label="Тест кейс", URL="#Тест кейс"]; 
 TestSuite [label="Набор тестов"]; 
 RequirementSpecification [label="Спецификация требований"]; 
 Requirement [label="Требование"]; 
 Keyword     [label="Тэг (ключевое слово)"];

 Product->Component->Category->TestCase;
 Product->TestSuite->TestCase;
 Keyword->TestCase [arrowtail="crow"];
 RequirementSpecification->Requirement;
 Requirement->TestCase[arrowtail="crow"];
}
</graph>


=== Продукт ===
Продукт («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>
digraph G{
    rankdir=LR; 

    node [shape="box",fillcolor="lightgray",style="filled"];
    Guest [label="Гость"];
    TestExecutor [label="Тестер"];
    TestAnalyst [label="Тест-аналитик"];
    TestLeader [label="Руководитель тестирования"];

    node [shape="ellipse",fillcolor="yellow",style="filled"];
    Browse [label="Просмотр результатов тестов и метрик"];
    DescribeTestResults [label="Выполнение тестов и регистрация их результатов"];
    WriteTestSpecification [label="Написание спецификаций тестов"];
    AssignKeywords [label="Пометка ключевыми словами"];
    WriteProductRequirements [label="Описание требований к продукту"];
    ImportRequirements [label="Импорт требований"];
    AssignTestCasesToRequirements [label="Покрытие требований тест-кейсами"];

    Guest->Browse;

    TestExecutor->DescribeTestResults;

    TestAnalyst->DescribeTestResults;
    TestAnalyst->WriteTestSpecification->AssignKeywords;
    TestAnalyst->WriteProductRequirements->ImportRequirements;
                 WriteProductRequirements->AssignTestCasesToRequirements;

    TestLeader->WriteProductRequirements;
    TestLeader->DefineTestPlan;
                DefineTestPlan->AddTestSuiteToTestPlan;
                DefineTestPlan->CreateBuilds;
                DefineTestPlan->DefineOwnership;
                DefineTestPlan->DefinePriority;

    Administrator->ManageUsers;
    Administrator->BackupDB;
}
</graph>
=== Гость ===
Имеет права только на просмотр всего.
=== Тестер ===
Может просматривать все и записывать результаты тестирования по тем планам, на которые ему выданы права.
=== Тест-аналитик ===
Имеет права на все, что и тестер и дополнительно:
* создавать тест кейсы
* присваивать ключевые слова тест кейсам
* писать требования
* привязывать требования к тест кейсам 
=== Руководитель тестирования ===
Может то же, что и тест-аналитик и тестер и еще:
* создавать план тестирования
* добавлять/удалять тест кейсы из плана
* создавать сборки
* определять приоритеты тест кейсов
* определять владение тест кейсами, т.е. кто, что должен сделать
=== 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 в сборке 1
# сделали новую сборку 2
# предположим, что поменяли тест кейс согласно новой сборке 2, получили тест кейс версии 2
# получи результат тестирования по тест кейсу версии 2 в сборке 2
# захотели проверить какой там результат по тест кейсу был в сборке 1
# в архивах отражен правильный тест кейс версии 1 (не версии 2) и его результат

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

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

[[Category:Тестирование программного обеспечения]]

{{replicate-from-custiswiki-to-lib}}