[Compartir experiencias] Gestión de casos de prueba de software
Alguien dijo: ¿Aún no conoces los casos de prueba? ¿No describe simplemente los pasos de la prueba?
Esta respuesta no es incorrecta, pero si lo piensa así en su corazón, solo puede significar que no comprende los casos de prueba.
Además de describir los comportamientos de prueba, los casos de prueba también se utilizan para verificar si el objetivo bajo prueba cumple con los requisitos. Principalmente prueban la capacidad de inducción organizacional de un ingeniero de pruebas. Las fuentes de entrada suelen ser cartas de compromiso, casos de uso y su propia experiencia en el área empresarial. La profesionalidad de un ingeniero de pruebas de software a menudo se refleja en los casos de prueba que diseña.
El conjunto de casos de prueba diseñado por ingenieros profesionales puede describir su propio comportamiento y guiar a otros para implementarlo. Destaca la profundidad y el pensamiento del usuario es excelente.
Aunque el formato está básicamente finalizado:
Solo hay muchos tutoriales en Internet sobre esta parte, por lo que no entraré en detalles.
Solo es necesario enfatizar que el formato solo puede garantizar la claridad de los casos de prueba, pero no puede mejorar la capacidad de diseño de los casos de prueba. Entonces, ¿cómo se escriben casos de prueba? Todavía tenemos que comenzar con el diseño estructural. Es necesario mencionar aquí un concepto, HLTD (diseño de prueba de alto nivel), que puede entenderse de manera simple y aproximada como el diseño de un esquema de prueba.
Al igual que escribir un artículo, haremos un borrador antes de escribir el texto principal, enumeraremos la idea central y el esquema del párrafo, y luego lo escribiremos.
Escribir casos de prueba es un proceso similar. En primer lugar, los puntos de prueba están delineados y tienen un diseño estructurado. Por lo general, se clasifica en funciones o módulos grandes, luego se refina en clasificaciones de segundo o incluso tercer nivel y, finalmente, se enumeran puntos de prueba específicos. En esta etapa del diseño, el autor tiende a utilizar mapas mentales (mapas cerebrales), que son más intuitivos que las herramientas tradicionales de software documental.
Porque al final se verá la situación general y también se reflejarán las fallas. Solo es adecuado para pensar y clasificar, no para la gestión de documentos.
Registrar estos puntos de prueba estructurados es lo que llamamos casos de prueba.
Entonces desde aquí podemos ver que el propósito de cada caso de prueba es claro, que es verificar uno o un tipo de punto de prueba. La granularidad debe sopesarse en función de la situación real de la empresa. Demasiado grueso no favorece el resumen de la cobertura de los puntos de prueba y demasiado fino consumirá más energía.
Un caso de prueba es en realidad un documento muy detallado, que inevitablemente consumirá una parte considerable de la energía del ingeniero de pruebas. En la era del desarrollo de software tradicional, incluso se utiliza como indicador de KPI.
Pero con el surgimiento de la era ágil, una voz comenzó a impactar esta percepción.
Los primeros practicantes ágiles sólo interpretaron el Manifiesto Ágil en la superficie, creyendo que "sólo se necesita software, no se necesita documentación". Esto llevó directamente a este período en el que una gran cantidad de equipos carecían de documentación detallada o incluso de documentación básica.
Hoy en día, cada vez más profesionales ágiles se dan cuenta de que el Manifiesto Ágil no aboga por "la necesidad de documentación detallada". Por el contrario, el Manifiesto Ágil reconoce que "la documentación detallada es muy importante" y plantea requisitos más altos: "el software que funcione es más importante".
Muchos equipos todavía están estancados en la elección de las herramientas de documentación para los casos de prueba. Software ofimático tradicional, como Word y Excel.
Sin embargo, en el entorno de mercado actual, donde todo es más rápido que otros, la demanda de que los miembros del equipo colaboren de manera eficiente y disfruten de la información del equipo en tiempo real es cada vez mayor. La gestión de casos de prueba basada en plataforma eventualmente aumentará. ser inevitable. Además de la documentación, la plataforma se utiliza para desarrollar planes y mostrar avances y resultados.
De hecho, en la era tradicional, las empresas de software más grandes han utilizado plataformas para gestionar casos de prueba, lo que demuestra una vez más que la era ágil no significa revertir la experiencia y los resultados pasados, sino proponer estándares más altos.
En la actualidad existen plataformas de gestión relativamente conocidas basadas en Jira como complemento, como Zefa, Xray, synapseRT y TM4J. También existen plataformas independientes de código abierto, como TestLink, o de pago. plataformas independientes, como TestRail.
Lo consideramos principalmente desde la perspectiva de la ecología, el costo de implementación, la escalabilidad y el costo.
Zefa siempre ha tenido una gran reputación, pero en realidad no se ajusta a los hábitos de los chinos y es incómodo de usar. El caso de uso se lanza directamente usando Jira y la función es relativamente simple. La gestión de casos de uso se centra en la correlación entre planes y ciclos. Debido a que es un complemento de Jira, se correlaciona bien con otros problemas (requisitos, tareas, defectos) en Jira. Sin embargo, la visualización de su gestión de casos de uso no es muy buena y no existe el concepto de conjunto de casos de uso. En términos de migración, los tipos admitidos por la importación de datos son limitados. En términos de extensiones, si desea utilizar su API, debe instalar otro complemento. Su costo es moderado.
X-Ray es bastante satisfactorio y también utiliza las preguntas de Jira para crear casos de prueba. Sin embargo, existen hasta cinco nuevos tipos de problemas, que son extremadamente complejos. La capacidad de correlación es la misma que la de Zefa. Los tipos de importación de datos admitidos son limitados y la API integrada está disponible. Su costo es moderado.
SynapseRT fue desarrollado por los chinos y tiene el mejor efecto de localización y funciones potentes. Existe el concepto de conjunto de casos de uso, y los casos de uso también se amplían con el problema de Gila. La importación de datos es compatible con otras plataformas como TestLink y Zefa. La capacidad de correlación es la misma que la de Zefa. Los tipos admitidos por la importación de datos aún son limitados y también tiene su propia API para usar. Y el costo es relativamente bajo.
TM4J utiliza una página separada para administrar casos de prueba, que está separada de la compleja página de problemas de Jira y es difícil comenzar. La función de importación de datos es poderosa y cubre muchos tipos y algunas plataformas conocidas. Las capacidades de correlación son las mismas que las de los complementos anteriores y también hay API disponibles. Pero el costo es relativamente alto.
TestLink es una plataforma de gestión de pruebas independiente, totalmente funcional y gratuita. Se puede pensar en plataformas conocidas como Gila, pero como no es un sistema Atlantis, la experiencia ecológica no es alta. El defecto es que la interfaz es fea y puede afectar fácilmente el estado de ánimo del ingeniero. Solía usar su propia API para embellecer la interfaz de usuario.
TestRail es una poderosa plataforma comercial con la que no tengo mucho contacto, así que no haré comentarios casualmente.
En general, aunque TestLink, como la principal plataforma de gestión de casos de uso gratuita y de código abierto, es muy científico en la gestión de casos de uso y siempre vale la pena aprenderlo, mi empresa ya está utilizando Jira y lo está utilizando actualmente. Al implementar DevOps, a menudo recibo apoyo del subdirector del Atlassian China Community Research Institute, por lo que TM4J se convirtió en la opción final:
El productor es bastante fuerte. Además de TM4J, Swagger es en realidad su producto y Swagger ya es un producto altamente reconocido.
Como se puede ver en la introducción en el sitio web oficial, TM4J es relativamente moderno:
Primero, echemos un vistazo a cómo usar TM4J para escribir casos de prueba.
Hablando jerárquicamente, creamos directorios y subdirectorios de acuerdo con HLTD para que todos puedan comprenderlos y leerlos. El punto de prueba final se instancia como un caso de prueba. Este caso de prueba tiene una clave globalmente única.
Haga clic en el botón Nuevo para crear un nuevo caso de prueba. De forma predeterminada, se encuentra en la pestaña Detalles, donde puede definir el nombre, el propósito y los requisitos previos del caso de prueba. Puede establecer el estado, la prioridad, el componente de pertenencia y agregar algunas etiquetas fáciles de administrar en los detalles.
Cambie a la pestaña Scripts de prueba, el valor predeterminado es el tipo Paso a paso y agregue cada paso de prueba de acuerdo con PASO-DATOS DE PRUEBA-RESULTADO ESPERADO.
También cabe mencionar que en la pestaña Trazabilidad puedes asociar el lanzamiento de Gila y la página de confluencia.
Normalmente necesitamos desarrollar un alcance para el lanzamiento y entrega de cada producto, por lo que la gestión del plan es esencial.
La administración del plan recomienda crear un directorio de nivel superior basado en la versión de lanzamiento y luego crear un directorio de segundo nivel para los tipos de prueba, como regresión, nuevas funciones, de un extremo a otro, interfaces y rendimiento. , etc.
La creación del plan de prueba en sí no es complicada, excepto definir el nombre, el propósito, el estado, la persona a cargo del plan y agregar algunas etiquetas.
También es necesario asociar un requisito o una página de fusión. Es posible que el ciclo de prueba no exista cuando se crea el plan de prueba por primera vez, pero cuando el ciclo de prueba se cree más adelante, estará asociado en ambas direcciones.
El ciclo de prueba es un vínculo clave entre el anterior y el siguiente. Conecta el plan de prueba con los casos de prueba específicos.
Por lo general, la entrega de una versión pasará por entre 3 y 5 sprints, y el alcance de cada sprint puede no ser exactamente el mismo.
Después de crear un nuevo ciclo de prueba, nombre, descripción y detalles.
Ingrese a la pestaña del caso de prueba, haga clic en +Agregar caso de prueba y agregue el caso de prueba escrito.
Este paso hace que el caso de prueba tenga propiedades de proyecto.
Finalmente, haga clic en la lupa detrás del plan de prueba en la pestaña Trazabilidad del ciclo de prueba.
Relacionar planes de pruebas completados mediante búsqueda.
Después de crear un ciclo de prueba, puede ingresar al ciclo y explorar los casos de prueba asignados a su propio nombre. Esta es una interfaz que todos los ejecutores de pruebas deben usar. También puede usar Agrupar por para clasificar de acuerdo con diferentes reglas, como diferentes directorios durante el ciclo de prueba.
Para la ejecución de los pasos del caso de uso, TM4J proporciona algunos botones de acceso directo que pueden marcar directamente si pasa, falla y bloquea. Puede hacer clic en el botón de engranaje para crear y encontrar rápidamente problemas de Jira para correlacionarlos. Por supuesto, además de asociar la pregunta con el paso, también puede marcar la pregunta para este caso de uso y hacer clic en +▼ después de la pregunta para tomar acción. Ésta es la ventaja de una plataforma unificada.
Aunque podemos ver el progreso de la prueba al ver la lista de ciclos de prueba, se pueden mostrar más datos a través del informe de prueba.
La función de informes de TM4J nos proporciona una gran cantidad de plantillas para facilitar la tarea a algunos administradores de calidad de pruebas sin experiencia.
Finalmente, al autor le gustaría decir que las pruebas no pueden ser un negocio independiente, sino que deberían ser más bien una colaboración con otras funciones. Especialmente en la era ágil actual, la ejecución de casos de prueba puede requerir la atención de los ingenieros de desarrollo y las situaciones de prueba pueden requerir la intervención de los gerentes de producto en cualquier momento. Por lo tanto, recomendamos encarecidamente que los evaluadores de software intenten elegir algunas plataformas de colaboración multifuncionales.