3.2. Проектирование тестов

Используйте в качестве тестов систематически подобранные, а не случайные входные данные! Исходными данными для разработки тестов служат спецификация и логика программы [4, 16 – 18]. Спецификация описывает входные данные, выходные данные и функции (“поведение”) программы – что она делает. Логика программы описывает, как программа выполняет свои функции, ее внутреннее устройство (алгоритм), и определяется схемой или текстом программы.

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

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

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

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

Одним из методов черного ящика является метод эквивалентного разбиения, идея которого заключается в следующем. Совокупность значений входных данных (например, соответствующих определенному тесту) можно рассматривать как вектор или “точку” некоторого многомерного пространства входных данных, а соответствующий результат исполнения программы – как “точку” пространства выходных данных программы. Аналогичным образом можно говорить о пространстве тестов.

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

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

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

При наличии сложных связей между входными и выходными данными хорошим систематическим методом построения тестов является метод функциональных диаграмм [17, 18].

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

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

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

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

Первой входной величиной является количество вершин графа n (см. раздел 2.2.2 и разделы 2.3 и 4.2.1 приложения), которое должно находиться в диапазоне от 1 до NMAX. Для этой величины имеются три области эквивалентности (в скобках указаны их номера) - одна «правильная»: 1nNMAX (1) и две «неправильных»: n<1 (2) и n>NMAX (3).

Аналогично выявляются тестовые ситуации с номерами до 16. Каждое сообщение программы должно появляться хотя бы один раз при ее отладке и поэтому образует самостоятельную тестовую ситуацию (от 17 до 26), причем сообщениям об ошибках соответствуют «неправильные» ситуации (от 20 до 26). Ситуации с номерами от 27 до 38 возникают при различных способах записи команды запуска отлаживаемой программы и разных состояниях входного и выходного файлов.

Затем был разработан по возможности минимальный набор тестов (табл. 4.2 приложения), обеспечивающий создание каждой из полученных тестовых ситуаций. Сначала использовались тесты, разработанные еще при постановке задачи (см. раздел 2.1 приложения), охватывающие несколько тестовых ситуаций, которые указаны в правом столбце табл. 4.2 приложения. Затем выявлялись не охваченные ими ситуации и подбирались тесты для этих ситуаций до тех пор, пока не были охвачены все ситуации.

После этого методами белого ящика была проверена полнота разработанного набора тестов.

2. Методы белого ящика.