Automação de teste - Test automation

Em teste de software , a automação de teste é o uso de software separado do software que está sendo testado para controlar a execução dos testes e a comparação dos resultados reais com os resultados previstos. A automação de teste pode automatizar algumas tarefas repetitivas, mas necessárias, em um processo de teste formalizado já implementado ou realizar testes adicionais que seriam difíceis de fazer manualmente. A automação de teste é crítica para entrega contínua e teste contínuo .

Existem muitas abordagens para a automação de teste, no entanto, abaixo estão as abordagens gerais amplamente utilizadas:

• Teste de interface gráfica do usuário . Uma estrutura de teste que geraeventos da interface do usuário , como pressionamentos de tecla e cliques do mouse, e observa as alterações que resultam na interface do usuário, para validar se o comportamento observável do programa está correto.
• Teste conduzido por API . Uma estrutura de teste que usa uma interface de programação para o aplicativo para validar o comportamento em teste. Normalmente, o teste orientado por API ignora totalmente a interface do usuário do aplicativo. Também pode ser testar interfaces públicas (geralmente) para classes, módulos ou bibliotecas são testados com uma variedade de argumentos de entrada para validar se os resultados que são retornados estão corretos.

Uma maneira de gerar casos de teste automaticamente é o teste baseado em modelo por meio do uso de um modelo do sistema para geração de casos de teste, mas a pesquisa continua em uma variedade de metodologias alternativas para fazer isso. Em alguns casos, a abordagem baseada em modelo permite que usuários não técnicos criem casos de teste de negócios automatizados em inglês simples, de forma que nenhuma programação de qualquer tipo seja necessária para configurá-los para vários sistemas operacionais, navegadores e dispositivos inteligentes.

O que automatizar, quando automatizar ou mesmo se alguém realmente precisa de automação são decisões cruciais que a equipe de teste (ou desenvolvimento) deve tomar. Uma revisão da literatura multi-vocal de 52 profissionais e 26 fontes acadêmicas descobriu que cinco fatores principais a serem considerados na decisão de automação do teste são: 1) Sistema em teste (SUT), 2) os tipos e números de testes, 3) ferramenta de teste, 4) tópicos humanos e organizacionais e 5) fatores transversais. Os fatores individuais mais frequentes identificados no estudo foram: necessidade de teste de regressão, fatores econômicos e maturidade do SUT.

Uma tendência crescente no desenvolvimento de software é o uso de estruturas de teste de unidade , como as estruturas xUnit (por exemplo, JUnit e NUnit ), que permitem a execução de testes de unidade para determinar se várias seções do código estão agindo conforme o esperado sob várias circunstâncias. Os casos de teste descrevem os testes que precisam ser executados no programa para verificar se o programa é executado conforme o esperado.

A automação de teste, principalmente usando teste de unidade, é um recurso-chave da programação extrema e do desenvolvimento ágil de software , onde é conhecido como desenvolvimento orientado a teste (TDD) ou desenvolvimento test-first. Os testes de unidade podem ser escritos para definir a funcionalidade antes que o código seja escrito. No entanto, esses testes de unidade evoluem e são estendidos à medida que a codificação avança, os problemas são descobertos e o código é submetido a refatoração. Somente quando todos os testes para todos os recursos exigidos passam, o código é considerado completo. Os proponentes argumentam que ele produz software que é mais confiável e menos caro do que o código testado por exploração manual. É considerado mais confiável porque a cobertura do código é melhor e porque é executado constantemente durante o desenvolvimento, em vez de uma vez no final de um ciclo de desenvolvimento em cascata . O desenvolvedor descobre defeitos imediatamente após fazer uma alteração, quando é mais barato consertar. Finalmente, a refatoração de código é mais segura quando o teste de unidade é usado; transformar o código em uma forma mais simples com menos duplicação de código , mas comportamento equivalente, tem muito menos probabilidade de introduzir novos defeitos quando o código refatorado é coberto por testes de unidade.

Algumas tarefas de teste de software (como testes extensivos de regressão de interface de baixo nível ) podem ser trabalhosas e demoradas para serem executadas manualmente. Além disso, uma abordagem manual pode nem sempre ser eficaz na localização de certas classes de defeitos. A automação de teste oferece a possibilidade de realizar esses tipos de teste com eficácia.

Uma vez desenvolvidos os testes automatizados, eles podem ser executados rápida e repetidamente. Muitas vezes, esse pode ser um método econômico para o teste de regressão de produtos de software com longa vida útil de manutenção. Mesmo pequenos patches ao longo da vida útil do aplicativo podem causar a falha de recursos existentes que estavam funcionando anteriormente.

Embora a reutilização de testes automatizados seja valorizada pelas empresas de desenvolvimento de software, essa propriedade também pode ser vista como uma desvantagem. Isso leva ao chamado "Paradoxo dos Pesticidas", onde scripts executados repetidamente param de detectar erros que vão além de seus frameworks. Nesses casos, o teste manual pode ser um investimento melhor. Essa ambigüidade mais uma vez leva à conclusão de que a decisão sobre a automação de testes deve ser feita individualmente, levando em consideração os requisitos e peculiaridades do projeto.

As ferramentas de automação de teste podem ser caras e geralmente são empregadas em combinação com o teste manual. A automação de teste pode ser econômica a longo prazo, especialmente quando usada repetidamente em testes de regressão . Um bom candidato para automação de teste é um caso de teste para o fluxo comum de um aplicativo, pois ele deve ser executado (teste de regressão) toda vez que um aprimoramento é feito no aplicativo. A automação de teste reduz o esforço associado ao teste manual. O esforço manual é necessário para desenvolver e manter verificações automatizadas, bem como revisar os resultados dos testes.

Em testes automatizados, o engenheiro de teste ou pessoa de garantia de qualidade de software deve ter habilidade de codificação de software, uma vez que os casos de teste são escritos na forma de código-fonte que, quando executado, produz saída de acordo com as afirmações que fazem parte dele. Algumas ferramentas de automação de teste permitem que a criação de teste seja feita por palavras-chave em vez de codificação, o que não requer programação.

Teste de API

O teste de API também está sendo amplamente usado por testadores de software, pois permite que eles verifiquem os requisitos independentemente de sua implementação de GUI, normalmente para testá-los mais cedo no desenvolvimento e para garantir que o próprio teste adira aos princípios de código limpo, especialmente o princípio de responsabilidade única. Envolve o teste direto de APIs como parte do teste de integração , para determinar se atendem às expectativas de funcionalidade, confiabilidade, desempenho e segurança. Como as APIs não possuem GUI , o teste da API é realizado na camada de mensagem . O teste de API é considerado crítico quando uma API serve como a interface primária para a lógica do aplicativo .

Teste contínuo

O teste contínuo é o processo de execução de testes automatizados como parte do pipeline de entrega de software para obter feedback imediato sobre os riscos de negócios associados a um candidato a lançamento de software. Para o Teste Contínuo, o escopo do teste se estende desde a validação de requisitos ascendentes ou histórias de usuários até a avaliação dos requisitos de sistema associados aos objetivos de negócios abrangentes.

Teste de interface gráfica do usuário (GUI)

Muitas ferramentas de automação de teste fornecem recursos de gravação e reprodução que permitem aos usuários registrar interativamente as ações do usuário e reproduzi-las inúmeras vezes, comparando os resultados reais aos esperados. A vantagem dessa abordagem é que ela requer pouco ou nenhum desenvolvimento de software . Essa abordagem pode ser aplicada a qualquer aplicativo que tenha uma interface gráfica com o usuário . No entanto, a confiança nesses recursos apresenta grandes problemas de confiabilidade e manutenção. Voltar a rotular um botão ou movê-lo para outra parte da janela pode exigir que o teste seja regravado. Gravar e reproduzir também frequentemente adicionam atividades irrelevantes ou registram incorretamente algumas atividades.

Uma variação desse tipo de ferramenta é o teste de sites. Aqui, a "interface" é a página da web. No entanto, essa estrutura utiliza técnicas totalmente diferentes porque está renderizando HTML e ouvindo eventos DOM em vez de eventos do sistema operacional. Navegadores sem cabeça ou soluções baseadas no Selenium Web Driver são normalmente usados ​​para essa finalidade.

Outra variação desse tipo de ferramenta de automação de teste é para testar aplicativos móveis. Isso é muito útil devido ao número de tamanhos, resoluções e sistemas operacionais diferentes usados ​​em telefones celulares. Para esta variação, um framework é usado para instanciar ações no dispositivo móvel e reunir os resultados das ações.

Outra variação é a automação de teste sem script que não usa registro e reprodução, mas em vez disso constrói um modelo do aplicativo e permite que o testador crie casos de teste simplesmente inserindo parâmetros e condições de teste, o que não requer habilidades de script.

Testando em diferentes níveis

A pirâmide de automação de teste proposta por Mike Cohn

Uma estratégia para decidir a quantidade de testes a automatizar é a pirâmide de automação de testes. Essa estratégia sugere escrever três tipos de testes com granularidade diferente. Quanto mais alto o nível, menor é a quantidade de testes a serem escritos.

Níveis

• Como uma base sólida, o teste de unidade fornece robustez aos produtos de software. Testar partes individuais do código torna mais fácil escrever e executar os testes.
• A camada de serviço se refere ao teste dos serviços de um aplicativo separadamente de sua interface de usuário; esses serviços são qualquer coisa que o aplicativo faça em resposta a alguma entrada ou conjunto de entradas.
• No nível superior, temos o teste de IU que tem menos testes devido aos diferentes atributos que o tornam mais complexo de executar, por exemplo, a fragilidade dos testes, onde uma pequena mudança na interface do usuário pode interromper muitos testes e adicionar manutenção esforço.

Abordagem de framework em automação

Uma estrutura de automação de teste é um sistema integrado que define as regras de automação de um produto específico. Este sistema integra as bibliotecas de funções, fontes de dados de teste, detalhes de objetos e vários módulos reutilizáveis. Esses componentes atuam como pequenos blocos de construção que precisam ser montados para representar um processo de negócios. A estrutura fornece a base da automação de teste e simplifica o esforço de automação.

A principal vantagem de uma estrutura de premissas, conceitos e ferramentas que fornecem suporte para testes automatizados de software é o baixo custo de manutenção . Se houver alteração em qualquer caso de teste , apenas o arquivo do caso de teste precisará ser atualizado e o script do driver e o script de inicialização permanecerão os mesmos. Idealmente, não há necessidade de atualizar os scripts em caso de alterações no aplicativo.

Escolher a estrutura / técnica de script certa ajuda a manter custos mais baixos. Os custos associados ao script de teste são devidos aos esforços de desenvolvimento e manutenção. A abordagem de script usada durante a automação de teste tem efeito sobre os custos.

Várias técnicas de framework / script são geralmente usadas:

1. Linear (código de procedimento, possivelmente gerado por ferramentas como aquelas que usam gravação e reprodução)
2. Estruturado (usa estruturas de controle - normalmente 'if-else', 'switch', 'for', 'while', condições / instruções)
3. Orientado por dados (os dados são mantidos fora dos testes em um banco de dados, planilha ou outro mecanismo)
4. Baseado em palavras-chave
5. Híbrido (dois ou mais dos padrões acima são usados)
6. Estrutura de automação ágil

A estrutura de teste é responsável por:

1. definir o formato no qual expressar as expectativas
2. criar um mecanismo para conectar ou conduzir o aplicativo em teste
3. executando os testes
4. relatórios de resultados

Interface de automação de teste

Interfaces de automação de teste são plataformas que fornecem um único espaço de trabalho para incorporar várias ferramentas de teste e estruturas para teste de Sistema / Integração do aplicativo em teste. O objetivo da Interface de automação de teste é simplificar o processo de mapeamento de testes para critérios de negócios sem que a codificação atrapalhe o processo. Espera-se que a interface de automação de teste melhore a eficiência e flexibilidade de manutenção de scripts de teste.

Modelo de interface de automação de teste

A Interface de automação de teste consiste nos seguintes módulos principais:

• Interface Engine
• Ambiente de Interface
• Repositório de Objetos

Motor de interface

Os mecanismos de interface são desenvolvidos com base no ambiente de interface. O mecanismo de interface consiste em um analisador e um executor de teste. O analisador está presente para analisar os arquivos de objeto provenientes do repositório de objetos na linguagem de script específica de teste. O executor de teste executa os scripts de teste usando um equipamento de teste .

Repositório de objetos

Repositórios de objetos são uma coleção de dados de objetos de IU / Aplicativo registrados pela ferramenta de teste enquanto explora o aplicativo em teste.

Definindo limites entre a estrutura de automação e uma ferramenta de teste

As ferramentas são projetadas especificamente para atingir algum ambiente de teste específico, como ferramentas de automação do Windows e da web, etc. As ferramentas servem como um agente condutor para um processo de automação. No entanto, uma estrutura de automação não é uma ferramenta para realizar uma tarefa específica, mas sim uma infraestrutura que fornece a solução onde diferentes ferramentas podem fazer seu trabalho de maneira unificada. Isso fornece uma plataforma comum para o engenheiro de automação.

Existem vários tipos de estruturas. Eles são categorizados com base no componente de automação que utilizam. Estes são:

1. Teste baseado em dados
2. Teste baseado em modularidade
3. Teste baseado em palavras-chave
4. Teste híbrido
5. Teste baseado em modelo
6. Teste orientado a código
7. Desenvolvimento orientado por comportamento

O que testar

As ferramentas de teste podem ajudar a automatizar tarefas como instalação de produto, criação de dados de teste, interação de GUI, detecção de problemas (considere a análise ou agentes de pesquisa equipados com oráculos de teste ), registro de defeitos, etc., sem necessariamente automatizar os testes de ponta a ponta .

Deve-se continuar atendendo aos requisitos populares quando se pensa em automação de teste:

• Independência de plataforma e sistema operacional
• Capacidade orientada a dados (dados de entrada, dados de saída, metadados )
• Relatórios de personalização (acesso a banco de dados de banco de dados , Crystal Reports )
• Depuração e registro fáceis
• Controle de versão amigável - arquivos binários mínimos
• Extensível e personalização ( APIs abertas para integração com outras ferramentas)
• Driver comum (por exemplo, no ecossistema de desenvolvimento Java, isso significa Ant ou Maven e os IDEs populares ). Isso permite que os testes se integrem aos fluxos de trabalho dos desenvolvedores .
• Suporta execuções de teste autônomas para integração com processos de construção e execuções em lote. Os servidores de integração contínua exigem isso.
• Notificações de e-mail, como mensagens devolvidas
• Suporte a ambiente de execução distribuída ( test bed distribuído )
• Suporte de aplicativo distribuído ( SUT distribuído )

Veja também

• Lista de ferramentas de teste de GUI
• Lista de ferramentas de teste da web
• Teste contínuo
• Fuzzing
• Navegador sem cabeça
• Teste de software
• Teste de sistema
• Teste de unidade

Referências

Referências gerais

links externos

• Experiência prática em testes automatizados
• Automação de teste: agregando valor ao negócio
• Óleo de cobra de automação de teste por James Bach
• Quando um teste deve ser automatizado? por Brian Marick
• Diretrizes para estrutura de automação de teste
• Automação de Teste Avançada
• Fatores de sucesso para testes baseados em palavras-chave de Hans Buwalda
• Automação que aprende: fazendo seu computador trabalhar para você por Jeremy Carey-Dressler
• Recursos de teste de automação e práticas recomendadas por Joe Colantonio