Интеграционное тестирование

Тестирование ПО

Определения

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

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

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

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

Контроль (verification) – попытка найти ошибки, выполняя программу в тестовой, или моделируемой среде.

Испытание (validation) – попытка найти ошибки, выполняя программу в заданной реальной среде.

Аттестация (certification) – авторитетное подтверждение правильности программы. При тестировании с целью аттестации выполняется сравнение с некоторым заранее определенным стандартом.

Отладка (debugging) не является разновидностью тестирования. Хотя слова “отладка” и “тестирование” часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование – деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки, а затем – на исправление этой ошибки. Эти два вида деятельности связаны – результаты тестирования являются исходными данными для отладки.

Тестирование модуля, или автономное тестирование (module testing, unit testing) – контроль отдельного программного модуля, обычно в изолированной среде (т. е. изолированно от всех остальных модулей). Тестирование модуля иногда включает также математическое доказательство.

Тестирование сопряжении (integration testing) – контроль сопряжении между частями системы (модулями, компонентами, подсистемами).

Тестирование внешних функций (external function testing) – контроль внешнего поведения системы, определенного внешними спецификациями.

Комплексное тестирование (system testing) – контроль и/или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной.

Тестирование приемлемости (acceptance testing) – проверка соответствия программы требованиям пользователя.

Тестирование настройки (installation testing) – проверка соответствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки системы.

Модульное тестирование

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

Интеграционное тестирование

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

Системное тестирование

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

Нагрузочное тестирование

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

Формальные инспекции

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

Бета-тестирование

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

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

Регрессионное тестирование (regression testing)

Если после окончания проекта, во время активного использования, обнаружили пару багов, исправили, заодно и пару функций добавили, а потом через некоторое время обнаружили, что код, с которым раньше не было проблем, нормально не работает?

По достоверным данным количество ошибок после изменения исходного кода (будь-то добавление новой функциональности или же исправление багов) составляет около 50%. Для того, чтобы выявить эти ошибки, и нужно регрессионное тестирование (regression test).

Основные виды тестов регрессии в порядке их важности (обычно в таком порядке их и выполняют).

1. Тесты верификации версии (Build Verification Test). Нужны эти тесты для проверки основной функциональности каждой версии программы. Только будучи уверенным в том, что основная функциональность программы не нарушена, можно спать спокойно. При нахождении ошибки с помощью таких тестов необходимо пересмотреть соответствующую часть кода на предмет ошибок.

2. Тесты верификации багов (Bug Verification Test). Если некоторый тест выявил баг, необходимо после исправления провести этот тест еще раз. Хотя проведение этих тестов и является логичным, многие программисты пренебрегают такого вида тестированием.

3. Тесты регрессии (Regression Test Pass). К этим тестам относятся те, которые уже проводились с предыдущими версиями софта и не выявляли ошибок. пногда при отсутствии времени некоторые из тестов можно пропустить (желательно только тогда, когда не были внесены изменения в соответствующие участки кода). Если ранее такие тесты уже проводились более 3 раз, процесс неплохо было бы автоматизировать.

4. Тесты регрессии на исправленных багах (тесты на закрытых багах). Что такое закрытые баги можно понять из примера. Пусть некоторый тест нашел ошибку. После исправления этот же тест ошибки не обнаружил. В этом случае баг и называется “закрытым”. Баг может проявится снова по ряду причин (особенно при модификации кода). Поэтому время от времени нужно возвращаться к этому месту программы.

В крупных фирмах при проведении регрессионного тестирования часто создают таблицы вида “номер теста – версия программы 1 – номер бага – версия 2 – … – версия N – номер бага”.