Formato de caso de prueba¶
| Proyecto | SuiteSET3 |
| Descripción | Plantilla para proyectos basada en ReadySET y Métrica 3. |
| Desarrollo | project:suiteset3-dev versión suiteset3-dev:version#1 |
| Plazos vigentes | FECHA INICIO - FECHA FINALIZACIÓN |
| Fecha edición | 16/04/2024 |
IMPACTO: Esta página de referencia documenta el formato de los casos de prueba y da sugerencias para escribir los casos de prueba. Ud. puede copiar y pegar el caso de prueba de ejemplo en su archivo test-cases.html. Este archivo no debería ser editado para casos de prueba específicos. Este formato de caso de prueba es adecuado para casos de pruebas manuales de sistema. Los casos de prueba deberían de ser escritos con el detalle suficiente para que un nuevo miembro del equipo pueda empezar rápidamente a ejecutar pruebas y a encontrar defectos.
caso-de-prueba-único: Título de Casos de Prueba¶
|
Propósito |
Una o dos oraciones cortas sobre el aspecto del sistema que está siendo probado. Si esto toma mucho tiempo, rompa el caso de prueba o ponga más información en las descripciones de las carcterísticas. |
|
Prerequisitos |
Suposiciones que deben cumplirse antes de que correr el caso de prueba. Por ejemplo, "registrado", "inicio de sesión como invitado permitido", "el usuario testuser existe". |
|
Datos de Prueba |
Lista de variables y sus posibles valores usados en el caso de prueba. Ud. puede enlistar valores espcíficos o describir rangos de valores. El caso de prueba deberá ser ejecutado una vez por cada combinación de valores. Estos valores se escriben notación de asignación, uno por línea. Por ejemplo: loginID = {loginID válido, loginID inválido, email válido, email inválido , vacío} password = {válido, inválido, vacío} |
|
Pasos |
Pasos a ejecutar la prueba. Vea las reglas de formateo para pasos abajo.
|
|
Notas y Preguntas |
|
Escogiendo los Datos de Prueba¶
En la spruebas de sistema, los datos de prueba deberá cubrir los posibles valores de cada parámetro basado en los requerimientos. Debido a que probar cada uno de los valores es impráctico, se deberán de escoger unos cuantos valores de cada clase de equivalencia. Una clase de equivalencia es un conjunto de valores que deberán ser tratados igual.
Idealmente, los casos de prueba que evalúan condiciones de error son escritos de forma separada del los casos de prueba funcionales y deberán incluir pasos para verificar los mensajes de error y los registros. En la realidad, los casos de prueba para errores no se han escrito aún, es correcto que los evaluadores revisen las condiciones de error cuando estén realizando casos de prueba de funcionamiento normal. Debería estar claro que datos de prueba, si existen, se espera que disparen errores.
Ejemplos de clases de equivalencia:
Cadenas
- cadena vacía
- cadena consistnete de únicamente un espacio vacío
- cadena que empieza o termina en un espacio en blanco
- sintácticamente correcta: valores cortos y largos
- sintácticamente correcta: valores semánticamente válidos e inválidos
- valor sintácticamente incorrecto: caracteres o combinaciones ilegales
- asegúrese de probar caracteres especiales como #, ", ', &, y <
- asegúrese de probar caracteres "extranjeros" escritos desde teclados internacionales
Números
- cadena vacía, si es posible
- 0
- pequeños y largos en rangos positivos
- pequeños y largos en rangos negativos
- fuera del rango de positivos
- fuera del rango de negativos
- que comiencen con ceros
- sintácticamente inválidos (por ejemplo, que incluya letras)
Identificadores
- cadena vacía
- valor sintácticamente correcto
- sintácticamente correcto: refrencia a un ID existente, referencia inválida
- valor sintácticamente incorrecto
Botones de opción (radio)
- un objeto seleccionado
- nada seleccionado, si es posible
Botones de opción múltiple
- seleccionados
- sin seleccionar
- Menus de pestaña
- seleccione un elemento en cada turno
Listas con Scroll
- no seleccione ningún elemento, si es posible
- seleccione un elemento en cada turno
- seleccione combinaciones de elementos, si es posible
- seleccione todos los elementos, si es posible
Subir archivos
- en blanco
- archivo de 0 byte
- archivos grandes
- archivo con nombre corto
- archivo con nombre grande
- nombre de archivo sintácticamente incorrecto, si es posible (por ejemplo, "Nombre Con Espacios.tar.gz")
Formato de los pasos de las pruebas¶
Cada paso puede ser escrito de forma muy conscisa utilizando las siguientes frases:
login [como ROL-O-USUARIO]
Registrese en el sistema con un nombre de usuario dado o un usuario de un tipo dado. Usualmente se menciona de forma específica cuando el caso de prueba depende de los permisos de un rol en particular o un involucra un flujo de trabajo entre diferentes usuarios.
visitar LUGAR
Visitar una página o pantalla. Para aplicaciones web, LUGAR puede ser una hiperliga. El lugar deberá ser un punto de inicio bien definido (Por ejemplo, la pantalla de inicio de sesión), navegar a través de páginas específicas debería ser parte de la prueba.
introduzca NOMBRE-DEL-CAMPO [como VALOR] [en LUGAR-DE-LA-PANTALLA]
llene un campo determinado de una forma. VALOR puede ser un valor literal o el nombre de una variable definida en la sección "Datos de Prueba". El NOMBRE-DEL-CAMPO en si puede ser un nombre de variable cuando el campo de la UI para ese valor este libre de contexto. Por ejemplo, "introduzca password".
introduzca CAMPOS
Llene todos los campos de una forma cuando sus valores esten libres de contexto o cuando los valores específicos no son importantes en el caso de prueba.
haga click "LIGA-ETIQUETA" [en LUGAR-DE-LA-PANTALLA]
Siga una liga etiqeutada o presione un botón. El lugar de la pantalla puede ser un nombre predefinido del panel o una frase. Los nombres predefinidos del panel están basados en los nombres de las clases de la GUI, nombres de la plantilla maestra o títulos de cajas en la página.
haga click NOMBRE-DEL-BOTÓN [en LUGAR-DE-LA-PANTALLA]
Presione un botón dado. Este paso deberá siempre estar seguido por un paso "ver" para evaluar los resultados.
ver: PANTALLA-O-PÁGINA
La persona que ejecute las pruebas deberá ver la pantalla nombrada en la GUI o la página web. La correción general de la página deberá ser comprobable basado en la descripción de sus características.
verificar CONDICIÓN
La persona que ejecuta las pruebas deberá revisar que la condición ha sido satistefecha. A este tipo de pasos por lo general les sigue un paso "ver:" al final del caso de prueba.
verificar CONTENIDO [es VALOR]
La persona que ejecuta las pruebas deberá ver el contenido nombrado en la página actual, los valores correctos deberán estar libres de datos de prueba, o deberá tenerlos explícitamente. A este tipo de pasos por lo general les sigue un paso "ver:" al final del caso de prueba.
realice NOMBRE-DEL-CASO-DE-PRUEBA
Este paso es como una llamada a subrutina. La persona que realiza las pruebas deberá realizar todos los pasos del caso de prueba nombrado y después continuar en el siguiente paso del caso de prueba.
Cada caso de prueba debe incluir un paso de verificación al final para que la salida esperada sea muy clara. Un caso de prueba puede tener muchos pasos de verificación en la mitad o al final. Teniendo muchos pasos de verificación puede ser útil si desea un menor de número de pruebas largas en lugar de un número de grande de pruebas cortas.