PRUEBAS DE SOFTWARE

INTEGRANTES:
RUBEN ALZATE
WILSON ARGUELLO
FABIAN CASTRO
FREDY JIMENEZ
CARLOS RODRIGUEZ

DOCENTE:
ING. ALFONSO LPEZ PALACIO

INGENIERA DE SOFTWARE II
UNIVERSIDAD COOPERATIVA DE COLOMBIA
FACULTAD DE INGENIERA DE SISTEMAS
BOGOT
2015
TABLA DE CONTENIDO

Introduccin
1. Conceptos bsicos
Las pruebas de software
Pruebas como proceso
2. Objetivos de las pruebas de software
3. Principios y fundamentos de las pruebas de software
En qu consisten las pruebas de software
Evaluacin de resultados
4. Metodologa de las pruebas de software
Planeacin de pruebas
Diseo de pruebas
Implementacin y ejecucin de pruebas
Evaluacin de criterios
Cierre del proceso
5. Niveles de las pruebas de software
6. Pruebas de software
Pruebas del Sistema
Pruebas funcionales
Pruebas unitarias
Tcnica caja blanca
Tcnica caja negra
Tcnica caja gris
Validacin y verificacin
Pruebas de integracin
Pruebas de humo
Pruebas de regresin
Pruebas de entrega
Pruebas No funcionales
Pruebas de comunicacin
Pruebas de rendimiento
Pruebas de volumen
Pruebas de integridad de datos y BD
Pruebas de operacin
Pruebas de entorno o ambiente
Pruebas de seguridad y control de acceso
Pruebas de almacenamiento
Pruebas de configuracin
Pruebas de desempeo
2

Pruebas de implantacin
Pruebas de instalacin
Pruebas de la documentacin
Pruebas de recuperacin y tolerancia a fallas
Pruebas de resistencia
Pruebas de tensin
Pruebas de usabilidad
Pruebas de compatibilidad y conversin
Pruebas de estrs o esfuerzo
Pruebas GUI
Pruebas de estilo
Pruebas de mltiples sitios
Pruebas de ciclo de negocio
Pruebas de aceptacin
Pruebas alfa y beta
Pruebas alfa
Pruebas beta
7. Conclusiones
8. Web grafa

INTRODUCCION

El Software testing o como se conoce en espaol las pruebas de

software se aplican como una etapa ms del proceso de desarrollo de
software, su objetivo es asegurar que el software cumpla con las
especificaciones requeridas y eliminar los posibles defectos que este
pudiera tener. En un principio la mayora de empresas de desarrollo
contaban con una etapa de pruebas demasiado informal, en la
actualidad el software testing se ha convertido en una de las etapas ms
crticas del ciclo de vida del desarrollo de software y esto ha causado el
origen de diversas metodologas.
En la actualidad el software testing se hace ms complicado ya que
debe hacer frente a una gran cantidad de metodologas de desarrollo,
lenguajes de programacin, sistemas operativos, hardware etc.
Es por esto que el testing debe apoyarse en metodologas generales que
revisan los aspectos ms fundamentales que debe considerar todo
proceso de pruebas. Debido a esta complejidad actualmente se cuentan
con una gran cantidad de software diseado exclusivamente para la
etapa de pruebas, incluyendo la gestin del proceso de software testing,
la administracin y seguimiento de errores, la administracin de los
casos de prueba, automatizacin de pruebas etc.
Luego de culminadas las etapas de anlisis, diseo y desarrollo se inicia
la etapa de pruebas, en esta etapa lo recomendable es que el software
se mantenga en un ambiente aislado o separado del ambiente de
desarrollo o de produccin, lo ideal es preparar un ambiente de pruebas
lo ms parecido a los ambientes que existen en produccin para
asegurar su correcto funcionamiento en esa futura etapa, se debe
considerar adquirir un equipo de pruebas especializado software tester
o analista de pruebas, con experiencia.
Estas personas tienen una formacin que les permite detectar una gran
cantidad de errores en tiempos mnimos, as como una metodologa
especifica que les permite hacer el trabajo de manera correcta, algunas
empresas ms informales utilizan a los futuros usuarios del sistema
como testers situacin que puede traer una serie de problemas debido a
la poca experiencia que pueden tener los usuarios en la deteccin de
errores, adems se obvian pruebas importantes como las pruebas de
Esfuerzo o Stress testing.
Tambin se dejan de lado las pruebas unitarias o pruebas modulares, las
que deberan asegurar que cada mdulo del sistema trabaje
correctamente de manera independiente, otro error muy conocido en
4

empresas de software es el uso de los mismos desarrolladores como

analistas de pruebas.
Es muy difcil probar con objetividad un software si nosotros mismos lo
hemos desarrollado, un tcnico o analista programador empezara a
probar con la idea preconcebida de que su desarrollo trabaja a la
perfeccin e inconscientemente evitara realizar pruebas ms
exhaustivas considerando que las mismas podran ser absurdas o
innecesarias, lo bueno es que poco a poco estas ideas van quedando
descartadas y se van alineando conceptos hacia un software testing
profesional
1. CONCEPTOS BASICOS
Las pruebas de software
Consisten en la dinmica de la verificacin del comportamiento de un
programa en un conjunto finito de casos de prueba, debidamente
seleccionados de por lo general infinitas ejecuciones de dominio, contra
la del comportamiento esperado. Son una serie de actividades que se
realizan con el propsito de encontrar los posibles fallos de
implementacin, calidad o usabilidad de un programa u ordenador;
probando el comportamiento del mismo
Pruebas como proceso
La prueba es un proceso que se enfoca sobre la lgica interna del
software y las funciones externas. Es un proceso de ejecucin de un
programa con la intencin de descubrir un error, no puede asegurar la
ausencia de defectos; slo puede demostrar que existen defectos en el
software.
2. OBJETIVOS DE LAS PRUEBAS DE SOFTWARE
La prueba de software es un elemento crtico para la garanta del
correcto funcionamiento del software. Entre sus objetivos estn:
1. Detectar defectos en el software.
2. Verificar la integracin adecuada de los componentes.
3. Verificar que todos los requisitos se han implementado
correctamente.
4. Identificar y asegurar que los defectos encontrados se han corregido
antes de entregar el software al cliente.
5

5. Disear casos de prueba que sistemticamente saquen a la luz

diferentes clases de errores, hacindolo con la menor cantidad de
tiempo y esfuerzo.
6. Para lograr los objetivos propuestos, un ingeniero de software deber
conocer los principios bsicos que guan las pruebas del software.

3. PRINCIPIOS Y FUNDAMENTOS DE LAS PRUEBAS DE

SOFTWARE
En el proceso de ingeniera del software, existen dependiendo de la
metodologa de desarrollo utilizada (SCRUM, RUP, etc.), una serie de
etapas claramente identificadas en el proceso, teles como: anlisis,
diseo, implementacin, pruebas, etc. Sin embargo, por algunas razones
la etapa correspondiente al proceso de pruebas de un producto, a la que
las firmas desarrolladoras menos tiempo de planeacin le asignan, y a la
que menos recursos comprometen en sus respectivos planes de trabajo.
En muchos casos, las fbricas de software, suelen acudir a una mala
prctica en donde involucran personal de desarrollo, para ejecutar
actividades de pruebas, sin tener en cuenta que estas personas, debido
al rol que asume dentro del proceso, de manera involuntaria protegern
el estado de su producto, muchas veces minimizando la criticidad de los
fallos encontrados, sesgando de esta manera el grado real de calidad del
producto.
Por esta razn se aconseja que esta etapa de pruebas sea ejecutada por
un equipo ajeno a los procesos de desarrollo o en el mejor de los casos
por un tercero especializado en el aseguramiento de calidad como la
planeacin y ejecucin de pruebas sobre sus productos.

Las pruebas se rigen por una serie de principios, una buena comprensin
de estos facilitar el posterior uso de los mtodos en un efectivo diseo
de casos de prueba.

A continuacin se citan:
La prueba puede ser usadas para mostrar la presencia de errores,
pero
nunca su ausencia.
La principal dificultad del proceso de prueba es decidir cundo
parar.
Evitar casos de pruebas no planificados, no reusables y triviales a
menos que el programas
sea verdaderamente sencillo.
Una parte necesaria de un caso de prueba es la definicin del
resultado esperado.
Los casos de pruebas tienen que ser escritos no solo para
condiciones de entrada vlidas y esperadas sino tambin para
condiciones no vlidas e inesperadas.
El nmero de errores sin descubrir es directamente proporcional al
nmero de errores descubiertos.
Estas leyes que definen bsicamente la aplicacin de las pruebas
de software ayudan a refinar el producto de software a travs de
las etapas involucradas.
En Que Consisten Las Pruebas De Software
1.
2.

3.

4.
5.

Seleccionar qu es lo que debe medir la prueba, es decir, cul es

su objetivo, para qu exactamente se hace la prueba.
Decidir cmo se va a realizar la prueba, es decir, qu clase de
prueba se va a utilizar para medir la calidad y qu clase de
elementos de prueba se deben usar.
Desarrollar los casos de prueba. Un caso de prueba es un conjunto
de datos o situaciones de prueba que se utilizarn para ejecutar la
unidad que se prueba o para revelar algo sobre el atributo de
calidad que se est midiendo.
Determinar cules deberan ser los resultados esperados de los
casos de prueba y crear el documento que los contenga.
Ejecutar los casos de prueba.

Evaluacin De Resultados
Comparar los resultados de la prueba con los resultados esperados.
Cualquier discrepancia entre ellos significa un error. Tpicamente el error
est en el sistema o unidad probada, pero tambin puede ser generado
por algn aspecto del mismo proceso de prueba.
Caracterstic Observacin
7

a
Operatividad Cunto mejor funcione, ms eficientemente se puede
probar

El sistema tiene pocos errores

Ningn error bloquea la ejecucin de las pruebas

El producto evoluciona en fases funcionales

Observabilid Lo que se ve es lo que se prueba
ad
Se genera una salida distinta para cada entrada
Todos los factores que afectan a los resultados
estn visibles

Un resultado incorrecto se identifica fcilmente

Los errores internos se detectan automticamente

Se informa
internos

automticamente

de

los

errores

El cdigo fuente es accesible.

Controlabilid Cunto mejor se pueda controlar el software, ms se
ad
puede automatizar y optimizar

Todo el cdigo es ejecutable a travs de alguna

combinacin de entrada
El ingeniero de pruebas puede controlar los
estados y las variables del hardware y software

Los formatos de las entradas y los resultados son

consistentes y estructurados
Capacidad
Controlando el mbito de las pruebas, podemos aislar
de
ms rpidamente los problemas y llevar a cabo pruebas
descomposic de regresin
in
El
software est construido con mdulos
independientes

Los mdulos de software se pueden probar

independientemente.
Cunto menos haya que probar, ms rpidamente se
puede probar

Simplicidad

Simplicidad funcional

Simplicidad estructural

Simplicidad del cdigo

Caracterstic Observacin
a
Estabilidad

Cuanto menos cambios, menos interrupciones a las

pruebas

Los cambios del software son infrecuentes

Los cambios del software estn controlados

Los cambios del software no invalidan las

pruebas existentes

El software se recupera bien de los fallos

Facilidad de Cuanta ms informacin se tenga, ms inteligentes
comprensin sern las pruebas

El diseo se ha entendido perfectamente

Las dependencias entre los componentes
internos, externos y compartidos se han
entendido perfectamente

Se han comunicado los cambios del diseo

La documentacin tcnica es accesible

4. METODOLOGA DE LAS PRUEBAS DE SOFTWARE

Para procesos de desarrollo de mtodos tradicionales, implementar una
metodologa de pruebas es totalmente viable, teniendo en cuenta que
estas metodologas estn orientadas a la documentacin y a la
formalizacin de todas las actividades ejecutadas. Si por el contrario, la
firma desarrolladora gua su proceso bajo lineamientos basados en
metodologas giles, ser necesario reevaluar la conveniencia de
ejecutar todas las actividades que implica un proceso de pruebas formal,
lo que en la mayora de los casos, conlleva a reducir al mnimo las
actividades relacionadas con un proceso de pruebas, circunstancia que
9

naturalmente puede desencadenar

bajos niveles de calidad.

en la liberacin de productos con

Un proceso para la ejecucin de pruebas de software, est compuesto,

cuando menos por las siguientes 5 tpicas etapas:
1.
2.
3.
4.
5.

Planeacin de pruebas.
Diseo de pruebas.
implementacin de pruebas.
Evaluacin de criterios de salida.
Cierre del proceso.

Planeacin de pruebas
Es la etapa en donde se ejecutan las primeras actividades
correspondientes al proceso de pruebas y tiene como resultado un
entregable denominado plan de pruebas el cual debe estar conformado
en cuando menos por aspectos tales como:

Alcance de la prueba: determina que funcionalidades del

producto y/o software sern probadas durante el transcurso de la
prueba. Este listado de funcionalidades a probar se extrae con
base a un anlisis de riesgos realizado de manera previa, que
tienen en cuenta variables tales como el impacto que podra
ocasionar la falla de una funcionalidad y la probabilidad de falla de
una funcionalidad. Producto de este anlisis, se cuenta con
informacin adicional que permite determinar adems del alcance
detallado del proceso de pruebas, la prioridad con la que las
funcionalidades deben probarse y la profundidad de las pruebas.

Tipos de Prueba: en este punto se debe determinar qu tipos de

pruebas requerira el producto. No todos los productos de software
requieren la aplicacin de todos los tipos de pruebas que existen,
por esta razn, es estrictamente necesario que el lder de pruebas
se plantee preguntas que le permitan determinar qu tipos de
prueba son aplicables al proyecto en evaluacin. Los posibles tipos
de prueba a aplicar son: pruebas de stress, pruebas de
rendimiento, pruebas de carga, pruebas funcionales, pruebas de
usabilidad, pruebas de regresin, entre otros.

Estrategia de Pruebas: teniendo en cuenta que no es viable

probar con base a todas las posibles combinaciones de datos, es
necesario determinar a travs de un anlisis de riesgos sobre que
funcionalidades
debemos
centrar
nuestra
atencin.
10

Adicionalmente, una buena estrategia de pruebas debe indicar los

niveles de pruebas (ciclos) que aplicaremos y la intensidad o
profundidad a aplicar para cada nivel de pruebas definido. En este
punto tambin es importante definir los criterios de entrada y
salida para cada ciclo de pruebas a ejecutar.

Criterios de Salida: entre las partes involucradas en el proceso,

se define de manera formal, bajo qu condiciones se puede
considerar que una actividad de pruebas fue finalizada. Los
criterios de salida se deben definir para cada nivel de pruebas a
ejecutar. Algunos ejemplos de criterios de salida que pueden ser
utilizados son: porcentaje de funcionalidades de alto riesgo
probadas con xito, nmero defectos crticos y/o mayores
aceptados, etc.

Otros aspectos: tal y como se realiza en cualquier plan de

proyecto, se debe incluir una estimacin de tiempos, los roles y/o
recursos que harn parte del proceso, la preparacin del entorno
de pruebas, cronograma base, etc.

Diseo De Pruebas
Una vez elaborado y aprobado el plan de pruebas, el equipo de trabajo
debe iniciar el anlisis de toda la documentacin existente con respecto
al sistema, con el objeto de iniciar el diseo de los casos de prueba. Los
entregables claves para iniciar este diseo pueden ser: casos de uso,
historias de usuario, arquitectura del sistema, diseos, manuales de
usuario (si existen), manuales tcnicos (si existen).
El diseo de los
casos, debe considerar la elaboracin de casos positivos y negativos.
Los casos de prueba negativos permiten validar cmo se comporta el
sistema ante situaciones atpicas y permite verificar la robustez del
sistema, atributo que constituye uno de los requerimientos no
funcionales indispensable para cualquier software. Por ltimo, es
necesario definir cules son los datos de prueba necesarios para la
ejecucin de los casos de prueba diseados.
Implementacin Y Ejecucin De Pruebas
La ejecucin de pruebas debe iniciar con la creacin de los datos de
prueba necesarios para ejecutar los casos de prueba diseados. La
ejecucin de estos casos, puede realizarse de manera manual o
automatizada; en cualquiera de los casos, cuando se detecte un fallo
en el sistema,
este debe ser documentado y registrado en una
herramienta que permita gestionar los defectos (Bug Tracker). Una vez
el defecto ha sido corregido por la firma desarrolladora en su respectivo
proceso de depuracin, es necesario realizar un re-test que permita
11

confirmar que el defecto fue solucionado de manera exitosa. Por ltimo,

es indispensable ejecutar un ciclo de regresin que nos permita
garantizar, que los defectos corregidos en el proceso de depuracin de
la firma, no hayan desencadenado otros tipos de defectos en el sistema.
Evaluacin De Criterios De Salida
Los criterios de salida son necesarios para determinar si es posible dar
por finalizado un ciclo de pruebas. Para esto, es conveniente definir una
serie de mtricas que permitirn al finalizar un proceso de pruebas,
comparar los resultados obtenidos contra las mtricas definidas, s los
resultados obtenidos no superan la mtricas definidas, no es posible
continuar con el siguiente ciclo de pruebas.
Existen varios tipos de criterios de salida dentro de los cuales se pueden
mencionar: cubrimiento de funcionalidades en general, cubrimiento de
funcionalidades crticas para el sistema, Nmero de defectos crticos y
mayores detectados, etc. Tambin es importante aclarar que el proceso
de pruebas puede ser suspendido y/o paralizado, debido entre otros, a
aspectos relacionados con el presupuesto y la calidad mnima del
sistema requerida para el inicio formal de pruebas.
Cierre Del Proceso
Durante este periodo de cierre el cual histricamente se ha comprobado
que se le destina muy poco tiempo en la planeacin, se deben cerrar las
incidencias reportadas, se debe verificar si los entregables planeados
han sido entregados y aprobados, se deben finalizar y aprobar los
documentos de soporte de prueba, analizar las lecciones aprendidas
para aplicar en futuros proyectos, etc.
5. NIVELES DE LAS PRUEBAS DE SOFTWARE

12

6. PRUEBAS DE SOFTWARE
PRUEBAS DEL SISTEMA
Las Pruebas de sistemas buscan discrepancias entre el programa y el
objetivo o requerimiento, enfocndose en los errores hechos durante la
transicin del proceso al disear la especificacin funcional. Esto hace a
las pruebas de sistema un proceso vital de pruebas, ya que en trminos
del producto, nmero de errores hechos, y severidad de esos errores, es
un paso en el ciclo de desarrollo generalmente propenso a la mayora de
los errores.
Las Pruebas de sistemas no son procesos para probar las funciones del
sistema o del programa completo, porque esta seria redundante con el
proceso de las pruebas funcionales. Las pruebas del sistema tienen un
propsito particular: para comparar el sistema o el programa con sus
objetivos originales (Requerimientos funcionales y no funcionales). Dado
este propsito, se presentan dos implicaciones.

Las pruebas de sistema no se limitan a los sistemas. Si el producto

es un programa, la prueba del sistema es el proceso de procurar
demostrar cmo el programa, en su totalidad, no resuelve sus
objetivos o requerimientos.
Las pruebas de sistema, por definicin, son imposibles si no estn
los requerimientos por escrito, mensurables para el producto.

13

Las pruebas de sistema tienen como objetivo ejercitar profundamente el

sistema comprobando la integracin del sistema de informacin
globalmente, verificando el funcionamiento correcto de las interfaces
entre los distintos subsistemas que lo componen y con el resto de
sistemas de informacin con los que se comunica.
Un problema clsico de la prueba de sistema es sealar con el dedo.
Esto ocurre cuando se descubre un error y el desarrollador de cada
elemento del sistema culpa a los dems. En lugar de caer en este
absurdo, el ingeniero del software debe de anticiparse a posibles
problemas de la interfaz:

Disear ruta de manejo de errores que prueben toda la

informacin proveniente de otros elementos del sistema.
Aplicar una serie de pruebas que simulen datos incorrectos u
otros posibles errores en la interfaz de software.
Registrar los resultados de la prueba como evidencia en el caso
de que se culpe.
Participar en la planeacin
y el diseo de las pruebas del
sistemas para asegurar que le software
se ha probado
adecuadamente.

En realidad, la prueba de sistema abarca una serie de pruebas

diferentes cuyo propsito principal
es ejecutar profundamente el
sistema en cmputo. Aunque cada prueba tiene un propsito diferente,
todas trabajan para verificar que se hayan integrado adecuadamente
todos los elementos del sistema
y que realicen las funciones
apropiadas.
Visin Sistmica De La Prueba
Cuando se deben realizar pruebas, debe mantenerse un enfoque
sistmico, es decir integral, que est detrs de todo desarrollo de
software. Al hablar de enfoque sistmico se indica que:

Todo sistema tiene una serie de objetivos que le dan sentido. Esos
objetivos estn asociados con indicadores de xito que
permiten determinar si los objetivos se cumplen y en qu medida.
Todo sistema tiene una serie de elementos que lo forman y
la interaccin de tales elementos se orienta a satisfacer los
objetivos.
14

Todo sistema tiene una frontera que lo separa de un medio

ambiente. Los elementos de ese medio ambiente influyen sobre
el sistema proporcionndoles una serie de entradas y obteniendo
del mismo un conjunto de salidas.
Ningn sistema existe en aislamiento; siempre interaccionan
con otros sistemas constituyendo un sistema mayor.

Al aplicar esos conceptos a la prueba de software, se obtienen una serie

de principios que servirn de base para la prueba:

Debe asegurarse de conocer con precisin los objetivos del

software a probar, as como sus indicadores de xito. Estos
elementos se localizan en los documentos obtenidos en la etapa
de recoleccin de requerimientos, as como en las especificaciones
del software. Esta informacin ser indispensable para preparar el
plan de pruebas y ser la base para iniciar el desarrollo de los
casos de prueba.
Deben determinarse las entradas y salidas del sistema aprobar.
ste aspecto es necesario en la preparacin de los casos de
prueba y tambin
en el establecimiento de procedimientos
de prueba, orientados especialmente a los casos de prueba que
muestran el cumplimiento de los objetivos.
Considerar el sistema mayor donde opera el software a
probar. Generalmente es un ambiente organizacional, formado
por elementos de hardware, de software y personas (usuarios).
Todos estos elementos influyen mucho sobre el sistema y ayudan
especialmente en la preparacin de casos de prueba de
situaciones no deseadas, relacionadas con datos inadecuados,
ausencia de elementos necesarios y ocurrencia de excepciones.

El proceso de prueba de un sistema tiene dos etapas que pueden estar

muy separadas en el tiempo:

La preparacin de las pruebas: La cual est muy ligada a la

obtencin de requerimientos, por lo que ocurre en las primeras
etapas del proyecto
La aplicacin de las mismas: Requiere del sistema completo o al
menos una integracin, como se denomina a un producto parcial,
an no liberado, para poder aplicar las pruebas, por lo que ocurre
en etapas avanzadas del proyecto.

15

La situacin exacta de estas partes depende del modelo de ciclo de vida

que se haya elegido, La etapa de preparacin de pruebas incluye al
menos tres actividades:

preparar un plan de pruebas.

preparar una lista de verificaciones de los requerimientos.
preparar casos de prueba.

Para ejecutar la segunda y la tercera actividades se requiere contar con

el documento de requerimientos.
La primera etapa de pruebas provee retroalimentacin para el anlisis
de requerimientos, identificando huecos, ambigedades y otros
problemas. Tambin provee valiosas sugerencias para el diseo y la
implementacin del sistema, si apenas est desarrollando.
La etapa de aplicacin de pruebas requiere del plan de pruebas y de
una versin del sistema que sea ejecutable (una integracin). Sobre sta
se aplicarn los casos de prueba que se prepararon, se analizarn
los resultados y se identificarn posibles defectos.
Esta segunda etapa provee retroalimentacin a la implementacin
y al diseo, mostrando posibles defectos que deben ser corregidos.
Tambin provee informacin que ser de utilidad en la liberacin del
sistema, su aceptacin, la estimacin de su confiabilidad y para su
mantenimiento.

La prueba de sistemas tiene varias suposiciones importantes:

Cada unidad que forma el sistema ha sido probada por

separado y se han eliminado sus defectos.
Las interfaces humano-computadoras (de texto o grficas) han
sido probadas tambin por separado.
Se han realizado pruebas de integracin para analizar la
interaccin entre partes del sistema y se han eliminado los
defectos identificados.

El segundo punto es importante, ya que algunas veces se confunde la

prueba de sistema con la prueba de la interfaz. La primera verifica la
interaccin de todas las partes, mientras que la segunda nicamente
16

analiza los elementos de la interfaz y posiblemente el manejo de

eventos asociados. Sin embargo, las herramientas que ayudan a la
prueba de interfaz pueden utilizarse para iniciar las pruebas de sistema.
PRUEBAS FUNCIONALES
Se denominan pruebas funcionales o Funcional Testing, a las pruebas de
software que tienen por objetivo probar que los sistemas desarrollados,
cumplan con las funciones especficas para los cuales han sido creados,
es comn que este tipo de pruebas sean desarrolladas por analistas de
pruebas con apoyo de algunos usuarios finales, esta etapa suele ser la
ltima etapa de pruebas y al dar conformidad sobre esta el paso
siguiente es el pase a produccin.
A este tipo de pruebas se les denomina tambin pruebas de
comportamiento o pruebas de caja negra, ya que los testers o analistas
de pruebas, no enfocan su atencin a como se generan las respuestas
del sistema, bsicamente el enfoque de este tipo de prueba se basa en
el anlisis de los datos de entrada y en los de salida, esto generalmente
se define en los casos de prueba preparados antes del inicio de las
pruebas.
Las pruebas funcionales en la mayora de los casos son realizadas
manualmente por el analista de pruebas, Al realizar pruebas funcionales
lo que se pretende en ponerse en los pies del usuario, usar el sistema
como l lo usara sin embargo el analista de pruebas debe ir ms all
que cualquier usuario, generalmente se requiere apoyo de los usuarios
finales ya que ellos pueden aportar mucho en el desarrollo de casos de
prueba complejos, enfocados bsicamente al negocio, posibles
particularidades que no se hayan contemplado adecuadamente en el
diseo funcional, el analista de pruebas debera dar fuerza a las pruebas
funcionales y ms an a las de robustez, generalmente los usuarios
realizan las pruebas con la idea que todo debera funcionar, a diferencia
del analista de pruebas que tiene ms bien una misin destructiva.
Su objetivo ser encontrar alguna posible debilidad y si la llega a ubicar
se esforzar por que deje de ser pequea y posiblemente se convertir
en un gran error, cada error encontrado por el analista de pruebas es un
xito, y se debera considerar como tal, en mi experiencia personal he
podido ver qu proyectos atrasados, o con algunos problemas de tiempo
sacrifican horas de pruebas, incluso se siente algn malestar si el tester
sigue encontrando errores, si no se corrige esta situacin los proyectos
en su gran mayora fracasaran o perdern ms tiempo an.
17

PRUEBAS UNITARIAS
Es el proceso de hacer pruebas sobre los componentes individuales
(subprogramas o procedimientos) de un programa. El propsito es
encontrar discrepancias entre la especificacin de la interfaz del mdulo
y su comportamiento real.
La base de este mtodo es el hacer pruebas en pequeos fragmentos de
nuestro programa. Estos fragmentos deben ser unidades estructurales
de nuestro programa encargados de una tarea especfica, en
programacin orientada a objetos podemos afirmar que estas unidades
son los mtodos o las funciones que tenemos definidos.
Tras realizar estas pruebas sobre los elementos unitarios de nuestro
programa podremos eliminar gran parte de los errores de los que podra
adolecer. Como ya sabemos cualquier prueba demuestra no la ausencia
de errores sino que revela la presencia de ellos. Las pruebas unitarias no
revelan errores en la integracin de las partes unitarias ni tampoco otros
problemas como el bajo rendimiento de las aplicaciones o problemas
derivados del sistema sobre el que est ejecutndose nuestro programa.
El objetivo de las pruebas unitarias es el aislamiento de partes del
cdigo y la demostracin de que Estas partes no contienen errores.
Una vez creados el conjunto de pruebas unitarias sobre un fragmento de
cdigo los beneficios obtenidos, incluso antes de ejecutar ninguna
prueba, son mltiples. Pasar a enumerarlos:

Simplificacin de la integracin, Las pruebas unitarias

eliminan las posibles incertidumbres y errores en lo que se espera
de cada una de las unidades ayudando a entender la integracin
de cada una de las partes.
Refactorizacin de cdigo, Una vez refactorizado el cdigo; las
mismas pruebas unitarias nos pueden servir para probar el nuevo
cdigo asegurndonos de que este sigue siendo vlido bajo la
nueva implementacin.
Documentacin, Las pruebas unitarias sirven como mtodo de
documentacin mismo. Los desarrolladores pueden ver a travs de
las pruebas unitarias cual es el objetivo de las distintas partes del
cdigo de una manera bsica.
Diseo, Cuando se desarrolla el software las pruebas unitarias
pueden tomar el lugar del diseo formal. Cada prueba unitaria
puede ser visto como un elemento de diseos que especifica las
18

clases, los mtodos y el comportamiento observable de la

aplicacin.
CAJA BLANCA (TECNICA)
Es un mtodo de pruebas de software que pone a prueba las estructuras
internas o funcionamiento de una aplicacin, en lugar de su
funcionalidad. En pruebas de caja blanca una perspectiva interna del
sistema, as como conocimientos de programacin, se utilizan para el
diseo de casos de prueba. El probador escoge entradas para ejercer
caminos a travs del cdigo y determinar las salidas apropiadas.
Se realiza cuando el tester accede al cdigo fuente de la aplicacin y en
consecuencia a los diferentes algoritmos y estructuras de datos
utilizadas. La implementacin de este tipo de pruebas requiere
habilidades de programacin, un conocimiento del framework de
desarrollo y un cierto conocimiento funcional que permita conocer qu
misin tienen determinadas clases y mtodos.

Entre las tcnicas de caja blanca ms conocidas tenemos la cobertura

que consiste bsicamente en la verificacin de que todos los caminos
lgicos de la aplicacin son alcanzables tericamente en funcin de los
diferentes valores de entradas de los parmetros. Este tipo de pruebas,
se automatizan con la ejecucin de pruebas unitarias.
Otra tcnica bastante conocida es la Mutation Testing que se suele
utilizar para verificar la bondad de los mtodos de testing utilizados. Se
basa principalmente en realizar ligeras modificaciones en el programa
que daran lugar a un comportamiento anmalo del mismo (resultados
distintos) y verificar si la estrategia de testing utilizada es capaz de
detectar estos cambios. Ejemplos de estos pequeos cambios lo
podemos tener modificando el operador en las guardas de sentencias
selectivas o iterativas, eliminando sentencias, etc.
19

Una de las tcnicas de caja blanca ms conocida es el anlisis esttico

de cdigo que tiene como objetivo principal evaluar (directa o
indirectamente) la deuda tcnica del software o lo que es lo mismo,
evaluar el grado de mantenibilidad del sistema.
La mantenibilidad del sistema es una caracterstica a la que no se suele
dedicar suficiente atencin, al fin y al cabo lo importante es que el
sistema funcione (algo de lo que estoy totalmente de acuerdo), pero que
una vez que se consigue debe ser compatible con el hecho de que el
sistema sea escalable y pueda ser modificado a un coste razonable.
Ventajas De Usar La Tcnica De Caja Blanca
TRANSPARENCIA: Por qu los analistas pueden ver el cdigo
fuente mientras el programa se est probando, cada lnea de
cdigo se puede analizar, al menos tericamente. Tiempo y
presupuesto a menudo dictan cmo se analiza a fondo el
cdigo. Si el software parece estar funcionando segn lo
previsto, las pruebas de caja blanca puede validar o no el
cdigo en s funciona como estaba previsto. Por ejemplo, piezas
intiles de cdigo, caminos innecesarios entre las operaciones y
prdidas de memoria se pueden detectar cuando un analista
puede ver el cdigo fuente.
SEGURIDAD: La seguridad es un factor importante en el
diseo de la mayora de los programas de software - para el
mismo software, y otro software que interacta con el sistema
que lo hospeda. Si el software se ha probado el uso de tcticas
y mtodos que pueden ser utilizados por los hackers, el
comportamiento del cdigo se puede controlar mediante las
pruebas de caja blanca, luego se analiza en busca de
vulnerabilidades que podran ser explotadas despus de que el
software ha sido puesto en libertad. Basndose nicamente en
las pruebas de caja negro no siempre se revelan la
vulnerabilidad por debajo de la capa de interfaz.
OPORTUNIDAD: Ser capaz de lanzar un nuevo software en el
momento oportuno es una consideracin importante en cada
proyecto. Por qu las pruebas de caja blanca no requiere la
interfaz de usuario que est terminado, la prueba se puede
realizar bajo se encuentra todava en la fase de desarrollo, la
interfaz grfica de usuario? Como resultado, los problemas de
software pueden ser detectados y tratados con mucha anterior.
Cada problema se detecta y se fija antes de que el producto
20

acabado reduce la cantidad de tiempo que de otra manera sera

necesaria durante la fase de pruebas de recuadro negro.
BENEFICIOS ECONMICOS: Las pruebas de caja blanca
puede ser ms caro que las pruebas de recuadro negro, porque
las habilidades necesarias para analizar el cdigo fuente.
Probadores caja blanca necesita una formacin en lenguaje de
programacin, mientras que los negros caja probador suelen
ser especialistas en garanta de calidad que slo necesitan
saber cmo utilizar la interfaz de usuario. Sin embargo, en el
ciclo global de desarrollo de productos, pruebas de caja blanca
puede dar lugar a un ahorro significativo en el programa si se
detectan defectos mediante pruebas de caja blanca, mientras
que el producto an est en fase de desarrollo.

Desventajas De Usar La Tcnica De Caja Blanca

Aunque las pruebas de caja blanca tienen grandes ventajas, no es
perfecta y contiene algunas desventajas:
Pruebas de caja blanca aporta complejidad a las pruebas
porque para ser capaz de probar todos los aspectos
importantes del programa, debe tener un gran conocimiento
del programa.
Pruebas de caja blanca requiere un programador con un alto
nivel de conocimiento debido a la complejidad del nivel de
pruebas que hay que hacer.
En algunas ocasiones, no es realista para poder probar
todas las condiciones existentes solo de la aplicacin y
algunas condiciones sern probados.
CAJA NEGRA (TECNICAS)
Las pruebas de caja negra son, ni ms ni menos que, pruebas
funcionales dedicadas a mirar en el exterior de lo que se prueba.
Estas pruebas se denominan de varias formas, pruebas de caja opaca,
pruebas de entrada/salida, pruebas inducidas por datoslos sinnimos
son muchos y muy variados.
Descripcin De Las Pruebas De Caja Negra

21

Las pruebas de caja negra se centran principalmente en lo que se

quiere de un mdulo, charter o seccin especfica de un software, es
decir, es una manera de encontrar casos especficos en ese modulo que
atiendan a su especificacin.
Las pruebas de caja negra se limitan a que el tester pruebe
con datos de entrada y estudie como salen, sin preocuparse de lo que
ocurre en el interior.
stas, principalmente, se centran en mdulos o charters de interfaz de
usuario (pantalla, ficheros, canales de comunicacin) pero suelen ser
tiles en cualquier mdulo ya que todos o la mayora tienen datos de
entrada y salida que se pueden comprobar y verificar.

Como cualquier otra prueba, las de caja negra se apoyan y basan en la

especificacin de requisitos y documentacin funcional, estos requisitos
suelen ser ms complejos que los internos, para ello realizaremos
una cobertura de especificacin que ser muy recomendable para
conseguir probar el mayor campo posible.
Limitaciones de las pruebas de caja negra
Lo ms deseable a la hora de realizar pruebas de caja negra es realizar
una cobertura completa, pero, en la mayora de los casos no es
suficiente, siempre hay que combinarlas con pruebas de integracin, ya
que por mucho que funcionen los datos de entrada/salida, por dentro o
en terceros sistemas, pueden existir defectos que no se estn teniendo
en cuenta. Estos defectos pueden no acarrear problemas a corto plazo,
pero a lo largo del tiempo aparecern y como dicen. Es mejor el
remedio que la enfermedad.

22

 CAJA GRIS (TECNICAS)

Pruebas de caja gris es una combinacin de pruebas de caja blanca y las

pruebas de recuadro negro. El objetivo de esta prueba es buscar los
defectos si alguno debido a la estructura incorrecta o el uso inadecuado
de aplicaciones. Pruebas de caja gris es tambin conocida como la
prueba translcida.
Visin En Conjunto
Un probador de recuadro negro no tiene conocimiento de la estructura
interna de la aplicacin para ser probado, mientras que un probador de
caja blanca conoce la estructura interna de la aplicacin. Un probador de
caja gris sabe parcialmente la estructura interna, que incluye el acceso a
la documentacin de las estructuras de datos internas, as como los
algoritmos utilizados.
Necesidades De Pruebas De Caja Gris

23

Pruebas de caja gris es beneficioso, ya que toma la tcnica sencilla de

prueba negro de cuadro y lo combina con los sistemas especficos de
cdigo en pruebas de caja blanca. Pruebas de caja gris se basa en el
requisito de generacin de casos de prueba porque presentan todas las
condiciones antes del programa se prueba utilizando el mtodo de
afirmacin. Lenguaje de especificacin de requisito se utiliza para
establecer los requisitos que hacen fcil de entender las necesidades y
verificar su exactitud tambin en la entrada para el requerimiento de
generacin de casos de prueba es los predicados y la verificacin
comentarse en el idioma especificacin de requisitos.
Unos

ejemplos son:
Modelo arquitectnico
Modelo de Diseo UML
Modelo de Estados

Ventajas De Las Pruebas De Caja Gris

Ofrece beneficios combinados. Sirve de ventaja en los testeos.

No intrusiva. Se basa en las especificaciones funcionales, vista
arquitectnicos, mientras que no en el cdigo fuente que se
hace demasiado invasiva.
Autora de prueba inteligente: probador de caja gris maneja
escenario de prueba inteligente, por ejemplo, la manipulacin
de tipo de datos, el protocolo de comunicacin, el manejo de
excepciones
Prueba imparcial: A pesar de todas las ventajas y
funcionalidades anteriores, las pruebas de caja gris mantienen
lmites para las pruebas entre probador y desarrollador.

Desventajas De Las Pruebas De Caja Gris

Cobertura de cdigo parcial: En las pruebas de caja gris, cdigo

fuente o binarios estn desaparecidos debido al acceso limitado
a los internos o la estructura de las aplicaciones que se traduce
en un acceso limitado para el cdigo camino recorrido
Identificacin de defectos: En aplicaciones distribuidas, es difcil
asociar la identificacin de defectos. Sin embargo, las pruebas
de caja gris es una gran ayuda para encontrar la forma
adecuada estos sistemas generan excepciones y cmo bien son
estas excepciones se manejan en los sistemas distribuidos que
tienen entorno de servicios web.
24

 Aplicaciones De Las Pruebas De Caja Gris

Es muy adecuado para las aplicaciones web. Aplicaciones Web

se han distribuido de red o sistemas; debido a la ausencia de
cdigo fuente o binarios que no es posible utilizar pruebas de
caja blanca. Negro pruebas de caja tambin no se utiliza debido
a solo contrato entre el cliente y el desarrollador, por lo que es
ms eficaz utilizar las pruebas de caja gris como informacin
relevante est disponible en Web Services Definition Language.

Pruebas de dominio funcional o de negocio. Las pruebas

funcionales se realiza, bsicamente, una prueba de las
interacciones del usuario con puede ser systems.As externos
pruebas de caja gris puede eficientemente trajes para pruebas
funcionales, debido a sus caractersticas, sino que tambin
ayuda a confirmar que el software cumple con los requisitos
definidos para el software.

VALIDACION Y VERIFICACION

La validacin y verificacin (V y V) de software se define como un

conjunto de procedimientos, actividades, tcnicas y herramientas que se
utilizan, paralelamente al desarrollo, para asegurar que un producto de
software cumpla con los requerimientos planteados por los usuarios
finales.
La visin del desarrollo de software, formada por un conjunto de fases,
no slo facilita el desarrollo, sino tambin el esfuerzo de la V y V. Se
puede dividir el esfuerzo de V y V indicando las actividades,
procedimientos y tcnicas a emplear en cada fase del ciclo de vida. Para
ello es necesario definir un Plan de Verificacin y Validacin de software
al inicio del proyecto que determine estas actividades.

Objetivos

Detectar y corregir los defectos tan pronto como sea posible en

el ciclo de vida del software.
Disminuir los riesgos, las desviaciones sobre los presupuestos y
sobre el programa de tiempos.
Mejorar la calidad y fiabilidad del software.
Mejorar la visibilidad de la gestin del proceso de desarrollo.
25

Valorar rpidamente
consecuencias.

los

cambios

propuestos

sus

La validacin tiene por objetivo determinar la correccin del producto

final con respecto a las necesidades planteadas por los usuarios finales
y, La verificacin tiene por objetivo demostrar la consistencia y
correccin del software entre las fases del ciclo de desarrollo de un
proyecto.
Se clasifican en 2 grandes grupos:
1. INSPECCIONES DE SOFTWARE: analizan y comprueban las
representaciones del sistema (los diagramas de diseo, el cdigo
fuente del programa). Se aplica a todas las etapas del proceso de
desarrollo y se complementan con algn tipo de anlisis
automtico del texto fuente y documentos asociados. Son tcnicas
de verificacin y validacin estticas, no requieren que el sistema
se ejecute.
2. PRUEBAS DE SOFTWARE: consisten en comparar datos tericos
con los resultados del software utilizando series de datos de
prueba, se examinan los resultados del software y su
comportamiento operacional para comprobar que se desempee
conforme a lo requerido. Es una tcnica dinmica de la verificacin
y validacin ya que requiere disponer de un prototipo ejecutable
del sistema.
Lo que buscamos descubrir con ambos tipos de pruebas son:

Defectos (bug): un defecto en el software como, por ejemplo, un

proceso, una definicin de datos o un paso de procesamiento
incorrectos en un programa.
Fallos (failure): La incapacidad de un sistema o de alguno de sus
componentes para realizar las funciones requeridas dentro de los
requisitos de rendimiento especificados.

PRUEBA DE INTEGRACIN
El proceso de integracin del sistema implica construir este a partir de
sus componentes y probar el sistema resultante
para encontrar
problemas que pueden surgir debido a la integracin de los
componentes. Los componentes que se integran pueden ser
componentes comerciales, componentes reutilizables que han sido
26

adaptados a un sistema particular, o componentes nuevos desarrollados.

Para muchos sistemas grandes, es probable que usen los tres tipos de
componentes. La prueba de integracin comprueba que estos
componentes funcionen realmente juntos, son llamados correctamente y
transfieren los datos correctos en el tiempo preciso a travs de sus
interfaces.
La integracin del sistema implica identificar grupos de componentes
que proporcionan alguna funcionalidad del sistema e integrar estos
aadiendo cdigos para hacer que funcione conjuntamente. Algunas
veces, Esto se denomina INTEGRACIN DESCENDENTE.

Integracin En Profundidad: integra todos los mdulos de un

camino de control principal de la estructura.

Por ejemplo, si se elige el camino de la izquierda se

integrarn primero los mdulos M1, M2 y M5. A continuacin,
se integrar M8 o M6. A continuacin se construyen los
caminos de control central y derecho.

Integracin Anchura: incorpora todos los mdulos directamente

subordinados a cada nivel, movindose por la estructura de forma
horizontal.

Por ejemplo, Los primeros mdulos que se integran son M2,

M3 y M4. A continuacin, sigue el siguiente nivel de control,
M5, M6, M7 y por ltimo M8.

27

De forma alternativa, pueden integrarse primero los componentes de

infraestructura que proporcionan servicios comunes, tales como el
acceso a bases de datos y redes, y a continuacin pueden aadirse los
componentes funcionales. Esta es la INTEGRACIN ASCENDENTE.

Se combinan los mdulos para formar los grupos 1,2 y 3. Cada uno de
los grupos se somete a prueba mediante un controlador (mostrado como
un bloque punteado). Los mdulos de los grupos 1 y 2 son subordinados
Ma. Los controladores D1 y D2 se eliminan y los grupos interaccionan
directamente con Ma. De forma similar, se elimina el controlador D3 del
grupo 3 antes de la integracin con el mdulo Mb. Tanto Ma como Mb se
integraran finalmente con el mdulo Mc y as sucesivamente.
En la prctica, para muchos sistemas, la estrategia de integracin es
una mezcla para ambas, aadiendo en incrementos componentes de
infraestructura y componentes funcionales. En ambas aproximaciones
de integracin, normalmente tiene que desarrollarse cdigo adicional
para simular otros componentes y permitir que el sistema se ejecute.
La principal dificultad que surge durante las pruebas de integracin es la
localizacin de los errores. Existen interacciones complejas entre los
componentes del sistema, y cuando se descubra una salida anmala,
puede resultar difcil identificar donde ha ocurrido el error. Para hacer
ms fcil la localizacin de errores, siempre debera utilizarse una
aproximacin incremental para la integracin y pruebas del sistema.
La prueba de Integracin tiene dos enfoques:

Integracin No-Incremental

28

Todos los componentes se integran al mismo tiempo y el

resultado integrado se prueba.

Este enfoque no es efectivo por que cuando se produce un

error, ste se puede asociar a diferentes componentes.

Integracin Incremental

Es cuando probamos un mdulo y lo integramos con los

que ya estn probados.

Tiene la ventaja de que los errores encontrados

generalmente estn asociados con el nuevo mdulo que
se acaba de integrar.

PRUEBAS DE HUMO
Esta prueba es utilizada cuando se ha desarrollado un producto software
empaquetado. Es diseado como un mecanismo para proyectos
crticos por tiempo, permitiendo que el equipo de software valore su
proyecto sobre una base slida. La prueba de humo comprende las
siguientes actividades:

Los componentes software que han sido traducidos al cdigo se

integran en una construccin. Una construccin incluye fichas de
datos, libreras, mdulos reutilizables y componentes de ingeniera
que se requieren para implementar una o ms funciones del
producto.

Se disea una serie de pruebas para descubrir errores que impiden

a la construccin realizar su funcin adecuadamente. El objetivo
ser descubrir errores bloqueantes que tengan la mayor
probabilidad de impedir al proyecto de software el cumplimiento
de su planificacin.

Es habitual en la prueba de humo que la construccin se integre

con otras construcciones y que se aplica una prueba de humo al
producto completo. La integracin puede hacerse bien de forma
descendente o ascendente.

La prueba de humo facilita una serie de beneficios cuando se aplica

sobre proyectos de ingeniera de software complejos y crticos por su
duracin:

29

Se minimiza los riesgos de integracin.

Se perfecciona la calidad del producto final.
Se simplifican el diagnstico y la correccin de errores.
El progreso es fcil de observar.

PRUEBAS DE REGRESION
La prueba de regresin consiste en volver a ejecutar un subconjunto de
pruebas que se han llevado a cabo anteriormente para asegurarse de
que los cambios no han propagado efectos colaterales no deseados. La
prueba de regresin es la actividad que ayuda a asegurar que los
cambios no introducen un comportamiento no deseado o errores
adicionales.
El conjunto de pruebas de regresin contiene tres clases diferentes de
casos de prueba:
1. Una muestra representativa de pruebas que ejercite todas las
funciones del software.
2. Pruebas adicionales que se centran en las funciones del software
que se van a ver probablemente afectadas por el cambio.
3. Pruebas que se centran en los componentes del software que han
cambiado.
PRUEBA DE ENTREGA
Las pruebas de entrega son normalmente prueba de caja negra en las
que el equipo de prueba se ocupa simplemente de demostrar si el
sistema funciona o no correctamente.
Las Pruebas de Entrega son el proceso de probar una entrega del
sistema que ser distribuido a los clientes. El principal objetivo de este
proceso es incrementar la confianza del suministrador en que el sistema
satisface sus requerimientos. Si es as este puede entregarse como un
producto o ser entregado al cliente. Para demostrar que el sistema
satisface sus requerimientos, tiene que mostrarse que ste entregue la
funcionalidad especificada, rendimiento y confiabilidad, y que no falla
durante su uso normal.
Las pruebas de entregas son normalmente un proceso de pruebas de
caja negra en las que las pruebas se derivan a partir de la especificacin
del sistema. El sistema se trata como una caja negra cuyo
comportamiento solo debe ser determinado estudiando su entradas y
30

salidas relacionadas. Otro nombre para esto es Pruebas funcionales,

debido a que el probador solo le interesa la funcionalidad y no la
implementacin del software.

PRUEBAS NO FUNCIONALES
Las Pruebas no funcionales se realizan para verificar que el software
desarrollado cumple con los requerimientos no funcionales establecidos
por el cliente y se centran ms en como trabaje el sistema.
El trmino de las pruebas no funcionales describen las pruebas
requeridas para medir las caractersticas de sistemas y software que
pueden ser cuantificadas en una escala variable como tiempos de
respuesta para las pruebas de rendimiento.
PRUEBAS DE COMUNICACIONES
Determinan que las interfaces entre los componentes del sistema
funcionan adecuadamente, tanto a travs de dispositivos remotos,
como locales. As mismo, se han de probar las interfaces
hombre/mquina.

PRUEBA DE RENDIMIENTO
Se centra en determinar la velocidad con la que el sistema bajo pruebas
realiza una tarea en las condiciones particulares del escenario de
pruebas. Este servicio ayuda a su organizacin a detectar los cuellos de
31

botella de su aplicacin, antes de que, sus usuarios sufran un mal

rendimiento, con la consecuente prdida econmica y frustracin de sus
clientes o empleados.
El objetivo es determinar si el usuario estar satisfecho con la velocidad
de la aplicacin, bajo condiciones de uso esperadas durante el da a
da.
Las pruebas de rendimiento son ejecutadas por medio de scripts
automatizados, stos se encargan de emular las acciones que realizara
un usuario final sobre la aplicacin bajo pruebas. Los scripts se ejecutan
en paralelo, cada uno de ellos emulando un usuario virtual, de esta
forma, anticipando la carga esperada cuando el sistema pase a
produccin. Durante la ejecucin de las pruebas, nuestros consultores se
encargan de vigilar el sistema, que recibe la carga por medio de
indicadores de rendimiento, esta accin es comnmente llamada
monitorizacin del sistema. En base a las mtricas obtenidas, Globe
Testing sugiere mejoras para optimizar el rendimiento del sistema y, de
esta forma, mejorar los tiempos de respuesta de la aplicacin.
Las pruebas de rendimiento tienen como objetivo anticipar los
problemas que puedan ocurrir una vez la aplicacin est en produccin.
Hacer pruebas de rendimiento significa dormir bien, sabiendo que su
sistema est preparado para la carga esperada.
No realizar pruebas de rendimiento supone, en muchos casos, una
prdida econmica, no solo causada por la falta de disponibilidad de sus
sistemas y el impacto que esto tiene en su produccin, sino tambin por
el impacto que la falta de servicio tiene en el usuario final (ya sea un
cliente que no volver a usar su eCommerce por falta de confianza, o un
empleado que siempre se quejar de la velocidad de su sistema SAP).
La metodologa en las cuales se basan las pruebas de rendimiento se
componen en 4 fases consecutivas bien diferenciadas:

Planificacin
Preparacin
Ejecucin
Cierre

Como se puede apreciar en el grfico, cada una de estas fases tiene una
serie de acciones que tienen, como ltimo fin, validar que el sistema
bajo pruebas funcionar a una velocidad aceptable por sus usuarios, una
vez que sea puesto en produccin.
32

PRUEBAS DE VOLUMEN
Consisten en examinar el funcionamiento del sistema cuando est
trabajando con grandes volmenes de datos, simulando las cargas de
trabajo esperadas

Capacidad de Almacenamiento.
Capacidad de procesamiento.
Mximo (actual o fsicamente posible) nmero de clientes
conectados (o simulados), todos ejecutando la misma funcin
(peor caso de desempeo) por un perodo extendido.
Mximo tamao de base de datos (actual o escalado) y mltiples
consultas ejecutadas simultneamente

Las pruebas de volumen hacen referencia a grandes cantidades de datos

para determinar los lmites en que se causa que el Sistema falle.
Tambin identifican la carga mxima o volumen que el sistema puede
manejar en un perodo dado. Por ejemplo, si el sistema est procesando
un conjunto de registros de Base de datos para generar un reporte, una
prueba de volumen podra usar una Base de datos de prueba grande y
verificar que el sistema se comporta normalmente y produce el reporte
correctamente.
El objetivo de esta prueba es someter al sistema a grandes volmenes
de datos para determinar si el mismo puede manejar el volumen de
datos especificado en sus requisitos.
Algunos ejemplos de escenarios de prueba de volmenes:

33

Un compilador puede ser alimentado por un programa para

compilar que sea absurdamente grande.
Un editor de nexos puede recibir un programa que contenga miles
de mdulos.
Un simulador de circuito electrnico puede recibir un circuito
diseado con miles de componentes.
Puesto que obviamente, la prueba de volumen es una prueba
costosa, tanto en tiempo de mquina como en personal, se debe
tratar de no exceder los lmites. Sin embargo, todo programa
debera ser expuesto, al menos, a algunas pruebas de volumen.

PRUEBAS DE INTEGRIDAD DE DATOS Y BD

Asegurar que los mtodos de acceso y procesos
adecuadamente y sin ocasionar corrupcin de datos.

funcionan

Consisten en demostrar que el sistema puede recuperarse ante fallos,

tanto de equipo fsico como lgico, sin comprometer la integridad de los
datos.
Pruebas de integridad de base de datos son pruebas de los mtodos y
procesos utilizados para acceder y gestionar datos (base de datos), para
asegurar que los mtodos de acceso, los procesos y las reglas de los
datos funcionan como se espera y que durante el acceso a la base de
datos, los datos no se corrompan, sean borrados, modificados o creados
de forma inesperada.
PRUEBAS DE OPERACIN
Consisten en comprobar la correcta implementacin de los
procedimientos de operacin, incluyendo la planificacin y control de
trabajos, arranque y re arranque del sistema.
PRUEBAS DE ENTORNO O AMBIENTE
Consisten en verificar las interacciones del sistema con otros sistemas
dentro del mismo entorno.
Estas pruebas validan que la configuracin y el entorno en los que se
ejecutarn los casos de prueba presenten caractersticas de hardware y
software similares al ambiente de produccin en el que residir la
aplicacin que se est probando.

34

PRUEBAS DE SEGURIDAD y CONTROL DEL ACCESO

Las pruebas de seguridad y control de acceso se centran en dos reas
claves de seguridad:
Seguridad del sistema, incluyendo acceso a datos o Funciones de
negocios y

Seguridad del sistema, incluyendo ingresos y accesos remotos al

sistema.

Cualquier sistema de cmputo que maneje informacin confidencial o

que desencadenen acciones que daen o beneficien inapropiadamente a
los individuos es un blanco para irrupciones impropias o ilegales. La
irrupcin abarca un amplio rango de actividades:

Hacker que tratan de entrar en los sistemas por juego.

Empleados disgustados que tratan de irrumpir como forma de
venganza.
Individuos deshonestos que buscan ganancias personales ilcitas.

La prueba de seguridad comprueba que los mecanismos de proteccin

integrados en el sistema
realmente lo protejan de irrupciones
inapropiadas.
Durante la prueba de seguridad, quien la aplica desempea el papel del
individuo que desea entrar en el sistema. Todo vale! Debe de tratar de
obtener contraseas por cualquier medio externo; podra atacar el
sistema con software personalizados, diseados para burlar cualquier
defensa que se haya construido; podra saturar el sistema, negando as
el servicio a otros; podra producir errores intencionales en el sistema
para tratar de tener acceso durante la recuperacin: podra revisar datos
sin proteccin, con la idea de encontrar la clave de acceso al sistema.
Si se dan el tiempo y los recursos suficientes, una buena prueba de
seguridad terminara por irrumpir en el sistema. El papel del diseador
del sistema es que el costo de la irrupcin sea mayor que el valor de la
informacin que habr de obtenerse.
PRUEBAS DE ALMACENAMIENTO
Los programas tienen de vez en cuando objetivos de almacenamiento
que indiquen, por ejemplo, la cantidad de memoria principal y
secundaria que el programa usa y el tamao de los archivos temporales.
35

Se disean casos de prueba para demostrar que estos objetivos de

almacenaje no han sido encontrados.
PRUEBAS DE CONFIGURACION
Estas pruebas verifican la operacin del sistema en diferentes
configuraciones de hardware y software. En la mayora de los ambientes
de produccin, las especificaciones para las estaciones de trabajo,
equipos de red y servidores pueden variar. Las estaciones pueden tener
diferentes versiones de software instaladas (Sistemas Operativos,
Drivers, etc.) y en cualquier momento, pueden llegar a utilizarse
diferentes combinaciones.
Con frecuencia, el nmero de configuraciones posibles es demasiado
grande para intentar una prueba de cada una de ellas, pero el programa
debe probarse al menos con cada tipo de dispositivo y con las
configuraciones mnima y mxima posibles.
PRUEBAS DE DESEMPEO
Validar el tiempo de respuesta para las transacciones o funciones de
negocios bajo las siguientes dos condiciones:

Volumen normal anticipado

Volumen mximo anticipado.

La prueba de desempeo est diseada para probar el desempeo del

software en tiempos de ejecucin dentro del contexto de un sistema
integrado. La prueba de desempeo se aplica en todos los pasos del
proceso de la prueba. Incluso al nivel de la unidad. El desempeo de un
mdulo individual debe de evaluarse mientras se realizan las pruebas.
Sin embargo, no es sino hasta que se encuentre totalmente integrado
todos los elementos del sistema que es posible asegurar el verdadero
desempeo del sistema.
Con frecuencia las pruebas de desempeo se vinculan con pruebas de
resistencia y suelen requerir instruccin de software y hardware. Es
decir, a menudo resulta necesario medir con exactitud la utilizacin de
recursos (por ejemplo: los ciclos de procesador).
Mediante instrumentacin externa pueden vigilarse de manera regular
los intervalos de ejecucin, los eventos que se registran (como las
interrupciones) y los estados de muestra del equipo. Si se instrumenta

36

un sistema, la persona que aplica la prueba descubrir situaciones que

lleven a la degradacin y posibles fallas del sistema.
Adicionalmente, las pruebas de desempeo pueden ser utilizadas para
perfilar y refinar el desempeo del sistema como una funcin de
condiciones tales como carga o configuraciones de hardware.
Las principales actividades son:

Comparar el desempeo del sistema actual con los requisitos,

Poner a punto el sistema para mejorar las mtricas de desempeo
y proyectar la capacidad futura de carga del sistema.

Los objetivos de nivel de servicio definidos deben guiar la prueba de

performance. Algunas caractersticas que afectan el desempeo son:

Errores lgicos
Procesamiento ineficiente
Diseo pobre: muchas interfaces, instrucciones y entradas/salidas.
Cuellos de botella en discos, CPU o canales de entrada/salida
Salidas del sistema
Tiempos de respuesta
Capacidad de almacenamiento
Tasa de entrada/salida de datos
Nmero
de transacciones que pueden ser manejadas
simultneamente.
Las pruebas de desempeo utilizan las tcnicas de caja blanca y
caja negra.

PRUEBAS DE IMPLANTACIN
El objetivo de las pruebas de implantacin es comprobar el
funcionamiento correcto del sistema integrando el hardware y software
en el entorno de operacin, y permitir al usuario que, desde el punto de
vista de operacin, realice la aceptacin del sistema una vez instalado
en su entorno real y en base al cumplimiento de los requisitos no
funcionales especificados.
PRUEBAS DE INSTALACION
Las pruebas de instalacin tienen dos propsitos. El primero es asegurar
que el sistema puede ser instalado en todas las configuraciones
posibles, tales como nuevas instalaciones, actualizaciones, instalaciones
completas o personalizadas, y bajo condiciones normales o anormales;
37

estas ltimas incluyen insuficiente espacio en disco, falta de privilegios

para algunas tareas, etc.
El segundo propsito es verificar que, una vez instalado, el sistema
opera correctamente. Esto usualmente implica correr un nmero
significativo de pruebas de Funcionalidad.
Los objetivos de las pruebas de instalacin son:
Verificar y validar que el sistema se instala apropiadamente en cada
cliente, bajo las siguientes condiciones:
Instalaciones nuevas, nuevas mquinas a las que nunca
se les ha instalado el sistema.
Actualizar mquinas previamente instaladas con el
sistema.
Instalar versiones viejas en mquinas previamente
instaladas con el sistema.
PRUEBAS DE LA DOCUMENTACION
Las pruebas de sistema tambin se refieren a la exactitud de la
documentacin del usuario. Una manera de lograr esto es utilizar la
documentacin para determinar la representacin de los casos
anteriores de prueba del sistema. Cuales quiera de los ejemplos
ilustrados en la documentacin se deben probar y hacer parte de los
casos y alimentarlos al programa.
El objetivo de esta prueba es evaluar la exactitud y claridad de la
documentacin del usuario y para determinar si el manual de
procedimientos trabajar correctamente como una parte integral del
sistema. Muchos defectos son identificados cuando un probador
competente chequea totalmente los manuales y documentacin del
usuario.
Muchos programas son parte de sistemas mayores, no completamente
automatizados,
que
contienen
procedimientos
realizados
por
operadores. Cualquier procedimiento humano, tal como los que llevan a
cabo el operador, el administrador de la base de datos, o el usuario de
terminal, debe ser probado durante la prueba de sistemas.
PRUEBAS DE RECUPERACION Y TOLERANCIA A FALLAS
Estas pruebas aseguran que una aplicacin o sistema se recupere de
una variedad de anomalas de hardware, software o red con prdidas de
datos o fallas de integridad.
38

Las pruebas de tolerancia a fallas aseguran que, para aquellos sistemas

que deben mantenerse corriendo, cuando una condicin de falla ocurre,
los sistemas alternos o de respaldo pueden tomar control del sistema sin
prdida de datos o transacciones.
Las pruebas de recuperacin son contrarias a las pruebas en que la
aplicacin o sistema es expuesto a condiciones extremas (o condiciones
simuladas), tales como fallas en dispositivos en entrada/salida o llaves o
apuntadores invlidos de base de datos. Los procesos de recuperacin
se invocan y la aplicacin es monitoreada y/o inspeccionada para
verificar que estos mecanismos se han ejecutado en forma apropiada.
Esta prueba evala las caractersticas de contingencia construidas en el
sistema para procesar interrupciones y para volver a puntos especficos
en el ciclo de procesamiento del sistema. La recuperacin debe ser
considerada en el proceso de diseo. Errores de programacin o de
datos pueden ser incorporados ex profeso en un sistema para
determinar si se puede recuperar de ellos. Las fallas de equipo (por
ejemplo errores de paridad en memoria, errores en dispositivos de
entrada/salida) pueden ser simuladas.
El objetivo de esta prueba es determinar la habilidad del sistema para
recuperarse de una falla de hardware o software.
Verificar que los procesos de recuperacin (manual o automtica)
restauran apropiadamente la Base de datos, aplicaciones y sistemas, y
los llevan a un estado conocido o deseado.
Los siguientes tipos de condiciones deben incluirse en la prueba:

Interrupcin de electricidad en el cliente.

Interrupcin de electricidad en el servidor
Interrupcin en la comunicacin hacia el servidor (cadas
de red)
Interrupcin en la comunicacin con los controladores de
disco.
Ciclos incompletos (procesos de consultas interrumpidos,
procesos de sincronizacin de datos interrumpidos)
Llaves o apuntadores de base de datos invlidos
Elementos corruptos o invlidos en la base de datos.

PRUEBAS DE RESISTENCIA

39

Los pasos de prueba analizados antes en este trabajo, llevan a una

evaluacin completa de las funciones y el desempeo normalmente del
programa. Las pruebas de resistencia estn diseadas para confrontar
los programas en situaciones anormales. En esencia, la persona que
realiza la prueba de resistencia se preguntara.
Hasta dnde llevar esto antes de que falle?
La prueba de resistencia ejecuta un sistema de tal manera que
requiera una cantidad, una frecuencia o volumen anormal de
recursos. Por ejemplo:

Se disea pruebas especiales que generen 10 interrupciones

por segundo cuando la taza de promedio es de una o dos.
Se aumenta la frecuencia de
entrada de datos una
magnitud que permita como responder las funciones de
entrada.
Se ejecutan casos de pruebas que requieran el mximo de
memoria u otros recursos.
Se disea casos de pruebas que causen problemas de
administracin de memoria.

PRUEBAS DE TENSION
La prueba de tensin es poner al programa a grandes cargas o
tensiones. Esto no se debe confundir con la prueba de volumen; una
gran tensin es volumen mximo de datos, o de actividad, en un tiempo
corto. Una analoga sera evaluar a un mecangrafo. Una prueba de
volumen se determinara si el mecangrafo hiciera frente a un bosquejo
de un informe grande; una prueba de tensin se determinara si el
mecangrafo puede mecanografiar a un ndice de 50 palabras por
minuto.

PRUEBAS DE USABILIDAD
Otra categora importante de casos de prueba de sistema es la tentativa
de encontrar problemas de factores humanos, o usabilidad. Sin
embargo, un anlisis de factores humanos sigue siendo una cuestin
altamente subjetiva.

40

Determina cun bien el usuario podr usar y entender la aplicacin.

Identifica las reas de diseo que hacen al sistema de difcil uso para el
usuario.
La prueba de usabilidad detecta problemas relacionados con la
conveniencia y practicidad del sistema desde el punto de vista del
usuario.
PRUEBAS DE COMPATIBILIDAD Y CONVERSION
El propsito es demostrar que los objetivos de compatibilidad no han
sido logrados y que los procedimientos de conversin no funcionan. La
mayora de los programas que se desarrollan no son completamente
nuevos; con frecuencia son reemplazos de partes deficientes, ya sea de
sistemas de procesamiento de datos, o sistemas manuales. Como tales,
los programas tienen a menudo objetivos especficos con respecto a su
compatibilidad y a sus procedimientos de conversin con el sistema
existente.
PRUEBA DE STRESS O ESFUERZO
Verificar que el sistema funciona apropiadamente y sin errores, bajo
estas condiciones de stress:

Memoria baja o no disponible en el servidor.

Mximo nmero de clientes conectados o simulados (actuales o
fsicamente posibles)
Mltiples usuarios desempeando la misma transaccin con los
mismos datos.
El peor caso de volumen de transacciones (ver pruebas de
desempeo)

La meta de las pruebas de stress tambin es identificar y documentar

las condiciones bajo las cuales el sistema FALLA.
Las pruebas de stress se proponen encontrar errores debidos a recursos
bajos o completitud de recursos. Poca memoria o espacio en disco puede
revelar defectos en el sistema que no son aparentes bajo condiciones
normales. Otros defectos pueden resultar de incluir recursos
compartidos, como bloqueos de base de datos o ancho de banda de la
red. Las pruebas de stress identifican la carga mxima que el sistema
puede manejar.
El objetivo de esta prueba es investigar el comportamiento del sistema
bajo condiciones que sobrecargan sus recursos. No debe confundirse con
41

las pruebas de volumen: un esfuerzo grande es un pico de volumen de

datos que se presenta en un corto perodo de tiempo.
Puesto que la prueba de esfuerzo involucra un elemento de tiempo, no
resulta aplicable a muchos programas, por ejemplo a un compilador o a
una rutina de pagos.
Es aplicable, sin embargo, a programas que trabajan bajo cargas
variables, interactivas, de tiempo real y de control de proceso.
Aunque muchas pruebas de esfuerzo representan condiciones que el
programa encontrar realmente durante su utilizacin, muchas otras
sern en verdad situaciones que nunca ocurrirn en la realidad. Esto no
implica, sin embargo, que estas pruebas no sean tiles.
Si se detectan errores durante estas condiciones imposibles, la prueba
es valiosa porque es de esperar que los mismos errores puedan
presentarse en situaciones reales, algo menos exigentes.
PRUEBAS GUI (INTERFAZ GRAFICA DE USUARIO)
La prueba de interfaz de usuario verifica la interaccin del usuario con el
software. El objetivo es asegurar que la interfaz tiene apropiada
navegacin a travs de las diferentes funcionalidades. Adicionalmente,
las pruebas de interfaz aseguran que los objetos de la interfaz a ser
probada se encuentran dentro de los estndares de la industria.

Verifica lo siguiente:

La navegacin a travs de los objetos de la prueba reflejan las

funcionalidades del negocio y requisitos, se realiza una
navegacin ventana por ventana, usando los modos de acceso
(tabuladores, movimientos del mouse, teclas rpidas, etc.)
Los objetos de la ventana y caractersticas, tales como mens,
medidas, posiciones, estados y focos se verifican conforme a los
estndares.

PRUEBAS DE ESTILO
Se entienden como tales el formato de las ventanas, colores
corporativos, tipos de letra etc. Comprobar que la aplicacin sigue los
estndares de estilo propios del cliente
PRUEBAS DE MULTIPLES SITIOS

42

Detectar fallas en configuraciones y comunicaciones de datos entre

mltiples sitios.
El propsito de esta prueba es evaluar el correcto funcionamiento del
sistema o subsistema en mltiples instalaciones.
PRUEBAS DEL CICLO DE NEGOCIO
Asegurar que el sistema funcione con el modelo de negocios emulando
todos los eventos en el tiempo y funcin del tiempo.
Procedimiento de prueba que evala el sistema a lo largo de todo un
ciclo completo de negocio, generalmente un ao fiscal u otra unidad de
tiempo similar. Se acompaa con todos los procedimientos necesarios
para evaluar en poco tiempo lo que de normal ocurre a lo largo de un
periodo de tiempo extenso.
PRUEBAS DE ACEPTACION
La prueba de aceptacin es ejecutada antes de que la aplicacin sea
instalada dentro de un ambiente de produccin. La prueba de
aceptacin es generalmente desarrollada y ejecutada por el cliente o un
especialista de la aplicacin y es conducida a determinar como el
sistema satisface sus criterios de aceptacin validando los requisitos que
han sido levantados para el desarrollo, incluyendo a documentacin y
procesos de negocio.

Basado en esta prueba el cliente determina si acepta o rechaza el

sistema
Estas pruebas estn destinadas a probar que el producto est listo
para el uso operativo.
Suelen ser un subconjunto de las Pruebas de Sistema.
Sirve para que el usuario pueda validar si el producto final se ajusta a
los requisitos fijados, es decir, si el producto est listo para ser
implantado para el uso operativo en el entorno del usuario.
Esta prueba es complementada por la prueba de estilo.

PRUEBAS ALFA Y BETA

Cuando se construye software a medida para un cliente, se lleva a cabo
una serie de pruebas de aceptacin para permitir que el cliente valide
todos los requisitos. La mayora de los desarrolladores de productos de
software llevan a cabo un proceso denominado pruebas alfa y beta para
descubrir errores que parezca que slo el usuario final puede descubrir.
43

 Pruebas Alfa
Se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el
software de forma natural con el desarrollador como observador del
usuario y registrando los errores y problemas de uso. Las pruebas alfa se
llevan a cabo en un entorno controlado.
Las pruebas -alfa consisten en invitar al cliente a que pruebe el
sistema en el entorno de desarrollo. Se trabaja en un entorno controlado
y el cliente siempre tiene un experto a mano para ayudarle a usar el
sistema. El desarrollador va registrando los errores detectados y los
problemas de uso.
Pruebas Beta
A en el entorno del cliente. En este caso, el cliente se queda a solas con
el producto y trata de encontrarle fallos de los que informa al
desarrollador.
Se llevan a cabo por los usuarios finales del software en los lugares de
trabajo de los clientes. A diferencia de la prueba alfa, el desarrollador no
est presente normalmente. As, la prueba beta es una aplicacin en
vivo del software en un entorno que no puede ser controlado por el
desarrollador. El cliente registra todos los problemas que encuentra
durante la prueba beta e informa a intervalos regulares al desarrollador.

7. CONCLUSIONES

En el desarrollo de software se deben tener en cuenta las etapas que

conforman el ciclo de vida del desarrollo de software para garantizar el
xito de una aplicacin.
Las pruebas de software permiten la ejecucin de un programa cuya
intencin u objetivo principal es el de detectar errores presentes en el
software con el fin de disminuirlos y corregirlos para que a su vez se
mejore la calidad con la que se produce el software.
Este tipo de pruebas deben ser realizadas por personal especializado en
la aplicacin de pruebas a nivel de software, el cual debe estar
familiarizado en el uso de herramientas de depuracin y pruebas,
44

igualmente deben conocer el lenguaje de programacin en el que se

est desarrollando la aplicacin.
Es mejor detectar a tiempo cualquier error por mnimo que sea, antes de
empezar a distribuir el producto al cliente.

8. WEBGRAFIA.

https://jummp.wordpress.com/2011/05/21/testing-de-caja-blancawhite-box-testing/
http://many-how.com/articulos/computadoras/programacionordenadores/article-158.html
http://docsetools.com/articulos-educativos/article_11483.html
https://leonardosc.files.wordpress.com/.../
verificacion-y-validacionde-software..doc
http://juankenny.blogspot.com/2012/08/vvs-la-verificacion-yvalidacion-de.html
http://datateca.unad.edu.co/contenidos/301404/301404_ContenidoEn
Linea/leccin_43__prueba_de_integracin.html
http://ing-sw.blogspot.com/2005/04/tipos-de-pruebas-desoftware.html
http://es.slideshare.net/abnergerardo/pruebas-de-sistemas-yaceptacion-23663195
http://www.calidadysoftware.com/testing/pruebas_funcionales.php
http://www.novanebula.net/blog/archives/99-Unit-testing-pruebasunitarias.html
http://www.globetesting.com/2012/08/pruebas-de-caja-negra/
http://docsetools.com/articulos-educativos/article_11753.html
https://prezi.com/t1ucw_krvvqu/pruebas-no-funcionales/
http://www.globetesting.com/pruebas-de-rendimiento/
http://www.carlosfau.com.ar/nqi/nqifiles/QA4%20Pruebas%20del
%20Software%20Parte%20B.pdf
http://www.klpsolutions.com/pages/services/control_calidad_pruebas_entorno.htm
45

http://indalog.ual.es/mtorres/LP/
https://crowdsourcedtesting.com/es/faq-clients/article/metodologiapruebas-de-software
http://www.ecured.cu/index.php/Pruebas_de_software
https://pruebasdelsoftware.wordpress.com
http://es.slideshare.net/GuillermoLemus/tipos-de-pruebas-de-software
http://www.lsi.us.es/~javierj/cursos_ficheros/02.SR.pdf
http://www.tamps.cinvestav.mx/~ertello/swe/swTestingTecZacatecas.
pdf
http://materias.fi.uba.ar/7548/Pruebas-Intro.pdf
https://pruebasdelsoftware.wordpress.com/tag/metodologia-depruebas/

46