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

/ АНАЛИЗ АРХИТЕКТУРА ДАННЫЕ DevOps БИБЛИОТЕКА ПРОЦЕССЫ ТЕСТИРОВАНИЕ: - ТЕСТИРОВАНИЕ - Тестирование требований - Тест-анализ и тест дизайн - Тест план - Метрики качества - Android - Автоматизация | Ресурсы | Основные подходы | Что если компания хочет автотесты | Что автоматизировать | Общие рекомендации | Java + Maven + Cucumber + Selenium - Selenium WebDriver - XPATH - Генератор случайных данных - Различные расчёты - Безопасность - Нагрузочное
Автоматизация тестирования
last update: 02-06-2021, 13:58 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. TBD

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