¿Por qué es tan importante el posicionamiento?
Puede aclarar si un problema es realmente un "error"
Muchas veces encontramos la causa del problema, sólo para descubrir que no se trata de un error en absoluto. Cuando la causa es clara, se reducen los falsos positivos.
Múltiples sistemas interactúan, lo que puede señalar claramente qué sistema está defectuoso, evitar "patear la pelota" y mejorar la eficiencia de la resolución de problemas.
Mejorar la confianza entre desarrollo y pruebas, comunicarse de manera más efectiva, cooperar mejor y mejorar la puntualidad en el desarrollo y modificación de errores.
Una comprensión más efectiva de la lógica interna del sistema y del flujo de procesamiento del flujo de datos puede mejorar el nivel de los probadores. Una vez reparado el defecto, el rango de prueba afectado se puede evaluar con mayor precisión y volver a probar con mayor precisión.
Puede reducir la tasa de defectos
Este es posiblemente el más importante. En el sistema de errores, los desarrolladores deben registrar la causa del error. Solo cuando tengamos una comprensión más completa de los errores podremos juzgar si el desarrollo y la escritura son las verdaderas razones, y también nos ayudará a analizar y clasificar errores en el futuro. De acuerdo con el análisis de errores, podemos planificar con anticipación en un manera específica y luego mejorar la calidad del producto y reducir los defectos
01. Antes de posicionar la causa
Cuando encuentre un problema, no se apresure a localizar la causa.
1. Guarde los registros generados por errores:
Lo primero que debe hacer es guardar los registros generados por el error para asegurarse de que se pueda reproducir.
¿Por qué mantener registros? Porque si no se puede reproducir en el futuro, no podrá probar la existencia del error.
2. Eliminar problemas de bajo nivel:
Luego están los problemas de bajo nivel que excluyen el control de calidad, problemas comunes de bajo nivel:
[anfitriones incorrectos]
El archivo de hosts sirve principalmente para acelerar la velocidad de resolución de un determinado nombre de dominio o sitio web, a fin de lograr el efecto de acceso rápido, y también puede bloquear el sitio web.
Los hosts anormales pueden hacer que algunas páginas web sean inaccesibles y se puedan cargar, pero la página web no se puede mostrar normalmente.
[Fallo de red]: captura de paquetes, ping
Causado por el impacto de herramientas, como el violinista.
Y postura operativa incorrecta, etc.
3. Excluir problemas de datos (datos sucios):
A veces, el servidor informará un error 500. Después de verificar el registro, se informará un puntero nulo, por lo que es probable que los datos de la tabla asociada en la base de datos se hayan eliminado artificialmente.
Datos sucios: los datos recuperados del objetivo han caducado, son incorrectos o no tienen sentido; este tipo de datos se denominan datos sucios.
Lectura sucia: la lectura sucia se llama lectura sucia
02. La idea de posicionar el problema.
Revisar orden:
Nivel de entorno de usuario -> nivel de presentación -> nivel de control lógico -> nivel de servicio -> nivel de base de datos
1. Nivel del entorno del usuario
Se refiere principalmente a si se puede utilizar el entorno básico. Por ejemplo:
Si se hace ping a la red
¿Son correctas las configuraciones de ip y puerto?
¿La versión jdk cumple con el estándar?
Puede ser que el sistema funcione de forma anormal debido a la incompatibilidad de la versión jdk, este tipo de problema depende de la situación real para decidir si es compatible.
El proxy está configurado en la red.
Red débil (como js/css no completamente cargado, tiempo de espera agotado para la solicitud)
el navegador no es compatible
La versión del sistema no es compatible.
se elimina la base de datos
Datos sucios del entorno de prueba
Interruptor de configuración del proyecto
El entorno de prueba ha cortado ramas, etc.
Una vez completada la inspección, puede pasar al segundo paso.
2. Capa de visualización del usuario
Algunos problemas encontrados por los usuarios durante la visualización y otras operaciones durante el uso:
Estilos de página (problemas de estilo CSS)
Consejos para js durante la interacción (problema de interacción js)
Información rápida para el control del terminal
Visualización de texto (problema de texto html)
3. Capa de control lógico
En el proceso de operación del usuario, si la lógica de procesamiento comercial se implementa de acuerdo con el diseño anterior. O hay una excepción en el enlace intermedio, como el servidor de caché (como redis), el middleware de mensajes (como RabbitMQ), el middleware de acceso a datos, etc.
4. Capa de servicio
La capa de servicio a menudo verifica la configuración del servidor, por ejemplo, puede haber un problema con la configuración de Tomcat, la configuración de nginx, la configuración de jdbc, etc. Es mejor que los evaluadores comprendan sus configuraciones.
5. Capa de base de datos
Puede haber diferentes versiones de la base de datos entre el entorno de prueba y el entorno oficial, y diferentes formatos de datos y límites de longitud para el front-end y el back-end. Una vez completada la operación del usuario, el proceso de transacción es muy fluido, lo que no significa que no haya problemas con toda la transacción, y los evaluadores deben verificar si las tablas y campos registrados en la base de datos son correctos.
Si encuentra que los campos registrados no coinciden con los resultados esperados, puede consultar el registro para verificar si los campos enviados en el mensaje de solicitud son correctos y consistentes con los completados en la recepción.
Algunas operaciones registrarán varias tablas, por lo que es necesario verificar si el registro o la actualización de varias tablas es correcto, y el evaluador también debe estar familiarizado con la estructura de la tabla de datos del sistema bajo prueba.
6. Reglas generales
Los evaluadores experimentados han visto algunos errores muchas veces y pueden encontrar rápidamente la causa raíz, ir directamente al tema, informar o resolver el error rápidamente.
7. Otros
Los errores comunes también pueden deberse a motivos de construcción.
Por ejemplo, el código en sí es correcto, pero hay un problema después de fusionar el código con el troncal.
Por ejemplo, cuando hay un conflicto en el código, se resuelve manualmente
03. Cómo localizar el problema
1. Estrategias de posicionamiento comunes:
Las estrategias de posicionamiento comúnmente utilizadas se dividen en tres categorías: clase original (fuerza bruta), clase de retroceso (retroceso), clase de exclusión (eliminaciones de causas)
Método de ubicación de clase primitiva
El método de posicionamiento de clases original es el más utilizado y el menos eficiente, sólo se utiliza en situaciones desesperadas, la idea principal es "encontrar errores a través de la computadora".
Retroceder
El retroceso se puede utilizar con éxito para depurar programas
El método consiste en rastrear manualmente a lo largo del flujo de control desde el lugar donde ocurre el síntoma del error, hasta encontrar la causa raíz del error. Desafortunadamente, cuando el programa se hace más grande, las posibles rutas de rastreo aumentan significativamente, por lo que el rastreo manual es fuera de alcance..
Exclusión
Basado en los principios de inducción y deducción, se adopta el concepto de "divide y vencerás".
Primero determine todos los datos relacionados con la aparición del error, imagine la causa del error y utilice estos datos para probarlo o refutarlo. O enumere todas las causas posibles a la vez y descartelas una por una mediante pruebas. Siempre que el resultado de una determinada prueba muestre que ha surgido una determinada hipótesis, refine inmediatamente los datos y persiga la victoria.
2. Ver el código de estado
Código de estado 4xx: generalmente indica un problema del cliente (por supuesto, también puede ser un problema de configuración del servidor), como por ejemplo:
Si ocurre 401, depende de si se trae la información de autenticación correcta
Si ocurre 403, depende de si tienes permiso para acceder
404 depende de si la URL correspondiente realmente existe
Código de estado 5xx: generalmente indica que hay un problema con el servidor. Por ejemplo:
Si ocurre un error 500, significa que es un error interno del servidor, en este momento es necesario cooperar con el registro del servidor para localizar
Si se produce un error 502, el problema puede deberse a que el servidor se cuelga
Los errores 503 pueden deberse a una sobrecarga de la red
Si ocurre un error 504, es posible que el tiempo de ejecución del programa sea demasiado largo, lo que resulta en un tiempo de espera
3. Verifique el registro del servidor
Si ocurre un problema 5xx, o necesita verificar si el SQL ejecutado por la interfaz backend es correcto, nuestro método de solución de problemas más común es verificar el registro del servidor, como el registro de Tomcat. Los desarrolladores generalmente escriben información clave y mensajes de error para descubrir dónde radica el problema, por lo que los evaluadores también deben desarrollar el hábito de leer registros.
4. Verifique la configuración
En muchos casos, los errores no son problemas de código, sino problemas con la configuración de Tomcat, la configuración de nginx, la configuración de jdbc, etc. En este nivel, es mejor que los evaluadores puedan comprender sus diversas configuraciones y pueden pensar en problemas en esta área después de descubrirlos.
5. Ver el documento de requisitos.
A veces, la interacción entre el front-end y el servidor es correcta, pero no tiene sentido desde el punto de vista de las pruebas. En este momento, deberíamos revisar el documento de requisitos. Si no coincide con el documento de requisitos, entonces es necesario ver qué es más razonable cambiar, si cambiar el front-end, el servidor o ambos.
Hay un principio aquí, es decir, la interfaz adopta la menor lógica posible y solo es responsable de renderizar y mostrar. Por supuesto, no crea que el documento de requisitos es correcto, también puede haber errores, también deberíamos encontrar errores en el documento de requisitos y luego coordinarnos con PM para instar a FE o RD a realizar cambios.
6. Busque soporte de capacidad de prueba del desarrollo.
A veces, algunas pruebas relacionadas con el proceso de desarrollo también requieren desarrollo para brindar soporte de capacidad de prueba.
Por ejemplo, para verificar si la solicitud enviada por una interfaz a otra interfaz es correcta, puede dejar que el desarrollo imprima el registro de solicitudes completo, así como algunos cambios lógicos, modificar la cantidad de elementos de datos en la página, etc. todos pertenecen a la categoría de soporte de comprobabilidad.
04. Herramientas comunes para la localización de errores.
Firefox: firebug, desarrollador web, encabezados http en vivo, http fox
Complemento de IE: httpwatch
Herramienta de terceros: violinista
Herramienta de simulación de red lenta: acelerador de Firefox
05. Cómo distinguir errores de front-end y back-end
¿Por qué distinguir los errores de front-end y back-end?
Si se trata de un sistema desarrollado por varias personas, es imposible localizar claramente quién causó el error y es fácil enviarlo al desarrollador equivocado.
Al mismo tiempo, al enviar a los desarrolladores de front-end y back-end, todos tendrán una mentalidad de dependencia y el desarrollador pateará el error como una pelota, lo que retrasará el tiempo para que el desarrollo resuelva el error.
Además, si el equipo es grande o está compuesto por equipos de proyecto de varios lugares, inevitablemente aumentará los costos de comunicación, lo que requiere que primero indiquemos qué errores se envían al enviar errores en software de gestión de proyectos como ZenTao o Jira. Evite patear la pelota entre ellos.
Por lo tanto, la prueba debe aprender a distinguir errores de front-end y back-end por sí misma. Después de clasificar y procesar los errores, se mejorará la eficiencia de todo el equipo.
¿Cuáles son las características de los errores de front-end y back-end?
1. Utilice herramientas de captura de paquetes para el análisis.
Generalmente, existen herramientas de captura de paquetes (paquetes), como httpwatch, firebug, fiddler y charles.
Httpwatch y firebug son complementos del navegador que requieren descargas adicionales
Fiddler, Charles también necesita descargar el paquete de instalación e instalarlo por separado.
También existe una herramienta de captura de paquetes sencilla y práctica, que es el depurador F12 del navegador.
2. Localización de errores de interfaz
Los errores de front-end suelen estar relacionados con funciones, interfaces y compatibilidad, e involucran jstl, jsp, js, css y html. Hay dos errores principales:
Relacionado con JS
página
3. Localización de errores de back-end
El fondo involucra servlet, jms, ejb y muchos frameworks struts, hibernate, spring, ibatis, etc.
Los errores son difíciles de corregir, pero fáciles de encontrar. Lo principal es buscar errores en la consola y luego localizar el número de línea de error. Si no hay ningún problema con el archivo de configuración, entonces el error general es un puntero nulo o el subíndice de la matriz está fuera de los límites. Básicamente, observar las variables cercanas y los parámetros del método puede localizar el error.
06. Después de localizar el problema
Después de encontrar el problema o localizar la causa del problema, se debe continuar, es decir, confirmar el problema nuevamente. El llamado problema de confirmación es averiguar si el problema ocurre cada vez, es un evento de probabilidad o es un problema relacionado con la herramienta:
Por ejemplo, ¿sigue apareciendo el navegador? Si no aparece otro navegador, es probable que se trate de un problema de compatibilidad del front-end.
Por ejemplo, el control de paso de página, muchas páginas del sistema a probar tienen controles de paso de página, por lo que es necesario verificar si este problema ocurre en cada página y luego proporcionar una explicación unificada al informar errores, lo cual también es más conveniente para los desarrolladores procesar en lotes y evitar fugas.
Finalmente me gustaría agradecer a todos los que han leído atentamente mi artículo, la reciprocidad siempre es necesaria, aunque no es algo muy valioso, puedes quitártelo si lo necesitas:
Subprograma de entrevista de prueba de software
¡El banco de preguntas de pruebas de software superado por millones de personas! ! ! ¡Quién es quién lo sabe! ! ! El miniprograma de cuestionarios más completo de toda la red, puedes usar tu teléfono móvil para hacer los cuestionarios, en el metro o en el autobús, ¡enróllalo!
Se cubren las siguientes secciones de preguntas de la entrevista:
1. Teoría básica de pruebas de software, 2. web, aplicaciones, pruebas de función de interfaz, 3. red, 4. base de datos, 5. linux
6. web, aplicación, automatización de interfaz, 7. pruebas de rendimiento, 8. conceptos básicos de programación, 9. preguntas de la entrevista de horas, 10. preguntas de prueba abiertas, 11. pruebas de seguridad, 12. conceptos básicos de informática
Estos materiales deberían ser el almacén de preparación más completo y completo para los amigos [de pruebas de software]. Este almacén también ha acompañado a decenas de miles de ingenieros de pruebas en el viaje más difícil. ¡Espero que pueda ayudarlo a usted también!