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
Wilson Rafael Rovere
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
Wilson Rafael Rovere
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
USF – Universidade São Francisco – Campinas – SP.
Prof. Esp. Ricardo César Boaretto
USF – Universidade São Francisco – Campinas – SP.
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
Fonte: AFI RFS-100875 Project
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
Fonte: AFI RFS-100875 Project
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
Fonte: AFI RFS-100875 Project
É 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
Last date document was updated <15/12/2008 11:50:00>
Original Test Case Author Wilson Rafael Rovere
Weight (if Applicable) 10
Design Document AFI_CR41_DesignSketch_v12.doc
1.2 Summary of Changes Version
Number
Date of
Change Nature of Change Changed by
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 Test Configuration
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
1.6 Detailed Test Script (Including Expected Results)
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
Last date document was updated <15/12/2008 11:50:00>
Original Test Case Author Wilson Rafael Rovere
Weight (if Applicable) 30
Design Document AFI_CR41_DesignSketch_v12.doc
1.2 Summary of Changes Version
Number
Date of
Change Nature of Change Changed by
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 Test Configuration
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
1.6 Detailed Test Script (Including Expected Results)
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.
Task executed successfully.
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.
Task executed successfully.
6. Navigate to c:\metering\logs and open ituam.log. Ensure NO ERROR messages were logged.
NO ERROR messages logged.
7. Execute the task which corresponds to MakeApp2App.sh script’s execution.
Task executed successfully.
8. Navigate to c:\metering\logs and open ituam.log. Ensure NO ERROR messages were logged.
NO ERROR messages logged.
9. Execute the task which corresponds to Task executed successfully.
50
Step
#
Description Expected Results
pollEndpoints.sh script’s execution.
Once the production data were processed, this step should be skipped.
10. Navigate to c:\metering\logs and open ituam.log. Ensure NO ERROR messages were logged.
NO ERROR messages logged.
11. Execute the task which corresponds to convertAAType4.sh script’s execution.
Task executed successfully.
12. Navigate to c:\metering\logs and open ituam.log. Ensure NO ERROR messages were logged.
NO ERROR messages logged.
13. Execute the task which corresponds to queryVCDBs.sh script’s execution.
Task executed successfully.
14. Navigate to c:\metering\logs and open ituam.log. Ensure NO ERROR messages were logged.
NO ERROR messages logged.
15. Execute the task which corresponds to lookUpAndStoreNormFactors.sh script’s execution.
Task executed successfully.
16. Navigate to c:\metering\logs and open ituam.log. Ensure NO ERROR messages were logged.
NO ERROR messages logged.
17. Execute the task which corresponds to processAllUnprocessedUsageFiles.sh script’s execution.
Task executed successfully.
18. Navigate to c:\metering\logs and open ituam.log. Ensure NO ERROR messages were logged.
NO ERROR messages logged.
19. Execute the task which corresponds to processEndpointCounts.sh script’s execution.
Task executed successfully.
20. Navigate to c:\metering\logs and open ituam.log. Ensure NO ERROR messages were logged.
NO ERROR messages logged.
21. Execute the task which corresponds to loadVmCalibrations.sh script’s execution.
Task executed successfully.
22. Navigate to c:\metering\logs and open ituam.log. Ensure NO ERROR messages were logged.
NO ERROR messages logged.
23. Execute the task which corresponds to doVmCorrections.sh script’s execution.
Task executed successfully.
24. Navigate to c:\metering\logs and open ituam.log. Ensure NO ERROR messages were logged.
NO ERROR messages logged.
51
Step
#
Description Expected Results
25. Execute the task which corresponds to aggregate.sh script’s execution.
Task executed successfully.
26. Navigate to c:\metering\logs and open ituam.log. Ensure NO ERROR messages were logged.
NO ERROR messages logged.
27. Execute the task which corresponds to flagRateCodes.sh script’s execution.
Task executed successfully.
28. Navigate to c:\metering\logs and open ituam.log. Ensure NO ERROR messages were logged.
NO ERROR messages logged.
29. Execute the task which corresponds to spreading.sh script’s execution.
Task executed successfully.
30. Navigate to c:\metering\logs and open ituam.log. Ensure NO ERROR messages were logged.
NO ERROR messages logged.
31. Execute the task which corresponds to reports.sh script’s execution.
Task executed successfully.
32. Navigate to c:\metering\logs and open ituam.log. Ensure NO ERROR messages were logged.
NO ERROR messages logged.
33. Execute the task which corresponds to mappingVerifReport.sh script’s execution.
Task executed successfully.
34. Navigate to c:\metering\logs and open ituam.log. Ensure NO ERROR messages were logged.
NO ERROR messages logged.
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
#
Description Expected Results
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.