Внедряй, масштабируй: опыт применения автотестов в ВТБ

Наше подразделение создает полностью автоматические пайплайны для вывода новых версий приложений в прод-среду. Разумеется, для этого требуются автоматизированные функциональные тесты. Под катом — история о том, как, начав с тестирования в один поток на локальной машине, мы дошли до многопоточного запуска автотестов на Selenoid в пайплайне сборки с Allure-отчетом на GitLab pages и в итоге получили крутой инструмент для автоматизации, который смогут использовать будущие команды.

29e991c13a89c4069a46fb4ed6965ec0.jpg

С чего мы начинали


Чтобы реализовать автотесты и встроить их в пайплайн, нам требовался фреймворк для автоматизации, который можно гибко менять под наши потребности. В идеале хотелось получить единый стандарт для движка автотестирования, приспособленный под встраивание автотестов в пайплайн. Для реализации мы выбрали следующие технологии:

  • Java,
  • Maven,
  • Selenium,
  • Cucumber+JUNIT 4,
  • Allure,
  • GitLab.


252ac0c39f01083634120a48b2a96952.png

Почему именно такой набор? Java — один из самых популярных языков для автотестов, к тому же им владеют все члены команды. Selenium — очевидное решение. Cucumber же, помимо прочего, должен был повысить доверие к результатам автотестов со стороны подразделений, занимающихся ручным тестированием.

Однопоточные тесты


Чтобы не изобретать велосипед, за основу фреймворка мы взяли наработки с различных репозиториев на GitHub и адаптировали их под себя. Создали репозиторий для главной библиотеки с ядром фреймворка автотестов и репозиторий с Gold-примером реализации автотестов на нашем ядре. Каждая команда должна была брать Gold-образ и разрабатывать в нем тесты, адаптируя под свой проект. Развернули в банке GitLab-CI, на котором настроили:

  • ежедневные запуски всех написанных автотестов по каждому проекту;
  • запуски в пайплайне сборки.


Сначала тестов было мало, и они шли в один поток. Однопоточный запуск на Windows-раннере GitLab нас вполне устраивал: тесты очень незначительно нагружали тестовый стенд и почти не утилизировали ресурсы.

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

  • мы не могли убедиться в том, что тесты стабильны;
  • тесты, которые проходили по несколько прогонов подряд на локальной машине, иногда падали в CI.


Пример настройки автотестов:


	

    	
org.apache.maven.plugins
    	
maven-surefire-plugin
    	
2.20
    	

        	
${skipTests}
        	
false
        	

            	
-javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
            	
-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"
        	

    	

	
    
        	

            	
org.aspectj
            	
aspectjweaver
            	
${aspectj.version}
        	

    	

	

	

    	
io.qameta.allure
    	
allure-maven
    	
2.9
	



 8641b823bd4b8e0cd4f55ea6f026c6fd.png
Пример Allure-отчета

 38723c761d476c0f5d7536d22529d614.png
Нагрузка на раннер во время тестов (8 ядер, 8 ГБ ОЗУ, 1 поток)
 
Плюсы однопоточных тестов:

  • легко настроить и запустить;
  • запуски в CI практически не отличаются от локальных запусков;
  • тесты не аффектят друг друга;
  • минимальные требования к ресурсам раннера.


Минусы однопоточных тестов:

  • очень долго выполняются;
  • долгая стабилизация тестов;
  • неэффективное использование ресурсов раннера, крайне низкая утилизация.


Тесты на форках JVM


Поскольку при реализации базового фреймворка мы не позаботились о thread-safe коде, самым очевидным способом параллельного запуска стал cucumber-jvm-parallel-plugin для Maven. Плагин легко настроить, но для корректной параллельной работы автотесты нужно запускать в отдельных браузерах. Делать нечего, пришлось использовать Selenoid.

Selenoid-сервер подняли на машине с 32 ядрами и 24 ГБ ОЗУ. Лимит установили в 48 браузеров — 1,5 потока на ядро и порядка 400 МБ ОЗУ. В итоге время тестов сократилось с трех часов до 40 минут. Ускорение прогонов помогло решить проблему стабилизации: теперь мы могли быстро прогонять новые автотесты 20–30 раз, пока не убедимся, что они выполняются стабильно.
Первым недостатком решения стала высокая утилизация ресурсов раннеров при небольшом количестве параллельных потоков: на 4 ядрах и 8 ГБ ОЗУ тесты работали стабильно не более чем в 6 потоков. Второй минус: плагин генерирует классы-раннеры для каждого сценария, сколько бы их ни запускалось.

Важно! Не прокидывайте переменную с тегами в argLine, например, так:

-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"
…
Mvn –DTAGS="@smoke"


Если передавать тег таким образом, плагин будет генерировать раннеры для всех тестов, то есть пытаться запустить все тесты, пропуская их сразу после запуска и создавая при этом множество форков JVM.

Правильно переменную с тегом прокидывать в tags в настройках плагина, см. пример ниже. В других проверенных нами способах возникают проблемы с подключением плагина Allure.

Пример времени прогона 6 коротких тестов с неправильной настройкой:

[INFO] Total time: 03:17 min


Пример времени прогона тестов, если напрямую передавать тег в mvn… –Dcucumber.options:

[INFO] Total time: 44.467 s


Пример настройки автотестов:


	

    	
parallel
    	

        	

            	

                	
com.github.temyers
                	
cucumber-jvm-parallel-plugin
                	
5.0.0
                	

                    	

                        	
generateRunners
                        	
generate-test-sources
                        	

                            	
generateRunners
                        	

                        	

                	
            
                            	
${TAGS}
                            	

                            	

                                	
stepdefs
                            	

                        	

     	
               
                	

    	
        
            	

                	
org.apache.maven.plugins
                	
maven-surefire-plugin
        	
        2.21.0
                	

                    	
12
                    	
false
                    	
**/*IT.class
                   	
 false
                    	

                    	

  	
 -javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar" -Dcucumber.options="--plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm TagPFAllureReporter --plugin pretty"
                    	

                	

                	

                    	

                        	
org.aspectj
                        	
aspectjweaver
                        	
${aspectj.version}
                 	
   
                	

         	
   
        	

    	

	


82ffa3c04c02ca5be5e47fdfe8c9b052.png
Пример Allure-отчета (самый нестабильный тест, 4 рерана)

07570c0ceade310c1afdceb8e0daf50f.pngНагрузка раннера во время тестов (8 ядер, 8 ГБ ОЗУ, 12 потоков)
 
Плюсы:

  • простая настройка — нужно лишь добавить плагин;
  • возможность одновременного выполнения большого количества тестов;
  • ускорение стабилизации тестов благодаря п.1. 


Минусы:

  • требуется несколько ОС / контейнеров;
  • высокое потребление ресурсов на каждый форк;
  • плагин устарел и больше не поддерживается. 


Как победить нестабильность 


Тестовые стенды не идеальны, как и сами автотесты. Неудивительно, что у нас появилось некоторое количество flacky-тестов. На помощь пришел maven surefire plugin, который из коробки поддерживает перезапуск упавших тестов. Нужно обновить версию плагина минимум до 2.21 и написать одну строчку с количеством перезапусков в pom-файле или передать в качестве аргумента для Maven.

Пример настройки автотестов:

   	

        	
org.apache.maven.plugins
  	
      maven-surefire-plugin
        	
2.21.0
        	

           	
….
            	
2
            	
….
            	



Либо при запуске: mvn… -Dsurefire.rerunFailingTestsCount=2…
Как вариант — задать опции Maven для скрипта PowerShell (PS1):

  
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"


Плюсы:

  • не нужно тратить время на анализ нестабильного теста, когда он падает;
  • можно сгладить проблемы стабильности тестового стенда.


Минусы:

  • можно пропустить плавающие дефекты;
  • время прогона увеличивается.


Параллельные тесты с библиотекой Cucumber 4

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

На тот момент уже вышел Cucumber 4, поэтому мы решили переписать ядро под эту версию. В release notes нам обещали параллельный запуск на уровне тредов. Теоретически это должно было:

  • значительно ускорить прогон автотестов за счет увеличения количества потоков;
  • исключить потерю времени на генерацию раннеров для каждого автотеста.


Оптимизировать фреймворк для многопоточных автотестов оказалось не так сложно. Cucumber 4 прогоняет каждый отдельный тест в выделенном потоке от начала и до конца, поэтому некоторые общие static-вещи были просто преобразованы в ThreadLocal-переменные. 
Главное при конвертации средствами рефакторинга Idea — проверить места, в которых происходило сравнение переменной (например, проверка на null). Кроме того, нужно вынести Allure-плагин в аннотации класса Junit Runner.

Пример настройки автотестов:

 

	
parallel
	

    	

        	

            	
org.apache.maven.plugins
 	
           maven-surefire-plugin
            	
3.0.0-M3
   	
         
                	
false
                	
false
        	
        methods
                	
6
                	
true
                	

                    	
-javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
                	

            	

            	

                	

                    	
org.aspectj
   	
                 aspectjweaver
                    	
${aspectj.version}
                	

            	

        	

    	

	



b47ef92c6608aebaccd13664af9cbf07.pngПример Allure-отчета (самый нестабильный тест, 5 реранов)

6d7db7677375e71ebde6992c96cee920.pngНагрузка раннера во время тестов (8 ядер, 8 ГБ ОЗУ, 24 потока)

Плюсы:

  • низкое потребление ресурсов;
  • нативная поддержка от Cucumber — не нужны дополнительные инструменты;
  • возможность запуска более 6 потоков на ядро процессора.


Минусы:

  • нужно следить за тем, чтобы код поддерживал многопоточное выполнение;
  • увеличивается порог вхождения.


Allure-отчеты в GitLab pages


После внедрения многопоточного запуска мы стали тратить на анализ отчетов гораздо больше времени. На тот момент нам приходилось выкладывать каждый отчет как артефакт в GitLab, потом скачивать его, распаковывать. Это не очень удобно и долго. А если кто-то еще хочет посмотреть отчет у себя, то ему нужно будет проделать те же операции. Нам хотелось получать фидбэк быстрее, и выход нашелся — GitLab pages. Этот встроенная функция, которая доступна из коробки во всех последних версиях GitLab. Позволяет деплоить статические сайты у себя на сервере и получать к ним доступ по прямой ссылке.

Все скриншоты с Allure-отчетами сделаны в GitLab pages. Скрипт для деплоя отчета на GitLab pages — на Windows PowerShell (перед этим необходимо выполнить автотесты):

New-Item -ItemType directory -Path $testresult\history | Out-Null

try {Invoke-WebRequest -Uri $hst -OutFile $outputhst}
Catch{echo "fail copy history"}
try {Invoke-WebRequest -Uri $hsttrend -OutFile $outputhsttrnd}
Catch{echo "fail copy history trend"}

mvn allure:report
#mvn assembly:single -PzipAllureReport
xcopy $buildlocation\target\site\allure-maven-plugin\* $buildlocation\public /s /i /Y


Что в итоге 


Итак, если вы думали о том, нужен ли вам Thread safe-код в Cucumber-фреймворке автотестов, теперь ответ очевиден — с Cucumber 4 его просто внедрить, значительно увеличив тем самым количество запускаемых одновременно потоков. При таком способе запуска тестов вопрос стоит уже о производительности машины с Selenoid и тестового стенда.

Практика показала, что запуск автотестов на тредах позволяет свести расход ресурсов к минимуму при наилучшей производительности. Как видно из графиков, увеличение потоков в 2 раза не приводит к аналогичному ускорению прохождения тестов производительности. Тем не менее мы смогли добавить в сборку приложения более 200 автоматических тестов, которые даже с 5 реранами выполняются примерно за 24 минуты. Это позволяет получать от них быстрый фидбэк, а при необходимости — вносить правки и повторять процедуру снова.

© Habrahabr.ru