5.1.5. Тестирование модулей и комплексное тестирование.

Как уже упоминалось в § 2.3 при тестировании модулей программного обеспечения, так же, как при проектировании и кодировании возможно при­менение как восходящего, так и нисходящего подходов.

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

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

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

В этом случае автономно тестируется только основной модуль. При его тестировании все вызываемые им модули заменяют модулями, которые в той или иной степени имитируют поведение вызываемых модулей (рис. 9.4). Такие модули принято называть «заглушками». В отличие от тестирующих программ заглушки очень просты, например, они могут просто фиксировать, что им передано управление. Часто заглушки просто возвращают какие-либо фиксированные данные.

Как только тестирование основного модуля завершено, к нему подключают модули, непосредственно им вызываемые, и необходимые заглушки, затем проводят их совместное тестирование. Далее последовательно подключают следующие модули, пока не будет собрана вся система. Желательная последовательность сборки обсуждалась в § 2.3, хотя на практике ее редко удается соблюдать.

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

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

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

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

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

Каждое отклонение от спецификации обязательно документируют, за­полняя специальный протокол (рис. 9.5). Наиболее интересными полями протокола являются тип проблемы и ее описание.

Описание проблемы должно быть коротким и понятным, например:

«Система не запоминает настройки принтера, выполняемые в окне настрой­ки».

Если программист исправляет ошибку, то тестирование повторяют сна­чала, так как при исправлении ошибки программист может внести в про­грамму новые ошибки. Такое тестирование называют «регрессионным».

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

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

Предложено очень много критериев. Все критерии⁵можно разделить на три группы:

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

• основанные на оценке возможного количества ошибок - возможное ко­личество ошибок оценивают экспертно, или по специальным методикам [21], а затем завершают тестирование при нахождении примерно 93-95% ошибок;

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

Часто тестирование завершают потому, что закончилось время, отведен­ное на выполнение данного этапа. В этом случае тестирование сворачивают, обходясь минимальным вариантом. Минимальное тестирование [31] предпо­лагает:

• тестирование граничных значе­ний;

• тщательную проверку руководства;

• тестирование минимальных кон­фигураций технических средств;

• тестирование возможности ре­дактирования команд и повторения их в любой последовательности;

• тестирование устойчивости к ошибкам пользователя.

Часть ошибок при этом остаются неисправленными «отложенными» до выпуска следующей версии.