Задача для иллюстрации подходов к тестированию программ по требованиямНаименование: Определение номера максимального параметра. Формат обращения: Max(A, B, C), Например, вызов функции Max(25,44,13) должен вернуть значение 2. Спецификация: (в формате С) int Max(int A,B,C) Требования (1 версия): [SRD 0001] Процедура должна вычислять порядковый номер параметра с максимальным значением. Параметры процедуры нумеруются слева направо. Реализация (1 версия):
Рисунок 1. Первый вариант реализации тела процедуры Тест-план: Очевидно, что для тестирования данной программы необходимо создать группу тестов, относящихся, по меньшей мере, к трем классам эквивалентности. Каждому из них будут соответствовать тесты, дающие на выходе одно из возможных значений номера параметра: 1, 2, и 3 соответственно. Простейший анализ приводит примерно к следующему составу тест-плана:
Тем самым мы проверили, что процедура корректно возвращает все возможные значения результата. Однако любой тестировшик скажет, что в тест-плане отсутствует важная входная комбинация параметров с одинаковыми значениями. Соответственно добавим четвертый тест.
Однако при построении этого варианта тест-плана мы сталкиваемся с проблемой задания значения ожидаемого выхода. Действительно, реализация на Рис.1 возвратит значение 3. Но является ли оно правильным. Наше единственное требование [SRD 0001] ничего не говорит о параметрах с одинаковыми значениями. Видимо в жизненном цикле нашей программной разработки придется вернуться к этапу определения требований и добавить в него, по крайней мере, еще одно. После чего выполнить новую реализацию.
Требования (2 версия): [SRD 0001] Процедура должна вычислять порядковый номер параметра с максимальным значением. Параметры процедуры нумеруются слева направо. [SRD 0002] При одинаковых значениях параметров процедура должна выдавать порядковый номер с наименьшим значением.
Ой, как плохо получилось. При вызове Max(3,4,4) можно подумать, что речь идет о первом параметре. Давайте лучше напишем так:
[SRD 0002] При одинаковых значениях параметров процедура должна выдавать порядковый номер параметра, расположенного левее других.
Опять возможно двоякое понимание, но оставим, как получилось. Реализация (2 версия):
Рисунок 2. Второй вариант реализации тела процедуры Тест-план: Очевидно, что теперь можно определить значение ожидаемого выхода четвертого теста. Он должен быть отнесен теперь ко второму требованию. Кроме того для тестирования данной программы необходимо создать еще одну группу тестов с одинаковыми значениями параметров.
Все получилось просто чудесно. Для поверки двух простых требований мы написали всего 7 тестов. При этом, шутки ради, любопытно взглянуть на тест с входными значениями Max(3,3,4). На основании требования [SRD 0002] он должен соответствовать выходному значению 1, а требование [SRD 0001], с очевидностью, относит этот случай тому же классу эквивалентности, что и тест 3. То есть третий параметр имеет максимальное значение. На этом примере видно, что при написании требований они часто получаются зависимыми друг от друга, а тесты редко покрывают какое-нибудь одно требование, чаще – несколько. Если считать, что мы покрыли все требования к программе, то полезно провести анализ того, насколько полно мы проверили ее данную реализацию. Переходя к анализу полноты покрытия реализации необходимо убедиться, что мы хотя бы раз выполнили каждый из функциональных блоков. Это действительно было обеспечено, причем, уже первыми тремя тестами нашего плана. Более детальный уровень покрытия реализации требует прохождения тестов по каждой ветви нашего графа управления. Проверив выполнение всех наших семи тестов, можно убедиться, что одна ветвь осталась не выполнена. Это случай, когда первый параметр предпочтительней второго, но третий предпочтительней первого. Такой случай возникает при обращении к программе Max(2,1,3) или в том самом случае Max(3,3,4), который мы рассматривали как спорный.
Включение такого теста не добавляет нам полноты покрытия требований. С точки зрения классов эквивалентности, это модифицированный вариант первого теста. Часто говорят, что тест типа восьмого добавляется к тест-плану специально для покрытия кода. Другими словами, эта часть тест-плана обусловлена конкретной реализацией.
Рисунок 3 Последовательная реализация проверок Пример реализации, приведенной на Рис. 3 показывает, что для полного покрытия подобного программного кода достаточно всего двух тестов: Max(1,2,3) и Max(3,2,1), но их очевидно недостаточно для проверки требований. Поэтому пест план будет содержать все те же семь тестов. Если же и добавлять восьмой тест, то он скорее должен быть дополнительным подтверждением того, что требование [SRD 0001] является доминирующим, определяя тем самым основное назначение разрабатываемой процедуры. Из этих соображений такой тест можно добавить и для первой реализации программы.
Литература: 1. Синицын С.В., Налютин Н.Ю. Верификация программного обеспечения: Учебное пособие. М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2008.-368с.
|
