Este documento trata sobre la gestión de pruebas de software. Explica el diseño de casos de prueba, incluyendo la definición de escenarios, identificación de condiciones de entrada, definición de clases de equivalencia y generación de casos de prueba. También describe los roles involucrados en las pruebas de software como el administrador de pruebas, analista de pruebas, diseñador de pruebas y ejecutor de pruebas, así como los artefactos clave como el plan de pruebas.

1. Gestión de Pruebas de
Software
Maestría de Ingeniería de Software
Msc. Antonio Quiña Mera.
Universidad Técnica del Norte - 2016
Diseño de Pruebas

2. Diseño de Pruebas

3. Diseño de Casos de prueba
• Un caso de prueba es un conjunto de entradas, condiciones de ejecución y
resultados esperados, desarrollado para conseguir un objetivo particular o
condición de prueba. Ejemplo: verificar el cumplimiento de un requisito
específico.
• En la ingeniería de software, mediante el caso de prueba o test case el
analista determinará, si una aplicación o una característica de esta es
parcial o completamente satisfactoria.
• Para llevar a cabo un caso de prueba, es necesario definir los siguientes
pasos:
• Definir escenarios.
• Identificar condiciones de entrada
• Definir clases de equivalencia
• Realizar casos de prueba

4. Caso de prueba - Definir escenarios
• Consiste en identificar todos los escenarios (caminos) a probar de un
caso de uso: flujo básico, sub flujos y flujos alternativos.
• Para definir el mínimo número de escenarios (caminos
independientes) para un caso de uso se puede aplicar la técnica de la
complejidad ciclomática.
• El cálculo de la complejidad ciclomática (CC) consiste en obtener un
valor a partir del grafo del caso de uso; este valor es conocido como
V(G).
• Existen 3 métodos de cálculo:

5. Caso de prueba - Definir escenarios
a. Según aristas y nodos
V (G) = a - n + 2, siendo a el número de arcos o aristas del
grafo y n el número de nodos.
b. Según áreas cerradas
V (G) = r + 1, siendo r el número de regiones cerradas del grafo.
c. Según nodos predicados
V(G) = c + 1, siendo c el número de nodos predicados
(condicionados).
La experiencia en este campo asegura que:
• V(G) marca el límite mínimo de casos de prueba para un caso de uso
• Cuando V(G) > 10 la probabilidad de defectos crece mucho.

6. Caso de prueba - Definir escenarios
• Para el siguiente diagrama de grafo, calcular el mínimo número de
escenarios:

7. Identificar condiciones de entrada
Las condiciones de entrada son parte del dominio de valores de
entrada. Se pueden identificar condiciones de entrada con estados
válidos (V) y no válidas (NV); asimismo se consideran condiciones de
entrada con el estado que no se aplica (N/A) para un determinado
escenario.
Existen los siguientes tipos de condiciones de entrada:
• Miembro de un conjunto
• Lógico
• Valor
• Rango

8. Identificar condiciones de entrada
Ejemplo: Considérese una aplicación bancaria, donde el usuario puede
conectarse al banco por Internet y realizar una serie de operaciones
bancarias. Una vez accedido al banco con las siguientes medidas de seguridad
(clave de acceso), la información de entrada del procedimiento que gestiona
las operaciones concretas a realizar por el usuario requiere las siguientes
entradas:
• Código de banco: En blanco o número de tres dígitos el primer debe ser mayor que 1.
• Código de sucursal: Número de cuatro dígitos, el primero de ellos mayor a 0.
• Número de cuenta: Número de cinco dígitos.
• Clave personal: Valor alfanumérico de cinco posiciones.
• Orden: Este valor se seleccionará de una lista desplegable, según la orden que se
desee realizar. Puede estar en “Seleccione Orden” o una de las dos cadenas siguientes:
“Talonario” o “Movimientos”
• En el caso “Talonario” el usuario recibirá un talonario de cheques, mientras que en
“Movimientos” recibirá los movimientos del mes en curso. Si no se especifica este
dato, el usuario recibirá los dos documentos.

9. Identificar condiciones de entrada
• A continuación, se muestra una tabla con estados de las condiciones
de entrada por cada resultado esperado.

10. Definir clases de equivalencia
Pueden usarse varias técnicas para identificar los valores de los datos de
entrada, la técnica de particiones o clases de equivalencias es una de
ellas.
Las clases de equivalencia se identifican examinando cada condición de
entrada (normalmente una frase en la especificación) y dividiéndola en
dos o más grupos.
Se definen dos tipos de clases de equivalencia:
• Clases Válidas: Entradas válidas al programa.
• Clases no Válidas: Valores de entrada erróneos.

11. Definir clases de equivalencia
• A continuación, se muestra las clases de equivalencia para el caso de
gestión bancaria anterior.

12. Casos de prueba
En esta última etapa, se generan los casos de pruebas. Para ello, se considera como
referencia la tabla de condiciones de entrada, indicando en cada caso de prueba las
clases de equivalencia creadas.
Por ejemplo, para el caso bancario se tendría lo siguiente:

13. Taller – Diseño de pruebas
Partiendo de los grupos establecidos.
Realizar:
• Definir un caso de uso de un sistema (CC mínimo de 5)
• Definir escenarios
• Identificar condiciones de entrada
• Definir clases de equivalencia
• Realizar casos de prueba

14. Roles y responsabilidades
En RUP se definen los siguientes roles.
• Administrador de pruebas
• Analista de pruebas
• Diseñador de pruebas
• Ejecutor de pruebas

15. Responsabilidades – Administrador de pruebas
Es el responsable del éxito total de la prueba, involucra calidad y aprobación de la
prueba, recurso de planeación, dirección, y solución a de los problemas que impiden
el éxito de la prueba.
Artefactos:
• Plan de Pruebas
• Resumen de Resultado de Pruebas
• Lista de Problemas
• Cambios de Requerimientos

16. Responsabilidades – Analista de pruebas
Es el responsable de identificar y definir las pruebas requeridas, mientras supervisa
el progreso de la comprobación detallada y resultado por cada ciclo de realización de
las pruebas.
Artefactos:
• Casos de Pruebas
• Modelo de Análisis de Carga de Trabajo
• Datos de Prueba
• Resultados de Pruebas

17. Responsabilidades – Diseñador de pruebas
Es el responsable de definir la estrategia de pruebas y de asegurar su puesta en
práctica acertadamente. El rol implica identificar técnicas, herramientas y pautas
apropiadas para poner en ejecución las pruebas requeridas, y dotar de los recursos
necesarios para conducir los requisitos de la prueba.
Artefactos:
• Plan de Estrategia
• Arquitectura de Automatización
• Configuración del Entorno de Pruebas
• Suite de Pruebas

18. Responsabilidades – Ejecutor de pruebas
Es el responsable de todas las actividades de las pruebas. El rol implica verificar,
ejecutar pruebas, analizar y recoger las ejecuciones de errores.
Artefactos:
• Registro de Pruebas
• Script de Pruebas

19. Plan de prueba - Artefacto
El propósito del plan de pruebas es explicitar el alcance, enfoque, recursos
requeridos, calendario, responsables y manejo de riesgos de un proceso de pruebas.
Note que puede haber un plan global que explicite el énfasis a realizar sobre los
distintos tipos de pruebas (verificación e integración).
Un plan de pruebas incluye:
1. Identificador del plan.
Preferiblemente de alguna forma mnemónica que permita relacionarlo con su alcance.
Por ejemplo:
• TP-Global (plan global del proceso de pruebas)
• TP-Req-Seguridad1 (plan de verificación del requerimiento 1 de seguridad)
• TP-Contr-X (plan de verificación del contrato asociado al evento de sistema X).

20. Plan de prueba
2. Alcance.
Indica el tipo de prueba y las propiedades/elementos del software a ser probado.
3. Ítems de prueba
Indica la configuración a probar y las condiciones mínimas que debe cumplir para comenzar a
aplicarle el plan.
4. Estrategia
Describe la técnica, patrón y/o herramientas a utilizarse en el diseño de los casos de prueba.
Por ejemplo, en el caso de pruebas unitarias de un procedimiento, esta sección podría indicar:
"Se aplicará la estrategia caja-negra de pruebas funcionales" o "Ejercicio de los caminos
ciclomáticos válidos".
En lo posible la estrategia debe precisar el número mínimo de casos de prueba a diseñar, por
ejemplo: 80% de funcionalidades del documento de reuisitos, 60% de los caminos ciclomáticos.
La estrategia también explicita el grado de automatización que se exigirá, tanto para la
generación de casos de prueba como para su ejecución.

21. Plan de prueba
5. Categorización de la configuración
Explicita las condiciones bajo las cuales, el plan debe ser:
• Suspendido
• Repetido
• Culminado
6. Tangibles
Explicita los documentos a entregarse al culminar el proceso previsto por el plan.
Ejemplo: Sub planes, especificación de pruebas, casos de prueba, resumen
gerencial del proceso y bitácora de pruebas.
7. Procedimientos especiales
Identifica el grafo de las tareas necesarias para preparar y ejecutar las pruebas, así como
cualquier habilidad especial que se requiere.

22. Plan de prueba
8. Recursos
Especifica las propiedades necesarias y deseables del ambiente de prueba, incluyendo las
características del hardware, el software de sistemas (Ejemplo: Sistema operativo), cualquier
otro software necesario para llevar a cabo las pruebas, así como la colocación específica del
software a probar (módulos se colocan en qué máquinas de una red local) y la configuración del
software de apoyo. La sección incluye un estimado de los recursos humanos necesarios para el
proceso.
9. Calendario
Esta sección describe los hitos del proceso de prueba y el grafo de dependencia en el tiempo de
las tareas a realizar.
10. Manejo de riesgos
Explicita los riesgos del plan, las acciones mitigantes y de contingencia.
11. Responsables
Especifica quién es el responsable de cada una de las tareas previstas en el plan.

23. Referencias.