| ||||||||||||
| ||||||||||||
|
2002 г
Управление изменениями, тестированием и документированием с использованием технологий RationalНовичков Александр ПредисловиеВ статье рассказывается о средстве управления изменениями 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 отдельным участникам команд? Ответ можно представить так:
CQ представляет собой многомодульное приложение с клиент-серверной архитектурой. Модули являются составной частью CQ и поставляются вместе с ним одним комплектом:
По своей структуре CQ - блочный, расширяемый продукт. Создание базы в нем инициируется руководителем проекта, а осуществляется администратором. Любая новая база создается в соответствии с одной из схем, имеющихся в CQ Designer. Схема определяет размер и число таблиц в базе, определяет логику работы базы, а также ее внешний вид. Схемы можно модернизировать, улучшая тем самым определенные характеристики. Расширить функциональность CQ можно при помощи специальных модулей – package’ей. Они устанавливаются непосредственно в Designer, и являются расширением возможностей продукта. Установка нового package на схему базы ведет к созданию новой версии схемы (подобно тому, как это делает ClearCase при модификации артефактов проекта). Еще одно неоспоримое преимущество CQ заключается в том, что он является не просто расширяемым продуктом, а может быть также настраиваемым и обучаемым. "Обучить" инструмент можно работе с любыми программами и данными, поскольку в CQ имеется возможность создания скриптов по работе как с внутренними, так и с внешними данными. В качестве языка скриптов можно применять знакомый всем Basic и универсальный Perl. Последний особенно выгодно использовать при написании универсальных скриптов, работающих как с Windows, так и с Unix платформами. Основные возможности ClearQuest:
В качестве положительных черт данного продукта можно отметить его адаптивность (то есть продукт можно на месте доработать с учетом конкретной функциональности), масштабируемость, простоту в администрировании и легкость в использовании.
Запросы на изменения проходят цикл из нескольких состояний (states), начиная с подачи и заканчивая их разрешением. Например, только что поданный запрос находится в состоянии “Подан” (Submitted). После передачи запроса сотруднику он переходит в состояние “Назначен” (Assigned). Начало работы над запросом переводит его в “Открытое” состояние (Open), и вся команда может видеть, что кто-то обрабатывает запрос. Наконец, когда запрос проверен и закрыт, он проходит соответственно стадии “Проверка” (Verify) и “Закрыт” (Resolved). Хранение ошибок. ДефектоскопияИзвестно, что отловить и исправить ошибку в программном коде очень сложно. Обычно все самые неприятные ошибки обнаруживаются на этапе коммерческой эксплуатации продукта со всеми вытекающими отсюда последствиями. Компания Rational предлагает достаточно большой круг программных и методологических решений, направленных на уменьшение числа ошибок в текстах программ. По RUP процесс тестирования и документирования найденных ошибок должен начинаться вместе с этапом разработки. Чем позже начинается тестирование, тем ниже качество конечного продукта, тем больше времени тратится командой на постоянные доводки продукта в режиме "пожарной команды". Для тестирования по RUP можно пользоваться следующими инструментами:
Описывать данные инструменты мы здесь не будем. По ссылкам вы сможете прочитать специальные статьи по каждому из них.
Менеджерам проектов и руководителям отделов абсолютно необходим контроль (мониторинг) состояния текущего проекта, наличия в нем ошибок, также необходим механизм поручения исправления ошибок с последующим контролем вплоть до выхода новой версии продукта или передачи исправленной версии клиенту. А весь контроль необходимо осуществлять в реальном масштабе времени. Здесь и придет на помощь 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):
Рис. 2. Отображает историю изменений данного дефекта. Как видно из рисунка, в истории хранятся не только дата и время редактирования, но и тип
Рис. 3. Демонстрация ассоциации со скриптами и средой средств автоматизированного тестирования
Над имеющимися дефектами можно произвести четыре действия (actions): modify, reopen, duplicate и delete.
Рис. 4. Список таблиц созданной базы в Access Если посмотреть на CQ в разрезе обоснованности его применения в командной разработке, то получится, что продукт представляет собой достаточно интересный и полезный инструмент для четкого отслеживания происходящего в проекте. Для лучшей управляемости проекта необходимо административным образом распределить роли участников проекта. Действительно, ClearQuest позволит закрыть собой многие "проектные дыры" только в том случае, когда в компании строго определены роли участников, когда каждый из них отвечает за свой сегмент проводимых работ. Необходимо это сделать в силу многих причин, но одна, пожалуй, самая важная - это гибкая подстройка инструмента под конкретные цели конкретной организации вообще, и под конкретный проект в частности. Соответственно, подобная гибкость требует четкой иерархической структуры команды и определенных правил, во избежание ненужных действий. Для CQ необходимо решить, кто из участников проекта имеет право на поручение (перепоручение) исправления дефектов (например, менеджер проекта или начальник отдела тестирования), поскольку если все будут иметь право на внесение изменений, то контроль за дефектами будет очень усложнен и запутан. Информацию о проблеме распределения ролей и взгляд Rational на эту проблему можно узнать из статьи документации (в начале статьи описан типичный сценарий внесений дефекта с распределением ролей).
Рис. 5. Фрагмент таблицы "Defect" со списком дефектов из рис. 1 Документирование ошибок из Robot и TestManagerRobot - средство нагрузочного и функционального тестирования. С его помощью можно тестировать Web-приложения (как часть клиент/серверных систем) а также GUI (оконные компоненты работающих приложений). Описывать целиком продукт я не буду, для этого есть отдельная статья, отмечу лишь некоторые моменты его работы.
Рис. 6 и 7. Диалог, выводящийся после вызова контекстного меню на ошибке. Поле «HeadLine» заполнено вручную. При ручном документировании необходимо четко придерживаться корпоративного стандарта, во избежание дублирующихся записей в базе. По окончании тестирования Robot передает управление TestManager, в котором в дальнейшем хранятся все сведения о найденных ошибках. Если тестирование прошло успешно, то ничего делать не придется, так как ошибок нет. В случае возникновения ошибки тестировщик вызывает модуль интеграции с ClearQuest (в Robot он называется Submit ClearQuest Defect и вызывается контекстным меню на имени ошибки).
Рис. 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Все описанное выше относится только к одному типу отчетов TestManager, а именно отчетам по дефектам. На самом деле, ошибка может быть как ощутимой (не нажалось, повисло, не открылось…) так и не ощутимой (медленно работало, или наоборот, слишком быстро). Дефекты подобного рода труднее отыскать, так как они не могут быть описаны в виде "работает/не работает", а представляют собой сложные графики и таблицы. Прямой интеграции с CQ у них нет, но ее можно осуществить через CQD. Перечислим дополнительные отчеты TestManager: PerformanceСодержит табличный и графический отчет о производительности приложения. Работает с обоими видами скриптов (виртуальными и графическими). В случае графических скриптов отслеживается время исполнения каждого таймера, проставленного в скрипте Robot’а. Отчет Performance позволяет тестировщикам узнавать, при каком количестве пользователей в процентном отношении начинают появляться существенные временные задержки в исполнении операций.
Рис. 11. Производительность приложения во времени Статистическая шкала представляется по следующим параметрам: CmdId - имя команды. идентификатор. В режиме графического тестирования - наименование таймера; CmdStatusСодержит графический и табличный отчет о числе проведенных временных замеров. Данный вид отчета работает как с виртуальными скриптами, так и с графическими. Взаимодействие с графическими скриптами производится на уровне расставленных таймеров. В отчете измеряется общее число таймеров или запросов, вычисляется процент невыполненных запросов или таймеров. Представляют интерес следующие поля отчета: CmdID - имя команды, идентификатор. В режиме графического тестирования - наименование таймера;
Рис. 12-13. Число запросов и откликов CmdTraceВыдает список действий и событий по работе скрипта. Выдаются временные характеристики и тип применяемой команды. Данные выводятся в текстовом виде. CmdUsageВыводит статистику по всем эмулированным командам и откликам. Отчет описывает производительность и характеристики виртуальных тестеров для каждого сьюта. Отчет работает только с виртуальными тестерами. RespVSTimeОтчет по времени отклика для каждого виртуального тестера Документирование из средств Purify, Quantify, PureСoverageДанные утилиты ориентированны исключительно на разработчиков и позволяют получить на выходе эффективный код с точки зрения устойчивости и производительности (более подробно об утилитах тестирования ЗДЕСЬ). В отличие от Robot и TestManager, данные инструменты ориентированы на индивидуальное использование, поэтому встроенных средств коллективной разработки они не включают. Возможность сетевой работы появляется только после интеграции с CQ, либо после интеграции с Robot и TestManager (об этом ниже).
Рис. 14. Документирование дефекта из Purify. Поля «Description» и «Headline» заполняются автоматически, позволяя избавляться от дублирующихся ошибок. Интеграция с CQ у инструментов тестирования для разработчиков происходит так же, как и с Robot’ом – методом вызова контекстного меню на имени ошибки. Разница (в отношении TestManager) состоит в том, что Purify и Quantify автоматически заполняют поля Headline и Description.
Rational Purify имеет большой запас по документированию ошибок, так как число распознаваемых ошибок ею велико (подробности ЗДЕСЬ). Rational Quantify имеет всего два типа ошибок: "Slow Performance in…" и "Performance degradation". Последняя ошибка проявляется при сравнении разных запусков, когда одна из функций системы стала работать медленнее, чем обычно. Инструмент ведет полное документирование, правильным образом заполняя все поля.
Рис. 15. Документирование дефекта из Purify. Поля «Description» и «Headline» заполняются автоматически. В поле «Description» находится полный путь до модуля и до бинарного билда. Rational PureCoverage имеет всего один тип ошибки - "Coverage regression". В поле Description выносится лишь краткая информация об ошибке без деталей. Заполнение остальных полей: Environment, TestData, производится пользователем в ручном режиме, точно так же, как и в случае с Robot + TestManager. Встроенные средства отчетностиВсе программные продукты тестирования для разработчиков способны экспортировать в текстовом виде отчеты по найденным дефектам, каждый со своей спецификой. QuantifyПомимо классических оконных отчетов, ведет несколько логов, из которых можно получить информацию о числе проектных 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 Распределенное сетевое тестирование. Взаимодействие средств тестирования для разработчиков c TestManagerИзначально все инструменты тестирования для разработчиков рассчитаны на индивидуальное использование. Однако спектр их применения гораздо шире, если воспользоваться интеграцией с TestManager (TM). Напомним, что TestManager является средством планирования и осуществления тестирования. ТМ также занимается распределенным сетевым тестированием, при котором одно и тоже испытываемое приложение одновременно исполняется на разных компьютерах с различными операционными системами. Распределенное тестирование позволяет тестировщику за короткий промежуток времени протестировать билд на совместимость с максимально возможным количеством аппартно-программных платформ.
Рис. 16. Демонстрируется финальный отчет тестирования приложения «калькулятор» при включенной интеграции Robot+Purify По умолчанию TestManager проводит только функциональное тестирование, но при включении интеграции со средствами разработки может проверить не только внешний вид приложения, но и его внутреннюю структуру, исполняя параллельно с основным процессом функциональной проверки один из трех инструментов тестирования для разработчиков. На выходе в едином логе TestManager собираются ошибки, как функциональные, так и структурные (при распределенном тестировании отчет дается по каждой машине отдельно). Тестировщику останется только вызывать свойства на дефектах и вносить их в базу CQ. На 16 рисунке показан фрагмент экрана TestManager с TestLOG по окончании процесса тестирования (испытывалось стандартное приложение системы calc.exe. TM запускался вместе с Purify). ЗаключениеАвтор надеется, что данная статья ответила на часто задаваемые вопросы по документированию ошибок. Здесь не затрагивались проблемы тестирования как отдельного раздела RUP, так как это тема даже не статьи, а книги. В следующей части статьи автор подробно опишет интеграцию средств тестирования и отчетности со средством хранения версий ClearCase. Будут рассмотрены две схемы объединения - UCM и "базовая". По-прежнему автор ждет вопросов и предложений по тематике тестирования и конфигурационного управления по адресу rational@interface.ru Interface Ltd.
|
 | |||||||||
| |||||||||
|
CITForum © 1997–2025