Tiempo de lectura: 10 minutos

Cómo escribir casos de prueba puede no parecer una parte tan importante del desarrollo. Pero para que un probador de software realice mejor su trabajo, necesita un conjunto de pasos a seguir y una definición clara de lo que se está probando.

Todos, desde la NASA y GE hasta las corporaciones de nivel empresarial, pueden beneficiarse de equipos que operan al máximo. Escribir excelentes casos de prueba es solo una forma más de mejorar la eficiencia y la eficacia del equipo, y Parasoft se trata de capacitar a los equipos para que hagan precisamente eso.

En este blog, cubrimos los siguientes temas relacionados con cómo escribir un caso de prueba:

1. ¿Qué es un caso de prueba?
2. Guión de prueba vs. caso de prueba
3. Diferentes tipos de casos de prueba
4. Cómo escribir casos de prueba de software
5. Formato de caso de prueba estándar
6. Mejores prácticas de escritura de casos de prueba
7. Conjunto de pruebas vs. plan de prueba
8. Herramientas de escritura de casos de prueba

¿Qué es un Caso de prueba en Software?

Un caso de prueba es exactamente lo que parece: un escenario de prueba que mide la funcionalidad de un conjunto de acciones o condiciones para verificar el resultado esperado. Se aplican a cualquier aplicación de software, pueden usar pruebas manuales o automatizadas y pueden hacer uso de herramientas de administración de casos de prueba.

Una cosa clave a recordar cuando se trata de escribir casos de prueba es que están destinados a probar una variable o tarea básica, como si se aplica o no un código de descuento al producto correcto en una página web de comercio electrónico. Esto permite a un probador de software más flexibilidad en cómo probar el código y las características.

Guión de prueba vs. Caso de prueba

También debe aclararse la diferencia entre los casos de prueba vs.guiones de prueba. Un script de prueba es un programa corto destinado a probar cierta funcionalidad. Un caso de prueba es un documento con pasos que deben completarse según lo planeado con anticipación.

Considere los casos de prueba como un viaje meticulosamente planeado y los guiones de prueba para ser más como un viaje rápido a la tienda de comestibles.

Diferentes tipos de casos de prueba

Los casos de prueba pueden medir muchos aspectos diferentes del código. Los pasos involucrados también pueden tener la intención de inducir un resultado fallido en lugar de un resultado esperado positivo, como cuando un usuario ingresa la contraseña incorrecta en una pantalla de inicio de sesión.

Algunos ejemplos de casos de prueba comunes serían los siguientes:

Los casos de prueba se pueden aplicar a cualquier número de características que se encuentren en cualquier software dado. Algunos de los ejemplos más populares incluyen:

• Pruebas de API: Véalo en acción. Pruebas de interfaz de usuario
• : Véalo en acción.
• Pruebas unitarias: Véalo en acción.
• Cargar & pruebas de rendimiento: Véalo en acción.
• Pruebas de seguridad
• Consultas SQL
• Pruebas de aplicaciones de bajo código

Un Ejemplo de caso de prueba popular

Los casos de prueba son útiles en una variedad de escenarios de software. Todo, desde la banca hasta el software personal, requiere una aplicación de caso de prueba. Por ejemplo, si el objetivo es tener datos confidenciales cifrados, el software debe tener características que funcionen según lo previsto.

Pero las pruebas funcionales son solo un aspecto de la escritura de un caso de prueba. Las pruebas de software deben desafiar todos los aspectos del código, desde el rendimiento hasta la compatibilidad y la seguridad. Es por eso que el software de cifrado personal debe probarse tan a fondo, especialmente cuando se trata de cosas como las API web.

Cómo escribir casos de prueba de software

Escribir casos de prueba varía según lo que esté midiendo o probando el caso de prueba. También es una situación en la que compartir activos de prueba entre equipos de desarrollo y de prueba puede acelerar las pruebas de software. Pero todo comienza con saber cómo escribir un caso de prueba de manera efectiva y eficiente.

Los casos de prueba tienen algunas partes integrales que siempre deben estar presentes en los campos. Sin embargo, cada caso de prueba se puede dividir en 8 pasos básicos.

Paso 1: ID de caso de prueba

Los casos de prueba deben llevar ID únicos para representarlos. En la mayoría de los casos, seguir una convención para este ID de nombre ayuda a la organización, la claridad y la comprensión.

Paso 2: Descripción de la prueba

Esta descripción debe detallar qué unidad, característica o función se está probando o qué se está verificando.

Paso 3: Supuestos y Precondiciones

Esto implica cualquier condición que deba cumplirse antes de la ejecución del caso de prueba. Un ejemplo sería requerir una cuenta de Outlook válida para iniciar sesión.

Paso 4: Datos de prueba

Esto se refiere a las variables y sus valores en el caso de prueba. En el ejemplo de un inicio de sesión de correo electrónico, sería el nombre de usuario y la contraseña de la cuenta.

Paso 5: Pasos a ejecutar

Estos deben ser pasos fácilmente repetibles como se ejecutan desde la perspectiva del usuario final. Por ejemplo, un caso de prueba para iniciar sesión en un servidor de correo electrónico podría incluir estos pasos:

1. Abra la página web del servidor de correo electrónico.
2. Introduzca el nombre de usuario.
3. Introduzca la contraseña.
4. Haga clic en el botón» Entrar «o» Iniciar sesión».

Paso 6: Resultado esperado

Esto indica el resultado esperado después de la ejecución del paso del caso de prueba. Al ingresar la información de inicio de sesión correcta, el resultado esperado sería un inicio de sesión exitoso.

Paso 7: Resultado real y Post-Condiciones

En comparación con el resultado esperado, podemos determinar el estado del caso de prueba. En el caso del inicio de sesión por correo electrónico, el usuario podría haber iniciado sesión correctamente o no. La condición posterior es lo que sucede como resultado de la ejecución del paso, como ser redirigido a la bandeja de entrada de correo electrónico.

Paso 8: Aprobado / No aprobado

La determinación del estado aprobado/no aprobado depende de cómo se comparen el resultado esperado y el resultado real entre sí.

El mismo resultado = Aprobado
Resultados diferentes = No aprobado

Formato de Caso de Prueba Unitaria estándar

Cada parte de una prueba unitaria bien escrita definirá varios aspectos fundamentales, incluidos:

1. Funciones realizadas por la prueba
2. Datos utilizados en la prueba
3. Resultado esperado de la ejecución de la prueba
4. Garantizar que la prueba se ejecutó de forma aislada de otras partes de la base de código

Es importante saber que el formato estándar de las pruebas bien escritas se compone de las siguientes partes:

• Nombre significativo del método de prueba
• Datos controlados o simulaciones que se utilizarán para probar
• Método o unidad bajo prueba (la parte del código que estamos probando)
• Aplicar una aserción
• Ejecutar la prueba de unidad de forma aislada

¿Hay una Plantilla de caso de prueba?

Como se mencionó, hay un formato de caso de prueba estándar. Sin embargo, la plantilla de caso de prueba probablemente variaría de una empresa a otra e incluso de un equipo a otro. En su lugar, una plantilla de caso de prueba es el documento con una lista de escenarios de prueba y casos de prueba posteriores.

Ejemplo de caso de prueba de calidad

Aunque los casos de prueba variarán según el tipo de prueba y el campo general de prueba, la construcción de un caso de prueba de calidad se reduce a los pocos elementos confiables anteriores. Recuerde: el nombre del método de prueba debe incluir el método o la unidad que se está probando y cuál es el resultado esperado.

También debe tenerse en cuenta que cada unidad debe someterse a ensayo de forma aislada. En este caso, «aislamiento» significa mantener las pruebas enfocadas tanto como sea posible para ejecutar solo la parte de la aplicación para la que estamos probando.

Este ejemplo proviene de un caso de prueba relacionado con la banca:

Con este nombre de método, sabemos que se trata de una prueba unitaria que es:

• Probando el método ‘ isOverDrawn ()’.
• El equilibrio utilizado para los datos controlados fue de 500.
• El resultado esperado es verdadero.

Un nombre de método significativo permite a cualquier persona que revise los resultados comprender para qué se estaba probando la prueba unitaria. Además, señala los datos que se van a probar, el resultado esperado y lo que se probó.

Si la prueba falla, conocer el resultado esperado es fundamental para facilitar la solución de problemas y garantizar que no se introduzcan regresiones.

Datos del caso de prueba

Los datos utilizados deben ser suficientes para ejecutar la prueba. Para las pruebas unitarias, queremos que sea lo más sencillo posible probar la unidad más básica de nuestra aplicación. Los datos pueden ser tan simples como crear una cadena o variable de objeto para la que pueda controlar los datos. O se puede usar un marco de trabajo simulado para la prueba si una dependencia no está disponible o si necesita que esa dependencia esté en un estado específico.

Tener lo suficiente para probar esa parte si es suficiente. NO es necesario configurar cada parte de la aplicación para que se ejecute la prueba.

Todo esto afecta a cómo se comportará la prueba unitaria, ya que estos son los datos que se utilizan para la ejecución de la prueba unitaria. Como tal, esta parte de las pruebas unitarias consume más tiempo, ya que requiere cierta comprensión del código que está probando para saber qué datos usar para las pruebas.

Manténgalo simple usando solo las partes necesarias para el código que se está probando. Las burlas son muy útiles en esta fase, ya que le permiten controlar cómo se comportarán los métodos de esos objetos al interactuar con su prueba.

Por ejemplo, teniendo en cuenta los siguientes datos:

Evitamos la » clase de cliente real «mediante el uso de un simulacro de la» clase de cliente » para probar el aislamiento. No queremos introducir ni configurar otro objeto para esta prueba, ya que agrega otra capa de mantenibilidad para ese objeto, y no afecta el resultado del método bajo prueba.

La siguiente variable a crear es el «balance inicial», algo conocido debido al conocimiento del código. La siguiente línea muestra el objeto de Cuenta que se está creando junto con el simulado y el Saldo Inicial para preparar el método que estamos probando con los datos que acabamos de usar.

En este ejemplo, el objeto account se configura con el cliente simulado, ya que no nos importan los datos del objeto customer y pasamos un saldo inicial que podemos controlar para nuestra prueba.

La siguiente línea define la entrada ya que el método bajo prueba requiere un número para ser utilizado. Definimos el «equilibrio» que se utilizará en el método que estamos probando. Luego, el método se ejecuta con el resultado de que el método se almacena en nuestra variable para que lo usemos más tarde.

Aplicar una aserción

Una vez que la prueba se haya completado correctamente (ya que se ejecuta de principio a fin sin excepciones ni errores), es hora de aplicar una aserción a la prueba unitaria. Sin la afirmación, la prueba unitaria no tiene sentido, ya que no hay nada que esté haciendo cumplir para asegurarse de que funciona como se pretende.

La recopilación de la cobertura de las líneas que se ejecutaron indica lo que se ejecutó, pero no proporciona suficientes detalles para determinar lo siguiente:

• Si el código se comporta como se espera.
• Si el código cumple los objetivos de calidad.
• Si los datos devueltos son los datos esperados.

Una aserción puede ser tan básica como:

Siempre que la prueba unitaria contenga una aserción que verifique el método en el resultado de la prueba, esta es una prueba unitaria significativa.

Al aplicar el formato estándar de prueba unitaria, un equipo puede mantener, leer y/o actualizar pruebas fácilmente con más facilidad para ver fácilmente dónde se pueden aplicar más pruebas al resto de la aplicación.

¿Cuáles Son las Mejores Prácticas para Escribir Casos de Prueba de Calidad?

Cómo escribir pruebas efectivas y casos de prueba se pueden simplificar con el tiempo. Algunas de las mejores prácticas incluyen el uso de títulos sólidos, descripciones sólidas y mantener el lenguaje conciso y claro.

Pero también querrás incluir precondiciones, suposiciones y los resultados esperados. Toda esta información es relevante para el probador de software, especialmente para determinar si el caso de prueba debe ser un «aprobado» o un «fallo» en su lugar.

Una hoja de trucos para crear casos de prueba que funcionen bien es la siguiente:

• Mantenga las cosas simples y transparentes.
• Haga que los casos de prueba sean reutilizables.
• Mantenga los identificadores de casos de prueba únicos.
• La revisión por pares es importante.
• Los casos de prueba deben tener en cuenta el usuario final o los requisitos definidos.
• Especifique los resultados esperados y las hipótesis.

Simple, único, específico, abierto a comentarios y centrado en la reutilización: esa es la forma de un gran caso de prueba. Para una visión más visual de cómo escribir un caso de prueba de calidad, consulte el seminario web de Parasoft sobre el tema.

Conjunto de pruebas vs. Plan de pruebas

El otro aspecto de un caso de prueba involucra grupos de pruebas y planes de prueba. Estos difieren en aspectos clave y ambos son vitales para el desarrollo preciso de casos de prueba.

¿Qué es un Conjunto de Pruebas?

Un conjunto de pruebas entra en juego para casos de prueba en lo que se refiere al código fuente, la colección de dependencias o el conjunto de pruebas que se realizarán en el código. Los conjuntos de pruebas le permiten categorizar los casos de prueba de manera que se alineen con cualquier necesidad de análisis o planificación.

Esto significa que las funciones principales del software pueden tener su propio conjunto de pruebas, mientras que otro conjunto de pruebas es para un tipo de prueba específico, como humo o seguridad. Piense en las suites de prueba como una estantería para organizar sus casos de prueba.

¿Qué es un Plan de Prueba?

Por el contrario, un plan de prueba es más como el paraguas que se coloca sobre todos los conjuntos de pruebas. Si los casos de prueba son libros y las suites de prueba son estanterías, entonces los planes de prueba son la sala que contiene la estantería.

En general, los planes de prueba se configuran en términos de pruebas manuales, pruebas automatizadas y un formato general de cómo realizar las pruebas. Probarán el software desde la base hasta el uso de conjuntos de pruebas y casos de prueba antes de implementar cambios o agregar nuevas características.

Las mejores herramientas de escritura de casos de prueba

Parasoft generalmente desarrolla sus herramientas y suites con la teoría de «George Jetson» en mente. Es decir, que queremos que nuestros clientes puedan «presionar un botón» y que todo se encargue. Si bien esto no es totalmente realista, las herramientas que tienen este enfoque en la automatización son las mejores para usar cuando se trata de escribir casos de prueba.

No solo pueden ayudar con la automatización, sino que también pueden ayudar desde el principio del desarrollo. Después de todo, es demasiado fácil quedarse atascado por pequeños detalles o características. Uno podría olvidar que el software solo tiene que funcionar primero. Ahí es donde entra en juego una herramienta de prueba de unidades Java como Parasoft Jtest.

Esta herramienta permite a principiantes y expertos mejorar sus habilidades de prueba unitaria más rápidamente, así como la experiencia de prueba unitaria. Después de establecer una base, ejecuta las pruebas unitarias y luego guía al usuario para asegurarse de que las pruebas sean significativas. Cuando puedes entender el tipo de cosas que debes buscar en una prueba, escribir un caso de prueba se vuelve menos intimidante.