11.4. ПОДХОДЫ К ПРОЕКТИРОВАНИЮ ТЕСТОВ

11.4. ПОДХОДЫ К ПРОЕКТИРОВАНИЮ ТЕСТОВ

Рассмотрим два самых противоположных подхода к проектированию тестов.

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

Рис. 11.2. Взаимосвязь процессов проектирования и тестирования

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

Сторонник второго подхода использует стратегию "белого ящика", или стратегию тестирования, управляемую логикой программы, которая позволяет исследовать внутреннюю структуру программы. В этом случае тестировщик получает тестовые данные путем анализа только логики программы; стремится, чтобы каждая команда была выполнена хотя бы один раз. При достаточной квалификации добивается, чтобы каждая команда условного перехода выполнялась бы в каждом направлении хотя бы один раз. Цикл должен выполняться один раз, ни разу, максимальное число раз. Цель тестирования всех путей извне также недостижима. В программе из двух последовательных циклов внутри каждого из них включено ветвление на десять путей, имеется 1018 путей расчета. Причем выполнение всех путей расчета не гарантирует выполнения всех спецификаций. Для справки: возраст Вселенной 1017с.

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

Последнее утверждение имеет два слабых пункта: во-первых, число не повторяющих друг друга маршрутов — астрономическое; во-вторых, даже если каждый маршрут может быть проверен, сама программа может содержать ошибки (например, некоторые маршруты пропущены).

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

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

Рассмотрим пример тестирования оператора

if A and В then…

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

При критерии покрытия условий требовались бы два теста: А = true, В = false и А = false, В = true. Но в этом случае не выполняется then-предложение оператора if.

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

Недостатком критерия покрытия решений/условий является невозможность его применения для выполнения всех результатов всех условий. Часто подобное выполнение имеет место вследствие того, что определенные условия скрыты другими условиями. Например, если условие AND есть ложь, то никакое из последующих условий в выражении не будет выполнено. Аналогично, если условие OR есть истина, то никакое из последующих условий не будет выполнено. Следовательно, критерии покрытия условий и покрытия решений/условий недостаточно чувствительны к ошибкам в логических выражениях.

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

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

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

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

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

Деление алгоритма на типовые стандартные структуры, согласно проектной процедуре кодирования текста модуля (метода) из пятой главы учебника, позволяет минимизировать усилия программиста, затрачиваемые им на тестирование. Запрет на вложенные структуры как раз и объясняется излишними затратами на тестирование. Использование цепочки простых альтернатив с одним действием или структуры ВЫБОР вместо вложенных простых АЛЬТЕРНАТИВ значительно сокращает число тестов!

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг

Набор тестов

Из книги Разгони свой сайт автора Мациевский Николай

Набор тестов Итак, для проверки гипотезы и установления истинных коэффициентов нам потребуется 2 набора тестов:Тесты на сжатие: для набора пар значений «size — gzip»Тесты на запись: для набора пар значений «size — FS»Почему именно 2 — а как же издержки на инициализацию


Защита СМБ: подходы и принципы

Из книги Журнал PC Magazine/RE №10/2009 автора Журнал «PC Magazine»

Защита СМБ: подходы и принципы Все больше разработчиков средств безопасности применяют так называемые «облачные» подходы, используя для контроля защищаемой системы данные, на лету предоставляемые онлайновыми системами накопления и классификации угроз. Это могут быть


Рекомендации по проектированию, отладке и тестированию программ

Из книги Технологии программирования автора Камаев В А

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


Выполнение тестов

Из книги Инфраструктуры открытых ключей автора Полянская Ольга Юрьевна

Выполнение тестов На Web-сайте книги в каталоге TimeTest находятся пакетные файлы, с помощью которых вы сможете запускать тесты как под управлением Windows 2000/NT, так и под управлением Windows 9x:• cpTIME.bat• cpTIME.bat• atouTIME.bat• grepTIME.bat• sortTIME.bat• threeST.batДля всех тестов, кроме тестов


3.3. КАСКАДНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ

Из книги Удвоение продаж в интернет-магазине автора Парабеллум Андрей Алексеевич

3.3. КАСКАДНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ Каскадные технологические подходы задают некоторую последовательность выполнения видов работ, обычно изображаемую в виде каскада. Иногда их называют подходами на основе модели водопада.Классический каскадный подход (от англ. pure


3.4. КАРКАСНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ

Из книги Как тестируют в Google автора Уиттакер Джеймс

3.4. КАРКАСНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ Каркасные подходы представляют собой каркас для видов работ и включают их огромное количество.Рациональный унифицированный подход к выполнению работ(rational unified process-RUP), изложенный подробно в десятой главе данного учебника, вобрал в


3.5. ГЕНЕТИЧЕСКИЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ

Из книги автора

3.5. ГЕНЕТИЧЕСКИЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ Термин "генетический" в названии этой группы подходов связан с происхождением программы и дисциплиной ее создания.Синтезирующее программирование предполагает синтез программы по ее спецификации. В отличие от программы,


3.8. АДАПТИВНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ

Из книги автора

3.8. АДАПТИВНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ Адаптивные технологические подходы были задуманы как подходы, поддерживающие изменения. Они только выигрывают от изменений, даже когда изменения происходят в них самих. Данные подходы ориентированы на человека, а не на процесс. Во


3.9. ПОДХОДЫ ИССЛЕДОВАТЕЛЬСКОГО ПРОГРАММИРОВАНИЯ

Из книги автора

3.9. ПОДХОДЫ ИССЛЕДОВАТЕЛЬСКОГО ПРОГРАММИРОВАНИЯ Исследовательское программирование имеет следующие особенности (http://www.osp.ru/pcworld/2001/01/062.htm):— разработчик ясно представляет направление поиска, но не знает заранее, как далеко он сможет продвинуться к цели;— нет


6.5. ПОДХОД К ПРОЕКТИРОВАНИЮ АРХИТЕКТУРЫ СИСТЕМЫ НА ОСНОВЕ АБСТРАКТНЫХ МАШИН ДЕЙКСТРЫ

Из книги автора

6.5. ПОДХОД К ПРОЕКТИРОВАНИЮ АРХИТЕКТУРЫ СИСТЕМЫ НА ОСНОВЕ АБСТРАКТНЫХ МАШИН ДЕЙКСТРЫ Самый нижний уровень абстракции — это уровень аппаратуры. Каждый уровень реализует абстрактную машину с все большими возможностями.Принцип 1. На каждом уровне абсолютно ничего не


Стандарты и руководства по проектированию безопасности

Из книги автора

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


Товары для тестов

Из книги автора

Товары для тестов Можно сделать тестовую категорию товаров «Специальные предложения» и на них тестировать


Виды тестов

Из книги автора

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


Выполнение тестов

Из книги автора

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