A nosa división crea canalizacións totalmente automáticas para lanzar novas versións de aplicacións ao ambiente de produción. Por suposto, isto require probas funcionais automatizadas. Debaixo do corte hai unha historia sobre como, comezando coas probas dun só fío nunha máquina local, chegamos ao punto de autotest multiproceso que se executaba en Selenoid no proceso de compilación cun informe Allure nas páxinas de GitLab e, finalmente, obtivemos unha ferramenta de automatización xenial. que as persoas futuras poidan usar equipos.
Por onde empezamos?
Para implementar as probas automáticas e integralas no pipeline, necesitábamos un marco de automatización que puidese cambiarse de forma flexible para adaptarse ás nosas necesidades. Idealmente, quería obter un único estándar para o motor de probas automáticas, adaptado para incorporar probas automáticas na canalización. Para a súa implementación escollemos as seguintes tecnoloxías:
- Java,
- Maven,
- selenio,
- Pepino + XUÑO 4,
- encanto,
- GitLab.
Por que este conxunto en particular? Java é un dos idiomas máis populares para probas automatizadas e todos os membros do equipo fálano. O selenio é a solución obvia. O pepino, entre outras cousas, debía aumentar a confianza nos resultados das probas automatizadas por parte dos departamentos implicados nas probas manuais.
Probas de rosca única
Para non reinventar a roda, tomamos desenvolvementos de varios repositorios en GitHub como base para o marco e adaptámolos para nós. Creamos un repositorio para a biblioteca principal co núcleo do marco de autotest e un repositorio cun exemplo Gold de implementación de autotests no noso núcleo. Cada equipo tivo que tomar a imaxe Gold e desenvolver nela probas, adaptándoa ao seu proxecto. Implementamos GitLab-CI no banco, no que configuramos:
- execucións diarias de todas as probas automáticas escritas para cada proxecto;
- lanzamentos en proceso de construción.
Ao principio houbo poucas probas, e realizáronse nun só fluxo. A execución dun só fío no corredor de Windows de GitLab acabounos bastante ben: as probas cargaron o banco de probas moi lixeiramente e case non empregaron recursos.
Co paso do tempo, o número de autotests foi cada vez máis numeroso, e pensamos en lanzalos en paralelo, cando unha carreira completa comezou a levar unhas tres horas. Tamén apareceron outros problemas:
- non puidemos verificar que as probas fosen estables;
- as probas que se executaron varias veces seguidas na máquina local ás veces fallaban en CI.
Exemplo de configuración de autotests:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.20</version>
<configuration>
<skipTests>${skipTests}</skipTests>
<testFailureIgnore>false</testFailureIgnore>
<argLine>
-javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"
</argLine>
</configuration>
<dependencies>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjweaver</artifactId>
<version>${aspectj.version}</version>
</dependency>
</dependencies>
</plugin>
<plugin>
<groupId>io.qameta.allure</groupId>
<artifactId>allure-maven</artifactId>
<version>2.9</version>
</plugin>
</plugins>
Exemplo de informe Allure
Carga do corredor durante as probas (8 núcleos, 8 GB de RAM, 1 fío)
Pros das probas dun só fío:
- fácil de configurar e executar;
- os lanzamentos en CI practicamente non son diferentes dos lanzamentos locais;
- as probas non se afectan entre si;
- requisitos mínimos para os recursos do corredor.
Desvantaxes das probas dun só fío:
- tarda moito en completar;
- longa estabilización das probas;
- uso ineficiente dos recursos do corredor, utilización extremadamente baixa.
Probas en forks JVM
Como non nos ocupamos do código seguro para fíos ao implementar o marco base, a forma máis obvia de executar en paralelo era para Maven. O complemento é fácil de configurar, pero para un correcto funcionamento paralelo, as probas automáticas deben executarse en navegadores separados. Non hai nada que facer, tiven que usar Selenoid.
O servidor Selenoid lanzouse nunha máquina con núcleos 32 e 24 GB de RAM. O límite estableceuse en 48 navegadores: 1,5 fíos por núcleo e uns 400 MB de RAM. Como resultado, o tempo da proba reduciuse de tres horas a 40 minutos. Acelerar as carreiras axudou a resolver o problema de estabilización: agora podíamos executar rapidamente novas probas automáticas de 20 a 30 veces ata estar seguros de que funcionaban de forma fiable.
O primeiro inconveniente da solución foi a alta utilización dos recursos do corredor cun pequeno número de fíos paralelos: en 4 núcleos e 8 GB de RAM, as probas funcionaron de forma estable sen máis de 6 fíos. A segunda desvantaxe: o complemento xera clases de corredor para cada escenario, sen importar cantas se lancen.
Importante! Non pase unha variable con etiquetas a argLine, por exemplo, así:
<argLine>-Dcucumber.options="--tags ${TAGS} --plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm --plugin pretty"</argLine>
…
Mvn –DTAGS="@smoke"
Se pasas a etiqueta deste xeito, o complemento xerará corredores para todas as probas, é dicir, tentará executar todas as probas, saltándoas inmediatamente despois do lanzamento e creando moitos forks JVM.
É correcto lanzar unha variable cunha etiqueta etiquetas na configuración do complemento, vexa o exemplo a continuación. Outros métodos que probamos teñen problemas para conectar o complemento Allure.
Exemplo de tempo de execución de 6 probas curtas con configuracións incorrectas:
[INFO] Total time: 03:17 min
Exemplo de tempo de execución de proba se transfire directamente a etiqueta a mvn... –Dcucumber.opcións:
[INFO] Total time: 44.467 s
Exemplo de configuración de autotests:
<profiles>
<profile>
<id>parallel</id>
<build>
<plugins>
<plugin>
<groupId>com.github.temyers</groupId>
<artifactId>cucumber-jvm-parallel-plugin</artifactId>
<version>5.0.0</version>
<executions>
<execution>
<id>generateRunners</id>
<phase>generate-test-sources</phase>
<goals>
<goal>generateRunners</goal>
</goals>
<configuration>
<tags>
<tag>${TAGS}</tag>
</tags>
<glue>
<package>stepdefs</package>
</glue>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
<forkCount>12</forkCount>
<reuseForks>false</reuseForks>
<includes>**/*IT.class</includes>
<testFailureIgnore>false</testFailureIgnore>
<!--suppress UnresolvedMavenProperty -->
<argLine>
-javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar" -Dcucumber.options="--plugin io.qameta.allure.cucumber2jvm.AllureCucumber2Jvm TagPFAllureReporter --plugin pretty"
</argLine>
</configuration>
<dependencies>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjweaver</artifactId>
<version>${aspectj.version}</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</profile>
Exemplo dun informe Allure (a proba máis inestable, 4 repeticións)
Carga do corredor durante as probas (8 núcleos, 8 GB de RAM, 12 fíos)
Pros:
- configuración sinxela: só tes que engadir un complemento;
- a capacidade de realizar simultaneamente un gran número de probas;
- aceleración da estabilización da proba grazas ao paso 1.
Contras:
- Requírense varios sistemas operativos/contedores;
- alto consumo de recursos para cada garfo;
- O complemento está desactualizado e xa non é compatible.
Como superar a inestabilidade
Os bancos de probas non son ideais, como os propios autotests. Non é de estrañar que teñamos unha serie de probas escamosas. Veu ao rescate, que admite reiniciar probas erradas. Debes actualizar a versión do complemento a polo menos 2.21 e escribir unha liña co número de reinicios no ficheiro pom ou pasalo como argumento a Maven.
Exemplo de configuración de autotests:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.21.0</version>
<configuration>
….
<rerunFailingTestsCount>2</rerunFailingTestsCount>
….
</configuration>
</plugin>
Ou ao iniciar: mvn... -Dsurefire.rerunFailingTestsCount=2...
Como opción, configure as opcións de Maven para o script de PowerShell (PS1):
Set-Item Env:MAVEN_OPTS "-Dfile.encoding=UTF-8 -Dsurefire.rerunFailingTestsCount=2"Pros:
- non hai que perder o tempo analizando unha proba inestable cando falla;
- Os problemas de estabilidade do banco de probas pódense mitigar.
Contras:
- os defectos flotantes poden perderse;
- o tempo de execución aumenta.
Probas paralelas coa biblioteca Cucumber 4
O número de probas medrou cada día. Volvemos a pensar en acelerar as carreiras. Ademais, quería integrar tantas probas como fose posible no pipeline de montaxe da aplicación. O factor crítico foi que a xeración de corredores tardou demasiado cando se executaba en paralelo usando o complemento Maven.
Nese momento, Cucumber 4 xa fora lanzado, polo que decidimos reescribir o núcleo para esta versión. Nas notas de lanzamento prometéronnos o lanzamento paralelo a nivel de fío. Teoricamente isto debería ser:
- acelerar significativamente a execución das probas automáticas aumentando o número de fíos;
- eliminar a perda de tempo na xeración de corredores para cada autotest.
Optimizar o marco para as probas automáticas multiproceso non resultou tan difícil. Cucumber 4 executa cada proba individual nun fío dedicado de principio a fin, polo que algunhas cousas estáticas comúns simplemente convertéronse en variables ThreadLocal.
O principal cando se converte usando as ferramentas de refactorización de Idea é comprobar os lugares onde se comparou a variable (por exemplo, comprobando nulo). Ademais, cómpre engadir o complemento Allure á anotación da clase Junit Runner.
Exemplo de configuración de autotests:
<profile>
<id>parallel</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M3</version>
<configuration>
<useFile>false</useFile>
<testFailureIgnore>false</testFailureIgnore>
<parallel>methods</parallel>
<threadCount>6</threadCount>
<perCoreThreadCount>true</perCoreThreadCount>
<argLine>
-javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
</argLine>
</configuration>
<dependencies>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjweaver</artifactId>
<version>${aspectj.version}</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</profile>
Exemplo dun informe Allure (a proba máis inestable, 5 repeticións)
Carga do corredor durante as probas (8 núcleos, 8 GB de RAM, 24 fíos)
Pros:
- baixo consumo de recursos;
- soporte nativo de Cucumber: non se precisan ferramentas adicionais;
- a capacidade de executar máis de 6 fíos por núcleo do procesador.
Contras:
- cómpre asegurarse de que o código admite a execución multiproceso;
- o limiar de entrada aumenta.
Informes de Allure en páxinas de GitLab
Despois de introducir a execución multiproceso, comezamos a dedicar moito máis tempo a analizar informes. Nese momento, tiñamos que cargar cada informe como un artefacto a GitLab, despois descargalo e desempaquetalo. Non é moi cómodo e leva moito tempo. E se alguén quere ver o informe por si mesmo, terá que facer as mesmas operacións. Queriamos recibir comentarios máis rápido e atopamos unha solución: as páxinas de GitLab. Esta é unha función integrada que está dispoñible en todas as versións recentes de GitLab. Permítelle implementar sitios estáticos no seu servidor e acceder a eles mediante unha ligazón directa.
Todas as capturas de pantalla dos informes de Allure fixéronse en páxinas de GitLab. Script para implementar o informe nas páxinas de GitLab - en Windows PowerShell (antes debes executar probas automáticas):
New-Item -ItemType directory -Path $testresulthistory | 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 $buildlocationtargetsiteallure-maven-plugin* $buildlocationpublic /s /i /Y
Cal é o resultado?
Entón, se estabas a pensar se necesitas código Thread safe no marco de proba automática de Cucumber, agora a resposta é obvia: con Cucumber 4 é fácil implementalo, aumentando así significativamente o número de fíos que se inician simultáneamente. Con este método de realización de probas, a pregunta agora faise sobre o rendemento da máquina con Selenoid e o banco de probas.
A práctica demostrou que a execución de probas automáticas en fíos permítelle reducir o consumo de recursos ao mínimo co mellor rendemento. Como se pode ver nas gráficas, duplicar fíos non leva a unha aceleración similar nas probas de rendemento. Non obstante, puidemos engadir máis de 2 probas automatizadas á compilación da aplicación, que mesmo con 200 repeticións se executan nuns 5 minutos. Isto permítelle recibir comentarios rápidos deles e, se é necesario, facer cambios e repetir o procedemento de novo.
Fonte: www.habr.com