Teste de banco de dados - Guia rápido

O teste de banco de dados inclui a validação de dados, teste de integridade de dados, verificação de desempenho relacionado ao banco de dados e teste de procedimentos, gatilhos e funções no banco de dados.

Exemplo

Considere um aplicativo que captura os detalhes da transação do dia a dia para os usuários e armazena os detalhes no banco de dados. Do ponto de vista do teste de banco de dados, as seguintes verificações devem ser realizadas -

• As informações transacionais da aplicação devem ser armazenadas no banco de dados e devem fornecer informações corretas ao usuário.

• As informações não devem ser perdidas quando são carregadas no banco de dados.

• Apenas as transações concluídas devem ser armazenadas e todas as operações incompletas devem ser abortadas pelo aplicativo.

• A autorização de acesso ao banco de dados deve ser mantida. Nenhum acesso não aprovado ou não autorizado às informações do usuário deve ser fornecido.

Por que você precisa realizar testes de banco de dados?

Existem vários motivos pelos quais o teste de banco de dados é executado. É necessário realizar a verificação da integridade, validação e consistência dos dados no banco de dados, pois o sistema backend é responsável por armazenar os dados e é acessado para fins múltiplos.

A seguir estão alguns motivos comuns para testes de banco de dados -

• Para diminuir a complexidade das chamadas para o back-end do banco de dados, os desenvolvedores aumentam o uso de View e Stored Procedimentos.

• Estes Stored procedimentos e Viewscontêm tarefas críticas, como inserir detalhes do cliente (nome, informações de contato, etc.) e dados de vendas. Essas tarefas precisam ser testadas em vários níveis.

• Black-box testingexecutado no front-end é importante, mas torna difícil isolar o problema. O teste no sistema de back-end aumenta a robustez dos dados. É por isso que o teste do banco de dados é executado no sistema back end.

• Em um banco de dados, os dados vêm de vários aplicativos e existe a possibilidade de que dados prejudiciais ou incorretos sejam armazenados no banco de dados. Portanto, é necessário verificar os componentes do banco de dados regularmente. Além disso, a integridade e a consistência dos dados devem ser verificadas regularmente.

Teste de banco de dados versus teste de front-end

O teste de banco de dados é diferente do teste de interface do usuário de front-end. A tabela a seguir destaca as principais diferenças -

Com base na função e estrutura de um banco de dados, o teste de banco de dados pode ser categorizado em três categorias -

• Structural Database Testing - Lida com teste de tabela e coluna, teste de esquema, procedimentos armazenados e testes de visualizações, verificação de gatilhos, etc.

• Functional Testing- Envolve a verificação da funcionalidade do banco de dados do ponto de vista do usuário. Os tipos mais comuns de teste funcional são os testes de caixa branca e caixa preta.

• Nonfunctional Testing - Envolve teste de carga, teste de risco em banco de dados, teste de estresse, requisitos mínimos do sistema e lida com o desempenho do banco de dados.

Teste de banco de dados estrutural

O teste de banco de dados estrutural envolve a verificação dos componentes do banco de dados, que não são expostos aos usuários finais. Envolve todos os componentes do repositório, que são usados ​​para armazenar os dados e não são alterados pelos usuários finais. Administradores de banco de dados com bom comando sobre procedimentos armazenados SQL e outros conceitos normalmente executam esse teste.

Discutidos são os componentes comuns testados com relação aos testes estruturais -

Esquema / Teste de Mapeamento

Envolve a validação dos objetos do aplicativo front-end com o mapeamento de objetos do banco de dados.

No Teste de Esquema -

• Às vezes, acontece que os objetos do aplicativo do usuário final não são mapeados corretamente ou não são compatíveis com os objetos do banco de dados. Portanto, é necessário verificar a validação dos vários formatos de esquema associados aos bancos de dados.

• É necessário encontrar os objetos não mapeados no banco de dados, como tabelas, visualizações, colunas etc.

Existem várias ferramentas no mercado que podem ser utilizadas para realizar o mapeamento de objetos em esquemas.

Example - No Microsoft SQL Server, um testador pode escrever consultas simples para verificar e validar esquemas no banco de dados.

Se o testador deseja fazer alterações na estrutura de uma tabela, ele deve garantir que todos os stored procedimentos que possuem essa tabela são compatíveis com esta mudança.

Procedimentos armazenados e testes de visualizações

Nesse teste, um testador garante que a execução manual de procedimentos armazenados e visualizações gere o resultado necessário.

O testador garante -

• Se permitir que os gatilhos necessários sejam executados conforme o esperado.

• Se a equipe de desenvolvimento cobriu todos os loops e condições, passando a entrada para os aplicativos nos procedimentos.

• Se houver algum procedimento armazenado não utilizado no banco de dados.

• As operações TRIM são aplicadas corretamente quando os dados são buscados nas tabelas necessárias no banco de dados.

• Validação da integração geral dos módulos de procedimento armazenado de acordo com os requisitos do aplicativo em teste.

• Mecanismos de exceção e tratamento de erros são seguidos.

As ferramentas mais comuns usadas para realizar testes de procedimentos armazenados são LINQ, SP Test tooletc.

Teste de gatilho

No teste de gatilho, um testador precisa garantir o seguinte -

• Se as convenções de codificação são seguidas durante a fase de codificação dos gatilhos.

• Veja se os gatilhos executados atendem às condições exigidas.

• Se o gatilho atualiza os dados corretamente, uma vez que eles foram executados.

• Validação da funcionalidade de gatilhos Atualizar / Inserir / Excluir aplicativo em teste.

Teste de tabelas e colunas

As principais áreas cobertas neste teste são -

• Validando os tipos de dados no banco de dados para valores de campo no aplicativo front-end.

• Validando o comprimento do campo de dados no banco de dados para o comprimento dos tipos de dados no aplicativo.

• Verificar se existem tabelas ou colunas não mapeadas no banco de dados de objetos de campo do aplicativo.

• As convenções de nomenclatura das tabelas e colunas do banco de dados são verificadas, se estão de acordo com os requisitos do negócio ou não.

• Validando as Chaves e Índices no banco de dados, ou seja, as chaves primárias e estrangeiras nas tabelas são definidas conforme a necessidade.

• Verifique se as chaves primárias e suas chaves estrangeiras correspondentes são iguais nas duas tabelas.

• Verifique se as características Unique e NOT NULL das chaves são mantidas.

• O comprimento e o tipo de dados das chaves e índices são mantidos de acordo com o requisito.

Verificação do servidor de banco de dados

A verificação do servidor de banco de dados envolve verificar -

• Se o servidor de banco de dados pode lidar com o número esperado de transações de acordo com os requisitos de negócios.

• Se os detalhes de configuração dos servidores de banco de dados atendem aos requisitos de negócios.

• Se a autorização do usuário for mantida de acordo com o requisito.

Teste funcional

O teste funcional é executado tendo em mente o ponto de vista do usuário final; se as transações e operações necessárias executadas pelos usuários finais atendem às especificações de negócios.

Teste de caixa preta

O teste da caixa preta envolve a verificação da integração do banco de dados para verificar a funcionalidade. Os casos de teste são simples e são usados ​​para verificar os dados de entrada e de saída da função.

Várias técnicas, como técnica de representação gráfica de causa e efeito, particionamento de equivalência e análise de valor limite, são usadas para testar a funcionalidade do banco de dados.

Está advantages são os seguintes -

• É bastante simples e é executado nos estágios iniciais de desenvolvimento.
• O custo de desenvolver casos de teste é menor em comparação com o teste de caixa branca.

Suas desvantagens são as seguintes -

• Alguns erros não podem ser detectados
• Não se sabe quanto programa precisa ser testado.

Teste de caixa branca

O teste de caixa branca lida com a estrutura interna do banco de dados e os detalhes da especificação são ocultados dos usuários. Envolve o teste de gatilhos de banco de dados e visualizações lógicas, que irão suportar a refatoração de banco de dados.

Realiza teste de módulo de funções de banco de dados, gatilhos, visualizações, consultas SQL etc. Este tipo de teste valida tabelas de banco de dados, modelos de dados, esquema de banco de dados etc. Ele verifica as regras de integridade referencial. Ele seleciona os valores da tabela padrão para verificar a consistência do banco de dados.

As técnicas mais comuns usadas para realizar o teste de caixa branca são cobertura de condição, cobertura de decisão, cobertura de declaração, etc.

Erros de codificação podem ser detectados em testes de caixa branca, de forma que bugs internos no banco de dados possam ser eliminados. A limitação do teste de caixa branca é que as instruções SQL não são cobertas.

Teste Não Funcional

O teste não funcional envolve a realização de teste de carga, teste de estresse, verificação dos requisitos mínimos do sistema para atender às especificações do negócio, descoberta de risco e otimização de desempenho do banco de dados.

Teste de carga

O objetivo principal do teste de carga é verificar se a maioria das transações em execução tem impacto no desempenho do banco de dados.

No teste de carga, o testador verifica -

• O tempo de resposta para executar as transações para vários usuários remotos.
• Tempo gasto pelo banco de dados para buscar registros específicos.

Examples of load testing in different testing types -

• Executando a transação mais usada repetidamente para ver o desempenho do sistema de banco de dados.
• Baixando uma série de arquivos grandes da Internet.
• Executar vários aplicativos em um computador ou servidor simultaneamente.

Teste de Estresse

O teste de estresse é executado para identificar o ponto de interrupção do sistema. Neste teste, o aplicativo é carregado de tal forma que o sistema falha em um ponto. Este ponto é chamado debreakpoint do sistema de banco de dados.

Determinar o estado das transações do banco de dados envolve uma quantidade significativa de esforço. É necessário um planejamento adequado para evitar problemas de tempo e custos.

As ferramentas de teste de estresse mais comumente usadas são LoadRunner e WinRunner.

Vamos dar uma examplede teste de estresse. Um aplicativo de CRM pode ter uma carga máxima de 50.000 usuários simultâneos. Suponha que você aumente a carga para 51000 e faça algumas transações, como atualizar registros ou adicionar uma entrada. Assim que você fizer a transação, o aplicativo pode sincronizar com o sistema de banco de dados. Portanto, o próximo teste é executado com uma carga de usuário de 52.000. Às vezes, o teste de estresse também é chamadoFatigue Testing.

O processo para realizar o teste do banco de dados é semelhante ao teste de outros aplicativos. O teste de banco de dados pode ser descrito com os principais processos fornecidos abaixo.

• Configure o ambiente
• Faça um teste
• Verifique o resultado do teste
• Validar de acordo com os resultados esperados
• Relate as descobertas às respectivas partes interessadas

Várias instruções SQL são usadas para desenvolver os casos de teste. A instrução SQL mais comum, que é usada para realizar testes de banco de dados, é oSelectdeclaração. Além disso, várias instruções DDL, DML, DCL também podem ser usadas.

Example - Criar, inserir, selecionar, atualizar, etc.

Estágios de teste de banco de dados

O teste de banco de dados não é um processo tedioso e inclui vários estágios no ciclo de vida do teste de banco de dados de acordo com os processos de teste.

Os principais estágios do teste de banco de dados são -

• Verificando o estado inicial
• Execução de teste
• Validação de resultado de acordo com o resultado esperado
• Gerando os resultados

First stageem Teste de banco de dados é verificar o estado inicial do banco de dados antes de iniciar o processo de teste. Em seguida, o comportamento do banco de dados é testado para casos de teste definidos. De acordo com os resultados obtidos, os casos de teste são customizados.

Para um teste de banco de dados bem-sucedido, o fluxo de trabalho fornecido a seguir é executado por cada um dos testes.

• Cleaning up the database - Se houver dados testáveis ​​no banco de dados, ele deve ser esvaziado.

• Set up Fixture - Isso envolve inserir os dados no banco de dados e verificar o estado atual do banco de dados.

• Perform test, verify results and generate results- O teste é executado e a saída é verificada. Se a saída for conforme os resultados esperados, a próxima etapa é gerar os resultados de acordo com o requisito. Caso contrário, o teste é repetido para encontrar os bugs no banco de dados.

Este capítulo explica as técnicas mais comuns usadas para realizar testes de banco de dados.

Teste de esquema de banco de dados

Conforme mencionado anteriormente, envolve testar cada objeto no Esquema.

Verificando bancos de dados e dispositivos

• Verificando o nome do banco de dados
• Verificando o dispositivo de dados, dispositivo de registro e dispositivo de despejo
• Verificando se espaço suficiente alocado para cada banco de dados
• Verificando a configuração da opção do banco de dados

Verificação de regras de tabelas, colunas e tipos de coluna

Verifique os itens fornecidos abaixo para descobrir as diferenças entre a configuração real e aplicada.

• Nome de todas as tabelas no banco de dados

• Nomes de colunas para cada tabela

• Tipos de coluna para cada tabela

• NULL valor verificado ou não

• Se um padrão está vinculado às colunas corretas da tabela

• Definições de regras para corrigir nomes de tabelas e privilégios de acesso

Chave e índices

Verifique a chave e os índices em cada tabela -

• Chave primária para cada tabela

• Chaves estrangeiras para cada tabela

• Tipos de dados entre uma coluna de chave estrangeira e uma coluna em outros índices da tabela, agrupados ou não agrupados exclusivos ou não exclusivos

Testes de procedimento armazenado

Envolve verificar se um procedimento armazenado está definido e se os resultados de saída são comparados. Em um teste de procedimento armazenado, os seguintes pontos são verificados -

• Nome do procedimento armazenado

• Nomes de parâmetros, tipos de parâmetros, etc.

• Output- Se a saída contém muitos registros. Zero linhas são afetadas ou apenas alguns registros são extraídos.

• Qual é a função do procedimento armazenado e o que um procedimento armazenado não deve fazer?

• Passar consultas de entrada de amostra para verificar se um procedimento armazenado extrai dados corretos.

• Stored Procedure Parameters- Chame o procedimento armazenado com dados de limite e com dados válidos. Torne cada parâmetro inválido uma vez e execute um procedimento.

• Return values- Verifique os valores que são retornados pelo procedimento armazenado. Em caso de falha, um valor diferente de zero deve ser retornado.

• Error messages check- Faça alterações de forma que o procedimento armazenado falhe e gere todas as mensagens de erro pelo menos uma vez. Verifique todos os cenários de exceção quando não houver mensagem de erro predefinida.

Testes de gatilho

Em um teste de gatilho, o testador deve realizar as seguintes tarefas -

• Certifique-se de que o nome do gatilho está correto.
• Valide o gatilho se ele for gerado para uma coluna de tabela específica.
• Validação de atualização do acionador.
• Atualize um registro com dados válidos.
• Atualize um registro com dados inválidos e cubra todos os erros do acionador.
• Atualiza um registro quando ele ainda é referenciado por uma linha em outra tabela.
• Garanta a reversão das transações quando ocorrer uma falha.
• Descubra todos os casos em que um acionador não deva reverter as transações.

Scripts de configuração do servidor

Dois tipos de testes devem ser realizados -

• Configurando o banco de dados do zero e
• Para configurar um banco de dados existente.

Testes de Integração do SQL Server

Os testes de integração devem ser executados depois de concluir os testes de componentes.

• Os procedimentos armazenados devem ser chamados intensamente para selecionar, inserir, atualizar e excluir registros em tabelas diferentes para localizar quaisquer conflitos e incompatibilidades.

• Quaisquer conflitos entre esquema e gatilhos.

• Quaisquer conflitos entre procedimentos armazenados e esquema.

• Quaisquer conflitos entre procedimentos armazenados e gatilhos.

Método de teste funcional

O teste funcional pode ser executado dividindo o banco de dados em módulos de acordo com a funcionalidade. As funcionalidades são dos seguintes dois tipos -

• Type 1- No teste Tipo 1, descubra as características do projeto. Para cada recurso principal, descubra o esquema, os gatilhos e os procedimentos armazenados responsáveis ​​por implementar essa função e colocá-los em um grupo funcional. Em seguida, teste cada grupo juntos.

• Type 2- No teste do Tipo 2, a fronteira dos grupos funcionais em um back-end não é óbvia. Você pode verificar o fluxo de dados e ver onde pode verificar os dados. Comece pelo front-end.

O seguinte processo ocorre -

• Quando um serviço tem uma solicitação ou salva dados, alguns procedimentos armazenados serão chamados.

• Os procedimentos irão atualizar algumas tabelas.

• Esses procedimentos armazenados serão o local para iniciar o teste e essas tabelas serão o local para verificar os resultados do teste.

Teste de Estresse

O teste de resistência envolve obter uma lista das principais funções do banco de dados e procedimentos armazenados correspondentes. Siga as etapas fornecidas abaixo para o teste de estresse -

• Escreva scripts de teste para tentar essas funções e cada função deve ser verificada pelo menos uma vez em um ciclo completo.

• Execute os scripts de teste novamente e novamente por um período de tempo específico.

• Verificar os arquivos de log para verificar quaisquer bloqueios, falha de memória, corrupção de dados, etc.

Teste de referência

Se seu banco de dados não tiver problemas de dados ou bugs, o desempenho do sistema pode ser verificado. Um fraco desempenho do sistema pode ser encontrado em testes de benchmark, verificando os parâmetros fornecidos abaixo -

• Desempenho de nível de sistema
• Identificar funções / recursos provavelmente usados
• Tempo - tempo máximo, tempo mínimo e tempo médio para executar funções
• Volume de acesso

Testando um banco de dados via front-end

Bugs de back-end também podem ser encontrados às vezes fazendo testes de front-end. Você pode seguir as etapas simples fornecidas abaixo para detectar bugs por meio de testes de front-end.

• Escreva consultas do front-end e emita as pesquisas.

• Pegue um registro existente, altere os valores em alguns campos e salve o registro. (Envolve a instrução UPDATE ou atualiza procedimentos armazenados e atualiza gatilhos.)

• Insira um novo item de menu na janela do front-end. Preencha as informações e salve o registro. (Envolve as instruções INSERT ou procedimentos armazenados de inserção e gatilhos de exclusão.)

• Pegue um registro existente, clique no botão EXCLUIR ou REMOVER e confirme a exclusão. (Envolve a instrução DELETE ou procedimentos armazenados de exclusão e gatilhos de exclusão.)

• Repita esses casos de teste com dados inválidos e veja como o banco de dados responde.

Neste capítulo, veremos alguns cenários comuns de teste de banco de dados com relação a vários métodos de teste.

Teste de banco de dados estruturado

Cenários de banco de dados comuns com relação ao teste de banco de dados estruturado são fornecidos abaixo -

• Verificando o nome do banco de dados, verificando o dispositivo de dados, dispositivo de log e dispositivo de dump, verificando se espaço suficiente alocado para cada banco de dados e verificando a configuração das opções do banco de dados.

• Nomes de todas as tabelas no banco de dados, nomes de colunas para cada tabela, tipos de colunas para cada tabela, verificação de valor nulo ou não. Verifique a chave e os índices em cada tabela: chave primária para cada tabela, chaves estrangeiras para cada tabela.

• Tipos de dados entre uma coluna de chave estrangeira e uma coluna em outros índices de tabela, agrupados ou não agrupados exclusivos ou não exclusivos.

Teste de banco de dados funcional

Cenários de teste de banco de dados comuns com relação a Functional Database Testing são -

• Descobrir o esquema, gatilhos e procedimentos armazenados responsáveis ​​por implementar essa função e torná-los em um grupo funcional e, em seguida, cada grupo pode ser testado em conjunto.

• Verifique o fluxo de dados e veja onde você pode verificar os dados. Comece pelo front-end.

Teste de banco de dados não funcional

Cenários de teste de banco de dados comuns com relação a Non-Functional Database Testing são -

• Escreva scripts de teste para experimentar as funções principais e cada função deve ser verificada pelo menos uma vez em um ciclo completo.

• Execute os scripts de teste novamente e novamente por um período de tempo específico.

• Verificar os arquivos de log para verificar qualquer bloqueio, falha de memória, corrupção de dados, etc.

• Escreva consultas de um front end e execute as pesquisas. Pegue um registro existente, altere os valores em alguns campos e salve o registro. (Envolve a instrução UPDATE ou procedimentos armazenados de atualização, gatilhos de atualização.)

• Insira um novo item de menu em uma janela de front-end. Preencha as informações e salve o registro. (Envolve instruções INSERT ou procedimentos armazenados de inserção, gatilhos de exclusão.)

• Pegue um registro existente, clique no botão EXCLUIR ou REMOVER e confirme a exclusão. (Envolve a instrução DELETE ou procedimentos armazenados de exclusão, gatilhos de exclusão.)

• Repita esses casos de teste com dados inválidos e veja como o banco de dados responde.

Schemas, tables, stored procedures, e Triggerssão objetos-chave de um banco de dados. Já compartilhamos tipos de teste de banco de dados e cenários de teste para esses objetos de banco de dados.

Esquemas

Um esquema de banco de dados define a estrutura de um sistema de banco de dados em um formato compatível com o sistema de gerenciamento de banco de dados. Um esquema refere-se a como um banco de dados é estruturado (composto de tabelas de banco de dados no caso de bancos de dados relacionais).

O esquema do banco de dados é um conjunto de fórmulas chamadas restrições de integridade impostas a um banco de dados. Essas restrições de integridade garantem a compatibilidade entre as partes do esquema.

Em um banco de dados relacional, o esquema consiste em tabelas, campos, visualizações, índices, pacotes, procedimentos, funções, gatilhos, tipos, visualizações materializadas, sinônimos, links de banco de dados e outros elementos.

Os esquemas são geralmente armazenados em um dicionário de dados. Embora um esquema seja definido em linguagem de banco de dados de texto, o termo é freqüentemente usado para se referir a uma representação gráfica da estrutura do banco de dados. Em outras palavras, o esquema é a estrutura do banco de dados que define os objetos no banco de dados.

Tipos comuns de esquemas usados ​​em um data warehouse são -

• Esquema Star
• Esquema de flocos de neve
• Galaxy Schema

Tabelas no banco de dados

Em um banco de dados relacional, uma tabela é usada para organizar as informações em linhas e colunas.

Example - Uma tabela de clientes contém informações como id do cliente, endereços, números de telefone e assim por diante como uma série de colunas.

Cada dado é um campo da tabela. Uma coluna consiste em todas as entradas em um único campo, como os números de telefone de todos os clientes. Os campos são organizados como registros, que são conjuntos completos de informações (como o conjunto de informações sobre um cliente específico), cada um composto por uma linha.

Procedimentos armazenados

Um procedimento armazenado é uma série de instruções SQL armazenadas no banco de dados em um formato compilado e vários programas podem compartilhá-lo. O uso de procedimentos armazenados pode ser útil para manter a integridade dos dados, controlar o acesso aos dados e melhorar a produtividade.

Gatilhos

Um gatilho de banco de dados é um código executado em resposta a certos eventos em uma determinada tabela ou exibição em um banco de dados. O gatilho é usado principalmente para manter a integridade das informações no banco de dados.

A integridade dos dados é importante em um banco de dados. Inclui validação de dados antes da inserção, atualizações e exclusão. Os gatilhos devem estar implementados para validar os registros da tabela de referência.

Para verificar a integridade dos dados, você precisa realizar as seguintes operações -

• Você precisa verificar as colunas principais em cada tabela e verificar se existem dados incorretos. (Caracteres no campo de nome, porcentagem negativa, etc.)

• Descubra dados inconsistentes e insira-os nas tabelas relevantes e veja se ocorre alguma falha.

• Insira os dados de um filho antes de inserir os dados de seu pai. Tente excluir um registro que ainda é referenciado pelos dados em outra tabela.

• Se os dados de uma tabela forem atualizados, verifique se os outros dados relevantes também são atualizados. Você precisa garantir que os servidores ou bancos de dados replicados estejam em sincronia e contenham informações consistentes.

O mapeamento de dados em um banco de dados é um dos principais conceitos que precisa ser validado por cada testador. Normalmente, os testadores precisam verificar o mapeamento do campo front-end da interface do usuário com o campo do banco de dados back-end correspondente.

Essas informações são fornecidas no documento SRS / BRS de especificação de requisitos de software ou especificação de requisitos de negócios. Se o mapeamento não for fornecido, você precisará verificar a parte de codificação.

Quando você executa qualquer ação no aplicativo front-end, uma ação CRUD correspondente é chamada e o testador deve verificar se cada ação chamada foi bem-sucedida ou não.

Aspectos chave do mapeamento de dados

A seguir estão os principais aspectos do mapeamento de dados -

• Para verificar os campos nos formulários UI / Front end e mapeados de forma consistente com a tabela de banco de dados correspondente. Essas informações de mapeamento são definidas nos documentos de requisitos conforme mencionado acima.

• Para qualquer ação realizada no front end de um aplicativo, uma ação CRUD correspondente 'Criar, Recuperar, Atualizar e excluir' é iniciada no back end.

• Um testador terá que verificar se a ação correta foi invocada e se a ação invocada em si foi bem-sucedida ou não.

Etapas no teste de mapeamento de dados

A seguir estão as etapas seguidas para o teste de mapeamento de dados -

• Step 1 - Primeiro verifique se há erros de sintaxe em cada script.

• Step 2 - Em seguida, é verificar o mapeamento de tabela, mapeamento de coluna e mapeamento de tipo de dados.

• Step 3 - Verifique o mapeamento de dados de pesquisa.

• Step 4 - Execute cada script quando os registros não existirem nas tabelas de destino.

• Step 5 - Execute cada script quando os registros já existirem nas tabelas de destino.

Um aplicativo com mais tempo de resposta e baixo desempenho pode levar a grandes problemas. O Teste de Carga de Banco de Dados é usado para localizar quaisquer problemas de desempenho antes de implantar seus aplicativos de banco de dados para usuários finais.

O Teste de carga de banco de dados ajuda a projetar aplicativos de banco de dados para desempenho, confiabilidade e escalabilidade. O teste de carga de aplicativos de banco de dados envolve o teste de desempenho e escalabilidade de seu aplicativo de banco de dados com carga de usuário variável.

O teste de carga do banco de dados envolve a simulação da carga do usuário na vida real para o aplicativo de banco de dados de destino. Ajuda a determinar como seu aplicativo de banco de dados se comporta quando vários usuários o acessam simultaneamente.

Teste de carga

O objetivo principal do Teste de Carga é verificar se a maioria das transações em execução tem impacto no desempenho do banco de dados. No teste de carga, você precisa verificar os seguintes aspectos -

• O tempo de resposta para executar as transações para vários usuários remotos deve ser verificado.

• Com transações normais, você deve incluir uma transação editável para verificar o desempenho do banco de dados para essas transações do tipo pf.

• Com transações normais, você deve incluir uma transação sem edição para verificar o desempenho do banco de dados para esse tipo de transação.

• O tempo gasto pelo banco de dados para buscar registros específicos deve ser verificado.

Teste de Estresse

O teste de estresse é realizado para identificar o sistema breakpoint. Aqui, o aplicativo é carregado de tal forma que o sistema falha em um ponto. Esse ponto é chamado de ponto de interrupção do sistema de banco de dados. O teste de estresse também é conhecido comoFatigue Testing.

Determinar o estado das transações do banco de dados envolve uma quantidade significativa de esforço. O planejamento adequado é necessário para evitar quaisquer problemas baseados em tempo e custo.

As ferramentas de teste de estresse mais comuns são LoadRunner e WinRunner.

Existem várias ferramentas fornecidas por fornecedores que podem ser usadas para gerar dados de teste, para gerenciar dados de teste e realizar testes de banco de dados como teste de carga e teste de regressão.

Algumas ferramentas comuns usadas são fornecidas abaixo.

A parte mais importante de um crescimento organizacional são seus dados. Em caso de falha do sistema, é necessário restaurar os dados. O backup é uma cópia exata do banco de dados, o que ajuda a restaurar seus dados em caso de perda de dados.

Considere uma empresa financeira que possui dados relacionados a seus clientes, como número do A / C, nomes de clientes, crédito e débitos, duração, etc. Como tal organização lidaria com a pressão de perder informações tão importantes em caso de falha de dados?

Esta é a razão pela qual você faz backup dos dados para que, em caso de qualquer falha de um disco, controlador de disco, etc., você possa contar com o backup para restaurá-lo no banco de dados.

Tipos de backups de dados

Existem dois tipos de backup que podem ser usados ​​-

• Physical Backups - O backup físico inclui fazer o backup usando ferramentas de backup de terceiros, como Veritas Net Back, IBM Tivoli Manager ou backups do gerenciador de usuários usando utilitários do sistema operacional.

• Logical Backups - O backup lógico do banco de dados inclui fazer backups de objetos lógicos como tabelas, índices, procedimentos, etc.

Example - Uma das ferramentas comuns para fazer backup de dados é Oracle Recovery Manager (RMAN) que é um utilitário Oracle para fazer backup do banco de dados.

RMAN consiste em dois componentes -

• Target database para o qual o backup é necessário.

• RMAN cliente é usado para executar comandos para fazer backup de dados.

BACKUP VALIDATEé usado para testar se você é capaz de fazer um backup válido dos arquivos do banco de dados. Isso garante -

• Se o backup estiver em vigor para objetos físicos ou lógicos do banco de dados.
• Se backups regulares forem configurados para dados valiosos.
• Se a ferramenta de backup atende aos requisitos de backup de uma organização.

Database recovery testingé usado para garantir que o banco de dados seja recuperado. O teste de recuperação permite que você descubra se o aplicativo está sendo executado corretamente e verifique a recuperação de dados valiosos que seriam perdidos se o método de recuperação não estivesse configurado corretamente.

Você também verifica se vários processos críticos estão funcionando sem problemas para garantir que a recuperação de dados passe sem problemas pela fase de teste.

Você pode realizar as seguintes verificações para recuperação de banco de dados -

• Quaisquer erros ou erros no software para backup e você precisará resolver esses problemas em um estágio anterior.

• Você precisa conduzir o teste de recuperação para saber o que fazer em caso de uma situação de emergência.

• Você precisa verificar as necessidades de teste de recuperação para que possa planejar uma estratégia de recuperação eficaz.

• Você também deve saber como recuperar os documentos.

Você precisa executar os testes de recuperação na fase inicial do projeto. Isso permite que você remova e descarte todos os tipos de erros do sistema. Aqui está uma lista de alguns pontos importantes, que devem ser considerados no momento do teste -

• Período de tempo em que ocorrem mudanças ou modificações no sistema de banco de dados.

• O período em que você deseja que seu plano de recuperação seja conduzido.

• A sensibilidade dos dados no sistema de banco de dados. Quanto mais críticos forem os dados, mais regularmente você precisará testar o software.

Etapas comuns no teste de backup e recuperação de banco de dados

No teste de recuperação de banco de dados, você precisa executar o teste no ambiente real para verificar se o sistema ou os dados podem realmente ser recuperados em caso de desastres e quaisquer outros eventos imprevistos no ambiente de negócios.

A seguir estão as ações comuns realizadas no Teste de Recuperação de Banco de Dados -

• Teste do sistema de banco de dados
• Teste dos arquivos SQL
• Teste de arquivos parciais
• Teste de backup de dados
• Teste da ferramenta de backup
• Testando backups de registro

O teste de segurança do banco de dados é feito para encontrar as brechas nos mecanismos de segurança e também para encontrar as vulnerabilidades ou fraquezas do sistema de banco de dados.

O principal objetivo dos testes de segurança de banco de dados é descobrir vulnerabilidades em um sistema e determinar se seus dados e recursos estão protegidos contra invasores em potencial. Os testes de segurança definem uma maneira de identificar vulnerabilidades potenciais com eficácia, quando realizados regularmente.

A seguir estão os principais objetivos da realização de testes de segurança de banco de dados -

• Authentication
• Authorization
• Confidentiality
• Availability
• Integrity
• Resilience

Tipos de ameaças em um sistema de banco de dados

Injeção SQL

Este é o tipo mais comum de ataque em um sistema de banco de dados onde instruções SQL maliciosas são inseridas no sistema de banco de dados e são executadas para obter informações críticas do sistema de banco de dados. Este ataque tira proveito de lacunas na implementação de aplicativos de usuário. Para evitar isso, os campos de entrada do usuário devem ser tratados com cuidado.

Elevação de privilégio no banco de dados

Neste ataque, um usuário já possui algum acesso no sistema de banco de dados e ele apenas tenta elevar este nível de acesso para que possa realizar algumas atividades não autorizadas no sistema de banco de dados.

Negação de serviço

Nesse tipo de ataque, um invasor torna um sistema de banco de dados ou recurso de aplicativo indisponível para seus usuários legítimos. Os aplicativos também podem ser atacados de maneiras que tornam o aplicativo, e às vezes a máquina inteira, inutilizável.

Acesso não autorizado aos dados

Outro tipo de ataque é obter acesso não autorizado aos dados em um aplicativo ou sistema de banco de dados. O acesso não autorizado inclui -

• Acesso não autorizado a dados por meio de aplicativos baseados no usuário
• Acesso não autorizado, monitorando o acesso de terceiros
• Acesso não autorizado a informações reutilizáveis ​​de autenticação de cliente

Spoofing de identidade

No Identity Spoofing, um hacker usa as credenciais de um usuário ou dispositivo para lançar ataques contra hosts de rede, roubar dados ou contornar os controles de acesso ao sistema de banco de dados. A prevenção desse ataque requer infra-estrutura de TI e mitigações em nível de rede.

Manipulação de dados

Em um ataque de manipulação de dados, um hacker altera os dados para obter alguma vantagem ou para danificar a imagem dos proprietários do banco de dados.

Técnicas de teste de segurança de banco de dados

Teste de Penetração

Um teste de penetração é um ataque a um sistema de computador com a intenção de encontrar brechas de segurança, potencialmente obtendo acesso a ele, sua funcionalidade e dados.

Descoberta de risco

A Detecção de Risco é um processo de avaliação e decisão sobre o risco envolvido com o tipo de perda e a possibilidade de ocorrência de vulnerabilidade. Isso é determinado dentro da organização por várias entrevistas, discussões e análises.

Teste de Injeção SQL

Envolve a verificação das entradas do usuário nos campos do aplicativo. Por exemplo, inserir um caractere especial como ',' ou ';' em qualquer caixa de texto em um aplicativo de usuário não deve ser permitido. Quando ocorre um erro no banco de dados, significa que a entrada do usuário é inserida em alguma consulta, que é então executada pela aplicação. Nesse caso, o aplicativo fica vulnerável à injeção de SQL.

Esses ataques são uma grande ameaça aos dados, pois os invasores podem obter acesso a informações importantes do banco de dados do servidor. Para verificar os pontos de entrada de injeção de SQL em seu aplicativo da web, descubra o código de sua base de código onde consultas diretas do MySQL são executadas no banco de dados aceitando algumas entradas do usuário.

O teste de injeção SQL pode ser executado para colchetes, vírgulas e aspas.

Quebra de senha

Esta é a verificação mais importante ao realizar o teste do sistema de banco de dados. Para acessar informações críticas, os hackers podem usar uma ferramenta de quebra de senha ou adivinhar um nome de usuário / senha comum. Essas senhas comuns estão facilmente disponíveis na Internet e também existem ferramentas de cracking de senha livremente.

Portanto, é necessário verificar na hora do teste se a política de senhas é mantida no sistema. No caso de quaisquer aplicações bancárias e financeiras, é necessário definir uma política de senha rígida em todos os sistemas de banco de dados de informações críticas.

Auditoria de segurança do sistema de banco de dados

Uma auditoria de segurança é um processo de avaliação das políticas de segurança da empresa em um intervalo de tempo regular para determinar se os padrões necessários são seguidos ou não. Vários padrões de segurança podem ser seguidos de acordo com os requisitos de negócios para definir a política de segurança e, em seguida, a avaliação das políticas definidas em relação a esses padrões pode ser feita.

Exemplos dos padrões de segurança mais comuns são ISO 27001, BS15999, etc.

Ferramentas de teste de segurança de banco de dados

Existem várias ferramentas de teste de sistema disponíveis no mercado, que podem ser usadas para testar o sistema operacional e verificar o aplicativo. Algumas das ferramentas mais comuns são discutidas abaixo.

Zed Attack Proxy

É uma ferramenta de teste de penetração para encontrar vulnerabilidades em aplicativos da web. Ele foi projetado para ser usado por pessoas com uma ampla gama de experiência em segurança e, como tal, é ideal para desenvolvedores e testadores funcionais que são novos em testes de penetração. É comumente usado para Windows, Linux, Mac OS.

Paros

Todos os dados HTTP e HTTPS entre o servidor e o cliente, incluindo cookies e campos de formulário, podem ser interceptados e modificados usando esses scanners. É usado para plataforma cruzada, Java JRE / JDK 1.4.2 ou superior.

Kit de ferramentas para engenheiro social

É uma ferramenta de código aberto e os elementos humanos são atacados em vez do elemento do sistema. Ele permite que você envie e-mails, miniaplicativos java etc. contendo o código de ataque. É preferível para Linux, Apple Mac OS X e Microsoft Windows.

Skipfish

Esta ferramenta é usada para verificar vulnerabilidades em seus sites. Os relatórios gerados pela ferramenta servem como base para avaliações de segurança de aplicativos da web profissionais. É preferível para Linux, FreeBSD, MacOS X e Windows.

Vega

É uma ferramenta de segurança da web multiplataforma de código aberto que é usada para localizar instâncias de injeção de SQL, script entre sites (XSS) e outras vulnerabilidades em aplicativos da web. É preferível para Java, Linux e Windows.

Wapiti

Wapiti é uma ferramenta de código aberto e baseada na web que varre as páginas da web do aplicativo da web e verifica se há scripts e formulários onde pode injetar dados. É construído com Python e pode detectar erros de manuseio de arquivos, injeções de banco de dados, XSS, LDAP e CRLF, detecção de execução de comandos.

Web Scarab

Ele é escrito em Java e é usado para analisar os aplicativos que se comunicam por meio de protocolos HTTP / HTTPS. Esta ferramenta foi projetada principalmente para desenvolvedores que podem escrever códigos sozinhos. Esta ferramenta não depende do sistema operacional.

Para realizar o teste de banco de dados com sucesso, um testador deve coletar os requisitos de todas as fontes, como requisitos técnicos e funcionais. Existe a possibilidade de que alguns requisitos estejam em um nível alto, então é necessário dividir esses requisitos em pequenas partes. Testar o banco de dados é uma tarefa complexa e os testadores enfrentam muitos desafios ao realizar esse teste. Os desafios de teste de banco de dados mais comuns são -

O escopo do teste é muito grande

Um testador precisa identificar os itens de teste no teste de banco de dados, caso contrário ele pode não ter um entendimento claro do que ele testaria e o que não testaria. Portanto, se você for claro quanto ao requisito, pode perder muito tempo testando objetos acríticos no banco de dados.

Quando você tem uma lista de objetos para testar, o próximo passo é estimar o esforço necessário para projetar os testes e executar os testes para cada item de teste. Dependendo do design e do tamanho dos dados, alguns testes de banco de dados podem levar muito tempo para serem executados.

Como o tamanho do banco de dados é muito grande, torna-se um grande desafio descobrir os objetos que devem ser testados e aqueles que devem ser deixados de fora.

Banco de dados de teste reduzido

Normalmente, os testadores recebem uma cópia do banco de dados de desenvolvimento para teste. Esse banco de dados possui poucos dados, o que é suficiente para executar o aplicativo. Portanto, é necessário testar o sistema de desenvolvimento, preparação e produção do banco de dados.

Mudanças na estrutura do banco de dados

Este é um dos desafios comuns em testes de banco de dados. Às vezes, acontece que você projeta ou executa um teste e a estrutura do banco de dados foi alterada naquele momento. Isso é necessário para que você esteja ciente das alterações feitas no banco de dados durante o teste.

Uma vez que a estrutura do banco de dados muda, você deve analisar o impacto das mudanças e modificar os testes. Além disso, se vários usuários usarem o banco de dados de teste, você não terá certeza sobre os resultados do teste, portanto, certifique-se de que o banco de dados de teste seja usado apenas para fins de teste.

Outro desafio no teste de banco de dados é executar vários testes ao mesmo tempo. Você deve executar um teste de cada vez, pelo menos para os testes de desempenho. Você não quer que seu banco de dados execute várias tarefas e subestime o desempenho.

Planos de teste complexos

A estrutura do banco de dados é normalmente complexa e possui muitos dados, portanto, existe a possibilidade de que você esteja executando os mesmos testes ou incompletos repetidamente. Portanto, é necessário criar um plano de teste e proceder de acordo e verificar o andamento regularmente.

Boa compreensão de SQL

Para testar um banco de dados, você deve ter um bom conhecimento de consultas SQL e das ferramentas de gerenciamento de banco de dados necessárias.

db_connect(query1 DRIVER {drivername};SERVER server_name;UID uidname;
   PWD password;DBQ database_name );

db_excecute_query (write the required query that is to execute); Specify the appropriate condition

db_disconnect(query);