Версия 03:02, 27 октября 2010 (просмотреть исходный код) BenderBot (обсуждение | вклад) м (1 версия) ← Предыдущая правка		Версия 20:16, 1 декабря 2010 (просмотреть исходный код) StasFomin (обсуждение | вклад) м Следующая правка →
Строка 159:		Строка 159:
	{{replicate-from-custiswiki-to-smwiki}}		{{replicate-from-custiswiki-to-smwiki}}
	[[Категория:Тестирование программного обеспечения]]		[[Категория:Тестирование программного обеспечения]]
		+	[[Категория:CustisWikiToTools]]

---

Версия 20:16, 1 декабря 2010

Testopia — инструмент управления тест кейсами от Mozilla Foundation, тесно интегрированный в систему управления ошибками Bugzilla. Основной разработчик Greg Hendricks — инженер компании Novell, который видимо сопровождает их внешнюю инсталяцию Bugzilla и разрабатывает Testopia для нужд Novell. Он так же ведет блог посвященный Testopia.

Компании которые используют Testopia:

• Novell — установлена Testopia, но она не показана наружу;

в ноябре 2006 тут шло обсуждение что надо выставить testopia для внешних тестировщиков, но не срослось

• fedoraproject.org — рассматривали для использования, чем кончилось не ясно.

Есть PHP блиотека для доступа к функция XML-RPC Testopia http://idea.opensuse.org/content/ideas/develop-php-library-for-testopia-api.

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

Анатомия теста (test case)

Структурные

Product

Продукт из Bugzilla к которому относиться тест.

Componet

Компонент из Bugzilla внутри продукта к которому относиться тест.

Category

Категория. Дополнительное поле для организации тестов в группы. В целом похоже на поле Componet в Bugzilla, но это поле самой Testopia не пересекающееся с Bugzilla.

Tags

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

Атрибуты жизненного цикла

Status

Стату теста. Имеет три значения:

• PROPOSED — Тест предложен и пока не написан.
• CONFIRMED — Тест написан и готов к проверке.
• DISABLED — Тест устарел и убран из пула тестов.

Runs

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

Описание бага

Summary

Краткое описание

Alias

Дополнительное кототкое название теста.

Priority

Приоритет теста имеет значения от Р1 до Р5ю возможности настройки не известны.

Estimated Time

Примерное время выполнения теста в формате HH:MM:SS.

Requirement

Числовой идентификатор или URL, который указывает на требование которое проверяет этот баг. Если ввести URL, то в тесте он будет отображаться в браузере как ссылка. Это удобно для связи с требованиями написанными. например в WikiWiki.

Automatic

Поле показывающее автоматизирован ли данный тест. Имеет два значения:

• Manual
• Automatic

Script

Адрес или URL скрипта, если это автоматизированный тест.

Arguments

Аргументы скрипта, если это автоматизированный тест.

Set Up

Необходимые условия и действия для выполнения теста. В данном поле возможно богатое редактирования при помощи встроенного WYSWIG редактора html.

Break Down

Необходимые действия после выполнения теста. В данном поле возможно богатое редактирования при помощи встроенного WYSWIG редактора html.

Action

Действия (шаги) осуществялемые в тесте для проверки чего-либо. В данном поле возможно богатое редактирования при помощи встроенного WYSWIG редактора html.

Expected Results

Ожидаемые результаты теста для сравнения с полученными результатами. В данном поле возможно богатое редактирования при помощи встроенного WYSWIG редактора html.

Связанные пользователи

Author

Автор теста, проставляется автоматически.

Default Tester

Тот кому по умолчанию назначена проверка данного теста.

Зависимости между тестами

Зависимости теста, от каких тестов зависит данный тест (Depends on), какие зависят от него (Blocks). Зависимости позволяют автоматически менять статус теста в некоторых случаях. Если тест провален и имеет состояние FAILED, то все тесты которые от него зависят и включены в текущий цикл работ (Run) автоматически получат статус BLOCKED.

Права доступа

Группа Testers

Права доступа организованы аналогично Bugzilla, но более слабо. Есть группа Testers — все кто в нее входят имеют доступ на чтение и изменение всех объектов в Testopia. Для того чтобы создавать новые планы тестирования необходимо быть членом этой группы.

Доступ к планам тестирования

Дополнительно для каждого плана тестирования можно задать список пользователей (Access Control Lists), которые имеют доступ к нему (и всем дочерним объектам). Есть несколько уровней доступа:

• Read — просмотр всех объектов плана;
• Write — изменение всех объектов плана, подразумевает просмотр;
• Delete — удаление объектов в Testopia, подразумевает чтение и изменение;
• Admin — возможность выдавать права в объекте.

Конечно не совсем удобная, но гибкая система.

---