Engenharia de Software

Engenharia de Software

Testes de Software

Hélia Guerra

helia@uac.pt Departamento de Matemática

Universidade dos Açores

Causas de faltas e falhas

de software

• Requisitos errados: não é o que o cliente pretende • Requisitos em falta

• Requisitos impossível de implementar • Desenho com faltas

testes

Objectivo dos testes: encontrar faltas

Um teste diz-se bem sucedido se encontrar alguma falta

Identificação de faltas é o processo de determinação das possíveis faltas que causaram a falha

Correcção de faltas é o processo de modificação do sistema para remover as faltas (depuração)

3

Tipos de faltas

Algorítmicas Computação e precisão Documentação Overloading Capacidade ou limite Timing ou coordenação Desempenho

Faltas algoritmicas

• Ocorrem quando o algoritmo de um componente não produz o output adequado

–Poucas/demasiadas alternativas –testa a condição errada

–Não inicializa variáveis ou define os invariantes do ciclo

–Não testa condição particular

–Compara variáveis de tipos incompatíveis • Faltas sintácticas ₅

organização dos testes

Testes de unidade Testes de integração Testes de funcionalidade Testes de desempenho Testes de aceitação Testes de instalação

organização dos testes

7

Atitude perante os testes

Egoless programming:

programas são componentes de um grande sistema programas não são propriedade de quem os escreve

Quem executa os testes?

Equipa de testes independente evita conflitos

melhora a objectividade

permite testar e escrever código ao mesmo tempo

9

Estratégias de teste

Caixa fechada (closed box ou black box): testes feitos à funcionalidade dos objectos, ignorando a sua estrutura interna

Caixa aberta (clear box ou white box): testes feitos tendo em conta a estrutura interna dos objectos

Nem sempre é possível testar todas as possibilidades

caixa aberta

11

factores que influenciam a escolha

da estratégia de testes

Número de possibilidades Natureza dos dados

Quantidade de computação envolvida Complexidade dos algoritmos

Testes de unidade

Revisão do código

walkthrough Inspecção

Prova da correcção do código Métodos formais

Execução simbólica

ferramentas automáticas

13

escolha dos casos de teste

• Determinar os objectivos do teste

• Seleccionar os casos de teste • Definir um teste

profundidade dos testes

Instrução (statement): toda a instrução é executada pelo menos uma vez

Alternativa (branch): para cada ponto de decisão, toda a alternativa é executada pelo menos uma vez

Caminho (path): todos os possíveis caminhos distintos de instruções são executados pelo menos uma vez

... 15

Testes de integração

• Bottom-up • Top-down • Big-bang • ...

Testes de integração

Terminologia

• Component Driver: rotina que chama determinado componente e passa-lhe um caso de teste

• Stub: programa especial para simular a actividade de um componente que ainda não foi testado

17

Testes de integração

Exemplo de um sistema

Testes de integração

Integração bottom-Up

Sequência de testes e respectivas dependências

19

Testes de integração

Integração Top-Down

Testes de integração

Integração Big-Bang Componentes testados isoladamente e depois integrados de uma só vez Necessita de stubs e de drivers para testar os componentes

21

comparação de estratégias de

integração

Bottom-up _downTop- Modified top-_down Big-bang Sandwich _sandwichModified

Integration Early Early Early Late Early Early

Time to basic working

program Late Early Early Late Early Early

Component drivers

needed Yes No Yes Yes Yes Yes

Stubs needed No Yes Yes Yes Yes Yes

Work parallelism at

beginning Medium Low Medium High Medium High

Ability to test particular

paths Easy Hard Easy Easy Medium Easy

Ability to plan and

Testes ao sistema

Testes de funcionalidade: verificam se o sistema faz o que foi especificado nos requisitos funcionais

Testes de desempenho: verificam os requisitos não funcionais

Testes de aceitação: verificam se o sistema funciona de acordo com as espectativas do cliente

Testes de instalação: verificam se o sistema funciona correctamente no seu ambiente de instalação

23

Testes de funcionalidade

Comparam a execução do sistema com os requisitos Casos de teste são desenvolvidos baseados no

documento dos requisitos

25

testes de desempenho

Examinam os cálculos a velocidade de resposta a precisão do resultado a acessibilidade aos dados

Tipos de testes de desempenho

• Carga • Volume • Configuração • Compatibilidade • Operacionais • Segurança • Timing • Ambientais • Qualidade • Recuperação • Manutenção • Documentação • Usabilidade 27

testes de aceitação

• Servem para os clientes e utilizadores verificarem se o sistema satisfaz os objectivos e as expectativas

• Concebidos, geridos e realizados pelos clientes/ utilizadores

tipos de testes de aceitação

• Benchmark: cliente prepara conjunto de casos de teste

que representam situações típicas de utilização

• Piloto: sistema instalado numa base experimental para ser utilizado diariamente (sem casos de teste)

•Alfa: realizado no local onde foi desenvolvido •Beta: realizado no local do cliente

• Paralelo : novo sistema é executado em paralelo com o antigo

29

testes de instalação

Podem não ser necessários, caso os testes de aceitação tenham sido realizados no local de funcionamento do sistema

Antes de testar

Configurar o sistema

Ligar todos os dispositivos

Estabelecer as comunicações com os outros sistemas Testar operacionalidade: verificar se o sistema foi bem

Planeamento de testes

• Estabelecer os objectivos do teste

• Desenhar os casos de teste • Escrever os casos de teste • Testar os casos de teste • Executar os testes

• Avaliar os resultados dos testes

31

documentação de testes

Plano: descrição do sistema e plano para exercitar todas as funções e características

Especificação e avaliação: detalhes de cada testes e critérios de avaliação

Descrição: dados de teste e procedimentos para cada teste

Relatório: resultados de cada teste

33

Plano de testes

35

Exemplo

Test Requirement 2.4.1: Generate and Maintain Database Requirement 2.4.2: Selectively Retrieve Data Requirement 2.4.3: Produced Specialized Reports 1. Add new record X

2. Add field X

3. Change field X 4. Delete record X 5. Delete field X

6. Create index X

Retrieve record with a requested

7. Cell number X

8. Water height X

9. Canopy height X

Exemplo descrição de teste

INPUT DATA:

Input data are to be provided by the LIST program. The program generates randomly a list of N words of alphanumeric characters; each word is of length M. The program is invoked by calling

! RUN LIST(N,M)

in your test driver. The output is placed in global data area LISTBUF. The test datasets to be used for this test are as follows:

Case 1: Use LIST with N=5, M=5 Case 2: Use LIST with N=10, M=5 Case 3: Use LIST with N=15, M=5 Case 4: Use LIST with N=50, M=10 Case 5: Use LIST with N=100, M=10 Case 6: Use LIST with N=150, M=10 INPUT COMMANDS:

The SORT routine is invoked by using the command ! RUN SORT (INBUF,OUTBUF) or

! RUN SORT (INBUF) OUTPUT DATA:

If two parameters are used, the sorted list is placed in OUTBUF. Otherwise, it is placed in INBUF. SYSTEM MESSAGES:

During the sorting process, the following message is displayed: ! “Sorting ... please wait ...”

Upon completion, SORT displays the following message on the screen: ! “Sorting completed”

To halt or terminate the test before the completion message is displayed, press CONTROL-C on the keyboard. 37

Relatório de testes

Documentam o resultado dos testes

Fornece informação necessária para duplicar a falha e localizar e corrigir as respectivas causas

Fornece informação para se inferir se o projecto está completo

COmo relatar uma falha

• Localização: onde ocorreu?

• Timing: quando ocorreu?

• Sintoma: o que foi observado?

• Resultado: quais foram as consequências? • Mecanismo: como ocorreu?

• Causa: porque ocorreu?

• Gravidade: qual a intensidade dos danos? • Custo: quanto custou?

39

Resumo

Faltas versus falhas

O objectivo dos testes é encontrar faltas e não provar a correcção

Os testes devem iniciar-se o mais cedo possível Os testes baseiam-se no documento dos requisitos