O que é densidade de defeito? Fórmula para calcular com exemplo
Thomas Hamilton
⚡ Resumo Inteligente
A Densidade de Defeitos mede o número de defeitos confirmados em um módulo de software dividido pelo tamanho desse módulo, geralmente expresso por mil linhas de código, e indica se uma versão está pronta para ser lançada.
O que é densidade de defeito?
Densidade do defeito É o número de defeitos confirmados em um software ou módulo durante um período específico de operação ou desenvolvimento, dividido pelo tamanho desse software ou módulo. Ele permite que uma equipe decida se um software está pronto para ser lançado.
A densidade de defeitos é calculada por mil linhas de código, também conhecida como KLOC. Como a contagem é normalizada pelo tamanho, um módulo grande com muitos defeitos e um módulo pequeno com poucos defeitos podem ser comparados na mesma escala, algo que uma contagem bruta de bugs jamais permitiria.
A métrica é normalmente relatada ao final de um ciclo de testes e traclançamento sobre lançamento, então fica ao lado do resto do processo de gerenciamento de defeitos no ciclo de vida de teste de software.
Como calcular a densidade de defeitos
Uma fórmula para medir a densidade do defeito:
Defect Density = Defect count/size of the release
O tamanho de uma versão pode ser medido em termos de linhas de código (LOC).
Três detalhes determinam se o número resultante tem algum significado:
- A unidade de medida. LOC e KLOC são as unidades mais comuns. Pontos de função são usados quando as equipes desejam uma medida de tamanho que não mude com a linguagem de programação, e algumas equipes normalizam por módulo ou por componente.
- O que é considerado um defeito? Apenas defeitos confirmados devem ser incluídos no numerador. Duplicatas, relatórios rejeitados e solicitações de melhoria devem ser excluídos, caso contrário, o número infla sem qualquer alteração na qualidade do código.
- A janela de medição. Defeitos encontrados durante os testes do sistema, durante teste de regressão, e após o lançamento descrevem coisas diferentes, portanto o período deve ser indicado com o número.
Exemplo de densidade de defeito
Suponha que você tenha 3 módulos integrados ao seu produto de software. Cada módulo apresenta o seguinte número de bugs detectados:
- Módulo 1 = 10 bugs
- Módulo 2 = 20 bugs
- Módulo 3 = 10 bugs
Total de bugs = 10 + 20 + 10 = 40
O número total de linhas de código para cada módulo é:
- Módulo 1 = 1000 LOC
- Módulo 2 = 1500 LOC
- Módulo 3 = 500 LOC
Linha total de Code = 1000+1500+500 = 3000
A densidade do defeito é calculada como:
Defect Density = 40/3000 = 0.013333 defects/loc = 13.333 defects/Kloc
O mesmo cálculo aplicado a cada módulo é mais útil do que o valor combinado, como mostra o gráfico abaixo: o Módulo 2 apresenta 20 defeitos em 1500 linhas de código, enquanto o Módulo 3 apresenta 10 defeitos em apenas 500 linhas de código. Portanto, o Módulo 3 é o mais denso e arriscado dos dois, mesmo tendo relatado menos erros.
Um padrão para densidade de defeitos
Não existe um padrão fixo para a densidade de defeitos. Estudos sugerem que um defeito Geralmente, considera-se que um número de linhas de código por mil é um sinal de boa qualidade de projeto, e esse valor é a regra prática mais citada no setor.
A expectativa varia conforme o domínio. Softwares críticos para a segurança e regulamentados, como aviônicos e dispositivos médicos, devem atingir uma meta bem abaixo de um defeito por KLOC (mil linhas de código), enquanto aplicativos comerciais comuns geralmente ficam acima desse limite. Como as regras de contagem, as unidades de medida e a profundidade dos testes diferem entre as organizações, um benchmark obtido de um estudo publicado só é comparável a um projeto que utiliza as mesmas métricas. O uso prático da métrica, portanto, é interno: comparar uma versão com a versão anterior do mesmo produto, utilizando as mesmas métricas.
Fatores que afetam a densidade de defeitos
A mesma base de código pode produzir valores de densidade de defeitos muito diferentes, dependendo dos seguintes fatores:
- Code complexidade. Lógica profundamente aninhada e alta complexidade ciclomática Produzem mais defeitos por linha do que código direto.
- O tipo de defeitos levados em consideração. Considerando apenas defeitos funcionais ou incluindo usabilidade, documentação e não funcional resultados, altera substancialmente o numerador.
- O período de tempo considerado. Um valor medido ao longo de um ciclo de testes de duas semanas não é comparável a um valor medido ao longo de seis meses de uso em produção.
- Habilidades de desenvolvedor e testador. Desenvolvedores experientes inserem menos defeitos, e testadores experientes encontram mais defeitos existentes, portanto, os dois efeitos puxam a métrica em direções opostas.
- Cobertura de testes. Defeitos que nunca foram procurados nunca são contabilizados, portanto cobertura de teste limita silenciosamente o quanto a densidade medida pode ser atingida.
Densidade de defeitos versus outras métricas de defeitos
A Densidade de Defeitos responde a uma pergunta: quão concentrados estão os defeitos conhecidos? Três métricas complementares respondem às perguntas que ela não responde, e a maioria das equipes as reporta em conjunto.
| métrico | O que mede | Pergunta que responde |
| Densidade do defeito | Defeitos confirmados divididos por tamanho (KLOC ou pontos de função) | Quais módulos apresentam o maior número de defeitos em relação ao seu tamanho? |
| Vazamento por defeito | Defeitos encontrados após o lançamento, em relação ao total de defeitos. | Quanto do que escapou ao processo de teste chegou aos usuários? |
| Eficiência na remoção de defeitos | Defeitos removidos antes do lançamento, representando uma parcela de todos os defeitos. | Quão eficazes foram os testes na detecção de defeitos a tempo? |
| Índice de Gravidade do Defeito | Os defeitos são ponderados pela gravidade, em vez de serem contabilizados igualmente. | Quão prejudiciais são os defeitos, e não apenas quantos são? |
Lidos em conjunto, os quatro elementos oferecem um panorama mais completo: uma baixa densidade de defeitos com alta taxa de vazamento de defeitos aponta para testes superficiais em vez de código limpo, que é exatamente a interpretação errônea sobre a qual a próxima seção alerta.
Vantagens da densidade de defeitos
A seguir, as vantagens da Densidade de Defeitos:
- Isso ajuda a medir a eficácia dos testes.
- Isso ajuda a diferenciar a concentração de defeitos entre componentes e módulos de software.
- É útil para identificar as áreas que precisam de correção ou melhoria.
- É útil para identificar componentes de alto risco, o que alimenta diretamente a teste baseado em risco.
- Isso ajuda a identificar as necessidades de treinamento de diversos recursos.
- Pode ser útil para estimar o esforço de teste e retrabalho causado por defeitos.
- Ele pode estimar os defeitos restantes no software.
- Antes do lançamento, isso ajuda a determinar se os testes realizados até o momento são suficientes.
- Isso cria uma base histórica que serve de referência para versões posteriores.
Limitações da densidade de defeitos
A métrica é fácil de calcular e fácil de interpretar erroneamente. As seguintes limitações determinam o peso que ela merece em uma decisão de lançamento:
- Defeitos não detectados são invisíveis. O numerador inclui apenas os defeitos que os testes de fato encontraram, portanto, um módulo com testes deficientes apresenta um número enganoso.
- A gravidade é ignorada. Um defeito que corrompe um pagamento e um problema de alinhamento cosmético contam da mesma forma, razão pela qual é necessária uma visão ponderada pela gravidade em conjunto com eles.
- As definições de defeito variam. Duas equipes que utilizam métodos de contagem diferentes produzem números que não podem ser comparados, mesmo dentro da mesma organização.
- O número de linhas de código é um indicador de tamanho pouco preciso. Código verboso diminui a densidade sem trazer benefícios, e a unidade não é comparável entre diferentes linguagens de programação.
- Essa métrica pode ser manipulada. Rejeitar relatórios limítrofes ou inflar a contagem de linhas melhora o número sem melhorar o produto.
Nada disso torna a Densidade de Defeitos inútil. Isso a transforma em um indicador de tendência para um produto específico, medido de forma consistente, em vez de uma pontuação para comparar equipes entre si.
Como reduzir a densidade de defeitos
Reduzir a densidade de defeitos na prática, e não apenas no papel, significa prevenir defeitos precocemente e encontrar os restantes antes do lançamento. As práticas abaixo são as que se repetem nas diretrizes publicadas:
- Antecipe os testes. Envolver os testadores na fase de requisitos e projeto permite identificar ambiguidades antes que elas se transformem em código, que é onde os defeitos são mais baratos de corrigir.
- RevVisualize o código antes de ele ser mesclado. A revisão por pares detecta erros de lógica, requisitos mal interpretados e falhas de projeto que ninguém mais identificaria. teste de unidade Foi escrito para procurar.
- Automatize o conjunto de testes de regressão. Executando verificações em cada commit através de integração contínua Impede que defeitos antigos retornem enquanto um novo código está sendo escrito.
- Primeiro, escreva os testes. Desenvolvimento orientado a testes obriga que cada comportamento seja especificado antes de ser implementado, e teste de mutação Assim, podemos confirmar se os testes resultantes realmente afirmam algo.
- Utilize análise estática. A verificação automatizada de código identifica desreferências nulas, vazamentos de recursos e pontos críticos de complexidade antes mesmo da execução de um único teste.
- Refatorar os módulos densos. Após a análise de Densidade de Defeitos identificar os componentes mais problemáticos, dividi-los e simplificá-los geralmente reduz tanto a complexidade quanto o número de defeitos.
- Reintroduza os defeitos no processo. A análise da causa raiz em retrospectivas transforma defeitos individuais em correções de processo, em vez de soluções paliativas isoladas.
Traclançamento ked sobre lançamento ao lado técnicas de teste de software Com os dados de cobertura, a Densidade de Defeitos torna-se um sistema de alerta precoce em vez de um boletim escolar.
