TestLink (версия 1.6) - История изменений

BenderBot: 1 версия

2011-02-10T01:08:05Z

1 версия

StasFomin в 13:22, 9 февраля 2011

2011-02-09T13:22:13Z

WikiSysop: 1 версия

2008-08-04T09:55:51Z

1 версия

BenderBot: реплицировано из внутренней CustisWiki

2007-10-26T11:15:32Z

реплицировано из внутренней CustisWiki

Новая страница

= Введение =
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}}

StasFomin: +Category:TestLink

2007-08-28T15:38:49Z

+Category:TestLink

AndrewSatarin: /* Отчеты и метрики */

2007-08-23T13:57:51Z

‎Отчеты и метрики

BenderBot: реплицировано из внутренней CustisWiki

2007-02-02T04:56:54Z

реплицировано из внутренней CustisWiki

← Предыдущая		Версия 13:22, 9 февраля 2011
Строка 1:		Строка 1:
		+	<blockquote>
		+	Внимание! В нашей компании Testlink более не используется (экспериментировали с его использованием в 2006 году, нашли его неудобным и неправильным).
		+	Наш взгляд на правильные системы управления тестами — [[Управление тестами с Testopia — недостающее звено? (SECR-2009)]]
		+	</blockquote>
		+
	= Введение =		= Введение =
	Testlink — инструмент управления тест кейсами(test case managment)		Testlink — инструмент управления тест кейсами(test case managment)

← Предыдущая	Версия 09:55, 4 августа 2008
(не показаны 2 промежуточные версии 2 участников)
(нет различий)

← Предыдущая	Версия 01:08, 10 февраля 2011
(нет различий)

@@ Строка 196: / Строка 196: @@
 Есть роли обладающие разными правами. Планы тестирования (Test Suite) имеют отдельные права, которые надо выдавать, в этом случае права чтение/запись зависят от роли пользователя. Права на Test Suite могут выдавать администраторы или лидеры(роли admin, leader). Создание конфигурирование продуктов и компонент, категорий в них делает администратором.
-[[Category:Тестирование программного обеспечения]]
+[[Category:TestLink]]
 {{replicate-from-custiswiki-to-lib}}

@@ Строка 161: / Строка 161: @@
 * метрики выбранной сборки
 :в метрики входят таблицы результаты-по-приоритету, результаты-по-компоненту, результаты-по-категории (почему-то ошибочно назван Results by Test Suite), результаты-по-ключевому-слову
+* отчет по пройденным тест кейсам для каждой сборки, компонента, ключевого слова
+* отчет для каждого тест кейса по выявленным багам
-отчеты по пройденным тест кейсам для каждого билда, компонента, ключевого слова. Отчет для каждого тест кейса по выявленным багам. Отчет о выполнении требований: какие тест кейсы каких требований прошли, какие не проверялись, какие провалились, какие заблокированы.
+* отчет о выполнении требований
 == Интеграция c Bugzilla ==
@@ Строка 196: / Строка 197: @@
 Есть роли обладающие разными правами. Планы тестирования (Test Suite) имеют отдельные права, которые надо выдавать, в этом случае права чтение/запись зависят от роли пользователя. Права на Test Suite могут выдавать администраторы или лидеры(роли admin, leader). Создание конфигурирование продуктов и компонент, категорий в них делает администратором.
-[[Category:TestLink]]
+[[Category:Тестирование программного обеспечения]]
 {{replicate-from-custiswiki-to-lib}}