Cómo escribir casos de prueba para software: ejemplos y tutorial

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

Todo el mundo desde NASA y GE a corporaciones de nivel empresarial pueden beneficiarse de los equipos que operan de la mejor manera. Escribir casos de prueba excelentes 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. Script 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. Prácticas recomendadas para la redacción de casos de prueba
7. Conjunto de pruebas frente a plan de pruebas
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 en un conjunto de acciones o condiciones para verificar el resultado esperado. Se aplican a cualquier aplicación de software, pueden utilizar pruebas manuales o un prueba automatizaday puede hacer uso de herramientas de gestión de casos de prueba.

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

Script de prueba frente a caso de prueba

También debe aclararse la diferencia entre los casos de prueba y los scripts de prueba. Un script de prueba es un programa corto destinado a probar ciertas funciones. 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 que sean 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 de falla 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 cantidad de funciones que se encuentran en cualquier software dado. Algunos de los más populares incluyen:

• Ejemplo de prueba de API – Véalo en acción.
• ejemplo de prueba de interfaz de usuario – Véalo en acción.
• Ejemplo de prueba unitaria – Véalo en acción.
• Ejemplo de prueba de carga y rendimiento – Véalo en acción.
• Prueba de seguridad
• Consultas SQL
• Prueba 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 redacción de un caso de prueba. Las pruebas de software deben desafiar enérgicamente 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 API web.

Cómo escribir casos de prueba de software

La escritura de casos de prueba varía según lo que el caso de prueba esté midiendo o probando. Esta es también una situación en la que compartir activos de prueba entre los equipos de desarrollo y 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

Todos 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 nomenclatura ayuda con 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 condiciones previas

Esto implica que se cumplan las condiciones 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 relaciona con las variables y sus valores en el caso de prueba. En el ejemplo de un inicio de sesión por 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 ejecutados 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 su nombre de usuario.
3. Introducir 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 condiciones posteriores

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 iniciará 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 del correo electrónico.

Paso 8: Contraseña errónea

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

Mismo resultado = Aprobado
Diferentes resultados = Falla

Formato de caso de prueba de unidad estándar

Cada parte de un prueba unitaria bien escrita definirá varios aspectos centrales que incluyen:

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

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

• Nombre significativo del método de prueba
• Datos controlados o simulacros que se utilizarán para realizar pruebas.
• Método o unidad bajo prueba (la parte del código que estamos probando)
• Aplicar una afirmación
• Ejecución de la prueba unitaria de forma aislada

¿Existe una plantilla de caso de prueba?

Como se mencionó, existe un formato de caso de prueba estándar. Sin embargo, es probable que la plantilla de caso de prueba varíe de una empresa a otra e incluso de un equipo a otro. En cambio, 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 bajo prueba y cuál es el resultado esperado.

También debe tenerse en cuenta que cada unidad debe probarse 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 que estamos probando.

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

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

• Probando el método 'isOverDrawn ()'.
• El balance utilizado para los datos controlados fue 500.
• El resultado esperado es cierto.

Un nombre de método significativo permite que cualquiera que revise los resultados comprenda qué estaba probando la prueba unitaria. Además, indica 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 resolución de problemas y asegurando 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 simple posible probar la unidad más básica de nuestra aplicación. Los datos pueden ser tan simples como crear una cadena o una variable de objeto para la cual puede controlar los datos. O se puede usar un marco 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 que configure todas las partes de la aplicación para que se ejecute la prueba.

Todo esto afecta 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 es la que 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. Los simulacros 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, dados los siguientes datos:

Evitamos la "clase de cliente real" mediante el uso de una simulación 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 capacidad de mantenimiento para ese objeto y no afecta el resultado del método bajo prueba.

La siguiente variable a crear es el “saldo inicial”, algo conocido por el conocimiento del código. La siguiente línea muestra el objeto Cuenta que se está creando junto con el simulacro y el Saldo inicial para preparar el método que estamos probando con los datos que acabamos de usar.

Entonces, en este ejemplo, el objeto de la cuenta se configura con el cliente simulado, ya que no nos importan los datos del objeto del cliente 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 que se use un número. Definimos el "equilibrio" que se utilizará en el método que estamos probando. Luego, el método se ejecuta y el resultado del método se almacena en nuestra variable para que lo usemos más tarde.

Aplicar una afirmación

Una vez que la prueba se puede completar con éxito (ya que se ejecuta de principio a fin sin excepciones ni errores), es el momento de aplicar una afirmación a la prueba unitaria. Sin la afirmación, la prueba unitaria no tiene sentido, ya que no hay nada que imponga para asegurarse de que funciona según lo previsto.

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

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

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

Siempre que la prueba unitaria contenga una afirmación que verifique el resultado del método bajo 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 redactar casos de prueba de calidad?

La forma de escribir pruebas y casos de prueba eficaces se puede optimizar con el tiempo. Algunos y las mejores prácticas incluya el uso de títulos sólidos, descripciones sólidas y mantener el lenguaje conciso y claro.

Pero también querrá incluir condiciones previas, suposiciones y los resultados esperados. Toda esta información es relevante para el probador de software, especialmente cuando se determina si el caso de prueba debe ser un "aprobado" o un "error" 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 únicos los ID de los casos de prueba.
• La revisión por pares es importante.
• Los casos de prueba deben tener en cuenta al usuario final o los requisitos definidos.
• Especifique los resultados esperados y los supuestos.

Simple, único, específico, abierto a comentarios y enfocado en la reutilización: esa es la forma de un gran caso de prueba. Para obtener 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 frente a plan de pruebas

El otro aspecto de un caso de prueba implica conjuntos de pruebas y planes de prueba. Estos difieren en formas clave y ambos son vitales para el desarrollo preciso de casos de prueba.

¿Qué es una suite de pruebas?

Un conjunto de pruebas entra en juego para los 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 análisis o necesidad de 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 los conjuntos de pruebas como una estantería para organizar sus casos de prueba.

¿Qué es un plan de prueba?

Por el contrario, un plan de prueba se parece más al paraguas que cubre todas las suites de prueba. Si los casos de prueba son libros y los conjuntos de pruebas son estanterías, los planes de prueba son la sala que contiene la estantería.

Generalmente, 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 utilizando conjuntos de pruebas y casos de prueba antes de implementar cambios o agregar nuevas funciones.

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 tener todo bien cuidado. 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 muy fácil empantanarse con 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 unitaria de Java como Parasoft Jtest.

Esta herramienta permite tanto a los principiantes como a los 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 garantizar que las pruebas sean significativas. Cuando puede comprender el tipo de cosas que debe buscar en una prueba, la redacción de casos de prueba se vuelve menos intimidante.