Pruebas de software

¿Por qué probar? Las fallas de software ocasionan graves pérdidas económicas; éstos son 100 a 1000 veces más costosos de encontrar y reparar después de la construcción.

Las fallas de software ocasionan graves pérdidas económicas; éstos son 100 a 1000 veces más costosos de encontrar y reparar después de la construcción.

¿Por qué probar? Evitar plazos y presupuestos incumplidos, insatisfacción del usuario, escasa productividad y mala calidad en el software producido y finalmente la p érdida de clientes. Automatizar el proceso de pruebas consigue reducciones de hasta un 75% en el costo de la fase de mantenimiento.

Evitar plazos y presupuestos incumplidos, insatisfacción del usuario, escasa productividad y mala calidad en el software producido y finalmente la p érdida de clientes.

Automatizar el proceso de pruebas consigue reducciones de hasta un 75% en el costo de la fase de mantenimiento.

¿Quiénes deben de probar o que se debe probar? Cada caso de prueba debe definir el resultado de salida esperado. El programador debe evitar probar sus propios programas, ya que desea (consciente o inconscientemente) demostrar que funcionan sin problemas. Se debe inspeccionar a conciencia el resultado de cada prueba, así, poder descubrir posibles síntomas de defectos.

Cada caso de prueba debe definir el resultado de salida esperado.

El programador debe evitar probar sus propios programas, ya que desea (consciente o inconscientemente) demostrar que funcionan sin problemas.

Se debe inspeccionar a conciencia el resultado de cada prueba, así, poder descubrir posibles síntomas de defectos.

¿Quiénes deben de probar o que se debe probar? Al generar casos de prueba, se deben incluir tanto datos de entrada válidos y esperados como no válidos e inesperados. Las pruebas deben centrarse en dos objetivos: Probar si el software no hace lo que debe hacer Probar si el software hace lo que no debe hacer, es decir, si provoca efectos secundarios adversos.

Al generar casos de prueba, se deben incluir tanto datos de entrada válidos y esperados como no válidos e inesperados.

Las pruebas deben centrarse en dos objetivos:

Probar si el software no hace lo que debe hacer

Probar si el software hace lo que no debe hacer, es decir, si provoca efectos secundarios adversos.

¿Quiénes deben de probar o que se debe probar? Se deben evitar los casos no documentados ni diseñados con cuidado. No deben hacerse planes de prueba suponiendo que, prácticamente, no hay defectos en los programas y, por lo tanto, dedicando pocos recursos a las pruebas.

Se deben evitar los casos no documentados ni diseñados con cuidado.

No deben hacerse planes de prueba suponiendo que, prácticamente, no hay defectos en los programas y, por lo tanto, dedicando pocos recursos a las pruebas.

¿Por qué no probar todo? Prácticamente imposible. Es imposible evaluar todas las posibilidades. Recursos (costos, tiempo, personal) ¿Cuántos ciclos de pruebas son suficientes?

Prácticamente imposible.

Es imposible evaluar todas las posibilidades.

Recursos (costos, tiempo, personal)

¿Cuántos ciclos de pruebas son suficientes?

Estándares Internacionales ISO 9126 Modelo de evaluación de calidad de software; aporta características sencillas de evaluación y medición. Modelo de calidad Métricas externas (Aseguramiento de calidad) Métricas internas (Desarrollo) Métricas de calidad en uso (Producto final)

ISO 9126

Modelo de evaluación de calidad de software; aporta características sencillas de evaluación y medición.

Modelo de calidad

Métricas externas (Aseguramiento de calidad)

Métricas internas (Desarrollo)

Métricas de calidad en uso (Producto final)

Estándares Internacionales BS 7925 – 2 Estándar Británico para pruebas de componentes de software (Standard for Software Component Testing) Describe técnicas para el diseño y medición de casos de prueba, trata la ejecución y análisis de los resultados, características a seleccionar para determinar, comparar y mejorar la calidad de la prueba.

BS 7925 – 2

Estándar Británico para pruebas de componentes de software (Standard for Software Component Testing)

Describe técnicas para el diseño y medición de casos de prueba, trata la ejecución y análisis de los resultados, características a seleccionar para determinar, comparar y mejorar la calidad de la prueba.

Estándares Internacionales IEEE 829 Estándar para documentar pruebas de software. Especifica 8 etapas del proceso de documentación. Planeación de las pruebas Especificación del diseño de prueba Especificación de los casos de prueba Especificación del procedimiento Reporte de avance de los ciclos probados Registro de la prueba Reporte de incidentes Sumario de la prueba

IEEE 829

Estándar para documentar pruebas de software. Especifica 8 etapas del proceso de documentación.

Planeación de las pruebas

Especificación del diseño de prueba

Especificación de los casos de prueba

Especificación del procedimiento

Reporte de avance de los ciclos probados

Registro de la prueba

Reporte de incidentes

Sumario de la prueba

Estándares Internacionales TPI (Test Process Improvement) Metodología para evaluar el nivel de madurez de pruebas en una organización, así como para mejorar el proceso.

TPI (Test Process Improvement)

Metodología para evaluar el nivel de madurez de pruebas en una organización, así como para mejorar el proceso.

Definiciones importantes Prueba (test): A ctividad en la cual se somete a un sistema o uno de sus componentes a una evaluación de los resultados que arroja en base a la ejecución de éste en condiciones especificadas. Caso de Prueba (test case): C onjunto de entradas y condiciones que arrojan resultados esperados desarrollados con un objetivo en particular.

Prueba (test): A ctividad en la cual se somete a un sistema o uno de sus componentes a una evaluación de los resultados que arroja en base a la ejecución de éste en condiciones especificadas.

Caso de Prueba (test case): C onjunto de entradas y condiciones que arrojan resultados esperados desarrollados con un objetivo en particular.

Definiciones importantes Error Acción humana que produce o denera un resultado incorrecto. Defecto Es la manifestación de un error en el software. Un defecto es encontrado porque causa una FALLA , la cuál es una desviación del servicio o resultado esperado.

Error

Acción humana que produce o denera un resultado incorrecto.

Defecto

Es la manifestación de un error en el software.

Un defecto es encontrado porque causa una FALLA , la cuál es una desviación del servicio o resultado esperado.

Definiciones importantes

Definiciones importantes Verificación Determinar si los productos de una fase dada satisfacen las condiciones impuestas al inicio de la fase. ¿Estamos construyendo correctamente el producto?

Verificación

Determinar si los productos de una fase dada satisfacen las condiciones impuestas al inicio de la fase.

¿Estamos construyendo correctamente el producto?

Definiciones importantes Validación Evaluación de un sistema o uno de sus componentes durante o al final de su desarrollo para determinar si satisface los requisitos. ¿Estamos construyendo el producto correcto?

Validación

Evaluación de un sistema o uno de sus componentes durante o al final de su desarrollo para determinar si satisface los requisitos.

¿Estamos construyendo el producto correcto?

Modelos de desarrollo de software

Modelo en V

Modelo iterativo

Modelo en cascada

Clasificación de las pruebas Pruebas unitarias (componente, modulares o programa) Ejecutadas usualmente por los desarrolladores. Técnicas de caja blanca. Importante definir nivel de dependencia, a mayor independencia mayor efectividad.

Pruebas unitarias (componente, modulares o programa)

Ejecutadas usualmente por los desarrolladores.

Técnicas de caja blanca.

Importante definir nivel de dependencia, a mayor independencia mayor efectividad.

Clasificación de las pruebas Pruebas de sistemas Ejecutadas por los desarrolladores o equipo de pruebas en un ambiente controlado. Deben demostrar que los sistemas cumplen con los requerimientos detallados en los documentos de especificaciones de funcionalidad y calidad. Tipos: Funcionales No funcionales

Pruebas de sistemas

Ejecutadas por los desarrolladores o equipo de pruebas en un ambiente controlado.

Deben demostrar que los sistemas cumplen con los requerimientos detallados en los documentos de especificaciones de funcionalidad y calidad.

Tipos:

Funcionales

No funcionales

Clasificación de las pruebas Pruebas de integración Ejecutadas para exponer fallas en interfases y en la interacción entre componentes. Ejecutadas por los desarrolladores. Técnicas: Big bang Top down Bottom up Middle-out

Pruebas de integración

Ejecutadas para exponer fallas en interfases y en la interacción entre componentes.

Ejecutadas por los desarrolladores.

Técnicas:

Big bang

Top down

Bottom up

Middle-out

Clasificación de las pruebas Funcionales: Requerimientos No funcionales: Carga Estrés Usabilidad Volumen Documentación Desempeño Seguridad Almacenamiento Instalación Recuperación

Funcionales:

Requerimientos

No funcionales:

Carga

Estrés

Usabilidad

Volumen

Documentación

Desempeño

Seguridad

Almacenamiento

Instalación

Recuperación

Clasificación de las pruebas Pruebas de aceptación Ejecutadas por los usuarios y líderes de proyecto ó administradores en un ambiente simulado de operación. Deben demostrar que los sistemas cumplen con los requerimientos detallados en los documentos de especificaciones de funcionalidad y calidad.

Pruebas de aceptación

Ejecutadas por los usuarios y líderes de proyecto ó administradores en un ambiente simulado de operación.

Deben demostrar que los sistemas cumplen con los requerimientos detallados en los documentos de especificaciones de funcionalidad y calidad.

Clasificación de las pruebas Pruebas de regresión Determinar que las modificaciones no han causado fallas o efectos adversos. Determina que se cumple con los requerimientos. Modificaciones menores selección de pruebas. Construir paquetes de pruebas de regresión, actualizarlas.

Pruebas de regresión

Determinar que las modificaciones no han causado fallas o efectos adversos.

Determina que se cumple con los requerimientos.

Modificaciones menores selección de pruebas.

Construir paquetes de pruebas de regresión, actualizarlas.

Pruebas de caja Existen tres enfoques para el diseño de casos de prueba: El enfoque estructural o de caja blanca El enfoque funcional o de caja negra El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones estadísticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba

Existen tres enfoques para el diseño de casos de prueba:

El enfoque estructural o de caja blanca

El enfoque funcional o de caja negra

El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones estadísticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba

Pruebas de caja

Pruebas de caja BLANCA Las pruebas de caja blanca realizan un seguimiento del código fuente de manera que se determinan las instrucciones, bloques, etc. en los que existen errores. Las pruebas dinámicas se dividen en dos: Explícitas: Ejecución de los casos de prueba, comparar los resultados obtenidos con los esperados. Implícitas: Análisis de los datos o información que el sistema entrega, para detectar funcionamientos erróneos.

Las pruebas de caja blanca realizan un seguimiento del código fuente de manera que se determinan las instrucciones, bloques, etc. en los que existen errores.

Las pruebas dinámicas se dividen en dos:

Explícitas: Ejecución de los casos de prueba, comparar los resultados obtenidos con los esperados.

Implícitas: Análisis de los datos o información que el sistema entrega, para detectar funcionamientos erróneos.

Técnicas de caja BLANCA Métricas de complejidad Statement testing Decision coverage Condition Coverage

Métricas de complejidad

Statement testing

Decision coverage

Condition Coverage

Métricas de complejidad Complejidad ciclomatica Mide el número de decisiones lógicas dentro de un segmento de código. Número de rutas de prueba recomendado como mínimo a probar. Complejidad ciclomatica, v, es la medida de la complejidad lógica de un módulo “G” y el esfuerzo mínimo necesario para calificarlo. V es el número de rutas lineares independientes de un módulo “G”, por lo tanto es el número mínimo de rutas que deben probarse.

Complejidad ciclomatica

Mide el número de decisiones lógicas dentro de un segmento de código.

Número de rutas de prueba recomendado como mínimo a probar.

Complejidad ciclomatica, v, es la medida de la complejidad lógica de un módulo “G” y el esfuerzo mínimo necesario para calificarlo. V es el número de rutas lineares independientes de un módulo “G”, por lo tanto es el número mínimo de rutas que deben probarse.

edge node arista

Complejidad ciclomatica Calculando v(G) Formal (edges and nodes) v(G) = e-n+2 Predicate (aristas) v(G) = p+1 Regiones v(G)=R

Calculando v(G)

Formal (edges and nodes)

v(G) = e-n+2

Predicate (aristas)

v(G) = p+1

Regiones

v(G)=R

Statement Testing Test_func(int a, int b){ If(a==b) Op1(); Else Op2(); If(a==c) Op3(); Else Op4();

Test_func(int a, int b){

If(a==b)

Op1();

Else

Op2();

If(a==c)

Op3();

Else

Op4();

Statement Testing Rutas probadas Test 1 if(a==b)  true If (a==c)  True Test 2 if(a==b)  false if(a==c)  false Resultados de cobertura Test 1: 7 líneas probadas  64% Test 2: 9 líneas probadas  82% Test 1 & 2 : 11 líneas probadas  100% 2 pruebas requeridas

Rutas probadas

Test 1 if(a==b)  true

If (a==c)  True

Test 2 if(a==b)  false

if(a==c)  false

Resultados de cobertura

Test 1: 7 líneas probadas  64%

Test 2: 9 líneas probadas  82%

Test 1 & 2 : 11 líneas probadas  100%

2 pruebas requeridas

Decision Coverage Test_func(int a, int b){ If(a==b) Op1();  Branch 1 Else Op2();  Branch 2 If(a==c) Op3();  Branch 3 Else Op4();  Branch 4

Test_func(int a, int b){

If(a==b)

Op1();  Branch 1

Else

Op2();  Branch 2

If(a==c)

Op3();  Branch 3

Else

Op4();  Branch 4

Decision Coverage Rutas probadas Test 1 if(a==b)  true If (a==c)  True Test 2 if(a==b)  false if(a==c)  false Resultados de cobertura Test 1: 2 ramas probadas  50% Test 2: 2 ramas probadas  50% Test 1 & 2 : 4 ramas probadas  100% 2 pruebas requeridas

Rutas probadas

Test 1 if(a==b)  true

If (a==c)  True

Test 2 if(a==b)  false

if(a==c)  false

Resultados de cobertura

Test 1: 2 ramas probadas  50%

Test 2: 2 ramas probadas  50%

Test 1 & 2 : 4 ramas probadas  100%

2 pruebas requeridas

Condition Coverage Examinar cada punto de decisión. Tablas de verdad. No es fácil implementar. If (a==b or a==c) Op1(); F F F 3 T T F 2 T - T 1 Resultado C1 C0 Test #

Examinar cada punto de decisión.

Tablas de verdad.

No es fácil implementar.

If (a==b or a==c)

Op1();