10/10/2015 Conceitos: Principais Medidas de Teste

 Disciplinas >   Teste >   Conceitos >  Principais Medidas de Teste

Conceitos:  Principais Medidas de Teste
Introdução
Medidas de Cobertura
Cobertura de Teste Baseada em Requisitos
Cobertura de Teste Baseada em Códigos
Medição da Qualidade Percebida
Relatórios de Defeitos
Densidade de Defeitos
Tempo de Permanência de Defeitos
Tendência a Defeitos
Medidas de Desempenho
Monitoramento Dinâmico
Tempo de Resposta / Taxa de Transferência
Relatórios de Percentil
Relatórios de Comparação
Relatórios de Rastreamento e Perfil

Introdução 
As principais medidas de um teste incluem a cobertura e a qualidade.

A cobertura é a medida da abrangência do teste e é expressa pela cobertura dos requisitos e
casos de teste ou pela cobertura do código executado.

A qualidade é uma medida de confiabilidade, de estabilidade e de desempenho do objetivo do
teste (sistema ou aplicativo em teste). Ela se baseia na avaliação dos resultados do teste e na
análise das solicitações de mudança (defeitos) identificadas durante o teste.

Medidas de Cobertura 

As métricas de cobertura fornecem respostas à pergunta "Qual é a abrangência do teste?". As
medidas de cobertura usadas com mais freqüência são a cobertura de teste baseada em
requisitos e em códigos. Em resumo, a cobertura de teste é qualquer medida de abrangência
relacionada a um requisito (baseada em requisitos) ou a um critério de design/implementação
do código (baseada em códigos), como a verificação de casos de uso (baseada em requisitos)
ou a execução de todas as linhas de código (baseada em códigos).

Qualquer atividade sistemática de teste baseia­se em, pelo menos, uma estratégia de cobertura.
Essa estratégia orienta o design de casos de teste declarando a finalidade geral do teste. A
declaração da estratégia de cobertura pode ser tão simples quanto verificar todo o desempenho.

Se os requisitos estiverem completamente catalogados, uma estratégia de cobertura baseada em
requisitos poderá ser suficiente para produzir uma medida quantificável para testar a
abrangência. Por exemplo, se todos os requisitos do teste de desempenho foram identificados, é
possível fazer referência aos resultados do teste para obter medidas, como 75% dos requisitos
do teste de desempenho foram verificados.

Se a cobertura baseada em códigos for aplicada, as estratégias de teste serão formuladas em
termos da quantidade do código­fonte que foi executada pelos testes. Esse tipo de estratégia de
cobertura de teste é muito importante para sistemas de segurança crítica.

http://www.wthreex.com/rup/process/workflow/test/co_keyme.htm#Trace and Profile Reports 1/10
10/10/2015 Conceitos: Principais Medidas de Teste

Ambas as medidas podem ser obtidas manualmente (as equações são mostradas a seguir) ou
podem ser calculadas por ferramentas de automatização de testes.

Cobertura de Teste Baseada em Requisitos 

A cobertura de teste baseada em requisitos é medida diversas vezes durante o ciclo de vida do
teste e fornece a identificação da cobertura do teste em um marco desse ciclo (como a
cobertura de testes planejados, implementados, executados e bem­sucedidos).

A cobertura de teste é calculada pela seguinte equação:
(p,i,x,s)
Cobertura de Teste = T  / RfT

onde:
T é o número de Testes (planejados, implementados,
executados ou bem­sucedidos) expressos como
procedimentos ou casos de teste.

RfT é o número total de Requisitos do Teste.

Na atividade Planejar Teste, a cobertura de teste é calculada para determinar a
cobertura dos testes planejados e o cálculo é efetuado da seguinte maneira:
p
Cobertura dos Testes (planejados) = T  / RfT

onde:
p
T  é o número de Testes planejados expressos como
procedimentos ou casos de teste.

RfT é o número total de Requisitos do Teste.

Na atividade Implementar Teste, à medida que os procedimentos de teste são
implementados (como scripts de teste), a cobertura de teste é calculada usando a
seguinte equação:
i
Cobertura dos Testes (implementados) = T  / RfT

onde:
i
T  é o número de Testes implementados conforme expresso
pela quantidade de procedimentos ou casos de teste para os
quais existem scripts correspondentes.

RfT é o número total de Requisitos do Teste.

Na atividade Executar Teste, são usadas duas medidas de cobertura. Uma delas
identifica a cobertura obtida com a execução dos testes. A outra identifica a cobertura
dos testes bem­sucedidos (aqueles que foram executados sem falhas, como defeitos
ou resultados inesperados).

Essas medidas de cobertura são calculadas pelas seguintes equações:
x
Cobertura dos Testes (executados) = T  / RfT

http://www.wthreex.com/rup/process/workflow/test/co_keyme.htm#Trace and Profile Reports 2/10
10/10/2015 Conceitos: Principais Medidas de Teste

onde:
x
T  é o número de Testes executados expressos como
procedimentos ou casos de teste.

RfT é o número total de Requisitos do Teste.

 
s
Cobertura dos testes bem­sucedidos (executados) = T  /
RfT

onde:
s
T  é o número de Testes executados expressos como
procedimentos ou casos de teste que foram concluídos com
êxito e sem defeitos.

RfT é o número total de Requisitos do Teste.

A transformação das relações anteriores em porcentagens permite a seguinte declaração sobre a
cobertura de teste baseada em requisitos:
(p,i,x,s)
x% dos casos de teste (T  nas equações anteriores) obtiveram uma taxa de
êxito de y%

Essa é uma declaração importante de cobertura de teste que pode ser comparada a critérios de
êxito definidos. Se os critérios não forem atingidos, a declaração fornecerá uma base para
prever a quantidade de esforço de teste restante.

Cobertura de Teste Baseada em Códigos 

A cobertura de teste baseada em códigos mede a quantidade de códigos executada durante o
teste, em comparação com a quantidade de códigos com execução pendente. Essa cobertura
pode se basear em fluxos de controle (instrução, ramificação ou caminhos) ou fluxos de dados.
Na cobertura baseada em fluxo de controle, o objetivo é testar linhas de código, condições de
ramificação, caminhos que percorrem o código ou outros elementos do fluxo de controle do
software. Na cobertura baseada em fluxo de dados, o objetivo é testar se os estados dos dados
permanecem válidos durante a operação do software, por exemplo, se um elemento de dados é
definido antes de ser usado.

A cobertura de teste baseada em códigos é calculada pela seguinte equação:
e
Cobertura de Teste = I  / TIic

onde:
e
I  é o número de itens executados expressos como instruções de código,
ramificações de código, caminhos de código, pontos de decisão do
estado de dados ou nomes de elementos de dados.

TIic é o número total de itens no código.

http://www.wthreex.com/rup/process/workflow/test/co_keyme.htm#Trace and Profile Reports 3/10
10/10/2015 Conceitos: Principais Medidas de Teste

A transformação dessa relação em uma porcentagem permite a seguinte declaração sobre a
cobertura de teste baseada em códigos:

x% dos casos de teste (I na equação anterior) obtiveram uma taxa de êxito de y%

Essa é uma declaração importante de cobertura de teste que pode ser comparada a critérios de
êxito definidos. Se os critérios não forem atingidos, a declaração fornecerá uma base para
prever a quantidade de esforço de teste restante.

Medição da Qualidade Percebida 
Enquanto a avaliação da cobertura fornece a medida para testar a conclusão, uma avaliação dos
defeitos encontrados durante os testes fornece a melhor indicação da qualidade do software.
Qualidade é a indicação do grau em que o software satisfaz aos requisitos. Assim, nesse
contexto, os defeitos são identificados como um tipo de solicitação de mudança na qual o
objetivo do teste não satisfez aos requisitos.

A avaliação de defeitos pode se basear em métodos que variam de simples contagens à
modelagem estatística rigorosa.

A avaliação rigorosa utiliza suposições sobre as taxas de detecção ou recebimento de defeitos
durante o processo de teste. Um modelo comum pressupõe que a taxa segue uma distribuição
Poisson. Os dados reais sobre taxas de defeitos são ajustados ao modelo. A avaliação resultante
estima a confiabilidade do software atual e prevê como ela crescerá se os testes e a eliminação
de defeitos continuarem. Essa avaliação é descrita como modelagem do crescimento da
confiabilidade do software e é um campo de estudo ativo. Devido à ausência de suporte a
ferramentas desse tipo de avaliação, pondere com cuidado o custo para realizá­la em relação ao
valor que ela agrega.

A análise de defeitos significa examinar a distribuição de defeitos nos valores de um ou mais
parâmetros associados a um defeito. Essa análise fornece uma indicação da confiabilidade do
software.

Na análise de defeitos, existem quatro parâmetros principais que são geralmente usados:

Status ­ o estado atual do defeito (em aberto, em reparo, concluído, etc.).
Prioridade ­ a importância relativa do defeito a ser relatado e solucionado.
Gravidade ­ o impacto relativo do defeito. O impacto para o usuário final, uma
organização, terceiros etc.
Origem ­ onde está e qual é a falha original que está causando o defeito ou o
componente que será corrigido para eliminá­lo.

É possível relatar contagens de defeitos como uma função de tempo criando um relatório ou
diagrama de Tendência de Defeitos e como uma função de um ou mais parâmetros de defeito,
como gravidade ou status, em um relatório de Densidade de Defeitos. Esses tipos de análise
fornecem uma perspectiva das tendências ou da distribuição de defeitos que revelam a
confiabilidade do software.

Por exemplo, espera­se que as taxas de detecção de defeitos diminuam à medida que os testes e
as correções avançam. É possível estabelecer um limite até onde o software será implantado.
Você também pode reportar contagens de defeitos com base na origem do modelo de
implementação. Isso permite a detecção de módulos precários e pontos críticos, partes do
software que sofrem reparos constantes e indicam uma falha mais essencial de design.

http://www.wthreex.com/rup/process/workflow/test/co_keyme.htm#Trace and Profile Reports 4/10
10/10/2015 Conceitos: Principais Medidas de Teste

Os defeitos incluídos em uma análise desse tipo precisam estar confirmados. Nem todos os
defeitos relatados apresentam uma falha real. Alguns podem ser solicitações de melhoria, estar
fora do escopo do projeto ou descrever um defeito já relatado. No entanto, convém observar e
analisar o motivo pelo qual há tantos defeitos relatados que estão repetidos ou ainda não foram
confirmados.

Relatórios de Defeitos 

O Rational Unified Process® recomenda a avaliação de defeitos com base em três categorias de
relatórios:

Os relatórios de distribuição de defeitos (densidade) permitem que as contagens de
defeitos sejam mostradas como uma função de um ou mais parâmetros de defeitos.
Os relatórios de tempo de permanência de defeitos são um tipo especial de relatório
de distribuição de defeitos. Eles mostram o tempo de permanência de um defeito em
determinado estado, como Em aberto. Em qualquer categoria de tempo de
permanência, também é possível classificar defeitos por outro atributo, como
Proprietário.
Os relatórios de tendência de defeitos mostram contagens de defeitos, por status
(novo, em aberto ou concluído), como uma função de tempo. Eles podem ser
cumulativos ou não.
Os relatórios de resultados e progresso de teste mostram os resultados da execução
dos procedimentos de teste em diversas iterações e ciclos de teste para o aplicativo
que está sendo testado.

Muitos desses relatórios são valiosos para a avaliação da qualidade do software. Os critérios de
teste comuns incluem uma instrução sobre a quantidade permitida de defeitos em aberto em
determinadas categorias, como classe de gravidade. Esses critérios são verificados facilmente
com uma avaliação de distribuição de defeitos. Com a filtragem ou a classificação de requisitos
de teste, é possível concentrar essa avaliação em conjuntos distintos de requisitos.

Normalmente, a geração eficaz de relatórios desse tipo requer suporte a ferramentas.

Relatórios de Densidade de Defeitos 

Status Versus Prioridade do Defeito

É necessário atribuir uma prioridade a cada defeito. Em geral, convém haver quatro níveis de
prioridade:

1.  Resolver imediatamente
2.  Prioridade alta
3.  Fila normal
4.  Prioridade baixa

Os critérios de um teste bem­sucedido podem ser expressos em termos da forma como deverá
ser feita a distribuição de defeitos nesses níveis de prioridade. Por exemplo, para um teste bem­
sucedido, os critérios podem estabelecer a inexistência de defeitos de Prioridade 1 e menos de
cinco defeitos de Prioridade 2 em aberto. Um diagrama de distribuição de defeitos como este
deverá ser gerado:

http://www.wthreex.com/rup/process/workflow/test/co_keyme.htm#Trace and Profile Reports 5/10
10/10/2015 Conceitos: Principais Medidas de Teste

Está claro que os critérios não foram satisfeitos. Observe que esse diagrama precisa incluir um
filtro para mostrar apenas os defeitos em aberto, conforme exigido pelos critérios do teste.

Status Versus Gravidade do Defeito

Os relatórios de gravidade de defeitos mostram a quantidade de defeitos existentes em cada
classe de gravidade (por exemplo: erro fatal, função importante não executada, problema
secundário).

Status Versus Local do Defeito no Modelo de Implementação

Os relatórios de origem de defeitos mostram a distribuição de defeitos em elementos no
modelo de implementação.

Relatórios de Tempo de Permanência de Defeitos 

As análises de tempo de permanência de defeitos fornecem um ótimo feedback sobre a eficácia
dos testes e das atividades de eliminação de defeitos. Por exemplo, se grande parte dos defeitos
antigos e não resolvidos está em um estado de validação pendente, isso provavelmente
significa que não estão sendo empregados recursos suficientes no esforço de reaplicação dos
testes.

Relatórios de Tendências de Defeitos 

Os relatórios de tendências identificam as taxas de defeitos e fornecem uma visão nítida do
estado do teste. As tendências de defeitos seguem um padrão bastante previsível em um ciclo
de teste. No início do ciclo, as taxas de defeitos aumentam rapidamente. Depois, atingem um
pico e caem em um ritmo mais lento com o tempo.

http://www.wthreex.com/rup/process/workflow/test/co_keyme.htm#Trace and Profile Reports 6/10
10/10/2015 Conceitos: Principais Medidas de Teste

Para localizar problemas, é possível revisar o cronograma do projeto considerando essa
tendência. Por exemplo, se as taxas de defeitos ainda estão aumentando na terceira semana de
um ciclo de teste de quatro semanas, o projeto está claramente atrasado.

Essa simples análise de tendência pressupõe que os defeitos estejam sendo corrigidos
imediatamente e as correções estejam sendo testadas nos builds subseqüentes, de modo que a
taxa de conclusão de defeitos siga o mesmo perfil da taxa de detecção de defeitos. Quando isso
não acontece, há um problema no processo de resolução de defeitos; talvez os recursos de
correção de defeitos ou os recursos para reaplicar testes e validar correções estejam
inadequados.

A tendência refletida nesse relatório mostra que novos defeitos são descobertos e abertos
rapidamente no início do projeto e diminuem com o tempo. A tendência de defeitos em aberto
é semelhante à de novos defeitos, mas fica um pouco atrás. A tendência de defeitos concluídos
aumenta com o tempo à medida que defeitos em aberto são corrigidos e verificados. Essas
tendências mostram um esforço bem­sucedido.

Se as suas tendências forem muito diferentes dessas, poderão indicar um problema e identificar
quando será necessário aplicar recursos adicionais em áreas específicas do desenvolvimento ou
de testes.

Quando combinadas com as medidas de cobertura de teste, as análises de defeitos fornecem
uma avaliação muito eficaz na qual os critérios de conclusão de teste poderão se basear.

Medidas de Desempenho 
Diversas medidas são usadas para avaliar os comportamentos do desempenho do objetivo do
http://www.wthreex.com/rup/process/workflow/test/co_keyme.htm#Trace and Profile Reports 7/10
10/10/2015 Conceitos: Principais Medidas de Teste

teste e se concentram na coleta de dados relacionados a comportamentos, como tempo de
resposta, perfis de andamento, fluxo de execução, confiabilidade operacional e limites. Essas
medidas são avaliadas principalmente na atividade Avaliar Teste. No entanto, existem medidas
de desempenho que são usadas durante a atividade Executar Teste para avaliar o progresso e o
status do teste.

As principais medidas de desempenho incluem:

Monitoramento dinâmico ­ captação e exibição em tempo real do status e do estado
de cada script de teste que está sendo executado durante a realização do teste.
Tempo de Resposta/Produtividade ­ medida dos tempos de resposta ou resultado do
objetivo do teste para atores especificados e/ou casos de uso.
Relatórios de Percentil ­ medida/cálculo do percentil dos valores coletados de dados.
Relatórios de Comparação ­ diferenças ou tendências entre dois (ou mais) conjuntos
de dados que representam execuções de teste distintas.
Relatórios de Rastreamento ­ detalhes das mensagens/conversas entre o ator (script
de teste) e o objetivo do teste.

Monitoramento Dinâmico 

O monitoramento dinâmico permite a exibição/geração de relatórios em tempo real, geralmente
na forma de um histograma ou gráfico. Os relatórios são usados para monitorar ou avaliar em
tempo real a execução do teste de desempenho exibindo o estado, o status e o progresso atual
dos scripts de teste que estão sendo executados.

Por exemplo, no histograma anterior, há 80 scripts de teste executando o mesmo caso de uso.
Nessa exibição, 14 scripts de teste estão no estado Ocioso, 12 no estado Consulta, 34 em
Execução SQL, 4 em Conexão com SQL e 16 em Outros. À medida que o teste avança, espera­
se que o número de scripts em cada estado seja alterado. O resultado exibido é típico de uma
execução de teste normal que está na metade. No entanto, se durante a execução do teste os
scripts permanecerem em um estado ou não forem alterados, talvez haja um problema nessa
execução ou seja preciso implementar ou avaliar outras medidas de desempenho.

Relatórios de Tempo de Resposta/Produtividade 
http://www.wthreex.com/rup/process/workflow/test/co_keyme.htm#Trace and Profile Reports 8/10
10/10/2015 Conceitos: Principais Medidas de Teste

Os relatórios de Tempo de Resposta/Produtividade, como o próprio nome indica, medem e
calculam os comportamentos de desempenho relacionados ao tempo e/ou
produtividade(número de transações processadas). Em geral, são exibidos como um gráfico
com o tempo de resposta (ou o número de transações) no eixo "y" e os eventos no eixo "x".

Além de mostrar os comportamentos reais do desempenho, convém geralmente calcular e
exibir informações estatísticas, como o desvio médio e padrão dos valores de dados.

Relatórios de Percentil 

Os relatórios de percentil fornecem outro cálculo estatístico do desempenho exibindo valores
do percentil de preenchimento para os tipos de dados coletados.

Relatórios de Comparação 
http://www.wthreex.com/rup/process/workflow/test/co_keyme.htm#Trace and Profile Reports 9/10
10/10/2015 Conceitos: Principais Medidas de Teste

Convém comparar os resultados de uma execução de teste de desempenho com os de outra
execução para avaliar o impacto das mudanças efetuadas entre as execuções de teste nos
comportamentos de desempenho. Use os relatórios de comparação para exibir a diferença entre
dois conjuntos de dados (cada um representando execuções de teste distintas) ou tendências
entre muitas execuções de teste.

Relatórios de Rastreamento e Perfil 

Quando os comportamentos de desempenho são aceitáveis ou o monitoramento do desempenho
indica os possíveis gargalos (por exemplo, quando os scripts de teste permanecem em
determinado estado por períodos longos demais), os relatórios de rastreamento podem ser os
mais valiosos. Os relatórios de Rastreamento e Perfil exibem informações de nível inferior.
Essas informações incluem as mensagens entre o ator e o objetivo do teste, o fluxo de
execução, o acesso a dados, bem como as chamadas de função e do sistema.

Copyright  © 1987 ­ 2001 Rational Software Corporation
Rational Unified Process   

http://www.wthreex.com/rup/process/workflow/test/co_keyme.htm#Trace and Profile Reports 10/10