Si algún director de pruebas está leyendo mi artículo, espera sonreírle al entrevistador; de lo contrario, una vez finalizada la entrevista, 10.000 caballos de barro pasarán corriendo después de salir de la casa. De hecho, el entrevistador no quiere que les des nada. sino una especie de respeto e igualdad. No te sientas súper increíble, cualquier grandullón comienza desde un novato. Por supuesto, aquellos que están aprendiendo técnicas de prueba también deberían estar agradecidos y respetar a todos los entrevistadores por igual.
Preguntas de entrevista de prueba automatizadas 200 preguntas comunes, ¿cuántas puedes responder correctamente?
Sin más preámbulos, las siguientes son preguntas frecuentes en las entrevistas de prueba de software, organizadas de la siguiente manera:
1. Encontró un error en la prueba, pero el gerente de desarrollo cree que no es un error, ¿cómo debería solucionarlo?
Primero, envíe el problema a la biblioteca de gestión de defectos para su archivo.
Luego, para obtener las bases y estándares para el juicio:
- Con base en la especificación de requisitos, la descripción del producto, los documentos de diseño, etc., confirmar si los resultados reales son inconsistentes con el plan y proporcionar una base directa para confirmar si se confirman los defectos;
- Si no hay una base documental, puede explicar si existe alguna inconsistencia según las características generales de software similar para confirmar si se trata de un defecto;
- Según los hábitos generales de uso del usuario, para confirmar si se trata de un defecto;
- Discuta con diseñadores, desarrolladores, representantes de clientes y otro personal relevante para confirmar si se trata de un defecto;
- Discusión razonable, explique las razones de su juicio al director de la prueba, sea objetivo y riguroso y no mezcle emociones personales.
Espere a que el director de pruebas tome una decisión final, si aún hay disputas puede informar al superior a través de los canales previstos por la política de la empresa y el superior tomará una decisión.
2. Dado un sitio web, ¿cómo se prueba?
En primer lugar, busque documentos relevantes, como descripciones de requisitos y diseños de sitios web, y analice los requisitos de prueba.
Haga un plan de prueba, determine el alcance de la prueba y la estrategia de prueba, generalmente incluye las siguientes partes: prueba funcional, prueba de interfaz, prueba de rendimiento, prueba de base de datos, prueba de seguridad, prueba de compatibilidad.
Diseño de casos de prueba:
Las pruebas funcionales pueden incluir, entre otros, los siguientes aspectos:
- Pruebas de enlaces. Si el enlace salta correctamente, si hay páginas en blanco y páginas no válidas, y si se devuelven mensajes de error incorrectos.
- Envíe una prueba de la funcionalidad.
- Si los elementos multimedia se pueden cargar y visualizar correctamente.
- Si la compatibilidad con varios idiomas puede mostrar correctamente el idioma seleccionado, etc.
Las pruebas de interfaz pueden incluir, entre otros, los siguientes aspectos:
- Si la página tiene un estilo unificado y es hermosa;
- Si el diseño de la página es razonable, si el contenido clave y el contenido candente son destacados;
- Si el control se utiliza normalmente;
- Para los controles que deben instalarse, si se debe proporcionar la función de descarga e instalación automática;
- Verificación de texto.
Las pruebas de rendimiento generalmente consideran los siguientes aspectos:
Pruebas de estrés, pruebas de carga, pruebas de fuerza.
prueba de base de datos
Determinar específicamente si es necesario realizarlo. Las bases de datos generalmente necesitan considerar aspectos como la conectividad, las operaciones de acceso a los datos y la verificación del contenido de los datos.
Pruebas de seguridad:
- Verificación de la funcionalidad de inicio de sesión básica;
- Si hay un error de desbordamiento que provoca que el sistema falle o que se filtren permisos;
- Verifique los problemas de seguridad comunes de los lenguajes de desarrollo relacionados, como la inyección SQL, etc.;
- Si se requieren pruebas de seguridad avanzadas, asegúrese de contar con la ayuda de una empresa de seguridad profesional, subcontratar las pruebas u obtener soporte.
Las pruebas de compatibilidad determinan las combinaciones de plataformas admitidas según el contenido de la descripción de los requisitos:
- Compatibilidad del navegador;
- Compatibilidad del sistema operativo;
- Compatibilidad de plataformas de software;
- Compatibilidad de bases de datos.
Realizar pruebas y documentar defectos. Organice y ajuste razonablemente el progreso de las pruebas, obtenga los recursos necesarios para las pruebas con anticipación y establezca un sistema de gestión (por ejemplo, cambios de demanda, riesgos, configuraciones, documentos de prueba, informes de defectos, recursos humanos, etc.).
Revise, evalúe y resuma periódicamente la prueba y ajuste el contenido de la prueba.
3. Ingresar caracteres chinos en el motor de búsqueda resolverá el nombre de dominio correspondiente ¿Cómo puedo usar LoadRunner para probarlo?
Establecer un plan de prueba, determinar los estándares de prueba y el alcance de la prueba;
Diseñar casos de prueba para escenarios típicos, que abarquen procesos comerciales comunes y procesos comerciales poco comunes, etc.;
Desarrolle escenarios y scripts de prueba automáticos basados en casos de prueba:
Grabar script de prueba : cree un nuevo script (protocolo Web/HTML); haga clic en el botón de grabación e ingrese "about:blank" en la URL del cuadro de diálogo emergente; finalice la grabación después de realizar el proceso de operación normal en el navegador abierto. ; depurar el script y guardarlo, es posible que deba prestar atención a la asociación del conjunto de caracteres.
Establecer escenarios de prueba : Establezca escenarios de prueba para el rendimiento, principalmente para determinar si el tiempo promedio de respuesta de las transacciones del sistema cumple con el estándar en circunstancias normales; establezca escenarios de prueba para cargas de presión, principalmente para determinar si el sistema está a plena carga o excede la capacidad de carga del sistema. durante mucho tiempo Si el sistema fallará, ejecute la prueba, obtenga el resultado de la prueba, analice el resultado de la prueba.
4. ¿Cuál es la diferencia entre un cliente con 300 clientes y 300 clientes con 300 clientes presionando al servidor?
300 usuarios en un cliente ocuparán más recursos del cliente y afectarán los resultados de la prueba. Puede producirse interferencia entre subprocesos, lo que dará lugar a algunas excepciones.
300 usuarios en un cliente requieren más ancho de banda.
Para problemas de dirección IP, es posible que necesite utilizar IP Spoof para evitar el límite del servidor en la cantidad máxima de conexiones para una sola dirección IP.
Todos los usuarios están en un cliente, por lo que no es necesario considerar cuestiones de administración distribuida; si bien los usuarios están distribuidos en diferentes clientes, es necesario considerar el uso de un controlador para implementar usuarios en diferentes clientes. Al mismo tiempo, se deben proporcionar la configuración de permisos y la configuración del firewall correspondientes.
5. Describe los conceptos y características del software. ¿Qué significa la reutilización de software? ¿Cuáles son los componentes?
El software es otra parte del sistema informático que es interdependiente con el hardware, los programas informáticos, los procedimientos, las reglas y los posibles archivos, documentos y datos relacionados con el funcionamiento del sistema informático.
La reutilización de software (SoftWare Reuse) consiste en utilizar todo tipo de conocimientos relevantes del software existente para crear software nuevo, a fin de reducir el costo de desarrollo y mantenimiento del software. La reutilización de software es una tecnología importante para mejorar la productividad y la calidad del software. Al principio la reutilización de software era principalmente reutilización a nivel de código, y el conocimiento reutilizado se refería específicamente a programas. Posteriormente, se amplió para incluir conocimiento del dominio, experiencia en desarrollo, decisiones de diseño, arquitectura, requisitos, diseño, código, documentación y todos los demás aspectos relevantes. .
Los componentes de software que se pueden reutilizar generalmente se denominan componentes reutilizables .
6. ¿Cuál es el ciclo de vida del software y su modelo?
El ciclo de vida del software (Ciclo de vida del software) también se denomina ciclo de vida del software y período de supervivencia . Se refiere a todo el proceso desde la formación del concepto de desarrollo de software, después de que se utiliza el software desarrollado, hasta que pierde su valor de uso y muere. En términos generales, todo el ciclo de vida incluye tres períodos : planificación (definición), desarrollo y operación (mantenimiento), cada período se divide en varias etapas y cada etapa tiene tareas claras.
Modelo en cascada : Todo esto es comprensible.
Modelo de creación rápida de prototipos : El modelo de creación rápida de prototipos permite el análisis y la definición preliminares, pero no completos, de los requisitos del software en la etapa de análisis de requisitos, y el diseño y desarrollo rápido de un prototipo del sistema de software, que muestra al usuario todas o parte de las funciones y el rendimiento. del software a desarrollar El usuario prueba y evalúa el prototipo, y da sugerencias de mejora específicas para enriquecer y refinar los requisitos del software; los desarrolladores modifican y mejoran el software en base a esto, y completan la implementación, prueba y mantenimiento del software hasta el El usuario está satisfecho y aprobado.
Modelo de iteración : una iteración incluye todas las actividades de desarrollo que conducen al lanzamiento de un producto (una versión estable y ejecutable del producto) y todos los demás elementos periféricos necesarios para utilizar esa versión. En cierto modo, una iteración de desarrollo es un proceso completo que consiste en pasar por todos los flujos de trabajo: análisis de requisitos, diseño, implementación y flujos de trabajo de prueba. En esencia, es similar a un proyecto de pequeña cascada. RUP cree que todas las fases se pueden dividir en iteraciones. Cada iteración produce un producto entregable, que es un subconjunto del producto final.
Fases del ciclo de vida:
- Análisis y planificación de viabilidad del software.
- análisis de la demanda
- diseño de software
- codificación
- prueba de software
- Operación y mantenimiento
7. ¿Qué son las pruebas de software? El propósito y los principios de las pruebas de software.
El proceso de operar un programa bajo condiciones específicas para encontrar errores del programa, medir la calidad del software y evaluar si puede cumplir con los requisitos de diseño.
Propósito de las pruebas de software:
- El testing es el proceso de ejecución de un programa con el propósito de encontrar errores;
- Un caso de prueba exitoso consiste en descubrir errores hasta ahora no descubiertos;
- Una prueba exitosa es aquella que encuentra errores hasta ahora no descubiertos;
- Asegurar que el producto cumpla con las funciones prometidas o anunciadas y que las funciones a las que los usuarios puedan acceder tengan instrucciones escritas claras;
- Garantizar que los productos cumplan con los requisitos de rendimiento y eficiencia;
- Asegúrese de que los productos sean robustos y adaptables a los entornos de usuario.
Principios de las pruebas de software:
- Una parte esencial de un caso de prueba es definir el resultado esperado o la adquisición;
- Los programadores deben evitar probar los programas que escriben;
- Las organizaciones que escriben software no deberían probar el software que escriben;
- Los resultados de cada ejecución de prueba deben revisarse minuciosamente;
- Los casos de prueba deben escribirse no sólo basándose en condiciones de entrada válidas y esperadas, sino también en condiciones de entrada no válidas e inesperadas;
- Verificar si el programa "no hace lo que debería hacer" es sólo la mitad de la prueba, la otra mitad de la prueba es verificar si el programa "hace lo que no debe hacer";
- Se deben evitar los casos de prueba desechables a menos que el software en sí sea desechable;
- Los esfuerzos de prueba no deben planificarse con la suposición tácita de que no se encontrarán errores;
- La probabilidad de que haya más errores en una parte de un programa es proporcional a la cantidad de errores que se han encontrado en esa parte;
- Las pruebas de software son un trabajo muy creativo e intelectualmente desafiante.
8. ¿Cuál es la función de la gestión de la configuración del software? ¿Qué incluye la configuración del software?
La gestión de configuración de software ( SCM ) es una técnica para identificar, organizar y controlar cambios. La gestión de la configuración del software se aplica a todo el proceso de ingeniería del software. El cambio es inevitable cuando se crea software, y el cambio exacerba la confusión entre los desarrolladores de software en un proyecto. Los objetivos de las actividades de SCM son identificar cambios, controlar cambios, garantizar que los cambios se implementen correctamente e informar los cambios a otras partes interesadas. En cierto sentido, SCM es una técnica para identificar, organizar y controlar cambios con el fin de minimizar errores y maximizar la productividad.
La configuración del software incluye lo siguiente: identificación de elementos de configuración, gestión del espacio de trabajo, control de versiones, control de cambios, informes de estado y auditoría de configuración.
9. ¿Qué es la calidad del software?
En pocas palabras, la calidad del software es " el grado en que el software se ajusta a los requisitos definidos explícita e implícitamente ". Específicamente, la calidad del software es el grado en que el software se ajusta a los requisitos funcionales y de rendimiento claramente establecidos, a los estándares de desarrollo descritos explícitamente en la documentación y a las características implícitas que todo software desarrollado profesionalmente debería tener. Los principales factores que afectan la calidad del software, estos factores son la medición de la calidad del software desde el punto de vista de la gestión. Se puede dividir en tres grupos, que reflejan respectivamente los tres puntos de vista de los usuarios cuando utilizan productos de software. Corrección, robustez, eficiencia, integridad, disponibilidad, riesgo (operación del producto); comprensibilidad, mantenibilidad, flexibilidad, comprobabilidad (modificación del producto); portabilidad, reutilización, interoperabilidad (Transferencia del producto).
10. ¿Cuáles son los principales métodos de diseño de casos de prueba actuales?
Pruebas de caja blanca : cobertura lógica, cobertura de bucle, cobertura de ruta básica.
Pruebas de caja negra : análisis de valores límite, división de clases de equivalencia, adivinación de errores, diagrama de causa y efecto, diagrama de estado, esquema de prueba, pruebas aleatorias, escenario.
11. ¿Desde qué aspectos se debe probar la seguridad del software?
Las pruebas de seguridad del software incluyen pruebas de seguridad de programas y bases de datos. Las estrategias de prueba varían según los indicadores de seguridad del sistema.
Preguntas a considerar en la prueba de seguridad de autenticación de usuario: distinguir claramente los diferentes permisos de usuario en el sistema, si habrá conflictos de usuario en el sistema, si el sistema causará confusión debido a cambios en los permisos de usuario, si la contraseña de inicio de sesión del usuario es visible , reproducible, si puede iniciar sesión en el sistema de forma absoluta (copie el enlace después de que el usuario inicie sesión e ingrese directamente al sistema), si todas las marcas de autenticación se eliminan después de que el usuario cierra sesión en el sistema, si puede usar el botón Atrás para ingresar al sistema sin ingresar una contraseña, y se debe considerar la prueba de seguridad de la red del sistema. Preguntas, pruebe si las medidas de protección tomadas están correctamente ensambladas, si se aplican los parches relevantes del sistema, simule ataques no autorizados para ver si la protección El sistema es sólido y utiliza herramientas maduras de inspección de vulnerabilidades de red para comprobar las vulnerabilidades relacionadas con el sistema (es decir, utilice las herramientas de ataque de piratas informáticos más profesionales. Intente atacar, ahora las más utilizadas son la serie NBSI y IPhacker IP), utilice varias inspecciones de caballos de Troya. herramientas para verificar la situación del caballo de Troya del sistema y utilizar varias herramientas anti-complementos para verificar las vulnerabilidades de los complementos de varios grupos de programas en el sistema.
Consideraciones de seguridad de la base de datos: si los datos del sistema son confidenciales (por ejemplo, esto es particularmente importante para los sistemas bancarios, los sitios web generales no tienen requisitos altos), la integridad de los datos del sistema (esto existía en el sistema de servicio de verificación de nombre real de la empresa I recién completado Los datos incompletos crean obstáculos para la realización de las funciones del sistema), capacidad de administración de los datos del sistema, independencia de los datos del sistema, capacidades de copia de seguridad y recuperación de los datos del sistema (si la copia de seguridad de los datos está completa, si se puede restaurar y si la restauración se puede completar) ).
12. ¿Qué es un caso de prueba, qué es un script de prueba y cuál es la relación entre los dos?
Un conjunto específico de datos de entrada, operaciones o diversas configuraciones ambientales y resultados esperados proporcionados al sistema bajo prueba para realizar la prueba.
Los scripts de prueba son scripts escritos para pruebas automatizadas.
La redacción de guiones de prueba debe corresponder a los casos de prueba correspondientes.
13. Describa brevemente qué son las pruebas estáticas, las pruebas dinámicas, las pruebas de caja negra, las pruebas de caja blanca, las pruebas alfa y las pruebas beta.
La prueba estática es el proceso de buscar posibles errores en el código del programa o evaluar el código del programa sin ejecutar el programa en sí.
La prueba dinámica consiste en ejecutar el programa bajo prueba, ingresar la instancia de prueba correspondiente, verificar la diferencia entre el resultado de la ejecución y el resultado esperado y determinar si el resultado de la ejecución cumple con los requisitos, a fin de verificar la exactitud, confiabilidad y efectividad de el programa y analizar la eficiencia operativa del sistema y el rendimiento, como la robustez.
Las pruebas de caja negra se utilizan generalmente para confirmar la exactitud y operabilidad de las funciones del software. El propósito es detectar si cada función del software se puede realizar. El programa que se prueba se trata como una caja negra, independientemente de su estructura interna. Después de conocer el programa En el caso de relaciones entre entradas y salidas o funcionalidad del programa, se confía en las especificaciones del software para identificar casos de prueba e inferir la exactitud de los resultados de las pruebas.
La prueba de caja blanca se basa en el análisis de la estructura lógica interna del software. Es una prueba basada en código. Los evaluadores juzgan la calidad del software leyendo el código del programa o utilizando la depuración de un solo paso en las herramientas de desarrollo. Generalmente, la prueba de caja negra Las pruebas de caja las realiza el director del proyecto y los programadores están desarrollando para implementarlas.
La prueba alfa es una prueba realizada por un usuario en un entorno de desarrollo, o puede ser una prueba controlada realizada por usuarios dentro de la empresa en un entorno operativo real simulado.
La prueba Beta es una prueba realizada por múltiples usuarios del software en el entorno de uso real de uno o más usuarios. Los desarrolladores generalmente no están presentes en el sitio de prueba y los programadores o evaluadores no pueden realizar pruebas beta.
14. ¿Qué es el sistema de garantía de calidad del software? ¿Cuáles son las diversas normas relacionadas con la gestión de garantía de calidad en las normas nacionales? ¿Cuáles son sus números y nombres completos?
SQA (SQA-Software Quality Assurance) consiste en un conjunto de procesos y métodos de ingeniería de software para garantizar la calidad (del software). SQA recorre todo el proceso de desarrollo de software y debe incluir revisión de documentos de requisitos, control de código, revisión de código, gestión de cambios, gestión de configuración, gestión de versiones y pruebas de software.
El aseguramiento de la calidad del software es el establecimiento de un enfoque planificado y sistemático para asegurar a la gerencia que los estándares, procedimientos, prácticas y métodos propuestos sean adoptados correctamente en todos los proyectos. El propósito del aseguramiento de la calidad del software es hacer que el proceso del software sea visible para la gerencia. Verifica que el software cumpla con los estándares mediante la realización de revisiones y auditorías de productos y actividades de software. El grupo de garantía de calidad del software participa en el establecimiento de planes, estándares y procesos al comienzo del proyecto. Estos permitirán que el proyecto de software cumpla con los requisitos de la política de la agencia.
15. ¿Cuáles son las características de calidad de los productos de software?
- Funcionalidad: adaptabilidad, precisión, interoperabilidad, cumplimiento, seguridad.
- Fiabilidad: madurez, tolerancia a fallos, fácil recuperación.
- Usabilidad: fácil de entender, fácil de aprender y fácil de operar.
- Eficiencia: características del tiempo, características de los recursos.
- Mantenibilidad: análisis sencillo, cambio sencillo, estabilidad y pruebas sencillas.
- Portabilidad: Adaptabilidad, facilidad de instalación, cumplimiento y fácil reemplazo.
16. ¿Cuál es la estrategia para las pruebas de software?
Estrategia de prueba de software: bajo la guía de ciertos estándares y especificaciones de prueba de software, se especifica una colección de principios, métodos y métodos de prueba de software en función de las limitaciones ambientales específicas del proyecto de prueba.
17. Las pruebas de software se dividen en varias etapas ¿Cuáles son las estrategias y requisitos de prueba para cada etapa?
Correspondiente al proceso de desarrollo, el proceso de prueba pasará por cuatro etapas principales: prueba unitaria , prueba de integración , prueba del sistema y prueba de aceptación .
Pruebas unitarias : las pruebas unitarias son el trabajo de prueba para verificar la exactitud de la unidad más pequeña de diseño de software: un módulo de programa o incluso un segmento de código, generalmente realizado por desarrolladores.
Prueba de integración : La prueba de integración consiste en ensamblar los módulos de acuerdo con los requisitos de diseño para la prueba, el objetivo principal es encontrar problemas relacionados con la interfaz. Dado que el equipo de desarrollo del producto debe realizar una depuración conjunta antes de enviar el producto al departamento de pruebas, las pruebas de integración las realizan los desarrolladores en la mayoría de las empresas.
Pruebas del sistema : Las pruebas del sistema se realizan después de pasar la prueba de integración. El propósito es operar completamente el sistema y verificar si cada subsistema puede funcionar correctamente y completar los requisitos de diseño. La lleva a cabo principalmente el departamento de pruebas, es la prueba más grande e importante del departamento de pruebas y tiene un impacto significativo en la calidad del producto.
Prueba de aceptación : La prueba de aceptación toma la "Especificación de requisitos" en la fase de requisitos como estándar de aceptación y la prueba requiere simular el entorno operativo del usuario real. Para proyectos reales, se puede realizar junto con los clientes y, para productos, es la última prueba del sistema. El contenido de la prueba es una prueba completa de los módulos funcionales, especialmente la prueba de documentos.
Estrategia de prueba de pruebas unitarias:
- Estrategia de prueba unitaria de arriba hacia abajo: mucho más costosa que las pruebas unitarias aisladas, no es una buena opción para las pruebas unitarias.
- Estrategia de prueba unitaria ascendente: una estrategia de prueba unitaria más razonable, pero el ciclo de prueba es más largo.
- Estrategia de prueba unitaria aislada: la mejor estrategia de prueba unitaria.
Estrategia de prueba para pruebas de integración:
- Integración Big Bang: Adecuado para un proyecto de mantenimiento o el sistema bajo prueba es pequeño.
- Integración de arriba hacia abajo: adecuada para estructuras de control de productos que son relativamente claras y estables; las interfaces de alto nivel cambian poco; las interfaces de bajo nivel no están definidas o pueden modificarse con frecuencia; los componentes de control de producción tienen mayores riesgos técnicos y deben verificarse lo antes posible. lo antes posible; espero hacerlo lo antes posible. Puede ver el comportamiento funcional del sistema del producto.
- Integración ascendente: la adaptación a la interfaz de nivel inferior es relativamente estable; la interfaz de alto nivel cambia con más frecuencia; los componentes de nivel inferior se completan antes.
- Ventajas de la integración basada en el progreso: tiene un alto grado de paralelismo y puede acortar efectivamente el progreso del desarrollo del proyecto. Desventajas: la carga de trabajo de los stubs y los controladores es grande; algunas pruebas de interfaz son insuficientes; algunas pruebas se repiten y son un desperdicio.
Estrategia de prueba para pruebas del sistema:
Pruebas de integridad de datos y bases de datos; pruebas funcionales; pruebas de interfaz de usuario; medición del rendimiento; pruebas de carga; pruebas de resistencia; pruebas de capacidad; pruebas de control de acceso y seguridad; pruebas de recuperación y conmutación por error; pruebas de configuración; pruebas de instalación; pruebas de cifrado; pruebas de usabilidad; verificación de versiones pruebas;pruebas de documentación.
18. ¿Qué trabajo se suele realizar en cada fase de las pruebas de software? ¿Cuáles son los archivos de resultados para cada etapa? ¿Que esta incluido?
Etapa de prueba unitaria : cada módulo unitario independiente se prueba de forma aislada de otras partes del sistema. La prueba unitaria realiza una verificación de corrección en cada módulo del programa para verificar si cada módulo del programa implementa correctamente las funciones especificadas. Genere informes de pruebas unitarias y envíe informes de defectos.
Fase de prueba de integración : La prueba de integración se basa en pruebas unitarias. Prueba si el trabajo de cada parte alcanza o realiza los indicadores y estándares técnicos correspondientes durante el proceso de ensamblaje de todas las unidades de software en módulos, subsistemas o sistemas de acuerdo con los requisitos del esquema de especificaciones de diseño actividad requerida. En esta fase, se genera un informe de prueba de integración y se envía un informe de defectos.
Fase de prueba del sistema : el software que haya pasado la prueba de confirmación se utilizará como elemento de todo el sistema informático, combinado con otros elementos del sistema, como hardware informático, periféricos, determinado software de soporte, datos y personal, y se probará en el funcionamiento real. entorno Cobertura funcional integral de los sistemas informáticos. En esta etapa, es necesario enviar el resumen de la prueba y el informe de defectos.
19. ¿Cuáles son las tareas de los probadores en el proceso de desarrollo de software?
1. Encuentre errores en el sistema lo antes posible;
2. Evitar la aparición de defectos en el proceso de desarrollo de software;
3. Medir la calidad del software y garantizar la calidad del sistema;
4. Preste atención a las necesidades del usuario y asegúrese de que el sistema satisfaga las necesidades del usuario.
El objetivo general es: garantizar la calidad del software.
20. En su trabajo anterior, ¿qué se incluía en un registro de defecto (o error) de software? ¿Cómo enviar registros de defectos (errores) de software de alta calidad?
Un registro de error básicamente debería contener:
número de error; nivel de gravedad del error, prioridad; módulo donde ocurre el error; en primer lugar, debe haber un resumen del error, que describa el contenido general del error; la versión correspondiente al error; una descripción detallada del error, incluyendo algunos capturas de pantalla, videos, etc.; error El entorno de prueba cuando aparece y las condiciones generadas corresponden a los pasos de la operación.
Registro de errores de alta calidad:
1) La interfaz de usuario general debe ser unificada y precisa. La interfaz de usuario para informar defectos debe ser coherente con la interfaz de usuario del software probado, lo que facilita su búsqueda y localización.
2) Trate de utilizar los términos y métodos comúnmente utilizados en la industria Utilice los términos y métodos comúnmente utilizados en la industria para garantizar una expresión precisa y profesionalismo.
3) Cada informe de defectos incluye solo un defecto. Cada informe de defectos solo incluye un defecto, lo que permite al reparador de defectos localizar rápidamente un defecto y concentrarse en corregir solo un defecto a la vez. El verificador sólo verifica si se ha corregido correctamente un defecto a la vez.
4) También se deben informar los defectos no reproducibles. En primer lugar, el informe de defectos debe demostrar la capacidad de reproducir el defecto. Los defectos no reproducibles deben reproducirse tanto como sea posible. Si el defecto no se puede reproducir después de todos los esfuerzos, aún así se debe informar el defecto, pero el informe debe indicar que no se puede reproducir y la frecuencia del defecto.
5) Indique claramente el tipo de defecto, basándose en el fenómeno del defecto, resuma y juzgue el tipo de defecto. Por ejemplo, es decir, defectos funcionales, defectos de interfaz, defectos de datos, la racionalización sugiere que este es el defecto o tipo de defecto más común, y otras formas de defectos o defectos también están subordinados a una de las formas.
6) Indique claramente los niveles de gravedad y prioridad de los defectos. Aclare siempre la diferencia entre niveles de gravedad y prioridad. Es posible que no valga la pena resolver los problemas de alta gravedad y los problemas estéticos menores pueden considerarse de alta prioridad.
7) Descripción, ser concisa, precisa y completa, revelar la esencia del defecto, registrar el defecto o el lugar donde ocurre el defecto, la descripción debe reflejar con precisión la esencia del defecto, ser breve y clara. Para facilitar la búsqueda de defectos de prueba específicos en la base de datos de gestión de defectos de software, es una buena práctica incluir la interfaz de usuario (UI) cuando se produce el defecto. Por ejemplo, el título del cuadro de diálogo de registro, el nombre del menú, botón y otros controles.
8) Utilice números de serie numéricos automáticos entre líneas cortas y utilice la misma fuente, tamaño de fuente y espacio entre líneas. Utilice números de serie numéricos automáticos entre líneas cortas y utilice la misma fuente, tamaño de fuente y espacio entre líneas para garantizar que el formato de cada El registro es consistente y estandarizado.
9) Intente registrar solo una operación para cada paso para asegurarse de que sea concisa, organizada y fácil de repetir.
10) Confirme que los pasos sean completos, precisos y breves para garantizar una repetición rápida y precisa de los defectos. "Completo" significa que no hay omisiones, "preciso" significa que los pasos son correctos y "corto" significa que hay sin pasos redundantes.
11) Dependiendo del defecto, puede elegir si desea capturar imágenes. Para observar visualmente el defecto o el fenómeno del defecto, generalmente es necesario adjuntar el defecto o la interfaz donde ocurre el defecto y adjuntarlo como un archivo adjunto al "Adjunto" parte del registro en forma de imagen. Para ahorrar espacio y reflejar verdaderamente el defecto o la esencia del defecto, puede capturar la pantalla completa, la ventana activa y el área local cuando ocurre el defecto o el defecto. Para localizar y corregir rápidamente defectos o ubicaciones de defectos, normalmente es necesario adjuntar un mapa de control chino. Adjunte los documentos especiales necesarios y sugerencias y comentarios personales. Si se produce una falla o defecto como resultado de abrir un documento especial, el documento debe adjuntarse para que la falla o defecto pueda reproducirse rápidamente. En ocasiones, con el fin de que el defecto o corrector de defectos aclare más el defecto o la realización del defecto, se pueden adjuntar sugerencias o comentarios de modificación personal. 12) Revisar defectos ortográficos y gramaticales Antes de enviar cada defecto o defecto, revisa la ortografía y gramática para asegurar que el contenido sea correcto y describir el defecto correctamente. 13) Trate de utilizar frases y oraciones cortas y evite patrones de oraciones complejos. El propósito de la base de datos de gestión de defectos de software es facilitar la localización de defectos. Por lo tanto, requiere descripciones objetivas de los pasos de operación sin la necesidad de modificar el vocabulario y patrones de oraciones complejos. para mejorar la legibilidad sexo. Lo anterior resume los requisitos de especificación para informar defectos de prueba. Dado que los requisitos de prueba del software son diferentes, los evaluadores han acumulado la experiencia de prueba correspondiente después de pruebas a largo plazo y gradualmente desarrollarán buenos hábitos profesionales y agregarán continuamente nuevos requisitos de redacción de especificaciones. Además, puede mejorar constantemente sus habilidades leyendo y estudiando con frecuencia los informes de defectos de prueba de otros ingenieros de pruebas y comparándolos y pensando con sus propios informes de defectos de prueba anteriores. 14) Contenido de la descripción del defecto El contenido de la descripción del defecto puede incluir pasos de operación del defecto, resultados reales y resultados esperados. Los pasos operativos pueden facilitar a los desarrolladores la reproducción de defectos y su corrección. Algunos desarrolladores son muy deficientes en la reproducción de defectos. Aunque entienden los defectos a los que se refiere, no pueden reproducirlos. Especialmente para los nuevos desarrolladores que no están familiarizados con el sistema, introducir los pasos puede facilitarles la tarea. Los resultados reales permiten a los desarrolladores saber qué estaba mal y los resultados esperados permiten a los desarrolladores saber cuál debería ser el resultado correcto.
21. Las pruebas de caja negra y las pruebas de caja blanca son dos métodos básicos de prueba de software. ¿Explique sus respectivas ventajas y desventajas?
Las ventajas de las pruebas de caja negra son: es relativamente simple y no requiere conocimiento del código interno ni de la implementación del programa; no tiene nada que ver con la implementación interna del software; desde la perspectiva del usuario, es fácil de saber. qué funciones utilizará el usuario y qué problemas encontrará; basándose en los documentos de desarrollo de software, también puede saber qué funciones en los documentos implementa el software; es más conveniente cuando se realizan pruebas de software automatizadas.
Las desventajas de las pruebas de caja negra son: es imposible cubrir todo el código y la tasa de cobertura es baja, que sólo puede alcanzar el 30% del volumen total del código; la reutilización de las pruebas automatizadas es baja.
Las ventajas de las pruebas de caja blanca son: ayudar a los probadores de software a aumentar la cobertura del código, mejorar la calidad del código y descubrir problemas ocultos en el código.
Las desventajas de las pruebas de caja blanca son: hay muchas rutas diferentes para la operación del programa y es imposible probar todas las rutas en ejecución; las pruebas se basan en código y solo pueden probar si el desarrollador lo está haciendo correctamente, pero no puede saber si El diseño es correcto o no, y puede haber fugas. Eliminación de algunos requisitos funcionales; cuando el sistema es grande, la sobrecarga de prueba será muy grande.
22. ¿Cómo probar un vaso de papel?
- Funcionalidad: Utilice el vaso de agua para comprobar si hay alguna fuga o si el agua se puede beber.
- Seguridad: No hay venenos ni bacterias en la taza.
- Fiabilidad: El grado de daño de las copas caídas desde diferentes alturas.
- Portabilidad: Si la copa se puede utilizar normalmente en diferentes lugares, temperaturas y otros entornos.
- Compatibilidad: si la taza puede contener jugo, agua, alcohol, gasolina, etc.
- Facilidad de uso: Si la taza está caliente al tacto, si tiene medidas antideslizantes y si es conveniente para beber.
- Documentación de usuario: ¿El manual de usuario proporciona una descripción detallada del uso, restricciones, condiciones de uso, etc. de la copa?
- Prueba de fatiga: Llene la taza con agua (Caso 1) y déjela por 24 horas para verificar el tiempo y la situación de la fuga; llénela con gasolina (Caso 2) y déjela por 24 horas para verificar el tiempo y la situación de la fuga, etc.
- Prueba de presión: use una aguja y siga agregando peso a la aguja para ver cuánta presión penetrará.
23. ¿Cuál es el propósito del trabajo de planificación de pruebas? ¿Qué debe incluir el contenido de un documento de plan de pruebas? ¿Cuáles de estos son los más importantes?
El plan de prueba de software es un documento programático que guía el proceso de prueba; los líderes pueden realizar un macrocontrol y asignar recursos de acuerdo con el plan de prueba; los evaluadores pueden comprender toda la situación de prueba del proyecto y el trabajo a realizar en las diferentes etapas de la prueba del proyecto; es conveniente que otro personal comprenda el contenido del trabajo de los probadores y realice trabajos de cooperación relevantes.
Incluye descripción general del producto, estrategia de prueba, método de prueba, área de prueba, configuración de prueba, ciclo de prueba, recurso de prueba, comunicación de prueba, análisis de riesgos, etc. Con la ayuda del plan de prueba de software, los miembros del proyecto involucrados en la prueba, especialmente los gerentes de prueba, pueden aclarar las tareas y métodos de prueba, mantener una comunicación fluida en el proceso de implementación de la prueba, rastrear y controlar el progreso de la prueba y lidiar con varios cambios en el proceso de prueba.
6 elementos de la redacción del plan de prueba (5W1H):
- por qué - por qué se realizan estas pruebas;
- qué: qué aspectos se prueban y el contenido del trabajo en las diferentes etapas;
- cuándo: las horas de inicio y finalización de las diferentes etapas de la prueba;
- dónde: documentos correspondientes, ubicación de almacenamiento de defectos, entorno de prueba, etc.;
- quién: la composición del personal relevante del proyecto, qué evaluadores están contratados para realizar las pruebas;
- cómo: cómo hacerlo, qué herramientas y métodos de prueba utilizar para las pruebas.
Existe una relación estratégica y táctica entre el plan de prueba y las especificaciones de prueba y los casos de prueba. El plan de prueba planifica principalmente el alcance, el método y la asignación de recursos de las actividades de prueba desde una perspectiva macro, mientras que las especificaciones de prueba y los casos de prueba son los específicos. tácticas para completar la tarea de prueba. Entonces, lo más importante es probar la estrategia de prueba y el método de prueba (preferiblemente se puede revisar primero).
24. ¿Cuáles son los métodos de diseño comunes para casos de prueba en pruebas de caja negra? Utilice ejemplos específicos para ilustrar la aplicación de estos métodos en el trabajo de diseño de casos de prueba.
1) División de clases de equivalencia : la clase de equivalencia se refiere a un subconjunto de un dominio de entrada. Dentro de este subconjunto, cada dato de entrada equivale a revelar errores en el programa. Y es razonable suponer que probar un valor representativo de una clase de equivalencia equivale a probar otros valores de esta clase. Por lo tanto, todos los datos de entrada se pueden dividir razonablemente en varias clases de equivalencia, y un dato de cada clase de equivalencia se toma como condición de entrada de la prueba, de modo que se pueda utilizar una pequeña cantidad de datos de prueba representativos para obtener mejores resultados de la prueba. La división de clases de equivalencia puede tener dos situaciones diferentes: clases de equivalencia válidas y clases de equivalencia no válidas.
2) Análisis de valores límite : es un complemento del método de división de clases de equivalencia. La experiencia laboral en pruebas me dice que una gran cantidad de errores ocurren en los límites de los rangos de entrada o salida, en lugar de dentro de los rangos de entrada y salida. Por lo tanto, diseñar casos de prueba para varios casos extremos puede detectar más errores. Cuando se utiliza el método de análisis de valor límite para diseñar casos de prueba, primero se deben determinar las condiciones límite. Por lo general, los límites de las clases de equivalencia de entrada y salida son las condiciones límite en las que se debe centrar la prueba. Los valores que son exactamente iguales, ligeramente mayores o simplemente menores que el límite deben seleccionarse como datos de prueba, en lugar de valores típicos o valores arbitrarios en la clase de equivalencia como datos de prueba.
3) Método de adivinación de errores : basado en la experiencia y la intuición para especular todos los posibles errores en el programa, a fin de diseñar casos de prueba de manera específica.
La idea básica del método de especulación de errores es enumerar todos los posibles errores en el programa y las situaciones especiales donde es probable que ocurran errores, y seleccionar casos de prueba en función de ellos. Por ejemplo, se enumeraron muchos errores comunes en los módulos durante las pruebas unitarias, errores que se descubrieron en pruebas anteriores del producto, etc. Estos son el resumen de la experiencia. Además, cuando los datos de entrada y los datos de salida son 0, el formulario de entrada está en blanco o el formulario de entrada tiene solo una fila, todas estas son situaciones en las que es probable que se produzcan errores. Se pueden seleccionar ejemplos de estas situaciones como casos de prueba.
4) Método del diagrama de causa y efecto : El método de división de clases de equivalencia y el método de análisis de valores límite presentados anteriormente se centran en considerar las condiciones de entrada, pero no consideran la conexión ni la combinación mutua entre las condiciones de entrada. Considerando la combinación de condiciones de entrada, pueden surgir algunas situaciones nuevas. Pero no es una tarea fácil comprobar la combinación de condiciones de entrada, incluso si todas las condiciones de entrada se dividen en clases de equivalencia, existen bastantes combinaciones entre ellas. Por lo tanto, es necesario considerar el diseño de casos de prueba en una forma adecuada para describir la combinación de múltiples condiciones y, en consecuencia, generar múltiples acciones. Esto requiere el uso de diagramas de causa y efecto (modelos lógicos). El producto final generado por el método del diagrama causal es una tabla de decisiones. Es adecuado para comprobar varias combinaciones de condiciones de entrada del programa.
5) Método de análisis de tabla ortogonal : debido a la combinación de una gran cantidad de parámetros, el número de casos de prueba puede aumentar y, al mismo tiempo, no existe una brecha obvia en la prioridad entre estos casos de prueba y los evaluadores no pueden completar una cantidad tan grande. número de pruebas. , algunos casos de uso se pueden reducir a través de la tabla ortogonal, para lograr la posibilidad de cubrir un rango lo más grande posible con la menor cantidad de casos de uso posible.
6) Método de análisis de escenarios : se refiere a la simulación de los pasos de operación del usuario en función de los escenarios del usuario. Esto es similar a un diagrama de causa y efecto, pero puede tener una mejor profundidad y viabilidad de ejecución.
7) Método del gráfico de estados : obtenga todos los estados del sistema bajo prueba a través de condiciones de entrada y descripciones de requisitos del sistema, y obtenga condiciones de salida a través de condiciones y estados de entrada; obtenga casos de prueba para el sistema bajo prueba a través de condiciones de entrada, condiciones de salida y estados.
8) Método de esquema : El método de esquema es un método que se centra en los requisitos. Para enumerar varias condiciones de prueba, los requisitos se convierten en un formulario de esquema. El contorno se representa como una estructura de árbol con una ruta única entre la raíz y cada nodo de hoja. Cada ruta en el esquema define un conjunto específico de condiciones de entrada que se utilizan para definir el caso de prueba. La cantidad de hojas en el árbol o caminos en el esquema proporciona una cantidad aproximada de casos de prueba necesarios para probar todas las funciones.
25. Describa en detalle el proceso completo de una actividad de prueba. (Como referencia, esta respuesta se basa principalmente en el modelo en cascada)
El director del proyecto se comunica con el cliente para completar el documento de requisitos, y los desarrolladores y evaluadores completan conjuntamente la revisión del documento de requisitos. El contenido de la revisión incluye: dónde la descripción de los requisitos no es clara y dónde puede haber conflictos obvios o funciones irrealizables . El director del proyecto completa el plan del proyecto integrando las opiniones de desarrolladores, evaluadores y clientes. Luego SQA ingresa al proyecto e inicia las estadísticas y el seguimiento.
Los desarrolladores completan el documento de análisis de requisitos de acuerdo con el documento de requisitos y los evaluadores realizan una revisión. El contenido principal de la revisión incluye si existen omisiones o diferencias en el entendimiento entre las dos partes. El evaluador completa el documento del plan de prueba y el contenido incluido en el plan de prueba se describe arriba.
Los evaluadores comienzan a escribir casos de prueba basados en el documento de análisis de requisitos modificado, mientras que los desarrolladores completan el documento de diseño general y el documento de diseño detallado. Estos dos documentos se convierten en materiales complementarios para que los evaluadores escriban casos de prueba.
Una vez completados los casos de prueba, es necesario revisar las pruebas y el desarrollo.
Los evaluadores configuraron el entorno.
Cuando los desarrolladores envían la primera versión, es posible que queden características sin terminar que deban explicarse. Los evaluadores realizan pruebas y envían errores a BugZilla después de descubrirlos.
El desarrollador envía una segunda versión, que incluye correcciones de errores y funciones adicionales, para que las prueben los evaluadores.
Repita el trabajo anterior, generalmente después de 3 o 4 versiones de prueba, se reducirá la cantidad de ERRORES y se cumplirán los requisitos de envío.
Si los clientes informan problemas, los evaluadores deben ayudar a reproducir y volver a probar.
26. Proceso de seguimiento de la herramienta de gestión de BUG (usando BugZilla como ejemplo)
El evaluador descubre un ERROR y lo envía a Bugzilla, el estado es nuevo y el destinatario del ERROR es el personal de la interfaz de desarrollo.
La interfaz de desarrollo asigna el ERROR al desarrollador del módulo correspondiente y cambia el estado a asignado. El desarrollador y el evaluador confirman el ERROR. Si es mi propio ERROR, se configura para recibirlo; si es el problema de otro desarrollador , se reenvía, queda en manos del siguiente desarrollador llevar a cabo este comportamiento, si no se considera un problema, todos deben discutirlo y confirmarlo, rechazar el ERROR y luego el tester cierra el problema.
Si el desarrollador acepta el ERROR y lo modifica, cambia el estado del ERROR a solucionado e informa la versión en la que se puede probar la prueba.
Los evaluadores prueban la nueva versión y, si descubren que el problema persiste, se negarán a verificar; si se ha solucionado, cerrarán el ERROR.
27. En su opinión, durante el proceso de comunicación entre testers y desarrolladores, ¿cómo mejorar la eficiencia y eficacia de la comunicación? ¿Cuál es la clave para mantener buenas relaciones interpersonales entre los evaluadores y otros miembros del equipo de desarrollo?
Trate de comunicarse cara a cara tanto como sea posible y, en segundo lugar, pueda comunicarse directamente por teléfono. Si solo puede comunicarse por correo electrónico y otras herramientas de comunicación no oportunas, enfatice que debe tener un conocimiento profundo de las características. y poder expresarlos con claridad.
También es un método más eficaz utilizar algunas herramientas de gestión de pruebas como TestDirector para la gestión. Al mismo tiempo, se debe prestar atención a las descripciones precisas de los errores en TestDirector.
Preste atención a los siguientes puntos para establecer una buena comunicación entre los evaluadores y los desarrolladores del equipo:
El primero es la sinceridad, el segundo es el espíritu de equipo, el tercero es tener un lenguaje común en la profesión y el cuarto es tratar las cosas en lugar de las personas y anteponer el trabajo.
Por supuesto, también puede aumentar el favor de la otra parte señalando algunos problemas menores directamente en lugar de ingresar al sistema de seguimiento de errores.
28. ¿Cuál es tu mayor interés en las pruebas? ¿Por qué?
No existe una respuesta fija y unificada para esta pregunta de la entrevista, pero muchas empresas pueden formularla. Se proporcionan las siguientes respuestas para su revisión:
- El mayor interés es que este es un trabajo desafiante;
- Las pruebas son una industria basada en la experiencia. Cuanto más trabaje, más difícil y divertido se sentirá al hacer un buen trabajo en las pruebas;
- A través de su propio trabajo, puede hacer que los productos de software sean cada vez más perfectos y disfrutarlos.
Al responder a estas preguntas, preste atención a los siguientes aspectos:
Exprese su interés lo más cerca posible de la ruta técnica de la empresa de contratación. Por ejemplo, si la empresa es una empresa de aplicaciones de bases de datos, entonces exprese su interés en las pruebas de bases de datos y espere mejorar su dominio de la base de datos a través de las pruebas.
Demuestre que el propósito de sus pruebas es mejorar sus capacidades y hacer un mejor trabajo de prueba; mejorar sus capacidades no tiene como objetivo cambiar al desarrollo u otros campos en el futuro, a menos que el empleador tenga tales acuerdos.
No exprese demasiado su interés fuera del alcance de la empresa de contratación. Por ejemplo, la empresa de contratación está desarrollando software financiero, pero usted ha mostrado interés en el software de juegos; o la empresa de contratación está desarrollando JAVA, pero su interés está en el desarrollo de programas en lenguaje C.
29. ¿Cuáles crees que son las ventajas de realizar pruebas?
No hay una respuesta fija para esta entrevista, pero puedes consultar los siguientes puntos y combinar tus propias características:
Resiliente, paciente, organizado, le gusta enfrentar desafíos, tiene confianza para hacer todo bien, fuertes habilidades de comunicación, buenos comentarios de gerentes anteriores demuestran que estoy haciendo un buen trabajo.
30. Describe brevemente lo que has hecho en tu trabajo anterior y con qué estás familiarizado.
Mi trabajo principal en el pasado eran las pruebas de sistemas y de automatización. En la prueba del sistema, se prueban principalmente la función de lógica de negocios del sistema BOSS y las características de Clase 5 del sistema softswitch. En la prueba de rendimiento, se trata principalmente de una prueba de estrés para obtener el tiempo de respuesta del sistema y el consumo de recursos del sistema bajo diferentes números de solicitudes. Las pruebas automatizadas sirven principalmente para probar las características del softswitch mediante la combinación de scripts escritos por uno mismo y algunas herramientas de terceros.
Al realizar pruebas, creo que es muy importante tener una comprensión completamente precisa de las necesidades del usuario. Además, la gestión de los BUG debe basarse en las necesidades y no es necesario modificar todos los BUG.
Las pruebas requieren paciencia y meticulosidad, porque en la nueva versión, aunque la mayoría de los ERRORES descubiertos originalmente se han solucionado, las funciones correctas originales también pueden volverse incorrectas. Por lo tanto, céntrese en las pruebas iterativas y las pruebas de regresión.