Menu

O que são dados de teste? Técnicas de preparação de dados de teste com exemplo

what is test data test data preparation techniques with example

Experimente Nosso Instrumento Para Eliminar Problemas

Aprenda o que são dados de teste e como preparar dados de teste para teste:

No atual épico de crescimento revolucionário da Informação e Tecnologia, os testadores comumente experimentam um grande consumo de dados de teste no ciclo de vida de teste de software.

Os testadores não apenas coletam / mantêm dados das fontes existentes, mas também geram grandes volumes de dados de teste para garantir sua contribuição em expansão de qualidade na entrega do produto para uso no mundo real.

Portanto, nós, como testadores, devemos explorar, aprender e aplicar continuamente as abordagens mais eficientes para coleta, geração, manutenção, automação e gerenciamento abrangente de dados para qualquer tipo de teste funcional e não funcional.

O que são dados de teste - preparação de dados de teste

Neste tutorial, irei fornecer dicas sobre como preparar dados de teste para que qualquer caso de teste importante não seja perdido por dados inadequados e configuração incompleta do ambiente de teste.

O que você aprenderá:

O que são dados de teste e por que são importantes

Referindo-se a um estudo conduzido pela IBM em 2016, pesquisar, gerenciar, manter e gerar dados de teste abrangem 30% -60% do tempo dos testadores. É uma evidência inegável de que a preparação de dados é uma fase demorada de teste de software.

Tempo médio gasto pelos testadores em TDM

Figura 1: Tempo médio gasto pelos testadores em TDM

No entanto, é um fato em várias disciplinas que a maioria dos cientistas de dados gasta 50% -80% do tempo de desenvolvimento de seu modelo na organização de dados. E agora, considerando a legislação e também as Informações de identificação pessoal (PII), o engajamento dos testadores é extremamente decente no processo de teste.

Hoje, a credibilidade e confiabilidade dos dados de teste são consideradas um elemento inflexível para os proprietários de negócios. Os proprietários do produto veem as cópias fantasmas dos dados de teste como o maior desafio, o que reduz a confiabilidade de qualquer aplicativo neste momento único de demanda / requisitos dos clientes para garantia de qualidade.

Considerando a importância dos dados de teste, a grande maioria dos proprietários de software não aceita os aplicativos testados com dados falsos ou menos em medidas de segurança.

Neste ponto, por que não nos lembramos do que são dados de teste? Quando começamos a escrever nossos casos de teste para verificar e validar os recursos fornecidos e os cenários desenvolvidos do aplicativo em teste, precisamos de informações que são usadas como entrada para realizar os testes para identificar e localizar os defeitos.

java como fazer uma lista

E sabemos que essas informações precisam ser precisas e completas para a eliminação dos bugs. É o que chamamos de dados de teste. Para torná-lo preciso, podem ser nomes, países, etc ..., não são confidenciais, onde os dados relativos às informações de contato, SSN, histórico médico e informações de cartão de crédito são confidenciais por natureza.

Os dados podem estar em qualquer formato como:

  • Dados de teste do sistema
  • Dados de teste SQL
  • Dados de teste de desempenho
  • Dados de teste XML

Se você estiver escrevendo casos de teste, precisará de dados de entrada para qualquer tipo de teste. O testador pode fornecer esses dados de entrada no momento da execução dos casos de teste ou o aplicativo pode escolher os dados de entrada necessários dos locais de dados predefinidos.

Os dados podem ser qualquer tipo de entrada para o aplicativo, qualquer tipo de arquivo carregado pelo aplicativo ou entradas lidas nas tabelas do banco de dados.

A preparação de dados de entrada adequados faz parte de uma configuração de teste. Geralmente, os testadores chamam de preparação de banco de ensaio . No testbed, todos os requisitos de software e hardware são definidos usando os valores de dados predefinidos.

Se você não tem uma abordagem sistemática para construir dados enquanto escrever e executar casos de teste então há chances de perder alguns casos de teste importantes. Os testadores podem criar seus próprios dados de acordo com as necessidades de teste.

Não confie nos dados criados por outros testadores ou dados de produção padrão. Sempre crie um novo conjunto de dados de acordo com seus requisitos.

Às vezes, não é possível criar um conjunto completamente novo de dados para cada construção. Nesses casos, você pode usar dados de produção padrão. Mas lembre-se de adicionar / inserir seus próprios conjuntos de dados neste banco de dados existente. Uma melhor maneira de criar dados é usar os dados de amostra existentes ou base de teste e anexar seus novos dados de caso de teste cada vez que você obtém o mesmo módulo para teste. Dessa forma, você pode construir um conjunto de dados abrangente ao longo do período.

Desafios da fonte de dados de teste

Uma das áreas na geração de dados de teste, os testadores consideram é o requisito de fonte de dados para subconjunto. Por exemplo, você tem mais de um milhão de clientes e precisa de mil deles para testes. E esses dados de amostra devem ser consistentes e representar estatisticamente a distribuição apropriada do grupo-alvo. Em outras palavras, devemos encontrar a pessoa certa para testar, que é um dos métodos mais úteis de testar os casos de uso.

E esses dados de amostra devem ser consistentes e representar estatisticamente a distribuição apropriada do grupo-alvo. Em outras palavras, devemos encontrar a pessoa certa para testar, que é um dos métodos mais úteis de testar os casos de uso.

Além disso, existem algumas restrições ambientais no processo. Um deles é o mapeamento de políticas de PII. Como a privacidade é um obstáculo significativo, os testadores precisam classificar os dados PII.

As ferramentas de gerenciamento de dados de teste são projetados para resolver o problema mencionado. Essas ferramentas sugerem políticas com base nos padrões / catálogo que possuem. Porém, não é um exercício muito seguro. Ainda oferece a oportunidade de auditar o que se está fazendo.

Para acompanhar os desafios atuais e até mesmo futuros, devemos sempre fazer perguntas como Quando / onde devemos iniciar a condução do TDM? O que deve ser automatizado? Quanto investimento as empresas devem alocar para testes em áreas de desenvolvimento contínuo de habilidades de recursos humanos e o uso de ferramentas TDM mais novas? Devemos começar a testar com testes funcionais ou não funcionais? E perguntas muito mais prováveis ​​do que eles.

Alguns dos desafios mais comuns do Sourcing de dados de teste são mencionados abaixo:

  • As equipes podem não ter conhecimento e habilidades adequadas de ferramentas geradoras de dados de teste
  • A cobertura de dados de teste geralmente é incompleta
  • Menos clareza nos requisitos de dados que abrangem especificações de volume durante a fase de coleta
  • As equipes de teste não têm acesso às fontes de dados
  • Atraso em dar aos testadores acesso aos dados de produção pelos desenvolvedores
  • Os dados do ambiente de produção podem não ser totalmente utilizáveis ​​para testes com base nos cenários de negócios desenvolvidos
  • Grandes volumes de dados podem ser necessários em um curto período de tempo
  • Dependências / combinações de dados para testar alguns dos cenários de negócios
  • Os testadores gastam mais tempo do que o necessário para se comunicar com arquitetos, administradores de banco de dados e BAs para coleta de dados
  • Principalmente os dados são criados ou preparados durante a execução do teste
  • Vários aplicativos e versões de dados
  • Ciclos de lançamento contínuo em vários aplicativos
  • Legislação para cuidar das informações de identificação pessoal (PII)

No lado da caixa branca do teste de dados, os desenvolvedores preparam os dados de produção. É aí que o QA precisa trabalhar em contato com os desenvolvedores para promover a cobertura de teste do AUT. Um dos maiores desafios é incorporar todos os cenários possíveis (caso de teste 100%) com cada caso negativo possível.

Nesta seção, falamos sobre os desafios dos dados de teste. Você pode adicionar mais desafios à medida que os resolve de acordo. Posteriormente, vamos explorar diferentes abordagens para lidar com o design e gerenciamento de dados de teste.

Estratégias para preparação de dados de teste

Sabemos pela prática diária que os participantes da indústria de testes estão continuamente experimentando diferentes maneiras e meios para aprimorar os esforços de teste e, mais importante, sua eficiência de custo. No curto curso da evolução da Informação e Tecnologia, vimos quando as ferramentas são incorporadas aos ambientes de produção / teste, o nível de produção aumentou substancialmente.

Quando falamos sobre a integridade e a cobertura total dos testes, isso depende principalmente da qualidade dos dados. Como o teste é a espinha dorsal para obter a qualidade do software, os dados de teste são o elemento central no processo de teste.

Estratégias para gerenciamento de dados de teste (TDM)

Figura 2: Estratégias para gerenciamento de dados de teste (TDM)

Criação de arquivos simples com base nas regras de mapeamento. É sempre prático criar um subconjunto dos dados de que você precisa no ambiente de produção onde os desenvolvedores projetaram e codificaram o aplicativo. Na verdade, esta abordagem reduz os esforços dos testadores de preparação de dados e maximiza o uso dos recursos existentes para evitar mais despesas.

Normalmente, precisamos criar os dados ou pelo menos identificá-los com base no tipo de requisitos que cada projeto tem no início.

Podemos aplicar as seguintes estratégias tratando do processo de TDM:

  1. Dados do ambiente de produção
  2. Recuperando consultas SQL que extraem dados dos bancos de dados existentes do Cliente
  3. Ferramentas automatizadas de geração de dados

Os testadores devem fazer backup de seus testes com dados completos, considerando os elementos conforme mostrado na figura 3 aqui. Os restauradores em equipes de desenvolvimento ágil geram os dados necessários para a execução de seus casos de teste. Quando falamos sobre casos de teste, queremos dizer casos para vários tipos de teste, como caixa branca, caixa preta, desempenho e segurança.

Neste ponto, sabemos que os dados para teste de desempenho devem ser capazes de determinar a rapidez com que o sistema responde sob uma determinada carga de trabalho para estar muito próximo de um grande volume real ou ao vivo de dados com cobertura significativa.

Para o teste de caixa branca, os desenvolvedores preparam seus dados necessários para cobrir o maior número possível de ramificações, todos os caminhos no código-fonte do programa e a Interface de Programa de Aplicativo (API) negativa.

Atividades de geração de dados de teste

Figura 3: Atividades de geração de dados de teste

Eventualmente, podemos dizer que todos que trabalham no ciclo de vida de desenvolvimento de software ( SDLC ) como BAs, Desenvolvedores e proprietários de produtos devem estar bem envolvidos no processo de preparação de Dados de Teste. Pode ser um esforço conjunto. E agora vamos levá-lo ao problema dos dados de teste corrompidos.

Dados de teste corrompidos

Antes da execução de qualquer caso de teste em nossos dados existentes, devemos nos certificar de que os dados não estão corrompidos / desatualizados e que o aplicativo em teste pode ler a fonte de dados. Normalmente, quando mais de um testador trabalha em diferentes módulos de um AUT no ambiente de teste ao mesmo tempo, as chances de os dados serem corrompidos são muito altas.

No mesmo ambiente, os testadores modificam os dados existentes de acordo com sua necessidade / requisitos dos casos de teste. Principalmente, quando os testadores terminam com os dados, eles os deixam como estão. Assim que o próximo testador pegar os dados modificados e realizar outra execução do teste, existe a possibilidade de falha do teste específico que não é o erro ou defeito do código.

Na maioria dos casos, é assim que os dados são corrompidos e / ou desatualizados, o que leva à falha. Para evitar e minimizar as chances de discrepância de dados, podemos aplicar as soluções a seguir. E, claro, você pode adicionar mais soluções no final deste tutorial na seção de comentários.

  1. Ter o backup de seus dados
  2. Retorne seus dados modificados ao seu estado original
  3. Divisão de dados entre os testadores
  4. Mantenha o administrador do data warehouse atualizado para qualquer alteração / modificação de dados

Como manter seus dados intactos em qualquer ambiente de teste?

Na maioria das vezes, muitos testadores são responsáveis ​​por testar o mesmo build. Neste caso, mais de um testador terá acesso aos dados comuns e tentarão manipular o conjunto de dados comuns de acordo com suas necessidades.

Se você preparou dados para alguns módulos específicos, a melhor maneira de manter seu conjunto de dados intacto é manter cópias de backup do mesmo.

Dados de teste para o caso de teste de desempenho

Os testes de desempenho requerem um conjunto de dados muito grande. Às vezes, criar dados manualmente não detecta alguns bugs sutis que podem ser detectados apenas pelos dados reais criados pelo aplicativo em teste. Se você deseja dados em tempo real, que são impossíveis de criar manualmente, peça ao seu líder / gerente para disponibilizá-los no ambiente ao vivo.

Esses dados serão úteis para garantir o bom funcionamento do aplicativo para todas as entradas válidas.

Quais são os dados de teste ideais?

Os dados podem ser considerados ideais se, para o tamanho mínimo do conjunto de dados, todos os erros do aplicativo forem identificados. Tente preparar dados que irão incorporar todas as funcionalidades do aplicativo, mas não excedendo o custo e as restrições de tempo para preparar dados e executar testes.

Como preparar dados que garantirão a cobertura máxima de teste?

Projete seus dados considerando as seguintes categorias:

1) Sem dados: Execute seus casos de teste em dados em branco ou padrão. Veja se as mensagens de erro adequadas são geradas.

2) Conjunto de dados válido: Crie-o para verificar se o aplicativo está funcionando de acordo com os requisitos e se os dados de entrada válidos estão salvos corretamente no banco de dados ou arquivos.

3) Conjunto de dados inválido: Prepare um conjunto de dados inválido para verificar o comportamento do aplicativo quanto a valores negativos e entradas de string alfanuméricas.

4) Formato de dados ilegal: Faça um conjunto de dados de formato de dados ilegal. O sistema não deve aceitar dados em formato inválido ou ilegal. Além disso, verifique se as mensagens de erro adequadas são geradas.

5) Conjunto de dados de condição de limite: Conjunto de dados contendo dados fora do intervalo. Identifique os casos de limite de aplicação e prepare um conjunto de dados que cobrirá as condições de limite inferior e superior.

6) O conjunto de dados para teste de desempenho, carga e estresse: Este conjunto de dados deve ser grande em volume.

Dessa forma, a criação de conjuntos de dados separados para cada condição de teste garantirá uma cobertura completa do teste.

Dados para teste de caixa preta

Os Testadores de Garantia de Qualidade realizam testes de integração, testes de sistema e testes de aceitação, que são conhecidos como testes de caixa preta. Neste método de teste, os testadores não têm nenhum trabalho na estrutura interna, design e código da aplicação em teste.

O objetivo principal dos testadores é identificar e localizar erros. Ao fazer isso, aplicamos testes funcionais ou não funcionais usando diferentes técnicas de teste de caixa preta.

Métodos de design de dados de caixa preta

Figura 4: Métodos de design de dados de caixa preta

Neste ponto, os testadores precisam dos dados de teste como entrada para executar e implementar as técnicas de teste da caixa preta. E os testadores devem preparar os dados que examinarão todas as funcionalidades do aplicativo sem exceder o custo e o tempo fornecidos.

Podemos projetar os dados para nossos casos de teste considerando categorias de conjunto de dados como nenhum dado, dados válidos, dados inválidos, formato de dados ilegal, dados de condição de limite, partição de equivalência, tabela de dados de decisão, dados de transição de estado e dados de caso de uso. Antes de entrar nas categorias do conjunto de dados, os testadores iniciam a coleta de dados e a análise dos recursos existentes do aplicativo em teste (AUT).

De acordo com os pontos anteriores mencionados sobre como manter seu data warehouse sempre atualizado, você deve documentar os requisitos de dados no nível do caso de teste e marcá-los como utilizáveis ​​ou não reutilizáveis ​​ao criar o script de seus casos de teste. Isso ajuda a que os dados necessários para o teste sejam bem claros e documentados desde o início, para que você possa consultar para uso posterior.

Exemplo de dados de teste para Open EMR AUT

Para o nosso tutorial atual, temos o Open EMR como o aplicativo em teste (AUT).

=> Encontre o link para o aplicativo Open EMR aqui para sua referência / prática.

A tabela a seguir ilustra praticamente uma amostra da coleta de requisitos de dados que pode fazer parte da documentação do caso de teste e é atualizada quando você escreve os casos de teste para seus cenários de teste.

( NOTA : Clique em qualquer imagem para uma visão ampliada)

coleta de requisitos de dados de teste 1

Criação de dados manuais para testar o aplicativo Open EMR

Vamos avançar para a criação de dados manuais para testar o aplicativo Open EMR para as categorias de conjunto de dados fornecidas.

1) Sem dados: O testador valida a URL do aplicativo Open EMR e as funções “Pesquisar ou Adicionar Paciente” sem fornecer dados.

dois) Dados válidos: O testador valida o URL do aplicativo Open EMR e a função “Search or Add Patient” com o fornecimento de dados válidos.

3) Dados inválidos: O testador valida o URL do aplicativo Open EMR e a função “Pesquisar ou Adicionar Paciente” fornecendo dados inválidos.

4) Formato de dados ilegal: O testador valida o URL do aplicativo Open EMR e a função “Pesquisar ou Adicionar Paciente” fornecendo dados inválidos.

Dados de teste para 1-4 categorias de conjuntos de dados:

Amostras de dados de teste 2

5) Conjunto de dados de condição de limite: É para determinar os valores de entrada para limites que estão dentro ou fora dos valores fornecidos como dados.

6) Conjunto de dados de partição de equivalência: É a técnica de teste que divide seus dados de entrada em valores de entrada válidos e inválidos.

Dados de teste para 5ºe 6ºcategorias de conjuntos de dados, que são para nome de usuário e senha do Open EMR:

Dados de teste EMT abertos 3

7) Conjunto de dados da tabela de decisão: É a técnica para qualificar seus dados com uma combinação de entradas para produzir vários resultados. Este método de teste de caixa preta ajuda você a reduzir seus esforços de teste na verificação de cada combinação de dados de teste. Além disso, essa técnica pode garantir a cobertura completa do teste.

Consulte abaixo o conjunto de dados da tabela de decisão para o nome de usuário e a senha do aplicativo Open EMR.

Dados da Tabela de Decisão 4

O cálculo das combinações feitas na tabela acima é descrito para sua informação detalhada conforme abaixo. Você pode precisar quando fizer mais de quatro combinações.

  • Número de combinação = Número de valores das condições 1 * Número de valores das condições 2
  • Número de combinações = 2 ^ Número de condições verdadeiras / falsas
  • Exemplo: Número de combinações - 2 ^ 2 = 4

8) Conjunto de dados de teste de transição de estado: É a técnica de teste que ajuda a validar a transição de estado do Aplicativo em Teste (AUT), fornecendo ao sistema as condições de entrada.

Por exemplo, efetuamos login no aplicativo Open EMR fornecendo o nome de usuário e a senha corretos na primeira tentativa. O sistema nos dá acesso, mas se inserirmos os dados de login incorretos, o sistema nega o acesso. O teste de transição de estado valida quantas tentativas de login você pode fazer antes do fechamento do Open EMR.

A tabela abaixo indica como as tentativas corretas ou incorretas de login respondem

Dados de teste de tentativas de login 5

melhor aplicativo de download de música mp3 grátis para Android

9) Data de teste de caso de uso: É o método de teste que identifica nossos casos de teste, capturando o teste de ponta a ponta de um recurso específico.

Exemplo, Login de EMR aberto:

Dados de teste de falha de sucesso 6

Leia também => Técnicas de gerenciamento de dados de dados

Propriedades de um bom dado de teste

Como testador, você deve testar o módulo ‘Resultados do Exame’ do site de uma universidade. Considere que todo o aplicativo foi integrado e está no estado 'Pronto para Teste'. O ‘Módulo de Exame’ está vinculado aos módulos de ‘Registro’, ‘Cursos’ e ‘Finanças’.

Suponha que você tenha informações adequadas sobre o aplicativo e tenha criado uma lista abrangente de cenários de teste. Agora você deve projetar, documentar e executar esses casos de teste. Na seção ‘Ações / etapas’ ou ‘Entradas de teste’ dos casos de teste, você terá que mencionar os dados aceitáveis ​​como entrada para o teste.

Os dados mencionados nos casos de teste devem ser selecionados corretamente. A precisão da coluna 'Resultados reais' do documento de caso de teste depende principalmente dos dados de teste. Portanto, a etapa de preparar os dados de teste de entrada é significativamente importante. Portanto, aqui está meu resumo sobre “Teste de banco de dados - Estratégias de preparação de dados de teste”.

Propriedades de dados de teste

Os dados de teste devem ser selecionados com precisão e devem possuir as seguintes quatro qualidades:

1) Realista:

Por realista, significa que os dados devem ser precisos no contexto de cenários da vida real. Por exemplo, para testar o campo 'Idade', todos os valores devem ser positivos e 18 ou mais. É óbvio que os candidatos à admissão na universidade geralmente têm 18 anos (isso pode ser definido de forma diferente em termos de requisitos de negócios).

Se o teste for feito usando os dados de teste realistas, isso tornará o aplicativo mais robusto, pois a maioria dos possíveis bugs podem ser capturados usando dados realistas. Outra vantagem dos dados realistas é sua capacidade de reutilização, o que economiza nosso tempo e esforço para criar novos dados repetidamente.

Quando estamos falando sobre dados realistas, gostaria de apresentar o conceito de conjunto de dados dourado. Um conjunto de dados dourado é aquele que cobre quase todos os cenários possíveis que ocorrem no projeto real. Usando o GDS, podemos fornecer cobertura máxima de teste. Eu uso o GDS para fazer testes de regressão em minha organização e isso me ajuda a testar todos os cenários possíveis que podem ocorrer se o código for para a caixa de produção.

Existem várias ferramentas geradoras de dados de teste disponíveis no mercado que analisam as características da coluna e as definições do usuário no banco de dados e, com base nelas, geram dados de teste realistas para você. Alguns dos bons exemplos de ferramentas que geram dados para teste de banco de dados são DTM Data Generator , SQL Data Generator e Mockaroo .

2. Praticamente válido:

Isso é semelhante ao realista, mas não o mesmo. Esta propriedade está mais relacionada à lógica de negócios do AUT, por exemplo o valor 60 é realista na área de idade, mas praticamente inválido para um candidato a Programas de Graduação ou mesmo de Mestrado. Nesse caso, um intervalo válido seria de 18 a 25 anos (isso pode ser definido nos requisitos).

3. Versátil para cobrir cenários:

o que é um arquivo .swf

Pode haver várias condições subsequentes em um único cenário, portanto, escolha os dados astutamente para cobrir aspectos máximos de um único cenário com o conjunto mínimo de dados, por exemplo, ao criar dados de teste para o módulo de resultados, não considere apenas o caso de alunos regulares que estão completando seu programa sem problemas. Preste atenção aos alunos que estão repetindo o mesmo curso e pertencem a diferentes semestres ou mesmo a diferentes programas. O conjunto de dados pode ter a seguinte aparência:

Senhor# Identidade estudantil Program_ID Identidade do curso Grau
1 BCS-Outono2011-Manhã-01 BCS-F11 CS-401 PARA
dois BCS-Spring2011-Evening-14 BCS-S11 CS-401 B +
3 MIT-Outono2010-Tarde-09 MIT-F10 CS-401 PARA-
... ... ... ... ...

Pode haver várias outras subcondições interessantes e complicadas. Por exemplo. limitação de anos para conclusão de um programa de graduação, aprovação em um curso pré-requisito para a inscrição de um curso, no máximo de cursos, um aluno pode se inscrever em um único semestre, etc. etc. Certifique-se de cobrir todos esses cenários com sabedoria com o conjunto finito de dados.

bons dados de teste

4. Dados excepcionais (se aplicável / necessário):

Pode haver certos cenários excepcionais que ocorrem com menos frequência, mas exigem muita atenção quando ocorrem, por exemplo, problemas relacionados a alunos com deficiência.

Outra boa explicação e exemplo do conjunto de dados excepcional é visto na imagem abaixo:

Dados excepcionais

Remover:

Um dado de teste é conhecido como um bom dado de teste se for realista, válido e versátil. É uma vantagem adicional se os dados também fornecem cobertura para cenários excepcionais.

Técnicas de preparação de dados de teste

Discutimos brevemente as propriedades importantes dos dados de teste e também elaboramos como a seleção dos dados de teste é importante ao fazer o teste do banco de dados. Agora vamos discutir o ' técnicas para preparar dados de teste ' .

Existem apenas duas maneiras de preparar dados de teste:

Método 1) Inserir Novos Dados

Obtenha um banco de dados limpo e insira todos os dados conforme especificado em seus casos de teste. Uma vez que todos os seus dados necessários e desejados foram inseridos, comece a executar seus casos de teste e preencha as colunas 'Aprovado / Reprovado' comparando a 'Saída Real' com a 'Saída Esperada'. Parece simples, certo? Mas espere, não é tão simples.

Algumas preocupações essenciais e críticas são as seguintes:

  • Uma instância vazia do banco de dados pode não estar disponível
  • Os dados de teste inseridos podem ser insuficientes para testar alguns casos, como teste de desempenho e carga.
  • Inserir os dados de teste necessários no BD em branco não é uma tarefa fácil devido às dependências da tabela do banco de dados. Por causa dessa restrição inevitável, a inserção de dados pode se tornar uma tarefa difícil para o testador.
  • A inserção de dados de teste limitados (apenas de acordo com as necessidades do caso de teste) pode ocultar alguns problemas que poderiam ser encontrados apenas com o grande conjunto de dados.
  • Para a inserção de dados, podem ser necessários procedimentos e / ou consultas complexas e, para isso, seria necessária assistência ou ajuda suficiente do (s) desenvolvedor (es) do banco de dados.

As cinco questões mencionadas acima são as desvantagens mais críticas e óbvias dessa técnica para a preparação de dados de teste. Mas, também existem algumas vantagens:

  • A execução de TCs torna-se mais eficiente, pois o banco de dados possui apenas os dados necessários.
  • O isolamento de bugs não requer tempo, pois apenas os dados especificados nos casos de teste estão presentes no banco de dados.
  • Menos tempo necessário para teste e comparação de resultados.
  • Processo de teste sem confusão

Método # 2) Escolha um subconjunto de dados de amostra a partir de dados de banco de dados reais

Esta é uma técnica viável e mais prática para a preparação de dados de teste. No entanto, ele requer habilidades técnicas sólidas e exige conhecimento detalhado do esquema de banco de dados e SQL. Neste método, você precisa copiar e usar dados de produção, substituindo alguns valores de campo por valores fictícios. Este é o melhor subconjunto de dados para seu teste, pois representa os dados de produção. Mas isso pode não ser viável o tempo todo devido a questões de segurança e privacidade de dados.

Remover:

Na seção acima, discutimos acima as técnicas de preparação de dados de teste. Resumindo, existem duas técnicas - criar novos dados ou selecionar um subconjunto de dados já existentes. Ambos precisam ser feitos de forma que os dados selecionados forneçam cobertura para vários cenários de teste, principalmente teste válido e inválido, teste de desempenho e teste nulo.

Na última seção, faremos um rápido tour pelas abordagens de geração de dados também. Essas abordagens são úteis quando precisamos gerar novos dados.

Abordagens de geração de dados de teste:

  • Geração de dados de teste manual: Nesta abordagem, os dados de teste são inseridos manualmente pelos testadores de acordo com os requisitos do caso de teste. É um processo demorado e também sujeito a erros.
  • Geração automatizada de dados de teste: Isso é feito com a ajuda de ferramentas de geração de dados. A principal vantagem dessa abordagem é sua velocidade e precisão. No entanto, isso tem um custo mais alto do que a geração manual de dados de teste.
  • Injeção de dados de back-end : Isso é feito por meio de consultas SQL. Essa abordagem também pode atualizar os dados existentes no banco de dados. É rápido e eficiente, mas deve ser implementado com muito cuidado para que o banco de dados existente não seja corrompido.
  • Usando ferramentas de terceiros : Existem ferramentas disponíveis no mercado que primeiro entendem seus cenários de teste e, em seguida, geram ou injetam dados de acordo para fornecer uma ampla cobertura de teste. Essas ferramentas são precisas, pois são personalizadas de acordo com as necessidades do negócio. Mas, eles são muito caros.

Remover:

Existem 4 abordagens para testar a geração de dados:

  1. Manual,
  2. automação,
  3. injeção de dados de back-end,
  4. e ferramentas de terceiros.

Cada abordagem tem seus prós e contras. Você deve selecionar a abordagem que satisfaça suas necessidades comerciais e de teste.

Conclusão

A criação de dados de teste de software completos em conformidade com os padrões da indústria, legislação e documentos básicos do projeto realizado está entre as principais responsabilidades dos testadores. Quanto mais gerenciarmos com eficiência os dados de teste, mais poderemos implantar produtos razoavelmente livres de bugs para usuários do mundo real.

O gerenciamento de dados de teste (TDM) é o processo que se baseia na análise de desafios e na introdução e aplicação das melhores ferramentas e métodos para tratar bem os problemas identificados sem comprometer a confiabilidade e a cobertura total do resultado final (produto).

Sempre precisamos levantar questões para pesquisar métodos inovadores e mais econômicos para analisar e selecionar os métodos de teste, incluindo o uso de ferramentas para gerar os dados. É amplamente comprovado que dados bem projetados nos permitem identificar defeitos do aplicativo em teste em cada fase de um SDLC multifásico.

Precisamos ser criativos e participativos com todos os membros dentro e fora de nossa equipe ágil. Compartilhe seu feedback, experiência, perguntas e comentários para que possamos manter nossas discussões técnicas em andamento e maximizar nosso impacto positivo no AUT por meio do gerenciamento de dados.

Preparar os dados de teste adequados é uma parte central da “configuração do ambiente de teste do projeto”. Não podemos simplesmente perder o caso de teste dizendo que dados completos não estavam disponíveis para teste. O testador deve criar seus próprios dados de teste adicionais aos dados de produção padrão existentes. Seu conjunto de dados deve ser ideal em termos de custo e tempo.

Seja criativo, use sua própria habilidade e julgamentos para criar diferentes conjuntos de dados em vez de depender de dados de produção padrão.

Parte II - A segunda parte deste tutorial está no ' Geração de dados de teste com a ferramenta online GEDIS Studio ”.

Você enfrentou o problema de dados de teste incompletos para teste? Como você administrou isso? Compartilhe suas dicas, experiências, comentários e perguntas para enriquecer ainda mais este tópico de discussão.

Leitura recomendada

^