Тестирование компонентов с помощью Rational QualityArchitect

• Введение
• Снижение проектного риска с помощью тестирования компонентов на ранних стадиях разработки
• Преимущества тестирования компонентов в итеративной среде
• Проблемы тестирования компонентов
• Проблемы тестирования компонентов: как можно эффективно протестировать компонент B?
• Сценарий и архитектура – проблемы тестирования
• Решение компании Rational: Rational QualityArchitect
• Визуальное моделирование как прелюдия к тестированию
• Подход Rational к тестированию компонентов
• Использование Rational QualityArchitect
• Пример 1: Тестирование отдельных компонентов
• Создание тестовых программных заглушек
• Пример 2: Тестирование по сценарию
• Rational QualityArchitect как часть общего группового решения
• Преимущества Rational QualityArchitect при тестировании компонентов
• Дополнительная информация

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

С другой же точки зрения, развитие Интернет почти ничего не изменило - современные процветающие компании по прежнему используют те же способы и методы работы, которыми в течение многих лет пользовались преуспевающие организации. Оптимальные методики разработки ПО со временем не потеряли своего значения. Напротив, эти принципы – итеративная разработка ПО, управление требованиями, использование архитектур на основе компонентов, инструменты визуального моделирования, проверка качества и контроль изменений ПО – становятся все более и более обязательными вместе с ростом сложности, темпа и значения разработки ПО.

Для успешной работы в современных условиях разработчикам необходимы инструменты, реализующие эти принципы таким способом, который одновременно экономит время и повышает качество. Для этого идеально подходит комбинация оптимальных методик. Например, группы разработчиков, занимающиеся визуальным моделированием архитектур на основе компонентов, могут ускорить разработку путем повторного использования как своих собственных компонентов, так и готовых компонентов от других производителей. Более того, эти группы повышают качество своей продукции, поскольку их процесс позволяет выявить потенциальные проблемы архитектуры на ранних стадиях цикла разработки. Аналогично, группы, проводящие тестирование на ранних стадиях итеративного цикла разработки, также неявным образом повышают качество, поскольку они проверяют каждый шаг процесса. В то же время эти организации могут сократить жизненный цикл проекта, так как они обнаруживают и исправляют ошибки на ранних стадиях, когда их исправление требует меньше времени и ресурсов.

Рисунок 1. Устранение проблем, обнаруженных при раннем тестировании, обходится значительно дешевле.

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

Даже если группа уверена в качестве своих системных компонентов, общая уверенность в системе все равно может быть недостаточной. Рассмотрим, например, простую систему, состоящую из пяти компонентов, надежность каждого из которых оценивается (либо по метрикам тестового покрытия, либо полуколичественными методами) равной 95%. Поскольку надежность системы является кумулятивной величиной, ее общая оценка составляет 95% x 95% x 95% x 95% x 95%, или чуть более 77%. В то время, как вероятность возникновения проблемы в любом компоненте составляет лишь 1/20, для всей системы она достигает значения 1/4 – и это для системы из относительно небольшого числа компонентов.

В отличие от этого, процесс разработки, реализующий тестирование компонентов в течение всего итеративного процесса, имеет несколько существенных преимуществ:

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

Хотя раннее тестирование обладает огромными преимуществами, оно не часто встречается на практике, в особенности, когда дело касается тестирования компонентов среднего уровня без графического интерфейса пользователя. Почему? Оно требует много времени и усилий, поэтому в прошлом цена преодоления этих практических проблем часто перевешивала преимущества. Кроме того, поскольку большинство тестов рассчитаны на конкретные компоненты, возможностей для их повторного использования остается немного. Многие организации считают расточительством создание тестовой среды с нуля, ее использование и выбрасывание после каждого проекта – они предпочитают сосредоточить свои ограниченные ресурсы в других областях.

Рассмотрим пример разработки тестов для компонента B на рис. 2.

Рисунок 2. Упрощенная многоуровневая система.

В то время, как компонент B уже готов к тестированию, другие компоненты (A, C и D), вероятно, еще не готовы. Даже в случае готовности, эти компоненты могут иметь недостатки, которые исказят результаты тестов и существенно усложнят отслеживание проблем в компоненте B. Эта ситуация вынуждает разработчиков создавать свои собственные одноразовые тестовые драйверы и программные заглушки. Для имитирования поведения компонента A тестовый драйвер должен управлять компонентом B, посылать в него запросы, обеспечивать допустимый диапазон входных данных и регистрировать ответы.

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

Даже после создания и тестирования отдельных компонентов остаются существенные проблемы. При тестировании по сценарию несколько компонентов собираются вместе для проверки последовательности методов, определенных в диаграмме взаимодействия. Если клиентское ПО еще не готово, то для выполнения сценария разработчикам необходимо потратить время на создание имитации клиента. Кроме того, если при проведении этих тестов организации необходимо измерить производительность системы для оценки жизнеспособности ее архитектуры, то необходимое для выполнения тестов программное обеспечение должно быть более сложным и его разработка потребует еще больше времени и ресурсов. И наконец, при выполнении тестового сценария очень редко можно заметить какие-либо видимые признаки основной деятельности – часто единственным способом проверки правильности функционирования компонента является проверка базы данных, к которой он обращается. Также значительной проблемой может быть создание теста, который автоматизирует этот процесс.

В целях упрощения тестирования и повышения его эффективности компания Rational разработала революционный инструмент: Rational QualityArchitect. Этот новый инструмент является частью непрерывной работы компании Rational по оснащению разработчиков средствами, необходимыми для быстрого создания высококачественного программного обеспечения. Rational QualityArchitect устраняет наиболее утомительные и сложные аспекты тестирования компонентов путем использования содержащейся в визуальных моделях информации для автоматической генерации кода, имитирующего незавершенные компоненты – A, C и D на рис. 2. Эта возможность позволяет разработчикам сосредоточить усилия на создании актуальных тестовых примеров вместо того, чтобы тратить время на создание подверженных ошибкам одноразовых тестовых программ. По сути Rational QualityArchitect ускоряет итеративную разработку с помощью компонентов J2EE и COM/DCOM.

Ключом к экономической эффективности раннего тестирования является использование для генерации тестовых программ артефактов, созданных на более ранних стадиях процесса, – визуальных моделей. К этому моменту разработчики уже представляют себе необходимое поведение каждого компонента и это представление реализовано в модели. Несмотря на то, что степень использования организациями визуального моделирования различна, отраслевые эксперты и пользователи единогласно признают инструмент Rational Rose лидирующим мировым решением визуального моделирования.

Rational Rose позволяет управлять всеми моделями и вести их с помощью единого инструмента и единого языка – унифицированного языка моделирования или UML. Компания Rational первой использовала язык UML, который стал отраслевым стандартом для определения, визуализации и построения программного обеспечения и систем. Rational Rose предоставляет мощные средства прямого и обратного проектирования, позволяя группам разработчиков, не применявшим ранее визуальное проектирование, создавать визуальную модель на основе существующего исходного кода программы. Это дает возможность группам, никогда ранее не занимавшимся моделированием, точно определить взаимодействия компонентов и использовать эту информацию для выполнения их тестирования.

Rational QualityArchitect предназначен помочь разработчикам одновременно повысить качество и скорость разработки. Для достижения этого Rational QualityArchitect предоставляет уникальную поддержку трех принципов эффективного тестирования компонентов:

• Автоматическая генерация компонентных тестов на основе визуальной модели
  При использовании старого ручного метода время и усилия, необходимые для создания тестовых драйверов и программных заглушек, составляли значительную часть общего объема разработки. Эффективность этой утомительной работы также была низкой, поскольку тестовые программы часто использовались лишь однократно, а затем становились бесполезными.
  Rational QualityArchitect автоматически генерирует тестовые драйверы и программные заглушки непосредственно из визуальной модели и при любом ее изменении может автоматически сгенерировать их повторно.
• Непрерывная проверка реализации проекта
  Поскольку проект системы развивается в процессе своей реализации, разработчики могут упустить из виду основную цель. В этом случае они часто пренебрегают тестированием реализации текущей версии проекта и откладывают его до тестирования всей системы.
  С помощью Rational QualityArchitect разработчики могут легко проверить, насколько реализация соответствует проекту, поскольку они генерируют тесты непосредственно из самого проекта. При каждом изменении проекта тесты можно обновить, гарантировав соответствие текущей реализации последним изменениям проекта.
• Обеспечение взаимодействия компонентов разных уровней
  Хотя изолированное тестирование компонентов способно обеспечить их более высокое качество, оно не может гарантировать хорошую работу подсистем, собранных из этих компонентов.
  
  Rational QualityArchitect автоматически создает тесты взаимодействий из диаграмм последовательностей и диаграмм взаимодействий, содержащихся в визуальной модели. Разработчики могут использовать эти тесты взаимодействий для достоверной оценки общей функциональности группы архитектурно значимых компонентов и точного выявления проблем во взаимодействиях между отдельными компонентами.

Rational QualityArchitect позволяет проводить автоматическое тестирование компонентов и интегрированных подсистем. Здесь приведено два примера, поясняющих, как этот новый инструмент компании Rational помогает обеспечить качество создаваемого продукта и сократить общее время разработки.

Рисунок 3. Для тестирования метода в компоненте B необходимо наличие тестового драйвера в компоненте A и программных заглушек в компонентах C и D.

Рассмотрим следующий пример. В интерфейсе компонента B реализован метод с названием ExecuteWithdrawal(). Чтобы протестировать этот метод и убедиться в корректности его функционирования, необходимо вызвать его с несколькими комбинациями входных данных и проверить ответ на каждую из них. Основанный на данных подход Rational QualityArchitect отделяет логику процедуры, т.е. тестовый драйвер, от тестовых данных, указанных в таблице. В таблице содержится список входных значений и ожидаемых результатов при вызове метода ExecuteWithdrawal(). Пример простого набора данных приведен на рис. 4.

В этом примере метод ExecuteWithdrawal() использует три входных параметра (Номер счета, Личный номер и Сумма) и возвращает на выходе Сообщение. Rational QualityArchitect автоматически создает две вещи: тестовый сценарий и пустую таблицу, содержащую все эти четыре столбца с соответствующими типами данных. Тестовый сценарий считывает из таблицы входные данные, вызывает метод ExecuteWithdrawal() с этими данными и затем сверяет полученный результат с ожидаемым на основании таблицы. Как показано в варианте 6, в числе ожидаемых результатов для метода ExecuteWithdrawal() может быть и сообщение об ошибке (exception). С помощью Rational QualityArchitect разработчик может сосредоточиться исключительно на создании подробных тестовых примеров и реализовать их, заполнив строки в этой таблице, поскольку Rational QualityArchitect автоматически генерирует код тестового драйвера на нужном языке – Visual Basic или Java.

Продолжая этот пример, предположим, что метод ExecuteWithdrawal() вызывает методы ValidatePin() и GetBalance(), реализованные в компонентах C и D, которые еще не готовы к тестированию. Тест метода ExecuteWithdrawal() нельзя выполнить без этих методов. Однако Rational QualityArchitect может сгенерировать программные заглушки для методов, вызываемых компонентом B, с помощью той же информации о структуре модели Rational Rose, которая использовалась при создании тестового драйвера. Программные заглушки также управляются данными и их поведение сходно с поведением тестового драйвера, однако имеется одно существенное отличие. Тестируемый компонент вызывает заглушку и передает ей один или несколько входных параметров, после чего заглушка должна возвратить ожидаемый результат. Сгенерированный Rational QualityArchitect код заглушки ищет и находит в таблице строку с указанными параметрами. Строка содержит либо выходное значение для конкретного набора входных данных, либо специальную инструкцию, вызывающую сообщение об ошибке на выходе заглушки.

Вариант	Введенный номер счета	Выходной баланс	Ожидаемое сообщение об ошибке
1	12345678	1000	Отсутствует
4	88888888	0	Отсутствует
5	99999999		<Выдача сообщения об ошибке>

На рисунках 5a и 5b показаны простые таблицы для двух методов, вызываемых ExecuteWithdrawal(). Как и раньше, Rational QualityArchitect создает пустые таблицы с соответствующими столбцами и тестовый код, выполняющий поиск в таблице и возврат правильного результата. Разработчикам необходимо лишь заполнить таблицу подходящими значениями.

Особое значение имеет предоставляемая Rational QualityArchitect возможность заставить заглушку выдать сообщение об ошибке. В интегрированной системе тестирование обработки сообщений об ошибке компонента может быть чрезвычайно сложным. Определение особых случаев и приведение работающей системы в состояние, при котором конкретный метод должен выдать сообщение об ошибке, часто требует огромных усилий и длительной настройки. С помощью Rational QualityArchitect тестирование обработки сообщений об ошибках значительно упрощается – для этого достаточно заполнить поле Ожидаемое сообщение об ошибке соответствующими именами ошибок.

Как только отдельные методы и компоненты прошли тестирование и могут быть собраны с приемлемым уровнем уверенности, появляется возможность начать тестирование интегрированных подсистем. Этот тип тестирования, называемый тестированием по сценарию, сверяет поведение компонентов с определениями диаграммы взаимодействий. Эти тесты предназначены для подробного воспроизведения последовательности событий в архитектурно значимой транзакции и, таким образом, ее проверки. Сценарии используются для конструирования как простых тестов для отдельных компонентов, так и более сложных тестов, охватывающих несколько компонентов. На этом уровне существует параллельная проблема – для тестирования можно использовать завершенное клиентское приложение, но если клиент еще не готов, необходимо либо отложить тестирование, либо перенаправить ресурсы на разработку имитации клиента.

Как и в случае тестирования на уровне компонентов, информация, необходимая для создания этих тестовых драйверов, уже хранится в модели в виде диаграмм последовательностей и операций. С помощью Rational Rose и UML транзакция и ее бизнес-логика моделируются в виде последовательности действующих лиц (объектов или компонентов) и пересылаемых между ними сообщений (вызовов методов и их возвращаемых данных). Затем разработчики могут снова использовать эту информацию с помощью Rational QualityArchitect и на любой стадии тестирования создать тестовые сценарии с различными уровнями детализации для комбинаций реальных и имитированных компонентов. Подсистемы часто состоят из меньших подсистем, каждая из которых может быть протестирована как независимо, так и совместно с другими. С помощью Rational QualityArchitect можно создать тесты на любом уровне – как для каждой из малых независимых подсистем, так и для состоящей из них более крупной подсистемы.

Рисунок 6. Простая диаграмма последовательностей.

Rational QualityArchitect использует поведенческие спецификации модели для создания каркасов тестовых сценариев, реализующих имитацию клиента при выполнении транзакций. При генерации тестовых сценариев Rational QualityArchitect предлагает разработчику вставить дополнительные контрольные точки для каждого сообщения в диаграмме. Рассмотрим транзакцию, показанную на рис. 6. На сообщение, посылаемое из компонента A в компонент B для выполнения транзакции, нет ответного сообщения. Когда Rational QualityArchitect генерирует клиента для проведения этой транзакции через компоненты B, C и D, для проверки транзакции используется контрольная точка. Поскольку большинство транзакций приводят к созданию или обновлению информации в базе данных (или в какой-либо другой форме хранения данных), для упрощения проверки поведения транзакций среднего уровня, подобных приведенной на рисунке, Rational QualityArchitect вставляет точки контроля базы данных.

При первом запуске сценария код контрольной точки предлагает разработчику использовать генератор запросов. С помощью этого генератора разработчик может подключиться к базе данных и построить повторяемый запрос, который обнаруживает данные, обновленные или добавленные при выполнении данной транзакции. Если результаты запроса соответствуют правильному выполнению транзакции, подтвержденному разработчиком, данные сохраняются в качестве прототипа для сравнения с результатом запроса при следующем запуске сценария. Данные, используемые для проведения этих тестов, задаются путем заполнения одной или нескольких таблиц так же, как и при тестировании отдельных блоков, но при этом в таблице необязательно указывать ожидаемые результаты. Полученные сценарии могут также использоваться для проверки работы компонентов среднего уровня, что позволяет разработчикам выполнить тесты производительности и стресс-тесты среднего уровня системы без клиентского приложения.

Компания Rational предлагает полный спектр инструментов для всех видов тестирования – включая тестирование надежности, функциональности и производительности – на всех стадиях цикла разработки. Компания Rational позволяет разработчикам использовать при тестировании, где это возможно, результаты других стадий процесса разработки, особенно анализа требований, проектирования и управления изменениями.

Все артефакты, определенные и созданные при разработке, сохраняются в едином репозитарии, доступном каждому разработчику группы. Интегрированные инструменты, общие данные и общая методология приводят к улучшению обмена информацией внутри группы и повышению производительности как ее отдельных членов, так и всей группы в целом. Например, для быстрого начала разработки модели используются требования и прецеденты. Визуальные модели, в свою очередь, используются для создания тестов с помощью Rational QualityArchitect. Затем результаты тестов сравниваются с требованиями, что позволяет точно оценить степень выполнения проекта на каждой стадии разработки.

Результаты раннего и итеративного тестирования помогают достоверно оценить ход выполнения разработки. Эту степень выполнения можно визуализировать с помощью Rational TestManager – универсального удобного командного центра для контролирования и управления всеми операциями тестирования. Вместе с Rational QualityArchitect, Rational TestManager помогает следить за ходом проектов путем предоставления точных данных для реалистичного управления, а также позволяет избежать принятия желаемого за действительное в процессе планирования.

Без использования Rational QualityArchitect раннее тестирование является настолько длительным и неэффективным мероприятием, что многие организации отказываются от него, несмотря на его очевидную ценность. Использование Rational QualityArchitect делает раннее тестирование реально осуществимым благодаря многократной автоматической генерации тестовых программ по мере развития модели в ходе разработки. Преимущества, предоставляемые Rational QualityArchitect группам разработки ПО, очень разнообразны – от неуловимых до вполне осязаемых, от ускорения разработки до повышения качества программного обеспечения.

Весь процесс разработки становится более структурированным, измеряемым и прозрачным, поскольку результаты тестов компонентов способствуют усилению начальных критериев тестирования системы, предотвращающие его преждевременность. Rational QualityArchitect позволяет разработчикам сконцентрироваться на творческих аспектах создания тестов, поэтому, вместо написания и отладки тестовых драйверов и заглушек, они получают время на обдумывание наилучшего способа проверки компонента. Благодаря тесному сотрудничеству между разработчиками и системными архитекторами при совместном использовании визуальных моделей, они естественным образом развивают между собой более продуктивные взаимоотношения. Для разработчиков, знакомых с моделированием, Rational QualityArchitect предлагает беспрецедентную простоту эффективного тестирования компонентов. А в проектах, не имеющих модели, можно использовать Rational Rose для обратного проектирования модели, обеспечивающей основу для тестирования с помощью Rational QualityArchitect. Возможности имитации сообщений об ошибках и изолированного тестирования компонентов позволяют выполнять тесты с Rational QualityArchitect на таком уровне тщательности, который невозможно достигнуть любым способом при тестировании интегрированной системы.

Rational QualityArchitect ускоряет итеративную разработку, предоставляя разработчикам следующие возможности:

• Автоматическая генерация тестов компонентов на основе визуальной модели.
• Непрерывная проверка реализации проекта по мере его развития.
• Обеспечение правильной совместной работы отдельных компонентов при сборке подсистем путем генерации тестов взаимодействия на основе диаграмм последовательностей, взаимодействий и деятельности.

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

• Средства тестирования от компании Rational
• Эффективная разработка программного обеспечения с использованием технологий и инструментов компании RATIONAL
• Учебные курсы по продуктам Rational
• Средства тестирования Rational (VisualTest, Purify, PureCoverage, Quantify)
• Приобрести продукты Rational Software в электронном магазине IT-shop

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Отправить ссылку на страницу по e-mail
Форум по продуктам Rational Software