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

Diseño de Pruebas

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 ocondición de prueba. Ejemplo: verificar el cumplimiento de un requisitoespecífico.

• En la ingeniería de software, mediante el caso de prueba o test case elanalista determinará, si una aplicación o una característica de esta esparcial o completamente satisfactoria.

• Para llevar a cabo un caso de prueba, es necesario definir los siguientespasos:• Definir escenarios.• Identificar condiciones de entrada• Definir clases de equivalencia• Realizar casos de prueba

Caso de prueba - Definir escenarios

• Consiste en identificar todos los escenarios (caminos) a probar de uncaso de uso: flujo básico, sub flujos y flujos alternativos.

• Para definir el mínimo número de escenarios (caminosindependientes) para un caso de uso se puede aplicar la técnica de lacomplejidad ciclomática.

• El cálculo de la complejidad ciclomática (CC) consiste en obtener unvalor a partir del grafo del caso de uso; este valor es conocido comoV(G).

• Existen 3 métodos de cálculo:

Caso de prueba - Definir escenariosa. Según aristas y nodos

V (G) = a - n + 2, siendo a el número de arcos o aristas delgrafo 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.

Caso de prueba - Definir escenarios

• Para el siguiente diagrama de grafo, calcular el mínimo número deescenarios:

Identificar condiciones de entrada

Las condiciones de entrada son parte del dominio de valores deentrada. Se pueden identificar condiciones de entrada con estadosválidos (V) y no válidas (NV); asimismo se consideran condiciones deentrada con el estado que no se aplica (N/A) para un determinadoescenario.

Existen los siguientes tipos de condiciones de entrada:

• Miembro de un conjunto

• Lógico

• Valor

• Rango

Identificar condiciones de entradaEjemplo: Considérese una aplicación bancaria, donde el usuario puedeconectarse al banco por Internet y realizar una serie de operacionesbancarias. Una vez accedido al banco con las siguientes medidas de seguridad(clave de acceso), la información de entrada del procedimiento que gestionalas operaciones concretas a realizar por el usuario requiere las siguientesentradas:

• 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 estedato, el usuario recibirá los dos documentos.

Identificar condiciones de entrada

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

Definir clases de equivalencia

Pueden usarse varias técnicas para identificar los valores de los datos deentrada, la técnica de particiones o clases de equivalencias es una deellas.

Las clases de equivalencia se identifican examinando cada condición deentrada (normalmente una frase en la especificación) y dividiéndola endos 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.

Definir clases de equivalencia

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

Casos de pruebaEn esta última etapa, se generan los casos de pruebas. Para ello, se considera comoreferencia la tabla de condiciones de entrada, indicando en cada caso de prueba lasclases de equivalencia creadas.

Por ejemplo, para el caso bancario se tendría lo siguiente:

Taller – Diseño de pruebasPartiendo 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

Roles y responsabilidadesEn RUP se definen los siguientes roles.

• Administrador de pruebas

• Analista de pruebas

• Diseñador de pruebas

• Ejecutor de pruebas

Responsabilidades – Administrador de pruebasEs el responsable del éxito total de la prueba, involucra calidad y aprobación de laprueba, recurso de planeación, dirección, y solución a de los problemas que impidenel éxito de la prueba.

Artefactos:

• Plan de Pruebas

• Resumen de Resultado de Pruebas

• Lista de Problemas

• Cambios de Requerimientos

Responsabilidades – Analista de pruebasEs el responsable de identificar y definir las pruebas requeridas, mientras supervisael progreso de la comprobación detallada y resultado por cada ciclo de realización delas pruebas.

Artefactos:

• Casos de Pruebas

• Modelo de Análisis de Carga de Trabajo

• Datos de Prueba

• Resultados de Pruebas

Responsabilidades – Diseñador de pruebasEs el responsable de definir la estrategia de pruebas y de asegurar su puesta enpráctica acertadamente. El rol implica identificar técnicas, herramientas y pautasapropiadas para poner en ejecución las pruebas requeridas, y dotar de los recursosnecesarios para conducir los requisitos de la prueba.

Artefactos:

• Plan de Estrategia

• Arquitectura de Automatización

• Configuración del Entorno de Pruebas

• Suite de Pruebas

Responsabilidades – Ejecutor de pruebasEs 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

Plan de prueba - ArtefactoEl propósito del plan de pruebas es explicitar el alcance, enfoque, recursosrequeridos, 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 losdistintos 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).

Plan de prueba2. Alcance.

Indica el tipo de prueba y las propiedades/elementos del software a ser probado.

3. Ítems de pruebaIndica la configuración a probar y las condiciones mínimas que debe cumplir para comenzar aaplicarle el plan.

4. EstrategiaDescribe 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 caminosciclomáticos válidos".

En lo posible la estrategia debe precisar el número mínimo de casos de prueba a diseñar, porejemplo: 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 lageneración de casos de prueba como para su ejecución.

Plan de prueba5. 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, resumengerencial del proceso y bitácora de pruebas.

7. Procedimientos especialesIdentifica el grafo de las tareas necesarias para preparar y ejecutar las pruebas, así comocualquier habilidad especial que se requiere.

Plan de prueba8. Recursos

Especifica las propiedades necesarias y deseables del ambiente de prueba, incluyendo lascaracterísticas del hardware, el software de sistemas (Ejemplo: Sistema operativo), cualquierotro software necesario para llevar a cabo las pruebas, así como la colocación específica delsoftware a probar (módulos se colocan en qué máquinas de una red local) y la configuración delsoftware de apoyo. La sección incluye un estimado de los recursos humanos necesarios para elproceso.

9. CalendarioEsta sección describe los hitos del proceso de prueba y el grafo de dependencia en el tiempo delas tareas a realizar.

10. Manejo de riesgosExplicita los riesgos del plan, las acciones mitigantes y de contingencia.

11. ResponsablesEspecifica quién es el responsable de cada una de las tareas previstas en el plan.

Referencias.