Pergunta

Não acredito que sou a primeira pessoa a passar por esse processo de pensamento, então gostaria de saber se alguém pode me ajudar com isso.

Situação atual:os desenvolvedores escrevem um site, as operações o implantam.Uma vez implantado, um desenvolvedor faz um teste de fumaça para garantir que a implantação ocorreu sem problemas.

Para mim, isso parece errado, significa essencialmente que são necessárias duas pessoas para implantar um aplicativo;no nosso caso, essas duas pessoas estão em lados opostos do planeta e os fusos horários entram em jogo, causando estragos.Mas permanece o fato de que os desenvolvedores sabem qual é o conjunto mínimo de testes e isso pode mudar com o tempo (especialmente para a parte de serviço web do nosso aplicativo).As operações, com todo o respeito a elas (e elas mesmas diriam isso), são apertadores de botões que precisam de um conjunto de instruções a serem seguidas.

A solução manual é documentarmos os casos de teste e as operações seguirem esse documento sempre que forem implantadas.Isso parece doloroso, além disso, eles podem estar implantando versões diferentes em ambientes diferentes (especificamente UAT e Produção) e podem precisar de um conjunto diferente de instruções para cada um.

Além disso, um dos nossos planos para um futuro próximo é ter um ambiente de implantação diária automatizado, então teremos que instruir um computador sobre como implantar uma determinada versão do nosso aplicativo.Eu gostaria muito de acrescentar instruções sobre como testar o aplicativo com fumaça.

Agora os desenvolvedores são melhores em documentar instruções para computadores do que para pessoas, então a solução óbvia parece ser usar uma combinação de nUnit (eu sei que estes não são testes de unidade em si, mas é um teste criado para esse propósito runner) e as APIs Watin ou Selenium para executar as etapas óbvias do navegador e chamar o serviço da web e explicar ao pessoal de operações como executar esses testes de unidade.Eu posso fazer isso;Eu já fiz isso principalmente.

Mas não seria bom se eu pudesse tornar esse processo ainda mais simples?

Neste ponto, o pessoal de operações e o computador terão que saber qual conjunto de testes está relacionado a qual versão do aplicativo e informar ao executor nUnit para qual URL base ele deve apontar (digamos, www.example.com = v3. 2 ou test.example.com = v3.3).

Não seria melhor se o próprio executor de teste tivesse uma maneira de fornecer um URL base e permitir que ele baixasse um arquivo zip, descompacte-o e edite um arquivo de configuração automaticamente antes de executar qualquer acessório de teste encontrado nele?

Existe um aplicativo de código aberto que faria isso?Existe a necessidade de um?Existe uma solução usando algo diferente do nUnit, talvez Fitnesse?

Para que conste, estou analisando primeiro as ferramentas baseadas em .NET porque a maioria dos desenvolvedores são principalmente desenvolvedores .NET, mas não somos casados ​​com isso.Se tal ferramenta existir usando outras linguagens para escrever os testes, nos adaptaremos com prazer, desde que haja um executor de testes que funcione no Windows.

Foi útil?

Solução 7

Depois de muito tempo perdido tentando criar uma solução mais fácil, finalmente ensinamos à equipe de operações como usar o runner Gui do NUnit.Isso foi mais fácil do que o esperado e está funcionando bem.

Outras dicas

Trabalhei como redator de testes de fumaça para um aplicativo asp.net.Nós costumavamos Teste Rápido Pro, a automação das execuções de testes foi feita com Centro de Qualidade (era chamado de Diretor de Teste.).Isso envolveu escrever centenas de scripts de teste que automatizam a interação de um navegador da Web com o aplicativo da Web.Esses testes foram usados ​​para validar uma compilação antes de implementá-la em nossos servidores de produção.O Quality Center permite definir um "conjunto" de máquinas de teste para permitir a execução de uma grande lista de scripts de teste de maneira multithread.

Um teste de fumaça mais simplista seria registrar todos os erros/exceções que o aplicativo produz e executar um spider no sistema.Isso não obterá uma cobertura de código muito "profunda", mas os testes de fumaça não se destinam à cobertura profunda de código.Esse log de erros deve ser separado do aplicativo de produção para lidar com os erros à medida que eles surgem.Os bugs sempre escaparão e, infelizmente, os melhores testadores serão seus usuários.

Eu usei o Selenium no passado para fazer esse tipo de teste de fumaça para implantações na web.Você pode escrever um conjunto de scripts de teste e depois executá-los no mesmo site em ambientes diferentes.

Também pensei um pouco nesta sequência e propus adotar uma abordagem declarativa para implantação e verificação. Veja aqui minhas ideias,

http://jimblogdog.blogspot.co.uk/2010/10/introduzindodeclarative-deployment.html

Também criei alguns plugins para meu projeto de código aberto Wolfpack para automatizar todo esse processo.Essencialmente, você empacota seus "testes de fumaça de implantação" como um pacote NuGet e os publica em seu feed NuGet privado.O Wolfpack detectará automaticamente a nova versão do pacote e fará o download dele, junto com o pacote NUnit.Runner NuGet e descompactará todos os arquivos.Em seguida, ele executará silenciosamente seus testes usando o executor do console NUnit e analisará os resultados em um alerta que você pode receber por e-mail, rosnado, hipchat etc.

http://wolfpack.codeplex.com/

http://wolfpackcontrib.codeplex.com/wikipage?title=NUnitDeploymentPublisher

Telerik tem algumas ferramentas de teste de UI gratuitas e não gratuitas que podem ser executadas de forma automatizada por qualquer pessoa que possa ajudar com isso também.

Não sei qual VCS você está usando, mas você poderia escrever uma solução que extraia um arquivo de configuração específico da versão do VCS por meio de um serviço intermediário.

Você pode escrever um script PowerShell ou um aplicativo que baixe o arquivo de configuração de um serviço web ou aplicativo web, passando o URL de teste como parâmetro.Os servidores ou aplicativo estariam rodando em uma máquina com acesso ao VCS, para que pudesse retornar o conteúdo do arquivo.Depois de recuperado, o script ou aplicativo poderá iniciar os testes.

Normalmente, seus testes nUnit são suficientes para que, se todos forem aprovados, a base de código esteja funcionando bem.Se você implantar o código, passando nos testes nUnit, e encontrar uma falha no site, será necessário adicionar um nUnit adicional que também falha, pelo mesmo motivo.Então, ao corrigir seu código de forma que o nUnit esteja passando, você saberá que corrigiu o problema do código implantado.Por esse motivo, a maioria dos sistemas de construção automática podem ser configurados para executar automaticamente todos os testes nUnit primeiro e depois 'falhar' na construção se algum dos testes falhar.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top