“Año de la Lucha contra

la Corrupción e
Impunidad”

ESCUELA PROFESIONAL INGENIERIA DE SISTEMAS

CURSO:
TECNOLOGÍA DE LA

PROGRAMACION II

DOCENTE:
Mg. VIDAL MELGAREJO, ZORAIDA

CICLO:
V

ALUMNOS:
 AMAYA MONZÓN,Marjourie
 CEVERA VASQUEZ, Estefany
 MIRANDA SALAS, Baru
 PINEGRO DIAZ,Jesús
 ROJAS CUEVA, Anthony 2019
0
 INTRODUCCIÓN
ÍNDICE
Taller de pruebas de software --------------------------------------------------------- Pág. 2
Pruebas estáticas --------------------------------------------------------------------------- Pág. 2
Pruebas dinámicas --------------------------------------------------------------------------- Pág. 2
Métodos de pruebas
 Pruebas de Caja Blanca --------------------------------------------------------- Pág. 2
 Pruebas de caja negra --------------------------------------------------------- Pág. 3
 Testing aleatorio ------------------------------------------------------------------ Pág. 4
Clasificación de las pruebas según lo que verifican
 Pruebas funcionales

Pruebas unitarias --------------------------------------------------------- Pág. 5

Pruebas de integración ------------------------------------------------ Pág. 5
Pruebas de sistema ----------------------------------------------------- Pág. 5
Pruebas de humo --------------------------------------------------------- Pág. 7
Pruebas alpha ----------------------------------------------------------- Pág. 7
Pruebas beta -------------------------------------------------------------- Pág. 7
Pruebas de aceptación ------------------------------------------------ Pág. 7
Pruebas de regresión --------------------------------------------------- Pág. 8
Niveles de prueba ------------------------------------------------------------------ Pág. 8
 Pruebas no funcionales
Pruebas de compatibilidad -------------------------------------------- Pág. 9
Pruebas de seguridad ------------------------------------------------ Pág. 10
Pruebas de Stress ------------------------------------------------------ Pág. 11
Pruebas de usabilidad ------------------------------------------------ Pág. 12
Pruebas de rendimiento ------------------------------------------------ Pág. 12
Pruebas de internacionalización y localización ------------------- Pág. 12
Pruebas de escalabilidad ------------------------------------------------ Pág. 13
Pruebas de mantenibilidad -------------------------------------------- Pág. 13
Pruebas de instalabilidad ------------------------------------------------ Pág. 13
Pruebas de portabilidad ------------------------------------------------ Pág. 13
Herramientas para realizar pruebas de software

 Herramientas Open Source ------------------------------------------------------ Pág. 14

 Herramientas comerciales ------------------------------------------------------ Pág. 15

Bibliografía ------------------------------------------------------------------------- Pág. 17

1
2
 INTRODUCCIÓN
- El sistema ya se ha desarrollado por completo
- ¿se acaba aquí el trabajo? NO
a. Pruebas del sistema
b. Implantación del sistema
c. Mantenimiento del sistema

TALLER DE PRUEBAS DE SOFTWARE

Las pruebas de software (en inglés software testing) son las investigaciones

empíricas y técnicas cuyo objetivo es proporcionar información objetiva e

independiente sobre la calidad del producto a la parte interesada. Es una actividad

más en el proceso de control de calidad.

Las pruebas son básicamente un conjunto de actividades dentro del desarrollo

de software. Dependiendo del tipo de pruebas, estas actividades podrán ser

implementadas en cualquier momento de dicho proceso de desarrollo. Existen

distintos modelos de desarrollo de software, así como modelos de pruebas. A cada

uno corresponde un nivel distinto de involucramiento en las actividades de

desarrollo.

Pruebas estáticas: Son el tipo de pruebas que se realizan sin ejecutar el código
de la aplicación. Puede referirse a la revisión de documentos, ya que no se hace

una ejecución de código. Esto se debe a que se pueden realizar "pruebas de

escritorio" con el objetivo de seguir los flujos de la aplicación.

Pruebas dinámicas: Todas aquellas pruebas que para su ejecución requieren la

ejecución de la aplicación. Las pruebas dinámicas permiten el uso de técnicas de

caja negra y caja blanca con mayor amplitud. Debido a la naturaleza dinámica de

la ejecución de pruebas es posible medir con mayor precisión el comportamiento

de la aplicación desarrollada.

3
 Métodos de pruebas

 Pruebas de Caja Blanca

Las pruebas de caja blanca (también conocidas como pruebas de caja de

cristal o pruebas estructurales) se centran en los detalles procedimentales del
software, por lo que su diseño está fuertemente ligado al código fuente. El

ingeniero de pruebas escoge distintos valores de entrada para examinar cada uno

de los posibles flujos de ejecución del programa y cerciorarse de que se devuelven

los valores de salida adecuados.

Al estar basadas en una implementación concreta, si ésta se modifica, por regla

general las pruebas también deberán rediseñarse.

Aunque las pruebas de caja blanca son aplicables a varios niveles —

unidad, integración y sistema—, habitualmente se aplican a las unidades de

software. Su cometido es comprobar los flujos de ejecución dentro de cada unidad

(función, clase, módulo, etc.) pero también pueden probar los flujos entre unidades

durante la integración, e incluso entre subsistemas, durante las pruebas de sistema.

A pesar de que este enfoque permite diseñar pruebas que cubran una amplia

variedad de casos de prueba, podría pasar por alto partes incompletas de

la especificación o requisitos faltantes, pese a garantizar la prueba exhaustiva de

todos los flujos de ejecución del código analizado.

 Pruebas de caja negra

En teoría de sistemas y física, se denomina Caja Negra a aquel elemento que es

estudiado desde el punto de vista de las entradas que recibe y las salidas o

respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras

palabras, de una caja negra nos interesará su forma de interactuar con el medio

que le rodea (en ocasiones, otros elementos que también podrían ser cajas negras)

entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace. Por

tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es

decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos

de su funcionamiento.

4
 - Caja negra y programación modular

En programación modular, donde un programa (o un algoritmo) es dividido

en módulos, en la fase de diseño se buscará que cada módulo sea una caja

negra dentro del sistema global que es el programa que se pretende desarrollar, de

esta manera se consigue una independencia entre los módulos que facilita su

implementación separada por un equipo de trabajo donde cada miembro va a

encargarse de implementar una parte (un módulo) del programa global; el

implementador de un módulo concreto deberá conocer como es la comunicación

con los otros módulos (la interfaz), pero no necesitará conocer cómo trabajan esos

otros módulos internamente; en otras palabras, para el desarrollador de un módulo,

idealmente, el resto de módulos serán cajas negras.

- Pruebas de software

En pruebas de software, conociendo una función específica para la que fue

diseñado el producto, se pueden diseñar pruebas que demuestren que dicha función

está bien realizada. Dichas pruebas son llevadas a cabo sobre la interfaz del

software, es decir, de la función, actuando sobre ella como una caja negra,

proporcionando unas entradas y estudiando las salidas para ver si concuerdan con

las esperadas.

 Testing aleatorio

En el desarrollo de software, el testing es una de las tareas más importantes, pero

también es compleja y no siempre adoptada correctamente. Las Prueba unitaria, de

carga, integración, funcionales y no funcionales son distintos tipos de testing, cada

uno con objetivos diferentes y aplicados en diferentes etapas del desarrollo del

software. En el testing de unidad se desarrollan pruebas individuales sobre

componentes de un sistema. En la codificación de dichas pruebas, se busca simular

el entorno de dicho componente y descubrir la presencia de errores o “bugs”. Más

allá del esfuerzo, las pruebas de unidad pueden probar la presencia de ciertos

errores, pero no pueden asegurar la ausencia de ellos.

5
Buscando ampliar el ámbito de las pruebas de unidad, se han aplicado diversas

técnicas que van desde la automatización de pasos o caminos de ejecución, con

valores fijos o componentes predefinidos (hard-coded) o estáticos, y condiciones

específicas, hasta los enfoques basados en la generación de objetos de manera

aleatoria, aplicados a la Programación Orientada a Objetos. El fundamento básico

de este enfoque propuesto es el testing aleatorio.

Tanto la generación de valores aleatorios para testing, como el testing aleatorio (RT

o random testing) en sí no son técnicas nuevas. Por ej., en el paradigma

funcional existe una herramienta para probar especificaciones sobre funciones

llamada QuickCheck. Esta herramienta (escrita en Haskell) y sus ideas subyacentes

son usadas como fundamento para algunas herramientas desarrolladas para RT en

POO.

Clasificación de las pruebas según lo que verifican

 Pruebas funcionales: Una prueba funcional es una prueba basada en la

ejecución, revisión y retroalimentación de las funcionalidades previamente

diseñadas para el software (requisitos funcionales). Hay distintos tipos como,

por ejemplo:

Pruebas unitarias:

Se focaliza en ejecutar cada módulo (o unidad mínima a ser probada, ej. = una

clase) lo que provee un mejor modo de manejar la integración de las unidades en

componentes mayores.

Busca asegurar que el código funciona de acuerdo con las especificaciones y que

el módulo lógico es válido.

Pruebas de integración:

Identificar errores introducidos por la combinación de programas probados

unitariamente.

Determina cómo la base de datos de prueba será cargada.

Verificar que las interfaces entre las entidades externas (usuarios) y las aplicaciones

funcionan correctamente.

6
Verificar que las especificaciones de diseño sean alcanzadas.

Determina el enfoque para avanzar desde un nivel de integración de las

componentes al siguiente.

Pruebas de sistema:

Asegurar la apropiada navegación dentro del sistema, ingreso de datos,

procesamiento y recuperación.

Las pruebas del sistema deben enfocarse en requisitos que puedan ser tomados

directamente de casos de uso y reglas y funciones de negocios. El objetivo de

estas pruebas es verificar el ingreso, procesamiento y recuperación apropiado de

datos, y la implementación apropiada de las reglas de negocios. Este tipo de

pruebas se basan en técnicas de caja negra, esto es, verificar el sistema (y sus

procesos internos), la interacción con las aplicaciones que lo usan vía GUI y

analizar las salidas o resultados.

En esta prueba se determina qué pruebas de Sistema (usabilidad, volumen,

desempeño, etc.) asegurarán que la aplicación alcanzará sus objetivos de negocio.

La prueba de Sistema incluye:

Prueba de Usabilidad

Prueba de Performance

Prueba de Documentación y Procedimientos

Prueba de Seguridad y Controles

Prueba de Volumen

Prueba de Esfuerzo (Stress)

Prueba de recuperación

Prueba de múltiples sitios

Para sistemas web se recomienda especialmente realizar mínimo el siguiente grupo

de pruebas de sistema:

Humo.

7
 Usabilidad

Performance

Funcionalidad

Para capitalizar el trabajo hasta ahora completado, los casos de prueba de las

pruebas previas realizadas pueden frecuentemente ser reorganizados y rehusados

durante la prueba de sistema. No obstante, deben ser desarrollados casos de

prueba adicionales para aquellos aspectos del sistema, tales como documentación,

procedimientos y desempeño que no han sido probados durante la prueba unitaria

y de integración.

La prueba de sistema es compleja porque intenta validar un número de

características al mismo tiempo, a diferencia de otras pruebas que sólo se centran

en uno o dos aspectos del sistema al mismo tiempo.

Pruebas de humo

Detectar los errores en realases tempranos y de manera fácil

Probar el sistema constantemente

Garantizar poco esfuerzo en la integración final del sistema

Asegurar los resultados de las pruebas unitarias

Se reducen los riesgos y a baja calidad.

Pruebas alpha

Prueba de aceptación para detectar errores en el sistema bajo un ambiente

controlado.

La verificación involucra la ejecución de partes o todo del sistema en ambientes

simulados, con el fin de encontrar errores.

La retroalimentación de esta fase produce cambios en el software para resolver los

errores y fallas que se descubren.

Pruebas beta

Realizar la validación del sistema por parte del usuario.

8
Prueba de aceptación donde La validación (o pruebas beta) involucra el uso del

software en un ambiente real.

Pruebas de aceptación

Determinación por parte del cliente de la aceptación o rechazo del sistema

desarrollado.

La prueba de aceptación es ejecutada antes de que la aplicación sea instalada

dentro de un ambiente de producción. La prueba de aceptación es generalmente

desarrollada y ejecutada por el cliente o un especialista de la aplicación y es

conducida a determinar como el sistema satisface sus criterios de aceptación

validando los requisitos que han sido levantados para el desarrollo, incluyendo a

documentación y procesos de negocio.

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

Estas pruebas están 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.

Pruebas de regresión

Determinar si los cambios recientes en una parte de la aplicación tienen efecto

adverso en otras partes.

En esta prueba se vuelve a probar el sistema a la luz de los cambios realizados

durante el debugging, mantenimiento o desarrollo de la nueva versión del sistema

buscando efectos adversos en otras partes.

Niveles de prueba

Podemos considerar el proceso de pruebas funcionales como un proceso donde se

va probando inicialmente lo de más bajo nivel y se van integrando y probando

paulatinamente componentes hasta lograr un sistema completo totalmente probado.

Por eso se dice que hay distintos niveles de prueba. Se empieza por las pruebas

9
unitarias, luego las pruebas de Integración, luego las de pruebas de sistema, las

de humo, las alpha, las beta y finalmente las de pruebas de aceptación.

Las pruebas de regresión se pueden considerar como la ejecución (normalmente

automática) de las pruebas ya realizadas hasta el momento.

 Pruebas no funcionales

Una prueba no funcional es una prueba cuyo objetivo es la verificación de un

requisito que especifica criterios que pueden usarse para juzgar la operación de un

sistema (requisitos no funcionales) como por ejemplo la disponibilidad, accesibilidad,

usabilidad, mantenibilidad, seguridad, rendimiento. Podemos clasificar las pruebas no

funcionales según el tipo de requisito no funcional que abarcan:

Pruebas de compatibilidad

Buscar problemas de compatibilidad y conversión en los sistemas.

El propósito es demostrar que los objetivos de compatibilidad no han sido logrados

y que los procedimientos de conversión no funcionan.

La mayoría 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.

10
Como tales, los programas tienen a menudo objetivos específicos con respecto a su

compatibilidad y a sus procedimientos de conversión con el sistema existente.

Pruebas de seguridad

Nivel de seguridad de la aplicación: Verifica que un actor solo pueda acceder a las

funciones y datos que su usuario tiene permitido.

Nivel de Seguridad del Sistema: Verificar que solo los actores con acceso al

sistema y a la aplicación están habilitados para accederla.

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.

Las pruebas de seguridad de la aplicación garantizan que, con base en la

seguridad deseada, los usuarios están restringidos a funciones específicas o su

acceso está limitado únicamente a los datos que está autorizado a acceder. Por

ejemplo, cada usuario puede estar autorizado a crear nuevas cuentas, pero sólo los

administradores pueden borrarlas. Si existe seguridad a nivel de datos, la prueba

garantiza que un usuario “típico” 1 puede ver toda la información de clientes,

incluyendo datos financieros; sin embargo, el usuario 2 solamente puede ver los

datos institucionales del mismo cliente.

Las pruebas de seguridad del sistema garantizan que solamente aquellos usuarios

autorizados a acceder al sistema son capaces de ejecutar las funciones del sistema

a través de los mecanismos apropiados.

Debido a la creciente preocupación de la sociedad por la privacidad de la

información, muchos programas tienen objetivos específicos de seguridad.

11
El objetivo de esta prueba es evaluar el funcionamiento correcto de los controles

de seguridad del sistema para asegurar la integridad y confidencialidad de los

datos. El foco principal es probar la vulnerabilidad del sistema frente a accesos o

manipulaciones no autorizadas. Una manera de encontrar esos casos de prueba es

estudiar problemas conocidos de seguridad en sistemas similares y tratar de

mostrar la existencia de problemas parecidos en el sistema que se examina.

Algunas consideraciones de prueba son:

 Controles de acceso físico

 Acceso a estructuras de datos específicas a través de los programas de

aplicación.

 Seguridad en sitios remotos

 Existencia de datos confidenciales en reportes y pantallas

 Controles manuales, incluyendo aquellos para autorización y aprobación,

formularios, documentación numerada, transmisión de datos, balances y conversión

de datos.

 Controles automáticos, incluyendo aquellos para edición de datos, chequeo

de máquinas, errores del operador, acceso a datos elementales y archivos, acceso

a funciones, auditoría, entre otros.

Pruebas de Stress

Verificar que el sistema funciona apropiadamente y sin errores, bajo estas

condiciones de stress:

 Memoria baja o no disponible en el servidor.

 Máximo número de clientes conectados o simulados (actuales o físicamente

posibles)

 Múltiples usuarios desempeñando la misma transacción con los mismos

datos.

 El peor caso de volumen de transacciones (ver pruebas de desempeño).

12
 NOTAS: La meta de las pruebas de stress también 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 máxima 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 las pruebas de

volumen: un esfuerzo grande es un pico de volumen de datos que se presenta en

un corto período 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,

interactivos, de tiempo real y de control de proceso.

Aunque muchas pruebas de esfuerzo representan condiciones que el programa

encontrará realmente durante su utilización, muchas otras serán en verdad

situaciones que nunca ocurrirán 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 de usabilidad

Determinar la usabilidad del sistema.

13
Determina cuán bien el usuario podrá usar y entender la aplicación. Identifica las

áreas de diseño que hacen al sistema de difícil 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 rendimiento

En la ingeniería del software, las pruebas de rendimiento son las pruebas que se

realizan, desde una perspectiva, para determinar lo rápido que realiza una tarea un

sistema en condiciones particulares de trabajo. También puede servir para validar y

verificar otros atributos de la calidad del sistema, tales como

la escalabilidad, fiabilidad y uso de los recursos. 

Pruebas de internacionalización y localización

La prueba de localización es un servicio de aseguramiento de calidad que consiste

en verificar que un producto se ajusta al mercado en el cual será comercializado.

El producto está analizado desde un punto de vista lingüístico, funcional y cultural.

Si lanza un producto que contiene un gran número de errores gramáticales y

funcionales, es más probable que esto afecte la experiencia de sus usuarios e

impida que su empresa entre en el mercado objetivo.

Las pruebas de localización deben realizarse cuando su producto está listo para el

lanzamiento al extranjero. Eso significa que el contenido debe estar completamente

traducido y técnicamente adaptado al país en el cual será comercializado.

Pruebas de escalabilidad

En informática, se conocen como pruebas de escalabilidad, a aquellas pruebas no

funcionales que permiten determinar el grado de escalabilidad que tiene un sistema.

Se entiende como escalable la capacidad que tiene el sistema para que, sin aplicar

cambios drásticos en su configuración, pueda soportar el incremento de demanda

en la operación.

14
Un ejemplo de escalabilidad es si el sistema soporta la agregación de un nodo

extra en su esquema de balanceo en la capa aplicativa o de base de datos, o un

incremento en la memoria RAM o CPU´s en su infraestructura.

Pruebas de mantenibilidad

Implantación de sistemas de integración continua, para realizar revisión estática de

código, con el objetivo de conocer la calidad intrínseca del mismo valorada en

términos de: métricas del código fuente, adecuación a estándares de lenguaje de

programación y cumplimiento de buenas prácticas.

Pruebas de instalabilidad

capacidad del producto software para ser instalado en un entorno especificado.

Pruebas de portabilidad

Se define como la característica que posee un software para ejecutarse en

diferentes plataformas, el código fuente del software es capaz de reutilizarse en vez

de crearse un nuevo código cuando el software pasa de una plataforma a otra (ver

la nota, a continuación de este párrafo). A mayor portabilidad menor es la

dependencia del software con respecto a la plataforma.

Herramientas para realizar pruebas de software

El control de la calidad de software lleva consigo aplicativos que permiten realizar

pruebas autónomas y masivas permitiendo así la verificación desde el punto de

vista estático y de caja blanca, es decir pruebas donde se analiza el software sin

ejecutar el software mediante el código fuente del mismo. Podemos encontrar

herramientas Open Source (libres) o Comerciales (de pago). Estas herramientas

podrán ser utilizadas para diferentes tipos de pruebas como:

1. Herramientas de gestión de pruebas

2. Herramientas para pruebas funcionales

3. Herramientas para pruebas de carga y rendimiento

15
 Herramientas Open Source

1) Herramientas de gestión de pruebas

Bugzilla Testopia

FitNesse

qaManager

qaBook

RTH (open source)

Salome-tmf

Squash TM

Test Environment Toolkit

TestLink

Testitool

XQual Studio

Radi-testdir

Data Generator

2) Herramientas para pruebas funcionales

Selenium

Soapui

Watir

WatiN (Pruebas de aplicaciones web en .Net)

Capedit

Canoo WebTest

Solex

Imprimatur

SAMIE

ITP

WET

WebInject

16
 3) Herramientas para pruebas de carga y rendimiento

JMeter

Gatling

FunkLoad

FWPTT load testing

loadUI

 Herramientas comerciales

1) Herramientas de gestión de pruebas

HP Quality Center/ALM

Silk Central

QA Complete

qaBook

T-Plan Professional

SMARTS

QAS.Test Case Studio

PractiTest

SpiraTest

TestLog

ApTest Manager

Zephyr

2) Herramientas para pruebas funcionales

Ranorex

17
 Silk Test

QuickTest Pro

Rational Robot

Sahi

SoapTest

Test Complete

QA Wizard

Squish

vTest

Internet Macros

3) Herramientas para pruebas de carga y rendimiento

HP LoadRunner

IBM Rational Performance Test (RPT)

LoadStorm

NeoLoad

WebLOAD Professional

Forecast

ANTS – Advanced .NET Testing System

Webserver Stress Tool

Load Impact

Silk Performer

18
 BILIOGRAFÍA

 Wikipedia. Wikipedia. [En línea] [Citado el: 20 de 04 de 2018.]

https://es.wikipedia.org/wiki/Pruebas_de_software.

 Wikipedia. [En línea] [Citado el: 20 de 04 de 2018.]

https://es.wikipedia.org/wiki/Pruebas_de_escalabilidad.

 Wikipedia. [En línea] [Citado el: 20 de 04 de 2018.]

https://es.wikipedia.org/wiki/Caja_negra_(sistemas)#Pruebas_de_software.

 Wikipedia. [En línea] [Citado el: 20 de 04 de 2018.]

https://es.wikipedia.org/wiki/Testing_aleatorio.

 Wikipedia. [En línea] [Citado el: 20 de 04 de 2018.]

https://es.wikipedia.org/wiki/Pruebas_de_integraci%C3%B3n.

 Wikipedia. [En línea] [Citado el: 20 de 04 de 2018.]

https://es.wikipedia.org/wiki/Prueba_unitaria.

 Wikipedia. [En línea] [Citado el: 20 de 04 de 2018.]

https://es.wikipedia.org/wiki/Pruebas_de_caja_blanca.

 Londoño, Jorge Abad. Blogspot. [En línea] [Citado el: 20 de 04 de 2018.]

http://ing-sw.blogspot.pe/2005/04/tipos-de-pruebas-de-software.html.

 it-Mentor. [En línea] [Citado el: 20 de 04 de 2018.]

http://materias.fi.uba.ar/7548/PruebasSoftware.pdf.

 Wikipedia. Wikipedia. [En línea] [Citado el: 20 de 04 de 2018.]

https://es.wikipedia.org/wiki/Pruebas_de_rendimiento_del_software.

 smarter software testing. [En línea] [Citado el: 20 de 04 de 2018.]

https://crowdsourcedtesting.com/es/pruebas-de-localizacion.

 Instituto Tecnológico de Informática. [En línea] [Citado el: 20 de 04 de 2018.]

https://www.iti.es/servicios/calidad-de-software/pruebas-de-software/.

19