Ingenieria de software

1. Prueba del Software
Docente: Jesús Ulloa Ninahuamán

2. INTRODUCCIÓN
• Definición 1: La prueba
(testing) es el proceso de
ejecutar un programa
con la intención de
encontrar fallos.
• Un buen caso de prueba
es el que tiene alta
probabilidad de detectar
un nuevo error.
• Un caso de prueba con
éxito es el que detecta
un error nuevo.

3. INTRODUCCIÓN
• Definición 2: Una
investigación técnica del
producto bajo prueba
para proporcionar a los
interesados (stakeholders)
información relacionada
con la calidad.
• Para el efecto se tiene
establecido las fases,
como prueba de calidad
de software.

4. INTRODUCCIÓN
EJEMPLO:
Especificación:
• Un programa lee tres valores enteros desde la pantalla.
• Los tres valores son interpretados de forma que representan
las longitudes de los tres lados de un triángulo.
• El programa muestra un mensaje que indica si el triángulo es
escaleno (todos los lados distintos), isósceles (dos iguales) o
equilátero (todos iguales)
Problema:
• Escribir el conjunto de casos de prueba que se consideren
adecuados para probar este programa.

5. DEFINICIONES
• Error: Una equivocación de una persona al desarrollar
alguna actividad de desarrollo del software.
• Defecto: Se produce cuando el software presenta
algún error (vista interna detectado por
desarrolladores).
• Falla: Es un desvío respecto del comportamiento
esperado del sistema (vista externa, detectado por los
usuarios).

7. PRINCIPIOS
Los principios más relevantes son los siguientes:
• Un programador debe evitar probar su propio
desarrollo.
• Una organización, no debe probar sus propios
desarrollos.
• Los test deben incluir entradas inválidas e
inesperadas, así como las válidas y esperadas.
• No planear esfuerzos de prueba, asumiendo que no
se encontrará errores.
• El “testing” constituye una tarea creativa e
intelectualmente desafiante.

8. NIVELES DE PRUEBAS
• Unitario: Detecta errores en los datos, lógica y
algoritmos, participa los programadores y es usado el
método “Caja Blanca”
• Integración: Detecta errores de interfaces y relaciones
entre componentes, participa los programadores y es
usado los métodos “Caja Blanca, Top Down, Bottom
Up”
• Funcional: Detecta errores en la implementación de
requerimientos, participa los Testers y Analistas y se
usa el método funcional.

9. NIVELES DE PRUEBAS
• Sistema: Detecta fallas en el cubrimiento de los
requerimientos, participa los Testers y Analistas y se
usa el método funcional.
• Aceptación: Detecta fallas en la implementación del
sistemas, participa los Testers, Analistas y Cliente; y se
usa el método funcional.

10. MÉTODOS DE PRUEBAS
• Caja Negra: Realizar pruebas de forma que se
compruebe que cada función es operativa.
Los casos de prueba pretenden demostrar que las
funciones del software son operativas, que la entrada se
acepta de forma adecuada y que se produce una salida
correcta. Los tipos de prueba de mas relevantes son:
Prueba de partición equivalente
Prueba de análisis de valores límites

11. MÉTODOS DE PRUEBAS
• Caja Blanca Desarrollar pruebas de forma que se
asegure que la operación interna se ajusta a las
especificaciones, y que todos los componentes
internos se han probado de forma adecuada.
• Los tipos de prueba de Caja Blanca mas relevantes
son:
Prueba del camino básico.
Prueba de bucles

12. EJEMPLO CASO DE PRUEBA
• Diseñe los casos de prueba para la siguiente función:
char* LoadFile(char filePath[MAX_PATH], char* mode,
DWORD dwDesiredAccess, DWORD
dwCreationDisposition)
Antes de empezar a pensar que hacer, deben definir
una pequeña estrategia que debería responder al
menos cuatro preguntas 1-¿Qué se va a probar?, 2-
¿Desde cual perspectiva se va a probar?, 3-¿A qué nivel
se va a probar? y 4-¿con cuáles técnicas voy a probar?.
Responder las anteriores preguntas me da una visión
más clara del objetivo de mis pruebas.

13. EJEMPLO CASO DE PRUEBA
• Quién te encargó diseñar los casos de pruebas solo
debería contestarte la pregunta 1-¿Qué se va a
probar?, las demás debería definir el Analista y/o
programador.
• Se desea probar “los requerimientos funcionales, no
funcionales y la cobertura de código.” ¿Cuáles son los
requerimientos?
• “la función debe recibir una ruta de máximo 256
caracteres (mínimo 4 caracteres) y debe cargar de allí
el contenido del archivo en un vector. El contenido de
los archivos puede ser cualquier byte que se pueda
representar con un juego de caracteres ASCII”

14. EJEMPLO CASO DE PRUEBA
• Los requerimientos funcionales se prueban
usualmente a nivel de sistema.
• La perspectiva de pruebas será caja negra.
• Existen muchas técnicas para probar: Equivalence
Class Partitioning -ECP-, Boundary Value Analysis -
BVA- y Combinatorial (Pair wise) testing. Para nuestro
ejemplo utilizaremos una mezcla de las anteriores
técnicas.
• Aplicaremos ECP al parámetro 1 filePath porque
sabemos que puede ser cualquier cadena desde 4
hasta 256 caracteres de longitud.

15. MODELOS
• Modelo V: Describe la manera de aplicar
verificaciones y validaciones a los productos del SW.

16. PLAN DE PRUEBAS
• En esta actividad se inicia la definición del plan de
pruebas, el cual sirve como guía para la realización de
las pruebas, y permite verificar que el sistema de
información cumple las necesidades establecidas por
el usuario, con las debidas garantías de calidad.
• El plan de pruebas es un producto formal que define
los objetivos de la prueba de un sistema, establece y
coordina una estrategia de trabajo, y provee del
marco adecuado para elaborar una planificación paso
a paso de las actividades de prueba.

17. PLAN DE PRUEBAS
• El plan se inicia en el proceso Análisis del Sistema de
Información (ASI), definiendo el marco general, y
estableciendo los requisitos de prueba de aceptación,
relacionados directamente con la especificación de
requisitos.
• Dicho plan se va completando y detallando a medida
que se avanza en los restantes procesos del ciclo de
vida del software, Diseño del Sistema de Información,
Construcción del Sistema de Información e
Implantación y Aceptación del Sistema.

18. ACTIVIDADES DEL PLAN DE PRUEBAS
Definición del Alcance de las Pruebas.
• Es posible que determinados niveles de pruebas sean
especialmente críticos y otros no sean necesarios.
• Por ejemplo, puede haber grandes diferencias en
función de una solución de desarrollo completo o un
producto de mercado cerrado integrado con otros
sistemas.
• En esta tarea se especifican y justifican de los niveles
de pruebas a realizar, así como el marco general de
planificación de cada nivel de prueba

19. ACTIVIDADES DEL PLAN DE PRUEBAS
Definición de Requisitos del Entorno de Pruebas.
• La realización de las pruebas aconseja disponer de un entorno
de pruebas separado del entorno de desarrollo y del entorno
de operación. En esta tarea se especifican y justifican de los
niveles de pruebas a realizar, según el siguiente esquema:
- Definición de los perfiles implicados y Planificación temporal.
- Criterios de verificación y aceptación.
- Definición, generación y mantenimiento de verificaciones y
casos de prueba.
- Análisis y evaluación de los resultados
- Productos a entregar como resultado de la ejecución.

20. ACTIVIDADES DEL PLAN DE PRUEBAS
Definición de las Pruebas de Aceptación del Sistema.
• En esta tarea se realiza la especificación de las
pruebas de aceptación del sistema. Se debe insistir,
principalmente, en los criterios de aceptación del
sistema que sirven de base para asegurar que
satisface los requisitos exigidos.
• Los criterios de aceptación deben ser definidos
prestando especial atención a aspectos como:
- Procesos críticos del sistema.
- Rendimiento del sistema.
- Seguridad.
- Disponibilidad.

21. GRACIAS