Engenharia de Software

(1)

Engenharia de Software

Testes de Software

Hélia Guerra

[email protected] Departamento de Matemática

(2)

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}

(3)

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)

(4)

Tipos de faltas

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

(5)

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}

(6)

organização dos testes

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

(7)

(8)

Atitude perante os testes

Egoless programming:

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

(9)

Quem executa os testes?

Equipa de testes independente evita conflitos

melhora a objectividade

(10)

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

(11)

(12)

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

(13)

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

(14)

escolha dos casos de teste

• _{Determinar os objectivos do teste}

• Seleccionar os casos de teste • _{Definir um teste}

(15)

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

(16)

Testes de integração

• Bottom-up • _Top-down • _Big-bang • _...

(17)

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

(18)

Testes de integração

Exemplo de um sistema

(19)

Testes de integração

Integração bottom-Up

(20)

Testes de integração

Integração Top-Down

(21)

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

(22)

comparação de estratégias de

integração

Bottom-up

Top-down

Modified

top-down Big-bang Sandwich

Modified sandwich

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

(23)

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

(24)

(25)

Testes de funcionalidade

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

(26)

testes de desempenho

Examinam

os cálculos

a velocidade de resposta a precisão do resultado a acessibilidade aos dados

(27)

Tipos de testes de desempenho

• Carga

• Volume

• Configuração

• Compatibilidade

• Operacionais

• Segurança

• Timing

• Ambientais

• Qualidade

• Recuperação

• Manutenção

• Documentação

• Usabilidade

(28)

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

(29)

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

(30)

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

(31)

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}

(32)

(33)

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

(34)

(35)

(36)

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

10. Ground cover X

(37)

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”

(38)

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

(39)

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?}

(40)

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