Pruebas de software: guión de prueba

Los proyectos de software activos cambian constantemente: las páginas se rediseñan, la información del usuario cambia y se agregan nuevas funciones. Para que funcione horas extras, los probadores deben hacer un esfuerzo constante para actualizar los documentos para que coincidan con el nuevo producto. Esto puede tomar mucho tiempo para probar. Otro desafío es que las pruebas escritas a menudo están diseñadas para probar lo mismo una y otra vez, usando los mismos pasos y los mismos datos cada vez que se prueba. Esto significa que si hay errores que se encuentran fuera de las guías proporcionadas en el script de prueba, no se encontrarán a menos que el evaluador se desvíe del script. Las pruebas escritas no siempre alientan a los evaluadores a usar la inteligencia y las habilidades técnicas necesarias para detectar errores ocultos. Aquí, discutiremos los siguientes puntos:

1. ¿Qué es un guión de prueba?
2. Escritura de un guión de prueba.
3. ¿Qué tan eficiente debe ser un script de prueba?
4. Información en el script de prueba.
5. Cuándo usar el script de prueba.

Vamos a discutir cada uno de estos temas en detalle.

¿Qué es un guión de prueba?

Los scripts de prueba son una descripción línea por línea que contiene información sobre las funciones del sistema que se deben realizar para verificar una aplicación o sistema bajo prueba. El documento de prueba debe describir cada paso a seguir con los resultados esperados. Este script automatizado permite que el explorador de software escanee cada nivel de una amplia gama de dispositivos de forma sistemática. El script de prueba debe contener las entradas que se incluirán, así como los resultados esperados. Los Scripts automatizados se pueden escribir usando cualquier lenguaje de programación ( C / C++ / Python / Perl / Batch Scripts ).

Escribir un guión de prueba

Los siguientes son algunos de los enfoques utilizados por el evaluador para escribir scripts de prueba:

1. Grabar/reproducir:De esta forma, el probador necesita escribir cualquier código en lugar de registrar las acciones del usuario. Sin embargo, el inspector deberá generar código para corregir las fallas o corregir el comportamiento predeterminado. Este método es más fácil que escribir un script de prueba completo desde cero porque ya tiene el código completo. Es ampliamente utilizado en lenguajes de edición simplificados como VBScript.
2. Palabra clave/texto basado en datos:En este enfoque, existe una clara distinción entre evaluadores y desarrolladores. En el texto basado en datos, el probador describe la prueba usando palabras clave sin el conocimiento del código fuente. Aquí, el trabajo del desarrollador es aplicar el código de verificación de palabras clave y actualizar este código cuando sea necesario. Entonces, en este método, el probador no tiene que preocuparse por el sistema. Sin embargo, dependerán en gran medida de las herramientas de desarrollo para cualquier funcionalidad nueva que desee verificar automáticamente.
3. Usando Programación:Si le gusta crear texto de prueba con este método, por lo general aún podrá grabar o reproducir de nuevo y producir un guión simple. Aunque, como revisor, eventualmente debe omitir la grabación/reproducción y aprender a escribir códigos simples. Es importante comprender que puede elegir su lenguaje de programación incluso si su aplicación está escrita en Java. Sin embargo, esto no significa que deba escribir sus scripts de prueba en Java, que pueden ser difíciles de leer. En cambio, puede escribir sus textos de prueba en lenguajes simples como Python, o incluso podemos escribir un archivo por lotes.

A continuación se muestra un archivo por lotes de muestra para ejecutar la navegación web:

set / a count = 0
: in
am start – a android.intent.action.VIEW – d http: // m.google.com
set / a count += 1
ECHO % COUNT%
timeout / t 15

@goto en

¿Qué tan eficiente debe ser un script de prueba?

Estos son algunos consejos importantes para crear un script de prueba:

1. El guión de prueba debe ser claro y debe cubrir el escenario. Si el probador siempre necesita pedirle al gerente del proyecto que proporcione detalles sobre la aplicación. Esto ciertamente desperdicia tiempo y recursos. Para evitar esto, siempre debe asegurarse de que cada paso en el script de prueba sea claro, conciso y consistente. Esto ayuda a mantener el proceso de prueba fluido.
2. Cree un script de prueba que debe contener solo una acción específica que realizarán los evaluadores. Esto garantiza que cada trabajo se evalúe correctamente y que los probadores no pierdan pasos en el proceso de prueba de software.
3. Para escribir un texto de prueba, es necesario colocarlo en la interfaz de usuario para determinar qué métodos probar. Prediga todos los diferentes métodos que los usuarios pueden usar mientras usan el sistema o la aplicación.

Aunque diferentes ingenieros de pruebas tendrán diferentes preferencias con respecto al estilo, la estructura y el contenido del texto, el cumplimiento de las pautas establecidas por los expertos en pruebas automatizadas se puede considerar como una guía. Los documentos de prueba deben tener las siguientes propiedades:

1. Definiciones claras: Dirigir tanto al usuario como a la persona que las mantiene.
2. Activo: Realiza una sola función y promueve la reutilización.
3. Bien diseñado: para facilitar la lectura, la comprensión y el mantenimiento.
4. Fácil de entender: debe ser fácilmente comprensible para facilitar el mantenimiento.
5. Claramente Escrito: Debe estar claramente escrito para facilitar su uso y almacenamiento.

Información en el script de prueba

Un buen guión siempre está respaldado con información realmente útil. El propósito del guión es lo que hace el texto o las acciones que hacemos. La información potencial incluye lo siguiente:

1. El contenido sin procesar del script, es decir, las entradas y, a veces, los resultados esperados.
2. Información del usuario, es decir, qué información debe transferirse al script, qué información debe restaurarse, en qué estado debe estar el software que se está probando cuando se llama al script y en qué condición permanecerá el software al final del texto.
3. Información de uso, es decir, información adicional que es útil para los cuidadores, como una explicación de por qué se usa de una manera particular o referencias a textos similares que pueden necesitar cambios.
4. Anotación, es decir, comentarios incrustados en todo el script para indicar qué sucede en cada paso lógico en términos de acciones realizadas con el software que se está probando.

Cuándo usar el script de prueba

1. El uso del script de prueba es la forma más confiable de garantizar que no haya omisiones y que los resultados sean tan precisos como los del programa de prueba deseado.
2. Si el script de prueba es fijo, deja un espacio de error muy pequeño durante el proceso de prueba.
3. En algunos casos, los inspectores pueden navegar libremente por el producto. Pueden perder algunas características.
4. El inspector periódico también asume que el trabajo tiene el efecto esperado si no lo hace.
5. Es especialmente útil cuando la funcionalidad del usuario es importante y clara.

Guión de prueba vs Caso de prueba

A continuación se muestran las diferencias entre el script de prueba y el caso de prueba:

Ejemplo: supongamos que la tarea es validar que un archivo sea JSON o no en una lista de archivos. Podemos escribir un script de prueba para verificar lo mismo.

# Python code to check whether
# a file is JSON or not
import os
import sys
import json
  
if len(sys.argv) > 1:
    if os.path.exists(sys.argv[1]):
        file = open(sys.argv[1], "r")
        json.load(file)
        file.close()
        print("Validate JSON!")
    else:
        print(sys.argv[1] + " not found")
else:
    print("Usage: testing_script.py <file>")

Salida 1- Caso de paso

C:\QC_Work\Projects\Geeks\GPL\Python>python testing_script.py sample1.json

Validar JSON!

Salida 2- No se ingresa el archivo a verificar

C:\QC_Work\Proyectos\Geeks\GPL\Python>python testing_script.py

Uso: testing_script.py <archivo>

Salida 3- Archivo no válido

C:\QC_Work\Projects\Geeks\GPL\Python>python testing_script.py sample3.json

muestra3.json no encontrado

Figura 1.1 Guión de prueba

Figura 1.2 Archivo JSON válido

Fig. 1.3 Ejecución y salida de la prueba