Métricas de prueba de software: qué es, tipos y ejemplos
Tomas Hamilton
⚡ Resumen inteligente
Las métricas de pruebas de software son medidas cuantitativas del progreso, la calidad y la productividad de un proceso de pruebas. Esta guía abarca los tres tipos de métricas, la distinción entre métricas básicas y calculadas, el ciclo de vida de las métricas y un glosario de fórmulas que puede aplicar directamente.
¿Qué son las métricas de pruebas de software?
Métricas de prueba de software son las medidas cuantitativas utilizadas para estimar el progreso, la calidad, la productividad y la salud del proceso de prueba de software. El objetivo de las métricas de prueba de software es mejorar la eficiencia y eficacia en el proceso de prueba de software y ayudar a tomar mejores decisiones para procesos de prueba adicionales al proporcionar datos confiables sobre el proceso de prueba.
Una métrica expresa, en términos cuantitativos, el grado en que un sistema, un componente o un proceso posee un atributo determinado. Un ejemplo sencillo sería comparar el consumo real semanal de combustible de un automóvil con la cifra que indica el fabricante.
Métricas de prueba de software: mejora la eficiencia y eficacia de un proceso de prueba de software.
Las métricas de prueba de software o medición de prueba de software son la indicación cuantitativa de la extensión, capacidad, dimensión, cantidad o tamaño de algún atributo de un proceso o producto.
Ejemplo de medición de prueba de software: Número total de defectos
¿Por qué son importantes las métricas de las pruebas?
“No podemos mejorar lo que no podemos medir”. Las métricas de prueba existen para que el proceso de prueba sea medible.
- Decidir cuál debería ser la siguiente fase de actividades.
- Proporcionar evidencia para una afirmación o predicción sobre la calidad.
- Identificar qué tipo de mejora se requiere
- Justificar un cambio de proceso o de tecnología.
Leer más sobre su Importancia de las métricas de prueba
Tipos de métricas de prueba
- Métricas del proceso: Se puede utilizar para mejorar la eficiencia del proceso del SDLC (Ciclo de vida del desarrollo de programas)
- Métricas del producto: Se trata de la calidad del producto de software.
-
Métricas del proyecto: Se puede utilizar para medir la eficiencia de un equipo de proyecto o cualquier herramientas de prueba siendo utilizado por los miembros del equipo
Elegir las métricas adecuadas es más importante que recopilar muchas de ellas. Considere lo siguiente antes de decidirse por un conjunto:
- Fijar el público objetivo para la preparación de métricas.
- Definir el objetivo de las métricas
- Introducir todas las métricas relevantes basadas en las necesidades del proyecto.
- Analice el costo y el beneficio de cada métrica, y la fase del ciclo de vida del proyecto en la que aporta mayor valor.
Métricas de prueba manuales
In Ingeniería de SoftwareLas métricas de prueba manuales se clasifican en dos clases.
- Métricas base
- Métricas calculadas
Las métricas base son los datos sin procesar recopilados por Test Analyst durante el desarrollo y ejecución del caso de prueba (# de casos de prueba ejecutados, # de casos de prueba). Mientras que las métricas calculadas se derivan de los datos recopilados en las métricas base. El administrador de pruebas generalmente sigue las métricas calculadas para fines de informes de pruebas (% completado, % cobertura de prueba).
Dependiendo del proyecto o modelo de negocio, las métricas más importantes suelen ser:
- Métricas de productividad de ejecución de casos de prueba
- Métricas de productividad de preparación de casos de prueba
- Métricas de defectos
- Defectos por prioridad
- Defectos por gravedad
- Relación de deslizamiento de defectos
Métricas de pruebas manuales frente a automatizadas
Las métricas descritas anteriormente presuponen una ejecución manual del conjunto de pruebas. Una ejecución automatizada se mide de forma diferente, ya que el esfuerzo de ejecución deja de ser un factor limitante.
| Criterios | Métricas de pruebas manuales | Métricas de pruebas de automatización |
|---|---|---|
| Enfoque primario | Progreso en el esfuerzo y la ejecución | Cobertura, estabilidad y tiempo de ejecución |
| Medida típica | Casos de prueba ejecutados por día | Porcentaje de cobertura de automatización |
| Señal de calidad | Defectos encontrados por hora de prueba | Tasa de pruebas inestables, proporción de pruebas inestables |
| Medida de costos | Horas de prueba | Horas de mantenimiento del script por lanzamiento |
| Medición de velocidad | Duración del ciclo en días | Tiempo de ejecución de la suite en minutos |
Automation Coverage = (Test cases automated / Total test cases) x 100 Flaky Test Rate = (Tests with inconsistent results / Total automated tests) x 100
La tasa de pruebas inestables merece especial atención. Una vez que supera aproximadamente el 5 por ciento, los equipos comienzan a ignorar las compilaciones rojas, y en ese momento el conjunto de pruebas deja de proporcionar información, independientemente de su nivel de cobertura.
Ciclo de vida de métricas de prueba en ingeniería de software
| Diferentes etapas del ciclo de vida de las métricas | Pasos durante cada etapa |
|---|---|
| Análisis |
|
| Comunicar |
|
| Evaluación |
|
| Reportes |
|
Cómo calcular una métrica de prueba
| Sr # | Pasos para probar métricas | Ejemplo |
|---|---|---|
| 1 | identificar la clave pruebas de software procesos a medir | Progreso de las pruebas tracproceso rey |
| 2 | En este paso, el evaluador utiliza los datos como base para definir las métricas. | El número de casos de prueba que se planea ejecutar por día. |
| 3 | Determinación de la información a seguir, una frecuencia de tracrey y la persona responsable | El administrador de pruebas capturará la ejecución de prueba real por día al final del día. |
| 4 | Cálculo, gestión e interpretación eficaz de las métricas definidas. | Los casos de prueba reales ejecutados por día. |
| 5 | Identificar las áreas de mejora en función de la interpretación de métricas definidas | If caso de prueba Si la ejecución no alcanza el objetivo acordado, investigue la causa y proponga medidas correctivas. |
Ejemplo de cálculo de una métrica de prueba
Tomemos como ejemplo el porcentaje de casos de prueba ejecutados. Para expresar el estado de ejecución como un porcentaje, utilice la fórmula:
Percentage test cases executed= (No of test cases executed/ Total no of test cases written) X 100
Si se escribieron 250 casos de prueba y se ejecutaron 175, el resultado es (175 / 250) x 100 = el 70 por ciento.
El mismo patrón se aplica a todos los demás parámetros de ejecución: casos de prueba no ejecutados, superados, fallidos y bloqueados. Cada uno es simplemente un numerador diferente sobre el mismo denominador.
Métricas de prueba más importantes para Track
El glosario al final de este tutorial enumera todas las fórmulas de uso común. En la práctica, un informe rara vez necesita más de ocho. Estas son las que influyen sistemáticamente en la toma de decisiones.
| Métrico | A qué responde | Cuidado con |
|---|---|---|
| Porcentaje de ejecución de casos de prueba | ¿En qué punto de la carrera prevista nos encontramos? | No dice nada sobre la calidad, solo sobre el progreso. |
| Densidad de defectos | Defectos por unidad de tamaño, entonces, ¿qué módulo es el más débil? | Depende de una medida de tamaño consistente. |
| Eficiencia de eliminación de defectos | ¿Qué porcentaje de defectos detectamos antes del lanzamiento? | Solo se podrá finalizar una vez que lleguen los datos de producción. |
| Fuga defectuosa | ¿Cuántos defectos llegaron al cliente? | La señal de calidad más importante |
| Cobertura de prueba | ¿Qué porcentaje del conjunto de requisitos se cumple? | Una amplia cobertura con afirmaciones débiles no prueba nada. |
| Índice de gravedad del defecto | ¿Los defectos visibles son graves o meramente estéticos? | Contar los defectos sin ponderarlos induce a error. |
| Tiempo medio de reparación | ¿Con qué rapidez soluciona el problema el equipo? | Desviado por algunos defectos de larga duración |
| Productividad en la ejecución de pruebas | ¿Cuántos casos completa un evaluador al día? | Fomenta pruebas superficiales si se utiliza como objetivo. |
Dos fórmulas que vale la pena añadir al glosario porque son las que solicita la dirección:
Defect Removal Efficiency = (Defects found before release / Total defects found) x 100
Defect Leakage = (Defects found in production / Defects found before release) x 100
La trampa de medición. Cualquier métrica utilizada como objetivo deja de ser una buena medida. Si se establece un objetivo de productividad de 30 casos de prueba al día, los evaluadores escribirán 30 casos triviales. Informe las métricas en conjunto, nunca de forma aislada, y asocie cada cifra de productividad con una cifra de calidad.
Glosario de fórmulas de métricas de pruebas de software
- Relación de esfuerzo de retrabajo = (Esfuerzos de retrabajo reales invertidos en esa fase/esfuerzos reales totales invertidos en esa fase) X 100
- Avance de requisitos = (Número total de requisitos agregados/Número de requisitos iniciales)X100
- Variación del horario = (Fecha de entrega real – Fecha de entrega planificada)
- Costo de encontrar un defecto en las pruebas = (Esfuerzo total invertido en las pruebas/defectos encontrados en las pruebas)
- Deslizamiento del horario = (Fecha de finalización real – Fecha de finalización estimada) / (Fecha de finalización prevista – Fecha de inicio prevista) X 100
- Porcentaje de casos de prueba aprobados = (Número de Pruebas Pasadas/Número total de pruebas ejecutadas) X 100
- Porcentaje de casos de prueba fallidos = (Número de pruebas fallidas/Número total de pruebas ejecutadas) X 100
- Porcentaje de casos de prueba bloqueados = (Número de Pruebas Bloqueadas/Número total de pruebas ejecutadas) X 100
- Porcentaje de defectos fijos = (Defectos arreglados/Defectos reportados) X 100
- Porcentaje de defectos aceptados = (Defectos aceptados como válidos por el equipo de desarrollo/Total de defectos reportados) X 100
- Porcentaje diferido de defectos = (Defectos diferidos para versiones futuras /Total de defectos reportados) X 100
- Porcentaje de defectos críticos = (Defectos críticos / Total de defectos reportados) X 100
- Tiempo promedio para que un equipo de desarrollo repare los defectos = (Tiempo total necesario para corregir errores/Número de errores)
- Número de pruebas ejecutadas por período de tiempo = Número de pruebas ejecutadas/Tiempo total
- Eficiencia del diseño de pruebas = Número de pruebas diseñadas /Tiempo total
- Eficiencia de la revisión de pruebas = Número de pruebas revisadas /Tiempo total
- Tasa de detección de erroreso defectos por hora de prueba = Número total de defectos / Número total de horas de prueba
