Relatório do Excel Indicadores de Qualidade de Compilação

Os indicadores de qualidade da construção relatam a cobertura de teste do, o código a batedeira, e as pontuações de bugs para uma definição especificada de compilação. Você pode usar este relatório para ajudar a determinar como as partes do final do código são liberar a qualidade.

Idealmente, taxas de teste, bug, e a batedeira de código qualquer produto a mesma imagem, mas não normalmente. Quando você encontra uma discrepância, você pode usar os indicadores de qualidade de bugs relatórios para revisar os detalhes de uma construção específica do e série de dados. Como esse relatório combina os resultados da análise, codifique a cobertura de teste, batedeira de código, e bug, você pode exibir várias perspectivas ao mesmo tempo.

Para obter informações sobre como acessar, atualizar ou gerenciar relatórios, consulte Relatórios (SQL Server Reporting Services).

Dica

Esse relatório requer que a coleção de projeto de equipe que contém o projeto da equipe recebeu fornecimento de SQL Server serviços de relatórios.Esse relatório não está disponível se Relatórios não aparecer quando você abrir Team Explorer e expandir o nó do projeto de sua equipe.

Neste tópico Dados no relatório Alterando o número de compilações no relatório Interpretando o Relatório Filtrando o relatório

Você pode usar este relatório para responder às seguintes perguntas: Que é a qualidade de software? Com que frequência os testes estão sendo transmitidos e quantos trechos do código estão sendo testados? Com base em métricas de código e teste, é provável que encontre a equipe metas de destino?

Permissões necessárias

Para exibir o relatório, você deverá ser atribuído ou pertencer a um grupo que tem a atribuição da função de Pesquisador nos Reporting Services. Para obter mais informações, consulte Adicionar usuários a projetos da equipe.

Dados no relatório

Os dados exibidos nos indicadores de qualidade de criação de relatório são derivados do data warehouse. O eixo x lista as construções específicas do relatório inclui, com base nos filtros definidos para a plataforma, a configuração, e a definição de compilação.

Cada barra vertical representa um conjunto de dados que foram derivados de uma ou mais construções. A variante do tamanho de código do relatório, cada comprimento da barra vertical representa o tamanho de base fazer check-in de código. As barras são dimensionadas de forma que a figura a maior que a altura do gráfico. Os testes manuais podem ser executados em qualquer momento que depois da construção, e são associados com essa construção. Os testes que ainda não foi executado são contados como “inconsequentes”.

A ilustração a seguir mostra um relatório de exemplo dos indicadores das qualidades de compilação.

A tabela a seguir descreve as informações mostradas para cada indicador de qualidade no relatório:

Indicador de qualidade	Descrição
Bugs ativas (contagem)	Gráfico de linhas que descreve o número de bug que estavam ativas no momento da compilação. Dica Os bugs não são associados explicitamente com construções.Alguns dos bugs contados não podem afetar as construções que são exibidos no gráfico.Você pode usar o parâmetro da área para filtrar a área de produto de bugs.Essa técnica pode mostrar os bug que mais provavelmente afetar as construções no relatório.
Batedeira de código (linhas)	Gráfico de linhas que descreve o número de linhas de código que a equipe adicionado, descartado, e modificados no check-in antes da compilação. A batedeira de código é calculada para determinar o número de linhas de código que foram adicionadas, excluídas, modificadas ou à compilação particionada por linhas totais na compilação.
Cobertura de código (por cento)	Gráfico de linhas que descreve a porcentagem de código que a cobertura de teste.
Teste inconsequentes	Cinza parte do gráfico de barras empilhadas, que indica o número de teste que não foram bem-sucedidas ou foram pausado. Se a construção não teve êxito, o teste não são contados ou não são contados como inconsequentes.
Teste com falha	Parte vermelha do gráfico de barras empilhadas, que indica o número de teste que falharam para a construção.
Testando passados	Parte verde do gráfico de barras empilhadas, que indica o número de teste que passaram para a construção.

Dica

Para obter mais informações sobre o significado de falha e de transmitir resultados de teste, consulte Relatório Progresso do Plano de Teste.

Você pode filtrar o relatório das seguintes maneiras:

• Alterar o intervalo do eixo x especificando o número de compilações e especificando a data de término para o relatório. A data da primeira construção mostrada dependerá da frequência de compilações.

• Filtrar o conjunto de construções que o relatório mostra especificando a plataforma, a configuração, e a definição de compilação para incluir no relatório. Definir parâmetros nessa sequência porque o conjunto de valores disponíveis para a definição de compilação depende da plataforma e configuração.

• Filtrar os bug que são contados no relatório especificando as áreas do para incluir. Esse filtro não afeta o conjunto de construções que aparecem no eixo x, na batedeira de código, na cobertura de código, ou os resultados da análise.

Para obter mais informações, consulte Filtrando o relatório posteriormente neste tópico.

Atividades necessárias de gerenciamento de teste e de compilação

Para os indicadores de qualidade de criação de relatório para ser útil e descrever todos os medidores que pode exibir, membros da equipe do data quality deve executar as seguintes atividades para gerenciar teste e construções:

• Configurar um sistema de compilação. Para usar o Team Foundation Build, você deve configurar um sistema de compilação.

  Para obter mais informações, consulte Configurar e gerenciar seu sistema de compilação.

• Criar definições de compilação. Você pode criar várias definições de compilação, que podem ser executadas no código do produto para uma plataforma diferente. Além disso, você pode executar cada compilação para uma configuração diferente.

  Para obter mais informações, consulte Definir o processo de compilação.

• Definir testes para executar automaticamente como parte da compilação. Como parte da definição de compilação, você pode definir testes para executar como parte da compilação ou para falhar caso o teste falhe.

  Para obter mais informações, consulte Usar o modelo padrão no processo de compilação.

• Configurar testes para coletar dados de cobertura de código. Para que os dados de cobertura do código apareçam no relatório, os membros da equipe devem prover testes para coletar os dados.

• Executar compilações regularmente. Você pode executar compilações em intervalos definidos ou após cada check-in. Você pode criar compilações normais quando usa o disparador de cronograma.

  Para obter mais informações, consulte Criar ou editar uma definição de compilação e Executar, monitorar e gerenciar compilações.

  Dica

  Embora um membro da equipe possa avaliar manualmente uma compilação usando Build Explorer, essa avaliação não é refletida no relatório de indexadores de qualidade de compilação.A avaliação de compilação aparece no relatório de resumo de compilação.Para obter mais informações, consulte Classificar a qualidade de uma compilação concluída e Relatório Resumo da Compilação.

Alterando o número de compilações no relatório

A exibição do relatório de indicadores de qualidade de compilação significativamente variará com base no número de compilações que o relatório inclui e outros filtros que você aplica ao relatório. Você pode passar o relatório em um determinado intervalo as compilações alterando o número de compilações que aparecem no relatório.

Para definir o número de compilações que são representadas no relatório

1. Em Número de compilações, digite o número para incluir.

2. Ao lado de Termine (data), clique no ícone de calendário, clique na data que corresponde ao dia do último que as construções foram executadas que você deseja incluir no relatório.

3. Clique Exibir relatório.

Interpretando o Relatório

Você pode examinar o relatório para localizar respostas a essas perguntas para qualquer definição específica de construção:

• Que é a qualidade de software?

• A equipe está testando suficiente de nosso código?

• Os testes estão fluindo?

• A equipe é provável para ser concluída é baseado em métricas de código e de teste?

• Com que frequência os testes estão sendo transmitidos e quantos trechos do código estão sendo testados?

  Dica

  A taxa de colorido aos buckets cinza reflete a fração de código que a capa de teste, mas as proporções dentro dos segmentos coloridos somente reflete sobre as frações de código que transmite ou falha teste.Essa ambiguidade porque a fração de verde no segmento colorido realmente representa o número de teste que passam.Um único erro em uma parte do código pode levar muitos teste falhar, ou uma única falha pode representar um erro detalhadas no design que tem consequências na base de código.

Versão íntegro de relatório

Um relatório íntegro dos indicadores de qualidade da construção mostrará os indicadores seguintes:

• A maioria de teste estão fluindo (grandes áreas de verde), e alguns testes estão (pequenas quantidades de vermelho).

• A porcentagem de vermelho é inferior a porcentagem 20-30.

Como a ilustração a seguir mostra, codifique a cobertura e as taxas de passagem de teste são altas e crescent com o passar do tempo. O código a batedeira, bugs ativas, teste inconsequentes, e testes falha são todos baixos e diminuir.

Versões de relatório não íntegro dos indicadores de qualidade de compilação

Uma versão não íntegro dos indicadores de qualidade de criação de relatórios mostra um ou mais dos indicadores. Talvez você queira investigar a causa de acordo com a seguinte orientação.

• Menos cobertura e mais de código afeta a batedeira. A ilustração a seguir mostra uma diminuição na cobertura de código e um aumento na batedeira de código. Esses dados são um aviso claro que o novo código está sendo feito check-in sem teste da unidade para cobrir o.

  

• Taxa baixa de teste que estão sendo executados. A ilustração a seguir mostra uma taxa baixa de teste que está sendo executado. Esses dados podem indicar que a equipe não está executando o suficiente para teste. Esse bloqueio pode indicar a falta de recursos, ou testadores podem fazer algo mais, como a automação de teste do escrita em vez de testar a funcionalidade atual. Em ambos os casos, o equilíbrio de recurso pode ser justificado.

  

• Batedeira alta de código, desprezada de cobertura de código. A batedeira alta de código sugere que os bugs foram introduzidos como efeitos colaterais de alterações. Em um projeto perfeitamente refactored, você pode consultar a batedeira de código sem a alteração em taxas de passagem de cobertura ou de teste de código. Caso contrário, a batedeira alta de código pode indicar a cobertura menor e a necessidade de teste.

  A ilustração a seguir mostra uma taxa alta de batedeira de código e uma taxa baixa de cobertura de código de teste, mesmo que as taxas de passagem de teste permaneçam alta. Esses dados indicam que os testes que está sendo executado não são por meio da execução do novo código.

  

• Taxa alta de falha de teste. A ilustração a seguir mostra que muitos teste estão sendo executados com cobertura razoável de código, mas os testes estão. Esses dados podem indicar práticas fracas de desenvolvimento, ou, em iterações antiga, os testes podem ser muito irregulares para essa fase de produto.

  

  Falha de teste deve ser resolvido o mais rápido possível. Se corrige o código não é prático, os testes temporariamente falha devem ser desabilitados, e um bug deve ser registrado em log. Embora às vezes é aceitável controlar a análise de código com menos falhas urgência no início no projeto, você não deve deixar as seções vermelhas obter muito grande.

• Taxa alta de teste que passam e taxa alta de bugs ativo. A ilustração a seguir mostra uma taxa alta de passagem de teste mas ainda uma grande taxa de entrada de bugs. Esta situação pode ocorrer por vários motivos. Os testes podem não ser suficientemente rigorosos para essa fase de produto.

  

  Em iterações antiga, os testes simples são bons, mas como o produto se amadurece, o teste devem exercer um cenários e uma integrações mais largos. Os testes podem ser obsoletos, ou podem testar a funcionalidade errada. Pode ser hora de alternar técnicas de teste.

• A passagem de teste não avalia o aumento e nenhum aumento na cobertura de código. Em geral, como mais testes são executados, mais código deve ser coberto. Por outro lado, se as taxas de passagem de execução do teste e teste aumentam sem um aumento correspondente na cobertura de código, os testes incrementais podem ser redundantes.

• A contagem ativa de bugs está aumentando, mas as falhas de teste não estão aumentando. Se a contagem de bugs ativo está aumentando e os testes não estão sendo exibidos falhas correspondentes, os testes provavelmente não estão testando a mesma funcionalidade que os bugs são de relatório.

• A contagem ativa de bugs estão diminuindo, mas o teste não estão aumentando. Se a contagem ativa de bugs estão diminuindo e taxas de passagem de teste não estiver aumentando, você pode correr o risco de uma taxa crescente de reactivation.

• Grandes áreas de cinza. Os segmentos cinza significa o código que não foi criado ou não foi testado na construção determinada. Esses dados são exibidos somente em um relatório periódica em que uma ou mais das construções especificadas não ocorram dentro do período.

Filtrando o relatório

Você pode filtrar os indicadores de qualidade da construção relatórios das seguintes maneiras:

• Alterar o intervalo de tempo especificando o número de compilações e especificando a data de término para o relatório.

• Filtrar o conjunto de construções que são representadas no relatório especificando a plataforma, a configuração, e a definição de compilação para incluir no relatório.

  Dica

  Você pode configurar definições de compilação para não executar qualquer teste, alguns testes, ou todas teste.O relatório varia consideravelmente com base na configuração das definições de compilação.

• Filtrar os bug que são contados no relatório especificando as áreas do para incluir.

A ilustração a seguir mostra os filtros disponíveis:

Aplicar os filtros na sequência que especifica o procedimento a seguir. As opções que estão disponíveis com todos os filtros dependem dos filtros que você definem anteriormente.

Para filtrar as construções que aparecem no relatório

1. Em Número de compilações, digite o número para incluir.

2. Ao lado de Data de término, clique no ícone de calendário, e clique na última data de que as construções incluírem.

3. Na lista de Plataforma , marque a caixa de seleção de cada plataforma para incluir.

4. Na lista de Configuração , marque a caixa de seleção de cada configuração para incluir.

5. Na lista de Definição da compilação , marque a caixa de seleção de cada definição de compilação para incluir.

6. Clique Exibir relatório.

Para filtrar as contagens de bug que são exibidas no relatório

1. Na lista de Área , marque a caixa de seleção de cada resultado da análise para incluir.

   Esta etapa filtrando o relatório com base na hierarquia dos resultados da análise.

2. Clique Exibir relatório.

Consulte também

Outros recursos

Relatórios (SQL Server Reporting Services)