[Compartir experiencias] Gestión de casos de prueba de software

Este artículo incluye la redacción de especificaciones de casos de prueba y el intercambio de gestión de casos de uso. Por lo tanto, tiene cierta importancia de referencia tanto para los ingenieros de pruebas junior como para los gerentes de equipos de calidad. Los métodos y herramientas involucrados en este artículo no son las únicas soluciones. Espero que obtenga no solo la superficie del texto, sino también algunas de las ideas compartidas en el artículo.

Algunas personas dicen: ¿Aún no conoces los casos de prueba? ¿No se trata simplemente de describir los pasos de la prueba?

No hay nada de malo en responder de esta manera, pero si solo lo piensa en su corazón, solo se puede decir que no comprende el caso de prueba.

Además de ser una descripción del comportamiento de la prueba, los casos de prueba son más una verificación de si el objetivo probado cumple con los requisitos. A menudo prueba principalmente la capacidad de inducción organizacional de un ingeniero de pruebas. cartas de compromiso, casos de uso (Use Case) y su propia experiencia en el conocimiento del dominio empresarial. El profesionalismo 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 no solo puede describir su propio comportamiento, sino también guiar a otros para implementarlo. No solo enfatiza la profundidad, sino que también tiene un excelente pensamiento del usuario.

Aunque en cuanto a formato, básicamente está finalizado:

Respecto a esta parte, solo hay muchos tutoriales en Internet, por lo que no entraré en detalles.

Pero el punto importante a enfatizar es que el formato solo puede garantizar la claridad de los casos de prueba, pero no puede mejorar las capacidades de diseño de los casos de prueba. Entonces, ¿cómo escribir casos de prueba? Comencemos con el diseño estructurado. Hay un concepto que es necesario mencionar aquí, HLTD [Diseño de prueba de alto nivel], que puede entenderse simple y crudamente como el diseño de un esquema de prueba.

Al igual que cuando escribimos un artículo, antes de escribir el texto principal, primero haremos un borrador, enumeraremos la idea central y el esquema del párrafo, y luego lo puliremos.

Escribir casos de prueba es una rutina similar. Primero, enumere los puntos de prueba como un esquema y tenga un diseño estructurado. Por lo general, se clasifica en funciones o módulos grandes y luego se refina en categorías de segundo o incluso tercer nivel y, finalmente, se enumeran puntos de prueba específicos. Para esta etapa de diseño, el autor prefiere utilizar mapas mentales (mapas cerebrales). En comparación con las herramientas de software de documentos tradicionales, la presentación de los mapas mentales es más intuitiva.

Dado que al final será un panorama general, los defectos también se reflejarán. Solo es adecuado para ordenar ideas y no para la gestión de documentos.

Documentar estos puntos de prueba bien estructurados es lo que llamamos casos de prueba.

Entonces desde aquí podemos ver que el propósito de cada caso de prueba es muy claro, que es verificar uno o un tipo de punto de prueba. La granularidad debe sopesarse de acuerdo con la situación real de la empresa. Demasiado grueso no favorece la cobertura del punto de prueba. En resumen, desmantelarlo demasiado finamente consumirá más energía.

El 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 como métrica de KPI.

Pero con el auge de la era ágil, una voz comenzó a impactar esta percepción.

Los primeros practicantes ágiles solo interpretaron el Manifiesto Ágil en la superficie literal, creyendo que "solo 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 alguna documentación básica.

Hoy en día, cada vez más profesionales ágiles se dan cuenta de que lo que defiende el Manifiesto Ágil no es "la falta de documentación detallada". Por el contrario, el Manifiesto Ágil reconoce que "la documentación exhaustiva es importante" y propone más cosas. requisitos: "El software que funcione es más importante"

En cuanto a la elección de las herramientas de documentación de casos de prueba, muchos equipos todavía se apegan al software de oficina tradicional, como Word y Excel

p>

Sin embargo, en el entorno de mercado actual donde todo se hace más rápido, la demanda de colaboración eficiente entre los miembros del equipo y el intercambio de información del equipo en tiempo real es cada vez mayor. La gestión de casos de prueba basada en plataforma debe, en última instancia, pertenecer a ellos. Además de la documentación, también utiliza La plataforma desarrolla planes y muestra el progreso y los resultados.

De hecho, en la era tradicional, las empresas de software más grandes ya han utilizado plataformas para gestionar casos de prueba. Esto demuestra una vez más que la era ágil no significa revertir la experiencia y los resultados pasados, sino proponer requisitos más altos.

Hoy en día, las plataformas de gestión relativamente conocidas incluyen complementos basados ​​en Jira, como Zephyr, Xray, synapseRT y TM4J. También existen plataformas independientes de código abierto: como TestLink o plataformas independientes de pago. : como TestRail

Lo consideramos principalmente desde la perspectiva de la ecología, el costo de implementación, la escalabilidad y los gastos.

Zephyr siempre ha tenido una gran reputación, pero en realidad no se ajusta del todo a los hábitos de uso de los chinos y es muy incómodo de usar. Los casos de uso utilizan directamente el problema de Jira, la función es relativamente simple y la gestión de casos de uso se centra principalmente en la relación entre planes y ciclos. Debido a que es un complemento de Jira, puede asociarse 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, la importación de datos admite tipos limitados. En términos de extensiones, si desea utilizar su API, debe instalar un complemento adicional. Su costo es moderado.

Xray es bastante satisfactorio y también utiliza issues de Jira para crear casos de prueba. Sin embargo, hay hasta 5 tipos de problemas nuevos, lo que lo hace extremadamente complicado. Las capacidades de correlación son las mismas que las de Zephyr, los tipos de soporte de importación de datos son limitados y la API en sí está disponible. Su costo es moderado.

synapseRT fue desarrollado por chinos y tiene el mejor efecto de traducción al chino y potentes funciones. Existe el concepto de conjunto de casos de uso, y los casos de uso también se amplían utilizando los problemas de Jira. La importación de datos es compatible con otras plataformas como TestLink y Zephyr. Las capacidades de correlación son las mismas que las de Zephyr, pero los tipos de soporte de 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 independiente para gestionar casos de prueba, lejos de la compleja página de problemas de Jira, lo que facilita el inicio. La función de importación de datos es poderosa y cubre muchos tipos y algunas plataformas conocidas. Las capacidades de correlación son consistentes con los complementos anteriores y hay API disponibles. Pero el costo es relativamente alto.

TestLink es una plataforma de gestión de pruebas independiente con funciones integrales, de código abierto y gratuita. Se puede conectar a plataformas conocidas como Jira, pero como no es un sistema Atlassian, la experiencia ecológica no es alta. El inconveniente es que la interfaz es fea, lo que puede afectar fácilmente el estado de ánimo del ingeniero. El autor utilizó una vez su propia API para embellecer la interfaz de usuario.

TestRail es una poderosa plataforma comercial. El autor no ha tenido mucho contacto con ella y no hará ningún comentario.

Teniendo todo en cuenta, aunque TestLink, como la principal plataforma gratuita de gestión de casos de uso de código abierto, es muy científica en la gestión de casos de uso y siempre vale la pena aprender, la empresa del autor ya está utilizando Jira y está implementando DevOps, plus El autor suele contar con el apoyo del subdirector del Atlassian China Community Research Institute, y TM4J se convirtió en la opción final:

El productor es bastante fuerte, además de TM4J, Zephyr es en realidad su producto. y Swagger es también el reconocimiento actual. Un producto de muy alta calidad.

Se puede ver en la introducción del sitio web oficial que TM4J es relativamente moderno:

Primero, veamos cómo escribir casos de prueba usando TM4J.

En términos de estructura jerárquica, creamos directorios y subdirectorios basados ​​en HLTD para facilitar la comprensión y lectura de todos. El punto de prueba final se instancia como un caso de prueba, que 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. Aquí puede definir el nombre, el propósito y los requisitos previos del caso de prueba. los componentes de estado, prioridad y pertenencia, y puede agregar algunos para una gestión más sencilla.

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 vale la pena mencionar que en la pestaña Trazabilidad, puede asociar problemas de Jira y páginas de Confluence.

Por lo general, necesitamos establecer un alcance para cada entrega de lanzamiento de producto, por lo que la gestión del plan es esencial.

La gestión del plan recomienda formular el directorio de nivel superior de acuerdo con la versión de lanzamiento y luego crear directorios secundarios para los tipos de prueba, como regresión, nuevas funciones, de un extremo a otro, interfaces, rendimiento, etc.

La creación del plan de prueba en sí no es complicada, excepto definir el nombre del plan, el propósito, el estado, la persona responsable y agregar algunas etiquetas.

También necesitas asociar los requisitos o la página de Confluence. Es posible que el ciclo de prueba no exista cuando se crea el plan de prueba por primera vez, pero se asociará bidireccionalmente cuando el ciclo de prueba se cree más adelante.

El ciclo de prueba es el vínculo clave entre el anterior y el siguiente. El vínculo ascendente está relacionado con el plan de prueba y el vínculo descendente está relacionado 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 no es necesariamente exactamente el mismo.

Después de crear el nuevo ciclo de prueba, nombre, descripción y detalles.

Ingrese a la pestaña Casos de prueba y haga clic en + Agregar casos de prueba para agregar casos de prueba ya escritos.

Este paso hace que el caso de prueba tenga atributos de proyecto.

Finalmente, haga clic en la lupa detrás de Planes de prueba en la pestaña Trazabilidad del ciclo de prueba.

Relacionar planes de pruebas ya elaborados mediante búsqueda.

Después de crear un ciclo de prueba, puede ingresar al ciclo y buscar los casos de prueba asignados a su nombre. Esta es la interfaz que todos los ejecutores de prueba deben usar. También puede usar Group by según diferentes. Clasificar, por ejemplo, según diferentes categorías desarrolladas 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 como aprobado, fallido y bloqueado. También puede hacer clic en el botón de engranaje para crear y encontrar rápidamente problemas de Jira para asociar. Además del problema de asociación de pasos, también puede marcar el problema para este caso de uso y hacer clic en + ▼ detrás de Problemas para realizar operaciones. Este es el beneficio de una plataforma unificada.

Aunque podemos ver el progreso de la prueba al ver la lista de ciclos de prueba, se pueden reflejar más datos a través del informe de prueba.

La función Informes de TM4J nos proporciona una gran cantidad de plantillas para facilitar la tarea a algunos responsables de calidad de pruebas sin experiencia.

Finalmente, al autor le gustaría decir que las pruebas no pueden considerarse como un negocio independiente y deberían ser más colaborativas con otras funciones. Especialmente en la era ágil actual, la ejecución de casos de prueba puede requerir la atención de. Ingenieros de desarrollo. La situación puede requerir que el gerente de producto intervenga en cualquier momento. Por lo tanto, se recomienda encarecidamente que nuestros trabajadores de pruebas de software intenten elegir algunas plataformas de colaboración multifuncionales.