+ versión de portada mejor, pero menos divertida Tarde o temprano, todos llegan a AT. La situación cuando esto sucede tarde es comprensible, y ¿cuándo es temprano? ¿Y cómo entender lo que ya es posible?El artículo se basa en la experiencia de un equipo: le contaré acerca de nuestros requisitos previos y las razones para la introducción de la auto-evaluación, qué criterios hemos seleccionado para la preparación de AT y qué herramientas usamos al final. Spoiler: al final, algunos casos exitosos y no muy importantes con Xamarin.UITest.Introducción sobre el producto. , , , , , . offline.
-.
Lo que dice la teoría
Considere el enfoque de automatización utilizando la pirámide de prueba como ejemplo. Como niveles de la pirámide, tomaré los tipos de pruebas que usamos. A saber, pruebas unitarias, pruebas de integración y pruebas de extremo a extremo (E2E).
Las pruebas unitarias (pruebas unitarias) verifican el funcionamiento de pequeñas partes individuales del sistema (función, método). Son pequeños, pasan rápidamente, no requieren grandes costos de desarrollo y mantenimiento.Las pruebas de integración prueban el funcionamiento de la aplicación con componentes externos. Por ejemplo, con una base de datos o varios servicios. Toman más tiempo, tanto para escribir y apoyar pruebas, como para sus carreras. Para tales pruebas, la mayoría de las veces necesita configurar y admitir algún tipo de entorno. En este caso, a menudo se vuelven más frágiles, porque El ambiente tiende a romperse.Las pruebas de extremo a extremo verifican el funcionamiento del sistema en su conjunto, emulando las acciones del usuario final. La mayoría de las veces acceden al sistema a través de la interfaz de usuario: presionan los botones como usuario, completan los campos, etc. Pero también se pueden usar en sistemas sin interfaz. Estas pruebas son mucho más caras que las consideradas anteriormente, porque requieren más tiempo para desarrollar y respaldar tanto las pruebas como el entorno completo. Además, son muy frágiles, ya que se ven afectados por cambios en cualquier parte del sistema, y el comportamiento inesperado de un emulador o navegador puede afectar el resultado de una prueba específica. La duración de la ejecución de tales pruebas también es significativamente mayor que el resto: para realizar cualquier acción individual del usuario, debe realizar muchas más. Por ejemplo, inicie sesión o vaya al elemento de menú deseado.De acuerdo con el principio de la pirámide, cuanto más fácil, rápida y barata sea la prueba, más deben ser en un porcentaje del número total de pruebas. Aquellos. una prueba completa no debe verificar la asignación de diferentes valores a un campo (a menos que necesite verificar el funcionamiento de la IU en estos casos).Para todos estos tipos de pruebas se les asigna un rol. En algún momento del ciclo de vida de la aplicación, surge la necesidad de una u otra automatización de prueba. Su producto puede funcionar fácilmente con solo pruebas unitarias, y puede crecer rápidamente a la necesidad de pruebas de extremo a extremo. Lo principal cuando se planifica la automatización es comprender exactamente de qué se beneficiará actualmente su producto y para qué es probable que pierda el tiempo.Al implementar la automatización, no se olvide de las pruebas manuales, incluso con una gran cantidad de automatización, siempre habrá cosas que deben verificarse manualmente. Como mínimo, nueva funcionalidad para la cual no es racional escribir pruebas de inmediato.Pero toda la automatización, en mi opinión, debería estar dirigida principalmente a reducir el volumen de las pruebas manuales. Y al planificar las pruebas manuales, vale la pena considerar qué casos ya están automatizados.¿Cómo se organizan las pruebas automáticas con nosotros?
Cada producto individualmente tiene pruebas unitarias, ejecutadas en cada PR. Son responsabilidad de los desarrolladores.
Las pruebas de integración verifican la interacción del servicio web con el EDMS.Simulan el funcionamiento de una aplicación cliente. Recurren a métodos de servicio web para obtener y modificar datos EDS.Ejecutar después de cada compilación de una nueva versión del lado del servidor.
Las pruebas de extremo a extremo simulan el rendimiento del usuario final. Presionan los botones en la interfaz de la aplicación móvil, y la aplicación funciona con el EDMS a través de un servicio web.Los probadores ahora están realizando pruebas integrales y de extremo a extremo.¿Por qué necesitamos aplicaciones móviles AT de extremo a extremo?
Antes de embarcarse en la automatización, vale la pena considerar qué problema desea resolver introduciéndolo. A menos que tenga objetivos específicos, no podrá explicarle al supervisor o al propietario del producto por qué debería dedicar tiempo a las pruebas automáticas. Será difícil evaluar los beneficios de su implementación.Hemos probado durante mucho tiempo aplicaciones móviles de forma manual. Si bien esta era una aplicación con poca funcionalidad, lo superamos con éxito. Todo lo que se desarrolló fue ± en un área, y las pruebas manuales podrían organizarse de manera tal que se probaran rápida y fácilmente todas las características de la aplicación.Pero después de un tiempo, la aplicación comenzó a crecer con nuevas características, que eran bastante independientes y requerían más atención. Hubo un problema con los errores en la funcionalidad anterior, que solo pudimos encontrar en las últimas etapas del proyecto.Por lo tanto, los objetivos iniciales de introducir pruebas de IU de aplicaciones móviles para nosotros fueron:- AT cobertura de los principales casos de aplicación;
- reduciendo el número de errores en la regresión antes del lanzamiento.
Alcanzar el primer objetivo debería conducir automáticamente al logro del segundo, ya que Las ejecuciones regulares de pruebas de funcionalidad básica en todo el proyecto deberían encontrar errores en las etapas anteriores.Después de algún tiempo, se agregó otro objetivo: reducir el número de pruebas de regresión manual.¿Y cuándo es el momento de introducir la automatización en las pruebas?
Antes de embarcarse en la automatización de pruebas, debe evaluar la preparación de su aplicación para la automatización. Y también tu disposición para este proceso.Funcionalidad estable
Para que AT tenga la oportunidad de ser útil, la aplicación debe tener una funcionalidad estable. Y vale la pena cubrir las protestas automáticas. De lo contrario, dedicará mucho tiempo y esfuerzo a actualizar y actualizar las pruebas como resultado de los cambios en la aplicación.Planes de desarrollo
La automatización debe implementarse solo si su aplicación tiene planes de desarrollo futuros para los próximos años. ¿Por qué las pruebas automáticas para una aplicación que no cambia?Recursos
Debe tener recursos para desarrollar pruebas, y lo más importante, para su mayor apoyo. Aquellos. Al planificar la implementación de la automatización, es importante comprender que los recursos no solo serán necesarios para escribir pruebas. Las pruebas ciertamente caerán por alguna razón. Será necesario analizar los resultados de las corridas y tomar medidas. Incluso cambiar algo en las pruebas Bueno, además del soporte, no te olvides de la necesidad de su desarrollo.¿Cómo decidir?
Cuando pensamos en las pruebas de IU de aplicaciones móviles, inmediatamente encontramos grandes estantes con dispositivos o granjas en los que se alquilan dispositivos. Hubo muchos problemas en las pruebas debido a la necesidad de verificar diferentes tamaños y resoluciones de pantalla. Sí, y no había mucha experiencia en desarrollo. Fue todo aterrador y forzado a guardar planes.Los objetivos formulados anteriormente vinieron al rescate, y el principal fue una prueba funcional. Por lo tanto, comenzamos pequeño.Como resultado, nuestras pruebas:- ejecutar una vez al día (esto es suficiente para encontrar la fuente del problema si sucede algo);
- ejecutar localmente en nuestros servidores;
- en dos dispositivos (iOS y Android);
- para Android ahora hay alrededor de 50 pruebas, la ejecución dura aproximadamente una hora (junto con el ensamblaje);
- para iOS: alrededor de 40 pruebas, la ejecución dura unos 30 minutos;
- las pruebas se escriben usando Xamarin.UITest;
- son lanzados automáticamente por compilaciones en TFS, en el mismo lugar en TFS monitoreamos los resultados de las ejecuciones.
Un poco sobre Xamarin.UITest
Este es un marco para pruebas automáticas de IU para proyectos en Xamarin.iOS y Xamarin.Android (también se anuncia soporte para Objective-C / Swift y Java). Las pruebas se escriben en C # usando NUnit. Los proyectos de contenido se pueden integrar fácilmente.El principio del funcionamiento del marco se basa en dos componentes: buscar un elemento (Consultas) y realizar cualquier acción con él (Acciones), por ejemplo, presionar o ejecutar un deslizamiento.Aquí, por ejemplo, hay una prueba que verifica la visualización del error al ingresar un inicio de sesión no válido:public void ShowErrIncorrectLoginOrPassword_IfLoginIsWrong()
{
var wrongLogin = TestsSettings.UserLogin + "1";
app.EnterLoginAndPassword(wrongLogin, TestsSettings.UserPassword);
app.WaitForElement(Resources.Identifiers.ErrorMessage, "Login is incorrect, alert message wasn't shown.", TestsSettings.Delay);
Assert.AreEqual(CoreResources.ErrIncorrectLoginOrPassword, ErrorMessage);
}
private string ErrorMessage =>
app.Query(x => x.Marked(Resources.Identifiers.ErrorMessage)).First().Text;
El método de entrada de credenciales utilizado en él:public static void EnterLoginAndPassword(this AndroidApp app, string login, string password)
{
app.WaitForElement(Resources.Identifiers.LoginEdit, TestsSettings.Delay);
app.EnterText(Resources.Identifiers.LoginEdit, login);
app.EnterText(Resources.Identifiers.PasswordEdit, password);
app.Tap(Resources.Identifiers.LoginButton);
}
En este ejemplo, se utilizan los métodos de marco estándar: esperar un elemento, ingresar texto, hacer clic en un elemento.Al desarrollar y depurar pruebas, es conveniente usar la utilidad de consola integrada REPL (read-eval-print-loop), que le permite ver el árbol de elementos que se encuentran ahora en la pantalla, así como también realizar métodos de marco estándar.Ser inesperado para nosotros
Abordar los elementos de la interfaz a veces no condujo a lo que esperábamos.Por ejemplo, cuando se abre una nueva ventana en una aplicación con un fragmento en la misma actividad, el usuario solo ve esta nueva ventana en la pantalla. Pero en este caso habrá elementos en el árbol de elementos visibles que el usuario ahora no puede ver con sus ojos. La búsqueda de dicho elemento "invisible" será exitosa, y puede realizar una acción con él. Eso es solo un clic que se ejecutará en la ventana que ve el usuario. Aquellos. de hecho, será un falso positivo.El árbol puede contener varios elementos idénticos; de forma predeterminada, la acción se realizará con el primer elemento adecuado del árbol. Y si en una prueba accedió a un elemento a través de una etiqueta, y luego tiene un elemento con la misma etiqueta en algún lugar, la prueba comenzará a caer (o tal vez no si el elemento que necesita es el primero).Tuvimos un caso cuando una prueba escrita y depurada cayó en el primer lanzamiento de combate. Porque las pruebas se ejecutaron en un dispositivo con un tamaño de pantalla diferente. Y el elemento en el que se hizo clic en este dispositivo apareció debajo de otro elemento de interfaz.
La carpeta Bandeja de salida estaba debajo del botón Crear tarea, y al hacer clic en la carpeta en este caso, se hizo clic en el botón. Esta es una situación familiar para el usuario, simplemente desplazará la pantalla. Pero en el árbol de elementos esta superposición no es visible.Tales problemas causan inconvenientes menores y lo hacen pensar detenidamente en algunas pruebas. Y a veces simplemente ajustamos los datos en la base de datos para que nada interfiera con la prueba. Después de todo, el objetivo en este ejemplo es abrir una carpeta y no verificar que nada impida su apertura.Otra sorpresa y decepción fue la incapacidad de ejecutar y depurar pruebas de iOS desde Visual Studio para Windows. Esta característica aún no se ha implementado. Tengo que trabajar en el estudio para MacOS.Algunos resultados del capitán
Implemente la automatización si tiene sentido.Deje que sus pruebas tengan un mínimo de configuraciones, deje que se ejecuten manualmente y solo una vez al mes, pero si resuelven sus problemas y lo ayudan, ¿por qué no?Bueno, no te olvides del principio de la pirámide.