Средства тестирования приложений для разработчиков

       

ClearCase и ClearQuest


Данный набор продуктов позволяет разработчикам не просто исправлять определенные версии файлов, выводя их для этого в состояние Check-out, но и ассоциировать то или иное исправление в соответствии с теми дефектами, которые описаны в системе. Кажущийся сам по себе простым, данный механизм поможет извлечь из проекта всю информацию по ошибкам и изменениям, приведшим к их исправлению либо к порождению новых. Всю информацию можно извлечь подобно поднятию виноградной грозди за верхушку, рассматривая ее с разных сторон!

Здесь скрывается первый подводный камень - Rational предлагает для решения проблем с "change set" две методики: UCM (Unified Code Management) и ClearCase Base. О достоинствах каждой из них мы поговорим в одной из следующих статей, а сейчас остановимся только вот на чем: UCM предлагает универсальный подход и содержит в себе правила быстрого построения проектов установленного образца. UCM уже предопределил все роли и действия, а также осуществил интеграцию ClеarCase с ClearQuest. UCM - это попытка Rational осуществить унифицированный подход к тестированию. Но в погоне за универсальностью UCM потерял ряд важных черт, главная из которых - гибкая настройка под конкретный процесс. Тем не менее UCM развивается, улучшается, но для больших компаний со сложной инфраструктурой пока не совсем пригоден. Поэтому мы рассмотрим вариант интеграции ClearCase Base с уже сконфигурированной базой в ClearQuest.

Сначала проведем интеграцию, а потом поговорим о концепции.

"Внедрение" продуктов друг в друга - процесс двусторонний. Сначала ClearCase настраивается с помощью модуля ClearCase ClearQuest Integration. В появившемся окне необходимо указать, с каким VOB будет проведена интеграция и какие операции будут попадать в базу. Например, можно сделать так, что в базу будут попадать только действия check-out, связанные с ветвью DEBUG, и так далее (рис. 2).

Рисунок 2. Диалог интеграции ClearCase. Слева изображен список вобов, а в центре типы запросов. Здесь можно отметить, что интеграция со стороны ClearCase проходит на уровне инсталляции в VOB триггеров, вызывающих ClearQuest

То есть здесь мы настраиваем реакцию ClearCase на то или иное событие.
Соответствующим образом для каждого события будет вызываться список дефектов из ClearQuest, с которыми нужно проводить ассоциацию. Но этой настройки мало. Теперь схему ClearQuest необходимо "научить понимать" события ClearCase. Делается это следующим образом.

  1. Запускается ClearQuest Designer.
  2. Загружается схема, по которой была сгенерирована база данных.
  3. Через меню Package подключается интеграция с ClearCase.
  4. Схема сохраняется.
  5. Делается обновление базы.
Теперь, как только пользователь даст команду CheckOUT, ClearCase не только попросит прокомментировать действия, но и предложит указать ассоциацию с определенным дефектом в базе ClearQuest. Значит, можно узнать, какие версии в ClearCase были порождены той или иной ошибкой. Ассоциативные связи могут быть двух типов:
  1. Один файл, несколько проассоциированных дефектов.
  2. Несколько дефектов на основе одного файла.
Диалоговое окно, содержащее ассоциации, отображено на рис. 3. Итак, мы получаем следующий алгоритм разработки программного обеспечения:
  1. Разработчик создает работающий код.
  2. Тестировщик (или разработчик) обнаруживает ошибку:
    1. заносит описание ошибки (defect) в базу данных;
    2. вносит тип ошибки и ее критичность;
    3. назначает ответственного.
  3. Разработчик исправляет ошибку:
    1. отыскивает в базе модуль и дефект;
    2. выводит соответствующий файл в состояние CheckOut и ассоциирует его с одним или несколькими дефектами;
    3. исправляет ошибку и помечает ее как исправленную (fixed).
  4. Руководитель проекта получает полную статистику о наличии ошибок в проекте, степени их локализации и критичности.


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