1. Dado un sitio web, ¿cómo lo prueba? (explorar necesidades + formular planes)
Primero, busque documentos relevantes, como la descripción de los requisitos y el diseño del sitio web, y analice los requisitos de prueba.
Desarrolle un plan de prueba, determine el alcance de la prueba y la estrategia de prueba, generalmente incluye las siguientes partes:
Pruebas funcionales; Pruebas de interfaz; Pruebas de rendimiento; Pruebas de bases de datos; Pruebas de seguridad; Pruebas de compatibilidad
Las pruebas funcionales pueden incluir, entre otros, los siguientes aspectos:
prueba de enlace Si el enlace salta correctamente, si hay páginas vacías y páginas no válidas, y si se devuelve un mensaje de error incorrecto.
Envíe una prueba de la función.
Si los elementos multimedia se pueden cargar y mostrar correctamente.
Si el soporte multilingüe puede mostrar correctamente el idioma seleccionado, etc.
Las pruebas de interfaz pueden incluir, entre otros, los siguientes aspectos:
Si el estilo de la página es uniforme y hermoso.
Si el diseño de la página es razonable, si el contenido clave y el contenido atractivo son prominentes.
Si el control funciona normalmente
Para los controles que se requieren pero no se instalan, ya sea para proporcionar la función de descarga e instalación automática
verificación de palabras
Las pruebas de rendimiento generalmente consideran los siguientes dos aspectos:
test de presión;
prueba de carga;
prueba de fuerza
La prueba de la base de datos debe determinarse específicamente si es necesario llevarla a cabo. Las bases de datos generalmente deben considerar la conectividad, las operaciones de acceso a los datos y la verificación del contenido de los datos.
Pruebas de seguridad:
Comprueba la funcionalidad básica de inicio de sesión
Si hay un error de desbordamiento, lo que provoca un bloqueo del sistema o una fuga de permisos
Verificaciones de problemas de seguridad comunes para lenguajes de desarrollo relacionados, como inyección SQL, etc.
Si se requieren pruebas de seguridad avanzadas, asegúrese de obtener ayuda de una empresa de seguridad profesional, externalice las pruebas u obtenga soporte.
Las pruebas de compatibilidad, de acuerdo con el contenido de la descripción del requisito, determinan las combinaciones de plataformas soportadas:
compatibilidad del navegador;
compatibilidad del sistema operativo;
Compatibilidad de plataformas de software;
Compatibilidad de base de datos
Se realizan pruebas y se registran los defectos. Organice y ajuste razonablemente el cronograma de pruebas, obtenga los recursos necesarios para las pruebas con anticipación y establezca un sistema de gestión (por ejemplo, cambios de requisitos, riesgos, configuraciones, documentos de prueba, informes de defectos, recursos humanos, etc.).
Revise, evalúe y resuma regularmente la prueba, y ajuste el contenido de la prueba.
2. ¿Cuál es el método de diseño de caso de prueba principal actual?
Pruebas de caja blanca: cobertura lógica, cobertura de bucle, cobertura de ruta básica
Pruebas de caja negra: análisis de valor límite, división de clase de equivalencia, adivinación de errores, diagrama de causa y efecto, diagrama de estado, esquema de prueba, prueba aleatoria, escenario
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)
3. Describa brevemente qué es la prueba estática, la prueba dinámica, la prueba de caja negra, la prueba de caja blanca, la prueba alfa y la prueba beta.
La prueba estática es el proceso de encontrar 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 realmente 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 generalmente se usan para confirmar la corrección y la operabilidad de las funciones del software. En el caso de las relaciones entre entradas y salidas o funciones del programa, se confía en las especificaciones del software para determinar los casos de prueba e inferir la exactitud de los resultados de la prueba.
La prueba de caja blanca se realiza en base al análisis de la estructura lógica del software. Es una prueba basada en código. El probador juzga la calidad del software leyendo el código del programa o usando la depuración de un solo paso en la herramienta de desarrollo. Generalmente, la prueba de la caja negra la realiza el director del proyecto.Los programadores desarrollan para lograrlo.
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. Las pruebas alfa no pueden ser realizadas por programadores o evaluadores.
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.
4. Las pruebas de software se dividen en varias etapas.¿Cuáles son las estrategias y requisitos de prueba para cada etapa?
En correspondencia con el 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:
Prueba unitaria : la prueba unitaria es el trabajo de prueba para la unidad más pequeña de diseño de software: módulo de programa o incluso segmento de código para verificar la corrección, generalmente realizado por desarrolladores.
Prueba de integración : la prueba de integración es 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, los desarrolladores de la mayoría de las empresas realizan las pruebas de integración.
Prueba del sistema : la prueba del sistema se lleva a cabo después de pasar la prueba de integración, el propósito es ejecutar completamente el sistema, verificar si cada subsistema puede funcionar normalmente y cumplir con los requisitos de diseño. La lleva a cabo principalmente el departamento de pruebas, es la prueba más grande e importante en el 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 real del usuario. 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 del documento.
Estrategia de prueba de prueba unitaria:
Estrategia de pruebas unitarias 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 para pruebas de integración:
Big Bang Integration: adecuado para un proyecto de mantenimiento o el sistema bajo prueba es pequeño
Integración de arriba hacia abajo: adecuada para una estructura de control de productos clara y estable; cambios menores en las interfaces de alto nivel; interfaces de nivel inferior indefinidas o modificadas a menudo; los componentes de control del puerto de producción tienen altos riesgos técnicos y deben verificarse lo antes posible ; esperemos que lo antes posible pueda ver el comportamiento funcional del sistema del producto.
Integración ascendente: la interfaz de nivel inferior es relativamente estable; la interfaz de nivel superior cambia con frecuencia; los componentes de nivel inferior se completan antes.
Integración basada en el progreso
Ventajas: Tiene un alto grado de paralelismo, puede acortar efectivamente el progreso de desarrollo del proyecto.
Desventajas: los pilotes y los hincadores tienen una gran carga de trabajo; algunas pruebas de interfaz son insuficientes; algunas pruebas son repetitivas y inútiles.
Estrategia de prueba para la prueba del sistema:
Pruebas de integridad de datos y bases de datos;
prueba de funcionamiento;
pruebas de interfaz de usuario;
Evaluación del desempeño;
prueba de carga;
prueba de fuerza;
prueba de capacidad;
Pruebas de seguridad y control de acceso;
Pruebas de conmutación por error y recuperación;
prueba de configuración;
prueba de instalación;
prueba de cifrado;
pruebas de usabilidad;
Prueba de verificación de versión;
prueba de documento
5. ¿Qué trabajo se suele realizar en cada fase de las pruebas de software? ¿Cuáles son los documentos finales de cada fase? ¿Que esta incluido?
Etapa de prueba de unidad: cada módulo de unidad independiente se prueba de forma aislada de otras partes del sistema.La prueba de unidad verifica la corrección de cada módulo de programa para verificar si cada módulo de programa ha implementado correctamente las funciones especificadas. Genere informes de prueba de unidad y envíe informes de defectos.
Etapa de prueba de integración: la prueba de integración se basa en la prueba unitaria, probando si todas las unidades de software cumplen o realizan los indicadores técnicos correspondientes y la 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 ha pasado la prueba de verificación se utiliza como un elemento de todo el sistema informático dado, combinado con otros elementos del sistema, como hardware informático, periféricos, algún software de soporte, datos y personal, y se prueba en el entorno operativo real. Cobertura funcional integral de los sistemas informáticos. En esta etapa, se debe enviar el resumen de la prueba y el informe de defectos.
6. ¿Qué se incluye en un registro de defecto (o error) de software?
Un registro de error debe incluir básicamente:
número de error;
nivel de gravedad del error, prioridad;
El módulo generado por el error;
Primero, debe haber un resumen del error, explicando el contenido general del error;
La versión correspondiente al error;
Una descripción detallada del error, incluidas algunas capturas de pantalla, videos, etc.;
El entorno de prueba cuando ocurre el error y las condiciones generadas son los pasos de operación correspondientes;
7. Pruebas de caja negra y pruebas de caja blanca, sus respectivas ventajas y desventajas
Las ventajas de las pruebas de caja negra son: relativamente simple, no es necesario comprender el código interno y la implementación del programa; no tiene nada que ver con la implementación interna del software; desde el punto de vista del usuario, es fácil de saber qué funciones usará el usuario y qué problemas encontrará; con base en el documento de desarrollo de software, también es posible saber qué funciones en el documento implementa el software; es más conveniente cuando se realizan pruebas de automatización de software.
Las desventajas de las pruebas de caja negra son: es imposible cubrir todo el código y la tasa de cobertura es baja, que solo 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 evaluadores 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: habrá muchas rutas diferentes para que se ejecute el programa y es imposible probar todas las rutas en ejecución; la prueba se basa en el código y solo puede probar si el desarrollador lo está haciendo correcto, pero no puede saber si el diseño es correcto o no, y puede pasar por alto algunos requisitos funcionales; cuando el sistema es enorme, la sobrecarga de pruebas será muy grande.
8. ¿Cómo probar un vaso de papel?
Funcionalidad: llene agua en una taza de agua para ver si tiene fugas; si el agua se puede beber
Seguridad: ¿Hay algún veneno o bacteria en la taza?
Fiabilidad: el grado de daño de la taza caída desde diferentes alturas
Portabilidad: si la copa se puede usar normalmente en diferentes lugares, temperaturas y otros entornos
Compatibilidad: si la copa puede contener jugo, agua blanca, alcohol, gasolina, etc.
Facilidad de uso: si la taza está caliente, si tiene medidas antideslizantes y si es conveniente beber
Documentación del usuario: ¿El manual del usuario describe en detalle el uso, las restricciones y las condiciones de uso de la copa?
Prueba de fatiga: Llene el vaso con agua (caso 1) y déjelo durante 24 horas para comprobar el tiempo y la situación de la fuga; llénelo con gasolina (caso 2) y déjelo durante 24 horas para comprobar el tiempo y la situación de la fuga, etc.
Prueba de presión: use una aguja y siga agregando peso en la aguja para ver cuánta presión penetrará
9. ¿Cuáles son los métodos de diseño comunes de casos de prueba para pruebas de caja negra? Aplicación del método en el trabajo de diseño de casos de prueba.
1) División de clase de equivalencia: La clase de equivalencia se refiere a un subconjunto de un dominio de entrada. En este subconjunto, cada dato de entrada es equivalente a revelar errores en el programa. Es razonable suponer que: Probar cierta equivalencia El valor representativo de una clase es igual a la prueba de 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 en cada clase de equivalencia se toma como la condición de entrada de la prueba, y una pequeña cantidad de Datos de prueba representativos Obtenga buenos resultados de prueba La división de clase de equivalencia puede tener dos situaciones diferentes: clase de equivalencia válida y clase de equivalencia no válida.
2) Análisis de valor límite: es un complemento del método de división de clases de equivalencia. La experiencia del trabajo de prueba me dice que una gran cantidad de errores ocurren en el límite del rango de entrada o salida, en lugar de dentro del rango de entrada y salida. Por lo tanto, diseñar casos de prueba para varias condiciones de límite puede detectar más errores.
Para diseñar casos de prueba utilizando el método de análisis de valor límite, las condiciones límite deben determinarse primero. Por lo general, los límites de las clases de equivalencia de entrada y salida son las condiciones límite que deben enfocarse en las pruebas. Valores que son exactamente iguales a, Se debe seleccionar como datos de prueba un poco más o un poco menos que el límite, en lugar de seleccionar 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 sobre 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 adivinación de errores: enumere todos los errores posibles y los casos especiales que son propensos a errores en el programa, y seleccione los casos de prueba en función de ellos. Por ejemplo, muchos errores comunes en los módulos se han enumerado durante las pruebas unitarias. Productos anteriores Los errores encontrados en la prueba, etc., estos son el resumen de la experiencia. Además, los datos de entrada y los datos de salida son 0. El formulario de entrada está en blanco o el formulario de entrada tiene una sola línea. Estas son las situaciones que son propensos a errores Puede elegir estas situaciones El siguiente ejemplo se utiliza como caso de prueba.
4) Método de diagrama de causa y efecto : el método de división de clase de equivalencia y el método de análisis de valor límite presentados anteriormente se enfocan en considerar las condiciones de entrada, pero no consideran la relación entre las condiciones de entrada, combinación mutua, etc. Consideración de la combinación mutua de las condiciones de entrada, se pueden generar algunas situaciones nuevas. Pero no es una tarea fácil verificar la combinación de las condiciones de entrada. Incluso si todas las condiciones de entrada se dividen en clases de equivalencia, hay muchas combinaciones entre ellas. Por lo tanto, es necesario considerar la adopción de un adecuado Para describir la combinación de varias condiciones, en consecuencia generar múltiples acciones para considerar el diseño de casos de prueba. Esto requiere el uso de diagramas causales (modelos lógicos). El resultado final del método de diagrama causal es el tabla de decisión Es adecuado para verificar las condiciones de entrada del programa de varias combinaciones.
5) Método de análisis de tabla ortogonal : puede causar un aumento en la cantidad de casos de prueba debido a la combinación de una gran cantidad de parámetros. Al mismo tiempo, estos casos de prueba no tienen una brecha obvia en prioridad, y los probadores no pueden completar tal gran 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 tan grande como sea posible con la menor cantidad de casos de uso posible.
6) Método de análisis de escenarios : se refiere a simular los pasos de operación del usuario de acuerdo con el escenario del usuario.Esto es similar al diagrama de causa y efecto, pero la profundidad y la factibilidad de ejecución pueden ser mejores.
7) Método de diagrama de estado : obtenga todos los estados del sistema bajo prueba a través de las condiciones de entrada y la descripción de los requisitos del sistema, y obtenga las condiciones de salida a través de las condiciones y estados de entrada; obtenga los casos de prueba del sistema bajo prueba a través de las condiciones de entrada, las condiciones de salida y los 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 esquema. El contorno se representa como una estructura de árbol con una ruta única entre la raíz y cada nodo hoja. Cada ruta en el esquema define un conjunto específico de condiciones de entrada utilizadas para definir casos de prueba. El número de hojas en el árbol o caminos en el esquema da el número aproximado de casos de prueba necesarios para probar toda la funcionalidad.
10. Describa en detalle el proceso completo de una actividad de prueba. (Para referencia, esta respuesta es principalmente la práctica del modelo de cascada)
El gerente del proyecto se comunica con el cliente para completar el documento de requisitos, y los desarrolladores y probadores completan conjuntamente la revisión del documento de requisitos. El contenido de la revisión incluye: lugares donde la descripción de los requisitos no es clara y lugares que pueden tener conflictos obvios o irrealizables. funciones El director del proyecto completa el plan del proyecto integrando las opiniones de los desarrolladores, probadores y clientes. Luego, SQA ingresa al proyecto y comienza a hacer estadísticas y seguimiento.
El desarrollador completa el documento de análisis de requisitos de acuerdo con el documento de requisitos, y el probador realiza una revisión.El contenido principal de la revisión incluye si hay omisiones o diferencias en el entendimiento entre las dos partes. El probador completa el documento del plan de prueba y el contenido incluido en el plan de prueba se describe arriba.
Los probadores comienzan a escribir casos de prueba de acuerdo con el documento de análisis de requisitos modificado, y los desarrolladores completan el documento de diseño de esquema y el documento de diseño detallado. Estos dos documentos se convierten en materiales complementarios para que los probadores escriban casos de prueba.
Una vez que se completan los casos de prueba, es necesario revisar las pruebas y el desarrollo.
El probador construye el entorno.
El desarrollador envía la primera versión y puede haber funciones sin terminar que necesitan ser explicadas. Los evaluadores realizan pruebas y las envían a BugZilla después de encontrar errores.
El desarrollo envía la segunda versión, incluida la corrección de errores y algunas funciones agregadas, y los evaluadores realizan pruebas.
Repita el trabajo anterior, generalmente después de 3-4 versiones, la cantidad de BUG disminuirá y se cumplirán los requisitos para el envío.
Si hay problemas informados por los clientes, se requiere que los probadores ayuden a reproducir y volver a probar.
11. Hable sobre su comprensión de las dos estrategias de integración de arriba hacia abajo y de integración de abajo hacia arriba en las pruebas de integración, y hable sobre sus respectivas ventajas y desventajas y para qué tipo de prueba son principalmente adecuadas.
integración de arriba hacia abajo
Ventajas: los principales puntos de control y juicio se verifican antes; una función de software completa se puede realizar y verificar primero de acuerdo con la profundidad primero; la función se verifica antes, lo que brinda confianza; solo se necesita un controlador, lo que reduce el costo del desarrollo del controlador , soporte de aislamiento de fallas.
Desventajas: La cantidad de desarrollo de la columna es grande; la verificación subyacente se retrasa; los componentes subyacentes no se prueban lo suficiente.
La estructura de control del producto es relativamente clara y estable; la interfaz de alto nivel cambia poco; la interfaz de bajo nivel no está definida o puede modificarse con frecuencia; los componentes de control de producción y puerto tienen altos riesgos técnicos y deben verificarse lo antes posible ; espero ver el sistema del producto tan pronto como sea posible comportamiento funcional.
integración ascendente
Ventajas: verifique antes el comportamiento de los componentes subyacentes; el trabajo se puede integrar inicialmente en paralelo, lo que es más eficiente que de arriba hacia abajo; reduce la carga de trabajo del stub; admite el aislamiento de fallas.
Desventajas: la carga de trabajo de desarrollo del controlador es pesada, la verificación del alto nivel se retrasa y los errores de diseño no se pueden encontrar a tiempo.
La interfaz subyacente es relativamente estable; la interfaz de alto nivel cambia con frecuencia; los componentes subyacentes se completan antes.
12. ¿Qué aspectos se deben considerar al diseñar casos de prueba, es decir, qué aspectos son probados por diferentes casos de prueba?
Al diseñar casos de prueba, es necesario prestar atención no solo al proceso y las funciones generales, sino también a las pruebas de resistencia, de rendimiento, de estrés, de valor límite, de estabilidad, de seguridad y otros aspectos. (Los cuatro elementos básicos que deben considerarse en el caso de prueba son entrada, salida, operación y entorno de prueba; además, el caso de prueba debe considerar el tipo de prueba (función, rendimiento, seguridad...), esta parte se puede responder refiriéndose a TP. Además, también se debe considerar la importancia y la prioridad de los casos de uso)
13. Al guardar un archivo de texto en Windows, aparecerá un cuadro de diálogo para guardar.Si se crea un caso de prueba para el nombre del archivo, ¿cómo se debe dividir la clase de equivalencia?
Byte único, como A; byte doble, AA, I I; carácter especial /'. ';, =-, etc.; palabras reservadas, como com; el formato de archivo es formato 8.3; el formato de nombre de archivo no es formato 8.3; /, * y otros nueve caracteres especiales.
Suponiendo que hay un cuadro de texto que requiere el ingreso de un código postal de 10 caracteres, ¿cómo se debe dividir el cuadro de texto en clases de equivalencia?
Caracteres especiales, como 10 * o ¥; letras inglesas, como ABCDefghik; menos de diez caracteres, como 123; más de diez caracteres, como 11; números y otros mixtos, como 123AAAAAAAA; caracteres vacíos; caracteres reservados
14. ¿Cuál es el enfoque de las pruebas unitarias, las pruebas de integración y las pruebas del sistema?
Las pruebas unitarias están dirigidas a la unidad más pequeña de diseño de software: módulos de programa (funciones y procedimientos en orientados a procesos; clases en orientados a objetos). El trabajo de prueba para verificar la corrección es encontrar posibles errores que puedan existir dentro de cada módulo de programa. son generalmente dos pasos: inspección estática manual \ seguimiento de ejecución dinámica
La prueba de integración tiene como objetivo probar los componentes integrados por cada módulo que ha pasado la prueba unitaria, su contenido principal es la interfaz entre cada módulo de la unidad y las funciones realizadas por cada módulo después de la integración.
La prueba del sistema está dirigida al sistema de software integrado. Como elemento de todo el sistema informático, se combina con otros elementos del sistema, como hardware, periféricos, software de soporte, datos y personal. En el entorno operativo real, realice una serie de pruebas de integración y validación sobre el sistema informático.
15. ¿Cuáles son los tipos de pruebas de software que conoce y preséntelos brevemente?
Clasificados por estrategia de prueba: 1. Pruebas estáticas y dinámicas 2. Pruebas de caja negra y caja blanca 3. Pruebas manuales y automáticas 4. Pruebas de humo 5. Pruebas de regresión;
Clasificados por fase de prueba: prueba unitaria, prueba de integración, prueba del sistema;
Otros métodos de prueba comunes: 1. Pruebas funcionales 2. Pruebas de rendimiento 3. Pruebas de estrés 4. Pruebas de carga 5. Pruebas de usabilidad 6. Pruebas de instalación 7. Pruebas de interfaz 8. Pruebas de configuración 9. Pruebas de documentación 10. Pruebas de compatibilidad 11. Pruebas de seguridad 12 , prueba de recuperación
16. ¿Cuál cree que es la clave para hacer un buen trabajo en el diseño de casos de prueba?
La clave para el diseño de casos de prueba de caja blanca es cubrir tantos resultados lógicos internos del programa como sea posible con menos casos de prueba.
La clave para el diseño de casos de uso de caja negra también es cubrir las interfaces de entrada y salida del módulo con menos casos de uso. Imposible de probar completamente para encontrar la mayoría de los problemas en un tiempo razonable con la menor cantidad de casos de uso
17. ¿En qué fases debe constar un conjunto completo de pruebas?
Análisis de viabilidad, análisis de requisitos, diseño general, diseño detallado, codificación, pruebas unitarias, pruebas de integración, pruebas de sistemas, pruebas de aceptación