software testing (1)

148
Introducción Planificación de las Pruebas del Software Estrategias de Prueba para Software Convencional Pruebas de software (I) M.I. Capel ETS Ingenierías Informática y Telecommunicación Universidad de Granada Email: [email protected] Desarrollo de Software Ingeniería de Software (3er curso de Grado) 21 de mayo de 2014 M.I.Capel Tema 4 1/138

Upload: manuel-capel-tunon

Post on 13-Jun-2015

1.369 views

Category:

Technology


0 download

DESCRIPTION

A comprehensive review of all classic software testing techniques in Spanish

TRANSCRIPT

Page 1: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas de software (I)

M.I. Capel

ETS Ingenierías Informáticay Telecommunicación

Universidad de GranadaEmail: [email protected]

Desarrollo de SoftwareIngeniería de Software (3er curso de Grado) 21 de mayo de 2014

M.I.Capel Tema 4 1/138

Page 2: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Índice

1 IntroducciónConceptos generalesTipología de las pruebasCalidad y pruebas del software

2 Planificación de las Pruebas del SoftwareEstrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

3 Estrategias de Prueba para Software ConvencionalPruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

M.I.Capel Tema 4 2/138

Page 3: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Índice

1 IntroducciónConceptos generalesTipología de las pruebasCalidad y pruebas del software

2 Planificación de las Pruebas del SoftwareEstrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

3 Estrategias de Prueba para Software ConvencionalPruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

M.I.Capel Tema 4 2/138

Page 4: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Índice

1 IntroducciónConceptos generalesTipología de las pruebasCalidad y pruebas del software

2 Planificación de las Pruebas del SoftwareEstrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

3 Estrategias de Prueba para Software ConvencionalPruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

M.I.Capel Tema 4 2/138

Page 5: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Prueba de Software

ConceptoLa actividad denominada prueba de software (testing) consisterealmente en un conjunto de actividades sistemáticas que seplanean previamente a la programación y que son llevadas acabo por personal especializado y, para proyectos muygrandes, por un equipo de expertos en pruebas ("testers").

M.I.Capel Tema 4 3/138

Page 6: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Motivación

Las consecuencia de los fallos en el software cuestan a laeconomía norteamericana una cantidad estimada de 59.5 KMUSD por año (G. Tassey, The economic impacts of inadequateinfrastructure for software testing, 2002).

Se estima que se podrían suprimir 22.2 KM USD de laspérdidas anuales si se probara el software de maneraadecuada durante todas las fases del ciclo de desarrollo delmismo.

M.I.Capel Tema 4 4/138

Page 7: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Motivación

Las consecuencia de los fallos en el software cuestan a laeconomía norteamericana una cantidad estimada de 59.5 KMUSD por año (G. Tassey, The economic impacts of inadequateinfrastructure for software testing, 2002).

Se estima que se podrían suprimir 22.2 KM USD de laspérdidas anuales si se probara el software de maneraadecuada durante todas las fases del ciclo de desarrollo delmismo.

M.I.Capel Tema 4 4/138

Page 8: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Costes por software defectuoso (Basili–Boehm)

Corrección de defectos en la industria del software

Fase del desarrollo Coste / defecto (USD)Diseño y compilación 139Compilación o encuadernación 455Integración y pre–producción 977En el mercado 7,136

El coste promedio a la industria por corregir cada defecto de unsoftware que haya salido de la responsabilidad del equipo dedesarrollo y que sea detectado por el cliente que recibe elproducto es de 14,102 USD.

M.I.Capel Tema 4 5/138

Page 9: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Costes por software defectuoso (Basili–Boehm)

Corrección de defectos en la industria del software

Fase del desarrollo Coste / defecto (USD)Diseño y compilación 139Compilación o encuadernación 455Integración y pre–producción 977En el mercado 7,136

El coste promedio a la industria por corregir cada defecto de unsoftware que haya salido de la responsabilidad del equipo dedesarrollo y que sea detectado por el cliente que recibe elproducto es de 14,102 USD.

M.I.Capel Tema 4 5/138

Page 10: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Característica fundamental de las pruebas delsoftware

Las pruebas sólo pueden verificar el sistema y suoperación respecto de criterios predeterminados orequerimientos del software.La calidad del software ha de encontrarse dentro de éste,no es algo que se decida o se pueda incluir en la fase depruebas.

M.I.Capel Tema 4 6/138

Page 11: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Origen de los defectos del software

Porcentaje de defectos respecto de la fase del desarrollo

% Fase (introducidos en)85 Diseño y codificación< 2 Compilación y encuadernación< 2 Integración> 5 En el mercado

M.I.Capel Tema 4 7/138

Page 12: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Los objetivos fundamentales de la prueba de software

Identificar el origen y la magnitud de los riesgos en eldesarrollo que se puedan reducir mediante las pruebas.Realizar comprobaciones con sistematicidad para reducirlos riesgos identificadosSaber cuándo hemos de terminar las pruebas de unsoftwareGestionar las pruebas como otro proyecto dentro deldesarrollo completo de un sistema informático

M.I.Capel Tema 4 8/138

Page 13: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Concepto Clave 1

Todos los proyectos en Ingeniería suelen adolecer de defectosen el nuevo sistema o producto creado. Por consiguiente,tomar la decisión de no tratar de encontrar dichos defectos, esdecir, no realizar pruebas del software, no hará que losdefectos desaparezcan.

M.I.Capel Tema 4 9/138

Page 14: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Verificación y Validación

Verificación¿Estamos construyendo el producto correctamente?

Verificación se refiere al conjunto de tareas que aseguran queel software producido implementa correctamente una funcionespecifica.

Validación¿Estamos construyendo el producto correcto?

Validación se refiere a un conjunto diferente de tareas parapoder seguir("traceable”) al software hasta los requisitos.

M.I.Capel Tema 4 10/138

Page 15: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Verificación y Validación

Verificación¿Estamos construyendo el producto correctamente?

Verificación se refiere al conjunto de tareas que aseguran queel software producido implementa correctamente una funcionespecifica.

Validación¿Estamos construyendo el producto correcto?

Validación se refiere a un conjunto diferente de tareas parapoder seguir("traceable”) al software hasta los requisitos.

M.I.Capel Tema 4 10/138

Page 16: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Verificación y Validación

Verificación¿Estamos construyendo el producto correctamente?

Verificación se refiere al conjunto de tareas que aseguran queel software producido implementa correctamente una funcionespecifica.

Validación¿Estamos construyendo el producto correcto?

Validación se refiere a un conjunto diferente de tareas parapoder seguir("traceable”) al software hasta los requisitos.

M.I.Capel Tema 4 10/138

Page 17: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

¿Qué es y no es la actividad prueba de software?

Ejemplo: cómo probar un coche antes de comprarlo¿Qué exámenes o comprobaciones debemos hacer antes decomprarnos un coche nuevo?

Desde el punto de vista de usuarios–conductores delvehículo, no podemos repetir todos los diferentes tipos depruebas que ha realizado el fabricante antes de sacarlo almercado.Hemos de limitar nuestras pruebas a comprobacionesfactibles a través de Internet o en el concesionario deautomóviles.

M.I.Capel Tema 4 11/138

Page 18: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Ejemplo de las pruebas a realizar

Según el conductor del vehículo

Validar la financiabilidad de la compraQue nos gusteComprobar el grado de confortCapacidad, versatilidad, mantenibilidadPrestaciones:

Gasto combustible / 100 KmTipo de combustibleTiempo mínimo para conseguir velocidadEstabilidad en curvasEstabilidad en alta velocidad (> 180 KM/h)Tiempo promedio entre mantenimientos

M.I.Capel Tema 4 12/138

Page 19: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Tipos de pruebas en el ejemplo

Correspondencia con la terminología de pruebas

Tipo prueba Nombre técnicoExaminar el coche Pruebas estáticassin conducirloComprobar caracter. Pruebas funcionales y estructuralessin conducirloProbar a Prueba de rendimientoconducirlo

M.I.Capel Tema 4 13/138

Page 20: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Técnicas de Prueba de SoftwareCaracterísticas Comunes

Las pruebas comienzan a nivel de componentes y sedesarrollan "hacia arriba",es decir, hacia la integración delsistema informático global.Diferentes enfoques de Ingeniería de Software necesitandistintas técnicas de prueba, en diferentes momentos.La prueba (testing) y la depuración (debugging) desoftware son actividades completamente diferentes.Se han de incluir pruebas de bajo nivel para verificar quehan sido correctamente programados los diferentessegmentos de código y también pruebas de alto nivel quevalidan las funciones principales del sistema.

M.I.Capel Tema 4 14/138

Page 21: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Proceso procedural de la prueba del software

M.I.Capel Tema 4 15/138

Page 22: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Proceso procedural de la prueba del software II

Protocolo1 Pruebas unitarias: comprueban caminos específicos en la

estructura de control de un componente2 Prueba de integración: los componentes se ensamblan

para formar un paquete software completo3 Las pruebas de validación: el software ha de cumplir con

todos los requisitos funcionales, comportamiento,rendimiento . . .

4 Pruebas del sistema: verifica que todos los elementos(software+hardware) se combinan bien y que se consigueel rendimiento/funcionamiento global esperado

M.I.Capel Tema 4 16/138

Page 23: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Proceso procedural de la prueba del software III

¿Cuándo sabemos que hemos probado el software losuficiente?

Respuesta: probablemente nunca: cada vez que el usuariolo ejecuta, el programa está siendo probadoCriterios más rigurosos para determinar el fin de laspruebas:

Cleanroom Software Engineering: utilización de técnicasestadísticas de utilizaciónUtilización de modelos estadísticos y teoría de confiabilidaddel software para predecir la completitud de las pruebasRecogiendo muestras (y métricas) durante la realización depruebas del software

M.I.Capel Tema 4 17/138

Page 24: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Validación

ConceptoSe trata de la culminación de la prueba de integraciónDesaparecen las diferencias entre: software convencional,OO y aplicaciones WebLa validación tiene éxito cuando el software funciona de lamanera que espera el usuarioSoftware Requirements Specification, si se hadesarrollado: contendrá los criterios de validación

M.I.Capel Tema 4 18/138

Page 25: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Criterios de Validación

ConceptoSe consigue demostrar la conformidad con los requisitosdel software a través de un plan de prueba y de unprocedimientoLos casos de prueba, una vez realizados, pueden suponerla aceptación o la elaboración de una lista de deficiencias

M.I.Capel Tema 4 19/138

Page 26: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Antecedentes de Alpha, Beta Testing

Sirve para que el desarrollador conozca la forma en quelos usuarios utilizarán el software que han desarrollado ypuedan modificarlo de tal forma que sea aceptadoLos tests-alpha se realizan en un entorno controlado, enpresencia del desarrollador

M.I.Capel Tema 4 20/138

Page 27: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

"Beta Testing"

Los tests-beta son una aplicación viva del software en unentorno que no puede ser controlado por el desarrolladorEl cliente registra todos los problemas (reales oimaginados) y los envía al desarrollador periódicamenteLos tests alpha y beta se utilizan para validar un productopor muchos usuariosTest de Aceptación de Cliente: es una variante delbeta-test

M.I.Capel Tema 4 21/138

Page 28: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Sistemas y sus pruebas

AntecedentesEl software se incorpora junto con otros elementos en lossistemasSon muy importantes los pasos seguidos en el diseño yprueba del software para conseguir un alta probabilidad deintegración en sistemas grandesLa Prueba del Sistema se trata de realizar una serie detests que sirven para ejercitar de una manera completa unsistema

M.I.Capel Tema 4 22/138

Page 29: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Recuperación

ConceptoSe trata de una prueba del sistema que fuerza al software afallar de varias maneras Comprueba se realiza la recuperacióndel sistema de forma adecuada La automatización implica:

reinicializacióncheckpointingrecuperación de datos, etc.

M.I.Capel Tema 4 23/138

Page 30: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Seguridad

ConceptoEste tipo de prueba intenta verificar que los mecanismosde protección construidos con el sistema lo protegen deintrusionesEl tester juega el papel de un hackerUna buena prueba de seguridad ha de conseguirfinalmente penetrar el sistemaEl diseño del sistema ha de garantizar que conseguir unaintrusión es más costoso que el valor de la informaciónque se podría obtener

M.I.Capel Tema 4 24/138

Page 31: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Stress

ConceptoEste tipo de prueba se utiliza para confrontar a lossistemas con situaciones de funcionamiento anormales"How high can we crank this up before it’s all screwed up!!!"Ejecuta el sistema de un modo que demande recursos encantidad, frecuencia, o volúmen anormalesEl tester intenta romper el programaUna variación es el denominado test de sensibilidad

M.I.Capel Tema 4 25/138

Page 32: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Rendimiento

ConceptoEsta prueba se diseña para comprobar que el rendimientoen tiempo de ejecución del software dentro de un sistemaintegrado y en su contextoA menudo, se combinan con pruebas de stress ynormalmente necesitan instrumentación software yhardware para realizarlas:

Medición de ciclos del procesadorEvent Logs, p.e.: interrupciones/unidad tiempoMuestrear estados de dispositivos periódicamente

M.I.Capel Tema 4 26/138

Page 33: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Despliegue

ConceptoEjercita el software en cada plataforma y sistema operativoen el que vaya a funcionarPrueba todos los procedimientos de instalación delsoftware y el software de instalación especializadoExamina toda la documentación que vaya a ser utilizadapara introducir el software a los usuarios finales

M.I.Capel Tema 4 27/138

Page 34: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Aseguramiento de la Calidad y Pruebas de Software

Miller (1977):"The underlying motivation of program testing is to affirmsoftware quality with methods that can be economically andeffectively applied to both large–scale and small–scalesystems"

M.I.Capel Tema 4 28/138

Page 35: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Aseguramiento de la Calidad y Pruebas de Software II

V %V incluye un conjunto amplio de actividades paraasegurar la calidadLa prueba de software es la última posibilidad para evaluarla calidad de un software y, de manera más práctica, paradescubrir errores ocultosPero no introduce calidad al sistema: “If Quality isn’t therebefore you begin testing, it won’t be there when you’refinished testing"

M.I.Capel Tema 4 29/138

Page 36: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Principios para realizar buenas pruebas del software

1 Los riesgos de un sistema informático de negocio sepueden reducir si se buscan sistemáticamente los defectosdel software.

2 Las pruebas positivas y negativas aplicadas a dichosoftware contribuyen de manera importante a la reducciónde los riesgos.

3 Las pruebas estáticas y de ejecución contribuyen tambiéna su reducción.

4 Actualmente, la actividad de pruebas del software ha deser soportada por herramientas para automatización depruebas.

M.I.Capel Tema 4 30/138

Page 37: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Principios para realizar buenas pruebas II

5 La prioridad más importante a la hora de realizar laspruebas es la de afrontar primero los riesgos másimportantes del sistema.

6 Después, la segunda prioridad ha de ser la de comprobarlas actividades más frecuentes (regla 80/20) del negocio.

7 Análisis estadísticos (distribución de Weibull de patronesde aparición de defectos y otros errores) son muy efectivospara predecir cuándo se aconseja terminar la actividad depruebas un software.

8 Probar siempre el sistema de la misma manera que loutilizarán sus posibles usuarios.

M.I.Capel Tema 4 31/138

Page 38: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Principios para realizar buenas pruebas III

9 Considerar que los defectos del software son el resultadode un proceso y no convertirlo en una cuestión personalque vaya a implicar a desarrolladores concretos.

10 Buscar defectos en un software es una inversión, perotambién es otro coste del proyecto.

M.I.Capel Tema 4 32/138

Page 39: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

La prueba de software como una profesión

Esta actividad requiere de una mentalidad diferente de la queposee el desarrollador de software, así como de conceptos yhabilidades significativamente distintas de dicho personaltécnico.

M.I.Capel Tema 4 33/138

Page 40: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Conceptos generalesTipología de las pruebasCalidad y pruebas del software

Otros conceptos–clave

Para conseguir mayor eficacia, los planes y las actividadesde pruebas han de enfocarse en riesgos conocidos delnegocio para el que se desarrolla el sistema informático.Ningún proyecto de pruebas para un sistema de negociopuede llegar a comprobar todos los posibles defectos delsoftware debido a las limitaciones de presupuesto,habilidades del personal técnico y recursos en general.El desafío más importante para un tester con experienciaconsiste en identificar qué partes del sistema no se van aprobar produciendo el menor impacto posible en futuraspérdidas del negocio.

M.I.Capel Tema 4 34/138

Page 41: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Estrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

Relación entre las pruebas de software y el ciclo dedesarrollo

La prueba y el desarrollo de software son actividadesrelacionadas, ya que el éxito de ambos procesos es muyinterdependiente.Los procesos de prueba y desarrollo de softwaredependen de los procesos de soporte del otro, tales comogestión de requerimientos, búsqueda de defectos,cambios y control de versiones.Las pruebas deben comenzar al principio de un proyectode desarrollo porque cualquier producto del proyecto es unexcelente candidato para ser probado.

M.I.Capel Tema 4 35/138

Page 42: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Estrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

Estrategia de Pruebas de Software

M.I.Capel Tema 4 36/138

Page 43: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Estrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

Estrategia de Pruebas de Software II

ComentariosPara producir software: se disminuye el nivel deabstracción en cada vuelta (sentido contrario al de lasagujas del reloj).Para probar el software, seguimos la espiral hacia afueraen la dirección de las agujas del reloj ampliando el ámbitode la prueba en cada vuelta.

M.I.Capel Tema 4 37/138

Page 44: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Estrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

Estrategia de Pruebas de Software II

ComentariosPara producir software: se disminuye el nivel deabstracción en cada vuelta (sentido contrario al de lasagujas del reloj).Para probar el software, seguimos la espiral hacia afueraen la dirección de las agujas del reloj ampliando el ámbitode la prueba en cada vuelta.

M.I.Capel Tema 4 37/138

Page 45: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Estrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

Estrategia de Pruebas de Software III

M.I.Capel Tema 4 38/138

Page 46: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Estrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

El Plan de Pruebas

Documenta la planificación de las pruebas de un software"Master Test Plan":

1 Enumeración de los sistemas y/o aplicaciones que van aser probados

2 Riesgos, requisitos y objetivos de la prueba a realizar3 Ámbito y limitaciones de este Plan4 Fuentes de la "experticia.en el negocio, necesario para

planificar y ejecutar las pruebas5 Fuentes de la "experticia.en desarrollo de software,

necesario para planificar y ejecutar las pruebas6 Fuentes de los datos implicados en las pruebas de

preparación de los datos) el utilizar copias de los archivos ybases de datos de producción

M.I.Capel Tema 4 39/138

Page 47: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Estrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

Plan de Pruebas II

ComentariosLos items (1)–(8) del Plan de Pruebas anterior describenlas habilidades, proceso y marco tecnológico necesariopara que se puedan realizar las pruebasLa identificación de los elementos señalados por (1)–(8)son un pre–requisito para obtener una prueba con éxito dela aplicación o del sistema

M.I.Capel Tema 4 40/138

Page 48: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Estrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

El Plan de Pruebas III

"Master Test Plan"(2):7 Entornos de Pruebas y su Gestión8 Estrategia de Pruebas9 Para cada fase del Desarrollo del Sistema, REPETIR

Fase concreta del Desarrollo¿Cómo sabemos que podemos comenzar las pruebas?¿Cómo sabemos que podemos acabar las pruebas?Borrador de la lista de casos de prueba (ID, título,descripción)Borrador planificación escrita del caso de pruebaBorrador planificación escrita del caso de ejecuciónBorrador análisis resultados casos de ejecuciónPlanificación de informes

10 Elaborar borrador con la planificación completa de laspruebas

M.I.Capel Tema 4 41/138

Page 49: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Estrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

Plan de Pruebas IVComentarios

La lista de elementos enumerados en el item (9)constituyen las actividades de planificación de las pruebasespecíficas de la fase de desarrollo del softwareEl primer borrador del Plan de Pruebas contendrá unaplanificación de pruebas que sigue muy de cerca laplanificación del desarrollo del software encargadoSe irá adquiriendo más información y entendiendo mejor eltipo de pruebas que quedan por realizarEn la revisión de la planificación inicial de las pruebassalen a la luz nuevos aspectos del desarrollo detallado delsoftware, que no eran evidentes al comienzo de éste

M.I.Capel Tema 4 42/138

Page 50: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Estrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

Casos de Prueba

ConceptoLos casos de prueba son las condiciones generales que hayque probar para una aplicación o sistema–software, que seobtienen de los requerimientos de la aplicación de negocio ode la especificación del software producido

Uno de los resultados más importantes es el "Master TestPlan": lista de casos de prueba necesarios para verificarcada fase del desarrollo del software encargadoEl equipo de pruebas escribe los casos de prueba paracada subsistema o módulo de la aplicación, cuyaplanificación ha de coordinarse con el equipo de desarrollo

M.I.Capel Tema 4 43/138

Page 51: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Estrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

Casos de Prueba IIPropósito

El "Master Test Plan"documenta de forma global "qué"hayque probar de la aplicación–software y "por qué"Los casos de prueba se refieren más bien al çómo"hayque realizar las pruebas

ÁmbitoCada caso de prueba se centra en sólo 1 de lasactividades incluidas en el plan de pruebas completoSe deben identificar algunas de las actividades máselementales del negocio, que el software ha de soportarDefinir casos de prueba para cada una de las actividades

M.I.Capel Tema 4 44/138

Page 52: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Estrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

Completitud de los Casos de Prueba

Confirmar que hemos tenido en cuenta la realización detodas las actividades requeridas del negocio en los casosde prueba diseñadosComprobar que se han cubierto todos los requerimientosespecificados del software encargado para ese negocioContenidos de un Caso de Prueba:

1 ID único (indicado en el Plan de Pruebas)2 Título independiente (indicado en el Plan de Pruebas)3 Breve descripción (indicado en el Plan de Pruebas)4 Fase del Desarrollo en la que se aplica (indicado en el Plan

de Pruebas)

M.I.Capel Tema 4 45/138

Page 53: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Estrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

Completitud de los Casos de Prueba

Contenidos de un Caso de Prueba (2)5 Objetivos específicos de la prueba y sus medidas de logro6 Datos sugeridos para la prueba7 Herramientas de prueba sugeridas8 Procedimiento para comenzar la prueba9 Procedimiento para detener la prueba adecuadamente

10 Prueba de un procedimiento de reseteo para repetirla

M.I.Capel Tema 4 46/138

Page 54: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Estrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

Completitud de los Casos de PruebaContenidos de un Caso de Prueba (3)

11 REPETIR los pasos de ejecución de la prueba:Número de pasoAcción asociadaResultados esperados.TRACEAR e INFORMAR resultados actuales

12 TRACEAR e INFORMAR primera vez que se ejecuta(fecha/hora)

13 TRACEAR e INFORMAR número de intentos hastaejecutar la prueba con éxito

14 TRACEAR e INFORMAR lista de defectos del software15 TRACEAR e INFORMAR ¿Ejecutada con éxito ?(Sí|No)

M.I.Capel Tema 4 47/138

Page 55: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Estrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

Validación de los casos de Prueba

ObjetivosSi no se validan los casos de prueba, existe la posibilidadde que el equipo de pruebas esté informando de defectosdel software y pasos de ejcución de la prueba fallidos, enlugar de defectos en la elaboración del caso de pruebaSe trata de volver a revisar las acciones y los resultadosasociados a los pasos de ejecución de la pruebaSe comparan con los requerimientos del software,especificaciones (requerimientos y software) y se obtieneasesoramiento del experto del negocio

M.I.Capel Tema 4 48/138

Page 56: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Estrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

Validación de los casos de Prueba II

Acciones de los pasosLas acciones documentan las interacciones del usuariofinal con la aplicaciónSe trata de emular las actividades de negocio rutinariasque ejecutan los usuarios finales del software encargadoSi los resultados esperados casan con los resultadosreales, se dice que el paso de ejecución "pasó"En caso contrario, se dice que el paso ha fallado la pruebay se necesita un análisis y diagnóstico posterior

M.I.Capel Tema 4 49/138

Page 57: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Estrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

Validación de los casos de Prueba III

Diferencias entre resultados reales y esperadosCausa de resultados esperados incorrectos

1 Falta de comprensión adecuada del "probador", que setransmite al programador

2 Si probador, desarrollador y experto en el negocio están deacuerdo en los resultados esperados, el fallo se debe a undefecto en el proceso de desarrollo o en el código

M.I.Capel Tema 4 50/138

Page 58: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Estrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

Obtención del Plan de Pruebas

Idea general

Al comienzo del proceso de desarrollo hay suficienteinformación para elaborar un borrador del Plan de PruebasPero no hay nivel de detalle todavía para escribir cada unode los casos de pruebaTales detalles aparecen en orden inverso a como vanapareciendo las fases del proceso de desarrolloLa forma en que se planifican las pruebas parecefuncionar al contrario de lo esperado:

1 Pruebas de la post-implementación2 Pruebas de la implementación final3 Pruebas de la implementación inicial

M.I.Capel Tema 4 51/138

Page 59: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Estrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

Diagrama de Desarrollo en "V"(2)

M.I.Capel Tema 4 52/138

Page 60: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Estrategia de PruebasPlanificación de PruebasImplantación del Plan de Pruebas

Diagrama de Desarrollo en "V"(3)

Interpretación del diagrama

(1) Elaboración Plan de Pruebas y caso de prueba parapost-implementación(2) Escribir caso de prueba para la implementación final(3) Escribir caso de prueba para la construcción inicial delsoftware(4) Ejecutar el caso de prueba anterior (3)(5) Ejecutar el caso de prueba para la implementación finaldel software(6) Comienza la post–implementación y se ha de ejecutarsu caso de prueba, finalmente

M.I.Capel Tema 4 53/138

Page 61: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Pruebas Unitarias

AntecedentesConcentra el esfuerzo de verificación en la unidad máspequeña de diseño de software (módulo o componente)Trata de encontrar errores en la lógica de proceso internay las estructuras de datos de un componenteSe prueban caminos de control importantes para descubrirerrores dentro de los límites de un móduloLa complejidad de los tests y los errores que se puedenproducir están limitados

M.I.Capel Tema 4 54/138

Page 62: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Pruebas Unitarias II

M.I.Capel Tema 4 55/138

Page 63: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Pruebas Unitarias III

Prueba UnitariaLo primero es comprobar el flujo de datos a través de lainterfaz del componenteLas Estructuras de Datos han de ser ejercitadasDeterminar el impacto que producen en los datos globalesde la aplicaciónSeleccionar adecuadamente los caminos de ejecuciónDiseñar casos para descubrir errores de computación,comparaciones incorrectas o flujo de control impropioUn buen diseño de software ha de anticipar errores yestablecer su tratamiento cuando se produzcan

M.I.Capel Tema 4 56/138

Page 64: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Pruebas Unitarias IV

Prueba UnitariaEl procesamiento de grandes estructuras de datosfrecuentemente falla en los límites de la estructuraUn buen diseño de software ha de anticipar errores yestablecer su tratamiento cuando se produzcan

M.I.Capel Tema 4 57/138

Page 65: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Pruebas unitariasProcedimientos

Las pruebas unitarias se consideran normalmente comoadjuntas a la actividad de codificación del softwareEl diseño de tests unitarios puede ocurrir antes de quecomience la codificación, o despuésPara probar componentes hay que desarrollar:

Driver–softwareStubs

Un stub utiliza la interfaz del módulo subordinado (y hacepoco más) y devuelve el controlDrivers y stubs representan la sobrecarga del softwaredebida a su prueba

M.I.Capel Tema 4 58/138

Page 66: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Entorno para Pruebas Unitarias

M.I.Capel Tema 4 59/138

Page 67: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Pruebas de Integración

Cuestión FundamentalSi todos los componentes software, tras efectuar las pruebasunitarias, funcionan individualmente ¿Por qué dudar de quefuncionen también cuando se combinan todos en unaaplicación?

M.I.Capel Tema 4 60/138

Page 68: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Pruebas de Integración (II)

Antecedentes de problemaProblemas de interfaz entre componentesCuando se combinan sub–funciones pueden no producir lafunción principal deseadaProblemas de composición entre estructuras de datosglobalesLa imprecisión de los componentes se amplifica cuando secombinan varios de ellos

M.I.Capel Tema 4 61/138

Page 69: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Pruebas de Integración (III)

Concepto (Pressman, 2010)"Se trata de una técnica sistemática para construir laarquitectura del software mientras que, al mismo tiempo, serealizan pruebas para descubrir errores asociados con lainter-actuación de componentes (problema de interfaces)"

M.I.Capel Tema 4 62/138

Page 70: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Pruebas de Integración (IV)

ObjetivoUtilizando componentes comprobados con pruebas unitarias,construir una estructura de programa que ha sido promulgadacon la terminación de la actividad de diseño del sistema

M.I.Capel Tema 4 63/138

Page 71: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Pruebas de Integración (V)

Integración incremental vs. "Big–Bang"Todos los componentes combinados de una sola vez, y elprograma se prueba entero: El Caos!!!!

El caso de las interfacesCon pruebas incrementales se pueden verificar completamentey se puede llevar a cabo una actividad sistemática de pruebade software

M.I.Capel Tema 4 64/138

Page 72: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Integración Top-Down

ConceptoSe trata de una prueba de integración incrementalLos módulos se integran recorriendo la jerarquía decontrol (se supone en forma de árbol), hacia las hojasComenzando por el módulo de control principal (raíz delárbol)Seleccionar el orden de integración de los módulosdependerá de las características de la aplicaciónLos módulos subordinados se incorporan a la estructurarecorriéndola en profundidad o en anchura

M.I.Capel Tema 4 65/138

Page 73: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Integración Top-Down II

M.I.Capel Tema 4 66/138

Page 74: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Integración Top-Down III

Pasos del Proceso de Integración Top–Down1 El módulo de control principal se usa como el driver de la

prueba; los stubs se sustituyen por todos los subordinadosdirectamente conectados al principal

2 Los stubs subordinados se reemplazan, de una sola vez,por los componentes en su estado actual

3 Conforme se integra cada componente, se prueba4 Cada vez que se completa uno de los conjuntos de tests,

se reemplaza otro stub con el componente propuesto5 Se realizará una prueba de regresión para asegurar que

no se han introducido nuevos errores

M.I.Capel Tema 4 67/138

Page 75: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Integración Top-Down IV

Pros y ConsSe toman decisiones en un momento temprano delproceso de prueba del softwareSe puede implementar y "demostrarüna función completadel software si se utiliza recorrido en profundidadInicialmente, resulta una forma de probar el software pococomplicadaPueden aparecer problemas logísticosReemplazar los módulos bajo nivel en la jerarquía porstubs ocasiona que no fluyan datos significativos haciaarriba de la estructura de la aplicación

M.I.Capel Tema 4 68/138

Page 76: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Integración Top-Down IV

Resolución del problema de flujo de datos1 Retrasar pruebas hasta que los stubs sean reemplazados

por módulos reales2 Desarrollar stubs inteligentes, que realicen funciones

limitadas que simulan el módulo actual3 Integrar el software de abajo a arriba en la jerarquía

M.I.Capel Tema 4 69/138

Page 77: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Integración Bottom–Up

ConceptoComienza construyendo y probando módulos atómicos,componentes en los niveles más bajos de la estructura delprograma, eliminando la necesidad de crear stubs

M.I.Capel Tema 4 70/138

Page 78: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Integración Bottom–Up II

Pasos del Proceso de Integración1 Los componentes de bajo nivel se combinan en "builds"2 Se programa un driver para coordinar las entradas/salidas

al caso de prueba3 Se prueba el build4 Se eliminan drivers y se combinan clusters

M.I.Capel Tema 4 71/138

Page 79: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Integración Bottom–Up III

M.I.Capel Tema 4 72/138

Page 80: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Pruebas estáticas

ConceptoSe refieren a las pruebas que se realizan cuando laaplicación no se está ejecutandoReducción de defectos del software desde la mejora de ladocumentación, a partir de la cual se desarrollaAyudar a conseguir la operación correcta del software porparte de su usuario final cuando esté completamentedesarrollado y entregadoSe trata de una de las maneras más costo–efectivas deidentificar los probables defectos de lasaplicaciones–software

M.I.Capel Tema 4 73/138

Page 81: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Motivación

Observación:Unas pocas horas bien aprovechadas de pruebas estáticassobre la documentación de un proyecto de desarrollo puedenahorrar muchas horas de corrección y rediseño de software.

M.I.Capel Tema 4 74/138

Page 82: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Documentación de las pruebas estáticas

1 Software Development Manager/ Gestor de Desarrollo deSoftware

2 Software Developers/ Desarrolladores del Software3 Testers / Equipo de Pruebas4 Administrator / Administrador del Sistema5 Documentación de Usuario

M.I.Capel Tema 4 75/138

Page 83: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Documentos

(1)Del GestorRequisitos (Requirements) del SoftwarePlanificación del Proyecto de Desarrollo

(2)Del DesarrolladorCasos de Uso

Diseño (diagramas de clases, . . .), Diagramas de Flujo de Datos

Diseño de Bases de Datos y archivos

Interfaces

Especificaciones sobre conectividad (red)

Especificaciones sobre Seguridad

Especificaciones de Pantalla/Ventanas/Páginas

Código

M.I.Capel Tema 4 76/138

Page 84: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Documentos

(1)Del GestorRequisitos (Requirements) del SoftwarePlanificación del Proyecto de Desarrollo

(2)Del DesarrolladorCasos de Uso

Diseño (diagramas de clases, . . .), Diagramas de Flujo de Datos

Diseño de Bases de Datos y archivos

Interfaces

Especificaciones sobre conectividad (red)

Especificaciones sobre Seguridad

Especificaciones de Pantalla/Ventanas/Páginas

Código

M.I.Capel Tema 4 76/138

Page 85: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Documentos II

(1)Del "Tester"Planificación de las PruebasCasos de PruebaEspecificación del Entorno de PruebasPrueba de Fuentes de Datos y PreparaciónInstalación de Herramientas de Prueba de Software

M.I.Capel Tema 4 77/138

Page 86: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Pruebas Estáticas

Revisión de Contenidos (basadas en)Pruebas de Escritorio ("Desk Checking")InspeccionesPruebas Estructuradas de Recorrido ("Walk-throughs")

M.I.Capel Tema 4 78/138

Page 87: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Pruebas funcionales

ConceptoValidar el comportamiento del software con respecto a loque tiene que hacer, tal como aparece documentadoEjercitar más completamente posible el software quesoporta la actividades diarias de un negocio, mediante laejecución de casos de prueba:

Se obtienen a partir de los casos de uso previosInicialmente para componentes individuales: menús,ítemsde datos, páginas web, bases de datos, etc.Finalmente, se prueban los componentes software deforma conjunta

M.I.Capel Tema 4 79/138

Page 88: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Pruebas funcionales II

OperatoriaSe ejecutan los casos de prueba para los diferentescaminos de negocio (business paths)La ejecución de los casos de prueba se realiza en ordeninverso al del código producido para el sistema

M.I.Capel Tema 4 80/138

Page 89: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Objetivos

Prueba de navegación del usuarioPruebas de ventanas de transaccionesPrueba del flujo de las transaccionesPrueba de ventanas de reportePrueba de flujo de ventanas de reportePruebas de eliminación/ actualización/ recuperación/creación de registros en una base de datos

M.I.Capel Tema 4 81/138

Page 90: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Prueba de Regresión

ConceptoEl software cambia, durante una prueba de integración,cada vez que se añade un módulo. Tales cambios puedenproducir problemas en el comportamiento de funcionesque antes funcionaban perfectamente.Se trata de la re–ejecución de algunos subconjuntos depruebas que ya han sido realizadas para asegurar que loscambios no han propagado efectos colaterales indeseados

M.I.Capel Tema 4 82/138

Page 91: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Prueba de Regresión II

Contenidos de la prueba:1 Un ejemplar representativo de los posibles tests que

ejerciten todas las funciones del software a probar2 Test que se centran en la prueba de componentes

software que han sido cambiados3 Tests adicionales que se enfocan a la prueba de funciones

de software que podrían verse afectadas por los cambios

M.I.Capel Tema 4 83/138

Page 92: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Pruebas de Caja Blanca

Se trata de verificar la corrección de las sentencias,caminos en el código, condiciones, bucles y flujo de datosdel software producidoPara realizar este tipo de pruebas se necesita teneracceso al fuente, así como a: requisitos, casos de uso,datos y ejecutablesLas suele realizar propio programador depurando elcódigo que ha producidoCuanto mayor sea la cobertura lógica (algoritmos,protocolos, procedimientos, etc.), menos defectos sedescubrirán posteriormente con otros tipos de pruebas

M.I.Capel Tema 4 84/138

Page 93: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Pruebas de Caja Blanca II

Cobertura de SentenciasSe trata de verificar qué ocurre si cada sentencia delcódigo se ejecuta al menos una vezTambién qué procentaje en promedio de las líneas decódigo fuente de un programa consiguen ejecutarseLines base: cuanto mayor sea la cobertura de la pruebadel código fuente, el número de defectos del software queencontremos después será menor

M.I.Capel Tema 4 85/138

Page 94: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Pruebas de Caja Blanca III

Cobertura de RamasSe trata de determinar qué porcentaje de las ramas(verdadero/falso) lógicas de un programa se han ejecutadoLa co–existencia de ramas que nunca se han ejecutadocon sentencias no comprobadas suele ser la causa demuchos errores en la lógica de los programasEl escoger probar las ramas simples en un programaantes de pasar a hacerlo con ramas de condicionescompuestas hace las pruebas de este tipo más cortasPara probar todas las posibles combinaciones de valoresde verdad en ramas de condiciones compuestas seutilizarán tablas de verdad

M.I.Capel Tema 4 86/138

Page 95: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Pruebas de Caja Blanca IV

DefiniciónUna secuencia de sentencias de un programa desde la primerasentencia ejecutable a través de una serie de otras sentenciashasta llegar a una sentencia return/stop/end/exit

Cobertura de CaminosDeterminar qué porcentaje de los caminos en el códigofuente de un programa han sido ejecutados

M.I.Capel Tema 4 87/138

Page 96: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Pruebas de Caja Blanca V

Cobertura de BuclesConsiste en determinar el porcentaje de sentenciasloop–while–repeat–do de un programa que hayan sidoejecutadas completamenteEl objetivo es forzar a ejecutar el bucle en el programa: 0,1, n/2, n y n+1 vecesLos valores extremos de los límites (0,n+1) compruebancondiciones inesperadas o inapropiadas del bucleBucles no ejecutados completamente y los que seejecutan sólo dentro de sus límites esperados son unabomba de tiempo en los programas

M.I.Capel Tema 4 88/138

Page 97: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Pruebas de Caja Negra

Verificar la corrección del comportamiento del softwareque soporta directamente la actividad diaria en un negocioSe le denomina también: cobertura del comportamientoTener acceso a los requisitos, casos de uso, datos ysólo al código ejecutable y sus datosPor desarrolladores o "testers"siempre que no hayanproducido el código que se va a verificarSe hacen pruebas positivas (comportamiento esperadodel software) y negativas (comportamiento inesperado)Las pruebas negativas suelen sacar a la luz más defectosdel software

M.I.Capel Tema 4 89/138

Page 98: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Identificación de Datos

Figura: Descubrimiento de defectos del software desde los datos

M.I.Capel Tema 4 90/138

Page 99: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Pruebas de Caja Negra I

Clases de EquivalenciaIdentificar grupos de datos de entrada que tienden a hacerque la aplicación se ejecute de la misma maneraReducen sustancialmente el número de datos de pruebanecesarios para verificar un comportamiento específicoSe aplica, por ejemplo, agrupando por campos de datoscon valores que se pueden clasificar de otra forma(ID/clase de personal)Se deben seleccionar clases de equivalencia que incluyanseparadamente valores del comienzo, del final y del mediode un campo de valores

M.I.Capel Tema 4 91/138

Page 100: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Pruebas de Caja Negra II

Cobertura de los Valores EsperadosEncontrar reglas de negocio en los requisitos de laaplicación que definan los resultados esperadosSe trata de obtener valores–resultados de prueba a partirde sus valores de entrada asociadosElaborar una tabla de combinaciones válidas de entradas aclases de equivalencia con valores frontera para las reglasde negocio que se espera proporcionen los resultados

M.I.Capel Tema 4 92/138

Page 101: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Pruebas de Caja Negra III

Ejemplo Cobertura de Valores Esperados (1)

Input Input OutputEdad Copago Habitación0-6 50 EUR 50 EUR7–17 75 EUR 10018–35 100 15036–49 125 30050-74 200 35075-99 250 400

Cuadro: Reglas de negocio

M.I.Capel Tema 4 93/138

Page 102: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Pruebas de Caja Negra

Ejemplo Cobertura de Valores Esperados (2)

Input Input OutputEdad Copago Habitación0-6 50 EUR 50 EUR-1 50 EUR error-edad no está en el rango7–17 75 EUR 1005 75 EUR error–el copago no es válido6 75 EUR 1007 75 EUR 100

Cuadro: Tabla de combinaciones

M.I.Capel Tema 4 94/138

Page 103: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Pruebas Estructurales

ConceptoSe trata de validar el comportamiento del software queutilizan (dan soporte) las aplicaciones de usuarioReduce el riesgo de fallo del denominado software deplataformaSon pruebas de tipo no–funcionalLas pruebas de caja blanca no se pueden aplicarLa mayoría de las pruebas de caja negra tampoco

M.I.Capel Tema 4 95/138

Page 104: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Pruebas Estructurales I

Pruebas de InterfazProbar el paso de datos entre la aplicación y los distintoscomponentes de la plataforma se realiza correctamenteHan de ser probados: archivos de datos, APIs, peticionesa bases de datos, mensajes por la redSe puede realizar en 4 pasos:

1 Producir datos pero mantener la trasferencia inhibida2 Eliminar los inhibidores de transferencia de datos3 Escribir tests para que la aplicación pida datos desde otros

componentes de la plataforma4 Permitir que los componentes de la plataforma–software

alimenten con datos reales de entrada a la aplicación

M.I.Capel Tema 4 96/138

Page 105: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Pruebas Estructurales II

Pruebas de SeguridadUtilizar clases de equivalencia para probar elcomportamiento relativo a la seguridadPuede implicar la encriptación de las palabras de paso, locual complica la prueba basada en clases de equivalenciaEl equipo de pruebas ha de verificar la degradación delrendimiento de la aplicación por motivo de esta pruebaDesde el punto de vista de las pruebas de regresión,conviene realizar pruebas de seguridad lo antes posible enla aplicación

M.I.Capel Tema 4 97/138

Page 106: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Pruebas Estructurales III

Pruebas de InstalaciónSe trata de comprobar si la nueva aplicación se ha situadocorrectamente en entorno de producciónEs necesario probar el proceso de instalación paraasegurase que los clientes podrán hacer funcionar laaplicaciónNormalmente se ha de contar con una plataformasoftware+hardware análoga al entorno de utilización parahacer la prueba de la aplicaciónHay que proporcionar al cliente información acerca de si elproceso de instalación se desarrolló correctamente

M.I.Capel Tema 4 98/138

Page 107: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Pruebas Estructurales IV

Pruebas de HumoConfigurar una aplicación instalada consiste enseleccionar entre una lista de opciones cómo ha de operarel software para cumplir con las reglas específicasFijar parámetros de arranque ("start up"): ubicaciónarchivos, número de sesiones, ID/password, zonas...Reglas de procesamiento: clases de seguridad,planificación de arranque y backups del sistema,...

M.I.Capel Tema 4 99/138

Page 108: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Pruebas Estructurales V

Pruebas de Humo IIEste tipo de prueba se utiliza para verificar de forma noexhaustiva que una aplicación software instalada puedeser posteriormente bien configuradaLa dificultad consiste en identificar las combinaciones deconfiguración más probables de la aplicación paraprobarlasCada nueva configuración se prueba diferencialmente conrespecto a una que anteriormente funcionó

M.I.Capel Tema 4 100/138

Page 109: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Pruebas Estructurales VIPruebas de Administración

Se trata de una ampliación de las pruebas funcionales delas actividades de un negocioPrueba de las actividades de soporte a un negocioLos componentes administrativos de una aplicaciónpodrían haberse desarrollado antes que los funcionales,en ese caso los resultados de la prueba serán el punto decomienzo de la prueba de estos ultimosSi ocurre los contrario, los archivos de configuraciónmanual utilizados para probar la funcionalidad de laaplicación se pueden utilizar como los resultadosesperados de las pruebas de componentes administrativos

M.I.Capel Tema 4 101/138

Page 110: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Pruebas Estructurales VIIPruebas de Backup y Recuperación

Los archivos de backup se utilizan para restaurar elsoftware a un estado próximo al que tenía antes de fallarSi no se prevén situaciones de fallo en las aplicaciones denegocio durante su desarrollo, entonces probablementeéstas no se recuperarán en la eventualidad de un falloRealización de backups de archivos críticos del negocio:master files, transacciones y antes y después deinstalación de imágenes del sistemaHay que realizar varios backups, interrumpir la aplicaciónanormalmente y restaurar la aplicación utilizando sólo losbackups guardados

M.I.Capel Tema 4 102/138

Page 111: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Pruebas de Rendimiento

ConceptoSe trata de validar la velocidad de ejecución del softwarerespecto de la necesidad de velocidad del negocio, talcomo se expresó en el documento de requerimientosLa denominada velocidad del software se consigue comouna buena combinación del tiempo de respuesta y la cargade trabajo cuando se producen cargas–pico debidas a losusuarios activosPruebas de rendimiento: una serie de tests que introducende forma incremental más carga de trabajo por unacombinación de transacciones de un negocio

M.I.Capel Tema 4 103/138

Page 112: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Metas Importantes de las Pruebas de Rendimiento

Desafíos a Afrontar1 Identificar correctamente a cuáles transacciones y

actividades del negocio se les necesita medir elrendimiento

2 Por cada grupo de transacciones relevante del negocio,determinar la utilización–pico de recursoscomputacionales y cuándo ocurre (ventanas de tiempo)

3 Determinar cuántos picos de carga de trabajo hay quecomprobar para conseguir una buena prueba derendimiento

M.I.Capel Tema 4 104/138

Page 113: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Planificación de las Pruebas

Pasos para pruebas de carga de trabajo

Llevar a cabo una intensificación de la carga de trabajo delsoftware hasta llegar a una situación de carga–picoEjecutar medidas de rendimiento en el entorno de dichopico de carga de trabajoLlevar a cabo una disminución de la carga de trabajo delsoftware desde la última situación de carga–pico

M.I.Capel Tema 4 105/138

Page 114: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Planificación de las PruebasDocumentación de Requisitos de Carga de Trabajo

El análisis de carga de trabajo de una aplicación softwaredebe identificar los grupos de transacciones y susrequisitos de rendimiento

Grupo Transacciones Tiempo respuestaNavegar menús 3s. (máx)Des/Conexión 3s. (máx)Información productos 4s. (máx)Operación compra 7s. (máx)Búsqueda catálogo 10s. (máx)Pago con Tarjeta 30s. (máx)Envío 24h. (máx)

Cuadro: Ejemplo de aplicación de compras por Internet

M.I.Capel Tema 4 106/138

Page 115: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Planificación de las PruebasDocumentación de Requisitos de Carga de Trabajo

El análisis de carga de trabajo de una aplicación softwaredebe identificar los grupos de transacciones y susrequisitos de rendimiento

Grupo Transacciones Tiempo respuestaNavegar menús 3s. (máx)Des/Conexión 3s. (máx)Información productos 4s. (máx)Operación compra 7s. (máx)Búsqueda catálogo 10s. (máx)Pago con Tarjeta 30s. (máx)Envío 24h. (máx)

Cuadro: Ejemplo de aplicación de compras por Internet

M.I.Capel Tema 4 106/138

Page 116: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Planificación de las Pruebas IIDocumentación de Picos de Carga de Trabajo

Para cada pico de carga , estamos más interesados endeterminar el número de activos, cuando se produce, queel de usuarios concurrentesCada transacción de usuario (dentro de la misma ventanatemporal) entra en competencia con las de otros por losmismos recursosEl objetivo de la instrumentación de este tipo de pruebasconsiste en medir cómo de bien compiten lastransacciones respecto de diferentes cargas de trabajoHay que añadir la previsión de uso máximo de cada grupode transacciones a la planificación de la carga de trabajo

M.I.Capel Tema 4 107/138

Page 117: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Planificación de las Pruebas III

Documentación de Picos de Carga de Trabajo (2)Grupo Transacciones Tiempo respuesta Activos Fecha de la actividadNavegar menús 3s. (máx) 2000 L-V: 12-13hDes/Conexión 3s. (máx) 2000 L-V: 12-13hInformación productos 4s. (máx) 2000 L-V: 12-13hOperación compra 7s. (máx) 500 S: 9-11hBúsqueda catálogo 10s. (máx) 2000 L-V: 12-13hPago con Tarjeta 30s. (máx) 500 S: 9-11h

Cuadro: Planificación de la carga de trabajo para obtener rendimiento

M.I.Capel Tema 4 108/138

Page 118: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Planificación de las Pruebas IV

Documentación de Picos de Carga de Trabajo (3)

Para obtener una estimación del rendimiento de laaplicación en todo momento, hay que averiguar cuántospicos de carga de trabajo distintos hay que comprobar

Grupo Transacciones Tiempo respuesta Activos Fecha de la actividadNavegar menús 3s. (máx) 500 S: 9-11hDes/Conexión 3s. (máx) 500 S: 9-11hInformación productos 4s. (máx) 500 S: 9-11hOperación compra 7s. (máx) 500 S: 9-11hBúsqueda catálogo 10s. (máx) 500 S: 9-11hPago con Tarjeta 30s. (máx) 500 S: 9-11h

Cuadro: Planificación de la carga (sábados) para obtener rendimiento

M.I.Capel Tema 4 109/138

Page 119: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Planificación de las Pruebas IV

Documentación de Picos de Carga de Trabajo (3)

Para obtener una estimación del rendimiento de laaplicación en todo momento, hay que averiguar cuántospicos de carga de trabajo distintos hay que comprobar

Grupo Transacciones Tiempo respuesta Activos Fecha de la actividadNavegar menús 3s. (máx) 500 S: 9-11hDes/Conexión 3s. (máx) 500 S: 9-11hInformación productos 4s. (máx) 500 S: 9-11hOperación compra 7s. (máx) 500 S: 9-11hBúsqueda catálogo 10s. (máx) 500 S: 9-11hPago con Tarjeta 30s. (máx) 500 S: 9-11h

Cuadro: Planificación de la carga (sábados) para obtener rendimiento

M.I.Capel Tema 4 109/138

Page 120: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Técnicas de Ejecución de las Pruebas

Idea general

Para poder predecir el rendimiento de la aplicación hayque crearse los picos de carga de trabajo en un entornode pruebasEsto se realiza en 3 pasos:

1 Intensificación de la carga de trabajo hasta alcanzar el pico2 Medida de rendimiento en el pico3 Disminución de la carga de trabajo desde el pico

M.I.Capel Tema 4 110/138

Page 121: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Prueba de Rendimiento de un Componente

Idea general

Tener una estimación temprana acerca de si la inclusiónde un nuevo componente software nos puede llevar cercadel valor máximo del tiempo de respuesta previsto en laplanificación de carga de trabajo

M.I.Capel Tema 4 111/138

Page 122: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Prueba de Rendimiento de un Componente II

Rendimiento de "viaje completo"(roundtrip)Se trata de la medida del tiempo de respuesta de laaplicación desde que el usuario envía su petición hastaque los resultados se han mostrado completamenteEsta medida de rendimiento incluye:

Procesamiento implicado y realizado en la parte del usuarioComunicación necesaria a través de la redProcesamiento secundario en otros computadores desoporte para la transacción

M.I.Capel Tema 4 112/138

Page 123: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Prueba de Rendimiento de un Componente III

Ejemplo de Medida de Rendimiento de "Viaje Completo"

0.5s venta de compra en el cliente0.2s transmisión a la red2.4s registro en servidor1.3s generar orden al almacén (servidor)0.7s generar confiración compra (servidor)0.1s tramsión confirmación (red)0.6s mostrar registro confirmación (cliente)

Total tiempo de respuesta = 5,8s < tiempo máximo en pico(previsto en la planificación de carga de trabajo)

M.I.Capel Tema 4 113/138

Page 124: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"

Figura: Rendimiento de viaje completo

M.I.Capel Tema 4 114/138

Page 125: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"Comentarios a la figura

En un entorno de pruebas, se lanza la ejecución de laaplicación, inicialmente sin usuarios activosSe lanzan cada vez más copias de la misma transacciónCada una de ellas representa a un usuario activo, yobservar la forma de la gráfica bajo unas condiciones decarga de trabajo crecienteEl tiempo (eje de ordenadas) representa el peor tiempo derespuesta de todas las transacciones actualmente activasEl tiempo de respuesta promedio entre todas lastransacciones no se puede utilizar para determinar si secumple o no el requisito de rendimiento

M.I.Capel Tema 4 115/138

Page 126: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"

Comentarios a la figura (2)

El codo o rodilla ("knee") de la gráfica se debe a algún tipode embotellamiento en el que se interfieren lastransacciones, que se produce en algún momento de suscaminos de procesamientoLa gráfica no informa de las causas del embotellamiento,sólo de las circunstancias en las que se produceLa única forma de descubrir dónde se produce el codo esejecutar las pruebas incrementando la carga de trabajohasta que aparezca en la gráfica

M.I.Capel Tema 4 116/138

Page 127: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Prueba de Rendimiento de un Componente IV

Previo a la Prueba de Carga de Trabajo1 En un sistema vacío, para todas las transacciones, el

rendimiento de viaje completo inicial ha de ser menor queel tiempo máximo en pico previsto en los requerimientosdel software

2 El rendimiento de viaje completo de las transaccionesempeorará conforme éstas compitan por recursos en unsistema más ocupado

3 Todas las transacciones (color verde) que cumplan (1)están preparadas para la prueba de carga de trabajo

M.I.Capel Tema 4 117/138

Page 128: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Rendimiento de viaje completo de las transacciones

Grupo Transacciones Tiempo respuesta Activos Fecha RendimientoNavegar menús 3s. (máx) 500 S:9-11h 4.5sDes/Conexión 3s. (máx) 500 S:9-11h 2.0sInformación productos 4s. (máx) 500 S:9-11h 15.3sOperación compra 7s. (máx) 500 S: 9-11h 3.0sBúsqueda catálogo 10s. (máx) 500 S: 9-11h 1.6sPago con Tarjeta 30s. (máx) 500 S: 9-11h 103s

Cuadro: Planificación de la carga (sábados) para obtener rendimiento

M.I.Capel Tema 4 118/138

Page 129: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"

Figura: Rendimiento - Transacciones de búsqueda en catálogo

M.I.Capel Tema 4 119/138

Page 130: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"

Figura: Rendimiento - Transacciones de búsqueda en catálogo

M.I.Capel Tema 4 120/138

Page 131: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"Gráficas del t.respuesta para la búsqueda en catálogo

"Box Aïncluye el tiempo de respuesta de peor caso para elpico de carga de trabajo que se observa con 250transacciones activas (5.6 s)"Box B.extiende el test hasta las 350 transacciones activas,obteniéndose una gráfica lineal y valores debajo delmáximo requerido (6.8s en el pico)"Box C.extiende el test hasta las 450 transacciones , lo cualhace aparecer el codo de la gráfica que eleva el tiempo derespuesta en el pico de carga a 26.4 sAl llegar a las 350 transacciones activas al mismo tiempo,la ejecución de la aplicación comenzará a ser muy lenta

M.I.Capel Tema 4 121/138

Page 132: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"

Figura: Pico de Trabajo - Transacciones de conexión (logon)

M.I.Capel Tema 4 122/138

Page 133: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"

Figura: Pico de Trabajo - Transacciones de compra artículo

M.I.Capel Tema 4 123/138

Page 134: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"

Figura: Pico de Trabajo - Transacciones de búsqueda en catálogo

M.I.Capel Tema 4 124/138

Page 135: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"

Gráficas del t.respuesta para cada transacción individualPor simplicidad, se estudian sólo 3 grupos detransacciones (conexión, búsqueda en catálogo, compra)Se elije la planificación de carga de trabajo de las comprasde los sábados porque necesitan simular menostransacciones (500) hasta el pico de carga que la de laplanificación de los días laborables (2000 transacciones)Se encontró que los tiempos de respuesta de las 3transacciones consideradas individualmente estánbastante por debajo de máximo requerido para el pico decarga de los sábados de cada transacción

M.I.Capel Tema 4 125/138

Page 136: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"

Figura: Pico de Trabajo - Transacciones de conexión+compra

M.I.Capel Tema 4 126/138

Page 137: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"

Gráficas del t.respuesta para mezclas de transaccionesLas mezclas de las transacciones han de hacersegradualmente (conexión+ compra, conexión+ compra+búsqueda) para no introducir indeterminación respecto dela que causa la pérdida de rendimientoEl tiempo de respuesta de la transacción de conexión seconvierte en un elemento marginal para el cálculo delrendimiento si se superan las 400 transacciones activasPor consiguiente, existe un conflicto en el acceso arecursos entre la transacción de compra y la de búsqueda

M.I.Capel Tema 4 127/138

Page 138: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"

Figura: Transacciones de conexión+compra+búsqueda

M.I.Capel Tema 4 128/138

Page 139: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"

Gráficas del t.respuesta para mezclas de transacciones (2)Para la búsqueda en catálogo por encima de las 150transacciones, la gráfica que contempla la mezcla de las 3transacciones (conexión+compra+búsqueda) muestra untiempo de respuesta inaceptablemente altoSe deben detener las pruebas de rendimiento ( situacióndenominada "showstopper") y devolver el software aequipo de desarrollo

M.I.Capel Tema 4 129/138

Page 140: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"

Gráficas para cada transacción individual corregida

Se recibió el software de la aplicación corregido y con laspruebas funcionales de regresión realizadas:

El módulo de conexión de los usuarios interfería con elmódulo de compra por motivo de pérdida de memoriaasignada al primero, que le retiraba el segundo módulo apartir de 400 transacciones activasDegradación del rendimiento de una librería dinámicacompartida entre el módulo de compra y el de búsqueda encatálogo cuando se cargan en memoria rutinas deutilidades para su ejecución

M.I.Capel Tema 4 130/138

Page 141: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"

Figura: Transacciones de conexión después de correcciones

M.I.Capel Tema 4 131/138

Page 142: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"

Figura: Transacciones de compra después de correcciones

M.I.Capel Tema 4 132/138

Page 143: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"

Figura: Transacciones de búsqueda en catálogo después decorrecciones

M.I.Capel Tema 4 133/138

Page 144: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"

Gráficas del para cada transacción individual corregida

El rendimiento del código del módulo de conexión no se havisto afectado por los cambiosLos módulos de compra y búsqueda en catálogo muestranun ligero aumento de su rendimiento para cadatransacción individualAunque los cambios del código se centraron en corregir ladegradación del rendimiento debido a una malaimplementación de librerías compartidas, también mejoróel comportamiento individual de algunos módulos

M.I.Capel Tema 4 134/138

Page 145: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"

Figura: Transacciones de conexión+búsqueda después decorrecciones

M.I.Capel Tema 4 135/138

Page 146: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"

Figura: Transacciones de conexión+búsqueda+compra después decorrecciones

M.I.Capel Tema 4 136/138

Page 147: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Caso de Estudio: "Compras del Sábado"Gráficas del t.respuesta para mezclas corregidas

Se resolvió el problema de la interferencia con la compra(cuando existen > 400 transacciones-compra activas)Ambos grupos de transacciones (conexión y compra)producen un peor tiempo de respuesta muy por debajo delmáximo tiempo en pico (en los requerimientos)Añadir búsqueda en catálogo a las anteriores no afectaahora al rendimiento de ninguna trasacción cuandocompiten por recursosLos tests de rendimiento han de formar parte de laspruebas de regresión para demostrar que la inclusión denueva funcionalidad no degrada el rendimiento global

M.I.Capel Tema 4 137/138

Page 148: Software Testing (1)

IntroducciónPlanificación de las Pruebas del Software

Estrategias de Prueba para Software Convencional

Pruebas unitarias y de integraciónPruebas estáticasPruebas funcionalesPruebas EstructuralesPruebas de Rendimiento

Para ampliar

Black (2007).Pragmatic Software Testing.Wiley.

Everett and Raymond (2007).Software Testing.Wiley.

Lewis (2004).Software Testing and Continuous Quality Improvement.Auerbach.

Perry (2005).Effective Methods for Software Testing.Wiley.

Pressman, R. (2010).Software engineering: a practitioners approach.McGraw-Hill.

Spiller (2007).Softwre Testing Process: Test Management.Rocky Nook.

M.I.Capel Tema 4 138/138