Непсихологические тесты

Крис Касперски ака мыщъх

Спецвыпуск: Хакер, номер #053, стр. 053-060-1

Разбираемся в тестировании программного обеспечения

Программные ошибки коварны и злы. Сколько они загубили хороших проектов! Сколько времени было угрохано на поиски плавающих багов, затаившихся в засаде и выскакивающих во время демонстрации продукта заказчику. Но программист хитрее и терпеливее. Вооруженный современным инструментарием диагностики, он врезается в самое гнездилище багов и бьет их наповал.

В среднем тестирование отнимает 50% времени и 50% стоимости от общей сметы проекта (обязательно учитывай это закладывая бюджет). В больших компаниях (Intel, IBM, Microsoft) за каждым разработчиком закреплен тестер. Да, прошло то время, когда эту работу выполнял второсортный программист, которого еще не подпускали к самостоятельному кодированию (мол, прежде чем допускать свои ошибки, сначала пусть учатся на чужих). Сегодня тестер - это высококвалифицированный и хорошо оплачиваемый специалист, в услугах которого нуждаются тысячи фирм.

Когда тебе скажут, что жизненный цикл продукта состоит из проектирования, реализации, тестирования и поддержки, не верь! Тестирование сопровождает проект всю его жизнь - от момента рождения до самой смерти. Проектировщик закладывает механизмы самодиагностики и вывода "телеметрической" информации. Разработчик тестирует каждую написанную им функцию (тестирование на микроуровне). Бета-тестеры проверяют работоспособность всего продукта в целом. У каждого из них должен быть четкий план действий, в противном случае тестирование провалится еще не начавшись.

Тестирование на микроуровне

В идеале для каждой функции исходного кода разрабатывается набор автоматизированных тестов, предназначенных для проверки ее работоспособности. Лучше всего поручить эту работу отдельной группе программистов, поставив перед ними задачу разработать такой пример, на котором функция провалится. Вот, например, функция сортировки. Простейший тест выглядит так. Генерируем произвольные данные, прогоняем через нее, и, если для каждого элемента N условие N <= N+1 (N >= N+1 для сортировки по убыванию) истинно, считаем, что тест пройден правильно. Но этот тест неправильный! Нужно убедиться, что на выходе функции присутствуют все исходные данные и нет ничего лишнего! Многие функции нормально сортируют десять или даже тысячу элементов, но спотыкаются на одном или на двух (обычно это происходит при сортировке методом деления). А если будет ноль сортируемых элементов? А если одна из вызываемых функций (например, malloc), возвратит ошибку - сможет ли тестируемая функция корректно обработать ее? Сколько времени (системных ресурсов) потребуется на сортировку максимально возможного числа элементов? Неоправданно низкая производительность - тоже ошибка!

Существует два основных подхода к тестированию: черный и белый ящики. "Черный ящик" - это функция с закрытым кодом, проверка которой сводится к тупому перебору всех комбинаций аргументов. Очевидно, что подавляющее большинство функций невозможно протестировать за разумное время (количество комбинаций слишком велико). Код белого ящика известен, и тестер может сосредоточить свое внимание на пограничных областях. Допустим, в функции есть ограничение на предельно допустимую длину строки в MAX_LEN символов. Тогда следует тщательно исследовать строки в MAX_LEN–1, MAX_LEN и MAX_LEN+1 символов, поскольку ошибка "в плюс-минус один байт" - одна из самых распространенных.