Jpf@fe.up.pt www.fe.up.pt/~jpf TQS - Teste e Qualidade de Software (Software Testing and Quality) Teste Envolvendo Acesso a Bases de Dados João Pascoal.

Apresentação em tema: "Jpf@fe.up.pt www.fe.up.pt/~jpf TQS - Teste e Qualidade de Software (Software Testing and Quality) Teste Envolvendo Acesso a Bases de Dados João Pascoal."— Transcrição da apresentação:

1 jpf@fe.up.pt www.fe.up.pt/~jpf
TQS - Teste e Qualidade de Software (Software Testing and Quality) Teste Envolvendo Acesso a Bases de Dados João Pascoal Faria

2 Automação com testes data-driven
Parâmetros de retorno esperados (repres. XML) Diff Erros Parâmetros de retorno actuais (repres. XML) Parâmetros de chamada (repres. XML) Deserialize Serialize Parâmetros de retorno actuais (repres. em memória) Parâmetros de chamada (repres. em memória) Caso de Teste (em XML) Serviço de lógica de negócio ou acesso a dados a testar Base de dados no estado inicial Base de dados no estado final actual Base de dados no estado inicial (repres. XML) Load Dump Base de dados no estado final actual (repres. XML) Diff Erros Base de dados no estado final esperado (repres. XML) (1) Load e dump podem ser restringidos a determinadas tabelas e podem ser diferenciais (inserts, updates e deletes) (2) Em MS.Net é fácil efectuar as conversões todas de/para XML! (3) Uma forma prática de gerar os casos de teste, nomeadamente os resultados esperados, é analisar os resultados esperados e, se estiverem correctos, fazer "save as test case" (ou "save as error case" no caso concreto) (4) Outra forma de verificar os resultados (em vez de dump e diff) é chamar serviços de consulta da base de dados

3 Teste de propriedades ACID de serviços transaccionais
Atomicidade – em caso de falha a meio, ou faz tudo ou não faz nada Planear casos de teste em que a transacção falha em algum passo e verificar se base de dados fica inalterada e os parâmetros de retorno são consistentes (não dizem por exemplo que teve sucesso, quando na realidade não teve) Consistência – supondo que estado inicial da base de dados obedece às restrições de integridade, o estado final também deve obedecer No caso das restrições de integridade não estarem declaradas na base de dados (tipicamente para não penalizar desempenho), correr procedimentos de verificação de consistência a seguir à execução de um serviço transaccional Isolamento – no caso de execução concorrente, o resultado final deve ser equivalente a uma execução em série (no caso de ser escolhido o nível de isolamento máximo) Executar um conjunto de transacções concorrentemente e verificar se o resultado final é um dos admissíveis (exemplo: ambas incrementam um contador) Combinar com atomicidade Durabilidade – depois da transacção fazer "commit", as alterações devem ser duradoiras (devem sobreviver a falhas posteriores) Confiamos no SGBD e nos mecanismos de logging e recuperação Concentrar a atenção nos pontos críticos!