Управление изменениями с использованием технологий Rational

       

Документирование ошибок из Robot и TestManager


Robot - средство нагрузочного и функционального тестирования. С его помощью можно тестировать Web-приложения (как часть клиент/серверных систем) а также GUI (оконные компоненты работающих приложений). Описывать целиком продукт я не буду, для этого есть отдельная статья, отмечу лишь некоторые моменты его работы.

Диалог, выводящийся после вызова контекстного меню на ошибке. Поле «HeadLine» заполнено вручную. При ручном документировании необходимо четко придерживаться корпоративного стандарта, во избежание дублирующихся записей в базе.

По окончании тестирования Robot передает управление TestManager, в котором в дальнейшем хранятся все сведения о найденных ошибках. Если тестирование прошло успешно, то ничего делать не придется, так как ошибок нет.

В случае возникновения ошибки тестировщик вызывает модуль интеграции с ClearQuest (в Robot он называется Submit ClearQuest Defect и вызывается контекстным меню на имени ошибки).

Description. Короткое описание, говорящее о том, что тестирование проведено Robot’ом;

FoundInBuild. Описывается имя билда, в котором найден дефект. Именованием билда управляют ClearCase и TestManager. Соответственно, можно отследить ход появления ошибок (в первом билде была, а во втором нет);

LogFolder. Папка, в которой сгруппированы логи;

Log. Имя лога, в котором обнаружена ошибка;

Script. Имя скрипта, который "обнаружил" ошибку.

Описание среды системы, на которой обнаружен дефект. Все поля заполняются вручную. При необходимости добавляются новые поля, а существующие списки могут быть наполнены новыми данными, в соответствии с корпоративным стандартом на тестирование.

Обратим внимание на то, что количество полей, подлежащих автоматическому заполнению, невелико, и здесь необходимо следовать определенным правилам. Первое правило касается заголовка ошибки (Headline), который должен максимально четко отражать суть выявленного дефекта. Второе правило - необходимо тщательным образом описать среду ошибки (закладка "Environment").


Детальное описание среды позволяет обнаруживать «плавающие» ошибки, то есть те ошибки, которые проявляют себя на разных платформах или системах. Изначально список компьютеров (computers), аппаратного оборудования (hardware), операционных систем (OS), и др. не содержит в себе правильных данных для вашего проекта. Все дополнительные инструменты настройки списков находятся в ClearQuest Designer.

Еще раз отметим, что CQD отвечает за любую логику, связанную с работой CQ. Он отвечает за интерфейс пользователя, события и скрипты. Скрипты, в свою очередь, позволяют расширять возможности продукта, а также придавать новые свойства, которых не было ранее. Например, CQ не имеет интеграции с таким средством тестирования, как BoundsChecker от компании Numga, но при помощи языка скриптов CQ (его роль выполняет язык Perl или Basic), возможно импортирование данных об отчетной сессии в базу CQ.



Рис. 9. Окно свойств дефекта из TestManger. Основные данные о системе и о дефекте, свойства которого выведены.



Рис 10. Окно свойств дефекта из TestManger. Собраны свойства по конфигурации системы, на которой проводилось тестирование.

К сожалению, интеграция CQ, TestManager и Robot не позволяет заполнять поля среды автоматически, но данные, касающиеся среды, могут быть получены при выборе пункта "property" контекстного меню TestManager. Документировать дефект в CQ можно, уже основываясь на этих данных. Следующие рисунки демонстрируют свойства среды для тестируемой машины. Свойства получены в TestManager.

В базовом варианте CQ не предусмотрено описание таких свойств среды, как разрешение экрана, глубина представления цвета, но они реализованы в TestManager, как важная составляющая продукта для поиска сложных ошибок во время проведения распределенного сетевого тестирования (когда одно и тоже приложение одновременно тестируется на нескольких машинах с разными средами). Это не является недостатком, так как необходимые поля создать из CQ Designer.


Содержание раздела