1. La diferencia entre la arquitectura B/S y la arquitectura C/S
- B/S solo necesita tener un sistema operativo y un navegador, lo que puede lograr un cliente multiplataforma, sin mantenimiento, bajo costo de mantenimiento, pero baja capacidad de personalización y velocidad de respuesta lenta
- C/S tiene una velocidad de respuesta rápida y una fuerte seguridad. Generalmente se usa en redes de área local, porque necesita un desarrollo específico para diferentes sistemas operativos y el costo de mantenimiento es alto.
2.Protocolo HTTP
El protocolo http también se denomina protocolo de transferencia de hipertexto Cuando hacemos solicitudes de red, básicamente usamos el protocolo http.
El protocolo http incluye solicitudes y respuestas.
La solicitud incluye: dirección de solicitud, método de solicitud, método de solicitud incluye solicitud de obtención y solicitud de publicación, la diferencia entre obtención y publicación es que la solicitud de obtención es seguida por parámetros de solicitud detrás de la barra de direcciones, pero el tamaño de los parámetros de solicitud es limitado y diferente Los navegadores son diferentes. Por lo general, 4 KB. La solicitud posterior se utiliza principalmente para enviar parámetros de solicitud al servidor. Los parámetros de la solicitud de publicación se colocan en el contenido de la entidad de solicitud, que es más seguro que la solicitud de obtención. Además, habrá diversa información de encabezado de solicitud en la solicitud, como el tipo de datos admitido, la ubicación de origen de la solicitud y la información de encabezado relacionada, como el encabezado de la cookie.
Respuesta, contiene principalmente el código de estado de la respuesta, como 200, 304, 307, 404, 500
También hay diversa información de encabezado de respuesta, como la configuración de encabezados de respuesta en caché, el tipo de contenido de tipo de contenido y la configuración de información de encabezado de cookies.
- 200: (Éxito) El servidor ha procesado correctamente la solicitud
- 304: (Sin modificar) El cliente envía una solicitud condicional, pero los recursos en el servidor no han cambiado, luego responda a este estado de respuesta
- 307: (Redirigir) Redirección interna del navegador
- 404: (No encontrado) El servidor no puede encontrar el recurso solicitado por el cliente; No encontrado
- 500: (Error interno del servidor) No se pudo completar la solicitud;
La versión completa de las preguntas de la entrevista en PDF puede unirse al siguiente grupo:
3. La diferencia entre POST y GET
- Las solicitudes de obtención generalmente son para obtener datos (de hecho, también se pueden enviar, pero la forma común es obtener datos); las solicitudes de publicación generalmente son para enviar datos.
- Get no es seguro, porque durante el proceso de transmisión, los datos se colocan en la URL de la solicitud; todas las operaciones de Post son invisibles para el usuario y los datos de la solicitud se colocan en el cuerpo (el escenario más común, la contraseña de inicio de sesión del usuario Enviar, debe usar la solicitud posterior)
- La cantidad de datos transmitidos por Get es pequeña, lo que se debe principalmente a la limitación de la longitud de la URL; la cantidad de datos transmitidos por Post es relativamente grande, que generalmente se establece de manera predeterminada como ilimitada.
- Las solicitudes de obtención se pueden almacenar en caché, las solicitudes de publicación no se almacenarán en caché
4. La diferencia y conexión entre Cookie y Sesión
- Tanto la cookie como la sesión son tecnologías de sesión, la cookie se ejecuta en el lado del cliente y la sesión se ejecuta en el lado del servidor.
- Las cookies tienen un límite de tamaño y el número de cookies almacenadas por el navegador también está limitado.La sesión no tiene límite de tamaño y está relacionada con el tamaño de la memoria del servidor.
- Las cookies tienen riesgos de seguridad potenciales, y se pueden llevar a cabo ataques después de encontrar sus cookies a través de intercepción o archivos locales.
- La sesión se almacena en el servidor y existirá durante un período de tiempo antes de desaparecer. Si hay demasiadas sesiones, aumentará la presión sobre el servidor.
5. Propósito de la prueba
En pocas palabras, es probar para el usuario. El objetivo final de la prueba es garantizar que las funciones del producto que finalmente se entrega al usuario satisfagan las necesidades del usuario, y encontrar y corregir tantas posibles problemas antes de entregar el producto al usuario.
6. ¿Cuáles son las etapas de las pruebas de software?
Pruebas unitarias , pruebas de integración, pruebas de sistemas, pruebas de aceptación.
prueba de unidad
Es el nivel más bajo de actividad de prueba que se realizará durante el desarrollo de software. En las actividades de prueba unitaria, las unidades independientes de software se prueban aisladas del resto del programa. El enfoque de la prueba está en los módulos del sistema, incluidas las subrutinas. verificación, etc
Pruebas de integración
También se llama prueba de ensamblaje o prueba conjunta. 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.
Prueba del sistema
Consiste en 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.
Alcance de la prueba del sistema
Prueba funcional, prueba de interfaz de usuario, prueba de rendimiento, prueba de tolerancia a fallas, prueba de usabilidad, prueba de problemas anormales, prueba de estabilidad, prueba de estabilidad del sistema,
Prueba de compatibilidad, prueba de interfaz, prueba de seguridad, prueba de autoridad de inicio de sesión
Examen de ingreso
Es el último eslabón de la inspección de productos de software. Pruebe y revise todo el sistema de acuerdo con la declaración de la misión del proyecto o el contrato, y los documentos de base de aceptación acordados por el proveedor y el comprador, y decida si acepta o rechaza el sistema.
Otros se dividen en varias etapas.
回归测试：Al probar una nueva versión del software, se repiten todos los casos de prueba de una versión anterior importante.
1. Verificar que se hayan solucionado todos los defectos de las versiones anteriores;
2. Confirme que la reparación de estos defectos no cause nuevos defectos
冒烟测试：Se refiere a verificar si las funciones básicas del software se realizan y si se pueden probar antes de realizar una prueba sistemática a gran escala en una nueva versión. También llamado prueba de capacidad de prueba.
7. La diferencia entre una prueba y una prueba ß
а测试 Es una prueba realizada por un usuario en un entorno de desarrollo, o una prueba realizada por un usuario dentro de la empresa en un entorno operativo real simulado. ß测试 es una prueba de aceptación. Una prueba beta es una prueba realizada en las instalaciones de uno o más usuarios.
8. ¿Cómo hacer la prueba de aceptación?
1. Prueba de interfaz: se refiere a si los botones de función o la interfaz se pueden mostrar normalmente al navegar por todas las páginas del producto de software.
2. Prueba funcional, si las funciones del producto se pueden realizar normalmente.
3. Pruebas de rendimiento: el proceso de descubrir cuellos de botella en el rendimiento, incluidas varias pruebas de CPU, memoria, entorno de red, versión, etc.
4. Pruebas de seguridad, confidencialidad de la información del producto, protección con contraseña y otras pruebas funcionales.
9. La diferencia entre las pruebas de caja blanca, caja negra y caja gris
La diferencia entre la caja negra y la caja gris:
si un software contiene varios módulos, al usar la prueba de caja negra, solo debe preocuparse por los límites de todo el sistema de software, y no necesita preocuparse por cómo funcionan los diversos módulos en el sistema de software coopera. Y si usa pruebas de caja gris, debe preocuparse por la interacción entre los módulos.
La diferencia entre la caja blanca y la caja gris:
En las pruebas de caja gris, no necesita preocuparse por los detalles de implementación interna del módulo.Para los módulos internos del sistema de software, las pruebas de caja gris todavía los tratan como una caja negra. Las pruebas de caja blanca también requieren una comprensión más profunda de los detalles de implementación y las ramas de los módulos internos.
10. Propósito de la prueba de humo
Antes de las pruebas formales, verifique si hay errores en los principales requisitos o condiciones previas del producto o sistema.
11. ¿Cómo hacer pruebas de regresión?
- 1. En la etapa de formulación de la estrategia de prueba, formule la estrategia de prueba de regresión
- 2. Determinar la versión que necesita pruebas de regresión
- 3. Se lanza la versión de prueba de regresión y la prueba de regresión se realiza de acuerdo con la estrategia de prueba de regresión
- 4. Pase la prueba de regresión y cierre la lista de seguimiento de defectos (lista de problemas)
- 5. Si la prueba de regresión falla, la hoja de seguimiento de defectos se devuelve al desarrollador, el desarrollador vuelve a editar el problema y vuelve a enviar la prueba de regresión al evaluador.
12. Propósito del análisis de necesidades
Primero, transforme los requisitos del usuario en requisitos funcionales: 1) mida el progreso del alcance de la prueba 2) mida la rama de procesamiento 3) mida la escena del negocio requerido 4) aclare la entrada, el procesamiento y la salida correspondiente a su función 5) defina el Los requisitos formales ocultos se vuelven explícitos.
En segundo lugar, aclare los cinco elementos de las actividades de prueba: cuál es el requisito de prueba, decida cómo probar, especifique el tiempo de prueba, determine los probadores, determine el entorno de prueba: las habilidades, las herramientas y los conocimientos previos correspondientes requeridos en la prueba, el posible encuentros en el proceso de prueba riesgo etc. Los requisitos de las pruebas deben ser lo más detallados y claros posible para evitar omisiones y malentendidos.
13. Finalidad del Plan de Pruebas
1. Tan pronto como sea posible, aclare el contenido (alcance) del trabajo de prueba, el método del trabajo de prueba y los diversos recursos necesarios para el trabajo de prueba.
2. Todo el personal que participe en el trabajo de prueba implementará los aspectos que deben tenerse en cuenta y las condiciones de preparación para el siguiente trabajo de prueba lo antes posible.
3. El enfoque del trabajo de planificación de pruebas es: la preparación y planificación de las tareas de trabajo actuales y el intercambio de información.
14. Cuándo comenzar a escribir el plan de prueba
El plan de prueba es un plan que se formula junto con el plan de desarrollo después de resolver los requisitos y pertenece a uno de los planes del plan del proyecto.
15. Quién escribirá el plan de prueba
Jefe de proyecto (considerado desde la perspectiva del proyecto)
Jefe de prueba (considerado desde la perspectiva del equipo de prueba)
Probador (plan de prueba específico escrito)
16. Contenido del plan de pruebas
1. Objetivo de la prueba: describa brevemente el objetivo de la prueba.
2. Resumen de la prueba: una breve descripción del software que se probará, explicaciones de terminología y documentos relevantes a los que se hace referencia.
3. Alcance de la prueba: el alcance y la prioridad del software de prueba incluido en el plan de prueba, cuáles deben probarse, cuáles no necesitan probarse o no pueden probarse o posponerse.
4. Cuestiones clave: enumere todas las funciones principales y los puntos clave de prueba del software que se va a probar. Esta parte debe poder corresponder y verificar con el diseño del caso de prueba.
5. Objetivos de calidad: formular objetivos de calidad del producto y objetivos de prueba de software para probar software.
6. Requerimientos de recursos: software y hardware, herramientas de prueba, recursos técnicos necesarios, capacitación, documentos, etc. requeridos para la prueba.
7. Organización del personal: cuántas personas se requieren para realizar la prueba, sus respectivos roles y responsabilidades, si necesitan aprendizaje y capacitación relevantes, cuándo deben comenzar y cuánto durará.
8. Estrategia de prueba: formular la estrategia general de prueba, las técnicas de prueba y los métodos utilizados.
9. Envío de la versión: los productos de software, los casos de prueba, los datos de prueba y los documentos relacionados que deben entregarse después de que se publique la prueba de acuerdo con el plan de prueba.
10. Progreso de la prueba y disposición del personal de la tarea: asigne razonablemente el plan de prueba a diferentes probadores y preste atención a la secuencia. Si la versión desarrollada es incierta, se puede dar el período de tiempo de la prueba. Para pruebas a gran escala a largo plazo planes, puede utilizar hitos para representar cambios en curso.
11. Estándares para el inicio/finalización/retraso/continuación de la prueba: formule estándares de inicio y finalización de la prueba; a veces, el plan de prueba se retrasará por alguna razón (demasiados errores de bloqueo) y la prueba continuará después de que se resuelva el problema.
12. Análisis de riesgos: Es necesario considerar los posibles riesgos y soluciones en el plan de prueba.
17. Condiciones finales (condiciones para el lanzamiento del proyecto)
1. El software ha sido completamente probado.
Pruebas de desarrolladores—>pruebas cruzadas—>pruebas de probadores—>pruebas de expertos en negocios del usuario—>pruebas concentradas de un cierto número de expertos en negocios de usuarios—>ejecución de prueba antes de conectarse——>conectarse.
2. Formación de usuarios
Para los administradores, debe haber una persona que haya sido capacitada en una determinada fábrica o región.
3. La importación de datos básicos está completa
Los datos básicos, como usuarios, organizaciones y datos empresariales, deben importarse.
4. Se debe completar la autorización
5. El cambio entre el sistema antiguo y el nuevo debe ensayarse con anticipación, y se completa la importación de varios datos antiguos.
6. Debe existir un plan de emergencia.
18. Riesgos comunes de las pruebas
1. Riesgo de requisito, 2. Riesgo de caso de prueba, 3. Riesgo de defecto, 4. Riesgo de calidad de código, 5. Riesgo de entorno de prueba, 6. Riesgo de tecnología de prueba, 7. Riesgo de prueba de regresión, 8. Riesgo de comunicación y coordinación, 9. I+D Riesgos de proceso, 10. Otros riesgos impredecibles
19. Elementos de los casos de prueba
1. Número de caso de uso, 2. Módulo de prueba, 3. Título del caso de uso, 4. Nivel de prueba, 5. Propósito y condiciones de la prueba, 6. Entrada de prueba, 7. Pasos de operación, 8. Resultados esperados
20. División de niveles de casos de prueba
Propósito de la priorización de casos de prueba: la priorización de casos de prueba se puede utilizar para filtrar fácilmente los casos en función de la estrategia de prueba. Por ejemplo, si hay un pequeño cambio en una determinada función, solo se utilizan casos de uso de medición de altura o prioridad media y alta. Por ejemplo, durante la prueba de humo, solo necesitamos filtrar los casos de uso con la prioridad más alta para la ejecución.
De acuerdo con el propósito de la prioridad de nuestro caso de prueba: los puntos de prueba cubiertos por el caso de prueba de mayor prioridad deben ser los más preocupados por el usuario, como una función de registro, la prioridad del caso de uso que se puede registrar con éxito es la más alta ( pero no todos los registros son exitosos) El caso tiene la prioridad más alta, solo necesita elegir uno), otras comprobaciones anormales son de prioridad secundaria, y algunos puntos de prueba cubiertos por la escena son difíciles de aparecer, o incluso si hay un problema , el impacto no se verá afectado. Grande, se puede colocar en baja prioridad
21. ¿Cómo asegurar que las necesidades de los usuarios estén cubiertas?
1. Confirmar requisitos, 2. Clasificar requisitos, confirmar alcance de prueba, 3. Hacer plan de prueba, 4. Escribir casos de prueba de acuerdo con el plan de prueba, 5. Ejecutar pasos de prueba
22. La clave para escribir buenos casos de prueba/dimensiones en las que concentrarse al escribir buenos casos de uso
1. Antes de la prueba:
1. Tenga una comprensión clara del propósito de la prueba, 2. Familiarícese con los puntos de prueba funcionales del producto, 3. Familiarícese con el principio de los módulos para evitar problemas de "influencia mutua", 4 Preste atención a los problemas del escenario del usuario y los problemas de acceso a Internet.
5. Diseño de caso de prueba clave que no puede ser descuidado,
2. Al escribir casos de prueba:
1. Construcción del marco del caso de prueba, 2. Diseño de los pasos de la prueba (uno es que si los pasos son demasiado toscos, es fácil pasar por alto la prueba; el otro es que la escritura es demasiado detallada, lo que puede llevar mucho tiempo y requiere mucha mano de obra y limitará el pensamiento del ejecutivo).
3. Método y pensamiento de diseño de casos de prueba
1. Tenga en cuenta el objetivo principal de las pruebas de productos. 2. Preste atención al uso preciso de las palabras.
23. Métodos comunes de diseño de casos de prueba
División de clase de equivalencia, análisis de valor límite, método de inferencia de error, tabla de decisión, método de experimento ortogonal
24. Cuándo usar el método de escena
El método de escenarios es adecuado para resolver sistemas o funciones con procesos comerciales claros y negocios complejos.El método de escenarios es un método de prueba basado en el negocio del software.
El propósito de usar el método de escenarios es usar el flujo de negocios para unir los puntos de función aislados para establecer una sensación general de negocios para los probadores, a fin de evitar la tendencia equivocada de ignorar los puntos clave del proceso de negocios en los detalles funcionales. . Ejemplo: El proceso comercial típico de una llamada de voz combina las funciones de llamada de voz, vibración simultánea, mensaje de voz, llamada en espera y transferencia de llamada.
Básicamente, todos los programas utilizan el método de escenarios, ya que todos los programas cuentan con soporte empresarial.
El método de escenarios se utiliza principalmente para probar la lógica comercial y el proceso comercial del software. Cuando recibimos una tarea de prueba, no prestamos atención primero a la prueba detallada de un cierto control (clase de equivalencia + valor límite + tabla de juicio, etc.), sino que primero prestamos atención a si el proceso comercial principal y las funciones principales son implementado correctamente, lo que requiere Usar el método de escenario. Cuando no haya ningún problema con el proceso de negocio y las funciones principales, probaremos los detalles del control desde los aspectos de clases de equivalencia, valores límite y tablas de decisión (primero el todo y luego los detalles).
Nota: El punto clave del diseño del caso de prueba del método de escenarios es probar si el proceso comercial es correcto. Durante la prueba, se debe tener en cuenta que el hecho de que no haya ningún problema en la prueba del proceso comercial no significa que las funciones del sistema son correctos Se debe realizar una prueba detallada en una sola función para garantizar la idoneidad de la prueba.
25. Manejo de problemas accidentales
1. Asegúrese de enviar errores,
- 1. Recuerde que existe tal defecto, y cuando lo encuentre en el futuro, puede comprender la causa del mismo.
- 2. Intente encontrar la causa del error, como alguna operación especial o algún entorno operativo.
- 3. Los programadores están más familiarizados con el programa que los evaluadores. Tal vez lo envíe, incluso si no se puede reproducir, el programador entenderá el problema.
- 4. Después de que vuelva a aparecer el problema irreproducible, puede llamar directamente al programador para que eche un vistazo al problema.
- 5. Cuando registre errores, intente describir claramente los pasos de prueba, el entorno de prueba y los datos de prueba cuando ocurra un problema.
2. Intenta reproducir el error,
26. Cuando pensamos que cierto lugar es un error, pero el desarrollo piensa que no es un error, ¿cómo lidiar con eso?
1. Informar la base para juzgar el error de desarrollo y, al mismo tiempo, aclarar la razón por la cual el desarrollo dijo que no es un error.
2. Verificar el motivo del desarrollo, con base en 1. Consultar el documento de requisitos, 2. Comunicar y confirmar con el gerente de producto.
3. El resultado de la verificación no es un error, cierre el error, si es un error, envíelo al desarrollo para su procesamiento para garantizar la calidad del producto.
27. ¿Qué deben hacer los evaluadores cuando los usuarios encuentran errores después del lanzamiento del producto?
1. Después de que el evaluador reproduzca el problema, envíe un ticket de problema para su seguimiento;
2. Evaluar la gravedad del problema, el alcance del impacto cuando se solucione el problema y qué funciones deben probarse para las pruebas de regresión;
3. Después de solucionar el problema, primero regrese al entorno de prueba y luego aplique un parche al entorno de producción después de pasar, y luego realice la prueba de regresión;
4. Resuma la experiencia, analice la causa del problema y evite el mismo problema la próxima vez.
28. Veintiocho teorema
Los defectos tienden a acumularse. Un módulo ha encontrado más defectos que otros módulos. Por lo general, no significa que el módulo haya expuesto los defectos, pero significa que todavía hay muchos defectos en este módulo que no se han descubierto. Este es el famoso teorema 28: el 80% de los defectos aparecen en el 20% de los módulos.
29. Cómo rastrear defectos
Cuando se encuentra un defecto, debemos enviar una lista de problemas al desarrollo de ZenTao y verificar si el defecto se ha resuelto a intervalos regulares (una hora o dos horas está bien). Si no se resuelve a tiempo, lo haremos. impulsar el desarrollo.Deje que el desarrollo solucione el problema a tiempo.Después de que se solucione el problema, la prueba de regresión debe llevarse a cabo a tiempo.
30. Estado del defecto
1. Inicialización: el estado inicial del defecto;
2. Por asignar: el defecto está a la espera de ser asignado al desarrollador correspondiente para su procesamiento;
3. Por corregir: el defecto está a la espera de que el desarrollador lo corrija;
4. Para ser verificado: el desarrollador ha completado la corrección y está esperando que el probador verifique;
5. Para ser revisado: el desarrollador se niega a modificar el defecto y debe ser revisado por el comité de revisión;
6. Cerrado: El defecto ha sido procesado.
31. Clasificación de Defectos
Defectos menores, defectos generales, defectos graves, defectos fatales
32. Un ticket de defecto debe contener estos elementos
Título del defecto, tipo de defecto, pasos para reproducir, resultado esperado, resultado real, prioridad del defecto, comentarios adjuntos
33. Contenido principal del informe de ensayo
Qué se incluye en el informe de prueba: Módulo de prueba (cada módulo debe registrar la hora de inicio y la hora de finalización de la prueba, cuántos casos de uso se diseñaron, cuántos pasaron, cuántos fallaron, cuántos BUG, cuántos BUG quedaron , cuántos BUG se resolvieron y seguimiento de este módulo en conclusión)
Estadísticas de BUG, según el eje de tiempo para contar el número de BUG, por ejemplo: XXXX X mes X día, cuántos errores se encontraron, cuántos errores se cerraron, cuántos errores restantes, cuántos errores de alto nivel, cuántos errores de nivel medio, de bajo nivel y recomendados. Cuántos errores hay, enumerados hasta el final del proyecto.
Resumen del proyecto, informe de los resultados generales de la prueba.
Restos y riesgos, cualquier problema restante del software y cualquier riesgo, deben explicarse uno por uno.
Finalmente, juzgue si el software cumple con los estándares en línea, fecha, firma, sello, etc.
34. Cómo localizar errores:
1. Para encontrar un error, primero verifique la información detallada del error e inicialmente analice qué módulo y qué pieza de código es el problema de acuerdo con la descripción.
2. Verifique el entorno de prueba, el segmento de código de prueba y los datos de prueba que causaron el error, y elimine la excepción del programa causada por el mal funcionamiento del probador
3. Después de confirmar que el código de prueba, el entorno de prueba y los datos son correctos, analice más a fondo la causa raíz del error. Aquí debemos observar el negocio de prueba específico, que se puede analizar con la ayuda de herramientas relevantes.
4. Si el producto o la empresa tiene registros de registro relevantes, el error se puede confirmar analizando el registro.
5. Después de una serie de análisis, los probadores básicamente pueden confirmar la causa del error y luego pueden pedirle directamente al desarrollador que plantee el error (preste atención a las habilidades de comunicación)
6. Si la causa del error no se puede confirmar después de analizar todos los aspectos, puede encontrar al desarrollador para localizarlo juntos (tenga en cuenta que la escena del error se mantiene o la escena del error se puede reproducir)
7. Después de confirmar el error, se enviará el conocimiento de embarque al desarrollador para el seguimiento del error.
La siguiente información debe estar claramente descrita en la hoja de problemas:
Tiempo de prueba específico, entorno de prueba, escenarios de prueba, negocios y funciones específicas de la prueba, código de prueba y datos de prueba utilizados, pasos de ejecución de prueba, resultados de prueba, fenómenos de errores (preferiblemente capturas de pantalla), registros de registro, resultados esperados y personal relacionado con la confirmación de errores etc.
8. Realice un seguimiento de los errores y realice pruebas de regresión después de que los desarrolladores corrijan los errores. (Preste atención a si el error está completamente solucionado, si afecta otras funciones y si presenta nuevos problemas)
35. El desarrollo no tiene tiempo para corregir, cómo promover la corrección de errores:
1. Para errores con rutas profundas, al realizar pruebas para promover el desarrollo y corregir errores, debe prestar atención a los siguientes puntos:
a) Analizar la gravedad del problema desde el punto de vista del usuario, analizar la probabilidad de que el usuario encuentre este problema y guiar el desarrollo para pensar desde el punto de vista del usuario, de modo que el desarrollo sea consciente de la gravedad del problema.
b) Puede enumerar un problema similar anterior con el desarrollador para proporcionar una referencia para el desarrollo
c) El producto es la persona responsable del software. Cuando las opiniones de prueba y desarrollo no pueden llegar a un acuerdo, no se rinda porque no puede promover el desarrollo y la modificación. Debe encontrar el producto para confirmarlo, y se deja la decisión final. al personal del producto.
2. El tiempo de lanzamiento es ajustado y el desarrollo es demasiado tarde para modificarlo. En este momento, la prueba debe analizar la gravedad del problema y discutir con el personal del producto si es necesario modificarlo.
3. Modificación de errores Los cambios son grandes, el alcance de la influencia es amplio y no existe una solución óptima.Es tabú que tales cosas sucedan en el nodo donde el proyecto está a punto de entrar en línea. Ante esta situación, se recomienda a los desarrolladores hacer un trabajo de investigación, consultar a otros compañeros, u organizar una reunión ad hoc para juntar fuerzas entre todos para estudiar un buen plan de modificación
4. El desarrollo no puede modificar el problema de la aplicación de terceros. Después de confirmar el motivo, debe encontrar personal relevante, como productos, ponerse en contacto con personal de terceros, dar su opinión sobre el problema e intentar promover la aplicación para resolver el problema.
resumen
En resumen, ya sea que se repare el error o no, la prueba debe tener sus propios principios y, al mismo tiempo, sopesar los pros y los contras. No puede darse por vencido solo porque no puede impulsar el desarrollo, dejar que el error se conecte y no puede aferrarse a un pequeño error, lo que afectará el tiempo para conectarse.
36. Proceso de prueba de software
Comprender las necesidades del usuario – “referirse a la especificación de requisitos –” plan de prueba (disposición de recursos humanos y materiales y cronograma) – “escribir casos de prueba – “revisar casos de uso –” entorno de construcción – “pronóstico de disposición del paquete de prueba (prueba de humo) – prueba formal – error -Informe después de la prueba – “Versión lanzada –” Orientado al usuario
37. Para probar un bolígrafo, ¿qué aspectos se deben probar? Diseño de caso de prueba triangular
Prueba de rendimiento
¿Se puede escribir normalmente? ¿Hay alguna fuga de aceite de la pluma? ¿Se puede presionar y abrir la tapa de la pluma normalmente?
prueba de funcionamiento
¿Cuánto tiempo se puede usar un bolígrafo y si las palabras escritas se desvanecen?
prueba de usabilidad
¿La longitud y el grosor de la pluma son fáciles de usar?¿Es fácil reemplazar una recarga?
prueba de interfaz
Si la apariencia es hermosa, a la moda e interesante.
prueba de seguridad
¿El aceite de la pluma contiene sustancias nocivas? ¿La punta de la pluma es fácil de lastimar a las personas? ¿Cuánto dura la vida útil del aceite o la tinta de la pluma? ¿Produce sustancias nocivas?
prueba de compatibilidad
¿Se puede usar normalmente bajo diferentes temperaturas, presiones de aire y gravedad?¿Cuál es el resultado de escribir bajo diferentes calidades y resistencias de papel?
Diseño de caso de prueba triangular:
1. Cuando sea imposible que los tres lados formen un triángulo, se mostrará un error. Cuando se pueda formar un triángulo, se calculará el perímetro del triángulo.
2. Si es un triángulo isósceles, imprime "Triángulo isósceles", si la suma de los cuadrados de dos isósceles es igual a la suma de los cuadrados del tercer lado, entonces imprime "Triángulo rectángulo isósceles".
3. Si es un triángulo equilátero, escribe: "Triángulo equilátero".
4. Dibuje el diagrama de flujo del programa y diseñe un caso de prueba.
Diagrama de causalidad, división de clases de equivalencia (método de prueba recomendado)
38. ¿Qué errores clásicos se encontraron en el proyecto? ¿Qué lo causa?
problema de codificación
Cuando la interfaz está limitada para evitar el cepillado, la corriente está limitada por el contador. Si supera un cierto umbral, cuando un objeto codeMsg se devuelve al front-end para su visualización, la cadena mostrada es un problema de caracteres ilegibles. Anteriormente, el return siempre fue en formato json, está encapsulado en data.
Esta vez, el retorno se escribe directamente en la respuesta directamente a través del flujo de salida para devolver la matriz de bytes directamente, en lugar de que el controlador Spring devuelva los datos (el valor predeterminado de Springboot es utf-8), y hay un problema de caracteres ilegibles, que está codificado con utf-8 para resolverlo.
Solo hay dos tipos de errores que son difíciles de resolver. Uno es que hay un problema con la lógica del programa, lo que conduce a la imposibilidad de obtener el resultado correcto. El segundo son algunos problemas con el entorno de desarrollo y el middleware.
(1) Si hay un problema con la lógica, si su proyecto es relativamente grande, solo puede usar la depuración de un solo paso o usar System.out.println() para imprimir los datos deseados para ver qué paso tiene el problema. .
(2) Si se trata de un problema con el entorno de desarrollo o el middleware, el problema solo se puede resolver consultando la información en Internet. Si su capacidad de lectura en inglés está bien, le recomiendo usar Stack Overflow para verificar la información.
39. ¿Cómo realizar las pruebas cuando el documento de requisitos no es muy detallado?
1. Tome la iniciativa de comprender el trasfondo y la intención de esta función y qué tipo de problema se va a resolver. Esto se puede encontrar en productos o desarrolladores, o quien solicite esta función. Después de conocerlos, tendrá una buena idea al probar Saber si la función está implementada correctamente
2. Intente permitir que las personas que están familiarizadas con este negocio realicen pruebas, de modo que se puedan probar algunos problemas comerciales de la función.
3. Debido a que no hay una especificación de requisitos, el lado de la prueba solo sabe cómo se ve la función después de que la función se completa y se transfiere a la prueba. Por lo tanto, es demasiado tarde para escribir el caso de prueba en este momento, por lo que adoptamos esta forma. de pensar para operar, y registre la prueba mientras prueba los puntos, y luego revise estos puntos de prueba en el grupo para ver si hay alguna omisión.
40. ¿Cómo encontrar errores en el software lo antes posible?
Priorice los errores reproducibles. Para algunos errores despistados, puede discutir con colegas experimentados, la amplificación de errores, el método de posicionamiento binario, la escena simulada, etc.
41. ¿Es un ERROR el fenómeno de deglución de tarjetas del cajero automático?
No, es una medida de seguridad especialmente habilitada para evitar que alguien se descuide y se olvide de sacar la tarjeta bancaria después de la operación y se le reclame falsamente el dinero de la tarjeta, por lo que se habilita especialmente una cuenta regresiva. la tarjeta no se retira dentro del límite de tiempo, la tarjeta será tragada
42. ¿Cómo reducir la presentación de hojas sin problemas?
1. La descripción resumida del defecto debe ser clara y precisa, para que el personal de desarrollo relevante pueda comprender el problema de un vistazo.
2. Un informe de defectos completo debe contener la información de elementos necesaria, como: descripción resumida, descubridor de defectos, entorno de prueba, navegador, pasos de reproducción de defectos, nivel de gravedad, responsable, módulo funcional, etc. La información de elementos necesaria debe ser completa y clara. descrito.
3. Los pasos de reproducción de defectos deben describirse claramente, de modo que el director de desarrollo correspondiente pueda reproducir con precisión los defectos presentados de acuerdo con los pasos de reproducción, para que puedan localizar la causa del defecto.
4. La asignación debe ser clara, si se sabe que el defecto pertenece a un desarrollador específico, debe asignarse directamente al responsable correspondiente, de manera de reducir el tiempo en el proceso de asignación intermedia.
5. Datos de prueba, los datos de prueba son un elemento de información importante para reproducir defectos, y la información utilizada en la prueba debe describirse de manera clara y precisa. Permita que los desarrolladores reproduzcan con precisión los defectos en función de los datos de prueba proporcionados por la prueba.
6. La información de la captura de pantalla del archivo adjunto, la información del archivo adjunto o la captura de pantalla permite a los desarrolladores comprender el problema de un vistazo, por lo que también es muy importante proporcionar información del archivo adjunto o de la captura de pantalla cuando sea necesario.
7. El tono de la descripción del contenido del defecto. Al escribir la lista de defectos, trate de usar términos profesionales (que reflejen la profesionalidad de la prueba). En segundo lugar, preste atención a no usar un tono personal y objetivo al escribir el informe del defecto, de modo que para no afectar la relación entre desarrolladores y evaluadores.
43. Hay un programa que se ejecuta muy lentamente en Windows.¿Cómo juzgar si hay un problema con el programa o con el sistema de software y hardware?
1. Verifique si el sistema tiene características moderadas, tales como: las ventanas del navegador se abren continuamente, los íconos de archivos en el sistema se cambian a íconos uniformes, el uso de la CPU se mantiene por encima del 90%, etc.
2. Compruebe si la configuración de software/hardware cumple con los estándares recomendados del software
3. Confirme si el sistema actual es independiente, es decir, no proporciona servicios externos que consuman recursos de la CPU, como: ejecutar una máquina virtual
4. Si se trata de un software con estructura C/S o B/S, es necesario verificar si es causado por un problema con la conexión al servidor o un problema con el acceso;
5. Cuando el sistema no esté bajo ninguna carga, verifique el monitor de rendimiento para confirmar el acceso de la aplicación a la CPU/memoria,
44. Cómo probar la función de búsqueda
功能方面的测试：
Busque una sola palabra, frase, oración, si el contenido recuperado es preciso y si el enlace es preciso
Longitud: por ejemplo, si el cuadro de entrada admite 100 caracteres, debe comprobar si la longitud máxima es normal para 100 caracteres y 101 caracteres;
¿Cuáles son los tipos de caracteres admitidos: números, letras, caracteres chinos, caracteres? @! #, caracteres especiales; (dependiendo de la demanda)
Hay espacios antes y después de la cadena, ya sea para filtrar los espacios antes y después, y si mantener los espacios en el medio; (dependiendo de los requisitos)
Letras y números de ancho completo y ancho medio (según demanda)
性能方面的测试
¿Cuánto tardan en aparecer los resultados de búsqueda después de hacer clic en el botón de búsqueda?
¿Cuánto tiempo se tarda en llegar a la página de búsqueda?
pruebas de seguridad
Puede prevenir ataques de inyección SQL, ya sea para prevenir ataques XSS
Pruebas de experiencia de usuario:
Si el diseño de la página es razonable, si el cuadro de entrada y el botón están alineados
El tamaño del cuadro de entrada y la longitud del botón, si la altura es razonable
Tecla de acceso directo: ¿Puede seleccionar todo, seleccionar parte, si está disponible copiar, cortar y pegar, cómo mostrar la cadena pegada que excede la longitud máxima?
prueba de compatibilidad
Arquitectura BS: diferentes pruebas de navegador, tales como: IE, Firefox, Google, 360, etc.
APLICACIÓN: Probado en teléfonos móviles convencionales de diferentes tipos, diferentes resoluciones y diferentes sistemas operativos, como Huawei, vivo, oppo, etc.
45. Cómo probar la función de inicio de sesión
功能方面的测试：
Ingrese el nombre de usuario y la contraseña correctos, haga clic en el botón Enviar, inicie sesión correctamente y salte a la página correcta
Ingrese el nombre de usuario correcto, la contraseña incorrecta, el inicio de sesión falla y aparece el mensaje de error correspondiente
Ingrese el nombre de usuario incorrecto, la contraseña correcta, el inicio de sesión falla y aparece el mensaje de error correspondiente
Si el nombre de usuario está vacío, el inicio de sesión de verificación falla y aparece el mensaje de error correspondiente
Si la contraseña está vacía, el inicio de sesión de verificación falla y aparece el mensaje de error correspondiente
El nombre de usuario y la contraseña están vacíos, haga clic en iniciar sesión
Hay espacios antes y después del nombre de usuario y la contraseña, ya sea para procesar los espacios intermedios (según los requisitos)
性能方面的测试
¿Cuánto tiempo lleva abrir la página de inicio de sesión?
Después de ingresar el nombre de usuario y la contraseña correctos, ¿cuánto tiempo lleva iniciar sesión correctamente y pasar a una nueva página?
安全性方面的测试
Si la contraseña está encriptada en el front-end y si está encriptada durante la transmisión de la red
¿Puede el cuadro de entrada para el nombre de usuario y la contraseña evitar los ataques de inyección SQL?
Si el cuadro de entrada de nombre de usuario y contraseña puede prevenir el ataque XSS
Limite la cantidad de inicios de sesión incorrectos (para evitar el cracking de fuerza bruta)
Ya sea para permitir que varios usuarios inicien sesión en la misma máquina
Un usuario inicia sesión en diferentes terminales
Inicio de sesión remoto de usuario
用户体验测试：
Si el diseño de la página es razonable, si el cuadro de entrada y el botón están alineados
El tamaño del cuadro de entrada y la longitud del botón, si la altura es razonable
¿Es posible usar el teclado para todas las operaciones y hay una tecla de método abreviado?
Ingrese el nombre de usuario, la contraseña y presione Entrar, si puede iniciar sesión
Si el código de verificación está involucrado, también es necesario considerar si el texto está demasiado distorsionado para que sea difícil de reconocer, considere el color (usuarios daltónicos), si el botón actualizar o cambiar es fácil de usar.
兼容性测试
Arquitectura BS: diferentes pruebas de navegador, tales como: IE, Firefox, Google, 360, etc.
APLICACIÓN: Probado en teléfonos móviles convencionales con diferentes modelos, diferentes resoluciones y diferentes sistemas operativos, como Huawei, vivo, oppo, Apple, etc.
46. Si debe probar el carrito de compras de Taobao, ¿cómo diseñaría casos de prueba y qué aspectos deben considerarse?
1. Después de abrir la página de Taobao, ¿está completo el diseño de la página?
2. Si los botones de función en la página se pueden mostrar normalmente
3. Si se mostrará en la página del producto para agregar al carrito de compras
4. Si el producto seleccionado se puede agregar al carrito de compras
5. Si se puede mostrar toda la información del producto después de agregarlo al carrito de compras
6. Si los productos agregados al carrito de compras se pueden eliminar
7. Si la red es deficiente o no se puede agregar con éxito ninguna red al carrito de compras
8. Después de agregar el carrito de compras, ¿aumentará la cantidad cuando se haga clic en el signo más?
9. Después de agregar el carrito de compras, ¿se reducirá la cantidad cuando se haga clic en el signo menos?
10. Si hace clic en el signo menos para reducir a cierto nivel, ¿aparecerá un mensaje que ya no se puede reducir?
11. Si el usuario de Taobao no ha iniciado sesión, ¿habrá un aviso para iniciar sesión primero al agregarlo al carrito de compras?
12. Si no se selecciona ningún producto, haga clic en pagar, se le preguntará al usuario "Agregue artículos para retirar"
13. Si se mostrará el precio total del producto seleccionado después de verificar el producto
14. Después de verificar el artículo para mostrar el precio total, ¿es correcto el cálculo del precio total?
15. Después de seleccionar el producto y hacer clic en el botón de pago, ¿ingresará a la página para confirmar la información del pedido?
16. ¿Es correcto el precio total en la página de información del pedido de confirmación?
17. ¿Será inexacto el precio total, por ejemplo: el precio total correcto es 18,99, pero el resultado muestra que, de hecho, es 18,999999999999?
18. ¿Hay una función de volver al principio?
19. ¿Es posible editar los atributos del producto?
20. ¿Se puede mover a la colección?
21. Si se muestra el nombre de la tienda
22. ¿Es posible seleccionar todos los productos?
23. ¿Es posible deseleccionar todos los productos?
24. ¿Es posible modificar las especificaciones del producto en el carrito de compras?
25. Se limita si la cantidad de compras añadidas excede la cantidad de inventario
26. ¿Es posible vaciar el carrito de compras?
27. ¿Cambiará el monto de liquidación a medida que aumente o disminuya la cantidad de bienes?
28. Si hay demasiados tiempos de actualización, ¿habrá un fenómeno de flashback?
29. Cuando el teléfono móvil llame, la página de Taobao aún se ejecutará
30. Cuando la memoria del teléfono móvil no es suficiente, ¿Taobao se congelará al ejecutarse?
47. Reglas generales para casos de prueba
Finalmente, me gustaría agradecer a todos los que han leído mi artículo detenidamente. Como persona que ha estado aquí, espero que eviten algunos desvíos . Aquí compartiré con ustedes algunos recursos de aprendizaje para pruebas automatizadas . Si pueden usarlos , puedes llevártelo. Espero que te lo puedan dar. Ayuda en el camino. ( Incluyendo programación de Python, pruebas automatizadas WEB, pruebas automatizadas de aplicaciones, pruebas automatizadas de interfaz, marco de pruebas, integración continua, desarrollo de pruebas automatizadas, pruebas de rendimiento, pruebas de seguridad, preguntas de entrevistas en grandes fábricas, plantillas de currículum, etc. y, por supuesto, algunos conceptos básicos de pruebas , herramientas, pruebas de aplicaciones, pruebas de interfaz, linux, base de datos mysql y otros conocimientos básicos ), ¡creo que te hará progresar mejor!
Método de adquisición de información:
