Presentación referente a lo tipos de pruebas que existen para los software convencionales u Orientados a Objetos.

1. Álvarez, David
Gasperin, Lucía
Herrera, Jorge
Rivas, Edixson
Rodríguez, Ronald
Seijas, Fanny

2. Prueba según el DICCIONARIO DE LA LENGUA
ESPAÑOLA - Vigésima segunda edición
Acción y efecto de probar.
Razón, argumento,
Análisis médico.
instrumento u otro medio
con que se pretende
mostrar y hacer patente la
Indicio, señal o verdad o falsedad de algo.
muestra que se da
de algo.
Examen que se hace para
demostrar o comprobar
Ensayo o experimento que los conocimientos o
se hace de algo, para saber aptitudes de alguien.
cómo resultará en su forma
definitiva.
Muestra, cantidad pequeña de
un alimento destinada a
examinar su calidad.

3. Según IEEE
ERROR DEFECTO FALLA

4. Según Cem Kaner
Resultados esperados
¿Cómo sabemos que
paso o fallo las pruebas?

5. Testers:
¿Quién hace las pruebas?
Cubrimiento: Evaluación:
¿Qué estamos probando? Criterio para evaluar.
Riesgo: Actividades:
¿Qué estamos probando? ¿Cómo probamos?

6. Motivación
Las pruebas son incómodas
La pruebas son aburridas
“Estoy seguro de que lo he codificado bien”
Probar todo junto, al final – Big-Bang
Falla por todas partes
Muy difícil diagnosticar las causas de los fallos
Muy costoso de arreglar
Resultado productos finales defectuosos

7. “Encontrar Errores”
Algunos autores como Krutchen, Pressman, “Propiciar la calidad en el
Pfleger, Cardoso y Sommerville afirman Software”
que el proceso de ejecución de Pruebas
debe ser considerado durante todo el ciclo
de vida de un proyecto, para así obtener un Según Gonzáles, Javier. (2002), el
producto de alta calidad. Su éxito aseguramiento de la calidad toma
dependerá del seguimiento de una en cuenta todas aquellas acciones
Estrategia de Prueba adecuada. planificadas y sistemáticas
necesarias para proporcionar la
Requerimientos del Software confianza de que un producto o
servicio satisfaga los requisitos de
Según Sommerville, Bosch, Dromey, Pressman calidad establecidos.
entre otros, los requerimientos del software se
clasifican en:
 Requerimientos Funcionales (RF) y
 Requerimientos No Funcionales (RNF).
Requisitos
del usuario Sistema software
Proceso de desarrollo
de Software

8. Doc. Requisitos
Análisis
P. validación
Diseño
P. integración
Doc. Diseño
Codificación P. unidades
Cod. Módulos
Integración
Cód. Completo
Mantenimiento

9. “La estrategias de Prueba permiten identificar las Características
de Calidad que deben ser evaluadas en un software:”
• Fiabilidad
• Usabilidad
Convencional • Eficiencia
• Mantenibilidad
• Portabilidad.
• Localización
• Encapsulamiento
• Ocultamiento de
O.O. información
• Herencia
• Técnicas de abstracción
de objetos.
Ortega, M. Pérez, M. & Rojas, T. (2003). Construction of a Sistemic Quality Model for Evaluating a
Software Product. Software Quality Journal, 11, 219-242.

10. Barry Boehm:
divide en 4 sectores
 definición de objetivos,
PROGRESO
restricciones del producto y DETERMINAR
OBJETIVOS,
A TRAVÉS
DE LAS ITERACIONES
EVALUAR
ALTERNATIVAS,
proceso, plan de ALTERNATIVAS Y
RESTRICCIONES
IDENTIFICAR Y
RESOLVER RIESGOS
administración,... Análisis de
riesgos
 evaluación y reducción de Análisis de riesgos
riesgos (por ejemplo, mejor
Análisis de riesgos
definición de requerimientos Prototipo
operativo
An.
mediante prototipos) Riesgo.
Proto-
- Prototipo 2
Prototipo 3
REVISIÓN tipo 1

Simulaciones, modelos,
desarrollo y validación: Plan de
.
requerimientos Concepto de
pruebas comparativas
operación
elección de un modelo para Plan de ciclo
de vida Requerimientos
de software
el desarrollo Plan de Validación de
Diseño del
producto
Diseño
detallado
desarrollo requerimientos
 planificación: el proyecto se Plan de integración
Diseño de validación
Codificar
y prueba
revisa y se decide si se PLANIFICAR SIGUIENTE
y verificación Prueba de
unidad
FASE
continúa con el siguiente Prueba de
Prueba de integración
ciclo. si es así, se planifica -
Explotación
aceptación
DESARROLLAR, VERIFICAR
la siguiente fase PRODUCTO DE SIGUIENTE NIVEL

11. Laboratorio de Investigación de Sistemas de Información (LISI)
Departamento de Procesos y Sistemas, Universidad Simón Bolívar
Anna. C Grimán, María Pérez, Luis. E Mendoza
La formulación de la Estrategia de Prueba para Software aquí propuesta
contempló cinco pasos:
 Identificación de las Etapas del Proceso de Pruebas,
 Propuesta del Instrumento de Medición: Las Listas de Chequeo,
 El Diseño y Registro de Casos de Prueba, y
 Establecimiento de Pautas para Procesar los Resultados y
 Diseño Final de la EPSOO.
Identificación de las Etapas del Proceso de Pruebas:
Se inspiró en las Actividades Clásicas del Proceso de Desarrollo (ACPD), es
decir: Análisis, Diseño e Implantación; ya que las mismas se encuentran
actualmente presentes, a manera de disciplinas, en la mayoría de los procesos de
desarrollo.

12. Sub Características Objetivo Técnicas que Aplican
Madurez. Evaluar la capacidad que tiene el Prueba Negativa: Hacer que el sistema falle intencionalmente
software para evitar fallas para medir su capacidad de respuesta frente a un error.
Tolerancia a Verificar la capacidad del oftware Prueba de Valores Límites: Evaluar valores frontera; es decir,
para mantener un nivel de los valores mínimo y máximo que la unidad puede aceptar.
Fallas rendimiento específico ante un Prueba Bajo Stress: Evaluar la habilidad del sistema para seguir
error, es decir, la capacidad de operando apropiadamente ante bajos recursos o
continuar procesando en caso de competencias para los recursos. Ejecutar el sistema de
falla. manera que demande recursos en cantidad, frecuencia o
volúmenes anormales.
Prueba Negativa: Hacer que el sistema falle intencionalmente
para medir su capacidad de continuar su ejecución a pesar
de la falla.
Prueba de Volumen: Someter al software a una gran cantidad de
datos para determinar si los límites alcanzados hacen que
este falle.
Recuperabilidad Verificar que el proceso de Prueba de Recuperación: Exponer al software a condiciones
recuperación del sistema restaura extremas y verificar que la recuperación se realiza
apropiadamente la base de datos, correctamente.
la aplicación y el sistema a un
estado conocido o deseado
Correctitud 1) Evaluar la capacidad de Prueba Estructural: Verificar que las formas estructurales de
cómputo. las clases sean completas.
2) Comprobar la completitud de Prueba de Ejecución: La capacidad de cómputo esperada se
las formas estructurales y del puede evaluar durante la ejecución del software en
software como un todo. aquellos módulos en donde se apliquen cálculos.
3) Evaluar la consistencia. Prueba de Carga: Probar diferentes cargas para evaluar la
capacidad de cómputo.
Estructurado Que siga las reglas de Prueba Estructural: Esta técnica permite evaluar los valores de
Programación las variables, las constantes y los tipos de datos y si éstos
Estructurada. son usados en el contexto en que se definieron.
Encapsulado. Verificar que sea encapsulado, Prueba Estructural: Esta técnica permite evaluar los valores de
las variables, las constantes y los tipos de datos y si éstos
son usados en el contexto en que se definieron.

14. Son el proceso de revisión que el sistema de software
producido cumple con las especificaciones y que
cumple su cometido.
Se trata de evaluar el sistema o parte de este
durante o al final del desarrollo para determinar
si satisface los requisitos iniciales.
La validación es el proceso de comprobar lo
que se ha especificado es lo que e usuario
realmente quería.
Utiliza técnicas tales como evaluaciones,
inspecciones, y tutoriales.
Como en otras etapas de la
prueba, la validación permite
descubrir errores, pero su enfoque Las expectativas razonables están definidas en
está en el nivel de requisitos - la Especificación de Requisitos del Software,
sobre cosas que son necesarias contenidas en una sección denominada
para el usuario final.
Criterios de validación
http://es.wikipedia.org/wiki/Pruebas:_de_validaci%C3%B3n (Presuman, Roger…5ta Edición Pag 316)

15. Condiciones en cada caso de prueba:
 Las características de funcionamiento o de
rendimiento están de acuerdo con las especificaciones
y son aceptables.
 Se descubre una desviación de las especificaciones
y se crea una lista de deficiencias.
Revisión de la configuración
La intención de la revisión es asegurarse de que todos
los elementos de la configuración del software se han
desarrollado apropiadamente, a veces denominada
auditoria.
Pruebas Alfa y Beta
Es virtualmente imposible que un desarrollador de
software pueda prever cómo utilizará el usuario
realmente el programa.

16. Objetivo:
Buscar discrepancia entre el software y sus objetivos originales
(Requerimientos funcionales y no funcionales).
Las Funciones del sistemas o del programa completo no son probadas en esta
parte ya que implicaría una Redundancia con las Pruebas Funcionales.
Procurar demostrar como el producto (software, sistema, aplicación) no
resuelves sus objetivos o requerimientos planteados por los usuarios.
Principales tipos de Pruebas:
Recuperación: Forza al fallo del software y verifica que la recuperación
se lleva a cabo apropiadamente.
Usabilidad: Verifica el sistema por medio de las interacciones
realizadas por un grupo de usuarios.
Rendimiento: Verifica el rendimiento del sistema (tiempo de
respuesta) para realizar una tarea en situaciones
particulares . (Cargas, Estrés, Estabilidad, Picos)
Seguridad: Verifica que un usuario solo puede tener acceso a
datos y funciones autorizadas.

17. Elementos de una Prueba:
 Interacciones entre el Sistema y la Prueba (Propósito)
 Valores de Prueba (Pasos de ejecución)
 Resultados Esperados.
Los dos primeros permiten realizar la prueba y el ultimo evaluar si la prueba
se supero o no.
Fases de una Prueba: (Métodos y Herramientas)
Análisis y Diseños de pruebas
Codificación
Ejecución
Análisis de Resultados

18. La prueba, es el proceso mediante el
cual se detecta inicialmente el error.
Obtención de salida
incorrecta
Realización de
operaciones fuera de lo
normal
No finalización del
programa (ciclos infinitos)
Caídas del programa
Es el proceso de identificar la raíz de un error y corregirlo.

19. Bradley describe el enfoque de la depuración de la siguiente forma:
Fuerza Bruta
Es probablemente la más común y menos eficiente a la hora de aislar
la causa del error en el software. Se aplica cuando todo lo demás
falla. Mediante una filosofía de «dejar que la computadora encuentre
el error», se hacen volcados de memoria, trazas de ejecución y se
cargan multitud de sentencias Mostrar en el programa.
Vuelta Atrás
Se puede usar con éxito para pequeños programas.
Partiendo del lugar donde se descubre el síntoma, se
recorre hacia atrás (manualmente) el código fuente hasta
que se llega a la posición de error. A medida que aumenta el
número de líneas del código, el número de posibles
caminos de vuelta se hace difícilmente manejable.
Eliminación de Causas
Se manifiesta mediante inducción o
deducción. Se llega a una «hipótesis de causa» y
se usan los datos anteriores para probar o revocar
la hipótesis.

20. Estabiliza el • Debes hallar un caso de prueba que produzca
error el error y debe ser lo más simple posible.
Localiza la • Observar el comportamiento bajo
fuente del error condiciones controladas
• Errores de Programación
Corrige el error • Errores de Sintaxis
Prueba la • Con el caso de prueba y otras hipótesis
corrección
Busca errores • Verifica si existen otras partes del programa
similares donde pusiese presentar el mismo error.
http://www.galeon.com/neoprogramadores/howdebug.htm, Charles Connell . Escrito por J. F. Díaz.
Consultado el 01/05/2010..

21. • Comprende el • Cambia el
problema antes código solamente
de corregirlo por buenas
• Relájate razones
• Comprende el
programa, no • Guarda una • Haz un cambio a
sólo el problema copia del código la vez
• Confirma la original • Verifica tu
diagnosis del • Corrige el corrección
error problema, no los • Observa errores
síntomas similares

22. http://www.galeon.com/neoprogramadores/citas001.html