Trabalhar com bug

Porque você realiza teste para verificar suas necessidades, você está associado para localizar erros.Use o item de trabalho de bug para descrever e acompanhar o progresso para cada erros que você encontrar.Para obter mais informações sobre como criar itens de trabalho de bug, consulte Enviando bugs no Microsoft Test Manager.Como os erros são encontrados, siga o processo deste tópico para dar-lhes a prioridade, para certificar-se que obtêm fixa, e para certificar-se de que você tem um registro de trabalho e decisões que estavam envolvidos.

O formulário de item de trabalho para um bug armazenam dados em campos e guias que as ilustrações mostram:

Neste tópico

• Erros de triagem

• Corrigir um bug

• Fechar um bug

Erros de triagem

As reuniões de triagem devem ser realizadas em intervalos definidos depois que o trabalho e os testes de desenvolvimento seguir o iniciarão no projeto.Como geralmente você realiza as reuniões e quanto tempo devem ser depende de sua situação.

Normalmente, as reuniões de triagem de erros são executadas por um gerenciador de projeto e assistidas pela de equipe e os analistas talvez comerciais e os participantes que podem falar sobre os riscos de projeto específico.O gerenciador de projeto pode usar os erros ativos consulta para novos e bugs reaberto de gerar uma lista de erros a ser triaged.

Antes que inicia a triagem, planejarem um conjunto de critérios para determinar erros que devem ser corrigidos e na prioridade.Os critérios identificarão normalmente a gravidade de erro, os erros que são associados com os recursos de valor significativo (ou do custo de opção significativo de um atraso), ou outro riscos do projeto.

Os critérios de triagem devem ser armazenados na pasta documentos do seu projeto de equipe.Ao longo do tempo, o documento será atualizado.Assume-se que o projeto tiver o controle de versão ativada e os critérios específicos que estão sendo usados em um determinado momento no projeto podem ser recuperados para fins de evidência de auditoria e de avaliação.

No início do projeto, você provavelmente decidirá corrigir a maioria dos erros que você triagem.No entanto, como o projeto continuará, os critérios de triagem (ou a barra) podem ser gerados para reduzir o número de erros que são fixos.

Aumentando os critérios de triagem barre e permitir bugs relatados permaneçam unfixed é uma escolha.É uma escolha que digam que corrigir o erro é menos importante que a localização do escopo, o orçamento, e a agenta de projeto.

Use seus critérios para determinar que a corrigir bugs e como definir seu estado, prioridade, gravidade, e outros campos.Por padrão, o modelo fornece quatro prioridades: 1 para “deve corrigir 4 com” para “não importantes.” Se você alterar as definições no modelo de processo, você deve atualizar a orientação, o texto de ajuda, e todos os critérios de documentos de acordo.

Para obter mais informações sobre como preencher o item de trabalho de bug Erros (CMMI), consulte.

Corrigir erros

Depois que um bug passado para triagem e foi fornecido a prioridade, deve ser atribuído a um desenvolvedor para maiores investigações.

O item de trabalho de bug tem um guia para as etapas de repro, que devem fornecer o que você precisa para reproduzir o erro.No entanto, você também pode ser capaz de usar a ajuda de IntelliTrace você reproduz erros difíceis.Para obter mais informações sobre IntelliTrace, consulte Incluindo dados de rastreamento de diagnóstico com Bugs que são a dificuldade de reproduzir e Depurar seu aplicativo gravando execução de código com o IntelliTrace.

Depois que o desenvolvedor decidir em um curso de ação, devem observe as suas decisões no item de trabalho de bug.

Decida na correção

Trabalhando com outros membros da equipe, o desenvolvedor pode recomendar uma correção que tem implicações para outras seções de código e que pode exigir teste de regressão significativos.Todas as conversações que se relacionarem para avaliar o risco de tal correção devem ser registrados no histórico de item de trabalho de bug porque documenta a evidência útil de análise e de gerenciamento dos riscos de decisão para um método de avaliação de discussão ou padrão CMMI para avaliação de melhoria de processo (LAGOSTIM).Para obter mais informações sobre CMMI consulte Plano de fundo a CMMI.

Atualizar e testes de unidade de execução para corrigir o erro

Os testes de unidade verificam a implementação correta de uma unidade de código.Escrever e executar testes de unidade identificar erros antes que inicia e teste, como consequência, ajuda reduzem o custo de controle de qualidade.Os desenvolvedores deve escrever testes de unidade para qualquer código que será escrito como parte de implementar uma tarefa de desenvolvimento de ou implementar uma correção para o erro.Para obter mais informações, consulte Verificando o código usando testes de unidade.

Você pode preferir escrever o teste de unidade antes de fazer qualquer correção do código em uma teste- primeira estratégia de desenvolvimento.Esse tipo de estratégia é preferido por desenvolvedores de software ágeis.O CMMI não exigem que os testes de unidade são gravados em uma sequência específico, somente essa verificação efetivo de funcionalidade é obtida.

Evidências que os testes de unidade foram escritos e a execução é necessária para uma avaliação CMMI.Certifique-se de adicionar os testes para itens de trabalho de tarefas para a correção de código, essas tarefas e vincular ao item de trabalho de bug.Isso fornece a rastreabilidade a evidência que um avaliador de ligação de LAGOSTIM procurará.

Revisão e refatora o código para corrigir o erro

Uma revisão de código é usada para garantir que o novo código ou alterado localize uma barra estabelecida de qualidade antes que o código está integrado a compilação diária.Considerações de qualidade está codificando padrão, compatibilidade com a arquitetura e o design, desempenho, legibilidade, e segurança.As revisões de código também fornecem informações sobre adicional de outros desenvolvedores sobre como o código deve ser gravado.Para obter mais informações sobre como examinar e o código do, consulte refactor Implementando tarefas de desenvolvimento.

Próximos erro

Depois que um bug é corrigido, deve ser atribuído a um verificador para verificar se o problema foi resolvido antes do item de trabalho de bug seja fechado.

Verificando uma correção

Para verificar uma correção o, ele deve tentar reproduzir o erro, ele procura o comportamento inesperado adicional, e, se necessário, reativar o erro.

Para verificar uma resolução de erro, você pode descobrir que o erro não esteve corrigido completamente ou você pode discordar com resolução.Nesse caso, você descreve o erro com a pessoa que o solucionar, vindo a um acordo, e reativar possivelmente o erro.Se você reativar um erro, certifique-se que você inclui as razões para reactivating o erro na descrição do erro de modo que a informação seja preservada.

Fechando o item de trabalho de bug

Um bug é fechado por vários motivos.Em casos simples, o erro foi marcado como corrigido e também pode ser fechado.No entanto, um bug pode ser adiado para a próxima versão do produto, ser provado não ser reprodutível, ou ser confirmado como uma cópia.Cada um desses motivos deve ser documentada, e o erro deve ser encerrado corretamente para garantir que não haja nenhuma confusão sobre como é fechada.

Consulte também

Conceitos

Enviando bugs no Microsoft Test Manager

Depurar seu aplicativo gravando execução de código com o IntelliTrace

Outros recursos

Incluindo dados de rastreamento de diagnóstico com Bugs que são a dificuldade de reproduzir