Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Metricas para el proceso de pruebas de Software

No description
by

on 25 May 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Metricas para el proceso de pruebas de Software

Introducción
Para obtener un software de calidad es necesario medir el proceso de software (Avances, tamaño, costos, etc,).
Métricas
Las métricas determinan, mediante estadísticas en la experiencia, el avance del software y el cumplimiento de parámetros requeridos.
Métricas para Pruebas

¿Qué se utiliza en las pruebas?
Durante la etapa de pruebas se utilizarán la métrica de cobertura, madurez y profundidad de las pruebas, el porcentaje de defectos por tipo, la densidad de defectos, la métrica para el control de pruebas de unidad, la tasa de propagación de defectos, la métrica para pruebas de camino básico y el índice de madurez del software.
Métricas para el proceso de Pruebas de Software
Estas mediciones se realizan mediante las
métricas
que le dan un valor a los diferentes aspectos del desarrollo de software.
Aunque se ha escrito mucho sobre métricas del software para pruebas, la mayoría de las métricas propuestas se concentran en el proceso de pruebas, no en las características técnicas de las pruebas mismas.
Las pruebas al software se realizan con el objetivo de encontrar y documentar los defectos en la calidad del software, aconsejar en base a la calidad determinada, validar y probar las hipótesis hechas en el diseño y la especificación de requerimientos mediante una demostración concreta
Medida de amplitud o cobertura de las pruebas
Proporciona un indicador de cuantos requisitos se han probado del número total de ellos. Indica la complexión del plan de pruebas
La cobertura de las pruebas indica cómo se van cumpliendo los casos de prueba especificados, por tanto una mayor cobertura de las pruebas indica un buen desarrollo de las pruebas
La cobertura de las pruebas se calcula como:


Donde:
• CP: valor de la cobertura de las pruebas.
• CPE: número de casos de prueba que han sido ejecutados.
• CPR: número de casos de prueba a ejecutar requeridos para cubrir todos los requerimientos.

Profundidad de las pruebas
Porcentaje de los caminos básicos independientes probados en relación al total de ellos sumando la complejidad ciclomática de todos los módulos del programa.
La métrica para pruebas del camino básico se calcula como:
Donde:
• PCB: porcentaje de caminos básicos.
• P: número de pruebas diseñadas.
• v(G): complejidad ciclomática calculada anteriormente.

Madurez de las pruebas
Indicador del buen desempeño del flujo de trabajo de pruebas, no sólo se enfoca en la completitud de los casos de prueba según los definidos para cubrir los requerimientos, sino que también comprende los casos de pruebas que han obtenido resultados satisfactorios.
La madurez de las pruebas se calcula como:
Donde:
• MP: valor de la madurez de las pruebas.
• CPS: número de casos de prueba que han dado resultados satisfactorios.
• CPR: número de casos de prueba diseñados para cubrir todos los requerimientos.

Perfiles de fallos
Se emplean para categorizar y priorizar los errores. La prioridad indica la severidad del problema. Las categorías de fallos proporcionan una descripción del error para realizar análisis estadísticos de errores.

El porcentaje de defectos por tipo permite categorizar los fallos porque identifica los tipos de defectos más comunes que puedan presentarse en cualquier etapa del desarrollo del software.
El porcentaje de defectos por tipo se calcula como:
Donde:
• %DT: porcentaje de defectos por tipo.
• NDT: es el número de defectos por tipo.
• TDI: número total de defectos identificados en una etapa del proyecto.

La densidad de defectos ofrece una medida sobre la proporción de defectos con respecto a la cantidad de elementos de especificación.
Densidad de defectos
Esta métrica permite realizar análisis estadísticos al finalizar las pruebas para valorar la integridad y madurez del software analizado.
La densidad de defectos se calcula como:
Donde:
• DD: densidad de defectos.
• TD: número total de defectos encontrados durante las pruebas.
• CER: número de elementos de especificación revisados.

Es recomendable para una alta calidad del software que la densidad de defectos tenga un valor mínimo.

• La mayoría de las métricas se concentran en el proceso y no en el producto.
• Debe apoyarse en las métricas del análisis y del diseño.
• Las métricas basadas en la función pueden utilizarse para predecir el esfuerzo global de las pruebas.
• La métrica Bang puede proporcionar una indicación del numero de los casos de prueba necesarios para examinar una media primitiva(burbuja del DFD).
• A medida que avanzan las pruebas, hay métricas que indican la completitud de las mismas:
- Amplitud de las pruebas(cuantos requisitos se han probado).
- Profundidad de las pruebas(% de los caminos básicos probados).
- Perfiles de fallo(para dar prioridad y categorizar los errores encontrados).
• Ayudan a diseñar casos de prueba efectivos y evaluar la eficacia de las pruebas.
• Métricas de cobertura de instrucciones y ramas
• Métricas relacionadas con los defectos
• Efectividad de la prueba
• Métricas en el proceso
• En muchos modelos las métricas de un modelo pueden aplicarse en actividades posteriores a la ingeniería del software.
Métricas para las pruebas
Se emplea para desarrollar una indicación del tamaño del software a implementar como consecuencia del diseño del modelo de análisis. Desarrollada por el marco es una indicación independiente de la implementación del tamaño del sistema. El desarrollador del software debe evaluar un conjunto de primitivas.
Métrica Bang
Full transcript