1. ¿Qué son las pruebas de caja blanca y las pruebas de caja negra? ¿Qué son las pruebas de regresión?
Las pruebas de caja blanca requieren comprender la estructura interna del software y probar si el código implementa las funciones correctamente.
La prueba de caja negra consiste en comprobar si la función del programa cumple con las especificaciones de requisitos sin conocer la estructura interna del software.
La primera prueba de regresión consiste en comprobar si la modificación ha logrado el propósito previsto, por ejemplo, si el error se ha corregido y se puede adaptar al nuevo entorno operativo. En segundo lugar, no afecta la corrección de otras funciones del software.
2. ¿Cuál es el enfoque de las pruebas unitarias, las pruebas de integración y las pruebas de sistemas?
El objetivo de las pruebas unitarias son los módulos del sistema, incluida la verificación de la corrección de las subrutinas.
Las pruebas de integración se centran en las conexiones entre módulos y el paso de parámetros.
El objetivo de las pruebas del sistema es el funcionamiento de todo el sistema y su compatibilidad con otro software.
3. ¿Cuáles son los métodos y las bases para diseñar casos de uso?
Los siguientes métodos se utilizan para diseñar casos de prueba de caja blanca: pruebas de ruta básica, división de clases de equivalencia, análisis de valores límite, pruebas de cobertura, pruebas de bucle, pruebas de flujo de datos, pruebas de instrumentación de programas y pruebas de mutación. En este punto, la base son las especificaciones de diseño detalladas y su estructura de código.
Métodos de diseño de casos de prueba de caja negra: método de división de clases de equivalencia, método de análisis de valores límite, método de inferencia de errores, método de diagrama de causa y efecto, método de diseño de escenarios basado en las especificaciones de demanda del usuario y especificaciones de diseño detalladas.
4. ¿Qué cualidades y habilidades debe tener un ingeniero de pruebas?
Domina la teoría básica de las pruebas
Para probar con la actitud de encontrar problemas en el software, significa ser objetivo y no parecer exigente.
Competente en la lectura de especificaciones de requisitos y otros documentos.
Ver los problemas desde la perspectiva del usuario
Tener un fuerte sentido de la calidad
Ser concienzudo y responsable
Comunicación buena y efectiva ( con desarrolladores y clientes)
Tener experiencia en pruebas
Ser capaz de determinar dónde están las áreas de alto riesgo de manera oportuna y precisa.
5. ¿Cuáles son las estrategias comunes para las pruebas de integración?
Integración big bang; integración de arriba hacia abajo; integración de abajo hacia arriba; integración en capas; integración basada en funciones; integración basada en riesgos;
6. ¿Cuáles son las principales funciones, rendimiento, etc. de las herramientas de prueba que ha utilizado?
7. ¿Cuáles son los componentes de un informe de prueba de defectos?
8. ¿Qué factores se deben considerar al probar un sistema de gestión de información basado en WEB?
A. Pruebas funcionales: pruebas de enlaces, pruebas de formularios, pruebas de cookies, pruebas de lenguajes de diseño y pruebas de bases de datos.
B. Pruebas de rendimiento: prueba de velocidad de conexión, prueba de carga y prueba de estrés.
c Pruebas de usabilidad: pruebas de navegación, pruebas de gráficos, pruebas de contenido y pruebas generales de interfaz.
D. Pruebas de compatibilidad del cliente: pruebas de plataforma y pruebas de navegador.
E. Pruebas de seguridad
9. En comparación con las pruebas funcionales, ¿a qué aspectos se debe prestar atención en las pruebas de localización de software?
10. ¿Cuándo comenzó el proyecto de pruebas de software y por qué?
Debe participar en las pruebas de software durante la etapa de análisis de requisitos, porque el objeto de las pruebas no es solo el código del programa, sino también todos los productos producidos durante el proceso de desarrollo del software, y los defectos del software a menudo se amplifican. Cuanto más tarde se descubren los defectos, más caro resulta repararlos.
11. ¿Cuáles son los requisitos para realizar las pruebas?
Un buen requisito debe tener las siguientes características:
Completitud: Cada requisito debe describir claramente las funciones a implementar para que los desarrolladores puedan obtener lo necesario para diseñar e implementar estas funciones. toda la información necesaria.
Corrección: Cada requisito debe indicar con precisión la funcionalidad a desarrollar.
Coherencia: Coherencia significa que no entra en conflicto con otros requisitos de software o requisitos de alto nivel (sistema, negocio).
Viabilidad: Cada requisito debe ser alcanzable dentro de las capacidades y limitaciones conocidas del sistema y el entorno.
Confusión: Todos los lectores de la descripción del requisito sólo pueden tener una interpretación clara y unificada. Dado que el lenguaje natural puede generar ambigüedad fácilmente, intente expresar cada requisito en un lenguaje conciso y fácil de usar.
Robustez: Si se analizan posibles excepciones en la descripción del requisito y si estas excepciones son tolerantes a fallos.
Necesidad: Se puede entender que cada requisito es la "raíz" utilizada para autorizar la redacción de documentos. Cada requisito que se utilizará se puede rastrear hasta los aportes del cliente, como casos de uso u otras fuentes.
Testabilidad: Cada requisito debe aparecer una sola vez en el SRS. Esto facilita mantener la coherencia al cambiar. Además, el uso de catálogos, índices y listas de referencias cruzadas facilitará la modificación de las especificaciones de requisitos del software.
Trazabilidad: Debería ser posible establecer una cadena de vínculos entre cada requisito de software y sus causas raíz, elementos de diseño, código fuente y casos de prueba. Esta trazabilidad requiere que cada requisito se escriba de forma estructurada y granular y se etiquete individualmente, en lugar de una narrativa a gran escala.
12. Describe brevemente el ciclo de vida del defecto.
13. ¿Cuáles son las precauciones para analizar casos de prueba (elementos)?
A. ¿Por qué escribir casos de uso?
Escribimos casos de prueba, lo que tiene los siguientes beneficios:
Facilita la comunicación del equipo: si un equipo de prueba tiene 10 miembros, cada uno hará lo suyo durante la prueba y no hay estándar unificado. La eficiencia de las pruebas sin duda se reducirá en gran medida; si todos siguieran una especificación de caso de uso unificada, este problema se resolvería.
Pruebas fáciles de repetir: como todos sabemos, el software tendrá diferentes versiones durante el proceso de desarrollo real, como la actualización de 1.0 a 10.0, por lo que si no escribe casos de prueba, podrá recordarlo por completo. al probar la versión 10.0 ¿Qué pruebas se hicieron? Un caso de prueba es como una nota, lo que facilita la repetición de la prueba.
Estadísticas fáciles de rastrear:
Esto es para gerentes de pruebas o gerentes de proyectos. Al verificar el estado de ejecución de los casos de prueba, el líder del proyecto puede conocer la situación general actual del proyecto, como qué pruebas se han ejecutado, qué pruebas no se han ejecutado y qué módulos se concentran principalmente en fallas de prueba.
Facilita la autoevaluación del usuario: especialmente para el software de proyecto, a veces los usuarios quieren probar sus propios productos de software, pero la mayoría de los usuarios no son profesionales y necesitan probar mejor la calidad del producto en función del uso. casos que escribes.
Habiendo mencionado tantas ventajas de los casos de prueba, ¿hay alguna desventaja? Una desventaja obvia es que lleva mucho tiempo. Por lo general, el tiempo para escribir casos de prueba es más largo que el tiempo para ejecutar realmente la prueba, lo cual todos tendrán un conocimiento profundo en el trabajo real.
B. Cuándo escribir casos de prueba
Los casos de prueba deben escribirse lo antes posible. Normalmente, escribimos casos de prueba durante la fase de diseño de la prueba, es decir, después de que se hayan completado la especificación de requisitos y el plan de prueba.
14. ¿Cuáles son los criterios para finalizar la prueba?
Prueba todos los casos de uso; la tasa de cobertura cumple con el estándar; la tasa de defectos cumple con el estándar; otros indicadores cumplen con los estándares de calidad.
；