Está en la página 1de 4

1.

Exhaustividad de las pruebas


a) 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 compleció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.
El valor de CP debe estar entre 0 y 1. La cobertura de pruebas será más eficiente mientras
más se acerque a 1, esto implica que se están ejecutando la mayor cantidad de casos de
prueba de los que se propusieron en el plan de pruebas.

b) 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.
■ : complejidad ciclomática calculada anteriormente.
Si el valor de PCB no está cerca del 100%, entonces el número de pruebas diseñadas no es
suficiente para asegurar que se ejecutan todas las sentencias del programa.

c) 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. Para obtener esta métrica es preciso registrar los casos de prueba
que obtuvieron resultados satisfactorios y el total de los casos de prueba definidos para el
cumplimiento de los requerimientos. 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.

El valor de esta métrica debe estar entre 0 y 1. Mientras mayor sea el número de casos de
prueba que han obtenido un resultado satisfactorio de los casos realmente ejecutados y que
se requieren para cubrir los requerimientos, mayor será la madurez alcanzada por el equipo
de probadores del software, lo ideal es un valor tan cercano a 1 como sea posible.
d) 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.
El valor del %DT indica la frecuencia de aparición del error analizado, por tanto mientras
mayor sea su valor más frecuente será la aparición de ese error específico.

2. Densidad de defectos
La densidad de defectos ofrece una medida sobre la proporción de defectos con respecto a
la cantidad de elementos de especificación. 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.

3. Métrica para el control de pruebas de unidad


Las pruebas de unidad son aquellas pruebas individuales, que se realizan durante la
implementación, en las cuales se prueban los componentes antes de enviarlos para
integrarlos, compilarlos, enlazarlos con uno o más ejecutables y realizar las
comprobaciones del sistema.
La métrica para el control de pruebas de unidad ofrece una medida de los componentes que
se han probado individualmente antes de la integración con respecto al total de
componentes que fueron implementados. La métrica para el control de pruebas de unidad
se calcula como:

Donde:
■ CPU: valor de la métrica para el control de pruebas de unidad.
■ NCP: número de componentes probados individualmente antes de integrarlos.
■ CImp: número de componentes implementados.
Esta métrica ofrece valores entre 0 y 1. Si CPU = 1 significa que todos los componentes
implementados fueron probados individualmente antes de la integración.

4. Tasa de propagación de defectos


La corrección de defectos en el software puede originar nuevos defectos, este fenómeno es
conocido como propagación de defectos. La tasa de propagación de defectos indica el
comportamiento de la propagación de defectos en la realización de las pruebas. La tasa de
propagación de defectos se calcula como:

Donde:
■ Dn: número de defectos ocasionados al corregir defectos anteriores.
■ Dc: número de defectos corregidos.
El valor de TPD ofrece mejores resultados cuando está más cerca de 1. Al calcular esta
métrica pueden obtenerse valores negativos, cuando el número de defectos ocasionados al
corregir defectos es mayor que el número de defectos corregidos, en este caso dichos
valores no se tendrán en cuenta al trabajar con el resultado de la métrica, sino que se
considerarán como cero.

5. Índice de Madurez del Software


El Índice de Madurez del Software (IMS), propuesto por el estándar IEEE 982.1-1988,
proporciona un indicador de la estabilidad del software basado en los cambios que ocurren
en cada versión del producto, este es un indicador de la facilidad de mantenimiento del
software. El IMS se calcula como:

Donde:
■ IMS: índice de madurez del software.
■ Mt: número de módulos en la versión actual.
■ Fc: número de módulos en la versión actual que han sido modificados.
■ Fa: número de módulos en la versión actual que han sido añadidos.
■ Fe: número de módulos en la versión actual que han sido eliminados.
El valor del IMS está siempre entre 0 y 1. Mientras más cerca esté el valor del IMS de 1,
más estable será el producto software.

http://vinculando.org/articulos/sociedad_america_latina/propuesta_guia_de_medidas_para_
evaluacion_sistemas_informacion.html

También podría gustarte