Предсказания

Регрессивное тестирование

Тестирование и спецификации

При создании программ, опирающемся на тестирование (test-driven) и получившем известность благодаря методам «скорой» (agile) разработки, тесты ставят на первое место, но иногда считают, что они могут заменить спецификации. Не могут. Тесты, даже если их миллион, — это лишь примеры; в них отсутствует абстракция, которую может дать только спецификация.

Принцип 2. Тесты или спецификации. Тесты не заменяют спецификации.

Опасность заблуждения, что тесты могут выступать в роли спецификаций, была продемонстрирована целым рядом программных катастроф, которые произошли только потому, что никто не подумал об исключительном случае. Несмотря на то, что в спецификациях тоже могут быть упущены из виду какие-то случаи, по крайней мере, в них предпринимается попытка некого обобщения. В частности, спецификации могут использоваться для генерации тестов, даже автоматически (как в случае тестирования, опирающегося на модели); но обратное без вмешательства человека невозможно.

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

Принцип 3. Регрессивное тестирование. Любое неудачное выполнение должно порождать тестовый случай, который навсегда становится частью тестового пакета данного проекта.

Этот принцип касается всех ошибок, возникших во время разработки и тестирования. Отсюда вытекает необходимость в инструментарии, позволяющем превращать неудачное исполнение в воспроизводимый тестовый случай, и недавно такой инструментарий появился: Contract-Driven Development, ReCrash, JCrasher.

Выполнение теста полезно только в том случае, если вы можете однозначно определить, прошел ли он. Критерий называется предсказанием теста. Если у вас есть несколько десятков или даже сотен тестов, то вы в состоянии проверить их результаты по отдельности, однако с увеличением их количества это становится все менее вероятным. Данная задача требует автоматизации.

Принцип 4. Использование предсказаний. Определение успеха или неудачи тестов должно происходить автоматически.

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

Принцип 4 (вариант). Контракты как предсказания. Предсказания должны быть частью текста программы как контракты. Успех или неудача теста должны определяться автоматически, причем в рамках этого процесса необходимо вести мониторинг выполнения контракта во время работы программы.

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

Дата добавления: 2015-05-10