TECNOLOGICO DE ESTUDIOS SUPERIORES DE COACALCO ING. EN SISTEMAS COMPUTACIONALES
VALIDACION Y VERIFICACION UNIDAD 2: “PRUEBAS”
Índice 2.1 Tipos de pruebas ............................................................................................... 3 2.2 Coberturas de las pruebas ................................................................................ 5 2.3 Preparación de las pruebas ............................................................................... 7 2.5 Criterios para la realización de pruebas ............................................................ 8 2.6 Plan de pruebas (verificación y validación) ....................................................... 8 2.7 Estructura de los casos de prueba .................................................................. 10 2.8 Conceptos generales de los diseños de las pruebas (verificación y validación) .............................................................................................................................. 10 2.9 Reporte y seguimiento de errores ............................................................... 11 2.10 Informe de las pruebas ................................................................................ 12 2.11 Fuentes de información de QA para el control estadístico o métrico ............ 14 2.13 Importancia de la calidad, métricas y control estadístico............................... 15 Conclusiones ......................................................................................................... 16 Referencias ........................................................................................................... 16
2.1 Tipos de pruebas Existen dos tipos diferentes de prueba, que se utilizan en las diferentes etapas de desarrollo del software: Las pruebas de defectos: Pretenden encontrar las inconsistencias entre un
programa y su especificación. Estas inconsistencias se deben habitualmente a los fallos o defectos en el código del programa. Las pruebas se diseñan para revelar la presencia de defectos en el sistema, más que para evaluar su capacidad operacional. Las pruebas estadísticas: se utilizan para probar el desempeño y la fiabilidad del
programa y comprobar cómo trabaja bajo condiciones operacionales. Las pruebas se diseñan para reflejar las entradas de los usuarios y su frecuencia. Después de llevar a cabo las pruebas, se puede hacer una estimación de la fiabilidad operacional del sistema contando el número de caídas observadas en el sistema. La capacidad del programa se valora midiendo el tiempo de ejecución y el tiempo de respuesta del sistema cuando procesa los datos estadísticos de la prueba. No existe una separación clara entre estos dos tipos de pruebas. Durante las pruebas de defectos los desarrolladores obtienen una visión intuitiva de la fiabilidad, y durante las pruebas estadísticas, se descubren obviamente muchos fallos. El objetivo de las pruebas de defecto es detectar los defectos latentes de un sistema software antes de entregar el producto. --Una prueba de defectos exitosa es aquella que descubre un fallo, esto es, un comportamiento contrario a la especificación. --Las pruebas de defectos demuestran la existencia de un fallo, y no la ausencia de cualquier fallo. Las pruebas exhaustivas no son posibles y deben sustituirse por subconjuntos de casos de prueba. Se deben establecer políticas para establecer esos casos de prueba. Por ejemplo: --Que todas las instrucciones del programa se ejecuten al menos una vez --Se deben probar todas las funciones del sistema que se acceden a través de menú.
--Si la entrada es introducida por el operador, todas las funciones deben probarse con entradas correctas e incorrectas. Pruebas funcionales (“Caja negra”) Las pruebas funcionales o de caja negras
es una política de selección de casos de pruebas basado en la especificación del componente o programa. Las pruebas se seleccionan en función de la especificación y no de la estructura interna del software. Las pruebas funcionales o de caja negra son una estrategia para seleccionar las pruebas de fallos basándose en las especificaciones de los componentes y programas, y no del conocimiento de su implementación. El sistema se considera como una caja negra cuyo comportamiento sólo se puede determinar estudiando las entradas y de contrastarlas con las respuestas que proporciona el sistema. Pruebas estructurales (“Caja blanca”) En las pruebas estructurales las pruebas
se seleccionan en función del conocimiento que se tiene de la implementación del módulo. Se suelen aplicar a módulos pequeños. El probador analiza el código y deduce cuántos y qué conjuntos de valores de entrada han de probarse para que al menos se ejecute una vez cada sentencia del código. Se pueden refinar los casos de prueba que se identifican con pruebas de caja negra. Pruebas de integración Se prueban la respuesta de grupos de módulos
interconectados a fin de detectar fallos resultantes de la interacción entre los componentes. Las pruebas de integración se realizan con referencia a las especificaciones del programa. La principal dificultad de las pruebas de integración es la localización de los fallos. Para facilitar la detección de los errores se utilizan técnicas incrementales. --Una vez que se han probado los componentes individuales del programa, deben integrarse para crear un sistema parcial o completo. En el proceso de integración hay que probar el sistema resultante con respecto a los problemas que surjan de las interacciones de los componentes. --Las pruebas de integración se desarrollan a partir de la especificación del sistema y se inician tan pronto como estén disponible versiones utilizables de algunos componentes del sistema.
2.2 Coberturas de las pruebas Uno de los principales problemas a la hora de realizar las pruebas de un sistema es el gran número de casos de prueba necesarios para obtener una seguridad de que el sistema bajo prueba funciona correctamente, o con otras palabras, tener un conjunto de casos de prueba con la calidad suficiente para estar seguros que el programa bajo prueba funciona correctamente. Un criterio de cobertura se puede entender según M. Broy et al. Con dos significados diferentes: - Como un criterio de adecuación, el cual sirve para determinar cuándo un conjunto de casos de prueba tiene la calidad suficiente, por lo que el sistema bajo prueba que probado correctamente - Como un criterio de selección el cual nos sirve para añadir casos de prueba nuevos a nuestro conjunto de casos de prueba y de esta manera mejorar la calidad del mismo. Ambos significados dan la idea de que los criterios de cobertura son interesantes para medir la calidad de los conjuntos de casos de prueba. Dentro d el ámbito de las pruebas de caja blanca, las cuales tienen en cuenta la estructura interna del programa bajo prueba para comprobar el correcto funcionamiento del mismo, los criterios de cobertura se pueden clasificar en base a los siguientes tres aspectos: Los criterios estructurales se usan para medir la calidad de un conjunto de casos de prueba. Esta calidad se mide en función del porcentaje alcanzado en función del criterio que se haya escogido. Como su propio nombre indica, estos criterios s definen en base a la estructura del programa bajo prueba, por ejemplo, si tenemos una máquina de estados, un criterio estructural podría definirse en función de los estados de la misma o en función de las transiciones. Una clasificación bastante aceptada de los diferentes criterios de cobertura para las pruebas de caja blanca, es clasificar estos criterios en dos grandes grupos: criterios basados en el flujo de control y criterios basados en flujo de datos. Criterios de cobertura basados en el flujo de control este tipo de criterios están
basados en las expresiones lógicas introducidas en la especificación del sistema bajo prueba que determinan cuando existen saltos o bucles dentro de la implementación, en otras palabras, se basa en las condiciones de las estructuras IfTHENELSE y los LOOP que existe dentro de la implementación del sistema. Los criterios de cobertura de este tipo más usados son los siguientes:
El criterio de cobertura de sentencias, es el criterio más simple de todos, define que han de recorrerse todas las líneas o sentencias del código del programa al menos una vez. El criterio de cobertura de decisiones o cobertura de ramas expuesto por primera vez en requiere que cada posible valor (verdadero o falso) que pueda tomar cada una de las decisiones del sistema bajo prueba se dé al menos una vez, sabiendo que una decisión es un conjunto de condiciones relacionadas mediante operadores lógicos (and, or…) y una condición es un conjunto de expresiones algebraicas relacionadas con operadores relacionales (<, <=, >, >=…). El siguiente criterio es la cobertura de condiciones, el cual requiere que cada
condición de cada decisión tome todos los posibles valores al menos una vez. Siguiendo con el ejemplo anterior, en este caso necesitaríamos dos casos de prueba, uno que evalúe A Falso y B verdadero y otro A Verdadero, y B Falso. A pesar de que este criterio es más restrictivo que el anterior no alcanza la cobertura de decisiones, ya que en el ejemplo siempre se evaluaría a falso la decisión y nunca se ejecutaría S. EL siguiente criterio de cobertura que soluciona los problemas de los dos anteriores, es el criterio de cobertura de condición decisión , el cual requiere que cada posible valor de cada condición de cada decisión del programa es producida al menos una vez y que además se produzca cada posible valor de cada decisión. Siguiendo el ejemplo anterior para este criterio nos bastaría con tener dos casos de prueba, uno que evaluase A falso y B falso y otro que evaluase A verdadero y B verdadero. De esta manera si un conjunto de casos de prueba cumple este criterio va a cumplir todos los criterios expuestos anteriormente. Criterios de cobertura basados en el flujo de datos este tipo de criterios de cobertura se basa en el análisis de los flujos de los datos. Aquí se requiere que los casos de prueba ejecuten secuencias de instrucciones en las cuales se asignen valores a variables y posteriormente se usen esos valores. Para definir estos criterios de cobertura hay que definir previamente lo que es el grafo de control asociado al sistema bajo prueba. Este grafo está compuesto por u na serie de nodos en los cuales se representan secuencias lineales de instrucciones y una serie de enlaces que representan trasferencias de control entre los nodos, de manera que a cada enlace se asocia una expresión booleanas que contiene la condición correspondiente a la trasferencia de control. El criterio de cobertura de todas las definiciones, se basa en que para cada variable exista al menos un caso de prueba de manera que este ejecute las instrucciones del sistema para que se recorra un camino en el grafo de control del sistema en el cual se defina la variable y a l menos se use una vez. Este criterio de cobertura no es muy rigoroso porque podemos tener conjuntos de casos de prueba que dejen sin probar muchos usos de las variables. Para solucionar ese problema existe el criterio de cobertura de todos los usos , en cual se basa en que para cada variable existan dentro del conjunto de casos de
prueba, suficientes casos de prueba para que se recorran los caminos del grafo de control del sistema en los que se defina la variable y se alcancen todos los usos de dicha, es decir, que se ejecuten en el mismo caso de prueba la definición junto con los usos de la variable y en el caso de que no se puedan cubrir todos los usos con un único caso de prueba, añadir más casos reprueba que cubran siempre la definición de la variable hasta que se cubran todos los usos de dicha variable. Este criterio a pesar de que cubre todos los usos de las variables tiene el problema de que existe la posibilidad de que a cada uso se pueda llegar desde varios caminos diferentes, porque puede ser que existan errores que se den solo llegando desde un camino concreto y no sean detectados por el conjunto de casos de prueba. Para solucionar el problema presentado anteriormente surge el criterio de cobertura de caminos definición/uso , el cual se basa en recorrer todos los caminos posibles desde la definición hasta el uso de una variable, para todos los usos de una variable y para todas las variables. Este criterio de cobertura es muy costoso de conseguir y además existe un problema con los bucles ya que estos introducen la posibilidad de que existan caminos infinitos.
2.3 Preparación de las pruebas A la hora de realizar este tipo de pruebas, es imposible probar una clase con todas sus posibilidades, ya que es impracticable probar todos los números enteros para un método que recibe un entero como parámetro, por ejemplo. Con lo cual, necesitamos criterios para elegir el conjunto de casos de prueba óptimos, de manera que podamos saber si el conjunto de casos de prueba tiene calidad o no. Un caso de prueba está bien elegido si cumple lo siguiente: - Reduce el número de casos necesarios para que las pr uebas sean de una calidad razonable. Esto implica que el caso ejecute el número máximo de posibilidades de entrada diferentes para así reducir el total de casos. - Cubre un conjunto extenso de otros casos posibles, es decir, indica algo acerca de la ausencia o la presencia de defectos en el conjunto específico de entradas, así como de otros conjuntos similares. En este tipo de pruebas existen algunas técnicas y criterios que nos pueden ayudar a seleccionar el conjunto de casos de prueba óptimo, las cuales se podrían adoptar para medir la calidad, aunque no han sido desarrolladas para ese fin, sino para seleccionar un conjunto de valores de prueba óptimo.
2.5 Criterios para la realización de pruebas Criterios de cobertura a parte de los criterios mencionados anteriormente existen otros criterios de cobertura que se suelen usar la práctica como: la cobertura de funciones, que se verifica cuando se han ejecutado todas las funciones del sistema bajo prueba; la cobertura de llamadas, que se verifica cuando se cubren todas las llamadas a funciones que existen en el programa bajo prueba y la cobertura de tablas, que se verifica cuando se han hecho referencia a todos los elementos de
las tablas En definitiva, estos criterios de cobertura pueden ser útiles para medir la cálida de los casos de prueba, siempre teniendo en cuenta que h ablamos de pruebas de caja blanca y tenemos acceso al código del programa bajo prueba. Cuando no hay acceso al código del sistema, todos los criterios expuestos anteriormente no se pueden usar, por lo que la calidad de las pruebas va a venir dada por los valores de prueba. Así, para medir la calidad tendremos que fijarnos en la cálida de los valores que usen los casos de prueba. Criterios de cobertura para los valores de las pruebas con estos criterios, viene a medirse el grado en que los diferentes valores interesantes seleccionados con una de las técnicas expuestas anteriormente o manualmente se utilizan en la batería de casos de prueba, ya que aunque seleccionemos valores de prueba de calidad para ejecutar las pruebas, las diferentes combinaciones de estos valores van a influir en la calidad final del conjunto de casos de prueba. El criterio de cobertura de cada uso (each-use, o 1-wise) es el más simple y el que menos calidad aporta al conjunto de casos de prueba. Se satisface cuando cada valor interesante de cada parámetro se incluye, al menos, en un caso de prueba, Así, mediante las técnicas expuestas anteriormente podríamos seleccionar como buenos valores de prueba 0, 1 y 2 para cada uno de los parámetros correspondientes a cada uno de los lados del triángulo. Un conjunto de casos de prueba que satisface el criterio 1-wise estaría formado por los casos de prueba que ejecutara los valores siguientes: (0, 1, 2), (2, 0, 1) y (1, 2, 0) sobre la funcionalidad descrita.
2.6 Plan de pruebas (verificación y validación) Proporcionan un plano o guía para el desarrollador del software, para la organización de control de calidad y para el cliente. Es una guía que describe los pasos a llevar a cabo como parte de la prueba, cuándo se de ben planificar y realizar esos pasos, y cuánto esfuerzo, tiempo y recursos se van a requerir., por lo tanto,
cualquier estrategia de prueba debe incorporar la planificación de la prueba, el diseño de los casos de prueba, la ejecución de las pruebas y la agrupación y evaluación de los datos resultantes. Etapas de un plan de pruebas
especificar los objetivos de las pruebas. determinar con precisión los criterios a seguir en su realización. Integrar al personal y los elementos necesarios para el desarrollo de las pruebas. Aplicación de la prueba o pruebas según los criterios seleccionados. evaluación de los resultados y consideraciones para llevar a cabo una nueva serie de pruebas.
Un enfoque estratégico para la prueba del software Generalmente se proporciona una plantilla para la prueba con las siguientes características generales: --La prueba comienza en el nivel de módulo y trabaja "hacia fuera", hacia la integración de todo el sistema basado en computadora. Se usa el enfoque “bottom up”.
--En diferentes momentos se utilizarán diferentes técnicas de prueba --La prueba la lleva a cabo el que desarrolla el software y (para grandes proyectos) un grupo de prueba independiente.
Figura 2: proceso de plan de pruebas
2.7 Estructura de los casos de prueba Existen múltiples técnicas para medir o asegurar la calidad de un conjunto de casos de prueba, como las mediciones de cobertura que alcanzan las pruebas, la cantidad de fallos encontrados por la pruebas…, sin embargo, todas estas técnicas, que son
estudiadas en las siguientes secciones, no contribuyen con sus mediciones a la evaluación de la calidad del conjunto de casos de prueba en el marco de un mo delo de calidad propiamente dicho, sino que simplemente son intentos de mejorar la calidad de forma práctica. De hecho no existe un modelo de calidad propiamente dicho para los conjuntos de casos de prueba, de manera que solo se podría aplicar el modelo presentado en la ISO 9126, adaptándolo convenientemente a las características del software referente al conjunto de casos de prueba.
2.8 Conceptos generales de los diseños de las pruebas (verificación y validación) Pruebas de la estructura de control La prueba de condición se centra en encontrar errores en condiciones lógicas en un módulo, aunque también puede detectar errores adicionales en el programa. En una condición se pueden dar los siguientes errores:
Error de operador lógico Error en una variable lógica. Error en una condición simple o compuesta. Error en un operador relacional. Error en una expresión aritmética.
La prueba de flujo de datos selecciona caminos de prueba de un programa de acuerdo con la ubicación de las definiciones y los usos de las variables del programa. La prueba de bucles es una técnica de prueba de caja blanca que se centra exclusivamente en la validez de las construcciones de condiciones. Hay cuatro tipos de estructuras de control: simples, concatenadas, anidadas y no estructuradas. De acuerdo al tipo de estructura es la prueba que se aplicará.
Pruebas de caja negra Métodos de prueba basados en grafos
Partición equivalente Análisis de valores límites Prueba de comparación Este tipo de prueba se centra en los requisitos funcionales del software y permite obtener entradas que prueben todos los requisitos funcionales del programa. Con este tipo de pruebas se intenta encontrar: Funciones incorrectas o ausentes. Errores de interfaz Errores en estructuras de datos o en accesos a bases de datos externas. Errores de rendimiento. Errores de inicialización y terminación. Prueba de comparación Esta técnica consiste en la comparación de salidas de un mismo software pero de sus diferentes versiones.
2.9 Reporte y seguimiento de errores Quien crea la entrada puede ser un desconocido al proyecto los reportes d e fallos y las solicitudes de características provienen tanto de los usuarios como de los desarrolladores. Una vez enviada, la entrada entra en un estado llamado abierto porque ninguna acción ha sido tomada aun. Algunos gestores etiquetan las nuevas entradas como sin verificar o como sin iniciar . No está asignada a nadie, o en algunos sistemas, es asignada a un usuario fantasma que representa la falta de una asignación real. Llegado a este punto, la entrada se encuentra en el área de espera: ha sido registrada, pero a un no ha sido integrada en la conciencia del proyecto. 1. Otros leen la entrada, añaden comentarios y quizás soliciten el esclarecimiento de algunos puntos a quien realizo la entrada. 2. El fallo es reproducido. Este puede que sea el momento más importante en su ciclo vital, ya que incluso que el fallo a un no ha sido resuelto, el hecho de que alguien haya podido reproducirlo además de quien creo la entrada prueba que es genuino y, no menos importante, confirma al creador de la entrada que ha contribuido al proyecto reportando un fallo real. 3. El fallo es diagnosticado : su causa es identificada, y si es posible, es estimado el esfuerzo requerido para repararlo. Hay que asegurarse de que todo esto es registrado en la entrada, ya que en el case en que quien haya hecho el diagnostico abandona el proyecto (lo cual sucede a menudo con desarrolladores voluntarios), alguien más debe ser capaz de continuar con su trabajo.
2.10
Informe de las pruebas
Informes de Verificación
Documento
Creado por Para quien
Fecha de liberación
Documento Creado por Para quien
Fecha de liberación
Documento
Creado por Para quien
Fecha de liberación
Se genera un documento Informe de Verificación Unitaria por cada prueba unitaria que se realice al sistema. Las personas que ejecutan las pruebas. Es el retorno para los implementadores de la tarea de verificación, que detalla los errores encontrados para que puedan ser corregidos. Será liberado luego de cada verificación unitaria. [Indique la versión y la fecha de liberación de todas las versiones de este informe.] Se genera un documento Informe Consolidación por cada consolidación que se realice al sistema. Las personas que ejecutan las pruebas. Es el retorno para los implementadores de la tarea de consolidación, que detalla los errores encontrados para que puedan ser corregidos. Será liberado luego de cada consolidación. [Indique la versión y la fecha de liberación de todas las versiones de este informe.] Se genera un documento Informe de Verificación de Integración por cada prueba de integración que se realice al sistema. Las personas que ejecutan las pruebas. Es el retorno para los implementadores de la tarea de verificación, que detalla los errores encontrados para que puedan ser corregidos. Será liberado luego de cada verificación de integración. [Indique la versión y la fecha de liberación de todas las versiones de este informe.
Documento
Creado por Para quien
Fecha de liberación
Se genera un documento Informe de Verificación de Sistema por cada prueba de sistema que se realice. Las personas que ejecutan las pruebas. Es el retorno para los implementadores de la tarea de verificación, que detalla los errores encontrados para que puedan ser corregidos. Será liberado luego de cada verificación de sistema. [Indique la fecha de liberación de este informe.]
Evaluación de la verificación
Documento
Creado por Para quien Fecha de liberación
Documento Creado por Para quien Fecha de liberación
Se genera un documento Evaluación de la verificación por cada prueba que se realice al sistema. Este documento contiene las fallas encontradas en el sistema, la cobertura de la verificación realizada y el estado del sistema. El Responsable de verificación, que toma como fuente de su trabajo los Informes de verificación. Es el resumen de la tarea de verificación y es el retorno para todo el equipo de trabajo del estado del sistema. Será liberado luego de cada verificación, unitaria, de integración y de sistema. [Indique la versión y la fecha de liberación de todas las versiones de este informe. El documento Informe final de verificación es el resumen de la verificación final del sistema antes de que sea liberado al entorno del usuario. El Responsable de verificación, que toma como fuente de su trabajo los Informes de verificación. Indica el estado del sistema. Será liberado luego de la verificación final del sistema.
2.11 Fuentes de información de QA para el control estadístico o métrico Elementos de medida. Medir es asignar números o símbolos a los atributos de una entidad de acuerdo a unas reglas definidas para caracterizar los atributos. Según esto tenemos los siguientes elementos de medida: Entidades, que deben de ser objeto de interés Atributos, que son las características de las entidades Reglas, que determinan la asignación de valores a los atributos. Métrica, es el establecimiento de un patrón que se utiliza de referencia para las medidas que tengan relación de homogeneidad con él. De esta manera se puede aceptar un convenio que permita definir la distancia entre dos elementos. Entidades y Atributos.
Algunos ejemplos de entidades pueden ser: Productos
Procesos
Recursos
Actividades
Organizaciones
Entornos
Pero entidades también pueden ser un conjunto de otras entidades. Por ejemplo, un proceso software puede contener a muchos subprocesos, y cada uno de ellos estar produciendo, transformando o transmitiendo productos asociados. De la misma manera, estos productos más atómicos, los subprocesos, y sus elementos de datos son en sí mismo entidades que determinadas organizaciones pueden desear caracterizar. Los atributos son características o propiedades de las entidades. De la misma manera que un coche puede describirse por su longitud, número de puertas, cilindrada, velocidad máxima o consumo, en definitiva atributos, las entidades software pueden definirse por atributos tales como tamaño, coste, tiempo, esfuerzo consumido, tiempo de respuesta, número de transacciones por unidad de tiempo, número de defectos encontrados, etc. La habilidad debe estar en saber que atributos deben usarse para obtener medidas que proporcionen datos útiles. Cada entidad está acompañada por algunos atributos que la caracterizan y por medidas que pueden ser usadas para cuantificar los atributos.
Entidades de Recursos
Personal asignado
Atributos
Tamaño del equipo
Número de personas asignadas
Experiencia
Años de experiencia en programación Nombre del perfil profesional (Jefe de proyecto, Analista, Programador)
Perfil profesional
Herramient Tipo as CASE Es usada ? Tiempo
Medidas posibles
Fecha Fecha fin Duración
Nombre del tipo Si/No comienzo, Fechas del calendario Días (laborables o de calendario).
Figura 6: Ejemplos de medidas de recursos Escalas de Medida las escalas de medida proporcionan valores y unidades para la
descripción de los atributos. Por ejemplo: un proyecto software puede producir 30.000 líneas de código, tener una duración planificada de 12 meses y usar 10.000 horas de esfuerzo para su desarrollo. Cada una de esas observaciones ha sido cuantificada con un valor a partir de una escala que se supone está bien definida. Cualquiera que sea la medida y su forma, siempre requiere de una escala bien definida para la captura y registro de los resultados de medida.
2.13 Importancia de la calidad, métricas y control estadístico Las medidas de los procesos y los productos, y por tanto los datos que de ellas se derivan, deben están orientadas a demostrar la adecuación y la eficiencia del sistema de gestión de la calidad de la organización. Del análisis de estos datos podrán encontrarse oportunidades de mejora, que junto con otras fuentes de información como resultados de auditorías, políticas de calidad de la organización,
etc. darán lugar a la puesta en marcha de acciones correctivas o preventivas en el intento de mejorar continuamente la eficacia del sistema de gestión de calidad. La figura 9 muestra un Sistema de Gestión de la Calidad basado en los procesos, tal como se define en ISO 9000:2000. Podemos observar cómo los procesos de medidas, análisis y mejora, son una parte integrada dentro del co njunto de procesos de la organización.
Conclusiones En este trabajo nos damos cuenta que tan importante son la pruebas en el desarrollo de software ya que si en ellas el software a realizar llevaría bastantes errores, son de suma importancia, si se realizan este tipos de pruebas se podrán corregir los errores encontrados a tiempo, y de igual forma poder corregirlo.
Referencias capacitacion y guia para el desarrollo del software. (s.f.). Obtenido de http://materias.fi.uba.ar/7548/PruebasSoftware.pdf
Mateo, P. R. (s.f.). Master en tecnologías informáticas avanzadas . Obtenido de http://alarcos.infcr.uclm.es/doc/cmsi/trabajos/Pedro%20Reales.pdf software . (s.f.). Obtenido de http://www.historianaval.cl/publico/publicacion_archivo/publicaciones/2_4.pdf
