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

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

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

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

Сколько тестов надо? Структурный критерий выбора тестов на основе структуры исходного кода приложения.

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

УГП

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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