int no_of_tests = randint(100); // создаем около 50 тестов
for (int i = 0; i<no_of_tests; ++i) {
string lab = "rand_test_";
make_test(lab+to_string(i), // to_string из раздела 23.2
randint(500), // количество элементов
0, // base
randint(50)); // spread
}
Сгенерированные тесты, основанные на случайных числах, особенно полезны
в ситуациях, когда необходимо протестировать кумулятивные эффекты многих операций, результат которых зависит от того, как были обработаны более ранние операции, т.е. от состояния системы (см. раздел 5.2).
Причина, по которой случайные числа не являются панацеей для тестирования функции
binary_search
, заключается в том, что результат любого поиска в последовательности не зависит от результатов других попыток поисков в этой последовательности. Это, разумеется, предполагает, что функция
binary_search
не содержит совершенно глупый код, например не модифицирует последовательность. Для этого случая у нас есть более хороший тест (упр. 5).
26.3.3. Алгоритмы и не алгоритмы
В качестве примера мы рассмотрели функцию
binary_search
. Свойства этого алгоритма приведены ниже
Имеет точно определенные требования к входным данным.
• У него есть точно определенные указания, что он может и чего не может делать с входными данными (в данном случае он не изменяет эти данные).
• Не связан с объектами, которые не относятся явно к его входным данным.
• На его окружение не наложено никаких серьезных ограничений (например, не указано предельное время, объем памяти или объем ресурсов, имеющихся в его распоряжении).
У алгоритма бинарного поиска есть очевидные и открыто сформулированные пред- и постусловия (см. раздел 5.10). Иначе говоря, этот алгоритм — просто мечта тестировщика. Часто нам не так сильно везет и приходится тестировать плохой код (как минимум), сопровождаемый небрежными комментариями на английском языке и парой диаграмм.
Погодите! А не впадаем ли мы в заблуждение? Как можно говорить о корректности и тестировании, если у нас нет точного описания, что именно должен делать сам код? Проблема заключается в том, что многое из того, что должно делать программное обеспечение, нелегко выразить с помощью точных математических терминов. Кроме того, во многих случаях, когда это теоретически возможно, программист не обладает достаточным объемом математических знаний, чтобы написать и протестировать такую программу. Поэтому мы должны расстаться с идеальными представлениями о совершенно точных спецификациях и смириться с реальностью, в которой существуют не зависящие от нас условия и спешка.
А теперь представим себе плохую функцию, которую нам требуется протестировать. Под плохой функцией мы понимаем следующее.
• Входные данные. Требования к входным данным (явные или неявные) сформулированы не так четко, как нам хотелось бы.
• Выходные данные. Результаты (явные или неявные) сформулированы не так четко, как нам хотелось бы.
• Ресурсы. Условия использования ресурсов (время, память, файлы и пр.) сформулированы не так четко, как нам хотелось бы.
Под явным или неявным мы подразумеваем, что следует проверять не только формальные параметры и возвращаемое значение, но и влияние
глобальных переменных, потоки ввода-вывода, файлы, распределение свободной памяти и т.д. Что же мы можем сделать? Во-первых, такая функция практически всегда бывает очень длинной, иначе ее требования и действия можно было бы описать более точно. Возможно, речь идет о функции длиной около пяти страниц или функции, использующей вспомогательные функции сложным и неочевидным способом. Для функции пять страниц — это много. Тем не менее мы видели функции намного-намного длиннее. К сожалению, это не редкость.
Если вы проверяете свой код и у вас есть время, прежде всего попробуйте разделить плохую функцию на функции меньшего размера, каждая из которых будет ближе к идеалу функции с точной спецификацией, и в первую очередь протестируйте их. Однако в данный момент мы будем предполагать, что наша цель — тестирование программного обеспечения, т.е. систематический поиск как можно большего количества ошибок, а не простое исправление выявленных дефектов.
Итак, что мы ищем? Наша задача как тестировщиков — искать ошибки. Где они обычно скрываются? Чем отличаются программы, которые чаще всего содержат ошибки?
• Неуловимые зависимости от другого кода. Ищите использование глобальных переменных, аргументы, которые передаются не с помощью константных ссылок, указатели и т.п.
• Управление ресурсами. Обратите внимание на управление памятью (операторы
new
и
delete
), использование файлов, блокировки и т.п.
• Поищите циклы. Проверьте условия выхода из них (как в функции
binary_search
).
• Инструкции
if
и
switch
(которые часто называют инструкциями ветвления). Ищите ошибки в их логике.
Рассмотрим примеры, иллюстрирующие каждый из перечисленных пунктов.
26.3.3.1. Зависимости
Рассмотрим следующую бессмысленную функцию.
int do_dependent(int a,int& b) // плохая функция
// неорганизованные зависимости
{
int val;
cin>>val;
vec[val] += 10;
cout << a;
b++;
return b;
}
Для тестирования функции
do_dependent
мы должны не просто синтезировать набор аргументов и посмотреть, что она с ними будет делать. Мы должны учесть, что эта функция использует глобальные переменные
cin
,
cout
и
vec
. Это обстоятельство вполне очевидно в данной небольшой и бессмысленной программе, но в более крупном коде оно может быть скрыто. К счастью, существует программное обеспечение, позволяющее находить такие зависимости. К несчастью, оно не всегда доступно и довольно редко используется. Допустим, у нас нет программного обеспечения для анализа кода и мы вынуждены строка за строкой просматривать функцию в поисках ее зависимостей.