El concepto y clasificación de los errores.

En los artículos anteriores, hemos discutido los casos, los métodos de diseño y las herramientas del diseño de casos de prueba. En este artículo, hablemos de errores en los programas.

El llamado "(Bug)" se refiere a errores o defectos ocultos en el programa.

Ya en el apéndice del ciclo de trabajo de prueba de software, ya hemos explicado el origen del error. Haga clic en el enlace para verlo.

Los registros de errores deben incluir básicamente:

Número de error: el ID único del error, para que los errores puedan descubrirse lo antes posible. ※.

Título del error: resumen del error, que explica el contenido general del error. ※.

※Severidad y prioridad del error: como factor decisivo para determinar si el defecto se soluciona y la prioridad de reparación del defecto. ※.

Módulo generado por error: registra el módulo al que pertenece el error para facilitar el desarrollo y la localización del problema. ※.

La versión correspondiente al error: la versión del software correspondiente al error, que facilita el posterior archivo estadístico y el desarrollo y posicionamiento del problema. ※.

Descripción del error: entorno del error, pasos detallados, resultados esperados y resultados reales. ※.

Adjuntos: incluidos, entre otros, capturas de pantalla, registros, vídeos, archivos de muestra y aplicaciones. ※También es fácil de reproducir y solucionar defectos.

Las anteriores son las condiciones necesarias para informar errores (crear errores). Corregiremos y volveremos a probar los errores más adelante. Para registrar el trabajo de seguimiento, el error también debe incluir:

※Estado del error: iniciado, en reparación, en reparación, en prueba, en prueba, prueba aprobada/fallada, cerrado, etc. , que se mencionará en ciclos de errores posteriores.

Solucionador de errores: Solucionador de errores. ※.

Reevaluador de errores: normalmente, la persona que informa el error será devuelta a alguien para que la pruebe, pero en algunos casos, como si el informante del error acumula demasiadas tareas, se asignará a otras personas. , por lo que generalmente se registra a la persona responsable de volver a probar errores. ※.

Descripción de la corrección del error: escrita por el corrector del error, explicando la causa del error, ideas de corrección, etc. ※.

※Descripción del error de la nueva prueba: escrita por el personal de la nueva prueba, explicando el proceso de la nueva prueba, los resultados de la nueva prueba, etc. ※.

※Notas de error: notas para registrar información adicional.

Como dice el refrán, todo tiene sus prioridades. Esto es cierto en la vida, y también lo es el trabajo. Los defectos de software no son iguales. Según el entorno actual, clasificamos diferentes defectos según su gravedad y prioridad. Los desarrolladores utilizan esta clasificación para decidir si el error debe modificarse y el orden en el que debe modificarse ("Prioridad de defecto").

Los métodos de clasificación específicos varían de una empresa a otra, pero los principios generales son generalmente los mismos:

Severidad: Indica la gravedad del defecto de software, así como la posibilidad y el impacto. del usuario que encuentra el defecto. ※.

Prioridad: Indica la importancia y urgencia de solucionar el defecto. ※.

Aquí brindamos métodos comunes de clasificación de gravedad y prioridad. Cabe señalar que este es solo un ejemplo. El método de división de cada empresa es diferente y existen algunos cambios para su referencia.

Severidad:

Un sistema falla, se pierden datos, se destruyen datos, se destruye la seguridad, las funciones principales no se implementan (por ejemplo, QQ no tiene una función de chat), y la implementación de funciones principales no cumple con los requisitos (por ejemplo, la función de chat QQ solo puede enviar mensajes pero no recibir mensajes).

B. La operación es incorrecta, el resultado es incorrecto, cierto punto del módulo funcional no está implementado (por ejemplo, QQ no tiene recordatorio de mensaje) y la compatibilidad es incorrecta.

c Problemas menores, errores ortográficos, diseño feo de la interfaz de usuario, errores raros en determinadas situaciones.

D. Algunas sugerencias sobre facilidad de uso (también se pueden clasificar en 3 categorías)

Prioridad:

A.

B. Debe arreglarse antes del lanzamiento del producto.

C. Si el tiempo lo permite, se debe reparar.

D. Se puede arreglar sin afectar el lanzamiento.

Nuevamente, la lista anterior es solo un ejemplo, y se deben formular reglas específicas de clasificación de defectos en función de proyectos y escenarios de aplicación reales. Por ejemplo, generalmente consideramos que las fallas que corrompen los datos de los usuarios son más graves que simples errores tipográficos. Pero, ¿qué pasa si la corrupción de datos sólo ocurre en casos excepcionales donde los usuarios rara vez los usan y los errores tipográficos causan problemas con todos los usuarios que instalan el software? En este momento, la prioridad y la gravedad de la corrupción de datos y los errores ortográficos son evidentes. La gravedad y la prioridad de los errores ortográficos deben ser mayores que la corrupción de datos.

La gravedad y la prioridad son extremadamente importantes para quienes revisan los informes de defectos y deciden qué defectos de software deben corregirse y en qué orden. Si a un programador se le ordena arreglar 10 defectos, debería comenzar con defectos de gravedad 1 y prioridad 1, en lugar de arreglar defectos simples primero.

De manera similar, dos gerentes de proyecto (uno administra el portal publicitario/software de juegos y el otro administra monitores hospitalarios/software de pruebas de rendimiento) tomarán dos decisiones cuando se enfrenten al mismo problema, como por ejemplo: "Es una página hermosa". . En el primero, la prioridad puede ser 2, mientras que en el segundo, la prioridad puede ser 3 o 4.

Bien, eso es todo por hoy. Si tiene alguna pregunta, deje un mensaje para comunicarse conmigo a tiempo y le responderé lo antes posible. Gracias ~ ¡Hasta la próxima!