Índice

1. Objetivos
2. Escopo
3. Referências
4. Introdução
5. Cobertura do Teste
6. Cobertura do Código
7. Análise de Defeitos

   7.1    Densidade de Defeitos

   7.2    Tendência de Defeitos

   7.3    Idade dos Defeitos

8. Ações Sugeridas
9. Diagramas

1. Objetivos

Este Relatório de Avaliação do Teste descreve os resultados dos testes de sistema do C-Registration Release 1.0 em termos de cobertura de teste (tanto cobertura baseada em requisitos quanto baseada em código) e análise de defeitos (isto é, densidade de defeitos). Esses testes foram conduzidos durante a Iteração C2.

2. Escopo

Este Relatório de Avaliação do Teste é aplicado ao Release R1.0 do C-Registration implementado na Iteração C2. Os testes conduzidos estão descritos no Plano de Teste [5]. Este Relatório de Avaliação deve ser utilizado para o seguinte:

• Avaliar a capacidade de aceitação e apropriação do(s) comportamento(s) de desempenho do sistema R1.0
• Avaliar a capacidade de aceitação dos testes
• Identificar aprimoramentos para aumentar a cobertura do teste e/ou sua qualidade

3. Referências

As referências aplicáveis são:

1. Course Registration System Glossary, WyIT406, V2.0, 1999, Wylie College IT.
2. Course Registration System Software Development Plan, WyIT418, V1.0, 1999, Wylie College IT.
3. Course Registration System C2 Iteration Plan, WyIT500, V1.0, 1999, Wylie College IT.
4. Course Registration System C2 Integration Build Plan, WyIT502, V1.0, 1999, Wylie College IT.
5. Course Registration System Test Plan, WyIT501, V1.0, 1999, Wylie College IT.

4. Introdução

Os casos de teste definidos no Conjunto de Teste foram executados seguindo a estratégia de teste definida no Plano de Teste [5]. Os defeitos de teste foram registrados e todos os defeitos de prioridade média, alta ou crítica estão atualmente designados ao proprietário para correção.

A Cobertura de teste (consulte a seção 5.0 a seguir) em termos de cobertura dos casos de uso e requisitos de teste definidos no Plano de Teste [5] foi 95% concluída. 10 casos de teste que envolvem a operação do sistema sob uma carga completa não foram concluídos devido a erros no Software Simulador de Carga.

A cobertura de código foi medida utilizando-se o Rational Visual PureCoverage e está descrita na seção 6.0.

A análise dos defeitos (conforme mostrada na seção 7.0 a seguir) indica que a maioria dos defeitos encontrados tende a ser problemas grandes classificados como altos ou críticos em termos de gravidade. A outra descoberta significativa foi que os componentes de software que compõem a interface para o Sistema de Catálogo de Cursos continha um número significativo de defeitos.

5. Cobertura do Teste

Todos os casos de teste, conforme definido no Conjunto de Teste, foram tentados. 10 testes não foram concluídos devido a erros de software no Software Simulador de Carga. Do total de casos de teste executados, 15 falharam.

Os resultados da cobertura do teste são as seguintes:

Taxa de Casos de Teste Executados = 110/120 = 92%

Taxa de Casos de Teste com Êxito = 95/110 = 87%

A área de testes com a mais alta taxa de falha foi:

Detalhes adicionais sobre a cobertura de teste estão disponíveis utilizando-se o Rational RequisitePro e a matriz de Casos de Teste.

6. Cobertura do Código

O Visual PureCoverage foi utilizado para medir a cobertura de código dos testes.

Taxa de LOC executada = 94,399 / 102,000 = 93%

Aproximadamente 93% do código foi executado durante o teste. Essa cobertura excedeu a meta de 90%.

7. Análise de Defeitos

Esta seção resume os resultados da análise de defeitos gerada utilizando o Rational ClearQuest. A seção 8 recomenda ações para tratar as descobertas da análise de defeitos.

7.1     Densidade de Defeitos

Foram gerados dados sobre a densidade de defeitos utilizando os dados extraídos dos relatórios do ClearQuest. A seção 9 deste documento inclui gráficos que ilustram:

O Gráfico de Defeitos por Nível de Gravidade mostra que 26 dos 36 defeitos registrados são classificados como altos ou críticos em termos de gravidade. Esse número é considerado muito alto e, além disso, todos os defeitos altos e críticos devem ser fechados para que o Release seja liberado.

O Gráfico de Origem do Defeito mostra uma porcentagem extraordinariamente alta de defeitos associada aos componentes (c-abx, c-xxx) que formam a interface para o Sistema de Catálogo de Cursos. Além disso, muitos defeitos residem nos componentes de software que controlam a instalação do software cliente.

O Gráfico de Status do Defeito mostra que os defeitos estão sendo prontamente designados e trabalhados. A maioria dos defeitos foi verificada e fechada.

Além disso, a análise dos defeitos altos e críticos mostrou que muitos desses defeitos são devidos a tempos de resposta ruins no acesso ao Sistema de Catálogo de Cursos durante condições de alta carga. (Apenas 50% dos Casos de Teste de verificação dos requisitos de desempenho foram aprovados.)

7.2     Tendência de Defeitos

As tendências de defeitos (isto é, contagens de defeitos com o decorrer do tempo) são mostradas no Diagrama na seção 9. Essa tendência mostra que a ocorrência de defeitos permanece alta. Se a tendência continuar, poderão ser necessárias iterações adicionais para localizar defeitos remanescentes no código.

7.3     Idade dos Defeitos

O Gráfico de Idade dos Defeitos (consulte a seção 9) ilustra que o tempo para fechar alguns defeitos é de mais de 30 dias.

As ações recomendadas são as seguintes:

1. Continuar a dedicar recursos de engenharia de sistemas ao problema de tempo de resposta que envolve o Sistema de Catálogo de Cursos. Esse é um problema crítico pois o Release R1.0 não pode ser liberado sem que os requisitos de desempenho sejam atendidos.
2. Revisar o planejamento principal para verificar se uma quarta iteração pode ser incluída na Fase de Construção. A tendência de defeitos com o decorrer do tempo indica que muitos defeitos permanecem no código e um ciclo de teste adicional é recomendado.
3. Os componentes com uma alta taxa de defeitos devem ser inspecionados antes de submeter novamente para um build. Isso inclui c-abx e c-xxx.
4. A alta taxa de defeitos com gravidade Crítica e Alta pode indicar que o design estava incompleto e não foi revisado apropriadamente. Planejar revisões de design adicionais para o Release R2.0.
5. Corrigir os problemas com o Software Simulador de Carga e executar novamente os casos de teste associados.
6. Investigar idade dos defeitos. Por que vários defeitos estão demorando mais de 30 dias para ser fechados?