MDC Metodologia de Desenvolvimento Compartilhado Roteiro da Disciplina de Teste

Transcrição

1 MDC Metodologia de Desenvolvimento Compartilhado Roteiro da Disciplina de Teste Agosto

2 SUMARIO 1 INTRODUÇÃO APLICAÇÃO ESTRUTURA DO ROTEIRO DESCRIÇÃO DO ROTEIRO PLANEJAR O PROJETO DE TESTE Elaborar o Plano de Teste ELABORAR O PROJETO DE TESTE Levantar Dados Necessários Preparar o Ambiente de Teste Elaborar Casos de Teste EXECUTAR O PROJETO DE TESTE Executar o Teste Unitário Executar o Teste de Integração Executar os Testes Complementares Executar Teste de Aceitação Alfa Executar Teste de Aceitação Beta ANEXO FORMULÁRIOS DE TESTE TEMPLATE DOS FORMULÁRIOS DE TESTES NÍVEIS DE ERRO EM TESTES FLUXO DOS PROCESSOS DE TESTE REFERÊNCIAS...20

3 3 1 INTRODUÇÃO O Roteiro de Desenvolvimento da disciplina de Teste de Software tem por finalidade agregar qualidade ao produto antecipando a descoberta de falhas e incompatibilidades com o processo do usuário, reduzindo assim o custo do projeto. 2 APLICAÇÃO Esse roteiro deve ser utilizado, após a elaboração do documento de análise, em conjunto com os roteiros de projeto e construção que compõem a metodologia de desenvolvimento de projeto de software. A utilização desse roteiro deve ser feita para cada iteração definida para o produto de software. 3 ESTRUTURA DO ROTEIRO ATIVIDADE PRODUTO PAPEL Planejar o Projeto de Teste Elaborar o Plano de Teste Plano de Teste definido Analista de sistemas Elaborar o Projeto de Teste Levantar dados necessários Lista de Requisitos de Teste Critérios de Testes Analista de sistemas Preparar o Ambiente de Teste Ambiente preparado Analista de sistemas Elaborar Casos de Teste Conjunto de Casos de Teste Analista de sistemas Executar o Projeto de Teste Executar Teste Unitário Objeto/Módulo testado Relatório de Ocorrências Executar Teste de Integração Módulos/Aplicação testados Relatório de Ocorrências Executar Testes Complementares Aplicação Homologada Relatório de Ocorrências Executar Teste de Aceitação Alfa Aplicação Ajustada Relatório de Ocorrências Executar Teste de Aceitação Beta Aplicação Aceita Relatório de Ocorrências Desenvolvedor Integrador Integrador Especialista Integrador Cliente Cliente

4 4 4 DESCRIÇÃO DO ROTEIRO 4.1 PLANEJAR O PROJETO DE TESTE Objetivos: Identificar os objetivos, e os produtos liberados, do esforço de testes. Identificar uma boa estratégia de utilização de recursos e estruturação do ambiente de teste. Definir o escopo e o limite adequados para o esforço de teste. Descrever o método que será usado para teste. Definir os responsáveis pelo teste. Definir como o progresso será monitorado e avaliado Elaborar o Plano de Teste O maior valor na realização desse trabalho é pensar nas várias preocupações e problemas que afetarão o teste no curso da iteração, além de considerar as ações adequadas a se tomar. O Plano de Teste apresenta o planejamento para execução do teste, incluindo a abrangência, abordagem, recursos e cronograma das atividades de teste. Identifica os itens e as funcionalidades a serem testados, as tarefas a serem realizadas e os riscos associados com a atividade de teste. Geralmente, esse trabalho é conduzido no início da iteração, antes que outros detalhamentos do fluxo de trabalho comecem. É recomendado que não se gaste muito tempo no planejamento detalhado das tarefas de teste muito antes da iteração em que elas serão executadas como regra geral, não planeje trabalho de teste detalhado mais de uma iteração a frente. CHECK-LIST Foi definido os itens, requisitos e funcionalidades que serão testados? Os requisitos de teste foi determinado com base nas prioridades do projeto? Foi definido o escopo e a abrangência dos testes? O critério de teste escolhido agrega qualidade ao projeto? A abordagem de teste está clara e atende os requisitos de qualidade? O ambiente de teste foi contemplado? Os testes complementares foram definidos? Responsável: Analista de Sistemas Produto: Plano de Testes definido (ver item 5.1 template de formulários de testes)

5 5 4.2 ELABORAR O PROJETO DE TESTE Objetivos: Verificar o quanto antes se a abordagem de teste pretendida funcionará e produzirá resultados relevantes. Estabelecer a infra-estrutura básica para possibilitar e dar suporte à abordagem do teste. Obter comprometimento da equipe de desenvolvimento para fornecer e dar suporte à testabilidade exigida para atingir a abordagem de teste. Identificar escopo, fronteiras, limitações e restrições de cada teste Levantar Dados Necessários De posse dos requisitos funcionais e não funcionais levantados na análise e durante a elaboração do projeto preliminar, definir os requisitos de teste e identificar grupos de dados que possam dar uma boa cobertura para os itens a serem testados. Para identificar estes grupos de dados existem alguns critérios tais como: particionamento de equivalência, análise de valor limite, teste de caminho básico, teste de condição e teste de laço que são descritos a seguir para servir de apoio ao processo de teste Particionamento de Equivalência Este é um método de teste de caixa preta que divide o domínio de entrada de um programa em classes de dados a partir das quais os casos de teste podem ser derivados. O particionamento de equivalência procura definir um caso de teste que descubra classes de erros, assim reduzindo o número total de casos de teste que devem ser desenvolvidos. Por exemplo: Se os números de 0 a 99 são válidos, então todos os números do intervalo deveriam ser manuseados da mesma forma pelo software. Todos os valores de 0 a 99 estão na mesma classe de equivalência. O projeto de casos de teste para particionamento de equivalência baseia-se numa avaliação de classes de equivalência para uma condição de entrada. Uma classe de equivalência representa um conjunto de estados válidos ou inválidos para condições de entrada. Uma condição de entrada é um valor numérico, um intervalo de valores, um conjunto de valores relacionados ou uma condição booleana Análise de Valor Limite A análise de valor limite é uma técnica de projeto de casos de teste que serve como complemento para a técnica de particionamento de classes. Ao invés de selecionar

6 qualquer valor de uma classe de equivalência, a análise do valor limite leva a seleção de casos de teste nas extremidades da classe. Em vez de se concentrar somente nas condições de entrada, ela deriva os casos de teste também do domínio de saída. Se uma condição de entrada/saída especificar um intervalo delimitado pelos valores a e b, os casos de teste devem ser projetados com valores a e b, logo acima e logo abaixo de a e b respectivamente Teste de Caminho Básico Um caminho básico independente é qualquer caminho através do programa que introduza um novo conjunto de instruções de processamento ou uma condição nova. Se cada caminho básico for testado, cada instrução do programa terá a garantia de ser executada pelo menos uma vez e cada condição terá sido executada com resultado verdadeiro e falso. Prepare casos de teste que forcem a execução de cada caminho no conjunto básico Teste de Condição Em adição aos testes de caminho básico outros testes estruturais podem e devem ser aplicados. Um deles é o teste de condição. O teste de condição é um método de projeto de casos de teste que põe à prova todas as condições lógicas contidas em um programa Teste de Laço Os laços são amplamente utilizados na estrutura dos programas. Raros são os programas que não utilizam a estrutura de repetição(loop) para controle de execução. O teste de laços se concentra exclusivamente na validade das construções de laços. As condições de teste para cada laço é a seguinte: Pule o laço inteiramente; Somente uma passagem através do laço; n-1, n e n+1 passagens através do laço, onde n é o limite do laço. CHECK-LIST Foram consideradas às restrições ambientais e técnicas do ambiente do sistema? Os casos especiais são tratados? Responsável: Analista de Sistemas Ferramenta: TestPlan Produto: Lista de requisitos de teste, Critérios de Teste definidos Preparar o Ambiente de Teste

7 Verificar se o ambiente de teste precisa ser complementado para dar suporte a execução dos testes. Devem ser levantadas informações como: quais bancos de dados, quais servidores de aplicação, quais servidores web e browsers o aplicativo deve suportar e se está disponível neste ambiente, providências a serem tomadas para que sejam disponibilizadas chaves, senhas e diretórios para armazenamento dos arquivos, máquinas, ferramentas de teste, etc. 7 CHECK-LIST O ambiente foi especificado de acordo com as necessidades? Foi verificado as restrições de máquina? Precisa ser instalado algum componente? A massa de dados para teste foi gerada? A massa de dados contempla todas as funcionalidades e estruturas internas do módulo? A massa de dados para teste contempla todos os casos de teste? A massa de dados testa valores de fronteira, valores nulos, valores negativos, valores de tipos diferentes e os caminhos independentes do código? Foi avaliado o ambiente para os testes alfa e beta? Responsável: Analista de Sistemas Envolvidos: Especialistas Produto: Ambiente de Testes disponível Elaborar Casos de Teste A partir dos casos de uso, deve-se extrair casos de teste e depois, dependendo do critério e técnica, selecionar os casos de testes mais adequados. Os casos de teste podem ser projetados iniciando na análise para testes mais funcionais, e depois adequados conforme a necessidade. O importante é que em algum momento destas iterações, depois de definidos os tipos de testes que serão realizados, sejam especificados os critérios de satisfação para cada tipo de teste, ou seja, o critério de cobertura. Os critérios de geração de dados de teste normalmente já indicam critérios de cobertura. Os casos de teste para os testes de integração já podem ser projetados na fase de análise, assim que os requisitos (funcionais e não funcionais) são levantados e, serão executados praticamente em uma fase em que o sistema esteja pronto ou parcialmente pronto, com as partes integradas, para que possa ser testado o requisito levantado. Na fase de projeto, onde estes requisitos são representados em casos de uso e são mais detalhados, devem ser produzidos casos de teste de sistema. Na fase de construção, devem ser projetados os casos de teste para testes de integração e unidade. Os casos de teste de integração devem ser feitos com os registros da simulação da funcionalidade através do Jmeter. CHECK-LIST Os casos de testes atendem todo o escopo? Todos os requisistos foram contemplados nos testes?

8 Responsável: Analista de Sistemas Produto: Conjunto de Casos de Testes (ver item 5.1 template de formulários de testes) 4.3 EXECUTAR O PROJETO DE TESTE Objetivos: 8 Fornecer avaliação contínua dos itens de teste. Registrar as informações necessárias para diagnosticar e resolver os problemas identificados. Atingir a amplitude e o detalhamento apropriados no trabalho de teste. Fornecer feedback nas áreas de risco potencial para a qualidade. Todo problema identificado nas atividades de execução dos testes deve ser passível de ser reproduzido de acordo com as anotações nos registros de ocorrências Executar o Teste Unitário O teste de unidade concentra-se no esforço de verificação da menor unidade de projeto de software. Os caminhos de controle importantes são testados para descobrir erros dentro das fronteiras da unidade. A complexidade relativa dos testes e os erros detectados como resultados deles são limitados pelo escopo estabelecido para o teste de unidade. Nos testes de unidade são verificados: A interface com o módulo é testada para ter a garantia de que as informações fluem para dentro e para fora da unidade que se encontra em teste; A estrutura de dados local é examinada para ter a garantia de que os dados armazenados temporariamente mantêm sua integridade durante todos os passos de execução de um algoritmo; As condições de limite são testadas para ter a garantia de que a unidade opera adequadamente nos limites estabelecidos para demarcarem ou restringirem o processamento; Todos os caminhos independentes através da estrutura de controle são exercitados para ter a garantia de que todas as instruções de uma unidade foram executadas pelo menos uma vez e Todos os caminhos de tratamento de erros são testados. O procedimento comumente utilizado para teste de unidade envolve o desenvolvimento de um software driver para cada unidade de teste ou a utilização de uma ferramenta que auxilie o teste. O driver é um programa principal que aceita dados de teste, passa tais dados para a unidade a ser testada e imprime os dados relevantes. A unidade testada também deve ser verificada quanto ao atendimento de todos os requisitos definidos e a utilização dos padrões.

9 9 CHECK-LIST Foi testado a consistência dos dados de entrada? Foram testados campos obrigatórios, digitos verificadores, datas válidas, domínios de tabela, valores de fronteira, valores nulos, valores padrão (default) e de tipos diferentes? Foram testados a necessidade de caixa alta/baixa e a dependência de valores com outros atributos? As expressões e operações lógicas foram revisadas? O código está de acordo com os padrões da empresa? Os módulos codificam o que está especificado no projeto? O tratamento de erros e exceções foi incluído no código? As mensagens do programa estão claras? Todos os dados foram atualizados corretamente? Todas as operações de atualização permitidas foram testadas? Foi verificada a situação de duplicidade de dados? Foi verificada a solicitação de atualização/exclusão de um dado inexistente? O relatório foi testado com mais de uma página? Foram testadas todas as quebras do relatório? Os totais do relatório estão corretos? Responsável: Desenvolvedor Ferramentas: Junit, Verificador de Padrão de Codificação Java (a definir) Produtos: Relatório de Ocorrências, Item de teste aprovado (ver item 5.1 Template dos formulários de testes) Executar o Teste de Integração O teste de integração é uma técnica sistemática para a construção da estrutura da aplicação, que ao mesmo tempo procura descobrir erros relacionados à interface. O objetivo é, a partir dos módulos testados no nível de unidade, construir a estrutura da aplicação que foi determinada pelo projeto. Esta integração deve ser incremental com a abordagem bottom-up, ou seja, do nível mais baixo para cima. A estratégia de integração bottom-up pode ser implementada com os seguintes passos: Módulos de nível mais baixo são combinados em clusters (ou construções) que executam uma subfunção de software específica; Um driver (um programa de controle para teste) é escrito para coordenar a entrada e a saída do caso de teste; O cluster é testado; Os drivers são removidos e Os clusters são combinados ao se dirigir para cima na estrutura da aplicação. CHECK-LIST Foram feitas simulações para verificar interação com outros sistemas e bases de dados?

10 10 Todas as possibilidades de execução da estrutura da aplicação foram consideradas e simuladas? Responsável: Integrador Feramenta: JMeter Produto: Relatório de Ocorrências, Aplicação Homologada Tecnicamente Executar os Testes Complementares A necessidade e a amplitude dos testes complementares são definidos na elaboração do plano de teste. Os testes complementares são: Teste de Segurança Teste de Desempenho Teste de Estresse Teste de Resistência a Falhas Teste de Segurança O teste de segurança tenta verificar se todos os mecanismos de proteção embutidos em um sistema o protejerão de acessos indevidos. Este teste garante que os dados e/ou funções possam ser acessados apenas por determinados atores. Todas as formas de ataque devem ser simuladas. O papel do projetista é tornar o acesso indevido às informações mais caro do que o valor da informação que será obtida Teste de Desempenho O teste de desempenho é idealizado para testar o tempo gasto para processar uma funcionalidade do software dentro do contexto de um sistema integrado. O teste de desempenho ocorre dentro do contexto de um sistema integrado e ao longo de todos os passos do processo de teste. Algumas vezes os testes de desempenho são combinados com os de estresse e frequentemente utiliza-se instrumentação de hardware e de software para medição dos recursos com ciclo de processador Teste de Estresse O teste de estresse é feito para confrontar o sistema com situações anormais. O teste de estresse executa o sistema de forma que exige recursos em quantidade, frequência ou volume anormais.o stress no sistema pode abranger cargas de trabalho extremas, memória insuficiente, hardware e serviços indisponíveis ou recursos compartilhados limitados. Normalmente, esses testes são executados para compreender melhor como e em quais áreas o sistema será dividido, para que os planos de contingência e a manutenção de atualização possam ser planejados com bastante antecedência.

11 Teste de Resistência a Falhas Os dados podem ser perdidos quando hardware falha ou quando arquivos são apagados voluntária e involuntariamente, ataque de vírus, desastres naturais, falhas provocadas pelo conflito de memória do sistema operacional, quando aponta para um caminho que não existe, etc. Deve-se fazer um planejamento da estratégia de backup, registro de transações (log) e verificação das cópias para possibilitar a recuperação de informações. CHECK-LIST Foram feitos testes com o volume esperado? Foi verificado o tempo de resposta das funções? Foi testada a condição de término anormal e retomada dentro da rotina? Foi testado acesso não autorizado? Foi verificada a gravação do log? Responsável: Integrador Envolvidos: Especialistas Ferramenta: Jmeter (estresse) Produto: Relatório de Ocorrências, Aplicação Homologada Tecnicamente Executar Teste de Aceitação Alfa Os testes de aceitação alfa é executado por um cliente nas instalações do desenvolvedor. O software é usado num ambiente natural com o desenvolvedor acompanhando e registrando erros e problemas de uso. Os testes alfa são conduzidos em um ambiente controlado. CHECK-LIST Foi verificado a adaptabilidade do software ao modo de trabalho do usuário? Foi verificado a facilidade de compreensão do sistema pelo usuário? Responsável: Testador Envolvidos: Cliente Produto: Relatório de Ocorrências, Software Ajustado com o Cliente

12 Executar Teste de Aceitação Beta Os testes de aceitação beta, feitos pelo usuário, que dificilmente opera o sistema de forma prevista, e visam descobrir erros cumulativos que poderiam deteriorar o sistema no decorrer do tempo. Estes testes devem ser realizados no ambiente de homologação e se possível em uma ou mais instalações do cliente pelo usuário final do software. Geralmente o desenvolvedor não está presente. Assim, o teste beta é uma aplicação viva do software, num ambiente que não pode ser controlado pelo desenvolvedor. Os problemas são registrados pelo usuário e repassados regularmente ao desenvolvedor, que corrige o software antes de lançar o produto. Responsável: Usuário final Envolvidos: Testador Produto: Relatório de Ocorrências, Software Homologado pelo cliente

13 13 5 ANEXO FORMULÁRIOS DE TESTE 5.1 TEMPLATE DOS FORMULÁRIOS DE TESTES Plano de Teste 1 Descrição do Plano: a. Descrever em linhas gerais qual o objetivo dos testes e o seu escopo. 2 Itens de teste: a. Identificar os itens de teste Módulos. Métodos. Classes. Casos de Uso. b. O que será testado e os critérios de teste: Funcionalidade. Interface. Desempenho. Carga (stress). Usabilidade. Volume. Segurança. 3 Abordagem: a. De qual maneira serão realizados os testes? b. Será utilizado algum software? c. Será gerada massa de dados? 4 Ambiente necessário: a. Descrição hardware, software, configurações/condições especiais para que os testes sejam realizados. 5 Responsáveis: a. Definir as pessoas e/ou grupos responsáveis para cada atividade de teste.

14 Descrição do Caso de Teste Unitário Item de Teste: Data: / / Desenvolvedor: Objetivo do Teste: Ambiente Necessário: Dependência/Pré-Requisito: Casos de Teste Testador: Entrada Resultado Esperado Resultado Encontrado Situação Descrever os dados utilizados no teste Descrever o resultado esperado para o item de teste. Descrever o resultado obtido para o item de teste. Caso ocorra um evento inesperado, ele deverá ser descrito no Registro de Ocorrências. (OK, NOK)

15 Descrição do Caso de Teste de Integração/Complementar Caso de Uso: Data: / / Analista: Objetivo do Teste: Ambiente Necessário: Dependência/Pré-Requisito: Casos de Teste Testador: Procedimento Entrada Resultado Esperado Resultado Encontrado Situação Descrever o passo n do procedimento. Passo 2... Descrever os dados utilizados no teste Descrever o resultado esperado para o item de teste. Descrever o resultado obtido para o item de teste. Caso ocorra um evento inesperado, ele deverá ser descrito no Registro de Ocorrências. (OK, NOK) Passo 3... Passo n...

16 Registro de Ocorrência Item de Teste: Data: / / Desenvolvedor: Testador: Detalhamento da Ocorrência Nível Entrada Saída Descrição Simples Grave Crítica Descrever os dados utilizados no teste. Descrever o resultado, a mensagem que foi gerada pela execução do teste. Apresentar o resultado esperado e o resultado encontrado para fins de facilitar o entendimento. Descrever o procedimento que gerou a ocorrência. Passos que foram realizados até o momento da ocorrência. Detalhar a ocorrência para que possa ser reproduzido posteriormente. Descrever os impactos da ocorrência e se possível uma sugestão de melhoria.

17 NÍVEIS DE ERRO EM TESTES As ocorrências detectadas pelos testes realizados estão divididos em três níveis: Simples são ocorrências de fácil acerto e que não comprometem o resultado final do item testado. Grave são ocorrências que comprometem o resultado final do item testado. Crítico são ocorrências que comprometem o resultado final do item testado e tem impacto em outros itens da aplicação.

18 5.3 FLUXO DOS PROCESSOS DE TESTE GERENTE PROJETO ANALISTA DBA ORGANIZAR DOCUMEN- TAÇÃO PLANEJAR TESTE PROJETO CASOS DE USO PLANO DE TESTE LISTA DE REQUISITOS PROJETAR TESTE CASOS DE TESTE CRITERIOS DADOS CRIAÇÃO MASSA TESTE

19 DESENVOLVEDOR INTEGRADOR CLIENTE CODIFICAR COMPONENTE CORRIGIR OCORRENCIA N TESTAR UNIDADE OK S CONSTRUÇ ÃO ATUALIZAR CVS N FIM MODULO S TESTAR INTEGRACAO OK N S TESTAR ALFA OK N S N TESTAR BETA OK S

20 20 6 REFERÊNCIAS [LARMAN, 2004] LARMAN, CRAIG. Utilizando UML e Padrões: Uma introdução à análise e ao projeto orientados a objetos e ao processo unificado, Porto Alegre: Bookman, 2. edição, 2004 VOLPI (CEL.), Lisiane Maes. SZTOLTZ, Lisiane. Uma estrategia de teste de software para ambiente cliente-servidor. Curitiba : UFPR, 2001 NEVES (CEL.), Luciane. Projeto de uma metodologia de testes para sistemas de informação corporativa. Curitiba : ICSP, 1999 The Institute of Electrical and Eletronics Engineers. IEEE Std 829: Standard for Software Test Documentation. New York: IEEE Computer Society, 1998