Las Pruebas de Verificacin de Requerimientos

Preguntas claves:

Cundo se lleva a cabo el proceso de prueba? Cundo

comienza? Cundo culmina?
Cuntas pruebas?
Cules pruebas?
Quin realiza las pruebas?
Tipos de pruebas
A efectos del curso, aplicar el conocido diagrama en "V" del
desarrollo:

Anlisis de
requerimientos

Pruebas de sistema, pruebas de

verificacin (de requerimientos)

Diseo

Pruebas de integracin, pruebas

de subsistema.

Codificacin

Pruebas unitarias

Esta V es muy simplista por cunto no distingue entre una etapa

exploratoria de concepcin de un software y una etapa de
elaboracin.
1. LAS PRUEBAS DEL SISTEMA
Si bien en la prctica los trminos se manejan en forma
intercambiable, tcnicamente debemos distinguir entre las pruebas
del software completo (pruebas de verificacin de requerimientos) y
las pruebas del sistema que incorpora el software (pruebas del
sistema o pruebas de validacin del sistema). En el contexto de este
curso atenderemos fundamentalmente las pruebas de verificacin.

El objetivo de las pruebas de verificacin es buscar discrepancias entre los

requerimientos y la ejecucin del software.
Recuerde, de Sistemas de Programas, que probar es la actividad dedicada a encontrar
posibles defectos en un producto, no es determinar que un producto funcione. [Por qu?
Repasar barrera psicolgica: eltester como mdico diagnosticante].
El proceso de verificacin de los requerimientos comienza con el anlisis de esos
requerimientos y una inspeccin en la cual se busca evaluar la consistencia, completitud

y factibilidad de los requerimientos, tanto individualmente como juntos. Adicionalmente

los requerimientos deben ser revisados y validados por los distintos actores involucrados
con el sistema (stakeholders), accin que debe aclarar loscompromisos al respecto, tanto
en el sentido de trade-offs (prioridades y balance) entre requerimientos como en en el
sentido de commitments (compromisos que asumen los actores).
Para evitar sorpresas de variada ndole a la hora de entregar el software, es conveniente
especificar claramente qu vamos a hacer para determinar que el sistema satisface sus
requerimientos. Por ejemplo, no basta con decir que un sistema ser amigable o fcil de
usar, cmo se medir o verificar que el software es amigable?
Estas especificaciones son cruciales a la hora de disear las pruebas de verificacin.
Note que el diseo de estas pruebas requiere los siguientes pasos:
Revisar la verificabilidad del requerimiento;
Especificar el criterio de verificacin;
Hacer visible las propiedades o elementos del software
necesarios para verificar el cumplimiento del requerimiento;
Hacer controlable los elementos del software necesarios para
llevar a cabo las pruebas;
Elaborar el plan de pruebas;
Ejecutar el plan de pruebas y reportar sus resultados.
Ejemplo:
Tomemos un requerimiento de un software, tal como un atributo de
desempeo. La discusin anterior nos conduce a los siguientes pasos:
Revisar la verificabilidad del atributo. Supongamos que el
atributo restringe el tiempo de respuesta del software.
Especificar el criterio. Este puede darse en trminos absolutos
("el sistema debe responder a cualquier comando en menos de 2
segundos") o relativos a un modelo de desempeo.
Para hacer observable la propiedad que nos interesa (tiempo de
respuesta) tendremos que instrumentar el software o utilizar un
ambiente de ejecucin que permita obtener los tiempos que nos
interesan.
Para controlar el software, necesitamos poder variar los valores
de las entradas al sistema, as como otros elementos como
(posiblemente) el estado del software y la tasa, velocidad o
distribucin de presentacin de esas entradas. Para ello puede
ser que necesitemos escribir monitores, simuladores o
manejadores.
Pospondremos la discusin de los dos ltimos pasos.

Verificabilidad como requerimiento?

Se ha propuesto que la verificabilidad ( en Ingls, testability) es un
tipo de requerimiento de un sistema. De acuerdo con el grado de
verificabilidad que se desea obtener puede incrementarse o
disminuirse la cantidad de software de soporte necesario para llevar a
cabo las pruebas (p. ej. arneses de prueba, orculos, manejadores). En
mi opinin, la verificabilidad en abstracto no existe, siempre es
respecto a uno o ms requerimientos. Un software es verificable
respecto a un requerimiento en la medida que:
Las propiedades del software relevantes al requerimiento sean
visibles al ejecutar ese software (observabilidad);
Puede controlarse la ejecucin del software para explorar el
dominio del requerimiento (controlabilidad).
Cundo comenzar el proceso de pruebas de validacin?
La respuesta tradicional es al culminar la fase de codificacin.
La respuesta ms moderna es tan pronto como sea posible. [Por qu? Porque el anlisis
de la verificabilidad de los requerimientos y la elaboracin de los casos de prueba son
buenas formas de revisar los requerimientos y de detectar, de manera temprana,
problemas con ellos. Adicionalmente las necesidades de observabilidad y controlabilidad
forman parte de los requerimientos del diseo y permiten comenzar temprano el
desarrollo o bsqueda de software de apoyo a las pruebas].
Sin embargo, el proceso de pruebas debe adaptarse al macro-nivel o etapa del desarrollo.
Recuerden que en RPM, cada release pasa por las siguientes etapas: Exploracin,
Refinamiento del Plan, Construccin (Build) y Puesta en Marcha (Deploy). En una etapa
exploratoria, los requerimientos son menos precisas y ms fluidas, por lo que el proceso
de prueba puede ser muy informal; el proceso que hemos esgrimido usualmente resulta
demasiado pesado. En cambio, en una etapa de Construccin, el grueso de los
requerimientos deben ser ms precisos lo que conlleva mayor formalidad en el proceso
de prueba.
Los artefactos del desarrollo como fuente de pruebas
Los artefactos o diagramas de desarrollo son una rica fuente de
pruebas para el software desarrollado. En particular, podemos (y
debemos) crear pruebas de verificacin de los casos de uso, pruebas
que busquen errores en el manejo de las restricciones de integridad
de las clases del sistema, pruebas de verificacin de contratos y
pruebas de verificacin de diagramas de colaboracin.
2. PRUEBAS DE VERIFICACION:
En el proceso de V & V hay 2 aproximaciones complementarias para el anlisis y
comprobacin de los sistemas:

Las inspecciones de software: analizan y comprueban las representaciones del

sistema: el documento de requerimientos, los diagramas de diseo y el cdigo
fuente del programa. Pueden usarse inspecciones en todas las etapas del proceso.
Las inspecciones pueden ser complementadas con algn anlisis automtico del
cdigo fuente de un sistema o documentos asociados.
Las inspecciones de software y los anlisis automticos son tcnicas de V & V
estticas => pues no se necesita ejecutar software en la computadora.
Las pruebas del software implican ejecutar una implementacin del software
con datos de prueba. Se examinan las salidas del software y su entorno
operacional para comprobar que funciona tal y como se requiere. Las pruebas
son una tcnica dinmica de verificacin y validacin.

3. PRUEBAS DE INTEGRACION:
La prueba de integracin es una tcnica sistemtica para construir la estructura del programa mientras al
mismo tiempo, se lleva a cabo pruebas para detectar errores asociados con la interaccin. El objetivo es tomar
los mdulos probados en unidad y estructurar un programa que est deacuerdo con el que dicta el diseo. La
integracin puede ser descendente si se integran los mdulos desde el control o programa prinicpal, o bien,
asdendente, si la verificacin del diseo empieza desde los mdulos ms bajos y de all al principal. La
seleccin de una estrategia de integracin depende de las caractersticas depende de las caractersticas del
software y, a veces, del plan del proyecto, en algunos de los casos se puede combinar ambas estrategias.

4. PRUEBAS DE SUBSISTEMAS:
En este documento, se va a presentar el conjunto de pruebas relacionado con los
subsistemas de Delta Pensum 1.0 en su primera implementacion. La importancia de
este plan de pruebas es que sera llevado a cabo sobre los metodos y clases ya
probados, en este momento es que las funcionalidades separadas del sistema
comenzaran a probarse. Para probar los subsistemas de Delta Pensum 1.0, se va a
hacer uso de las herramientas suministradas por Binder. Dado que las pruebas se
realizaran a subsistemas separados, pero no disjuntos, nos daran un enfoque del

funcionamiento del sistema por partes, esto no significa que el comportamiento del
sistema completo sea correcto. Se dejara para otro plan de pruebas el chequeo de la
integracion de estos subsistemas. Este informe esta basado en los distintos patrones de
pruebas de subsistemas que se pueden observar en el capitulo 12 de Binder.

Enfoque: Binder nos ofrece en el captulo 12, cuatro patrones para diceo de pruebas
de subsistemas, las cuales nos presentan distintas estrategias para probar diferentes
funcionalidades en estos. Estas se describen a continuacion.

Pruebas de Asociacion de Clases: Nos permite disear planes de prueba que

ejerciten las asociaciones entre las clases de cada subsistema. Si van a ser usadas de la
forma como se describe posteriormente.
Pruebas de Control de Excepciones : Permite disear planes de prueba que ejerciten el manejo de
excepciones. No van a ser usadas en el ambito de subsistemas, porque se contemplaron para ser realizadas en
las pruebas de clases.

Pruebas de Escenarios de Ida y Vuelta : Permite disear un plan de pruebas que cubra todos los caminos
evento-respuesta en un diagrama de secuencia. Si van a ser usadas, y la forma de ejercitarlas se describe
posteriormente.

Pruebas de Modelo de Maquinas: Nos permite modelar el comportamiento de los estados de un

conjunto de clases y desarrollar un plan de pruebas basado en estados. No lo vamos a usar porque
involucran el uso de maquinas de estado, acerca de las cuales se dijo anteriormente la razon por la cual no se
iban a usar.

5. PRUEBAS DE UNITARIAS:
En programacin, una prueba unitaria es una forma de comprobar el correcto funcionamiento de un
mdulo de cdigo. Esto sirve para asegurar que cada uno de los mdulos funcione correctamente por
separado. Luego, con las Pruebas de Integracin, se podr asegurar el correcto funcionamiento del
sistema o subsistema en cuestin.
La idea es escribir casos de prueba para cada funcin no trivial o mtodo en el mdulo, de forma que
cada caso sea independiente del resto.

Caractersticas[editar]
Para que una prueba unitaria tenga la calidad suficiente se deben cumplir los siguientes requisitos:
Automatizable
No debera requerirse una intervencin manual. Esto es especialmente til para integracin
continua.
Completas
Deben cubrir la mayor cantidad de cdigo.
Repetibles o Reutilizables
No se deben crear pruebas que slo puedan ser ejecutadas una sola vez. Tambin es til
para integracin continua.
Independientes
La ejecucin de una prueba no debe afectar a la ejecucin de otra.
Profesionales

Las pruebas deben ser consideradas igual que el cdigo, con la misma profesionalidad,
documentacin, etc.
Aunque estos requisitos no tienen que ser cumplidos al pie de la letra, se recomienda seguirlos o de lo
contrario las pruebas pierden parte de su funcin.

Ventajas[editar]
El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las partes
individuales son correctas. Proporcionan un contrato escrito que el trozo de cdigo debe satisfacer.
Estas pruebas aisladas proporcionan cinco ventajas bsicas:
Fomentan el cambio
Las pruebas unitarias facilitan que el programador cambie el cdigo para mejorar su estructura (lo que
se ha dado en llamar refactorizacin), puesto que permiten hacer pruebas sobre los cambios y as
asegurarse de que los nuevos cambios no han introducido errores.
Simplifica la integracin
Puesto que permiten llegar a la fase de integracin con un grado alto de seguridad de que el cdigo
est funcionando correctamente. De esta manera se facilitan laspruebas de integracin.
Documenta el cdigo
Las propias pruebas son documentacin del cdigo puesto que ah se puede ver cmo utilizarlo.
Separacin de la interfaz y la implementacin
Dado que la nica interaccin entre los casos de prueba y las unidades bajo prueba son las interfaces
de estas ltimas, se puede cambiar cualquiera de los dos sin afectar al otro, a veces usando objetos
mock (mock object) para simular el comportamiento de objetos complejos.
Los errores estn ms acotados y son ms fciles de localizar
Dado que tenemos pruebas unitarias que pueden desenmascararlos.

Limitaciones[editar]
Es importante darse cuenta de que las pruebas unitarias no descubrirn todos los errores del cdigo.
Algunos enfoques se basan en la generacin aleatoria de objetos para amplificar el alcance de las
pruebas de unidad.1 Esta tcnica se conoce como testing aleatorio (RT, por random testing). Por
definicin, slo prueban las unidades por s solas. Por lo tanto, no descubrirn errores de integracin,
problemas de rendimiento y otros problemas que afectan a todo el sistema en su conjunto. Adems,
puede no ser trivial anticipar todos los casos especiales de entradas que puede recibir en realidad la
unidad de programa bajo estudio. Las pruebas unitarias slo son efectivas si se usan en conjunto con
otras pruebas de software.

Herramientas[editar]
JUnit: Entorno de pruebas para Java creado por Erich Gamma y Kent Beck. Se encuentra
basado en SUnit creado originalmente para realizar pruebas unitarias para el lenguaje
Smalltalk.
TestNG: Creado para suplir algunas deficiencias en JUnit.

 JTiger: Basado en anotaciones, como TestNG.

SimpleTest: Entorno de pruebas para aplicaciones realizadas en PHP.
PHPUnit: Sistema para la realizacin pruebas unitarias en PHP.
CPPUnit: Versin del framework para lenguajes C/C++.
NUnit: Versin del framework para la plataforma.NET.
FoxUnit: Entorno OpenSource de pruebas unitarias para Microsoft Visual FoxPro
MOQ: Entorno para la creacin dinmica de objetos simuladores (mocks). MOQ.
QUnit: Librera para pruebas unitarias en Javascript. Creada por la fundacin jQuery, ha sido
reescrita para ser independiente de la librera jQuery.
libunittest: Librera portable para pruebas unitarias en C++ que usa el nuevo estndar C++11.
CUnit: Entorno para escribir, administar y correr test unitarios en lenguaje C.

TIPOS DE PRUEBAS:

TIPOS DE PRUEBAS ESTTICAS

Revisiones gerenciales: Tienen por objetivo asegurar el progreso del proyecto, un
correcto uso de los recursos y recomendar acciones correctivas. Tienen un grado
medio de formalidad. Participan el responsable del proyecto, lderes tcnicos e
ingenieros. Generalmente el responsable del proyecto tiene el liderazgo de la revisin.
Las decisiones se toman en la reunin y/o como resultado de las recomendaciones. La

verificacin de cambios y correcciones se deja para otros puntos de control del

proyecto.
Revisiones tcnicas: Tienen por objetivo evaluar la conformidad de un producto con
respecto a especificaciones, planes y asegurar la integridad tcnica y conceptual de
los cambios. Tienen un grado medio de formalidad. Participan lderes tcnicos e
ingenieros. Generalmente el lder tcnico tiene el liderazgo de la revisin. Las
discrepancias son investigadas para confirmarlas. El lder tcnico debe verificar los
cambios que resulten necesarios.

Walkthroughs: Es una reunin informal entre analistas y usuarios para la evaluacin

de propuestas informacionales, generalmente es requerida una pequea preparacin
de documentos.
Tienen por objetivo detectar defectos de un producto, examinar alternativas y generar
un foro de aprendizaje. Tienen un bajo grado de formalidad. Participan colegas del
responsable del producto. Generalmente el mismo productor tiene el liderazgo de la
revisin. El productor decide si realizar los cambios y correcciones. La verificacin de
cambios y correcciones se deja para otros puntos de control del proyecto.

Inspecciones: La inspeccin es una reunin formal luego del walkthrough,

generalmente incluye personal de diferentes sectores esencialmente analistas,
programadores, y personal de prueba (testers) donde acuerdan con los usuarios los
mtodos de seguridad prueba a llevar a cabo. A menudo en estas reuniones se incluye
un moderador el cual representa a la empresa y que da a conocer al usuario una lista
de operaciones de mtodos de prueba y controles de calidad en las cuales el usuario
debe optar definiendo el mismo el nivel de calidad.
Tienen por objetivo detectar e identificar defectos de un producto y verificar su
correccin. Tienen un alto grado de formalidad. Participan ingenieros pares del
responsable del producto. El moderador tiene el liderazgo de la revisin. Los defectos
deben ser removidos. La verificacin de cambios y correcciones es obligatoria en el
proceso.

Revisiones por Pares

Una de las mejores prcticas de software es el uso de las Revisiones por Pares (Peer
Reviews), estas son una de las formas ms eficientes y efectivas para identificar
defectos en los productos de software. Existen estudios que muestran diferentes
beneficios en su aplicacin, desde el ms relevante que es la identificacin temprana
de defectos, as como la mejora en la productividad y esparcimiento del conocimiento
tcnico. Empresas comprometidas con la calidad implementan algn tipo de revisin
dentro de sus procesos.
Existen diferentes formas de inspecciones, desde revisiones informales (walkthrough)
realizadas con el apoyo de un colega, hasta las revisiones formales (inspecciones) que
son ms sistemticas y rigurosas. Cada una de ellas difiere en la formalidad, tiempo
dedicado, rigor, efectividad y costo, por lo que sera necesario revisar cual tiene mejor
costo-beneficio para nuestra organizacin dependiendo de la complejidad, y el riesgo
asociado a cada producto de software.
Para la realizacin de las revisiones existen diferentes mtodos (Fagan, Gilb/Graham)
en los que nos podemos apoyar para implementar la prctica en nuestra organizacin.

Para su aplicacin debemos definir el contexto en el que vamos a usar las revisiones,
los criterios para aplicarlas y como evaluar su efectividad. No resta decir que los
participantes deben de estar capacitados en el mtodo a utilizar.
Adicional, a la deteccin de defectos, las revisiones por pares son una excelente
herramienta para compartir conocimiento entre los integrantes de la organizacin al
tener acceso, miembros con menos experiencia, al trabajo de gente mas
experimentada. De igual forma, las revisiones ayudan a los miembros de una
organizacin a socializar, intercambiar opiniones y a hacer trabajo en equipo.
El uso de las revisiones por pares es un complemento para el rea de pruebas, cada
una se enfoca a una parte diferente del proceso, de los productos de trabajo, y se
requiere de habilidades diferentes. Por ejemplo en una revisin por pares podemos ver
si un producto de trabajo cumple con los estndares de calidad definidos, si tiene
claridad, si es fcil de mantener, si es completo, cosa que con las pruebas no lo
podemos hacer.
El implementar un proceso efectivo de revisin por pares requiere de seriedad y
compromiso de la organizacin para obtener lo mejor de esta prctica. Un punto
importante para el xito de las revisiones por pares es que se revisa el producto de
trabajo, No al autor del producto.

INSPECCIONES DE SOFTWARE

Implican que las personas examinen la representacin de la fuente con el

propsito de descubrir anomalas y defectos

Las inspecciones no requieren la ejecucin de un sistema por lo que debe

utilizarse antes de la implementacin.

Pueden estar aplicados a cualquier representacin del sistema (requerimientos,

diseo, configuracin, datos, pruebas de datos, etc).

Se ha demostrado que es una tcnica efectiva para descubrir errores del

programa.

xito de la inspeccin

Pueden descubrirse muchos diferentes defectos en una sola inspeccin. Al

probar, un defecto puede enmascarar a otro as que se requieren varias
ejecuciones

Inspecciones y pruebas

Las inspecciones y pruebas son complementarias y no tcnicas opuestas de

verificacin.

Ambas deben utilizarse durante el proceso V & V.

Las inspecciones pueden comprobar el ajuste con una especificacin pero no la

conformancia con los requerimientos reales del cliente.

Las inspecciones no pueden comprobar caractersticas no funcionales como

rendimiento, usabilidad, etc.

Inspecciones de programas

Es la aproximacin formalizada a las revisiones del documento

Est pensado explcitamente para la deteccin de defectos (no su correccin)

Los defectos pueden ser errores lgicos, anomalas en el cdigo que pueden
indicar una condicin errnea (p.ej: una variable no iniciada) o no conformidad
con los estndares.

Precondiciones de la inspeccin

Debe haber una especificacin precisa disponible.

Los miembros del equipo deben estar familiarizados con los estndares de
organizacin.

Debe estar disponible un cdigo sintcticamente correcto u otras

representaciones del sistema.

Debera prepararse una lista de errores.

La gestin debe aceptar que la inspeccin aumentar los costes pronto en el

proceso de software.

La gestin no debera utilizar inspecciones para la evaluacin del personal, es

decir, para encontrar quin comete errores.

Proceso de inspeccin

Visin de conjunto del sistema presentado al equipo de inspeccin.

Los cdigos y documentos asociados se distribuyen al equipo de inspeccin por

adelantado.

La inspeccin tiene lugar y se anotan los errores encontrados.

Se hacen modificaciones para reparar los errores descubiertos.

Puede requerirse o no una reinspeccin.

Listas de inspeccin

Debera utilizarse una lista de errores comunes para guiar la inspeccin.

Las listas de errores dependen del lenguaje de programacin y reflejan los

errores caractersticos que es probable que aparezcan en el lenguaje.

En general cuanto ms dbil sea la comprobacin del tipo, ms grande ser

la lista.

Ejemplos: inicializacin, nombramiento de constantes, terminacin de bucles,

lmites de vectores, etc.

Cifras de inspeccin

500 sentencias/hora durante la visin de conjunto.

125 sentencias de cdigo fuente/hora durante la preparacin individual.

Pueden inspeccionarse de 90 a 125 sentencias/hora.

Por lo anto la inspeccin es un proceso caro.

Inspeccionar 500 lneas cuesta el esfuerzo de unas 40 horas/hombre

4146 en cifras espaolas).

(unos

VALIDACIN DE REQUERIMIENTOS
Validacin
Consiste en actividades de detectar y corregir cualquier requisito innecesario e incorrecto.
Proceso de comprobacin de que estos requisitos fueron especificados de acuerdo a las
necesidades de los clientes.
Evita el riesgo de realizar una mala implementacin.

Seleccionar e integrar las tcnicas de validacin de requerimientos.

Identifique la tcnica de validacin ms apropiada.
Escoger una combinacin de tcnicas, diferentes tcnicas para diferentes
representaciones y partes delos requerimientos.
Validar los requerimientos de alto riesgo a inicio del proceso, para reducir los riesgos
generales.
Integrar las actividades de validacin a travs del desarrollo de requisitos.
Asegurar la participacin adecuada del usuario.
Verificar que los requerimientos del usuario describan la forma en que interactan con
los usuarios.
Los interesados comprueban que los requisitos estn completos, consistentes y sean de
alta calidad.(Revisar la documentacin).
Asegrese que los requerimientos funcionales provienen de los requerimientos del
negocio
Valide los requerimientos.
Implica comprobar que un subconjunto de los requisitos estn bien definidos, esto se lo
debe realizara principios del desarrollo de los requisitos y no cuando se tenga el detalle de
los modelos de anlisis.
Revisar la documentacin de requerimientos
Revisar la documentacin basados en la retroalimentacin de la etapa anterior.
Realizar el anlisis de los requisitos para saber cmo los cambios afectan al proyecto.

 Priorizar algn requerimiento que cambie, a causa delas actividades de validacin.

Repetir el ciclo a medida que avanza el proceso de desarrollo de requerimientos.
Herramientas y tcnicas de Validacin Cuando Ud. Necesite Se debe realizar
Revisin de pares.
Revisar requerimientos
Documentar requerimientos Crear pruebas de validacin.
Pruebas de aceptacin de usuario. Pruebas sobre modelos de requerimientos.
Valide los modelos Mostrar partes del sistema. Prototipos Operacionales.

Validacin de Requerimientos y Diseo

Lograr los Objetivos y Cumplir los Requerimientos Clave
La verificacin de validacin es esencial para garantizar la calidad del producto, cumplir con los estndares, cumplir los
requerimientos, eliminar los errores y costos de garanta, y optimizar los diseos para rendimiento y capacidad de manufactura.
NX te brinda herramientas de software de validacin de diseo que supervisan automtica y continuamente tus diseos y
adherencia a los estndares y requisitos.
Validacin de Requerimientos Integrados
La Validacin de requerimientos de NX admite la ingeniera de sistemas con herramientas de revisiones automatizadas. Al
trabajar en conjunto con Teamcenter, puedes asignar requerimientos a los subsistemas de productos y validar los productos
para su cumplimiento con los requerimientos a medida que diseas. La Validacin de requerimientos de NX promueve una
comprensin comn de los objetivos y qu tan bien los logran los productos.

Bibliografa:
http://www.ctr.unican.es/asignaturas/Ingenieria_Software_4_F/Doc/M7_09_VerificacionV
alidacion-2011.pdf
http://www.fing.edu.uy/tecnoinf/mvd/cursos/ingsoft/material/teorico/is09-VerificacionValidacion.pdf
http://ldc.usb.ve/~teruel/ci4713/clases2001/testReqs
https://es.wikipedia.org/wiki/Pruebas_de_validaci%C3%B3n
http://mmedia1.fi-b.unam.mx/material/t1046/tutorial/tutorial-VV.pdf
http://sistemas.unla.edu.ar/sistemas/sls/ls-4-optativa-algoritmos-y-lenguajes-pruebadel-software/pdf/Pruebas-de-Software-C04-Tipos-de-pruebas-estaticas.pdf
http://www.academica.mx/blogs/las-pruebas-integraci%C3%B3n-software
http://ldc.usb.ve/~teruel/southpark/DP/pruebas/documentos/planSubsistema