Testes automatizados no conteúdo dinâmico

5

Estou fazendo o trabalho de SQA para vários sites baseados no Kendo que têm muitas tabelas (algumas são feitas à mão pelos nossos desenvolvedores). Essas tabelas têm várias linhas, colunas, páginas e dados preenchidos. Por isso, basicamente faço o SQA em um conteúdo muito dinâmico.

Estou tentando criar scripts automatizados para garantir que recursos como adicionar uma linha ou editar uma linha funcionem, mas o processo pareça terrivelmente tedioso e propenso a falhar (não porque o código da tabela é ruim, mas porque o conteúdo é dinâmico e, portanto, os scripts do Selenium pegam a linha, a coluna, etc.)

Por exemplo, se eu quiser criar um script do Selenium para adicionar uma linha em uma tabela, preciso:

  • descubra o xPath para essa tabela específica
  • armazena o Xpath
  • armazena o XpathCount
  • adicione uma linha
  • preencha os detalhes
  • obtenha o novo XpathCount
  • verifique se a nova contagem de linhas é 1 mais do que o número original de linhas
  • se tudo estiver bem até agora, obtenha o caminho específico para a nova linha e espere que seja onde você acha que está
  • afirma que todos os dados dessa nova linha são os que foram inseridos na criação da linha

Digamos que sua tabela armazena as coisas alfabeticamente e você não pode controlar todos os outros testes que os desenvolvedores estão executando, então é preenchido com 54 itens; alguns feitos por você, alguns feitos por outros. Você executa seu script Selenium para clicar em "Criar linha" e, na página "Criar linha", preenche automaticamente os detalhes de uma linha com o nome do atributo principal "Bob". O selênio então clica em 'Enviar'.

A tabela / página da Web insere a linha 'Bob' entre 'BAMF' e 'Karl', mas o teste Selenium falha porque o conteúdo é dinâmico e, portanto, não tem ideia de qual linha procurar que tenha 'Bob' nele . Se eu tiver que olhar para a tabela toda vez que eu executar um teste para ver onde 'Bob' iria, para que eu possa atualizar o script para saber onde a linha ficará, eu também não posso automatizar.

São testes como estes que não devem ser automatizados? Os scripts de teste como esses devem funcionar apenas em tabelas vazias que você preenche?

    
por 8protons 02.09.2016 / 01:15
fonte

1 resposta

7

Você parece estar no caminho certo para testes automatizados ao vivo, mas tem alguns fatores significativamente complicadores:

  1. O conteúdo dinâmico aumenta a dificuldade de especificar um teste. Você geralmente tem que declarar em termos pelo menos um pouco mais genéricos.

  2. Mas muito pior: Vários outros testes possivelmente concorrentes acontecendo em paralelo. Isso realmente aumenta a aposta. Se outros testes puderem adicionar "Alice" ou até "Bob" enquanto você estiver adicionando "Bob", não será possível presumir que os itens estarão em posições fixas no conjunto de dados ou que haverá uma contagem fixa deles. Suas condições de navegação e teste acabam tendo que ser muito mais flexíveis e genericamente declaradas. E você precisará ser flexível sobre falhas. Em um ambiente paralelo, alguns testes falharão invariavelmente, mesmo se forem especificados corretamente. Isso é inescapável. Se outra pessoa testar "excluir uma linha aleatória" ou "limpar todos os registros que começam com as letras A-F" enquanto estiver testando "adicionar uma linha de Bob", sua linha estará em risco. Com o tempo, com testes suficientes, algumas vezes o teste concorrente ganhará ocasionalmente. Será também ser uma falha transitória. Execute novamente o teste e é improvável que os testes colidirão novamente da mesma maneira. (Problemas transitórios podem fazer melhor as coisas, porque elas são mais raras, mas também piores. Eles são muito muito mais difícil de rastrear, entender e consertar, porque eles dependem do tempo.)

Algumas recomendações:

  1. Não desista de automação. Quanto mais complexos e dinâmicos forem os dados e o comportamento do aplicativo, mais importante é que os testes serão automatizados. Em sistemas complexos. você não terá a energia e o foco para testar repetidamente cada comportamento. Nem mesmo se você tem uma equipe grande fazendo o trabalho. A automação é o único caminho confiável a seguir. Seja paciente ao aprender a especificar esses testes de maneiras mais flexíveis e inclusivas.
  2. Aumente o isolamento de seus testes. Atualmente, as instâncias em nuvem, as máquinas virtuais e os ambientes virtuais são incrivelmente baratos. Talvez você possa gerar sua própria instância do aplicativo para testar. Isso removeria completamente os bugaboos de paralelismo, simplificando seu trabalho. Ele também permite que você inicie com conjuntos de dados predefinidos e primitivos carregados para cada execução de teste ou sempre que for conveniente para suas necessidades de teste. No entanto, sei que isso pode ser difícil. Eu tenho estado em situações onde a gerência insistiu que não poderíamos pagar instâncias de teste separadas. Eu até trabalhei em produtos comerciais ao vivo, onde era obrigatório testar algumas coisas em sistemas de produção, com dados de produção ( arrepio ).

  3. Aumente o isolamento de dados. Mesmo que você não consiga realizar seu próprio teste instância (s), você ainda pode aumentar o isolamento de seus testes. Eu geralmente uso dados obviamente únicos para fazer isso. Não adicione "Alice" e "Bob" por exemplo; adicione "Alice_21387" e "Bob_21387", em que o sufixo é um índice gerado aleatoriamente por execução de teste. Não é possível adicionar números a esses campos? Adicione letras aleatórias. Há muito pouca chance de que "Alicezcfh" e "Bobzcfh" sejam usados por qualquer teste concorrente.

  4. Permita que seus testes falhem. A maioria das estruturas de teste tem a capacidade de esperar e repetir testes. Use-o. Deixe seus testes falharem até N vezes, com um segundo D atraso entre as corridas. Para muitos webapps, N = 3, D = 15 irá fazer o truque. Se não for uma opção incorporada ao seu test runner, é fácil escrever isso tipo de lógica de teste de nova tentativa.

  5. Torne seus scripts de teste mais robustos no que eles esperam como resultados. Por exemplo, se após uma inserção o registro de "Bob" precisar estar em algum lugar de uma tabela, não escreva teste que espera que apareça exatamente na linha número 42. Escreva o teste para esperar "Bob" em algum lugar da tabela. (dica do chapéu para @Doc Brown )

Em resumo, não desista da abordagem automatizada. Existem maneiras de fazer isso funcionar. É imperfeito, especialmente se você estiver testando um sistema que está sendo alterado durante o teste. Às vezes você terá que refazer, endurecer e melhorar os testes à medida que avança. Mas pode ser prático e eficaz. É também sua única esperança real. A alternativa lógica, o teste manual repetido, nunca funcionará com nada que se assemelhe a facilidade, velocidade e confiabilidade.

    
por 02.09.2016 / 04:56
fonte