Compartilhar via


Tendências de relatório de erros

Você pode usar as tendências de erro relata para ajudar a acompanhar a taxa em que sua equipe é de descoberta e resolvendo erro.Esse relatório mostra um rolamento ou uma média para dispositivos móveis de erro que estão sendo relatado, resolvidos, e fechados ao longo do tempo.Quando você gerencia um grande equipe ou um grande número de erros, você pode monitorar o semanário de relatório de tendências de erro para obter informações sobre em quanto a equipe é localizando resolvendo, e de erro.

Para obter informações sobre como acessar, update, ou gerenciar relatórios, consulte Relatórios (ágeis).

ObservaçãoObservação

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órioRelató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

  • Definindo a duração de iteração

  • Interpretando o Relatório

  • Filtrando o relatório

Você pode usar esse relatório para responder às seguintes questões:

  • Quantos bug a equipe estiver, está relatando resolvendo, e está fechando pelo dia?

  • O que é tendência total em que a equipe está processando erro?

  • As taxas de ativação e de resolução de erros são diminuindo para o final da iteração como esperado?

Permissões Necessárias

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

Dados no relatório

O relatório de tendências de bug calcula a média de rolamento o número de erros a equipe que abriu, solucionar, e termina com base nos filtros que você especificar.A média de rolamento é baseada em sete dias antes de data para que ele calcula.Isto é, o relatório média especifica o número de erros em cada estado para cada um dos sete dias antes que a data, e o resultado é dividida em seguida por sete.Os dados são derivados de data warehouse.

A ilustração a seguir mostra um exemplo de relatório de tendências do erro.

Exemplo de relatório de tendências de Bug

Esse relatório exibe até três elementos gráficos linear fixa, e cada elemento gráfico representa a média de rolamento os números de erro ativados, resolvidos, e fechados.

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

  • Altere o início e as datas de conclusão para o relatório.

  • Filtrar erros que são contados no relatório especificando caminhos de iteração e de área ou estado de erro, prioridade, ou gravidade.

Para obter mais informações, consulte filtrando o relatório posteriormente em este tópico.

Dd380674.collapse_all(pt-br,VS.110).gifAtividades necessários para rastrear bugs

Para o erro as tendências relatam para ser úteis e exato, a equipe deve executar as seguintes atividades:

  • Defina bugs, e especificar seus caminhos de Iteração e de Área .

  • Atualizar Estado de cada erro é marcado como corrigido, e fechado em.

  • Especificar Prioridade e Severidade de cada erro durante a triagem.

Você pode usar a pasta de trabalho de triagem para atualizar rapidamente a iteração, a área, o estado, a prioridade, e a gravidade de erro.Para obter mais informações, consulte Pasta de trabalho de triagem.

Definindo a duração de sprint ou iteração

Para entender as tendências de bug da iteração atual, o início e as datas de conclusão para o relatório deve coincidir com aqueles do seu ciclo de iteração atual.

Para alterar a duração de iteração

  1. A o lado de Iteração Início (data) ou de O final da iteração data (), clique no ícone de calendário, clique em uma data.

  2. Clique Exibir Relatório.

Interpretando o Relatório

Você deve aguardar taxas de bug variar baseados em onde você está em seu ciclo de desenvolvimento de produtos.A equipe deve encontrar menos erros em iterações adiantadas do que em uma iterações posteriores.A equipe deve fechar a maioria de erros em iterações por que estão no final de um ciclo de produto.

Você interpretam taxas de bug melhor examinando as relativo a todas as atividades atual do projeto de equipe e o outro métricas que os relatórios de status e de Reactivations de bug fornecem.Por exemplo, a equipe pode localizar bugs rapidamente especialmente no código de maneira distorcida gravado no código, recentemente integrado, com teste aprimorados, ou durante um evento excepcional como uma bash do erro.Por outro lado, os erros são mais difíceis de encontrar em um produto de alta qualidade e testes com ineficazes.Você pode usar métricas para a tinta de código, para codificar agitações, e as taxas de teste para ajudar ao avaliar mais significado de tendências do erro.

Como o produto estabilizar para o final de um ciclo de produto, a equipe deve encontrar erros menos com freqüência.

O relatório de tendências de bug pode mostrar um ou mais dos indicadores que a tabela a seguir descreve na coluna esquerda.Você pode examinar as perguntas na coluna direita para que as áreas enderecem com mais detalhes.

Indexador

Perguntas para solicitar

A equipe está localizando o número mais ou menos idêntico de erros em períodos de tempo sucessivos.Se a equipe localiza o mesmo número da semana de erro após a semana ou de iteração após a iteração, você pode investigar a causa subjacente.Em o início do ciclo de teste, os testes podem não ser rigorosos ou avançados suficiente para localizar vários erros.Em adiantadas iterações, essa situação é esperada.Em o entanto, como o produto é amadurece, os testes devem exercitar cenários e uma integrações mais de largura.

  • O é suficiente teste das situações de teste as histórias de usuário que estão sendo desenvolvidas?

  • Os testes personalizados desenvolvidos obsoletos que são ou testar a funcionalidade incorreta?

  • São os testes de equipe de teste rigorosa cada artigo do usuário?

A equipe está localizando o período de vários bugs em cada vez.A equipe pode localizar facilmente erro no código superficial, no código recentemente integrado, com teste têm efeito, ou durante um evento específico, como uma bash do erro.

  • Métricas para a tinta de código, agitações de código, ou o progresso de teste indicam um problema com o código ou os testes?

A equipe está localizando o período de alguns erros em cada vez.A equipe pode esforçar-se para localizar erros em uma solução de alta qualidade ou com teste ineficazes.

  • Métricas para a tinta de código, agitações de código, ou o progresso de teste indicam um problema com o código ou os testes?

A equipe é resolvendo o período de vários bugs em cada vez.Uma taxa alta de resolução geralmente indica que a equipe estiver fazendo bom progresso.

  • Obter resolvido de erro for fechado prontamente?A taxa fechado deve se parecer com a taxa resolvida.

  • Os reactivations de erros são restantes nos limites esperados?

A equipe é resolvendo bug rapidamente mas não os está fechando.Os membros da equipe que são atribuídos para verificar a correção de erro podem ser muito finas prioridades, ou distribuídas diferentes podem manter os membros da equipe de fechar bug resolvidos.

  • Os recursos de teste são superalocados?

  • A equipe deve revisitar prioridades de teste?

Dd380674.collapse_all(pt-br,VS.110).gifVersão íntegro de relatório

Um relatório íntegro de tendências de erro que mostra a equipe localizar mais bugs no início de um ciclo de desenvolvimento e menos erros para o final de uma versão.A equipe deve resolver e feche mais bugs para o final do projeto.

Quando a equipe resolve erro mais rápido do que os localiza, o número de erros ativos começará para reduzir.Quando inicia o equipe para localizar menos erros, o produto estabilizarem.

Dd380674.collapse_all(pt-br,VS.110).gifVersão não esteja íntegro de relatório

Um relatório não esteja íntegro de tendências de bug pode mostrar que a equipe estiver localizando bugs mais rapidamente como as abordagens data de enviar e apresenta resolver erros de trabalho mais lentamente.Em esta situação, a reserva de bug de equipe estiver crescendo porque os erros não são obter corrigido, e você pode querer investigar as causas.A ilustração a seguir mostra um relatório para uma equipe que está localizando bugs, muitos resolvendo menos erros de que localiza, e fechando menos erros de que resolve.

Versão não íntegra do relatório de tendências de Bug

Filtrando o relatório e alterar a exibição

Você pode filtrar as tendências de erro relata ou alterar a exibição das seguintes maneiras:

  • Altere o início e as datas de conclusão para o relatório.

  • Filtrar erros que são contados no relatório especificando caminhos de iteração e da área, estado, prioridade, ou gravidade.

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

Filtros para o relatório de tendências de Bug

Para filtrar os erros que são contados no relatório

  1. Execute uma ou ambas as seguintes ações:

    • Listas de Iteração e de Área , selecione a caixa de seleção de cada iteração ou área do produto para incluir.

    • Em Estado, Prioridade, ou listas de Severidade , selecione a caixa de seleção de cada estado, prioridade, e gravidade para incluir.

  2. Clique Exibir Relatório.

Consulte também

Conceitos

Painel de erro

Pasta de trabalho de triagem

Relatório de estado de erro

Relatório de Reactivations

Bug (Agile)

Outros recursos

Relatórios (ágeis)