1.5.1. Аксиомы тестирования

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

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

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

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

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

6. Избегайте невоспроизводимых тестов, не тестируйте «с лету».

7. Никогда не используйте тестов, которые тут же выбрасываются.    Более того, тесты следует документировать и хранить в такой форме, чтобы каждый мог использовать их повторно.

8. Готовьте тесты, как для правильных, так и для непра­вильных входных данных.

9. Детально изучите результаты каждого теста.

10. По мере того, как число ошибок, обнаруженных в некоторых компонентах программного обеспечения увеличивается, растет также относительная вероятность существования в них необнаруженных ошибок.

11. Поручайте тестирование самым опытным и способным программистам.

12. Считайте тестируемость ключевой задачей вашей раз­работки.

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

14. Тестирование, как почти всякая другая деятельность, должно начинаться с постановки целей.

15. Проект программного обеспечения должен быть таким, чтобы каждый модуль подключался к нему только один раз.

16. Для сокращения календарного времени отладки все тесты пропускаются в один выход на ЭВМ независимо от результатов выполнения каждого теста, а затем они обрабатываются.

17. Тест удаляется из дальнейшей работы, если он отработал правильно, т.к. его повторный пропуск не дает ничего нового.

18. Тест возвращается в работу, если вносились изменения в блоки, работающие при этом тесте.

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

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

1.5.2. Уровни тестирования

• Модульное тестирование (юнит-тестирование) — тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками ПО.

• Интеграционное тестирование — тестируются интерфейсы между компонентами, подсистемами или системами. При наличии резерва времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем.

• Системное тестирование — тестируется интегрированная система на её соответствие требованиям.

  • Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.

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

Часто для свободного/открытого ПО стадия альфа-тестирования характеризует функциональное наполнение кода, а бета-тестирования — стадию исправления ошибок. При этом как правило на каждом этапе разработки промежуточные результаты работы доступны конечным пользователям.