Pruebas de Software (2)

7/29/2019 Pruebas de Software (2)

1/129

PRUEBAS DE SOFTWARE 1

Pruebas de

Software


2/129

2

CARRERAS PROFESIONALES CIBERTEC


3/129


CIBERTEC CARRERAS PROFESIONALES

NDICE Pgina

Presentacin 5

Red de contenidos 6

Unidad de aprendizaje 1: Fundamentos de Pruebas de Software

1.1 Tema 1 : Pruebas de Software 8

1.1.1. : Validacin y Verificacin en el desarrollo de software 8

1.1.2. : Tipos de pruebas 11

1.1.3. : Diseo de casos de prueba 17

1.2 Tema 2 : Administracin de Pruebas 251.2.1. : Estrategias de pruebas 25

1.2.2. : Roles y responsabilidades 30

1.2.3. : Tcnicas de pruebas 33

1.2.4. : Herramientas de pruebas 42

Unidad de aprendizaje 2: Fundamentos Rational Functional Tester

2.1 Tema 3 : Introduccin al Rational Functional Tester 54

2.1.1. : Arquitectura de Rational Functional Tester 54

2.1.2. : Configuracin del entorno de pruebas 562.1.3. : Configuracin de aplicaciones Java a probar 62

2.1.4. : Proyectos de pruebas funcionales en Rational

Functional Tester

67

2.2 Tema 4 : Script de pruebas funcionales 70

2.2.1. : Grabacin de un script 71

2.2.2. : Reproduccin de un script 89

2.2.3. : Revisin de los resultados 90

2.2.4. : Caractersticas avanzadas de script de pruebas 90Unidad de aprendizaje 3: Fundamentos Rational Performance Tester

3.1 Tema 5 : Introduccin al Rational Performance Tester 98

3.1.1. : Arquitectura de Rational Performance Tester 98

3.1.2. : Caractersticas y beneficios 99


4/129

4


3.2 Tema 6 : Pruebas de rendimiento 105

3.2.1. : Crear y ejecutar pruebas de rendimiento

3.2.2. : Anlisis de resultados

4.1.3. : Modificar pruebas de rendimiento


5/129



PRESENTACIN

Pruebas de Softwarepertenece a la lnea de carrera y se dicta en la carreraprofesional de Computacin e Informtica. Brinda los conceptos bsicosrelacionados al rea de aseguramiento de calidad de software y administracinde pruebas de software, alineados a las mejores prcticas en desarrollo desoftware.

El manual para el curso ha sido diseado bajo la modalidad de unidades deaprendizaje, las que se desarrollan durante semanas determinadas. En cada una

de ellas, hallar los logros, que debe alcanzar al final de la unidad; el tematratado, el cual ser ampliamente desarrollado; y los contenidos, que debedesarrollar, es decir, los subtemas. Por ltimo, encontrar las actividades quedeber desarrollar en cada sesin, que le permitirn reforzar lo aprendido en laclase.

El curso es eminentemente prctico: consiste en sesiones tericas acompaadascon aplicaciones prcticas. En primer lugar, se explica la importancia de laverificacin y validacin de software para el control de calidad del producto desoftware. Contina con la presentacin de los fundamentos del Rational

Functional Tester para la creacin de scripts de pruebas funcionales. Por ltimo,se concluye con la aplicacin del Rational Performance Tester para el diseo depruebas de rendimiento.


6/129

6


RED DE CONTENIDOS

Pruebas de Software

Fundamentosde Pruebasde Software

Pruebas de Software

Administracin dePruebas

FundamentosRational

FunctionalTester

FundamentosRational

PerformanceTester

Introduccin alRational FunctionalTester

Script de pruebasfuncionales

Introduccin alRationalPerformance Tester

Script de pruebasde rendimiento


7/129



FUNDAMENTOS DE PRUEBAS DE SOFTWARE

LOGRO DE LA UNIDAD DE APRENDIZAJE

Al trmino de la unidad, el alumno reconoce la importancia de la validacin yverificacin de software para el control de calidad del producto de software.

TEMARIO

1.1.Tema 1: Pruebas de software1.1.1. Validacin y Verificacin en el desarrollo de software1.1.2. Tipos de pruebas

1.1.2.1. En funcin de qu conocemos1.1.2.2. Segn el grado de automatizacin

1.1.2.3. En funcin de qu se prueba1.1.3. Diseo de casos de prueba

1.2. Tema 2: Administracin de pruebas1.2.1. Estrategias de pruebas1.2.2. Roles y responsabilidades1.2.3. Tcnicas de pruebas1.2.4. Herramientas de pruebas

ACTIVIDADES PROPUESTAS

Los alumnos disean los casos de pruebas de un caso de uso a partir de suespecificacin.

Los alumnos disean los casos de pruebas de un caso de uso a partir de suprototipo y consideraciones del llenado de datos.

UNIDAD DE

APRENDIZAJE

1


8/129

8


1.1. PRUEBAS DE SOFTWARELas pruebas de software (testing en ingls) son los procesos que permitenverificar y revelar la calidad de un producto software antes de su puesta enmarcha. Bsicamente, es una fase en el desarrollo de software que consiste enprobar las aplicaciones construidas.

Las pruebas de software se integran dentro de las diferentes fases del ciclo devida del software dentro de la Ingeniera de software. En este sentido, se ejecutael aplicativo a probar y mediante tcnicas experimentales se trata de descubrirqu errores tiene.

Para determinar el nivel de calidad se deben efectuar unas medidas o pruebasque permitan comprobar el grado de cumplimiento respecto de lasespecificaciones iniciales del sistema.

Existen muchas definiciones de pruebas de software. A continuacin, se hacereferencia a la definicin citada por IEEE y SWEBOK.

Una prueba es una actividad en la que un sistema o un componente es

ejecutado bajo condiciones especificadas, los resultados son observados oregistrados, y una evaluacin es realizada de un aspecto del sistema ocomponente. [IEEE Std.610.12-1990]

Una prueba es una actividad ejecutada para evaluar y mejorar la calidad delproducto a travs de la identificacin de defectos y problemas. [SWEBOK]

Otros especialistas de pruebas manifiestan que las pruebas de software sonactividades claves para que los procesos de validacin y verificacin tenganxito, ya que ayudan a entregar el producto con la calidad suficiente parasatisfacer las necesidades del cliente y con la certeza de que el producto cumplelas especificaciones definidas. En este sentido, las pruebas pueden considerarsecomo un proceso que intenta proporcionar confianza en el software y cuyoobjetivo fundamental es demostrar al desarrollador y al cliente que el softwaresatisface sus requisitos.

Algo que los especialistas de pruebas deben considerar es que las pruebas desoftware nunca se deben realizar en un entorno de produccin. Es necesarioprobar los nuevos sistemas en un entorno de pruebas separado fsicamente delde produccin. Para crear un entorno de pruebas en una mquina independientede la mquina de produccin, es necesario crear las mismas condiciones queexiste en la de produccin.

Como parte del proceso de validacin y verificacin, se debera tomar decisionessobre quin debera ser responsable de las diferentes etapas de las pruebas.Dichas etapas de pruebas se integran dentro de las diferentes fases del ciclo delsoftware dentro de la Ingeniera de Software.

En la figura 1.1 se observa un modelo de cmo las etapas de pruebas seintegran en el ciclo de vida de desarrollo de software genrico. Durante la etapade planificacin es importante establecer una buena estrategia de pruebas yseleccionar las tcnicas adecuadas de estimacin en funcin de los factores queafecten a las pruebas del proyecto. La siguiente fase de desarrollo es el diseodel producto, que trae consigo el diseo de casos de prueba. Durante lassiguientes fases de codificacin y pruebas del producto, se ejecutan las pruebas


9/129



unitarias, de sistemas, de integracin, etc., de las que se explicar en apartadossiguientes.

Figura 1.1. Proceso de pruebas en el ciclo de vida de desarrollo de software

De lo anterior, el proceso de pruebas puede considerarse como un subproyectodentro del proyecto sobre el cual se estn ejecutando las pruebas, y como talrequiere la definicin de un plan a seguir. Cuando el proceso de pruebas existedentro del contexto del proyecto, debera prestarse atencin a la efectividad yeficiencia de las pruebas desde la perspectiva del proyecto y no desde laperspectiva del propio subproyecto de pruebas.

La eficiencia consiste en conseguir el efecto deseado de la manera correcta, esdecir, sin desaprovechamiento de recursos, ni de tiempo ni de dinero. Porconsiguiente, la eficiencia est relacionada con dos conceptos: productividad yausencia de prdidas. Para conseguir esta eficiencia deseada durante el procesode pruebas, se pueden considerar los siguientes aspectos:

- Evitar redundancias: Las redundancias traen consigo una prdida odesaprovechamiento de tiempo por lo que hay que intentar ejecutar laspruebas ms adecuadas a cada situacin y lo ms rpido posible. Esimportante encontrar los errores que ms impacto puedan tener sobre elproducto lo ms rpido posible. Aunque sea aconsejable no desaprovecharel tiempo, no hay que olvidarse de la planificacin, preparacin de las

pruebas, y de prestar atencin a todos los detalles. No abandonar lasestrategias previamente establecidas ante la primera seal de problemas oretrasos. Es decir, en un intento de ahorrar tiempo, se debe tener cuidadode no cometer errores que tendrn como consecuencias invertir mstiempo del que se intenta ahorrar.

- Reducir costes: Para reducir costes se debera prestar especial atencin ala adquisicin de elementos que puedan ayudar a la ejecucin de pruebas,del tipo de herramientas para la ejecucin de pruebas o entornos depruebas. Habra que cerciorarse de que realmente fueran necesarias y de


10/129

10


que existe el tiempo y las habilidades suficientes para emplearlas demanera ventajosa. Tambin, es aconsejable evaluar las herramientas antesde comprarlas y ser capaz de justificar estos gastos frente al anlisis decostos-beneficios.

Un posible flujo del proceso de pruebas, identificando distintas actividades yentregables se muestra en la figura 1.2.

Figura 1.2. Flujo del Proceso de pruebas

1.1.1. Validacin y Verificacin en el desarrollo de software

Los procesos de validacin y verificacin determinan si un productosoftware satisface las necesidades del negocio y si se est construyendoacorde a las especificaciones.

Con respecto a las tareas asociadas a estos procesos, las pruebas estnms relacionadas con el proceso de validacin, mientras que lasrevisiones son tareas ms orientadas al proceso de verificacin.

El objetivo principal de la validacin y verificacin es comprobar que elsistema est hecho para un propsito, es decir, que el sistema debe ser losuficientemente bueno para su uso previsto. El nivel de confianzarequerido depende de tres factores:

- El propsito o funcin del sistema. El nivel de confianza necesariodepende de lo crtico que sea el software para una organizacin.

- Las expectativas del usuario. Actualmente, es menos aceptable

entregar sistemas no fiables, por lo que las compaas deben invertirms esfuerzo en llevar a cabo las actividades de verificacin yvalidacin.

- Entorno de mercado actual. Cuando un sistema se comercializa, losvendedores del sistema deben tener en cuenta los sistemascompetidores, el precio que sus clientes estn dispuestos a pagar porel sistema y los plazos requeridos para entregar dicho sistema.Cuando una compaa tiene pocos competidores, puede decidir


11/129



entregar un programa antes de que haya sido completamenteprobado y depurado, debido a que quiere ser el primero en elmercado. Cuando los clientes no estn dispuestos a pagar preciosaltos por el software, pueden estar dispuestos a tolerar ms defectosen l.

Todos estos factores pueden considerarse a fin de decidir cuntoesfuerzo debera invertirse en el proceso de validacin y verificacin.

1.1.1.1. Validacin.

El propsito de la Validacin en CMMI es demostrar que unproducto o componente del mismo satisface el uso para el quese cre al situarlo sobre el entorno previsto.

Segn Boehm, la validacin responde la siguiente pregunta: Seest construyendo el producto correcto?

1.1.1.2. Verificacin.

El propsito de la Verificacin en CMMI es asegurar que losproductos seleccionados cumplen los requisitos especificados.

Para diferenciar esta tarea con la validacin, Boehm indica quedebe responderse a la siguiente pregunta: Se estconstruyendo el producto de la manera correcta?

1.1.2. Tipos de pruebas

La disciplina de pruebas es una de las ms costosas del ciclo de vidasoftware. En sentido estricto, deben realizarse las pruebas de todos losartefactos generados durante la construccin de un producto, lo queincluye especificaciones de requisitos, casos de uso, diagramas de

diversos tipos y, por supuesto, el cdigo fuente y el resto de productosque forman parte de la aplicacin (por ejemplo, la base de datos), einfraestructura. Obviamente, se aplican diferentes tcnicas de prueba acada tipo de producto software.

A continuacin, se describir los tipos de pruebas en funcin de quconocemos, segn el grado de automatizacin y en funcin de qu seprueba.

1.1.2.1. En funcin de qu conocemos.

a. Pruebas de caja negra

En este tipo de prueba, tan slo, podemos probar dando

distintos valores a las entradas. Los datos de prueba seescogern atendiendo a las especificaciones del problema,sin importar los detalles internos del programa, a fin deverificar que el programa corra bien.

Este tipo de prueba se centra en los requisitos funcionalesdel software y permite obtener entradas que prueben todoslos flujos de una funcionalidad (casos de uso).


12/129

12


Figura 1.3. Pruebas de caja negra

Con este tipo de pruebas se intenta encontrar:

- Funcionalidades incorrectas o ausentes.- Errores de interfaz.- Errores en estructuras de datos o en accesos a las

bases de datos externas.- Errores de rendimiento.- Errores de inicializacin y finalizacin.

b. Pruebas de caja blanca

Consiste en realizar pruebas para verificar que lneasespecficas de cdigo funcionan tal como esta definido.Tambin se le conoce como prueba de caja-transparente.La prueba de la caja blanca es un mtodo de diseo decasos de prueba que usa la estructura de control del diseoprocedimental para derivar los casos de prueba.

Figura 1.4. Pruebas de caja blanca

Las pruebas de caja blanca intentan garantizar que:

- Se ejecutan al menos una vez todos los caminosindependientes de cada mdulo

- Se utilizan las decisiones en su parte verdadera y ensu parte falsa

- Se ejecuten todos los bucles en sus lmites- Se utilizan todas las estructuras de datos internas.- Para esta prueba, se consideran tres importantes

puntos. Conocer el desarrollo interno del programa,

determinante en el anlisis de coherencia yconsistencia del cdigo.


13/129



Considerar las reglas predefinidas por cadaalgoritmo.

Comparar el desarrollo del programa en su cdigocon la documentacin pertinente.

1.1.2.2. Segn el grado de automatizacin

a. Pruebas manuales

Una prueba manual es una descripcin de los pasos deprueba que realiza un evaluador (usuario experto). Laspruebas manuales se utilizan en aquellas situaciones dondeotros tipos de prueba, como las pruebas unitarias o laspruebas Web, seran demasiado difciles de realizar o sucreacin y ejecucin sera demasiado laboriosa.

Tambin, podra utilizar una prueba manual en situacionesdonde no sea posible automatizar los pasos, por ejemplo,para averiguar el comportamiento de un componente cuandose pierde la conexin de red; esta prueba podra realizarsede forma manual, desenchufando el cable de red. Otro

ejemplo, sera en caso de comprobar cmo se visualiza elcontenido de una pgina web en dos navegadoresdiferentes.

Las pruebas manuales ayudarn a descubrir cualquierproblema relacionado con la funcionalidad de su producto,especialmente defectos relacionados con facilidad de uso yrequisitos de interfaces.

b. Pruebas automticas

A diferencia de las pruebas manuales, para este tipo depruebas, se usa un determinado software para

sistematizarlas y obtener los resultados de las mismas. Porejemplo, verificar un mtodo de ordenacin.

La suite de IBM Rationalnos provee varias herramientas quepermiten automatizar las pruebas de un sistema.

1.1.2.3. En funcin de qu se prueba

a. Pruebas unitarias

Se aplican a un componente del software. Podemosconsiderar como componente (elemento indivisible) a unafuncin, una clase, una librera, etc.

Estas pruebas las ejecuta el desarrollador, cada vez que vaprobando fragmentos de cdigo o scripts para ver si todofunciona como se desea. Estas pruebas son muy tcnicas.Por ejemplo, probar una consulta, probar que un fragmentode cdigo enve a imprimir un documento, probar que unafuncin devuelva un flag, etc.


14/129

14


Cdigo SoftwareEntradas

Diseo Detallado

Salidas Mdulo probado y listo para integrar

Roles Desarrollador

Tabla 1.1. E/S y roles en las pruebas unitarias

Para que una prueba unitaria, tenga xito se deben cumplirlos siguientes requisitos:

- Automatizable: no debera existir intervencin manual.Esto es, especialmente, til para la integracin continua.

- Completas: deben cubrir la mayor cantidad de cdigo.- Repetibles o Reutilizables: no se deben crear pruebas

que slo puedan ser ejecutadas una sola vez. Tambin,es til para integracin continua.

- Independientes: la ejecucin de una prueba no debeafectar a la ejecucin de otra.

- Profesionales: las pruebas deben ser consideradas igual

que el cdigo, con la misma profesionalidad,documentacin, etc.

El objetivo de las pruebas unitarias es aislar cada parte delprograma y mostrar que las partes individuales soncorrectas. Proporcionan un contrato escrito que el fragmentode cdigo debe satisfacer. Estas pruebas aisladasproporcionan cinco ventajas bsicas:

- Fomentan el cambio: Las pruebas unitarias facilitan queel programador cambie el cdigo para mejorar suestructura (lo que se llama refactorizacin), puesto quepermiten hacer pruebas sobre los cambios y asasegurarse de que los nuevos cambios no han

introducido errores.- Simplifica la integracin: Puesto que permiten llegar a la

fase de integracin con un grado alto de seguridad deque el cdigo est funcionando correctamente.

- Documenta el cdigo: Las propias pruebas sondocumentacin del cdigo puesto que ah se puede vercmo utilizarlo.

- Separacin de la interfaz y la implementacin: Dado quela nica interaccin entre los casos de prueba y lasunidades bajo prueba son las interfaces de estasltimas, se puede cambiar cualquiera de los dos sinafectar al otro.

- Los errores estn ms acotados y son ms fciles de

localizar: dado que tenemos pruebas unitarias quepueden desenmascararlos.

Es importante darse cuenta de que las pruebas unitarias nodescubrirn todos los errores del cdigo, pues solo pruebanlas unidades por s solas. Por lo tanto, no descubrirnerrores de integracin, problemas de rendimiento y otrosproblemas que afectan a todo el sistema en su conjunto. Laspruebas unitarias slo son efectivas si se usan en conjuntocon otras pruebas de software.


15/129



Figura 1.5. Flujo de control de pruebas unitarias

b. Pruebas de integracin

Consiste en construir el sistema a partir de los distintoscomponentes y probarlo con todos integrados. Estas pruebasdeben realizarse progresivamente. El foco de atencin es eldiseo y la construccin de la arquitectura de software.

Producto IntegradoEntradas

Plan de Pruebas de Integracin

Informe de Pruebas de IntegracinSalidas

Producto listo para su entrega a pruebas

Ingeniero de pruebasRoles

Jefe de desarrollo

Tabla 1.2. E/S y roles en las pruebas de integracin

Figura 1.6. Flujo de control de pruebas de integracin


16/129

16


c. Pruebas de aceptacin

Son las nicas pruebas que son realizadas por los usuariosexpertos, todas las anteriores las lleva a cabo el equipo dedesarrollo. Consiste en comprobar si el producto est listopara ser implantado para el uso operativo en el entorno delusuario. Podemos distinguir entre dos tipos de pruebas; en

ambas existe retroalimentacin por parte del usuario experto:- Pruebas alfa: las realiza el usuario en presencia de

personal de desarrollo del proyecto haciendo uso deuna mquina preparada para las pruebas.

- Pruebas beta: las realiza el usuario despus de que elequipo de desarrollo les entregue una versin casidefinitiva del producto.

Especificacin de Requisitos

Manuales de Usuario

Sistema probado

Entradas

Plan de Pruebas

Resultados de pruebasProducto aceptadoSalidas

Informe de Pruebas de Aceptacin

Ingeniero de pruebas

Jefe de pruebas

Roles

Jefe de proyecto

Tabla 1.3. E/S y roles en las pruebas de aceptacin

Figura 1.7. Flujo de control de pruebas de aceptacin


17/129



d. Pruebas funcionales

Este tipo de prueba se realiza sobre el sistema funcionando,comprobando que cumpla con la especificacin(normalmente a travs de los casos de uso). Para estaspruebas, se utilizan las especificaciones de casos de prueba.

e. Pruebas de rendimientoLas pruebas de rendimiento se basan en comprobar que elsistema puede soportar el volumen de carga definido en laespecificacin, es decir, hay que comprobar la eficiencia (porejemplo, se ha montado una pgina web sobre un servidor yhay que probar qu capacidad tiene el estado de aceptarpeticiones, es decir capacidad de concurrencia).

1.1.3. Diseo de casos de pruebas

Un caso de prueba es un conjunto de entradas, condiciones de ejecuciny resultados esperados, desarrollado para conseguir un objetivo particularo condicin de prueba como, por ejemplo, verificar el cumplimiento de unrequisito especfico. Para llevar a cabo un caso de prueba, es necesariodefinir las precondiciones y post condiciones, identificar unos valores deentrada, y conocer el comportamiento que debera tener el sistema antedichos valores. Tras realizar ese anlisis e introducir dichos datos en elsistema, se observar si su comportamiento es el previsto o no y por qu.De esta forma se determinar si el sistema ha pasado o no la prueba. Deah su importancia durante la ejecucin de pruebas.

A continuacin, se describir los pasos que se realizarn en el curso paradisear casos de pruebas.

1.1.3.1. Definir escenarios.

Consiste en identificar todos los escenarios (caminos) a probarde un caso de uso: f lujo bsico, sub flujos y flujos alternativos.

Para definir el mnimo nmero de escenarios (caminosindependientes) para un caso de uso se puede aplicar la tcnicade la complejidad ciclomtica. El clculo de la complejidadciclomtica (CC) consiste en obtener un valor a partir del grafodel caso de uso; este valor es conocido como V(G). Existen 3mtodos de clculo:

a. Segn aristas y nodos

V (G) = a - n+ 2, siendo ael nmero de arcos o aristas del

grafo y nel nmero de nodos.b. Segn reas cerradas

V (G) = r+ 1, siendo rel nmero de regiones cerradas delgrafo.

c. Segn nodos predicados

V(G) = c + 1, siendo c el nmero de nodos predicados(condicionados).


18/129

18


La experiencia en este campo asegura que:

- V(G) marca el lmite mnimo de casos de prueba para uncaso de uso

- Cuando V(G) > 10 la probabilidad de defectos crece mucho.

Ejemplo 1: Para el siguiente diagrama de grafo se calcula el

mnimo nmero de escenarios. Para ello, se aplica los 3 mtodosde clculo de la complejidad ciclomtica.

Caminos identificados

Camino 1: 1- 2 - 3 - 4 - 15Camino 2: 1- 2 - 3 - 5 6 14 - 15Camino 3: 1- 2 - 3 - 5 7 8 13 - 14 - 15Camino 4: 1- 2 - 3 - 5 7 9 10 - 12 13 14 - 15Camino 5: 1- 2 - 3 - 5 7 9 11 - 12 13 14 - 15

Clculo de la Complejidad Ciclomtica (CC)

a. V(G)= A N + 2V(G)= 18 15 + 2V(G)= 5

Donde: A = Aristas y N = Nodos

1

2

3

5 4

67

9 8

11 10

15

14

13

12

b. V(G) = 4 Regiones + 1V(G) = 5

c. V(G) = 4 Nodos Predicados + 1V(G) = 5


19/129



Ejemplo 2: Para el siguiente diagrama de grafo se calcula elmnimo nmero de escenarios. Para ello, se aplica los 3 mtodosde clculo de la complejidad ciclomtica.

Caminos identificadosCamino 1: 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 11 - 12

Camino 2: 1 - 2 - 3 - 4 - 5 - 6 - 7 - 7.1 - 9 - 10 - 11 - 12Camino 3: 1-2- 3-4- 5-6- 7-8 -9- 10-6 -7- 8-9- 10-1 1-1 2Camino 4: 1-2-3-4-5-6-7-8-9-10-11-12-5-6-7-8-9-10-11-12

Clculo de la Complejidad Ciclomtica (CC)a. V(G)= A N + 2

V(G)= 15 13 + 2V(G)= 4Donde: A = Aristas y N = Nodos

1

2

3

4

5

6

10

7

8

7.1

9

11

12


20/129

20


b. V(G) = 3 Regiones + 1V(G) = 4

c. V(G) = 3 Nodos Predicados + 1V(G) = 4

Tal como se especific en este apartado, con la tcnica de la CCse define el mnimo nmero de escenarios para un caso de uso.En algunos casos, se pueden identifican ms escenarioscombinando escenarios simples con flujos alternativos anidados.

Por ejemplo: Sea el siguiente diagrama de grafo de un caso deuso.

2.1

2.2

7.1

1

2

3

5

4

6

7

9

8

10


21/129



Si solo consideramos el nmero de caminos independientes queexisten en el grafo, segn el clculo de la CC, el caso de usotendra 3 escenarios:

Tabla 1.4. Escenarios independientes

Considerando flujos alternativos anidados se tendra 4escenarios:

Tabla 1.5. Escenarios con flujos anidados

1.1.3.2. Identificar condiciones de entrada.

Las condiciones de entrada son parte del dominio de valores deentrada. Se pueden identificar condiciones de entrada conestados vlidos (V) y no vlidas (NV); asimismo se considerancondiciones 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

- Lgico

- Valor

- Rango

Veamos un ejemplo. Considrese una aplicacin bancaria,donde el usuario puede conectarse al banco por Internet yrealizar una serie de operaciones bancarias. Una vez accedido albanco con las siguientes medidas de seguridad (clave de accesoy dems), la informacin de entrada del procedimiento quegestiona las operaciones concretas a realizar por el usuariorequiere las siguientes entradas:

- Cdigo de banco. En blanco o nmero de tresdgitos. En este ltimo caso, el primer

dgito tiene que ser mayor que 1.

- Cdigo de sucursal. Un nmero de cuatrodgitos. El primero de ellos mayor de 0.

Escenarios Flujo inicial Alternativo Secuencia de eventos

1 Bsico 1 al 10

2 Bsico FA1, Bsico 1,2,2.1,2.2,4 al 10

3 Bsico FA2, Bsico 1,2,3,4,5,6,7,7.1,10

Escenarios Flujo inicial Alternativo Secuencia de eventos

1 Bsico 1 al 10

2 Bsico FA1, Bsico 1,2,2.1,2.2,4 al 103 Bsico FA2, Bsico 1,2,3,4,5,6,7,7.1,10

4 Bsico FA1, Bsico, FA2 1,2,2.1,2.2,4,5,6,7,7.1,10


22/129

22


- Nmero de cuenta. Nmero de cinco dgitos.

- Clave personal. Valor alfanumrico de cincoposiciones.

- Orden. Este valor se seleccionar de unalista desplegable, segn 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.

A continuacin, se muestra una tabla con estados de lascondiciones de entrada por cada resultado esperado.

NOTA: La generacin de casos de prueba se completar,despus de identificar las clases de equivalencia:

CONDICIONES DE ENTRADAID CP Escenario Cdigo

de bancoCdigo desucursal

Nmerode cuenta

Clavepersonal

OrdenResultado esperado

CP1 Escenario 1 V V V V VMensaje "Envo de

talonarios"


movimientos "


talonarios ymovimientos"

CP4 Escenario 2 NV V V V VMensaje Cdigo de

banco incorrecto

CP5 Escenario 3 V NV V V VMensaje Cdigo de

sucursal incorrectoCP6 Escenario 4 V V NV V V

Mensaje Nmero decuenta incorrecto

CP7 Escenario 5 V V V NV VMensaje Clave

incorrecta

Tabla 1.6. Condiciones de entrada

1.1.3.3. Definir clases de equivalencia.

Pueden usarse varias tcnicas para identificar los valores de losdatos de entrada, la tcnica de particiones o clases deequivalencias es una de ellas.

Las clases de equivalencia se identifican examinando cada

condicin de entrada (normalmente una frase en laespecificacin) y dividindola en dos o ms grupos. Se definendos tipos de clases de equivalencia:

- Clases Vlidas: Entradas vlidas al programa.

- Clases no Vlidas: Valores de entrada errneos.

Estas clases se pueden representar en una tabla. Acontinuacin, se muestra las clases de equivalencia para el casode gestin bancaria anterior:


23/129


Tabla 1.7. Clases de equivalencia

1.1.3.4. Realizar casos de prueba.

En esta ltima etapa, se generan los casos de pruebas. Para ello, se considera como rede entrada, indicando en cada caso de prueba las clases de equivalencia creadas. Por etendra lo siguiente:

Clases Vlidas CSec.

Condicin deEntrada

TipoEntrada Cdigo En

Lgico (puedeestar o no)

En blanco CEV Un valor no num

Cdigo de banco 1 Cdigo de banco Si est, esRango

200


24/129

24


CONDICIONES DE ENTRADA

ID CP Clases de equivalencia Cdigo de

banco

Cdigo de

sucursal

Nmero de

cuenta Clave personal Orden

CP1CEV, CEV, CEV,CEV, CEV

200 1000 10000 Aaaaa Talonar


820 9999 99999 Zzzzz Movimien


999 1001 12345 A1b2cSeleccio

Orden

CP4CENV, CEV, CEV,CEV, CEV

30A 1989 12345 1a2b3Seleccio

Orden


210 999 12345 1a2b3Seleccio

Orden


210 1989 123 1a2b3Seleccio

Orden

CP7CENV, CEV, CEV,CEV, CEV 210 1989 12345

SeleccioOrden

Tabla 1.8. Casos de prueba

Complete la generacin de casos de prueba. Para ello considere las clases de equivalencia.

CONDICIONES DE ENTRADA

ID CP Clases de equivalencia Cdigo debanco

Cdigo desucursal

Nmero decuenta

Clave personal Orden


25/129


1.2. ADMINISTRACIN DE PRUEBASSin importar la metodologa utilizada por un equipo de desarrollo, las pruebasrealizadas sobre el producto, ya sean unitarias, de integracin o de sistema,reflejan si los objetivos planteados a nivel de requerimientos son satisfechos porel producto desarrollado. Este proceso, tpicamente involucra el diseo eimplementacin de las pruebas, su ejecucin, el reporte de los defectos

encontrados, la planeacin de las correcciones y la implementacin de dichascorrecciones. Estos pasos no siempre estn formalmente definidos y en muchasocasiones se encuentran en las cabezas de los miembros del equipo de trabajoquienes deciden en un momento dado cmo manejar la informacin asociada alas pruebas y qu pasos seguir durante este proceso.

Por otro lado, los responsables del proceso de pruebas deben consideraroptimizar las pruebas. Para ello, es necesaria la definicin de una buenaestrategia, es decir, definir una serie de principios e ideas que puedan ayudar aguiar las actividades de pruebas.

1.2.1. Estrategia de pruebas

Existen distintas estrategias de pruebas, y dependiendo de sualineamiento con el objetivo de las pruebas y con los propios proyectos,estas estrategias pueden tener xito o fallar. Otro punto a tener en cuentaes que no tiene por qu elegirse una sola estrategia. Puede utilizarse unaestrategia de manera dominante y utilizar otras de complemento.

Algunos autores como Krutchen, Pressman, Pfleger, Cardoso ySommerville afirman que el proceso de ejecucin de pruebas debe serconsiderado durante todo el ciclo de vida de un proyecto, para as obtenerun producto de alta calidad. Su xito depender del seguimiento de unaEstrategia de Prueba adecuada.

Los tipos de estrategia de pruebas ms importantes se describen a

continuacin:

Figura 1.8. Resumen de estrategias de prueba

Automatizacin


26/129

26


1.2.1.1. Estrategia analtica.

Las estrategias de pruebas analticas tienen en comn el uso dealguna tcnica analtica formal o informal normalmente durantela etapa de gestin de requisitos y de diseo del proyecto.Por ejemplo:

a) Estrategia orientada a objetos. Para determinar el enfoquede las pruebas, se presta atencin a los requisitos, el diseo,y la implementacin de objetos. Estos objetos pueden incluirespecificaciones de requisitos, especificaciones de diseo,diagramas UML, casos de uso, cdigo fuente, esquemas debase de datos y diagramas entidad-relacin. Este enfoque sebasa en una buena documentacin, por lo que la ausenciade la misma implica no poder utilizarla.

b) Estrategia basada en riesgos. Consiste en identificar riesgosestudiando el sistema, documentacin de proyectosanteriores, objetivos de la configuracin y cualquier otro datoque pueda encontrarse o que pueda aportar la gente

involucrada en el proyecto. El diseo, desarrollo y ejecucinde pruebas basadas en el conocimiento previo puede serbeneficioso. Este enfoque es apropiado si se dispone detiempo para investigar el sistema.

Los elementos que estn siendo analizados a menudo sedenominan base de las pruebas. Los resultados del anlisisguan el esfuerzo de pruebas, a menudo a travs de algunasformas de anlisis de cobertura durante el diseo, desarrollo dela ejecucin y obtencin de resultados de las pruebas. Estasestrategias tienden a ser minuciosas y buenas a la hora demitigar riesgos de calidad y encontrar errores. Sin embargo, serequiere una inversin de tiempo importante.

1.2.1.2. Estrategia basada en modelo

Las estrategias de pruebas basadas en modelo desarrollanmodelos que representan cmo el sistema debera comportarseo trabajar. Las estrategias de pruebas basadas en modelo tienenen comn la creacin o seleccin de algn modelo formal oinformal para simular comportamientos de sistemas crticos,normalmente durante las etapas de requisitos y diseo delproyecto. Existen distintos tipos de estrategias basadas enmodelos:

a) Con una estrategia basada en escenario se realizan

pruebas acorde a escenarios del mundo real. Estosescenarios deberan abarcar la funcionalidad del sistema.En el mundo orientado a objetos, se podra usar unaestrategia basada en casos de uso, donde se confe endocumentos de diseo orientados a objetos conocidos comocasos de uso. Estos casos de uso son modelos de cmo elusuario, clientes y otras partes involucradas en el negocioutilizan el sistema y cmo debera trabajar bajo estascondiciones.


27/129



b) Con una estrategia basada en el dominio se puedenanalizar diferentes dominios de datos de entrada aceptadospor el sistema, procesamiento de datos del sistema, y datosde salida entregados por el sistema. Se decidir cul ser elmejor caso de pruebas para cada dominio, se determinar laprobabilidad de errores, frecuencia de uso y entornosdesplegados.

c) Con una estrategia basada en un modelo, se disean,desarrollan y ejecutan las pruebas que cubran los modelosque se hayan construido. Esta estrategia ser tildependiendo de la capacidad del modelo para capturar losaspectos esenciales o potencialmente problemticos delsistema.

1.2.1.3. Estrategia metdica

La estrategia metdica tiende a seguir una lnea relativamenteinformal pero con un enfoque ordenado y predecible que ayuda acomprender dnde probar.

a) Estrategia basada en el aprendizaje. Se utilizan listas decontrol que se han desarrollado para guiar el proceso depruebas. Para desarrollar estas listas de control puede serde ayuda el basarse en los errores que se han encontradopreviamente, en lecciones aprendidas de otros proyectos yen cualquier otra fuente.

b) Estrategia basada en funciones. Se identifica y se pruebacada funcin del sistema por separado. Lo mismo ocurrecon la estrategia basada en estados, donde se identifica yprueba cada estado y cada posible transicin de estadosque pueda ocurrir.

c) Estrategia basada en la calidad: Se utiliza una jerarquade calidad, como la que ofrece la ISO 9126, para identificary probar la importancia de cada una de las caractersticasde la jerarqua como, por ejemplo, la facilidad de uso, elrendimiento, la funcionalidad o la escalabilidad.

Con una estrategia de pruebas metdica, se siguen estosestndares como objetivos de pruebas. Estas estrategiaspueden ser rpidas y efectivas en contra de sistemas quepermanecen relativamente estables, o sistemas que sonsimilares a otros ya probados. Los cambios significativos puedenfrenar temporalmente estas estrategias hasta que se puedan

volver a ajustar los objetivos de las pruebas a la nueva situacindel sistema.

1.2.1.4. Estrategia orienta al proceso o estndar conformista

Las estrategias de pruebas orientadas al proceso llevan elenfoque metdico un paso ms all a la hora de regular elproceso de pruebas. Estas estrategias siguen un desarrolloexterno orientado a pruebas a menudo con pocas posibilidadesde personalizacin. Un ejemplo de este tipo de estrategias es la


28/129

28


estrategia de pruebas estandarizada, se sigue un estndaroficial y reconocido, por ejemplo el estndar IEEE 829 orientadoa la documentacin de las pruebas. Este estndar, por ejemplo,es utilizado en algunas organizaciones para asegurar laregularidad y completitud de todos los documentos de pruebas.Esta estandarizacin puede ayudar a hacer que el proceso depruebas sea ms transparente y comprensible para losprogramadores, responsables, analista de negocio y otraspersonas ajenas a las pruebas.

1.2.1.5. Estrategia dinmica

Las estrategias de pruebas dinmicas, como las estrategias depruebas giles, minimizan la planificacin por adelantado yprueban el diseo. Adaptan todo lo posible el sistema bajoprueba a las condiciones que habr cuando se libere.Tpicamente, enfatizan las ltimas etapas de pruebas. Se tratade crear un pequeo conjunto de pautas de pruebas que seenfoquen en debilidades conocidas del software.

a) Con una estrategia de pruebas intuitiva, se puede probaracorde a la experiencia e instinto del equipo de pruebas.

b) Con una estrategia de pruebas exploratoria, se puedeaprender simultneamente sobre el comportamiento ydiseo de pruebas, a la vez que las pruebas se vanejecutando y se van encontrando errores. Se ir refinando elenfoque de las pruebas en funcin de los resultadosobtenidos de las pruebas.

Las estrategias de pruebas dinmicas valoran la flexibilidad y lafacilidad de encontrar errores. Estas estrategias no producenbuena informacin normalmente acerca de cobertura, mitigacin

sistemtica de riesgos ni ofrecen la oportunidad de detectardefectos en las primeras fases del ciclo de vida del producto.

Obviamente, aplicar estas estrategias es mejor que no realizarningn tipo de pruebas y, cuando van unidas a estrategiasanalticas, pueden servir como una excelente herramienta paraidentificar el vaco dejado por las mismas.

1.2.1.6. Estrategia de pruebas filosfica

Las estrategias de pruebas filosficas comienzan con unafilosofa o creencia de las pruebas.

a) Cuando se usa una estrategia de pruebas exhaustiva, seasume que todo puede tener errores. Es decir, se decide quela posibilidad de que haya fallos latentes es inaceptable porlo que se soportar un considerable esfuerzo al encontrartodos los errores.

b) Con la estrategia de pruebas shotgun, se asume que todoy nada puede tener y tendr errores. Sin embargo, en estecaso, se acepta que no se puede probar todo. Cuando sellegue al punto de no tener una idea slida acerca de por


29/129



dnde empezar a probar, se intentar distribuir de maneraaleatoria el esfuerzo de pruebas teniendo en cuenta lasrestricciones de recursos y la agenda.

c) Con una estrategia guiada externamente, no slo seacepta que no se puede probar todo, sino que tambin seasume que no se sabe donde estn los errores. Sinembargo, se confa en que otras personas puedan tener unabuena idea sobre donde estn. Para ello, se pedir ayuda aestas personas sobre la decisin a tomar acerca de si losresultados obtenidos son o no correctos.

Por ejemplo, se puede preguntar a los usuarios, personasque den soporte tcnico, analistas de negocio odesarrolladores del sistema sobre qu probar o inclusoconfiar en ellos para hacer las pruebas. Enfatizan las ltimasetapas de pruebas simplemente debido a la falta dereconocimiento del valor de pruebas tempranas.

1.2.1.7. Regresin

La regresin es la mala conducta de una funcin, atributo ocaracterstica previamente correctos. La palabra regresintambin se suele usar para definir el descubrimiento de un errorque previamente no se encontr durante la ejecucin de unaprueba. La regresin normalmente est asociada a algn cambioen el sistema, como aadir una caracterstica o arreglar un error.

La regresin puede ser de tres tipos:

a) Regresin local: al producirse un cambio o arreglarse unerror se crea un nuevo error.

b) Regresin de exposicin: al producirse un cambio oarreglarse un error se identifican errores ya existentes.

c) Regresin remota: un cambio o el arreglo de un error en undeterminado rea produce un fallo en otro rea del sistema.La regresin remota es la regresin ms difcil de detectar,ya que los usuarios, clientes y el resto de los interesados enel proyecto tienden a confiar en las caractersticas yaexistentes del sistema. Por ello, los tcnicos de pruebasdeberan tener estrategias que sean efectivas en contra detodas las causas y efectos de las regresiones.

Una posible estrategia para enfrentarse a la regresin, quizs el

enfoque ms simple, es la fuerza bruta. Para la mitigacin delriesgo de regresin, la estrategia de la fuerza bruta consiste enrepetir todas las pruebas. Imaginemos que se ha desarrollado unconjunto de pruebas bien alineadas con la calidad. En este caso,se habr desarrollado un anlisis de riesgos de calidad slido yse tendr tiempo y recursos suficientes para cubrir todos losriesgos crticos de calidad. Si se repiten todas las pruebasdespus del ltimo cambio realizado, se deberan encontrartodos los errores de regresin importantes.


30/129

30


d) La automatizacin. Se puede considerar la automatizacincomo una estrategia para aumentar la calidad de unproducto a un bajo coste y optimizar el esfuerzo de laspruebas.

La automatizacin es la nica manera de repetir todas laspruebas sobre sistemas complejos y grandes. Laautomatizacin es prctica cuando los costes del diseo eimplementacin de pruebas automatizadas seanrecuperables, y se vayan a ejecutar de manera frecuente.

A pesar de su gran utilidad, en ocasiones, la inversin extraque supone para el proyecto y la necesidad de ciertashabilidades por parte de miembros de la organizacin hacenque la automatizacin sea un proceso costoso. Sin embargo,algunas de sus ventajas son:

- La automatizacin puede reducir drsticamente elesfuerzo de las pruebas de regresin.

- La automatizacin permite realizar validaciones durante

los ciclos de cambios, cosa que sera imposible hacermanualmente debido a restricciones de tiempo.- La automatizacin habilita la consistencia y cobertura

lgica. No hay riesgo alguno de excluir casos de prueba opasar por alto errores si se disea correctamente.

Esta estrategia suele envolver pruebas funcionalesautomatizadas antes de la liberacin del producto, peroalgunas veces, se centra por completo en funcionesliberadas con anterioridad. Por ejemplo, se puede intentarautomatizar todas las pruebas de sistemas de tal forma quecuando se produzca cualquier cambio se pueda volver aejecutar cada prueba para asegurarse de que ningn rea se

ha visto afectada. Pero, incluso con una automatizacinefectiva, no siempre es posible repetir todas las pruebas yaque no resulta prctico o su gestin es insostenible. Por ello,en ocasiones se necesitar realizar una seleccin sobre elconjunto de pruebas a automatizar.

1.2.2. Roles y Responsabilidades

En RUP se definen los siguientes roles:

- Administrador de pruebas- Analista de pruebas- Diseador de pruebas- Ejecutor de pruebas

1.2.2.1. Administrador de pruebas

Es el responsable del xito total de la prueba. Involucra calidad yaprobacin de la prueba, recurso de planeacin, direccin, ysolucin a de los problemas que impiden el xito de la prueba.

El Administrador de pruebas es responsable de los siguientesartefactos: Plan de Pruebas, Resumen de Resultado dePruebas, Lista de Problemas y Cambios de Requerimientos.


31/129



Figura 1.9. El rol de Administrador de pruebas

- El Plan de Pruebas, contiene la definicin de las metas yobjetivos a probar dentro del alcance de cada iteracin delproyecto. Proporciona el marco de trabajo en el que elequipo llevar a cabo la prueba dentro de el horariocoordinado.

- El Resumen de Resultados de Pruebas, organiza ypresenta un anlisis resumen de los resultados de laspruebas y las medidas clave para revisar y definir estas,tpicamente por los Stakeholders claves. Adems, puedecontener una declaracin general de calidad relativa, puedemantener las recomendaciones de las pruebas que serealizaran a futuro.

- La Lista de los Problemas, proporciona una manera deregistrar para el Administrador del Proyecto los: problemas,excepciones, anomalas, u otras tareas incompletas querequieren atencin que relaciona a la direccin del proyecto.

- Cambios de Requerimientos. Se proponen cambios a losartefactos de desarrollo a travs de Cambios derequerimientos (CR). Se usan los Cambios deRequerimientos para documentar los problemas, lasmejoras solicitadas y cualquier otro tipo de solicitud para uncambio en el producto. El beneficio de CR es queproporcionan un registro de decisiones, debido a su procesode valoracin, asegura los impactos del cambio que puedandarse en el proyecto.

1.2.2.2. Analista de pruebas

Es el responsable de identificar y definir las pruebas requeridas,mientras supervisa el progreso de la comprobacin detallada yresultado por cada ciclo de realizacin de las pruebas.

Figura 1.10. El rol de Analista de pruebas


32/129

32


El Analista de pruebas es responsable de los siguientesartefactos: Casos de Pruebas, Modelo de Anlisis de Carga deTrabajo, Datos de Prueba, Resultados de Pruebas.

- Casos de Prueba. El propsito de estos artefactos esespecificar y comunicar las condiciones especficas quenecesitan ser validadas para permitir una definicin dealgunos aspectos particulares de los tems de pruebaobjetivo.

- El Modelo de Anlisis de la carga de Trabajo, trata dedefinir acertadamente las condiciones de carga bajo loscuales, los tems de prueba objetivo deben operar en suentorno de configuracin del sistema.

- Datos de Prueba, es la definicin (usualmente formal) deuna coleccin de valores de entrada de prueba que sonconsumidos durante la ejecucin de una prueba

- Resultados de Pruebas, es una coleccin de informacinsumaria determinada del anlisis de unas o ms peticionesde los registros y del cambio de la prueba. Referido a vecescomo un depsito ms grande de muchos resultados de laprueba.

1.2.2.3. Diseador de pruebas

Es el responsable de definir la estrategia de pruebas y deasegurar su puesta en prctica acertadamente. El rol implicaidentificar tcnicas, herramientas y pautas apropiadas paraponer en ejecucin las pruebas requeridas, y dotar de losrecursos necesarios para conducir los requisitos de la prueba.

Figura 1.11. El rol de Diseador de pruebas

El Diseador de pruebas es responsable de los siguientesartefactos: Plan de Estrategia, Arquitectura de Automatizacin,Configuracin del Entorno de Pruebas, Suite de Pruebas.

- El Plan de Estrategia, define el plan estratgico de como el

esfuerzo de la prueba ser conducido contra uno o msaspectos del sistema. Una estrategia de prueba necesitapoder convencer a la gestin y a otros Stakeholders que elacercamiento es alcanzable.

- Arquitectura de automatizacin, es til cuando laejecucin automatizada de las pruebas del software se debemantener y ampliar durante ciclos mltiples de prueba.Proporciona una descripcin arquitectnica comprensibledel sistema de automatizacin de las pruebas, usando un


33/129



nmero de diversas visiones arquitectnicas pararepresentar diversos aspectos del sistema.

- Configuracin del entorno de pruebas, es laespecificacin para un arreglo de hardware, software, yajustes asociados al entorno que se requieran para permitirlas pruebas exactas a ser conducidas que evaluarn uno oms tems de la prueba objetivo.

- Suite de Pruebas, es un tipo de paquete que agrupa lascolecciones de pruebas, para ordenar la ejecucin de esaspruebas y para proporcionar un sistema til y relacionado deinformacin del registro de prueba del cual los resultados deprueba pueden ser determinados.

1.2.2.4. Ejecutor de pruebas

Es el responsable de todas las actividades de las pruebas. El rolimplica verificar y ejecutar pruebas, y analizar y recoger lasejecuciones de errores.

Figura 1.12. El rol del Ejecutor de pruebas

El Ejecutor de pruebas es responsable de los siguientesartefactos: Registro de Pruebas, Script de Pruebas.

- El registro de las pruebas (Test Log), es una coleccin de

salidas capturadas durante la ejecucin de una o mspruebas, usualmente representa la salida resultante de laejecucin de un conjunto de pruebas para un ciclo depruebas.

- Scripts de prueba (Test Script), son instrucciones paso apaso de cmo realizar una prueba, permitiendo su ejecucinde una manera efectiva y eficiente.

1.2.3. Tcnicas de pruebas

Existen distintas tcnicas de pruebas de software, con sus debilidades ysus puntos fuertes. Cada una de ellas es buena para encontrar un tipoespecfico de defectos. Las pruebas realizadas en distintas etapas del

ciclo de desarrollo del software encontrarn diferentes tipos de defectos.Las pruebas dinmicas slo se aplican sobre el cdigo del producto paradetectar defectos y determinar atributos de calidad del software, por lo queestaran ms orientadas al rea de validacin. Por otra parte, las tcnicasde pruebas estticas son tiles para evaluar o analizar documentos derequisitos, documentacin de diseo, planes de prueba, o manuales deusuario, e incluso para examinar el cdigo fuente antes de ejecutarlo. Eneste sentido, ayudan ms a la implementacin del proceso de verificacin.


34/129

34


Las pruebas estticas y las pruebas dinmicas son mtodoscomplementarios ya que ambas tratan de detectar distintos tipos dedefectos de forma efectiva y eficiente, aunque las pruebas estticas estnorientadas a encontrar defectos mientras que las dinmicas fallos.

1.2.3.1. Tcnicas de pruebas dinmicas

Las tcnicas de pruebas dinmicas ejecutan el software. Paraello introducen una serie de valores de entrada, y examinan lasalida comparndola con los resultados esperados.

Figura 1.13. Clasificacin de tcnicas dinmicas

a) Basadas en la especificacin

Son conocidas como tcnicas de pruebas de caja negra oconducidas por entradas/salidas, porque tratan el softwarecomo una caja negra con entradas y salidas, pero no tienenconocimiento de cmo est estructurado el programa ocomponente dentro de la caja. Esencialmente, el tcnico depruebas se concentra en qu hace el software y no en cmolo hace. Las tcnicas basadas en especificaciones obtienenlos casos de prueba directamente de las especificaciones o

de otros tipos de artefactos que contengan lo que el sistemadebera hacer.

A continuacin, se detallarn las tcnicas basadas en laespecificacin ms comunes.

- Particionamiento de equivalenciaEsta tcnica consiste en dividir un conjunto decondiciones de prueba en grupos o conjuntos quepuedan ser considerados iguales por el sistema. Esta


35/129



tcnica requiere probar slo una condicin para cadaparticin. Esto es as porque se asume que todas lascondiciones de una particin sern tratadas de la mismamanera por el software. Si una condicin en unaparticin funciona, se asume que todas las condicionesen esa particin funcionarn. De la misma forma, si unade las condiciones en una particin no funciona,entonces se asume que ninguna de las condiciones enesta particin en concreto funcionar. Si existe tiemposuficiente, se debera probar ms de un valor para unaparticin, especialmente si se quiere confirmar unaseleccin tpica de entradas de usuario.

- Anlisis de valor fronteraLos errores generados por los programadores tienden aagruparse alrededor de las fronteras. Por ejemplo, si unprograma debera aceptar una secuencia de nmerosentre 1 y 10, el error ms probable ser que los valoresjusto fuera del rango sean aceptados de formaincorrecta o que los valores justo en los lmites del rangosean rechazados. El anlisis del valor frontera estbasado en probar los valores frontera de las particiones.Al hacer comprobaciones de rango, probablemente seest usando de forma inconsciente el anlisis del valorfrontera. En esta tcnica, tambin, se cuenta confronteras vlidas (en las particiones vlidas) y fronterasno vlidas (en las particiones no vlidas).

- Tablas de decisinLas tcnicas de particionamiento de equivalencia yanlisis del valor frontera son aplicadas con frecuencia asituaciones o entradas especficas. Sin embargo, si

diferentes combinaciones de entradas dan comoresultado diferentes acciones, resulta ms difcil usar lastcnicas anteriores.

Las especificaciones suelen contener reglas de negociopara definir las funciones del sistema y las condicionesbajo las que cada funcin opera. Las decisionesindividuales son normalmente simples, pero el efectoglobal de las condiciones lgicas puede ser muycomplejo. Los tcnicos de pruebas necesitan sercapaces de asegurarse que todas las combinaciones delas condiciones que puedan ocurrir han de serprobadas, por lo tanto, hay que capturar todas las

decisiones de una forma que permita explorar suscombinaciones. El mecanismo usado con frecuenciapara capturar las decisiones lgicas es la tabla dedecisin.

Una tabla de decisin lista todas las condiciones deentrada que pueden ocurrir y todas las acciones quepueden surgir de ellas. Estn estructuradas por filas,con las condiciones en la parte de arriba de la tabla y lasposibles acciones en la parte de abajo. Las reglas de


36/129

36


negocio, que incluyen combinaciones de condicionespara producir algunas combinaciones de acciones, seincluyen en la parte de arriba de un extremo a otro.Cada columna, por lo tanto, representa una regla denegocio individual y muestra cmo se combinan lascondiciones de entrada para producir acciones. De estamanera, cada columna representa un posible caso deprueba, ya que identifica ambas entradas y salidas.

- Transicin de estadosLa tcnica anterior (tabla de decisin) es particularmentetil cuando las combinaciones de condiciones deentrada producen varias acciones. La tcnica detransicin de estados se utiliza con sistemas en los quelas salidas son desencadenadas por cambios en lascondiciones de entrada, o cambios de estado.

Las pruebas de transicin de estados se usan cuandoalguno de los aspectos del sistema se pueden describiren lo que se denomina una mquina de estados finitos.Esto significa que el sistema puede estar en un nmero(finito) de estados, y las transiciones de un estado a otroestn determinadas por las reglas de la mquina. Estees el modelo en el que se basan el sistema y laspruebas. Cualquier sistema en el que se puedanconseguir diferentes salidas con la misma entrada,dependiendo de lo que haya pasado antes, es unsistema de estados finitos. Un sistema de estados finitosse suele representar mediante un diagrama de estados.

- Pruebas de casos de UsoLas pruebas de caso de uso son una tcnica que ayuda

a identificar casos de prueba que ejerciten el sistemaentero transicin a transicin desde el principio al final.

Un caso de uso es una descripcin de un uso particulardel sistema por un actor (un usuario del sistema). Cadacaso de uso describe las interacciones que el actor tienecon el sistema para conseguir una tarea concreta (o, almenos, producir algo de valor al usuario). Los actoresson generalmente gente pero pueden ser tambin otrossistemas. Resumidamente, los casos de uso son unasecuencia de pasos que describen las interaccionesentre el actor y el sistema.

Los casos de uso estn definidos en trminos del actor,no del sistema, describiendo qu hace y ve el actor, msque qu entradas o salidas espera el sistema. De formamuy frecuente, usan el lenguaje y trminos de negocioms que trminos tcnicos, especialmente cuando elactor es un usuario de negocio. Sirven comofundamento para desarrollar casos de prueba, en sumayora, en los niveles de pruebas de sistema ypruebas de aceptacin.


37/129



Los casos de uso pueden descubrir defectos deintegracin, defectos causados por la interaccinincorrecta entre diferentes componentes.

Los casos de uso describen el flujo de proceso a travsde un sistema basado en su uso ms probable. Estohace que los casos de prueba obtenidos de los casos deuso sean particularmente tiles a la hora de encontrardefectos en el uso real del sistema (p.ej. los defectosque los usuarios son ms propensos a hacer la primeravez que usan el sistema). Cada caso de uso tiene unescenario dominante (o ms probable) y algunas ramasalternativas (cubriendo, por ejemplo, casos especiales ocondiciones excepcionales). Cada caso de uso debeespecificar cualquier precondicin que tenga resultadosobservables y una descripcin del estado final delsistema despus de que el caso de uso haya sidoejecutado de forma exitosa.

b) Basadas en la estructura

Las pruebas estructurales son una aproximacin al diseode casos de prueba donde las pruebas se derivan a partirdel conocimiento de la estructura e implementacin delsoftware. Esta aproximacin se denomina a veces pruebasde caja blanca.

La comprensin del algoritmo utilizado en un componentepuede ayudar a identificar particiones adicionales y casosde prueba, asegurando as un mayor rango de pruebas. Lastcnicas ms sofisticadas proporcionan, de formaincremental, una cobertura de cdigo completa. A

continuacin, se detallarn las tcnicas basadas en laestructura ms comunes.

- Pruebas de sentenciaEl objetivo de las pruebas de sentencia es ir probandolas distintas sentencias a lo largo del cdigo. Si seprueban todas y cada una de las sentencias ejecutablesdel cdigo, habr una cobertura de sentencia total. Esimportante recordar que estas pruebas slo se centranen sentencias ejecutables a la hora de medir lacobertura. Es muy til el uso de grficos de flujo dedatos para identificar este tipo de sentencias, que serepresentan mediante rectngulos.

Generalmente, la cobertura de las sentencias esdemasiado dbil para ser considerada una medidaadecuada para probar la efectividad.

- Pruebas de decisinEl objetivo de estas pruebas es asegurar que lasdecisiones en un programa son realizadasadecuadamente. Las decisiones son parte de las


38/129

38


estructuras de seleccin e iteracin, por ejemplo,aparecen en construcciones tales como: IF THEN ELSE,o DO WHILE, o REPEAT UNTIL. Para probar unadecisin, es necesario ejecutarla cuando la condicinque tiene asociada es verdadera y tambin cuando esfalsa. De esta forma, se garantiza que todas las posiblessalidas de la decisin se han probado.

Al igual que las pruebas de sentencias, las pruebas dedecisin tienen una medida de cobertura asociada eintentan conseguir el 100% de la cobertura de decisin.

- Pruebas de caminosLas pruebas de caminos son una estrategia de pruebasestructurales cuyo objetivo es probar cada camino de laejecucin independientemente. En todas las sentenciascondicionales, se comprueban los casos verdadero yfalso. En un proceso de desarrollo orientado a objetos,pueden utilizarse las pruebas de caminos cuando seprueban los mtodos asociados a los objetos.

Las pruebas de caminos no prueban todas las posiblescombinaciones de todos los caminos en el programa.Para cualquier componente distinto de un componentetrivial sin bucles, este es un objetivo imposible. Existe unnmero infinito de posibles combinaciones de caminosen los programas con bucles. Incluso cuando todas lassentencias del programa se han ejecutado al menos unavez, los defectos del programa todava pueden aparecercuando se combinan determinados caminos.

c) Basadas en la experiencia

Las tcnicas basadas en experiencia son aquellas a las quese recurre cuando no hay una especificacin adecuadadesde la que crear casos de prueba basados enespecificacin, ni hay tiempo suficiente para ejecutar laestructura completa del paquete de pruebas.

- Adivinar erroresLas tcnicas basadas en experiencia usan laexperiencia de los usuarios y de los tcnicos de pruebaspara determinar las reas ms importantes de unsistema y ejercitar dichas reas de forma que seanconsistentes con el uso que se espera que tengan.

- Pruebas exploratoriasTcnicas de pruebas ms sofisticadas que se realizansobre la base del conocimiento y experiencia de lostcnicos de pruebas; dicha base es un factor decisivopara el xito de las pruebas.


39/129



1.2.3.2. Tcnicas de control estticas

Aunque las tcnicas estticas son utilizadas cada vez ms, laspruebas dinmicas siguen siendo las tcnicas predominantes devalidacin y verificacin. Las tcnicas estticas permitenencontrar las causas de los defectos. Aplicar un proceso depruebas estticas sobre el proceso de desarrollo permite una

mejora del proceso evitando cometer errores similares en elfuturo.

Las tcnicas de pruebas estticas proporcionan una forma demejorar la productividad del desarrollo del software. El objetivofundamental de las pruebas estticas es mejorar la calidad delos productos software, ayudando a los ingenieros a reconocer yarreglar sus propios defectos en etapas tempranas del procesode desarrollo. Aunque las tcnicas de este tipo de pruebas sonmuy efectivas, no conviene que sustituyan a las pruebasdinmicas.

Estas pruebas, son las primeras que se aplican al software y

buscan defectos sin ejecutar cdigo. Por esta razn, tambin sellaman tcnicas de no ejecucin. Las tcnicas estticas tienenque ver con el anlisis y control de las representaciones delsistema, es decir de los diferentes modelos construidos duranteel proceso de desarrollo de software.

La mayora de las tcnicas estticas son tcnicas de verificacinque pueden probar cualquier tipo de documentacin ya seacdigo fuente, o documentacin y modelos de diseo, oespecificacin funcional o de requisitos.

Figura 1.14. Clasificacin de tcnicas de control estticas

a) Revisiones

Las revisiones son una tcnica esttica que consiste enrealizar un anlisis de un documento con el objetivo deencontrar y eliminar errores.


40/129

40


El tipo de una revisin vara en funcin de su nivel deformalidad. En este caso, formalidad se refiere a nivel deestructura y documentacin asociada con la revisin. Unostipos de revisin son completamente informales mientrasque otros son muy formales.

No existe una revisin perfecta, sino que cada una tiene unpropsito distinto durante las etapas del ciclo de vida deldocumento. Los principales tipos de revisiones se describena continuacin:

- InformalDar un borrador de un documento a un colega para quelo lea es el ejemplo ms simple de revisin. Es unaforma de conseguir beneficios (limitados) a un bajocosto ya que no siguen ningn proceso formal a seguir.La revisin puede implementarse mediante pares deprogramadores , donde uno revisa el cdigo del otro, omediante un tcnico que lidere el diseo de lasrevisiones y el cdigo.

- WalkthroughUn walkthrough se caracteriza porque el autor deldocumento bajo revisin va guiando al resto departicipantes a travs del documento exponiendo susideas para conseguir un entendimiento comn y recogerrespuestas. Es especialmente til si los asistentes noestn relacionados con el software, o no son capaces deentender los documentos de desarrollo de software. Enlas revisiones walkthrough se explica el contenido deldocumento paso a paso hasta llegar a un consenso enlos cambios y en el resto de informacin. La reunin esdirigida por los autores y a menudo est presente un

documentador, y para facilitar su ejecucin puedenusarse escenarios y simulaciones para validar elcontenido.

- Revisin tcnicaUna revisin tcnica es una reunin que se centra enconseguir consenso sobre el contenido tcnico de undocumento, por lo que es posible que sea dirigida por unexperto tcnico. Los expertos necesarios para unarevisin tcnica son, por ejemplo, responsables deldiseo y usuarios clave.

El objetivo principal de este tipo de revisiones es evaluar

el valor de conceptos tcnicos y alternativas del entornodel proyecto y del propio producto. Este tipo de revisina menudo se lleva a cabo por pares (peer reviews) ypara facilitar su ejecucin suelen utilizarse listas decomprobacin o listas de registro.

- InspeccinLa inspeccin es el tipo de revisin ms formal. Eldocumento bajo inspeccin es preparado y validado


41/129



minuciosamente por revisores antes de la reunin, secompara el producto con sus fuentes y otrosdocumentos, y se usan listas de comprobacin. En lareunin de la inspeccin, se registran los defectosencontrados y se pospone toda discusin para la fasede discusin. Todo esto hace que la inspeccin seauna reunin muy eficiente.

La inspeccin es dirigida normalmente por unmoderador formado, no por el propio autor deldocumento, quien realiza un seguimiento formalaplicando criterios de salida. Los defectos encontradosson documentados en una lista de registro, y de maneraopcional, para mejorar los procesos y aprender de losdefectos encontrados, se realiza un anlisis de lascausas de los mismos. Tambin, es habitual tomarmtricas que posteriormente son agrupadas yanalizadas para optimizar el proceso.

b) Anlisis esttico

El anlisis esttico, al igual que las revisiones, buscadefectos sin ejecutar el cdigo. Sin embargo, el anlisisesttico se lleva a cabo una vez que se escribe el cdigo.Su objetivo es encontrar defectos en el cdigo fuente y enlos modelos del software.

Se utilizan herramientas de software para procesar cdigofuente. stas analizan sintcticamente el programa y tratande descubrir condiciones potencialmente errneas y llamarla atencin del equipo de validacin y verificacin.

Existen distintos tipos de anlisis sintctico, entre los que se

encuentran:- Anlisis de flujo de control

Comprueba los bucles con mltiples puntos de entradao salida, encuentra cdigos inalcanzables.

- Anlisis de uso de los datosDetecta variables no inicializadas, variables escritas dosveces sin que intervenga una asignacin, variables quese declaran pero nunca se usan.

- Anlisis de interfaz. Comprueba la consistencia de unarutina, las declaraciones del procedimiento y su uso.

- Anlisis de flujo de informacin. Identifica lasdependencias de las variables de salida. No detectaanomalas en s pero resalta informacin para lainspeccin o revisin del cdigo.

- Anlisis de caminos. Identifica los caminos delprograma y arregla las sentencias ejecutadas en elcamino. Es potencialmente til en el proceso derevisin.


42/129

42


1.2.4. Herramientas de pruebas

Mediante la utilizacin de herramientas se puede conseguir reproducircierto trabajo previamente realizado, obteniendo resultados consistentes.Esta caracterstica es especialmente til para confirmar que un defecto seha arreglado, o para introducir datos de entrada a pruebas.

Los principales beneficios que aporta el uso de herramientas como mediopara llevar a cabo el proceso de pruebas son:

- Reducir el trabajo repetitivo- Mejorar la consistencia- Facilitar las evaluaciones objetivas- Facilitar el acceso a informacin relacionada con pruebas

A continuacin, se definen una serie de herramientas en base a sufuncionalidad. Las herramientas estn clasificadas dependiendo de lasreas o actividades de pruebas a las que se enfocan. La mayora de lasherramientas comerciales pueden usarse para diferentes funciones. Porejemplo, una herramienta de gestin puede proporcionar soporte para la

gestin de pruebas, gestin de la configuracin, gestin de incidencias ygestin de los requisitos y trazabilidad.

1.2.4.1. Herramientas de soporte para la gestin de pruebas

La gestin de pruebas se aplica sobre el conjunto del ciclo devida de desarrollo del software, por lo que una herramienta degestin de pruebas debera de ser la primera en usarse en elproyecto. Esta rea abarcara cuatro tipos de pruebas:

Figura 1.15. Herramientas de soporte para la gestin de pruebas

a) Herramientas de gestin de pruebasEstas herramientas ayudan a recoger, organizar ycomunicar informacin sobre las pruebas en un proyecto.Esta informacin puede usarse para monitorear el procesode pruebas y decidir las acciones a tomar. Asimismo, estasherramientas tambin proporcionan informacin sobre elcomponente o sistema que es probado.

HERRAMIENTAS DE SOPORTE PARA LA GESTIN DE PRUEBAS

H. de gestin de pruebas

H. de gestin de requisitos

H. de gestin de incidencias

H. de gestin de configuracin


43/129



b) Herramientas de gestin de requisitosSon tiles para las pruebas dado que stas se basan en losrequisitos. De esta forma, cuanto mayor sea la calidad delos requisitos, ms fcil ser desarrollar pruebas paracomprobar que son correctos. Asimismo, es importantemantener una trazabilidad bidireccional entre los requisitos ylas pruebas, y estas herramientas pueden ser de gran ayudaen esta tarea.

c) Herramientas de gestin de incidenciasFacilitan el mantenimiento del registro de incidencias a lolargo del tiempo. Este tipo de herramientas permitenidentificar defectos, problemas, anomalas o posiblesmejoras.

d) Herramientas de gestin de configuracinLas herramientas de gestin de configuracin no sonestrictamente herramientas de pruebas, sin embargo, unabuena gestin de configuracin es crtica para controlar laspruebas. Es necesario conocer exactamente qu debe serprobado as como la versin exacta de todos loscomponentes del sistema.

1.2.4.2. Herramientas de soporte para pruebas estticas

Las herramientas de las que se habla en este apartado puedendar soporte a las actividades de prueba descritas en el apartadorelativo a las pruebas estticas. Esta rea abarca tres tipos depruebas, a continuacin se describen.

Figura 1.16. Herramientas de soporte para pruebas estticas

a) Herramientas de revisin de procesos

Las herramientas de revisin de procesos se hacenespecialmente tiles para revisiones formales, donde haymucha gente involucrada o donde las personas implicadasestn en lugares geogrficamente separados.

Es cierto que mediante el uso de hojas de clculo odocumentos de texto se puede llevar un seguimiento detoda la informacin del proceso de revisin, pero tambinhay que recordar que una herramienta de revisin estdiseada exclusivamente para este propsito, y por lo tanto

HERRAMIENTAS DE SOPORTE PARA PRUEBAS ESTTICAS

H. de revisin de procesos

H. de anlisis esttico

H. de modelado


44/129

44


ser ms probable conseguir un buen resultado utilizndola.Otra ventaja que ofrece este tipo de herramientas es quefacilitan mucho el trabajo de recogida de informacin delproceso de pruebas.

b) Herramientas de anlisis estticoLas herramientas de anlisis esttico, normalmente, sonutilizadas por desarrolladores como parte del proceso depruebas. La caracterstica principal de estas herramientases que el cdigo no se ejecuta, sino que sirve de elemento odato de entrada a la herramienta. Algunas de lascaractersticas de estas herramientas son que calculanmtricas (p.ej., complejidad ciclomtica), imponenestndares de codificacin, analizan estructuras ydependencias, identifican anomalas en el cdigo, entreotras.

c) Herramientas de modeladoAyudan a validar modelos del sistema, por ejemplo,validando la consistencia de los objetos en una base dedatos o encontrando inconsistencias y defectos. Estasherramientas son de gran utilidad en el diseo de software.

Una ventaja que tienen tanto las herramientas de anlisisesttico como las de modelado es que pueden utilizarseantes de la ejecucin de las pruebas dinmicas. Estopermite detectar defectos tan pronto como sea posible, loque supone que arreglarlos sea ms sencillo y barato.

1.2.4.3. Herramientas de soporte para la especificacin de pruebas

Estas herramientas dan soporte a actividades de pruebas talescomo el anlisis de pruebas, el diseo de pruebas o la

implementacin de pruebas. En este apartado destacamos dostipos de esta categora de herramientas.

Figura 1.17. Herramientas de soporte para especificacin de pruebas

a) Herramientas de diseo de pruebasEstas son de gran utilidad a la hora de comenzar con eldiseo de pruebas, aunque no harn todo el trabajo. Elbeneficio que ofrece este tipo de herramientas es quepueden identificar de manera rpida y sencilla las pruebas a

HERRAMIENTAS DE SOPORTE PARA ESPECIFICACIN DEPRUEBAS

H. de diseo de pruebas

H. de preparacin de datos de pruebas


45/129



ejecutar sobre todos los elementos del sistema. Es decir,ayuda a que el proceso de pruebas sea ms exhaustivo.

Las herramientas de diseo de pruebas tambin puedenayudar a identificar valores de entradas a las pruebas(requisitos, modelos de diseo, condiciones de prueba), aconstruir casos de pruebas, a seleccionar los factores atener en cuenta para asegurar que todos los pares decombinacin son probados, etc.

b) Herramientas de preparacin de datos de pruebasEstablecer datos de pruebas puede ser una tarea tediosa,especialmente si se contempla un gran volumen de datospara las pruebas. Las herramientas de preparacin de datosde prueba sirven de ayuda en esta rea. Estas herramientassuelen usarse por los desarrolladores, aunque tambin seutilizan durante las pruebas de sistema y de aceptacin. Sonespecialmente tiles en las pruebas de rendimiento, dondees imprescindible trabajar con gran cantidad de datosrealistas.

1.2.4.4. Herramientas para ejecucin y registro de pruebas

En este apartado, se van a definir tres tipos de herramientasrelacionadas con la ejecucin y registro de pruebas.

Figura 1.18. Herramientas para ejecucin y registro de pruebas

a) Herramientas de ejecucin de pruebasLa mayora de las herramientas de este tipo ofrecen unmecanismo para la captura y registro de pruebas.

Estas herramientas suelen utilizar un lenguaje de scripting,

por lo que si los tcnicos de pruebas desean utilizar unaherramienta de ejecucin de pruebas necesitarn tenerhabilidades de programacin sobre la creacin ymodificacin de scripts.

b) Comparadores de pruebasLa esencia de las pruebas es comprobar si el softwareproduce el resultado correcto, y para ello deben comparar loque el software produce y lo que debera producir. Loscomparadores de pruebas ayudan a automatizar estosaspectos. Hay dos maneras de llevar a cabo esta

HERRAMIENTAS PARA EJECUCIN Y REGISTRO DE PRUEBAS

H. de ejecucin de pruebas

Comparadores de pruebas

H. de seguridad


46/129

46


comparacin. De manera dinmica, donde la comparacines realizada dinmicamente, es decir, mientras la prueba seest ejecutando, o post- ejecucin, donde la comparacin serealiza despus de que la prueba haya acabado y elsoftware bajo prueba no se vuelva a ejecutar.

c) Herramientas de seguridadHay numerosas herramientas que protegen a los sistemasde ataques externos, por ejemplo, los cortafuegos. Lasherramientas de pruebas de seguridad se utilizan paraprobar la seguridad que tienen los sistemas, intentadoacceder a un sistema, por ejemplo. Tambin, se encargande identificar virus, simular ataques externos, detectarintrusos, etc.

1.2.4.5. Herramientas de monitorizacin y rendimiento

Las herramientas descritas en esta seccin soportan pruebasque pueden llevarse a cabo durante el propio proceso depruebas o despus de la liberacin del sistema. En esta seccin

se tratarn dos de estas herramientas.

Figura 1.19. Herramientas de soporte para especificacin de pruebas

a) Herramientas de anlisis dinmicoLas herramientas de anlisis dinmico se llaman as porqueson dinmicas, es decir, requieren que el cdigo se estejecutando, y porque no ejecutan pruebas como tal, sinoque analizan lo que ocurre cuando el software se estejecutando.

b) Herramientas de monitorizacinLas herramientas de monitorizacin se utilizan para realizarun seguimiento del estado del sistema en uso, con elobjetivo de conseguir avisos tempranos de los problemas yde mejorar el servicio. Hay herramientas de monitorizacinpara servidores, redes, bases de datos, seguridad,rendimiento, pginas web y uso de internet, y paraaplicaciones.

HERRAMIENTAS DE MONITORIZACIN Y RENDIMIENTO

H. de diseo de pruebas

H. de preparacin de datos de pruebas


47/129



Actividades

CASO 1: CASO DE USO GENERAR TRANSFERENCIA A OTROS BANCOS

A continuacin, se muestra el prototipo del caso de uso Generar Transferencia a otrosBanco del sistema de Banca por Internet. Revise la pantalla teniendo en cuenta lassiguientes consideraciones:

Para que un usuario pueda realizar una transferencia a otro banco deber:

a. Seleccionar la cuenta desde la cual realizar la transferencia. Aqu semostrar una lista de todas las cuentas que tiene el usuario.b. Seleccionar el tipo de moneda, que podr ser soles o dlares.c. Ingresar el monto de la transferencia. El monto debe ser un nmero entero de

mximo 4 posiciones. El monto mnimo de transferencia es de 10 nuevossoles o 5 dlares.

d. Seleccionar el banco destino que podrn ser: Banco RSSG, Banco AFSG,Banco BAMC, Banco MFS.

e. Seleccionar el tipo de transferencia a realizar: A cuenta de Terceros, Pago deHaberes, Pago a Proveedores, Depsitos CTS.


48/129

48


f. Ingresar el cdigo interbancario, que es un nmero de 20 posiciones, dondelos 2 primeros dgitos pueden ser 00 01

g. Ingresar el nombre de la persona que realiza la transferencia, en el campoNombre del ordenante. Es un campo de 30 caracteres.

h. Podr adems ingresar los datos de la persona que recibir la transferencia,indicando sus nombres y apellidos. Los campos son de mximo 30caracteres.

Se pide que usted realice lo siguiente:

1. Identifique los escenarios al caso propuesto.

2. A partir de los escenarios identificados, en la pregunta anterior, deberidentificar los casos de prueba, las condiciones de entrada (Vlido, No Vlido oNo Aplica), para cada uno de los escenarios, y el resultado esperado.

3. Cree una tabla de clases de equivalencias vlidas y no vlidas.

4. Genere los casos de prueba (indicando un ejemplo del dato usado),considerando como referencia el cuadro generado en la pregunta 2. Utilice lasclases de equivalencia creadas en la pregunta 3, indicndolas en cada caso de

prueba.


49/129



CASO 2: CASO DE USO AGENDAR ACTIVIDAD

Flujo Bsico (FB)

1. El Administrativo selecciona Agendar Actividad desde la interfaz de menprincipal.

2. El Sistema despliega las diferentes categoras de actividades: Fsicas, Plantel

Competitivo, Deportivas, Culturales.3. El Administrativo selecciona una categora distinta de Fsicas4. El sistema muestra las actividades para esa categora5. El Administrativo selecciona una actividad6. El Sistema muestra los grupos y rangos de edad al cual puede estar destinada

la actividad:Grupo 1: Nios y adolescentes Preescolares (2.5 a 5 aos) Escolar Inicial (6 a 8 aos) Escolar Final (9 a 11 aos) Preadolescente (12 a 14 aos)Grupo 2: Jvenes y adultos (> 14 aos)

7. El Administrativo selecciona uno de esos rangos.

8. El sistema solicita el perodo en que se realizar la actividad9. El Administrativo ingresa la fecha de inicio y la fecha de fin del perodo de la

actividad10. El sistema solicita horario en que se realiza la actividad11. El Administrativo ingresa horario12. El Sistema despliega los profesores de carcter permanente asociados a la

actividad seleccionada disponibles en el horario, perodo y franja de edadespecificados.

13. El Administrativo selecciona un profesor.14. El Sistema despliega los lugares disponibles para realizar la actividad

seleccionada en el horario y perodo indicados.15. El Administrativo selecciona el lugar.16. El Administrativo selecciona la opcin registrar la actividad.17. El Sistema registra la informacin ingresada por el administrativo en el

cronograma de actividades del club y muestra el mensaje de Registro exitoso.18. El Caso de Uso finaliza.

Flujos Alternos

FA1. El administrativo selecciona la actividad Fsicas3.1 En el paso 3 del FB si el administrativo selecciona la categora Fsicas, el

sistema despliega como actividad solamente Fsicas y como rango deedad solamente el Grupo 2.

3.2 El caso de uso contina en el paso 8 del FB

FA2. No hay profesores disponibles

12.1. En el paso 12 del FB si el sistema detecta que no hay profesoresdisponibles, el sistema muestra el mensaje No hay profesoresdisponibles.

12.2. El Caso de Uso finaliza.

FA3. No hay lugares disponibles14.1. En el paso 14 del FB si el sistema detecta que no hay lugares

disponibles, el sistema muestra el mensaje No hay lugares disponibles.14.2. El Caso de Uso finaliza.


50/129

50


Se pide que usted desarrolle los siguientes puntos:

1. Identifique los escenarios correspondientes al CU Agendar Actividad.2. A partir de los escenarios identificados en la pregunta anterior, deber

identificar el tipo de valor de las condiciones de entrada (Vlido, Invlido o NoAplica) para cada uno de los escenarios y el resultado esperado.

3. Identifique las clases de equivalencia vlidas y no vlidas para las condicionesde entrada

4. Identifique los distintos casos de prueba slo para los escenarios y condicionesde entrada relacionados con el Flujo Bsico del Caso de Uso AgendarActividad. Complemente los casos de prueba, de ser necesario, con aquellosque se generen luego de identificar las clases de equivalencia de la pregunta 3.


51/129



Resumen

Lavalidacin y la verificacin son procesos de evaluacin de productos que sontiles para determinar si se satisfacen las necesidades del negocio y si se estnconstruyendo acorde a las especificaciones.

Las pruebas estn ms relacionadas con el proceso de validacin, mientras quelas revisiones son tareas ms orientadas al proceso de verificacin.

La Estrategia de Prueba de software integra un conjunto de actividades quedescriben los pasos que hay que llevar a cabo en un proceso de prueba: la

planificacin, el diseo de casos de prueba, la ejecucin y los resultados, tomandoen consideracin cunto esfuerzo y recursos se van a requerir, con el fin deobtener como resultado una correcta construccin del software.

En RUP se definen 4 roles de pruebas: Administrador de pruebas, Analista depruebas, Diseador de pruebas y Ejecutor de pruebas

Las pruebas estticas y las pruebas dinmicas son mtodos complementarios yaque ambas tratan de detectar distintos tipos de defectos de forma efectiva yeficiente, aunque las pruebas estticas estn orientadas a encontrar defectosmientras que las dinmicas fallos.

El diseo de los casos de prueba consiste realizar los siguientes pasos: Definir escenarios Identificar condiciones de entrada Definir clases de equivalencia Realizar casos de prueba

Si desea saber ms acerca de estos temas, puede consultar las siguientespginas.

http://www.inteco.es/file/XaXZyrAaEYfaXKiMJlkT_g

Aqu encontrar una gua completa de Validacin y Verificacin orientada a lasreas de proceso de CMMI. Esta gua fue elaborado por INTECO (InstitutoNacional de Tecnologas de la Comunicacin) de Espaa.

http://epf.eclipse.org/

Pruebas de Software (2)

Documents

Transcript of Pruebas de Software (2)