|
Персональные инструменты |
|||
|
QaTraqМатериал из CustisWikiВерсия от 07:50, 27 января 2007; BenderBot (обсуждение | вклад) (реплицировано из внутренней CustisWiki) Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений. Содержание[убрать]ВведениеQaTraq — инструмент управления тест кейсами(test case managment) и требованиями.
Объекты системыКарта объектовОсновные объекты (документы) в QaTraq можно представить на следующей карте-диаграмме (с гиперссылками):
Обьекты, отмеченные на диаграмме «множественными бордюрами» хранятся с контролем версий. Нижеперечисленные типы объектов имеют стандартные префиксы использующиеся для формирования ID: Так объекты с версиями имеют идентификаторы в виде ZZZ##-#.#, где ZZZ-префикс, тип объекта, потом номер идентификатора и номер версии в формате major.minor, а объекты без версий имеют идентификаторы в виде ZZZ##. PhaseФазы тестирования, например:
Т.е. фазы — способ группировки планов тестирования. Если нет необходимости делить планы на фазы, можно не создавать (изначально имеется одна фаза, которую можно использовать по умолчанию).
Смысловые атрибуты:
PlanПлан тестирования. Может содержать как произвольное текстовое описание, так и дополнительную информацию, например: привязку по времени, графики Ганта и т.п. План не привязан к отдельному продукту, т.е. один и тот же план можно использовать при тестировании различных продуктов.
Смысловые атрибуты:
DesignУровень иерархии между планом тестирования и скриптами(списками) тест кейсов для объединения их по фунциональности.
Смысловые атрибуты:
ScriptНабор(список) тест кейсов.
Смысловые атрибуты:
TestCaseТест-кейс, тест-сценарий. Основной документ системы.
Смысловые атрибуты:
ProductПрограммный (возможно и не программный) продукт, который тестируется. Смысловые атрибуты:
Включает в себя компоненты и требования. Ведутся версии продукта. ComponentКомпонент продукта. Может отражать архитектурное (или какое-либо иное) деление. Смысловые атрибуты:
RequirementТребования к продукту (в виде текстовых описаний+ссылка). Используется для управления требованиями, так каждый тест кейс опционально привязан к требованию и можно получать отчеты по выполнению требований. Например: пройдены ли все тест-кейсы, проверяющие выполнение данного требования?
Смысловые атрибуты:
QueryЗапросы написанные на SQL для получения данных из базы QaTraq, некая расширенная функциональность отчетов которые можно писать самому получая практически любую требуемую информацию из базы. Показываться они правда будут не так красиво, как у отчетов (т. е. без гиперссылок, только автоматически формируемая по SQL-запросу таблица).
Смысловые атрибуты: ReportОтчеты, специально предустановленные в системе. Можно формировать новые из предустановленных блоков (некий конструктор запросов). Сами блоки (SQL-запрос +метаинформация) тоже можно делать новые, но не через интерфейс. В отличие от запросов отчеты показываются более удобно, с гиперссылками на выбранные запросом объекты.
Смысловые атрибуты: RoleРоли пользователей. Включает описание роли и права выданные этой роли ввиде простой таблицы:
Т.е. нет системы прав аналогичной Bugzilla, где права выдаются по продуктам. UserПользователи системы. Атрибуты: логин, имя, пароль, базовая роль, еще дополнительные роли. Один пользователь может иметь более одной роли. ФункциональностьКонтроль версийПрактически все объекты в QaTraq хранятся с контролем версий (Cм. #Объекты системы). Номер версии строится major.minor и расположен после дефиса в идентификаторе объекта, например TPL-1-0.4 — первый план тестирования, версия 0.4. С контролем версий не хранятся следующие объекты:
Инструмента сравнения версий нет. Доступ к предыдущим версиям в интерфейсе возможен, если при запросе поиска объекта убрать галочку «Latest Version». Управление тест кейсамиQaTraq позволяет создавть тест кейсы и организовывать их в иерархию «Phase→Plan→Design→Script» (См. #Объекты системы). Соотносить тест-кейсы с требованиями, компонентами. Делать отчеты по выполненым тест-кейсам. Результаты тестирования можно связывать с конкретной версией продукта. Управление требованиямиФункциональность управление требованиями в QaTraq исключительно базовая:
Интеграция с BugzillaДля каждого результата (Results) есть список тест кейсов с их статусом (not nested, fail, ..). В случае если статус для данного тест кейса совпадает fail, можно заполнить его список багов(defect list). В нем присутствует кнопка enter defect, которая есть просто ссылка на форму создания бага Bugzillа. Затем ссылку на новый баг и его краткое описание надо руками ввести в список как url. Это удобным считать нельзя, но тем не менее ссыки в Bugzilla работают. ОтчетыИмеется набор базовых отчетов (Report), так и возможность построения произвольных отчетов Queries с использованием зарегистрированных произвольных SQL-запросов (в этом случае, разумеется, требуется знание внутренней структуры БД системы). АдминистрированиеВ администрировании пользователей используется стандартная схема «пользователи/роли» и выдача прав на отдельные типы объектов. Почти все типы объектов имеют следующие виды прав (соответствующих возможным действиям через интерфейс):
Разделения прав по компонентам или другим экземплярам объектов нет, деление прав только по типам объектов. Заметки по опыту использования
(Т.е. когда в тесте возникла ошибка, она локализуется не очень глубоко).
Перед использование в русскоязычных проектах, возможно потребуется некоторая правка кода (чтобы в базе данные лежали в корректной кодировке). Так, например, если Apache для вашей инсталляции QaTraq настроен отдавать страницы в кодировке UTF-8: AddDefaultCharset utf-8 то в db_qatraq.php после строчки (успешное соединение) $this->dbh = $li; разумно добавить выставление правильной кодировки MySQL-клиента: $this->execute('set names utf8'); Аналогичная правка желательна и в случае других кодировок веб-сервера (cp1251 и т.п.) Ccылки
Репликация: База Знаний «Заказных Информ Систем» → «QaTraq» Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion». |
||