/ Процессы Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Архитектура Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Vision (Концепция) Проектное решение ESB Микросервисы и service mesh HTTP/REST RPC DDD Анализ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Сервисы Тестирование Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Тестирование требований Тест-анализ и тест дизайн Тест план Интеграционное, API, E2E Метрики качества Автотесты Selenium XPATH Нагрузочное Данные Ресурсы MDM Big data Об информации SQL intro MongoDB intro Библиотека Системная инженерия Станислав Лем Экстраполяция в будущее Политэкономия Сознание, интеллект Gaming Archolos Morrowind Bannerlord Serf City X-COM: TFTD

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

Базовое

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

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

Интересное

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

Cucumber

Coded UI

Подходы
Существуют следующие основные подходы:
  • тестирование на уровне кода — модульное (unit testing). Это тестирование одного модуля кода (обычно это одна функция или один класс в случае ООП-кода) в изолированном окружении. Это значит, что если код использует какие-то сторонние классы, то вместо них подсовываются классы-заглушки (моки и стабы). Код не должен работать с сетью (и внешними серверами), файлами, базой данных, иначе мы тестируем не саму функцию или класс, а еще и диск, базу, и т.д.
  • тестирование через API. API — это набор функций, которые можно вызывать, чтобы получить какие-то данные.
    Например, у Яндекс.Карт есть API геокодера. Отправив к нему запрос с географическим адресом, ты можешь получить координаты точки (и наоборот), а у Центробанка есть API, которое возвращает официальный курс валют в заданный день.
    Если у твоего приложения есть API, то можно тестировать его, посылая заранее подготовленные запросы и сравнивая пришедший ответ с ожидаемым.
    Естественно, API не ограничиваются лишь web и HTTP (REST)!
  • тестирование через пользовательский интерфейс — 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. Разметка автотестов (аннотация) по @Description, @Tag, @Category, @Feature, @Types, @Step и прочему. Не экономьте на этом.
    Такая группировка автотестов позволяет производить запуск не всех 100500 тестов при каждом чихе, а именно тех, которые связаны с изменённой/добавленной функциональностью.
    Также это позволяет производить трассировку между тестами и функциональностью.
  2. Кошерный автотест в случае PASS (успешного прохождения) "убирает за собой", удаляя за собой созданное в процессе прохождения, а также возвращая настройки ПО тестовом стенде в состояние, максимально близкое к исходному. Если, конечно, настройки тестируемых приложений менялись в ходе теста, если в ходе теста создавались/изменялись объекты данных.
    Если автотест упал, то чистить за собой ему не надо, потому что его данные потребуются для расследования причины падения.
    Также, хорошей идеей может быть создание cleanup-скрипта, который по расписанию, например, ранним утром каждый день, чистит данные, которые были созданы за предыдущий период время упавшими тестами; предполагается, что за 1-2 дня все упавшие автотесты были расследованы и их данные нам больше не нужны).
  3. Распараллеливание. Рекомендуется ВСЕГДА распараллеливать запуск (групп) тестов, КРОМЕ случаев, когда есть мешающие друг-другу тесты:
    • работающие (тестирующие) с одним и тем же объектом сущности;
    • действующие от имени одной и той же учётной записи, но с назначением в процессе выполнения ей разных ролей/прав/доступов;
    • перед / в процессе выполнения меняющие настройки ПО на тестовом стенде, влияющие на функции, используемые в другом тесте;
  4. Скрипт, запускаемый по расписанию 1+ раз в сутки, поддерживающий тестовый стенд в надлежащем состоянии по части предусловий для запуска тестов:
    • обеспечение наличия в БД нужных объектов тестируемых сущностей с определёнными именами и свойствами
    • обеспечение наличия учётных записей с нужным именем/логином и нужными для тестов ролями / правами / permissions
    • обеспечение необходимых преднастроек ПО

Автотесты пишутся на фреймворке 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://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://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