3. Составление тестов

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

• события без исходных данных;

• события с исходными данными.

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

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

1. Существуют ли обращения к переменным, не имеющим значения? Если Вы пользуетесь значениями по умолчанию, убедитесь, что они соответствуют требуемым; лучше присвоить все исходные значения явно.

2. Находятся ли индексы в допустимых границах? Не забудьте, что в массивах на Pascal’e и в объекте StringGrid разная очередность индексов.

1. Находятся ли значения переменных в допустимых для данного типа данных границах? Это касается и промежуточных результатов. Проверьте ради интереса, какой будет результат (на Pascal) следующей операции k:=i*j/l; если i, j, l имеют тип Integer; k тип real и i=10000, j=200 и l=20000. Почему? Что надо делать для исправления? А как на Delphi?

3. Имеются ли вычисления с нечисловыми данными? Нет ли возможности потенциальной ошибки в преобразованиях типов данных? Процедура val( ); функции StrToInt, StrToFloat. . . Согласуются ли типы числовых данных при вычислениях (тип результата деления целых не всегда целый).

4. Возможны ли недопустимые значения аргументов функций (например, логарифм отрицательного числа), деление на нуль, квадратный корень отрицательного числа?

5. Соблюдается ли требуемая очередность операций в арифметических и логических выражениях? Простое правило: если сомневаетесь – ставьте скобки, они никогда не мешают. Правильно ли в выражениях расставлены скобки?

6. Правильно ли расставлены пары Begin. . .End; некоторые программисты рекомендуют: если набрали Begin, наберите сразу же и End и вставьте нужные операторы между ними. Не забудьте, когда за End нужна ; а когда нет!

7. Существует ли потенциальная возможность зацикливания в циклах while . . do и repeat . . until, изменяется ли условие продолжения (прерывания) цикла по ходу его выполнения?

8. Соответствуют ли формальные и фактические параметры по количеству, типу и очередности?

9. Если решается задача, имеющая физическую суть, согласованы ли единицы измерения?

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

Имеется два подхода к тестированию:

• функциональное тестирование (тестирование по данным, тестирование “черного ящика”);

• структурное тестирование (тестирование по управлению, тестирование “белого ящика”).

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

При структурном тестировании тесты составляют на основе анализа структуры программы.

Наиболее распространенным методом функционального тестирования является эквивалентное разбиение: всю область значений исходных данных разбивают на конечное число классов эквивалентности так, чтобы можно было предположить, что каждый тест, являющийся представителем некоторого класса, эквивалентен любому другому тесту этого класса. Например, исходя из определения модуля y=abs(x), можем выделить два класса эквивалентности: x>=0 и x<0. Различают:

• правильные классы эквивалентности, представляющие допустимые значения исходных данных;

• неправильные классы эквивалентности, представляющие недопустимые значения исходных данных.

В примере с модулем неправильным классом эквивалентности является случай, когда вместо х используется нечисловое значение. Для y=ln(x) правильным классом эквивалентности является x>0; неправильными классами x<=0 и нечисловое значение х. Программа должна быть составлена таким образом, чтобы исходные данные из неправильных классов эквивалентности не вызывали программные прерывания во время решения, а лишь сообщение об этом, запрашивание новых исходных данных или возврат в исходное состояние. Например, в системе продажи билетов, если кассир ошибочно ввел дату 30.02, то необходимо запрашивать новую и продолжать работу. Чтобы это обеспечить, программа должна быть протестирована на всех правильных и неправильных классах эквивалентности.

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

if (a>1)AND(b=0) then x:=x/a;

if (a=2)OR(x>1) then x:=x+1;

Нужны тесты, удовлетворяющие следующим условиям:

1.	a>1 b=0	5.	a=2 x>1
2.	a>1 b<>0	6.	a=2 x<=1
3.	a<=1 b=0	7.	a<>2 x>1
4.	a<=1 b<>0	8.	a<>2 x<=1

Для того, чтобы протестировать эти комбинации, достаточно 4 теста:

• x=4 a=2 b=0 покрывает 1, 5;

• x=1 a=2 b=1 покрывает 2, 6;

• x=2 a=0 b=0 покрывает 3, 7;

• x=1 a=0 b=1 покрывает 4, 8.

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

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

• файл пуст, в массиве нет элементов;

• требуется найти максимальный элемент, но все элементы равны; требуется выделить n наибольших элементов, но n-1, n и n+1 элементы имеют одинаковые значения (после упорядочения).

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