Разработка тестов. Методы проверки и тестирования программ и систем. Тестовое окружениеВосходящее тестирование. Программное обеспечение собирается и тестируется снизу вверх.Только модули самого нижнего уровня тестируются изолированно, автономно. Затем тестируются модули, непосредственно вызывающие их,которые тестируются не автономно, а вместе с уже проверенными модулями. И так, пока не будет достигнута вершина. В последнюю очередь тестируется программное обеспечение в целом. Нисходящее тестирование. Программное обеспечение собирается и тестируется сверху вниз. Изолированно тестируется только головной модуль.Затем с ним соединяются один за другим модули, непосредственно вызываемые им, и тестируется полученная комбинация. Так до тех пор, пока не будут собраны и проверены все модули. Если вызываемый для тестирования модуль еще не существует, то для имитации функций недостающих модулей программируются модули-«заглушки». При модификации нисходящего подхода требуется, чтобы каждый модуль перед подключением его к комплексу программ прошел автономное тестирование. Метод большого скачка. Каждый модуль тестируется автономно.Затем они интегрируются в систему все сразу.Заметим, что при восходящем и нисходящем подходах каждый раз подключается только один модуль, и если обнаружится ошибка, подозрение в первую очередь падает на последний добавленный модуль. Так что метод большого скачка значительно усложняет отладку программного обеспечения и приемлем лишь для маленьких, хорошо спроектированных программ. Метод «сэндвича». Одновременно начинают восходящее и нисходящее тестирование, собирая программу как снизу, так и сверху и встречаясь где-то в середине.Точка встречи зависит от тестируемого программного обеспечения и должна быть заранее определена при изучении ее структуры. Это разумный подход к интеграции больших программных изделий, таких как операционная система или пакет прикладных программ. Аксиомы тестирования 1. Хорош тот тест, который позволяет обнаружить ошибку, а не тот, который демонстрирует правильную работу программы. 2. Тесты, не способствующие обнаружению ошибок и только подтверждающие корректность функционирования программного обеспечения, являются неэффективными, т.к. приводят к бесполезным затратам ресурсов и времени. 3. Одна из самых сложных проблем при тестировании — решить, когда нужно его закончить. 4. Невозможно тестировать свою собственную программу.Тестирование должно быть в высшей степени разрушительным процессом, но программист не может относиться к своей программе как разрушитель (психологические причины, жесткий график, давление коллектива и т.д.). 5. Необходимая часть всякого теста — описание ожидаемых выходных данных или результатов. Ожидаемые результаты нужно определять заранее. 6. Избегайте невоспроизводимых тестов, не тестируйте «с лету». 7. Никогда не используйте тестов, которые тут же выбрасываются. Более того, тесты следует документировать и хранить в такой форме, чтобы каждый мог использовать их повторно. 8. Готовьте тесты, как для правильных, так и для неправильных входных данных. 9. Детально изучите результаты каждого теста. 10. По мере того, как число ошибок, обнаруженных в некоторых компонентах программного обеспечения увеличивается, растет также относительная вероятность существования в них необнаруженных ошибок. 11. Поручайте тестирование самым опытным и способным программистам. 12. Считайте тестируемость ключевой задачей вашей разработки. 13. Никогда не изменяйте программу, чтобы облегчить ее тестирование. 14. Тестирование, как почти всякая другая деятельность, должно начинаться с постановки целей. 15. Проект программного обеспечения должен быть таким, чтобы каждый модуль подключался к нему только один раз. 16. Для сокращения календарного времени отладки все тесты пропускаются в один выход на ЭВМ независимо от результатов выполнения каждого теста, а затем они обрабатываются. 17. Тест удаляется из дальнейшей работы, если он отработал правильно, т.к. его повторный пропуск не дает ничего нового. 18. Тест возвращается в работу, если вносились изменения в блоки, работающие при этом тесте. 19. Составляя календарный план разработки программного обеспечения, разумно всегда настаивать на выделении необходимого времени для обеспечения надлежащего качества его тестирования. 20. Если программное обеспечение правильно ведет себя для солидного набора тестов, нет оснований утверждать, что в нем нет ошибок.
|
