Preguntas frecuentes sobre pruebas de software

1. ¿Qué son las pruebas de software?

El proceso de ejecutar un programa para detectar errores.

2. ¿Cuál es el propósito de las pruebas de software?

Con la menor mano de obra, recursos materiales y tiempo, descubra varios defectos y errores ocultos en el software, mejore la calidad del software y evite riesgos comerciales.

3. ¿Qué es la prueba de documentos de requisitos?

Si existen contradicciones lógicas en los requisitos de la prueba y si los requisitos son técnicamente alcanzables.

4. ¿Qué son las pruebas de documentos de diseño?

Pruebe si el diseño cumple con todos los requisitos y si el diseño es razonable.

5. ¿Qué son las pruebas alfa?

Es una prueba realizada por un usuario en el entorno de desarrollo, o puede ser una prueba controlada realizada por usuarios dentro de la empresa en un entorno operativo real simulado. Las pruebas alfa no pueden ser completadas por programadores o evaluadores. La prueba alfa puede comenzar después de que se complete la codificación del producto de software, o después de que se complete la prueba del módulo (subsistema), o después de que el producto haya alcanzado un cierto nivel de estabilidad y confiabilidad durante la prueba de confirmación.

6. ¿Qué son las pruebas beta?

Pruebas por parte de múltiples usuarios de software en el entorno de uso real de uno o más usuarios. No puede ser hecho por programadores o probadores. La prueba beta se enfoca en la compatibilidad del producto, incluida la documentación, la capacitación del cliente y el soporte de producción para el producto. Las pruebas beta solo se pueden iniciar cuando las pruebas alfa han alcanzado un cierto nivel de confiabilidad.

7. ¿Qué es un módulo de controlador?

El módulo controlador se denomina "programa principal" en la mayoría de los casos, recibe datos de prueba y transfiere estos datos al módulo bajo prueba.

Se utiliza para simular el módulo superior de la unidad bajo prueba y puede llamar al módulo bajo prueba. Durante el proceso de prueba, el módulo controlador acepta los datos de prueba, llama al módulo probado y transmite los datos relevantes al módulo probado.

8. ¿Cuál es la función del módulo controlador?

1) Aceptar la entrada de prueba;
2) Juzgar la entrada;
3) Pasar la entrada a la unidad bajo prueba para conducir la unidad bajo prueba para ejecutar;
4) Aceptar el resultado de ejecución de la unidad bajo prueba y juzgar el resultado;
5) Usar el resultado del juicio como Los resultados de la ejecución del caso de uso se envían al informe de prueba.

9. ¿Qué es un módulo stub?

Se utiliza para simular el módulo inferior llamado durante el proceso de trabajo del módulo bajo prueba. El módulo stub es llamado por el módulo bajo prueba y generalmente solo tiene poco procesamiento de datos.

En las pruebas unitarias, cuando se prueba un módulo, es necesario diseñar un módulo controlador y un módulo auxiliar.

Ejecute la unidad probada, para aislar la unidad, de acuerdo con la interfaz probada, desarrolle el controlador correspondiente y el programa auxiliar.

10. ¿Qué son las pruebas de caja blanca?

Las pruebas de caja blanca, también conocidas como pruebas estructuradas, pruebas basadas en código, son un método de diseño de casos de prueba. Deriva casos de prueba de la estructura de control del programa, que es una prueba de cómo funciona internamente la unidad bajo prueba. La herramienta de prueba de caja blanca es para probar el código fuente. El contenido principal de la prueba incluye análisis léxico y análisis de sintaxis, análisis de errores estáticos, detección dinámica, etc.

11. ¿Qué son las pruebas de caja negra?

La prueba de caja negra también se denomina prueba funcional, que consiste en detectar si cada función se puede usar normalmente a través de la prueba. Las pruebas de caja negra se centran en la estructura externa del programa, independientemente de la estructura lógica interna, y principalmente prueban la interfaz y las funciones del software.

12. ¿Qué son las pruebas estáticas?

La prueba del software mediante la revisión de la documentación, la lectura del código, etc. se denomina prueba estática. El método de prueba estático se refiere a no ejecutar el programa bajo prueba en sí mismo, sino solo verificar la corrección del programa analizando o verificando la sintaxis, estructura, proceso, interfaz, etc. del programa fuente.

13. ¿Qué son las pruebas dinámicas?

La prueba de software mediante la ejecución de programas se denomina prueba dinámica. En las pruebas dinámicas, las pruebas de caja blanca y las pruebas de caja negra generalmente se usan para diseñar casos de prueba desde diferentes perspectivas para encontrar errores en los códigos de software.

14. ¿Qué son las pruebas de regresión?

Una estrategia y un método de prueba para garantizar que la función original es normal cuando se modifica el programa.

15. ¿Cuáles son los métodos de prueba de caja blanca?

Inspección de código, análisis estructural estático, métricas de calidad estática, cobertura lógica, prueba de ruta fundamental, prueba de dominio, prueba de símbolos, cobertura de ruta y variación de programa.

16. ¿Cómo deben dividirse los niveles de defectos de software?

El nivel de defectos de software se puede describir por gravedad y prioridad;
1) Gravedad: mida el grado de satisfacción del impacto de los defectos en la satisfacción del cliente, dividido en
① errores fatales, que pueden causar problemas como anomalías y bloqueos de este módulo y otros módulos relacionados;
②Error grave, el problema se limita a este módulo, lo que hace que el módulo funcione mal o se cierre de forma anormal;
③Error general, falla parte de la función del módulo;
④Módulo sugerido, la persona que propuso el problema debe dar sugerencias para mejorar la prueba módulo;
2) Prioridad: el defecto se elimina La urgencia de la reparación;
① Solución inmediata (nivel P1): El defecto hace que la función del sistema sea casi inutilizable o la prueba no puede continuar, y necesita ser reparada inmediatamente;
② Alta prioridad (nivel P2): el defecto es grave y afecta a la prueba, a la que se debe dar prioridad;
③ Cola normal (nivel P3): los defectos deben ponerse en cola para su reparación con normalidad;
④ Prioridad baja (nivel P4): los defectos se pueden corregir cuando hay tiempo;

17. ¿Cuál es la diferencia entre la prueba de caja blanca y la prueba de caja negra?

1) Pruebas de caja negra: conociendo las especificaciones de diseño funcional del producto, se pueden realizar pruebas para comprobar si cada función implementada cumple con los requisitos.
2) La prueba de caja negra del software significa que la prueba se realiza en la interfaz del software. Este método considera el objeto de prueba como una caja negra, y el evaluador no considera en absoluto la estructura lógica y las características internas del programa, sino que solo verifica si la función del programa se ajusta a la descripción de su función de acuerdo con la especificación de requisitos del programa. programa. Por lo tanto, las pruebas de caja negra también se denominan pruebas funcionales o pruebas basadas en datos.
3) Prueba de caja blanca: conociendo el proceso de trabajo interno del producto, se puede probar para comprobar si cada operación interna cumple con los requisitos de especificación de diseño y si todos los componentes internos han sido inspeccionados.
4) La prueba de caja blanca del software es una inspección detallada de los detalles de procedimiento del software. Este método considera el objeto de prueba como una caja abierta, lo que permite a los probadores usar la estructura lógica interna y la información relacionada del programa para diseñar o seleccionar casos de prueba y probar todas las rutas lógicas del programa. Determine si el estado real es consistente con el estado esperado examinando el estado del programa en varios puntos. Por lo tanto, las pruebas de caja blanca también se denominan pruebas estructurales o pruebas basadas en la lógica.

18. ¿Cuál es el objetivo principal de las pruebas de caja negra para encontrar errores?

1) ¿Hay alguna característica incorrecta o faltante?
2) En la interfaz, ¿se puede aceptar correctamente la entrada? ¿Se puede generar el resultado correcto?
3) Si hay errores de estructura de datos o errores de acceso a información externa (como archivos de datos).
4) Si el desempeño puede cumplir con los requisitos.
5) Si hay errores de inicialización o terminación.

19. ¿Qué comprueban principalmente las pruebas de caja blanca para los módulos de programa?

1) Pruebe todas las rutas de ejecución independientes de los módulos del programa al menos una vez.
2) Para todos los juicios lógicos, las dos situaciones de tomar "verdadero" y tomar "falso" se pueden probar al menos una vez.
3) Ejecutar el cuerpo del ciclo dentro de los límites del ciclo y dentro de los límites de la ejecución.
4) Probar la validez de las estructuras de datos internas.

20. Si puede realizar pruebas de caja negra perfectas, ¿aún necesita pruebas de caja blanca?

1) En primer lugar, las pruebas de software tienen un defecto fatal, es decir, pruebas incompletas e incompletas. Dado que cualquier programa solo puede realizar una pequeña cantidad de pruebas limitadas (en relación con la gran cantidad de pruebas exhaustivas), cuando no se encuentran errores, no se puede decir que no hay errores en el programa. Por lo tanto, no existe una prueba de caja negra perfecta.
2) En segundo lugar, incluso si se realiza una prueba de caja negra perfecta, es imposible probar partes específicas dentro del programa. Además, cuando la especificación en sí es incorrecta, no se puede encontrar el problema.
3) Finalmente, las pruebas de caja blanca pueden realizar pruebas de cobertura en partes internas específicas del programa, por lo que las pruebas de caja blanca y negra son complementarias y es más razonable combinarlas para diseñar casos de prueba. La experiencia muestra que, por lo general, las pruebas de caja blanca se usan para pruebas unitarias, las pruebas de caja gris se usan para pruebas de integración y las pruebas de caja negra se usan para pruebas de sistema.

21. ¿En cuántas etapas se deben dividir las pruebas de software?, describa brevemente los puntos que se deben probar en cada etapa, ¿cuáles son los significados de cada etapa?

1) En términos generales, se puede dividir en pruebas unitarias, pruebas de integración, pruebas del sistema y pruebas de aceptación. Las
pruebas iniciales se centran en cada módulo para garantizar la exactitud del código fuente. Esta etapa se convierte en pruebas unitarias, seguida de la integración del módulo y integración para formar un paquete de software completo. Las pruebas de integración se centran en cuestiones de verificación y composición del programa.
Después de la integración del software, es necesario realizar la validación y las pruebas del sistema. Las pruebas de confirmación proporcionan la garantía final de que el software cumple con todos los requisitos funcionales y de rendimiento. Las pruebas de validación solo aplican el enfoque de pruebas de caja negra.

Hay cinco fases de prueba de software: prueba de unidad, prueba de integración, prueba de sistema, prueba de aceptación y prueba de regresión. Cada etapa se divide en los siguientes cinco pasos: plan de prueba, diseño de prueba, diseño de caso de uso, resultados de ejecución, informe de prueba.
1) Las pruebas unitarias son para probar los componentes básicos del software, como un módulo, un proceso, etc. Es la parte más básica de las pruebas dinámicas de software, y también es una de las partes más importantes. Su propósito es probar los componentes más básicos del software La corrección de las unidades constituyentes. Utilice principalmente el método de prueba de caja blanca.
2) La prueba de integración es una prueba que se lleva a cabo durante el proceso de integración del sistema de software y su objetivo principal es verificar si las interfaces entre las unidades de software son correctas. Se utiliza principalmente el método de prueba de caja negra, complementado por el método de prueba de caja blanca.
3) La prueba del sistema es una prueba exhaustiva del sistema de software integrado, que ha verificado que la corrección y el rendimiento del sistema de software cumplen con los requisitos especificados en su especificación y verifica si el comportamiento y la salida del software son correctos.
4) Las pruebas de aceptación tienen como objetivo demostrar al comprador del software que el software satisface las necesidades de sus usuarios. Sus datos de prueba suelen ser un subconjunto de los datos de prueba de la prueba del sistema.

Prueba de aceptación: se divide en prueba α y prueba β.
Prueba α: es una prueba interna realizada por evaluadores, desarrolladores y personal interno.
Prueba β: es la prueba pública después de la prueba interna y finalmente se entrega al usuario para su prueba.

5) La prueba de regresión es una prueba que se realiza después de modificar el software durante la fase de mantenimiento del software, cuyo propósito es verificar si la modificación del software es correcta.

22. ¿Qué son las pruebas unitarias?

La prueba unitaria, también conocida como prueba de módulo, es una prueba para verificar la corrección de la unidad más pequeña en el diseño de software: el módulo del programa. Las pruebas unitarias necesitan diseñar casos de prueba a partir de la estructura interna del programa. Se pueden probar varios módulos de forma independiente en paralelo.

23. ¿Qué es una prueba de integración?

Las pruebas de integración, también conocidas como pruebas de ensamblaje, generalmente prueban todos los módulos del programa de forma secuencial e incremental sobre la base de pruebas unitarias. Concéntrese en probar la parte de la interfaz de diferentes módulos.

24. ¿Qué es la prueba del sistema?

La prueba del sistema se refiere a probar todo el sistema de software como un todo, incluidas las funciones de prueba, el rendimiento y el entorno de hardware y software en el que se ejecuta el software. La prueba del sistema se lleva a cabo después de que se completa la integración del sistema. En la etapa inicial, prueba principalmente si las funciones del sistema cumplen con los requisitos. En la etapa posterior, prueba principalmente si el rendimiento de la operación del sistema cumple con los requisitos, y la compatibilidad del sistema en diferentes entornos de software y hardware.

25. ¿Qué es una prueba de aceptación?

Las pruebas de aceptación tienen como objetivo demostrar al comprador 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 de la prueba del sistema.

26. ¿Qué son las pruebas de regresión?

La prueba de regresión es una prueba que se realiza después de modificar el software durante la fase de mantenimiento del software. Su finalidad es comprobar que las modificaciones realizadas en el software son correctas.

27. ¿Qué medidas de gestión se toman para los defectos?

1) Introducir herramientas de gestión de defectos.
2) De acuerdo con el ciclo de vida del defecto, considere la gestión del envío del defecto, la gestión del estado del defecto y la gestión del análisis del defecto.
3) Todos los defectos encontrados deben enviarse a la herramienta de gestión de defectos de forma inmediata y precisa, que es la gestión de envío de defectos.
4) Después de enviar el defecto, debe asignarse al desarrollador correspondiente de manera oportuna. La persona que presentó el defecto debe prestar mucha atención al estado del defecto y ayudar a que se resuelva lo antes posible. .
5) Después de que se resuelva el defecto, es necesario verificar la reparación del defecto inmediatamente.
Finalidad: ① solucionar los defectos lo antes posible; ② facilitar el análisis de los defectos más adelante.
6) Para mejorar mejor el proceso de desarrollo y el proceso de prueba, es necesario analizar los defectos, resumir las categorías de defectos, la distribución de edad de los defectos y otra información, que es la gestión del análisis de defectos.

28. ¿Cuál es el enfoque de las pruebas unitarias, las pruebas de integración y las pruebas del sistema?

1) La prueba unitaria es el nivel más bajo de actividad de prueba que se lleva a cabo durante el desarrollo de software, en el que se prueba una unidad independiente de software aislada del resto del programa y el enfoque de la prueba está en los módulos del sistema, incluidos la verificación de corrección de subrutinas, etc.
2) Pruebas de integración, también llamadas pruebas de ensamblaje o pruebas conjuntas. Sobre la base de las pruebas unitarias, todos los módulos se ensamblan en subsistemas o sistemas de acuerdo con los requisitos de diseño y se llevan a cabo las pruebas de integración. La práctica ha demostrado que aunque algunos módulos pueden funcionar de forma independiente, no garantiza que puedan funcionar normalmente cuando están conectados. Es probable que los problemas que no se pueden reflejar localmente en el programa se expongan globalmente, afectando la realización de las funciones. El enfoque de la prueba es la conexión entre módulos y la transferencia de parámetros.
3) La prueba del sistema es ensamblar los subsistemas probados en un sistema completo para la prueba. Es un método efectivo para verificar si el sistema realmente puede proporcionar las funciones especificadas en la especificación del esquema del sistema. Las pruebas se centran en el funcionamiento de todo el sistema y la compatibilidad con otro software.

29. ¿Cuál es la base del método para el diseño de casos de prueba de caja blanca?

Prueba de ruta básica, análisis de valor límite, prueba de cobertura, prueba de bucle, prueba de flujo de datos, prueba de instrumentación del programa, prueba de mutación. La base es la especificación detallada del diseño y su estructura de código.

30. ¿Cuáles son las bases para el diseño de casos de prueba de caja negra?

Pruebas basadas en las necesidades del usuario, método de análisis de diagrama de funciones, método de partición de clase de equivalencia, método de análisis de valor límite, método de adivinación de errores, método de diagrama de causa y efecto, método de análisis basado en tablas de decisión, método de diseño de experimentos ortogonales. La base es la especificación de requisitos del usuario y la especificación detallada del diseño.

Supongo que te gusta

Origin blog.csdn.net/qq_48826058/article/details/124481125
Recomendado
Clasificación