Engenharia de Software com o RUP - Workflow de Testes Parte I

Apresentação em tema: "Engenharia de Software com o RUP - Workflow de Testes Parte I"— Transcrição da apresentação:

1 Engenharia de Software com o RUP - Workflow de Testes Parte I
Alexandre Vasconcelos, André Santos, Augusto Sampaio, Hermano Moura, Paulo Borba © Centro de Informática Universidade Federal de Pernambuco

2 Objetivos: Entender os conceitos básicos do workflow de Testes
Entender como ler e interpretar os artefatos gerados por este workflow

3 Tó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

4 Motivaçã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.

5 Introduçã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.

6 Objetivo 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

7 Abordagens 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.

8 Estratégia de Teste Descreve: Incorpora:
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.

9 Está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.

10 Teste 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.

11 Teste 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.

12 Teste 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.

13 Teste de Integração Integração top-down: Integração bottom-up:
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.

14 Teste 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;

15 Teste 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.

16 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.

17 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.

18 Ferramentas 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

19 Está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

20 Responsabilidades sobre a Execuçã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

21 Teste 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.

22 Abordagens 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.