Calidad de Software

2016

Sergio Zapata Marita Romagnano Magdalena Arrn

La construccin de un sistema software tiene
como objetivo satisfacer una necesidad planteada
por un usuario/cliente.
Cmo puede saber un desarrollador si el producto
construido se corresponde exactamente con lo que el
usuario le pidi?

Cmo puede un desarrollador estar seguro de que el

producto que ha construido va a funcionar correctamente?

Evaluando el producto software a medida

que se va construyendo (testing +
inspecciones)
 Qu es Probar (Test) Software?

Es el proceso de detectar diferencias (errores) entre el

comportamiento esperado y el comportamiento real del
sistema.

Qu NO es Probar Software?

- Intentar demostrar que el sw no tiene errores.

- Intentar demostrar que el sw realiza la funcionalidad correctamente.

- Intentar dar confianza que un programa ejecuta bien.

 No es lo mismo el Testing que el Debugging

El Testing o la Prueba muestra que un programa tiene

defectos, mientras el propsito del Debugging es encontrar
el error o mala concepcin que llev a la falla o defecto, y
disear e implementar los cambios que corrijan el error.

El Debugging usualmente se hace en conjunto con la

codificacin (es parte de la actividad de codificacin); el
Testing posterior a ella.

El Testing lo puede (debe?) hacer un externo, el Debugging

no.
Para qu sirve Probar software?

Es una de las barreras para evitar que Sistemas de

baja calidad lleguen a los usuarios finales

Cul es el objetivo de Probar software?

Detectar los defectos del sistema antes que lo haga el

usuario final
Un buen testing debe centrarse en dos objetivos:

Demostrar que el software NO HACE lo que

DEBE hacer.

Demostrar que el software hace lo que NO DEBE

hacer.

Una buena prueba no debe ser redundante. El tiempo y

los recursos son limitados, as todas las pruebas
deberan tener un propsito diferente.
 COSTO DE NO PROBAR

Prdidas de tiempo (retrabajo)

Prdidas econmicas (retrabajo)

Prdidas intangibles (confiabilidad, imagen

de la empresa)
Es posible PROBAR un programa
para encontrar TODOS sus posibles
defectos?
 No ni siquiera para los programas ms triviales

En general, es imprctico y a menudo

imposible encontrar todos los defectos
en un programa
 No se puede probar las respuestas del programa para
Cada posible entrada.

Qu significara probar cada entrada:

Se deben probar todas las entradas vlidas.
Se deben probar todas las entradas invlidas.
Se deben comprobar todas las entradas editadas.
Se deben probar las variables del ambiente operativo.
Se deben probar todas las variaciones temporales
de las entradas.

No se pueden probar todas las Secuencias de ejecucin.

 CMO DEBERAN SER LAS PRUEBAS?,
algunos consejos..

Respetar un encuadre formal para todas las actividades

de pruebas.

Aplicar una mtodo fcilmente repetible en mltiples

circunstancias.

Medir lo ms exhaustivamente posible.

Ejecutar el proceso de testing en paralelo al ciclo de

desarrollo de software.
 Dos Enfoques.
Prueba Habitual (mala prctica)

En la prueba habitual, el objetivo dominante es

demostrar que el sistema funciona.

Prueba Sistemtica

La prueba sistemtica por el contrario, se focaliza

en la deteccin e identificacin de defectos del sistema.
 VENTAJAS DE LAS PRUEBAS SISTEMTICAS

- Asegura la confiabilidad de las aplicaciones a

implementar.

- Permite detectar los defectos antes que lo hagan los

usuarios finales.

- Permite mejorar el proceso de desarrollo.

 Quin realiza las pruebas?

Las pruebas deberan ser realizadas por un equipo

independiente al que realiz el software. El ingeniero de
software que cre el sistema no es el ms adecuado para
llevar a cabo las pruebas de dicho software, ya que
inconcientemente tratar de demostrar que el software
funciona, por lo que la prueba puede tener menos xito.

Se debe lograr la independencia de la prueba

sistemtica, espritu critico e independiente
 DEFINICIONES
Pruebas (test): una actividad en la cual un sw, o parte, 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.

Defecto (defect, fault, bug): una deficiencia en el software

como, por ejemplo, un proceso, una definicin de datos o un
paso de procesamiento incorrectos en un programa.

Error (humano) -> (introduce) Defecto -> (aparece) fallo

 CASOS DE PRUEBA

Un caso de prueba es la unidad primaria del proceso de

testing. Consta, bsicamente, de tres partes:

Objetivo: la funcionalidad o atributo a comprobar del

sistema.

Datos de entrada y de ambiente: datos a introducir al

sistema y valores de las variables de ambiente.

Comportamiento esperado: La salida o la accin

esperada en el sistema de acuerdo a los
requerimientos del mismo.
Proceso estndar de testing de software
 CASOS DE PRUEBA

Deben ser documentados y archivados.

Definir el resultado esperado.

Tanto entradas invlidas e inesperadas como
esperadas.
Analizar detenidamente resultado de cada prueba.
Comprobar si no hace lo que debe o hace lo que
no debe.

Deben disearse tambin para condiciones de entrada

invlidas e inesperadas, no solo para aquellas vlidas y
esperadas.
 CICLO DE PRUEBAS

Un ciclo de pruebas abarca la ejecucin

de la totalidad de los casos de prueba
diseados y luego aplicados a una
misma versin del software a probar.
 Tareas a realizar para probar un software:

Esto es, identificacin de la tcnica o

tcnicas de pruebas que se utilizarn
Diseo de las pruebas. para probar el software.
Distintas tcnicas de prueba ejercitan
diferentes criterios guas para
realizar las pruebas.
 Tareas a realizar para probar un software:

Los casos de prueba determinan un conjunto de

entradas, condiciones de ejecucin y resultados
esperados para un objetivo particular.
Cada tcnica de pruebas proporciona unos
criterios distintos para generar estos casos o
Generacin de los datos de prueba. Por lo tanto, durante la tarea de
Casos de Prueba generacin de casos de prueba, se han de
confeccionar los distintos casos de prueba segn
la tcnica o tcnicas identificadas previamente. La
generacin de cada caso de prueba debe ir
acompaada del resultado que ha de producir el
software al ejecutar dicho caso (esto es necesario
para detectar un posible defecto en el programa).
 Tareas a realizar para probar un software:

Esto es, la especificacin de

Definicin de los
cmo se va a llevar a cabo el
procedimientos de la prueba proceso, quin lo va a realizar,
cundo, donde
 Tareas a realizar para probar un software:

Aplicacin de los casos de prueba

generados previamente e identificacin
Ejecucin de la prueba de los posibles fallos producidos al
comparar los resultados esperados con
los resultados obtenidos.
 Tareas a realizar para probar un software:

Con el resultado de la ejecucin de las

pruebas,

Realizacin de un informe Qu casos de prueba pasaron

de la prueba satisfactoriamente,

Cules no, y

Qu fallos se detectaron.
 Tareas a realizar para probar un software:

Las tares mencionadas (Diseo, Definicin

de Casos de Pruebas, Definicin de
Procedimientos, Ejecucin y Emisin de
Informes) no necesariamente son
secuenciales como se ha planteado ac.
Depender de la organizacin el
ordenamiento que se establece.
 Algunas tcnicas de testing
Static Dynamic
Reviews etc.
Static Analysis
Behavioural
Inspection
Walkthroughs Structural Non-functional Functional
Desk-checking etc.
etc.
Equivalence
Control Usability Partitioning
Data Flow
Flow Performance
etc. Boundary
Value Analysis
etc.
Statement
Symbolic Cause-Effect Graphing
Execution Branch/Decision Arcs
Random
Definition - Use Branch Condition LCSAJ
Branch Condition State
Combination Transition
 Tcnicas de Pruebas

- Tcnicas de caja blanca o estructurales

Se basan en un minucioso exmen de los detalles

procedimentales del cdigo a evaluar, por lo que es
necesario conocer la lgica del programa.

Tcnicas de caja negra o funcionales

Se realizan pruebas sobre la interfaz del programa a

probar, entendiendo por interfaz las entradas y salidas
de dicho programa. No es necesario conocer la lgica
del programa, nicamente la funcionalidad que debe
realizar.
Si se les diera un mdulo de cdigo
fuente Cmo haran para probar si
ese mdulo es correcto?
 CAJA BLANCA
Parecera que una prueba de Caja Blanca completa nos
llevara a disponer de un cdigo perfectamente correcto.
Para programas de moderado tamao, el nmero de
casos de prueba sera excesivo. El nmero de caminos
incrementa exponencialmente a medida que el nmero
de sentencias condicionales y bucles aumenta.

Sin embargo, este tipo de prueba no se desecha como

impracticable. Se pueden elegir y ejercitar ciertos
caminos representativos de un programa.
 CAJA NEGRA

Tampoco sera factible en una prueba de Caja Negra

probar todas y cada una de las posibles entradas a un
programa, anlogamente a como ocurra con las
tcnicas de caja blanca.

Se seleccionan un conjunto representativo de entradas

y se generan los correspondientes casos de prueba,
con el fin de provocar fallos en los programas.
 En realidad estos dos tipos de tcnicas son

COMPLEMETARIAS

Ayudan a identificar distintos tipos de fallas en

un programa.
 Qu defectos puede encontrar un testing
estructural que sea ms difcil de encontrar
con un testing funcional?
 Criterios para realizar las pruebas de Caja Blanca

Cobertura de Sentencias

Se escriben casos de prueba suficientes para que

cada sentencia en el programa se ejecute, al menos,
una vez.

Cobertura de Decisin

Se escriben casos de prueba suficientes para que

cada decisin en el programa se ejecute una vez con
resultado verdadero y otra con el falso.
Cobertura de Condiciones
Se escriben casos de prueba suficientes para que
cada condicin en una decisin tenga una vez
resultado verdadero y otra falso.

Cobertura Decisin/Condicin

Se escriben casos de prueba suficientes para que

cada condicin en una decisin tome todas las
posibles salidas, al menos una vez, y cada decisin
tome todas las posibles salidas, al menos una vez.
Cobertura de Condicin Mltiple
Se escriben casos de prueba suficientes para que
todas las combinaciones posibles de resultados de
cada condicin se invoquen al menos una vez.

Cobertura de Caminos

Se escriben casos de prueba suficientes para

que se ejecuten todos los caminos de un
programa. Entendiendo camino como una
secuencia de sentencias encadenadas desde la
entrada del programa hasta su salida.
 Criterios para realizar las pruebas de Caja Negra
Particiones de Equivalencia
Este mtodo intenta dividir el dominio de entrada de
un programa en un nmero finito de clases de
equivalencia, es decir, divide el campo de entrada de
un programa en clases de datos de los que se
pueden derivar casos de prueba.

Anlisis de Valores Lmite

Nos lleva a elegir los casos de prueba que ejerciten
los valores lmite. Las condiciones lmite son
aquellas que se hayan en los mrgenes de la clase
de equivalencia, tanto de entrada como de salida.
 OTROS CRITERIOS

- Mtodos Basados en Grafos.

- Pruebas de Comparacin.

- Anlisis Causa-Efecto.
ESTRATEGIAS DE PRUEBA

La estrategia que se ha de seguir a la hora de evaluar

dinmicamente un sistema software debe permitir
comenzar por los componente ms simples y ms
pequeos e ir avanzando progresivamente hasta
probar todo el software en su conjunto.
Ms concretamente, los pasos a seguir son:

Pruebas Unitarias
Pruebas de Integracin
Pruebas del Sistema
Pruebas de Aceptacin
ESTRATEGIAS DE PRUEBA

1. Pruebas Unitarias. Comienzan con la prueba de cada

mdulo.

2. Pruebas de Integracin. A partir del esquema del

diseo, los mdulos probados se vuelven a probar combinados
para probar sus interfaces.

3. Prueba del Sistema. El software totalmente

ensamblado, con cualquier componente hardware requerido, se
prueba para comprobar que se cumplen los requisitos
funcionales y no funcionales.

4. Pruebas de Aceptacin. El cliente comprueba que el

software funciona segn sus expectativas.
Pero, necesito tener el cdigo para comenzar
a ejecutar el proceso de testing ?
Las Pruebas Unitarias y de Integracin no pueden
comenzar hasta que no se dispone de componentes del
sistema ya construidos.

Lo mismos ocurre con las Pruebas de Implantacin y

Aceptacin que tampoco pueden comenzar hasta que se
disponga del sistema completo y se instale en su entorno
de produccin.
 Sin embargo

La Planificacin de las Pruebas de

sistema puede comenzar antes de que
el sistema est terminado.
 Como el objetivo de las Pruebas de Sistema

Es comprobar que todo lo que se est

desarrollando cumple con los Requisitos del
sistema

La Planificacin de estas Pruebas y la Definicin

de los casos de prueba pueden comenzar tan
pronto como estn disponibles las
especificaciones funcionales del sistema.
La Planificacin y
Definicin de las permite
pruebas de sistema en encontrar * Errores,
* Omisiones,
las primeras fases de
* Inconsistencias y
desarrollo, cuando an
* Sobreespecificaciones
se realiza la Elicitacin
de requisitos

En los requisitos funcionales cuando an es

fcil y econmico corregirlas,
 En los requisitos funcionales cuando an es
fcil y econmico corregirlas,

Ya que el Costo de eliminar defectos

AUMENTA

a medida que AUMENTA el tiempo qu

transcurre entre la introduccin del defecto y
su deteccin
 Para que el Proceso de Prueba del Sistema sea
EFICAZ

Debe estar:
Integrado dentro del propio proceso de desarrollo y
Debe realizarse de manera sistemtica, minimizando el
factor experiencia o intuicin.

Esto se puede conseguir a travs de metodologas que

guen el proceso de desarrollo de pruebas de sistema a
partir de requisitos funcionales.
 - Interfaces del usuario
- Performance
- Carga
Otros tipos de prueba para - Estrs
completar el proceso son:
- Volumen
- Configuracin
- Instalacin
 Prueba de las interfaces del usuario

Usuario en control + Muchas combinaciones = Ms pruebas

Pruebas de usabilidad, es una forma mas de testing.

Estado de los objetos
Modos de ventana

Mens

Tamao estndar de los controles

Redaccin
 Sesin #2
Windows
puede cambiar
su...
Sesin #1 ..Ubicacin

2 sec... ...Tamao

Velocidad
10 sec...
 Tiempo de respuesta: agregar una
Prueba de Performance cuenta en 3 seg.
Actualizaciones mltiples a las
bases de datos
Concurrencia de mltiples usuarios
Prueba de estrs

Encontrar errores debidos a la escasez de recursos

Falta de memoria
Falta de espacio en disco

Encontrar errores debidos a la existencia de recursos

compartidos
Recursos del sistema
Bloqueos de la base de datos
Ancho de banda de la red
Prueba de volumen

Someter al software a grandes cantidades de datos

para ver si el sistema falla al llegar a los lmites para
los cuales fue concebido.

Verificar que el software se comporte amigablemente

con el usuario al aproximarse a los lmites.

Por ejemplo:
Agregar el registro 1.000.001 para un sistema
desarrollado para soportar 1.000.000 de registros
 Prueba de configuracin, ejemplos:

Compatible con X video drivers

Conexiones de red

Aplicacin Servidor de Base de Datos

cliente

Server OS
Cliente OS Runtime Network
DLLs TP monitor Middleware E-mail
Mainframe connectivity
Prueba de instalacin

Opciones:
Nueva instalacin
Actualizacin de una instalacin
Personalizacin adecuada

Network / PC
 UML Y CASOS DE PRUEBA

Con el auge del conjunto de diagramas propuestos

en la notacin UML para el modelado de los
diferentes aspectos de un sistema, surgieron:

Nuevas propuestas Metodolgicas y Herramientas

para el desarrollo del proceso de prueba a partir de
escenarios de uso del sistema descritos mediante
diagramas, principalmente con la notacin UML.
El objetivo de las pruebas del sistema
es comprobar que el sistema software,
que se est desarrollando, cumple con
la funcionalidad recogida en casos de
uso o escenarios.
 En un proyecto de desarrollo de software, los
Casos de Usos definen los requisitos del sistema

De todas las tcnicas mencionadas estudiaremos:

Generacin de Casos de Pruebas

a partir de los Casos de Usos

Los desarrolladores pueden comenzar a crear los casos de

pruebas antes de que se comience a escribir el cdigo
Definamos previamente algunos conceptos que nos
servirn ms adelante:

Los casos de usos se basan en el Lenguaje de

Modelamiento Unificado (UML) y pueden ser representados
visualmente en un Diagrama de Casos de Usos

Segn el RUP un Caso de Uso :

Describe una secuencia de acciones ejecutadas por un sistema para

proveer un resultado a una persona o sistema que lo solicit
 COMPONENTES

Los valos representan los Casos de

Usos

Las figuras representan a los actores,

que pueden ser personas reales u otros
sistemas

Las lneas representan la comunicacin

Entre los actores y los casos de usos
 Cmo debe ser descripto un Caso de Uso

Cada caso de uso necesita de cierta cantidad de texto para poder

describirlo, esto se resume generalmente en una tabla o plantilla

Caso de uso Descripcin

Nombre Un nombre apropiado para cada Caso de Uso
Breve descripcin Una breve descripcin del caso de uso y el propsito
del mismo
Flujo de eventos Una descripcin textual de que es lo que hace el
caso de uso, no cmo se hace para solucionarlo
Requerimientos especiales Como requerimientos no funcionales, otros caso de uso
que es considerado en el modelo de casos de usos
Precondiciones Algo que se necesita para que comience el caso de uso
Post condiciones Algo que necesita generar el caso de uso al finalizar
La parte ms importante de un caso de uso para generar
los casos de prueba es el flujo de eventos

Un flujo de eventos consiste de:

El flujo Bsico

Flujos Alternativos
El flujo bsico de eventos debera cubrir lo que
normalmente ocurre cuando se ejecuta el caso de
uso

Los flujos alternativos de eventos cubren

comportamientos opcionales o excepciones relativos a
un normal comportamiento o tambin variantes al
comportamiento normal

Se puede pensar de los flujos alternativos como

destructores del flujo bsico de eventos
Hay un concepto ms que describir, antes de poder
concentrarnos en como a partir de casos de usos se
generarn los casos de prueba necesarios para llevar
a cabo el proceso de Prueba. Es el concepto de:

Escenarios de los Casos de Usos

Es una instancia de un caso de uso o un trayectoria

o camino a lo largo de un caso de uso.
Los usuarios del sistema pueden recorrer los caminos hacia
abajo para ejecutar la funcionalidad especificada en el caso
de uso

Siguiendo el flujo bsico debera haber un solo escenario

Siguiendo el flujo bsico ms los alternativos, deberan

existir otros escenarios
Generando los casos de Pruebas

Un caso de prueba es un conjunto de entradas de

prueba, condiciones ambientales y resultados
esperados, desarrollados con un objetivo
particular:

Ejecutar un camino o escenario particular de un programa o

verificar la satisfaccin de los requerimientos especificados.
El objetivo de un caso de prueba o
caso de test es identificar y expresar
las condiciones bajo las cuales se
probar el software y los resultados o
salidas esperadas de esa prueba.
 Etapas Previas del Proceso de Testing
basado en Casos de Uso

Identificar escenarios

Generar casos de prueba

Determinar los valores a probar

PROCESO

1. Para cada Caso de Uso, identificar el conjunto de

escenarios posibles.

2. Para cada escenario, identificar al menos un caso

de prueba y las condiciones que llevarn a ejecutar
este caso.

3. Para cada caso de prueba, identificar los valores de

los datos con los cuales se ejecutar dicho caso de
prueba.
PASO 1

IDENTIFICACIN DE ESCENARIOS

Se debe leer la descripcin del caso de uso e identificar cada

combinacin posible de Flujo normal y Flujo alternativo (los
Escenarios).

Luego crear una matriz de escenarios

Ejemplo

Todos estos escenarios sern utilizados para generar los casos

de prueba
PASO 2

GENERAR LOS CASOS DE PRUEBA

Una vez que todo el conjunto de escenarios ha sido identificado,

deberemos ahora identificar los casos de prueba, esto se puede
hacer analizando los escenarios y la descripcin textual del caso
de uso.

Debera haber al menos un caso de prueba por escenario pero

probablemente sern ms.

Adems quizs nosotros deseamos agregar casos de prueba

para probar condiciones lmites.
Para identificar claramente un caso de prueba se utilizar una
matriz denominada Matriz de Casos de Prueba

La primer columna de esta matriz contendr un identificador

de los casos de prueba, la segunda columna una breve
descripcin del caso de prueba, y todas las otras columnas
excepto la ltima contendrn los elementos de datos los
cuales sern usados para ejecutar las pruebas

La ltima columna contiene una descripcin del resultado

esperado del caso de prueba
 Matriz de Casos de Prueba

Variables de Entrada.
Identificador Controlan el flujo de Resultado
Caso de Prueba ejecucin esperado

Escenario a probar
Matriz de Casos de Prueba
 Matriz de Casos de Prueba

En esta matriz los valores correspondientes a los valores a probar

no han sido introducidos

Las celdas de esta matriz o tabla contienen una V, I o n/a.

La V indica vlido, la I para invlido y n/a significa que este dato

valor no es necesario o no se aplica en este caso de prueba

Esta matriz es un buen paso intermedio ya que ayuda a mostrar

claramente que condiciones se necesitan de los datos para probar
cada caso de prueba.
Mediante esta tabla es fcil determinar cual es el
escenario positivo en el cual todas las cosas
funcionan bien.

Como as tambin se observan los escenarios

negativos, cuando no todo funciona bien.
PASO 3

DETERMINAR LOS VALORES A PROBAR

Una vez que todos los Casos de Prueba han sido identificados,
deben ser revisados, para asegurar la exactitud e identificar as
errores o redundancia en los Casos de Prueba

Una vez aprobados, el paso final es sustituir los valores

generales (las I y las V) por los datos concretos a probar. Sin
los datos de prueba los casos de prueba no pueden ser
implementados, ya que solo son descripciones de
condiciones, escenarios y caminos.
Ejemplo

Registrar
Curso Seleccionar Sistema de catlogo
Curso De cursos
A dictar

estudiante

Cerrar
registracin

profesor

registrador
 Plantilla de Casos de Usos

Nombre Registrar Curso

Breve descripcin Permite que un alumno pueda inscribirse en los Cursos

que desea. El alumno tiene la posibilidad de salir del
caso de uso cuando lo desee, si la operacin no se ha
completado el curso no se registra.

Actores

Flujo de eventos 1. El alumno solicita ingresar al sistema

2. El sistema solicita nombre y contrasea
3. El alumno ingresa nombre y contrasea
4.a Si [datos] no son correctos
4.a.1 ir al paso 1
5. El sistema muestra informacin de los cursos
que puede inscribirse
6. El alumno ingresa 4 cursos principales y 2 alternativos
7. a Si [E] conflictos con los cursos ingresados
7.a.1 El sistema muestra mensaje de error
7.a.2 ir al paso 6
8. El alumno confirma que finaliz la registracin
9. El sistema muestra el detalle de los curso registrados
por ese alumno
10. Fin caso de uso
El alumno debe tener las correlativas correspondientes a
los cursos para poder inscribirse en el curso
seleccionado
1. El alumno solicita ingresar al sistema
2. El sistema solicita nombre y contrasea
3. El alumno ingresa nombre y contrasea
4.a Si [datos] no son correctos
4.a.1 ir al paso 1
5. El sistema muestra informacin de los cursos
que puede inscribirse
6. El alumno ingresa 4 cursos principales y 2 alternativos
7. a Si [E] conflictos con los cursos ingresados
7.a.1 El sistema muestra mensaje de error
7.a.2 ir al paso 6
8. El alumno confirma que finaliz la registracin
9. El sistema muestra el detalle de los curso registrados
por ese alumno
10. Fin caso de uso
 PASO 1 Caso de Uso: Registrar Curso

Generar Escenarios

Flujo Normal de eventos

1. El alumno solicita ingresar al sistema

2. El sistema solicita nombre y contrasea
3. El alumno ingresa nombre y contrasea
4. El sistema muestra la informacin de los cursos que puede inscribirse
5. El alumno ingresa 4 curso principales y 2 alternativos
6. El alumno indica que finaliz la registracin
7. El sistema muestra al alumno la lista de curso registrados.
8. Fin caso de uso
 Caso de Uso: Registrar Curso

Flujo Alternativo1 de eventos

El nombre y/o contrasea del alumno no son correctos

Flujo Alternativo2 de eventos

Existen problemas con los cursos ingresados en el sistema,
ya sea porque no tiene las correlativas o por que los cursos estn completos

Flujo Alternativo3 de eventos

El alumno puede elegir la opcin de salir en cualquier
momento por lo que el caso de uso finaliza
Escenario 1 Flujo Normal

Escenario 2 Flujo Normal Flujo Alternativo1

Escenario 3 Flujo Normal Flujo Alternativo2

Escenario 4 Flujo Normal Flujo Alternativo3

 PASO 2
Identificar Casos de Prueba

Id. CT Escenario Id/passw Cursos ok No Exit Resultado

CT1 1 V V V Registro
ok
CT2 2 I N/a V Error id,
vuelva
login
CT3 3 V I V Error
cursos
selecc.Vuel
va selecc.
CT4 4 V V I Aborta
ejec.
 PASO 3
Identificar los valores a probar

Id. Caso Escenario Nombre Contrasea Cursos OK No Quit Resultado

Prueba

CP1 escenario1 Ana xx1 si si Confirmacin

y plan correctos
CP2 escenario2 Ana x11 n/a si Mensaje de
Error vuelta
a login
No, falta si
CP3 escenario3 Ana xx1 Mensaje de
matemtica Error volver a
. seleccionar
.
.
 Informes de Prueba

Para que una prueba sea vlida, debe contener la mayor

documentacin posible, con el fin de que, quien deba efectuar la
correccin, pueda replicar el error para analizarlo y luego proceder a
tomar medidas correctivas.

Para ello se recomienda llevar una planilla de clculo en que se vayan

anotando por columna los siguientes datos
 Deteccin del Error
Para ser anotado por quien prueba.

Mdulo Indica la seccin en la que se produce el error

URL Direccin de la pgina donde ocurri el error

Accin Indica la secuencia de pasos que sigui

para que ocurra el error

Lo que hace Es la explicacin, ms detallada posible, de

o dice la manifestacin del defecto en el sistema
(mensaje, crash, resultado incorrecto, etc.)
Lo que debe Se debe indicar lo que se espera que debera
hacer o decir ocurrir cuando se hace la accin que se ha
descripto.

Encontrado por Nombre de quien prueba

Fecha Fecha en la que se hace la anotacin

Reproducible Indicar si el error se repite al hacer nuevamente

la prueba.
Permite definir el grado de complejidad del
error, al sealar si afecta el funcionamiento
Clasificacin
del sistema (caso extremo) o slo su
presentacin.
 Diagnstico del Error
Para ser anotado por quien corrige

Causas Motivo por el cual se produce el error

Indicar en qu otros mdulos la existencia

de este error puede estar causando impacto
Efectos colaterales negativo; muchas veces errores diversos
tienen una causa comn, por lo que al
reparar sta se arreglan los dems.
 Correccin del Error
Para ser anotado por quien corrige.

Accin realizada para hacer la reparacin

Descripcin del error

Archivos Archivos en los que se hicieron modificaciones

intervenidos o, al menos, el principal de ellos

Corregido por Persona que hizo la correccin

Fecha correccin Fecha en que qued reparado el error

 Comprobacin de la Correccin
Para ser anotado por quien revisa la correccin realizada

Nombre de quien revisa si el error fue

Revisor
efectivamente reparado

Fecha Fecha en que se realiza la revisin

Reparado Indicar si est reparado o no. Si no lo est,

se debe copiar la lnea de error en blanco en
una nueva planilla, con el fin de solicitar
nuevamente el proceso de correccin.
POR FIN SE TERMIN!!!
 CONDICIONES DE PRUEBA

Esta es la reaccin esperada de un sistema

frente a un estmulo particular, este
estmulo est constituido por las distintas
entradas.

Una condicin de prueba debe ser probada

por al menos un Caso de prueba
 Ofrece un mtodo muy completo para manipular y
SCENT organizar los requisitos funcionales en escenarios
de uso y derivar casos de prueba del sistema a
partir de ellos.

Abarca tanto la elaboracin de un prototipo del

sistema como la generacin y ejecucin de las
AGEDIS pruebas. Cuenta, adems, con un
conjunto de herramientas para automatizar el
proceso.
Generating Test Desarrolla un mtodo basado en tres pasos
Cases From use para obtener un conjunto de casos de prueba
Cases del sistema a partir de casos de uso
descritos en lenguaje natural.

Est orientada a obtener un conjunto de casos

UML-Based de prueba para realizar pruebas de carga en
Statistical Test Case funcin de las probabilidades de cada caminos
Generation de ejecucin para cada requisito funcional.
 Analiza todos los caminos de ejecucin para
Use Case Path un caso de prueba, los punta y selecciona el
Anmalisys conjunto mnimo que deben traducirse a
pruebas del sistema.
Todas las propuestas basadas en Casos de Uso tienen
principios comunes :
1. El objetivo de estas propuestas es obtener un conjunto
completo de pruebas del sistema que permitan garantizar
que el sistema software cumple con la especificacin
funcional dada, lo cual permite asegurar su calidad.

2. Todas parten de los requisitos funcionales del sistema y

todas permiten comenzar a desarrollar los casos de
prueba del sistema en cuanto se dispongan los requisitos
funcionales.

3. Todos usan el anlisis de los caminos posibles, bien

mediante la descripcin textual de los pasos del escenario
o caso de uso o mediante diagramas de estado.
4. Los requisitos funcionales no tienen que cumplir de principio
ningn requisito formal. A partir de una breve descripcin en
lenguaje natural ya se puede comenzar a trabajar.

5. La derivacin de pruebas del sistema a partir de los requisitos

funcionales se realiza de manera automtica y sistemtica. Todas
las propuestas son susceptibles de automatizacin mediante
herramientas software.

6. La aplicacin de estas propuestas a los requisitos funcionales

ayuda a validarlos, comprobando si son correctos y completos en
las primeras fases de desarrollo.
Ventajas

Las ventajas principales son que garantiza la calidad del

sistema y permite validar requisitos en fase temprana,
especialmente en este caso donde podemos encontrar
un nmero elevado de casos de uso a medida que vayamos
detallando la funcionalidad del sistema.

Inconveniente

El principal inconveniente es que estas propuestas an

han sido poco estudiadas y no hay una propuesta
uniforme.
 Guas a tener en cuenta para la seleccin de los datos
a probar

Volumen o cantidad de datos que sern usados en la

prueba
Una pequea cantidad puede No reflejar las condiciones
de vida real
Profundidad Una gran cantidad de datos es a la vez difcil de manejar
y de mantener

Deberan comenzar con una pequea cantidad para

luego ir aumentando hasta que dicha profundidad sea
representativa del ambiente de desarrollo
 Se refiere al grado en el cual los valores de los datos de
prueba varan

Si no se consideran las variaciones en nuestros datos,

se puede fallar en la identificacin de los defectos
Amplitud

Los valores de los datos de prueba deben reflejar los

valores de acuerdo al ambiente de desarrollo , por
ejemplo no ingresar nmeros de documentos de ms
de 8 cifras.
 El tomar una gran cantidad de datos no significa que
sean correctos debemos asegurarnos de que los
valores de los datos de prueba sean relevantes al
objetivo de la prueba.
Alcance
Es decir que si nuestra realidad nos indica que se
deben permitir valores negativos en una cuenta de
banco, esto no debe ser considerado Incorrecto, ya
que el desarrollo as lo demanda.