Quais são as melhores práticas para gerenciar os resultados do teste

5

Estamos usando o GitHub para gerenciar o código-fonte e a placa de waffle para gerenciar fluxos de trabalho / problemas.

Neste momento, quando testamos o sistema usando casos de teste personalizados, ele gera um arquivo CSV. Queremos ser capazes de manter um registro desses resultados de teste, para que possamos voltar e executar o mesmo teste novamente com as mesmas entradas e verificar os resultados, ou apenas compartilhar os resultados com as partes interessadas.

Qual é a melhor estratégia para gerenciar esses resultados de testes?

Devemos publicar o arquivo Results.csv no mesmo repositório do Github que o projeto? (isso se tornaria pesado e queremos evitar isso)

Nós tentamos publicar os resultados no Waffleboard, mas os problemas do Github não suportam o envio de arquivos para que possamos anexar os resultados (somente os arquivos de imagem podem ser enviados)

A única opção que vemos é publicar os resultados em um site interno. Essa é a melhor maneira de fazer isso?

Editar esclarecimento:

O sistema está substituindo um sistema legado. Os casos de teste mudam diariamente.

O script de teste coleta os dados do sistema legado e do novo sistema e faz uma comparação para ver se eles correspondem.

    
por user3711455 16.03.2016 / 16:16
fonte

5 respostas

3

Os resultados do teste devem ser gerenciados no mesmo repositório git. Você não precisa salvar os resultados de cada execução, você só precisa salvar os resultados para uma única execução. Todas as outras execuções devem comparar-se a essa versão "dourada" dos dados. Se um teste gerar resultados diferentes, ele falhará.

Em outras palavras, esse arquivo .csv não é uma saída de teste, é uma entrada de teste . Gere-o uma vez, então seus testes devem usá-lo para validar se o sistema atual está funcionando como deveria. Como é uma entrada, ela precisa ser controlada por versão como qualquer outro recurso de teste.

Ao executar seus testes, você pode criar um relatório diário que mostre apenas as falhas. Não haveria necessidade de arquivá-lo, a menos que você precise fazer análises sobre a frequência com que certos testes falham ou passam.

    
por 16.03.2016 / 16:26
fonte
1

Da sua pergunta:

We want to be able to keep a record of these test results, so we can go back and run the same test again with the same Inputs and verify the results – @user3711455

Do seu comentário:

The .CSV changes daily. The test script's input is the output of a legacy system. It takes that, gets equivalent data from New system, and then compares to see if they both match. Resulting with a CSV that has: Legacy System Results, New System Results Total Differences: – @user3711455

Estes não são o mesmo teste. Executar o mesmo teste, com as mesmas entradas, contra o mesmo código deve ser um exercício redundante. Se isso não produzir sempre o mesmo resultado, você terá permitido a mágica no seu sistema.

Isso é útil apenas para verificar se nada de mágico está acontecendo. Normalmente, você executa novamente esses testes, certificando-se de que apenas uma coisa tenha mudado. Código geralmente refatorado. Dessa forma, quando o teste quebra você sabe o que culpar, a única coisa que mudou.

A execução de dois sistemas lado a lado, duplicando o trabalho para comparação, não é um teste. É um sistema de votação. Quando eles discordam, você tem que decidir em quem acreditar. O sistema legado não deve ser confiável para ser perfeito não importa quantos anos ele tem sob seu cinto. Na verdade, quanto mais velho, mais provável é que alguns erros cometidos sejam tão conhecidos que todos simplesmente os ignoram, uma vez que são esperados e podem nunca ter contado a vocês novos caras, já que todo mundo sabe disso. Você pode obter algum valor com a comprovação de que o novo sistema está pronto para a transição para o operacional, mas estes não são testes, pois exigem que o sistema antigo exista.

No entanto, alimente a entrada para o sistema antigo e grave a saída e você terá uma saída de linha de base. Mas apenas para essa entrada, e apenas para essa versão do sistema legado. Que esperançosamente não é buggy em si. A partir disso você pode construir um teste no novo sistema. Mas se suas entradas não exercitarem cada caso de uso e cada código, então você está apenas esperando ter sorte.

Se, como suspeito, o custom written test cases que faz com que os casos de teste sejam change daily , é apenas ter os dois sistemas funcionando com o mesmo feed de entrada operacional. Não tenho muita confiança em ter uma boa cobertura de código .

Se, no entanto, sua entrada for ajustada manualmente para exercitar diferentes partes de seu código, essas entradas e o código que automatiza os testes e a comparação de suas saídas devem ser organizados de maneira estruturalmente semelhante ao código testado. que é muito fácil navegar de um para o outro. Faça isso e mantenha toda a versão controlada e você terá um bom sistema de desenvolvimento.

    
por 16.03.2016 / 18:34
fonte
0

Embora responda a uma pergunta diferente, acho que respondo a uma pergunta sobre como armazenar os resultados da análise estática pode ser útil aqui também.

Você precisa controlar os casos de teste e testar a entrada da versão. Dada uma versão de software, você deve conseguir reproduzir exatamente os testes que você executou e seus dados de entrada associados naquele momento. No entanto, você também pode querer executar testes mais recentes em códigos mais antigos. Manter seus testes (código de teste, dados de entrada de teste, procedimentos de teste) em seu sistema de controle de versão e marcá-los é essencial.

Uma vez que você é capaz de executar novamente os mesmos testes com os mesmos dados em um instantâneo do software a qualquer momento, não acho que seja necessário manter todos os resultados do teste.

Se você sentir necessidade de disponibilizar alguns dados, poderá agrupar os resultados do teste como parte de um lançamento formal. Se você incluir os resultados do teste, poderá ver como deseja empacotá-lo - incluindo todos os resultados e resultados do teste ou redigir um relatório de resumo que descreva os resultados do teste.

    
por 16.03.2016 / 17:06
fonte
0

Usamos três tipos de testes:

  • Selênio
  • NUnit
  • Soap UI

Todos estes produzem arquivos de resultados (XML). Para os testes de Selenium, estes são fluxos de alto nível, então enviamos um email para um grupo que pode ver os resultados, pois há menos de 10. Estes são muito técnicos verificando o estilo de testes (teste de fumaça). O XML é convertido em HTML e inserido no email.

Para os testes de UI nUnit e SOAP, temos 100s, se não 1000s. Ambos os testes produzem arquivos XML que são nUnit. A partir daí, alimentamos esses resultados em uma página da Web simples (Report Unit) que converte o XML e, em seguida, coloca os resultados em uma página da web.

Não nos importamos com os resultados anteriores, mas você pode enviar cada "execução" para uma pasta de arquivo para revisão, mas os resultados de alguns dias atrás são obsoletos do nosso ponto de vista e podem não ser mais válidos se houver são muitas mudanças de código. Esses resultados são enviados para um monitor (TV) para que toda a equipe possa ver a integridade dos testes. Testes que ficam vermelhos são investigados e resolvidos.

O (s) mecanismo (s) para produzir os resultados estão sob controle de origem, mas os próprios resultados reais não estão no controle de origem.

    
por 16.03.2016 / 17:52
fonte
0
A prática de

Melhor permite que um desenvolvedor execute o conjunto de testes a partir de uma nova cópia de trabalho sem dependências externas.

Seu cenário já parece divergir do cenário de teste típico. Mas, o que isso provavelmente significa para você é armazenar os resultados de "destino" no repositório. Sua ferramenta de teste não deve armazenar seus resultados imediatos em qualquer lugar; deve comparar seus resultados imediatos com os resultados "alvo" para validação e relatar falhas individuais.

A partir daí, qualquer falha única deve levar o desenvolvedor a corrigir o bug ou validar a alteração nos requisitos e ajustar o "alvo "dados de acordo antes de cometer.

    
por 16.03.2016 / 17:48
fonte