Здравствуйте!
В прошлой записи я рассказал о том, что подавляющее число настольных и веб-приложений можно спроектировать в виде набора модулей, каждый из которых относится к одному из 5 типов. Если спроектировать ПО таким образом, то его легче и дешевле будет протестировать.
Сегодня мы поговорим о том, как тестировать различные виды модулей.
Но для начала мы поговорим о видах проверочных программ.
Виды проверочных программ
Я разделаю все проверочные программы на 2 класса:
- Модульные
- Интеграционные
Модульные проверочные программы – это такие, при выполнении которых задействован один или несколько (но не все) модули приложения. Допустим, в проверочной программе Вы создаёте некий объект из какого-то модуля, производите над ним некие операции, а потом сравниваете ожидаемый результат с реальным.
В такой проверочной программе задействован один единственный модуль.
Интеграционные тесты устроены иначе – при их выполнении проверяется работоспособность всех модулей приложения.
Пример. Допустим, у Вас есть настольное приложение, которое обменивается данными с серверной частью, а та – с базой данных. Типичная 3-слойная архитектура.
Вы хотите одним тестом выявить как можно больше ошибок. Вы делаете некую программу, которая
1) запускает настольное приложение,
2) вводит данные, нажимает на кнопки и симулирует другие действия пользователя и
3) после этого сверяет ожидаемый результат с реальным.
Другими словами проверочная программа заменяет пользователя-человека и повторяет его действия. Так как приложение клиент-серверное, действия пользователя в настольном приложении приведут к каким-то операциям на сервере и в базе данных.
В случае тех или иных ошибок или сбоев, в настольном приложении появится соответствующее сообщение.
Таким образом, с помощью такого теста можно выявить дефекты не в одном отдельно взятом модуле, а во всех модулях, которые так или иначе реагируют на действия пользователя.
Далее – в отличии от модульного теста, интеграционные тесты выявляют
- не только дефекты в модулях, но и
- дефекты во взаимодействии нескольких модулей.
Если, например, модуль А передаёт модулю Б неправильные данные и поэтому модуль Б сбоит – то это не дефект модуля Б, а дефект взаимодействия модулей А и Б.
Как тестировать модуль вида № 1 (хранение данных)
Проверить работу модуля хранения данных можно при помощи модульного теста, который
- Подключается с тестовой базе данных
- Заполняет её исходными данными
- Выполняет ту или иную операцию модуля хранения данных
- Сверяет ожидаемый результат с реальным
Как тестировать модули видов № 2 и 3 (модуль отображения и модуль-координатор)
Модули этих видов можно протестировать только в рамках интеграционной проверки. Причём, делать эту интеграционную проверку следует только после того, как модуль хранения данных и все алгоритмические модули, имеющие отношение к проверямым модулям отображения и модулю-координатору, были проверены и работают (т. е. их модульные тесты работают без ошибок).
Как тестировать модуль вида № 4 (алгоритмический модуль)
Алгоритмический модуль протестировать проще всего (при правильном проектировании 
). Типовая проверочная программы выглядит так:
- Создаются и инициализируются все объекты-заглушки, которые требуются проверяемому модулю.
- Инициализируется проверямый объект.
- Вызывается проверяемый метод объекта.
- Ожидаемые результаты сверяются с реальными.
Как тестировать модуль вида № 5 (модуль создания отчётов)
Модуль для создания отчётов тестируется модульным тестом. Как конкретно выглядит проверочная программа для такого модуля, зависит от цели проверки.
Целью проверки может быть одно из двух:
- Проверить правильность составления отчёта.
- Удостовериться, что после изменения программы создаваемые ею отчёты остались прежними.
Если Вы преследуете цель № 1, то надо взять относительно малое количество исходных данных, дабы генерируемый отчёт был относительно маленьким. В маленьком отчёте легче разобраться и легче найти ошибку.
Кроме того, при достижении цели № 1 в одной проверочной программе должен проверяться один тип отчёта.
Если Вы преследуете цель № 2, т. е. Вам нужно знать, изменились ли генерируемые отчёты по сравнению с прошлой версией, то в этом случае
- нет ограничения на объём входных данных и
- в проверочной программе должны проверяться все типы отчёта.
Чем больше отчётов Вы проверите в таком тесте, тем скорее достигнете цель № 2. Аналогично по поводу объёма данных – здесь действует принцип «чем больше, тем лучше».
В обоих случаях проверочная программа для отчётов устроена одинаково:
- Инициализируется модуль создания отчётов и все нужные ему модули.
- Модулю создания отчётов передаются входные данные.
- Создаются отчёты и складываются в некую директорию.
- Созданные отчёты сравниваются с правильными (ожидаемыми) отчётами, которые были сделаны до этого.
Примечание к шагу 3: Отчёты следует генерировать в легко проверямом формате – текстовый или CSV файл. Большинство библиотек для создания отчётов поддерживают экспорт в текстовый формат. Это сильно облегчает процесс тестирования, т. к. сравнить два текстовых файла проще, нежели 2 ПДФ-файла.
Успехов
Дмитрий Писаренко
