Clasificación de prueba de software:
Dividido en: prueba de caja negra, prueba de caja gris, prueba de caja blanca
Prueba de caja negra: también conocida como prueba funcional, prueba basada en datos o prueba basada en especificaciones. La prueba no requiere la comprensión de las condiciones internas del programa, solo la entrada y salida del programa y la función del sistema. Esto se realiza desde la perspectiva del usuario. Prueba.
Prueba de caja blanca: también conocida como prueba estructural, prueba basada en lógica o prueba basada en la provincia del programa. Es más importante que la estructura interna y el algoritmo del programa. Por lo general, no incluye funciones e indicadores de rendimiento. La prueba de caja blanca es una estructura de control basada en el código fuente. , Proceso de procesamiento, etc., para verificar si el procesamiento interno del programa es correcto, incluido el manejo de excepciones, resultados de declaraciones, ramificación, estructura de bucle, etc. Las pruebas de caja blanca generalmente se basan en unidades o módulos; los
principales métodos de prueba de prueba de caja blanca son:
1. Declaración Cobertura: Haga que cada declaración en el programa esté cubierta al menos una vez
2. Cobertura de juicio: Haga que cada juicio en el programa sea al menos verdadero o falso una vez
3. Cobertura condicional: Haga que cada condición en el juicio obtenga varios resultados posibles
4. Cobertura de sentencia / condición: tanto la Cobertura de sentencia como la Cobertura condicional se satisfacen al mismo tiempo
5. Cobertura de combinación condicional: Haga que todas las combinaciones posibles de condiciones en cada sentencia aparezcan al menos una vez.
Prueba de caja gris:
es una tecnología de prueba basada en el rendimiento externo del programa al mismo tiempo y en los resultados lógicos internos del programa para diseñar el caso de uso, ejecutar el programa y recopilar información de ejecución del programa y resultados de la interfaz externa del usuario externo. Esta tecnología de prueba se encuentra entre la prueba de caja negra y la blanca. Entre las pruebas de caja, la prueba de caja gris consiste en métodos y herramientas, que se basan en el conocimiento interno de la aplicación y el entorno con el que se puede usar. Se puede usar en pruebas de caja negra para mejorar la eficiencia de la prueba, la detección de errores y el análisis de casos de error. Eficiencia (la prueba de interfaz es una prueba de caja gris).
Dividido en: prueba estática y prueba dinámica
Prueba estática: no ejecute el código, verifique estáticamente los posibles errores en el código del programa, la interfaz o la documentación, incluida la revisión del código, la verificación de la interfaz de UI, la especificación de la regla de requisitos y la verificación del manual del usuario.
Prueba dinámica: ejecute el código probado, ingrese los datos de prueba correspondientes y verifique si el resultado de salida es consistente con el resultado esperado.
Dividido en: pruebas unitarias, pruebas de integración, pruebas de sistema, pruebas de aceptación.
Pruebas unitarias: probar
las funciones y los módulos del software bajo prueba es la menor granularidad de las pruebas.
Prueba de integración: pruebe
principalmente el problema de la estructura del software. La prueba se basa en la interfaz del módulo, por lo que la prueba de la interfaz se complementa con la prueba de caja blanca. La prueba de integración es una tecnología de prueba del sistema para ensamblar software. De acuerdo con los requisitos de diseño, cada módulo que pasa la prueba de la unidad Reúnanse y realicen pruebas exhaustivas para descubrir varios errores relacionados con la interfaz.
Se deben seguir los siguientes métodos para realizar pruebas de integración:
1. Confirme la relación entre los módulos que conforman un sistema completo.
2. Revise los requisitos de interacción y comunicación entre los módulos y confirme la interfaz entre los módulos.
3. Use la información anterior para generar un conjunto de casos de prueba.
4. Usando pruebas incrementales, agregue módulos al sistema en secuencia y pruebe el sistema recién fusionado.Este proceso se repite en una secuencia lógica / funcional hasta que todos los módulos estén integrados en el sistema para formar un sistema completo.
El principio que sigue a las pruebas de integración: las
pruebas de integración no son fáciles de entender, y la planificación debe iniciarse lo antes posible para el diseño general
1. Todas las interfaces públicas deben ser probadas.
2. Los módulos clave deben ser completamente probados.
3. Las pruebas de integración deben realizarse a cierto nivel.
4. La selección de la estrategia para las pruebas integradas debe considerar la relación entre calidad, costo y cronograma.
5. Las pruebas de integración deben comenzar lo antes posible y basarse en el diseño general.
6. En la división de módulos e interfaces, los probadores deben comunicarse completamente con los desarrolladores.
7. Cuando se modifica la interfaz, la interfaz relacionada debe probarse nuevamente.
8. Los resultados de la ejecución de la prueba deben registrarse con sinceridad.
Prueba del sistema: después de
pasar la prueba de integración, el software se ensambla en un paquete de software completo. En este momento, la prueba del sistema debe llevarse a cabo. La prueba del sistema utiliza completamente la tecnología de prueba de caja negra. Los datos utilizados en la prueba del sistema son tan precisos y representativos como sea posible para simular los datos reales. Sexo
Prueba de aceptación: una vez completada la
prueba del sistema, el software está completamente ensamblado. En este momento, puede comenzar la prueba de confirmación final del software. La prueba de confirmación verifica principalmente si el software puede funcionar de acuerdo con los requisitos del contrato, es decir, si cumple con los requisitos de la especificación de la regla de requisitos de software. .
La prueba de aceptación se centra en si el software cumple con todas las funciones y el rendimiento especificados en el contrato, si la documentación es completa y precisa, y si la interfaz hombre-máquina y otros aspectos (como portabilidad, compatibilidad, capacidad de recuperación de errores y mantenibilidad) cumplen con los requisitos del cliente. .
La prueba de aceptación puede usar la prueba α, β.
- Prueba alfa: se refiere al personal interno de la empresa de desarrollo de software para simular varios comportamientos de los usuarios para probar los próximos productos de software. Los productos de software que se han sometido a la prueba alfa se denominan versiones beta.
- Prueba beta: la compañía de productos de software organiza a los usuarios típicos para que usen la versión beta en su trabajo diario, y requiere que los usuarios informen condiciones anormales y presenten sugerencias para mejorar, y luego la compañía de desarrollo de software corrige y perfecciona la versión beta. (La compañía de software coloca la versión beta del software en Internet para que los usuarios la descarguen de forma gratuita, y puede probarla durante un cierto período de tiempo, o distribuirla a algunos grupos de clientes potenciales que esperan probar gratis durante un cierto período de tiempo.
Divida otras pruebas: prueba de regresión, prueba de humo, prueba aleatoria
Pruebas de regresión: casos de prueba utilizados al probar la nueva versión del software y ejecutar repetidamente la versión anterior.
Prueba de humo: para cada software recién compilado que necesita ser probado oficialmente, se confirma que las funciones básicas del software son normales. El ejecutivo de humo es generalmente un compilador de versiones u otro personal de I + D.
Prueba aleatoria: en la prueba, los datos de la prueba se generan aleatoriamente, también llamada prueba de mono (prueba de mono).
Algunas desventajas de las pruebas aleatorias:
1. Las pruebas a menudo no son muy ciertas.
2. No se puede alcanzar una cierta tasa de cobertura.
3. Muchas pruebas son redundantes.
4. Debe usar la misma semilla aleatoria para reconstruir la prueba.
Este tipo de prueba aleatoria no es muy útil en muchos casos, a menudo se usa como una "prevención del colapso" o para verificar si el sistema puede permanecer normal cuando se ve afectado negativamente. Robustez, para evitar la generación de grandes cantidades de datos basura y otros medios.
--Extracto de "Competente en pruebas de rendimiento de software y mejores prácticas de Loadrunner"