Engenharia de Software com o RUP Workflow de

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

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

Tópicos Cobertos n n n n n 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 Teste x Depuração Abordagens para a Depuração

Motivação n n n 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ção n n n 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 Testes n n n 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 Teste n Existem basicamente duas abordagens que podem ser aplicadas a diferentes tipos de teste: u 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; u 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 Teste n Descreve: u os passos a serem dados como parte da atividade de teste; u quando esses passos serão planejados e executados; u esforço, tempo e recursos exigidos. n Incorpora: u planejamento de testes; u projeto de casos de teste; u execução de teste; u coleta e avaliação de dados.

Estágios de Teste n n 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 Unidade n São testados: A interface com a unidade para garantir que as informações fluem para dentro e para fora da mesma; u 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); u Caminhos de controle importantes e de tratamento de erros dentro das fronteiras da unidade (“teste caixa branca”); u Condições de limite para garantir que a unidade opera adequadamente nos limites estabelecidos para demarcarem ou restringirem o processamento. u

Teste de Unidade n O procedimento para teste de unidades pode ser: u 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); u 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ção n n 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ção n Integração top-down: u As unidades são integradas movimentando-se de cima para baixo na hierarquia de controle, iniciando-se na unidade de controle principal. n Integração bottom-up: u As unidades são integradas movimentando-se de baixo para cima na hierarquia de controle.

Teste de Sistema n n A integração dos componentes de software com o ambiente operacional é testada; Tipos de teste: Teste funcional - a funcionalidade geral do sistema é testada. u 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; u Teste de segurança - tenta verificar se todos os mecanismos de proteção a acesso indevido estão funcionando satisfatoriamente; u

Teste de Sistema n Tipos de Teste (cont. ): u Teste de Estresse - o sistema é testado no seu limite (número de acessos/transações, sobrecarga da memória/disco); F 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); u Teste de Portabilidade - são testes que verificam o grau de portabilidade do software em diferentes ambientes de harware/software. u

Teste de Aceitação (homologação) n Testes de “caixa preta”que demonstram a conformidade com os requisitos obtidos do cliente: u Requisitos funcionais; u Documentação; u etc.

Teste de Aceitação (homologação) n São realizados pelo usuário. Podem ser de dois tipos: u Testes alfa: feito pelo cliente nas instalações do desenvolvedor, que observa e registra erros e/ou problemas; u 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 Teste n n n n 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 Ferramentas n Teste de unidade/Teste de integração u Ferramenta de teste de API u Ferramenta de teste de cobertura n Teste de sistema u Ferramenta de teste de carga u Ferramenta de detecção de deadlocks u Ferramenta de geração de massa de dados u Ferramenta de teste de desempenho/gargalos n Teste de homologação u Geralmente é feito de forma manual, e eventualmente com o auxílio da ferramenta de teste de GUI

Responsabilidades sobre a Execução dos Testes n Grupo de Desenvolvimento: Teste de unidades; u Teste de integração; u Correção de erros; u Assessoria ao grupo de teste. u n Grupo de Independente de Teste: Teste de sistema; u Elaboração de casos de teste; u Preparação de relatórios sobre a qualidade do software. u n Usuário u Teste de aceitação

Teste x Depuração n n n 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ção n n Força bruta: u Exames de listagens de dump; u Exame de traços de run-time; u 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.