05/04/2011

Pruebas de Software

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Mapa conceptual
Identificar Prcticas Probar unidades por separado Usar implementaciones Aplicar disciplina Obtener cobertura

corporativas

Planear el proyecto

Analizar Requerimientos Design Integrate & test system Implement Test units

Maintain

05/04/2011

Reglas de Oro
Metas de las pruebas
Maximizar el numero y la severidad de los defectos encontrados Haga pruebas pronto

Limites de las pruebas

Probar solo puede determinar la presencia de los defectos, nunca la ausencia

Pruebas de unidad
3. System tests

Incluye C.U.

2. Integration tests Paquetes de Clases

Combinacin de modulos

1. Unit tests

Modulos

Combinacion de mtodos en las clases Mtodos

Funcin

05/04/2011

Pruebas de unidad en proceso unificado

Inception Elaboration Requirements Construction Transition

Analysis Design Implementation Test Unit Tests

Integration tests ... System tests

Prelim. iterations

Iter. #1

Iter. #n

Iter. #n+1

..

Iter. #m

Iter. .. #m+1

Iter. #k

Mapa conceptual
Requerimientos
1. Plan para pruebas de unidades
Identificar los mayores puntos de problemas potenciales

Diseo Detallado Plan de pruebas de unidades

Productos de pruebas anteriores

2. Adquisicin de conjunto de pruebas

Conjunto de pruebas
3. Ejecucion de pruebas de unidad

Cdigo que se prueba

Resultados de las pruebas

IEEE, 1986

05/04/2011

Tipos de pruebas
Entrada determinada por
requirements* Black box

Resultado
Salida real comparada con la salida requerida

Tipos de pruebas

Entrada determinada por

requerimientos Black box

Resultado
Salida real comparada con la salida requerida

requerimientos y Elementos de diseo clave

Gray box

Igual que para pruebas de caja negra y caja blanca

White box elementos De diseo Confirmacion de comportamiento esperado

05/04/2011

Intervalos de prueba: Casos elementales

1.Dentro del intervalo 2.En las fronteras del intervalo 3. fuera del intervalo
(ilegal)

intervalo

Trayectorias que deben verificarse

Establecer nombre igual a defaultName"

Tienen sentido los parametros y valores?

Nombre de parametro demasiado largo?

Establecer nombre igual a parametro

Truncar nombre

05/04/2011

Trayectorias que deben verificarse

Establecer nombre igual a defaultName"

Tienen sentido los parametros y valores?

Nombre de parametro demasiado largo?

Establecer nombre igual a parametro

Truncar nombre

PLAN DE PRUEBAS DE UNIDAD

05/04/2011

Plan de pruebas de unidades

1. Decida la filosofa de las pruebas de unidad
a) b) c) Es responsable un ingeniero individual? Revisadas por otros? diseadas y realizadas por otros?

2. Decida que / donde / como documentar

a) b) c) Se usan utilidades de herramientas /pruebas Conjunto de doc personales individuales Como / cuando incorporar otros tipos de pruebas

3. Determine el grado de las pruebas de unidades

a) b) No solo realice pruebas hasta que el tiempo expire Asigne prioridades para que las pruebas importantes se hagan

Plan de pruebas de unidades

4. Decida como y donde obtener los datos para las pruebas 5. Estime los recursos requeridos
a) Use datos histricos si estn disponibles b) Registre tiempo, cuenta defectos, tipo y fuente

05/04/2011

Pruebas de Unidad de metodos(Humphrey) 1/2 1. Verificar la operacin con valores normales de los parmetros
(prueba de caja negra basada en los requerimientos de la unidad)

2. Verificar la operacin en los valores limite de los parametros

(caja negra)

3. Verificar la operacin en los valores fuera de limite de los parametros (caja negra) 4. Asegurar que ejecuta todas las instrucciones 5. Verificar todas las trayectorias, incluidos ambos lados de todas las ramas 6. Verificar el uso de todos los objetos llamados 7. Verificar el manejo de todas las estructuras de datos 8. Verificar el manejo de todos los archivos

Pruebas de Unidad de metodos(Humphrey) 2/2

9. Checar la terminacin normal de todos los ciclos

10. Verificar la terminacin anormal de todos los ciclos 11. Checar la terminacion normal de todas las recursiones 12. Checar la terminacion anormal de todas las recursiones 13. Verificar el manejo de todas las condiciones de error 14. Verificar el tiempo y la sincronizacin 15. Verificar todas las dependencias de hardware
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

05/04/2011

Listas de verificacin para pruebas de clase Una vez probados los mtodos individuales de una clase, se puede pasar a la prueba de la clase como un todo. Esto significa ejecutar sus mtodos en combinacin o someter los objetos de la clase a eventos como una accin

Resumen
Pruebas de unidad = piezas Pruebas de integracin = un todo Caja negra: E/S Caja blanca : verifica procesos De muchas formas Asegura que esten completos Planeacion de pruebas, mas pronto / mejor Ayuda a aclarar los requerimientos
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

05/04/2011

Integracin, verificacin y validacin del sistema

Integracin, verificacin y validacin del sistema

Identify corporate practices

Construir rel sistema en etapas

planear la integracion de partes para llegar a un todo probar subensambles Ensamblar lo que va integrado Probar el sistema completo de varias maneras
Maintain

Plan project

Analyze requirements Design Implement Test units Integrate & test system

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

10

05/04/2011

Metas
Poder planear los modulos de integracin Comprender los tipos de pruebas requeridas Poder planear y ejecutar las pruebas
Mas alla del nivel de unidades

Integracin
Se refiere al proceso de ensamble En esta etapa de integracin del proceso en cascada suele producir sorpresas desagradables por incompatibilidad de las partes que se integran. En el proceso de desarrollo de software unificado intenta evitar la integracin explosiva mediante la integracin continua con mltiples iteraciones

11

05/04/2011

Unified Process for Integration & Test

Jacobson et al: USDP

Inception Elaboration Requirements

Construction

Transition

Analysis Design Implementation Test Unit Tests

Integration Integration tests ... System tests

Prelim. iterations

Iter. #1

Iter. #n

Iter. #n+1

..

Iter. #m

Iter. .. #m+1

Iter. #k

cliente Perdida de informacin Requirements prdida Arquitectura prdida prdida Diseo detallado prdida Cdfigo de funciones

Vision general del desarrollo de cascada con los problemas de perdida de informacin

Especificaciones de interfaz

prdida

Codigo de modulos (e.g., package)

After Myers

Codigo del sistema

12

05/04/2011

Verificacin, validacin y pruebas del sistema

Verificacin: se esta construyendo bien
Se construyen en la etapa presente justo aquellos artefactos que se especificaron en la etapa anterior.

Validacin : se contruye lo correcto

Se satisfacen los requerimientos segn se establecen en el SRS

order of testing

Requirements Docs. Architecture Docs. Docs. Detailed design Docs.

(11) Acceptance tests

Vision general de pruebas

(10) Installation tests (9) Usability tests (8) System tests (7) Regression tests (6) Integration tests (5) Interface tests (2),(4) Module tests (1),(3) Function tests

Interface specs

Function code Docs. Code + Module (e.g., package) code Code + Code + Code +

Iteration or System code

Complete code

13

05/04/2011

(11) Acceptance tests*

Requirements

Tested against requirements (validation)

(10) Installation tests*

(9) Usability tests*

(8) System tests* (7) Regression tests*

Pruebas de verificacin y validacin

(After Myers)
Includes : *use-cases performance testing

(1), (4) Function tests

Pruebas de verificacin y validacin (After Myers)

Requirements

(11) Acceptance tests* (10) Installation tests* (9) Usability tests* (8) System tests* (7) Regression tests* (6) Integration tests* (5) Interface tests (1), (4) Function tests

validation1

Architecture

verification2

Interface specs

verification2

Detailed design

verification2
(2), (3) Module tests

Note 1: Tested against requirements

Note 2: Tested against documents indicated

Includes : *use-cases performance testing

14

05/04/2011

El proceso de integracin
El tipo mas sencillo de integracin consiste en agregar nuevos elementos a la base en cada iteracin alrededor de un espiral

Build 1

15

05/04/2011

Build 2

Build 3

16

05/04/2011

Final Build of Single Level

Final Build of Double Level

17

05/04/2011

Build 1

Build 2

Proceso de Construccin

Build 3

Final Build of Single Level

1a Iteracin 2a Iteracin
Final Build of Single Level Final Build of Double Level

....

Design

Integracion con desarrollo en espiral

Second iteration

Requirements analysis

First iteration

2. Diseo para requerimientos adicionales

1. Obtener requerimientos adicionales

3. Codigo para diseo adicional 5. pruebas 4. Integracion de nuevo codigo Implementation Test

18

05/04/2011

Relacion de construcciones e iteraciones en el proceso unificado

Jacobson et al: USDP

Inception Elaboration Requirements

Construction

Transition

Analysis Design Implementation Test

1a construccion Para la iteration i

Ultima construccion para iteration i

Prelim. iterations

Iter. #1

Iter. #n

Iter. Iter. Iter. .. .. #n+1 #i #m

Iter. .. #m+1

Iter. #k

Construccin tpica 1

Module 1

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

19

05/04/2011

Construccin tpica 2

Module 1

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Unit-Oriented Build 1

Module 1

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

20

05/04/2011

Unit-Oriented Build 2

Module 1

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Unit-Oriented Build 3

Module 1

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

21

05/04/2011

Last Build

Module 1

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Unit-Oriented Build 1
Module 1

Build Sequences: Ideal vs. Typical

Unit-Oriented Build 3
Module 1 2 3 4

Last Build
Module 1 2 3 4

Typical Build 2
Module 1 2 3 4

Typical Build 1
Module 1 2 3 4

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

22

05/04/2011

1. Comprender la descomposicion de la arquitectura. Intentar hacer una arquitectura sencilla de integrar 2. Identificar las partes de la arquitectura que implementara cada iteracion
Construir clases de marcos de trabajo primero o en paralelo Si es posible, integrar continuamente Construir suficientes GUI para anclar las pruebas Documentar los req. para cada iteracion Intentar construir de abajo arriba al menos parte del tiempo Para que las partes esten disponibles cuando se quieran Intentar planear las iteracines para eliminar los riesgos Especificar las iteraciones y construir de manera que cada caso de uso dse maneje por completo

3. Descomponer cada iteracion en construcciones si es necesario 4. Planear las pruebas, revisar e inspeccionar el proceso 5. Refinar el programa para reflejar los resultados

Planear la integracion y la construccion

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Factores que determinan la secuencia de integracin

Uso de modulos por otros modulos

Factores tcnicos

Construir e integrar modulos usados antes que los modulos que los usan

Definicion y uso de clases y marcos de trabajo Prctica de integracin temprana Reduccin De riesgos Practica de partes de riesgo clave de la aplicacin lo ms pronto posible Mostrar partes o prototipos a los Requerimientos clientes

23

05/04/2011

Pruebas del sistema

Es la culminacin de las pruebas de integracin Aseguran que los requerimientos se cumplan Se validan los casos de uso

Types of System Tests* 1 Volumen Usabilidad

Somete al producto a la entrada de grandes cantidades de datos Mide la reaccion del usuario (Calificacin 1-10). Mide la velocidad para varias circunstancias Congigura los distintos elementos de hardware y software

Desempeo

Configuracion

Compatibilidad

Mide el tiempo de preparacin

Con otras aplicaciones designadas

Confiabilidad / disponibilidad
Mide el tiempo de operacion en periodos largos

Mide el tiempo de adaptacion

24

05/04/2011

Seguridad

Sujeta a intentos comprometedores

Uso de recursos

Mide el tiempo promedio para entrar (romper ) al sistema

Aptitud de Instalacion Recuperabilidad Funcionalidad

Mide el uso de RAM, espacio en disco etc Mide el tiempo de instalacion Fuerza actividades que desactivan la aplicacion
Mide el tiempo de recuperacion

Da servicio a las aplicaciones en diferentes circunstancias

Mide el tiempo de servicio

Carga / Tension

Sujeta a datos extremos y trafico de eventos

Pruebas de Utilidad
Una buena interfaz puede mejorar mucho el valor de una aplicacin. Estas pruebas validan la aceptacin de la aplicacin por los usuarios Aseguran que la aplicacin satisface los requerimientos establecidos

25

05/04/2011

Atributos clave para la prueba de utilidad*

Accesibilidad
Facilidad con la que entran, navegan y salen los usuarios

Rapidez de respuesta Eficacia

Medida por el tiempo promedio

Que tan rapido permite la aplicacion al usuario lograr sus metas especificadas Que tan pequeos son los pasos requeridos para la funcionalidad elegida

Comprension
La facilidad con que se entiende y usa el producto mediante la documentacion y la ayuda

4. Documentacin de integracin y pruebas

26

05/04/2011

ANSI/IEEE 829-1983 Software Test Documentation (reaff. 1991)

1. Introduction 2. Test plan items under test, scope, approach, resources, schedule, personnel 3. Test design items to be tested, the approach, the plan in detail 6. Test item transmittal report items under test, physical location of results, person responsible for transmitting 7. Test log chronological record, physical location of test, tester name 8. Test incident report documentation of any event occurring during testing which requires further investigation 9. Test summary report summarizes the above

4. Test cases sets of inputs and events

5. Test procedures steps for setting up and executing the test cases

Cada punto tiene su template

Organizacin de la documentacin de integracin y pruebas

Plan de admon. Del proyecto de soft.

SPMP

Plan de admon. De la configuracion del soft -- delcaracion de procedimiento

-Hace referencia a todas las versiones de los doc.

SCMP

Apendice

Documentos de diseo de soft

SDD

Codigo fuente
Software Requirements Specification

Documento de pruebas de Soft.

STD

SRS

27

05/04/2011

Mantenimiento
Identify corporate practices Mantener la aplicacion til despues de la entrega Reparar los defectos

Plan project

Mejorar la aplicacion

Maintain Analyze requirements Design Implement Test units Integrate & test system

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Aspectos del mantenimiento de software

Administracion
Dificil definir el retorno sobre la inversion

Proceso
Se requiere una amplia coordinacion para manejar el flujo de solicitudes de mantenimiento

Tecnica
Debe cubrirse todo el impacto de los cambios Las pruebas son muy costosas en comparacion con la utilidad de cada cambio
Las pruebas concretas son ideales pero costosas Todavia se requieren las pruebas de regresion.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

28

05/04/2011

Activity

Estimate (person-days)

Activity

Estimate (persondays)

Estimacion del costo de atender una solicitud de mantenimiento

1 Comprender el problema e identificar las funciones que deben modificarse 2-5 6. Compilar e integrar en la base 2-3

2. Disear los cambios

1-4

7. Pruebas de funcionalidad

2-4

3. Realizar el analisis de impacto

1-4

8. Pruebas de regresion

2-4

4. Implementar los cambios en el cod fuente

1-4

9. Liberar la nueva base e informar resultados

5. Cambiar SRS, SDD, STP, Estado de configuracion

2-6

TOTAL

14 - 35

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

RoadMap to Establish Maintenance (After Pigoski)

1a. Disear para el mantenimiento 1b. Asegurar la sustentabilidad 1c. Planear la transicion al mantenimiento 1d. Planear la logistica posterior ala entrega 2. Determinar el alcance del mantenimiento Todo tipo?

Solo correctivo? Correctivo limitado?

3. Identificar quien da el mantenimiento

Interno? Contratado?

4. Desarrollar plan de mantenimiento Cambiar procedimiento de aprobacion de control

Apoyo tecnico etc.

5. Estimacion de costos

6. Realizar mantenimiento

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

29

05/04/2011

Tipos de mantenimiento

Correctivo
Reparacion
Identificar defecto y eliminarlo

Adaptativo
Cambios obtenidos al operar los cambios en sistema harware y DBMS

Perfectivo
Mejoras
Cambios que resultan de las solicitudes de los usuarios

Preventivo
Cambios hechos al software para facilitar el mantenimiento

Impacto de la solicitud de mantenimiento #162

Requirements Agregar cambio de apariencia

Architecture

Adecuar la habilidad para cambiar la apariencia global

Detailed design Interface specs Function code

Agregar metodos de interfaz para el paquete de distribucion Agregar clases y metodos segun el diseo detallado Modificar el codigo de control

Module (e.g., package) code

System code
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

30

05/04/2011

4. IEEE standard 840-1992

1. Problem identification 1.1 Input 1.2 Process 1.3 Control 1.4 Output 1.5 Quality factors 1.6 Metrics 2. Analysis 2.1 Input 2.2 Process
2.2.1 Feasibility analysis 2.2.2 Detailed analysis

IEEE 840-1994 Software Maintenance Table of Contents

2.3-2.6 Control, Output,

Quality factors, Metrics.

3. Design 3.1-3.6 Input, Process, Control,

Output, Quality factors, Metrics.

31

05/04/2011

1. Problem identification 4. Implementation 1.1 Input 1.2 Process 4.1 Input 1.3 Control 1.4 Output 4.2 Process 1.5 Quality factors 4.2.1 Coding and & testing 4.2.3 Risk analysis & review 1.6 Metrics IEEE 840-1994 4.2.4 Test-readiness review 2. Analysis Software 4.3-4.6 Control, Output, Maintenance 2.1 Input Quality factors, Metrics. Table of Contents 2.2 Process 5. System test 2.2.1 Feasibility analysis 5.1-5.6 Input, Process, Control, 2.2.2 Detailed analysis Output, Quality factors, Metrics. 6. 2.3-2.6 Control, Output, Acceptance test Quality factors, Metrics. 6.1-6.6 Input, Process, Control, 3. Design Output, Quality factors, Metrics. 7. 3.1-3.6 Input, Process, Control, Output, Quality factors, Metrics. Delivery 7.1-7.6 Input, Process, Control,
Output, Quality factors, Metrics.

Pasos de mantenimiento (IEEE)

1. Problem identification 2. Analysis 3. Design 4. Implementation 5. System test 6. Acceptance test 7. Delivery

32

05/04/2011

Pasos de mantenimiento (IEEE)

Pasos

Atributos
a. Entrada de artefactos del ciclo de vida oara este paso b. Proceso requerido para este paso c. Como se controla el proceso d. Salida de artefactos de ciclo de vida e. Factores de calidad del proceso involucrados f. Metricas para este paso

1. Problem identification 2. Analysis 3. Design

4. Implementation
5. System test 6. Acceptance test 7. Delivery

5. Administracin de mantenimiento

33

05/04/2011

Flujo de mantenimiento tipico

SM por escrito

Cliente

Trayectoria nominal Servicio a clientes

SM Propuestas

SM aprobadas
Ingeniero de mantenimiento
Fuente actual y documentacion

Comite de cambios

Documentacion modificada
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

SM Rechazadas

34