Software Engineering: A Practitioner’s Approach, 6/e

Capitulo 13
Estrategias de Prueba de Software
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.

For University Use Only

May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1
 Prueba de software

Prueba es el proceso de ejercitar un

programa con la intencion especifica de
encontrar errores Antes de entregar el
producto al usuario final

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2
 Lo que pruebas mostran
errors
requirements conformance

performance

an indication
of quality

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3
 Quien Prueba el Software?

developer independent tester

Understands the system Must learn about the system,
but, will test "gently" but, will attempt to break it
and, is driven by "delivery" and, is driven by quality

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4
 Estrategias de Prueba
unit test integration
test

system validation
test test

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5
 Estrategia de Prueba
„ Iniciamos por “Probar Pequeñas partes” y evoluimos para
“probar grandes partes”
„ Para software Convencional
„ El modulo (componente) es el focus inicial
„ Sigue con la integracion de modulos
„ Para software OO
„ Nuestro focurs cuando “probamos pequeñas partes” cambia de un
modulo individual (la vision convencional) para una clase OO que
involucra atributos y operaciones y implica comunicacion y
colaboracion

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6
 Aspectos Estrategicos
„ Definir los objetivos de la prueba explicitamente .
„ Comprender los usuarios del software y desarrollar un profile para cada
categoria de usuario.
„ Desarrollar un plano de pruebas que enfatiza “Pruebas de ciclo rapido”
„ Utilizar revisiones tecnicas formales como un filtro entes de probar
„ Conducir revisiones tecnicas formales para evaluar la estrategia de prueba y
los casos de prueba propiamente..
„ Desarrollar una abordage de mejora continua para el proceso de pruebas.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7
 Prueba de Unidad

module
to be
tested
results
software
engineer
test cases

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8
 Prueba de Unidad
module
to be
tested
interface
local data structures
boundary conditions
independent paths
error handling paths

test cases
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9
 Ambiente de Prueba de
Unidad
driver
interface
local data structures
Module boundary conditions
independent paths
error handling paths
stub stub

test cases
RESULTS
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10
 Estrategias de Pruebas de Integracion
Opciones:
• Abordage “big bang”
• estrategia de construccion evolutiva

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11
 Integracion Top-down
A
top module is tested with
stubs

B F G

stubs are replaced one at

a time, "depth first"
C
as new modules are integrated,
some subset of tests is re-run
D E

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12
 Integracion Bottom-Up
A

B F G

drivers are replaced one at a

time, "depth first"
C

worker modules are grouped into

builds and integrated
D E

cluster
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13
 Prueba Sandwich
A
Top modules are
tested with stubs

B F G

Worker modules are grouped into

builds and integrated
D E

cluster
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14
 Prueba Orientada a Objetos

„ Comienza por la evaluacion de la correctitud y consistencia de

los modelos de la Analisis y Diseño OO
„ Cambios de la estrategia de prueba
„ El concepto de “unidad” se alarga debido al encapsulamiento
„ La intregacion se focaliza en las clases y su ejecucion en el contexto de
un escenario de uso.
„ Validacion utiliza metodos convencionales de caja negra.
„ Diseño de casos de prueba basado en metodos convencionales,
pero tambien incluye caracteristicas especiales

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15
 Ampliando la Vision de “Prueba”
Se puede argumentar que la revision de modelos de
la analisis y diseño OO es especialmente util
porque los mismos constructores semanticos (p.ej.,
clases, attributos, operaciones, mensajes) aparecen
en la analisis, diseño y implementacion. Asi, un
problema en la definicion en los atributos de clase
que es descobierto durante la analisis ira a prevenir
efectos colaterales para las fases de diseño y
codificacion.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16
 Tecnicas OO
1. Proyectos que consideran los escenarios como base
para casos de prueba (Casos de Uso y Diagramas de
Secuencia o colaboracion)
2. Tambien se considera diagramas de Estado para
construir casos de Prueba
3. Prueba de valores de atributos y operaciones de
clases

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17
 Estrategia de Prueba OO
„ Prueba de Clase es equivalente a Prueba de Unidad
„ Operaciones dentro de la clase son probadas
„ El comportamiento (estados) de una clase es examinado
„ Integracion es aplicada con tres diferentes estrategias
„ Prueba basada en thread—integra el conjunto de clases
requeridas para responder a una entrada o evento
„ Prueba basada en uso—integra el conjunto de clases
requeridas para responder a un caso de uso
„ Prueba de cluster—integra el conjunto de clases para
demonstrar una colaboracion

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 18
 Prueba Humo
„ Una bordage comun para crear “construcciones diarias” para un
producto de software
„ Pasos de Prueba Humo:
„ Componenets de Software que ya fueron traducidos en codigo son
integrados dentro de un “build”
„ Un build incluye archivos de datos, bibliotecas, modulos reutilizables y
componentes que son requeridos para implementar una o mas fucniones
del producto.
„ Una serie de pruebas es diseñada para exponer errores que impidan el build
de desempeñar adecauadamente su funcion. El proposito es descobrir
errores “bloqueadores” que tienen mayor probabilidad de atrasar el proyecto
de software
„ El build es integrado con otros builds y el producto entero pasa por la
prueba del humo diariamente.
„ El abordage puede ser top down or bottom up.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 19
 Vision de las Estrategias de Pruebas
„ Prueba de validacion
„ Focus esta en los requerimientos del software
„ Prueba de Sistema
„ Focus esta en la integracion del sistema
„ Prueba Alpha/Beta
„ Focus esta en la utilizacion del software por el cliente
„ Prueba de recuperacion
„ Forza el software a fallar en varias situaciones y verifica que la recuperacion
del software para estas fallas es apropiada
„ Prueba de Seguridad
„ Verifica que los mecanismos de proteccion construidos en el sistema lo
protegeran realmente de invasiones
„ Prueba de Stress
„ Ejecuta el sistema de forma a probar la demanda por recursos en una cantidad,
frequencia o volumen anormales
„ Prueba de Performance
„ Prueba el desempeño en tiempo de ejecucion del software en el contexto de un
sistema integrado.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 20
 Depuracion:
Un proceso de Diagnostico

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 21
 El proceso de Depuracion
test cases

new test results

regression cases
tests suspected
causes
corrections Debugging
identified
causes

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 22
 Esfuerzo de Depuracion

Tiempo requerido
Para Diagnosticar
Tiempo requerido el sintoma y
para corrigir un error determinar la causa
Y conducir pruebas
de regresion

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 23
 Tecnicas de Depuracion

Fuerza Bruta / Prueba

backtracking

Induccion/
Deduccion

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 24
 Depuracion: Ideas Claves
1. Piensa y analisa el sintoma que estas viendo.

2. Utiliza Herramientas (ej, depuradores dinamicos)

para observar dentro del codigo

3. Si llegas a un impase, solicita ayuda de otra persona

4. Estes absolutamente cierto de conducir pruebas

de regresion cuando “corrijas” un error

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 25