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