Presentación sobre pruebas del software. El documento que da soporte a esta presentación, puede ser solicitado en luiseduardo.pelaez@gmail.com

1. La prueba de Por otro lado, es de
software es una las actividades
paradoja. Por un menos entendidas
lado es conocida y aplicadas
por todos su
necesidad
–Roger S- Pressman, 2005

3. 1: Concepción
2: Objetivos
3: Localización de la prueba
4: Prueba vs Mantenimiento
5: Tipos de prueba
6: Niveles de la prueba
7: Métodos
8: Diseño de casos
9: Algunos casos…

4. Software testing is the process
conducted to provide stakeholders
with information about the quality of
the product or service under test. Test
techniques include, but are not
limited to, the process of executing a
program or application with the
intent of finding software bugs
(errors or other defects).

5. Pruebas (test): una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias
previamente especificadas, los resultados se observan y registran y se realiza una evaluación de algún
aspecto.
Caso de prueba (test case): la documentación en la que se describen las entradas, condiciones y salidas de
un de un diseño de caso de prueba.
Defecto (defect, fault, bug): un
defecto en el software como, por
ejemplo, un proceso, una definición
de datos o un paso de procesamiento
incorrectos en un programa.
Fallo (failure): la incapacidad de un
sistema o de alguno de sus
componentes para realizar las
funciones requeridas dentro de los
requisitos de rendimiento
especificados
Error (error): la diferencia entre un
valor calculado, observado o medido
y el valor verdadero, especificado o
teóricamente correcto. Por
ejemplo, una diferencia de dos
centímetros entre el valor calculado y
el real.

6. 1: Concepción
2: Objetivos
3: Localización de la prueba
4: Prueba vs Mantenimiento
5: Tipos de prueba
6: Niveles de la prueba
7: Métodos
8: Diseño de casos
9: Algunos casos…

7. •
•

8. Principios de la prueba del software
•
•
•
•
•
•
•

9. Principios de la prueba del software
• Un buen caso de prueba responde al
principio de formalidad de la prueba, y
la formalidad exige planificación y
diseño de pruebas.
• La probabilidad de la existencia de más
errores en una parte del software es
proporcional al número de errores ya
encontrados en dicha parte. Es un
fenómeno difícil de explicar, pero la
estadística así lo demuestra.
•
•

10. 1: Concepción
2: Objetivos
3: Localización de la prueba
4: Prueba vs Mantenimiento
5: Tipos de prueba
6: Niveles de la prueba
7: Métodos
8: Diseño de casos
9: Algunos casos…

12. 1: Concepción
2: Objetivos
3: Localización de la prueba
4: Prueba vs Mantenimiento
5: Tipos de prueba
6: Niveles de la prueba
7: Métodos
8: Diseño de casos
9: Algunos casos…

13. Las pruebas de software no son parte del mantenimiento.
Mas bien, impactan el desarrollo y el mantenimiento

14. La prueba afecta a ambas
En cuanto al uso, éste implica evolución, lo que conduce al
etapas del software (desarrollo
mantenimiento en el código. El mantenimiento puede ser:
y mantenimiento). La prueba
durante el desarrollo puede • correctivo (corrección de errores que aún no habían sido
afectar a cualquier fase, por descubiertos);
ejemplo: se está probando el • adaptativo (cambio en el entorno cambio de rendimiento para
producto y se detecta la una función dada, etc.); y
omisión de un requisito, lo que • aumentativo (inclusión de nuevas funciones, etc.). Tanto el
mantenimiento adaptativo como el aumentativo implican
implica
necesariamente, trabajar sobre código, lo que supone la
definirlo, diseñarlo, implementa existencia de pruebas
rlo y. por último,
probarlo.
Tangible Intangible
Se construye/fabrica Se diseña/desarrolla
Resulta un producto que se usa
Su uso genera confianza Su uso genera desconfianza
Hay deterioro No hay deterioro
Se agota/caduca Vence
Si el producto es software (lógico), el problema radica en que, en origen, el producto tiene fallos, pero no
hay repuestos, y por tanto el arreglo debe realizarse sobre el mismo producto, pero como éste es lógico, el
arreglo puede producir nuevos fallos: ¿por qué creer que cuando se arregla el software se está libre del
fallo, si cuando se desarrolla no se es capaz de estarlo? Nuevamente, la respuesta se halla en cómo se
prueba el producto.

15. 1: Concepción
2: Objetivos
3: Localización de la prueba
4: Prueba vs Mantenimiento
5: Tipos de prueba
6: Niveles de la prueba
7: Métodos
8: Diseño de casos
9: Algunos casos…

16. variety of tests
variety of stakeholders

17. Types Button-Up test
Tipos prueba que consideran la revisión de componentes con visión de lo
pequeño a lo grande, de lo primero hacia lo último y de manera jerárquica

18. Types Stand-alone test
Tipos prueba que consideran la revisión de componentes de manera independiente
visión futura de integración. Si funciona solo, luego funcionara con el todo.

19. ¿Cómo hace pruebas de software el ingeniero en la
actualidad?

20. Tipos de pruebas en el desarrollo de so
1: Unitarias (Unit)
2: Integración (Integration)
3: Regresión (Regression)
4: Humo (Smoke or Ad Hoc)
5: Sistema (System)
6: Desempeño (Performance)
7: Carga (Load & Stress)
8: Volumen (Volume)
9: Recuperación (Recovery)
10: Almacenamiento (Store)
11: Requerimientos funcionales (Functional)
12: Interfaz (GUI Test)
13: Instalación (Install)
A list of 100 types of Software Testing Types along with definitions. A must read
for any SQA professional.

21. Tipos de pruebas en el desarrollo de so
1: Unitarias (Unit)
2: Integración (Integration)
3: Regresión (Regression)
4: Humo (Smoke or Ad Hoc)
5: Sistema (System)
6: Desempeño (Performance)
7: Carga (Load & Stress)
8: Volumen (Volume)
9: Recuperación (Recovery)
10: Almacenamiento (Store)
11: Requerimientos funcionales (Functional)
12: Interfaz (GUI Test)
13: Instalación (Install)

22. «Es la primera prueba realizada de todo el proceso de
pruebas y corresponde con la prueba de cada módulo del
programa. La realiza el propio programador en su entorno
de trabajo. Quizás, la única que por conducta generada, se
permite que haga el mismo programador»
Centra sus actividades en
ejercitar la lógica del módulo
y los distintos aspectos de la
especificación del mismo. Un
error encontrado en esta fase
provocaría un retroceso a la
fase de diseño detallado e
implicaría revisar la lógica y/o
las especificaciones del
módulo.

23. Los lenguajes han avanzado
en la asistencia a las pruebas
unitarias, de tal manera que el
programador no deba
interactuar directamente con
ellas. Ejemplos de ellos son:
Junit, PHPUnit,
Microsoft.VisualStudio.Qualit
yTools.UnitTestFramework.
Nunit.
“Testing cannot be expected to
catch every error in the program:
it is impossible to evaluate every
execution path in all but the most
trivial programs”
- Microsoft, 1998

24. Prueba de la caja blanca

25. «La prueba de la caja blanca es un método
de diseño de casos de prueba que usa la
estructura de control del diseño procedimental
para derivar los casos de prueba.»
• Prueba del camino básico
• Notación del grafo de flujo o grafo del programa
• Complejidad ciclomática
• Prueba de bucles
• Bucles simples
• Bucles anidados
• Bucles concatenados
• Bucles no estructurados
• Prueba de la estructura de control
• Condición simple
• Condición compuesta
• Condición anidada

26. Tipos de pruebas en el desarrollo de so
1: Unitarias (Unit)
2: Integración (Integration)
3: Regresión (Regression)
4: Humo (Smoke or Ad Hoc)
5: Sistema (System)
6: Desempeño (Performance)
7: Carga (Load & Stress)
8: Volumen (Volume)
9: Recuperación (Recovery)
10: Almacenamiento (Store)
11: Requerimientos funcionales (Functional)
12: Interfaz (GUI Test)
13: Instalación (Install)