TALLER DE PRUEBAS DE

SOFTWARE
DARIO JOSE GUACANEME MARQUEZ
ASIGNATURA: INGENIERIA DE SOFTWARE II
DOCENTE: MARIBEL ROMERO
PRUEBAS SEGÚN SU CONCEPTO Y CARACTERÍSTICAS
OBJETO
Verifican el funcionamiento aislado de piezas
de software que pueden ser probadas de
forma separada por:
 Subprogramas/Módulos individuales
 Componente que incluye varios
subprogramas/módulos
PRUEBAS UNITARIAS
Estas pruebas suelen llevarse a cabo con:
 Acceso al código fuente probado
 Ayuda de herramientas de
depuración
 Participación (opcional) de los
programadores que escribieron el
código
Es el proceso que permite verificar si un
PRUEBAS DE módulo funciona adecuadamente cuando
INTEGRACIÓN trabaja conjuntamente con otros, por lo que
es necesario comprobar si existen defectos en
las interfaces entre dicho modulo y el resto.
TIPOS DE PRUEBAS Y TÉCNICAS HERRAMIENTAS PARA CADA TIPO
USADAS DE PRUEBA
 JUnit
Casos de prueba
 TestNG (versión mejorada de
Métodos de análisis de Valores limites JUnit)
 PHPUnit
Prueba del camino basico y
Complejidad Ciclomatica de McCabe  CPPUnit
 NUnit (.Net)
 MOQ (creación dinámica de
objetos simuladores, mocks)
 Katalon
 Guiadas por la arquitectura:  Mocha
Los componentes se integran
según hilos de funcionalidad  Jasmine
 Incremental: Se combina el
siguiente módulo que se debe  Jest
probar con el conjunto de
módulos que ya han sido  Ava
probados.
 Incremental ascendente  Katalon
(bottom up): integran
primero los componentes de
infraestructura o los módulos
hoja (pruebas unitarias) y
añaden componentes
funcionales progresivamente.
Es decir, se prueban primero
los componentes de menor
nivel, luego se combinan los
 módulos según la jerarquía, y
así, sucesivamente, Se repite
en niveles superiores
 Incremental Descendente
Top-Down): consiste en
probar primero el
componente de más alto
nivel, después aquellos que
son utilizados por dicho
componente, y así
sucesivamente con el resto de
componentes hasta llegar a
los de más bajo nivel.
Se clasifican en:
Primero en profundidad:
permite implementar y
demostrar una función
completa del software, es
perfecto para sistemas por
transacciones
Primero en anchura: funciona
completando niveles de
jerarquía
 Integración no incremental.
Se prueba cada módulo por
separado y luego se integran
todos de una vez y se prueba
el programa completo
 Integración Big Bang: se
prueban todos los
componentes juntos (A, B, C,
D.... M)
 Integración en sándwich: se
combinan todas las
estrategias ascendente y
descendente.
  Pruebas funcionales:  Jmeter
Dirigidas a asegurar que el
sistema de información  Gatling
realiza correctamente todas
Su objetivo es verificar el comportamiento del las funciones que se han  Supertest
sistema y su funcionalidad en conjunto, detallado en las
integrado, con el objetivo primordial de especificaciones dadas por el  SoapUI
comprobar si hace lo que el cliente desea. usuario del sistema.
 Pruebas de comunicaciones:  Cucumber
PRUEBAS DE SISTEMA Este nivel es más adecuado para comprobar Determinan que las interfaces
requisitos no funcionales entre los componentes del  Robolectric
Como son: sistema funcionan
Seguridad, Velocidad, Exactitud, Fiabilidad adecuadamente, tanto a  KIF
través de dispositivos
También se prueban: remotos, como locales.
 Interfaces externos con otros Asimismo, se han de probar
sistemas las interfaces
 Utilidades hombre/maquina.
 Unidades físicas  Pruebas de rendimiento:
 Entorno operativo Consisten en determinar que
los tiempos de respuesta
estan dentro de los intervalos
Las pruebas del sistema también verifican que establecidos en las
el sistema tiene la capacidad volumétrica, de especificaciones del sistema.
robustez y que se comporta bien ante fallas  Pruebas de volumen:
Consisten en examinar el
funcionamiento del sistema
cuando está trabajando con
grandes volúmenes de datos,
simulando las cargas de
trabajo esperadas.
 Pruebas de sobrecarga:
Consisten en comprobar el
funcionamiento del sistema
en el umbral límite de los
 recursos, sometiéndole a
cargas masivas. El objetivo es
establecer los puntos
extremos en los cuales el
sistema empieza a operar por
debajo de los requisitos
establecidos.
 Pruebas de disponibilidad de
datos: Consisten en
demostrar que el sistema
puede recuperarse ante
fallos, tanto de equipo físico
como logico, sin
comprometer la integridad de
los datos.
 Pruebas de facilidad de uso:
Consisten en comprobar la
adaptabilidad del sistema a
las necesidades de los
usuarios, tanto para asegurar
que se acomoda a su modo
habitual de trabajo, como
para determinar las
facilidades que aporta al
introducir datos en el sistema
y obtener los resultados.
 Pruebas de operación:
Consisten en comprobar la
correcta implementación de
los procedimientos de
operación, incluyendo la
planificación y control de
trabajos, arranque y re
arranque del sistema, etc.
 Pruebas de entorno:
Consisten en verificar las
 interacciones del sistema con
otros sistemas dentro del
mismo entorno.
 Pruebas de seguridad:
Consisten en verificar los
mecanismos de control de
acceso al sistema para evitar
alteraciones indebidas en los
datos.
Es la prueba planificada y organizada  Pruebas de punto de  Canoo
formalmente para determinar si se cumplen referencia: Es donde el
los requisitos de aceptación marcados por el usuario establece un conjunto  Concordion
cliente. de puntos de referencia para
el rendimiento de ciertas  FitNesse
Sus características principales son las funcionalidades del sistema
siguientes: que sirven para evaluar su  JBehave
 Participación del usuario rendimiento en comparación
 Está enfocada hacia la prueba de los con dichos niveles.  JMeter
requisitos de usuario especificados.
 Está considerada como la fase final  Prueba piloto: consiste en  Sahi
PRUEBAS DE del proceso para crear una confianza hacer una instalación
ACEPTACIÓN en que el producto es el apropiado experimental del software y  Selenium
para su uso en explotación someterlo al trabajo diario al
que se sometería una vez en  SoapUI
Las pruebas de aceptación son fundamentales producción
por lo cual deben incluirse obligatoriamente  Watir
en el plan de pruebas de software.  Pruebas en paralelo: se llevan
a cabo siempre que se  easyb
El test de aceptación termina de definir el construyen un sistema que va
nivel de calidad de la aplicación y le permite a reemplazar a uno ya en
conocer al equipo qué tan bien supo funcionamiento
interpretar correctamente los requerimientos
del usuario o Product owner.  Las Pruebas Alfa: las realizan
en la propia compañía
desarrolladora del software
Es el cliente quien tendrá la decisión final de con el equipo de “Pruebas de
aprobar o no el producto, como también de software”.
solicitar modificaciones.
 Las Pruebas Beta: se realizan
de formas externa con los
potenciales clientes /
usuarios, o con sus propios
clientes, independientes de la
compañía creadora del
software

 Pruebas de aceptación de
contratos y regulaciones
En este tipo de pruebas, nos
referimos específicamente a
las que quedaron estipuladas
en la firma de contrato,
mediante clausulas
específicas, entre la empresa
“cliente” y la empresa
“desarrolladora”. Es común
que estas cláusulas y
regulaciones sean de tipo:
leyes, seguridad y el gobierno
en donde se encuentre, entre
otras.