Ingeniera de Software

Pruebas (de Unidad)

Profesores
Joan Manuel Briones Prez
Jaime Sebastin Luna Orrego

Apoyo colaborativo de:

Pedro Campos Soto
Mara Antonieta Soto Chico
Alejandra Segura Navarrete
 Gestin de Calidad de Software
(SQA)
Asegurar que los niveles requeridos de calidad se logren en
un producto de software.

Definicin de estndares y procedimientos de calidad, as

como asegurar que stos se sigan.

Apunta a desarrollar una cultura de calidad donde la

responsabilidad es de todos.

2
 Qu es calidad?
Significa que un producto debera cumplir con sus
especificaciones.

Esto complica a los ingenieros de software, principalmente

en que:
Existe una tensin entre requerimientos de calidad del cliente
(eficiencia, dependencia, etc.) y requerimientos de calidad de
desarrollo (mantenibilidad, reusabilidad, etc.)
Algunos requerimientos de calidad son difciles de especificar en
una manera no ambigua. (Ejemplo de sus trabajos: Navegadores
ms populares, responder de la forma ms rpida posible,
garantizar seguridad en la informacin)
Las especificaciones de software estn usualmente incompletas y a
menudo son inconsistentes

3
 Qu se entiende por Falla,
Defecto o Error?

DEFECTO FALLAS

Causa mecnica o algoritmica de un error Es cualquier desviacin del comportamiento

observado respecto al especificado.

ERROR
Significa que el sistema est en un estado el cual el procesamiento adicional del sistema conducir a
una falla, lo cual causa que el comportamiento se desve del pretendido

4
Gestin de Calidad de Software
(Apunta a 3 tpicos)
Mejora de la calidad Mejora
continua
Calidad total

Garanta de calidad
Prevenir defectos

Control de
calidad
Detectar defectos

Tiempo
 1. Control de Calidad
Pruebas del software

En esta etapa, se busca demostrar que el software realiza lo

que se espera que realice, y descubrir fallas antes de que se
comience a utilizar (puesta en produccin).
En general, al realizar las pruebas, se ejecuta el software con
datos artificiales.
Las pruebas de software son parte del proceso ms general
de control de calidad, tambin llamado verificacin y
validacin, tambin conocido como V&V.

6
 1. Control de Calidad
Pruebas del software

De acuerdo a IEEE V&V se definen como:

Verification
The process of evaluating a system or component to determine
whether the products of a given development phase satisfy the
conditions imposed at the start of the phase

Validation
The process of evaluating a system or component during or at the
end of the development process to determine whether it satisfies
specified requirements

7
 1. Control de Calidad
Tipos de Fallas

En algoritmos, de capacidad de procesamiento

de sintaxis, o desempeo,
de recuperacin,
de precisin y clculo,
de estndares y procedimientos,
de documentacin, relativos al hardware o software
de estrs o sobrecarga, del sistema.
de capacidad o de borde,
de sincronizacin o
coordinacin.

8
 2.Pruebas del software
Objetivos de las pruebas

Pruebas de Validacin
El sistema funciona correctamente ante casos de prueba que reflejan el uso
esperado del sistema
Una prueba de validacin tiene xito si el sistema opera como se estipul.

Pruebas de defectos:
Una prueba de defectos tiene xito si descubre un defecto.
Una prueba defectos fracasa si hay defectos pero no los descubre
Si no aparecen fallos, no podemos asegurar que no existan
defectos!

9
 Proceso de prueba

Test Cases: Es un conjunto de datos de entrada y resultados esperados que ejercitan a

un componente con el proposito de causar fallas y detectar defectos.

10
 Etapas de Pruebas
Unit
testing
Module
testing
Sub-system
testing
System
testing
Acceptance
testing

Component Integration testing User

testing testing

11
 Modelo V
sabemos realmente lo que quiere decir?

Son muchas las presentaciones o artculos sobre calidad de software que

siempre incluyen la figura del Modelo-V.

El modelo-V deriva directamente del modelo en cascada (Waterfall model),

y se usa como base de procesos dentro del ciclo de vida de software. El
modelo considera el testing como una actividad paralela al SDLC (Sofware
development Life Cycle) y no como una actividad aislada que se realiza al
final del desarrollo. Fue desarrollado en Alemania por el Ministerio de
Defensa.

12
 Modelo V
sabemos realmente lo que quiere decir?

13
14
 Datos de prueba y casos de
prueba
Recordar que los datos de prueba son entradas que
permiten probar el sistema.

Los casos de prueba son entradas para probar el

sistema y la prediccin de las salidas que deberan
ocurrir si el funcionamiento del sistema est de
acuerdo a las especificaciones.

15
 Estrategias de prueba unitaria
Pruebas basadas en particiones (caja negra)
Se identifican grupos de entradas que tienen caractersticas
en comn y deben ser procesados de forma similar.
Se analizan las entradas y las salidas del sistema sin analizar
qu ocurre dentro de l.
Pruebas basadas en trayectoria (caja blanca)
Se analiza el cdigo a ser probado, para determinar entradas
que permitan ejecutar las diferentes trayectorias.
Pruebas basadas en guas
Se usan guas que reflejan la experiencia con los tipos de
errores frecuentes para generar los casos de prueba

16
Pruebas de caja negra
Inputs causing
anomalous
Input test data I behaviour
e

System

Outputs which reveal

the presence of
Output test results Oe defects

17
 Particiones de equivalencia
(Caja Negra)

Los datos de entrada y los resultados de salida a menudo

caen en diferentes clases. Por ejemplo: nmeros positivos,
nmeros negativos, cadenas con caracteres en blanco, etc.

El sistema tiende a comportarse en forma equivalente para

cada una de estas clases. Por este motivo resulta til
identificar dichas clases al momento de probar.

Estas clases se denominan particiones de equivalencia.

18
 Particiones de equivalencia
Las entradas al sistema se dividen en sets de equivalencia.

Ejemplo: Si una entrada es un entero 5-digit entre 10.000

and 99.999, las particiones de equivalencia son < 10.000,
10.000 - 99.999 y > 99.999.

Por lo tanto se deben escoger los conjuntos de prueba entre

estos lmites:
00000, 09999, 10.000, 99.999, 100.001

Es muy importante probar los lmites!

19
 Particiones de equivalencia
3 11
4 7 10

Less than 4 Between 4 and 10 More than 10

Number de
Nmero of input values
valores de entrada
9999 100000
10000 50000 99999

Less than 10000 Between 10000 and 99999 More than 99999

Valores de entrada
Input values

20
 Particiones de equivalencia

Buscar particiones a partir de especificacin

Buscar particiones a partir de la funcionalidad
especfica de la rutina

21
 Pruebas basadas en trayectorias
(Caja Blanca)

Caja Blanca
Tambin llamadas pruebas estructurales o de caja
transparente.

Se definen a partir del conocimiento que se tiene de la

estructura interna del sistema.

El objetivo es que se ejecuten todas las instrucciones del

programa

22
 Pruebas de Caja Blanca

Test data

Tests Derives

Component Test
code outputs

23
Prueba de trayectorias (ruteo)
El objetivo de las pruebas de trayectoria es asegurarse que
las diferentes instrucciones se ejecutan correctamente.

El punto de partida es un flujo grfico del programa que

muestre los nodos representativos de las decisiones que va
tomando el programa. Los arcos representan el flujo de
control.

Las instrucciones con condiciones se escriben junto a los

nodos en el grfico.

24
 Notacin
Secuencia
SI

Condicin
IF NO
SI
Ciclo
While NO
SI
NO
Ciclo
Hasta 25
 Diagrama de flujo
1
para una rutina de bsqueda binaria

while bottom < = top

bottom > top
2

3 if (elemArray [mid] == key

8 4
(if (elemArray [mid]< key

5 6
9

26
 Las trayectorias independientes
(sin vuelta atrs) son:
1, 2, 3, 8, 9
1, 2, 3, 4, 6, 7, 2
1, 2, 3, 4, 5, 7, 2
1, 2, 3, 4, 6, 7, 2, 8, 9
Los casos de prueba deberan asegurarse que se
ejecutan todas las trayectorias.
Un analizador dinmico podra utilizarse para saber
las trayectorias efectivamente ejecutadas.

27
 Complejidad ciclomtica
Mtrica que proporciona una medicin cuantitativa
de la complejidad lgica.
Es el nmero de caminos independientes.
En trminos del grafo de flujo (G), la complejidad ciclomtica
(CC) se puede calcular de la siguiente forma:

CC(G) = Aristas Nodos + 2

Permite determinar las pruebas necesarias para

ejecutar cada sentencia al menos una vez.

28
 Pruebas de Caja Blanca
Ventajas
Mayor probabilidad de deteccin de fallas.
Ayuda a encontrar la localizacin de defectos.

Desventajas
Requiere gran esfuerzo (HH).
Se necesita una comprensin profunda de la implementacin
realizada
Se pueden perder de vista aspectos de la funcionalidad.
A veces es difcil forzar ciertas condiciones de la
estructura de los programas.

29
 Dicotoma caja blanca caja
negra
Hoy en da se considera poco relevante la distincin
entre pruebas de caja negra o blanca.
Lo importante es considerar diferentes fuentes de
datos para generar buenos casos de prueba.

30
Guas de prueba (para secuencias)
Probar con secuencias de un solo valor
Usar secuencias de diferentes tamaos en las diferentes
pruebas
Generar pruebas de forma que se accese los elementos del
principio, del medio y del final.
Probar con secuencias de largo 0

31
 Guas de prueba en general
Escoger entradas que fuercen al sistema a generar todos los
mensajes de error
Forzar la generacin de salidas invlidas
Forzar resultados de clculo muy pequeos o muy grandes

32
 Pruebas automatizadas
Las pruebas de unidad pueden ser automatizadas
As, las pruebas pueden ser ejecutadas y sus resultados
revisados sin intervencin manual.
Comnmente se utiliza un framework de pruebas
automatizadas para escribir y ejecutar los casos de
prueba (ej. JUnit)
Estos frameworks proveen clases de pruebas
genricas, que se deben extender para crear casos
de prueba especficos.

33
 Elementos de Pruebas
automatizadas
Configuracin (setup) en que se inicializa el sistema
con los casos de prueba
Llamada (call) en que se invoca el mtodo o funcin
a probar
Afirmacin (assertion), en que se compara el
resultado de la llamada con el resultado esperado.
Si la assertion es evaluada como verdadera, la
prueba ha sido exitosa (se pasa la prueba).

34
 Conclusiones
Existen diversas estrategias para realizar las pruebas del
sistema. Es importante utilizar una mezcla adecuada de
ellas, que nos permita detectar la mayor cantidad de
errores posible.
El uso de pruebas automatizadas ayudan a evitar que las
modificaciones daen cdigo que funciona.
Es ms importante probar las partes del sistema que se
utilizan ms frecuentemente que las partes que raramente
se utilizan.

35