Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho...

Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho

Engenharia de Software

Testes de Software


Motivação

• Existe grande possibilidade de injeção de falhas humanas no processo de desenvolvimento de software

• Os custos associados às falhas de software justificam um processo de testes cuidadoso e bem planejado


Motivação

• U$59.500.000.000,00 foi o custo das falhas em software nos EUA, apenas em 2002.

• U$22.200.000.000,00 em economia, caso a infra-estrutura para testes fosse melhor


Motivação

• Mars Climate Orbiter• Objetivo

– Enviar sinais a partir de Marte, após seu pouso no planeta

• Desastre– Chocou-se com o planeta

• Motivo– Bug no software responsável pela conversão de medidas

• Prejuízo– 165 milhões de dólares


Motivação

• Airbus Airbus 320• Desastre

– USS Vicennes derrubou um Airbus 320 em 1988

• Motivo– Bug no software no software de reconhecimento

confundindo o avião com um F14

• Prejuízo– 290 mortes


Motivação

• Máquina de Terapia Radiotiva• Desastre

– Overdose em pacientes sob tratamento

• Motivo– Inabilidade em gerenciar certas condições de disputa

• Prejuízo– Morte de 2 pessoas– 6 outras lesionadas


Motivação

• London Ambulance Service• Desastre

– Serviço auxiliado por computador falhou nos dias 26 e 27 de novembro de 1992, gerando várias falhas, como o envio de 2 ambulâncias para o mesmo destino, envio de uma ambulância para um local estando outras mais próximas, etc

• Motivo– Tudo indica que o problema estava relacionado a alta carga

de emergências durante o período.



Motivação

• Airbus A300 China Air Lines• Desastre

– Avião caiu em 1994

• Motivo– Foi feita uma investigação e, dentre as recomendações,

aconselharam mudanças nos softwares de controle



Motivação

• Se a indústria automobilística tivesse se desenvolvido como a indústria do software, nós teríamos carros por U$25, fazendo 5000 milhas com um galão de combustível.

• Porém, esse carro iria “quebrar” duas vezes por dia, sem um motivo aparente, e quando você solicitasse assistência junto às concessionárias eles iriam dizer para você reinstalar o motor.


Finalidade dos Testes

• Verificar se todos os requisitos do sistema foram corretamente implementados

• Assegurar, na medida do possível, a qualidade e a corretude do software produzido

• Reduzir custos de manutenção corretiva e retrabalho

• Assegurar a satisfação do cliente com o produto desenvolvido


Finalidade dos Testes

• Produzir casos de teste que têm elevada probabilidade de revelar um erro ainda não descoberto com uma quantidade mínima de tempo e esforço

• Comparar o resultado dos testes com os resultados esperados a fim de produzir uma indicação da qualidade e da confiabilidade do software

• Verificar a correta integração entre todos os componentes de software


Defeitos, Erros e Falhas

• Defeito: deficiência mecânica ou algorítmica que, se ativada, pode levar a uma falha

• Erro: item de informação ou estado de execução inconsistente

• Falha: evento notável em que o sistema viola suas especificações


Defeitos no Software

• A maior parte é de origem humana

• São gerados na comunicação e na transformação de informações

• Continuam presentes nos diversos produtos de software produzidos e liberados

• A maioria encontra-se em partes do código raramente executadas


Defeitos no Software

• Quanto antes a presença do defeito for revelada, menor o custo de correção do defeito e maior a probabilidade de corrigi-lo corretamente

• Principal causa: tradução incorreta de informações

• Solução: introduzir atividades de VV&T ao longo de todo o ciclo de desenvolvimento


Definição de Teste de Software

Processo de executar um programa com o objetivo de revelar a presença de defeitos; ou, falhando nesse objetivo, aumentar a

confiança sobre o programa.


Teste de Software

• Objetivo: revelar a presença de erros• Inexistência de erro:

– Software é de alta qualidade?– Conjunto de casos de teste T é de baixa qualidade?

• Defeitos e erros não revelados– Falhas se manifestam durante a utilização pelos

usuários– Erros devem ser corrigidos durante a manutenção– Alto custo


Testes de Software

• Caso de teste– Especificação de uma entrada para o programa e a

correspondente saída esperada– Entrada: conjunto de dados necessários para uma– execução do programa– Saída esperada: resultado de uma execução do

programa (oráculo)– Um bom caso de teste tem alta probabilidade de

revelar um erro ainda não descoberto


Processo de Teste

• Objetivo– Criar testes para revelar a presença de erros.

• Define– Como os testes serão planejados e executados através de

atividades e passos, e quando serão executados.

• O teste pode ser visto como “destrutivo” ao invés do desenvolvimento que é “construtivo”

• O “engenheiro de testes” tenta elaborar casos de teste que têm a intenção de “demolir” o software (descobrir erros)


Processo de Teste

• Quando bem planejado e controlado– Exige menor esforço e tem maior eficácia.

• Objetos testados– Módulos de código– Estrutura de dados– ...

• É impossível provar a ausência total de erros


Processo de Teste - Atividades

• planejamento dos testes– requisitos a serem testados e priorização– estratégias de testes– cronograma, esforço e recursos exigidos

• projeto dos testes– casos e procedimentos de testes

• implementação dos testes– scripts e componentes de teste


Processo de Testes - Atividades

• execução dos testes– manual e/ou automática

• avaliação dos testes– cobertura– tendência dos defeitos– critérios de sucesso


Processo de Testes

Design testcases

Prepare testdata

Run programwith test data

Compare resultsto test cases

Testcases

Testdata

Testresults

Testreports


Processo de Testes• Quando se acaba de testar? Quando parar? Quando podemos

considerar o sistema como testado?

• Nunca termina

• Critérios de parada

– Funcionalidade

– Expectativa do usuário

– Mercado

• Quando o tempo ou o dinheiro acaba

• Técnicas estatísticas

• Comparação com experiências anteriores


Abordagens de Teste

• Abordagem funcional (“caixa preta”)– Os testes são gerados a partir de uma análise dos

relacionamentos entre os dados de entrada e saída, com base nos requisitos levantados com os usuários.

– É muito aplicado durante as últimas etapas do processo de teste.

– Objetivo• Erros de interface• Erros nas estruturas de dados ou acesso ao banco• Erros de desempenho


Abordagens de Teste

• Abordagem estrutural (“caixa branca”)– Os testes são gerados a partir de uma análise dos

caminhos lógicos possíveis de serem executados, de modo a conhecer o funcionamento interno dos componentes do software.

– Objetivo• Garantir que todos os caminhos independentes dentro de

um módulo tenham sido exercitados pelo menos uma vez• Realizar todas as decisões lógicas para valores falsos e

verdadeiros• Executar laços dentro dos valores limites• Executar as estruturas de dados internas


Estágios de Teste

• Teste de unidade– Componentes individuais (ex: classes, métodos) são testados

para assegurar que os mesmos operam de forma correta

• Teste de integração– A interface entre as unidades integradas é testada

• Teste de sistema– Os elementos de software integrados com o ambiente

operacional (hardware, pessoas, etc.) são testados como um todo

• Teste de aceitação (homologação)– O software é testado pelo usuário final– Envolve treinamento, documentação e empacotamento


Teste de Unidade

• Testar cada método de cada uma das classes

• Teste realizado, em geral, pelo próprio programador

• Pode ser automatizado (ex: JUnit)


Conceitos

• Driver – programa principal, que aceita dados do caso de teste, passa estes dados para o módulo a ser testado e visualiza os dados relevantes.

• Stubs – módulos que substituem outros módulos subordinados. Utiliza a interface do módulo subordinado, manipula os dados e retorna um resultado esperado.


Teste de Integração

• A integração dos módulos pode ser feitas através das abordagens top-down e bottom-up:

• Top-down – Os módulos são integrados de cima para baixo. O teste usa driver e stubs. O driver é utilizado como módulo de controle principal, e os módulos reais são substituídos por stubs.


Teste de Integração

• Bottom-up – a integração é feita a partir do nível mais básico da hierarquia. Os stubs nem sempre são necessários.– Os módulos do nível inferior são combinados. – Para cada combinação é criado um driver que

coordena a entrada e a saída dos casos de teste.– O módulo é testado.– O driver é substituído pela combinação de módulos

correspondente, que passam a interagir com os módulos do nível superior.


Teste de Sistema

• Verifica se a aplicação está funcionando como um todo

• A integração dos componentes de software com o ambiente operacional similar ao de produção (hardware, software, pessoas e outros sistemas) é testada

• Geralmente é um teste “caixa-preta”, executado por um testador de sistemas (idealmente membro de um grupo independente de testes)


Teste de Aceitação

• Testes de “caixa preta”, realizados pelo usuário a fim de demonstrar a conformidade com os requisitos do software

• Envolve treinamento, documentação e empacotamento• Podem ser de duas categorias:

– Testes alfa: feitos pelo usuário, geralmente nas instalações do desenvolvedor, que observa e registra erros e/ou problemas

– Testes beta: feitos pelo usuário, geralmente em suas próprias instalações, sem a supervisão do desenvolvedor. Os problemas detectados são então relatados para o desenvolvedor


Tipos de Teste

• Teste funcional (regras de negócio)– A funcionalidade geral do sistema em termos de

regras de negócio (fluxo de trabalho) é testada– Condições válidas e inválidas

• Teste de recuperação de falhas– O software é forçado a falhar de diversas maneiras

para que seja verificado o seu comportamento, bem como a adequação dos procedimentos de recuperação. A recuperação pode ser automática ou exigir intervenção humana


Tipos de Teste

• Teste de segurança e controle de acesso– Verifica se todos os mecanismos de proteção

de acesso estão funcionando satisfatoriamente

• Teste de integridade de dados– Verifica a corretude dos métodos de acesso à

base de dados e a garantia das informações armazenadas


Tipos de Teste

• Teste de performance– Tempo de resposta e processamento (para diferentes

configurações, número de usuários, tamanho do BD, etc.)

– Exemplo• Recuperar uma conta do usuário em x segundos• Processar a transação y em x segundos

– São necessários definir• Os servidores e clientes• Sistemas operacionais, servidores de aplicação• Protocolos utilizados


Tipos de Teste

• Teste de volume (carga)– Foca em transações do BD– Verifica se o sistema suporta altos volumes

de dados uma única transação– Verifica o número de terminais, modems e

bytes de memória que é possível gerenciar


Tipos de Teste

• Teste de estresse– Verifica a funcionalidade do sistema em situações

limite– Pouca memória ou área em disco, alta competição

por recursos compartilhados (ex: vários acessos/transações no BD ou rede)

– Exemplo: pode-se desejar saber se um sistema de transações bancárias suporta uma carga de 100 transações por segundo ou se um sistema operacional pode manipular 200 terminais remotos


Tipos de Teste

• Teste de configuração ou portabilidade– Verifica o funcionamento adequado do

sistema em diferentes configurações de hardware/software

– O que testar• Compatibilidade do software/hardware• Configuração do servidor• Tipos de conexões com a Internet• Compatibilidade com o browser


Tipos de Teste

• Teste de instalação e desinstalação– Verifica a correta instalação e desinstalação

do sistema para diferentes plataformas de hardware/software e opções de instalação

– O que testar• Compatibilidade do hardware e software• A funcionalidade do instalador/desinstalador sob

múltiplas opções e condições de instalação• A interface do programa instalador/desinstalador


Tipos de Teste

• Teste de interfaces com o usuário– Aparência e comportamento da interface– Navegação– Consistência– Aderência a padrões– Tempo para aprender como usar o programa– Funcionalidade– Algo que a aplicação é esperada fazer, mas é difícil

de ser realizado, complicado ou impossível


Tipos de Teste

• Teste de documentação– Verifica se a documentação corresponde à

informação correta e apropriada:• online• escrita• help sensível ao contexto

• Teste de ciclo de negócios– Garante que o sistema funciona adequadamente

durante um ciclo de atividades relativas ao negócio


Tipos de Teste

• Testes de Regressão– Re-execução de testes feitos após uma

manutenção corretiva ou evolutiva.– Em processos de desenvolvimento iterativos,

muitos dos artefatos produzidos nas primeiras iterações, como casos e procedimentos de teste, são usados em iterações posteriores nos testes de regressão.

Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho...

Documents

Transcript of Faculdade 7 de Setembro – Sistemas de Informação Engenharia de Software – Prof. Ciro Coelho...