Для того чтобы отладить программу, нужно проверить ее работоспособность на каких-то входных данных. Следовательно, эти входные данные нужно каким-то образом подобрать. Затем, после выполнения программы на этих входных данных, нужно сравнить полученный результат с тем, который должен получиться, если программа работает правильно. Этот процесс и называется тестированием.
Заметим, что если полученный результат отличается от эталонного, то тест считается удачным (!), потому что он помог обнаружить ошибку. А если полученный ответ совпал с правильным - радоваться рано. Один тест не может полностью проверить всю программу, ошибка вполне могла затаиться в той части, которая осталась на сей раз невыполненной. Для того чтобы протестировать всю программу, проверить все возможные частные случаи, составляют не один тест, а набор тестов.
И здесь существуют следующие правила.
Правило 1. Любой тест должен состоять не только из входных, но и из соответствующих им выходных данных. Ведь для того чтобы понять, верный или неверный результат выдала вам программа, необходимо самому знать правильный ответ.
Проверяйте вручную результаты тестов, с помощью которых вы отлаживаете программу. Немногого можно добиться, если выдаваемый программой правильный ответ вы считаете неверным и продолжаете поиск несуществующей ошибки. Хуже того - если вы все-таки добьетесь, чтобы программа выдавала ожидаемый вами неверный результат, объяснить ее неправильное поведение на других тестах вам будет еще сложнее.
Из двух предыдущих абзацев вытекает очень важный вывод: нельзя строить тесты при помощи генератора случайных чисел. Конечно, вы можете случайным образом составить входные данные, но как быть с правильным ответом? Откуда его взять, если вы сами понятия не имеете, что там подается на вход?
Правило 2. После того как программа начала правильно работать на одном или нескольких простых тестах, усложните задания, введите тест на граничные условия или тест, содержащий значения, выходящие за рамки формата входных данных. Иногда ошибка может скрываться в тех частях программы, которые кажутся самыми прозрачными. Например, в проверке нескольких переменных на равенство между собой. Если до сих пор все переменные в тестах были разными, попробуйте прогнать программу через тесты, в которых сравниваемые значения будут совпадать - все сразу или только некоторые из них в разных комбинациях.
Правило 3. Не ограничивайтесь только похожими тестами.
Все тесты можно разделить на три группы: регулярные, граничные и критические. Например, при заданных ограничениях на параметр 0 <= x <= 100 регулярными будут все тесты, где 1 <= x <= 99; граничными, где х = 0 и х = 100; остальные - критическими. Если ваша программа правильно работает для пяти-шести тестов из какой-либо группы, можно предположить, что она выдаст правильный результат и для всех остальных тестов из этой группы.
В тестовом наборе, составленном для проверки программ, обязательно должны присутствовать тесты первых двух групп, а для проверки работоспособности "защиты от дурака" (см. лекцию 14) - и третьей тоже. Если входных параметров несколько - комбинируйте! Пусть в одном и том же тесте первый параметр будет граничным, второй - регулярным, а третий - критическим. Всегда интересно посмотреть, достаточно ли надежна ваша программа, справится ли она с таким заданием.
В хорошей, надежной программе всегда нужно писать проверку того, что файл ввода существует, не пуст и содержит данные в правильном формате, что считываемые из входного файла данные попадают в определенные условием задачи диапазоны.
Правило 4. Исправления, вносимые в программу, могут повлиять на результаты нескольких тестов.
После того, как вы нашли и исправили ошибку, вновь выполните программу на всех тех тестах, которые раньше не были успешными (то есть выдавали правильные ответы) - а вдруг найдется новая ошибка?
Вообще же, составление исчерпывающих тестовых наборов для тестирования любой программы - задача очень нетривиальная, зачастую требующая математического доказательства полноты.
