Está en la página 1de 46

Unidad 4

4.1 DEFINICIONES
Estamos construyendo correctament e el producto?

4.1.1

Verificacin: El proceso de evaluacin de un sistema (o de uno de sus componentes para determinar si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase.

Estamos construyendo el producto correcto?

Validacin: El proceso de evaluacin de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos marcados por el usuario. 2

Proceso de ejecutar un programa con el fin de encontrar errores

Pruebas (test): Una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluacin de algn aspecto.

Caso de prueba (test case): Un conjunto de entradas, condiciones de ejecucin y resultados esperados desarrollados para un objetivo particular.
3

Defecto (defect, fault, bug): Un defecto en el software como, por ejemplo, un proceso, una definicin de datos o un paso de procesamiento incorrectos en un programa. Fallo (failure): La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados. Error (error): tiene varias acepciones:
Fallo

La diferencia entre un valor calculado, observado o medio y el valor verdadero, especificado o tericamente correcto. Un defecto Un resultado incorrecto Una accin humana que conduce a un resultado incorrecto

Defecto Fallo Error

4.1.2

La prueba exhaustiva del software es impracticable (no se pueden probar todas las posibilidades de su funcionamiento ni siquiera en programas sencillos). El objetivo de las pruebas es la deteccin de defectos en el software (descubrir un error es el xito de una prueba).

Mito: Un defecto implica que somos malos profesionales y que debemos sentirnos culpables.

Todo el mundo comete errores.

Cada caso de prueba debe definir el resultado de salida esperado que se comparar con el realmente obtenido.

El programador debe evitar probar sus propios programas, ya que desea (consciente o inconscientemente) demostrar que funcionan sin problemas. Adems, es normal que las situaciones que olvid considerar al crear el programa queden de nuevo olvidados al crear los casos de prueba. Se debe inspeccionar a conciencia el resultado de cada prueba, y as, poder descubrir posibles sntomas de defectos. Al generar casos de prueba, se deben incluir tanto datos de entrada vlidos y esperados como no vlidos e inesperados.
7

Las pruebas deben centrarse en dos objetivos (es habitual olvidar el segundo): Probar si el software no hace lo que debe hacer Probar si el software hace lo que debe hacer, es decir, si provoca efectos secundarios adversos.

Se deben evitar los casos desechables, es decir, los no documentados ni diseados con cuidado. Ya que suele ser necesario probar muchas veces el software y por tanto hay que tener claro qu funciona y qu no. No deben hacerse planes de prueba suponiendo que, prcticamente, no hay defectos en los programas y, por lo tanto, dedicando pocos recursos a las pruebas. Siempre hay defectos.
8

La experiencia parece indicar que donde hay un defecto hay otros, es decir, la probabilidad de descubrir nuevos defectos en una parte del software es proporcional al nmero de defectos ya descubierto.

Las pruebas son una tarea tanto o ms creativa que el desarrollo de software. Siempre se han considerado las pruebas como una tarea destructiva y rutinaria. Es interesante planificar y disear las pruebas para poder detectar el mximo nmero y variedad de defectos con el mnimo consumo de tiempo y esfuerzo.
9

4.1.3
Existen tres enfoques principales para el diseo de casos:

1.- El enfoque estructural o de caja blanca. Se centra en la estructura interna del programa (analiza los caminos de ejecucin).

2.- El enfoque funcional o de caja negra. Se centra en las funciones, entradas y salidas. 3.- El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones estadsticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba.
10

El diseo de casos de prueba tiene que estar basado en la eleccin de caminos importantes que ofrezcan una seguridad aceptable de que se descubren defectos (un programa de 50 lneas con 25 sentencias if en serie da lugar a 33,5 millones de secuencias posibles), para lo que se usan los criterios de cobertura lgica.

11

Sequence

If x then else

Do until x

While x do..

Consejos: -Separar todas las condiciones. -Agrupar sentencias simples en bloques. -Numerar todos los bloques de sentencias y tambin las condiciones.
12

Menos riguroso (ms barato)

Cobertura de sentencias. Se trata de generar los casos de prueba necesarios para que cada sentencia o instruccin del programa se ejecute al menos una vez.

Cobertura de condiciones. Se trata de disear tantos casos como sea necesario para que cada condicin de cada decisin adopte el valor verdadero al menos una vez y el falso al menos una vez. (No incluye cobertura de condiciones). Criterio de decisin/condicin. Consiste en exigir el criterio de cobertura de condiciones obligando a que se cumpla tambin el criterio de decisiones. Criterio de condicin mltiple. En el caso de que se considere que la evaluacin de las condiciones de cada decisin no se realiza de forma simultnea, se puede considerar que cada Ms decisin multicondicional se descompone en varias condiciones riguroso unicondicionales. Ejemplo en la siguiente diapositiva. (menos barato) Criterio de cobertura de caminos. Se recorren todos los caminos (impracticable)
13

14

Se centran en las funciones, entradas y salidas. Seria imprctico probar el software para todas las posibilidades. De nuevo hay que tener criterios para elegir buenos casos de prueba.

Un caso de prueba funcional es bien elegido si se cumple que:

Reduce el nmero de otros casos necesarios para que la prueba sea razonable. Esto implica que el caso ejecute el mximo nmero de posibilidades de entrada diferentes para as reducir el total de casos.
Cubre un conjunto extenso de otros casos posibles, es decir, no indica algo acerca de la ausencia o la presencia de defectos en el conjunto especfico de entradas que prueba, as como de otros conjuntos similares.

15

En las pruebas aleatorias simulamos la entrada habitual del programa creando datos de entrada en la secuencia y con la frecuencia con las que podran aparecer en la prctica (de manera repetitiva). Para ello habitualmente se utilizan generadores automticos de casos de prueba.

16

4.1.4

Para poder tener la certeza de que una aplicacin de software ha sido revisada en todos los aspectos indispensables y que posee una funcionalidad de acuerdo a los requerimientos del cliente, es necesario llevar un registro de las pruebas a realizar, donde se pueda tener un control del progreso de esta etapa. La documentacin del diseo de pruebas se compone de los siguientes pasos:

Generar un plan de pruebas. Disear pruebas especficas. Especificar los casos de prueba (tomar configuracin del sw a probar). Especificar los procedimientos de las pruebas (configurar las pruebas).

17

18

4.2 PROCESO DE PRUEBAS


Objetivo del documento: Sealar el enfoque, los recursos y el esquema de actividades de prueba, as como los elementos a probar, las caractersticas, las actividades de prueba, el personal responsable y los riesgos asociados.

4.2.1

Estructura del documento segn el estndar:

1. Identificador nico del documento.


2. Introduccin y resumen de elementos y caractersticas a probar. 3. Elementos de software a probar. 4. Caractersticas a probar. 5. Caractersticas que no se probarn. 6. Enfoque general de la prueba. 7. Criterios de paso / fallo para cada elemento.
19

Estructura del documento segn el estndar (cont): 8. Criterios de suspensin y requisitos de reanudacin. 9. Documentos a entregar. 10.Actividades de preparacin y ejecucin de pruebas. 11.Necesidades de entorno. 12.Responsabilidades en la organizacin y realizacin de pruebas. 13.Necesidades de personal y formacin. 14.Esquema de tiempos. 15.Riesgos asumidos por el plan y planes de contingencias.

16.Y las aprobaciones y firmas con nombre y puesto desempeado.

20

4.2.2

Objetivo del documento: Especificar los refinamientos sobre el enfoque general reflejado en el plan e identificar las caractersticas que se deben probar con este diseo de pruebas.

Estructura del documento segn el estndar:

1. Identificador nico para la especificacin (proporcionar tambin una referencia del plan asociado (si existe).
2. Caractersticas a probar de los elementos de software (y combinaciones de caractersticas).

3. Detalles sobre el plan de pruebas del que surge este diseo, incluyendo las tcnicas de prueba especifica y los mtodos de anlisis de resultados.

21

Estructura del documento segn el estndar (cont): 4. Identificacin de cada prueba: Identificador. Casos que se van a utilizar. Procedimientos que se van a seguir.

5. Criterios de paso / fallo de la prueba (criterios para determinar si una caracterstica o combinacin de caractersticas ha pasado con xito la prueba o no)

22

4.2.3

Objetivo del documento: Definir uno de los casos de prueba identificado por una especificacin del diseo de las pruebas.

Estructura del documento segn el estndar:

1. Identificador nico de la especificacin.


2. Elementos de software (por ejemplo, mdulos) que se van a probar: definir dichos elementos y las caractersticas que ejercitar este caso.

3. Especificaciones de cada entrada requerida para ejecutar el caso ( incluyendo las relaciones entre las diversas entradas; por ejemplo: la sincronizacin de las mismas).
4. Especificaciones de todas las salidas y las caractersticas requeridas (por ejemplo, el tiempo respuesta) para los elementos que se van a probar.
23

Estructura del documento segn el estndar (cont): 5. Necesidades de entorno (hardware, software y otras, como por ejemplo el personal). 6. Requisitos especiales de procedimiento (o restricciones especiales en los procedimientos) para ejecutar este caso. 7. Dependencias entre casos (por ejemplo, listar los identificadores de los casos que se van a ejecutar antes de este caso de prueba).

24

4.2.4

Objetivo del documento: Especificar los pasos para la ejecucin de un conjunto de casos de prueba, o ms generalmente, los pasos utilizados para analizar un elemento de software con el propsito de evaluar un conjunto de caractersticas del mismo.

Estructura del documento segn el estndar:


1. Identificador nico de la especificacin y referencia a la correspondiente especificacin de diseo de prueba. 2. Objetivo del procedimiento y lista de casos que se ejecutan con el. 3. Requisitos especiales para la ejecucin (por ejemplo, entorno especial o personal especial)

25

Estructura del documento segn el estndar (cont): 4. Pasos en el procedimiento. Adems de la manera de registrar los resultados y los incidentes de la ejecucin, se debe especificar: La secuencia necesaria de acciones para preparar la ejecucin. Acciones necesarias para empezar la ejecucin. Acciones necesarias durante la ejecucin. Como se realizarn las medidas (por ejemplo, el tiempo de respuesta) Acciones necesarias para suspender la prueba (cuando los acontecimientos no previstos lo obliguen). Puntos para reinicio de la ejecucin y acciones necesarias para el reinicio en estos puntos. Acciones necesarias para detener ordenadamente la ejecucin. Acciones necesarias para restaurar el entorno y dejarlo en la situacin existente antes de las pruebas. Acciones necesarias para tratar los acontecimientos anmalos.

26

4.2.5

Proceso de pruebas, tras el diseo de casos, segn el estndar IEEE 1008.

1. Ejecutar

3. Pruebas adicionales
2. Comprobar si termin la prueba

3. Evaluar resultados
27

Detalles del proceso a ejecutar:


Ejecutar pruebas
Depurar las pruebas
Hay falla ?

Depuracin del cdigo

Defectos en las pruebas

Defectos de software

Comprobar terminaci n
28

Histrico de pruebas: Documenta todos los hechos relevantes ocurridos durante la ejecucin de las pruebas. Informe de incidentes: Documenta cada incidente (por ejemplo, una interrupcin en las pruebas debido a un corte de electricidad, bloqueo del teclado, etc.) ocurrido durante la prueba y que requiera una posterior investigacin.

Resumen de pruebas: Lista los resultados de las actividades de prueba y aporta una evaluacin del software basada en dichos resultados.

29

4.2.5. 1
Es el proceso de analizar y corregir los defectos que se sospecha que contiene el software..

30

Localizacin del error: Analizar la informacin y pensar (analizar bien, en

lugar de aplicar un enfoque aleatorio de bsqueda del defecto) Al llegar a un punto muerto, pasar a otra cosa (refresca la mente) Al llegar a un punto muerto, describir el problema a otra persona (el simple hecho de describir el problema a alguien puede ayudar) Usar herramientas de depuracin slo como recurso secundario (no sustituir el anlisis mental) No experimentar cambiando el programa (no s qu est mal, as que cambiar esto y ver lo que sucede ) Se deben atacar los errores individualmente Se debe fijar la atencin tambin en los datos (no slo en la lgica del programa)
31

Correccin del error: Donde hay un defecto, suele haber ms (lo dice la

experiencia) Debe fijarse el defecto, no sus sntomas (no debemos enmascarar sntomas, sino corregir el defecto) La probabilidad de corregir perfectamente un defecto no es del 100% (cuando se corrige, hay que probarlo) Cuidado con crear nuevos defectos (al corregir defectos se producen otros nuevos) La correccin debe situarnos temporalmente en la fase de diseo (hay que retocar desde el comienzo, no slo el cdigo) Cambiar el cdigo fuente, no el cdigo objeto
32

4.2.5. 2 El objetivo del anlisis causal es proporcionar informacin sobre la naturaleza de los defectos. Para ello es fundamental recoger para cada defecto detectado esta informacin:

Cundo se cometi? Quin lo hizo Qu se hizo mal? Cmo se podra haber prevenido? Por qu no se detect antes? Cmo se podra haber detectado antes? Cmo se encontr el error?
33

4.3 TECNICAS DE DISEO DE CASOS DE PRUEBAS

TECNICA: Participaciones o clases de equivalencia.

Cada caso debe cubrir el mximo numero de entradas.


Cualidades que definen un buen caso de prueba.

Debe tratarse el dominio de valores de entrada dividido en un nmero finito de clases de equivalencia que cumplan la siguiente propiedad: la prueba de un valor representativo de una clase permite suponer <<razonablemente>> que el resultado obtenido (existan defectos o no) ser el mismo que el obtenido probando cualquier otro valor de la clase.
1. Identificar clases de equivalencia 2. Crear casos de prueba correspondiente
34

Lo que hay que hacer es:

1. Pasos para identificar las clases de equivalencia.

1.- Identificacin de las condiciones de las entradas del programa, es decir, restricciones de formato o contenido de los datos de entrada. 2.- A partir de ellas, se identifican clases de equivalencia que pueden ser: a) De datos vlidos. b) De datos no vlidos errneos.

3.- Existen algunas reglas que ayudan a identificar las clases: a) Se especifica un rango de valores para los datos de entrada, se creara una clase vlida y dos clases no vlidas. b) Se especifica un numero finito y consecutivo e valores, se creara una clase vlida y dos clases no vlidas. c) Se especifica una situacin del tipo << debe ser>> o booleana (por ejemplo, <<el primer caracter debe ser una letra>>), se identifican una clase vlida (<<es una letra>>) y una no vlida (<<no es una letra>>).
35

d) Si se especifica un conjunto de valores admitidos y se sabe que el programa trata de forma diferente cada uno de ellos, se identifica una clase vlida por cada valor y una no vlida. e) En cualquier caso, si se sospecha que ciertos elementos de una clase no se tratan igual que el resto de la misma, deben dividirse en clases menores.

2. Pasos para crear los casos de prueba.


Asignacin de un numero nico a cada clase de equivalencia.
Hasta que todas las clases de equivalencia vlidas hayan sido cubiertas por (incorporadas a) casos de prueba, se tratara de escribir un caso que cubra tantas clases vlidas no incorporadas como sea posible.

Hasta que todas las clases de equivalencia no vlidas hayan sido cubiertas por casos de prueba, escribir un caso para una nica clase no vlida sin cubrir.

36

EJEMPLO: Aplicacin bancaria en la que el operador debe proporcionar un cdigo, un nombre y una operacin. Habra que disear casos d prueba que cubran todas las clases de equivalencia, tanto vlidas como invlidas en casos de prueba distintos.
Condicin de entrada Cdigo de rea: No. De 3 dgitos que no empiece con 0 ni con 1 Clases vlidas (1) 200 cdigo 999 Clases invlidas (2) cdigo < 200 (3) cdigo > 999 (4) no es nmero

Nombre para identificar la operacin.

(5) Seis caracteres

(6) menos de 6 caracteres (7) ms de 6 caracteres


(12) ninguna orden vlida

Orden: (8) <<cheque>> Una de las siguientes: (9) <<deposito>> (10) <<pago factura>> (11) <<retiro de

37

TECNICA: Conjetura de errores.

Se enumera una lista de posibles equivocaciones tpicas que pueden cometer los desarrolladores y de situaciones propensas a ciertos errores. El valor cero es una situacin propensa a error tanto en la salida como en la entrada. En situaciones en las que se introduce un nmero variable de valores, conviene centrarse en el caso de no introducir ningn valor y en el de un solo valor. Tambin puede ser interesante una lista que tiene todos los valores iguales. Es recomendable imaginar que el programador pudiera haber interpretado algo mal en su especificacin. Tambin interesa imaginar lo que el usuario puede introducir como entrada a un programa.

38

4.5 ESTRATEGIAS DE APLICACIN DE LAS PRUEBAS

Se analiza como plantear las pruebas en el ciclo de vida del software. La estrategia de pruebas suele seguir estas etapas: Comenzar pruebas a nivel de modulo Continuar hacia la integracin del sistema completo y su instalacin Culminar con la aceptacin del producto por la parte del cliente

39

Relacin entre productos de desarrollo y niveles de prueba:

40

4.5.1

PRUEBAS DE UNIDAD
Se trata de las pruebas formales que permiten declarar que un mdulo est listo y terminado (no las informales que se realizan mientras se desarrollan los mdulos) Hablamos de una unidad de prueba para referirnos a uno o ms mdulos que cumplen las siguientes condiciones [IEEE, 1986a]: Todos son del mismo programa Al menos uno de ellos no ha sido probado El conjunto de mdulos es el objeto de un proceso de prueba

La prueba de unidad puede abarcar desde un mdulo hasta un grupo de mdulos (incluso un programa completo)

41

4.5.2

PRUEBAS DE INTEGRACIN
Implican una progresin ordenada de pruebas que van desde los componentes o mdulos y que culminan en el sistema completo. El orden de integracin elegido afecta a diversos factores, como lo siguientes:
La forma de preparar casos Las herramientas necesarias El orden de codificar y probar los mdulos El coste de la depuracin El coste de preparacin de casos
42

Tipos fundamentales de integracin: Integracin incremental. Se combina el siguiente mdulo que se debe probar con el conjunto de mdulos que ya han sido probados. ascendente. Se comienza por los mdulos hoja. descendente. Se comienza por el mdulo raz. Integracin no incremental. Se prueba cada mdulo por separado y luego se integran todos de una vez y se prueba el programa completo. Habitualmente las pruebas de unidad y de integracin se solapan y mezclan en el tiempo.
43

Ventajas de los tipos de pruebas de integracin:


Integracin incremental Requiere menos trabajo, ya que se escriben menos mdulos. Los defectos y errores de la interface se detectan antes, ya que las uniones entre mdulos se prueban antes. La depuracin es mucho mas fcil, ya que si se detectan los sntomas de un defecto en un paso de la integracin se puede atribuir al ultimo modulo incorporado. Se examina con mayor detalle el programa, al ir comprobando cada interfaz poco a poco. Integracin no incremental Requiere menos tiempo de maquina para las pruebas, ya que se prueba una sola vez la combinacin de los mdulos. Existen mas oportunidades de probar mdulos en paralelo

44

4.5.3

PRUEBAS DE SISTEMA
Es el proceso de prueba de un sistema integrado de hardware y software para comprobar lo siguiente:
Cumplimiento de todos los requisitos funcionales, considerando el producto software final al completo en un entorno de sistema. El funcionamiento y rendimiento en las interfaces hardware, software, de usuario y de operador. Adecuacin de la documentacin de usuario. Ejecucin y rendimiento en condiciones lmite y de sobrecarga.
45

4.5.4

PRUEBAS DE ACEPTACION
Es la prueba planificada y organizada formalmente para determinar si se cumplen los requisitos de aceptacin marcados por el cliente. Sus caractersticas principales son las siguientes: Participacin del usuario Est enfocada hacia la prueba de los requisitos de usuario especificados. Est considerada como la fase final del proceso para crear una confianza en que el producto es el apropiado para su uso en explotacin
46