Curso de Engenharia de Computação PROCESSO DE TESTE DE...

Curso de Engenharia de Computação

PROCESSO DE TESTE DE SOFTWARE:

UM ESTUDO DE CASO

Wilson Rafael Rovere

Campinas – São Paulo – Brasil

Dezembro de 2008

i

Curso de Engenharia de Computação

PROCESSO DE TESTE DE SOFTWARE:

UM ESTUDO DE CASO


Monografia apresentada à disciplina de Trabalho de Conclusão do Curso de Engenharia de Computação da Universidade São Francisco, sob a orientação do Prof. Dr. Adalberto Nobiato Crespo, como exigência parcial para conclusão do curso de graduação. Orientador : Prof. Dr. Adalberto Nobiato Crespo Co-orientador: Prof. Dr. André Leon S. Gradvohl

Campinas – São Paulo – Brasil

Dezembro de 2008

ii

PROCESSO DE TESTE DE SOFTWARE: UM ESTUDO DE CASO


Monografia defendida e aprovada em 11 de Dezembro de 2008 pela Banca

Examinadora assim constituída:

Prof. Dr. Adalberto Nobiato Crespo (Orientador)

USF – Universidade São Francisco – Campinas – SP.

Prof. M. Sc. Raimundo Cláudio da Silva Vasconcelos


Prof. Esp. Ricardo César Boaretto


iii

Este trabalho é dedicado a toda minha família,

especialmente a meus pais, Maria Judite

Moscatini Rovere e Wilson Roberto Rovere, por

terem sido tão maravilhosamente dedicados e

amorosos, sempre me guiando pelos melhores

caminhos da vida.

iv

.Agradecimentos

Agradeço primeiramente a Deus, por ter me guiado espiritualmente nesta caminhada de

crescimento pessoal e profissional.

Aos meus familiares e em especial aos meus pais e minha namorada Patrícia que sempre

acreditaram no meu potencial e me incentivaram nas horas mais difíceis.

Ao orientador deste trabalho, Prof. Dr. Adalberto Nobiato Crespo, pela confiança, apoio,

paciência e amizade.

Ao coordenador do curso de Engenharia de Computação da Universidade São Francisco Prof.

Dr. André Leon S. Gradvohl, pela predisposição em analisar este trabalho e pelas sugestões

recebidas.

Finalmente, agradeço a todos que direta ou indiretamente colaboraram na elaboração deste

trabalho de conclusão de curso.

v

Sumário

Lista de Siglas .........................................................................................................................vii

Lista de Figuras .....................................................................................................................viii

Lista de Tabelas ....................................................................................................................... ix

Resumo ...................................................................................................................................... x

Abstract ..................................................................................................................................... x

1 Introdução .......................................................................................................................... 1

1.1 Contextualização ........................................................................................................... 1

1.2 Objetivos ....................................................................................................................... 2

1.3 Estrutura do texto .......................................................................................................... 4

2 Revisão bibliográfica ......................................................................................................... 4

3 Níveis de testes.................................................................................................................... 6

3.1 Teste de unidade............................................................................................................ 6

3.2 Teste de integração........................................................................................................ 7

3.3 Teste de sistema ............................................................................................................ 8

3.4 Teste de aceitação do usuário........................................................................................ 8

4 Tipos de testes..................................................................................................................... 9

4.1 Testes funcionais ........................................................................................................... 9

4.1.1 Teste de usabilidade ............................................................................................. 9

4.1.2 Teste de interface ............................................................................................... 10

4.1.3 Teste de regressão .............................................................................................. 10

4.2 Testes estruturais ......................................................................................................... 11

4.2.1 Teste de desempenho ......................................................................................... 11

4.2.2 Teste de segurança ............................................................................................. 12

4.2.3 Teste de stress / volume ..................................................................................... 12

4.3 Relacionamento entre os níveis e tipos de testes......................................................... 13

vi

5 Processo de testes ............................................................................................................. 14

5.1 Definição de processo de testes................................................................................... 14

5.2 Caracterização do processo de testes .......................................................................... 14

5.3 Documentação do processo de testes .......................................................................... 16

5.4 Os sete passos de um porcesso de teste de software ................................................... 19

6 Estudo de caso .................................................................................................................. 22

7 Conclusão.......................................................................................................................... 34

7.1 Contribuições .............................................................................................................. 34

7.2 Trabalhos futuros......................................................................................................... 35

8 Referências bibliográficas ............................................................................................... 36

9 Anexos ............................................................................................................................... 37

vii

Lista de Siglas

ABNT Associação Brasileira de Normas Técnicas

AFI Ameriprise Financial Inc. (American Express)

CMI Common Message Interface

CMMI Capability Maturity Model Integration

CTI Centro de tecnologia da Informação Renato Archer

E2E End to End

FVT Functional Verification Test

IBM International Business Machines

NBR Norma Brasileira Registrada

PRAXIS Processo para Aplicativos Extensíveis Interativos

PSE Professional Services Environment

RFS Report File System

RVT Regression Verification Test

SVT System Verification Test

TC Test Case

TI Tecnologia da Informação

TUAM Tivoli Usage and Accounting Manager

UAT User Acceptance Tests

viii

Lista de Figuras

FIGURA 1: RELAÇÃO ENTRE CUSTO E NÍVEL DE QUALIDADE EM UM PROCESSO DE TESTE DE

SOFTWARE...........................................................................................................................2

FIGURA 2: MODELO BÁSICO DE PROCESSO DE TESTE.................................................................15

FIGURA 3: CARACTERIZAÇÃO DO PROCESSO DE TESTE DE SOFTWARE.......................................16

FIGURA 4: FLUXOGRAMA DA DOCUMENTAÇÃO DO PROCESSO DE TESTE DE SOFTWARE.............18

FIGURA 5: VISÃO SIMPLIFICADA DA DOCUMENTAÇÃO DO PROCESSO DE TESTE DE SOFTWARE...19

FIGURA 6: OS SETE PASSOS DE UM PROCESSO DE TESTE DE SOFTWARE......................................20

FIGURA 7: PROCESSO DE TESTE DE SOFTWARE DE UMA EMPRESA COM CERTIFICAÇÃO CMMI

NÍVEL 5..............................................................................................................................24

FIGURA 8: NÚMERO TOTAL DE CASOS DE TESTES.......................................................................30

FIGURA 9: STATUS FINAL DE DEFEITOS ABERTOS/FECHADOS/CANCELADOS ..............................30

FIGURA 10: STATUS FINAL DAS EXECUÇÕES DOS TESTES...........................................................32

FIGURA 11: PERCENTAGEM ACIMA/ABAIXO DO PLANEJADO......................................................33

ix

Lista de Tabelas

TABELA 1: TABELA DE RELACIONAMENTO ENTRE OS NÍVEIS E TIPOS DE TESTES........................13

TABELA 2: CLASSIFICAÇÃO DA SEVERIDADE.............................................................................28

TABELA 3: CLASSIFICAÇÃO DA PRIORIDADE..............................................................................28

x

Resumo

Atualmente, as empresas de software têm investido na melhoria dos seus processos de

desenvolvimento, e o teste de software é uma das maneiras de garantir a qualidade do produto

final. No entanto, percebe-se a existência de uma grande diferença entre o estado da arte e o

estado da prática de teste de software. Existem poucas evidências relatadas da efetividade das

práticas de teste de software sugeridas pela literatura técnica na indústria. Baseado neste

contexto, este trabalho apresentará como são realizadas as atividades de planejamento, projeto

e execução do teste e análise dos resultados da aplicação de um processo de teste de software.

Desta forma, define-se o processo, caracteriza-o, descreve-se a documentação utilizada em

um processo de teste, os níveis de testes, os tipos de testes dentro das técnicas funcionais e

estruturais de teste com um demonstrativo do relacionamento entre os níveis e tipos de testes

de software. Um estudo de caso de um processo de teste de software de uma empresa com

certificação CMMI nível 5 é também apresentado.

PALAVRAS-CHAVE: Teste de software, Processo de teste, Qualidade de software.

Abstract

Nowadays, software companies have invested in improving their development

processes and software testing is one of the ways to ensure the final product quality. However,

there is a gap between the state of the art and the state of the practice regarding software

testing area. There are just a few evidences concerned with effectiveness of software testing

practices suggested by the technical literature in the industry. Based on this context, this

monograph will present how works the planning activities, design and implementation of

testing and analyzing their results applying software testing process. Thus, defines the

process, characterized it, describing the used documentation in a testing process, the levels

and types of tests on functional and structural test techniques with an example of the

relationship between them. A case study of software testing process on a CMMI level 5

company certified is also presented.

KEY WORDS: Software testing, Test process, Software quality.

1

1. Introdução

1.1. Contextualização

Teste de software é o processo de executar o software de uma maneira

controlada com o objetivo de avaliar se o software se comporta conforme

especificado. O teste é uma atividade fundamental para assegurar que o software

atende aos requisitos do usuário, para se ter a confiança de que o software terá um

desempenho adequado, certificar que o programa não contém erros e compreende a

avaliação final da qualidade do produto desenvolvido.

O desenvolvimento de sistemas de software envolve uma série de atividades de

produção em que as oportunidades para a ocorrência da falha humana são enormes.

Erros podem vir a ocorrer em qualquer fase do processo de desenvolvimento. Por este

motivo, o desenvolvimento é acompanhado por uma atividade de garantia de

qualidade.

Para todo e qualquer processo de desenvolvimento de software, o teste

realizado durante ou após o desenvolvimento do software requer um processo bem

definido que oriente a sua realização.

Entretanto, como a maioria das atividades bem planejadas, um bom processo

de testes custa caro e carrega consigo o grande dilema dos produtos de software:

“Qual o retorno de investimento no processo de testes?”

Para tentar explicar a importância do investimento em um processo de testes,

podemos montar a seguinte conta:

Custo total = custo de falha + custo do teste, onde:

Custo de falha: Defeitos encontrados no produto após sua entrega ao cliente,

produto de baixa qualidade (ex: Correção de defeitos, re-testes, insatisfação dos

clientes, danos à reputação da empresa, oportunidades de negócio perdidas, etc.).

Custo do teste: Quanto se gasta para que o sistema fique de acordo com o

documento de requisitos (ex: Métodos de engenharia de software, atividades de teste,

melhoria de processos, auditorias, inspeções, etc.). [Fundamentos de teste de software,

Adalberto Nobiato Crespo].

2

A figura 1 apresenta um gráfico onde ilustra melhor esta relação entre custo e o

nível de qualidade em um processo de testes de software:

Figura 1: Relação entre custo e nível de qualidade em um processo de teste de software

Fonte: CTI - Centro de Tecnologia da Informação Renato Archer

De acordo com a representação deste gráfico, quanto maior a qualidade do

software desenvolvido menores são os custos de falhas, ou seja, os custos de não se

testar um software (Correção de Defeitos, Perda de Imagem, Perda de Mercado, etc.) e

maiores são os custos dos testes envolvidos no processo de testes para a prevenção e

melhoria da qualidade (Atividades de Teste, Melhoria de Processos, etc.).

Um processo de teste de software tem como objetivo balancear estes custos,

fazendo com que a soma dos custos de falhas e custos dos testes resultem em um custo

total que, conforme apresentado no gráfico é o ponto central, ou seja, a melhor relação

custo/benefício para o desenvolvimento e garantia de qualidade de um software.

Portanto, os testes são investimentos e não perda de tempo. Pensando dessa

forma é preciso verificar os riscos que existem, analisando-os, de modo que, os

benefícios sejam os maiores possíveis.

1.2. Objetivos

O teste do software é um processo realizado pelo testador de software que

permeia outros processos da Engenharia de Software, e envolve ações que vão do

levantamento de requisitos (necessidades) até a execução do teste propriamente dito. O

objetivo do teste, por paradoxal que pareça, é encontrar defeitos nos produtos, para

Custo de falha

Custo do teste Custo total

Qualidade

Custo

3

que estes possam ser corrigidos pela equipe de programadores, antes da entrega final

do produto ao cliente.

O processo de teste de software é voltado para o alcance de um nível de

qualidade de produto, que durante o processo de desenvolvimento de software muda

conforme avanço das atividades - requisitos, protótipos, código-fonte, módulos

funcionais e finalmente um sistema.

O conceito de teste de software pode ser compreendido através de uma visão

intuitiva ou mesmo de uma maneira formal. Existem atualmente várias definições para

esse conceito. De uma forma intuitiva, testar um software significa verificar através de

uma execução controlada se o seu comportamento está de acordo com o especificado.

O objetivo principal desta tarefa é encontrar o número máximo de erros dispondo do

mínimo de esforço, ou seja, mostrar aos que desenvolvem se os resultados estão ou

não de acordo com os padrões estabelecidos.

No desenvolvimento de um software, dentre os processos que refletem na

qualidade, a tarefa de teste é fundamental para a avaliação do software desenvolvido.

Entretanto, testar software não é uma atividade trivial, mas exige conhecimentos,

habilidades e infra-estrutura específicos. Um bom desenvolvedor ou projetista de

software, sem esta base, dificilmente poderá realizar uma boa tarefa de teste.

O CMMI (Capability Maturity Model Integration) é um modelo de referência

que fornece orientação para o desenvolvimento de processos de softwares e tem como

objetivos eliminar suas inconsistências; aumentar sua clareza e entendimento; fornecer

uma terminologia comum e um estilo consistente; promove uma visão integrada da

melhoria dos processos organizacionais; e um novo meio de representação da

informação de disciplinas específicas, através do uso de modelos de melhoria testados.

[Software Engineering Institute, 2001].

O objetivo deste trabalho é estudar um processo de teste, identificar os

diferentes níveis e tipos de testes, bem como suas respectivas técnicas de testes. A

criação de um plano de testes, de casos de testes, a execução dos testes e a análise dos

resultados, apresentando-se por fim, um estudo de caso onde é aplicada de forma

prática toda a teoria apresentada no trabalho.

4

1.3. Estrutura do texto

No capítulo 1 é apresentado uma contextualização, o objetivo deste trabalho

acadêmico, e a estrutura do texto. No capítulo 2 temos a revisão bibliográfica onde são

apresentadas as principais definições do assunto estudado para uma melhor

compreensão de toda a parte teórica em que se baseia este trabalho. O capítulo 3 trata

dos principais níveis de testes existentes em um processo de testes. O capítulo 4 é

especialmente dedicado a descrição dos tipos de testes dentro das técnicas funcionais e

estruturais com um demonstrativo do relacionamento entre os níveis e tipos de testes.

No capítulo 5 contém a definição de processo de testes, caracterização de processo de

testes, e a descrição da documentação do processo de teste. O capítulo 6 apresenta o

estudo de caso de um processo de testes utilizado em uma empresa com certificação

CMMI nível 5 conforme estudado. O capítulo 7 finaliza com a conclusão e as

possíveis contribuições para trabalhos futuros.

2. Revisão bibliográfica

Para Ian Sommerville (2003), um processo de software é um conjunto de atividades e

resultados associados que geram um produto de software. Um modelo de processo de software

é uma descrição simplificada de um processo de software. As quatro atividades fundamentais

de qualquer processo de software são: especificação de software, desenvolvimento do software,

validação do software e evolução do software. Diferentes processos de software organizam

essas atividades de maneiras diversas e são descritos em diferentes níveis de detalhe. Diferentes

organizações podem utilizar processos diferentes para produzir o mesmo tipo de produto.

Alguns processos são mais adequados do que outros para alguns tipos de aplicação. Um

modelo de processo de software é uma descrição simplificada de um processo de software; é

uma abstração do processo real.

Na visão de Wilson de Pádua Paula Filho (2004), um processo de software é um

conjunto de passos parcialmente ordenados, constituídos por atividades, métodos, práticas e

transformações, usado para desenvolver, evoluir, adquirir e contratar software. Um processo de

desenvolvimento de software abrange subprocessos de determinação dos requisitos, análise,

desenho, implementação e testes. Um processo define: o que é feito (produto), quando (passos),

5

por quem (agentes), as coisas que usa (insumos) e as coisas que produz (resultados). Os passos

de um processo podem ter ordenação apenas parcial, o que pode permitir paralelismo entre

alguns passos. Um subconjunto de passos pode ser definido como um subprocesso. Passos,

subprocessos, agentes, insumos e resultados estão entre os elementos de um processo. A

arquitetura de um processo define um arcabouço conceitual para a organização dos elementos

de um processo.

Para Shari Lawrence Pfleeger (2004) um processo é um conjunto de tarefas ordenadas

que envolvem atividades, restrições e recursos para alcançar a saída desejada. Um processo

geralmente envolve um conjunto de ferramentas e técnicas. Todo processo tem as seguintes

características: - o processo prescreve todas as suas principais atividades; - o processo utiliza

recursos, está sujeito a um conjunto de restrições (como um cronograma) e gera produtos

intermediários e finais; - o processo pode ser composto de subprocessos de algum modo

relacionados, pode ser definido como uma hierarquia de processos, organizados de tal maneira

que cada subprocesso tenha seu próprio modelo de processo; - cada atividade do processo tem

critérios de entrada e saída, de modo que seja possível saber quando o processo começa e

quando termina; - as atividades são organizadas em uma seqüência, para que a ordem de

execução de uma atividade em relação às outras seja clara; - todo processo tem um conjunto de

diretrizes que explicam os objetivos de cada atividade; - Restrições e controles podem ser

aplicados a uma atividade, recurso ou produto (por exemplo, o orçamento ou o cronograma

podem limitar o tempo que a atividade pode levar, ou a ferramenta, o modo como os recursos

podem ser utilizados).

Myers (1979) define um processo de teste como atividades e práticas usadas para se

testar um software, assim como artefatos usados nas atividades. Considerando que qualidade do

processo de teste tem relação direta com a qualidade final do produto desenvolvido, o

aprimoramento deste processo é crucial para o sucesso de organizações desenvolvedoras de

software. Define teste como um processo de executar um programa ou sistema com a intenção

de encontrar erros. Trata-se de uma atividade essencial para que se atinjam bons níveis de

qualidade em produtos de software.

Segundo Bill Hetzel, John Wiley & Sons (1988), teste é uma atividade direcionada

para avaliar um atributo ou capacidade de um programa ou sistema e determinar se o mesmo

satisfaz os resultados requeridos.

Um caso de teste é constituído por um conjunto de dados de entrada e os respectivos

resultados esperado da execução.

6

De acordo com Pressman (2002), a atividade de teste consiste em uma análise

dinâmica do produto, ou seja, na execução do produto de software com o objetivo de verificar a

presença de defeitos no produto e aumentar a confiança de que o mesmo esteja correto,

representando a última versão da especificação, projeto e codificação. A atividade de teste não

pode mostrar a ausência de bugs; ela só pode mostrar se defeitos de software estão presentes.

Além disso, uma atividade de teste conduzida de forma sistemática e criteriosa auxilia no

entendimento dos artefatos testados e evidencia as características mínimas desejadas do ponto

de vista da qualidade do software. A qualidade de software é a conformidade a requisitos

funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento

claramente documentados e a características implícitas esperadas de todo software

desenvolvido profissionalmente.

3. Níveis de testes

O nível de teste é determinado pelo artefato de software utilizado para derivar os

requisitos de teste; a cada fase do processo de software corresponde um nível de teste.

[Fundamentos de teste de software, Adalberto Nobiato Crespo].

A seguir serão descritos alguns níveis de testes utilizados em um processo de teste de

software em uma empresa com certificação CMMI nível 5.

3.1. Teste de unidade

Também conhecida como Teste Unitário, é a fase do processo de teste em que

se testam as menores unidades de software desenvolvidas (pequenas partes ou

unidades do sistema). O universo alvo desse tipo de teste são os métodos dos objetos

ou mesmo pequenos trechos de código. Assim, o objetivo é o de encontrar falhas de

funcionamento dentro de uma pequena parte do sistema funcionando

independentemente do todo. [Bill Hetzel, 1988].

Teste de unidade é o nível de teste inicial de experimentação das mudanças

realizadas no código em uma determinada fase do projeto. Neste nível são verificadas

as especificações do programa para a validação de sua lógica interna desenvolvida em

7

um módulo, sub-rotina, método ou classe do sistema. [Wilson de Pádua Paula Filho,

2004].

Algumas etapas em comum que devem ser verificadas neste nível de testes são:

• Se todas as variáveis estão explicitamente declaradas e inicializadas;

• Se as variáveis de referência estão atribuídas corretamente;

• Se as condições de erros inesperados foram manuseadas corretamente.

Durante o desenvolvimento do programa, deverão ser escritos os casos de

testes em paralelo, pois assim, algumas vantagens serão obtidas, como por exemplo:

• Os casos de testes serão concebidos mais objetivamente;

• Não serão influenciados pelo estilo da codificação;

• Não serão ignoradas as etapas que necessitam ser verificadas neste nível de teste.

3.2. Teste de integração

Na fase de teste de integração o objetivo é encontrar falhas provenientes da

integração interna dos componentes de um sistema. Geralmente os tipos de falhas

encontradas são de envio e recebimento de dados. Por exemplo, um objeto A pode

estar aguardando o retorno de um valor X ao executar um método do objeto B, porém

este objeto B pode retornar um valor Y, desta forma gerando uma falha. Não faz parte

do escopo dessa fase de teste o tratamento de interfaces com outros sistemas

(integração entre sistemas). Essas interfaces são testadas na fase de teste de sistema,

apesar de, a critério do gerente de projeto, estas interfaces podem ser testadas mesmo

antes de o sistema estar plenamente construído. [Wilson de Pádua Paula Filho, 2004].

Teste de integração é o nível de testes que verifica a execução apropriada dos

componentes existentes na aplicação e não serve para impedir que a aplicação em teste

interfira com outras aplicações dentro do mesmo sistema. A comunicação entre os

módulos dentro do subsistema é testada em um ambiente controlado e isolado dentro

do projeto. [Pressman, 2002].

8

3.3. Teste de sistema

Na fase de teste de sistema o objetivo é executar o sistema sob ponto de vista

de seu usuário final, varrendo as funcionalidades em busca de falhas.

Neste nível, os requisitos são derivados da especificação de requisitos

funcionais e não funcionais, aplicado para verificar se o software e o hardware

executam corretamente quando integrados ao ambiente de operação, incluindo seus

componentes até a interface do sistema desenvolvido com outras aplicações.

São realizados para certificar-se de que o sistema está funcionando

corretamente tanto funcionalmente quanto operacionalmente. [Bill Hetzel, 1988].

3.4. Teste de aceitação do usuário

Fase de Teste em que o teste é conduzido por usuários finais do sistema. Os

testes são realizados, geralmente, por um grupo restrito de usuários finais do sistema.

Esses simulam operações de rotina do sistema de modo a verificar se seu

comportamento está de acordo com o solicitado.

Nos testes de aceitação do usuário, do termo em inglês “User Acceptance Tests

(UAT)” é verificado se o sistema atende os requisitos dos usuários conforme

especificado. Teste formal conduzido para determinar se um sistema satisfaz ou não

seus critérios de aceitação e para permitir ao cliente determinar se aceita ou não o

sistema. [Bill Hetzel, 1988].

O UAT simula o ambiente do usuário e enfatiza os testes funcionais, de

segurança, de desempenho e de regressão que demonstrarão se o sistema funciona

conforme o esperado pelo cliente e o usuário final, para que eles possam aceitar o

sistema.

9

4. Tipos de testes

4.1. Testes funcionais

Dentro desta técnica de teste que busca analisar as funcionalidades dos

cenários conforme especificação, validando as regras de negócio, serão apresentados a

seguir seus principais tipos de testes.

Na técnica de testes funcional, além dos cenários básicos, são também

verificadas contingências de acordo com os cenários de exceção. Este tipo de teste é

normalmente utilizado em todos os projetos, já que objetiva a correta implementação

das regras de negócio do produto.

Segundo Ian Sommerville (2003), os testes funcionais têm como principal

objetivo garantir que os requisitos funcionais do usuário e as especificações do projeto

foram devidamente implementados.

Condições de testes são geradas para avaliar a exatidão do que foi solicitado

com o que foi desenvolvido.

4.1.1. Teste de usabilidade

Simula as condições de utilização do software sob a perspectiva do usuário

final, focando, por exemplo, na facilidade de navegação entre as janelas da aplicação,

clareza dos textos e mensagens que são apresentadas ao usuário. Ao contrário de

outros tipos de teste, não existe uma lista de itens pré-determinados a serem conferidos

numa verificação padrão de usabilidade, pois cada cliente precisa ser avaliado de

forma independente através de bom senso, experiência técnica e conhecimento de

usabilidade (requerendo testadores especialistas). Contudo, estes testes tipicamente

geram melhorias importantes na interface, tornando o aplicativo mais amigável e

intuitivo, gerando maior satisfação do usuário final. [Wilson de Pádua Paula Filho,

2004].

Portanto, o teste de usabilidade garante que a interface entre o sistema e as

pessoas que trabalharão nele seja utilizável e aceitável.

10

Considerando que o teste funcional visa à garantia de precisão do sistema testado, este

tipo de teste procura por simplicidade e facilidade do usuário final na utilização do

software desenvolvido. Normalmente são executados durante os testes de aceitação do

usuário.

Os objetivos deste teste são garantir que o sistema seja fácil de operar de um

ponto de vista do usuário e do provedor de serviços, e que as funcionalidades sigam

um caminho intuitivo.

4.1.2. Teste de interface

O objetivo do teste de interface é analisar a interface da aplicação testada,

compreendendo navegação entre as janelas, preenchimento de campos, etc. São

levadas em consideração contingências na interface, através da inserção de valores

inválidos e tentativa de utilização inesperada das janelas. Este tipo de teste é

tipicamente realizado em conjunto com teste funcional, buscando garantir a correta

implementação das janelas, campos e textos. [Wilson de Pádua Paula Filho, 2004].

4.1.3. Teste de regressão

O Teste de Regressão é uma fase do Teste de Software que consiste na

aplicação de testes à versão mais recente do software, para garantir que não surgiram

novos defeitos em componentes já testados.

É o tipo de teste normalmente aplicado durante a fase de manutenção do

software. Nele é verificado se não foi feito nenhum tipo de modificação indesejada

durante alguma fase de desenvolvimento em parte do sistema durante o processo de

desenvolvimento do software. [Bill Hetzel, 1988].

Para realizar um teste de regressão, o aplicativo deve ser executado através do

mesmo cenário de teste, pelo menos, duas vezes. O primeiro teste é executado quando

o seu sistema ou uma parte específica dele está funcionando corretamente. O segundo

teste é executado depois de terem sido feitas eventuais modificações no software e

então, serão comparados os resultados obtidos antes e depois das modificações para

garantir o funcionamento correto do sistema conforme especificado.

11

O resultado da comparação pode ser utilizado para documentar e analisar as

diferenças encontradas. Analisando as diferenças entre as duas execuções do mesmo

caso de teste, pode-se determinar se houve alguma mudança inesperada no sistema.

Testes de regressão também devem ser executados pelos programadores

durante os testes de unidades, pois irão prevenir que as mudanças feitas anteriormente

no código sejam perdidas ou substituídas por alterações posteriores. Finalmente, uma

última execução de teste de regressão deve ser feita após o término do

desenvolvimento do sistema, uma vez que toda a aplicação desenvolvida estará

estabilizada e não é mais esperada nenhuma alteração.

4.2. Testes estruturais

O propósito da técnica de teste estrutural é assegurar que o sistema funciona

corretamente. Este tipo de teste foi projetado para verificar se o sistema possui uma

estrutura técnica sólida e pode executar as tarefas pretendidas com sucesso. Também

tem como objetivo garantir que a tecnologia foi utilizada corretamente e na integração

dos componentes deste sistema desenvolvido atue como uma unidade coesa. [Ian

Sommerville, 2003].

Os testes neste caso não são destinados a verificar as características funcionais do

sistema, mas sim de que o sistema está tecnicamente correto.

Dentro desta técnica de teste, serão apresentados a seguir seus principais tipos

de testes.

4.2.1. Teste de desempenho

O teste de desempenho foi concebido para testar se o sistema atende o nível

desejado de desempenho em um ambiente de produção. Verificações de desempenho

podem estar relacionadas ao tempo de resposta do aplicativo que está sendo testado,

questões de design técnico e assim por diante. Testes de desempenho são conduzidos

utilizando um ambiente de testes simulando o de produção ou um protótipo.

[Pressman, 2002].

12

Atenção a problemas de desempenho (por exemplo, tempo de resposta ou

disponibilidade) que começam ainda na fase de concepção do sistema.

A medição real do desempenho de um programa deve começar o mais rápido

possível, não necessariamente após o término de seu desenvolvimento.

4.2.2. Teste de segurança

A segurança de um sistema é necessária para garantir a proteção das

informações confidenciais em um sistema, proteção contra perda, corrupção ou má

utilização, quer seja por ações acidentais ou deliberadas. A quantidade de testes

necessários depende da avaliação do risco de conseqüências de uma falha na

segurança. Os testes devem incidir sobre os recursos de segurança desenvolvidos no

sistema limitando-se a eles, mas também podem incluir funções de segurança

aplicadas anteriormente. O importante é que o sistema seja testado exaustivamente

neste tipo de teste. [Bill Hetzel, 1988].

4.2.3. Teste de stress / volume

Teste de stress ou volume é definido como a transformação de um grande

número de transações através do sistema em um período definido de tempo. É

realizado para medir as características de desempenho do sistema sob condições de

pico de carga. Fatores de stress podem ser aplicados a diferentes aspectos do sistema,

tais como operações de entrada, comunicações, capacidade de processamento

computacional, espaço em disco, I/O e assim por diante. [Bill Hetzel, 1988].

Neste tipo de teste simulam-se condições atípicas de utilização do software,

provocando aumentos e reduções sucessivas de transações que superem os volumes

máximos previstos.

13

4.3. Relacionamento entre os níveis e tipos de testes

A Tabela 1 ilustra a relação entre os principais níveis e tipos de testes

apresentados neste trabalho. Os níveis de testes são as colunas e os tipos são as linhas

na tabela. A tabela mostra o nível em que cada tipo de teste pode ser realizado. Estas

são apenas sugestões. É óbvio que cada projeto tem características diferentes, que

devem ser considerados ao planejar o processo de testes a ser utilizado.

Tabela 1: Tabela de relacionamento entre os níveis e tipos de testes

Níveis de teste

Unidade Integração Sistema Aceitação do usuário (UAT)

Tipos de teste

Usabilidade X X Interface X X Regressão X X X X

Desempenho X Segurança X X

Stress/Volume X

Nesta tabela são apresentados os níveis onde cada tipo de teste estudado neste

trabalho pode ser realizado.

O teste de usabilidade que visa garantir a facilidade e simplicidade na

utilização do usuário final no software desenvolvido podendo ser executado no nível

de sistema e mais freqüentemente no nível de aceitação do usuário. O teste de

interface tem como principal objetivo garantir a correta implementação das janelas,

campos e textos, ele pode ser executado nos mesmos níveis do teste de usabilidade.

Já nos testes de regressão normalmente são executados na fase de manutenção

do software, mas pode fazer parte de qualquer nível de teste dentro do processo de

teste do software em desenvolvimento.

Teste de desempenho é realizado no nível do sistema e é importante ressaltar

que a medição real do desempenho de um programa deve começar neste nível, não

necessariamente após o término de seu desenvolvimento.

Nos testes de segurança é importante iniciá-los já no nível de teste de unidade e

ser concluído no nível de sistema garantindo, por exemplo, a proteção das informações

confidenciais.

14

Teste de stress ou de volume é normalmente realizado durante o nível de teste

de sistema onde poderá ser medida as características de desempenho do sistema sob

condições de pico de carga, por exemplo.

5. Processo de testes

5.1. Definição de processo de testes

De acordo com Pressman (2002), um processo de teste de software é um

conjunto de passos parcialmente ordenados constituídos por atividades, métodos e

práticas, usadas para testar um produto de software. Um processo de teste de software

possui como subprocessos o planejamento, a preparação dos testes, a execução e a

análise dos resultados.

Os subprocessos têm as seguintes características: Utilizam recursos; estão

sujeitos a um conjunto de restrições; geram artefatos (plano, preparação, casos de teste

e relatórios de execução ou resultados); podem ser definidos de uma maneira

hierárquica, organizados de tal forma que cada subprocesso tenha seu próprio modelo

de processo; são compostos de atividades; cada um possui seu critério de início e

término; e suas atividades são organizadas em uma seqüência.

5.2. Caracterização do processo de testes

Para todo e qualquer desenvolvimento de software, a aplicação do teste deve

ser realizada seguindo um processo de teste previamente caracterizado. Para

caracterizar um processo de teste é necessário especificar os seus elementos de acordo

com o processo de desenvolvimento de software adotado.

A caracterização do processo de teste de software depende da política de teste

adotada pela empresa. Uma empresa pode caracterizar um processo de teste de uma

única maneira, ser aplicado em qualquer produto de software por ela desenvolvido, ou

seja, o seu modelo de processo de teste de software é fixo.

15

Um processo de teste é composto pelo detalhamento das atividades de

planejamento, preparação, execução e o registro dos seus resultados. A figura 2 ilustra

os elementos desta caracterização.

Figura 2: Modelo básico de processo de teste.

O fluxo do processo de teste está em planejar, especificar os testes, executar e

reportar os defeitos realimentando o sistema para uma melhoria contínua do software.

Em qualquer desenvolvimento de software a aplicação do teste deve ser

realizada segundo um processo de teste previamente caracterizado. Para caracterizar

um processo de teste é necessário especificar os seus elementos segundo a visão

associada ao processo de software, composta pelos níveis de teste correspondentes às

fases do desenvolvimento, pelas técnicas e tipos de teste.

A caracterização do processo de teste é completada pelo detalhamento do plano

de testes, casos de testes, execução e registro do teste, levando em consideração os

elementos anteriormente especificados.

A caracterização do processo de teste depende da política de teste adotada pela

empresa. Uma empresa pode caracterizar um processo de teste de uma única maneira,

a ser aplicado em qualquer produto de software por ela desenvolvido, ou seja, o seu

modelo de processo de software é fixo. Uma outra empresa pode caracterizar seus

processos de teste de acordo com os vários tipos de produtos de software por ela

desenvolvidos, ou seja, o modelo de processo de software da empresa é configurável.

16

A caracterização geral de um processo de teste de software envolve a seleção

de itens inseridos em três dimensões como mostra a figura 3:

Figura 3: Caracterização do processo de teste de software

Fonte: CTI - Centro de Tecnologia da Informação Renato Archer

O processo de teste a ser aplicado num produto de software específico deve ser

caracterizado de acordo com o modelo de processo de software adotado pela

organização.

Cada modelo de processo de software define suas atividades e produtos

correspondentes, que serão utilizados para estabelecer os requisitos de teste do produto

final.

5.3. Documentação do processo de testes

Segundo Pressman (2002), o processo de teste de software consiste em quatro

etapas básicas. São elas:

• Plano de testes;

• Preparação dos testes;

• Execução dos testes;

17

• Análise dos resultados.

Plano de testes: O Plano de teste é um documento que deve conter a extensão

do teste, a abordagem utilizada no teste, os recursos necessários, o cronograma das

atividades de teste e a definição do ambiente operacional para sua execução.

O planejamento em si é um processo. Desempenhar cada passo do processo de

planejamento irá assegurar que o plano foi construído sistematicamente e por

completo.

O Plano de teste identifica os itens do software a serem testados, o nível em

que os itens devem ser testados, a abordagem utilizada para testar cada um dos itens,

as tarefas envolvidas em cada atividade de teste, as pessoas responsáveis por cada

atividade e os riscos associados ao plano.

Os casos de teste são documentos fundamentais para o Teste de Software.

Alguns autores consideram que as ações do usuário, necessárias para execução

da função a ser testada, também fazem parte do caso de teste.

Preparação dos testes: Nesta etapa, devem ser especificadas todas as entradas,

saídas e atributos requeridos para a execução de cada caso de teste.

Identificar os casos de teste que devem ser executados antes de cada caso de

teste. Resumir a natureza dessas dependências.

Definir as características e as configurações de hardware e software requeridos

para executar os casos de testes.

Criar todos os passos para a execução do caso de teste e para cada um deles

descrever o resultado esperado para aquela ação.

Execução dos testes: A execução do teste corresponde à realização dos passos

de um caso de teste. É uma seqüência manual ou automatizada de passos necessários

para a realização de uma tarefa.

Na execução do teste, devem ser registrados (documentados) os resultados da

execução, as falhas detectadas, e quaisquer outros eventos pertinentes ao teste,

utilizando os métodos ou formatos previamente definidos na documentação. Após o

registro de todos os passos descritos no caso de teste a execução pode ser finalizada.

Os resultados da execução do teste incluem as concordâncias e discordâncias

entre as saídas esperadas e saídas obtidas, bem como eventuais incidentes observados.

Análise dos resultados: Nesta etapa final, avaliam-se cada item do teste,

incluindo suas limitações e restrições, baseando-se nos resultados do teste e nos

critérios de aprovação/reprovação.

18

Caso ocorra a aprovação do caso de teste ele é finalizado com sucesso e todas

as suas evidências são armazenadas para futuras conferências. Se durante a análise dos

resultados for constatado algum problema, o caso de teste falha, o defeito encontrado é

registrado com a devida prioridade pelo analista de testes e a equipe de

desenvolvimento responsável pela correção do defeito é acionada para trabalhar no

reparo.

A caracterização da documentação do processo de teste de software pode ser

melhor compreendida pelo fluxograma (Figura 4):

Figura 4: Fluxograma da documentação do processo de teste de software

Por uma visão mais simplificada podemos apresentar a documentação utilizada

em um processo de teste conforme mostra a Figura 5:

19

Figura 5: Visão simplificada da documentação do processo de teste de software

5.4. Os sete passos de um processo de teste de software

De acordo com William E. Perry (2006) um processo de testes é dividido em

sete etapas conforme apresenta a figura 6:

20

Figura 6: Os sete passos de um processo de teste de software

Fonte: Effective Methods for Software Testing, Third Edition, William E. Perry 2006

Traduzido por Wilson Rafael Rovere.

De uma forma geral, William E. Perry (2006) descreve os objetivos de cada um

destes sete passos da seguinte maneira:

Preparação para os testes. Este passo possui dois objetivos. O primeiro

objetivo consiste em definir o que será testado para garantir que o software atende as

necessidades do cliente. O segundo consiste em determinar, com base no tipo de teste

a ser realizado, as tarefas que cada membro da equipe trabalhará.

Desenvolvimento do plano de testes. A criação do plano de testes deve

seguir o mesmo padrão de qualquer processo de planejamento de software. A estrutura

de todos os planos devem ser as mesmas, mas o conteúdo irá variar de acordo com a

análise de riscos dos testes a serem realizados no software em desenvolvimento. O

plano de testes determinará como os testes serão realizados. Por exemplo, em um

21

sistema de folha de pagamentos, um objetivo de teste poderia ser testar o cálculo dos

impostos sobre a folha de pagamento. Este tipo de infomação que será utilizada para

desenvolver o plano de teste detalhado.

Teste de verificação. "Estamos construindo certo o produto?". O teste de

verificação visa garantir que as funcionalidades especificadas e definidas nos

requisitos estão sendo implementadas no software.

Teste de validação. "Estamos construindo o produto certo?". O teste de

validação garante que o software que foi construído atende os requisitos do cliente.

Análise dos resultados. O objetivo desta etapa é determinar o que foi

detectado a partir dos testes realizados e, em seguida, informar a equipe de

desenvolvimento. Isso pode incluir o que funciona, o que não funciona, assim como

qualquer sugestão que a equipe de testes possa fazer aos desenvolvedores do software.

Teste de aceitação do usuário. O objetivo desse nível de teste é determinar

se é possível para o usuário final utilizar o sistema agora, e que, enquanto o sistema é

alterado ao longo do tempo, ainda é eficaz e eficiente. Os testes de aceitação do

usuário devem ser realizados antes do software entrar na fase de produção ou quando

for desenvolvida alguma alteração no sistema.

Análise pós-implementação. O objetivo desta etapa é uma perspectiva de

futuro. Ela tenta determinar se os testes foram realizados de forma eficaz, e se não, que

mudanças poderiam ser feitas para testar o processo de testes, para que os futuros

testes sejam mais eficazes e eficientes. É importante ressaltar que isto pode ser feito

individualmente ou em grupo, dento da equipe de testes ou de desenvolvimento, como

a garantia da qualidade pessoal.

22

6. Estudo de caso

Este estudo de caso apresenta o processo de testes de software de uma empresa com

certificação CMMI nível 5 durante o ciclo de vida de um projeto.

É importante ressaltar que este trabalho não tem como objetivo a apresentação das

ferramentas utilizadas para o armazenamento, reporte de execução e defeitos nos testes

realizados, mas sim apresentar todo o processo de testes que é utilizado, tanto em testes

manuais como em testes automatizados.

A apresentação deste processo de testes inicia-se com a descrição dos profissionais

envolvidos e suas respectivas funções dentro do processo de testes.

Basicamente, a equipe de testes é composta pelos seguintes profissionais:

1. Líder de testes – Suas principais funções são:

• Representar a equipe de testes na revisão dos requisitos do projeto

juntamente com o líder da equipe de desenvolvimento, arquiteto e o gerente

de projeto para obter informações e calcular os esforços que serão

necessários para a equipe de testes no que diz respeito a quantidade de

testes e analistas para cada funcionalidade do sistema;

• Analisar a necessidade de novos hardwares e softwares para execução dos

testes e caso exista necessidade comunicar o gerente de projeto;

• Configurar o ambiente de testes com o apoio da equipe de

desenvolvimento;

• Elaborar um plano de testes com todas as funcionalidades que serão

testadas e o número necessário de profissionais (Analistas de testes) para

criação e execução dos testes;

• Divisão de tarefas para cada membro da equipe;

• Comunicar toda e qualquer informação necessária para a equipe de testes;

• Participar de reuniões e enviar o status dos testes para o gerente de projeto;

• Revisar os casos de testes para garantir que cumprem todos os requisitos do

sistema proposto;

• Atualizar o plano de testes se houver algum tipo de mudança nesta fase

inicial dos testes;

23

• Após finalização de escrita do plano e dos casos de testes, o líder de testes

deve aprová-los ou rejeitá-los.

2. Analistas de testes – Suas principais funções são:

• Completar a análise dos requisitos, individualmente, de acordo com a

divisão feita pelo líder da equipe;

• Auxiliar o líder da equipe na configuração do ambiente de testes de acordo

com as necessidades;

• Projetar os casos de testes detalhados para garantir que os requisitos foram

devidamente implementados e as funcionalidades do sistema funcionam

conforme as necessidades do cliente (entenda-se como cliente empresas,

consultorias e/ou parceiros de negócios.);

• Executar os casos de testes nos diferentes cenários representados em cada

caso de teste e armazenar as evidências do comportamento do sistema ou

funcionalidade que está sendo testada;

• Reportar os defeitos quando encontrados para que a equipe de

desenvolvimento possa resolver o problema.

O processo de testes deste estudo de caso está representado no fluxograma (Figura 7):

24

Revisão e

Atualização

plano e casos

Aprovação do

plano e casos

de testes

Participação

na revisão dos

requisitos

Não

Requisitos

aprovados?

Preparação dos

casos de testes

Sim

Aquisição de

Hardware e

Software

Configuração

do ambiente de

testes

Ambiente de

testes pronto?

Preparação do

plano de testes

Sim

Não

Aprovado?

Execução dos casos de testes

Registro do

defeito

encontrado

Sim

Não

Casos de testes

executados

com sucesso?

Sim

Não

+

FIM

Cliente

Líder

de Testes

Analista

de Testes

Solicitação dos

serviços de testes

Figura 7: Processo de teste de software de uma empresa com certificação CMMI nível 5

25

Descrição das atividades do processo de testes de software:

1. O cliente solicita o serviço de testes para um determinado projeto;

2. De acordo com as especificações de cada projeto pode ou não ser necessário a

aquisição de novos hardwares e/ou softwares para o ambiente de testes do

projeto;

3. Preparar e configurar o ambiente de testes, incluindo a instalação e

configuração do software e depois de finalizado, executar os casos de testes

aprovados nas fases de revisão e aprovação.

Caso não sejam cumpridos todos os requisitos, é preciso solicitar ao gerente de

projeto a configuração de hardware e/ou software necessário para a execução dos

testes;

4. O líder de testes participa da revisão dos requisitos solicitados pelo cliente.

Se os requisitos forem aceitos, logo em seguida ele elabora o plano de testes

que descreve o escopo dos testes, prazos, atividades, recursos necessários, etc.

Caso contrário será discutido mudanças necessárias durante a revisão dos

requisitos;

5. O analista de testes elaborara os casos de testes de acordo com as definições do

plano de testes;

6. O líder de testes revisa e atualiza conforme necessário o plano e os casos de

testes. Revisores opcionais são requisitados para garantir a qualidade do plano

e dos casos de testes, normalmente um desenvolvedor responsável pela

funcionalidade a ser testada ou o arquiteto do projeto;

7. Obter aprovação das partes identificadas no processo de testes. Caso a

aprovação seja negada, serão feitas as alterações necessárias e, em seguida,

tentar obter a aprovação novamente;

8. O analista de testes deve executar os casos de testes aprovados de acordo com

o plano de testes aprovado após o processo de revisão;

9. Para os casos de testes executados com sucesso, o analista de testes deve

armazenar todas as evidências obtidas no teste e registrar em uma base de

dados conforme especificações de cada projeto.

Caso o teste executado tenha encontrado algum defeito/falha, o analista de

testes analisa e registra o defeito encontrado usando a ferramenta de

monitoramento de defeitos específica do projeto e através desta ferramenta ele

26

pode priorizar e acompanhar o trabalho da equipe de desenvolvimento na

correção do problema.

10. Após o término de todas as etapas previamente citadas, inicia-se a escrita do

relatório final dos testes executados com o resumo dos defeitos encontrados

apresentados através de métricas e gráficos para o gerente de projeto,

finalizando assim todo o processo de testes.

Estrutura de um plano de testes:

O documento do plano de testes segue um modelo básico com as seguintes

características:

1. Cabeçalho onde contém o nome do líder de testes responsável, o nome do

projeto, descrição dos requisitos utilizados para a elaboração do plano de

testes, os níveis e tipos de testes que serão realizados e um espaço adicional

para maiores detalhes do objetivo dos testes.

2. Lista dos casos de testes que deverão ser escritos onde constam os nomes, em

quantas plataformas/sistemas operacionais os testes serão realizados,

pontuação de cada caso de testes (mede a importância do caso de testes, quanto

maior o número de pontos, maior o impacto do teste, normalmente um caso de

testes comum possui 10 pontos.)

3. Nome e versão da documentação (requisitos) do projeto utilizada para a

criação do plano de testes.

4. Comentários ou suposições relacionadas aos testes.

5. Tabela com as respostas de algumas perguntas básicas para a construção de um

plano de testes de uma empresa com certificação CMMI nível 5. Ao responder

as questões o analista de testes é capaz de obter todo o tipo de informação

necessária para os testes que serão realizados no projeto.

O anexo A mostra este modelo de documentação de plano de testes utilizado

em projetos dentro de uma empresa com certificação CMMI nível 5.

27

Estrutura de um caso de teste:

Um caso de testes deve conter as seguintes informações:

1 Um cabeçalho com o nome do caso de teste, nome do projeto, nome do

analista de testes responsável, data da última atualização do documento, peso

dos testes (medição da importância dos testes que serão aplicados. Quanto

maior o número de pontos, maior o impacto do teste, normalmente um caso de

testes comum possui 10 pontos.) e nome da documentação utilizada para a

elaboração do caso de testes.

2 Uma tabela com informações das atualizações feitas no documento para o

controle da equipe com versão, data da modificação, breve descrição do

motivo da atualização e o nome do analista de testes responsável pelas

mudanças.

3 Os objetivos gerais do teste, com uma breve descrição da funcionalidade a ser

testada ou sobre o projeto.

4 O objetivo detalhado do teste explicando em no máximo dois parágrafos a

maneira pela qual os testes serão executados no passo a passo (item 6 abaixo).

5 A configuração necessária para a execução deste caso de teste, com

informações de documentos que podem ser úteis para um melhor

entendimento do analista de testes que executará este caso de teste.

6 Passo a passo detalhado do caso de teste com a descrição de cada passo e um

espaço dedicado ao que é esperado em cada uma dessas etapas.

O anexo B mostra este modelo de documentação de caso de teste

utilizado neste processo de teste.

Pontuação e classificação dos defeitos:

Para um melhor entendimento do processo de pontuação após a execução

dos casos de testes na ferramenta específica de testes utilizada neste projeto,

devemos ter conhecimento de dois conceitos relacionados a defeitos de softwares,

são eles: severidade e prioridade.

A severidade de um defeito define o impacto do defeito no funcionamento

do software. Por outro lado, a prioridade indica a ordem de correção do defeito

28

(defeitos com alta prioridade são corrigidos imediatamente ou num curto prazo de

tempo). De modo geral, defeitos com alta severidade são classificados com alta

prioridade.

Estas pontuações variam de acordo com a severidade e prioridade do

defeito encontrado para um determinado caso de teste.

Serão apresentados na Tabela 2 e Tabela 3 exemplos de critérios para

classificar a severidade e a prioridade dos defeitos respectivamente.

Tabela 2: Classificação da severidade

Severidade Descrição

Alta Bloqueia completamente a utilização de

uma funcionalidade básica ou do software

inteiro.

Média Bloqueia a utilização de uma

funcionalidade.

Baixa Problemas cosméticos e solicitações de

melhorias

Tabela 3: Classificação da prioridade

Prioridade Descrição

1 O defeito deve ser corrigido imediatamente

(até um dia útil). O software não pode ser

liberado sem a correção deste defeito.

2 É altamente desejável que o defeito seja

corrigido tão logo seja possível (até cinco

dias úteis). O software não pode ser

liberado sem a correção deste defeito.

3 Defeito de baixa prioridade. O software

pode ser liberado sem a correção deste

defeito.

29

Caso o defeito encontrado seja classificado como severidade/prioridade 1, são

registrados apenas 3 dos 10 pontos do caso de teste na ferramenta. Se for

severidade/prioridade 2 registra-se para o respectivo caso de teste 6 pontos dos 10 e quando é

encontrado um defeito de severidade/prioridade 3 são registrados 9 pontos dos 10 totais do

caso de teste.

A seguir será apresentado o plano de testes e duas amostras de como foram elaborados

os casos de testes para o projeto AFI (Ameriprise Financial Inc. – Antigo American Express)

na fase denominada de RFS (Report File System) 100875 que teve duração de

aproximadamente seis meses (Jun/2008 à Nov/2008) dentro da IBM (International Business

Machines), no qual fui membro da equipe de testes e no decorrer dos trabalhos desenvolvidos

obtiveram-se métricas dos resultados alcançados com a utilização do processo de testes

estudado neste trabalho.

O projeto AFI RFS 100875 tem como objetivo a realização de testes de shell scripts que

são executados no sistema para a geração de relatórios específicos do projeto para cada script

desenvolvido.

Basicamente, shell scrips são conjuntos de comandos armazenados em um arquivo texto

que são executados seqüencialmente.

Durante este projeto, foram realizados testes nos níveis de unidade e sistema, utilizando

técnicas funcionais aplicando-se alguns dos tipos de testes estudados, como, teste de

usabilidade, interface e regressão.

O plano de testes desenvolvido neste projeto pode ser visto em detalhes no anexo C.

Um caso de teste no nível de unidade que pode ser classificado como teste de usabilidade

e de regressão pode ser visualizado em detalhes no anexo D desta monografia.

Outro caso de teste desenvolvido e executado neste projeto no nível de sistema do tipo

interface e que também deve ser classificado como de regressão é mostrado em detalhes no

anexo E.

Os casos de testes apresentados necessitam de alguns conhecimentos técnicos adicionais,

como o de interpretação do funcionamento de shell scripts para um melhor entendimento do

que foi testado neste estudo de caso dentro do sistema proposto.

Por fim, conclui-se este estudo de caso com a apresentação das métricas alcançadas na

finalização do projeto, utilizando este processo de testes de software.

30

Na figura 8, é apresentado o número total de casos de testes projetados e executados no

projeto AFI RFS 100875 com o total de casos de testes realizados com sucesso e os

respectivos prazos estabelecidos para a fase de testes do projeto.

Figura 8: Número total de casos de testes

Fonte: AFI RFS-100875 Project

A figura 9 mostra o resultado final após a finalização dos testes, dos defeitos

encontrados pela equipe de testes do projeto AFI RFS 100875. Nesta figura, temos o número

total de defeitos cancelados (Canceled) e/ou rejeitados (Deferred) pela validação dos

responsáveis do projeto (Líder da equipe de desenvolvimento, desenvolvedor responsável

pela funcionalidade em testes ou arquiteto do projeto) com suas respectivas percentagens com

relação ao total de defeitos encontrados durante a fase de testes.

O total de defeitos detectados, aceitos e corrigidos neste projeto foram 25, os quais

estão denominados como “Closed” no gráfico.

Figura 9: Status final de defeitos abertos/fechados/cancelados


31

O próximo gráfico gerado para reportar os resultados finais das execuções dos testes

do projeto AFI RFS 100875 (Figura 10) mostra no eixo Y a pontuação total da soma dos casos

de testes onde cada um possui 10 pontos, foram projetados 47 casos de testes para esta fase,

portanto um total de 470 pontos. No eixo X estão os dias das duas semanas que foram

destinadas para a execução dos testes deste projeto.

A pontuação é utilizada pelo líder de testes para mensurar através de métricas

(quantidade de erros encontrados, quantidade de erros críticos, quantidade de re-testes

realizados, entre muitas outras) como estão as atividades de testes do projeto para reporte

semanal ao gerente de projetos.

A linha azul representa os casos de testes que foram executados, tanto casos de testes

ainda não completados, ou seja, os que foram detectados defeitos, quanto os casos de testes

executados com sucesso (completos).

A linha vermelha mostra somente o número de casos de testes executados com

sucesso. Esta linha vermelha representa todos os casos de testes já registrados como

completos com suas respectivas evidências documentadas.

A linha preta mostra o plano de execuções previamente definido para as execuções

dos casos de testes do projeto, em outras palavras, o mínimo de execuções por dia que deve

ser realizada pela equipe de testes.

32

AFI RFS-100875

050

100150200250300350400450500

19-O

ct-08

21-O

ct-08

23-O

ct-08

25-O

ct-08

27-O

ct-08

29-O

ct-08

31-O

ct-08

2-Nov

-08

Projected Complete Actual Attempted Actual Complete

Figura 10: Status final das execuções dos testes


De acordo com as informações do gráfico anterior (Figura 10) é possível gerar um

gráfico da percentagem acima/abaixo do planejado (Figura 11).

A curva final da execução dos testes deste projeto pode ser visualizada na linha

vermelha e as zonas em destaque no gráfico (verde, amarela e vermelha) indicam se os

objetivos e prazos previamente estipulados foram devidamente alcançados no decorrer das

duas semanas de execuções dos testes.

33

Figura 11: Percentagem acima/abaixo do planejado


É importante ressaltar que estes gráficos mostram os resultados obtidos na finalização

do projeto, todos eles são atualizados e reportados semanalmente desde o início das atividades

para o gerente de projeto durante a criação e/ou execução dos casos de testes para o

acompanhamento do processo de testes aplicado.

AFI RFS-100875Percent over/under plan

-60%-50%-40%-30%-20%-10%

0%10%20%30%40%50%60%70%80%90%

100%110%120%

10/20

/08

10/22

/08

10/24

/08

10/26

/08

10/28

/08

10/30

/08

Actual Attempted Actual Complete

34

7 Conclusão

De acordo com a realização deste trabalho o processo de teste de software deve ser

tratado como mais um processo de software integrado ao desenvolvimento do software desde o

início para proporcionar redução de custos e melhora na produtividade.

Todo processo de teste de software tem que estar bem definido e caracterizado com

níveis, técnicas e tipos de testes para que possa contribuir com a qualidade do produto final.

A garantia da qualidade do produto de software está diretamente relacionada, entre

outros fatores, com a qualidade do processo de testes ao qual o mesmo foi submetido. Um

processo de teste pode ser entendido como um processo utilizado para revelar defeitos em

softwares e para estabelecer se os mesmos alcançam um determinado nível de qualidade

referente aos requisitos selecionados para o seu desenvolvimento.

O processo de teste é um componente vital em um processo de qualidade de software e

é uma das atividades mais desafiadoras e custosas cumpridas durante o desenvolvimento e

manutenção de um produto de software. Como todo processo envolvido na criação de software,

o processo de teste deve ser gerenciado. Isto quer dizer que uma política organizacional deve

ser definida e documentada. Plano e casos de teste devem ser bem definidos e documentados. O

processo de teste deve estar associado a objetivos quantificáveis que possam ser mensurados e

monitorados, devendo ser capaz de evoluir a um nível onde haja mecanismos que o levem a

promover melhorias contínuas. Estas melhorias no processo de teste, por sua vez, estão

diretamente relacionadas com a qualidade do software à medida que garantem a satisfação e

confiança do cliente, ao lhe entregar um produto dentro do prazo e orçamento acordados e com

a segurança de que o mesmo atende às suas exigências.

7.1 Contribuições

Resumidamente, as principais contribuições deste trabalho foram: Uma visão

sobre processo de teste de software baseado no nível de maturidade CMMI

(Capability Maturity Model Integration) nível 5, certificado que confere à empresa

um padrão de qualidade internacional de nível máximo na engenharia de software.

Conhecer os diferentes níveis, técnicas e tipos de testes de software para que o

analista de testes possa saber exatamente o que será testado.

35

Entender toda a teoria envolvida no processo de teste de software estudado de

forma prática em um estudo de caso onde são projetados e documentados o plano

de teste, casos de testes e métricas dos resultados alcançados na utilização deste

processo de teste de software.

7.2 Trabalhos futuros

Ao longo do estudo e desenvolvimento deste trabalho constatou-se que dentro

de um processo de teste de software apresentam-se uma série de técnicas de testes

que podem ser estudadas em profundidade, pode-se também fazer comparações do

processo de testes de software estudado neste trabalho utilizado em uma empresa

com certificação CMMI nível 5 com outros processos que podem ser encontrados

em empresas com certificações inferiores e/ou sem certificação.

Portanto ficam como indicações de trabalhos futuros:

FERRAMENTAS E TÉCNICAS DE TESTE DE SOFTWARE –

Apresentar as ferramentas disponíveis para a realização dos testes de softwares

disponíveis no mercado de TI para testes manuais ou automatizados aplicadas

nas diferentes técnicas e tipos conforme estudadas neste trabalho. Elaborar um

estudo de caso com as métricas (quantidade de erros encontrados no cliente,

quantidade de erros críticos, quantidade de re-testes realizados, entre muitas

outras).

PROCESSOS DE TESTE DE SOFTWARE COM E SEM

CERTIFICAÇÃO CMMI – Demonstrar de forma comparativa as diferenças

existentes em um processo de teste de software que segue os padrões CMMI e

de um processo que ainda não possui nenhum tipo de certificação. Elaborar um

estudo de caso onde mostra as vantagens e desvantagens de cada um.

PROCESSO DE TESTE DO MÉTODO PRAXIS – Estudar as técnicas e os

tipos de testes empregados neste método e apresentar um estudo de caso com

as vantagens e desvantagens de utilização deste método.

CMMI E PROCESSO DE TESTE DE SOFTWARE – Descrever um processo

de teste de software, utilizando práticas de nível 3 ou 4 do modelo de qualidade de

software. Definir e mostrar a importância da utilização de um modelo único para

o processo de melhoria corporativo, integrando diferentes modelos e

disciplinas (CMMI).

36

8 Referências bibliográficas

The Art of Software Testing, Myers G. J., Addison-Wesley, New York, 1979.

The Complete Guide to Software Testing – Second Edition, Bill Hetzel, John Wiley & Sons,

QED Information Sciences, Inc., Massachusetts, 1988.

Engenharia de Software, Roger S. Pressman. Makron Books, São Paulo, 2002.

Engenharia de Software, Ian Sommerville. Pearson/Addison Wesley, São Paulo, 2003.

Engenharia de Software: Fundamentos, Métodos e Padrões, Wilson de Pádua Paula Filho.

LTC – Livros Técnicos e Científicos Editora S.A., Rio de Janeiro, RJ, 2004.

Engenharia de Software: Teoria e Prática, Shari Lawrence Pfleeger. Makron Books, 2004 .

Effective Methods for Software Testing, Third Edition, William E. Perry, Copyright Wiley

Publishing, Inc. 2006.

Software Engineering Institute, CMMI - Capability Maturity Model Integration version 1.1

Pittsburgh, PA. Software Engineering Institute, Carnegie Mellon University. USA, 2001.

Módulo I – Fundamentos de teste de software, Adalberto Nobiato Crespo. CTI - Divisão de

Melhoria de Processos de Software - DMPS.

37

9 Anexos

Anexo A

Modelo de documentação de plano de testes.

Test Cases Planning Template

Analyst Name: <Analyst Name>

Product Name/ Release: <Product & Release>

Requirement(s)/Description(s):

Defect(s)/ Description(s): N/A if not applicable to this form

Use Cases(s): N/A if not applicable to this form

Testing Strategy for Requirement(s)/Defect(s):

Testing Approach: Positive, Negative, Black Box,

White Box, Usability, Integration

Test Component: For ex.: Create Ticket

Functional area: Main functional area for

requirement

<Additional space provided for tester to detail strategy for requirement>

Test Case Listing for Requirement(s)/Defect(s)/Use Case(s):

Test Case Name To be executed

against how many

platforms?

Points Per TC Total Points

Identify the Design Documentation used for test case mapping to design

documentation. The change history associated with the design documentation

should indicate which changes within the design document are related to specific

changes (requirements/defect fixes):

Document Title Version Level Date

38

List your assumptions if any for this testing:

# Assumption

Other Test Case Info:

Does the application being tested interface with

other components of the same product or with

other products? If so, are the other components

/ products being tested?

Does the change create or modify an item

(example - ticket) that another product should

be able to use? If so will the other product be

tested?

Does testing of this change (Req/defect fix)

require any other baselined changes to be

implemented before this change can/should be

tested? If so list the changes?

Will testing require multiple instances of

applications to be active concurrently (ex:

multiple servers in a client/server environment;

multiple web servers; etc.)?

Will this change be tested in the environment

defined in the Test Plan? If not, what are the

reasons for testing in unplanned environments

or for not fully testing the planned

environments?

Are these test Cases being used to validate any

Corporate Compliance? If yes, specify specific

instruction(s), and explain.

39

Anexo B

Modelo de documentação de caso de teste.

1.1 Test Case Statistics Test Case Name (with File Type) <<Test Case Name>.doc>

Product Name and Release <Product and Release>

Last date document was updated <15/12/2008 11:50:00>

Original Test Case Author <Author>

Weight (if Applicable) <10>

Design Document <Document name, including version and date,

plus referenced section and page number>

1.2 Summary of Changes Version

Number

Date of

Change Nature of Change Changed by

0.1 mm/dd/yyyy Initial

Requirement/Defect/Description

Test Owner

Name

1.3 Objective <Brief, one sentence synopsis of what this test case intends to cover>

1.4 Objective Details <Detailed paragraph or two explaining the manner in which the stated objective is carried out in

the steps.>

1.5 Test Configuration

1.5.1 Setup or predecessor test case: <List test cases that are needed for setup for this test or any other special setup needs for this test.>

1.5.2 Associated Test Specifications: <If you have grouped more than one test case to test a function place those here in the order by

which they need to be executed.>

1.5.3 Additional configuration items: <List any configuration items which are necessary to execute this test case.>

40

1.5.4 Reference documentation: <List any documentation that may be helpful to the tester executing this test case.>

1.6 Detailed Test Script (Including Expected Results)

Step # Description Expected Results

1. Brief description of test step.

Best Practice Suggestions:

1) Use Bold to highlight the object of the activity and the action.

For example: Select the User and Click the Ok button.

2) Use brackets to suggest the recommended selection if it is one of many. For example:

Login with a user not in the COORD group (ROAM)

Expected result, if any (use N/A if there are no specific expected results being analyzed for this test step).

2.

3.

4.

5.

6.

7.

8.

9.

10.

41

Anexo C

Plano de testes desenvolvido no projeto AFI RFS 100875.

Test Cases Planning for AFI RFS - 100875

Analyst Name: Tan H. Nguyen

Product Name/ Release: AFI RFS - 100875

Requirement(s)/Description(s):

Defect(s)/ Description(s): N/A

Use Cases(s): N/A

Testing Strategy for Requirement(s)/Defect(s):

Testing Approach: Positive, Negative, Usability,

Interface

Test Component: Business rules (shell scripts)

Functional area: Functional Verification Test (FVT),

System Verification Test (SVT) and

Regression Verification Test (RVT)

The objective of Functional Verification Test (FVT) is to test the function in AFI RFS - 100875

and detect defects. Its goal is to ensure that the code functions correctly as defined in

technical requirements, functional designs and defects. It exercises the external interfaces,

functions, internal interfaces, and error handling capabilities for the component(s).

System Verification Test (SVT) is a dynamic level of testing in which all the components that

comprise a system are tested to verify that the system functions together as a whole. SVT

test cases/scenarios are developed in cooperation with the user to mimic both their day to

day activities and their work environment. Entire AFI RFS - 100875 solution will have all

components tested.

Regression Verification Test (RVT) is the process of testing software to make sure that new

function and defect fixes have not broken the functions from the prior release. After System

Test is complete, but before a new release of software is made available, regression test

cases are run against the new release to ensure that all the original capabilities still work.

Regression testing may also be run earlier in a project to verify latent function or that no

collateral defects has been created, but this does not remove the need to run a final

regression test suite at the end of the project. Successful completion of the regression test

bucket gives a level of confidence that the new release has not “regressed” the quality level

of the previous release’s capabilities.

These test cases will be responsible for verifying correct functionality of AFI RFS - 100875

solution according to designed and subsequent design documents.

42

Test Case Listing for Requirement(s)/Defect(s)/Use Case(s):

Test Case Name To be executed

against how many

platforms?

Points Per TC Total Points

TC_AFI_RFS_M_P_ScheduledTasks 1 10 10

TC_AFI_RFS_M_P_FlagFiles 1 10 10

TC_AFI_RFS_M_N_makeLparsFlagFile 1 10 10

TC_AFI_RFS_M_N_makeAppsFlagFile 1 10 10

TC_AFI_RFS_M_N_makeMap2AppFlagF

ile

1 10 10

TC_AFI_RFS_M_N_pollEndpointsFlagFil

e

1 10 10

TC_AFI_RFS_M_N_convertAAType4Fla

gFile

1 10 10

TC_AFI_RFS_M_P_queryVCDBsFlagFile 1 10 10

TC_AFI_RFS_M_N_LookupAndStoreNor

mFactorsFlagFile

1 10 10

TC_AFI_RFS_M_N_processAllUnproces

sdUsageFilesFlagFile

1 10 10

TC_AFI_RFS_M_N_processEndpointCo

untsFlagFile

1 10 10

TC_AFI_RFS_M_N_loadVmCalibrations

FlagFile

1 10 10

TC_AFI_RFS_M_N_doVmCorrectionsFla

gFile

1 10 10

TC_AFI_RFS_M_N_flagRateCodesFlagF

ile

1 10 10

TC_AFI_RFS_M_N_aggregateFlagFile 1 10 10

TC_AFI_RFS_M_N_runSpreadingFlagFil

e

1 10 10

TC_AFI_RFS_M_P_makeMap2App_Ded

icatedEP1

1 10 10

TC_AFI_RFS_M_P_makeMap2App_Mep

TypeCodeField

1 10 10

TC_AFI_RFS_M_N_makeMap2App_Inv

alidConfigFiles

1 10 10

TC_AFI_RFS_M_N_makeMap2App_Inv

alidMMFile

1 10 10

TC_AFI_RFS_M_N_makeMap2App_No

MMFile

1 10 10

TC_AFI_RFS_M_N_makeMap2App_No 1 10 10

43

ConfigFiles

TC_AFI_RFS_M_P_DoVmCorrections_N

eedVirtCalc2

1 10 10

TC_AFI_RFS_N_P_DoVmCorrections_I

nvalidLparFile

1 10 10

TC_AFI_RFS_M_N_FlagRateCodes_NoP

ropertiesFile

1 10 10

TC_AFI_RFS_M_N_FlagRateCodes_Inv

alidPropertiesFile

1 10 10

TC_AFI_RFS_M_N_Aggregate_NoTabFi

le

1 10 10

TC_AFI_RFS_M_P_TransferReports 1 10 10

TC_AFI_RFS_M_N_TransferReports_No

tAll5Reports

1 10 10

TC_AFI_RFS_M_N_TransferReports_No

Reports

1 10 10

TC_AFI_RFS_M_P_MeterArchive 1 10 10

TC_AFI_RFS_M_N_MeterArchive_NoPr

opertiesFile

1 10 10

TC_AFI_RFS_M_N_MeterArchive_Invali

dPropertiesFile

1 10 10

TC_AFI_RFS_M_N_PreLoadRateCodes_

InvalidCsvFiles

1 10 10

TC_AFI_RFS_M_P_AppsMMFile 1 10 10

TC_AFI_RFS_M_P_Map2AppMMFile 1 10 10

TC_AFI_RFS_M_E2E_P_AdderCounts 1 30 30

TC_AFI_RFS_M_E2E_P_AppSubtypes 1 30 30

TC_AFI_RFS_M_E2E_P_B = PC = CB +

EX

1 30 30

TC_AFI_RFS_M_E2E_P_BillingAndPreC

hargebackReports

1 30 30

TC_AFI_RFS_M_E2E_P_ChargebackRe

port

1 30 30

TC_AFI_RFS_M_E2E_P_CMIxReports 1 30 30

TC_AFI_RFS_M_E2E_P_EndpointTypes 1 30 30

TC_AFI_RFS_M_E2E_P_ExcludeReport 1 30 30

TC_AFI_RFS_M_E2E_P_LPARCounts 1 30 30

TC_AFI_RFS_M_E2E_P_MultipleCostCe

nters

1 30 30

TC_AFI_RFS_M_E2E_P_OnlyBusinessA

pplications

1 30 30

44

Identify the Design Documentation used for test case mapping to design

documentation. The change history associated with the design documentation

should indicate which changes within the design document are related to specific

changes (requirements/defect fixes):

Document Title Version Level Date

Ameriprise Metering

CSD for RFS

100875

v1.4 1.4 N/A

AFI RFS 100875

Design

N/A N/A N/A

List your assumptions if any for this testing:

# Assumption

1 FVT, SVT, RVT will be performed using Production usage data.

2 PSE test environment will not have multiple Virtual Center servers.

Other Test Case Info:

Does the application being tested interface with

other components of the same product or with

other products? If so, are the other components

/ products being tested?

Yes, will be tested during

regression test phase.

Does the change create or modify an item

(example - ticket) that another product should

be able to use? If so will the other product be

tested?

Yes, will be tested during

regression test phase.

Does testing of this change (Req/defect fix)

require any other baselined changes to be

implemented before this change can/should be

tested? If so list the changes.

No.

Will testing require multiple instances of

applications to be active concurrently (ex:

multiple servers in a client/server environment;

multiple web servers; etc.)?

No.

Will this change be tested in the environment

defined in the Test Plan? If not, what are the

reasons for testing in unplanned environments

or for not fully testing the planned

environments?

Yes.

45

Are these test Cases being used to validate any

Corporate Compliance? If yes, specify specific

instruction(s), and explain.

Yes, new business rules.

The new business Rules for

AFI RFS 100875 solution

must be configurable for:

• Application types and

derivation;

• Cost allocation method

(proportional or even);

• Limits of cost

allocation (global, LPAR,

platform, application, or cost

center);

• Default application

type and cost center;

• Hierarch level to

receive cost allocation (any combination of LPAR, platform, app, or cost center).

46

Anexo D

Caso de teste no nível de unidade classificado como teste de usabilidade e de

regressão desenvolvido e executado no projeto AFI RFS 100875.

1.1 Test Case Statistics

Test Case Name (with File Type) TC_AFI_RFS_M_P_TransferReports.doc

Product Name and Release AFI RFS - 100875


Original Test Case Author Wilson Rafael Rovere

Weight (if Applicable) 10

Design Document AFI_CR41_DesignSketch_v12.doc


Number

Date of


1.0 09/17/2008 Initial Test Case Wilson Rafael

Rovere

1.1 09/23/2008 Action Item Corrections Wilson Rafael

Rovere

1.3 Objective Verify script transferReports.sh transfer all 5 reports to the TUAM Report Server successfully.

1.4 Objective Details Verify script transferReports.sh transfer all 5 reports to the TUAM Report Server successfully.

They are:

- Billing Summary

- Billing Detailed

- PreChargeback

- Chargeback

- Exclude.


1.5.1 Setup or predecessor test case: All 5 reports must be already generated.

47

The reports are: Billing Summary / Billing Detailed / PreChargeback / Chargeback / Exclude.

1.5.2 Associated Test Specifications:

None

Additional configuration items: None

1.5.2 Reference documentation: AFI_CR41_DesignSketch_v12.doc

AFI_MeteringDetailedDesign.doc


Step # Description Expected Results

1. Log into the TUAM Application Server. Tester is logged into the TUAM Application Server .

2. Navigate to Start > All Programs > Accessories > System Tools > Scheduled Tasks.

Tester is in Scheduled Tasks window.

3. Execute task 13_TransferReports, which corresponds to TransferReports.sh script’s execution.

Task executed successfully.

4. Navigate to c:\metering\flags directory and ensure it was created a new flag file:

• TransferReports_YyyyMmDD

Where YyyyMmDD corresponds to today’s date.

Flag file created correctly.

5. Ensure all 5 reports were transferred to the TUAM Report Server.

The reports are: Billing Summary / Billing Detailed / PreChargeback / Chargeback / Exclude.

All reports were transferred to the TUAM Report Server successfully.

6. Navigate to c:\metering\logs directory and open ituam.log file. Ensure no error messages were logged. Verify for this script’s execution, it had call for flag.sh script.

Messages logged correctly.

7. END OF TEST CASE.

48

Anexo E

Caso de teste no nível de sistema do tipo interface e que também deve ser

classificado como de regressão desenvolvido e executado no projeto AFI RFS 100875.

1.1 Test Case Statistics

Test Case Name (with File Type) TC_AFI_RFS_M_E2E_P_AppSubtypes.doc

Product Name and Release AFI RFS - 100875


Original Test Case Author Wilson Rafael Rovere

Weight (if Applicable) 30

Design Document AFI_CR41_DesignSketch_v12.doc


Number

Date of


0.1 09/16/2008 Initial Test Case Wilson Rafael

Rovere

1.3 Objective The objective of this test case is to ensure that the Ameriprise RFS – 100875 solution

contemplates corrects rules for spreading and correct values are calculated and contemplated in the

reports.

1.4 Objective Details The objective of this test case is to ensure that the Ameriprise RFS – 100875 solution

contemplates corrects rules for spreading and correct values are calculated and contemplated in the

reports. This test case verifies solution contemplates two application subtypes: Regular and

Exclude ones and both can apply to both Business and Infrastructure applications, giving a total

of 4 type and subtypes combinations.

49


1.5.1 Setup or predecessor test case: Positive and Negative FVT test cases already executed.

1.5.2 Associated Test Specifications:

N/A

Additional configuration items: N/A

1.5.2 Reference documentation: AFI_CR41_DesignSketch_v12.doc

AFI_MeteringDetailedDesign.doc


Step

#

Description Expected Results

1. Log into the TUAM Application Server. Tester is logged into the TUAM Application Server.

2. Navigate to Start > All Programs > Accessories > System Tools > Scheduled Tasks.

Tester is in Scheduled Tasks window.

3. Execute the task which corresponds to copyAndUnzip.sh script’s execution.


4. Navigate to c:\metering\logs and open ituam.log. Ensure NO ERROR messages were logged.

NO ERROR messages logged.

5. Execute the task which corresponds to makeLpars.sh script’s execution.




7. Execute the task which corresponds to MakeApp2App.sh script’s execution.




9. Execute the task which corresponds to Task executed successfully.

50

Step

#


pollEndpoints.sh script’s execution.

Once the production data were processed, this step should be skipped.



11. Execute the task which corresponds to convertAAType4.sh script’s execution.




13. Execute the task which corresponds to queryVCDBs.sh script’s execution.




15. Execute the task which corresponds to lookUpAndStoreNormFactors.sh script’s execution.




17. Execute the task which corresponds to processAllUnprocessedUsageFiles.sh script’s execution.




19. Execute the task which corresponds to processEndpointCounts.sh script’s execution.




21. Execute the task which corresponds to loadVmCalibrations.sh script’s execution.




23. Execute the task which corresponds to doVmCorrections.sh script’s execution.




51

Step

#


25. Execute the task which corresponds to aggregate.sh script’s execution.




27. Execute the task which corresponds to flagRateCodes.sh script’s execution.




29. Execute the task which corresponds to spreading.sh script’s execution.




31. Execute the task which corresponds to reports.sh script’s execution.




33. Execute the task which corresponds to mappingVerifReport.sh script’s execution.




35. Navigate to c:\metering\cmi_user directory and open the CMIyyyymmdd.csv file, where yyyymmdd corresponds to yesterday´s date.

CMI file open.

36. Navigate to c:\metering\reports directory and open the reports:

• AFIExclude_YyyyMm_YyyyMmDd.xls

• AFIChargeback_YyyyMm_YyyyMmDd.xls

• AFIPrechargeback_YyyyMm_YyyyMmDd.xls

• AFIBillingDetail_YyyyMm_YyyyMmDd.xls

• AFIBillingSummary_YyyyMm_YyyyMmDd.xls

Reports opened successfully.

37. Verify in CMI file and Reports that there are only two types of explicit application: Business and Infrastructure and all other type, implicit one, Overhead.

Files contemplate only three types of application: Business, Infrastructure and Overhead.

38. Verify in CMI file that infrastructure applications have “INFRA” in the Cost Center field.

INFRA value in Cost Center field for infrastructure applications.

52

Step

#


39. Compare CMI file and reports to ensure all mapping of applications and values are done correctly.

Reports correct.

40. Verify that both Business and Infrastructure applications can have Regular and Exclude subtypes, giving a total of 4 type/subtype combinations.

Reports and CMI file with correct applications types and subtypes.

41. END OF TEST.

Curso de Engenharia de Computação PROCESSO DE TESTE DE...

Documents

Transcript of Curso de Engenharia de Computação PROCESSO DE TESTE DE...