Introduccion
Anteriormente he compartido un artículo sobre el uso del marco unittest para pruebas de automatización de interfaz, basado en el marco de prueba de automatización de interfaz Python + separación de datos y código (artículo avanzado) , este artículo habla principalmente sobre ideas de diseño y práctica simple. Sin embargo, los editores lucharon por el combate real y cumplieron con las necesidades del proyecto. Como dice el dicho: si simplemente no practicas trucos falsos, muchas personas escriben blogs y obtienen algunos ejemplos pequeños, sienten que han aprendido un conjunto de marcos e incluso sienten que están abiertos. De hecho, de lo contrario, encontrará muchos problemas cuando utilice el proceso, especialmente las interfaces sofisticadas de la compañía y la lógica empresarial compleja. Encontrará que los marcos construidos en el pasado son muchos incompletos y no pueden aplicarse completamente en todos los escenarios. En este momento, necesita optimizar constantemente y perfeccionar en la práctica, lo cual también es muy raro. Debe continuar explorando y aprendiendo en este proceso para mejorar su capacidad.
Prueba de salto de prueba de unidad
En la versión inicial, después de completar el desarrollo de la interfaz de la mayoría de los proyectos, se puede realizar la prueba de la interfaz. En la última parte del proyecto, los casos y scripts de prueba de interfaz bien mantenidos se pueden usar para las pruebas de regresión para liberar tiempo para las pruebas manuales y el diseño de escenarios de prueba de casos de prueba. En vista del patrón de diseño anterior DDT, todos los casos de prueba se ejecutan en su totalidad, ¿qué sucede si quiero ejecutar una parte de los casos de prueba? El uso de la prueba de omisión basada en el marco de unittest:
En circunstancias normales, unittest probará automáticamente cada caso de prueba (el método comienza con test_), pero si desea omitir temporalmente un determinado caso de prueba, hay dos métodos de implementación:
Método 1: use el decorador skipXxx para omitir el caso de prueba , Unittest proporciona un total de 3 decoradores:
@ unittest.skip (razón) ----- representa omisión incondicional;
@ unittest.skiplf (condición, razón) ----- representa omisión cuando la condición es Verdadera;
@ unittest.skipUnless (condición, razón) ------ significa omitir cuando la condición es False.
Método 2: utilice el método SkipTest () de TestCase para omitir casos de prueba
Presentación del caso:
import unittest
class TestHello (unittest.TestCase):
# test say_hello () function
def test_001 (self):
self.assertEqual (1 + 2,3)
print ("test_001: ejecutado")
# test add () function
@unittest. skip ('Temporalmente omitir test_002')
def test_002 (self):
self.assertEqual ((3 + 4), 7)
self.assertEqual ((0 + 4), 4)
self.assertEqual ((-3 + 0), -3)
print ("test_002: ejecutado")
def test_003 (self):
self.skipTest ("temporalmente omitir test_003")
print ("test_003: ejecutado")
if __name__ == '__main__':
unittest.main ( )
Los resultados son los siguientes:
Prueba de omisión de DDT
Lo anterior es la prueba de omisión unittest, y ddt utiliza el marco unittest, que también se puede implementar de esta manera. Sin embargo, no lo presentaré aquí. Yo uso otro método Nuestros datos de prueba se almacenan en archivos de Excel, y las operaciones de lectura y escritura se implementan antes. En este caso, podemos configurar un interruptor para leer los casos de prueba que queremos ejecutar.
Ejemplos:
Agregamos un campo en la plantilla basada en datos: ejecutar, utilizada para controlar la ejecución de casos de uso.
Luego agregue juicio lógico en nuestro programa principal de ejecución:
Resultados de prueba y optimización de registro
Contamos los resultados para que cuando transfiramos, podamos rastrear qué éxitos y fracasos, y las razones del fracaso.
Resultado de la operación:
Imprimir registro:
¿Mira si todos los casos de uso se ejecutan?
Se mantuvo un total de 134-1, y luego se activaron todos los interruptores de ejecución de casos de uso, por lo que el registro en ejecución mostró que el número total fue 133, 133 ejecuciones, 132 éxitos y 1 falla. Dado que los datos de registro detallados implican un acuerdo de confidencialidad, no soy conveniente publicar fotos aquí, por favor, comprenda.
Gráfico dinámico:
Informe de prueba
El informe y los datos impresos de los resultados de la prueba son consistentes, lo que demuestra que no es un problema.
Solución de problemas
Lo anterior está básicamente optimizado para su visualización, luego, para algunas interfaces, empaqueta el campo de resultado ['mensaje'], pero la interfaz que prueba no tiene un campo de mensaje en la cadena json devuelta por todas las interfaces. El desarrollo de cada empresa tiene su propio estilo, si no hay un uniforme, esto es para traer ciertos problemas a la prueba, como la interfaz que encontré, el resultado devuelve resultado ['msg'], y algunos son resultado ['mensaje ']. El método de aserción que usted escribe es afirmarEqual, y se usa uno de ellos, pero hay muchas interfaces, algunas de las cuales no tienen este campo. Si escribe de esta manera, definitivamente informará un error. Así que cambia la lógica de tu código. La forma más simple es usar el juicio condicional directamente y el procesamiento de derivación:
Datos de retorno de la interfaz uno:
Datos de retorno de la interfaz 2:
Como otro ejemplo, por ejemplo, el código que hemos escrito obtiene los datos serializados de la interfaz: la cadena json, pero algunas interfaces no devuelven el formato json y pueden estar en otros formatos, incluso en el proyecto real, encontré Interfaz, los datos devueltos son un valor dinámico o un valor constante. En este momento, la forma de obtener datos es: res.json (). Debe ser un error. Y para valores variables, no puede afirmar, porque no sabe cuál es el resultado esperado, cambia. Pero no está exento de reglas, en cuanto a las reglas, es decir, la lógica generada, después de que necesita comunicarse con el desarrollo, ya sabe, luego escriba esta lógica y finalmente afirme. Este tipo de interfaz por sí sola no es tan simple de hacer. Por lo tanto, generalmente hace pruebas de interfaz y piensa más
Resumen
Lo anterior son los problemas que el marco de prueba automatizado se utiliza en el proyecto real. Estos problemas pueden o no haberse encontrado antes, pero nunca lo ha pensado. Por supuesto, si tiene una mejor manera de lidiar con estos problemas, puede unirse a la prueba Desarrolle e intercambie el grupo QQ para comunicarse y aprender: 696400122. Este grupo se enfoca en el aprendizaje y la comunicación. Todos los productos secos se estudian y se comparten en profundidad con el caso de combate real en el proyecto real como fondo.