'

Организация тестового набора при автоматизированном функциональном тестировании

Понравилась презентация – покажи это...





Слайд 0

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


Слайд 1

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


Слайд 2

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


Слайд 3

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


Слайд 4

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


Слайд 5

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


Слайд 6

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


Слайд 7

Отчет о результатах тестирования Вид страницы с отчетом о результате тестирования: 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


Слайд 8

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


Слайд 9

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


Слайд 10

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


Слайд 11

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


Слайд 12

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


Слайд 13

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


Слайд 14

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


Слайд 15

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


Слайд 16

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


Слайд 17

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


Слайд 18

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


Слайд 19

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


×

HTML:





Ссылка: