24 de noviembre de 2012

Métricas para Pruebas

Aunque se ha escrito mucho sobre las métricas del software para pruebas, la mayoría de las métricas propuestas se concentran en el proceso de prueba, no en las características técnicas de las pruebas mismas. En general, los responsables de las pruebas deben fiarse de las métricas de análisis, diseño y código para que les guíen en el diseño y ejecución de los casos de prueba.

Las métricas basadas en la función pueden emplearse para predecir el esfuerzo global de las pruebas. Se pueden juntar y correlacionar varias características a nivel de proyecto (por ejemplo, esfuerzo y tiempo para las pruebas, errores descubiertos, número de casos de prueba producidos) de proyectos anteriores con el número de PF producidos por un equipo del proyecto. El equipo puede después predecir los valores «esperados» de estas características del proyecto actual.

La métrica bang puede proporcionar una indicación del número de casos de prueba necesarios para examinar las medidas primitivas. El número de primitivas funcionales (PFu), elementos de datos (DE), objetos (OB), relaciones (RE), estados (ES) y transiciones (TR) pueden emplearse para predecir el número y tipos de prueba del software de caja negra y de caja blanca. Por ejemplo, el número de pruebas asociadas con la interfaz hombre-máquina se puede estimar examinando: (1) el número de transiciones (TR) contenidas en la representación estado-transición del IHM y evaluando las pruebas requeridas para ejecutar cada transición, (2) el número de objetos de datos (OB) que se mueven a través de la interfaz y (3) el número de elementos de datos que se introducen o salen.

Las métricas del diseño arquitectónico proporcionan información sobre la facilidad o dificultad asociada con
la prueba de integración y la necesidad de software especializado de prueba (por ejemplo, matrices y controladores). La complejidad ciclomática (una métrica de diseño de componentes) se encuentra en el núcleo de las pruebas de caminos básicos. Además, la complejidad ciclomática puede usarse para elegir módulos como candidatos para pruebas más profundas. Los módulos con gran complejidad ciclomática tienen más probabilidad de tendencia a errores que los módulos con menor complejidad ciclomática.
Por esta razón, el analista debería invertir un esfuerzo extra para descubrir errores en el módulo antes de integrarlo en un sistema. Es esfuerzo de las pruebas también se puede estimar usando métricas obtenidas de medidas de Halstead. Usando la definición del volumen de un programa, V, y nivel de programa, NP, el esfuerzo de la ciencia del software, e, puede calcularse como:



El porcentaje del esfuerzo global de pruebas a asignar a un módulo k se puede estimar usando la siguiente relación:


donde e(k) se calcula para el módulo k usando la primera ecuaciones y la suma en el denominador de la segunda ecuación  es la suma del esfuerzo de la ciencia del software a lo largo de todos los módulos del sistema.

A medida que se van haciendo las pruebas, tres medidas diferentes proporcionan una indicación de la compleción de las pruebas. Una medida de la amplitud de las pruebas proporciona una indicación de cuantos requisitos (del número total de ellos) se han probado.
Esto proporciona una indicación de la compleción del plan de pruebas. La profundidad de las pruebas es una medida del porcentaje de los caminos básicos independientes probados en relación al número total de estos caminos en el programa. Se puede calcular una estimación razonablemente exacta del número de caminos básicos sumando la complejidad ciclomática de todos los módulos del programa. Finalmente, a medida que se van haciendo las pruebas y se recogen los datos de los errores, se pueden emplear los perfiles de fallos para dar prioridad y categorizar los errores descubiertos. La prioridad indica la severidad del problema. Las categorías de los fallos proporcionan una descripción de un error, de manera que se puedan llevar a cabo análisis estadísticos de errores.




1 comentario: