Как уже упоминалось в § 2.3 при тестировании модулей программного обеспечения, так же, как при проектировании и кодировании возможно применение как восходящего, так и нисходящего подходов.
Восходящее тестирование. Восходящий подход предполагает,что каждый модуль тестируютотдельно на соответствие имеющимся спецификациям на него, затем собирают оттестированные модули в модули более высокой степени интеграции и тестируют их. При этом проверяют межмодульные интерфейсы, используемые для подключения модулей более низкого уровня ие-рархии. И так далее, пока не будет собран весь программный продукт (рис. 9.3).
Такой подход обеспечивает полностью автономное тестирование, для которого просто генерировать тестовые последовательности, которые передаются в модуль напрямую. Однако он имеет и существенные недостатки. Во-первых, при восходящем тестировании так же, как при восходящем проектировании, серьезные ошибки в спецификациях, алгоритмах и интерфейсе могут быть обнаружены только на завершающей стадии работы над проектом. Во-вторых, для того, чтобы тестировать модули нижних уровней, необходимо разработать специальные тестирующие программы, которые обеспечивают вызов интересующих нас модулей с необходимыми параметрами. Причем эти тестирующие программы также могут содержать ошибки.
|
|
Нисходящее тестирование. Нисходящее тестирование органически связано с нисходящимпроектированием и разработкой; как только проектирование какого-либо модуля заканчивается, его кодируют и передают на тестирование.
В этом случае автономно тестируется только основной модуль. При его тестировании все вызываемые им модули заменяют модулями, которые в той или иной степени имитируют поведение вызываемых модулей (рис. 9.4). Такие модули принято называть «заглушками». В отличие от тестирующих программ заглушки очень просты, например, они могут просто фиксировать, что им передано управление. Часто заглушки просто возвращают какие-либо фиксированные данные.
Как только тестирование основного модуля завершено, к нему подключают модули, непосредственно им вызываемые, и необходимые заглушки, а затем проводят их совместное тестирование. Далее последовательно подключают следующие модули, пока не будет собрана вся система. Желательная последовательность сборки обсуждалась в § 2.3, хотя на практике ее редко удается соблюдать.
Основной недостаток нисходящего тестирования - отсутствие автономного тестирования модулей. Поскольку модуль получает данные не непосредственно, а через вызывающий модуль, то гораздо сложнее обеспечить его «достаточное» тестирование.
|
|
Основным достоинством данного метода является ранняя проверка основных решений и качественное многократное тестирование сопряжения модулей в контексте программного обеспечения. При нисходящем тестировании есть возможность согласования с заказчиком внешнего вида (интерфейса) программного обеспечения.
Комбинированный подход. Чаще всего применяют комбинированный подход:модуливерхних уровней тестируют нисходящим способом, а модули нижних уровней - восходящим. Этот способ позволяет с одной стороны начать с тестирования интерфейса, с другой - обеспечивает качественное автономное тестирование модулей низших уровней.
Тестирование программного обеспечения специалистами. Согласно основнымпринципам нежелательно тестирование программного обеспечения его автором, поэтому эту работу, как правило, выполняют другие программисты, желательно - специалисты в этой области.
Задачей специалиста по тестированию является обнаружение максимального количества несоответствий тестируемого модуля и спецификаций на него. Для выполнения этой задачи специалист по тестированию формирует тесты, используя как структурный, так и функциональный подходы, обеспечивая всестороннее тестирование.
Каждое отклонение от спецификации обязательно документируют, заполняя специальный протокол (рис. 9.5). Наиболее интересными полями протокола являются тип проблемы и ее описание.
В поле тип проблемы указывают один из вариантов:
1 - ошибка кодирования - программа ведет себя не так, как следует из общепринятых представлений, например, 2 + 2 = 5 - на что разработчик может выдать резолюцию «соответствует проекту»;
2 - ошибка проектирования — программа ведет себя в соответствии с проектом, но специалист по тестированию не согласен с данным решением в проекте - на что разработчик может отреагировать, наложив резолюцию «не согласен с предложением»;.
3 - предложение - предложение по улучшению проекта;
4 - расхождение с документацией - обнаружено, что программа ведет себя не так, как указано в документации;
5 - взаимодействие с аппаратурой - обнаружены проблемы при использовании определенного вида аппаратуры;
6 - вопрос - программа делает что-то не совсем понятное.
Описание проблемы должно быть коротким и понятным, например: «Система не запоминает настройки принтера, выполняемые в окне настройки».
Если программист исправляет ошибку, то тестирование повторяют сначала, так как при исправлении ошибки программист может внести в программу новые ошибки. Такое тестирование называют «регрессионным».
Комплексное тестирование. Особенностью комплексного тестирования является то,чтоструктурное тестирование для него практически не применимо. В основном на данной стадии используют тесты, построенные по методам эквивалентных классов, граничных условий и предположении об ошибках.
Критерии завершения тестирования и отладки. Одним из самых сложных являетсявопрос о том, когда следует завершать тестирование, поскольку невозможно гарантировать, что
в разрабатываемом программном обеспечении не осталось ошибок.
Предложено очень много критериев. Все критерии можно разделить на три группы:
• основанные на методологиях проектирования тестов – определенное количество тестов, полученных по методам анализа причинно-следственных связей, анализа граничных значений и предположения об ошибке, перестают выявлять ошибки;
• основанные на оценке возможного количества ошибок - возможное количество ошибок оценивают экспертно, или по специальным методикам [21], а затем завершают тестирование при нахождении примерно 93-95% ошибок;
• основанные на исследовании результатов тестирования - строят график зависимости количества обнаруженных ошибок от времени тестирования, если он напоминает график, представленный на рис. 9.6, то тестирование можно завершать.
|
|
Часто тестирование завершают потому, что закончилось время, отведенное на выполнение данного этапа. В этом случае тестирование сворачивают, обходясь минимальным вариантом. Минимальное тестирование [31] предполагает:
тестирование граничных значений;
• тщательную проверку руководства;
• тестирование минимальных конфигураций технических средств;
• тестирование возможности редактирования команд и повторения их в любой последовательности;
• тестирование устойчивости к ошибкам пользователя.
Часть ошибок при этом остаются неисправленными «отложенными» до выпуска следующей версии.