Hoy en dia los 

proyectos de software son más complejos que nunca antes.

La industria del software crece a una velocidad altísima y
los desarrolladores de software han de estar a la última de novedades y
oportunidades en el mundo del software para utilizar la última tecnología de
la mejor manera. Por lo que esta vez, he decidido hablar un poco mas de la
parte de testeo, que juega un rol crucial en las construcciones
de plataformas escalables de gran actuación.

Hay muchos tipos de negocio, pero en el desarrollo de software, la calidad

es esencial para el éxito. Para garantizar este éxito, la función de testeo es
vital. Los tests de software ayudan a los equipos a evaluar el software con
los requerimientos e información recogida de los usuarios y el product
owner, simplificando la vida de los developers. Somos grandes fans de
la metodología Ágil y creemos que para aplicar de manera correcta esta
metodología necesitas hacer TDD (Desarrollo guiado por pruebas)
y CI (Integración continua). Los test ágil forman uno de los roles más
importantes de la metodología Ágil. Creemos que los test no deberían
separarse del proceso de desarrollo, como es hecho con modelos más
tradicionales. El testeo de software es una parte del proceso de desarrollo
del mismo. Y los test deben ser escritos antes de escribir el codigo para
poder identificar los errores más rápidamente y corregirlos en el menor
tiempo posible. El test de software ayuda a reducir los riesgos de desarrollo,
tiempo y costes. 

Aun hay gente, que prefieren ahorrar dinero en el proceso de testeo. Y esto
es un gran error!
Incluso aunque la inversión inicial pueda ser mayor, a largo plazo el
mantenimiento de la plataforma y el proceso de desarrollo es mucho mas
barato. Los test de software dan feedback rápido, por lo que todos los
amantes de la metodología Agile lo usan.

Hablamos con nuestro equipo de desarrollo de software y aunque haya

docenas de diferentes tests en internet, hemos subrayado 4 que creemos
ser los más importantes y esenciales para construir software que funciona.
Tambien encontraras una lista de las mejores herramientas que utilizamos
en nuestros proyectos.

 
4 técnicas de testeo de software esenciales
para construir software que funciona. 
 

1. Prueba unitaria
Empecemos con el primero y más pequeño de todos – prueba unitaria. La
prueba unitaria se aplica en el elemento más pequeño de un sistema, cada
componente es testeado para asegurar que funciona correctamente.
Normalmente desarrolla una única función cohesiva. La función de la
prueba unitaria es de analizar cada pequeña parte y testear que funciona
correctamente.
La prueba unitaria se usa mayormente por desarrolladores ágil,
especialmente en programadores extremos, los amantes del TDD. Sin
embargo las pruebas unitarias son más populares hoy en dia y otros
desarrolladores están empezando a utilizarlo.

Herramientas de las pruebas

unitarias: Junit, Phpunit, Mocha, Mockito, Chai, Sinon, Jasmine, Jest,
Ava y TestNG, Powermock, XCTest

2. Pruebas de integración
La prueba de integración es una extensión lógica de las pruebas unitarias.
Dos unidades que ya han sido testeadas y combinadas en un componente y
su interface son testeadas entre ellas. Un componente, en este ejemplo, se
refiere a un agregado que está integrado en más de una unidad, estas son
combinadas en componentes, que son agregadas por orden en partes mas
grandes del programa. El motivo de las pruebas de integración es de
verificar la funcionalidad y la seguridad entre los componentes que han sido
integrados. Identifica los problemas que ocurren cuando las unidades se
combinan. Esto es particularmente beneficioso porque determina cómo de
eficientes son los tests trabajando juntos. Recuerda que no importanta como
de eficiente cada test funcione, si no están propiamente integrados. Afecta a
la funcionalidad del programa de software. Además, es importante conocer
que las pruebas de integración están basados en pruebas unitarias con
base de datos u otra biblioteca ajena de terceras partes.

Herramientas de pruebas de integración: Mocha, Jasmine, Jest y Ava

3. Pruebas funcionales
Las pruebas funcionales se basan en asegurarse de que todas las
características funcionen de cabo a rabo. Por ejemplo, testear que las
características de un usuario se actualicen cuando el usuario clicka en el
botón de guardar. Las pruebas funcionales testean una pequeña parte de la
funcionalidad del sistema entera. Se aplica para verificar que las
aplicaciones y funcionalidades del software actuan correctamente acorde a
un diseño específico.

Las pruebas funcionales son elementos cruciales para asegurar la calidad

del producto software y confirmar que actúa acorde a sus funciones tal y
como el usuario espera. Los test se utilizan para verificar que la aplicación,
página web ejecute sus funcionalidad a través de una respuesta adecuada a
los controles de usuario, una interfaz de usuario consistente, integración con
otros sistemas y procesos de negocios, y manejo adecuado de información
y búsqueda.

Antes de empezar un proyecto, siempre nos aseguramos que empezamos a

trabajar para crear las mejores historias de usuario; corta, simple,
características deseadas y descriptiva desde una perspectiva de usuario.
Las mejores historias de usuario son las más simples y normalmente tienen
una forma muy entendible:

Como <type of user>, quiero <some goal> para que <some reason>

Por ejemplo,

Como estudiante, quiero notificaciones para que no olvide fechas de

entrega.
Los test de funcionalidad testean este tipo de historias de usuarios. Otra
forma de nombrar las pruebas funcionales son los test de aceptación, test
de consumidor, etc. Hay miles de versiones en internet, pero creemos que
“prueba funcional” es la mejor manera de nombrar a estos test.

Herramientas de pruebas
funcionales: Jmeter, Gatling, Supertest, SoapUI, Cucumber, Robolectric, KI
F

4. Pruebas de rendimiento
Y la última es la prueba de rendimiento. En el desarrollo de software, la
prueba de rendimiento es una práctica de test que determina la actuación
de un sistema en términos de respuesta y estabilidad en una carga de
trabajo en particular. También puede servir para investigar, medir, validar o
verificar otros atributos de calidad del sistema, como la escalabilidad,
seguridad y uso de recursos.

Las pruebas de rendimiento construye unos estándares de actuación en la

implementación, diseño y arquitectura de un sistema.

Puede servir para verificar que una plataforma de software presenta las
especificaciones del product owner. Este test muestra como eficiente es un
software. Chequea como de bien un software trabaja bajo una carga
máxima de trabajo. Hay varias variaciones o subtipos de pruebas de
rendimiento como tests de carga, test de estrés, test de volumen y muchas
otras más. Estos métodos de tests de aseguran de que lo que se ha hecho,
se ha realizado correctamente, teniendo en cuenta las diferentes
circunstancias que pueden aparecer en el futuro.

Herramientas de pruebas de rendimiento: Jmeter, Gatling

Hay otras herramientas de pruebas de software, estaré feliz de discutirlos

en la sección de comentarios de abajo! Y si estais interesados en estos
temas sobre como construir software que funciona, os recomiendo que os
suscribais a nuestro newsletter mensual para recibir los últimos artículos y
las mejores prácticas.

https://apiumhub.com/es/tech-blog-barcelona/tecnicas-de-testeo-de-software/

Cada vez más los usuarios móviles se han vuelto más exigentes e impacientes. En tan sólo unos
segundos, ya pueden determinar si una App les gusta o no.

Si la app es demasiado complicada o lenta, seguramente no sólo pasarán al competidor  sino que
también publicarán una crítica negativa de tu sitio en las redes sociales que podría perjudicar tu
reputación.

Debido a que cualquier aplicación sólo dispone de una oportunidad rápida de hacerlo bien y
que cada vez más hay más competencia altamente cualificada, realizar un gran test es la clave
del éxito.

Desde pruebas funcionales más básicas o concretas, pruebas basadas en riesgo hasta pruebas de
seguridad y privacidad,… Se pueden hacer cantidad de pruebas que aseguren el buen
funcionamiento de la app. Desde pruebas a nivel externo hasta incluso en el propio código, lo
 cual es primordial para un buen test.

A continuación vamos a detallar cuatro tipos de pruebas de software que desempeñaría un QA

o tester:
 Funcionales
 No funcionales
 Estructurales
 De regresión o re-pruebas

Pruebas de software funcionales

Son las que revisan el comportamiento del sistema, subsistema o componente software. Suelen
ser pruebas ya documentadas en especificaciones de requisitos o en casos de uso.

También se las llaman Pruebas de Caja Negra (“black-box testing”) dado que se valora el

comportamiento externo del sistema. Entre algunas de sus pruebas podemos encontrar las
‘Pruebas de seguridad’ y las ‘Pruebas de interoperabilidad’.

Fuente foto:  http://toka-solutions.com

Pruebas de software no funcionales

Dentro de este grupo de pruebas se incluyen las de Rendimiento, Carga, Estrés, Usabilidad,
Mantenibilidad, Fiabilidad y de Portabilidad.

Puesto que estas pruebas normalmente consideran el comportamiento externo del sistema, en la
mayoría de los casos se utilizan técnicas de Pruebas de Caja Negra.

Pruebas de software estructurales
En este tipo de pruebas se indaga más el comportamiento interno, en el que se revisa los
componentes y la integración de éstos. Por eso se las suele llamar Pruebas de Caja
Blanca (“white-box testing”).
 

Fuente foto:  blog.elevenpaths.com

Pruebas de software de regresión o re-pruebas

Las pruebas de regresión se realizan una vez que un error detectado ha sido corregido para
confirmar que éste ha sido eliminado.

Además de probar el componente que ha tenido que ser modificado es importante volver a
revisar todo para descubrir cualquier defecto introducido, o no cubierto previamente, como
consecuencia de los cambios.

Fuente foto:  http://christianfontalvo.com

 

Y aquí termina los tipos de pruebas existentes que permitirán validar correctamente cualquier
app. Por otro lado, si os interesa conocer más cosas sobre testing, podéis acceder aquí. 

http://visual-engin.com/2017/10/26/importancia-pruebas-de-software-testing/

¿Qué tipos de pruebas de

software son habituales para
un desarrollador?
Por  Jorge Turrado.  Publicado el 6 de abril de 2020 a las 08:00

Una carrera con futuro a punto de explotar: súbete al Machine Learning con nosotros

No hace mucho escribí en este blog una entrada describiendo qué son las pruebas de
software. En ella planteaba qué son las pruebas de software y por qué son importantes,
dando una visión superficial de algunos de los tipos de pruebas de software que existen. Si
aun no la has leído te recomiendo leerla antes de continuar.
Asumiendo la gran variedad y cantidad de pruebas que existen a la hora de desarrollar
software, es fácil perder la visión sobre qué está en el tejado de quién durante el ciclo de
vida de un sistema. Como desarrolladores, las cuestiones de hasta dónde debemos llegar y
qué escapa a nuestro control o responsabilidades, suele ser algo bastante difuso. Sin
embargo, existe consenso en torno a que los desarrolladores, como mínimo,
debemos desarrollar 3 tipos de pruebas sobre el código :

 Pruebas unitarias
 Pruebas de integración
 Pruebas funcionales

Existen otros tipos de pruebas que habitualmente pueden ser responsabilidad de

los desarrolladores, pero ya no es algo tan aceptado y depende de a quién
preguntes, te dirá una cosa u otra.

Vamos a darle un repaso a estas tres, las más importantes, para ver en qué consisten y
qué implicaciones tienen para el desarrollador.

Pruebas unitarias
El primero de los grupos, las pruebas unitarias, es como se conoce a todas esas pruebas
que solo comprueban una funcionalidad específica de una única clase . A este tipo
de pruebas "les da igual" el comportamiento del resto, ya que la gran mayoría de las veces
reciben un objeto que simula el comportamiento externo a esa clase, necesario para
funcionar.
La finalidad última de las pruebas unitarias es comprobar funcionalidades muy
concretas de cada clase.
Son pruebas que no deberían costarnos más de 5 minutos escribir, y de las cuales vamos
a tener tantas como sea necesario para probar el 100%  (o lo máximo posible al
menos) de los posibles casos que estén contemplados en el código.

Aprende desde cero a trabajar para   Data Science y Machine

Learning  con nuestro Máster OnLine.

👉Infórmate aquí

Por ejemplo, el hecho de comprobar que un método lanza una excepción en una
condición concreta es un caso claro de prueba unitaria.
De este tipo de pruebas se espera que sean rapidísimas de ejecutar, ya que en un
proyecto grande habitualmente habrá cientos (¡o incluso miles!) de éstas. Sin ir más lejos,
el framework de simulación Moq tiene 2.843 pruebas unitarias, y cada una tarda en
ejecutarse del orden de milisegundos.

Pruebas de integración
El segundo de los grupos, las pruebas de integración, es como conocemos a todas esas
pruebas que verifican que las relaciones existentes entre las diferentes clases y
servicios funcionan correctamente .
Este tipo de pruebas lo que busca es encontrar todos esos problemas que surgen al
mezclar las diferentes capas de nuestra aplicación.

Por ejemplo, si trabajamos con una base de datos, en una prueba de integración
utilizaremos un motor de base de datos real y no uno en memoria o simulado. De este
modo validaremos la correcta integración de nuestro sistema con esa base de datos.

En este tipo de pruebas es posible utilizar simulaciones para algunos niveles que todavía
no se pueden probar, como por ejemplo un servicio de terceros.

Suelen ser pruebas más costosas de desarrollar y ejecutar que las pruebas unitarias ya que
en cada una de ellas se deben integrar varios puntos del sistema para asegurar que
funcionan correctamente en conjunto.

Pruebas funcionales
Las pruebas funcionales verifican el comportamiento del sistema para afirmar que se
cumple con la funcionalidad completa . Se les suele denominar también pruebas End-
To-End o E2E.
Este tipo de pruebas se realizan con los requisitos de funcionamiento en la mano,
y no se centran en los pormenores del sistema, que ya deberían estar probados
con los dos grupos anteriores.

Por lo general, son pruebas que requieren de más esfuerzo que las anteriores, ya que en
ellas debemos probar el funcionamiento completo del sistema en base a los requisitos
existentes. Por esto debemos utilizar el mismo tipo de sistemas que utilizará el código en
producción.

Además, es habitual que se hagan pruebas específicas para evaluar el rendimiento y

comprobar que está dentro de los parámetros deseados.
Un ejemplo de pruebas funcionales podría ser cuando en ASP.NET
Core utilizamos TestServer*, de modo que estamos probando que el funcionamiento
completo es correcto: desde el enrutado hasta la conexión a una base de datos (pasando
por cada uno de los componentes internos).
* TestServer es una clase incluida en ASP.NET Core que nos proporciona un
servidor completo, con toda la aplicación en memoria, para poder probarla con
gran rendimiento y sin necesidad de configurar y desplegar un servidor completo
real.

Relación entre tipos de pruebas

A la hora de desarrollar los diferentes grupos de pruebas, como en casi todo, debemos
aplicar el sentido común para conseguir probar el máximo código posible con el
menor esfuerzo.

Por ejemplo, no siempre tiene mucho sentido intentar cubrir con pruebas funcionales el
100% de las posibilidades de una clase concreta. El motivo es que, además de que muchas
veces no es ni siquiera posible, hacerlo aumentaría enormemente los costes.

En relación a cómo debería ser la cantidad de código a probar, se suele representar como
una pirámide en la que las pruebas unitarias constituyen su base, y las pruebas
funcionales están en la cúspide:
Esta pirámide se llama pirámide de testing o pirámide de Cohn (se atribuye a Mike
Cohn aunque nunca ha quedado clara su autoría). Lo que nos intenta transmitir es que,
aunque debes usar el sentido común para cada caso, en general siempre debe haber
muchas más pruebas unitarias que de integración y muchas más que test
funcionales.
De hecho, si dentro de los test funcionales tuviésemos pruebas de la interfaz de usuario
(también llamados test End to End o E2E), estos deberemos mantenerlos al mínimo. El
motivo es que este tipo de test, aunque suelen aportan bastante valor, son muy costosos
de crear, pero sobre todo, son muy costosos de mantener y no conviene abusar de ellos.
https://www.campusmvp.es/recursos/post/que-tipos-de-pruebas-de-software-son-habituales-
para-un-desarrollador.aspx

Esta página hace referencia a la imagen.

https://coggle.it/diagram/WXFAuukD_gABz2kR/t/t%C3%A9cnicas-de-pruebas-pruebas-
funcionales

Pruebas de software
Ir a la navegaciónIr a la búsqueda
Este artículo o sección tiene referencias, pero necesita más para
complementar su verificabilidad.
Este aviso fue puesto el 27 de noviembre de 2018.

Diagrama que en forma gráfica, evoca la situación en la cual las opiniones y/o evaluaciones se
concretan a través de una multitud de evaluadores y aportantes (crowdsourced testing), trabajando en
forma abierta y participativa (crowdsourcing).

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 o  stakeholder.
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.

Índice
 1Definición
 2Historia
 3Proceso de Desarrollo de Software
o 3.1Pruebas estáticas
o 3.2Pruebas dinámicas
 4Pruebas contra Especificación (ESRE)
 5Tipos de pruebas por su ejecución
 6Enfoques de pruebas
 7Clasificación de las pruebas según lo que verifican
o 7.1Pruebas funcionales
 7.1.1Niveles de prueba
o 7.2Pruebas no funcionales
 8Herramientas para realizar pruebas de software
o 8.1Herramientas en código abierto
o 8.2Herramientas comerciales
 8.2.1Herramientas de gestión de pruebas
 8.2.2Herramientas para pruebas funcionales
 8.2.3Herramientas para pruebas de carga y rendimiento
 9Véase también
 10Referencias
 11Enlaces externos

Definición[editar]
Un caso de pruebas es una breve declaración de algo que debería ser probado.
Es el mecanismo, manual o automático, de verificar si el comportamiento del
sistema es el deseado o no.1

Historia[editar]
El objetivo de las pruebas es presentar información sobre la calidad del producto a
las personas responsables de este. Las pruebas de calidad presentan los
siguientes objetivos: encontrar defectos o bugs, aumentar la confianza en el nivel
de calidad, facilitar información para la toma de decisiones, evitar la aparición de
defectos.
Teniendo esta afirmación en mente, la información que puede ser requerida es de
lo más variada. Esto hace que el proceso de testing sea completamente
dependiente del contexto en el que se desarrolla. 2
El ambiente ideal de las pruebas es aquel que es independiente del desarrollo del
software, de esta manera se logra objetividad en las pruebas.
A pesar de lo que muchos promueven, no existen las "mejores prácticas" como
tales. Toda práctica puede ser ideal para una situación, pero completamente inútil
o incluso perjudicial en otra.
Por esto, las actividades técnicas, documentación, enfoques y demás elementos
que condicionarán las pruebas a realizar deben ser seleccionadas y utilizadas de
la manera más eficiente según contexto del proyecto.
Proceso de Desarrollo de Software[editar]
Tenemos el proceso de desarrollo en cascada, se denomina de este modo, ya que
a cada salida de una etapa cae en la siguiente, es decir, las etapas se llevan a
cabo una a continuación de la otra. Una de las peculiaridades de este proceso, es
que no está previsto volver a una etapa anterior, es decir si se olvidó relevar algún
requerimiento al comienzo, no tiene una alternativa para considerar este caso.
Este proceso supone cada etapa independiente de las etapas anteriores.
También tenemos el desarrollo iterativo y creciente, se tiene las mismas etapas
que en el Proceso de Desarrollo en Cascada, sin embargo, en este proceso, la
etapa de relevamiento se divide en distintos sub conjuntos,y cada uno de estos
sub conjuntos se construye de la misma forma que con el ciclo de vida en
cascada. Se van desarrollando por partes que luego se integran, una vez
finalizadas las mismas.
Otro Proceso de Desarrollo que tenemos es el Iterativo, en este tenemos las
mismas etapas de desarrollo que los procesos anteriores, pero trabajamos sobre
el todo, no necesariamente conocemos al comienzo todos los detalles del
producto que queremos construir.
Y por último tenemos el desarrollo ágil de software, este es un proceso iterativo e
incremental, se caracteriza por contar con iteraciones cortas y por no tener fases
lineales, tipo cascada en cada iteración. Existen distintas metodologías Ágiles, que
entre las más conocidas y utilizadas encontramos "Scrum" y "XP: Extreme
Programming".
Pruebas estáticas[editar]
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[editar]
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.

Pruebas contra Especificación (ESRE)[editar]

Antes de entender para que les sirve a los probadores beta trabajar con el
documento de especificación de requerimientos, debemos saber qué son las
especificaciones de requerimientos (ESRE).
Las Especificaciones de Requerimientos son un documento clave en el desarrollo
de Software. Cuando consideramos los ciclos de vida clásicos, tiene la descripción
completa de lo que va a hacer el sistema sin describir cómo lo va a hacer. Estos
documentos tienen una estructura en forma de reporte bastante definida, poseen
carátula, historial de cambios, introducción, definiciones, acrónimos y abreviaturas,
especificación de requerimientos funcionales, especificación de requerimientos no
funcionales y casos de uso.
Los probadores beta se guían en este documento para validar si el sistema se
comporta de la manera que indican las ESRE. Contiene información detallada
sobre los requisitos funcionales y no funcionales que el Cliente desea en el
sistema. También se pueden ejecutar casos de pruebas a partir de las
especificaciones de requerimientos ya que estos resultan muy útiles porque son
sencillos de seguir y se conocen de antemano los posibles resultados.

Tipos de pruebas por su ejecución[editar]

 Pruebas manuales
 Pruebas automáticas

Enfoques de pruebas[editar]
 Pruebas de Caja blanca

 Pruebas de Caja negra

 Testing aleatorio3

Clasificación de las pruebas según lo que verifican[editar]

Pruebas funcionales[editar]
Artículo principal: 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
 Pruebas de componentes
 Pruebas de integración
 Pruebas de sistema
 Pruebas de humo
 Pruebas alpha
 Pruebas beta
 Pruebas de aceptación
 Pruebas de regresión
Niveles de prueba[editar]
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 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 puede considerar como la ejecución (normalmente
automática) de las pruebas ya realizadas hasta el momento.
Pruebas no funcionales[editar]
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
 Pruebas de seguridad
 Pruebas de Estrés
 Pruebas de usabilidad
 Pruebas de rendimiento
 Pruebas de internacionalización y localización
 Pruebas de escalabilidad
 Pruebas de mantenibilidad
 Pruebas de instalabilidad
 Pruebas de portabilidad

Herramientas para realizar pruebas de software[editar]

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 escritas en software libre, código abierto o software privativo.4 Estas
herramientas podrán ser utilizadas para diferentes tipos de pruebas como por
ejemplo:

1. Herramientas de gestión de pruebas

2. Herramientas para pruebas funcionales
3. Herramientas para pruebas de carga y rendimiento
Herramientas en código abierto[editar]
1. Herramientas de gestión de pruebas

 Bugzilla Testopia
 FitNesse
 qaManager
 qaBook
 RTH.5
 Salome-tmf
 Squash TM
 Test Environment Toolkit
 TestLink
 Testitool
 XQual Studio
 Radi-testdir
 Data Generator

1. Herramientas para pruebas funcionales

 Selenium
 Soapui
 Watir
 WatiN (Pruebas de aplicaciones web en .Net)
 Capedit
 Canoo WebTest
 Solex
 Imprimatur
 SAMIE
 ITP
 WET
 WebInject

1. Herramientas para pruebas de carga y rendimiento

 JMeter
 Gatling
 FunkLoad
 FWPTT load testing
 loadUI
Herramientas comerciales[editar]
Herramientas de gestión de pruebas[editar]

 ApTest Manager
 HP Quality Center/ALM
 PractiTest
 QA Complete
 QAS.Test Case Studio
 qaBook
 SMARTS
 Silk Central
 SpiraTest
 T-Plan Professional
 TestLog
 Zephyr
Herramientas para pruebas funcionales[editar]

 BASSP testConfig/testExecutor
 Internet Macros
 QA Wizard
 QuickTest Pro
 Ranorex
 Rational Robot
 Sahi
 Silk Test
 SoapTest
 Squish
 Test Complete
 vTest
Herramientas para pruebas de carga y rendimiento[editar]

 JMeter
 ANTS – Advanced .NET Testing System
 Forecast
 HP LoadRunner
 IBM Rational Performance Test (RPT)
 Load Impact
 LoadStorm
 NeoLoad
 Silk Performer
 WebLOAD Professional
 Webserver Stress Tool
Véase también[editar]
 Ingeniería de software.
 Automatización de pruebas.
 Pruebas de humo (informática).
 Pruebas de remojo (informática)

Referencias[editar]
1. ↑ Federico Toledo Rodríguez (2014). «Introducción a las pruebas
funcionales». Introducción a las Pruebas de Sistemas de Información. Consultado el 15 de
octubre de 2019. Abstracta. ISBN 9-789974-993853.
2. ↑ Kaner, Cem (17 de noviembre de 2001). «The Seven Basic Principles of the Context-
Driven School». context-driven-testing.com (Lessons Learned in Software Testing) (en inglés).
Archivado desde el original el 17 de noviembre de 2001. Consultado el 3 de febrero de 2018.
«There are good practices in context, but there are no best practices.»
3. ↑ Barrientos, Pablo Andrés (04 de 2014). Enfoque para pruebas de unidad basado en
la generación aleatoria de objetos. p. 101. Consultado el 28 de abril de 2014.
4. ↑ «8 outils de test en 2018» (html). Pandora FMS (en francés). 24 de abril de 2019.
Archivado desde el original el 18 de junio de 2019. Consultado el 18 de junio de 2019.
5. ↑ RTH - Requirements and Testing Hub