Глава 7: Разработка тестов 203

Применение технологии эквивалентности

Тестирование математических функций — не единственная область применения эталонных программ. Путем сравнения с готовым и проверен­ным продуктом можно тестировать самые разные аспекты поведения про­граммы. Вот несколько примеров.

• Если разрабатывается программа проверки правописания и в ее основе лежит тот же алгоритм, который используется в одной из уже существующих программ, можно предложить им проверить один и тот же набор слов.

• Если разрабатывается программа автоматического переноса слов и особенно если отрабатывается модификация ее алгоритма для дру­гого языка, возьмите для сверки проверенную программу, продава­емую на том же рынке. Подготовьте узкий столбик текста и предложите его обеим программам.

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

• Для отладки посылаемых на принтер управляющих последователь­ностей можно перенаправить вывод в файл и то же самое сделать в эталонной программе, распечатав в ней точно такой же документ. Затем оба файла можно сравнить — они должны быть идентичны.

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

— во многих случаях ее применение значительно ускоряет работу и во много раз повышает ее эффективность.

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

204 Часть II: Приемы и технологии тестирования

Регрессионное тестирование: успешно ли исправлена ошибка

Получив отчет об ошибке, программист тщательно анализирует исход­ный код, находит причину ошибки, исправляет ее и тестирует результат. Однако это идеальный вариант — на практике же так бывает далеко не всегда. Некоторые программисты исправляют только описанные в отчете симптомы. В результате исправления настоящие причины ошибки не уст­раняются — одно из проявлений ошибки исчезает, но другие остаются. Бывает и так, что программист неправильно поймет отчет и исправит не то, что надо. Некоторые недобросовестные сотрудники вообще не тестируют свою работу: они не глядя вносят исправления и немедленно возвращают программу тестировщикам, не исправив прежнюю ошибку и наделав новых. Этот перечень можно продолжать бесконечно. Главное же — не растерять­ся, столкнувшись с подобными ситуациями. Опытный тестировщик должен быть готов к ним заранее.

Считается, что около трети вносимых в программу исправлений или не срабатывают, или даже “ломают” то, что уже работало. Мартин и Мак-Клер (МаПт & тсОиге, 1983) приводят статистику, показывающую, что с пер­вого раза срабатывает менее половины вносимых программистами исправ­лений.

Вот три задачи, которые ставит перед собой тестировщик, проверяющий внесенные программистом исправления.

• Проверьте, что ошибка исправлена. Выполните тот же тест, в кото­ром она проявилась и который был описан в отчете. Если программа его не пройдет, дальнейшее тестирование ни к чему. Если же про­грамма пройдет тест, не торопитесь. Подумайте еще секунду, в са­мом ли деле вы провели именно нужный тест. Уверены ли вы, что знаете, как воспроизвести ошибку? И при малейших сомнениях загрузите старую версию программы, выполните описанные в отчете действия и убедитесь, что ошибка налицо.

• Поищите связанные ошибки. Предположим, что программист устра­нил описанные в отчете симптомы ошибки, но саму ее не исправил. Можно попробовать воспроизвести ошибку каким-нибудь иным способом. Может быть, в программе есть другие подобные ситуа­ции? Не жалейте времени, если вам кажется, что ошибка могла остаться — потестируйте программу еще час, может быть несколь­ко часов. Проведите как можно больше тестов.