Em um determinado grupo de testes, vi alguém fazer uma pergunta: Qual a diferença entre colocar os dados de teste no arquivo de configuração para leitura e colocar o arquivo para leitura através de chamadas de função?
Naquela época, eu inconscientemente respondi: quanto maior a quantidade de dados, mais inchado será o arquivo de configuração.Coloque-o em um arquivo de dados especial (como Excel, CSV) para facilitar a manutenção direcionada.
À primeira vista, não havia nada de errado com isso, mas quando discuti esse assunto com outras pessoas, pensei seriamente sobre isso. A seguir estão alguns dos resultados do meu pensamento e discussão, apenas para referência. . .
No processo de teste automatizado, a maioria deles agora adota um design que separa os scripts de teste dos dados de teste. Os benefícios disso são: redução de custos de manutenção, custos de migração e melhoria da eficiência.
Portanto, onde colocar os dados de teste e como gerenciá-los não pode ser generalizado. Pessoalmente, acho que devemos considerar os seguintes aspectos:
1. Cenário de negócios
① Por exemplo, em testes de automação de UI, cada módulo de negócios de um site de comércio eletrônico precisa ser testado, mas o pré-requisito é que o usuário faça login. Os dados da conta de teste usados para realizar o login geralmente são corrigidos, portanto, especificamente
Colocar um conjunto de nomes de usuário e senhas em um arquivo de dados de teste ou banco de dados de teste é muito complicado, demorado e trabalhoso. Escreva-o em um script de teste ou em um arquivo de configuração e será mais eficiente citá-lo diretamente.
② Da mesma forma, ao testar sites de comércio eletrônico, o sistema de contas é dividido em contas comuns, contas de membros e membros são divididos em vários níveis.Às vezes, para testar se as informações exibidas por diferentes contas no centro de membros são diferentes, você preciso usar diferentes
Faça login com uma conta de nível. Neste cenário, você pode colocar os dados de teste no arquivo de teste (como Excel, csv), lê-los em um loop por meio de parametrização e realizar operações subsequentes.
③. Em testes automatizados de API, por exemplo, para interfaces de estilo repousante, seus nomes de domínio são relativamente fixos, mas os caminhos de diferentes interfaces são diferentes. Então, o nome de domínio também pode ser gravado no arquivo de configuração.
Durante o processo de teste, você só precisa unir o nome de domínio e o caminho instanciados, o que também economiza o custo de manutenção do arquivo de dados de teste e melhora a eficiência do teste até certo ponto.
2. Tipo de dados
Os dados de teste também são divididos em diferentes tipos, divididos aproximadamente nos seguintes tipos:
dados base: dados básicos, como informações de produtos e SKU em sites de comércio eletrônico, como gerenciamento de armazéns de empresas de logística, etc. Esse tipo de dados geralmente tem uma base relativamente grande e pode ser considerado como uma camada de persistência e armazenado em BD;
dados de teste: dados de teste. Dependendo do cenário de negócios, os dados serão diferentes tanto em magnitude quanto em frequência de alterações. Com base no conceito de separação de scripts de teste e dados, eles podem ser colocados em arquivos de teste especiais, como Excel e csv;
dados efêmeros: dados temporários, ou seja, dados que são usados uma vez.Esse tipo de dados pode ser armazenado em um formato de arquivo temporário (como dat, csv, etc.) e depois lido parametrizado ou gravado diretamente em um script ;
3. Nível de dados
① Ou em um determinado cenário em um site de comércio eletrônico, você precisa fazer login primeiro. A conta de login é, por exemplo, uma conta de teste especialmente configurada, que é relativamente fixa, então não há nada de errado em gravar a conta de teste em o roteiro de teste.
Porém, pessoalmente não gosto de escrever os dados de teste diretamente no script. Nesse caso, escreverei o arquivo de configuração e depois instanciarei a chamada. Nesse caso, ele precisa ser projetado de acordo com hábitos pessoais, e aí não há rotina fixa;
②. A magnitude dos dados varia de dezenas a centenas a milhares. Nesse caso, arquivos Excel podem ser gravados para gerenciamento de armazenamento, mas a limitação do Excel é que atualmente ele suporta no máximo mais de 65.500 linhas de armazenamento de dados.
E suporta apenas transações únicas. Se a leitura multithread for necessária, isso se tornará um gargalo.
③. O arquivo csv possui uma estrutura simples e universal, pode ser convertido para Excel, pode reduzir o tamanho do arquivo armazenado e possui segurança simples. Ele pode substituir o Excel como arquivo de armazenamento de dados até certo ponto.
Atualmente uso arquivos do tipo csv para armazenamento e gerenciamento de dados de teste na maioria dos cenários;
④. Quando os dados de teste excedem um determinado nível, como em testes de desempenho, se você quiser realizar um teste simultâneo ou de estabilidade, os dados de teste necessários serão muito grandes. Neste momento, será muito inconveniente usar o Excel ou csv.
Independentemente do custo de manutenção ou da conveniência, você deve optar por usar o banco de dados ou outros métodos de gerenciamento eficientes para armazenar e gerenciar dados de teste;
4. Frequência de uso
A frequência de reutilização dos dados de teste é diferente e diferentes métodos de armazenamento precisam ser selecionados, como:
①. Uma vez: Os dados de teste são usados apenas uma vez, então você só precisa gravá-los em um arquivo temporário e invalidá-los ou excluí-los após o uso;
②. frequentemente: para dados de teste usados com frequência, métodos apropriados de gerenciamento de armazenamento devem ser selecionados com base na magnitude dos dados, cenários de uso e tipos de dados;
③. sempre: Pode ser entendido como dados base ou dados persistentes. Este tipo de dados tem uma frequência de atualização muito baixa ou um grande tamanho de dados. Geralmente, armazená-los no banco de dados é uma melhor solução de gerenciamento.
Resumindo, não existe uma rotina fixa para o armazenamento e gerenciamento de dados de teste. Ela precisa ser considerada de forma abrangente com base nos cenários de negócios, frequência de uso, tipo e magnitude dos dados, e projetar uma solução razoável e eficiente é o caminho certo. !
O conteúdo é apenas para referência. Se você tiver sugestões melhores, comente, obrigado. . .
[Último em 2023] Testes automatizados em Python, concluem 60 projetos práticos em 7 dias e fornecem informações práticas durante todo o processo. [Teste automatizado/teste de interface/teste de desempenho/teste de software]
Por fim, gostaria de agradecer a todos que lêem meu artigo com atenção. A reciprocidade é sempre necessária. Embora não seja algo muito valioso, se você puder usá-lo, poderá pegá-lo diretamente:
Esta informação deve ser o armazém de preparação mais abrangente e completo para amigos [de teste de software]. Este armazém também acompanhou dezenas de milhares de engenheiros de teste na jornada mais difícil. Espero que também possa ajudá-lo!