Dividido de la fase de prueba
| nombre | concepto | método de prueba | Período de planificación |
|---|---|---|---|
| Prueba unitaria (prueba de módulo) | Compruebe si el módulo implementa las funciones y algoritmos especificados en la especificación detallada. Las pruebas unitarias encuentran principalmente errores en la programación de variables y el diseño detallado | Los programadores autoevalúan los módulos escritos por ellos mismos. | El plan de prueba de la unidad debe desarrollarse durante la etapa de diseño detallado |
| Prueba de integración (prueba de montaje) | Pruebe el programa ensamblado de cada módulo, principalmente para encontrar los problemas de interfaz y comunicación entre los módulos | Las pruebas de integración encuentran principalmente errores en la fase de diseño | El plan de prueba de integración debe desarrollarse durante la fase de prueba resumida |
| Prueba del sistema (la última y más completa prueba) | Observe el rendimiento y las funciones del sistema de software desde una perspectiva global. | El plan de prueba del sistema debe desarrollarse durante la etapa de análisis de requisitos. |
La prueba del sistema incluye prueba de confirmación y prueba de aceptación
Prueba de confirmación : verifique si la función, el rendimiento y otras características del software son consistentes con las necesidades del usuario según el manual del software
La prueba de aceptación se divide en prueba (Alfa) y prueba (Beta)
Prueba (Alfa) : La realiza el usuario en las instalaciones del desarrollador, y la prueba se realiza bajo el conocimiento del desarrollador. El desarrollador es responsable de registrar los errores encontrados y los problemas encontrados durante el uso. En otras palabras, las pruebas se realizan en un entorno "controlado".
Prueba (Beta) : es implementada por el usuario final del software en el sitio de uno o más usuarios. El desarrollador generalmente no está en el sitio. El usuario es responsable de registrar los errores encontrados y los problemas encontrados durante el uso y reportarlos. problemas para el desarrollador. Es decir, la prueba se realiza en un entorno "no controlado".
Prueba de regresión : el propósito es probar la exactitud de la pieza cambiada y el tipo compuesto de los requisitos cambiados después de que se cambia el software, así como las funciones originales y correctas, el rendimiento y otros requisitos del software.
Dividido del método de prueba
Prueba de caja blanca : (prueba estructural) se utiliza principalmente en la fase de prueba unitaria. Su premisa es que el programa puede considerarse cargado en una caja blanca transparente y el evaluador conoce completamente la estructura y el algoritmo de procesamiento del programa. Este método diseña casos de prueba de acuerdo con la lógica interna del programa y detecta si las principales rutas de ejecución en el programa pueden funcionar normalmente de acuerdo con los requisitos predeterminados.
Tecnología comúnmente utilizada: cobertura lógica, es decir, la cobertura de la lógica del programa cuando se ejecutan los datos de prueba del caso de prueba. Los
principales criterios de cobertura del programa : cobertura de declaración, cobertura de juicio, cobertura de condición, cobertura de juicio / condición, combinado cobertura de condición, cobertura de ruta
Prueba de caja negra : (prueba funcional) se utiliza principalmente para las fases de prueba de integración y prueba de confirmación. Es un software opaco como una caja negra, y la estructura no considera el algoritmo de procesamiento interno (o comprende) el software, solo verifique si el software puede funcionar de acuerdo con la especificación de requisitos de software para uso normal, y si el software puede recibir una entrada de datos adecuada y generar información de salida correcta, si la integridad de la información externa (como archivos y bases de datos) se puede mantener durante la ejecución del software.
Técnicas de uso común: división de clases de equivalencia, análisis de valor límite, diagramas de especulación errónea y de causalidad, etc.