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

Август 29, 2022

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

Содержание

2. Содержание Кто мы, что и с помощью чего тестируем Цели автоматизации функционального тестирования Проблемы анализа результатов
3. Xored Software Российская компания, созданная с нуля в Новосибирском Академгородке. Занимается созданием средств разработки и продуктов
4. Тестируемое приложение Eclipse Tigerstripe – приложение для моделирования – создания UML диаграмм и кода на их
5. Инструмент тестирования Q7 – приложение для автоматизации функционального тестирования Создано на платформе Eclipse и для тестирования
6. Цели автоматизации тестирования Получение информации о качестве продукта при каждой сборке приложения Сокращение трудозатрат на тестирование
7. Шаги автоматизации тестирования Сформировать базу сценариев работы пользователя с приложением На основе сценариев создать автоматизированные тесты
8. Отчет о результатах тестирования Вид страницы с отчетом о результате тестирования: Test Summary 384 tests in
9. Анализ результатов тестирования При просмотре отчета невозможно указать шаг, который привел к падению теста. В итоге
10. Требования к отдельному тесту Чем меньше тест, тем проще локализовать проблему Необходимо отделить шаги по подготовке
11. Структура теста Precondition – подведение системы к состоянию, пригодному для тестирования Steps (Test) – непосредственное проведение
12. Структура автоматизированного теста Каждый тест обязательно разделяется на 2 части: Context – отдельный скрипт (либо файлы
13. Преимущества Информация о локализации проблемы (и возможном шаге) появляется уже при беглом просмотре отчета Исключаются ошибки
14. Требования к организации тестов Максимальный отказ от ручных тестов Тестовая база для всего приложения Тесты на
15. Достоверность получаемого результата Тесты, которые дают ложный результат из-за проблем инструмента тестирования либо неактуальности самого теста,
16. Достоверность получаемого результата Stable set – тесты, выполняемые при каждой сборке приложения. Падение каждого такого теста
17. Достоверность получаемого результата В случае падения теста из-за проблемы с самом тесте, тест быстро актуализируется (до
18. Итог организации тестового набора На основе сценариев действий пользователя создана база автоматизированных тестов для покрытия основной
19. Итог организации тестового набора Вынесение предусловий в отдельный файл, который можно использовать в нескольких тестах, упрощает
21. Скачать презентацию

Слайд 2

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

анализа результатов тестирования
Требования к отдельному тесту. Запись теста
Требования к организации тестового набора
Достоверность получаемого результата
Итог работы

Слайд 3

Xored Software
Российская компания, созданная с нуля в Новосибирском Академгородке. Занимается созданием

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

Слайд 4

Тестируемое приложение
Eclipse Tigerstripe – приложение для моделирования – создания UML

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

Слайд 5

Инструмент тестирования
Q7 – приложение для автоматизации функционального тестирования
Создано на платформе

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

Слайд 6

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

трудозатрат на тестирование

Слайд 7

Шаги автоматизации тестирования
Сформировать базу сценариев работы пользователя с приложением
На основе сценариев

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

Слайд 8

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

Слайд 9

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

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

Слайд 10

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

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

Слайд 11

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

– непосредственное проведение теста
Post Condition – удаление данных, созданных в процессе выполнения скрипта

Слайд 12

Структура автоматизированного теста
Каждый тест обязательно разделяется на 2 части:
Context – отдельный

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

Слайд 13

Преимущества
Информация о локализации проблемы (и возможном шаге) появляется уже при беглом

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

Слайд 14

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

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

Слайд 15

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

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

Слайд 16

Достоверность получаемого результата
Stable set – тесты, выполняемые при каждой сборке приложения.

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

Слайд 17

Достоверность получаемого результата
В случае падения теста из-за проблемы с самом тесте,

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

Слайд 18

Итог организации тестового набора
На основе сценариев действий пользователя создана база

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

Слайд 19

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

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

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

Содержание

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

Xored SoftwareРоссийская компания, созданная с нуля в Новосибирском Академгородке. Занимается созданием

Тестируемое приложение Eclipse Tigerstripe – приложение для моделирования – создания UML

Инструмент тестированияQ7 – приложение для автоматизации функционального тестирования Создано на платформе

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

Шаги автоматизации тестированияСформировать базу сценариев работы пользователя с приложениемНа основе сценариев

Отчет о результатах тестированияВид страницы с отчетом о результате тестирования:Test Summary384

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

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

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

Структура автоматизированного тестаКаждый тест обязательно разделяется на 2 части:Context – отдельный

ПреимуществаИнформация о локализации проблемы (и возможном шаге) появляется уже при беглом

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

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

Достоверность получаемого результатаStable set – тесты, выполняемые при каждой сборке приложения.

Достоверность получаемого результатаВ случае падения теста из-за проблемы с самом тесте,

Итог организации тестового набора На основе сценариев действий пользователя создана база

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

Похожие презентации