Автоматизированное тестирование Области применения Потенциально практически

Автоматизированное тестирование

Области применения ● Потенциально практически любой тест может быть автоматизирован, но не все тесты должны быть автоматизированы! ● Автоматизировать можно и нужно только то, что автоматизации требует, а не функциональные модули где автоматизацию можно применить ● Регрессионное тестирование ● Приемочное тестирование ● Нагрузочное тестирование ● Тестирование в проектах поддержки ● Тестирование приложений без графического интерфейса

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

Цели автоматизации ● Повышения качества тестирования ● Экономия времени затрачиваемого на тестирование ● При этом исключаются ошибки совершаемые человеком ● Увеличивается скорость тестирования ● Увеличивается стоимость тестирования

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

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

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

Преимущества (4) ● Создание надежной системы ● Улучшенное тестирование ● Улучшение регрессионного тестирования ● Повышение эффективности за счет большого числа комбинаций входных данных

Недостатки (1) ● Более квалифицированный персонал – дороже ● Автоматизация – прослойка между тестировщиком и автоматизируемым приложением. Теперь ошибки могут быть и в самом автотесте ● Критичность к устойчивости требований. Т. е. изменение требований влечет изменение сценариев, а значит и автоматизированных скриптов. Поддержка тестовых скриптов в актуальном состоянии – очень дорогое удовольствие

Недостатки (2) ● Критичность оценки времени, затраченного на ручное и автоматизированное тестирование ● Надо преодолеть желание, что все можно автоматизировать. Это не так. Некоторые вещи проще выполнить руками, чем писать код.

Ложные ожидания ● Неограниченные возможности средств тестирования ● Сокращение объема работ по тестирования ● Сокращение сроков работ ● Облегчение использования инструментальных средств ● Универсальное применение автоматизированного тестирования

Мифы автоматизации тестирования (1) ● Автоматизация функционального тестирования применима в любом проекте ● Завышенные требования к команде тестировщиков ● Заниженные оценки трудозатрат на тестирование ● Невозможность проведения автоматизированного тестирования ● Поздний переход на ручное тестирование ● Детальный анализ целесообразности автоматизации тестирования

Мифы автоматизации тестирования (2) ● Автоматизация функционального тестирования применима только для регрессионного тестирования: ● Как правило, но не всегда ● Пример, проекты redevelopment ● Нецелесообразность проведения ручного тестирования ● Рост затрат на ручное тестирование ● Детальный анализ целесообразности автоматизации тестирования

Мифы автоматизации тестирования (3) ● Автоматизация функционального тестирования применима только при большом числе раундов тестирования: ● Как правило, но не всегда ● Например, проекты mission-critical ● Невозможность проведения ручного тестирования ● Рост затрат на ручное тестирование ● Детальный анализ целесообразности автоматизации тестирования

Мифы автоматизации тестирования (4) ● Раннее проведение нагрузочного тестирования ● Исправление функциональных дефектов, как правило, вызывает перезапись и повторный прогон нагрузочных скриптов ● Как правило, но не всегда ● Пример: нагрузочное тестирование прототипа ● Необходимость выделения ресурсов для повторного проведения нагрузочного тестирования ● Детальное планирование момента проведения нагрузочного тестирования

Мифы автоматизации тестирования (5) ● Неадекватная модель нагрузки ● Ролей (кто работает в системе) ● Характеристических сценариев ( что делает) ● Профилей (доля и частота) ● Не соответствует бизнесу заказчика ● Неадекватные результаты нагрузочного тестирования ● Несоответствие ожиданиям заказчика ● Согласование модели нагрузки с заказчиком

Мифы об автоматизированном тестировании «В автоматизированном тестировании всё выполняется само» ‒ ‒ Выбор скриптов для запуска Подготовка тестовых данных Собственно запуск скриптов Анализ результатов

Мифы об автоматизированном тестировании «Автоматизация решает проблему с нехваткой ресурсов» Нагрузка перераспределяется с тестировщиков на программистов, что ещё больше замедляет проект. Тестировщики изучают автоматизацию – замедление ручного тестирования.

Мифы об автоматизированном тестировании «Автоматизация позволяет найти больше ошибок» «при любом виде автоматизированного тестирования находится не более 30% ошибок в самом удачном случае. И только при конфигурационном тестировании можно найти до 80% от общего числа ошибок. » Канер, Бах, Петтикорд • Большее покрытие кода; • Тест не будет пропущен; • Тесты содержат одни и те же шаги; • Ошибки в основном находятся при создании скрипта; • Скрипты не позволяют отклонений; • Скрипты также могут содержать ошибки.

Мифы об автоматизированном тестировании «Чем больше автотестов, тем лучше» Не всё можно заавтоматизировать Больше тестов — больше времени на их выполнение, больше времени на их поддержку.

Стратегия автоматизации тестирования ● Определение цели ● Определение видов тестирования, для автоматизации ● Определение областей функциональности системы для автоматизации ● Обоснование выбора инструмента автоматизации тестирования ● Управление конфигурацией, build management, управление средой тестирования (test environment) ● Критерии отбора тест-кейсов для автоматизации ● Описание процессов и процедур автоматизации ● Требования к Test Automation Framework и, возможно, его краткое описание ● Способ расчёта трудоемкости разработки и поддержки тестов для составления плана и расчёта эффекта от автоматизации ● Оценка эффективности автоматизации

Оценка трудозатрат на проведение автоматизации ● Общее количество автоматизируемых тестовых сценариев и их сложность ● Среднее число GUI объектов ● Среднее число verification points ● Среднее число параметров (например, входные переменные)

Оценка трудозатрат на проведение автоматизации ● Уточнить сложность автоматизации: ● Уточнить процент GUI-объектов, свойства которых не распознаются через стандартные методы ● Часто ли изменяются/дорабатываются участки функциональности, для которой осуществляется автоматизация? ●…

Оценка трудозатрат на проведение автоматизации ● Дополнительные факторы: ● Опыт инженера автоматизатора ● Трудозатраты на планирование работ по автоматизации ● Трудозатраты на подготовку тестовых данных ● Трудозатраты на разработку автоматизированных скриптов ● Сложность автоматизируемой системы

Простая подсказка – решение в двух вопросах ● Является ли сценарий автоматизируемым? 1. Да, при небольших затратах 2. Да, потребуется существенные затраты 3. Нет, сценарий невозможно автоматизировать ● Насколько важным является данный сценарий? 1. Требуется проверять его при любых обстоятельствах 2. Надо регулярно проверять 3. Нужно проверить один раз ● Варианты ответов: ▪ 1 -1 – автоматизируйте ▪ 1 -2 или 2 -1 рекомендуется автоматизировать ▪ 2 -2 стоит сильно подумать надо ли вкладывать средства в автоматизацию ▪ 3 -* или *-3 нецелесообразно

Эффективность автоматизации

Эффективность автоматизации На самом деле сравнивать запуски автоматизированных тестов и их ручное выполнение некорректно. ● 5 запусков автотестов в неделю — это не в 5 раз эффективнее, чем одно прохождение тестов вручную. ● В ручных тестах всегда есть вариативность. Но это лучше, чем ничего.

Эффективность автоматизации ● ROI - return on investment коэффициент окупаемости инвестиций. Этот показатель является одним из основных способов измерения эффективности вложений. ● ROI = Прибыль / Затраты ● ROI = Экономия / Затраты ● ROI = 1 все нормально, чистая прибыль. Чем выше показатель — тем лучше. Минусовое значение говорит о том, что вы в убытке.

Эффективность автоматизации ● ROI автоматизации = ( X – Y) / Y; ● Где: X — время на ручное тестирование. Y — время на выполнение авто-тестов. ● Вначале – прогноз.

Рассчет ROI ● Тест прогоняется тестировщиком за 10 минут ● Тест надо гонять 2 раза в неделю ● До релиза 3 месяца ● Автоматизация теста – 4 часа ● Анализ результатов автотеста – 5 минут

Пример расчёта ROI ● ● ● Тест прогоняется тестировщиком за 10 минут Тест надо гонять 2 раза в неделю До релиза 3 месяца Автоматизация теста – 4 часа Анализ результатов автотеста – 5 минут ● ● Сэкономили = 2*3*4*10 = 240 минут Потратили = 4*60 +2*3*4*5 = 360 минут ROI = 66% Прибыль = -120 минут

Эффективность автоматизации

Когда стоит автоматизировать ● Без автоматизации не обойтись ● Миграция большого объема данных ● Поведение системы при стрессовой нагрузке ● Тестировать стоит устойчивую к изменениям тестовую область ● Проекты поддержки

Когда стоит автоматизировать ● Планируется большое количество итерации тестирования ● Регрессионное тестирование каждый раз увеличивается (Критичным является объем регресса в 4 -5 раз превышающий объемы тестирования новой функциональности) ● При ресурсном конфликте в тестировании в обозримом будущем (баланс Dev/Test отражается на качестве продукта)

Что автоматизировать? ● Виды тестов хорошо поддающихся дрессировке автоматизации: ● Приемочные ● Рутинные ● Тестирование интерфейсов на соответствие стандартам ● Конфигурационное тестирование ● Тестирование с помощью различных вариаций метода «Monkey Testing» ● Функциональные тесты и Model-Based Testing ● Тестирование отчетов (не графических)

Что автоматизировать? ● Труднодоступные места в системе (бэкенд процессы, логирование файлов, запись в БД) ● Часто используемая функциональность, риски от ошибок в которой достаточно высоки. Автоматизировав проверку критической функциональности, можно гарантировать быстрое нахождение ошибок, а значит и быстрое их решение. ● Валидационные сообщения (Автоматизировать заполнение полей не корректными данными и проверку на появление той или иной валидации) ● Длинные end-to-end сценарии ● Проверка данных, требующих точных математических расчетов ● Проверка правильности поиска данных

А что ещё можно тестировать? ● API ● Приложения командной строки ● Web-приложения через HTTP POST, GET запросы

Тестирование производительности Пожалуй, единственный вид тестирования, который всегда автоматизируется. ● Нагрузочное ● Стресс ● Стабильности

Автоматизация процесса тестирования Можно автоматизировать не только выполнение тестов, но и другие тестовые активности: ● Подготовка входных данных; ● Создание отчетов; ● Подготовка тестовых окружений; ● …. .

Принципы внедрения автоматизации ● Раннее планирование тестирования с точными оценками ● Рентабельность автоматизации ● Стоимость инструмента – вложение денег ● Разработка неавтоматизированных версий тестов ● Если время разработки автотеста в 10 -12 раз превышает время ручного теста, то автоматизация не оправдана ● Четкое формулирование тестового сценария ● С соблюдением условий атомарности и целостности ● Тестирование автоматических тестов ->

Мантры автоматизатора ● ЗАЧЕМ ● ЧТО ● КАК ● Надежность ● Скорость ● Качество

Процесс разработки Подходы к автотестам зависят от процессов разработки ● Фазы RUP (Rational Unified Process) ● Inception phase – выбор инструмента автоматизации, в зависимости от которого решается будут ли использоваться уже готовые наработки (фреймворки) или же все будет написано “с нуля” ● Elaboration phase – написание тестов на основную архитектуру (в дальнейшем эти тесты будут использоваться для приема билда) ● Construction phase – более детальная автоматизация: критическая функциональность, проверка регрессий, end -to-end сценарии ● Transition phase – подготовка тестов к передаче заказчику (если это требуется)

Выбор инструмента (пример) ● Распознавание элементов управления в приложении ● Сколько времени требуется на поддержку скриптов ● Запись теста, оценка времени на изменение. При больших числах – инструмент не оптимален. В реальности все будет хуже. ● Удобство для написания новых скриптов ● Поддержка ООП ● Читаемость кода ● Удобная среда разработки для рефакторинга

Выбор инструмента ● «Пилотный» проект ● Сравнить несколько инструментов в столбик за и против ● На этапе выбора редко получается предвидеть все случаи использования библиотеки, поэтому сделать "100% правильный выбор" за разумное время практически невозможно. ● Новые технологии внедрять на некритичных проектах

Чем чреват выбор неподходящего инструмента? ● Непрерывными «допиливаниями» изначально неподходящей среды ● Неоправданными трудозатратами ● «Ментальными ловушками» и неготовностью к смене инструмента

Отбор тестов ● Стабильные ● Повторяющиеся ● Часто повторяющиеся ● Атомарные ● Легко автоматизируемые ● Окупаемые

Когда не стоит использовать ● Краткосрочный проект ● Малое количество раундов тестирование в плане ● Будет редизайн системы ● Доработка/исправление тестов займет больше или столько же времени, чем написание заново ● Высока сложность теста для автоматизации ● Разработать, а потом сопровождать будет дороже, чем тестировать каждый раз вручную

Атоматизаторы – кто они? ● Manual tester ● Automation Testers ● Developer ● Software Engineers in Test ● Написанием тестов должны заниматься «специально обученные люди» (Software Automation Testers) ● Тест-дизайн и автоматизация тестов – очень разные задачи

Автоматизированное тестирование Ко д Модульно е GU I Функционально е Нефунк ц. Производительнос ти Конфигурационное

Автоматизированное тестирование Ко д Модульно е Unit test GU I Функционально е Componen t Big testing Нефунк ц. Производительнос ти Конфигурационное

Автоматизация внутри и снаружи ● Unit Tests Layer ● Functional Tests Layer (Non-UI) ● GUI Tests Layer ● Используйте все!

Соотношения объема тестов

Unit Test layer Тестирование отдельных модулей (компонентов) программного обеспечения Обычно выполняется разработчиками на уровне кода

$Шаблон Unit test [Test] public void Test_$METHOD_NAME$() { //arrange //act //assert Assert. Fail("Not implemented");$

Шаблон Unit test [Test] public void Test_$METHOD_NAME$() { //arrange //act //assert Assert. Fail("Not implemented"); }

Functional Test Layer non-ui ● Специальные методы для доступа минуя пользовательский интерфейс

● Протоколирование исполняемого кода во время тестирования

Управляющий граф программы Граф G(V, A), Где V(V 1, … Vm) – множеств вершин(операторов), A(A 1, … An)– множество дуг(управлений), соединяющих операторы-вершины

1 УГП 2 3 4 5 6 7

Пути и ветви ● Путь – последовательность вершин и дуг УГП, в которой любая дуга выходит из вершины Vi и приходит в вершину Vj , например: (3, 4, 7), (3, 4, 5, 6), (3, 4, 5, 6) ● Ветвь – путь (V 1, V 2, … Vk), где V 1 - либо первый, либо условный оператор программы, Vk - либо условный оператор, либо оператор выхода из программы, а все остальные операторы – безусловные, например: (3, 4) (4, 5, 6, 4) (4, 7). ● Пути, различающиеся хотя бы числом прохождений цикла– разные пути, поэтому число путей в программе может быть не ограничено. Ветви – линейные участки программы, их конечное число.

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

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

Критерий тестирования путей Условие критерия тестирования путей— набор тестов в совокупности должен обеспечить прохождение каждого пути не менее 1 раза. Если программа содержит цикл (в особенности с неявно заданным числом итераций), то число итераций ограничивается константой (часто — 2, или числом классов выходных путей).

GUI-автоматизация ● Выполняется тестировщиком ● Функциональное ● Чёрного ящика

GUI-автоматизация ● Автоматизация регрессионного тестирования ● Прогоняем одни и те же тесты после изменений для валидации продукта ● Автоматизация конфигурационного тестирования ● Прогоняем одни и те же тесты в разных окружениях, чтобы убедиться, что продукт везде работает одинаково.

GUI-автоматизация регрессии Цели: устраняет риски, что: ● Исправление не устранило баг; ● Снова появился старый баг; ● Исправление повлекло за собой новый баг. Плюсы: ● Повышение уверенности в качестве продукта; Слепые пятна: ● Всё, что не покрыто в тестовой сессии; ● Поддержка тестов может быть весьма дорогой.

GUI-автоматизация регрессии Обычный сценарий автоматизации регрессии: ● Продумать и создать тест ● Запустить и оценить результат ● Если проявляется баг → создать отчёт и проверить после обновления ● Если тест прошёл → сохранить результат выполнения ● В дальнейших тестовых прогонах запускать тест и сравнивать с сохранённым результатом ● Если результат не совпал с сохранённым → баг

Высокая стоимость GUIавтоматизации ● Написание автоматизированных тестов, по различным подсчетам, от 3 до 10 раз дороже, чем создание и прогон «ручных» тестов. ● Зачастую бывает необходимо увеличить команду тестировщиков ● Для автоматизации требуется более высокая квалификация тестировщиков ● Автоматизация может затянуть тестирование

Поддержка GUI-автоматизации ● Не все инструменты автоматизации подойдут: технологии, языки — надо подстраиваться; ● Изменения интерфейса → поломка тестов: ● Надо ждать, пока стабилизируется интерфейс; ● Поначалу много ложных падений тестов из-за незначительных косметических изменений; ● Ложные срабатывания оказываются дорогими: ● Каждый случай надо изучить; ● Надо поправить тест или убрать его, если обнаружилась проблема теста/инструмента ● Реальная польза получается только в следующем релизе, а не в текущем.

Автотесты - Recording ● Блокнот ● ● ● Напишем строку “Test string”, затем нажмем Enter и введем текст “Second string” Выберем пункт меню Правка – Выделить все, затем Правка – Удалить, затем Правка – отменить Щелкнем правой кнопкой мыши по тексту и из контекстного меню выберем пункт “Копировать” ● function Test 1() { var w 1; var w 2; w 1 = Sys. Process(“notepad”). Window(“Notepad”, “*”); w 2 = w 1. Window(“Edit”); w 2. Click(20, 12); w 2. Keys(“Test string[Enter]Second string”); w 1. Main. Menu. Click(“Edit|Select All”); w 1. Main. Menu. Click(“Edit|Delete”); w 1. Main. Menu. Click(“Edit|Undo”); w 2. Click. R(19, 15); w 2. Popup. Menu. Click(“Copy”); }

Автотесты – браузер объектов

Организация автотестов ● Выделяем классы форм (окон, функциональных модулей) Application. start. New. Instance(); Login. Form login = (Login. Form) Application. get. Current. Form(); Main. Form main = login("user", "password"); login = main. logout(); ● Общие методы взаимодействия с элементами выносим из классов форм в общий супер класс ● Выносим данные теста в файл ● Создаем кейворды LOGIN. execute(new String[] {"user", "password"}); CREATE_NEW_USER. execute(new String[] {"user 2", "password 2"}); . . .

Эффективность автоматизации

Организация автотестов ● Идентификация объектов в начале, или в отдельном классе. ● Все как в обычных тестах ● Precondition (Инициализация) ● Steps ● Post Condition (Очистка, закрытие) ● Общая библиотека по обработке ошибок ● Pre. Condition. Exception ● Test. Case. Exception ● Post. Condition. Exception

Организация автотестов ● Разделение ● Базовые операции создания/чтения/изменения/удаления сущностей (так называемые CRUD операции - Create / Read / Update / Delete) ● Пример: создание, удаление, просмотр и изменение данных о пользователе ● Типовые сценарии использования приложения, либо отдельные действия ● Пример: пользователь заходит на почтовый сайт, листает письма, просматривает новые, пишет и отправляет письмо, выходит с сайта. Это так называемый end-toend сценарий, который проверяет совокупность действий. Именно такие сценарии, позволяют вернуть систему в состояние, максимально близкое к исходному, а значит – минимально влияющее на другие тесты ● Интерфейсы, работы с файлами и другие моменты, неудобные для тестирования вручную копирование/создание/удаление/проверка существования файлов архивация/разархивация файлов и каталогов копирование файлов с/на целевую файловую систему поиск в файлах по паттерну (логи) / изменение содержимого текстовых файлов (конфиги) ● выполнение команд на удаленной системе и получение стандартного вывода (stdout) и ошибок (errout) от них ● ●

Инфраструктура автоматизации ● Система автозапуска ● Автоматически и вручную ● Комбинации тестов для запуска ● По выходу сборки или по желанию пользователя ● Система подготовки стендов ● Для автоматизированного тестирования и для воспроизведения дефектов ● Возврат системы в «чистое» состояние

Инфраструктура автоматизации ● Система автоматической отчётности ● Для оценки статуса ● Для сохранения истории ● Для доступа к логам ● Для принятия оперативных решений ● Интегрированная с TMS

Инфраструктура автоматизации ● Система автоматической отчётности ● Отчеты ● ● ● ● Время начала выполнения теста Время завершения выполнения теста Результат (passed / failed / blocked) Полный лог выполнения теста и крайне желательно - с метками времени для каждой записи в логе Номер билда для которого проводился тест Конфигурация (аппаратная платформа + настройки) на которой проводился тест. (Актуально только если используется несколько конфигураций) Скриншот (в случае отличного от passed результата) ● Хранение ● В БД ● Для небольших подойдет и файловая система ● Рассылка ● Менеджеру проекта ● Менеджеру по тестированию ● Тестлиду

Непрерывная разработка

Жизненный цикл в CI

Pipeline

Code commit

Build

Acceptance Test

Performance Test

Stability Test

Manual Test

Production