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

Интеграционное тестирование редко попадает в заголовки статей из раздела «Информационные технологии». Масштаб ошибок интеграции не сравнится по степени критичности и по размеру понесенных убытков с ошибками безопасности.

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

Однако важность интеграционного тестирования недооценивать нельзя. Грамотное интеграционное тестирование – один из основных шагов на пути к выпуску надежного продукта.

Что же это за тестирование и как оно проводится?

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

Бизнес сегодня опирается на множество программных решений: вебсайт, системы ERP, CRM, CMS. От интеграции всех систем зависит качество обработки запросов пользователей, скорость предоставления услуг и успешность бизнеса в целом.

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

Интеграционное тестирование: обзор проекта

Заказчик

В a1qa обратился представитель популярного англоязычного журнала. Издание доступно как в печатном виде, так и онлайн. На тестировании онлайн-портала и сфокусировалась команда a1qa.

Задача проекта

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

Для реализации функции подписки и ее управления заказчик использовал следующие программные решения:

• CMS-решение eZ Publish. Функция – предоставлять любые данные о подписках с применением различных фильтров: типа подписки, ее продолжительности, применяемых скидок, бонусов и так далее.
• Вебсайт, через который пользователь взаимодействует с системой.
• CRM Salesforce. Функция – хранение данных о пользователях и приобретенных ими подписках. Дополнительная надстройка позволяет команде заказчика управлять приобретенными подписками, а также создавать новые и проверять старые подписки.
• SaaS-решение Zuora для выставления счетов и обработки платежей.
• Обмен данными между системами осуществляется с помощью сервисной шины Mule ESB.
• База данных как инструмент Business Intelligence.
• Salesforce Marketing Cloud – инструмент рассылки корреспонденции и коммуникации с пользователями.
• Drupal ранее использовался вместо eZ Publish. На данный момент все еще остается системой, хранящей данные о зарегистрированных пользователях, и инструментом для публикации статей, видео- и аудио-контента.

Процесс оформления подписки был построен следующим образом:

1. Подготовка набора данных, создание подписки.
2. Предоставление пользователю возможности приобретения подписки после внесения персональных и платежных данных.
3. Обработка заказа третьей стороной, предоставляющей свои услуги клиенту в данной сфере.

Цель клиента

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

Задача тестирования

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

Важно было проверить, как они взаимодействуют между собой, и ответить на вопрос: способна ли вся система решать требуемые задачи?

Стратегия проведения интеграционного тестирования a1qa

1. Определены ключевые бизнес-процессы, которые должна выполнять система: создание, отмена, приостановка и возобновление подписки, изменение платежной информации для подписки и т.д.
2. Разработана тестовая документация с учетом всех возможных вариаций. Вариации – различные альтернативные выполнения операций (например, отмена подписки может произойти по желанию заказчика, а может быть произведена автоматически, если платежные данные были отклонены банком), а также различные параметры (например, тип продукта). В документации требовалось учесть проверку того, например, что создание подписки пройдет успешно для всех продуктов в рамках каждого бизнес-процесса.
3. Проведение тестирования, которое заключалось в пошаговом прохождении каждого бизнес-процесса со стартового компонента (где он был инициирован) через все промежуточные и до финального (или финальных) с проверкой того, что все данные передаются правильно, а ожидаемые события на самом деле случаются.

Большинство процессов включало в себя передачу данных из одного модуля (чаще всего из Salesforce) во все остальные. Если начальной точкой был не SF, то информация из модуля поступала в MuleESB, а потом в SF, а оттуда во все остальные (опять же, через MuleESB).

На проведение тестирования интеграции было потрачено порядка 40% всех трудозатрат QA-команды.

Трудности

Большинство трудностей при проведении тестирования интеграции было вызвано недостаточной проработкой требований на начальном этапе проекта. Именно некачественные требования стали причиной множества дефектов и нестабильности системы в целом.

Поясним. Изначально требования выглядели как набор пользовательских историй (User Story) в JIRA и содержали только заголовки без какого-либо пояснения. Создавали их чаще всего разработчики.

Команда a1qa инициировала изменения в подходе написания требований: теперь для них обязательно добавляются описания и Acceptance Criteria, создаются промежуточные задачи с четким определением, кто и за что отвечает.

Автоматизация интеграционного тестирования

Автоматизация тестирования – непростой вопрос, который требует внимательного сопоставления всех «за» и «против».

Автоматизация интеграционного тестирования требует еще более внимательного подхода. С одной стороны, разработка автотестов сокращает время на выполнение тестов. С другой стороны, автотесты эффективны, когда работают с повторяющимися наборами данных или, как минимум, предсказуемыми.

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

Результаты

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

Подводя итоги

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

Для проведения эффективного тестирования, обнаружения всех дефектов и недочетов команда по тестированию должна:

1. Понимать структуру продукта, знать, как между собой взаимодействуют все модули;
2. Владеть спецификой проекта. Это важно для написания хороших тест-кейсов, анализа результатов прогона тестов, выбора между ручным и автоматизированным тестированием.

Как заказать интеграционное тестирование?

Для получения бесплатной консультации по интеграционному тестированию, заполните .

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

Теоретические основы

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

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

Ещё одним недостатком многих инструментальных методов исследования является недифференцированность тревоги и тревожности. Тревога и тревожность – различные, но системно связанные понятия, анализировать которые следует сопряжено для того, чтобы понять их личностный смысл в реальной жизненной ситуации человека. Именно таким образом в комплексной многомерной диагностике нарушений психической адаптации исследуется патогенез формирующихся психогений и социогений, внутренней картины болезни, тенденций к саморазрушающему поведению и др. Особенно четко эти общие механизмы формирования клинической картины болезни, где тревога – тревожность играют существенную (а нередко и основополагающую) роль, прослеживаются преимущественно при невротических и неврозоподобных расстройствах соматоформного типа (F4 – МКБ-10). Универсальность тревоги как аффективного регулятора поведения заключается прежде всего в ее опосредующей значимости и включенности в другие психические феномены, поэтому позитивная диагностика этого феномена чрезвычайно важна для квалификации формирующейся клинической картины болезни при тревожно-фобических (F40), других тревожных расстройствах (F.41), особенно при смешанных тревожных и депрессивных расстройствах (F41.2), при посттравматических стрессовых расстройствах (F43.1) и расстройствах адаптации (F43.2), соматоформных вегетативных расстройствах (F45.3), при соматогенных и др. нарушениях аффективного круга. Более того, тревога как эмоциональное состояние и тревожность как фундаментальная личностная характеристика, должна анализироваться во многих сферах функционирования личности: в спорте, военной и операторской деятельности специалистов, профотборе, педагогическом процессе и других областях, где предъявляются специальные требования к адаптивным возможностям человека. Нарушения психической адаптации как сложной многомерной системы приспособительных механизмов личности возникают в силу различных причин и обстоятельств, и в настоящее время одной из наиболее практически значимых задач совместной деятельности психиатров и врачей общего профиля с клиническими психологами является диагностика, содержательная квалификация и комплексная коррекция состояний условно патологического типа, к которым относятся нарушения психической адаптации.

Особенностью этих расстройств являются клинически слабо структурированные, нестойкие, полиморфные симптомы, не имеющие четкой нозологической принадлежности. Частота их встречаемости по данным литературы варьирует в широких пределах (22,0%-89,7%), но имеет четкую тенденцию к увеличению, прежде всего в связи с изменениями качества жизни населения в нашей стране. В их генезе, наряду с влиянием так называемых социально-стрессовых расстройств и социальной фрустрированности имеют место и личностные факторы – неумение людей самостоятельно разрешать кризисные ситуации, внутриличностные, семейные и производственные конфликты, что неизбежно приводит к хроническому стрессу и дистрессам, сопровождающимся тревожными переживаниями.

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

Внутренняя структура

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

С целью дифференцированного и детализации представления о влияниях различных компонентов самооценки испытуемого как носителя тревоги, в отношении накопленного эмпирического материала был применен метод факторного анализа, что позволило в структуре 15 признаков выделить 5 факторов, интерпретируемых, как уже говорилось, в качестве вспомогательных шкал, а именно “эмоциональный дискомфорт” (ЭД), “астенический компонент тревожности" (АСТ), “фобический компонент” (ФОБ), “тревожная оценка перспективы” (ОП) и “социальная защита" (СЗ) (факторы даны в порядке убывания объяснимой дисперсии – соответственно – 2,082; 1,512; 1,459; 1,458, 1,280). Подробное описание эквивалентных им вспомогательных шкал приводится ниже. Полученные факторные нагрузки по признакам используются в качестве диагностических коэффициентов новых вспомогательных шкал, построенных на базе извлеченных факторов, что повышает диагностический потенциал теста ИТТ. Прежде всего, это усиливает информативность методики в целом, а также повышает ее надежность в принятии решения, обеспечивая тем самым высокий уровень дифференцированности значений отдельных признаков как субкомпонентов тревоги-тревожности. Таким образом оказалось возможным рассматривать психологическую структуру тревоги – тревожности в экспериментально заданных рамках.

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

Таким образом, интегративный тест тревожности состоит из двух субтестов, предназначенных для раздельной оценки тревоги и тревожности. Каждый субтест содержит 15 утверждений, с каждым из которых испытуемый должен выразить своё согласие по 4-балльной шкале. Утверждения субтестов полностью идентичны, различается лишь инструкция. В итоге из теста можно извлечь общий балл по каждому субтесту и 5 шкальных значений (всего 12 показателей).

Валидность

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

Проверка эмпирической валидности, связанной, главным образом, с корреляционными соотношениями между проверяемым тестом и результатами исследований с помощью других методик, позволяющих оценивать исследуемые качества, показала следующие результаты. Параллельные исследования по СТ и 16-факторному опроснику Кеттелла продемонстрировали корреляцию на уровне r= + 0,43 (p<0,01) показателя шкалы общей тревожности и фактора “О” (уверенность в себе – тревожность), причем близкие к такого же уровня значимости корреляции с этим же фактором показали и все вспомогательные шкалы ИТТ (ЭД, АСТ, ФОБ, ОП и СЗ). Кроме того, выявилась отрицательная корреляция шкалы АСТ с фактором QЗ (низкий самоконтроль – высокий самоконтроль или низкая интеграция чувства “Я” – высокая интеграция) r= – 0,406 (р<0,01). Остальные шкалы также имели достаточно отчетливую отрицательную связь с показателем фактора Q3, но не достигшую уровня статистической достоверности. Подобные же на уровне выраженной тенденции отрицательные корреляции продемонстрировали все вспомогательные шкалы и с фактором “С” (эмоциональная неустойчивость – эмоциональная устойчивость или низкая сила “эго” – высокая сила “эго”). Определенный интерес с точки зрения эмпирической валидности представляет и связь шкалы ОП с фактором Q4 (раccлабленность – напряженность) (r= + 0,36; р<0,05), что свидетельствует о наличии общих корней тревожной оценки перспективы в ее содержательном значении по методике СТ и мотивационной неудовлетворенностью, репрезентируемой фактором Q4 теста Кеттелла.

В корреляционной матрице методик СТ и 16 РF обнаружилась еще одна корреляционная зависимость, подтверждающая эмпирическую валидность выделенных шкал – это положительная связь шкалы ЭД с фактором “L” (доверчивость – подозрительность), отражающим, главным образом, настороженно-эмоциональное отношение к людям (г = + 0.387; р<0,01).

Апробация методики

В процессе разработки методика использовалась при изучении особенностей психологической адаптации участников отечественных антарктических экспедиций на ряде полярных станций, а также в период их транспортировки на Шестой континент и обратно. При этом проводились параллельные ежемесячные (иногда через два месяца) исследования эмоционального состояния с помощью блока психологических методик, в число которых входили СТ и широко известная личностная шкала проявлений тревоги J. Тауlоr. Этот материал послужил дополнительным основанием для суждения о концептуальной валидности рассматриваемого метода.

Прежде всего, наблюдалось общее, практически синхронное, совпадение профиля кривых динамики оценки тревожности по обеим методикам, отражающим один и тот же процесс эмоционального приспособления к экстремальным условиям как на уровне включения в специфическую природную среду, так и необычные социально-психологические условия, свойственные подобным экспедициям. С другой стороны, результат частного анализа изменения основной и вспомогательных шкал методики СТ и их пики полностью соответствуют ситуации, характеризовавшейся психологическим напряжением и спецификой различных этапов зимовки, ранее отписанных в литературе и наблюдаемых врачами экспедиций (первый месяц работы, вершина полярной ночи, период выхода судов за отзимовавшей партией и т.д.). При этом эмоциональная реактивность определялась как особенностями личностно-средового взаимодействия, так и фоном интерперсонального взаимодействия. Для подтверждения общей чувствительности методики к специфическим личностным особенностям, предрасполагающим или включающим в себя тревожность как один из основных компонентов клинико-психологического статуса, было проведено сравнительное исследование практически здоровых лиц и группы больных с различными формами неврозов и неврозоподобных расстройств с клинически подтвержденными диагнозами и наличием в структуре расстройств тревожного компонента. Исследования показали, что общий уровень самооценки изучаемых свойств среди группы больных статистически значимо отличается от контрольной – средний показатель ситуативной тревожности у них составил 20,0, а личностной 26,8 балла (в обоих случаях достоверность различий с р<0,001), что может свидетельствовать и о способности методики улавливать более общие характеристики адаптивности человека как многокомпонентного (системного) образования, биопсихосоциального по своей сущности.

В связи с задачами практической апробации методика ИТТ была включена в программу скринингового исследования педагогов общеобразовательных школ Челябинска в целях первичной психопрофилактики. Обследовано 7300 педагогов с помощью формализованных анкет, опросников и различных медико-психологических тестов. У 89% отмечались нарушения здоровья уровня “группы риска”, т.е. выявлялись признаки психической дезадаптации, у 43% выявлены нарушения уровня повышенного риска или начальных проявлений болезни. Среди них с признаками неврозов – 60%, патологии сердечно-сосудистой системы – 34 7%, сосудов головного мозга – 38,2%, пищеварительного тракта – 28,6% и др. У большинства из обследованных педагогов группы повышенного риска отмечались неврозоподобные расстройства в виде тревоги, астении, снижения настроения и работоспособности.

Исследование особенностей и уровня тревожности с помощью методики Ч. Спилбергера проведено у 349 педагогов, выявлены в среднем достоверно высокие уровни ситуативной и личностной тревожности (соответственно 49,3±5,4 балла и 47,0±5,9 баллов) при высоком уровне их взаимной корреляции. Для уточнения структуры тревожности была выделена репрезентативная группа из 86 человек с высокими показателями уровня тревожности. Эта группа была обследована с помощью теста ИТТ.

В целом у исследованной группы преобладала личностная тревожность, в особенности тревожная оценка перспектив. Это прослеживается и в оценке ситуативной тревоги. Характерно, что факторная структура личностной тревожности определяется также эмоциональным дискомфортом и астеническими нарушениями. Полученные данные на высоком статистическом уровне коррелируют с результатами тестирования по методике 16-РF Кеттелла и шкалой актуальной ригидности Томского опросника психической ригидности .

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

Интерпретация

Общие принципы

Оценки выраженности симптомов переводятся в числовые значения следующим образом: 0 – отсутствие данного признака, два других связываются с наличием слабо и умеренно выраженных признаков (баллы 1 и 2) и последний – как чрезвычайная, с точки зрения испытуемого, степень выраженности – 3 балла. Таким образом, по каждому субтесту испытуемый может набрать не более 45 баллов.

Для подсчёта сырых значений дополнительных шкал необходимо в соответствии с таблицей сложить баллы, соответствующие ответам на входящие в кажду шкалу утверждения:

Нормативные показатели

Средний фактический балл, полученный для нормативной группы из 540 практически здоровых лиц в возрасте от 22 до 55 лет равен 11,91 (стандартное отклонение – 4,58). Статистически достоверных различий для СТ-Л и СТ-С, а также отдельно для мужчин и женщин получено не было, хотя тенденцию более высокой тревожности женщин все же следует отметить, что, как известно, отмечается и в литературе.

Нормативные материалы для подростков (12-15 лет – 520 человек) дали средний балл 12,88 (сигма = 5,5), однако здесь, в отличие от взрослого контингента разница средних для юношей и девушек оказалась статистически достоверной с надежностью р<0,001 (соответственно, юноши – 11,64 и девушки – 14,13 балла).

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

Клиническая значимость

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

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

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

Следует также помнить, что тест не имеет мотивацонной защиты и его результаты могут быть леко искажены.

Аннотация: Лекция является второй из трех рассматривающих уровни процесса верификации. Тема данной лекции - процесс интеграционного тестирования, его задачи и цели. Рассматриваются организационные аспекты интеграционного тестирования - структурная и временная классификации методов интеграционного тестирования, планирование интеграционного тестирования. Цель данной лекции: дать представление о процессе интеграционного тестирования, его технической и организационной составляющих

20.1. Задачи и цели интеграционного тестирования

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

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

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

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

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

20.2. Организация интеграционного тестирования

20.2.1. Структурная классификация методов интеграционного тестирования

Как правило, интеграционное тестирование проводится уже по завершении модульного тестирования для всех интегрируемых модулей. Однако это далеко не всегда так. Существует несколько методов проведения интеграционного тестирования:

• восходящее тестирование ;
• монолитное тестирование ;
• нисходящее тестирование .

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

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

Рис. 20.1.

Однако, у восходящего метода тестирования есть существенный недостаток - необходимость в разработке драйвера и заглушек для модульного тестирования перед проведением интеграционного тестирования и необходимость в разработке драйвера и заглушек при интеграционном тестировании части модулей системы (Рис 20.1)

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

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

Монолитное тестирование имеет ряд серьезных недостатков.

• Очень трудно выявить источник ошибки (идентифицировать ошибочный фрагмент кода). В большинстве модулей следует предполагать наличие ошибки. Проблема сводится к определению того, какая из ошибок во всех вовлечённых модулях привела к полученному результату. При этом возможно наложение эффектов ошибок. Кроме того, ошибка в одном модуле может блокировать тестирование другого.
• Трудно организовать исправление ошибок. В результате тестирования тестировщиком фиксируется найденная проблема. Дефект в системе, вызвавший эту проблему, будет устранять разработчик. Поскольку, как правило, тестируемые модули написаны разными людьми, возникает проблема - кто из них является ответственным за поиск устранение дефекта? При такой "коллективной безответственности" скорость устранения дефектов может резко упасть.
• Процесс тестирования плохо автоматизируется. Преимущество (нет дополнительного программного обеспечения, сопровождающего процесс тестирования) оборачивается недостатком. Каждое внесённое изменение требует повторения всех тестов.

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

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

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

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

Интеграционное тестирование применяется на этапе сборки модульно оттестированных модулей в единый комплекс. Известны два метода сборки модулей:
Монолитный , характеризующийся одновременным объединением всех модулей в тестируемый комплекс
Инкрементальный , характеризующийся пошаговым (помодульным) наращиванием комплекса программ с пошаговым тестированием собираемого комплекса. В инкрементальном методе выделяют две стратегии добавления модулей:
o "Сверху вниз" и соответствующее ему восходящее тестирование.
o "Снизу вверх" и соответственно нисходящее тестирование.

Особенности монолитного тестирования заключаются в следующем: для замены неразработанных к моменту тестирования модулей, кроме самого верхнего, необходимо дополнительно разрабатывать драйверы (test driver) и/или заглушки (stub), замещающие отсутствующие на момент сеанса тестирования модули нижних уровней.

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

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

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

Недостатки восходящего тестирования :
Запаздывание проверки концептуальных особенностей тестируемого комплекса
Необходимость в разработке и использовании драйверов

Особенности интеграционного тестирования для процедурного программирования

Процесс построения набора тестов при структурном тестировании определяется принципом, на котором основывается конструирование Графа Модели Программы (ГМП). От этого зависит множество тестовых путей и генерация тестов, соответствующих тестовым путям.

Первым подходом к разработке программного обеспечения является процедурное (модульное) программирование. Традиционное процедурное программирование предполагает написание исходного кода в императивном (повелительном) стиле, предписывающем определенную последовательность выполнения команд, а также описание программного проекта с помощью функциональной декомпозиции. Такие языки, как Pascal и C, являются императивными. В них порядок исходных строк кода определяет порядок передачи управления, включая последовательное исполнение, выбор условий и повторное исполнение участков программы. Каждый модуль имеет несколько точек входа (при строгом написании кода - одну) и несколько точек выхода (при строгом написании кода - одну). Сложные программные проекты имеют модульно-иерархическое построение, и тестирование модулей является начальным шагом процесса тестирования ПО. Построение графовой модели модуля является тривиальной задачей, а тестирование практически всегда проводится по критерию покрытия ветвей C1, т.е. каждая дуга и каждая вершина графа модуля должны содержаться, по крайней мере, в одном из путей тестирования.

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

Интеграционное тестирование как часть большой работы

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

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

Методы сборки модулей

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

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

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

Инкрементальный метод включает в себя два способа добавления модулей:

• сверху-вниз или восходящий,
• снизу-вверх - нисходящий.

Особенности монолитного и инкрементального тестирования

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

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

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

Преимущества проведения интеграционного тестирования

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

Интеграционное тестирование программного обеспечения имеет ряд преимуществ:

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

Исправление дефектов

Интеграционное тестирование завершено, однако это еще не все. Найденные ошибки фиксируются и отправляются разработчику для исправления, после чего процесс начинается заново.

Во-первых, необходимо проверить, были ли устранены выявленные дефекты. Во-вторых, во время изменения исходного кода могли возникнуть новые ошибки в работе программы и взаимодействии со сторонним ПО.

Хотя в настоящее время и существует большое количество методов контроля качества, по-прежнему немаловажную роль играет интеграционное тестирование. Пример такого вида проверки может наглядно продемонстрировать «узкие» места при разработке программного обеспечения и документации.

Автоматизация тестирования

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

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

Однако автоматизация тестирования не может полностью заменить труд инженера по качеству, а лишь дополнить его.

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