Este artigo foi traduzido por máquina.

Visual Studio 2012

Teste para desenvolvimento contínuo

Larry Brader
Alan Cameron Cameron

Aplicativos da Web são normalmente atualizados ou prorrogados a cada poucas semanas (ou até mesmo dias) em reação às mudanças de necessidades comerciais e comentários dos clientes. Para apoiar o desenvolvimento contínuo, todos os aspectos do ciclo de desenvolvimento devem ser mais eficiente e mais leve do que os processos de desenvolvimento mais tradicionais. Por exemplo, é a natureza do software que mesmo a menor mudança requer tudo ser testadas de novo. Mas repetir um conjunto completo de testes manuais, todos os dias é impossível. Isso significa que testes eventualmente devem ser automatizados, mesmo se eles começam como explorações de manuais. Neste artigo vamos mostrar como Microsoft Visual Studio 2012 oferece suporte a testes em um ambiente de desenvolvimento contínuo.

O ciclo de desenvolvimento

Alguns projetos de software chegam ao fim quando o software é implantado e executado. Feedback é obtido das partes interessadas, melhorias ou extensões são planejadas e, eventualmente, uma nova versão é lançada, quando então o ciclo recomeça. Este processo, conhecido como o desenvolvimento do ciclo, é ilustrado na Figura 1.

Figura 1 O ciclo de desenvolvimento contínuo

Em um projeto de software tradicional, cada ciclo pode levar anos. O primeiro lançamento geralmente é rico em recursos, entregue em um DVD e instalado em máquinas locais dos usuários. Por outro lado, em uma aplicação Web moderna, a primeira versão pode ser mínima, mas extensões e melhorias são liberadas a cada poucas semanas (ou até mesmo dias).

Por exemplo, os gestores de um site de redes sociais podem tentar um novo recurso para uma semana, durante o qual eles monitoram como clientes usá-lo. No final do período experimental, ajustam-se os detalhes de como funciona o recurso.

Este ciclo muito mais rápido, é importante para as equipes de desenvolvimento a pensar sobre o ciclo de desenvolvimento como um todo processo. Em particular, eles precisam fazer cada atividade no ciclo mais eficiente, removendo quaisquer obstáculos que impedem o progresso em torno do laço.

As melhorias no processo de teste que discutimos aqui visam reduzir o tempo necessário para percorrer o ciclo de desenvolvimento. Em particular, essas novas ferramentas e técnicas visam reduzir o gargalo que testes tradicionalmente tem causado neste ciclo.

Teste do ciclo de desenvolvimento

O papel essencial do teste é demonstrar que histórias de usuário e outros requisitos foram implementados. A maneira mais eficaz de fazer isso é executar o aplicativo manualmente e exercício cada história assim como os usuários finais. Um testador experiente aplica-se uma variedade de estratégias para expor erros e explora todas as variantes e casos extremos do comportamento do aplicativo.

Quando alterações de código do aplicativo, é prudente testar tudo o que pode depender dele. Dependências de software normalmente formam uma trama complexa e erros notoriamente transformar-se em características que parecem independentes para o foco da atualização. Por esta razão, as equipes de desenvolvimento tradicional não como alteração de qualquer componente que foi escrito e testado. Como observado, a menor variação exige um completo teste novamente, então se você testar tudo manualmente, isso requer uma grande dose de esforço e recursos.

Em contraste, os inerentes ao desenvolvimento contínuo de ciclos curtos exigem que cada parte do software freqüentemente ser revisitado como sua funcionalidade é melhorada e alargada. Seria impossível testar manualmente cada característica que todos os dias. Ciclos curtos exigem testes automatizados, que substitua os testes manuais de código de programa. Você pode executar testes codificados rapidamente e tão frequentemente como você gosta.

Devem equipes de desenvolvimento contínuo de todos os seus testes de código e abandonar completamente o teste manual? Essa abordagem, por vezes, tem sido sugerida, mas na prática, há um compromisso eficaz, que funciona da seguinte maneira.

Teste histórias novas e substancialmente alteradas manualmente. Quando cada teste passa de forma consistente, crie versões automatizadas dos testes para essa história. Por conseguinte, embora o número total de testes gradualmente aumenta à medida que expande o produto, a carga de testes manuais permanece constante, porque testes manuais é algo que você faz apenas para relativamente novos recursos.

Na verdade, a maior parte dos testes codificados em um projeto de desenvolvimento contínuo típico são os testes de unidade, que são escritos juntamente com o código do aplicativo e teste de componentes individuais dentro do software, em vez de testar o comportamento de toda a aplicação. Teste de unidade é uma ferramenta poderosa para manter a estabilidade como a base de código é atualizada.

Figura 2 mostra uma transição gradual de manual para testes automatizados ao longo do tempo, juntamente com a expansão dos testes de unidade, juntamente com o código do aplicativo. O diagrama é uma imagem ideal; na prática, a maioria das equipes automatizar apenas alguma parte de seus testes manuais. Visual Studio 2012 (e outras versões) prevê também a automação parcial, que pode ser usada para acelerar os testes sem escrever código.

Figura 2 transição Ideal de Manual para testes automatizados ao longo do tempo

Testes no Visual Studio 2012

Vamos ver como o teste é suportado pelo Visual Studio 2012 e seus produtos associados, o Visual Studio Team Foundation Server (TFS) e Microsoft Test Manager (MTM).

Se sua especialidade é testar toda a aplicação, você estará mais interessado no suporte fornecido pela MTM. Se você é um desenvolvedor, você pode ter mais interesse no suporte para testes automatizados em Visual Studio 2012. No entanto, contínuo desenvolvimento exige um relacionamento mais estreito entre essas duas funções, e algumas equipes de dispensar a distinção por completo. Portanto, as ferramentas do Visual Studio 2012 são projetadas para integrar os diferentes estilos de testes, e eles oferecem suporte a um amplo espectro de práticas, as abordagens mais tradicionais através do desenvolvimento contínuo de teste.

Testes com Visual Studio 2012 automatizados

Teste automatizado inclui todos os tipos de testes que são definidos por escrito ou geração de código de programa. Você pode criar testes automatizados em Visual Studio 2012, onde inicialmente executá-los para depuração.

Quando o teste — e o código do aplicativo que ele testa — estão corretas, você verificar no teste, juntamente com o código do aplicativo. Do repositório de código fonte, tem captado pelo serviço de compilação e executar regularmente de acordo com as definições de compilação da sua equipe.

Testes de integração e unidade teste de unidade é uma das mais eficazes maneiras de manter um bug-free codebase através de sucessivas alterações em um aplicativo.

Um teste de unidade é um método que testa o método, classe ou componente maior do seu aplicativo em isolamento de outras partes, sistemas externos e recursos. Na prática, os desenvolvedores muitas vezes escrever testes de integração — isto é, os testes escritos em uma maneira similar para testes de unidade, mas que dependem de bancos de dados externos, sites da Web ou outros recursos. De qualquer forma, esses testes usam as mesmas ferramentas e infra-estrutura.

Em Visual Studio 2012, você pode escrever testes que usam qualquer um dos vários frameworks de teste, como o NUnit, xUnit e o padrão VSTest. Quando você codificou testes em qualquer um destes quadros, basta abrir a janela Test Explorer e escolha executar tudo. Os resultados estão resumidos na janela.

Teste de fundo é uma opção que eficientemente executa os testes em segundo plano sempre que você criar sua solução. Os testes que afetaram as alterações são executados primeiro. Isto significa que enquanto você trabalha, você sempre pode ver quais testes estão passando ou falha.

Isolar unidades por usando Fakes teste de unidade verdadeira significa desconectar a unidade sob teste o código, no qual ele é dependente. Isso tem uma série de vantagens. Se seu aparelho está sendo desenvolvido ou atualizado, ao mesmo tempo, como outras unidades, no qual ele é dependente, você pode testá-lo sem esperar que os outros para ser completo. Se reestruturar o aplicativo para usar este aparelho em uma maneira diferente, ou em um aplicativo diferente, os testes de ir com ele e não precisam mudar.

Visual Studio 2012 fornece dois mecanismos, chamados coletivamente de fakes, para desconectar uma unidade de suas dependências. Chamadas a partir de sua unidade para métodos fora do seu limite podem ser tratadas por pequenos pedaços de código que você fornecer. Por exemplo, você pode definir um calço que intercepta chamadas para qualquer método externo como DateTime. Now. Porque ele sempre recebe a mesma resposta de calço, seu aparelho irá demonstrar o mesmo comportamento toda vez que ele é chamado. Você também pode definir stubs, que fornecem o espaço reservado para implementações de métodos em assemblies que não tenha sido carregados.

Testes de carga e desempenho Visual Studio Ultimate 2012 oferece instalações de teste específico para testes de desempenho e estresse. Um aplicativo pode ser instrumentado e conduzido a fim de medir seu desempenho sob cargas especificados. Aplicativos da Web podem ser conduzidos com várias solicitações, simulando a muitos usuários.

Codificados testes de interface do usuário UI codificados testes permitem que você executar o aplicativo e gerar o código que impulsiona sua interface do usuário. Visual Studio 2012 inclui ferramentas especializadas para criação e edição de testes, e você também pode editar e adicionar o código a mesmo. Por exemplo, você pode criar um procedimento simples para comprar algo em um site da Web e, em seguida, editar o código para adicionar um loop que muitos itens de compra.

Testes são particularmente úteis, onde não há validação ou outra lógica da interface do usuário — em uma página da Web, por exemplo. Você pode usá-los como testes de unidade para a interface do usuário ou como testes de integração para todo o aplicativo.

Manual de testes com o Gerenciador de teste Microsoft

Teste manual pode ser planejada ou exploratório. Você executar manual testes, com a ajuda de MTM. Normalmente, são realizados testes em versões do seu aplicativo que foram construídos a partir de check-in código.

Normalmente, testes manuais estão ligados a histórias de usuário (ou itens de lista de pendências de produto ou outros requisitos), e os resultados dos testes são exibidos no relatório no painel de projeto. Isso significa que cada­pode-se ver rapidamente quais histórias foram implementadas com êxito.

Teste exploratório teste exploratório significa simplesmente executando o aplicativo para experimentá-lo. No entanto, por que você precisa de MTM para ajudá-lo a executá-lo?

MTM pode gravar suas ações, comentários e imagens enquanto você trabalha. Se você decidir criar um relatório de bug, toda esta informação é automaticamente adicionada a ele, tornando desnecessário para você adicionar uma descrição precisa de como reproduzir o bug. Figura 3 mostra um exemplo da janela teste exploratório de MTM juntamente com um aplicativo da Web que está sendo testado.

Figura 3 uma imagem de gravação e fazer as anotações na janela de teste exploratória

MTM também pode instrumentar o aplicativo em si, tanto no cliente e servidor, os dados de registro de evento que podem ser usados para depurar o aplicativo. Este dados é automaticamente anexados ao seu relatório de bug.

Quando o bug é corrigido, você vai querer repetir as etapas você tomou na exploração para verificar a correção. Para ajudar com isso, você pode gerar um caso de teste da sessão exploratória, em que você incluir as etapas relevantes.

Planejado de teste com casos de teste casos de teste são testes manuais que você define como uma série de etapas que o testador deve executar. Figura 4 mostra as etapas definidas em um caso de teste.

Figura 4 definindo as etapas e os resultados esperados em um caso de teste

Casos de teste fornece uma ótima maneira de esclarecer o que os usuários precisam. No início do sprint, quando você está discutindo histórias ou requisitos com os usuários e demais partes interessadas, você pode usar as etapas como um exemplo preciso do que os usuários será capazes de fazer até ao final do sprint. Cada caso de teste é apenas uma instância do requisito, e assim cada requisito é associado geralmente com mais de um caso de teste. Por exemplo, se o requisito é ser capaz de comprar sorvete, um caso de teste irá detalhar os passos para comprar um sabor particular. Você criaria um outro caso de teste para descrever uma mistura de sabores de compra. O princípio orientador da discussão com as partes interessadas deve ser: "Quando você com êxito pode executar esses casos de teste, então vamos considerar a história a ser implementado."

No TFS, tanto as histórias ou requisitos e casos de teste são representados por itens de trabalho. Você pode vinculá-los juntos para que o progresso de um requisito pode ser rastreado pelos resultados dos testes.

Quando você executa um caso de teste, as etapas são exibidas ao lado da tela. Você marcar cada etapa enquanto você executa o aplicativo. No final, você marcar se o teste passou ou falhou.

Apenas como com teste exploratório, suas ações, comentários, imagens e aplicativos são registados assim você pode criar um relatório de bugs muito rapidamente.

Uma grande vantagem do uso de etapas é que ajudar alguém repetir o teste de forma confiável, mesmo se eles não estão familiarizados com o aplicativo. Quando um teste é repetido, você pode ter certeza que se ele passa ou falha, ele não é simplesmente porque o teste foi executado de forma diferente da última vez.

Você também pode gerar um caso de teste planeado uma sessão experimental. Fazer isso ajuda a garantir que você sempre executa o teste usando as mesmas ações.

Automatizando testes manuais

Automatizar uma parte substancial dos testes manuais é essencial para minimizar o tempo gasto pelo teste do ciclo de desenvolvimento. Visual Studio 2012 oferece suporte a automação de várias maneiras.

Gravação/reprodução você pode executar novamente um caso de teste semi-automática. Os tempos de segundo e subseqüentes que executar um teste, MTM repete os pressionamentos de tecla e os gestos que você usou na primeira execução. Tudo o que você tem a fazer é verificar que os resultados que você vê de acordo com as expectativas detalhadas nas etapas.

Reprodução faz testes manuais mais rápido e mais confiável. Também torna possível distribuir a carga de teste entre colegas que não pode ser completamente familiarizado com o aplicativo.

Mesmo se você não automatizar totalmente um teste, reprodução rápida e confiável ajuda a reduzir o desenvolvimento de tempo de ciclo. Esse recurso não requer Visual Studio 2012 ser instalado e não envolve escrever código.

Geração de testes de interface do usuário codificado você pode gerar um teste de interface do usuário codificado totalmente automatizado de um caso de teste manual gravado executado. O código gerado executa as mesmas ações que o teste manual. Usando um editor especial no Visual Studio 2012, você também pode estender o teste para verificar os resultados e generalizá-lo para repetir o teste para entrada de dados diferente. Figura 5 mostra o editor especial.

Figura 5 edição de ações de interface do usuário Visual Studio 2012

Vinculando os casos de teste para testar métodos você pode vincular um caso de teste para qualquer método de teste, mesmo que ainda não foi gerado a partir de seu ensaio. O resultado da execução do teste será relatado como se você tivesse executado as etapas manuais. Normalmente você ligaria o caso de teste para um teste de integração que realiza as mesmas ações que o teste manual, mas conduz a lógica de negócios diretamente, em vez de usar a interface do usuário.

Esta abordagem tem a vantagem de que as alterações no layout da interface do usuário não invalidam o teste. Também é útil quando a equipe de desenvolvimento já criou um teste de integração adequado.

Lab Management

Quando você testar um aplicativo, a primeira coisa que você precisa é uma máquina para executá-lo. Na verdade, a maioria dos aplicativos precisa hoje várias máquinas. Para um ambiente de teste Realista, você pode, por exemplo, precisa instalar um servidor Web, um servidor de banco de dados e um navegador do cliente em computadores separados. Figura 6 ilustra tal ambiente.

Figura 6 exemplo ambiente de laboratório para testar um Site de vendas

Além da instalação básica, você também vai querer instalar os agentes que podem coletar os dados de evento que foi mencionados anteriormente na seção "Teste exploratório".

MTM um recurso chamado Lab Center faz tudo isso direto. Centro de laboratório permite-lhe definir os ambientes de laboratório. Um ambiente de laboratório é um conjunto de máquinas que será usado como um grupo para fins de teste.

Além de lidar com a atribuição das máquinas (para que você acidentalmente não usa uma máquina que executa testes de outra pessoa), o centro de laboratório também instala os agentes necessários. Lab Center fornece um console onde você pode rapidamente logon qualquer uma das máquinas em um ambiente.

Lab Center também é bom para criar e gerenciar máquinas virtuais (VMs). Você pode criar um ambiente virtual, instalar o software de plataforma relevante e, em seguida, armazenar uma cópia da biblioteca dele que pode ser usado sempre que você deseja testar seu aplicativo. Tudo o que você tem a fazer é reinstantiate uma cópia limpa do ambiente e instale as novas versões dos componentes do aplicativo. Você também pode automatizar este processo de implantação.

Usando o centro de laboratório — e, em particular, aproveitando sua facilidade com VMs — pode diminuir significativamente o tempo de instalação de laboratório em comparação comparado abordagens mais tradicionais para a manutenção de um laboratório. Lab Center é um contribuinte significativo para reduzir o tempo gastado em cada ciclo de desenvolvimento.

Teste no TFS automatizado

Testes automatizados são realizados inicialmente em Visual Studio 2012 no computador de um desenvolvedor. Depois que o código tem sido check-in para o repositório de origem, há um número de maneiras em que os testes código integrado podem ser executados pelo serviço de compilação.

Compilações periódicas o serviço de compilação compila o código e executa os testes. Você pode criar definições de compilação para especificar quais testes devem ser executados, e você pode especificar quando devem executar. Por exemplo, você pode executar um conjunto de testes em uma base contínua e executar um conjunto mais amplo de todas as noites.

Construir resultados podem ser exibidos em Visual Studio 2012 e também estão disponíveis a partir do seu projeto TFS Web service. E-mails podem notificá-lo de falhas.

Implantação de laboratório como descrito anteriormente, você pode atribuir um grupo de máquinas de laboratório para um teste usando o centro de laboratório. Definindo uma compilação de laboratório, você pode automatizar esse processo. Quando a compilação é disparada — por exemplo, quando código é verificado em, ou em um determinado momento do dia — a compilação começa por compilar todo o código de aplicativo e teste. Se esta for bem sucedida, um ambiente de laboratório é atribuído, e se é um ambiente virtual, ele pode ser definido de volta para um estado fresco. Seus componentes de aplicativo, em seguida, são implantados para as máquinas corretas, e os testes estão instalados na máquina do cliente designado de onde eles dirigem a aplicação.

Os testes podem ser testes automatizados de qualquer espécie, mas normalmente você usar este tipo de compilação para realizar testes de integração de grandes ou testes de toda a aplicação.

Se os testes forem vinculados para casos de teste, os resultados serão registrados contra os requisitos ou histórias de usuário relacionados e exibidos nos relatórios de progresso do projeto.

Reports

TFS fornece uma série de gráficos e tabelas que mostram o andamento de um projeto. Você pode visualizá-los individualmente ou em painéis de controle do projeto. Entre os relatos são vários relacionados aos ensaios.

Por exemplo, o relatório de Status do teste de história de usuário, ilustrado na Figura 7, mostra a lista de artigos que você está trabalhando no sprint atual. Além do trabalho de desenvolvimento realizado para cada história, o gráfico mostra o sucesso ou o fracasso de seus testes associados. Se falhas foram descobertas durante a execução dos testes, os relatórios de bug resultantes também estão ligados aos requisitos.

Relatório de Status de teste do Figura 7 User Story

Os resultados no gráfico vêm de ambos os testes mais recentemente a execução manuais e executa o teste automatizado.

O relatório de progresso do plano, ilustrado na Figura 8, mostra como muitos casos de teste foram criados para o sprint atual e quantos foram executados.

Figura 8 teste plano relatório de progresso para um Sprint

Algumas equipes como criar casos de teste no início de cada sprint, como um destino para a equipe. Todos os testes devem ser verdes no final do sprint.

Visual Studio 2012 e desenvolvimento contínuo

Agora, você tem alguma familiaridade com o intervalo do 2012 Visual Studio teste recursos, a partir de testes de unidade para toda a aplicação de testes manuais.

O desenvolvimento de ciclo de desenvolvimento de vistas como apenas um meio de um processo que também incorpora o feedback de operações. Dependendo do contexto, o ciclo de desenvolvimento será curto ou longo. Se você está desenvolvendo uma central nuclear, espero que você vai passar em torno do laço muito lentamente. Se você estiver executando um aplicativo da Web, você pode ir em torno dele todos os dias. Ciclos lentos e rápidos são igualmente válidos e adequados para diferentes tipos de sistemas. Ambas incorporam a necessidade de testes, em diferentes graus. Se o ciclo rápido de desenvolvimento contínuo é apropriado para o seu projeto, é importante reduzir o tempo que leva para executar cada ação no loop. Você provavelmente vai também fazer menos distinção entre as funções de desenvolvedor e testador do que em projetos que trabalham em uma medida mais ritmo.

As ferramentas disponíveis no Visual Studio 2012 podem reduzir substancialmente a quantidade de tempo que leva para testar seu aplicativo. Aqui estão alguns pontos a serem lembrados:

• Ambientes de laboratório limpo podem ser configurados rapidamente e automaticamente, especialmente por meio de VMs. Aproveite o centro de laboratório.
• Gravação de ações durante a exploratória e planejado de testes permite criar relatórios de bug rápida e confiável, reduzindo a chance de que um bug desaparecerá quando alguém tenta reproduzi-lo.
• Você pode implementar uma transição gradual de testes manuais para testes automatizados. Os testes automatizados manipular a maior parte dos testes de regressão com foco em novos e atualizados contos de testes manuais.
  • De testes exploratórios, você pode gerar casos de teste manuais repetitivos.
  • Você pode gravar o teste é executado e reproduzi-los rapidamente e confiantemente.
  • Você pode gerar testes de execuções de teste.Como alternativa, você pode vincular os testes de integração codificado separadamente para casos de teste.

Figura 9 mostra a progressão de testes exploratórios para testes automatizados.

Figura 9 teste progressão

• Casos de teste pode ajudá-lo a descrever suas histórias de usuário com precisão. Você pode trabalhar com os acionistas para gravar as etapas para reduzir mal-entendidos sobre o que fazem as histórias.
• Testes estão ligadas aos requisitos (ou histórias de usuários ou itens de lista de pendências de produto) para que você pode ver relatórios abrangentes sobre até que ponto as necessidades dos usuários foram implementadas — não simplesmente em termos de trabalho feito nelas, mas se eles são bem sucedidos. Os testes fornecem a meta para a equipe de desenvolvimento em cada sprint.
• Requisitos e casos de teste podem ser vinculados a storyboards no PowerPoint, documentos de requisitos ou modelos de linguagem de modelagem unificada. Quando você faz alterações no storyboard, você pode rastrear as mudanças necessárias para os testes.
• Um casos de teste juntos de links de plano de teste, código, requisitos, ambientes de teste e configurações de teste e o projeto de equipe. Se a equipe passa alguns meses trabalhando em outra coisa, antes de retornar para melhorar um produto, é fácil reconstruir tudo que é necessário para o teste.

Demos a você uma visão geral de como o Visual Studio 2012 se encaixa com o ciclo de desenvolvimento. Agora, você deve entender porque você precisa de uma abordagem simplificada para testes e que ferramentas Visual Studio 2012 oferece para ajudá-lo a cumprir essa meta. Se você quiser mais informações, leia "Testando para contínua entrega com Visual Studio 2012 RC" na biblioteca MSDN em bit.ly/KHdOq4. É um guia detalhado que cobre todos os aspectos da infra-estrutura de teste fornecido pelo Visual Studio 2012. Relacionados com artigos incluem "Verificar código por usando testes de unidade", em bit.ly/dz5U3m e "Testando o aplicativo" no bit.ly/NbJ01v.

Larry Brader tem sido um testador sênior sobre os padrões de Microsoft & equipe de práticas para os últimos anos. Antes que ele trabalhou como desenvolvedor e testador de tecnologias militares e médicos.

AlanCameron Wills é um gravador de programação da divisão de desenvolvedores da Microsoft. Em vidas passadas, ele tem sido um desenvolvedor, arquiteto de software e consultor em métodos de desenvolvimento.

Agradecemos aos seguintes especialistas técnicos pela revisão deste artigo: Howie Hilliker, Katrina Lyon-Smith, Peter Provost e Rohit Sharma