Análisis de casos de prueba de automatización de UI
Comencemos nuestro viaje analizando un extremo del código del caso de prueba automatizado. La siguiente es una pequeña demostración de una prueba automatizada que escribí antes. Esta demostración está basada en Selenium y Java .
Pequeña demostración de prueba automatizada
Lo que quiere probar es en realidad ver si la búsqueda de Baidu puede devolver el sitio web oficial del Industrial Bank. Analicemos qué contiene este código.
-
Primero, este código contiene localizadores.
Aquellos que están familiarizados con Selenium saben que inpubBox y searchButton son elementos de la página web, instanciados por By.id, y luego el controlador los encuentra a través de sus identificadores, es decir, "kw" y "su" al encontrarElement. Entonces "kw" y "su" son sus localizadores.
locador
-
En segundo lugar, este código contiene datos de prueba.
"Banco Industrial", "Banco Industrial le da la bienvenida" son los datos que se ingresarán para las pruebas.
Datos de prueba
-
La tercera parte es menos intuitiva que las dos primeras.
Este código encuentra el cuadro de entrada basado en "kw", completa las cuatro palabras "Banco Industrial", luego hace clic en el botón de búsqueda para enviar la solicitud de búsqueda y luego busca el texto "Banco Industrial le da la bienvenida" en los resultados de la búsqueda, y luego selecciona si Buscar este texto como estándar para afirmar. Estos pasos de prueba reflejan la lógica empresarial real y el orden no se puede cambiar arbitrariamente. Entonces la tercera parte es la lógica empresarial.
Lógica de negocios
-
La cuarta parte es el funcionamiento específico de cada paso en la lógica empresarial.
Por ejemplo, ingrese un texto determinado o haga clic en un botón, etc. Específico de nuestro ejemplo es enviar claves y hacer clic.
Operación concreta
-
La quinta parte es lo que queda del código de prueba después de extraer las primeras cuatro partes.
Básicamente, es algún código responsable de la preparación o limpieza, como la inicialización del controlador, etc. Yo lo llamo esqueleto de código.
Según el análisis anterior, un caso de prueba automatizado consta de cinco partes: localizador, datos de prueba, lógica empresarial, operación específica y esqueleto de código.
Estructura de prueba de automatización de UI
02. Pruebas automatizadas basadas en datos
Si se extraen los datos de la prueba, la ejecución de la prueba automatizada es impulsada por el cambio de los datos y, finalmente, se cambia el resultado de la prueba, que es la prueba automatizada basada en datos. Para decirlo sin rodeos, es parametrización de datos de prueba .
impulsado por datos
Las pruebas automatizadas basadas en datos son adecuadas para escenarios donde el escenario de prueba y la lógica empresarial son relativamente simples y los cambios no son particularmente grandes, pero los datos de prueba tienen un gran impacto en los resultados de la prueba, o escenarios donde se requiere el mismo escenario de prueba. ser probado a través de una gran cantidad de datos de prueba diferentes. Su método de implementación es relativamente simple, pero debido a que la lógica empresarial todavía está integrada en el código de prueba, la lógica empresarial y el código de prueba todavía están fuertemente acoplados . Una vez que cambia el escenario empresarial, el código de prueba debe modificarse para adaptarse al negocio. cambiar.
Si desea aislar el impacto del negocio en el código de prueba, debe utilizar un enfoque basado en palabras clave .
03. Pruebas automatizadas basadas en palabras clave
En pocas palabras, las pruebas automatizadas basadas en palabras clave se basan en datos, extraen operaciones específicas del código e impulsan la ejecución de pruebas a través de cambios en operaciones específicas.
Las palabras clave mencionadas aquí son en realidad operaciones específicas, como enviar claves y hacer clic en el ejemplo. Sin embargo, dado que las operaciones específicas (palabras clave) se basan en la lógica empresarial, para extraer palabras clave, la lógica empresarial también debe extraerse en conjunto para lograr una verdadera palabra clave. Al mismo tiempo, el objeto de la operación específica es el elemento posicionado por el localizador, por lo que el localizador también debe extraer las excepciones del código para aislar completamente el impacto del negocio en el código.
impulsado por palabras clave
Las pruebas automatizadas basadas en palabras clave son adecuadas para escenarios con escenarios comerciales complejos y numerosos pasos de prueba, o escenarios en los que desea crear una plataforma de prueba unificada. Su mayor ventaja es que los empresarios que no entienden de programación pueden agregar libremente nuevos casos de prueba o modificar casos de prueba existentes cambiando la configuración sin leer el código. Esto es bastante práctico en el desarrollo ágil, puede involucrar a las empresas en la prueba y preparar los casos de prueba lo antes posible; además, el código de prueba está completamente aislado de la lógica de negocios a probar y el mismo código de prueba puede reutilizarse para diferentes aplicaciones. El escenario de prueba reduce el costo del desarrollo repetido. Sin embargo, no está completamente exento de inconvenientes.
-
En primer lugar, no todos los escenarios necesitan ser impulsados por palabras clave.Si algunos escenarios se pueden resolver mediante métodos basados en datos, se deben seleccionar decisivamente los basados en datos en lugar de sobrediseñar;
-
En segundo lugar, debido a que la lógica empresarial está aislada del código, la legibilidad del código se reducirá considerablemente . El código puro básicamente no tiene significado comercial y es básicamente imposible entender el negocio leyendo el código de prueba. La legibilidad del código se sacrifica por la reutilización.
-
En tercer lugar, debido a la reutilización del código, la ejecución de cada caso de prueba es equivalente a una prueba completamente nueva, lo que significa que sin procesamiento adicional, los informes de prueba se cubrirán entre sí y siempre solo se contará el resultado de la ejecución del último caso de prueba. mantenido.
04. Ejemplo de prueba automatizada basada en palabras clave
Esta es una demostración de una prueba automatizada basada en palabras clave que escribí hace mucho tiempo. La idea básica es extraer localizadores, datos de prueba, lógica empresarial y operaciones específicas en un archivo llamado testCase.properties.
El parámetro se utiliza para almacenar las propiedades leídas de testCase.properties, y la clase de prueba principal TestBankIndex controla la ejecución de la prueba leyendo este archivo. La operación específica correspondiente a la palabra clave se coloca en PageAction.
En testCase.Properties, el nombre del caso de prueba se define mediante testCaseNameList, separado por | en el medio. Debajo de testCaseNameList se encuentran los pasos de prueba específicos para cada caso de prueba. Cada nombre de paso de prueba tiene el prefijo del nombre del caso de prueba y su orden es el orden de los pasos de prueba. Luego, el valor del paso de prueba se organiza por operación (palabra clave), método de posicionamiento, expresión de posicionamiento, datos de prueba y tiempo de espera requerido para la prueba, separados por | en el medio. Hay aquí una afirmación especial. Si es una afirmación, habrá una palabra clave que se utiliza para juzgar la afirmación.
testCase.Propiedades
-
El parámetro se utiliza para almacenar las propiedades de testCase.Properties
En realidad, es sólo un simple Java Bean.
Parámetro
-
PageAction se utiliza para definir la operación específica correspondiente a cada palabra clave .
Tomemos el método de búsqueda como ejemplo, pasando el Parámetro para obtener los elementos requeridos por la búsqueda para ubicar el texto de búsqueda que se ingresará, y luego realizar la operación de búsqueda real y esperar un tiempo específico.
Acción de página
-
TestBankIndex es la clase de prueba principal
Pero, de hecho, hay un método testEachCase dentro. Utiliza ampliamente el mecanismo de reflexión de Java para crear instancias y ejecutar métodos. Por tanto, cuando se ejecuta testEachCase no sabe qué caso de prueba ejecutará y qué operación realizará hasta el último momento, estas están completamente definidas en testCase.properties.
Índice del banco de pruebas
Básicamente eso es todo. No hay tiempo para optimizar el código, muchos lugares no están muy estandarizados y no hay pruebas unitarias, el problema de la cobertura del informe de prueba no se ha resuelto, testCase.properties es demasiado pesado y todo está metido en él. Todavía no hay una interfaz de usuario y no existe una operación conveniente. Pero como MVP, básicamente realiza las funciones requeridas por el marco de prueba de automatización de la interfaz de usuario.
La siguiente es la información de respaldo. Para los amigos que hacen [pruebas de software], debería ser el almacén de preparación más completo y completo. Este almacén también me acompañó en el viaje más difícil. ¡Espero que pueda ayudarlos a ustedes también!
Puede obtener un documento de recopilación de entrevistas para ingenieros de pruebas de software de 216 páginas de forma gratuita desde mi cuenta oficial a continuación. ¡Y los videotutoriales de aprendizaje correspondientes se pueden compartir gratis! , que incluye conocimientos básicos, conceptos básicos de Linux, Shell, principios de programas de Internet, base de datos Mysql, temas de herramientas de captura de paquetes, herramientas de prueba de interfaz, pruebas avanzadas: programación Python, pruebas automatizadas web, pruebas automatizadas de aplicaciones, pruebas automatizadas de interfaces, pruebas de integración continua avanzada. marco de prueba desarrollo marco de prueba, pruebas de rendimiento, pruebas de seguridad, etc.
