Модульное тестирование. Достоинства и недостатки шаблонов

Лекция 64

Достоинства и недостатки шаблонов

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

Стандартная библиотека С++ предоставляет большой набор шаблонов для различных способов организации хранения и обработки данных.

На этом данный курс лекций завершается. В него не вошли многие темы, рассмотренные в учебнике [18] и практикуме [19]: шаблоны функций, основы структурной и объектно-ориентированной технологии разработки программ, организация динамических структур данных, обработка исключительных ситуаций, преобразование типов, введение в паттерны проектирования, описание стандартной библиотеки (потоковые классы, строки, контейнеры, итераторы, функциональные объекты, алгоритмы и другие средства). Это связано с формулировкой договора, заключенного автором с издательством ПИТЕР при публикации книги.

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

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

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

Однако он имеет и существенные недостатки.

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

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

Рис. 1 Тестирование программного обеспечения при восходящем подходе:

а - автономное тестирование модулей нижнего уровня;

б - тестирование следующего уровня.

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

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

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

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

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

Рис. 2 Начальные этапы тестирования:

а - основного модуля; б - двух модулей

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

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

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

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

Рис. 3. Бланк отчета об обнаруженном несоответствии

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

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

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

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

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

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

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

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

Минимальное тестирование предпо­лагает:

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

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

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

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

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

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