E novamente em nossa fita "Calendário do testador" . Este mês, Marina Tretyakova, testadora do projeto Kontur . Entregas , falará sobre a otimização de testes. Marina analisará problemas específicos e como resolvê-los, além de aconselhar como otimizar seus testes e reduzir o tempo de teste.
Primeiro, vamos dividir todos os testes pelo grau de automação, a fim de examinar mais detalhadamente cada tipo.
De acordo com o grau de automação, os testes são divididos em:
- Manso.
- Automatizado.
- Automático (sem intervenção humana, no momento - mais um mito do que realidade).
A abordagem para otimizar testes depende diretamente do grau de automação.
Otimizações aplicáveis a todos os tipos de testes
O teste inclui as etapas de:
- preparação do sistema de teste
- preparação de dados de entrada
- teste (manual ou automaticamente, consideraremos abaixo),
- coleta e análise de resultados.
Acredita-se que a regressão manual leve mais tempo dos testadores. No entanto, na maioria dos casos, não é assim. No mínimo, você não deve dizer isso até que o problema seja medido e comprovado.
Considere soluções para problemas comuns. Muitas dicas podem parecer extremamente óbvias para você, mas, como mostra a experiência de conferências e discursos de colegas de outras empresas, essas dicas ainda são relevantes e comprovaram sua aplicabilidade e utilidade.
Os problemas:
1. Longa preparação do sistema de teste
Perguntas importantes a serem feitas antes de implementar otimizações:
- Longo quanto a quê?
- Quem está envolvido neste treinamento (testadores, programadores ...)?
- Quantas vezes você pode preparar um sistema de teste durante um dia útil? Esse número atende às necessidades de teste?
- Qual é o estágio mais longo da preparação e por quê?
Para descobrir a causa desse problema, é importante fazer a pergunta certa.
Considere os seguintes exemplos:
Compilação longa de todos os módulos do sistema
A pergunta certa é : todos os módulos precisam de compilação?
Solução : compilar não todos os módulos do sistema, mas apenas aqueles que foram afetados na tarefa e que participarão da liberação.
O longo processo manual de atualização de todo o sistema para diferentes "máquinas virtuais" na bancada de testes
A pergunta correta é : em que momento da atualização é necessária a participação humana e em que momento?
Solução : automatize o processo de cálculo, use ferramentas especiais de implantação e rolagem de serviço ou mecanismos de liberação depurada para "combate", mas use-os apenas para implantação em um teste.
O longo processo de "espalhar" o código fonte em "máquinas virtuais" em uma bancada de testes para posterior compilação e rolagem
Possível problema : conectividade de rede.
A pergunta correta é : longa quanto a quê (coleta na máquina local, coleta na rede local)?
Solução : a bancada de testes e o local em que as fontes estão localizadas devem estar na mesma rede para minimizar a interação da rede.
Encontrei esse problema no meu trabalho quando decidi mudar o local do teste em Ecaterimburgo para Moscou. E, no processo de tentar "organizar" o site, notamos rapidamente que a atualização do estande começou a demorar não 15 minutos, mas quase 15 minutos. O motivo foi que o código fonte com um grande número de arquivos pequenos estava em Ecaterimburgo e o estande estava em Moscou. O processo de cálculo “repousou” na transferência de arquivos pequenos da rede para posterior compilação e “cálculo” no estande. Como resultado, o código também "saiu" para Moscou :)
2. Longa coleta e análise dos resultados
Perguntas importantes a serem feitas antes de implementar otimizações:
- Longo quanto a quê?
- Quais são as etapas do processo de coleta e análise de resultados? Qual estágio é o mais longo e por quê?
- Quem analisa os resultados?
- Quem decide o lançamento e com que base? Quanto tempo leva para tomar uma decisão?
Por exemplo :
Os resultados dos testes são emitidos de acordo com o modelo, o registro de acordo com o modelo leva a maior parte do tempo durante o teste.
Solução (obrigado, Cap!) : Recuse preencher os resultados do modelo ou crie um modelo mais fácil para preencher. Será necessário chegar a um acordo com a equipe e descobrir quem lê esses resultados (e eles os lêem?). Existe realmente a necessidade desse modelo (o risco é escrever os resultados dos testes “na mesa”).
Otimizações aplicáveis a testes manuais
Esses testes podem ser divididos em duas grandes classes:
- realizado regularmente, por exemplo, antes da liberação (considere o teste de regressão),
- raramente e apenas para testar novas funcionalidades.
Se a regressão for muitas vezes manual, faz sentido pensar na automação e no retorno da automação, mas neste artigo não consideraremos o ROI da automação.
Para testes manuais (não regressão), deve-se falar não sobre automação de testes, mas sobre o suporte a testes instrumentais (como Alexei Barantsev aconselhou no treinamento que realizamos em nossa empresa). Nesse caso, os autotestes funcionarão como uma ferramenta. Nesse contexto, a lógica e a visão dos autotestes em geral mudarão.
Para testes manuais, antes de tudo, você precisa procurar tarefas de rotina (tarefas, não testes!) E já otimizar (usando automação ou redistribuição de recursos humanos).
Por exemplo, a rotina para testes é preparar dados de teste. Existem diferentes maneiras de realizar essa mesma preparação:
- manualmente através da interface do usuário,
- manualmente através da API,
- executando autotestes, os dados serão um efeito colateral desses testes,
- Automatizado através de scripts / utilitários / ferramentas personalizadas via API ou interface do usuário.
Se você nunca pensou em quanto tempo leva para preparar manualmente os dados de teste, talvez seja hora de medi-los? E acontece que é muito mais eficiente usar pelo menos a segunda e, de preferência, a terceira e a quarta abordagens.
Otimizações aplicáveis a testes automatizados
O problema de preparar dados de teste aqui é mais agudo do que no teste manual. A preparação dos dados do teste deve ser:
- rápido
- Resistente a alterações de design / layout,
- resistente a possíveis ensaios paralelos,
- Resistente a mudanças na arquitetura interna do sistema.
É desejável que a preparação dos dados não exija habilidades e tempo adicionais na implementação da solução.
Os dados de teste podem ser preparados automaticamente:
- através da interface do usuário,
- via solicitações de API ou HTTP,
- através de consultas ao banco de dados.
Considere os prós e contras dessas abordagens em mais detalhes na tabela:
A preparação dos dados de teste por meio de solicitações de API ou HTTP para uma combinação de prós e contras é a mais ideal.
Existem várias otimizações mais comuns que se aplicam a testes automatizados:
Testar paralelismo
Se um dos problemas dos testes for precisamente o tempo de sua passagem, enquanto houver recursos computacionais, você poderá paralelizar e executá-los em um dos três modos paralelos:
- Paralelismo em um computador, paralelismo em threads do processador.
- Paralelismo em computadores diferentes.
- A combinação do primeiro e do segundo métodos, ou seja, se houver várias máquinas de computador, os testes passam em paralelo ao longo dos fluxos em cada uma e em paralelo entre todas as máquinas.
Removendo testes antigos
Se os testes são escritos, eles passam, mas na verdade não checam nada (por exemplo, costumava haver lógica de negócios, agora ela não existe e os testes não checam nada), então esses testes precisam ser cruelmente excluídos, porque na verdade não têm significado , tirando um tempo desnecessário da execução. Também vale a pena remover os testes, o resultado da aprovação que não afeta a decisão sobre a possibilidade de liberação.
Usando técnicas de design de teste para otimizar conjuntos de casos de teste
Para testes manuais, para otimizar conjuntos de casos de teste, é necessário aplicar várias técnicas de design de teste. Para autotestes, métodos de divisão em classes de equivalência, emparelhados, análise de limites e muitas outras técnicas também devem ser usados para otimizar o conjunto de autotestes.
Transferindo testes e verificações existentes para outro nível
Por exemplo, existe um teste do navegador que abre a barra de pesquisa, insere "maçã", "maçã", "maçã", "maçã" (e assim por diante) e parece que, ao concluir a pesquisa, ele recebeu uma notificação sobre a compra de maçãs na loja (teste examina o fato de mostrar a notificação e não mais). Portanto, um teste longo da interface do usuário não verifica essencialmente a interface do usuário, mas sim a lógica que um teste de unidade pode testar; portanto, esse teste deve ser excluído e um teste de unidade gravado.
Decomposição correta dos testes nos níveis de “modular - integração - sistema”
Eu darei um exemplo Há um cenário manual: selecione o produto na loja online, coloque-o na cesta e faça o checkout. O que pode ser feito (e estará errado): crie exatamente um teste que procurará o produto, adicione-o ao carrinho e continue com o design.
Nesse caso, será correto primeiro dividir o teste em três sub-cenários: selecionar um produto, adicionar um produto à cesta e fazer um pedido. Vamos dividir cada cenário em verificações mais atômicas.
Por exemplo: "abrir uma loja - exibindo diferentes categorias de produtos para seleção" - um teste; "Selecionar uma categoria de diferentes categorias de produtos" é outro teste. Examinamos cada teste com mais detalhes e determinamos que nível de testes são necessários para ele; o exemplo anterior pode dizer que tipo de testes é melhor projetar imediatamente como testes de unidade.
Um esquema de conexão popular dos sistemas testados e testados para testes automatizados de aplicativos da web:
Para otimizar o teste automatizado de um aplicativo da web, é recomendável considerar a otimização de cada interação no esquema descrito.
Para simplificar, considere otimizar algumas interações:
1) Interação “casos de teste - navegador - banco de dados”
Usando a API não apenas para preparar dados para o teste, mas também para executar várias etapas no teste.
Por exemplo, se o objetivo é verificar a interface do usuário no final de uma longa cadeia de ações, não é necessário realizar todas as ações por meio da interface do usuário. Afinal, se algo quebrou no meio da cadeia na interface do usuário, o teste nunca chegará ao fim e à verificação do alvo. O testador vai adivinhar, e se eles consertarem esse elo quebrado na cadeia, tudo o que funciona depois dele? Se, nesse caso, em toda a cadeia, além da última ação, uma API for usada, com uma quebra da interface do usuário de qualquer link, o testador saberá se o sistema funcionará conforme o esperado, se os desenvolvedores corrigirem o link quebrado.
2) Interação "casos de teste - SeleniumWebDriver - navegador".
- Fechando guias extras após a conclusão do teste, em vez de fechar o navegador.
No meu projeto, essa otimização ajudou a economizar 10 minutos na execução de testes de interface do usuário (em vez de 1h 10 min, os testes começaram a passar em 1h). Essa otimização está conectada à lógica do SeleniumWebDriver, que é usada no projeto - ela tem uma preparação muito longa para abrir um navegador, mas o fechamento das guias ocorre quase instantaneamente. - Otimização do cache de aplicativos do sistema em teste, para que os testes passem mais rapidamente.
- Usando navegadores sem cabeça para que não haja custo na renderização de elementos de página da web.
Em conclusão
Para qualquer otimização, você precisa identificar claramente os problemas atuais no processo de teste, expandir os pontos em que estão, apresentar opções possíveis (várias mais!) Para resolvê-los. Depois disso, é necessário dar voz a eles em uma equipe, "vender" suas idéias e sugestões para uma solução e somente após a aprovação universal distribuir os esforços e resolver as tarefas. Uma avaliação preliminar de "Antes" e uma avaliação de "Depois" ajudarão a considerar todos os ganhos da otimização de processos.
E, mais uma vez, gostaria de repetir: não procure testes de rotina, procure tarefas de rotina e automatize-os!
Lista de artigos do calendário:
Tente uma abordagem diferente
Teste de par razoável
Feedback: como acontece
Otimizar testes
Leia um livro
Teste de análise
O testador deve pegar o erro, ler Caner e organizar a mudança.
Carregar serviço
Métricas de serviço de controle de qualidade
Teste de segurança
Conheça seu cliente
Receber lista de pendências