Содержание


Инфраструктура для автоматизации тестирования интерфейсов

Службы сервис-ориентированной интеграции (SOI)

Comments

В этой статье приводится введение в инфраструктуру автоматизированного тестирования интерфейсов (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 позволяет генерировать как сводные, так и детализированные отчеты.

Рисунок 1. Компоненты ITF
ITF Components
ITF Components

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

Объекты ITF

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

Таблица 1. Атрибуты TestCase
Имя атрибутаТипОбязательный атрибут?Описание
NamestringYНазвание теста
DescriptionstringYОписание теста
OutcomestringYПризнак результата выполнения теста: Success или Failure
InputEndpointObjectYВходная точка доступа (см. таблицу 2)
OutputEndpointObjectYВыходная точка доступа (см. таблицу 3)
TimeoutIntegerYЗначение тайм-аута теста
ExpectedGALCountIntegerYОжидаемое число записей GAL
ExpectedGEHCountIntegerYОжидаемое число записей GEH
GroupObjectYГруппа, к которой принадлежит тест (см. таблицу 4)
Таблица 2. Атрибуты InputEndpoint
Имя атрибутаТипОбязательный атрибут?Описание
NamestringYНазвание точки доступа
JMSPriorityIntegerYJMS-приоритет запроса
RequeststringYСообщение в запросе к тесту
ReplyObjectYОтклик для теста
Таблица 3. Атрибуты OutputEndpoint
Имя атрибутаТипОбязательный атрибут?Описание
NamestringYНазвание точки доступа
BodystringYТело сообщения, отправляемого в точку доступа
Таблица 4. Атрибуты Group
Имя атрибутаТипОбязательный атрибут?Описание
NamestringYИмя группы тестов

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

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

Рисунок 2. Создание теста, группы тестов и точек доступа
Create TestCase/Group/Endpoint
Create TestCase/Group/Endpoint

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

  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. Генерация и выдача сводного отчета с указанием положительных и отрицательных тестов, их групп тестов и точек доступа.

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

Рисунок 3. Выполнение тестов и групп тестов
Execute TestCase/Group
Execute TestCase/Group

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

  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 выполняет обыкновенное строковое сравнение.

Рисунок 4. Генерация отчета о выполнении тестов
Generate Test Execution Report
Generate Test Execution Report

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

  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).

Рисунок 5. Цикл тестирования в ITF
ITF Test Cycle
ITF Test Cycle
Рисунок 6. Взаимодействие CBT и ITF
ITF Process Flow
ITF Process Flow

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

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

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

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

Рисунок 7. Взаимодействие типа "JMS–JMS"
JMS to JMS Interaction
JMS to JMS Interaction

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

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

Рисунок 8. Взаимодействие типа "Web-сервис–Web-сервис"
Web service to Web service Interaction
Web service to Web service Interaction

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

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

Рисунок 9. Взаимодействие типа "JMS–Web-сервис"
JMS to Web service Interaction
JMS to Web service Interaction

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

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

Рисунок 10. Взаимодействие типа "Web-сервис–JMS"
Web Service to JMS Interaction
Web Service to JMS Interaction

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

  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 содержит детализированную информацию о результатах выполнения тестов.
Рисунок 11. ER-модель базы данных
ER Model
ER Model
Таблица 5. Таблица UT_DEF_TEST_CASE
СтолбецТипРазмерОписаниеИнформация для администратора
idvarchar2256GUIDПервичный ключ (PK)
namevarchar21024Уникальное имя каждого тестаУникальный атрибут
descriptionvarchar24000Описание теста-
created_byvarchar21024Имя пользователя, создавшего тест-
create_datetimestamp-Время создания тестаСистемное время
expected_outcomechar1Флаг, задающий ожидаемый результат теста. S означает Success, F – Failure, E – Error. Success говорит о том, что все проверки прошли успешно, в том числе проверки количества записей GAL и GEH. Failure означает, что тест был выполнен, но полученный результат не совпал с ожидаемым. Error означает, что тест был либо завершен по тайм-ауту, либо произошла ошибка. Если в данной колонке указано F, инфраструктура не будет сравнивать полученный результат с ожидаемым. Если задано значение "E", инфраструктура будет ожидать тайм-аута. При этом инфраструктура всегда будет проверять число записей GAL/GEH в журнале.-
input_messageclob-Сообщение, поступающее во входную очередь. В нем можно указывать строку "UNIQUE_TRANSACTIONID_REPLACEMENT", которая должна быть заменена на идентификатор транзакции.-
output_messageclob-Ожидаемое выходное сообщение, которое будет сравниваться с сообщением, полученным от CBT. В нем можно указывать строку "UNIQUE_TRANSACTIONID_REPLACEMENT", которая должна быть заменена на идентификатор транзакции.-
input_endpointvarchar2256ID, соответствующий значению в таблице ut_def_endpoint. Внешний ключ (FK)
output_endpointvarchar2256ID, соответствующий значению в таблице ut_def_endpoint. Внешний ключ (FK)
timeout_intervalnumber-Интервал в миллисекундах. Если в течение этого интервала ITF не получает выходного сообщения, она помечает тест как отрицательный (failure). -
expected_gal_countnumber-Ожидаемое число записей GAL, содержащих указанный идентификатор транзакции.-
expected_geh_countnumber-Ожидаемое число записей GEH, содержащих указанный идентификатор транзакции.-
Таблица 6. Таблица UT_DEF_GROUP
СтолбецТипРазмерОписаниеИнформация для администратора
idvarchar2256GUIDПервичный ключ (PK)
namevarchar21024Уникальное имя группыУникальный атрибут
descriptionvarchar24000Описание группы -
created_byvarchar21024Имя пользователя, создавшего группу-
create_datetimestamp-Время создания группысистемное время
Таблица 7. Таблица UT_DEF_ENDPOINT
СтолбецТипРазмерОписаниеИнформация для администратора
idvarchar2256GUIDПервичный ключ (PK)
namevarchar21024Уникальное имя точки доступаУникальный атрибут
descriptionvarchar24000Описание точки доступа-
created_byvarchar21024Имя пользователя, создавшего точку доступа-
create_datetimestamp-Время созданияСистемное время
typevarchar2256JMS или WS-
message_typevarchar2256Байты или текст-
encodingvarchar2256Кодировка байтовых сообщенийПо умолчанию UTF8
comparechar1Y или N-
destination_queuevarchar21024Очередь назначения для запросов-
reply_to_queuevarchar21024Очередь, в которую должны поступать отклики-
prioritynumber-Приоритет запросов-
delivery_modevarchar21024Режим доставки сообщений-
correlation_idvarchar21024ID корреляции сообщений-
timeoutnumber-Значение тайм-аута-
soap_actionvarchar21024Действие SOAP (Action) для Web-сервиса-
Таблица 8. Таблица UT_DEF_CASE_GROUP_REL
СтолбецТипРазмерОписаниеИнформация для администратора
idvarchar2256Уникальный идентификатор. ITF использует GUID.PK
created_byvarchar21024Имя пользователя, создавшего отношение-
create_datetimestamp-Время созданияСистемное время
def_group_idvarchar2256ID для связи с таблицей ut_def_groupFK
def_test_case_idvarchar2256ID для связи с таблицей ut_def_test_caseFK
Таблица 9. Таблица UT_EXE_SUMMARY
СтолбецТипРазмерОписаниеИнформация для администратора
idvarchar2256GUIDPK
user_namevarchar21024Имя пользователя, выполнившего тест-
descriptionvarchar24000Описание выполненных тестов-
external_referencevarchar21024Может содержать информацию о количестве ошибок и т.д.-
test_requestclob-Полная версия запроса для тестирования-
start_timetimestamp-Время начала выполнения теста-
end_timetimestamp-Время завершения теста-
success_countnumber-Число тестов с результатом Success-
failure_countnumber-Число тестов с результатом Failure-
error_countnumber-Число тестов с результатом Error-
total_countnumber-Общее число выполненных тестов-
Таблица 10. Таблица UT_EXE_DETAILS
СтолбецТипРазмерОписаниеИнформация для администратора
idvarchar2256GUIDPK
exe_summary_idvarchar2256ID для связи с таблицей ut_exe_summaryFK
def_test_case_idvarchar2256ID для связи с таблицей ut_def_test_caseFK
actual_outcomechar1Результат теста (S, F или E). Расшифровка приведена в поле ut_def_test_case.outcome.-
test_outcomechar1Окончательный признак успешности теста после сравнения с ожидаемым результатом (S, F или E). Расшифровка приведена в поле ut_def_test_case.outcome. -
test_inputclob-Входные данные-
test_outputclob-Выходные данные-
start_timetimestamp-Время начала выполнения теста-
end_timetimestamp-Время завершения теста-
gal_countnumber-Полученное число записей GAL-
geh_countnumber-Полученное число записей GEH-
errorvarchar24000Сообщения об ошибках, их описания, стек вызовов при исключениях и т.д.-

Заключение

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


Ресурсы для скачивания


Похожие темы


Комментарии

Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы
ArticleID=630455
ArticleTitle=Инфраструктура для автоматизации тестирования интерфейсов
publish-date=03032011