1: proceso de revisión
R: Realice los siguientes preparativos antes de comenzar
1. Determine el motivo de la revisión
2. Determine el momento de la revisión
3. Identificar a los participantes en la revisión.
4. Aclare el contenido de la revisión.
5. Determinar el final de los criterios de revisión.
6. Con al menos un día de anticipación, el contenido que necesita ser revisado se enviará al personal relevante de la reunión de revisión en forma de correo electrónico. E indicar la hora y el lugar de la revisión detallada y el personal involucrado en la compensación.
7. En el correo electrónico, recuerde al personal relevante de la reunión de revisión que lea el contenido de la revisión al menos una vez y registre las preguntas relacionadas para que puedan plantearse en la reunión de revisión.
8. El anfitrión de la reunión (generalmente un redactor de casos de uso) debe resolver las preguntas relevantes antes de la reunión para que puedan plantearse en la reunión.
B: Iniciar revisión
1. Realice una reunión de revisión. Los participantes dieron comentarios y sugerencias después de la explicación del diseñador, y al mismo tiempo llevaron a cabo un registro de revisión detallado.
2. Comunicarse con el personal pertinente por correo general.
3. Las herramientas de mensajería instantánea generales se comunican directamente con el personal pertinente
4. Revise de acuerdo con el contenido de la revisión.
2: Juzgar el contenido
1. Si la disposición estructural del diseño del caso de uso es clara y razonable, y si conduce a una cobertura eficiente de los requisitos.
2. Si el arreglo de prioridad es razonable.
3. Si se deben cubrir todos los puntos funcionales de los requisitos de prueba.
4. Si el caso de uso es bien ejecutable. Por ejemplo, si los requisitos previos, los pasos de ejecución, los datos de entrada y los resultados esperados del caso de uso son claros y correctos; si existen métodos de verificación obvios para los resultados esperados.
5. ¿Se han eliminado los casos de uso redundantes?
6. ¿Contiene suficientes casos de prueba negativos? Completamente definido, si se usa la regla 2 y 8 aquí, es cuatro veces el número de casos de uso positivos. Después de todo, en un software robusto, el 80% del código está "protegiendo" el 20% de la implementación de la función.
7. Ya sea para diseñar casos de prueba para escenarios de uso de usuarios y procesos de uso desde el nivel de usuario.
8. Si es conciso y reutilizable. Por ejemplo, los pasos o procesos altamente repetitivos se pueden extraer y definir como algunos pasos estándar reutilizables.
3: Revisores participantes (aquí se dividirá en varios niveles para su revisión)
1. Revisión del departamento, revisión que involucra a todos los miembros del departamento de pruebas.
2. Revisión de la empresa, incluidos directores de proyectos, analistas de requisitos, diseñadores de arquitectura, desarrolladores y probadores.
3. Revisión del cliente, incluidos los desarrolladores y evaluadores del cliente. Esta situación es más común en empresas de outsourcing
1. Propósito de la revisión de casos de uso La
especificación del proceso de revisión de casos de prueba proporciona principalmente pautas para el desarrollo del trabajo de revisión de casos de prueba y estandariza la gestión de revisión de casos de prueba.
2. Contenido del proceso de revisión del caso de prueba
2.1 Prerrequisito: Los probadores han escrito un caso de prueba del módulo funcional completo o han completado todos los casos de prueba;
2.2 Entrada del proceso: A. Caso de prueba; B. Especificación de requisitos;
2.3 Salida del proceso: A. Lista de registros de problemas ; B. Informe de revisión de caso de prueba;
2.4 Participantes en la revisión: gerentes de proyecto, líderes de prueba, evaluadores, analistas de requisitos, diseñadores de arquitectura, desarrolladores;
2.5 Método de evaluación:
1) Convocar una reunión de evaluación. Los participantes hacen comentarios o sugerencias después de que los redactores de los casos de prueba explican y registran las minutas de la reunión de revisión al mismo tiempo;
2) Comunicarse con el personal relevante a través de correos electrónicos y herramientas de comunicación oportunas.
Independientemente del método que se adopte, los documentos relevantes de los casos de prueba que deben revisarse deben enviarse por correo electrónico al personal relevante que participa en la revisión con anticipación, y se debe recordar al personal relevante que participa en la revisión que revise el contenido de la revisión antes y registrar los problemas relacionados para que se puedan plantear en la reunión de revisión para ahorrar costos de comunicación.
2.6 Lista de comprobación para casos de uso de revisión:
1) Si los casos de prueba están escritos de acuerdo con la plantilla definida por la empresa;
2) Si la descripción del caso de prueba en sí es clara y si existe ambigüedad;
3) Si el contenido del caso de prueba es correcto y si es consistente con los requisitos Consistente;
4) Si el resultado esperado del caso de prueba es cierto y único;
5) Si los pasos de la operación deben ser consistentes con la descripción;
6) Si el caso de prueba cubre todos los requisitos;
7) Si el diseño de prueba es redundante;
8) Prueba si los casos de uso son ejecutables;
9) Si diseñar casos de prueba para escenarios de usuario y procesos comerciales desde el nivel de usuario;
10) Si los casos de prueba de escenarios cubren los procesos comerciales más complejos ;
11) Si el diseño del caso de uso incluye casos de uso positivos y negativos;
12) el elemento de salida es generado automáticamente por el sistema indica si las reglas de generación;
13) de la prueba debe incluir una inspección intermedia y datos de antecedentes;
14) la prueba debe ser el nombre y la identificación correctos;
15) para ser marcado como prueba Prioridad de ejecución;
16) Los casos de prueba incluyen información de configuración relevante: entorno de prueba, datos, casos previos a la prueba, autorización del usuario, etc .;
17) Cada paso del caso de prueba debe ser <= 15 pasos;
18) El script de prueba automatizado debe tener comentarios (los comentarios deben incluyen: Propósito, entrada, resultados esperados, etc.);
19) ¿Se enumeran y explican los requisitos de prueba no funcionales o los requisitos no comprobables en el caso de uso?
2.7 Criterios de salida:
1) Recopilar la información de retroalimentación del personal relevante durante el proceso de revisión (es decir, la lista de registros de problemas) y actualizar los casos de prueba sobre esta base hasta que se apruebe la revisión;
2) Después de la revisión, la persona a cargo de la prueba emitirá un informe de revisión del caso de prueba al personal pertinente;
3) Los resultados de la revisión son aprobados y confirmados por el director del proyecto.
2.8 Mecanismo de control: Al
adoptar la reunión de revisión, el anfitrión debe tratar de captar el progreso de la reunión y tratar de completar el trabajo de revisión a tiempo y de manera efectiva;
Anexo 1: Lista de registros de problemas Anexo 2: Informe de revisión de caso de prueba
¿Cuál es la importancia de la revisión de casos de prueba? Los casos de prueba deben cumplir con los requisitos del producto, pero las funciones del producto están escritas por el desarrollo, y la lógica del desarrollo y la implementación deben revisarse y comunicarse para evitar puntos lógicos poco claros; puede mejorar la corrección de la prueba. casos y mejorar la eficiencia de las pruebas; Mejorar la cobertura de los casos de prueba y encontrar errores mejor.
3. Tiempo de revisión de casos de uso
Para proyectos de desarrollo ágil, se recomienda controlarlo en media hora.
Si cree que los requisitos son complejos y hay demasiados puntos de función que cubrir en media hora, se recomienda que priorice los puntos de función, revise primero los casos de uso con alta prioridad y luego revise los casos de uso con muchos preguntas y, finalmente, se pueden revisar los casos de uso con funciones simples. Recuerde siempre el objetivo de revisión de nuestro caso de uso, no solo una formalidad.
Cuarto, la forma de revisión de casos de uso.
1. Controle los casos de prueba, lea de arriba a abajo, de izquierda a derecha, uno por uno.
Esta es la práctica actual de muchas empresas. Si lo ha hecho antes, creo que puede que no le guste este método porque lleva mucho tiempo, independientemente de la prioridad, y el entusiasmo y la atención de los participantes disminuye gradualmente, y la eficiencia de toda la revisión del caso de uso es baja. Como anfitrión, también hablé seco y seco, con la mitad del esfuerzo.
2. Primero revise los casos de uso con funciones complejas, alta prioridad y muchas preguntas, y luego revise los puntos de función con funciones simples y de baja prioridad.
En el proceso de revisión, no habrá conclusiones por un tiempo, que se pueden registrar como el foco de discusión y seguimiento después de la reunión.
Este enfoque tiene muchas ventajas. Al comienzo de la revisión, la atención y el entusiasmo de todos son altos. Durante este período de tiempo, hay cuestiones difíciles y cuestionables que debatir, y la eficiencia es alta. Haga las cosas más importantes primero.
Además, toda la reunión de revisión tiene prioridades claras, con clímax y más lentas, que pueden lograr nuestros objetivos de revisión de manera más eficiente.
5. Revisión formal
Hay varios detalles a los que se debe prestar atención en el proceso de revisión formal. Si lo ha hecho todo, entonces puede decir que la revisión completa es exitosa y valiosa.
1. La revisión debe realizarse de acuerdo con la prioridad del caso de uso y la complejidad de la función;
2. Trate de hacer todo lo posible durante el proceso de revisión, con pensamiento claro, y use el lenguaje más conciso para explicar cada punto funcional;
3. Las preguntas que no se puedan resolver durante más de 5 minutos se reservan para discusión y seguimiento después de la reunión.
6. ¿Qué se debe hacer después de la revisión?
No es que la revisión termine cuando termine la reunión de revisión. De hecho, esto es solo la mitad de la revisión completa del caso de uso.
Una vez finalizada la revisión, los casos de prueba se resuelven lo antes posible y el contenido revisado se reordena y complementa.
Para el contenido no confirmado en la reunión, haga un seguimiento después de la reunión hasta que se confirme el resultado.
Cuando pregunte, hagamos un resumen de la reunión de revisión de casos de uso simple (como, por ejemplo, qué puntos de función se han revisado y cuáles se han completado, qué funciones de módulo se han cambiado, qué funciones se han pospuesto para el próximo número, etc.),
Este resumen es un resumen de todo el trabajo de revisión de casos de uso para usted, y también es importante compartir información con otros miembros del equipo del proyecto al mismo tiempo.
Grupo de intercambio de pruebas de software: 785128166
Cuenta pública de WeChat: Programador Erhei; Después de prestar atención, puede recibir un conjunto de recursos de video de forma gratuita; explique en detalle: pruebas automatizadas de Python, automatización web, automatización de interfaces, automatización de terminales móviles, experiencia de entrevistas y otro contenido relacionado, el valor de los recursos de aprendizaje dependen de su acción, no sea un "coleccionista"
Aquí hay una colección de artículos de productos secos seleccionados para pruebas funcionales: