Engenharia de Software com o RUP - Workflow de Testes Parte I Alexandre Vasconcelos, André Santos,...

Preview:

Citation preview

Engenharia de Software Engenharia de Software com o RUP - com o RUP -

Workflow de Workflow de TestesTestesParte IParte I

Alexandre Vasconcelos, André Santos, Augusto Sampaio, Hermano Moura,

Paulo Borba

© Centro de Informática

Universidade Federal de Pernambuco

ObjetivosObjetivos::

Entender os conceitos básicos do workflow de Testes Entender como ler e interpretar os artefatos gerados

por este workflow

Tópicos CobertosTópicos Cobertos

Motivação Introdução Objetivo dos Testes Abordagens de Testes Estratégia de Testes Estágios de Teste Ferramentas de Teste Responsabilidades sobre a Execução dos Testes Teste x Depuração Abordagens para a Depuração

MotivaçãoMotivação Existe grande possibilidade de injeção de

falhas humanas no processo de desenvolvimento de software;

A atividade de teste faz parte da garantia de qualidade de software (SQA);

Os custos associados às falhas de software justificam uma atividade de teste cuidadosa e bem planejada.

IntroduçãoIntrodução A atividade de testes pode ser vista como

“destrutiva” ao invés do desenvolvimento que é “construtivo”;

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

É impossível mostrar a ausência de erros.

Objetivo dos TestesObjetivo 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.

O objetivo pode ser alcançado de forma automática e/ou manual

Abordagens de TesteAbordagens de Teste Existem basicamente duas abordagens que podem ser

aplicadas a diferentes tipos de teste: Abordagem funcional (“caixa preta”) - os casos de teste 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;

Abordagem estrutural (“caixa branca”) - os casos de teste 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. No entanto, é impossível gerar casos de teste para todos os caminhos lógicos.

Estratégia de TesteEstratégia de Teste Descreve:

os passos a serem dados como parte da atividade de teste;

quando esses passos serão planejados e executados; esforço, tempo e recursos exigidos.

Incorpora: planejamento de testes; projeto de casos de teste; execução de teste; coleta e avaliação de dados.

Estágios de TesteEstágios de Teste Teste de unidades: componentes individuais 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 outros componentes (hardware, pessoas, etc.) são testados como um todo;

Teste de aceitação (homologação): o software é testado pelo usuário final.

Teste de UnidadeTeste de Unidade São testados:

A interface com a unidade para garantir que as informações fluem para dentro e para fora da mesma;

Estruturas de dados locais (digitação inconsistente ou imprópria, inicialização com valores default/outros valores, overflow/underflow e corretude dos tipos de dados);

Caminhos de controle importantes e de tratamento de erros dentro das fronteiras da unidade (“teste caixa branca”);

Condições de limite para garantir que a unidade opera adequadamente nos limites estabelecidos para demarcarem ou restringirem o processamento.

Teste de UnidadeTeste de Unidade O procedimento para teste de unidades pode ser:

top-down: as unidades são testadas a partir do topo da hierarquia. O teste usa software driver (aceita dados do caso de teste, ativa a unidade a ser testada e imprime dados relevantes) e stubs (substituem as unidades subordinadas simulando o acesso às suas interfaces);

bottom-up: as unidades são testadas a partir do nível mais básico da hierarquia. O teste usa software driver para ativar a unidade a ser testada. As unidades já testadas num nível inferior podem então ser usadas para testar uma unidade específica no nível superior.

Teste de IntegraçãoTeste de Integração Unidades testadas em separado não são

garantidas de funcionarem em conjunto; A integração deve ser de forma incremental, ou

seja, o programa é construído e testado em pequenos segmentos.

Teste de IntegraçãoTeste de Integração Integração top-down:

As unidades são integradas movimentando-se de cima para baixo na hierarquia de controle, iniciando-se na unidade de controle principal.

Integração bottom-up: As unidades são integradas movimentando-se

de baixo para cima na hierarquia de controle.

Teste de SistemaTeste de Sistema A integração dos componentes de software com o

ambiente operacional é testada; Tipos de teste:

Teste funcional - a funcionalidade geral do sistema é testada. Teste de recuperação - o software é forçado a falhar de

diversas maneiras para que seja verificado se a recuperação é adequada. A recuperação pode ser automática ou exigir intervenção humana;

Teste de segurança - tenta verificar se todos os mecanismos de proteção a acesso indevido estão funcionando satisfatoriamente;

Teste de SistemaTeste de Sistema Tipos de Teste (cont.):

Teste de Estresse - o sistema é testado no seu limite (número de acessos/transações, sobrecarga da memória/disco); 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. Teste de Desempenho - tenta avaliar a performance do

software (principalmente em software de tempo real); Teste de Portabilidade - são testes que verificam o grau de

portabilidade do software em diferentes ambientes de harware/software.

Teste de Aceitação (homologação)Teste de Aceitação (homologação)

Testes de “caixa preta”que demonstram a conformidade com os requisitos obtidos do cliente: Requisitos funcionais; Documentação; etc.

Teste de Aceitação (homologação)Teste de Aceitação (homologação)

São realizados pelo usuário. Podem ser de dois tipos: Testes alfa: feito pelo cliente nas instalações do

desenvolvedor, que observa e registra erros e/ou problemas;

Testes beta: feito pelo cliente em suas próprias instalações, sem a supervisão do desenvolvedor. Os problemas detectados são então relatados para o desenvolvedor.

Ferramentas de TesteFerramentas de Teste

Ferramentas de geração de massa de dados; Ferramentas de teste de API; Ferramentas de teste de GUI; Ferramentas de teste de cobertura; Ferramentas de teste de carga; Ferramentas de detecção de deadlocks; Ferramentas de teste de

desempenho/detecção de gargalos

Estágio de Testes x FerramentasEstágio de Testes x Ferramentas

Teste de unidade/Teste de integração Ferramenta de teste de API Ferramenta de teste de cobertura

Teste de sistema Ferramenta de teste de carga Ferramenta de detecção de deadlocks Ferramenta de geração de massa de dados Ferramenta de teste de desempenho/gargalos

Teste de homologação Geralmente é feito de forma manual, e eventualmente com o

auxílio da ferramenta de teste de GUI

Responsabilidades sobre a Responsabilidades sobre a Execução dos TestesExecução dos Testes Grupo de Desenvolvimento:

Teste de unidades; Teste de integração; Correção de erros; Assessoria ao grupo de teste.

Grupo de Independente de Teste: Teste de sistema; Elaboração de casos de teste; Preparação de relatórios sobre a qualidade do software.

Usuário Teste de aceitação

Teste x DepuraçãoTeste x Depuração Quando um caso de teste ou o uso revela um

erro, a depuração é o processo que resulta na remoção do erro;

Muitas vezes a manifestação externa do erro não tem uma relação óbvia com a sua causa;

A remoção de um erro pode inserir outros erros.

Abordagens para a DepuraçãoAbordagens para a Depuração Força bruta:

Exames de listagens de dump; Exame de traços de run-time; Inserção de instruções “WRITE”.

Backtracking: o programa é rastreado para traz a partir do local onde apareceu o erro;

Eliminação da causa: Os dados relacionados à uma provável causa do erro são gerados. Uma hipótese da causa é formulada e os dados são usados para provar ou refutar a hipótese;

Ajuda externa.