Кто осуществляет тестирование? Тестирование, проводимое создателем кода или кем-то другим, имеющим тем не менее доступ к исходному коду, называется тестированием белого ящика. Термин придуман по аналогии с тестированием черного ящика, — это когда тестер не знает, как реализован компонент. Лучше передает суть происходящего, на наш взгляд, термин "прозрачный ящик". Свой код тестировать, конечно, необходимо — не ждите, что некая мифическая тестирующая организация или пользователь сделают это вместо вас. Однако мы зачастую склонны обманывать сами себя и верить в лучшее, поэтому при тестировании вам надо отрешиться от кода и стараться придумать как можно более каверзные ходы. Вот как Дон Кнут (Don Knuth) описывает процесс создания тестов для системы форматирования ТЕХ: "Я роюсь в самых мерзких и отвратительных уголках своего мозга, потом сажусь и пишу самый мерзкий [тестирующий] код, который только могу придумать, после чего стремительно меняюсь и встраиваю его в еще более мерзкие конструкции — такие мерзкие, что и говорить противно". Цель тестирования — найти ошибки, а не объявить, что программа работает. Стало быть, тесты должны быть жесткими, и если с их помощью вы обнаруживаете проблемы, то это является доказательством действенности ваших методов, а не сигналом тревоги. Тестирование черного ящика означает, что тестер не имеет никакого представления ни о доступе к коду, ни о его внутреннем устройстве. При таком тестировании выявляются несколько иные сшибки, поскольку тестер имеет иные отправные точки для поиска. Хорошо начинать с проверки граничных условий; после этого стоит перейти к большим объемам и некорректному вводу. Естественно, не надо забывать и о "золотой середине": проверке работы программы в нормальных условиях. Следующий этап — реальные пользователи. Новые пользователи находят новые ошибки, потому что они опробуют программу неожиданными способами. Важно провести этот этап тестирования до того, как вы выпустите свое детище в большой мир, однако, к сожалению, многие программы распространяются без прохождения достаточного тестирования какого бы то ни было вида. Бета-версии программ — попытка привлечь большое количество конечных пользователей к тестированию, однако такие бета-версии нельзя рассматривать как замену нормальному тестированию. Однако чем больше и сложнее становятся системы, чем короче сроки на их разработку, тем выше вероятность появления плохо оттестированных продуктов. Трудно тестировать интерактивные программы, особенно если в них обрабатывается ввод с помощью мыши. Некоторые тесты можно выполнить с помощью сценариев (их конкретные возможности зависят от языка, среды и т. п.). Интерактивные программы можно контролировать из скриптов, имитирующих поведение пользователя. Здесь есть два способа: первый — перехватить действия реального пользователя и воспроизводить их; второй — создать язык скриптов, позволяющий описать последовательность и протяженность событий. Наконец, стоит задуматься и о том, как тестировать сами тесты. В главе 5 мы упомянули о проблеме, вызванной некорректностью программы, которая тестирует пакет функций для работы со списками. Набор возвратных тестов, содержащий ошибку, вызовет проблемы во всех версиях, и вообще, результат выполнения набора тестов вряд ли будет что-то значить, если сами тесты окажутся некорректными.