Рекомендуемая последовательность разработки тестов для программного модуля. 1. По внешней спецификации готовятся тесты

1. По внешней спецификации готовятся тесты:

- для каждого класса входных данных

- для граничных и особых значений входных данных

- проверяется, все ли классы выходных данных при этом проверяются, и при необходимости добавляются нужные тесты

2. Готовятся тесты для тех функций, которые не проверяются в п. 1.

3. По тексту программы проверяется, все ли условные переходы выполнены в

каждом направлении (С1). При необходимости добавляются новые тесты.

4. Аналогично проверяется, проходятся ли пути для каждого цикла: без

выполнения тела, с однократным и максимальным числом повторений.

5. Готовятся тесты, проверяющие исключительные ситуации, недопустимые

входные данные, аварийные ситуации и режимы повышенной нагрузки.

Функциональное тестирование дополняется здесь структурным. Классы вх/вых данных должны быть определены в плане тестирования уже во внешней спецификации. Согласно статистике, 1 и 2 пункты обеспечивают степень охвата С1 в среднем 40-50%. Проверка по С1 (пункт 3) обычно выявляет 90% всех ошибок, найденных при тестировании. Все программное обеспечение ВВС США принимается с проверкой по С1. На практике, для менее ответственных программ, ограничиваются функциональ-ным тестированием, особенно при независимом тестировании.

Примеры систематического функционального тестирования:

· Полный набор тестов для Excel 4.0 - около 12000 последовательностей команд по 5-20 команд в каждой (1996, MS Europe Division, Dublin).

· Стандартный набор тестов для приемо-сдаточных испытаний трансляторов с языка Ада: 1200 коротких программ с исходными данными и ожидаемыми результатами. Более 200 компиляторов для разных машин были приняты с такими испытаниями.

Аксиомы тестирования по Майерсу [1]

1. Тест должен быть направлен на обнаружение ошибки, а не на подтверждение правильности программы.

2. Автор теста – не автор программы.

3. Тесты разрабатываются одновременно или до разработки программы.

4. Необходимо предсказывать ожидаемые результаты теста до его выполнения и анализировать причины расхождения результатов.

5. После каждого исправления ошибки нужно повторять тест(ы), ее обнаруживший.

6. Следует повторять полное тестирование после каждого внесения исправлений и изменений в программу или после переноса ее в другую среду.

7. Для тех программ, в которых обнаружено много ошибок, необходимо дополнить первоначальный набор тестов.

Пункты 5 и 6 называют регрессионным тестированием. Исправление может не устранить ошибку, а может и породить новые ошибки. По статистике эффективности исправления ошибок, 10% неудачных исправлений – это очень хороший показатель; 25% - средний, а в сложных проектах зафиксированы гораздо большие значения, вплоть до 80%. Требование п. 6 – слишком сильное; на практике прогон полного набора тестов (или его представительного подмножества) производится не после каждого исправления, а после их серии – цикла тестирования. В больших проектах проходят 10-30 таких циклов, синхронизированных с различными стадиями готовности продукта.