class="p1"> << t.seq.size() << "элементов, val==" << t.val
<< " –> " << t.res << 'n';
++error_count;
}
}
return error_count;
}
int main()
{
int errors = test_all(ifstream ("my_test.txt");
cout << "Количество ошибок: " << errors << "n";
}
Вот как выглядят некоторые тестовые данные.
{ 1.1 1 { 1 2 3 5 8 13 21 } 1 }
{ 1.2 5 { 1 2 3 5 8 13 21 } 1 }
{ 1.3 8 { 1 2 3 5 8 13 21 } 1 }
{ 1.4 21 { 1 2 3 5 8 13 21 } 1 }
{ 1.5 –7 { 1 2 3 5 8 13 21 } 0 }
{ 1.6 4 { 1 2 3 5 8 13 21 } 0 }
{ 1.7 22 { 1 2 3 5 8 13 21 } 0 }
{ 2 1 { } 0 }
{ 3.1 1 { 1 } 1 }
{ 3.2 0 { 1 } 0 }
{ 3.3 2 { 1 } 0 }
Здесь видно, почему мы использовали строковую метку, а не число: это позволяет более гибко нумеровать тесты с помощью десятичной точки, обозначающей разные тесты для одной и той же последовательности. Более сложный формат тестов позволяет исключить необходимость повторения одной и той же тестовой последовательности в файле данных.
26.3.2.3. Случайные последовательности
Выбирая значения для тестирования, мы пытаемся перехитрить специалистов, создавших реализацию функции (причем ими часто являемся мы сами), и использовать значения, которые могут выявить слабые места, скрывающие ошибки (например, сложные последовательности условий, концы последовательностей, циклы и т.п.). Однако то же самое мы делаем, когда пишем и отлаживаем свой код. Итак, проектируя тест, мы можем повторить логическую ошибку, сделанную при создании программы, и полностью пропустить проблему. Это одна из причин, по которым желательно, чтобы тесты проектировал не автор программы, а кто-то другой.
Существует один прием, который иногда помогает решить эту проблему: просто сгенерировать много случайных значений. Например, ниже приведена функция, которая записывает описание теста в поток cout с помощью функции randint() из раздела 24.7 и заголовочного файла std_lib.facilities.h.
void make_test(const string& lab,int n,int base,int spread)
// записывает описание теста с меткой lab в поток cout
// генерирует последовательность из n элементов, начиная
// с позиции base
// среднее расстояние между элементами равномерно распределено
// на отрезке [0, spread]
{
cout << "{ " << lab << " " << n << " { ";
vector<int> v;
int elem = base;
for (int i = 0; i<n; ++i) { // создаем элементы
elem+= randint(spread);
v.push_back(elem);
}
int val = base + randint(elem–base); // создаем искомое значение
bool found = false;
for (int i = 0; i<n; ++i) { // печатаем элементы и проверяем,
// найден ли элемент val
if (v[i]==val) found = true;
cout << v[i] << " ";
}
cout << "} " << found << " }n";
}
Отметим, что для проверки, найден ли элемент val в случайной последовательности, мы не использовали функцию binary_search. Для того чтобы обеспечить корректность теста, мы не должны использовать функцию, которую проверяем.
На самом деле функция binary_search не самый удобный пример для тестирования с помощью наивного подхода на основе случайных чисел. Мы сомневаемся, что сможем найти какие-то новые ошибки, пропущенные на ранних этапах с помощью тестов, разработанных “вручную”, тем не менее этот метод довольно часто оказывается полезным. В любом случае следует выполнить несколько случайных тестов.
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). Иначе говоря, этот алгоритм — просто мечта тестировщика. Часто нам не так сильно везет и приходится тестировать плохой код (как минимум), сопровождаемый небрежными комментариями на английском языке и парой диаграмм.
Погодите! А не впадаем ли мы в заблуждение? Как можно говорить о корректности и тестировании, если у нас нет точного описания, что именно должен делать сам код? Проблема заключается в том, что многое из того, что должно делать программное обеспечение, нелегко выразить с помощью точных математических терминов. Кроме того, во многих случаях, когда это теоретически возможно, программист не обладает достаточным объемом математических знаний, чтобы написать и протестировать такую программу. Поэтому мы должны расстаться с идеальными представлениями о совершенно точных спецификациях и смириться с
