Cómo automatizar las pruebas de Magento 2 con MFTF

Este septiembre, Amasty participó en Meet Magento NYC. Valeria Shevtsova, directora del departamento de control de calidad, explicó cómo funciona MFTF y cómo lo usamos en Amasty. Y hoy, compartimos su discurso y presentación con ustedes.

MFTF significa Marco de prueba funcional de Magento.

MFTF es una solución multiplataforma de código abierto. MFTF le permite desarrollar rápidamente pruebas funcionales para la aplicación Magento.

Y ahora, discutiremos las razones por las que Magento Functional Testing Framework es adecuado para la automatización de pruebas, fases importantes que no deben omitirse en el curso del desarrollo de pruebas, características específicas de los casos de prueba de automatización, algunas de las mejores prácticas y trucos.

Nota : lea nuestra guía paso a paso para aprender cómo comenzar sin problemas con MFTF .

Razones para aplicar MFTF a su proyecto

Estas son las razones para automatizar las pruebas a través de MFTF:

• para reducir el tiempo de prueba;
• esta es una herramienta que funciona desde cero y se adapta a diferentes plataformas;
• desarrollo de proyectos a largo plazo;
• compatibilidad con múltiples versiones de productos;
• para probar productos en diferentes versiones de Magento y detectar errores específicos de la versión, etc.

Tenemos más de 250 extensiones , por lo que las pruebas de regresión, como parte de su actualización, requieren mucho tiempo. Decidimos acelerar este proceso y desarrollar pruebas MFTF para evitar retrasos en los lanzamientos.

Aquí hay un ejemplo: la prueba de regresión manual del regalo gratis para Magento 2 tomó 7 horas, el tiempo se redujo a 2 horas (excluyendo el tiempo de ejecución de la prueba) tan pronto como lo cubrimos con autopruebas. Incluso cuando la mitad de las pruebas automáticas están listas, ya las hemos estado ejecutando y viendo los resultados. Para la extensión de Navegación en capas mejorada más grande , el tiempo de prueba de regresión se ha reducido de 50 a 20 horas, aunque el desarrollo de la prueba automática aún no se ha completado.

Además, puede usar las pruebas MFTF listas para usar y omitir algunas de las pruebas manuales sin desarrollar sus propias pruebas. Por ejemplo, puede probar características tan importantes como el registro de usuarios; creación de productos, categorías, atributos; Búsqueda de Producto; check-out, y muchos más usando pruebas predeterminadas. Por supuesto, si se han realizado cambios y la funcionalidad difiere de la predeterminada, algunas de las pruebas pueden bloquearse. Sin embargo, puede ser útil seleccionar pruebas predeterminadas que funcionen correctamente y usarlas como parte de las pruebas de regresión. Puede hacerlo incluso si no tiene un ingeniero de control de calidad de automatización en su equipo, ya que MFTF está basado en .xml y es fácil de usar.

Por tanto, las principales ventajas del MFTF son:

• La disponibilidad de pruebas listas para usar;
• La sencillez de la masterización;
• Escalabilidad.

Se pueden escribir pruebas adicionales para funciones específicas, ya que MFTF lo permite. En Amasty estamos desarrollando pruebas para cubrir la funcionalidad de nuestras extensiones.

Estrategia de desarrollo de pruebas

Si nunca ha hecho esto antes, no siempre está claro por dónde empezar. Por prueba y error, hemos descubierto que ciertos pasos son imprescindibles.

1. Cálculo de la rentabilidad del proyecto. Eso significa cálculo de ROI. Vale la pena considerar la frecuencia de las actualizaciones y el tiempo requerido para desarrollar y respaldar las pruebas. Sin embargo, tenga en cuenta que las pruebas automáticas no solo ahorran presupuestos de pruebas manuales, sino que también ganan en términos de confiabilidad, el tiempo requerido para pasar la fase de control de calidad (lo que resulta en una implementación de actualizaciones más rápida) y la eliminación del «factor humano».
2. Definición de qué es exactamente lo que necesita para automatizar. Existe cierto consenso de que la regresión es el mejor candidato para la automatización, por lo que decidimos comenzar con ella. En algunos casos, estos pueden ser bloques de funcionalidad importantes o lugares detectados que acumulan defectos. Es difícil sobrestimar la importancia del paso de planificación, porque cuanto mejores sean los datos de entrada, mejor será el resultado final.
3. Composición de casos de prueba. Vaya a la siguiente parte para leer la descripción completa de este paso.
   
   Elige el orden en el que desarrollar las pruebas. Por ejemplo, dividimos las pruebas de extensión en grupos «Humo», «Regresión» y «Es bueno tenerlo» y comenzamos con el primer grupo.
4. Desarrollo de pruebas.
5. Revisar.
6. Incluir pruebas en las extensiones.
7. Análisis. Es vital realizar un seguimiento de la frecuencia con la que se utilizan las pruebas y si se encuentran errores. El resultado del análisis puede compararse con los cálculos del paso 1.
8. Pasamos al refinamiento y mantenimiento en base a la información obtenida en el transcurso de las actividades que forman parte del paso anterior.

Características específicas de los casos de prueba diseñados para pruebas automáticas

Como mencionamos anteriormente, los casos de prueba diseñados para pruebas de automatización son algo completamente diferente a lo que definitivamente vale la pena prestar atención.

Elegimos casos de prueba porque son bastante detallados y, por lo tanto, son adecuados para la automatización.

Otros tipos de documentación de prueba son demasiado inespecíficos. Con la Encuesta de prueba práctica, un ingeniero de automatización, independientemente de su experiencia, corre el riesgo de perder comprobaciones importantes. Por lo tanto, la prueba no alcanzará su objetivo principal y detectará los defectos.

Consideremos el punto más importante de los casos de prueba.

Controles y pasos recurrentes

Los casos de prueba deben contener la menor cantidad posible de controles y pasos recurrentes. De hecho, si hubiera un error en un producto, fallarían varias pruebas automáticas, no solo una. Por supuesto, hacer que todos los pasos sean únicos es casi imposible.

condiciones previas

Las «condiciones previas» son una lista de acciones que dan como resultado un estado adecuado para ejecutar la prueba principal. Mientras realiza las pruebas manualmente, el ingeniero de control de calidad apenas piensa en las condiciones previas para la ejecución de las pruebas. Sin embargo, son cruciales para la automatización.

Analicemos un ejemplo. Digamos que tenemos un caso de prueba sobre la edición de productos. Seleccionaríamos cualquier producto existente y lo editaríamos al probarlo manualmente. Una prueba automática no debería actuar de esa manera. ¡Nos arriesgamos a romper la codependencia de las pruebas! Si una prueba edita un producto, mientras que la otra intentará usarlo de la misma manera, puede bloquearse. La solución es la siguiente: ¡debe crearse a través de una autoprueba! Es importante comprender que agregar dichos datos no es la prueba en sí misma, estas son solo acciones secundarias. Las condiciones previas son importantes. Hacen que las pruebas sean autosuficientes, estables, independientes y reducen el tiempo de ejecución de las pruebas.

Optimización de casos de prueba

Es importante utilizar la ruta más corta del caso de prueba. La transición a través de páginas, pestañas o clics en botones, la apertura o el cierre de diálogos lleva tiempo. Minimice estos pasos para acelerar la prueba.

Un paso no debe estar referenciado a otro paso. Por ejemplo, no debe escribir: «Repita los pasos 1 a 10 para un producto configurable» en el paso 11. Esta verificación no es necesaria o la incluimos en una prueba separada para este tipo de producto.

Conexión entre autotest y un caso de prueba

El siguiente punto importante es la correspondencia de un autotest con un caso de prueba. Cada paso de la autoprueba debe ser el mismo que en el caso de prueba. Esta es la única forma de examinar los resultados de las pruebas automáticas, encontrar errores y mantener las pruebas.

Optimización de tamaño

La tarea bastante complicada es la optimización del tamaño de un caso de prueba .

¿Qué tamaño debe tener un caso de prueba para la automatización? No hay una respuesta definitiva.

Nos atenemos al siguiente enfoque:

• Una prueba significa una verificación significativa. Por ejemplo, verifique si la regla del precio del carrito se puede editar.
• Puede agregar algunas verificaciones menos significativas después de una verificación significativa, siempre que utilicen las mismas condiciones previas y no aumenten significativamente el tiempo de ejecución de la prueba.
• En caso de que exista una secuencia indivisible de pasos, se sacan al grupo de acción.

Mejores prácticas de MFTF

Como dicen los devdocs :

Use un grupo de acciones para envolver un conjunto de acciones para reutilizarlas varias veces. Utilice una extensión cuando sea necesario repetir un grupo de prueba o acción con la excepción de algunos pasos.

¡Este es un principio fundamental al desarrollar pruebas!

Algunos otros consejos:

• Independencia _ Esto significa que el resultado de una prueba no afecta el resultado de las otras. Incluso si las pruebas se realizan simultáneamente (por ejemplo, se ejecutan en diferentes navegadores), no deberían interferir entre sí.
• Una prueba de Magento debe eliminar datos críticos después de que se haya ejecutado, ya que puede interferir con las ejecuciones posteriores de otras pruebas o de esta misma prueba (esto no siempre significa la eliminación como tal, a veces el campo que era obligatorio como parte de la prueba puede configurarse como opcional).
• Todos los datos que crea una prueba de Magento deben ser únicos cuando se trata de ID, URL, claves, nombres, etc. para el mismo propósito.
• Los grupos de acción estándar de Magento no deben descuidarse.
• Autosuficiencia. Las autopruebas no deben depender de ningún dato que pueda desaparecer o cambiar con el tiempo o en un momento dado.
• Estabilidad. Si no hay errores en la aplicación, la prueba siempre debe completarse. Esto parece ser obvio, pero no siempre se logra fácilmente.

Trabajo en equipo

Cuando varias personas colaboran en un proyecto de automatización, la correcta organización del trabajo en equipo se vuelve aún más crucial. Hemos seguido los siguientes pasos para lograrlo:

• Presentamos Git Workflow. Puede encontrar en nuestra presentación cómo se ve. Esto ayudó mucho a fomentar la colaboración, especialmente cuando se trata de varias personas que desarrollan pruebas para la misma extensión.
• Usamos los mismos Grupos de Acción no solo dentro de la misma extensión, sino también para diferentes extensiones. Cuando los Grupos de Acción, que pueden ser comunes para varias o todas nuestras extensiones, aumentan en número, los colocamos en Base.
• Las extensiones más grandes (esto puede ser un proyecto grande o una tienda) deben dividirse en partes lógicas y, en consecuencia, automatizarse parte por parte. Varias personas pueden escribir pruebas para diferentes partes al mismo tiempo. Eso es lo que hicimos cuando trabajamos en nuestra extensión ILN .

Trucos de la vida

1. Comprometerse con las mismas opciones de valor por parte de todos los que trabajan en pruebas para la anotación de «grupo» parece ser un enfoque poco sofisticado pero muy útil para mantener el orden en las pruebas y ejecutarlas más tarde. Por lo tanto, hemos compilado una lista de valores posibles y los usamos en cada prueba (puede haber varios grupos en una prueba):

• Un grupo común para todas las pruebas desarrolladas dentro de la empresa; por ejemplo, el grupo Amasty para todas nuestras pruebas con el fin de ejecutar convenientemente todo junto;
• Un grupo que coincida con el nombre de la extensión/proyecto, que combine todas las pruebas de esta extensión (por ejemplo, Orderattr para el orden de los atributos);
• Un grupo correspondiente a la funcionalidad de Magento (opcional). Por ejemplo, las pruebas en cualquier módulo que afecten los pagos se combinan en un grupo de Pago. Estos grupos pueden corresponder a módulos nativos de Magento;
• Se pueden seleccionar grupos lógicos de pruebas dentro de una extensión mayor.

2. Si varias pruebas tienen la misma condición previa, no descuide el uso de conjuntos de pruebas. Esto reduce drásticamente el tiempo que lleva ejecutar las pruebas.

Nota : Puede obtener más información sobre esta herramienta en la documentación de MFTF .

3. Ejecutar pruebas automáticamente después de la actualización de la rama maestra es una gran práctica.

4. Mantener las estadísticas de cómo se realizaron las pruebas para que pueda ver qué tan bien detectan errores en el futuro, ¡también genial! En caso de que las pruebas se ejecuten una cantidad significativa de veces sin detectar errores, bueno, bien por ti, hiciste una regresión. Sin embargo, esto puede ser una señal para que analice los escenarios de prueba y los mejore.

5. No olvide que todas las pruebas, incluidas las pruebas MFTF, requieren mantenimiento, correcciones y refactorización debido a cambios en el producto. Por lo tanto, asigne algo de tiempo para estas actividades cuando planifique.

6. ¡No olvides usar los informes!

En conclusión

Desarrollar pruebas es un proceso creativo que mejorará la calidad del sitio o extensión. Vale la pena contribuir a la plataforma para mejorarla y desarrollar sus habilidades al siguiente nivel.

¿Quieres obtener un PDF gratis con nuestra presentación MM19NY?

¡Deja tu correo electrónico y te lo enviaremos de inmediato! Sin spam garantizado.(function() {
if (!window.mc4wp) {
window.mc4wp = {
listeners: [],
forms : {
on: function (event, callback) {
window.mc4wp.listeners.push({
event : event,
callback: callback
});
}
}
}
}
})();

(function() {
mc4wp.forms.on(‘28075.submit’, function(form, event) {
event.preventDefault();

var submitForm = function() {
if(form.element.className.indexOf(‘mc4wp-ajax’) > -1) {
mc4wp.forms.trigger(‘submit’, [form, event]);
} else {
form.element.submit();
}
};
var previousToken = form.element.querySelector(‘input[name=_mc4wp_grecaptcha_token]’);
if (previousToken) {
previousToken.parentElement.removeChild(previousToken);
}

try {
window.grecaptcha
.execute(‘6LcoY6UZAAAAAP7Dqjtr6MPM8yGySn617oAlWVSx’, {action: ‘mc4wp_form_submit’})
.then(function (token) {
var tokenEl = document.createElement(‘input’);
tokenEl.type = ‘hidden’;
tokenEl.value = token;
tokenEl.name = ‘_mc4wp_grecaptcha_token’;
form.element.appendChild(tokenEl);
submitForm();
});
} catch(err) {
submitForm();
throw err;
}
})
})();

Deja este campo vacío si eres humano: