Este documento presenta los fundamentos de las pruebas de software, incluyendo técnicas como caja blanca, derivación de casos de prueba a partir de casos de uso, y el uso de matrices de grafos. Explica conceptos como flujo de pruebas de software, diseño de casos de prueba, y objetivos de prueba como verificar la funcionalidad y el funcionamiento interno de un producto.

1. Asignatura: Integrantes:
Implantación de Sistema Erick Castillo
Profesor: Carlos Barrios
Edecio Sneider Salero
Sección: Oryeli Arellano
7D01IS Luis Garcia
Joel Soteldo
José Torres
República Bolivariana de Venezuela
Ministerio del Poder Popular para La Defensa
Universidad Experimental Nacional Politécnica
De la Fuerza Armada
Núcleo-Lara
Barquisimeto Abril del 2018

3. Fundamentos de Prueba del Software
Operatividad
Controlabilidad
Observabilidad
Comprobabilidad
Mientras mejor funcione, más
eficientemente puede probarse
Lo que ve es lo que prueba. Las entradas
proporcionadas como parte de las pruebas
producen distintas salidas.
Mientras mejor pueda controlar el
software, más podrá automatizar y
optimizar las pruebas

4. Simplicidad
Comprensibilidad
Estabilidad
Descomponibilidad
Al controlar el ámbito de las pruebas,
es posible aislar más rápidamente los
problemas y realizar pruebas nuevas y
más inteligentes
Mientras haya menos que probar,
más rápidamente se le puede
probar
Mientras menos cambios, menos
perturbaciones para probar
Mientras más información se tenga,
se probará con más inteligencia

5. OBJETIVOS DE LA PRUEBA
conocer la función específica que
se asignó a un producto para su
realización
conocer el funcionamiento interno de un
producto, pueden realizarse pruebas
para garantizar que “todos los engranes
embonan”

6. Diseño de casos de pruebas

7. Flujo de pruebas de un software
Un conjunto de pruebas es una colección de casos de
prueba que se han agrupado para la ejecución de pruebas.
Los conjuntos de pruebas incluyen pruebas manuales y
automatizadas, pero son más beneficiosas cuando se
dispone de una serie de pruebas automatizadas que se
pueden ejecutar sin supervisión.

8. Diagrama de flujo de trabajo para
ejecución de conjunto de pruebas
 Flujo  Descripción
1. Cree casos de prueba.
2. Opcional: cree scripts de prueba y asócielos
a los casos de prueba.
3. Opcional: añada los casos de prueba a un
plan de prueba.
4. Analice los casos de prueba y los scripts de
prueba existentes en su entorno para determinar
cuales formarán parte de la nueva conjunto de
pruebas.
5. Cree una nueva conjunto de pruebas.
6. Opcional: añada el conjunto de pruebas a
un plan de prueba.
7. Añada casos de prueba existentes a el
conjunto de pruebas.
8. Cree un registro de ejecución de conjunto de
pruebas único.
9. Ejecute el conjunto de pruebas.
10. Analice los resultados.

9. Caja blanca
Se centran en los detalles procedimentales del software, por lo
que su diseño está fuertemente ligado al código fuente.
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, modulo, etc.

10. Caja blanca
• Las principales técnicas de diseño de pruebas de
caja blanca son:
• Pruebas de flujo de control
• Pruebas de flujo de datos
• Pruebas de bifurcación
• Pruebas de caminos básicos

11. • Para aplicar la técnica del camino básico se
debe introducir una sencilla notación para la
representación del flujo de control, el cual
puede representarse por un grafo de flujo.
Un grafo de flujo esta representado por 3
componentes fundamentales.

12. Componentes
• Nodo: Cada circulo representado se denomina nodo del grafo de flujo,
el cual representa una o mas secuencias procedimentales.
• Aristas: Las flechas del grafo se denominan aristas y representan el
flujo de control.
• Regiones: Son las áreas delimitadas por las aristas y nodos.

13. Complejidad ciclomatica
Es una métrica de software extremadamente útil pues
proporciona una medición cuantitativa de la
complejidad lógica de un programa.

14. Los pasos para desarrollar la prueba del
camino básico son:
1.- Dibujar el grafo de flujo
2.- Calcular la complejidad ciclo matica
3.- Determinar el conjunto básico de caminos
independientes

18. La complejidad ciclo mática mide el número de caminos
independientes dentro de nuestro código que es sometido a
prueba. La fórmula para su cálculo es:
V(G) = a – n +2
dónde:
a: Es el número de aristas (lados)
n: Es el número de nodos (vértices)
En nuestro ejemplo la formula queda de la siguiente forma:
V(G) = 11 – 9 + 2 = 4

19. Vamos formando los caminos independientes (4 según la
complejidad ciclo matica) desde el más largo al más corto
observando nuestro grafo de flujo.

20. Derivación de casos de prueba a
partir de casos de Uso
• En esta técnica no utilizaremos ese tipo de
diagramas sino las descripciones de los casos de
uso, lo que nos indica cuál es la interacción
esperada entre el usuario y el sistema para realizar
determinada acción o lograr determinado
cometido.

21. Derivación de casos de prueba a partir
de casos de Uso
Luego de contar con estos insumos será sencillo derivar los casos de
prueba funcional de una aplicación. A continuación se presenta un
diagrama que permite observar su proceso de diseño:

22. Derivación de casos de prueba a
partir de casos de Uso

23. La plantilla de caso de prueba que se referencia en los pasos 4 y 6 del diagrama
se presenta a continuación:

24. Matrices de grafos
Es una matriz cuadrada cuyo
tamaño (es decir, el número de
filas y de columnas) es igual al
número de nodos del grafo de
flujo. Cada fila y cada columna
corresponde a un nodo
especifico y la entradas de la
matriz corresponden a las
conexiones (aristas) entre los
nodos

25. Matrices de grafos
Conexiones
1- 1 = 0
Cada fila y cada columna corresponde a
un nodo específico y las entradas de la
matriz corresponden a las conexiones
(aristas) entre los nodos
2- 1 = 1
2- 1 = 1
2- 1 = 1/3 +1 =4
usaremos la forma más
simple de peso, que indica
la existencia de conexiones
( O ó 1). La matriz de grafo
de la Figura anterior se
rehace tal y como
se muestra en la matriz
mostrada reemplazado
cada
letra por un 1, indicando la
existencia de una conexión
(se han excluido los ceros
por claridad). Cuando se
representa de esta forma,
la matriz se denomina
matriz
de conexiones.

26. GRACIAS POR SU ATENCION