database testing complete guide why
Um guia completo para testes de banco de dados com dicas práticas e exemplos:
Os aplicativos de computador são mais complexos hoje em dia com tecnologias como Android e também com muitos aplicativos para smartphones. Quanto mais complexas as extremidades frontais, mais intrincadas as extremidades posteriores se tornam.
Portanto, é ainda mais importante aprender sobre testes de banco de dados e ser capaz de validar bancos de dados de forma eficaz para garantir a segurança e a qualidade dos bancos de dados.
Neste tutorial, você aprenderá tudo sobre teste de dados - por que, como e o que testar?
O banco de dados é uma das partes inevitáveis de um aplicativo de software.
Não importa se é uma web, desktop ou móvel, cliente-servidor, ponto a ponto, empresa ou negócio individual; o banco de dados é necessário em todo o backend.
Da mesma forma, quer se trate de Saúde, Finanças, Leasing, Varejo, aplicativo de mala direta ou controle de uma nave espacial; um banco de dados está sempre em ação nos bastidores.
Conforme a complexidade do aplicativo aumenta, surge a necessidade de um banco de dados mais forte e seguro. Da mesma forma, para os aplicativos com alta frequência de transações ( Por exemplo, Aplicação bancária ou financeira), a necessidade de uma ferramenta de banco de dados com todos os recursos está associada.
Hoje em dia, temos big data que são grandes e complexos que os bancos de dados tradicionais não conseguem lidar.
Existem vários Ferramentas de banco de dados estão disponíveis no mercado Por exemplo, MS-Access, MS SQL Server, SQL Server, Oracle, Oracle Financial, MySQL, PostgreSQL, DB2, Toad, Admirer, etc. Essas ferramentas variam em custo, robustez, recursos e segurança. Cada um desses tem suas próprias vantagens e desvantagens.
O que você aprenderá:
- Por que testar o banco de dados?
- O que testar (lista de verificação de teste de banco de dados)
- Como testar o banco de dados (processo passo a passo)
Por que testar o banco de dados?
Abaixo, veremos por que os seguintes aspectos de um banco de dados devem ser validados:
# 1) Mapeamento de dados
Em sistemas de software, os dados geralmente viajam para frente e para trás da IU (interface do usuário) para o banco de dados de backend e vice-versa. Portanto, estes são alguns aspectos a serem observados:
- Verifique se os campos nos formulários de interface de usuário / front-end são mapeados de forma consistente com os campos correspondentes na tabela de banco de dados. Normalmente, essas informações de mapeamento são definidas nos documentos de requisitos.
- Sempre que uma determinada ação é executada no front end de um aplicativo, uma ação CRUD (Criar, Recuperar, Atualizar e Excluir) correspondente é chamada 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.
# 2) Validação de propriedades ACID
Atomicidade, consistência, isolamento e durabilidade. Cada transação que um banco de dados realiza deve aderir a essas quatro propriedades.
- Atomicidade significa que uma transação falha ou é aprovada. Isso significa que mesmo se uma única parte da transação falhar, significa que toda a transação falhou. Normalmente, isso é chamado de regra “tudo ou nada”.
- Consistência : Uma transação sempre resultará em um estado válido do banco de dados
- Isolamento : Se houver várias transações e elas forem executadas todas de uma vez, o resultado / estado do BD deve ser o mesmo como se fossem executadas uma após a outra.
- Durabilidade : Uma vez que uma transação é feita e confirmada, nenhum fator externo como perda de energia ou falha deve ser capaz de alterá-la
Leitura sugerida = >> Tutorial de transação do MySQL
# 3) Integridade de dados
Para qualquer um dos Operações CRUD , os valores / status atualizados e mais recentes dos dados compartilhados devem aparecer em todos os formulários e telas. O valor não deve ser atualizado em uma tela e exibir um valor mais antigo em outra.
Quando o aplicativo está em execução, o o usuário final utiliza principalmente as operações ‘CRUD’ facilitadas pela ferramenta DB .
C: Criar - Quando o usuário ‘Salvar’ qualquer nova transação, a operação ‘Criar’ é realizada.
R: Recuperar - Quando o usuário ‘Pesquisar’ ou ‘Visualizar’ qualquer transação salva, a operação ‘Recuperar’ é realizada.
U: Atualizar - Quando o usuário ‘Editar’ ou ‘Modificar’ um registro existente, a operação ‘Atualizar’ do BD é realizada.
D: Excluir - Quando um usuário ‘Remove’ qualquer registro do sistema, a operação ‘Delete’ do DB é realizada.
Qualquer operação de banco de dados executada pelo usuário final é sempre uma das quatro anteriores.
Portanto, planeje seus casos de teste de banco de dados de forma a incluir a verificação dos dados em todos os lugares que aparecem para ver se são consistentemente os mesmos.
# 4) Conformidade de regras de negócios
Mais complexidade em bancos de dados significa componentes mais complicados, como restrições relacionais, gatilhos, procedimentos armazenados, etc. Portanto, os testadores terão que criar consultas SQL apropriadas para validar esses objetos complexos.
O que testar (lista de verificação de teste de banco de dados)
# 1) Transações
Ao testar transações, é importante certificar-se de que elas satisfaçam as propriedades ACID.
Estas são as declarações comumente usadas:
- BEGIN TRANSACTION TRANSACTION #
- END TRANSACTION TRANSACTION #
A instrução Rollback garante que o banco de dados permaneça em um estado consistente.
- ROLLBACK TRANSACTION #
Depois que essas instruções forem executadas, use um Select para certificar-se de que as alterações foram refletidas.
- SELECT * FROM TABLENAME
# 2) Esquemas de banco de dados
Um esquema de banco de dados nada mais é do que uma definição formal de como os dados serão organizados dentro de um banco de dados. Para testar:
- Identifique os Requisitos com base nos quais o Banco de Dados opera. Requisitos de amostra:
- Chaves primárias a serem criadas antes de quaisquer outros campos serem criados.
- As chaves estrangeiras devem ser completamente indexadas para fácil recuperação e pesquisa.
- Nomes de campos que começam ou terminam com determinados caracteres.
- Campos com uma restrição de que determinados valores podem ou não ser inseridos.
- Use um dos seguintes métodos de acordo com a relevância:
- Consulta SQL DESC
para validar o esquema.
- Expressões regulares para validar os nomes dos campos individuais e seus valores
- Ferramentas como SchemaCrawler
# 3) Gatilhos
Quando um determinado evento ocorre em uma determinada mesa, um trecho de código (um gatilho) pode ser auto-instruído para ser executado.
Por exemplo, um novo aluno ingressou em uma escola. O aluno está cursando 2 aulas: matemática e ciências. O aluno é adicionado à “tabela do aluno”. Um acionador pode adicionar o aluno às tabelas de assuntos correspondentes, uma vez que ele é adicionado à tabela de alunos.
O método comum de teste é executar primeiro a consulta SQL incorporada no Trigger e registrar o resultado. Em seguida, execute o Trigger como um todo. Compare os resultados.
Eles são testados nas fases de teste de caixa preta e caixa branca.
tipos de funções c ++
- Teste de caixa branca : Stubs e drivers são usados para inserir, atualizar ou excluir dados que resultariam na ativação do gatilho. A ideia básica é apenas testar o banco de dados sozinho antes mesmo da integração com o front end (IU) ser feita.
- Teste de caixa preta :
para) Desde a IU e o banco de dados, a integração agora está disponível; podemos inserir / excluir / atualizar dados do front end de forma que o acionador seja chamado. Depois disso, as instruções Select podem ser usadas para recuperar os dados do banco de dados para ver se o Trigger foi bem-sucedido na execução da operação pretendida.
b) A segunda maneira de testar isso é carregar diretamente os dados que invocariam o Trigger e ver se ele funciona conforme o esperado.
# 4) Procedimentos armazenados
Os procedimentos armazenados são mais ou menos semelhantes às funções definidas pelo usuário. Eles podem ser invocados por instruções Call Procedure / Execute Procedure e a saída geralmente é na forma de conjuntos de resultados.
Eles são armazenados no RDBMS e estão disponíveis para aplicativos.
Eles também são testados durante:
- Teste de caixa branca: Stubs são usados para chamar os procedimentos armazenados e, em seguida, os resultados são validados em relação aos valores esperados.
- Teste de caixa preta: Execute uma operação a partir do front end (IU) do aplicativo e verifique a execução do procedimento armazenado e seus resultados.
# 5) Restrições de campo
O valor padrão, o valor exclusivo e a chave estrangeira:
- Execute uma operação de front-end que exercita a condição do objeto Banco de Dados
- Valide os resultados com uma consulta SQL.
Verificar o valor padrão de um determinado campo é bastante simples. Faz parte da validação da regra de negócios. Você pode fazer isso manualmente ou usar ferramentas como o QTP. Manualmente, você pode executar uma ação que irá agregar valor diferente do valor padrão do campo do front end e ver se isso resulta em um erro.
A seguir está um exemplo de código VBScript:
Function VBScriptRegularexpressionvlaidation(pattern , string_to_match) Set newregexp = new RegExp newregexp.Pattern = “
” newregexp.Ignorecase = True newregexp.Global = True VBScriptRegularexpressionvlaidation = newregexp.Test(string_to_match) End Function Msgbox VBScriptRegularexpressionvlaidation(pattern , string_to_match) O resultado do código acima é Verdadeiro se o valor padrão existir ou Falso se não existir.
Verificar o valor único pode ser feito exatamente da maneira que fizemos para os valores padrão. Tente inserir valores da IU que violarão esta regra e veja se um erro é exibido.
O código do Script VB de automação pode ser:
Function VBScriptRegularexpressionvlaidation(pattern , string_to_match) Set newregexp = new RegExp newregexp.Pattern = “
” newregexp.Ignorecase = True newregexp.Global = True VBScriptRegularexpressionvlaidation = newregexp.Test(string_to_match) End Function Msgbox VBScriptRegularexpressionvlaidation(pattern , string_to_match) Para oChave Estrangeiraa validação de restrição usa carregamentos de dados que inserem diretamente os dados que violam a restrição e ver se o aplicativo os restringe ou não. Junto com o carregamento de dados de back-end, execute as operações de interface do usuário de front-end também de uma maneira que viole as restrições e veja se o erro relevante é exibido.
Atividades de teste de dados
O testador de banco de dados deve se concentrar nas seguintes atividades de teste:
# 1) Garanta o mapeamento de dados:
O mapeamento de dados é um dos principais aspectos do banco de dados e deve ser testado rigorosamente por cada testador de software.
Certifique-se de que o mapeamento entre diferentes formulários ou telas do AUT e seu banco de dados seja não apenas preciso, mas também de acordo com os documentos de projeto (SRS / BRS) ou código. Basicamente, você precisa validar o mapeamento entre cada campo de front-end com seu campo de banco de dados de back-end correspondente.
Para todas as operações CRUD, verifique se as respectivas tabelas e registros são atualizados quando o usuário clica em ‘Salvar’, ‘Atualizar’, ‘Pesquisar’ ou ‘Excluir’ da GUI do aplicativo.
O que você precisa verificar:
- Mapeamento de tabela, mapeamento de coluna e mapeamento de tipo de dados.
- Mapeamento de dados de pesquisa.
- A operação CRUD correta é chamada para cada ação do usuário na IU.
- A operação CRUD foi bem-sucedida.
# 2) Garanta as propriedades ACID das transações:
As propriedades ACID de transações de banco de dados referem-se ao ‘ PARA tomicidade ',' C onsistência ',' eu solação 'e' D urabilidade ’. O teste adequado dessas quatro propriedades deve ser feito durante a atividade de teste do banco de dados. Você precisa verificar se cada transação satisfaz as propriedades ACID do banco de dados.
Vamos dar um exemplo simples através do código SQL abaixo:
CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100));
A tabela de teste ACID terá duas colunas - A e B. Há uma restrição de integridade de que a soma dos valores em A e B deve ser sempre 100.
Teste de atomicidade irá garantir que qualquer transação realizada nesta tabela seja total ou nenhuma, ou seja, nenhum registro será atualizado se qualquer etapa da transação falhar.
Teste de consistência irá garantir que sempre que o valor na coluna A ou B for atualizado, a soma sempre permanecerá 100. Não permitirá a inserção / exclusão / atualização em A ou B se a soma total for diferente de 100.
Teste de isolamento irá garantir que se duas transações estiverem ocorrendo ao mesmo tempo e tentando modificar os dados da tabela de teste ACID, então essas transações estão sendo executadas isoladamente.
Teste de durabilidade irá garantir que uma vez que uma transação sobre esta tabela tenha sido confirmada, ela permanecerá assim, mesmo no caso de perda de energia, travamentos ou erros.
Esta área exige testes mais rigorosos, completos e apurados se seu aplicativo estiver usando o banco de dados distribuído.
# 3) Garantir a integridade dos dados
Considere que diferentes módulos (ou seja, telas ou formulários) do aplicativo usam os mesmos dados de maneiras diferentes e executam todas as operações CRUD nos dados.
Nesse caso, certifique-se de que o estado mais recente dos dados seja refletido em todos os lugares. O sistema deve mostrar os valores atualizados e mais recentes ou o status de tais dados compartilhados em todos os formulários e telas. Isso é chamado de integridade de dados.
Casos de teste para validar a integridade dos dados do banco de dados:
- Verifique se todos os Triggers estão no lugar para atualizar os registros da tabela de referência.
- Verifique se existem dados incorretos / inválidos nas colunas principais de cada tabela.
- Tente inserir dados errados nas tabelas e observe se ocorre alguma falha.
- Verifique o que acontece se você tentar inserir uma criança antes de inserir seu pai (tente brincar com as chaves primária e estrangeira).
- Teste se ocorrer alguma falha se você excluir um registro que ainda é referenciado por dados em qualquer outra tabela.
- Verifique se os servidores e bancos de dados replicados estão sincronizados.
# 4) Garantir a precisão das regras de negócios implementadas:
Hoje, os bancos de dados não se destinam apenas a armazenar os registros. Na verdade, os bancos de dados evoluíram para ferramentas extremamente poderosas que fornecem amplo suporte aos desenvolvedores para implementar a lógica de negócios no nível do banco de dados.
Alguns exemplos simples de recursos poderosos são ‘Integridade referencial’, restrições relacionais, gatilhos e procedimentos armazenados.
Portanto, usando esses e muitos outros recursos oferecidos pelos bancos de dados, os desenvolvedores implementam a lógica de negócios no nível do banco de dados. O testador deve garantir que a lógica de negócios implementada esteja correta e funcione com precisão.
Os pontos acima descrevem os quatro 'O que fazer' mais importantes do teste de banco de dados. Agora, vamos passar para a parte de ‘Como fazer’.
Como testar o banco de dados (processo passo a passo)
O banco de dados de teste do processo de teste geral não é muito diferente de qualquer outro aplicativo.
A seguir estão as etapas principais:
Passo 1) Prepare o ambiente
Passo 2) Faça um teste
Etapa 3) Verifique o resultado do teste
Passo 4) Validar de acordo com os resultados esperados
Etapa 5) Relate as descobertas às respectivas partes interessadasNormalmente, consultas SQL são usadas para desenvolver os testes. O comando mais comumente usado é “Selecionar”.
Selecione * de onde
Além de Selecionar, o SQL tem 3 tipos importantes de comandos:
- DDL: linguagem de definição de dados
- DML: linguagem de manipulação de dados
- DCL: linguagem de controle de dados
Vamos ver a sintaxe das instruções mais comumente usadas.
Linguagem de definição de dados Usa CREATE, ALTER, RENAME, DROP e TRUNCATE para lidar com tabelas (e índices).
Linguagem de manipulação de dados Inclui instruções para adicionar, atualizar e excluir registros.
Linguagem de controle de dados: Trata de dar autorização aos usuários para manipulação e acesso aos dados. Conceder e Revogar são as duas declarações usadas.
Sintaxe de concessão:
Conceder seleção / atualização
Sobre
Para ;Revogar sintaxe:
Revogar seleção / atualização
sobre
a partir de;Algumas dicas práticas
# 1) Escreva você mesmo as consultas:
Para testar o Banco de Dados com precisão, o testador deve ter muito bom conhecimento de instruções SQL e DML (Linguagem de Manipulação de Dados). O testador também deve conhecer a estrutura interna do banco de dados do AUT.
Você pode combinar GUI e verificação de dados nas respectivas tabelas para melhor cobertura. Se estiver usando o servidor SQL, você pode usar o SQL Query Analyzer para escrever consultas, executá-las e recuperar resultados.
Esta é a melhor e robusta forma de testar um banco de dados quando o aplicativo é de nível de complexidade pequeno ou médio.
Se o aplicativo for muito complexo, pode ser difícil ou impossível para o testador escrever todas as consultas SQL necessárias. Para consultas complexas, você recebe ajuda do desenvolvedor. Sempre recomendo esse método, pois ele lhe dá confiança nos testes e também aprimora suas habilidades em SQL.
# 2) Observe os dados em cada tabela:
Você pode realizar a verificação de dados usando os resultados das operações CRUD. Isso pode ser feito manualmente usando a interface do usuário do aplicativo quando você conhece a integração do banco de dados. Mas isso pode ser uma tarefa tediosa e complicada quando há muitos dados em diferentes tabelas de banco de dados.
Para o teste manual de dados, o testador de banco de dados deve possuir um bom conhecimento da estrutura da tabela de banco de dados.
# 3) Obtenha consultas dos desenvolvedores:
Esta é a maneira mais simples de testar o banco de dados. Execute qualquer operação CRUD a partir da GUI e verifique seus impactos executando as respectivas consultas SQL obtidas do desenvolvedor. Não requer um bom conhecimento de SQL nem requer um bom conhecimento da estrutura do banco de dados do aplicativo.
Mas esse método precisa ser usado com cautela. E se a consulta fornecida pelo desenvolvedor estiver semanticamente errada ou não atender aos requisitos do usuário corretamente? O processo simplesmente falhará ao validar os dados.
# 4) Faça uso de ferramentas de teste de automação de banco de dados:
Existem várias ferramentas disponíveis para o processo de Teste de Dados. Você deve escolher a ferramenta correta de acordo com suas necessidades e fazer o melhor uso dela.
=> Aqui está a lista das ferramentas de teste TOP DB que você deve verificar
Conclusão
Com todos esses recursos, fatores e processos para testar em um banco de dados, há uma demanda crescente para que os testadores sejam tecnicamente proficientes nos principais conceitos de banco de dados. Apesar de algumas crenças negativas de que testar um banco de dados cria novos gargalos e envolve muitos gastos adicionais - esse é um reino de teste que está atraindo atenção e demanda significativas.
Leitura sugerida = >> O que é teste de segurança de banco de dados
Espero que este tutorial tenha ajudado a enfocar o porquê disso e também tenha fornecido a você os detalhes básicos do que é necessário para testar um banco de dados.
Deixe-nos saber seus comentários e também compartilhar suas experiências pessoais se você estiver trabalhando em testes de banco de dados.
Leitura recomendada
- Teste de banco de dados com JMeter
- Mais de 40 melhores ferramentas de teste de banco de dados - Soluções populares de teste de dados
- Uma abordagem simples para XML para teste de banco de dados
- Teste ETL Tutorial de teste de data warehouse (um guia completo)
- Tutorial de teste de migração de dados: um guia completo
- Dez principais ferramentas de design de banco de dados para construir modelos de dados complexos
- Tutorial de teste de data warehouse com exemplos | Guia de teste ETL
- Como testar o banco de dados Oracle
^
- Consulta SQL DESC