Новичков Александр
rational@interface.ru
29.08.02
В статье рассказывается о средстве управления изменениями Rational ClearQuest, которое позволяет совместно с инструментами тестирования (Robot, TestManager, Purify, Quantify и PureCoverage) тщательно документировать встречающиеся при испытаниях дефекты.
Материал написан в рамках подготовки к семинару и является сопроводительным.
Cтатьей также можно пользоваться как источником информации о технологии тестирования и документирования Rational. Информационная часть статьи рассчитана на людей, знакомых с представленными инструментами тестирования. Описание ClearQuest дано "с нуля" и не требует предварительной подготовки.
Статья открывает собой цикл материалов, посвященных тестированию и документированию по технологии Rational Unified Process.
В целях обобщения существующих подходов автор предлагает читателям написать по адресу rational@interface.ru письмо, в котором Вы вкратце опишете свои подходы в тестировании, ответив на вопросы. Автор будет с нетерпением ждать отзывов о статье, рекомендаций по следующим выпускам, а также информации о том, какие подходы применяете конкретно ВЫ при тестировании собственного программного обеспечения.
ClearQuest - средство управления запросами на изменение (Change Request Management - CRM), специально разработанное с учетом сложной динамической структуры процесса разработки программного обеспечения (ПО). ClearQuest (CQ) отслеживает и управляет любым типом действий, приводящих к изменениям в течение всего жизненного цикла продукта, помогая организациям более предсказуемым (правильным) образом создавать качественное ПО.
ClearQuest - самодостаточный продукт, то есть он способен функционировать отдельно от остальных инструментальных средств Rational. Единственное, что нужно для его полноценной работы, - это СУБД. Из баз данных CQ поддерживает MS SQL, MS Access, Sybase SQL Anywhere и Oracle, но для отдельного проекта только одну.
Мы знаем, что любой проект сопровождается набором изменений, которые нужно где-то хранить и как-то отслеживать. Такая функциональность просто необходима разработчикам, тестировщикам, и особенно руководителям, поскольку для данной категории сотрудников жизненно необходимо знать, кто из участников проекта в какой момент чем занимался. Получается, что CQ создает обычную базу данных, куда складирует всю информацию об изменениях в проекте. Естественно, что сам продукт имеет средства просмотра изменений, а также возможность по созданию новых. Подход, который Rational, называет Итеративным, позволяет не только вносить изменения и дефекты, но также поручать работу над той или иной задачей для определенного сотрудника либо группы сотрудников с последующим завершением.
Что помогает сделать ClearQuest отдельным участникам команд? Ответ можно представить так:
Разработчики могут идентифицировать и располагать по приоритетам элементы действий, которые принадлежат их разделу кода. При помощи механизма запросов разработчики получают инструмент планирования работ по исправлению дефектов. Также разработчики при необходимости сами могут вносить найденные дефекты в состав проекта;
Тестировщики получают мощный инструмент документирования ошибок тестирования ПО;
Руководители проекта могут быстро получать информацию, помогающую им распределять ресурсы разработки, организовывать поток работ и точно определять даты выпуска;
Администраторы могут интегрировать ClearQuest с существующими инструментальными средствами и настраивать его, чтобы приспособить к специфике организации.
CQ представляет собой многомодульное приложение с клиент-серверной архитектурой. Модули являются составной частью CQ и поставляются вместе с ним одним комплектом:
ClearQuest. Основной модуль работы с продуктом. Содержит в себе средства по внесению и документированию дефектов (как частной проблемы управления изменениями), по построению графиков, таблиц, запросов, таблиц, отчетов;
ClearQuest Web. Web - версия продукта, которая способна обеспечить полную функциональность для тех пользователей, которые работают удаленно через Интернет. CQWEB часто пользуются при срочном внесении небольших изменений в базу, находясь удаленно. Данный модуль могут использовать для документирования изменений (дефектов) клиенты или служба технической поддержки;
ClearQuest Designer.Специальный модуль, управляющий схемами баз данных CQ, пользователями и внешним видом CQ;
ClearQuest MultiSite.Расширение для поддержки управления изменениями в регионально удаленных командах. Необходимость в CQMS возникает при работе над сложными проектами, когда команды тестировщиков и разработчиков находятся на значительном удалении, а уровень интеграции должен быть выше, чем просто Web-доступ.
По своей структуре CQ - блочный, расширяемый продукт. Создание базы в нем инициируется руководителем проекта, а осуществляется администратором.
Любая новая база создается в соответствии с одной из схем, имеющихся в CQ Designer. Схема определяет размер и число таблиц в базе, определяет логику работы базы, а также ее внешний вид. Схемы можно модернизировать, улучшая тем самым определенные характеристики.
Расширить функциональность CQ можно при помощи специальных модулей – package’ей. Они устанавливаются непосредственно в Designer, и являются расширением возможностей продукта. Установка нового package на схему базы ведет к созданию новой версии схемы (подобно тому, как это делает ClearCase при модификации артефактов проекта).
Еще одно неоспоримое преимущество CQ заключается в том, что он является не просто расширяемым продуктом, а может быть также настраиваемым и обучаемым. "Обучить" инструмент можно работе с любыми программами и данными, поскольку в CQ имеется возможность создания скриптов по работе как с внутренними, так и с внешними данными. В качестве языка скриптов можно применять знакомый всем Basic и универсальный Perl. Последний особенно выгодно использовать при написании универсальных скриптов, работающих как с Windows, так и с Unix платформами.
В качестве положительных черт данного продукта можно отметить его адаптивность (то есть продукт можно на месте доработать с учетом конкретной функциональности), масштабируемость, простоту в администрировании и легкость в использовании.
В работе с программой каждый участник проекта может заходить в базу и определять собственные запросы.
Запросы на изменения проходят цикл из нескольких состояний (states), начиная с подачи и заканчивая их разрешением. Например, только что поданный запрос находится в состоянии “Подан” (Submitted). После передачи запроса сотруднику он переходит в состояние “Назначен” (Assigned). Начало работы над запросом переводит его в “Открытое” состояние (Open), и вся команда может видеть, что кто-то обрабатывает запрос. Наконец, когда запрос проверен и закрыт, он проходит соответственно стадии “Проверка” (Verify) и “Закрыт” (Resolved).
Известно, что отловить и исправить ошибку в программном коде очень сложно. Обычно все самые неприятные ошибки обнаруживаются на этапе коммерческой эксплуатации продукта со всеми вытекающими отсюда последствиями. Компания Rational предлагает достаточно большой круг программных и методологических решений, направленных на уменьшение числа ошибок в текстах программ.
По RUP процесс тестирования и документирования найденных ошибок должен начинаться вместе с этапом разработки. Чем позже начинается тестирование, тем ниже качество конечного продукта, тем больше времени тратится командой на постоянные доводки продукта в режиме "пожарной команды".
Для тестирования по RUP можно пользоваться следующими инструментами:
Purify – для контроля над ошибками доступа к памяти;
Quantify – для профилирования производительности и оптимизации кода;
PureCoverage – для получения области охвата (сколько процентов кода протестировано);
Robot – для функционального и нагрузочного тестирования;
TestManager – как средство планирования и осуществления тестирования (совместно с Robot). Позволяет не только проводить планирование тестов, но и осуществлять распределенные комбинированные тесты на разных платформах.
Описывать данные инструменты мы здесь не будем. По ссылкам вы сможете прочитать специальные статьи по каждому из них.
Давайте рассмотрим, как Rational предполагает осуществлять документирование ошибок, но сначала еще раз разберемся с терминологией и направленностью инструментов тестирования. Первые три продукта в списке - это продукты необходимые разработчикам во время написания и отладки кода. Четвертый и пятый - для тестировщиков, которым видеть код не всегда нужно, им важно проверить функциональность системы в целом, не вдаваясь в тонкости кодирования. Заметим, что это не всегда так, потому что на этапе определения требований к проекту может быть записано, что тестировщик должен оценивать строгость кода, проверяя его на наличие специальных инструкций или на соответствие определенным стандартам на разработку.
Менеджерам проектов и руководителям отделов абсолютно необходим контроль (мониторинг) состояния текущего проекта, наличия в нем ошибок, также необходим механизм поручения исправления ошибок с последующим контролем вплоть до выхода новой версии продукта или передачи исправленной версии клиенту. А весь контроль необходимо осуществлять в реальном масштабе времени. Здесь и придет на помощь ClearQuest.
Наличие одного CQ недостаточно, поскольку для полноценной работы необходимо взаимодействовать с репозиторием, с определенной версией схемы и физической базой данных. Не вдаваясь в детали того, как это делается (читайте следующий выпуск статьи) отметим, что для целей создания единого репозитория и инициализации схем и баз данных используется утилита Rational Administrator.
Все базы и схемы настраиваются единожды для каждого проекта, представляя собой репозиторий хранения групп пользователей, баз требований RequisitePro, баз изменений ClearQuest и тестовых данных. При создании базы следует выбрать ее тип и схему. Схема нужна для того, чтобы определить, по каким правилам и с какими продуктами будет работать база ClearQuest. В идеальном случае можно воспользоваться схемой ENTERPRISE для получения базы, способной работать с любой программой из комплекта поставки Rational Suite Enterprise (более подробно о схемах читайте в первой части данной статьи, а также в следующей статье). В нашем случае для тестового примера была выбрана схема Test, а в качестве СУБД - MS Access (так как создание файлов mdb не требует установки самого продукта).
За время существования ошибки она проходит несколько стадий, от "начальной" (представленной), до "закрытой", когда дефект исправлен. Ценность ClearQuest состоит в том, что он имеет ряд предустановленных состояний ошибок (дефектов), а также предоставляет возможность компании вносить любое число возможных состояний и именовать их в соответствии со сложившимся корпоративным стандартом (смотрите описание CQ Designer).
Рассмотрим основные этапы нахождения и прохождения ошибки через проект:
1. Начальный (представлено). Вводится человеком, который обнаружил ошибку. Здесь следует отметить, что ошибку может представить любой участник проекта. Это может быть служба технической поддержки, которая принимает нарекания по телефону, и должна как-то документировать свою деятельность. При помощи специальных механизмов, встроенных в CQ, представить ошибку может и сам заказчик (например, через Web-доступ). Еще, как вариант, можно встроить в конечный программный продукт "обратную связь" через электронную почту, когда найденный дефект в работе автоматически (по согласованию с пользователем) отправляется на сервер дефектов, где входит в состав базы дефектов.
2. Назначено. По RUP предполагается наличие роли, действием которой, является просмотр и назначение представленных дефектов на конкретного исполнителя. Обычно это руководитель группы разработчиков или тестировщиков.
3. Открыто. Данный статус начинается с момента реализации (редактирования) исполнителем ошибки. При этом, если говорить о связи CQ с ClearCase, можно отметить, что в базе CQ будет отражено имя файла (или файлов), номер версии и имя разработчика, который начал исправление дефекта. Это очень интересный момент, так как работа над одной ошибкой часто приводит к изменению в нескольких файлах исходного текста;
4. Реализовано.Выход от разработчика. Данное состояние ошибка получает тогда, когда разработчик закончил ее исправление. Ее можно считать сигналом для тестировщиков.
5. Протестировано.Это состояние свидетельствует о том, что версия протестирована. При совместной работе CQ и CC каждую версию сопровождает атрибут, на основании которого строится следующий релиз (продвигается базовая линия). Для того чтобы получить релиз, тестировщик помечает исправленную версию (ставит атрибут "tested"). Интегратор, просматривая атрибуты, делает новый релиз на основе проставленной метки.
6. Закрыто. Финальный этап. Отмечается после отправки версии клиенту.
Существует два способа документирования дефектов - ручной ввод (выполняется непосредственно из среды ClearQuest) и автоматический (CQ вызывается автоматически из средств тестирования Rational). Это значит, что если продукт выпущен в коммерческую эксплуатацию, а сама компания создала службу технической поддержки, то все ошибки, связанные с работой программы, может документировать служба техподдержки, а менеджер проекта может назначать конкретные лица на исправление тех или иных ошибок.
Как видите, способов взаимодействия очень много, и как любой сложный инструмент, CQ требует в первую очередь решения организационно-методических проблем, то есть в компании должны определиться участники команды, и соответствующие им роли: один исправляет, другой вносит, третий контролирует. Без организационных решений будет сложно настроить подобную систему с четко выверенной структурой.
Рис. 1. Здесь отображено главное окно CQ, поделенное на три части: дерево запросов (отображает список проектных запросов), список дефектов (для текущего запроса) и состояние
Рисунок 1 показывает фрагмент окна с запущенным CQ.
В данном окне через интерфейс мы можем построить новый запрос на изменение, новую гистограмму о состоянии проекта (число ошибок) и новый отчет.
Единица представления информации в CQ - это дефект (defect). Все участники проекта изъясняются только на языке дефектов. Сам по себе дефект связан с определенной ошибкой в программной системе, либо может описать более глубокую особенность системы. С дефектами можно связать следующие атрибуты (смотрите рисунки 2 и 3):
ID. Идентификационный код дефекта. Назначается автоматически;
State. Текущий статус дефекта (закрыт, в работе, назначен.... и т.д.);
Headline. Комментарий к дефекту. В зависимости от используемых средств тестирования заполняется автоматически или вручную;
RA. Ассоциация с проектом (репозиторием);
Priority. Приоритет дефекта. Заполняется вручную менеджером проекта;
Severity. Строгость, критичность дефекта. На данном этапе можно, например, определить дефект как нестрогий и исправить в последнюю очередь, либо в последующей версии продукта;
Owner. Владелец дефекта. Здесь следует отметить такую особенность: CQ имеет два контрольных поля - Submitter и Owner. Причем первое поле содержит имя пользователя, под которым была активизирована ошибка, а под вторым заводится владелец ошибки – тот, кому нужно исправить. В идеальном случае имена пользователей могут совпадать, то есть когда разработчик сам исправляет свои же ошибки). Поле владельца может изменять любой участник проекта без ограничений;
Keyword. Набор ключевых слов для дефекта. В качестве ключевых слов часто выносят ассоциации с номерами ошибок, выданными компилятором;
Symptoms. Признак воздействия дефекта (Cosmetic Flaw, Data Corruption, Data Loss, Slow Performance... и так далее). В поле заносится ассоциация с результатом воздействия дефекта на приложение или систему. Список симптомов являет собой часть корпоративного стандарта на тестирование и разрабатывается на этапе определения требований;
Description. Описание проблемы. Если поле Headline необходимо заполнять строго в соответствии с корпоративным стандартом во избежание двусмысленности, то поле описания насыщается произвольным образом. При совместной работе со средствами тестирования и это поле может быть заполнено автоматически;
Resolution. Заключение о разрешении проблемы (fixed/nofixed). Выставляется при завершении работы над дефектом (или при смене статуса);
Attachment.Сюда можно присоединить любой документ (например, код программы или документ);
History. История документирования изменений дефекта (см. рис 2). Генерируется автоматически, показывая список участников проекта, редактировавших данный дефект;
Рис. 2. Отображает историю изменений данного дефекта. Как видно из рисунка, в истории хранятся не только дата и время редактирования, но и тип
TestData. (рис. 3) Определенный набор сопроводительных артефактов (логи, билды...). Поля заполняются при автоматизированном тестировании Robot’ом и TestManager’ом;
Рис. 3. Демонстрация ассоциации со скриптами и средой средств автоматизированного тестирования
Environment. Среда сопровождения. Здесь можно определить тип операционной системы, тип процессора, где был найден дефект. Заполняется вручную;
Requirements. Здесь можно задать связку дефекта с требованием из RequisitePro. Данная связь необходима для документирования сложных ошибок, таких как, противоречие начальным требованиям. Например, разработчик реализовал компонент "кнопка" круглой, а в требованиях на интерфейс указано, что она прямоугольная. Такое противоречие должно быть документировано;
ClearCase. Это поле появляется при правильно настроенной интеграции с данным инструментом. Показывает список версий файлов, которые были редактированы (получены/изменены) в результате исправления данного дефекта;
Над имеющимися дефектами можно произвести четыре действия (actions): modify, reopen, duplicate и delete.
По своей природе CQ является прослойкой между средствами тестирования, участником проекта и физической базой данных (в нашем случае Access). Любые изменения, внесенные в CQ, мгновенно сохраняются в физической базе. Это дополнительный "плюс", так как если руководителю проекта не хватит изобразительных возможностей по отчетности, то всегда можно обратиться напрямую к базе, сформировав SQL-запрос. Рисунки 4 и 5 показывают сформированные таблицы в Access.
Рис. 4. Список таблиц созданной базы в Access
Если посмотреть на CQ в разрезе обоснованности его применения в командной разработке, то получится, что продукт представляет собой достаточно интересный и полезный инструмент для четкого отслеживания происходящего в проекте.
Для лучшей управляемости проекта необходимо административным образом распределить роли участников проекта. Действительно, ClearQuest позволит закрыть собой многие "проектные дыры" только в том случае, когда в компании строго определены роли участников, когда каждый из них отвечает за свой сегмент проводимых работ. Необходимо это сделать в силу многих причин, но одна, пожалуй, самая важная - это гибкая подстройка инструмента под конкретные цели конкретной организации вообще, и под конкретный проект в частности. Соответственно, подобная гибкость требует четкой иерархической структуры команды и определенных правил, во избежание ненужных действий.
Для CQ необходимо решить, кто из участников проекта имеет право на поручение (перепоручение) исправления дефектов (например, менеджер проекта или начальник отдела тестирования), поскольку если все будут иметь право на внесение изменений, то контроль за дефектами будет очень усложнен и запутан.
Информацию о проблеме распределения ролей и взгляд Rational на эту проблему можно узнать из статьи документации (в начале статьи описан типичный сценарий внесений дефекта с распределением ролей).
Рис. 5. Фрагмент таблицы "Defect" со списком дефектов из рис. 1
Robot - средство нагрузочного и функционального тестирования. С его помощью можно тестировать Web-приложения (как часть клиент/серверных систем) а также GUI (оконные компоненты работающих приложений). Описывать целиком продукт я не буду, для этого есть отдельная статья, отмечу лишь некоторые моменты его работы.
Рис. 6 и 7. Диалог, выводящийся после вызова контекстного меню на ошибке. Поле «HeadLine» заполнено вручную. При ручном документировании необходимо четко придерживаться корпоративного стандарта, во избежание дублирующихся записей в базе.
По окончании тестирования Robot передает управление TestManager, в котором в дальнейшем хранятся все сведения о найденных ошибках. Если тестирование прошло успешно, то ничего делать не придется, так как ошибок нет.
В случае возникновения ошибки тестировщик вызывает модуль интеграции с ClearQuest (в Robot он называется Submit ClearQuest Defect и вызывается контекстным меню на имени ошибки).
Description. Короткое описание, говорящее о том, что тестирование проведено Robot’ом;
FoundInBuild. Описывается имя билда, в котором найден дефект. Именованием билда управляют ClearCase и TestManager. Соответственно, можно отследить ход появления ошибок (в первом билде была, а во втором нет);
LogFolder. Папка, в которой сгруппированы логи;
Log. Имя лога, в котором обнаружена ошибка;
Script. Имя скрипта, который "обнаружил" ошибку.
Рис. 8. Описание среды системы, на которой обнаружен дефект. Все поля заполняются вручную. При необходимости добавляются новые поля, а существующие списки могут быть наполнены новыми данными, в соответствии с корпоративным стандартом на тестирование.
Обратим внимание на то, что количество полей, подлежащих автоматическому заполнению, невелико, и здесь необходимо следовать определенным правилам. Первое правило касается заголовка ошибки (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.
Все описанное выше относится только к одному типу отчетов TestManager, а именно отчетам по дефектам. На самом деле, ошибка может быть как ощутимой (не нажалось, повисло, не открылось…) так и не ощутимой (медленно работало, или наоборот, слишком быстро).
Дефекты подобного рода труднее отыскать, так как они не могут быть описаны в виде "работает/не работает", а представляют собой сложные графики и таблицы. Прямой интеграции с CQ у них нет, но ее можно осуществить через CQD.
Перечислим дополнительные отчеты TestManager:
Содержит табличный и графический отчет о производительности приложения. Работает с обоими видами скриптов (виртуальными и графическими). В случае графических скриптов отслеживается время исполнения каждого таймера, проставленного в скрипте Robot’а. Отчет Performance позволяет тестировщикам узнавать, при каком количестве пользователей в процентном отношении начинают появляться существенные временные задержки в исполнении операций.
Рис. 11. Производительность приложения во времени
Статистическая шкала представляется по следующим параметрам:
CmdId - имя команды. идентификатор. В режиме графического тестирования - наименование таймера;
NUM - Число прохождений команды (число проигранных таймеров);
Mean - Среднее время отклика команды;
Std_dev - Среднее временное отклонение (разброс) во времени исполнения команды;
Min - Минимальное время исполнения команды;
50..70... - Процентная шкала, показывающая «завал» тех или иных таймеров от начала тестирования;
Max - Максимальное время исполнения (отклика) команды.
Содержит графический и табличный отчет о числе проведенных временных замеров. Данный вид отчета работает как с виртуальными скриптами, так и с графическими. Взаимодействие с графическими скриптами производится на уровне расставленных таймеров. В отчете измеряется общее число таймеров или запросов, вычисляется процент невыполненных запросов или таймеров.
Представляют интерес следующие поля отчета:
CmdID - имя команды, идентификатор. В режиме графического тестирования - наименование таймера;
Num - Число прохождений команды;
Passed - Число удачных попыток прохождения;
Failеd - Число неудачных проходов;
%Passed- Процент успешных проходов;
%Failed - Процент неудачных проходов.
Рис. 12-13. Число запросов и откликов
Выдает список действий и событий по работе скрипта. Выдаются временные характеристики и тип применяемой команды. Данные выводятся в текстовом виде.
Выводит статистику по всем эмулированным командам и откликам. Отчет описывает производительность и характеристики виртуальных тестеров для каждого сьюта. Отчет работает только с виртуальными тестерами.
Отчет по времени отклика для каждого виртуального тестера
Данные утилиты ориентированны исключительно на разработчиков и позволяют получить на выходе эффективный код с точки зрения устойчивости и производительности (более подробно об утилитах тестирования ЗДЕСЬ).
В отличие от Robot и TestManager, данные инструменты ориентированы на индивидуальное использование, поэтому встроенных средств коллективной разработки они не включают. Возможность сетевой работы появляется только после интеграции с CQ, либо после интеграции с Robot и TestManager (об этом ниже).
Рис. 14. Документирование дефекта из Purify. Поля «Description» и «Headline» заполняются автоматически, позволяя избавляться от дублирующихся ошибок.
Интеграция с CQ у инструментов тестирования для разработчиков происходит так же, как и с Robot’ом – методом вызова контекстного меню на имени ошибки.
Разница (в отношении TestManager) состоит в том, что Purify и Quantify автоматически заполняют поля Headline и Description.
Автозаполнение снимает проблему поиска дублирующихся дефектов, остро стоящую в больших коллективах тестировщиков (так как одну и ту же ошибку разные люди могут назвать по разному, и будет казаться, что проект содержит больше ошибок, чем есть на самом деле); позволяет более точно описывать дефект, с включением имени модуля с ошибкой и его местоположением (с учетом версии билда). Рисунки 14 и 15 демонстрируют основное окно описания дефекта для программных продуктов Purify и Quantify, соответственно.
Rational Purify имеет большой запас по документированию ошибок, так как число распознаваемых ошибок ею велико (подробности ЗДЕСЬ).
Rational Quantify имеет всего два типа ошибок: "Slow Performance in…" и "Performance degradation". Последняя ошибка проявляется при сравнении разных запусков, когда одна из функций системы стала работать медленнее, чем обычно. Инструмент ведет полное документирование, правильным образом заполняя все поля.
Рис. 15. Документирование дефекта из Purify. Поля «Description» и «Headline» заполняются автоматически. В поле «Description» находится полный путь до модуля и до бинарного билда.
Rational PureCoverage имеет всего один тип ошибки - "Coverage regression". В поле Description выносится лишь краткая информация об ошибке без деталей. Заполнение остальных полей: Environment, TestData, производится пользователем в ручном режиме, точно так же, как и в случае с Robot + TestManager.
Все программные продукты тестирования для разработчиков способны экспортировать в текстовом виде отчеты по найденным дефектам, каждый со своей спецификой.
Помимо классических оконных отчетов, ведет несколько логов, из которых можно получить информацию о числе проектных DLL-библиотек, а также о среде тестирования:
(1) Общий отчет "Details":
Program Name: C:\projects\aa\Debug\aa.exe Program Arguments: Working Directory: C:\projects\aa\Debug User Name: Alex Product Version: 2002.05.00 4113 Host Name: ALEX-GOLDER Machine Type: Intel Pentium Pro Model 8 Stepping 10 # Processors: 1 Clock Rate: 847 MHz O/S Version: Windows NT 5.1.2600 Physical Memory: 382 MBytes PID: 0xfbc Start Time: 24.04.2002 14:17:38 Stop Time: 24.04.2002 14:17:52 Elapsed Time: 13330 ms # Measured Cycles: 191748 (0 ms) # Timed Cycles: 2489329 (2 ms) Dataset Size (bytes): 0x4a0001.
(2) "Log"
Quantify for Windows, Copyright (C) 1993-2001 Rational Software Corporation All rights reserved. Version 2002.05.00; Build: 4113; WinNT 5.1 2600 Uniprocessor Free Instrumenting: Far.exe 620032 bytes ADVAPI32.DLL 549888 bytes ADVAPI32.DLL 549888 bytes USER32.DLL 561152 bytes USER32.DLL 561152 bytes SHELL32.DLL 8322560 bytes SHELL32.DLL 8322560 bytes WINSPOOL.DRV 131584 bytes WINSPOOL.DRV 131584 bytes MPR.DLL 55808 bytes MPR.DLL 55808 bytes RPCRT4.DLL 463872 bytes RPCRT4.DLL 463872 bytes GDI32.DLL 250880 bytes GDI32.DLL 250880 bytes MSVCRT.DLL 322560 bytes MSVCRT.DLL 322560 bytes SHLWAPI.DLL 397824 bytes SHLWAPI.DLL 397824 bytes
Purify просто перечисляет в лог-файле найденные ошибки:
[I] Starting Purify'd hello.exe at 27.08.2002 16:52:01
Instrumented executable: D:\xp\Rational\Purify\cache\hello$Purify_D_xp_Rational_Purify_Samples.exe
Working directory: D:\xp\Rational\Purify\Samples
Command line arguments: <none>
Process ID: 0xaec
Thread ID: 0xf74
[I] Starting main
[W] UMR: Uninitialized memory read in strlen {1 occurrence}
Reading 1 byte from 0x00384220 (1 byte at 0x00384220 uninitialized)
Address 0x00384220 is argument #1 of strlen
Address 0x00384220 is at the beginning of a 10 byte block
Address 0x00384220 points to a malloc'd block in heap 0x00380000
Thread ID: 0xf74
Error location
strlen [strlen.obj]
WinMain [hello.c:30]
WinMainCRTStartup [wincrt0.obj]
Allocation location
malloc [malloc.obj]
WinMain [hello.c:28]
WinMainCRTStartup [wincrt0.obj]
PureCoverage выдает статистику по модулям, а также описывает число исполнений каждой строки в модуле:
SourceLines D:\xp\Rational\Coverage\Samples\hello.c D:\xp\Rational\Coverage\Samples\hello.exe LineNumber LineCoverage 18.1 2 23.1 2 26.1 2 26.1 2 27.1 2 27.1 1 27.1 1 30.1 1 32.1 2 36.1 1
Изначально все инструменты тестирования для разработчиков рассчитаны на индивидуальное использование. Однако спектр их применения гораздо шире, если воспользоваться интеграцией с TestManager (TM).
Напомним, что TestManager является средством планирования и осуществления тестирования. ТМ также занимается распределенным сетевым тестированием, при котором одно и тоже испытываемое приложение одновременно исполняется на разных компьютерах с различными операционными системами.
Распределенное тестирование позволяет тестировщику за короткий промежуток времени протестировать билд на совместимость с максимально возможным количеством аппартно-программных платформ.
Рис. 16. Демонстрируется финальный отчет тестирования приложения «калькулятор» при включенной интеграции Robot+Purify
По умолчанию TestManager проводит только функциональное тестирование, но при включении интеграции со средствами разработки может проверить не только внешний вид приложения, но и его внутреннюю структуру, исполняя параллельно с основным процессом функциональной проверки один из трех инструментов тестирования для разработчиков. На выходе в едином логе TestManager собираются ошибки, как функциональные, так и структурные (при распределенном тестировании отчет дается по каждой машине отдельно). Тестировщику останется только вызывать свойства на дефектах и вносить их в базу CQ.
На 16 рисунке показан фрагмент экрана TestManager с TestLOG по окончании процесса тестирования (испытывалось стандартное приложение системы calc.exe. TM запускался вместе с Purify).
Автор надеется, что данная статья ответила на часто задаваемые вопросы по документированию ошибок. Здесь не затрагивались проблемы тестирования как отдельного раздела RUP, так как это тема даже не статьи, а книги.
В следующей части статьи автор подробно опишет интеграцию средств тестирования и отчетности со средством хранения версий ClearCase. Будут рассмотрены две схемы объединения - UCM и "базовая".
По-прежнему автор ждет вопросов и предложений по тематике тестирования и конфигурационного управления по адресу rational@interface.ru
Interface Ltd.
Тел/Fax: +7(095) 105-0049 (многоканальный)
http://www.interface.ru