Организация тестового набора при автоматизированном функциональном тестировании Мария Колчинская. Xored Software

Содержание Кто мы, что и с помощью чего тестируем Цели автоматизации функционального тестирования Проблемы анализа результатов тестирования Требования к отдельному тесту. Запись теста Требования к организации тестового набора Достоверность получаемого результата Итог работы

Xored Software Российская компания, созданная с нуля в Новосибирском Академгородке. Занимается созданием средств разработки и продуктов на основе технологии Eclipse Одно из направлений – разработка систем моделирования для компаний телекоммуникационного сектора (Cisco Systems, British Telecom) Cобственная разработка – средство автоматизации функционального тестирования Q7

Тестируемое приложение Eclipse Tigerstripe – приложение для моделирования – создания UML диаграмм и кода на их основе. Создано на платформе Eclipse Содержит большое количество диаграмм и взаимосвязей между объектами В данный момент все функциональные тесты приложения автоматизированы и встроены в систему непрерывной интеграции Atlassian Bamboo

Инструмент тестирования Q7 – приложение для автоматизации функционального тестирования Создано на платформе Eclipse и для тестирования Eclipse приложений Поддерживает работу с графическими элементами Обеспечивает встраивание тестов в систему непрерывной интеграции

Цели автоматизации тестирования Получение информации о качестве продукта при каждой сборке приложения Сокращение трудозатрат на тестирование

Шаги автоматизации тестирования Сформировать базу сценариев работы пользователя с приложением На основе сценариев создать автоматизированные тесты для покрытия основной функциональности приложения. Тесты полностью повторяют действия пользователя через UI Встроить тесты в систему непрерывной интеграции. В результате тесты будут выполняться при каждой сборке приложения на всех указанных платформах

Отчет о результатах тестирования Вид страницы с отчетом о результате тестирования: Test Summary 384 tests in total. 1 New Failures; 1 Existing Failures; 6 Fixed Tests New Test Failures (1): UpdateLiteralValue View Job: Q7 win32 Duration: 15 secs testcase: Execution failed on line 38 at column 1 (UpdateLiteralValue) Caused by: The Window "Save Enumeration" could not be found. [get-window "Save Enumeration"] Information: gef.editparts (1175 more lines...) Existing Test Failures (1): AddRemoveAnnotationDiagramAttribute View Job: Q7 win32 Duration: 4 secs Failing Since Build: #64

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

Требования к отдельному тесту Чем меньше тест, тем проще локализовать проблему Необходимо отделить шаги по подготовке среды тестирования от шагов самого теста Результаты предыдущих тестов не должны влиять на результат выполняемого теста

Структура теста Precondition – подведение системы к состоянию, пригодному для тестирования Steps (Test) – непосредственное проведение теста Post Condition – удаление данных, созданных в процессе выполнения скрипта

Структура автоматизированного теста Каждый тест обязательно разделяется на 2 части: Context – отдельный скрипт (либо файлы контекста Eclipse), который удаляет все изменения, оставшиеся в результате предыдущих действий и подготавливает условия для теста Сценарий – отдельный скрипт с записью шагов теста

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

Требования к организации тестов Максимальный отказ от ручных тестов Тестовая база для всего приложения Тесты на новую функциональность Отдельный тест на каждый тестовый случай Отдельный тест на каждый баг в системе, полученный от заказчика (для теста создается «метка» для привязки к участку функциональности)

Достоверность получаемого результата Тесты, которые дают ложный результат из-за проблем инструмента тестирования либо неактуальности самого теста, неинформативны и искажают общую картину. Для того чтобы получать достоверный результат тестирования и не отказываться от созданных тестов, было решено разделить тестовые наборы на две части: Stable test set Unstable test set

Достоверность получаемого результата Stable set – тесты, выполняемые при каждой сборке приложения. Падение каждого такого теста означает наличие ошибки в приложении (в крайнем случае – необходимости актуализировать тест) Unstable set – тесты, исключенные из набора из-за ложных результатов, обычно из-за ошибок системы автоматизации. По мере исправления ошибок, тесты перемещаются в основной набор

Достоверность получаемого результата В случае падения теста из-за проблемы с самом тесте, тест быстро актуализируется (до следующей сборки). В крайнем случае, если требуется больше времени для обновления теста, он перемещается в unstable set. Тесты из «нестабильного» набора необходимо выполнять вручную

Итог организации тестового набора На основе сценариев действий пользователя создана база автоматизированных тестов для покрытия основной функциональности приложения. Благодаря небольшим размерам тестов, принципу «1 тест на 1 тестовый случай» и выделенным в отдельный файл предусловиям, при падении теста: –легко локализовать участок функциональности даже при просмотре отчета о результатах. Шаги, которые привели к ошибке, легко воспроизвести вручную –результат одного теста не влияет на результаты последующих тестов

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

Спасибо за внимание!