Testar antecipadamente e com freqüência

Detectar defeitos mais cedo possível é a maneira menos dispendiosa para garantir a qualidade do software. Kent Beck e Carla Andres escreveram "aqui está o dilema no desenvolvimento de software: defeitos são caros, mas também é caro eliminar os defeitos. No entanto, a maioria dos defeitos acabam custam mais do que ele custaria para impedi-los." (Para obter mais informações, consulte a seguinte página Web: Programação Extreme explicou: Alteração de adotar.) Ferramentas e práticas recomendadas podem ajudar sua equipe para minimizar o custo de prevenir e corrigir defeitos, mantendo a qualidade do seu projeto em todo o ciclo de vida.

Sua equipe pode determinar mais precisamente a qualidade do seu projeto a qualquer momento se você encontrar defeitos, corrigir defeitos e verificar correções à medida que avança. Testando com freqüência, sua equipe e partes interessadas podem permanecer cientes do estado atual do código e tomem decisões durante todo o projeto. Por fim, você deve ser capaz de responder a pergunta "pode lançamos?" e compreender as implicações para as pessoas que usam o software.

Este tópico recomenda as seguintes práticas:

• Crie um conjunto de testes de unidade automatizado para cada classe e a API de cada componente principal. Escrever testes de unidade deve levar cerca de 40% dos membros da equipe tempo. Para obter mais informações, consulte Criação automatizada de testes.

• Crie testes para cada história de usuário. Essas preferência devem ser automatizadas. Para obter mais informações, consulte Criando um plano de teste usando requisitos ou histórias de usuários.

• Crie diretivas check-in que lembrem os membros da equipe para executar testes de unidade antes de verificar no código. Para obter mais informações, consulte Adicionar diretivas de Check-In.

• Configure uma compilação contínua ou noturna que executa o conjunto completo de testes.

• Cobertura de teste do monitor para garantir que todo o seu código é testado. Tenha como objetivo a cobertura pelo menos 70%. Para obter mais informações, consulte Testar intervalos de Reportar do Excel (Agile).

• Execute testes manuais, próximo ao final de todos os sprints.

Sua equipe pode gerenciar e dimensionar a essas atividades de teste no início do seu projeto usando a integração entre Microsoft Test Manager, Visual Studio Application Lifecycle Management (ALM), e Visual Studio Team Foundation Server. Para obter mais informações, consulte Testando o aplicativo.

Neste tópico

• Estratégia de teste

• Planejamento de teste

• Teste de aceitação

• Teste de unidade

• Desenvolvimento e teste logo controlado por teste

• Manual em vez de testes automatizados

• Os resultados do teste de emissão de relatórios

Estratégia de teste

O sucesso da sua equipe com o teste depende de vários fatores, que incluem o tamanho de sua equipe, os métodos da sua equipe e ferramentas de gerenciamento da sua equipe. Você pode usar os métodos ágeis para melhorar continuamente os resultados de teste. Ao aplicar esse método, não só pode começar a testar com recursos muito limitados, mas também é possível ajustar a sua prática conforme apropriado em todo o projeto.

O que considerar ao introduzir ágil de teste

Ao introduzir ágil de teste para um aplicativo existente, sua equipe pode começar pensando em sua estratégia de teste no nível do projeto e o nível de sprint. No nível da sprint, você pode incluir um conjunto de testes de aceitação para cobrir cada história de usuário do sprint atual. No nível do projeto, você pode ter testes que abrangem todo o projeto, tais como testes de ponta a ponta. Isso é útil se você quiser verificar a funcionalidade que abrange as oportunidades de dois ou mais. Você pode criar todos os tipos de testes, enquanto sua equipe cria o código durante um sprint. Esses testes incluem os testes de unidade, testes de aceitação e testes não-funcionais, tais como testes de desempenho, testes de segurança e testes de usabilidade.

Para aplicar os métodos ágeis de testes, você deve primeiro considerar o histórico de seu aplicativo e o sistema que usa a sua equipe. Você pode aplicar os métodos ágeis de testes para aplicativos novos e existentes. Você pode usar Microsoft Test Manager para criar um plano de teste para todo o projeto e um plano de teste para cada sprint no projeto. Esses planos permitem que sua equipe para organizar os casos de teste em suítes de teste para ajudam a priorizar os testes em execução e ajudam a compreender os resultados do teste de teste. Para obter mais informações, consulte Criando um plano de teste usando requisitos ou histórias de usuários. Sua equipe pode usar Visual Studio ALM para o casos de grupo de teste em suítes de teste por meio de vários métodos:

• Criando e gerenciando um grupo estático de casos de teste.

• Usando uma consulta para criar e gerenciar um grupo dinâmico de casos de teste (isto é, localizar casos de teste com base na prioridade).

• Adicionando uma história de usuário ou um requisito para um plano de teste, onde os casos de teste tem um link para o requisito.

• Copiando um conjunto de teste existente a partir de outro plano de teste.

Para obter mais informações, consulte Organizando os casos de teste usando conjuntos de teste.

Em segundo lugar, você deve considerar a capacidade de teste do seu código. Para saber isso, você precisa compreender a arquitetura e padrões do seu aplicativo. Se você usar padrões como o controlador MVC (Model View), ViewModel de modo de exibição do modelo (MVVM) ou apresentador MVP (Model View), pode isolar determinadas funções e executar testes funcionais, sem o impacto negativo do teste de interface do usuário. No entanto, isso nem sempre representam o caso real. Por exemplo, é possível isolar a funcionalidade das partes de refatoração do seu aplicativo e você pode acessar certas áreas do código somente por meio do usuário manipuladores de eventos de rede ou interface. Se você desejar melhorar significativamente a qualidade do teste, você deve aumentar o percentual de código testável. Para obter mais informações sobre esses padrões, consulte <>>ASP\.NET MVC 2.

Em terceiro lugar, você deve considerar os recursos da equipe antes de implementar o teste ágil. Alguns membros da equipe devem ser capazes de criar testes de unidade quando você implementa funcionalidades. Alguns membros da equipe devem ser capazes de criar e definir os casos de uso manual e testes de fluxo de trabalho se eles estão familiarizados com as regras de negócios do seu aplicativo. Além disso, outros membros da equipe devem ser capazes de criar testes automatizados e mais detalhadas que sejam baseiam estes testes manuais se eles possuem habilidades técnicas necessárias.

Como gerenciar o ciclo de vida do teste

O teste é um processo iterativo em todo o projeto. Consulte as seguintes etapas:

1. Tornar os objetivos de teste de limpar e certificar-se de que toda a equipe concorda a eles. Com base nesses objetivos, determine sua estratégia de teste. Por exemplo, a sua estratégia pode ser "testes serão executados antes de cada check-in, testes de unidade terá a cobertura de código de 70% e a história de cada usuário terá pelo menos um teste automatizado.

2. Defina o plano de teste com base nos requisitos não-funcionais no sprint atual, suposições de design e histórias de usuários do projeto.

   1. Você pode adicionar as histórias de usuários à lista de pendências e planejá-los para futuras oportunidades. Você deve corresponder a cada plano de teste para pelo menos um sprint e, portanto, deve ter os casos de teste para todas as histórias de usuários na sprint.

3. Definir e criar casos de teste, tais como testes de aceitação, testes de unidade, testes funcionais e testes de desempenho.

4. Grupo de casos de teste em suítes de teste. Você pode ajustar essas suítes de testes em planos de teste definido para ajudam a orientar seu esforço de teste.

5. Execute o suítes de teste e continha os casos de teste várias vezes ao longo da sprint. Iniciar para executar testes no início do sprint e continuar a adicionar os casos de teste para suítes de teste. Se você quiser identificar situações e condições de teste importante, você pode aplicar testes exploratório e conversas freqüentes dentro de sua equipe.

6. Garanta que todos os testes de aceitação de uma história de usuário passaram antes de definir seu status para concluir.

Embora o fluxo de trabalho pode ser muito mais envolvido, dependendo da divisão de software, a ilustração anterior captura a essência de um fluxo de trabalho entre os componentes principais.

• Código gera compilações.

• Código é influenciado pelo trabalho definido, planos de teste e a qualidade das compilações.

• Planos de teste, suítes de teste e casos de teste são influenciados pela metas planejadas e outros aspectos do projeto que não mostra esta ilustração.

• Alterações no código podem afetar os casos de teste.

A correção de Bugs

1. Você deve lidar com bugs mais cedo possível. Um bug sério significa que não tenham sido concluídas as histórias de usuários, ela afeta.

2. Crie itens de trabalho bug para bugs encontrados por meio de testes ou outras atividades. Defina a gravidade do bug para indicar o grau ao qual ele afeta as histórias de usuários. Alta gravidade, como, por exemplo, 0 ou 1, indica que as histórias importantes não foram implementadas ou que os usuários façam soluções alternativas significativas para alcançar a história. Severidade baixa, como, por exemplo, 3, indica que os usuários ainda podem atingir seus objetivos de principais sem trabalho extra.

3. Trabalhe com outras pessoas da sua equipe a decidir sobre um plano de ação para cada bug.

4. Resolva bugs como corrigi-los. O bug deve ser atribuído a outra pessoa para verificar. Verifique e fechar bugs assim que possível.

5. Acompanhar o status de bugs. Na reunião retrospectiva no final de cada iteração, examine o relatório de tendências de bugs e discuta os motivos para qualquer aumento incomuns. Para obter mais informações, consulte Reportar de tendências de bug.

Planejamento de teste

O planejamento de teste é o processo de ajudar sua equipe para compreender a visão geral do projeto e o processo de preparação de sua equipe para todos os tipos de teste. Teste ágil começa com a sprint nível. Em cada sprint, sua equipe cria testes para verificar as histórias de usuários que foram criadas nesse sprint. A equipe executa os testes que foram criados em oportunidades atuais e anteriores. Por meio de curso do projeto, um grande número de testes é composto que abrange todas as funcionalidades. A ilustração a seguir mostra um modelo para planos de teste em seu projeto.

Criar um plano de teste para cada sprint e para o projeto.

Usando os recursos de testes do Visual Studio ALM, sua equipe pode incrementalmente planejar, organizar, executar e reportar testes. Sua equipe pode criar um modelo para planos de teste e os membros da equipe podem preencher suítes de teste. Um plano de teste, sua equipe pode identificar onde você deve usar os casos de teste automatizados ou manuais.

Para cada sprint em seu projeto, você pode iniciar para criar um plano de teste. Usando esse plano, sua equipe pode se concentrar na verificação da funcionalidade no sprint atual. Embora o plano está vazio a princípio, você pode usá-lo como um espaço reservado para suítes de teste. Você pode organizar os casos de teste em suítes de teste apropriados. Se você deseja obter feedback pontual de participantes do projeto, você deve criar esses casos de teste no início e ao longo de um sprint.

Você também pode criar um plano de teste que abrange todo o projeto. Você pode usar os planos de teste do projeto para testes de oportunidades anteriores de união e organizar as suítes de teste que se aplicam a todo o projeto. Você deve continuar a executar suítes de teste de regressão porque é importante manter a estabilidade e o fluxo quando sua equipe cria projetos maiores. Especialmente se você trabalha com as equipes distribuídas e maiores falta de proximidade, suítes de teste de regressão capaz de detectar erros que são baseados em alterações que têm impacto em cascata. Sem medidas corretas no local, esses erros são muito difíceis de detectar e podem ser detectados no final do ciclo ou após a entrega.

Algumas equipes talvez queira definir um plano de teste que abrange todo o projeto. Esses tipos de planos de teste podem verificar a funcionalidade relacionada em um número de oportunidades e conter as suítes de testes que são executados em todo o projeto. Por exemplo, você pode testar um recurso que englobe histórias sprints em seguida, somente quando o recurso inteiro for concluído.

Definir os testes de aceitação antes da sprint

Você deve definir os testes de aceitação antes da sprint. Esses testes de aceitação podem ajudá-lo a determinar se uma história de usuário foi concluída. Se você criar um conjunto de teste que é denominado testes de aceitação em um plano de teste para cada sprint, você pode controlar os casos de teste de aceitação. Para obter mais informações, consulte Testes de aceitação posteriormente neste tópico.

Criar testes de unidade durante um sprint.

Sua equipe deve criar testes de unidade durante a sprint. Testes de unidade podem verificar o desempenho do código, como, por exemplo, o custo do tempo e recursos que são usados para executar o código. Outros tipos de testes, tais como testes não-funcionais (ou seja, testes de desempenho e testes de segurança) devem ser criados e adicionados a conjuntos de teste apropriados. Você deve organizar essas suítes de testes, para que você possa identificar facilmente o seu custo.

Foco nas áreas de alto uso de teste

A compreensão de onde não existe muita variabilidade no seu software determina onde os pontos de acesso podem ser. A entrada do usuário, o ambiente que executa o software, rede e hardware são exemplos de variáveis de configuração que permitem que sua equipe descobrir os pontos de acesso no software. Se houver um número intrincado de condições que podem ocorrer durante um teste ou uma condição raramente ocorre, o valor do teste diminui, exceto que o impacto potencial de um defeito é muito alto. Em geral, o isolamento de funcionalidade é desejável quando possível. Situações de teste de alto impacto também são importantes. Para obter mais informações sobre como gerenciar configurações usando Microsoft Test Manager, consulte A definição de sua matriz de teste usando as configurações de teste.

Para projetos existentes, monitore as áreas que têm o maior número de defeitos e determinam por que os defeitos existem. Também monitore a variação de código porque essa área pode subestimar suposições subjacentes. Algumas das razões para defeitos de código incluem a dificuldade de gerenciar não apenas estados (por exemplo, interface de usuário e de rede), mas também código.

Testes separados para processar e armazenar dados

Código que usa um banco de dados normalmente separa o dados de processamento do armazenamento de dados. Você pode testar o processamento de dados executando testes de unidade e você pode testar o armazenamento de dados diretamente na camada de banco de dados. Visual Studio Test Professional 2010fornece funcionalidade para testar procedimentos armazenado do banco de dados. Você deve organizar esses testes em seu próprio conjunto de testes. Para obter mais informações, consulte Criar e definir os testes de unidade de banco de dados.

Microsoft Test Managerpode ser usado para criar snapshots de imagens da máquina e usá-los como uma maneira de reverter para um estado conhecido depois de executar os testes que dependem de dados (ou algum outro aspecto do estado). Esses testes são muito valiosos e ter sido tradicionalmente muito tempo intensivo.

Teste de aceitação

Testes de aceitação, verifique se as histórias de usuários. Esses testes não apenas garante compilar com êxito o que seus clientes precisam durante todo o ciclo de vida do projeto, mas também construir a confiança com seus clientes e mostram suas responsabilidades aceitas. Para obter mais informações, consulte a seguinte página Web: Guia de engenharia de teste de aceitação.

Como começar com o teste de aceitação

Abrir Microsoft Test Managere em seguida, crie um pacote de teste que é chamado de testes de aceitação em seu plano de teste. Sua equipe deve ter pelo menos um conjunto de testes que agrupa os testes de aceitação para cada sprint. Para obter mais informações, consulte Definir o seu esforço de teste usando o teste planos..

Migrar de testes manuais para testes automatizados

Testes manuais são mais fácil de definir que os testes automatizados, mas é mais caro. Ele é, portanto, uma boa estratégia para começar com testes manuais e substituem gradualmente o mais importantes para aqueles com testes automatizados.

Primeiro, inicie a criação de um conjunto de casos de teste manuais que verificam cada história de usuário tiver sido definida para a sprint. Porque não há nenhum código no início da sprint, um caso de teste deve descrever as ações de alto nível que mapeiam para as partes de uma história de usuário. Por exemplo, uma etapa em um caso de teste pode ser "como um usuário autenticado, avalia" Começando com um caso de teste manual permite que sua equipe definir rapidamente os testes de aceitação ideal antes de inicia a sprint.

Segundo, revisar e atualizar os testes de aceitação para refletir as experiências de usuário específico quando sua equipe tem o código que implementa as histórias de usuários em um sprint. Entretanto, se não desejar que sua equipe modificar o conjunto de testes de aceitação, importar os testes de um novo conjunto de teste e têm um ponto de partida para testes mais detalhados. Por exemplo, uma etapa em um caso de teste mais detalhada pode ser "Digite o nome na caixa de texto nome de usuário e clique no botão Login para fazer logon na conta bancária".

Em terceiro lugar, com base em seus testes de aceitação, crie testes de interface (UI) do usuário codificado usando-se a gravação de ação. Para obter mais informações, consulte Como: Gerar um teste UI codificados de uma gravação de ação. Testes codificados da interface do usuário podem gerar o código de limpo, se você criar etapas isolar a funcionalidade. Você pode executar testes automatizados de seu plano de teste, se você anexar um teste codificado de interface do usuário para os casos de teste manuais (para obter mais informações, consulte Como: Associar um teste automatizado de um caso de teste.)

Os testes manuais que foram definidos no início da sprint podem ajudá-lo a criar testes automatizados. Há um custo para os testes manuais e automatizados, porque precisam ser executado por uma pessoa testes manuais e testes automatizados precisem ser atualizado se tiver alterações de código ou do usuário. Para obter mais informações, consulte vs manuais automatizada testes posteriormente neste tópico.

Quem executa os casos de teste de aceitação?

Seus clientes, o proprietário do seu produto e sua equipe podem executar casos de teste de aceitação. Sua equipe deve executá-los sempre que possível para fornecer uma linha de base no conjunto de testes que precisam passar em um sprint. O proprietário do produto e o cliente também podem executar os testes de aceitação e podem exigir a verificação para concluir com êxito a sprint.

Sua equipe pode usar Microsoft Test Manager para executar cada caso de teste de aceitação e registrar uma captura de vídeo de tela de resultados do teste. Dessa forma, você pode obter um registro visual dos resultados do teste e também pode compartilhar os resultados com seus clientes. Isso é útil quando é difícil criar configurações necessárias (por exemplo, configurações de vários servidores).

Definir os casos de teste de aceitação junto com histórias de usuários

Você pode definir o direito de critérios de aceitação depois de definir as histórias de usuários. Definindo os testes de aceitação, você pode ajudar a sua equipe a entender os critérios de aceitação sprint atual do proprietário do produto e os clientes. Como o cliente precisa concordar com os testes de aceitação, é uma boa idéia criar casos de teste de aceitação antes da sprint inicia.

Teste de unidade

Os testes de unidade são testes automatizados que verifiquem a funcionalidade no nível do componente, classe, método ou propriedade. Testes de unidade são a base da automatizadas e testes de regressão que fornece a estabilidade a longo prazo e a sustentabilidade futura do projeto.

Como o teste ajuda a evoluir o design do meu aplicativo de unidade?

O processo de criação de unidade testa enquanto o código testado de construção ajuda a definir a forma do código. Você pode criar o código testável usando testes de unidade. Dificuldade em criar testes de unidade para o código é um sinal de que o código deve ser refatorado.

Como organizo meus testes de unidade?

Cada membro da equipe que escreve o código deve criar testes de unidade para os componentes que elas criam e verificar a unidade de testar o código no controle de versão dentro de um Visual Studio project. Os itens de trabalho do caso de teste de arquivos em uma suíte de testes de verificação de compilação que será executada durante cada compilação por meio da integração contínua e também dentro do conjunto de testes que verifica a história de usuário correspondente.

Como gerenciar a variação de testes de unidade sem ter que alterar o código de teste?

Variação em entradas de teste define a semelhança ou as diferenças entre os testes, como ele verifica a funcionalidade no código do projeto. Por exemplo, ao testar o componente de logon de um aplicativo Web, você pode fornecer vários tipos de senhas para criar uma conta de usuário. O sistema pode ter regras para a ordem e a combinação de tipos de caracteres que são usados.

Visual Studio Test Professional 2010fornece recursos para testes de unidade orientado a dados de escrita e testes codificados da interface do usuário. Para obter mais informações, consulte Como: Criar um teste de unidade orientado a dados e Como: Criar um teste de interface do usuário orientado a dados codificado.

Desenvolvimento orientado a testes e testes no início

Test-driven development (TDD) é uma disciplina do design e a programação, onde cada linha de código é gravada em resposta a um teste que o programador escreve antes de codificação. A idéia de se tornar o consumidor do código que você deseja implementar é muito poderosa e mantém uma expectativa realista de como o código deve ser usado e projetado.

O desenvolvedor TDD, funciona em vários pequenos incrementos. O desenvolvimento de cada incremento pequeno leva entre alguns minutos e poucas horas. Normalmente, a muitos desses incrementos compõem uma história de usuário. O desenvolvedor verificar nos testes e código quando a história de usuário funciona. O desenvolvedor funciona no ciclo do seguinte:

1. Escreva um teste automatizado que seja esperado a passar quando o incremento é gravado.

2. Verifique se que o novo teste falha para ajudar a certificar-se de que o teste funciona.

3. Escreva código que fará com que o teste passar.

4. Execute o teste para verificar se ele for bem-sucedido.

5. Também execute todos os outros testes na mesma área para certificar-se de que nenhum bug foram introduzido.

6. Refatorar o código, se necessário, para melhorar sua estrutura sem adicionar o comportamento. Execute novamente os testes para certificar-se de que o código ainda funciona.

7. Repita todas essas etapas até que uma história de usuário completa é implementada. Como os incrementos anteriores estão integrados em uma matéria completa, adicione os testes que verifiquem a história completa.

8. Verifique nos testes de unidade e o código de implementação.

Se você estiver interessado nos benefícios dos métodos de início do teste, você pode começar pela criação de manual (ou aceitação manual) testes. Esses testes manuais podem ser automatizados, criando um teste codificado de interface do usuário. (Para obter mais informações, consulte Como: Gerar um teste codificado UI gravando o aplicativo em teste.) Testes de integração para usam a unidade test framework em Visual Studio ALM também podem ser criados para verificar a funcionalidade que está sendo implementada. Os grupos de casos de teste que são criados no início de iteração são executados no início da iteração para tentar verificar a funcionalidade tanto encontrar bugs. Essas suítes de teste e casos de teste pode ser executados continuamente como testes de regressão durante o ciclo de vida do projeto. Continuar executar esses testes, você ajuda a garantir que os bugs que foram encontrados e a funcionalidade que foi verificada no início de iteração não são afetados pela mudança posteriormente no projeto.

Usar testes de unidade para a integração contínua

Os testes de unidade são criados enquanto estiver utilizando a prática antecipado de teste devem ser organizados dentro do conjunto de teste para texto sprint e o usuário atual. Esses testes de unidade podem ser promovidos para o plano de teste de todo o projeto e executar periodicamente pela equipe e dentro do ciclo de integração contínua. Testes de unidade também podem servir como base para a integração, carga e testes de desempenho.

Os testes de unidade são criados no início podem ser usados como parte da integração contínua. Para obter mais informações sobre como executar testes durante uma compilação, consulte Tarefa de TestToolsTask.

Usar a virtualização para gerenciar configurações de teste

Para executar testes de unidade, você pode criar um conjunto de ambientes são imagens gerenciadas do Hyper-V em Microsoft Test Manager. Para obter mais informações sobre como executar testes automatizados de um plano de teste usando Microsoft Test Manager, consulte Tarefa de TestToolsTask.

Manual em vez de testes automatizados

Manuais e automatizados de casos de teste são complementares. As equipes Agile se esforçar para ter mais automatizada casos de teste porque eles promovem freqüente ou executa teste contínuo. Para executar continuamente os testes, eles devem executar rapidamente e com freqüência, que é difícil de alcançar com testes manuais.

Há várias considerações devem ser feitas quando Decidindo sobre uma distribuição de manuais e automatizadas de casos de teste.

Como as habilidades na sua organização influenciar a sua distribuição dos tipos de teste?

O proprietário do produto ajuda a definir as histórias de usuários para o projeto e também deve contribuir para a criação de testes de aceitação. O proprietário do produto será provavelmente não ser produzir testes codificados, mas terá conhecimento significativo de domínio da empresa. Os casos de teste são definidos pelo proprietário do produto, portanto, será no nível do vocabulário de negócios e regras de negócios. Por exemplo, o proprietário de um produto em uma empresa de remessa será especificar diferentes meios de transporte que são suportados pela empresa (por exemplo, caminhão, trem, ar, sea ou uma combinação). O proprietário do produto pode então definir vários casos de teste diferentes possibilidades de exercício. Esses testes manuais, é importante especificar o número mínimo de testes que exercício as diferentes opções (no caso, o meio de transporte).

Membros da equipe que produzem código podem construir testes codificados de interface do usuário, que podem ser com base em testes manuais ou independente de qualquer outro teste. (Para obter mais informações, consulte How to: Generate a Coded UI Test by Recording the Application Under Test) os testes codificados da interface do usuário devem ser suportados pelos integrantes da equipe que têm a capacidade de gerenciar e desenvolver o código do projeto.

Quando você deve converter a testes manuais em testes automatizados ou criar automatizada testes desde o início?

Quando você espera executar testes repetidamente para manter a estabilidade de seu código, você pode construir testes automatizados. É importante considerar o esforço de criação porque o investimento de automação afeta os recursos da sua equipe de testes automatizados. Criação automatizada de testes quando o código tem pouca rotatividade resultados em um maior retorno sobre o investimento (ROI) porque há menos rotatividade de teste. No entanto, há valor na criação de automação antecipadamente porque o ajudará a descobrir problemas em que a lógica e o design. Em ambos os casos, os recursos necessários para suportar o código de teste automatizado deve ser considerado.

Depois de decidir que um conjunto de testes deve ser automatizado, mova-o para concluir a automação mais rápido possível, porque os benefícios da automação incluem a gerenciar a estabilidade do código. A estabilidade e o número de defeitos encontrados como a automação é escrita afetará o esforço necessário para concluir a automação. Finalmente, o equilíbrio entre manual em vez de testes automatizados é sobre a priorização dos tipos de testes que precisam ser criados e executados durante a vida do projeto.

Que tipos de testes são automatizados?

Testes Unitários

Testes de unidade verificar a funcionalidade no código ou por meio de um processo como, por exemplo, TDD. Testes de unidade são importantes porque eles ajudam a manter a estabilidade e dependências dentro do código. TDD também pode produzir o melhor design com dependências e definição de camada boa porque ajuda a entender o design do ponto de vista do consumidor de código.

Testes de carga

Você pode criar testes de carga que sejam baseiam em casos de teste automatizados existentes, ou você pode criar testes geram tipos específicos de cargas em aplicativos ou serviços. Para obter mais informações sobre como usar os controladores de agente de teste e teste de agentes para gerar simuladas cargas de testes, consulte Como: Executar um teste usando o controladores de teste e agentes de teste.

Para obter mais informações sobre o teste de carga com Visual Studio ALM, consulte a seguinte página no site da Microsoft: Noções básicas sobre testes de carga.

Testes de integração contínua

Você pode usar a integração contínua com Visual Studio ALM para ajudar a garantir que sempre que o código é desenvolvido e check-in, o que ele funciona corretamente com o código existente. Integração contínua é essencial como sua equipe e aumenta a sua base de código. Você pode definir um tipo de compilação inclui parâmetros de teste e especificar quais testes para executar depois de concluir a compilação. Para obter mais informações sobre como definir uma compilação que executa testes, consulte Definir uma compilação usando o modelo padrão.

Os tipos de testes que podem ser automatizadas?

Teste de configuração

Testes em vários ambientes instalados podem ser uma tarefa muito trabalhosa. Microsoft Test Managerfornece recursos da execução de suítes de testes em diferentes configurações por meio de máquinas virtuais ou máquinas físicas. Para obter mais informações sobre como executar testes e coletar dados em vários ambientes, consulte Configurando as máquinas de teste para executar testes ou coletar dados.

Testes de Interface do usuário

Visual Studio ALMpossui recursos de criação de testes automatizados diretamente na interface do usuário. Para obter mais informações sobre como criar testes de interface de usuário codificado, consulte Como: Criar um teste codificado de UI.

Testes de instalação

Você pode usar os recursos do laboratório de Microsoft Test Manager para configurar um grupo de configurações que você pode usar para verificar se os programas de instalação para os aplicativos funcionam como esperado.

Quais são as barreiras à automação?

Recursos da equipe

A criação de automação requer um subconjunto da equipe de teste para aprender a escrever código. Planeje incorrer a curva de aprendizado de criação de automação e o design do código de teste. Semelhante ao código de produção, o código de automação para suas metas desejados, como, por exemplo, manutenção, a facilidade de composição e a longevidade do design.

Para obter mais informações sobre como criar testes automatizados usando Visual Studio Test Professional 2010, consulte Criação automatizada de testes.

Variação de código

Código que está mudando freqüentemente é um alvo em movimento e terá efeitos em cascata no código de automação de teste, porque ele também precisa ser alterado. Para evitar esses efeitos em cascata, criando um código de automação de teste para componentes e interfaces que tenham menos possibilidade de alterar.

Design de código

O código de estruturas como o ASP.NET MVC e MVVM guiam membros da equipe para escrever código que tenha o isolamento que é necessário para verificar as diferentes partes do código. Código que está estreitamente ligado à interface do usuário é difícil testar porque ele pode exigir que o usuário interaja com os controles de interface do usuário.

Quais são os benefícios de casos de teste manuais?

Casos de teste manuais oferecem os seguintes benefícios:

• Ajuda que sua equipe encontrar bugs durante o processo de exploração de testes manuais.

• Manuais de casos de teste são fáceis de definir porque você pode definir o conjunto de etapas em qualquer abstração e definir o sucesso e falha em quaisquer termos que você gosta.

• É muito fácil começar a escrever casos de teste manuais no início do projeto antes de qualquer código foi escrito. Isso é importante durante o processo de definição de testes de aceitação.

• Se você usar Visual Studio Test Professional 2010, casos de teste pode ser composto de etapas compartilhadas, que ajudam a economizar tempo ao definir testes semelhantes e permitir que sua equipe reutilizar uma única versão de um subconjunto da Test. Usando as etapas compartilhadas também ajuda quando a alteração de casos de teste porque uma alteração às etapas compartilhadas é alterado automaticamente todos os casos de teste que use as etapas compartilhadas. Para obter mais informações sobre como criar e usar etapas compartilhadas, consulteHow to: Share Common Test Case Steps Using Shared Steps

• Casos de teste manuais pode servir como um meio de comunicação antecipada no projeto ou sprint.

• Casos de teste manuais pode servir como um meio de documentar um caso de teste automatizado, sem qualquer pessoa que revise o código.

• Se você usar Visual Studio ALM, executar os testes manuais pode reunir métricas de cobertura de código.

Quais são os deficits de casos de teste manuais?

Manuais de casos de teste executar as seguintes deficits:

• Definindo critérios de sucesso pode ser complicado porque ele depende da perspectiva e a linguagem usada na definição do teste. Alguns idiomas podem ser interpretados de maneira diferente e que pode deixar espaço para o erro.

• A execução de suítes de testes que incluem os casos de teste manuais requer uma pessoa fisicamente, siga as etapas de teste e os resultados do relatório. Esse processo pode consumir de muito tempo e, portanto, pode exigir um aumento do número de membros da equipe para executar testes ou um período maior de tempo para executar a suíte de testes. Usando Visual Studio Test Professional 2010, a equipe pode usar "Avançar rapidamente teste manual," nos quais ações são registradas durante o teste, que podem ser executados em um futuro teste é executado.

• Dependendo da estabilidade do código, irá variar o tempo e o esforço necessário para executar os testes. Como resultado, executar os testes manuais pode afetar o fluxo da equipe.

• O déficit maior é que os testes manuais são propensas a erro humano na detecção de um bug. Os testadores podem ver o bug na frente de seus olhos e não reconhecê-lo.

Quais são os benefícios de casos de teste automatizados?

Casos de teste automatizados oferecem as seguintes vantagens:

• Testes automatizados ajudam a manter a estabilidade e o ajudam a encontrar regressões podem ocorrer devido a alterações no código.

• Testes automatizados podem ser executados autônomos.

• Testes automatizados são softwares e podem ser projetados e compostos por outro código reutilizável. Isso torna os testes automatizados flexível e de fácil manutenção.

• Automação pode ser executada em várias configurações usando Microsoft Test Manager.

• Avaliação da cobertura de código pode ser obtidas quando são executados testes automatizados.

Quais são os deficits de casos de teste automatizados?

Casos de teste automatizados executar as seguintes deficits:

• Condições especiais que precisam ser considerados e implementado usando código. Como a automação é criada e condições adicionais de execução serão implementadas como elas são descobertas.

• Quando o código for alterado ou refatorado, pode haver efeitos em cascata que exigirão um esforço correspondente para alterar os testes automatizados afetados.

• Pode haver um impacto psicológico da sua equipe quando muitos testes de falha de causar alterações no código. Se esses testes são usados como sinalizadores, a equipe não poderá elevar os sinalizadores.

• Pode haver uma falsa sensação de segurança quando todos os testes passarem se os casos de teste não está testando as condições corretas. É importante manter as suítes de teste e garantir a que verificam os resultados e as condições corretas.

Os resultados do teste de emissão de relatórios

De uma perspectiva ágil, emissão de relatórios e consultas Team Foundation Server para o estado atual de qualidade, com base em bugs ou métricas agregadas, é a parte do loop de feedback que permite que a equipe de iteração e faça as alterações para o código, o plano de projeto e o plano de teste. Para obter mais informações, consulte Reportar de progresso do plano de teste.

Quais níveis de teste devem ser relatados à sua equipe?

Usando Visual Studio Test Professional 2010 e Team Foundation Server, sua equipe pode compreender o status de planejamento e execução de testes. Team Foundation Serverarmazena seus planos de teste, suítes de teste, casos de teste, os resultados de teste e todos os outros dados associados, são gerados em todo o processo de teste. Você pode visualizar o processo de testes e controle de qualidade, se você combinar Microsoft Test Manager com emissão de relatórios e o item de trabalho consultas de Team Foundation Server. Você pode usar Microsoft Test Manager a consulta de bugs em uma variedade de diferentes estados. Bugs que são marcadas como fixo por outros membros da equipe devem estar no estado resolvido. Você pode usar compilações subseqüentes para verificar os bugs corrigidos. Para obter informações sobre como verificar se um bug foi corrigido, consulte Como: Verifique se que um Bug é fixo usando Microsoft Test Manager.