Файл: Отладка и тестирование программ: основные подходы и ограничения (Отладка программ).pdf

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

5) Тестирование базового пути

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

6) Тестирование потока данных

В этом типе тестирования граф потока управления сопровождается информацией о том, как программные переменные определяются и используются.

1. Циклическое тестирование

Сосредоточено исключительно на валидности конструкции цикла.

Преимущества:

1. Обнаруживает ошибку в скрытом коде, удаляя лишние строки кода.
2. Максимальный охват достигается при написании тестового сценария [19.].
3. Разработчик тщательно обосновывает причины реализации.

Недостатки:

1. Для проведения этого тестирования необходим опытный специалист по тестированию, так как требуется знание внутренней структуры ПО.
2. Многие пути останутся непроверенными, так как очень трудно заглянуть в каждый уголок и найти скрытые ошибки.

2.6 Метод серого ящика

Тестирование по методу серого ящика пытается и в целом успешно сочетает в себе преимущества тестирования как по методу черного, так и по методу белого ящика. Тестирование «серого ящика» использует прямой подход к тестированию «черного ящика», но также использует некоторые ограниченные знания о внутренней работе приложения. Белый ящик + черный ящик = серый ящик, это методика тестирования приложения с ограниченными знаниями о внутренней работе приложения, а также со знанием фундаментальных аспектов системы. Таким образом, тестер может проверить как вывод пользовательского интерфейса, так и процесс, который приводит к выводу этого пользовательского интерфейса. Тестирование по этому методу может быть применено к большинству этапов; однако в основном оно используется в интеграционном тестировании.

Этот метод включает в себя следующие техники:

1. Тестирование ортогональных массивов

Этот тип тестирования используют в качестве подмножества всех возможных комбинаций.

1. Матричное тестирование

В матричном тестировании указывается отчет о состоянии проекта.

1. Регрессионное тестирование

Если в программное обеспечение вносятся новые изменения, регрессионное тестирование подразумевает выполнение тестовых случаев.

1. Тестирование шаблонов

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

Преимущества:

1. Данный метод обеспечивает совместное преимущество методов тестирования «черного ящика» и «белого ящика».

2. При тестировании по этому методу специалист может разработать отличные сценарии тестирования.

3. Беспристрастное тестирование.

Недостатки:

1. Тестовое покрытие в данном случае ограничено, так как доступ к исходному коду невозможен.

2. Многие пути программы остаются непроверенными.

3. Контрольные примеры могут быть избыточными.

Сравнение методов тестирования приведено в таблице ниже.

Сравнение методов тестирования по некоторым критериям

Продолжение таблицы

3. Инструменты для организации тестирования

3.1 Библиотека doctest

Быстрый и удобный способ тестирования программы на примере функции проверки корректности скобочной структуры приведен на рисунке 9. Считается, интерфейс уже проработан. С помощью библиотеки doctest можно сделать примеры из документ-строки действующими (будут выполняться как юнит-тесты), добавив несколько примеров корректных и некорректных скобочных последовательностей.

Рисунок 9. Функция проверки корректности скобочной структуры с тестированием

После подключения библиотеки doctest и вызова функции testmod будет получен отчет о выполнении комментариев для каждого завалившегося теста. Пока реализации нет, для всех отображается «Expected: ... Got nothing» (рисунок 10).

Рисунок 10. Результаты тестирования функции проверки корректности скобочной структуры

Фрагмент реализации приведен на рисунке 11.

Рисунок 11. Реализация описанной ранее функции

При запуске тестов будет выведено «Process finished with exit code 0». Тестирование производится, но ошибки не отображаются и всё работает хорошо. Таким образом, прямо в процессе программирования, еще разрабатывая интерфейс функции и прописывая документ-строку, можно уже писать тесты простым и естественным способом.

3.2 Библиотека unittest

В этом подразделе рассматривается более сложное тестирование при помощи библиотеки unittest на примере функции, вычисляющей числа Фибоначчи (рисунок 12).

Рисунок 12. Определение функции вычисления чисел Фибоначчи

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

Для этого требуется создать тестирующий модуль, который будет содержать тестирующий класс, наследующийся от unnittest.TestCase (рисунок 13). И все методы, начинающиеся со слова test, будут тестирующими.

Рисунок 13. Тестирующий модуль для проверки функции

Простой юнит тест, проверяющий, что число Фибоначчи от 0 это действительно 0, приведен на рисунке 13. assertEqual проверяет равенство своих параметров. Модуль unittest автоматически запустит этот test_zero и оформит результат красиво, если тест будет заваливаться. Другой вариант использования библиотеки unittest: если в модуле достаточно много микротестов(подслучаев), и если произойдет заваливание на одном подслучае, то весь этот маленький тест-кейс просто будет выброшен. А можно было бы протестировать их все, чтобы даже было видно, с каким номером это происходило. Это делается при помощи вызова функции subTest с указанием некоторого индекса. Рисунок 14 иллюстрирует проверку для 1-5 и 10-го числа Фибоначчи.

Рисунок 14. Проверка работы функции на конкретных примерах

3.3 Использование библиотеки unittest

Когда производится анализ тестовых случаев, следует задуматься, а не могут ли функцию вызвать с какими-то некорректными параметрами, например, для отрицательных чисел.

В этом случае принято выбрасывать исключение. Библиотека unittest позволяет перехватить это исключение. Таким образом можно добавить тесты на отрицательные и дробные числа (рисунок 15).

Отличие assert-ов в 1 случае (test_simple) и во 2 (test_negative) в том, что в test_simple функция вызывается самостоятельно, а во втором передается вместе со списком аргументов.

Рисунок 15. Тест отрицательных и дробных чисел

Если сейчас запустить программу, возникнет целый отчёт, где, что и почему упало (рисунок 16).

Рисунок 16. Отчет с результатами первого тестирования

В результате будет сообщено, что пять тестов прошло, и десять ошибок найдено. Анализ этих ошибок позволит найти необходимые поправки (рисунок 17).

Рисунок 17. Функция вычисления чисел Фибоначчи после первых правок

Теперь при запуске тестирующего модуля будут пойманы ошибки test_negative и test_fractional. После исправления (рисунок 18) все тесты проходят получается короткий отчёт, приведенный на рисунке 19.

Рисунок 18. Функция вычисления чисел Фибоначчи после итоговых правок

Рисунок 19. Результат – все тесты пройдены успешно

Инструментарий библиотеки unittest:

1. Test case – тестовый случай, базовая единица тестирования.
2. Test fixture – среда исполнения теста. Включает подготовку к тестированию и последующее обнуление данных, используемых в тестовом случае.
3. Test suite – набор тестовых случаев.
4. Test runner – группа запуска тестов. Это множество классов, связанных с запуском и представлением тестов.

Для начала самое главное – научиться создавать тестовые случаи («тест-кейсы»).

Класс тестового случая – потомок unittest.TestCase.

Тестирующий метод начинается со слова test.

Для проверки утверждения используется метод self.assertEqual() Если не соблюдать эти правила, то метод либо не будет выполнен, либо ошибка не будет корректно обработана.

Варианты методов assert приведены на рисунке 20.

Рисунок 20. Варианты методов assert

Следует заметить, что assertEqual(a, b) для строк, последовательностей, списков, кортежей, множеств и словарей осуществляет специализированную по типу проверку. Есть также проверки, проводящие сравнение и проверки включения (рисунок 21).

Рисунок 21. Варианты методов assert для структур данных

Хороший программный код должен быть устойчивым в тех случаях, когда его используют с некорректными параметрами. В частности, метод или функция должны возбуждать определённое исключение, когда возникает конкретная внештатная ситуация: self.assertRaises(ValueError, math.sqrt, -1)

Обратите внимание, что при использовании assertRaises нельзя вызывать функцию. Мы передаём ему ссылку на функцию и её параметры, чтобы она была вызвана уже внутри метода assertRaises, описанного в библиотеке unittest.

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

Для проведения теста нужно создание определённых тестовых условий, определённого состояния среды исполнения теста (Test fixture). Например, нужно создать и заполнить определённым образом базу данных, необходимую для проведения операций, подвергающихся проверке. Или же проводится тестирование некоего класса A, использующего объект класса B, который использует объект класса C. В этом случае требуется создать и инициализировать эти объекты.

Базовые правила тестирования:

1. Работа теста не должна зависеть от результатов работы других тестов.
2. Тест должен использовать данные, специально для него подготовленные, и никакие другие.
3. Поскольку предыдущие тесты могут повлиять на среду исполнения, её нужно уничтожать и создавать заново для каждого тестового случая. Для этого используются автоматически вызываемые методы setUp() и tearDown().