WikiSysop: 1 версия

2008-08-04T09:55:49Z

1 версия

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

2007-01-27T04:50:51Z

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

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

= Введение =
QaTraq — инструмент управления тест кейсами(test case managment) и требованиями.

* [[RuPedia:OpenSource|OpenSource]];
* [[RuPedia:PHP|PHP]], [[RuPedia:MySQL|MySQL]];
* Базовая версия бесплатна, за деньги можно заказать поддержку и custom-доработку.

= Объекты системы=

==Карта объектов==

Основные объекты (документы) в [[{{NAMESPACE}}:{{PAGENAME}}]] можно представить на следующей карте-диаграмме (с гиперссылками):

<graph>
digraph G{
node[shape="box", style="filled", fillcolor="yellow"];

Product [label="Product", URL="#Product", peripheries=4];
Component [label="Component", URL="#Component"];
Requirement [label="Requirement", URL="#Requirement"];
Phase [label="Phase", URL="#Phase", peripheries=4];
Design [label="Design", URL="#Design", peripheries=4];
Project [label="Project", URL="#Project", peripheries=4];
Plan [label="Plan", URL="#Plan", peripheries=4];
Script [label="Script", URL="#Script", peripheries=4];
Result [label="Result", URL="#Result"];
TestCase [label="TestCase", URL="#TestCase", peripheries=4];

//Описание 1:m-отношений между обьектами
edge[arrowhead="crow"];
Phase->Plan->Design->Script->Result;
Product->Component->TestCase;
Product->Requirement;
Product->Script;
Project->Plan;

//Описание m:n-отношений между обьектами
edge[arrowhead="crow",arrowtail="crow"];
Script->TestCase;
Requirement->TestCase;
}
</graph>

Обьекты, отмеченные на диаграмме «множественными бордюрами» хранятся с контролем версий.

Нижеперечисленные типы объектов имеют стандартные префиксы использующиеся для формирования ID:
;TPL: [[#Plan|Plan]];
;TPH: [[#Phase|Phase]];
;TDG: [[#Design|Design]];
;TSC: [[#Script|Script]];
;TCA: [[#Case|Case]];
;TRS: [[#Result|Result]];
;RPT: [[#Report|Report]];
;REQ: [[#Requirement|Requirement]].

Так объекты с версиями имеют идентификаторы в виде <tt>ZZZ##-#.#</tt>, где <tt>ZZZ</tt>-префикс, тип объекта, потом номер идентификатора и номер версии в формате <tt>major.minor</tt>, а объекты без версий имеют идентификаторы в виде <tt>ZZZ##</tt>.

== Phase ==

Фазы тестирования, например:
* unit testing;
* GUI testing;
* system testing.

Т.е. фазы — способ группировки планов тестирования. Если нет необходимости делить планы на фазы, можно не создавать (изначально имеется одна фаза, которую можно использовать по умолчанию).

;Префикс идентификатора: TPH

Смысловые атрибуты:
;Title: Заголовок;
;Content: [[HTML]]-описание.

== Plan ==

План тестирования. Может содержать как произвольное текстовое описание,
так и дополнительную информацию, например: привязку по времени, графики Ганта и т.п.

{{note}} План не привязан к отдельному продукту, т.е. один и тот же план можно использовать при тестировании различных продуктов.

;Префикс идентификатора: TPL

Смысловые атрибуты:
;Title: Заголовок;
;Content: [[HTML]]-текст плана;
;Phase: Фаза, к которой относится план;
;Attachements: Файловые вложение.

== Design ==

Уровень иерархии между планом тестирования и скриптами(списками) тест кейсов для объединения их по фунциональности.

;Префикс идентификатора: TDG

Смысловые атрибуты:
;Title: Заголовок;
;Content: [[HTML]]-текст;
;Plan: План, к которому относится дизайн.

== Script ==

Набор(список) тест кейсов.

;Префикс идентификатора: TSC

Смысловые атрибуты:
;Title: Заголовок;
;Content: [[HTML]]-текст;
;Design: Дизайн, к которому относиться этот список.
;Product (version): Продукт, причем конкретная версия, который нужно тестировать этим набором тестов.
;OS: Операционная система;
;Platform: Аппаратная платформа;
;Tester: Назначенный тестировщик.

== TestCase ==

Тест-кейс, тест-сценарий. Основной документ системы.

;Префикс идентификатора: TCA

Смысловые атрибуты:
;Title: Заголовок;
;Content: [[HTML]]-текст, содержание/сценарий тест-кейса;
;[[#Product|Product]]/[[#Component|Component]]: Компонент продукта. В различных версиях одного документа, возможны ссылки на разные компоненты, но одного и того же продукта.
;Attachments: Файловые вложения.
;[[#Requirement|Requirement]]s: Покрываемые этим кейсом требования. (Управления требованиями, определение полноты покрытия требований тест-кейсами и т.п.).

== Product ==
Программный (возможно и не программный) продукт, который тестируется.

Смысловые атрибуты:
;Name: Имя продукта (Может изменятся, а ID продукта - числовой и скрыт от пользователя);
;Description: [[HTML]]-описание;

Включает в себя [[#Component|компоненты]] и [[#Requirement|требования]].
Ведутся версии продукта.

=== Component ===
Компонент продукта. Может отражать архитектурное (или какое-либо иное) деление.

Смысловые атрибуты:
;Component Name: Название компонента (Может изменятся, а ID - числовой и скрыт от пользователя);
;Component Owner: Ответственный за компонент.
;Description: [[HTML]]-текст требования;

=== Requirement ===
Требования к продукту (в виде текстовых описаний+ссылка).

Используется для управления требованиями, так каждый тест кейс опционально привязан к требованию и можно получать отчеты по выполнению требований. Например: пройдены ли все тест-кейсы, проверяющие выполнение данного требования?

;Префикс идентификатора: REQ

Смысловые атрибуты:
;Title: Заголовок;
;Content: [[HTML]]-текст требования;
;[[#Product|Product]]: Продукт.
;Attachments: Файловые вложения.
;URL: Ссылка на внешний документ, где, возможно поддерживаются (актуализируются требования). Это может быть специализированная система управления требованиями или просто система хранения документов, Wiki-система или даже каталог офисных файлов.

== Query ==
Запросы написанные на SQL для получения данных из базы QaTraq, некая расширенная функциональность отчетов которые можно писать самому получая практически любую требуемую информацию из базы.

Показываться они правда будут не так красиво, как у [[#Report|отчетов]] (т. е. без гиперссылок, только автоматически формируемая по SQL-запросу таблица).

;Префикс идентификатора: QRY

Смысловые атрибуты:
;Title: Заголовок;
;Description: [[HTML]]-описание;
;Query: [[SQL]]-запрос.

== Report ==
Отчеты, специально предустановленные в системе. Можно формировать новые из предустановленных блоков (некий конструктор запросов). Сами блоки (SQL-запрос +метаинформация) тоже можно делать новые, но не через интерфейс.

В отличие от [[#query|запросов]] отчеты показываются более удобно, с гиперссылками на выбранные запросом объекты.

;Префикс идентификатора: RPT

Смысловые атрибуты:
;Title: Заголовок;
;Description: [[HTML]]-описание;
;Query: [[SQL]]-запрос.

== Role ==
Роли пользователей. Включает описание роли и права выданные этой роли ввиде простой таблицы:
* объект системы/права в ячейки
* галочка выдано/нет.

{{caution}} Т.е. нет системы прав аналогичной [[Bugzilla]], где права выдаются по продуктам.

== User ==
Пользователи системы. Атрибуты: логин, имя, пароль, базовая роль, еще дополнительные роли. Один пользователь может иметь более одной роли.

= Функциональность =

== Контроль версий ==
Практически все объекты в QaTraq хранятся с контролем версий (Cм. [[#Объекты системы]]).

{{note}} Номер версии строится major.minor и расположен после дефиса в идентификаторе объекта, например TPL-1-0.4 — первый план тестирования, версия 0.4.

С контролем версий не хранятся следующие объекты:
* [[#Requirement|требования]];
* запросы (Queries);
* отчеты (Reports);
* [[#Component|компоненты продукта]].

{{caution}} Инструмента сравнения версий нет. Доступ к предыдущим версиям в интерфейсе возможен, если при запросе поиска объекта убрать галочку «Latest Version».

== Управление тест кейсами ==
[[QaTraq]] позволяет создавть тест кейсы и организовывать их в иерархию «Phase→Plan→Design→Script» (См. [[#Объекты системы]]).

Соотносить тест-кейсы с требованиями, компонентами.
Делать отчеты по выполненым тест-кейсам.

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

== Управление требованиями ==
Функциональность управление [[#Requirement|требованиями]] в [[QaTraq]] исключительно базовая:

{{no}} Нет
:* Версионности требований;
:* Классификации (кроме как по продукту);
{{ok}} Есть
:* Отчеты о покрытии тестовыми сценариями требований.

== Интеграция с Bugzilla ==
Для каждого результата (Results) есть список тест кейсов с их статусом (not nested, fail, ..). В случае если статус для данного тест кейса совпадает fail, можно заполнить его список багов(defect list). В нем присутствует кнопка enter defect, которая есть просто ссылка на форму создания бага Bugzillа. Затем ссылку на новый баг и его краткое описание надо руками ввести в список как url. Это удобным считать нельзя, но тем не менее ссыки в Bugzilla работают.

== Отчеты ==

Имеется набор базовых отчетов ([[#Report|Report]]), так и возможность построения произвольных отчетов [[#Query|Queries]] с использованием зарегистрированных произвольных [[SQL]]-запросов (в этом случае, разумеется, требуется знание внутренней структуры БД системы).

== Администрирование ==
В администрировании пользователей используется стандартная схема «пользователи/роли» и выдача прав на отдельные типы объектов.

Почти все типы объектов имеют следующие виды прав (соответствующих возможным действиям через интерфейс):
* view
* modify
* new
* delete
* copy

Разделения прав по компонентам или другим экземплярам объектов нет, деление прав только по типам объектов.

= Заметки по опыту использования =
;{{no}} Отрицательные моменты.

* при создании тест кейса необходимо каждый раз проводить поиск, указывать продукт, затем выбирать из списка компонент для данного тест кейса, что
:* сильно увеличивает число лишних действий (движений и кликов);
:* в принципе решается копированием тест-кейса, но при этом, привязка к [[#Script|test script]] все равно не копируется.

* то же самое при создании других объектов: [[#design|test design]], [[#script|test script]] и т. д. для них надо каждый раз указывать «родительский», «владеющий ими» объект. Неудобно, можно ошибиться и создать свой объект в другом проекте.

* неглубокая структура внутри [[#Product|продукта]], только один уровень — [[#Component|компоненты]].
(Т.е. когда в тесте возникла ошибка, она локализуется не очень глубоко).

;{{ok}} Положительные моменты.

* приятная возможности делать аттачменты к разным документам (тест кейсам, test design, test script, результатам, планам тестирования).

;Русификация:
Перед использование в русскоязычных проектах, возможно потребуется некоторая правка кода (чтобы в базе данные лежали в корректной кодировке). Так, например, если [[RuPedia:Apache|Apache]] для вашей инсталляции
[[QaTraq]] настроен отдавать страницы в кодировке UTF-8:
AddDefaultCharset utf-8

то в <tt>db_qatraq.php</tt> после строчки (успешное соединение)
<code-php>
$this->dbh = $li;
</code-php>
разумно добавить выставление правильной кодировки MySQL-клиента:
<code-php>
$this->execute('set names utf8');
</code-php>

Аналогичная правка желательна и в случае других кодировок веб-сервера (cp1251 и т.п.)

= Ccылки =
* [http://www.testmanagement.com Официальный сайт]

{{replicate-from-custiswiki-to-lib}}
[[Category:Тестирование программного обеспечения]]

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

2007-01-26T20:06:28Z

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

← Предыдущая	Версия 20:06, 26 января 2007
(нет различий)

QaTraq - История изменений

WikiSysop: 1 версия

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

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