¿Cómo garantizar mejor las pruebas exhaustivas al modificar el módulo público ***?
De hecho, muchos problemas de prueba son causados por el diseño del propio sistema. Por ejemplo, un sistema altamente acoplado siempre afecta a todo el sistema. ¿Cómo les pide a los demás que distingan los módulos públicos? Las interfaces de los paquetes públicos siempre están cambiando. ¿Cómo se mantienen los módulos que llaman a estas interfaces? Los desarrolladores y especialmente los diseñadores a menudo pasan por alto la "capacidad de prueba" del software porque tiene poca visibilidad desde la perspectiva del cliente. ¿Por qué requerimos pruebas en todo momento? Significa que todos deben prestar atención a la "capacidad de prueba" de todos los artefactos enviados desde el principio hasta el lanzamiento. Bien, después de resolver este problema, podemos ver qué estrategias se pueden adoptar desde una perspectiva de prueba, comenzando con pruebas manuales regulares. 1. Suponga que el módulo público cambia el método de implementación pero no cambia la interfaz de firma. Esto es fácil de manejar y se puede realizar mediante pruebas unitarias. Personalmente, siempre creo que un conjunto de pruebas unitarias completo y de alta calidad es crucial para garantizar la calidad del producto. Siempre que pasen 100 de las pruebas unitarias originales, tenemos motivos para confiar en que el código actual seguirá siendo confiable. Riesgo: Bajo 2. Se cambia la interfaz de un único módulo público, pero no afecta las interfaces de otros módulos. Se recomienda realizar un conjunto completo de pruebas unitarias, encontrar todos los módulos con relaciones de llamada del índice y realizar pruebas de integración y pruebas de regresión. Riesgo: Medio 3. Se cambian varios módulos públicos al mismo tiempo, lo cual es común en la reconstrucción de sistemas a gran escala, como la aplicación de nuevos patrones de diseño. Este tipo de cambio no se recomienda como último recurso porque el riesgo es demasiado alto. Si esto realmente sucede, sólo podremos volver a realizar la prueba de la forma más exhaustiva posible en función de la situación real. Se recomienda que al diseñar casos de prueba, los clasifique según su gravedad. Al realizar las pruebas, proceda de mayor a menor para reducir posibles pérdidas. También se recomienda crear índices para casos de uso y módulos de código que deben actualizarse a alta prioridad. Riesgo: Alto 4. Para los nuevos módulos públicos, después de buenas pruebas unitarias y de interfaz, se pueden realizar pruebas integrales del sistema en los casos de prueba con la mayor prioridad, y otros casos de prueba se pueden tratar como los módulos de terceros (asumiendo que no defectos) para manejar. Riesgo: alto Hablando de pruebas automatizadas, normalmente no prestamos especial atención a la sobrecarga de ejecución de las pruebas automatizadas porque a menudo se ejecutan por la noche. Por eso no nos importa mucho la redundancia, pero damos gran importancia a la cobertura y la independencia de los casos de uso. Por ejemplo, las operaciones comunes que realizamos para objetos comerciales son C (aumentar), R (leer), U (escribir) y D (eliminar). Desde una perspectiva de automatización, el escenario de prueba típico es: 1. C-gt; validación 2. C-gt; validación 3. C-gt; validación-gt; validación 4. C-gt; gt ;validation 6. C-gt;D-gt;C-gt;validation Es fácil ver que la redundancia es muy alta. Declaración de derechos de autor: trabajo original, se permite la reimpresión Al reimprimir, asegúrese de indicar la fuente original del artículo, la información del autor y esta declaración en forma de hipervínculo; de lo contrario, se perseguirá la responsabilidad legal.