Concepto: Medidas clave de la prueba
En esta directriz se presentan las medidas de calidad y cobertura para los conjuntos de aplicaciones de prueba.
Relaciones
Elementos relacionados
Descripción principal

Introducción

Las medidas clave de una prueba incluyen la cobertura y la calidad.

La cobertura de la prueba es la medida de la completitud de la prueba y se basa en la cobertura de la prueba expresada mediante la cobertura de los requisitos de prueba y los guiones de prueba o mediante la cobertura del código ejecutado.

La calidad es una medida de fiabilidad, estabilidad y rendimiento del destino de la prueba (sistema o aplicación que se está probando). La calidad se basa en la evaluación de los resultados de la prueba y el análisis de las solicitudes de cambio (defectos) identificados durante la prueba.

Medidas de cobertura

La métrica de cobertura responde a la pregunta: "¿Qué porcentaje de la prueba está completo?" Las medidas de cobertura que se utilizan con más frecuencia se basan en la cobertura de los requisitos de software y el código fuente. Básicamente, la cobertura de la prueba es cualquier medida de completitud con respecto a un requisito (basada en requisitos) o los criterios de implementación y diseño de código (basada en código), como la verificación de guiones de uso (basada en requisitos) o la ejecución de todas las líneas de código (basada en código).

Cualquier tarea de prueba sistemática se basa en, como mínimo, una estrategia de cobertura de la prueba. La estrategia de cobertura guía el diseño de los guiones de prueba indicando el objetivo general de la prueba. La sentencia de la estrategia de cobertura puede ser tan simple como verificar todo el rendimiento.

Una estrategia de cobertura basada en requisitos puede ser suficiente para producir una medida cuantificable de la completitud de la prueba si los requisitos se catalogan completamente. Por ejemplo, si se han identificado todos los requisitos de la prueba de rendimiento, los resultados de la prueba se pueden consultar para obtener medidas; por ejemplo, se ha verificado el 75% de los requisitos de la prueba de rendimiento.

Si se aplica la cobertura basada en código, las estrategias de prueba se formulan en términos de qué cantidad del código fuente han ejecutado las pruebas. Este tipo de estrategia de cobertura de la prueba es muy importante para sistemas de seguridad crítica.

Las dos medidas se pueden derivar manualmente (utilizando las ecuaciones que se proporcionan en las dos cabeceras siguientes) o se pueden calcular con las herramientas de automatización de pruebas.

Cobertura de la prueba basada en requisitos

La cobertura de la prueba basada en requisitos, medida varias veces durante el ciclo vital de la prueba, identifica la cobertura de la prueba en un hito del ciclo vital de pruebas, como la cobertura de la prueba satisfactoria, ejecutada, implementada y planificada.

  • La cobertura de la prueba se calcula con la siguiente ecuación:

Cobertura de la prueba = T(p,i,x,s) / RfT

Donde:
T es el número de pruebas (planificadas, implementadas, ejecutadas o satisfactorias), expresadas como procedimientos de prueba o guiones de prueba.

RfT es el número total de requisitos de la prueba.

  • En la tarea Planificar prueba, la cobertura de la prueba se calcula para determinar la cobertura de la prueba planificada de la siguiente manera:

Cobertura de la prueba (planificada) = Tp / RfT

Donde:
Tp es el número de pruebas planificadas, expresadas como procedimientos de pruebas o guiones de prueba.

RfT es el número total de requisitos de la prueba.

  • En la tarea Implementar prueba, cuando se implementan los procedimientos de prueba (como scripts de prueba), se calcula la cobertura de la prueba con la siguiente ecuación:

Cobertura de la prueba (implementada) = Ti / RfT

aquí:
Ti es el número de pruebas implementadas, expresado mediante el número de procedimientos de prueba o guiones de prueba para los que hay scripts de prueba correspondientes.

RfT es el número total de requisitos de la prueba.

  • En la tarea Ejecutar prueba, se utilizan dos medidas de cobertura de la prueba: una identifica la cobertura de la prueba que se consigue mediante la ejecución de pruebas y la segunda identifica la cobertura de la prueba satisfactoria (las pruebas que se ejecutaron sin anomalías, como defectos o resultados inesperados).

    Estas medidas de cobertura se calculan con las siguientes ecuaciones:

    Cobertura de la prueba (ejecutada) = Tx / RfT

    Donde:
    Tx es el número de pruebas ejecutadas, expresadas como procedimientos de prueba o guiones de prueba.

    RfT es el número total de requisitos de la prueba.



Cobertura de la prueba satisfactoria (ejecutada) = Ts / RfT

Donde:
Ts es el número de pruebas ejecutadas, expresadas como procedimientos de prueba o guiones de prueba que se completaron satisfactoriamente, sin defectos.

RfT es el número total de requisitos de la prueba.



Si convertimos las proporciones anteriores en porcentajes, se admite la siguiente sentencia de cobertura de la prueba basada en requisitos:

El x% de los guiones de prueba (T(p,i,x,s) en las ecuaciones anteriores) se ha cubierto con un índice de satisfacción del y%

Esta sentencia significativa de la cobertura de la prueba se puede comparar con los criterios de satisfacción definidos. Si no se han cumplido los criterios, la sentencia proporciona una base para predecir la cantidad de esfuerzo de prueba que resta.

Cobertura de la prueba basada en código

La cobertura de la prueba basada en código mide la cantidad de código que se ejecutó durante la prueba, en comparación con la cantidad de código que queda por ejecutar. La cobertura de código puede basarse en flujos de control (sentencia, ramificación o vías de acceso) o flujos de datos.

  • En la cobertura del flujo de control, el objetivo es probar las líneas de código, las condiciones de ramificación, las vías de acceso del código u otros elementos del flujo de control del software.
  • En la cobertura del flujo de datos, el objetivo es comprobar que el estado de los datos es válido durante el funcionamiento del software; por ejemplo, que un elemento de datos se define antes de utilizarse.

La cobertura de la prueba basada en código se calcula con la siguiente ecuación:

Cobertura de la prueba = Ie / TIic

Donde:
Ie es el número de elementos ejecutados, expresados como sentencias de código, ramificaciones de código, vías de acceso de código, puntos de decisión del estado de los datos o nombres de elementos de datos.

TIic es el número total de elementos del código.



Si se convierte esta proporción en un porcentaje, se admite la siguiente sentencia de cobertura de la prueba basada en código:

El x% de los guiones de prueba (I en la ecuación anterior) se han cubierto con un índice de satisfacción del y%

Esta sentencia significativa de la cobertura de la prueba se puede comparar con los criterios de satisfacción definidos. Si no se han cumplido los criterios, la sentencia proporciona una base para predecir la cantidad de esfuerzo de prueba que resta.

Medida de la calidad percibida

Aunque la evaluación de la cobertura de la prueba proporciona una medida del grado de completitud del esfuerzo de prueba, la evaluación de los defectos descubiertos durante la prueba proporciona la mejor indicación de la calidad del software tal como se ha experimentado. Esta percepción de calidad se puede utilizar para razonar sobre la calidad general del sistema de software en su conjunto. La calidad del software percibida es una medida del grado en que el software cumple los requisitos que se le imponen; por lo tanto, en este contexto, los defectos se consideran como un tipo de solicitud de cambio en el que el destino de la prueba no cumplió los requisitos de software.

La evaluación de defectos puede basarse en métodos que van desde simples recuentos de defectos hasta un riguroso modelado estadístico.

La evaluación rigurosa utiliza conjeturas sobre la velocidad de descubrimiento o llegada de defectos durante el proceso de prueba. Un modelo común presupone que la velocidad está de acuerdo con la distribución de Poisson. Los datos reales sobre la velocidad de los defectos se ajustan al modelo. La evaluación resultante calcula la fiabilidad actual del software y predice cómo aumentará la fiabilidad si continúan la eliminación de defectos y las pruebas. Esta evaluación se describe como modelado del crecimiento de la fiabilidad del software y es un área de estudio activo. Debido a la falta de soporte de herramientas para este tipo de evaluación, es recomendable equilibrar cuidadosamente el coste de utilizar este enfoque con los beneficios obtenidos.

El análisis de defectos incluye el análisis de la distribución de defectos a los valores de uno o varios de los atributos asociados a un defecto. El análisis de defectos proporciona una indicación de la fiabilidad del software.

En el análisis de defectos, normalmente se analizan cuatro atributos de defectos principales:

  • Estado: el estado actual del defecto (abierto, arreglándose, cerrado, etc).
  • Prioridad: la importancia relativa de este defecto que se está resolviendo.
  • Gravedad: el impacto relativo de este defecto para el usuario, una organización, terceros, etc.
  • Origen: dónde está y cuál es el error de origen que provoca este defecto o qué componente se va a arreglar para eliminar este defecto.

Los recuentos de defectos se pueden notificar como una función de tiempo, creando un informe o diagrama de la tendencia de defectos. También se pueden notificar en un informe de densidad de defectos como una función de uno o varios atributos de defectos, como la gravedad o el estado. Estos tipos de análisis proporcionan una perspectiva de las tendencias o de la distribución de defectos que revela la fiabilidad del software.

Por ejemplo, es de esperar que la velocidad de descubrimiento de defectos disminuya a medida que avanzan las pruebas y los arreglos. Se puede establecer un umbral de defectos o calidad pobre que indique el punto en que la calidad del software pasa a ser inaceptable. Los recuentos de defectos también se pueden notificar en función del origen del modelo de implementación, lo que permite detectar "módulos débiles", "zonas activas" y componentes de software que se arreglan una y otra vez, lo que indica errores de diseño más fundamentales.

En un análisis de este tipo sólo se incluyen defectos confirmados. No todos los defectos notificados denotan un error real; algunos son solicitudes de mejora fuera del ámbito del proyecto o describen un defecto que ya se ha notificado. Sin embargo, merece la pena analizar por qué se notifican muchos defectos que son duplicados o defectos no confirmados.

Informes de defectos

Rational Unified Process recomienda la evaluación de defectos basada en varias categorías de informes, como se muestra a continuación:

  • Los informes de distribución (densidad) de defectos permiten que se muestren los recuentos de defectos como una función de uno o dos atributos de defectos.
  • Los informes de antigüedad de defectos son un tipo especial de informe de distribución de defectos. Los informes de antigüedad de defectos muestran el tiempo que lleva un defecto en un estado en particular, por ejemplo, Abierto. En cualquier categoría de antigüedad, los defectos también se pueden ordenar según otro atributo, por ejemplo, Propietario.
  • Los informes de tendencia de defectos muestran los recuentos de defectos, por estado (nuevo, abierto o cerrado), como una función de tiempo. Los informes de tendencia pueden ser acumulativos o no acumulativos.

Muchos de estos informes son valiosos para evaluar la calidad del software. Son especialmente útiles cuando se analizan junto con los resultados de la prueba y los informes de progreso que muestran los resultados de las pruebas que se realizaron en una serie de iteraciones y ciclos de prueba para la aplicación que se está probando. Los criterios de prueba habituales incluyen una sentencia sobre el número tolerable de defectos abiertos en determinadas categorías, como la clase de gravedad, que se comprueba fácilmente con una evaluación de la distribución de defectos. Al clasificar y agrupar esta distribución según motivadores de prueba, la evaluación se puede centrar en áreas de preocupación importantes.

Normalmente, es necesario el soporte de herramientas para crear eficazmente informes de este tipo.

Informes de la densidad de defectos

Prioridad en oposición a estado del defecto

Proporcione a cada defecto una prioridad. Normalmente, resulta práctico y es suficiente tener cuatro niveles de prioridad, por ejemplo:

  • Prioridad urgente (resolver inmediatamente)
  • Prioridad alta
  • Prioridad normal
  • Prioridad baja

Nota: los criterios para una prueba satisfactoria se pueden expresar en términos del aspecto que debería tener la distribución de defectos en estos niveles de prioridad. Por ejemplo, los criterios de prueba satisfactorios pueden ser "están abiertos cero defectos de Prioridad 1 y menos de cinco defectos de Prioridad 2". Debe generarse un diagrama de distribución de defectos, como el siguiente.

Diagrama de distribución de defectos



Está claro que no se han satisfecho los criterios. Este diagrama debe incluir un filtro para mostrar únicamente los defectos abiertos, como requieren los criterios de la prueba.

Gravedad en oposición a estado del defecto

Los informes de gravedad de defectos muestran cuántos defectos hay en cada clase de gravedad; por ejemplo, error muy grave, función principal no realizada, error leve.

Ubicación es oposición a estado del defecto en el modelo de implementación

Los informes de origen de defectos muestran la distribución de los defectos en los elementos del modelo de implementación.

Informes de antigüedad de defectos

El análisis de la antigüedad de defectos proporciona información fiable sobre la eficacia de las pruebas y las tareas de eliminación de defectos. Por ejemplo, si la mayoría de los defectos antiguos, sin resolver, se encuentran en estado de validación pendiente, probablemente significa que no se han aplicado los suficientes recursos al esfuerzo de repetir la prueba.

Informes de tendencia de defectos

Los informes de tendencia de defectos identifican los índices de defectos y proporcionan una vista especialmente buena del estado de la prueba. Las tendencias de defectos siguen un patrón bastante previsible en un ciclo de prueba. Al principio del ciclo, los índices de defectos aumentan con rapidez, hasta que alcanzan un pico y empiezan a disminuir a una velocidad menor a lo largo del tiempo.



Diagrama de informes de tendencia de defectos

Para buscar problemas, la planificación del proyecto se puede revisar teniendo en cuenta esta tendencia. Por ejemplo, si los índices de defectos siguen aumentando en la tercera semana de un ciclo de prueba de cuatro semanas, no cabe duda de que el proyecto no está siguiendo la planificación.

Este sencillo análisis de tendencias presupone que los defectos se están arreglando puntualmente y que los arreglos se están probando en compilaciones posteriores, de modo que la velocidad de cerrar defectos debería tener el mismo perfil que la velocidad de encontrar defectos. Cuando esto no sucede, indica que hay un problema con el proceso de resolución de defectos; los recursos de arreglo de defectos o los recursos para repetir la prueba y validar los arreglos podrían ser inapropiados.

Diagrama de informes de análisis de tendencias

La tendencia que se refleja en este informe muestra que se han descubierto defectos nuevos y se han abierto rápidamente al principio del proyecto, y que disminuyen con el tiempo. La tendencia para abrir defectos es similar a la tendencia para defectos nuevos, aunque va un poco por detrás. La tendencia para cerrar defectos aumenta con el tiempo, a medida que se arreglan y verifican los efectos abiertos. Estas tendencias representan un esfuerzo satisfactorio.

Si sus tendencias se desvían dramáticamente de estas, pueden indicar un problema e identificar cuándo es necesario aplicar recursos adicionales a áreas específicas de desarrollo o prueba.

Cuando se combinan con las medidas de cobertura de la prueba, el análisis de defectos proporciona una evaluación excelente para basar los criterios de terminación.

Medidas de rendimiento

Se utilizan varias medidas para evaluar los comportamientos de rendimiento del destino de la prueba y para centrarse en la captura de datos relacionados con los comportamientos, como el tiempo de respuesta, los perfiles de tiempo, el flujo de ejecución, la fiabilidad operativa y los límites. Principalmente, estas medidas se evalúan en la tarea Evaluar prueba; sin embargo, hay medidas de rendimiento que se utilizan durante la tarea Ejecutar prueba para evaluar el estado y el progreso de la prueba.

Las principales medidas de rendimiento son:

  • Supervisión dinámica: captura y visualización en tiempo real del estado de cada script de prueba que se ejecuta durante la ejecución de la prueba.
  • Informes de rendimiento y tiempo de respuesta: medida de los tiempos de respuesta y el rendimiento del destino de la prueba para los actores y guiones de uso especificados.
  • Informes de percentil: medida y cálculo del percentil de los valores recopilados de los datos.
  • Informes de comparación: diferencias o tendencias entre dos (o más) conjuntos de datos que representan diferentes ejecuciones de la prueba.
  • Informes de rastreo: detalles de los mensajes y conversaciones entre el actor (script de prueba) y el destino de la prueba.

Supervisión dinámica

La supervisión dinámica proporciona visualización e informes en tiempo real durante la ejecución de la prueba, normalmente en formato de histograma o gráfico. El informe supervisa o evalúa la ejecución de pruebas de rendimiento mediante la visualización del estado actual y el progreso de los scripts de prueba.

Supervisión dinámica visualizada como un histograma

Por ejemplo, en el histograma precedente, hay 80 scripts de prueba ejecutando el mismo guión de uso. En este gráfico, hay 14 scripts de prueba en estado Desocupado, 12 en estado Consulta, 34 en estado Ejecución de SQL, 4 en estado de Conexión SQL y 16 en estado Otro. A medida que progresa la prueba, verá cómo cambia el número de scripts en cada estado. La salida visualizada será típica de la ejecución de una prueba que progresa con normalidad y se encuentra en medio de la ejecución. Sin embargo, si los scripts de prueba permanecen en un estado o no muestran cambios durante la ejecución de la prueba, podría ser una indicación de que existe un problema en la ejecución de la prueba, o la necesidad de implementar o evaluar otras medidas de rendimiento.

Informes de rendimiento y tiempo de respuesta

Los informes de rendimiento y tiempo de respuesta, como su nombre indica, miden y calculan los comportamientos de rendimiento relacionados con el tiempo y el rendimiento (número de transacciones procesadas). Normalmente, estos informes se muestran como un gráfico con tiempo de respuesta (o número de transacciones) en el eje "y" y sucesos en el eje "x".

Diagrama de informes de análisis y rendimiento de ejemplo

Normalmente, es recomendable calcular y visualizar la información estadística, como la desviación media y estándar de los valores de datos, además de mostrar los comportamientos de rendimiento real.

Informes de percentil

Los informes de percentil proporcionan otro cálculo estadístico de rendimiento mediante la muestra de valores de percentil de la población para los tipos de datos recopilados.

Diagrama de informes de percentil de ejemplo

Informes de comparación

Es importante comparar los resultados de la ejecución de una prueba de rendimiento con los de otra, para poder evaluar el impacto de los cambios realizados entre las ejecuciones de la prueba en los comportamientos de rendimiento. Utilice los informes de comparación para visualizar la diferencia entre dos conjuntos de datos (cada uno representa una ejecución de prueba diferente) o tendencias entre muchas ejecuciones de prueba.

Informes de rastreo y perfil

Cuando los comportamientos de rendimiento son inaceptables o la supervisión de rendimiento indica posibles cuellos de botella (por ejemplo, scripts de prueba que permanecen en un estado dado durante periodos de tiempo muy largos), el informe de rastreo podría ser el informe más valioso. Los informes de rastreo y perfil muestran información de bajo nivel. Esta información incluye los mensajes entre el actor y el destino de la prueba, el flujo de ejecución, el acceso de datos y las llamadas al sistema y a funciones.