Siguiendo con los apuntes de Ingeniería de Software para la Ingeniería en Computación, de la Universidad Tecnologica de la Mixteca en Huajuapan de León, Oaxaca México.

1. 5 . M É T O D O S D E
P R U E B A D E S O F T WA R E
I N G E N I E R Í A D E S O F T WA R E
U T M 2 0 1 7
M A Y O 2 0 1 5

2. ¿ P O R Q U É P R O B A R E L S O F T WA R E ?
2

3. ¿ Q U É E S P R O B A R S O F T WA R E ?
¿Qué hacen los ingenieros de pruebas? ¿Demostrar que
el software funciona correctamente? ¿Buscar fallas?
¿Mejorar la calidad del software?
Los expertos ofrecen diferentes definiciones para las
pruebas del software pero hay algo en lo que todos
parecen estar de acuerdo: probar software no consiste
en demostrar que éste funciona correctamente.
3

4. 4

5. 5

6. E D S G E R D D I J K S T R A
“Probar software es el proceso de ejecutar un
programa con el objetivo de encontrar errores”
6

7. G L E N F O R D J M Y E R S
“Las pruebas de software pueden ser usadas para
mostrar la presencia de errores, pero nunca para
demostrar la ausencia de errores!”
7

8. C E M K A N E R
“Las pruebas de software es la investigación
empírica como técnica que se desarrolla para
ofrecerle a los stakeholders con información sobre
la calidad del producto o servicio evaluado.”
8

9. 5 . 1 E L P R O C E S O D E P R U E B A S
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.
Como existen distintos modelos de desarrollo de
software, así también existen modelos para pruebas. A
cada uno corresponde un nivel distinto de
involucramiento en las actividades de desarrollo.
9

10. 10

11. 5 E L E M E N T O S E S E N C I A L E S
1. Una estrategia de pruebas que nos indique qué tipos de pruebas y la
cantidad de ellas que consideremos serán suficientes para encontrar
defectos en el software
2. Un plan de pruebas que nos diga cómo deberemos de llevar a cabo la
estrategia
3. Casos de prueba que preparemos con anterioridad en la forma de
ejemplos detallados que usaremos para comprobar si el software cumple
sus requerimientos
4. Datos de prueba, que consiste en los datos de entrada y las bases de
datos de prueba que se utilizarán para ejecutar los casos de prueba y
5. Un ambiente de pruebas que nos permitan llevar a cabo dichas pruebas
11

12. ¿ C Ó M O S E H A C E N L A S P R U E B A S E N E L
M U N D O R E A L ?
1. Reunión inicial - ¿Quién es el cliente? ¿Duración del
proyecto y fecha de entrega? ¿Stakeholders?
2. Plan de pruebas - desarrollado en base al SRS: se
divide el diseño en módulos
3. Casos de Prueba y Escenarios - se crean pruebas
siguiendo una filosofía bottom-top (pruebas de
módulos y luego su integración)
4. Testing y debugging
12

13. P R U E B A S E N M E T O D O L O G Í A S Á G I L E S
13

14. 5 . 3 M É T O D O S D E P R U E B A
• Diferentes técnicas de pruebas son apropiadas para
diferentes momentos en el desarrollo de software
• El primero en probar su código es el mismo
desarrollador que puede ser asistido por grupos de
pruebas independientes para proyectos grandes
• El papel del tester independiente es eliminar el
conflicto de interés inherente cuando el
desarrollador prueba su propio producto
14

15. Validación
¿Estamos construyendo el producto correcto?
Verificación
¿Estamos construyendo el proyecto correctamente?
15

16. E TA PA S D E P R U E B A S
• Pruebas de Módulo o unitarias
• Pruebas de Integración
• Pruebas del Sistema
• Pruebas de Rendimiento
• Pruebas de Aceptación
• Pruebas de Instalación
16

17. 17

18. 18

19. ¿ C A J A N E G R A
O C A J A
B L A N C A ?
E L D I L E M A D E S I E M P R E …
• El número de caminos lógicos
determina si es caja blanca
• La naturaleza de los datos de
entrada
• La cantidad de
procesamiento necesario
• La complejidad de los
algoritmos
19

20. P R U E B A S U N I TA R I A S
• Se deben de probar los límites de los rangos de datos
• Los paths (rutas) básicas deben ser probadas
• Todos las rutas que generen errores deben ser
probadas
• Drivers y/o stubs deben ser desarrollados para
probar software incompleto
20

21. D AT O S D E P R U E B A
• Idealmente se deben alternar datos válidos e inválidos
• Particiones equivalentes (eg. fechas, edades, etc)
• Pruebas de Regresión
21

22. P R U E B A S D E I N T E G R A C I Ó N
• Proceso Bottom-Up (con Drivers)
• Proces Top-Down (con Stubs)
• Sandwich testing
22

23. P R U E B A S D E L S I S T E M A
Pruebas de Recuperación
• Checar las habilidades del sistema de recuperarse de fallas
Pruebas de seguridad
• Verifica los mecanismos de protección del sistema que prevenga accesos no
autorizados o la alteración de datos
Pruebas de Estrés
• El sistema es probado para ver cómo se comporta con demandas de trabajo no
planeadas
Pruebas de Rendimiento
• Prueba el desempeño del sistema por un largo periodo de tiempo
23

24. P R U E B A S D E R E N D I M I E N T O
• Pruebas de Estrés
• Pruebas de Volumen
• Pruebas de Configuración (hardware & software).
• Pruebas de Compatibilidad
• Pruebas de Regresión
• Pruebas de Seguridad
24

25. P R U E B A S D E R E N D I M I E N T O
• Pruebas de Tiempo
• Pruebas Ambientales
• Pruebas de Calidad
• Pruebas de Recuperación
• Pruebas de Mantenimiento
• Pruebas de Documentación
• Evaluación de Factores Humanos (Usabilidad)
25

26. P R U E B A S D E A C E P TA C I Ó N
26

27. P R U E B A S D E A C E P TA C I Ó N
Asegurarnos de que el software trabaja correctamente para los
stakeholders en su ambiente normal de trabajo
Pruebas Alfa
• El sistema completo es probado por el cliente, con la
presencia del equipo de desarrollo, en el sitio de desarrollo
Pruebas Beta
• El sistema completo es probado por el cliente, sin la
presencia del equipo de desarrollo, en el sitio del cliente
27

28. E S T R AT E G I A S PA R A P R U E B A S D E
A C E P TA C I Ó N
• Pruebas de Benchmark
• Pruebas Piloto
• Pruebas en Paralelo
28

29. H E R R A M I E N TA S D E P R U E B A
• Simuladores
• Programas monitores
• Analizadores de resultados
• Generadores de datos de prueba
29

30. E Q U I P O D E P R U E B A S
• Testers profesionales
• Analistas
• Diseñadores de sistema
• Especialistas de configuración
• Usuarios
30

31. 5 . 3 D I S E Ñ O D E P R U E B A S
El objetivo del proceso de diseño de casos de prueba
es crear un conjunto de casos de prueba que sean
efectivos descubriendo defectos en los programas y
muestren que el sistema satisface sus requerimientos.
31

32. P R O C E S O D E D I S E Ñ O
• Para diseñar un caso de prueba, se selecciona una
característica del sistema o componente que se está
probando.
• A continuación, se selecciona un conjunto de
entradas que ejecutan dicha característica,
documenta las salidas esperadas o rangos de salida y,
donde sea posible, se diseña una prueba
automatizada que prueba que las salidas reales y
esperadas son las mismas.
32

33. T I P O S D E A P R O X I M A C I O N E S
• Pruebas basadas en requerimientos
• Pruebas de particiones
• Pruebas estructurales
• Pruebas de caminos
33

34. P R U E B A S B A S A D A S E N
R E Q U E R I M I E N T O S
• Los casos de prueba se diseñan para probar los
requerimientos del sistema
• Se usa generalmente en las pruebas del sistema
• Se identifican casos de prueba que puedan demostrar
que el sistema satisface ese requerimiento
34

35. P R U E B A S D E PA R T I C I O N E S
• Se identifican particiones de entrada y salida y se
diseñan pruebas para que el sistema ejecute entradas
de todas las particiones y genere salidas para todas
las particiones
• Las particiones son grupos de datos que tienen
características comunes
35

36. P R U E B A S E S T R U C T U R A L E S
• Se utiliza el conocimiento de la estructura del
programa para diseñar pruebas que ejecuten todas las
partes del sistema
• Cuando se prueba un sistema debería ejecutar cada
instrucción al menos una vez. Las pruebas
estructurales deben ayudar a hacer eso
36

37. P R U E B A S D E C A M I N O S
• Es una estrategia de pruebas estructurales cuyo
objetivo es probar cada camino de ejecución
independiente en un componente o programa
• Se pruebas cada instrucción al menos una vez. Las
condiciones se prueban en verdadero y falso
37

38. 5 . 4 C A S O S D E E S T U D I O D E
P R U E B A S D E S O F T WA R E
38

39. C A S O 1 : G O O G L E Y S U S P R U E B A S D E
1 0 M I N U T O S
“Cada 10 minutos cambiaba de aplicación. Y a medida que los minutos
pasaban mi equipo iba entendiendo el mensaje: descartaron la idea de
describir el problema, la aplicación o cualquier cosa innecesaria. Cambiaron
prosa por listas de viñetas. Caso omiso a cualquier información no relevante
para el testing. Si no era importante, lo ignoraban. No había tiempo.”
Así creamos el método ACC (atributos, componentes y capacidades)
• Atributos (valor del producto para el usuario)
• Componentes (enumerar, de memoria, los componentes del software)
• Capacidades (las acciones que realiza el sistema)
Caso de estudio: Cómo hace Google sus planes de pruebas (y los hace en menos de 10 minutos) http://
www.javiergarzas.com/2012/12/google-pruebas.html
39

40. C A S O 2 : P O K E R O N L I N E A P P
Real Poker Online es una app cliente servidor desarrollada en Java que permite
a jugadores de todo el mundo jugar poker
Se busca validar los requerimientos, además de la escalabilidad del proyecto
(Eclipse IDE, Ant, JUnit, XDoclet, Hibernate JDO, Tapestry Web Application
Framework, Hessian RPC, Sun ONE J2EE 1.3 certified application server, Firebird
RDBMS y Tomcat)
La estimación inicial para las pruebas hecha por el cliente era de 8000 horas-
hombre
Bughuntress propuso pruebas automatizadas en vez de un proceso manual: caja
negra, simulación, funcionalidad, estrés, usabilidad y pruebas de apuestas
lógicas. Las pruebas finalmente requirieron 2500 horas-hombre
CASE STUDIES: ONLINE GAME: http://www.bughuntress.com/portfolio/case-studies/poker-online
40

41. C A S O 3 : U S O D E H E R R A M I E N TA S D E
S O F T WA R E L I B R E
Reto:
Las empresas deben entender los riesgos y mitigar los problemas que su desarrollo web enfrenta durante la
etapa de desarrollo y cuando la aplicación se encuentra en producción
Solución:
PushToTest Turnkey Testing Services identifica y resuelve las causas de problemas de rendimiento y seguridad
en ambientes de múltiples proveedores
Resultados:
• Desarrollo de scripts de pruebas y ejecución de pruebas funcionales y en pruebas de rendimiento y
volumen
• Costo: comparado con herramientas propietarias, las soluciones de PushToTest ahora el 895% en la
creación de pruebas y el 33% en las pruebas reales
• Certificación: PushToHelp ayuda a mitigar los riesgos en pruebas funcionales, de seguridad y rendimiento
PushToTest Case Studies: http://www.pushtotest.com/software-testing-case-studies.html
41

42. C A S O 4 : T E S T I N G Á G I L D E S O F T WA R E
C O N H E R R A M I E N TA S L I B R E S Y A B I E R TA S
El paper describe las pruebas de software mediante el uso de una metodología
ágil (SCRUM) y herramientas de software libre y abierto aplicadas a un proyecto
en particular: SWEST (Software para Empresas deServicios Temporales)
• Necesidad urgente del cliente por tener en producción la aplicación, en
concreto el módulo de nómina
• Antecedentes de fallos e incidencias en la primera versión del módulo de
nómina
• Necesidad de mostrar resultados en el menor tiempo posible.
Tres herramientas utilizadas y probadas: TestLink, Mantis y PangoScrum
Paper en: http://www.academia.edu/2332917/Testing_
%C3%81gil_de_Software_con_Herramientas_Libres_y_Abiertas
42

43. C A S O 5 : P R U E B A S D E C O M PAT I B I L I D A D
D E G U I
El cliente: proveedor líder de fotografía y contenidos para empresas en el ramo de
hoteles y viajes
El reto: asegurar la compatibilidad de su UI en varias plataformas sin ningún problema
La solución:
• Análisis de requerimientos utilizando la arquitectura y escenarios de alto nivel
• Pruebas de las interfaces con escenarios y prototipos
• Casos de prueba para diferentes medios ambientes y resoluciones
• Reportes diarios
• GUI COMPATIBILITY TESTING CASE STUDY: http://www.optimusinfo.com/case-
study/gui-compatibility-testing/
43