Toda la discusión será muy larga en general, desde el pensamiento automatizado, los modelos, las herramientas hasta las tecnologías de prueba automatizadas, los marcos de prueba y las plataformas de prueba en todos los niveles, incluidas las tecnologías de automatización orientadas al futuro. Además, debido al amplio alcance involucrado, parte del contenido aún es algo profundo. Trato de describir el contexto completamente para que todos puedan entenderlo. Si hay algo que no está claro o es incorrecto (el conocimiento siempre es limitado), por favor corrígeme.
01. Pensamiento de prueba automatizado
Los lectores que me conocen deben saber que estoy acostumbrado a hablar sobre el pensamiento antes de escribir aplicaciones específicas. Porque creo que lo primero que hay que comprender de cualquier cosa es su esencia.Después de comprender la esencia, será mucho más fácil observar el fenómeno. Se puede decir de esta manera: las pruebas de primer nivel se usan como pensamiento, las pruebas de segundo nivel se usan como modelos y las pruebas de tercer nivel se usan como herramientas (la "prueba" aquí es un verbo, no una persona, simplemente palmaditas). ).
Cuando se trata del diseño de un sistema de pruebas automatizado, la reacción de muchas personas es el modelo piramidal. Sin embargo, con el desarrollo de la teoría de la prueba hasta el día de hoy, la aplicabilidad del modelo piramidal ya no es alta (hablaremos de ello en detalle más adelante), no podemos simplemente aferrarnos al modelo antiguo y las ideas antiguas. Los modelos que deben adoptarse en el negocio, o los nuevos modelos que pueden nacer, están todos guiados por el pensamiento de prueba automatizado. Muchos equipos atribuyen el fallo de la aplicación de automatización al error del modelo, que está sesgado. El problema no es el modelo, sino la falta de pensamiento detrás del modelo.
¿ Qué es el pensamiento de prueba automatizado ? El significado literal es hacer que las pruebas funcionen en una forma que la máquina ejecute automáticamente. Todos deberían poder entender este punto, pero el problema radica en la conexión entre las ideas y la práctica. Comprender no significa que lo usarás. . Por ejemplo, ¿piensa que el monitoreo de máquinas en el entorno de producción es una prueba automatizada? Debe serlo, también resuelve el problema de la verificación de errores en la forma de un sistema, sin importar en términos de medios o propósitos, es una especie de prueba automatizada. Entonces, ¿por qué mucha gente todavía piensa que es parte de la operación y el mantenimiento?
Por lo tanto, cuando hablamos de pruebas automatizadas, no debemos limitarnos a las pruebas unitarias, la automatización de la interfaz y la automatización de la interfaz de usuario, sino que debemos considerar si las capacidades de pruebas automatizadas se pueden formar en todos los aspectos, y la entrada y salida después de adoptar esta capacidad. En comparación, haciendo un juicio integral , este es el pensamiento de las pruebas automatizadas. Hasta ahora, la aplicación más exitosa del pensamiento de prueba automatizado, creo que hay dos, una es la tecnología de reproducción de flujo y la otra es la tecnología de automatización que combina el reconocimiento de imágenes y el aprendizaje automático. No te preocupes, hablaré de ello en detalle más adelante.
02. Modelo de prueba automatizado
Cuando se trata de modelos de prueba automatizados, el modelo piramidal debe ser un umbral inevitable, y la proporción de 10->20->70 se considera la regla de oro de la práctica de la automatización. Pero ahora han pasado más de diez años desde que se propuso el modelo piramidal, y la forma comercial actual, la teoría de las pruebas y la tecnología de automatización han sufrido cambios tremendos. Para ser práctico, ¿cuántos de sus equipos utilizan estrictamente este modelo? ¿Es solo porque las ideas domésticas no se han mantenido?
Primero, veamos cuál es el mayor desafío de la automatización. Todos sabemos que el propósito de la automatización es ahorrar costos de mano de obra, por lo que si el costo de la automatización en sí es alto, ¿sigues pensando que tiene sentido? Por supuesto que no. Por lo tanto, desde el pasado hasta el presente, el desarrollo tecnológico de la automatización ha estado luchando con el tema del costo . Recuerde cuidadosamente, reproducción de grabación, reproducción de tráfico, comparación de pantalla, reconocimiento de imágenes, etc., cuál no nació para reducir los costos de automatización. Por lo tanto, la base del modelo piramidal parte de la premisa de que el costo de utilizar este modelo es óptimo debido a las limitaciones técnicas del momento.
现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036
Pero ahora es 2023, la tecnología de reproducción de tráfico hace que la API (de hecho, la reproducción de tráfico se puede usar para múltiples niveles, y lo explicaré más adelante) el costo de la regresión automática es cercano a 0, y el nuevo aprendizaje automático La tecnología basada en el reconocimiento de imágenes también hace que la automatización de la interfaz de usuario El costo de la regresión sea cercano a 0. La adopción de estas dos tecnologías hace que el modelo evolucione directamente hacia una forma de huso o incluso un triángulo invertido.¿Podemos decir que no es razonable? Obviamente no. Por lo tanto, el costo es el elemento central que determina la "forma" del modelo. Ya sea una pirámide, una rueda giratoria o un triángulo invertido, siempre que el ROI sea alto, es un buen modelo .
Además, aunque se trate de una pirámide, los gráficos existentes se dibujan de varias formas. Las pruebas de integración se confunden con las pruebas de interfaz, y las pruebas de interfaz se confunden con las pruebas de extremo a extremo. Por ejemplo, de extremo a extremo, de hecho, se han realizado algunas expansiones al concepto original de "prueba del sistema". Para los servicios Paas/Iaas, el punto final a menudo no es una interfaz sino una interfaz, o simplemente una línea de comando. Así que no podemos pensar que la interfaz es de extremo a extremo, no es lo mismo.
Estrictamente hablando, hay dos tipos de estructuras piramidales: una se basa en la granularidad, como prueba unitaria -> prueba de integración -> prueba del sistema (extremo a extremo); la otra se basa en la profundidad jerárquica, como la capa de dispositivo - > Capa de codificación -> capa de interfaz -> capa de interfaz . Esto no significa que cada capa deba existir y deba analizarse de acuerdo con su propio negocio.
03. Cobertura de prueba automatizada
Después de tener el modelo, ¿solo necesitamos determinar su cobertura de acuerdo con el "gordo y delgado" de cada capa del modelo? ¿O es posible que cuanto mayor sea la tasa de cobertura, mejor? Estamos acostumbrados a tratar cada nivel de automatización por separado y formular sus indicadores de cobertura por separado, poca gente piensa en la relación entre niveles y niveles. Considere el siguiente ejemplo, donde diferentes precios de productos dan diferentes descuentos.Suponga que el código comercial es el siguiente y se empaqueta una interfaz de acceso:
public float getDiscount(float commodityPrice) {
float discount;
if (commodityPrice >= 500.0) {
discount = 0.3;
} else if (commodityPrice >= 300.0) {
discount = 0.2;
} else if (commodityPrice >= 100.0) {
discount = 0.1;
} else {
discount = 0.0;
}
return discount;
}Ya sea que esta lógica sea prueba de código (unidad) o prueba de interfaz, es fácil de implementar. Se pueden realizar cuatro casos de uso (sin considerar los límites y las excepciones por el momento), por lo que la mayoría de las personas buscarán la automatización de las pruebas de código y de interfaz. 100% de cobertura (cuatro códigos + cuatro interfaces), después de todo, el costo no es alto. Pero en términos de efectividad, la redundancia llega al 75%. Debido a que la lógica comercial se ha realizado en la capa de código, para la prueba de la interfaz, solo debemos asegurarnos de que el enlace de la interfaz esté conectado y no es necesario repetir la verificación de cada rama lógica.
Por ejemplo, los purificadores de agua que usamos en casa generalmente tienen de 3 a 5 capas de mallas filtrantes, desde objetos más grandes como sedimentos hasta objetos diminutos como bacterias, cada capa tiene su propósito y función. Si utilizamos el material de filtro más fino de la primera capa, inevitablemente se producirá un desperdicio de material y un aumento de los costos.
Lo mismo es cierto para la automatización de capas. Deberíamos comenzar con la capa con el costo de implementación más bajo (nuevamente, no necesariamente la capa de código) para cubrir tantos casos de uso como sea posible, y luego ordenar las partes que no fueron cubiertas por la capa anterior. según el orden de coste Combinado con las características del propio nivel a complementar. Por lo tanto, la idea de la estratificación automática es en realidad una idea complementaria y no debe verse de forma independiente .
Una cosa que debe recordarse es que no confíe demasiado en la alta cobertura. Por ejemplo el siguiente código:
public float test(float divisor) {
return 100.0/divisor;
}Solo necesitamos test(10.0) para lograr una cobertura del 100 %, pero obviamente el código no maneja el caso de divisor por cero, por lo que no podemos decir que la cobertura del 100 % (código) esté libre de errores. Por lo tanto, la tasa de cobertura se divide en tasa de cobertura comercial y tasa de cobertura de código. También hay muchos métodos que se pueden usar para probar la efectividad, como pruebas de mutación, ingeniería del caos, etc. Dado que no existe una relación rígida entre la efectividad de las pruebas y la automatización, este artículo puede presentar brevemente el contenido relevante y el resto no se explicará demasiado. El contenido de hoy sobre automatización se cubrirá aquí por el momento, continuaremos la próxima semana :)
Los siguientes son materiales de apoyo para el aprendizaje. Para los amigos que hacen [pruebas de software], debería ser el almacén de preparación más amplio y completo. Este almacén también me acompañó en el viaje más difícil. ¡Espero que también pueda ayudarlos!
subprograma de entrevista de prueba de software
¡El banco de preguntas de prueba de software maximizado por millones de personas! ! ! ¡Quién es quién sabe! ! ! El mini programa de cuestionarios más completo de toda la red, puedes usar tu teléfono móvil para hacer los cuestionarios, en el metro o en el autobús, ¡enróllalo!
Se cubren las siguientes secciones de preguntas de la entrevista:
1. Teoría básica de las pruebas de software, 2. web, aplicación, pruebas de funciones de interfaz, 3. red, 4. base de datos, 5. linux
6. web, aplicación, automatización de interfaz, 7. pruebas de rendimiento, 8. conceptos básicos de programación, 9. preguntas de la entrevista de hora, 10. preguntas de prueba abiertas, 11. pruebas de seguridad, 12. conceptos básicos de informática
Método de adquisición de información:
