Tutorial de Teste de Banco de Dados

A GUI geralmente recebe maior ênfase pelos membros da equipe de teste e desenvolvimento, uma vez que a Interface Gráfica do Usuário é a parte mais visível do aplicativo. Porém, o que também é importante é validar as informações que são o coração da aplicação, também conhecido como DATABASE.

Vamos considerar uma aplicação bancária em que um usuário faz transações. Agora, do ponto de vista de teste de banco de dados ou teste de banco de dados a seguir, as coisas são importantes:

1. O aplicativo armazena as informações da transação no banco de dados do aplicativo e as exibe corretamente ao usuário.
2. Nenhuma informação é perdida no processo.
3. Nenhuma informação de operação parcialmente executada ou abortada é salva pelo aplicativo.
4. Nenhum indivíduo não autorizado tem permissão para acessar as informações do usuário.

Para garantir todos esses objetivos acima, precisamos usar validação ou teste de dados.

Diferenças entre testes de interface de usuário e testes de dados

Teste de interface do usuário	Banco de dados ou teste de dados
Este tipo de teste também é conhecido como teste de interface gráfica do usuário ou teste de front-end.	Este tipo de teste também é conhecido como teste de back-end ou teste de dados.
Este tipo de teste trata principalmente de todos os itens testáveis ​​​​que estão abertos ao usuário para visualização e interação, como Formulários, Apresentação, Gráficos, Menus e Relatórios, etc. (criados através de VB, VB.net, VC++, Delphi – Ferramentas front-end)	Este tipo de teste trata principalmente de todos os itens testáveis ​​que geralmente ficam ocultos do usuário para visualização. Isso inclui processos internos e armazenamento como Assembly, SGBD como Oracle, SQL Server, MySQL, etc.
Este tipo de teste inclui a validação do caixas de texto selecione menus suspensos calendários e botões Navegação de página exibição de imagens Aparência da aplicação geral	Este tipo de teste envolve a validação: o esquema tabelas de banco de dados colunas chaves e índices gatilhos de procedimentos armazenados validações de servidor de banco de dados validando duplicação de dados
O testador deve ter profundo conhecimento sobre os requisitos de negócios, bem como sobre o uso das ferramentas de desenvolvimento e de estruturas e ferramentas de automação.	Para poder realizar testes de back-end, o testador deve ter uma sólida experiência em servidor de banco de dados e conceitos de linguagem de consulta estruturada.

Tipos de teste de banco de dados

Os 3 tipos de teste de banco de dados são

1. Testes Estruturais
2. Teste funcional
3. Teste não funcional

Neste tutorial de teste de banco de dados, examinaremos cada tipo e seus subtipos, um por um.

O que é teste de esquema?

Teste de esquema no teste de banco de dados valida vários formatos de esquema associados ao banco de dados e verifica se os formatos de mapeamento de tabelas/visualizações/colunas são compatíveis com os formatos de mapeamento da interface do usuário. O principal objetivo do teste de esquema é garantir que o mapeamento de esquema entre front-end e back-end seja semelhante. Portanto, também é conhecido como teste de mapeamento.

Vamos discutir os pontos de verificação mais importantes para testes de esquema.

1. Validação dos diversos formatos de esquema associados às bases de dados. Muitas vezes o formato de mapeamento da tabela pode não ser compatível com o formato de mapeamento presente no nível da interface do usuário da aplicação.
2. Há necessidade de verificação no caso de tabelas/visualizações/colunas não mapeadas.
3. Também é necessário verificar se os bancos de dados heterogêneos em um ambiente são consistentes com o mapeamento geral da aplicação.

Vejamos também algumas das ferramentas interessantes de teste de banco de dados para validar esquemas de banco de dados.

• DBUnit integrado ao Ant é muito adequado para testes de mapeamento.
• O SQL Server permite que os testadores possam verificar e consultar o esquema do banco de dados escrevendo consultas simples e não por meio de código.

Por exemplo, se os desenvolvedores quiserem alterar a estrutura de uma tabela ou excluí-la, o testador deverá garantir que todos os procedimentos armazenados e visualizações que usam essa tabela sejam compatíveis com a alteração específica. Outro exemplo poderia ser que, se os testadores quiserem verificar alterações de esquema entre 2 bancos de dados, eles poderão fazer isso usando consultas simples.

Tabela de banco de dados, teste de coluna

Vejamos várias verificações para testes de banco de dados e colunas.

1. Se o mapeamento dos campos e colunas do banco de dados no back-end é compatível com os mapeamentos no front-end?
2. Validação do comprimento e convenção de nomenclatura dos campos e colunas do banco de dados conforme especificado pelos requisitos.
3. Validação da presença de quaisquer tabelas/colunas de banco de dados não utilizadas/não mapeadas.
4. Validação da compatibilidade do

• tipo de dados
• comprimentos de campo

das colunas do banco de dados back-end com aquelas presentes no front-end da aplicação.

5. Se os campos do banco de dados permitem que o usuário forneça as entradas desejadas conforme exigido pelos documentos de especificação de requisitos de negócios.

Teste de chaves e índices

Verificações importantes de chaves e índices –

1. Verifique se o necessário

• Chave primária
• chave estrangeira

restrições foram criadas nas tabelas necessárias.

2. Verifique se as referências para chaves estrangeiras são válidas.
3. Verifique se o tipo de dados da chave primária e as chaves estrangeiras correspondentes são iguais nas duas tabelas.
4. Verifique se as convenções de nomenclatura exigidas foram seguidas para todas as chaves e índices.
5. Verifique o tamanho e o comprimento dos campos e índices obrigatórios.
6. Quer seja o necessário

• Clusteríndices ed
• Não. Clusteríndices ed

foram criados nas tabelas necessárias, conforme especificado pelos requisitos de negócios.

Teste de procedimentos armazenados

Testes importantes para verificar procedimentos armazenados são:

1. Se a equipe de desenvolvimento adotou as convenções padrão de codificação exigidas, A) e B) tratamento de exceções e erros. Para todos os procedimentos armazenados de todos os módulos do aplicativo em teste.
2. Se a equipe de desenvolvimento cobriu todas as condições/loops aplicando os dados de entrada necessários ao aplicativo em teste?
3. Se a equipe de desenvolvimento aplicou corretamente a operação TRIM sempre que os dados são obtidos das tabelas necessárias no banco de dados?
4. Se a execução manual do procedimento armazenado fornece ao usuário final o resultado necessário?
5. A execução manual do Stored Procedure garante que os campos da tabela sejam atualizados conforme exigido pela aplicação em teste?
6. Se a execução dos Procedimentos Armazenados permite a invocação implícita dos gatilhos necessários?
7. Validação da presença de quaisquer procedimentos armazenados não utilizados.
8. Validação para a condição Permitir Nulo que pode ser feita no nível do banco de dados.
9. Validação de que todos os Stored Procedures e Functions foram executados com sucesso quando o Banco de Dados em teste está em branco.
10. Validação da integração geral dos módulos de procedimento armazenado de acordo com os requisitos da aplicação em teste.

Algumas das ferramentas úteis de teste de banco de dados para testar procedimentos armazenados são LINQ, ferramenta SP Test, etc.

Teste de gatilho

1. Se as convenções de codificação exigidas foram seguidas durante a fase de codificação dos Triggers?
2. Verifique se os gatilhos executados para as respectivas transações DML atenderam às condições exigidas.
3. O gatilho atualiza os dados corretamente depois de executados?
4. Validação da funcionalidade necessária de acionadores Atualizar/Inserir/Excluir no domínio do aplicativo em teste.

Validações de servidor de banco de dados

1. Verifique as configurações do servidor de banco de dados conforme especificado pelos requisitos de negócios.
2. Verifique a autorização do usuário necessário para executar apenas os níveis de ações exigidos pelo aplicativo.
3. Verifique se o servidor de banco de dados é capaz de atender às necessidades do número máximo permitido de transações de usuários, conforme especificado pelas especificações de requisitos de negócios.

Teste de banco de dados funcional

Teste de banco de dados funcional é um tipo de teste de banco de dados usado para validar os requisitos funcionais de um banco de dados da perspectiva do usuário final. O principal objetivo do teste funcional de banco de dados é testar se as transações e operações realizadas pelos usuários finais relacionadas ao banco de dados funcionam conforme o esperado ou não.

A seguir estão as condições básicas que precisam ser observadas para validações de banco de dados.

• Se o campo é obrigatório ao permitir valores NULL nesse campo?
• Se o comprimento de cada campo é de tamanho suficiente?
• Se todos os campos semelhantes têm os mesmos nomes nas tabelas?
• Se há algum campo computado presente no banco de dados?

Este processo específico é a validação dos mapeamentos de campo do ponto de vista do usuário final. Neste cenário específico, o testador executaria uma operação no nível do banco de dados e, em seguida, navegaria até o item relevante da interface do usuário para observar e validar se as validações de campo adequadas foram realizadas ou não.

A condição vice-versa em que a primeira operação é realizada pelo testador na interface do usuário e depois a mesma é validada no back-end também deve ser feita.

Verificando a integridade e consistência dos dados

As seguintes verificações são importantes

1. Se os dados estão logicamente bem organizados?
2. Se os dados armazenados nas tabelas estão corretos e de acordo com os requisitos do negócio?
3. Existem dados desnecessários presentes no aplicativo em teste?
4. Se os dados foram armazenados de acordo com o requisito em relação aos dados que foram atualizados na interface do usuário?
5. Se as operações TRIM foram executadas nos dados antes de inseri-los no banco de dados em teste?
6. Se as transações foram realizadas de acordo com as especificações dos requisitos de negócios e se os resultados estão corretos ou não?
7. Se os dados foram confirmados corretamente se a transação foi executada com sucesso?
8. Se os dados foram revertidos com sucesso se a transação não tiver sido executada com sucesso pelo usuário final?
9. Se os dados foram revertidos se a transação não tiver sido executada com êxito e vários bancos de dados heterogêneos estiverem envolvidos na transação em questão?
10. Se todas as transações foram executadas usando os procedimentos de design exigidos, conforme especificado pelos requisitos de negócios do sistema?

Login e segurança do usuário

As validações das credenciais de login e segurança do usuário precisam levar em consideração o seguinte.

1. Se o aplicativo impede o usuário de prosseguir no aplicativo no caso de uma

• nome de usuário inválido, mas senha válida
• nome de usuário válido, mas senha inválida.
• nome de usuário inválido e senha inválida.

2. O usuário tem permissão para executar apenas as operações específicas especificadas pelos requisitos de negócios?
3. Se os dados estão protegidos contra acesso não autorizado?
4. Existem diferentes funções de usuário criadas com permissões diferentes?
5. Todos os usuários possuem níveis de acesso exigidos no banco de dados especificado, conforme exigido pelas especificações de negócios?
6. Verifique se dados confidenciais, como senhas e números de cartão de crédito, estão criptografados e não armazenados como texto simples no banco de dados. É uma boa prática garantir que todas as contas tenham senhas complexas e difíceis de adivinhar.

Teste não funcional

Teste não funcional no contexto de testes de banco de dados podem ser categorizados em várias categorias conforme exigido pelos requisitos de negócios. Podem ser testes de carga, testes de estresse, Teste de Segurança, Testando usabilidade e Teste de compatibilidade, e assim por diante. Os testes de carga, bem como os testes de estresse, que podem ser agrupados na gama de testes de desempenho, atendem a dois propósitos específicos quando se trata da função de testes não funcionais.

Quantificação de risco– A quantificação do risco ajuda as partes interessadas a determinar os vários requisitos de tempo de resposta do sistema sob os níveis de carga exigidos. Esta é a intenção original de qualquer garantia de qualidade tarefa. Precisamos de observar que os testes de carga não mitigam o risco diretamente, mas através dos processos de identificação e quantificação de riscos, apresentam oportunidades corretivas e um impulso para a remediação que irá mitigar o risco.

Requisito mínimo de equipamento do sistema– A configuração mínima do sistema que permitirá que o sistema atenda às expectativas de desempenho formalmente declaradas das partes interessadas. Para que hardware e software estranhos e o custo de propriedade associado possam ser minimizados. Este requisito específico pode ser categorizado como o requisito geral de otimização do negócio.

Teste de carga

A finalidade de qualquer teste de carga deve ser claramente compreendida e documentada. Os seguintes tipos de configurações são obrigatórios para teste de carga.

1. As transações de usuários usadas com mais frequência têm o potencial de impactar o desempenho de todas as outras transações se não forem eficientes.
2. Pelo menos uma transação de usuário sem edição deve ser incluída no conjunto de testes final, para que o desempenho de tais transações possa ser diferenciado de outras transações mais complexas.
3. As transacções mais importantes que facilitam os objectivos centrais do sistema devem ser incluídas, uma vez que a falha sob uma carga destas transacções tem, por definição, o maior impacto.
4. Pelo menos uma transação editável deve ser incluída para que atuação dessas transações podem ser diferenciadas de outras transações.
5. Tempo de resposta ideal sob um grande número de usuários virtuais para todos os requisitos potenciais.
6. Tempos efetivos para busca de vários registros.

Ferramentas importantes de teste de carga são LoadRunner Profissional, vencer o corredor e JMeter.

Ferramentas importantes de teste de estresse são LoadRunner Profissional e JMeter.

Problemas mais comuns durante testes de banco de dados

A significant amount of overhead could be involved to determine the state of the database transactions

Solução: O planejamento e o cronograma geral do processo devem ser organizados de modo que não apareçam problemas baseados em tempo e custos.

New test data have to be designed after cleaning up of the old test data.

Solução: Um plano e metodologia prévios para geração de dados de teste devem estar disponíveis.

An SQL generator is required to transform SQL validators in order to ensure the SQL queries are apt for handling the required database test cases.

Solução: A manutenção das consultas SQL e sua atualização contínua é uma parte significativa do processo geral de teste que deve fazer parte do processo geral estratégia de teste.

The above mentioned prerequisite ensure that the set-up of the database testing procedure could be costly as well as time consuming.

Solução: Deve haver um equilíbrio delicado entre a qualidade e a duração geral do cronograma do projeto.

Mitos ou equívocos relacionados ao teste de banco de dados

Database Testing requires plenty of expertise and it is a very tedious job

Realidade: Testes de banco de dados eficazes e eficientes em testes de software fornecem estabilidade funcional de longo prazo para o aplicativo geral, portanto, é necessário trabalhar duro para isso.

Database testing adds extra work bottleneck

Realidade: Pelo contrário, os testes de banco de dados agregam mais valor ao trabalho geral, descobrindo problemas ocultos e, assim, ajudando proativamente a melhorar a aplicação geral.

Database testing slows down the overall development process

Realidade: Uma quantidade significativa de testes de banco de dados ajuda na melhoria geral da qualidade do aplicativo de banco de dados.

Database testing could be excessively costly

Realidade: Qualquer gasto em testes de banco de dados é um investimento de longo prazo que leva à estabilidade e robustez do aplicativo a longo prazo. Assim, as despesas com testes de banco de dados ou SQL O teste é necessário.

Melhores Práticas

• Todos os dados, incluindo os metadados, bem como os dados funcionais, precisam ser validados de acordo com seu mapeamento pelos documentos de especificação de requisitos.
• Verificação do dados de teste que foi criado por/em consulta com a equipe de desenvolvimento precisa ser validado.
• Validação dos dados de saída usando procedimentos manuais e automatizados.
• Implantação de várias técnicas, como a técnica de gráficos de causa e efeito, técnica de particionamento de equivalência e técnica de análise de valor limite para geração de condições de dados de teste necessárias.
• As regras de validação de integridade referencial para as tabelas de banco de dados necessárias também precisam ser validadas.
• A seleção dos valores padrão da tabela para validação da consistência do banco de dados é um conceito muito importante Se os eventos de log foram adicionados com sucesso no banco de dados para todos os eventos de login necessários
• Os trabalhos agendados são executados em tempo hábil?
• Faça backup oportuno do banco de dados.

Verifique também Perguntas e respostas da entrevista sobre teste de banco de dados