# ПРОЦЕССЫ Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление АРХИТЕКТУРА Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Проектное решение ESB Микросервисы и service mesh HTTP/REST RPC DDD АНАЛИЗ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Vision (Концепция) Сервисы DevOps CI/CD/CDP VM и Docker Контракты API Оценка задачи git Frontend Apache Регулярка Linux ТЕСТИРОВАНИЕ Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Тестирование требований Тест-анализ и тест дизайн Интеграционное, API, E2E Тест план Метрики качества Автотесты Selenium XPATH Генератор данных Нагрузочное ДАННЫЕ Ресурсы MDM Big data Об информации SQL intro MongoDB intro БИБЛИОТЕКА Курсы Системная инженерия "Сумма технологии" Экстраполяция в будущее Политэкономия Красивые диаграммы Сознание, интеллект

/ АНАЛИЗ АРХИТЕКТУРА ДАННЫЕ DevOps Gaming Библиотека ПРОЦЕССЫ ТЕСТИРОВАНИЕ: + ТЕСТИРОВАНИЕ + Тестирование требований + Тест-анализ и тест дизайн + Импакт-анализ в тестировании + API, интеграционное и E2E + Тест план + Метрики качества + Android - Автоматизация | Присмотреться к чужому опыту | Подходы | Компания созрела для автотестов? | Что автоматизировать | Общие рекомендации | Java + Maven + Cucumber + Selenium + Selenium WebDriver + XPATH + Генератор случайных данных + Различные расчёты + Безопасность + Нагрузочное
Автоматизация тестирования
latest update of the page: 24-04-2023, 13:46 UTC
Присмотреться к чужому опыту

Базовое

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

Комплексный подход

Интересное

Тестирование в условиях микросервисной архитектуры и Service mesh

Cucumber

Coded UI

Подходы
Существуют следующие основные подходы:
  • тестирование на уровне кода — модульное (unit testing). Это тестирование одного модуля кода (обычно это одна функция или один класс в случае ООП-кода) в изолированном окружении. Это значит, что если код использует какие-то сторонние классы, то вместо них подсовываются классы-заглушки (моки и стабы). Код не должен работать с сетью (и внешними серверами), файлами, базой данных, иначе мы тестируем не саму функцию или класс, а еще и диск, базу, и т.д.
  • тестирование через API. API — это набор функций, которые можно вызывать, чтобы получить какие-то данные.
    Например, у Яндекс.Карт есть API геокодера. Отправив к нему запрос с географическим адресом, ты можешь получить координаты точки (и наоборот), а у Центробанка есть API, которое возвращает официальный курс валют в заданный день.
    Если у твоего приложения есть API, то можно тестировать его, посылая заранее подготовленные запросы и сравнивая пришедший ответ с ожидаемым.
  • тестирование через пользовательский интерфейс — GUI-тестирование. Имитация действий пользователя в браузере с помощью специальных тестовых фреймворков (типа Selenium).
Некоторые инструменты для автоматизированного тестирования:
Компания созрела для автотестов?
Если хочется , то для этого нужно и скиллы ролей
проектирования и разработки автотестов 1. Сначала нужно провести тест-анализ продукта/сервисов — выявить требования, определить процент покрытия их существующими тестами, определить технологический стек, используемый тестируемыми сервисами и их БД. тест-аналитика, лида
2. Определиться с уровнем тестирования: фронт, бэк, UI, API (web REST, web не REST, RPC,...), десктоп/мобильное приложение и т.п. тест-аналитика
3. Определиться каким образом будем тестировать: функциональное, интеграционное, нагрузочное. тест-аналитика
4. Исходя из п.1-3 подобрать ЯП и фреймворк (готовый или создавать самим) для автотестов.
Используем ли Selenium для UI, используем ли Cucumber с его Gherkin. И т.п.
опытного разработчика автотестов, тест-аналитика
5. Для подачи на вход автоматизаторам, требуется, чтобы кто-то составлял тест-кейсы по требованиям. Возможно, это будет тест-аналитик или сами тестировщики.
Требуется удобный инструмент для хранения тест-кейсов (какой-нибудь древний HP ALM, современная Jira-плагин TM4J, что-то ещё.
тест-аналитика, тестировщика
6. Непосредственно разработка автотестов.
Требуется обеспечить разработчиков удобной IDE (платной/бесплатной), исходя из выбранных языков/фреймворков в п.4.
разработчика автотестов
7. Исходя из п.1-3 можно уже сколько и каких сервисов требуется развернуть для тестирования.
Таким образом выходим на технические требования к тестовому стенду (CPU/RAM, OS, будет ли это Openshift и прочее и прочее) и БД на них. Нужны ли в наличии актуальные мобильные устройства для прогона на них автотестов.
Далее происходит обсуждение с ЛПР есть ли бюджет на покрытие этих технических требований, надо ли где-то ужиматься за счёт уменьшения тестового покрытия. Обычный процесс "торговли" за бюджет и поиски компромисса.
встраивания автотестов в CI/CD 8. Выбрать инструмент для CI/CD. Возможно, решено использовать Jenkins как один из самых распространённых, по установке/настройке/решению проблем с которым легко найти ресурсы в Сети.
Определить как будут запускаться job'ы с автотестами, на каких машинах, с какими параметрами, в каком виде мы хотим получать отчёт о тесте (Allure, кастомные виды представлений,...).
Определить на какой машине с какими ресурсами будет размещён выбранный инструмент, какая там будет ролевая модель (кто будет иметь права на запуск/редактирование job'ов).
Если делать это всё без инструмента, т.е. запуск будет производиться вручную или средствами cron в linux или job'ов Windows — то всё равно это требует обсуждения.
любого кто пользовался выбранным инструментом CI/CD
-- разработчика автотестов, администратора, тестировщика...
* методик нагрузочного тестирования,
* разработки и актуализации средств нагрузочного тестирования
(сценарии и скрипты НТ
, эмуляторы, скрипты генерации данных
, скрипты анализа результатов),
9. После п.1 провести тест-анализ сервисов в разрезе именно нагрузочного тестирования, в т.ч. получение профия нагрузки с ПРОДа, опрос администраторов, поддерживающих ПРОД и т.п.
Отталкиваясь от требований, определить что следует нагружать и каким образом, какими способами будем измерять, какие метрики будем использовать.
тест-аналитика, тестировщика-нагрузочника
10. Определить какие технические ресурсы нам потребуются для реализации задуманного по НТ.
Провести обсуждение с ЛПР есть ли бюджет на такие ресурсы, надо ли где-то ужиматься за счёт уменьшения тестового покрытия. Обычный процесс "торговли" за бюджет и поиски компромисса.
тестировщика-нагрузочника, архитектора, тест-аналитика, лида
11. На основании тест-анализа в разрезе НТ из п.9 спроектировать сценарии НТ, определить необходимость скриптов анализа данных, учесть их в сценариях. тестировщика-нагрузочника, тест-аналитика
12. На основании сценариев НТ из п.9 определяем необходимость подготовки данных в БД. Какие они должны быть. Нужно ли их подготавливать отдельными скриптами или же можем себе позволить репликацию с БД прода полностью или частично. тестировщика-нагрузочника, тестировщика данных, тест-аналитика
13. На основании тест-анализа из п.1 и п.9 определяем нужны ли нам заглушки, моки, синтетические тестовые приложения (имитирующие поведение задействованных в сценарии сервисов) тестировщика-нагрузочника, разработчика автотестов, тест-аналитика
14. Непосредственно разработка скриптов НТ. тестировщика-нагрузочника, разработчика автотестов
15. На основании данных из п.10 и п.12 провести обсуждение с ЛПР есть ли бюджет на такие ресурсы, надо ли где-то ужиматься за счёт уменьшения тестового покрытия. Обычный процесс "торговли" за бюджет и поиски компромисса. тестировщика-нагрузочника, архитектора, тест-аналитика, лида.
поддержки разработанных автотестов - разработчика автотестов и немного тест-аналитика.
Что автоматизировать

Какие тест-кейсы стоит автоматизировать в первую очередь

  • покрывающие самые критические для Бизнеса бизнес-процессы и юзкейсы
  • часто требующиеся к (пере)прохождению
  • которые слишком сложно и неудобно выполнять вручную
    , например, содержащие проверку данных, требующих точных математических и логических расчётов (банковское, бухгалтерское, аналитическое ПО)
    или проверку структуры многочисленных файлов/сообщений, созданных системой.
  • требующие много времени на ручное прохождение
    , например по проверке корректности отображаемых результатов поиска данных в ответ на запрос по данным
    или проверяющие длинные бизнес-процессы, требующие действий под различными пользовательскими ролями на многочисленных формах UI и в различных системах.
В общем случае, автоматизируют регрессионные тест-кейсы и API-тесты.

Какие тест-кейсы НЕ СТОИТ автоматизировать

  • разработанные недавно и еще не проверенные вручную
  • требования для которых постоянно меняются
  • разработанные для специфической задачи
Общие рекомендации

  1. Разметка автотестов по @Tag, @Category, @Feature, @Types, @Step и прочему. Не экономьте на этом.
    Такая группировка автотестов позволяет производить запуск не всех 100500 тестов при каждом чихе, а именно тех, которые связаны с изменённой/добавленной функциональностью.
    Также это позволяет производить трассировку между тестами и функциональностью.
  2. Кошерный автотест в случае PASS (успешного прохождения) "убирает за собой", возвращая данные и настройки тестового стенда в состояние, максимально близкое к исходному. Если, конечно, настройки тестируемых приложений менялись в ходе теста, если в ходе теста создавались/изменялись объекты данных.
    Если автотест упал, то чистить за собой ему не надо, потому что его данные потребуются для расследования причины падения.
    Также, хорошей идеей может быть создание cleanup-скрипта, который по расписанию, например, ранним утром каждый день, чистит данные, которые были созданы за предыдущий период время упавшими тестами; предполагается, что за 1-2 дня все упавшие автотесты были расследованы и их данные нам больше не нужны).
  3. Здесь про must have
  4. TBD

Автотесты пишутся на фреймворке XXX.
Принцип работы автотестов:

  1. Файлы проекта укладываются в контейнер с указанием запускающего файла start.sh и публикуются в хранилище YYY.
  2. При запуске тестов из Jenkins, контейнер устанавливается в Openshift/k8s и происходит автоматический запуска скрипта start.sh
  3. все файлы из контейнера копируются в папку /tmp/tests
  4. запускается сборка проекта Maven'ом с запуском тестов
  5. по завершению сборки и тестов формируется allure-отчёт

Java + Maven + Cucumber + Selenium

Создадим примитивные helloworld GUI-тест и API-тест с использованием Java, Maven, Cucumber (+JUnit) и Selenium.
Нижеизложенное выполнялось под Windows 10 и Intellij IDEA Ultimate 2020.1.

Установка

  1. Установить JRE (Java Run-Time Environment) = https://www.java.com/ru/download/
    Посредством консоли убедиться что Java установлена, например: > java -version java version "1.8.0_261" Java(TM) SE Runtime Environment (build 1.8.0_261-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12, mixed mode)
  2. Установить JDK: SE или EE.
    Ссылки для Java Standard Edition:
    1. Java SE download = https://www.oracle.com/java/technologies/javase-downloads.html
    2. JDK installation guide = https://docs.oracle.com/en/java/javase/14/install/overview-jdk-installation.html
  3. Настроить системные Переменные среды (Environment variables) для Java:
    1. JAVA_HOME = [путь установленного JDK, например C:\Program Files\Java\jdk-14.0.2]
    2. в переменную Path добавить путь %JAVA_HOME%\bin
  4. Установить Maven:
    1. download = https://maven.apache.org/download.cgi
    2. installation guide = https://maven.apache.org/install.html
    3. installation guide = https://mkyong.com/maven/how-to-install-maven-in-windows/
  5. Настроить системные Переменные среды (Environment variables) для Java:
    1. MAVEN_HOME = [путь установленного Maven, например C:\Program Files\apache-maven-3.6.3].
    2. в переменную Path добавить путь %MAVEN_HOME%\bin
    Проверить корректность установки и настройки можно в cmd > mvn -v Apache Maven 3.6.3 Maven home: C:\Program Files\apache-maven-3.6.3\bin\.. Java version: 14.0.2, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk-14.0.2 Default locale: ru_RU, platform encoding: Cp1251 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
  6. Установить Intellij IDEA

Настройка IDEA, создание Проекта, настройка dependencies

  1. Настроить Intellij IDEA на работу с Maven.
    1. Меню File/Config -> Settings -> Build, Execution, Deployment -> Build Tools -> Maven. Maven home directory = путь до каталога с Мавен
    2. .. Maven->Importing. JDK for importer = Use JAVA_HOME
    3. .. Maven->Runner. JRE = Use JAVA_HOME
    4. OK
  2. Создание Проекта:
    1. +Create New Proejct
    2. Maven
    3. Archetype = org.apache.maven.archetypes:maven-archetype-quickstart
    4. Project SDK = [путь до JDK]
    5. Next
    6. Заполняем Name, выбираем Location
    7. Заполняем GroupId и ArtifactId, например = org.tests и helloworld
    8. Finish
  3. (дождались когда IDEA подтянула всё что нужно и обновила файл pom.xml, добавив блок dependencies)
    Подключить в POM-файл dependency свежего Cucumber (поиск по Maven Central Repository): <dependency> <groupId>io.cucumber</groupId> <artifactId>cucumber-java</artifactId> <version>6.2.2</version> <scope>test</scope> </dependency> Этот модуль сам уже имеет зависимость от модуля cucumber-junit, который имеет зависимость от модуля junit, так что можно их явно самому не указывать в dependency.
  4. Подключить в POM-файл dependency свежего Selenium (поиск по Maven Central Repository): <dependency> <groupId>org.seleniumhq.selenium</groupId> <artifactId>selenium-java</artifactId> <version>3.14.0</version> </dependency>
  5. либо в IDEA либо в консоли в каталоге проекта выполняем
    mvn clean compile
    Произойдёт всё на свете.

Hello world

  1. Структура проекта, создание cucumber-файлов для фич и кода
    TBD
  2. Hello World test
    TBD