En las primeras etapas de desarrollo, puede pasar las pruebas manuales de acuerdo con un plan de prueba dado. Pero con el advenimiento de la arquitectura modular, cuando varios equipos de desarrollo pueden hacer cambios al mismo tiempo, hay un aumento exponencial en el número de scripts de prueba. Alejarlos manualmente es cada vez más difícil.
En este artículo, hablaremos sobre cómo nosotros en Virto Commerce automatizamos las pruebas de escenarios comerciales importantes.
¿Por qué todo esto?
Daré un ejemplo de nuestra experiencia: una pequeña edición de estilo CSS hizo que el botón "Agregar producto al carrito" ya no fuera visible en el dispositivo móvil. Desafortunadamente, de esta forma, se probó y llegó al lanzamiento. Hay muchos ejemplos en los que la nueva funcionalidad, correcciones menores y correcciones, rompen escenarios comerciales importantes. Desafortunadamente, a menudo nos enteramos de ellos después de los lanzamientos y de los clientes. Para evitar esto, hace más de dos años, comenzamos a implementar las pruebas E2E como parte del proceso de desarrollo. Después de eso, la mayoría de los errores se identificaron en la etapa de desarrollo, y no en el entorno de combate.
E2E está probando un escenario empresarial de principio a fin. La prueba E2E simula acciones reales del usuario en un navegador real, tal como el usuario real usará la solución.
Utilizamos pruebas E2E:
- Para controlar la regresión
- Describir el sistema.
- Para integración en CI / CD
Esto incluye asegurar que todos los módulos funcionen y trabajen juntos de manera correcta y previsible.
Las pruebas E2E nos permiten cubrir secciones de la aplicación que no están verificadas por la Unidad y las pruebas de integración. Esto se debe al hecho de que las pruebas unitarias y las pruebas de integración cubren partes individuales de la aplicación y prueban una parte aislada de la funcionalidad. Incluso si estas partes funcionan bien por sí mismas, no puede estar completamente seguro de si funcionarán juntas. Por lo tanto, la presencia de un conjunto de pruebas E2E en la parte superior de la Unidad y la integración nos permite probar la solución completa de la manera más completa.
Escribir y ejecutar pruebas E2E requiere tiempo y recursos. Google, por ejemplo, ofrece una separación 70/20/10: 70% de pruebas unitarias, 20% de pruebas de integración y 10% de pruebas E2E. La combinación exacta será diferente para cada proyecto, pero en general debe preservar la forma de la pirámide.
Las pruebas E2E no son simples y al principio parecen caras de desarrollar y mantener. En Virto Commerce, trabajamos constantemente para simplificar el desarrollo y reducir el costo de soportar las pruebas E2E cuando se lanzan nuevas versiones. Esperamos que nuestras soluciones lo ayuden a simplificar el uso de E2E en sus proyectos.
Buena historia de usuario: está casi lista la prueba E2E
A menudo puede escuchar que escribir pruebas E2E lleva tiempo; son difíciles de mantener. Sí, esto es así, no son fáciles de mantener de la misma manera que la documentación. ¿Por qué no hacerlos parte del proceso de desarrollo y escribir documentación, capturando así los escenarios empresariales?
La creación de E2E comienza con una descripción de la historia del usuario. Cuán cuidadosamente preparemos la descripción en esta etapa, será tan simple para el equipo de desarrollo escribir una prueba E2E que demostrará que todos los sistemas funcionan correctamente al implementar este escenario.
Un ejemplo de una historia de usuario para un botón para agregar un artículo al carrito:
GIVEN I am signed in to the storefront AND Some product page is open (/product-name) AND my cart is empty WHEN I click to the "Add" button on the item with the following parameters: THEN I should see a dropdown menu where I can choose from 1 to 10+
que luego se convierte en la siguiente prueba:
Después de un tiempo, los escritores técnicos o un nuevo equipo de desarrollo, en lugar de leer la documentación, pueden usar las pruebas para ejecutar y ver los scripts implementados en un navegador real o grabar automáticamente tutoriales en video.
Fácil - Instalar y configurar el transportador
Como herramienta de prueba, elegimos Protractor, un sistema de automatización de prueba E2E de código abierto desarrollado específicamente para aplicaciones web AngularJS.
Protractor es un programa Node.js creado sobre WebDriverJS. Protractor funciona como un integrador de soluciones que combina tecnologías potentes como Node.js, Jasmine, Selenium, Mocha, Cucumber y Web.
El transportador conoce AngularJS, lo que hace que sea más fácil escribir pruebas sin perder tiempo esperando que se inicie el proyecto AngularJS, refrescando la página, etc. ... La experiencia muestra que el umbral de entrada del desarrollador es muy bajo.
Use npm para instalar Protractor a nivel mundial:
npm install -g protractor
webdriver-manager es una utilidad que facilita la configuración de una instancia de Selenium Server. Selenium Server: se utilizará para transferir comandos entre la prueba y el entorno real.
Ejecute este comando para instalar o descargar:
webdriver-manager update
Y corre:
webdriver-manager start
Este comando inicia Selenium Server y abre una ventana para mostrar el registro. El transportador enviará solicitudes a este servidor para controlar el navegador.
El transportador está listo para funcionar. Puede encontrar una descripción más detallada de los pasos básicos para escribir pruebas en el
sitio principal .
La estructura correcta del proyecto.
Las pruebas E2E siempre están en el mismo repositorio que la aplicación o el tema.
Nos negamos a usar servicios de prueba E2E externos, porque, con aparente simplicidad, los servicios complican el lanzamiento de pruebas en la máquina local y el mantenimiento posterior. El código y las pruebas se encuentran en diferentes lugares físicos, lo que lleva al hecho de que los desarrolladores se olvidan de actualizarlos.
Encontrar el código de la aplicación y probarlo en un repositorio facilita el mantenimiento y el mantenimiento del proyecto.
Un ejemplo básico se puede
encontrar aquí .
El proyecto crea una carpeta E2E de la siguiente estructura, que utiliza Page Objects para organizar las pruebas.
E2E/ |--cart | |--cart.pageObject.js | |--*.spec.js |--home | |--home.pageObject.js | |--*.spec.js |--conf.js
- conf.js: el archivo de configuración está en la raíz
- para cada objeto de interfaz se crea su propia carpeta, en la que se encuentra
- archivo pageObject para describir los elementos en la página
- varios archivos de especificaciones, donde se encuentran las pruebas
El proyecto debe usar:
- baseUrl: que le permite usar la prueba para probar diferentes entornos
- parámetros - que se utilizan para encontrar elementos clave en una página o completar formularios
github.com/VirtoCommerce/vc-storefront/blob/master/VirtoCommerce.Storefront.Test/e2e/conf.js#L21
github.com/VirtoCommerce/vc-storefront/blob/master/VirtoCommerce.Storefront.Test/e2e/conf.js#L29El administrador de TI puede cambiar estos parámetros al configurar el lanzamiento en Jenkins, en modo automático para entornos DEV y QA.
protractor conf.js --baseUrl=https://some-url.azurewebsites.net/--params.api.endpoint=https://some-admin-url.azurewebsites.net
Optimización de la búsqueda de elementos en la página.
El transportador ofrece métodos muy flexibles para encontrar elementos en la página:
- por.
- por.modelo
- por.repetidor
- by.className
- por.css
- by.select ()
- by.partialButtonText ()
- ...
Pero en proyectos recientes, llegamos al modelo de que los elementos que participan en la prueba están marcados con una clase especial con el prefijo transportador. En la prueba, byclassName encuentra estos elementos.
Esto simplifica el mantenimiento de las pruebas y la realización de cambios, por lo que un programador o herramientas automatizadas pueden determinar que el elemento que participa en la prueba E2E ha cambiado.
¿Qué navegadores estamos probando?
Por defecto, todos los procesos están configurados para ejecutar pruebas en el navegador Chrome. Como muestra nuestra experiencia en el uso de pruebas E2E en Chrome, nos permite identificar la mayoría de los problemas y, al mismo tiempo, no complicar la redacción de las pruebas.
Si necesita probar en varios navegadores, esto se hace por un lado muy simple, por otro lado hay dificultades con la configuración y la presencia de errores en la implementación de controladores para diferentes navegadores.
En varios proyectos de clientes, también probamos en Firefox, Safari e IE. Las pruebas de Firefox en realidad duplican los resultados en Chrome. Pero el lanzamiento de E2E en Safari e IE requirió la configuración del sistema, la apertura de puertos, la desactivación de la seguridad y la edición del registro, pero esto permitió detectar automáticamente muchos problemas con la visualización y la incompatibilidad de los scripts en la aplicación.
Para agregar pruebas en el navegador, debe descargar e instalar el
WebDriver necesario.Y agregue una nueva sección multiCapabilities en el archivo de configuración:
exports.config = { … multiCapabilities: [ { 'browserName' : 'chrome' }, { 'browserName' : 'firefox' } ], … }
Dado que las aplicaciones web modernas admiten el trabajo con diferentes resoluciones, esto debe tenerse en cuenta al escribir pruebas.
Transportador le permite ejecutar pruebas para diferentes resoluciones de pantalla.
Para hacer esto, hay una opción para establecer el tamaño de la pantalla a través de browser.driver.manage (). Window (). SetSize. En este ejemplo, establecemos el tamaño de la pantalla en 1600 por 800.
exports.config = { … capabilities: { 'browserName': 'chrome' }, onPrepare: function() { browser.driver.manage().window().setSize(1600, 800)
O a través de la sección multiCapabilities en el archivo de configuración. En este ejemplo, ejecutaremos pruebas en el navegador Chrome para tres resoluciones diferentes.
multiCapabilities: [ { 'browserName': 'chrome', 'chromeOptions' : { args: ['--lang=en', '--window-size=1920,1080'] }, specs: ['specs.js'] }, { 'browserName': 'chrome', 'chromeOptions' : { args: ['--lang=en', '--window-size=1680,1050'] }, specs: ['specs.js'] }, { 'browserName': 'chrome', 'chromeOptions' : { args: ['--lang=en', '--window-size=1600,900'] }, specs: ['specs.js'] }]
E2E es parte de la documentación.
Una vez más, E2E es bueno como elemento de documentación, lo que demuestra lo que hizo el equipo de desarrollo. Un nuevo equipo de desarrollo o escritor técnico puede ejecutar las pruebas y ver los scripts implementados en vivo. Por lo tanto, documente cómo un nuevo empleado puede ejecutar estas pruebas.
Integración CI / CD
Cualquier prueba debe ser relevante y ejecutarse periódicamente. Si esto no se hace, entonces no debe perder el tiempo escribiendo pruebas, ya que en un par de semanas no tendrán valor y será más fácil reescribirlas desde cero.
Hemos dado un paso importante en la integración de las pruebas E2E en CI / CD y en hacer que E2E sea parte del proceso de implementación.
La integración en el CI / CD le permite ejecutar pruebas E2E automáticamente para entornos DEV y QA para proporcionar comentarios y agregar información de que el sistema permanece operativo incluso después de un pequeño cambio. Y si la decisión se rompe, proporcione información sobre cuándo y en qué cambio sucedió esto.
En primer lugar, las pruebas se inician cuando uno de los módulos se actualiza y la nueva versión ingresa al entorno de control de calidad.
En segundo lugar, las pruebas E2E se ejecutan por la noche en un horario en entornos DEV y QA en modo automático.
En tercer lugar, si es necesario, los propios desarrolladores pueden ejecutar las pruebas según sea necesario.
Según los resultados del lanzamiento, todos los participantes del proyecto desde el equipo de desarrollo hasta el cliente reciben un correo electrónico con un informe HTML sobre los resultados de la prueba.
Es importante tener en cuenta la disponibilidad obligatoria de información sobre el resultado de la prueba para todo el equipo del proyecto. Esto le da confianza al equipo de desarrollo, por un lado, y administra las expectativas del cliente, por el otro. El equipo de desarrollo puede hacer cambios más rápido, mientras se da cuenta de que los principales escenarios comerciales están funcionando. Y el cliente recibe información sobre la calidad del proyecto, que la mayoría de los problemas se identifican antes del lanzamiento. E incluso si la prueba identifica el problema y se pospone el lanzamiento, entonces aparece información sobre qué se rompió exactamente y cómo va el proceso de corrección.
Utilizamos la versión modificada del complemento protractor-jasmine2-html-reporter (https://github.com/VirtoCommerce/protractor-jasmine2-html-reporter) para generar informes. Este complemento genera un informe HTML e inserta capturas de pantalla de elementos en línea.
Instalarlo es muy simple:
- Instalar protractor-jasmine2-html-reporter
- Agregar protractor-jasmine2-html-reporter al proyecto
- Informe de conexión sobre el método de preparación
var HtmlScreenshotReporter = require('protractor-jasmine2-html-reporter'); var reporter = new HtmlScreenshotReporter(self.options); var name = browser.suite; self.options.reportTitle = name + '-report.html'; jasmine.getEnv().addReporter(reporter);
Mejorar constantemente el proceso.
Trabaje constantemente en un equipo para reducir costos y aumentar la velocidad de desarrollo y soporte de las pruebas E2E.
Capacite y revise el proceso de redacción del examen. Vea qué componentes y servicios nuevos se pueden usar.
Por ejemplo, estamos considerando una opción de conexión de Pepino. Cucumber es una herramienta para ejecutar pruebas automatizadas escritas en un lenguaje simple.
Conclusiones
Las pruebas E2E no son tan simples y al principio parecen costosas de mantener, pero son muy valiosas porque son un indicador de la salud de los escenarios comerciales importantes.
A partir de la experiencia de usar las pruebas E2E en el proyecto Virto Commerce, podemos sacar las siguientes conclusiones:
- Escribir E2E es parte del proceso de desarrollo. Y es muy importante, porque prueba el trabajo de los procesos comerciales y la solución completa. Se detectó una gran cantidad de errores en la etapa de DEV y QA, y no en el entorno de combate.
- Las pruebas y el código deben estar en el mismo repositorio y estar disponibles para el desarrollador.
- La calidad de la prueba E2E depende de la descripción de la historia del usuario; si está escrita correctamente, es más fácil para el equipo de desarrollo crear una prueba E2E.
- Las pruebas E2E pueden actuar como documentación y registrar secuencias de comandos realizadas.
- Las pruebas E2E deben ejecutarse de forma continua y automática en entornos DEV y QA. Si no automatizaste el lanzamiento, entonces no deberías perder el tiempo en las pruebas, ya que no tendrán valor en un par de semanas.
- Los resultados de la prueba deben estar disponibles para todos los participantes del proyecto. Esto da una idea de lo que está sucediendo.
- E2E no es una solución al 100% para todos los problemas. Siga la regla 70/20/10: 70% de pruebas unitarias, 20% de pruebas de integración y 10% de pruebas E2E
- Trabaje constantemente en un equipo para reducir costos y aumentar la velocidad de desarrollo y soporte de las pruebas E2E.
Referencias
www.protractortest.orgTransportador para AngularJS: escribir pruebas de extremo a extremo nunca ha sido tan divertidogithub.com/angular/protractor/blob/master/docs/page-objects.mdgithub.com/VirtoCommerce/vc-storefront/tree/master/VirtoCommerce.Storefront.Test/e2eSimplemente diga no a más pruebas de punta a punta
testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html