Introdução

As principais medidas de um teste incluem a cobertura e a qualidade.

A cobertura é a medida da integralidade do teste e baseia-se na cobertura de teste expressa pela cobertura de requisitos e casos de teste ou pela cobertura do código executado.

A qualidade é uma medida de confiabilidade, estabilidade e desempenho do destino do teste (sistema ou aplicativo em teste). A qualidade baseia-se na avaliação dos resultados do teste e na análise dos controles de mudanças (defeitos) identificados durante o teste.

Medidas de Cobertura

As métricas de cobertura fornecem respostas à pergunta: "O quanto o teste é completo?" As medidas mais comumente utilizadas de cobertura baseiam-se na cobertura dos requisitos de software e do código fonte. Basicamente, a cobertura de teste é qualquer medida de integralidade relacionada a um requisito (baseada em requisitos) ou aos critérios de design e 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 tarefa sistemática de teste baseia-se em, pelo menos, uma estratégia de cobertura de teste. 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.

Uma estratégia de cobertura baseada em requisitos pode ser suficiente para produzir uma medida quantificável de integralidade do teste, se os requisitos forem catalogados por completo. Por exemplo, se todos os requisitos do teste de desempenho foram identificados, é possível fazer referência aos resultados do teste para obter medidas; por exemplo, 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.

Ambas as medidas podem ser obtidas manualmente (utilizando as equações fornecidas nos dois títulos a seguir) ou podem ser calculadas utilizando ferramentas de automatização de testes.

Cobertura de Teste Baseado em Requisitos

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

• A cobertura de teste é calculada utilizando a equação a seguir:

Cobertura de Teste = T^(p,i,x,s) / RfT

Em que:
T é o número de Testes (planejados, implementados, executados ou bem-sucedidos), expresso como procedimentos de teste ou casos de teste.

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

• Na tarefa Planejar Teste, a cobertura de teste é calculada para determinar a cobertura dos testes planejados da seguinte maneira:

Cobertura de Teste (planejado) = T^p / RfT

Em que:
T^p é o número de Testes planejados, expresso como procedimentos de teste ou casos de teste.

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

• Na tarefa Implementar Teste, à medida que os procedimentos de teste são implementados (como scripts de teste), a cobertura de teste é calculada utilizando a equação a seguir:

Cobertura de Teste (implementado) = Tⁱ / RfT

aqui:
Tⁱ é o número de Testes implementados, expresso pelo número de procedimentos de teste ou casos de teste para os quais há scripts de teste correspondentes.

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

• Na tarefa Executar Teste, são utilizadas duas medidas de cobertura de teste, uma delas identifica a cobertura obtida com a execução dos testes e a outra identifica a cobertura dos testes bem-sucedidos (aqueles que foram executados sem defeitos, como falhas ou resultados inesperados).

  Essas medidas de cobertura são calculadas utilizando as equações a seguir:

  Cobertura de Teste (executado) = T^x / RfT

  Em que:
  T^x é o número de Testes executados, expresso como procedimentos de teste ou casos de teste.

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

• 
  
  

Cobertura de Teste Bem-sucedido (executado) = T^s / RfT

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

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

A transformação das proporções mencionadas em porcentagens permite a instrução a seguir sobre a cobertura de teste baseada em requisitos:

x% de casos de teste (T^(p,i,x,s) nas equações acima) foram cobertos com uma taxa de sucesso de y%

Essa instrução significativa de cobertura de teste pode ser comparada com critérios de sucesso 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 Baseado em Código

A cobertura de teste baseada em código mede a quantidade de códigos executada durante o teste, em comparação à quantidade de códigos com execução pendente. A cobertura de código 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 de 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 utilizado.

A cobertura de teste baseada em códigos é calculada pela seguinte equação:

Cobertura de Teste = I^e / TIic

Em que:
I^e é o número de itens executados, expresso 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.

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 instrução significativa de cobertura de teste pode ser comparada com critérios de sucesso 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.

Medindo a Qualidade Observada

Embora a avaliação da cobertura de teste forneça uma medida da extensão da intregralidade do esforço de teste, a avaliação dos defeitos descobertos durante o teste fornece a melhor indicação da qualidade de software tal como foi experienciada. Essa observação da qualidade pode ser utilizada para raciocinar sobre a qualidade geral do sistema de software como um todo. A Qualidade de Software Observada é uma medida do grau em que o software atende aos requisitos determinados a ele, portanto, neste contexto, os defeitos são considerados como um tipo de controle de mudanças em que o destino do teste não atendeu aos requisitos de software.

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

A avaliação rigorosa utiliza suposições sobre as taxas de descoberta 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 de crescimento de confiabilidade do software e é uma área de estudo ativo. Devido à ausência de suporte a ferramentas para este tipo de avaliação, você precisa equilibrar com cuidado o custo de utilização desta abordagem em relação ao valor que ela agrega.

A análise de defeitos envolve a análise da distribuição de defeitos sobre os valores de um ou mais atributos associados a um defeito. Essa análise fornece uma indicação da confiabilidade do software.

Na análise de defeitos, quatro atributos principais de defeitos são normalmente analisados:

• Status - o estado atual do defeito (aberto, em correção, fechado e assim por diante).
• Prioridade - a importância relativa do defeito que está sendo tratado e resolvido.
• Gravidade - o impacto relativo deste defeito para o usuário final, uma organização, terceiros e outros.
• Origem - onde está e qual é a falha original que resulta neste defeito ou qual componente será corrigido para eliminar este defeito.

As contagens de defeitos podem ser relatadas como uma função de tempo, criando um diagrama ou relatório de Tendência a Defeitos. Elas também podem ser relatadas em um Relatório de Densidade de Defeitos como uma função de um ou mais atributos de defeitos, tal como gravidade ou status. Esses tipos de análise fornecem uma perspectiva sobre as tendências ou sobre a distribuição de defeitos que revelam a confiabilidade do software.

Por exemplo, espera-se que as taxas de descoberta de defeitos diminuam eventualmente à medida que o teste e a correção avançam. Um limite de defeito ou de qualidade insatisfatória pode ser estabelecido, em cujo ponto a qualidade do software será inaceitável. As contagens de defeitos também podem ser relatadas com base na origem do modelo de Implementação, permitindo a detecção de "módulos inadequados", pontos ativos e partes do software que sofrem correções constantes e indicam as imperfeições mais fundamentais de design.

Apenas os defeitos confirmados são incluídos em uma análise desse tipo. Nem todos os defeitos relatados indicam uma imperfeição real; alguns podem ser pedidos de aprimoramento fora do escopo do projeto ou podem descrever um defeito já relatado. No entanto, é importante observar e analisar a razão pela qual muitos defeitos, que são duplicatas ou defeitos não confirmados, estão sendo relatados.

Relatórios de Defeitos

O Rational Unified Process recomenda a avaliação de defeitos com base em várias categorias de relatório, conforme a seguir:

• Os Relatórios de Distribuição de Defeitos (Densidade) permitem que as contagens de defeitos sejam mostradas como uma função de um ou dois atributos 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 a Defeitos mostram contagens de defeitos, por status (novo, aberto ou fechado), como uma função de tempo. Eles podem ser cumulativos ou não.

Muitos desses relatórios são valiosos para a avaliação da qualidade do software. Eles são mais úteis quando analisados em conjunto com os resultados do Teste e os relatórios de progresso, que mostram os resultados dos testes conduzidos em várias iterações e ciclos de teste para o aplicativo em teste. Os critérios comuns de teste incluem uma instrução sobre os números toleráveis de defeitos abertos em determinadas categorias, como classe de gravidade, que é facilmente verificada com uma avaliação de distribuição de defeitos. Classificando ou agrupando essa distribuição por motivadores de teste, a avaliação pode ter o foco em importantes áreas de interesse.

Normalmente, o suporte de ferramenta é necessário para produzir com eficácia relatórios desse tipo.

Relatórios de Densidade de Defeitos

Status versus Prioridade de Defeitos

Forneça uma prioridade para cada defeito. Normalmente é prático e suficiente ter quatro níveis de prioridade, tais como:

• Prioridade urgente (resolver imediatamente)
• Alta prioridade
• Prioridade normal
• Baixa prioridade

Nota: Os critérios de um teste bem-sucedido podem ser expressos em termos de como deverá ser feita a distribuição de defeitos nesses níveis de prioridade. Por exemplo, os critérios de teste bem-sucedido poderiam ser "nenhum defeito de Prioridade 1 e menos de cinco defeitos de Prioridade 2 abertos. Um diagrama de distribuição de defeitos, tal como mostrado a seguir, deverá ser gerado.

Está claro que os critérios não foram atendidos. Este diagrama precisa incluir um filtro para mostrar apenas os defeitos abertos, conforme requerido pelos critérios de filtro.

Status versus Gravidade de Defeitos

Os Relatórios de Gravidade de Defeitos mostram a quantidade de defeitos existentes em cada classe de gravidade; por exemplo, erro fatal, função principal não executada, dificuldade secundária.

Status versus Local de Defeitos 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

A Análise de Tempo de Permanência de Defeitos fornece um ótimo feedback sobre a eficácia dos testes e das tarefas de remoção de defeitos. Por exemplo, se grande parte dos defeitos mais antigos e não resolvidos estiver 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 de Defeitos identificam as taxas de defeitos e fornecem uma visão particularmente favorável 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 e, depois, alcançam um máximo e diminuem em uma taxa menor ao longo do tempo.

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 descoberta 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, elas poderão indicar um problema e identificar quando será necessário aplicar recursos adicionais a áreas específicas do desenvolvimento ou de testes.

Quando combinada com as medidas de cobertura de teste, a análise de defeitos fornece uma avaliação muito satisfatória na qual os critérios de conclusão de teste poderão se basear.

Medidas de Desempenho

Várias medidas são utilizadas para avaliar os comportamentos do desempenho do destino do teste e para focalizar a captura de dados relacionados a comportamentos, como tempo de resposta, perfis de sincronização, fluxo de execução, confiabilidade operacional e limites. Essas medidas são avaliadas principalmente na tarefa Avaliar Teste. No entanto, existem medidas de desempenho que são utilizadas durante a tarefa Executar Teste para avaliar o progresso e o status do teste.

As principais medidas de desempenho incluem:

• Monitoramento Dinâmico - captura e exibição em tempo real do status e do estado de cada script de teste executado durante a realização do teste.
• Relatórios de Tempo de Resposta e Rendimento do Processamento - medida dos tempos de resposta e rendimento do processamento do objetivo do teste para agentes e casos de uso especificados.
• Relatórios de Percentual - medida e cálculo de percentual dos valores de dados coletados.
• 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 Rastreio - detalhes das mensagens e conversas entre o agente (script de teste) e o objetivo do teste.

Monitoramento Dinâmico

O monitoramento dinâmico fornece exibição e geração de relatórios em tempo real, geralmente na forma de um histograma ou gráfico. O relatório monitora ou avalia a execução do teste de desempenho, exibindo o estado, o status e o progresso atuais dos scripts de teste.

Por exemplo, no histograma anterior, há 80 scripts de teste executando o mesmo caso de uso. Neste gráfico, 14 scripts de teste estão no estado Inativo, 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. A saída exibida seria típica de uma execução de teste normal que está na metade. No entanto, se os scripts de teste permanecerem em um estado ou não mostrarem mudanças durante a execução do teste, isso pode indicar um problema nessa execução ou a necessidade de implementar ou avaliar outras medidas de desempenho.

Relatórios de Tempo de Resposta e Rendimento do Processamento

Os Relatórios de Tempo de Resposta e Rendimento do Processamento, como os próprios nomes indicam, medem e calculam os comportamentos de desempenho relacionados ao tempo e ao rendimento do processamento (número de transações processadas). Normalmente, esses relatórios são exibidos como um gráfico com tempo de resposta (ou número de transações) no eixo "y" e eventos no eixo "x".

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

Relatórios de Percentual

Os Relatórios de Percentual fornecem outro cálculo estatístico do desempenho, exibindo valores do percentual de preenchimento para os tipos de dados coletados.

Relatórios de Comparação

É importante comparar os resultados de uma execução de teste de desempenho com os de uma outra para avaliar o impacto das mudanças feitas entre as execuções de teste nos comportamentos de desempenho. Utilize 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 Rastreio e Perfil

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