INSTITUTO POLITECNICO

NACIONAL

Escuela Superior de Computo

Orientado a Objetos
Analisis y Diseno
Tarea 6: Pruebas de calidad de software

Grupo 2CM6
Maestra:
Maldonado Castillo Idalia

Alumno:
Martnez Rodrguez Emmanuel

Mexico - 19 de junio de 2015


Indice
1. Objetivo

2. Introduccion

3. Contenido
3.1. Concepto de calidad de software . . . . .
3.2. Objetivos de la prueba de software . . . .
3.3. Caractersticas de las pruebas de software
3.4. Calidad de software . . . . . . . . . . . . .
de la calidad de software . .
3.5. Clasificacion
3.6. Pruebas de software . . . . . . . . . . . . .
3.7. Pruebas de aplicaciones convencionales .
3.7.1. Prueba de la caja blanca . . . . . .
3.8. Prueba de la ruta basica . . . . . . . . . . .
3.9. Prueba de la estructura de control . . . . .

3.9.1. Prueba de condicion

. . . . . . . .
3.9.2. Prueba de flujo de datos . . . . . .
3.9.3. Prueba de bucle . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.

4
4
4
4
5
5
5
6
6
6
6
7
7
7

4. Pruebas de caja negra

4.0.4. Prueba de arreglo ortogonal . . . . . . . . . . . . . . . . . . . . .

8
9

5. Prueba basada en el modelo

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

6. Pruebas para entornos,arquitecturas, y entornos especializados

6.1. Pruebas de interfaces graficas de usuario . . . . . . . . . . . .
6.2. Prueba de arquitecturas cliente-servidor . . . . . . . . . . . .
6.3. Pruebas para sistemas de tiempo real . . . . . . . . . . . . . .
6.3.1. Prueba de tareas . . . . . . . . . . . . . . . . . . . . . .
6.3.2. Prueba de comportamiento . . . . . . . . . . . . . . .
6.3.3. Prueba iteranea . . . . . . . . . . . . . . . . . . . . . .
6.4. Prueba del sistema . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

10
10
10
11
11
11
11
11

7. Conclusion

11

8. Referencias

12

1.

Objetivo

Investigar y analizar las diferentes pruebas de software que son concebidas en la

actualidad para entender como es que estas se desarrollan.

2.

Introduccion

La calidad de un producto refleja el agrado que el usuario tendra por e l, as tambien muestra si existe la eficacia, usabilidad y compatibilidad necesaria para que este

producto pueda ser liberado al publico

al que es destinado. En este caso el producto
se define como un sistema de software, para e l existen distintas pruebas que pueden
aplicarse, estas pruebas se realizan en distintas etapas del desarrollo del software.[1]
El uso de pruebas nos permite evaluar cualquier posible error antes de que este sea
experimentado por el usuario, aunque muchas veces,son los usuarios mismos quienes
terminan reportando un error, pues en ellos recae el uso, y siempre existe la posibi
lidad de que ellos evaluen
una trayectoria que los desarrolladores del sistema jamas
consideraron.
se muestran los distintos tipos de pruebas y su clasificacion
en el a mbiA continuacion

to de la busqueda
de la mejor calidad de un sistema de software.

3.
3.1.

Contenido
Concepto de calidad de software

Existen diversas definiciones de la Calidad del Software enunciadas por varias com as entre ellas la ISO y la IEEE que proponen normas y estandares para llevar a cabo
pan
de los procesos, dentro de las
una correcta practica que garantice la buena ejecucion
cuales pueden citarse:
La calidad del software es el grado con el que un sistema componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del
cliente o usuario
El conjunto de caractersticas de una entidad que le confieren su aptitud para
satisfacer las necesidades expresadas y las implcitas
Si interpretamos todo desde una amplia perspectiva podemos decir que se trata de:
C
oncordancia con los requisitos funcionales y de rendimiento explcitamente establecidos, con los estandares de desarrollo documentados, y con las caractersticas implcitas que se espera de todo software desarrollado profesionalmente.

3.2.

Objetivos de la prueba de software

Probar si el software no hace lo que debe.
Probar si el software hace lo que no debe, es decir, si provoca efectos secundarios
adversos.
no ha sido descubierto.
Descubrir un error que aun

Encontrar el mayor numero

de errores con la menor cantidad de tiempo y esfuerzo posibles.
Mostrar hasta que punto las funciones del software operan de acuerdo con las
especificaciones y requisitos del cliente.

3.3.

Caractersticas de las pruebas de software

Alta probabilidad de encontrar un error. El ingeniero de software debe tener un
a construir para poder disenar
casos
alto nivel de entendimiento de la aplicacion

de prueba que encuentren el mayor numero

de defectos.
No debe ser redundante. Uno de los objetivos de las pruebas es encontrar el ma
yor numero
de errores con la menor cantidad de tiempo y esfuerzo posibles, por
casos de prueba que tengan el mismo proposito

lo cual no se deben disenar

que
el menor numero

otros, sino que se debe tratar de disenar

de casos de prueba que
permitan probar adecuadamente el software y optimizar los recursos.
Una buena prueba no debera ser ni demasiado sencilla ni demasiado compleja.

3.4.

Calidad de software

se ve. Es el resultado de la buena administracion

La calidad del software no solo

del proyecto y de una correcta practica de la ingeniera de software. La administra y practica se aplican en el contexto de cuatro actividades principales que ayudan
cion
al equipo de software a lograr una alta calidad en e ste: metodos de la ingeniera de
de proyectos, acciones de control de calidad y
software, tecnicas de administracion
aseguramiento de la calidad del software. [2]

3.5.

de la calidad de software
Clasificacion

3.6.

Pruebas de software

El proceso de software puede verse como la espiral que se ilustra en la siguiente. Inicialmente, la ingeniera de sistemas define el papel del software y conduce al
analisis de los requerimientos del mismo, donde se establecen los criterios de dominio,
comportamiento, desempeno,
restricciones y validacion
de informacion
para
funcion,
el software.

3.7.

Pruebas de aplicaciones convencionales

3.7.1.

Prueba de la caja blanca

La prueba de caja blanca, en ocasiones llamada prueba de caja de vidrio, es una

de casos de prueba que usa la estructura de control descrita como
filosofa de diseno
a nivel de componentes para derivar casos de prueba. Al usar los
parte del diseno
metodos de prueba de caja blanca, puede derivar casos de prueba que:

1) garanticen que todas las rutas independientes dentro de un modulo

se revisaron al menos una vez

2) revisen todas las decisiones logicas

en sus lados verdadero y falso
3) ejecuten todos los bucles en sus fronteras y dentro de sus fronteras operativas
4) revisen estructuras de datos internas para garantizar su validez.

3.8.

Prueba de la ruta basica

La prueba de ruta o trayectoria basica es una tecnica de prueba de caja blanca propuesta por primera vez por Tom McCabe [McC76]. El metodo de ruta basica permite al

disenador
de casos de prueba derivar una medida de complejidad logica
de un diseno
de procedimiento y usar esta medida como gua para definir un conjunto basico de ru Los casos de prueba derivados para revisar el conjunto basico tienen
tas de ejecucion.
garanta para ejecutar todo enunciado en el programa, al menos una vez durante la
prueba.

3.9.

Prueba de la estructura de control

Esta prueba mas amplia cubre y mejora la calidad de la prueba de caja blanca.

3.9.1.

Prueba de condicion

3.9.2.

Prueba de flujo de datos

3.9.3.

Prueba de bucle

Los bucles son la piedra de toque de la gran mayora de todos los algoritmos imple as, con frecuencia se les pone poca atencion
mientras
mentados en el software. Y aun

se realizan las pruebas de software. La prueba de bucle es una tecnica de prueba de

caja blanca que se enfoca exclusivamente en la validez de los constructos bucle.

4.

Pruebas de caja negra

Las pruebas de caja negra, tambien llamadas pruebas de comportamiento, se enfocan en los requerimientos funcionales del software; es decir, las tecnicas de prueba
de caja negra le permiten derivar conjuntos de condiciones de entrada que revisaran
por completo todos los requerimientos funcionales para un programa. Las pruebas de
caja negra no son una alternativa para las tecnicas de caja blanca. En vez de ello, es un
enfoque complementario que es probable que descubra una clase de errores diferente
que los metodos de caja blanca. Las pruebas de caja negra intentan encontrar errores
en las categoras siguientes:
1) funciones incorrectas o faltantes.
2) errores de interfaz.
3) errores en las estructuras de datos o en el acceso a bases de datos externas.
4) errores de comportamiento o rendimiento.
y terminacion.

5) errores de inicializacion
A diferencia de las pruebas de caja blanca, que se realizan tempranamente en el

proceso de pruebas, la prueba de caja negra tiende a aplicarse durante las ultimas

etapas de la prueba. Puesto que, a proposito,

la prueba de caja negra no considera
se enfoca en el dominio de la informacion.
Las
la estructura de control, la atencion
para responder a las siguientes preguntas:
pruebas se disenan

Como
se prueba la validez funcional?

Como
se prueban el comportamiento y el rendimiento del sistema?
Que clases de entrada haran buenos casos de prueba?
El sistema es particularmente sensible a ciertos valores de entrada?

Como
se aslan las fronteras de una clase de datos?
Que tasas y volumen de datos puede tolerar el sistema?
del sistema algunas combinaciones esQue efecto tendran sobre la operacion
pecficas de datos?
Al aplicar las tecnicas de caja negra, se deriva un conjunto de casos de prueba que
satisfacen los siguientes criterios:

1) casos de prueba que reducen, por una cuenta que es mayor que uno, el numero

de casos de prueba adicionales que deben disenarse

para lograr pruebas razonables2) casos de prueba que dicen algo acerca de la presencia o ausencia de clases de
errores, en lugar de un error asociado solamente con la prueba especfica a mano.
8

4.0.4.

Prueba de arreglo ortogonal

Existen muchas aplicaciones en las cuales el dominio de entrada es relativamen

y los valores
te limitado, es decir, el numero
de parametros de entrada es pequeno
que cada uno de los parametros puede tomar estan claramente acotados. Cuando di
(por ejemplo, tres parametros de entrada que toman
chos numeros
son muy pequenos
de entrada
tres valores discretos cada uno), es posible considerar cada permutacion
y probar de manera exhaustiva el dominio de entrada. Sin embargo, conforme crece

el numero
de valores de entrada y el numero
de valores discretos para cada tem de
datos, la prueba exhaustiva se vuelve impractica o imposible. La prueba de arreglo
ortogonal puede aplicarse a problemas en los que el dominio de entrada es relativa pero demasiado grande para alojar la prueba exhaustiva. El metodo
mente pequeno
para encontrar los fallos de rede prueba de arreglo ortogonal es particularmente util

gion, una categora de error asociada con logica defectuosa dentro de un componente
de software.

5.

Prueba basada en el modelo

La prueba basada en modelo (PBM) es una tecnica de prueba de caja negra que usa
contenida en el modelo de requerimientos como la base para la generala informacion
de casos de prueba. En muchos casos, la tecnica de prueba basada en modelo usa
cion
diagramas de estado UML, un elemento del modelo de comportamiento como la base
de los casos de prueba.7 La tecnica PBM requiere cinco pasos:
para el diseno
1. Analizar un modelo de comportamiento existente para el software o crear

uno. Para crear el modelo, debe realizar los pasos expuestos a continuacion:
1) evaluar todos los casos de uso para comprender por completo la secuencia de
dentro del sistema.
interaccion
y entender
2) identificar los eventos que impulsen la secuencia de interaccion

como
dichos eventos se relacionan con objetos especficos.
3) crear una secuencia para cada caso de uso.
4) construir un diagrama de estado UML para el sistema
y congruencia.
5) revisar el modelo de comportamiento para verificar precision
2. Recorrer el modelo de comportamiento y especificar las entradas que forzaran
de estado a estado. Las entradas dispararan
al software a realizar la transicion

eventos que haran que ocurra la transicion.

3. Revisar el modelo de comportamiento y observar las salidas esperadas, con de estado a estado. Para cada conjunto
forme el software realiza la transicion
de entradas (casos de prueba) especificado en el paso 2, las salidas esperadas se
especifican como se caracterizan en el modelo de comportamiento. ?Una supo fundamental de esta prueba es que existe cierto mecanismo, un oraculo
sicion
son o
de prueba, que determinara si los resultados de una prueba de ejecucion
no correctos? [DAC03]. En esencia, un oraculo de prueba establece la base para
de lo correcto de la salida. En la mayora de los casos, el
cualquier determinacion
oraculo es el modelo de requerimientos, pero tambien podra ser otro documento
9

 datos registrados en cualquier otro lado o, incluso, un experto huo aplicacion,

mano.
4. Ejecutar los casos de prueba. Las pruebas pueden ejecutarse manualmente o
de prueba usando una herramienta de prueba.
crearse y ejecutarse un guion
correctiva
5. Comparar los resultados reales y esperados y adoptar una accion
se requiera.
segun

6.
6.1.

Pruebas para entornos,arquitecturas, y entornos especializados

Pruebas de interfaces graficas de usuario

Las interfaces graficas para usuario (GUI, por sus siglas en ingles) presentan interesantes retos de prueba. Puesto que los componentes reutilizables ahora son parte
en los entornos de desarrollo GUI, la creacion
de la interfaz para el usuario
comun
se ha vuelto menos consumidora de tiempo y mas precisa. Pero, al mismo tiempo, la
y ejecomplejidad de las GUI ha crecido, lo que conduce a mas dificultad en el diseno
de los casos de prueba. Debido a que muchas GUI modernas tienen la misma
cucion
apariencia y ambiente, puede derivarse una serie de pruebas estandar. Es posible usar
las graficas de modelado de estado finito para derivar una serie de pruebas que aborden objetos de datos y programa especficos que sean relevantes para la GUI.

6.2.

Prueba de arquitecturas cliente-servidor

La naturaleza distribuida de los entornos cliente-servidor, los conflictos de rendimiento asociados con el procesamiento de transacciones, la potencial presencia de
en
algunas plataformas de hardware diferentes, las complejidades de la comunicacion

red, la necesidad de atender a multiples

clientes desde una base de datos centralizada
impuestos al
(o en algunos casos, distribuida) y los requerimientos de coordinacion
servidor se combinan para realizar las pruebas de las arquitecturas cliente-servidor y
el software que reside dentro de ellas es considerablemente mas difcil que las aplicaciones independientes.
En general, la prueba del software cliente-servidor ocurre en tres niveles diferentes:
1) las aplicaciones cliente individuales se prueban en un modo ?desconectado?; no se
del servidor ni la red subyacente.
considera la operacion
2) El software cliente y las aplicaciones servidor asociadas se prueban en concierto,
pero las operaciones de red no se revisan de manera explcita.
de red y
3) Se prueba la arquitectura cliente-servidor completa, incluidos la operacion
el rendimiento.

10

6.3.

Pruebas para sistemas de tiempo real

La naturaleza asncrona, dependiente del tiempo de muchas aplicaciones de tiempo real, agrega un nuevo y potencialmente difcil elemento a la mezcla de pruebas: el

debe considerar los casos de prueba

tiempo. El disenador
de casos de prueba no solo
de eventos (es decir, el procesamiento
convencionales, sino tambien la manipulacion
de los datos y el paralelismo de las tareas (prode interrupciones), la temporizacion
cesos) que manejan los datos. En muchas situaciones, probar los datos proporcionados
cuando un sistema de tiempo real esta en un estado dara como resultado un procesamiento adecuado, mientras que los mismos datos proporcionados cuando el sistema
esta en un estado diferente pueden conducir a error.
6.3.1.

Prueba de tareas

El primer paso en la prueba del software en tiempo real es probar cada tarea de ma para cada tarea y
nera independiente. Es decir, las pruebas convencionales se disenan
se ejecutan independientemente durante dichas pruebas. La prueba de tareas descubre

mas no en temporizacion
y comportamiento.
errores en logica
y funcion,
6.3.2.

Prueba de comportamiento

Con modelos de sistema creados con herramientas automatizadas, es posible simular el comportamiento de un sistema en tiempo real y examinar su comportamiento
como consecuencia de eventos externos. Estas actividades de analisis pueden servir
de los casos de prueba que se realizan cuando se construye el
de base para el diseno
software en tiempo real.
6.3.3.

Prueba iteranea

Una vez aislados los errores en las tareas individuales y en el comportamiento del
sistema, las pruebas se cambian a los errores relacionados con el tiempo. Las tareas
asncronas que se sabe que se comunican mutuamente se prueban con diferentes tasas
de datos y carga de procesamiento para determinar si ocurriran errores de sincroni intertarea. Ademas, las tareas que se comunican va cola de mensaje o almacezacion
de estas a reas de
namiento de datos se prueban para descubrir errores en el tamano
almacenamiento de datos.

6.4.

Prueba del sistema

Al integrar software y hardware, se lleva a cabo un amplio rango de pruebas del

de descubrir errores en la interfaz software-hardware. La masistema con la intencion
yora de los sistemas en tiempo real procesan las interrupciones. Por tanto, probar la
de estos eventos booleanos es esencial.
manipulacion

11

7.

Conclusion

A traves de esta tarea se investigaron las formas de verificar y validar la calidad de

nuestro sistema, este tema es muy amplio, encontre varios libros en donde mas de un
captulo esta dedicado a las pruebas del sistema, algo que resulto poco ortodoxo que el
precio que esta parte tienen, pues se mostraban graficas de investigaciones realizadas
en donde la mayor parte de los costos se da en la parte de pruebas, ya que si se encuentran errores aqu, dado que ya se tiene implementado el sistema, realizar correcciones
sera que usuarios finales encontrasen esos errores, ya
es una gran labor, y peor aun
que eso reflejara que no se realizaron las pruebas correctas y de igual forma tendra
implicaciones en costos muy altas.
del codigo

Existe una gran variedad de tipos de pruebas, desde la verificacion

hasta la
de los tamanos
correctos de cada icono o imagen que se usa, ademas, tamvalidacion

bien existe una especie de analisis psicologico

para la parte de las interfaces, en donde
entran los tipos de fuente, colores, etc...
Las pruebas realizadas son de distintos tipos y suelen ser valuadas por distintos tipos
de usuarios, esto se por niveles hasta abarcar todos los usuarios, considero que es muy
error y eso nos orilla a
poco probable que hayan sistemas que se liberen sin ningun
tener versiones posteriores en donde ademas de corregir un error se pueden mejorar y
optimizar diferentes partes del sistema.

8.

Referencias

[1] EcuRed, conocimiento con todos y para todos, Pruebas de calidad de software,
disponible en: http://www.ecured.cu/index.php/Pruebas de Calidad de Software
[2] Ingeniera de software, un enfoque practico. Roger S. Pressman, Mac Graw Hill,
PP. 351.
septima edicion.

12