Правила тестирования Майерса

1. Считайте тестирование ключевой задачей разработки программного средства, поручайте его лучшим программистам.

2. Нежелательно тестировать свою собственную программу.

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

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

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

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

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

Нельзя гарантировать, что тестированием можно установить наличие каждой имеющейся в ПС ошибки. Поэтому возникает две задачи. Первая задача: подготовить такой набор тестов и применить к ним ПС, чтобы обнаружить в нем возможности большее число ошибок. Вторая задача: определить момент окончания отладки ПС (или отдельной его части).

Существуют следующие принципы тестирования:

1. Функциональное (тестирование «черного ящика»). Тестируется спецификация программ, то есть вход-выход без учета знаний о ее структуре; известна общая схема работы программы.

2. Структурное (тестирование «белого ящика»). Тестируется логика, внутренняя структура программы (блоки ветвления, циклы).

Тестирование программного обеспечения – процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта.

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

1. Модульное тестирование. Тестируется минимально возможные для тестирования компоненты. Например, отдельный класс или функция. Данное тестирование осуществляется разработчиками ПО.

2. Интеграционное тестирование. Тестируются интерфейсы между компонентами и подсистемами.

3. Системное тестирование. Тестируется интегрированная система на ее соответствие требованиям.

4. Альфа тестирование. Имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями (либо заказчиками).

5. Бета тестирование. Выполняется распространение версии с ограничениями (по функциональности или времени работы).

6. Тестирование белого и черного ящика. Фразы тестирование белого ящика и тестирование черного ящика относятся к тому, имеет ли разработчик тестов доступ к исходному коду программного продукта. Тестирование выполняется через пользовательский интерфейс, либо прикладной программный интерфейс, предоставляемый тестируемым модулем.

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

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

7. Статическое и динамическое тестирование. При тестировании белого и черного ящика происходит динамическое тестирование, так как в обоих случаях мы прогоняем программу. При статическом тестировании программный код не выполняется. Анализ программы происходит на основе исходного кода, который вычитывается вручную, либо анализируется специальными инструментами. К статическому тестированию также относят тестирование требований, спецификаций, документаций.

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

9. Тестовые скрипты. Используются на разных уровнях: модульном, интеграционном и системном тестировании. Тестовые скрипты пишутся для проверки компонентов, в которых наиболее высока вероятность появления отказов.

10. Покрытие кода. Покрытие кода показывает процент, насколько исходный код программы был протестирован.

Существует несколько различных способов измерения покрытия. Основные из них:

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

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

3. Покрытие пути (все ли возможные пути через заданную часть кода были выполнены и протестированы)

4. Покрытие функций (все ли функции были задействованы)

5. Покрытие входа выхода (вызовы функций и возврат в них).