Введение

В этой статье приводится введение в инфраструктуру автоматизированного тестирования интерфейсов (ITF) систем сервис-ориентированной интеграции (Service Oriented Integration – SOI). Эта проверенная на практике инфраструктура предоставляет возможности для управления наборами тестовых данных при юнит-тестировании интерфейсов, группирования тестов и генерации отчетов о результатах их выполнения. Она может использоваться для тестирования любого промежуточного программного обеспечения и продуктов, созданных на основе архитектуры ESB (Enterprise Service Bus – сервисная шина предприятия).

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

Инфраструктура, рассматриваемая в этой статье, представляет собой подход к организации тестирования интерфейсов систем SOI методом "белого ящика" (white box testing). Использование этого метода требует знания внутреннего устройства системы для определения оптимальной стратегии тестирования. Инфраструктура включает мощную среду для юнит-тестирования и компонентного тестирования, в которой каждый компонент может тестироваться как изолированно от других, так и с использованием необходимых заглушек и генераторов данных. Ее можно легко расширить с целью поддержки регрессионного и дымового тестирования (smoke testing) интерфейсов при различных внешних условиях. Инфраструктура предоставляет следующие возможности:

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

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

В начало

Назначение инфраструктуры тестирования интерфейсов

Написание автоматизированных тестов с использованием данной инфраструктуры часто позволяет выявить недостатки в реализации или архитектуре системы. Юнит-тесты выступают в качестве первых пользователей ESB-системы, тем самым помогая идентифицировать ошибки или нехватку той или иной функциональности. Как правило, разработчикам требуется время на освоение ITF, но в итоге написанные ими тесты начинают играть роль документации ESB-системы. ITF позволяет легко создавать юнит-тесты на основе данных. Каждый такой тест выполняется для каждой записи источника данных и имеет полный доступ к тестовой информации.

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

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

В начало

Возможности ITF

Ниже перечислены некоторые из ключевых возможностей тестирования, поддерживаемых ITF.

Разработка на основе тестирования

Разработка на основе тестирования (test-driven development – TDD) – это подход к созданию программного обеспечения, при котором юнит-тесты пишутся до тестируемого кода. Разработчикам предлагается создавать тесты на основе спецификации еще до начала проектирования и реализации системы. TDD поддерживает непрерывный цикл разработки программного обеспечения, состоящий из небольших легко управляемых этапов. Благодаря своей поддержке TDD, ITF может играть значительную роль в проектах по созданию корпоративных систем.

Проверки

Чаще всего признаком успешности выполнения юнит-теста является соответствие полученных данных ожидаемому результату. Проверки (assertions) в ITF позволяют разработчикам задавать ожидаемые результаты, которые будут сравниваться с результатами, полученными в процессе выполнения теста. Ожидаемые результаты могут быть динамическими, т.е. их значения могут частично устанавливаться на этапе выполнения при помощи регулярных выражений. Эта возможность играет очень важную роль в тестах на основе сравнений.

Покрытие кода

ITF предоставляет полную поддержку проверки степени покрытия кода (code coverage). Эта функция автоматически вставляет трассирующий код, который выполняет мониторинг процессов, вызываемых при выполнении тестов. Наиболее существенным достоинством такого подхода является определение участков кода, не покрытого тестами. Нередко в приложениях встречаются логические ветви или код обработки исключений, которые не выполняются в стандартных ситуациях. Такие участки кода необходимо выявлять. При этом покрытие кода, при всей своей полезности, не может являться единственным индикатором эффективности тестов. Эта функция не может определить, каким именно образом тесты выполняют тот или иной участок кода и могут ли они пропустить ошибки, которые проявятся на других наборах данных. Вследствие этого необходимо создавать наборы тестов с разными входными данными и порядком выполнения – это поможет убедиться в том, что код корректен, функционально полон и отказоустойчив. Тем не менее покрытие кода позволяет выявить части приложения, которые не охвачены тестами.

Отрицательное тестирование

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

Журналирование и тестирование обработки исключений

Стандарты разработки подразумевают эффективное журналирование (logging) и обработку возникающих исключений. В процессе написания юнит-тестов разработчикам необходимо убедиться, что приложение корректно заносит сообщения в журнал и правильно обрабатывает исключения. Многие корпоративные приложения используют инфраструктуры глобального аудита (Global Audit Logging – GAL) и глобальной обработки исключений (Global Exception Handling – GEH). ITF может успешно интегрироваться с подобными решениями. Она предоставляет средства, при помощи которых разработчик может указать число ожидаемых сообщений разных типов в журнале для каждого юнит-теста. Таким образом, можно проверять, все ли сообщения (в том числе сообщения об обработке исключений) заносятся в журнал тем или иным участком кода.

Регрессионное тестирование

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

Тестирование производительности

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

Требования к инфраструктуре

Ниже перечислены некоторые из важных требований, которым удовлетворяет ITF.

1. ITF должна позволять добавлять новые тесты.
2. ITF должна предоставлять возможности по группированию тестов в наборы (test suits).
3. ITF должна предоставлять возможность выполнения и построения отчетов о выполнении отдельных тестов, групп тестов, а также всех имеющихся тестов.
4. ITF должна позволять создавать точки доступа различных типов, которые можно использовать многократно в разных тестах.
5. Тесты ITF включают следующие атрибуты:
   1. уникальное имя;
   2. описание;
   3. группу (или группы), к которой принадлежит тест;
   4. информацию об источнике входных данных;
   5. информацию о том, куда поступают результаты выполнения теста;
   6. значение тайм-аута.
6. Точки доступа ITF включают следующую информацию:
   1. тип точки: Web-сервис (WS) или сервис сообщений Java (JMS). На основе этого атрибута определяется тип тестируемого сервиса: JMS-JMS, WS-WS и т.д.;
   2. тип сообщения: байтовый поток, текст и т.д.;
   3. тип кодировки. Этот атрибут необходим для байтовых сообщений. Значение по умолчанию – UTF-8;
   4. флаг сравнения. Этот атрибут говорит о том, что инфраструктура должна сравнить полученный результат выполнения теста с ожидаемым;
   5. атрибуты заголовка:
      1. destinationQueue: имя очереди назначения;
      2. replyToQueue: имя очереди replyTo. Этот атрибут необходим только для точек доступа типа WS. По умолчанию используется временная очередь;
      3. JMSPriority: приоритет сообщений JMS. Значение по умолчанию – 4;
      4. JMSDeliveryMode: режим доставки сообщений JMS (PERSISTENT или NON_PERSISTENT). Значение по умолчанию – PERSISTENT;
      5. JMSCorrelationID;
      6. requestTimeout: значение тайм-аута при доставке сообщений. Указывается только для точек доступа типа WS.
   6. Информация о свойствах:
      1. SOAPAction: требуется только для точек доступа типа WS;
   7. Body: требуется только для точек доступа типа JMS;
   8. Request: требуется только для точек доступа типа WS. Этот атрибут должен включать SOAP-конверт Web-сервиса;
   9. Reply: требуется только для точек доступа типа WS. Этот атрибут должен включать SOAP-конверт Web-сервиса.
7. Результаты выполнения тестов ITF должны включать один из следующих признаков:
   1. Success: тест был выполнен успешно;
   2. Failure: результаты были получены, но не совпали с ожидаемыми результатами;
   3. Error: в процессе выполнения теста возникла ошибка, в результате чего данные для сравнения получены не были.
8. Тесты ITF должны быть способны выполняться в любой среде, пригодной для развертывания.
9. ITF должна предоставлять возможность проверки журнальных сообщений GAL и GEH.
10. ITF должна позволять поддерживать разные варианты выполнения тестов.

В начало

Архитектура

ITF включает систему запуска тестов, которая позволяет добавлять и модифицировать юнит-тесты, выполнять тесты и генерировать отчеты о результатах выполнения. Тесты ITF могут быть написаны с использованием того же промежуточного программного обеспечения, что и тестируемые интерфейсы. Эта возможность облегчает работу с ITF в интегрированных средах разработки (IDE).

ITF хранит всю информацию, относящуюся к тестам, их выполнению и точкам доступа в специальной базе данных. Благодаря такому подходу разработчики могут иметь доступ к репозиторию тестов с любого компьютера, что позволяет выполнять одни и те же тесты с разных рабочих станций. ITF имеет такой же доступ к всем компонентам ESB, как и тестируемый код, поскольку она использует те же параметры соединения и клиентские библиотеки. При этом конфигурационные параметры могут быть изменены на этапе выполнения, что облегчает тестирование в различных окружениях. Стандартные параметры соединения, поддерживаемые ITF, позволяют обращаться к таким компонентам ESB, как сервисы корпоративных сообщений (Enterprise Messaging Services – EMS), JDBC и точки доступа SOAP.

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

В начало

Проектирование

Объекты ITF

ITF использует четыре типа объектов: TestCase, InputEndpoint, OutputEndpoint и Group. Объекты TestCase, атрибуты которых приведены в таблице 1, представляют собой тесты. В таблице 2 показаны атрибуты объектов InputEndpoint, которые определяют тип взаимодействия между ITF и тестируемым кодом, генерирующим входные данные. Взаимодействие между ITF и тестируемым кодом на выходе описывается объектами типа OutputEndpoint (атрибуты приведены в таблице 3). Объекты типа Group (таблица 4) описывают группирование тестов в наборы.

Процесс создания тестов в ITF

На рисунках 2, 3 и 4 показаны шаги, выполняемые ITF в процессе создания тестов, групп и точек доступа, запуска тестов и их групп, а также генерации отчетов о выполнении тестов.

Входные данные

1. Имя теста.
2. Описание теста.
3. Список групп, к которым принадлежит данный тест.
4. Входные и выходные сообщения. Они состоят из следующих атрибутов:
   1. ссылка на точку доступа;
   2. сообщения Request и Reply для точек доступа типа WS;
   3. тело сообщения (Body) для точек доступа типа JMS;
   4. атрибуты, заменяющие соответствующие поля точки доступа.
5. Ожидаемое число записей GAL/GEH.
6. Ожидаемый результат выполнения теста: Success, Failure или Error.
7. Тайм-аут – время ожидания отклика в выходной точке доступа после отправки сообщения во входную точку доступа.

           
<?xml version = "1.0" encoding = "UTF-8"?>
<Input xmlns:def = "http://www.ibm.com/ams/common/unittestframework/definition">
	<TestCase>
		<def:Name>Sample</def:Name>
		<def:Description>Sample TestCase for illustration</def:Description>
		<def:Outcome>S</def:Outcome>
		<def:InputEndpoint>
			<def:Name>SampleWSEndpoint</def:Name>
			<def:JMSPriority>7</def:JMSPriority>
			<def:Request><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
                <SOAP-ENV:Envelope xmlns:SOAP-ENV=
                                        "http://schemas.xmlsoap.org/soap/envelope/">
                <SOAP-ENV:Body></SOAP-ENV:Body></SOAP-ENV:Envelope>]]>
                                         </def:Request>
			<def:Reply>Some reply with UNIQUE_TRANSACTIONID_REPLACEMENT
                                        </def:Reply>
		</def:InputEndpoint>
		<def:OutputEndpoint>
			<def:Name>SampleJMSEndpoint</def:Name>
			<def:Body>Some body with UNIQUE_TRANSACTIONID_REPLACEMENT
                                        </def:Body>
		</def:OutputEndpoint>
		<def:Timeout>10</def:Timeout>
		<def:ExpectedGALCount>1</def:ExpectedGALCount>
		<def:ExpectedGEHCount>0</def:ExpectedGEHCount>
		<def:Group>
			<def:Name>Sample</def:Name>
		</def:Group>
	</TestCase>
</Input>

Выполняемые действия

1. Получение входных данных.
2. Проверка существования подходящих описаний в базе данных.
3. Создание точек доступа (при необходимости).
4. Создание групп (при необходимости).
5. Создание тестов.
6. Определение отношений между тестами и группами тестов.
7. Генерация и выдача сводного отчета с указанием положительных и отрицательных тестов, их групп тестов и точек доступа.

Результат: созданные тесты, группа тестов и точки доступа.

Входные данные

1. Имя теста.
2. Имя группы тестов.

          
<?xml version = "1.0" encoding = "UTF-8"?>
<Input>
  <TestCases>
    <TestCase xmlns = "http://www.ibm.com/ams/common/unittestframework/execution">
	<Name xmlns = "http://www.ibm.com/ams/common/unittestframework/definition">
             testcase1</Name>
		</TestCase>
	</TestCases>
</Input>

Основные шаги

1. Получение входных данных.
2. Выборка всех подходящих тестов из базы данных на основе полученной на вход информации.
3. Запуск отдельного процесса для каждого теста.
4. Сбор результатов выполнения каждого теста.
5. Обновление сводной информации в базе данных.
6. Выдача сводной и детализированной информации пользователю.

Вспомогательные шаги

1. Проверка типов сообщений точек доступа.
2. Запуск объекта-слушателя выходной точки доступа.
3. Отправка сообщений через входную точку доступа.
4. Ожидание отклика в случае, если тип входной точки доступа – WS.
5. Отправка отклика на полученное сообщение в случае, если тип выходной точки доступа – WS.
6. Сравнение сообщения, полученного через выходную точку доступа, с ожидаемым сообщением, если установлен флаг сравнения. Подробная информация об операции сравнения в ITF приведена в описании компонента валидации ниже.
7. Проверка отклика на входящее сообщение (в определенных случаях и при установленном флаге сравнения).
8. Подсчет числа журнальных записей GAL и GEH и сравнение с ожидаемым числом записей.
9. Выдача результатов.

Результат: результаты выполнения теста или группы тестов, сохраненные в базе данных.

Компонент валидации

Ожидаемые результаты могут содержать динамические поля, например временные метки, ID корреляции и т.д. В таких случаях они должны быть заменены по шаблону исключения (exclusion pattern), который заставляет ITF выполнять сравнение полученных результатов с ожидаемыми на основе регулярных выражений. При отсутствии этой функции сравнение всегда было бы отрицательным. Если ожидаемые результаты не содержат динамических полей, ITF выполняет обыкновенное строковое сравнение.

Входные данные

1. Имя теста.
2. Имя группы тестов.
3. Номер версии.

          
<?xml version = "1.0" encoding = "UTF-8"?>
<Input>
	<Report>
		<TestCase xmlns = 
"http://www.ibm.com/ams/common/unittestframework/report">
			<Name xmlns = 
"http://www.ibm.com/ams/common/unittestframework/definition">testcase1</Name>
			<Version xmlns = 
"http://www.ibm.com/ams/common/unittestframework/definition">testcase1</Version>
		</TestCase>
	</Report>
</Input>

Шаги

1. Получение тестов или групп тестов и версии.
2. Запрос к базе данных ITF для получения результатов выполнения.
3. Генерация файла с суммарной информацией о выполнении.

Результат: сформированный сводный отчет о выполнении тестов.

В начало

Цикл тестирования в ITF

Цикл тестирования ITF показан на рисунке 5. Разработчик или специалист по тестированию указывает тесты, группы тестов и точки доступа, описывая их при помощи шаблонов входных данных, предоставляемых ITF. Инфраструктура самостоятельно создает экземпляры TestCase, Group и Endpoint, сохраняя их в базе данных. В процессе выполнения тестов тестируемый код (code being tested – CBT) получает входные данные от ITF через одну из описанных точек доступа. После выполнения CBT отправляет отклик обратно в ITF через одну из выходных точек доступа. При необходимости CBT может отправлять отклики через входные точки, а также может получать отклики от ITF через выходные точки доступа (рисунок 6).

Далее мы рассмотрим четыре типа взаимодействия CBT и ITF, которые могут применяться в зависимости от типа SOI-интеграции.

1. JMS-JMS.
2. Web-сервис-Web-сервис.
3. JMS-Web-сервис.
4. Web-сервис-JMS.

Взаимодействие типа "JMS–JMS"

В этом случае входными и выходными точками доступа CBT являются очереди JMS, а следовательно, нет необходимости в откликах. ITF посылает сообщения в входную очередь CBT и получает сообщения через выходную очередь. Инфраструктура сравнивает выходное сообщение с ожидаемым сообщением, указанным для данного теста. Результат этого сравнения определяет общий результат выполнения теста (рисунок 7).

Взаимодействие типа "Web-сервис–Web-сервис"

В этом случае входными и выходными точками доступа CBT являются Web-сервисы. Вследствие этого оба отклика являются обязательными. Входящее сообщение отправляется во входную очередь CBT, после чего ITF ждет отклика, который должен поступить в очередь, указанную в поле replyTo запроса. После получения выходных данных от CBT ITF сравнивает его с ожидаемым ответом. Инфраструктура эмулирует Web-сервис, вызываемый тестируемым кодом, отправляя заранее подготовленный ответ в выходную очередь, имя которой CBT указывает в поле replyTo. В результате CBT отправляет ответ во входную очередь, указанную в поле replyTo, и он также попадает в ITF. После этого инфраструктура сравнивает ответ, полученный через входную точку доступа, с ожидаемым ответом и на основании этого определяет признак успешности теста (рисунок 8).

Взаимодействие типа "JMS–Web-сервис"

В этом случае CBT не генерирует отклик на входящий запрос, но ожидает отклик на собственный ответ. Вначале ITF отправляет сообщение во входную очередь. CBT обрабатывает поступившие данные и отправляет ответ в выходную очередь. Этот ответ попадает в ITF и сравнивает с ожидаемым ответом для данного теста. При этом инфраструктура имитирует вызываемый Web-сервис, отправляя заранее подготовленный отклик в выходную очередь, указанную CBT в поле replyTo (рисунок 9).

Взаимодействие типа "Web-сервис–JMS"

При этом типе взаимодействия CBT откликается на входящий запрос, но не ожидает отклика на сообщение, которое было отправлено в выходную очередь. Вначале ITF отправляет сообщение во входную очередь. Получив на вход запрос, CBT обрабатывает его и отправляет ответ в выходную очередь, который затем попадает в ITF и сравнивается с ожидаемым результатом. Кроме того, ITF ожидает, что CBT отправит отклик в очередь, указанную в поле replyTo. Этот отклик также проверяется на соответствие ожидаемому результату. В свою очередь CBT не ожидает ответа на сообщение, которое он отправляет в выходную очередь (рисунок 10).

Схема базы данных

1. ITF использует шесть таблиц для хранения всей необходимой информации (см. таблицы 5–10).
2. Таблица UT_DEF_TEST_CASE содержит все данные, относящиеся к тестам.
3. Таблица UT_DEF_GROUP содержит все данные, относящиеся к группам тестов.
4. Таблица UT_DEF_ENDPOINT coдержит все атрибуты точек доступа.
5. Таблица UT_DEF_CASE_GROUP_REL содержит данные, связывающие тесты и группы тестов.
6. Таблица UT_EXE_SUMMARY содержит сводную информацию о результатах выполнения тестов.
7. Таблица UT_EXE_DETAILS содержит детализированную информацию о результатах выполнения тестов.

В начало

Заключение

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

Ресурсы

• Оригинал статьи: Automated Interface Test Framework (Сравана Кришна и Саран Санкар, developerWorks, апрель 2010 г.). (EN)
  
  
• В магазине технической литературы содержатся книги на эту и другие темы. (EN)
  
  
• Загрузите ознакомительные версии продуктов IBM, а также опробуйте средства разработки приложений и промежуточное программное обеспечение IBM, в частности DB2®, Lotus®, Rational®, Tivoli® и WebSphere® на сайте online-тестирования IBM SOA Sandbox. (EN)
  
  

Об авторах

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Назначение инфраструктуры тестирования интерфейсов
• Возможности ITF
• Архитектура
• Проектирование
• Цикл тестирования в ITF
• Заключение
• Ресурсы
• Об авторах
• Комментарии