Pruebas de software

1. PRUEBAS
DE
SOFTWARE
FIS IX “C”
DOCENTE: DR. ANTONIO ALONSO MORALES LOAIZA

2. Integrantes
 MEJIA CUBA RICHARD LUIS
 SÁNCHEZ ANICAMA ALONSO RODRIGO
 TORNERO HUAMÁN PERCY ALVINO
 VELARDE MUÑANTE GLORIA ISABEL

3. PRUEBAS DE
CAJA NEGRA
Y CAJA
BLANCA
Verificación: “Estamos creando el producto correctamente”
Validación: “Estamos creando el producto correcto”

4. “ • ANÁLISIS DE COBERTURA Y
PRUEBAS BASADAS EN
ESTRUCTURAS (CAJA BLANCA)
• TÉCNICAS DE PRUEBAS
FUNCIONALES DE CAJA NEGRA

5. PRUEBAS DE SOFTWARE
OBJETIVOS
Detectar defectos
Verificar integración de los componentes
Verificar implementación de los requisitos
Asegurar que los defectos sean corregidos
Diseñar casos de pruebas

6. ESTRATEGIAS DE PRUEBAS DE SOFTWARE
CARACTERÍSTICAS
Las pruebas comienzan en el nivel de módulo, y trabajan
hacia afuera.
En diferentes puntos es adecuada la utilización de las
técnicas de pruebas.
La lleva a cabo el que desarrolla el software.
La prueba y depuración son actividades diferentes.

7. TIPOS DE ESTRATEGIAS GENERALES:
Estrategia de pruebas de especificación
Estrategia de pruebas de código
Pruebas Unitarias
Pruebas Integrales

8. ANÁLISIS DE COBERTURA – CAJA BLANCA
Es una medida porcentual en las pruebas de software que mide el grado en
que el código fuente de un programa ha sido comprobado.
De estructura de datos
locales
• Se centra en el estudio de
las variables del programa
De cobertura lógica
• De cobertura de sentencias
• De cobertura de decisión
• De cobertura de condición
• De condición múltiple
• De cobertura de caminos

9. CARACTERÍSTICAS DE LAS TÉCNICAS DE
CAJA BLANCA
▸ Este método se centra en cómo diseñar los casos de
prueba atendiendo al comportamiento interno y la
estructura del programa.
▸ Se examina la lógica interna del programa, sin considerar
los aspectos del rendimiento.
▸ Estas se basan en el diseño de Casos de Prueba que usa
la estructura de control del diseño procedimental para
derivarlos.

10. TÉCNICAS DE DISEÑO DE PRUEBAS DE
CAJA BLANCA
Las técnicas de pruebas de caja blanca nos permiten
comprobar los flujos de ejecución dentro de cada unidad,
función, clase, módulo; también pueden probar los flujos
entre unidades durante la integración, e incluso entre
subsistemas, durante las pruebas de sistema, el enfoque
permite diseñar pruebas que cubran una amplia variedad
de casos de prueba.

11. PRINCIPALES TÉCNICAS DE DISEÑO DE
CAJA BLANCA
▸ Pruebas de Flujo de Control
En estas pruebas se quiere encontrar errores en la parte
lógica del programa, utilizando las condiciones simples
o con condiciones complejas.
▸ Pruebas de Flujos de Datos
Esta técnica selecciona caminos de un programa de
acuerdo a las definiciones y usos de las variables.

12. PRINCIPALES TÉCNICAS DE DISEÑO DE
CAJA BLANCA
▸ Pruebas de Bifurcación
Con ella podemos definir si algún bucle está correctamente
implementado y si las líneas de código donde exista una
condición es la mejor opción o si debería ser cambiada.
▸ Pruebas de Caminos Básicos
Esta prueba lo que demuestra es el conjunto de pasos
base del programa, lo que quiere lograr es que cada
sentencia de código se ejecute mínimo una vez.

13. Pasos para aplicar pruebas de caminos básicos:
 Representar el programa en un grafo de flujo
 Calcular la complejidad ciclomática
 Determinar el conjunto básico de caminos
independientes
 Derivar los casos de prueba que fuerzan la
ejecución de cada camino

14. HERRAMIENTAS AUTOMÁTICAS PARA
TÉCNICAS DE CAJA BLANCA
HERRAMIENTA LENGUAJE
Coverage Python Python
PHPUnit PHP
JUnit JAVA
JSCoverage JavaScript
NUnit Microsoft .NET
Testdroid Android

15. PRUEBAS DE CAJA NEGRA
Mayor importancia de la
funcionalidad
Enfoque general en las entradas y
salidas
No se toma en cuenta la estructura
interna del código, en contraste con
las pruebas de caja cristal.

16. OTRAS DEFINICIONES
Ian Sommerville
• Enfoque a las pruebas donde los
examinadores no tienen acceso al código
fuente de un sistema o sus componentes
Ilene Burnstein
• Pruebas de comportamiento, las cuales se
enfocan en los requerimientos funcionales
del software

17. OBJETIVOS
Funciones incorrectas o faltantes
Errores de interfaz
Errores de comportamiento o
rendimiento
Errores de inicialización y terminación.

18. FUNCIONAMIENTO
“Lo que
se quiere
saber”
Pruebas de
caja opaca
Pruebas
inducidas por
datos
Pruebas de
entrada/salida

19. ¿CÓMO SE REALIZAN?
▸ Tester datos
▸ Funcionalidad
▸ Estudiar resultados
.

20. TÉCNICAS DE
PRUEBAS
Según estándares para Software Testing definidos por
ISTQB

21. PARTICIPACIÓN DE EQUIVALENCIAS
 Clasificar las entradas de datos del
sistema en grupos que presentan un
comportamiento similar
 Se pueden definir particiones tanto
para datos válidos como no válidos
 A partir de allí se definen pruebas
para cubrir todos o parte de las
particiones de datos válidos y datos
inválidos

22. Ejemplo – Participación de Equivalencias

23. Ejemplo – Participación de Equivalencias
TKTKASE. (2014, 11 de marzo). Foundation Level - ISTQB - Clases
de Equivalencia. Recuperado de:
https://www.youtube.com/watch?v=Uo2xvx7zhwo

24. ANÁLISIS DE VALORES BORDE
 Parte del principio que el
comportamiento al borde de una
partición de datos tiene mayores
probabilidades de presentar errores
 Los valores máximos y mínimos de
una partición son sus valores borde
 La capacidad de identificar defectos
de esta técnica es alta

25. Ejemplo – Análisis de Valores Borde

26. Ejemplo – Análisis de Valores Borde
TKTKASE. (2014, 11 de marzo). Foundation Level - ISTQB - Clases
de Equivalencia. Recuperado de:
https://www.youtube.com/watch?v=Uo2xvx7zhwo

27. Ejemplo – Análisis de Valores Borde
TKTKASE. (2014, 19 de marzo). Foundation Level - ISTQB - Valores
Límites. Recuperado de:
https://www.youtube.com/watch?v=7FMFXLmu-sw
VALORES SENSIBLES DE UNA VARIABLE

28. TABLA DE DECISIÓN
 Documentar reglas de negocio de alta complejidad
que el sistema debe cumplir
 Creadas desde el análisis de la especificación
funcional y la identificación de estas reglas de
negocio
 La tabla de decisión contienen las condiciones
desencadenantes, que son la combinación de
valores de verdadero o falso para cada entrada de
datos, así como la acción que resulta de cada
combinación
 Cada columna de la tabla corresponde con una
regla de negocio que representan la combinación
de condiciones, y las acciones que resultan

29. Ejemplo – Tabla de Decisión

30. Ejemplo – Tabla de Decisión

31. Ejemplo – Tabla de Decisión

32. Ejemplo – Tabla de Decisión

33. Ejemplo – Tabla de Decisión
TKTKASE. (2014, 5 de abril). Foundation Level - ISTQB - Tablas de
Decisión. Recuperado de:
https://www.youtube.com/watch?v=6g9cYF0_J7Q

34. Ejemplo N° 1
Técnica de pruebas de caja negra: Tablas de decisión.
Se tiene una aplicación de comercio electrónico. En la aplicación, todo cliente
que se esté registrando por primera vez en la suscripción a la membresía
Premium, recibe un 15% de descuento en su primera compra bajo el programa.
Adicionalmente, el cliente puede usar un cupón electrónico (distribuido por la
empresa en diversos medios). El descuento de 15% de primera compra y el
cupón no se pueden usar simultáneamente.

35. Caso de Uso

36. Ejemplo N° 2
Se tiene un sistema integrado de crédito bancario, donde en uno de sus
formulario hay un campo que recibe la fecha de nacimiento como parámetro
cuyo resultado sirva para saber si la persona en cuestión puede recibir un
préstamo, considerando obviamente que debe ser mayor de edad ni
sobrepasar la edad de 75 años para acceder al crédito.
Técnica de pruebas de caja negra: Partición de equivalencias y análisis de valores borde.

37. Caso de Uso

38. Ejemplo N° 3
En este último caso veremos el caso de un sistema de registros para la policía judicial
de Ica, para el control de personas requisitoriadas. Este sistema se desarrollo en dos
semanas, por lo que no hubo tiempo para realizar pruebas unitarias, y menos
inspeccionar el código a detalle, sin embargo cubre los requisitos primordiales del
usuario. Donde se clasifica a la persona según su estado actual (Proceso Vigente,
Capturado, Caducado y Sin efecto).
- Interfaz principal con datos estadísticos.
- Registro de campos para requisitoria personas.
- Modulo de creación de usuarios.
- Paneles de listas de registros.
Por lo que la única forma de saber si algo esta mal en código o en algún proceso, es al
momento que los usuarios experimenten fallas al momento de usarlo.
Enlace: https://www.sisdataint.com

39. Caso de Uso

40. Requerimientos del software
Campos que se registren y guarden correctamente en el sistema.
Que se verifique correctamente que se cambie de estado (Vigente, capturado,
caducado y sin efecto)
Que todos lo campos estén validados correctamente (fecha de registro, hora de registro
y usuario de registro)
Comprobación de modulo usuario, de acuerdo a las especificaciones, que muestre el nombre
Completo, el grado del policía, su DNI, su teléfono y su estado.
Verificación que las listas de los modulo estén completadas en un 100%.

41. GRACIAS POR
SU ATENCIÓN