Clasificación de pruebas de software
Las pruebas de software son una ingeniería de sistemas compleja. Puede haber diferentes métodos de división desde diferentes perspectivas. El propósito de clasificar las pruebas es aclarar mejor el proceso. qué debe lograr exactamente la prueba y tratar de lograr una prueba integral.
1. Según la perspectiva de si es necesario ejecutar el software bajo prueba.
Se puede dividir según la perspectiva de si es necesario ejecutar el software bajo prueba. en pruebas estáticas y pruebas dinámicas. El primero no utiliza una computadora para ejecutar el programa de prueba y utiliza otros medios para lograr fines de prueba, como la revisión del código. (Creo que principalmente permite a los evaluadores analizar errores potenciales que el compilador no puede encontrar, como bucles infinitos no válidos, variables redundantes, etc.), mientras que las pruebas dinámicas logran su propósito ejecutando el software probado.
2. Dividido por etapas:
1 Prueba unitaria
La prueba unitaria es una prueba de los componentes básicos del software, como un módulo y un proceso. etc. Es la parte más básica y una de las más importantes de las pruebas dinámicas de software. Su propósito es probar la corrección de los componentes básicos del software. Debido a que las pruebas unitarias requieren un conocimiento detallado de la programación y codificación interna, generalmente deben ser completadas por programadores en lugar de evaluadores. A menudo es necesario desarrollar módulos de controlador de prueba y módulos auxiliares para ayudar a completar las pruebas unitarias. Por lo tanto, es particularmente importante que el sistema de aplicación tenga una arquitectura bien diseñada.
La exactitud de una unidad de software está relacionada con las especificaciones de la unidad. Por lo tanto, las pruebas unitarias se comparan con el protocolo de la unidad que se está probando. Los principales métodos de pruebas unitarias incluyen pruebas de flujo de control, pruebas de flujo de datos, pruebas de depuración, pruebas de dominio, etc.
2 Pruebas de integración
Las pruebas de integración son una prueba realizada durante el proceso de integración de sistemas de software. Su objetivo principal es comprobar si las interfaces entre unidades de software son correctas. Combina módulos u otras unidades de software en sistemas cada vez más grandes de acuerdo con el plan de prueba de integración, mientras ejecuta el sistema para analizar si el sistema compuesto es correcto y si los componentes encajan entre sí. Hay dos estrategias principales para las pruebas de integración: de arriba hacia abajo y de abajo hacia arriba.
3 Pruebas del sistema
Las pruebas del sistema son una prueba exhaustiva del sistema de software integrado para verificar que la corrección y el rendimiento del sistema de software cumplen con los requisitos especificados en su protocolo. Que el comportamiento y la salida del software sean correctos no es una tarea sencilla y se conoce como el "problema del profeta" de las pruebas. Por lo tanto, las pruebas del sistema deben realizarse de acuerdo con el plan de pruebas y sus entradas, salidas y otros comportamientos operativos dinámicos deben compararse con la especificación del software. Existen muchos métodos para probar sistemas de software, incluidas pruebas funcionales, pruebas de rendimiento, pruebas aleatorias, etc.
4 Pruebas de aceptación
Las pruebas de aceptación están diseñadas para demostrar a los compradores del software que el sistema de software satisface las necesidades de sus usuarios. Sus datos de prueba suelen ser un subconjunto de los datos de prueba para las pruebas del sistema. La diferencia es que las pruebas de aceptación a menudo cuentan con representantes del comprador del sistema de software en el sitio, incluso en el sitio donde se instala y utiliza el software. Esta es la prueba final del software antes de ponerlo en uso.
5 Pruebas de regresión
Las pruebas de regresión son una prueba que se realiza después de que se modifica el software durante la fase de mantenimiento del software. Su finalidad es verificar que las modificaciones realizadas en el software sean correctas. Aquí, la corrección de la modificación tiene dos significados: primero, la modificación ha logrado el propósito previsto, como corregir errores, poder adaptarse al nuevo entorno operativo, etc., segundo, no afecta la corrección de otros; funciones del software.
6 Pruebas alfa: prueba del sistema de aplicación cuando el desarrollo del sistema está a punto de completarse; después de la prueba, todavía habrá una pequeña cantidad de cambios de diseño. Este tipo de pruebas generalmente las realizan usuarios finales u otro personal, no programadores ni evaluadores.
7 Pruebas Beta: Las pruebas se realizan cuando el desarrollo y las pruebas están esencialmente completos y es necesario encontrar los errores y problemas finales antes del lanzamiento final. Este tipo de pruebas generalmente las realizan usuarios finales u otro personal, no programadores ni evaluadores.
3. Dividido por métodos de prueba:
1 Prueba de caja blanca
La prueba de caja blanca también se denomina prueba estructural o prueba basada en lógica, que se refiere a a las pruebas basadas en el conocimiento de la lógica interna, es decir, basadas en pruebas que cubren todos los códigos, ramas, rutas y condiciones. Es para conocer el proceso de trabajo interno del producto. Las acciones internas del producto se desarrollan normalmente de acuerdo con las especificaciones y las pruebas de acuerdo con la estructura interna del programa, verifican si cada canal del programa puede funcionar correctamente de acuerdo con los requisitos predeterminados, independientemente de su función. Las pruebas de caja incluyen controladores lógicos, pruebas de circuitos base, etc., que se utilizan principalmente para la verificación de software.
El método de la "caja blanca" comprende de manera integral la estructura lógica interna del programa y prueba todas las rutas lógicas. El enfoque de "caja blanca" es una prueba de ruta exhaustiva. Al utilizar esta solución, el evaluador debe examinar la estructura interna del programa y comenzar examinando la lógica del programa para derivar datos de prueba. El número de caminos independientes a través de un programa es astronómico. Pero incluso si se prueban todos los caminos, es posible que todavía haya errores. Primero, las pruebas exhaustivas de ruta nunca pueden detectar que un programa viola las especificaciones de diseño, es decir, el programa en sí es un programa incorrecto. En segundo lugar, las pruebas exhaustivas de rutas no pueden detectar errores debido a rutas omitidas en el programa. En tercer lugar, es posible que las pruebas exhaustivas de rutas no descubran algunos errores relacionados con los datos.
Las pruebas de caja blanca se pueden completar con la ayuda de algunas herramientas como Junit Framework, Jtest, etc.
2 Pruebas de caja negra
Las pruebas de caja negra se refieren a pruebas que no se basan en ningún conocimiento de diseño y código internos, sino que también se basan en requisitos y funcionalidades. Llamada prueba funcional o prueba basada en datos, que se basa en las funciones que debe tener el producto, utiliza pruebas para detectar si cada función se puede utilizar normalmente. Durante la prueba, el programa se considera como un recipiente negro que no se puede abrir. los aspectos internos del programa no se consideran en absoluto. En el caso de la estructura y las características internas, el probador prueba la interfaz del programa. Solo verifica si la función del programa se usa normalmente de acuerdo con la especificación de requisitos y si el programa puede recibir entradas correctamente. datos y producir información de salida correcta, y mantener la integridad externa de la información (como bases de datos o archivos). Los métodos de prueba de caja negra incluyen principalmente división de clases de equivalencia, análisis de valores límite, diagramas de causa-efecto, especulación de errores, etc., que se utilizan principalmente para pruebas de confirmación de software.
El método de la "caja negra" se centra en la estructura externa del programa, no considera la estructura lógica interna y prueba la interfaz y las funciones del software. El método de la "caja negra" es una prueba exhaustiva de entradas. Sólo utilizando todas las entradas posibles como situaciones de prueba se pueden encontrar todos los errores en el programa de esta manera. En realidad, hay un número infinito de situaciones de prueba, y hay que probar no sólo todas las entradas legales, sino también aquellas que son ilegales pero posibles.
Las pruebas de caja negra también pueden utilizar algunas herramientas, como WinRunner, QuickTestPro, Rational Robot, etc.
3 Prueba ALAC (Act-like-a-customer)
La prueba ALAC es un método de prueba desarrollado en base al conocimiento de los clientes que utilizan los productos. Las pruebas de ALAC se basan en el principio de que los productos de software complejos tienen muchos errores. Los mayores beneficiarios son los usuarios, y la búsqueda y corrección de defectos se centrará en aquellos clientes con mayor probabilidad de encontrar errores.