8. Тестирование по

Процесс разработки ПО предполагает три стадии тестирования:

• автономное,

• комплексное,

• системное.

Различают два подхода к формированию тестов: структурный и функциональный.

8.1. Виды контроля качества разрабатываемого по.

Чем раньше обнаруживаются ошибки, тем больше вероятность их правильного исправления и ниже его стоимость. Современные технологии разработки ПО предусматривают раннее обнаружение ошибок за счет выполнения контроля результатов всех этапов и стадий разработки. На начальных этапах контроль осуществляют в основном вручную или с использованием CASE-средств, на последнем этапе – он принимает форму тестирования.

Тестирование – это процесс выполнения программы с целью выявления ошибок. Никакое тестирование не может доказать отсутствие ошибок в ПО.

Для ПО выполнение полного тестирования, т. е. задание всех возможных комбинаций исходных данных, невозможно.

1). Автономное тестирование – это тестирование компонентов ПО.

2). Комплексное тестирование.

3). Системное (оценочное) тестирование – тестирование на соответствие основным критериям качества.

Основные принципы:

1). Избегать тестирования программы самим автором,

2). Предполагаемые результаты должны быть известны до тестирования,

3). Необходимо изучать результаты каждого теста,

4). Необходимо проверять действие программы на неверных данных.

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

8.2. Формирование тестовых наборов

Удачным считают тест, который обнаруживает хотя бы одну ошибку.

Существует два принципиально различных подхода к формированию тестов:

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

2). Функциональный – структура ПО неизвестна. Тесты строят по функциональным спецификациям (черный ящик; подход, управляемый данными).

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

Различают статический и динамический подходы к ручному контролю. При статическом подходе анализируют структуру, упрощающую информационные связи программы ,ее входные и выходные данные. При динамическом вручную моделируют процесс выполнения программы на заданных исходных данных. Исходными данными для таких проверок являются ТЗ, спецификация, структурная и функциональная схема ПО, схема отдельных компонентов и т.д.. Для более поздних этапов – это алгоритмы, тесты программы и тестовые наборы.

Основные методы ручного контроля:

1). Инспекции исходного текста,

2). Сквозные просмотры,

3). Проверка за столом,

4). Оценка программ.

8.3. Структурное тестирование

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

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

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

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

• не обнаруживают пропущенных маршрутов;

• не обнаруживают ошибок, зависящих от обрабатываемых данных, например, в операторе if (a - b) < eps - пропуск функции абсолютного значения abs проявится только, если а < b;

• не дают гарантии, что программа правильна, например, если вместо сортировки по убыванию реализована сортировка по возрастанию.

Формирование тестовых наборов для тестирования маршрутов может осуществляться по нескольким критериям:

• покрытие операторов,

• покрытие решений (переходов),

• покрытие условий.

• покрытие решений/условий,

• комбинаторное покрытие условий.

Покрытие операторов

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

Покрытие решений (переходов)

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

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

Покрытие условий

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

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

Основной недостаток метода - недостаточная чувствительность к ошибкам в логических выражениях.

Покрытие решений/условий

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

Комбинаторное покрытие условий

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

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

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

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

• передавать управление каждому оператору, по крайней мере, один раз.