Рекомендуемая последовательность разработки тестов для программного модуля
1. По внешней спецификации готовятся тесты:
для каждого класса входных данных
для граничных и особых значений входных данных
проверяется, все ли классы выходных данных при этом проверяются, и при необходимости добавляются нужные тесты
Готовятся тесты для тех функций, которые не проверяются в п. 1.
По тексту программы проверяется, все ли условные переходы выполнены в
каждом направлении (С1). При необходимости добавляются новые тесты.
Аналогично проверяется, проходятся ли пути для каждого цикла: без
выполнения тела, с однократным и максимальным числом повторений.
Готовятся тесты, проверяющие исключительные ситуации, недопустимые
входные данные, аварийные ситуации и режимы повышенной нагрузки.
Функциональное тестирование дополняется здесь структурным. Классы вх/вых данных должны быть определены в плане тестирования уже во внешней спецификации. Согласно статистике, 1 и 2 пункты обеспечивают степень охвата С1 в среднем 40-50%. Проверка по С1 (пункт 3) обычно выявляет 90% всех ошибок, найденных при тестировании. Все программное обеспечение ВВС США принимается с проверкой по С1. На практике, для менее ответственных программ, ограничиваются функциональ-ным тестированием, особенно при независимом тестировании.
Примеры систематического функционального тестирования:
Полный набор тестов для Excel 4.0 - около 12000 последовательностей команд по 5-20 команд в каждой (1996, MS Europe Division, Dublin).
Стандартный набор тестов для приемо-сдаточных испытаний трансляторов с языка Ада: 1200 коротких программ с исходными данными и ожидаемыми результатами. Более 200 компиляторов для разных машин были приняты с такими испытаниями.
Аксиомы тестирования по Майерсу [1]
Тест должен быть направлен на обнаружение ошибки, а не на подтверждение правильности программы.
Автор теста – не автор программы.
Тесты разрабатываются одновременно или до разработки программы.
Необходимо предсказывать ожидаемые результаты теста до его выполнения и анализировать причины расхождения результатов.
После каждого исправления ошибки нужно повторять тест(ы), ее обнаруживший.
Следует повторять полное тестирование после каждого внесения исправлений и изменений в программу или после переноса ее в другую среду.
Для тех программ, в которых обнаружено много ошибок, необходимо дополнить первоначальный набор тестов.
Пункты 5 и 6 называют регрессионным тестированием. Исправление может не устранить ошибку, а может и породить новые ошибки. По статистике эффективности исправления ошибок, 10% неудачных исправлений – это очень хороший показатель; 25% - средний, а в сложных проектах зафиксированы гораздо большие значения, вплоть до 80%. Требование п. 6 – слишком сильное; на практике прогон полного набора тестов (или его представительного подмножества) производится не после каждого исправления, а после их серии – цикла тестирования. В больших проектах проходят 10-30 таких циклов, синхронизированных с различными стадиями готовности продукта.