Qualidade sistemas legados

CENTRO UNIVERSITARIO SENAC

Reinaldo Coelho Sartorelli

Proposta de Processo para Automação de Testes em Sistemas

Legados

São Paulo

2007

REINALDO COELHO SARTORELLI

Proposta de Processo para Automação de Testes em Sistemas

Legados

Trabalho de conclusão de curso

apresentado ao Centro Universitário

Senac – Campus Tito, como exigência

parcial para obtenção do grau de Pós

Graduado em Técnicas de Construção

de Software Orientado a Objetos.

Orientador: Prof. Dr. Ivanir Costa

São Paulo

2007

RESUMO

Sistemas de software legados são sistemas que, apesar do tempo de vida,

continuam em produção e se mantém em uso. Os sistemas legados podem

apresentar problemas de qualidade por diversos fatores, dentre eles podem ser

citados, a baixa experiência do profissional que desenvolveu, o uso de uma

metodologia considerada antiquada, entre outros problemas que podem impedir

sua evolução ou até gerar erros graves após uma simples manutenção.

Normalmente os sistemas legados não podem ser substituídos por diversas

razões e que os tornam caros quanto à manutenção e trazem muitos riscos no

momento de sua evolução.

Devido a estes problemas torna-se necessário melhorar a qualidade desses

sistemas legados podendo ser uma forma interessante de mantê-los ativos,

tornando-os mais uma vez produtivos e permitindo que melhorias e evoluções

sejam efetuadas com menos riscos. Conseqüentemente é gerado uma maior

confiabilidade e segurança a cada evolução que se faça necessária. O incremento

de novas funcionalidades nos sistemas legados com maior qualidade permite que

que a empresa tenha vantagens competitivas sem grandes investimentos de

novos desenvolvimentos, gerando lucros, permitindo também a integração com

novos sistemas.

O objetivo deste trabalho é apresentar uma proposta teórica de um processo de

automação de testes que possa ser vinculado a qualquer processo de

manutenção de sistemas legados, visando melhorar a qualidade do sistema

legado de forma evolutiva, garantindo segurança no processo de implementação

e evitando prejuízos consideráveis a empresa.

Espera-se ao final desse trabalho uma contribuição com a proposta de um

processo automatizado de testes para sistemas legados, formado por passos em

uma seqüencia bem definida e simples e bem organizada.

Palavras-Chave: Sistemas Legados, Automação de Testes, Qualidade de

Software Legado, Melhoria de Sistemas de Software, Processo de Automação de

Testes, Processo de Desenvolvimento de Software.

ABSTRACT

Legacy computer system is the term that is commonly used to describe software

that is considered obsolete but is still being used in an organization. It usually

represents software that is difficult to maintain or created with technology that is no

longer supported by the vendor, software that is difficult to evolve due to a bad

design or the use of obsolete development methods and the cost of maintenance

is too high. These are some reasons for which the software is still used by the

company although the development and improvement were discontinued. Other

factors include de risk as it can consist of a core application for the company and

the cost does not justify the change, as replacing it can lead to profit loss.

Therefore, improving the quality of a legacy system can be an interesting way of

keeping it active and more productive, allowing improvements and new features to

be added with less risk, and also adding more confiability and security to a legacy

system. To improve the quality and reliability as means to evolve legacy systems

can add value and new ways of reusing the software without being a burden to the

company, even allowing it to be a profitable system again, and integrating it with

other new systems.

The main goal of this work is to present a theoretical proposal of tests automation

that can be linked to any software development process. The automation of a

systems' test routines leads to significant quality mprovements of legacy systems,

and a guarantee of reliability in the process of implementing new features and

avoiding losses due to the continued use of a legacy software in a company or

organization.

Finally, this paper intends to contribute with a proposal of a process of test

automation consisted of well-defined steps described in an organized and clear

way, to be applied in legacy systems in order to improve their quality overall.

Keywords: Legacy Systems, Test Automation, Legacy Quality Software, Improve

System Quality, Test Automation Process, Software Development Process.

LISTA DE ILUSTRAÇÕES

Figura 1: Estrutura do trabalho.............................................................................................12

Figura 2: Modelo de Ciclo de Vida Codifica-Remenda....................................................... 16

Figura 3: Ciclo de Vida Clássico ou Cascata........................................................................18

Figura 4: Ciclo de Vida Cascata do Tipo Sashimi................................................................19

Figura 5: Ciclo de Vida em Espiral...................................................................................... 20

Figura 6: Arquitetura Mista - Fase Cliente-Servidor............................................................ 22

Figura 7: Arquitetura Mista - Fase Final.............................................................................. 23

Figura 8: Exemplo de Modelo Cliente-Servidor Distribuído...............................................25

Figura 9: Exemplo de Modelo Cliente-Servidor de Banco de Dados Remoto....................26

Figura 10: Arquitetura Três Camadas numa aplicação baseada em Web............................. 27

Figura 11: Representação de um esquema Básico SOA...................................................... 30

Figura 12: O relacionamento entre Classe, SubClasse e SuperClasse................................. 35

Figura 13: Definição parcial de uma classe java..................................................................35

Figura 14: Relacionamento entre os padrões ISO/IEC 9126 e ISO/IEC 14598...................40

Figura 15: Escopo das Três Métricas de Qualidade............................................................. 45

Figura 16: Exemplo de Rede de Pesca como Analogia as Estratégias de Teste...................51

Figura 17: Ambiente de teste de unidade............................................................................. 56

Figura 18: Exemplo de Grafo de Fluxo de Controle............................................................ 70

Figura 19: Exemplo de Matriz de Grafo.............................................................................. 71

Figura 20: Aumento do tempo gasto com testes manuais.................................................... 80

Figura 21: Custo de testes manuais e automáticos ao longo do tempo................................ 80

Figura 22: Resultados de uma boa automação de testes...................................................... 82

Figura 23: Proposta de Processo de Automação de Testes em Sistemas Legados.............105

LISTA DE ABREVIATURAS

IEEE

SGBD

TI

SOA

XML

ISO

IEC

PUM

RNF

RUP

MTTR

AVL

GUI

CLI

API

Instituto de Engenharia Eletro-Eletrônica

Sistema Gerenciador de Banco de Dados

Tecnologia da Informação

Service Oriented Architecture(Arquitetura Orientada a Serviço)

eXtensible Markup Language(Linguagem de Marcação

Extensível)

International Organization for Standardization(Organização

Internacional para padronização)

International Eletrotechinical Comission(Comissão

Eletrotecnica Internacional)

Problems per User Mounth(Problemas por usuário mês)

Requisitos não Funcionais

Rational Unified Process(Processo Unificado Rational)

Mean-Time-To-Repair(Tempo médio para reparo)

Analise de Valor Limite

Graphical User Interface(Interface gráfica de usuário)

Command Line Interface(Interface de linha de comando)

Application Programming Interface(Interface de programação

de aplicação)

SUMÁRIO

1 INTRODUÇÃO.................................................................................................................10

Objetivos..........................................................................................................................11

Metodologia de Trabalho................................................................................................. 11

2 SISTEMAS DE SOFTWARE........................................................................................... 13

2.1 Processos de Desenvolvimento de Software............................................................. 13

2.1.1 Ciclo de Vida Codifica-Remenda ou Ad-Hoc....................................................15

2.1.2 Ciclo de Vida Cascata ou Clássico.....................................................................17

2.1.3 Ciclo de Vida em Espiral................................................................................... 19

2.2 Arquitetura de Software.............................................................................................21

2.2.1 Arquitetura Cliente Servidor.............................................................................. 24

2.2.2 Arquitetura Três Camadas..................................................................................27

2.2.3 Arquitetura Orientada a Serviços....................................................................... 28

2.3 Paradigmas de Desenvolvimento de Software.......................................................... 30

2.3.1 Paradigma Orientado a Objetos......................................................................... 33

3 QUALIDADE................................................................................................................... 38

3.1 Qualidade de Software...............................................................................................38

3.1.1 Atributos de Qualidade de Software.................................................................. 41

3.2 Métricas de qualidade de software............................................................................ 44

3.2.1 Métrica de Defeito............................................................................................. 45

3.2.2 Métrica de Problemas do Cliente.......................................................................46

3.2.3 Métrica de Satisfação do Cliente....................................................................... 48

3.3 Estratégias de Teste de Software............................................................................... 50

3.3.1 Teste de Unidade................................................................................................53

3.3.2 Teste de Integração.............................................................................................56

3.3.3 Teste de Sistema.................................................................................................60

3.3.4 Teste de Aceitação..............................................................................................64

3.3.5 Teste de Regressão............................................................................................. 65

3.4 Técnicas de Teste de Software...................................................................................66

3.4.1 Teste de Caixa-Branca....................................................................................... 67

3.4.2 Teste de Caixa-Preta...........................................................................................73

3.5 Automação de Teste de Software...............................................................................79

3.5.1 Automação de testes de unidade........................................................................ 84

3.5.2 Automação de testes de integração.................................................................... 86

3.5.3 Automação de testes de sistema.........................................................................88

4 SISTEMAS DE SOFTWARES LEGADOS..................................................................... 93

4.1 A qualidade do software legado.................................................................................95

4.2 Transformação de sistema legado............................................................................100

5 PROPOSTA DE AUTOMAÇÃO DE TESTES EM SISTEMAS LEGADOS................104

5.1 Identificar pontos de necessidade de automação..................................................... 107

5.2 Planejar os testes a serem efetuados........................................................................ 109

5.3 Definir as ferramentas para a automação.................................................................111

5.4 Incluir a automação no processo de desenvolvimento.............................................113

5.5 Acompanhamento e análise dos resultados..............................................................115

6 CONCLUSÃO.................................................................................................................117

REFERÊNCIAS................................................................................................................. 119

10

1 INTRODUÇÃO

Os autores de Engenharia de Software têm afirmado que nos últimos 40 anos as

empresas vêm investido em Sistemas de Software para automatizar diversos

tipos de processos de trabalho, focando nas principais atividades do seu ramo de

negócio, visando melhorar a produtividade e aumentar o controle sobre o

andamento do negócio.

Desta forma na atualidade grande parte do trabalho relacionado a

desenvolvimento de sistemas consiste em manter e evoluir estes sistemas criados

ao longo do tempo. A estes sistemas que foram criados à algum tempo, dá-se o

nome de Sistemas Legados1.

Alguns destes sistemas legados foram desenvolvidos com outros paradigmas de

desenvolvimento apropriados a época, alguns dos quais definidos atualmente

como de baixa produtividade e alto custo.

As empresas continuam a manter estes sistemas legados devido a complexidade

de sua substituição e sua importância muitas vezes vital para o negócio. Isto faz

com que as empresas invistam muito dinheiro para poder manter e evoluir um

destes sistemas legados, influindo diretamente no custo que este sistema

representa.

Devido as técnicas utilizadas para criar estes sistemas legados, muitas vezes a

qualidade deles em comparação aos sistemas construídos na atualidade é muitas

vezes menor, o que aumenta também o risco de se fazer uma manutenção ou

evolução nos mesmos.

1 Sistemas Legados serão melhor explicados no item 4.

11

Objetivos

O objetivo principal deste trabalho é apresentar uma proposta de processo para a

automação de testes nestes sistemas legados, gerando um material inicial que

poderá ser utilizado para novas pesquisas nesta linha de trabalho. A proposta

apresentada devido a sua dificuldade de realização não permitiu um estudo de

caso que poderia gerar um resultado prático e não somente uma proposta

teórica.

O objetivo secundário é apresentar um material que possa ser utilizado como

apoio à outros pesquisadores que precisem trabalhar com automação de testes

em sistemas legados, fornecendo caminhos e referências que podem ser

exploradas para a implantação desta proposta de processo.

Metodologia de Trabalho

Para a confecção deste trabalho, foram realizadas pesquisas bibliográficas em

diversos materiais, livros e documentos encontrados em bibliotecas e na Internet.

Também foram utilizados todos os materiais distribuídos ao longo das disciplinas

do curso e a partir desse referencial teórico foi então desenvolvida a proposta

tema desse trabalho de conclusão de curso.

A figura 1 apresenta de forma gráfica e simples a estrutura do trabalho. A partir da

figura é possível compreender a organização estrutural na qual o trabalho foi

construído.

12

Figura 1: Estrutura do trabalho

13

2 SISTEMAS DE SOFTWARE

Durante toda a história do desenvolvimento de sistemas de software foram

utilizados diversos processos, arquiteturas e paradigmas para a construção de

sistemas de software.

Desta forma encontram-se atualmente sistemas de software desenvolvidos de

diversas maneiras, com objetivos e fins específicos, tendo assim diversos

sistemas com estruturas diferenciadas em funcionamento.

Não é necessário que se domine todas estas características com profundidade,

desta forma, neste capítulo será abordado um pouco sobre Processos de

Desenvolvimento de Software, Arquiteturas de Software e Paradigmas de

Desenvolvimento de Software.

Por tratar de assuntos muito complexos, serão apresentados apenas algumas das

estruturas mais comuns destas divisões dos sistemas de software.

2.1 Processos de Desenvolvimento de Software

De acordo com Ian Sommerville processo de software é “um conjunto de

atividades e resultados associados que produzem um produto de software”,

(SOMMERVILLE, 1995). Já Roger Pressman define processo de software como

“um arcabouço para as tarefas que são necessárias para construir softwares de

alta qualidade”, (PRESSMAN, 2006, p.16). Desta forma, conclui-se que processo

de software é um conjunto de atividades bem organizadas que geram como

resultado um sistema de software de qualidade.

Um processo de software apresenta uma receita para se construir um sistema de

software. Esta receita pode conter atividades que trabalham em paralelo,

otimizando o tempo para a construção deste software. A Engenharia de Software

14

define processos para atividades como:

● Comunicação - Esta atividade envolve muita comunicação e colaboração

com o cliente e outras partes interessadas2. Esta atividade abrange todo o

levantamento das necessidades do cliente entre outros.

● Planejamento - Esta atividade envolve todo o plano de trabalho que será

realizado no projeto, que inclui levantar a quantidade de recursos

necessários, estimar total de horas que serão gastas na realização do

projeto, levantamento das atividades técnicas a serem realizadas no

projeto entre outras.

● Modelagem - Esta atividade inclui a geração de modelos que expliquem

tanto a equipe do projeto quanto ao cliente quais são os requisitos de

software que serão atendidos com a realização do projeto.

● Construção - Esta atividade descreve o processo de desenvolvimento do

código do sistema, assim como a realização dos testes que devem garantir

sua funcionalidade.

● Implantação - Esta atividade define uma entrega do software ou parte dele

ao cliente. A entrega pode ser de um sistema completo ou a adição de uma

nova funcionalidade num sistema já existente.

Quando se desenvolve um software e o mesmo é mantido, estamos de qualquer

maneira trabalhando num Ciclo de Vida de Software. Na Engenharia de Software

temos diversos tipos de ciclos de vida, e apesar de cada um deles ter suas

características, existe um pequeno grupo que é mais difundido no mercado.

A definição de Ciclo de Vida de Software segundo o Instituto de Engenharia

2 Partes Interessadas são todas as pessoas que tem um interesse na realização do projeto. Em Informática, estas pessoas são chamadas StakeHolders. Por exemplo: Gerente, Cliente e etc.

15

Eletro-Eletrônica (IEEE)3 é "O período de tempo entre o software ser idealizado e

o seu fim, quando o software não está mais disponível para uso", (IEEE, 1990).

Com isto pode-se entender que o Ciclo de Vida é o período ao qual um software

está em evolução, ou seja, ainda existem modificações sendo ou a serem feitas e

ainda existe utilidade para este software no mercado.

Abordaremos a seguir as variações mais comuns de Ciclo de Vida de Software,

quais são as vantagens e desvantagens de cada um e daremos alguns exemplos

de Ciclo de Vida em uso no mercado atualmente.

Existem três ciclos de vida primários de onde surgiram quase todos os ciclos de

vida existentes na atualidade. Muitos destes novos ciclos de vida foram formados

a partir da mistura de três ciclos básicos:

● Ciclo de Vida Codifica-Remenda;

● Ciclo de Vida Cascata ou Clássico;

● Ciclo de Vida Iterativo.

2.1.1 Ciclo de Vida Codifica-Remenda ou Ad-Hoc

O primeiro modelo de ciclo de vida e provavelmente o mais caótico deles é o

normalmente chamado de "codifica-remenda" apresentado na figura 2, onde

parte-se de uma especificação, quando esta existe, em muitos casos o ponto de

partida é apenas um escopo definido através de uma comunicação verbal com o

cliente e parte-se diretamente para a implementação, corrigindo o código a partir

dos erros que vão sendo descobertos durante o desenvolvimento.

Este modelo de ciclo de vida já foi e ainda é muito utilizado, devido a algumas de

suas características, o que implica em muitas vezes se encontrar no mercado

sistemas legados que em sua criação e/ou evolução utilizam este tipo de ciclo de

3 Institute of Electrical and Electronics Engineers será apresentado como IEEE a partir de agora.

16

vida.

Uma das características deste ciclo de vida que o torna tão utilizado é o prazo de

entrega proporcionado por ele, como não há nenhuma exigência de

planejamento, documentação ou qualidade comprovada (testes documentados,

automáticos e etc...), o tempo gasto entre a concepção e a entrega é

proporcionalmente menor.

Este modelo de ciclo de vida entretanto ainda tem sua valia quando utilizado em

algumas entregas muito pontuais, como por exemplo customizações de sistemas,

adaptações emergenciais entre outras.

Vantagens deste ciclo de Vida:

1. Desenvolvimento extremamente rápido;

2. Exige pouca experiência do desenvolvedor;

3. Baixo custo para entrega.

Desvantagens deste ciclo de Vida:

1. Extremamente complexo para manutenção, devido a pouca documentação;

2. Probabilidade de entrega com defeitos é alta, devido a não comprovação

da qualidade;

Fonte: (PADUA, 2000)

Figura 2: Modelo de Ciclo de Vida Codifica-Remenda

17

3. A chance de haver uma falha não prevista durante a produção do sistema é

alta.

2.1.2 Ciclo de Vida Cascata ou Clássico

O modelo de ciclo de vida em Cascata ou Clássico que é representado pela figura

3, também é conhecido como abordagem Top-Down4 contém uma seqüência de

atividades que devem ser executadas em ordem, o que permite ter pontos de

controle5 entre estas atividades, o que teóricamente deixa o processo confiável e

aplicável a projetos de qualquer escala.

Na prática este ciclo de vida apresenta alguns problemas, como quando é

aplicado ao processo, todo o sistema é planejado e documentado antes que se

comece a implementar o sistema, e o cliente somente vê o resultado do trabalho

após todo o sistema estar implementado e implantado.

Este sistema de entrega única causa problemas pois sempre que é encontrada

alguma falha em qualquer parte do ciclo, o ciclo de trabalho recomeça e os prazos

de entrega do sistema são alterados, muitas vezes com a necessidade de

reajustes no escopo do projeto.

Outro problema é o fato do cliente apenas ver o resultado do trabalho após o

término do desenvolvimento, o que muitas vezes leva a desentendimentos sobre

o que foi solicitado pelo cliente e o que foi entregue no produto.

4 Top-Down que em português quer dizer "De cima para Baixo", assim como o nome "Cascata" refere-se a seqüencia como este ciclo de vida é trabalhado, sempre numa ordem única, não possibilitando mudança nesta ordem.

5 Pontos de Controle são intervalos entre entregas onde é possível avaliar possíveis informações sobre a entrega desta parte do projeto, como lições aprendidas, riscos entre outros.

18


1. Possui um tempo de planejamento reduzido;

2. Gera uma documentação detalhada do sistema;

3. Permite o trabalho com grandes equipes de desenvolvimento;

4. O processo é rastreável, o que significa que é possível saber em que

momento do processo estamos.


1. Dependência entre as fases da cascata, uma não pode começar sem que a

anterior tenha terminado;

2. Gera uma grande chance de erro no planejamento já que toda a análise e

documentação do sistema é gerado antes do começo da implementação;

3. Sempre que um erro é descoberto, o sistema retorna para alguma fase

anterior, e o prazo de entrega deve ser reajustado, causando atrasos;

4. O cliente somente visualiza o resultado do trabalho ao final, o que

normalmente gera desconforto ou desacordos na entrega do sistema.

Nas fases do modelo em cascata é necessário permitir, que em fases posteriores

haja revisão e alteração das fases anteriores. Uma variante que permite este tipo

de alteração é o modelo Sashimi representado na figura 4, que apesar de ser um


Figura 3: Ciclo de Vida Clássico ou Cascata

19

processo mais seguro e confiável do que o modelo Cascata puro, tende a deixar

muito complexo o Gerenciamento de Projetos, (PADUA, 2000, p.24).

2.1.3 Ciclo de Vida em Espiral

Um modelo de ciclo de vida que utiliza uma abordagem completamente diferente

é o modelo em espiral apresentado na figura 5, este modelo é Iterativo e

Incremental, e faz com que a cada Iteração, seja dada uma volta no espiral.

Cada volta ao espiral envolve diversas atividades com o intuito de completar uma

parte do trabalho, isto gera diversas entregas ao longo do desenvolvimento do

sistema, que promovem validações a cada iteração, que por sua vez geram

informações sobre o andamento do projeto e necessidades de mudanças.

Uma das grandes vantagens deste processo iterativo é a possibilidade de um

acompanhamento mais rígido, podendo identificar problemas logo após o sistema

ter começado a ser desenvolvido, além das entregas parciais, que possibilitam ao

cliente deste projeto ter a possibilidade de acompanhar a evolução e fazer criticas

e sugestões de melhoria antes do custo do projeto tornar-se muito alto.

O principal problema do modelo em espiral é que ele requer uma gestão muito


Figura 4: Ciclo de Vida Cascata do Tipo Sashimi

20

sofisticada para que seja previsível e confiável.


1. Como os ciclos são curtos, a chance de encontrar um erro nos ciclos

iniciais é maior, diminuindo o risco de falhas;

2. O Modelo é adaptável, permitindo que cada iteração seja customizada para

a necessidade específica da mesma;

3. O cliente pode acompanhar a evolução do sistema, recebendo entregáveis;

4. Permite um maior controle de todo o processo, disponibilizando

informações mais exatas da evolução do software.


1. Por ser muito flexível, necessita de pessoas experientes para liderar o

projeto;

2. Exige um controle rigoroso para que não cometam erros nas iterações;

3. Possui um tempo de planejamento considerável.

Fonte: (WIKIPEDIA, 2007)

Figura 5: Ciclo de Vida em Espiral

21

2.2 Arquitetura de Software

Conforme Dr. Rick Kazman, Dr. Paul Clements e Len Bass arquitetura de software

“é a estrutura ou estruturas do sistema que abrange os componentes de software,

as propriedades externamente visíveis desses componentes e as relações entre

eles”, (BASS, 2003, p.21).

Baseado nisto Roger Pressman complementa que “a arquitetura não é o software

operacional. Ao contrário, é a representação que permite ao engenheiro de

software analisar a efetividade do projeto em satisfazer a seus requisitos

declarados, considerar alternativas arquiteturais em um estagio em que fazer

modificações de projeto é ainda relativamente fácil, e reduzir os riscos associados

à construção do software”, (PRESSMAN, 2006, 208).

Os Sistemas de Software geralmente são desenvolvidos utilizando-se de uma

arquitetura de software conhecida, desta forma aproveitamos as experiências

existentes obtendo-se as vantagens geradas por cada uma das arquiteturas.

Não existe uma melhor ou pior arquitetura, cada uma apresenta vantagens e

desvantagens, e cabe a cada um escolher a que mais se adapta ao negócio que

será suportado pelo sistema. Para tanto é necessário ter um conhecimento prévio

dos tipos de arquitetura existentes e uma visão geral sobre como cada uma pode

auxiliar numa determinada necessidade.

Existem casos entretanto onde pode-se encontrar um sistema desenvolvido sob

uma arquitetura mista, desta forma parte do sistema é desenvolvido numa

determinada arquitetura, aproveitando assim todos os benefícios gerados por ela,

e se comunica com outra parte do sistema desenvolvida numa outra arquitetura

atendendo assim a necessidades específicas.

Como exemplo de uma arquitetura mista, é possível imaginar um sistema para

Atendimento ao Consumidor6, que foi desenvolvido sobre a arquitetura cliente-

6 SAC – Sistema de Atendimento ao Consumidor é um sistema desenvolvido para que a

22

servidor7 num primeiro estágio, onde contempla apenas as estações de

atendimento gravando dados no servidor. Como apresentado na figura 6.

Supondo porém, que houve uma evolução do produto e a empresa resolveu

disponibilizar para seus clientes as informações de seus atendimentos na Internet.

Quando a empresa verificou as premissas para a evolução, percebeu que não

poderia utilizar a mesma arquitetura cliente-servidor para disponibilizar estas

informações devido a problemas de segurança.

Para corrigir este problema a empresa desenvolveu esta segunda parte do

sistema numa outra arquitetura conhecida como arquitetura Três Camadas8

(Como apresentado na figura 7). Desta forma o sistema passou a apresentar uma

solução de arquitetura mista.

empresa atenda o consumidor através de um telefone fornecido.7 Este tipo de arquitetura será melhor explicado no item 2.2.1.8 A arquitetura Três Camadas será melhor explicada no item 2.2.2.

Figura 6: Arquitetura Mista - Fase

Cliente-Servidor.

23

Alguns dos tipos de arquitetura existentes são:

● BlackBoard – Arquitetura baseada em multi-agentes que visa auxiliar em

problemas que possuam soluções não determinísticas, (CRAIG, 1995).

● Cliente-Servidor ou Duas Camadas – Arquitetura onde a parte Servidora

é basicamente um sistema gerenciador de Banco de Dados, e onde o

cliente é um sistema que utiliza este Servidor, (ROMAN, 2002).

● SOA - Orientada a Serviço9 – Arquitetura voltada a serviços e é baseada

em quatro chaves de abstração: FrontEnd da Aplicação, Serviço,

Repositório de Serviço e Barramento de Serviço, (BLANKE, 2004).

● P2P - Pessoa para Pessoa10 - Arquitetura de aplicação distribuída que

consiste em instalar dois módulos idênticos do sistema em duas máquinas

diferentes, (VERMA, 2004).

9 Software Oriented Architecture é apresentado como SOA deste momento em diante.10 Peer to Peer Architecture é apresentado como P2P deste momento em diante.

Figura 7: Arquitetura Mista - Fase Final

24

● Canos e Filtros (Pipes and Filters Architecture) – Arquitetura formada por

“canos e filtros”, onde interligamos os canos e o filtro é como se fosse a

água passando por dentro. Os comandos UNIX são gerados a partir desta

arquitetura, (L.A.S.E, 2007), (HOHPE, 2004).

● Plugin – Permite vincular executáveis a sua arquitetura, contanto que

estes sigam um padrão estipulado ao desenvolver a arquitetura. Muito

utilizado devido a grande flexibilidade que proporciona, (HENTENRYCK,

2006).

● Três camadas – Arquitetura Três Camadas veio basicamente para corrigir

algumas limitações geradas pela arquitetura Duas Camadas, (C.M.Ua,

2007).

Veremos a seguir alguns aspectos das arquiteturas mais comuns encontradas no

mercado de software e como cada uma delas pode ajudar numa determinada

situação.

2.2.1 Arquitetura Cliente Servidor

George Schussel nos apresenta que o termo Cliente/Servidor foi utilizado pela

primeira vez nos anos 80, em referência aos computadores pessoais em rede e

que a atual estrutura Cliente/Servidor ganhou aceitação em meados dos anos 80,

ao dar a entender que sua arquitetura possibilitava mais usabilidade, flexibilidade,

interoperabilidade e escalabilidade em comparação ao centralizado Mainframe,

(SCHUSSEL, 2007).

A arquitetura Cliente/Servidor é um tipo de arquitetura Multi-Camadas que tem

seu foco em separar a parte servidora da parte cliente, mesmo que estas estejam

instaladas na mesma máquina.

A parte Servidora neste caso é simplesmente o Sistema Gerenciador de Banco de

25

Dados(SGBD), que disponibiliza e controla o acesso por parte do Cliente as

informações necessárias.

Os SGBDs evoluíram com o passar do tempo e passaram a permitir a

implementação de regras de negócio diretamente no Banco de Dados através do

uso de Funções, Procedures e Triggers, (HARRINGTON, 2002).

A parte Cliente é responsável então pela interface disponibilizada para o usuário,

validações das informações de entrada e dependendo da forma com que foi

projetado o sistema esta camada contém também todas as regras de negócio

incluindo as buscas de dados ao SGBD.

O esquema básico de sistema Cliente/Servidor não apresenta nada a respeito da

distribuição dos componentes, (ROMAN, 2002, Pag. 124). Porém os dois tipos

mais comuns desta distribuição são apresentados nas figuras 8 e 9.

Fonte: (ROMAN, 2002)

Figura 8: Exemplo de Modelo Cliente-Servidor Distribuído

26

A arquitetura Cliente/Servidor foi a primeira arquitetura de sistemas de informação

que suportaram a Internet, (LERNER, 2000, p.115).

Em relação a Internet, a arquitetura Cliente/Servidor trabalha fazendo com que a

parte Cliente envie requisições11 ao servidor através de Objetos de Internet que

são respondidas12 por sua vez pela parte Servidora, (LERNER, 2000, p.115).

É possível entender Objetos de Internet como figuras, vídeos, sons e outros

objetos que trafegam através das respostas do Servidor.

Este sistema funcionou muito bem durante algum tempo, entretanto esta

arquitetura passou a gerar problemas de escalabilidade quando a quantidade de

requisições e o tamanho dos objetos de Internet cresceram.

Para solucionar este problema a arquitetura Cliente/Servidor foi estendida com

Proxies que ficam localizados entre a máquina cliente e o servidor.

Estes Proxies guardam os objetos que trafegam entre Clientes e Servidores

fazendo com que a requisição do cliente não precise chegar ao servidor para ser

retornada, diminuindo assim a quantidade de requisições efetuadas entre a parte

11 Estas requisições também são conhecidas como Requests12 Estas respostas também são conhecidas por Responses

Fonte: (ROMAN, 2002)

Figura 9: Exemplo de Modelo Cliente-Servidor de Banco de Dados Remoto

27

Cliente e a parte Servidora.

2.2.2 Arquitetura Três Camadas

Esta arquitetura também é um tipo de Arquitetura Muilti-Camadas e muitos a

consideram uma evolução da arquitetura Cliente/Servidor.

Segundo Hugh E. Williams e David Lane “a base da aplicação é a camada de

Banco de Dados, consistindo no SGBD que gerencia o Banco de Dados contendo

criação dos usuários de dados, atualização, exclusão e query13. Construído acima

da camada de Banco de Dados, temos uma complexa camada intermediária que

contém muito da lógica da aplicação e faz toda a comunicação entre as outras

camadas. Acima temos a camada de Cliente, normalmente um Software de Web

Browser que interage com a aplicação”, (WILLIAMS, 2002, p.2).

Esta mesma divisão apresentada por Hug E. Williams e David Lane pode ser vista

na figura 10.

13 Query é a definição dada as consultas efetuadas nos Bancos de Dados através de uma linguagem específica

Fonte: (WILLIAMS, 2002)

Figura 10: Arquitetura Três Camadas numa aplicação baseada em Web

28

Com base nas informações acima é possível entender que uma arquitetura três

camadas é uma arquitetura onde se divide o sistema em três partes, sendo a

primeira a parte do Banco de Dados que deveria conter muito pouca ou nenhuma

regra de negócio, sendo responsável apenas pelos dados do sistema, uma

segunda camada que contém toda a regra de negócio do sistema e que somente

ela efetua acessos a camada de Banco de Dados para efetuar as transações e

uma camada final onde se tem uma aplicação Cliente que também deve conter

pouca ou nenhuma regra de negócio e que tem como função principal ser a

interface da aplicação para o usuário final.

É muito comum acreditar que a camada Cliente deve ser obrigatoriamente um

Software de Web Browser, o que não é verdade pois se pode ter numa arquitetura

Três Camadas qualquer aplicação como cliente, contanto que obedeça a

formação das três camadas cada uma com suas responsabilidades definidas

como apresentado anteriormente.

A arquitetura três camadas é usada efetivamente para suprir deficiências da

arquitetura Cliente/Servidor, onde comparado com a arquitetura Cliente/Servidor a

arquitetura Três Camadas apresenta uma melhor performance, flexibilidade,

manutenabilidade, reusabilidade e escalabilidade, enquanto esconde a

complexidade do processamento distribuído do usuário, (C.M.U, 2007).

2.2.3 Arquitetura Orientada a Serviços

Segundo Norbert Bieberstein “o maior propósito da arquitetura orientada a serviço

é oferecer sinergia entre os negócios e os grupos de TI na organização e

oferecer para a organização maior flexibilidade...”, (BIEBERTEIN, 2006, p.35).

Desta forma é possível compreender que uma das idéias principais da Arquitetura

Orientada a Serviço (SOA) é facilitar a comunicação entre as pessoas de TI e as

pessoas de negócio. A maneira proposta para isto é que todas as chamadas ao

sistema sejam feitas através de chamadas de negócio, facilitando para que

29

qualquer pessoa de negócios consiga entender o que está acontecendo naquela

interação com o sistema através das chamadas efetuadas.

Como complemento a idéia acima, Jeffrey Hasan e Mauricio Duran definem que

“Arquitetura Orientada a Serviço(SOA) representa um novo e envolvente modo de

construir aplicações distribuídas” e que os serviços são “componentes distribuídos

que provem uma interface bem definida dos processos e trafega as mensagens

através de XML”, (HASAN, 2006, p.1).

Desta forma entendemos que além da comunicação com o sistema ser feita

através de chamadas de negócio, toda a informação trafegada entre elas é feita

através da linguagem de marcação XML14.

Tecnicamente Jeffrey Hasan e Mauricio Duran explicam que “SOA é como outras

arquiteturas distribuídas que permite a você construir aplicações que utilizam

componentes em domínios separados. SOA utiliza Web Services como aplicação

entre os pontos, que são conceitualmente equivalentes a componentes proxy e

stub dos tradicionais sistemas distribuídos baseados em componentes, exceto

que a interação entre um provedor Web Service e o cliente é mais fracamente

acoplado”, (HASAN, 2006, p.2).

Desta forma compreendemos que SOA trabalha com componentes distribuídos,

fornecendo como interface de comunicação os serviços de negócio escritos na

linguagem XML, e que a comunicação efetuada entre eles é através de Web

Services que é uma solução adotada para a integração de sistemas e na

comunicação entre aplicações diferentes, o que permite independência de

tecnologia entre as aplicações que estão conversando. A figura 11 mostra em

detalhes os domínios do SOA.

Um segundo grande benefício da arquitetura SOA é a possibilidade de integração

entre diferentes tecnologias, diferentes paradigmas de programação e diferentes

14 eXtensible Markup Language(XML) é uma recomendação da W3C para gerar linguagens de marcação para necessidades especiais

30

estruturas já que toda sua comunicação é feita através de mensagens de texto no

formato XML.

Para se tornar tão flexível e escalável, o modelo SOA utilizou de recursos

avançados que prejudicaram alguns outros pontos. O maior destes pontos foi a

performance devido ao uso constante de XML, o que consome bastante recurso

do sistema. A escalabilidade disponibilizada pela arquitetura permite que este

problema seja distribuído e desta maneira reduzido, porém não elimina o risco de

problemas de performance acontecerem dependendo de como for arquitetado o

sistema.

2.3 Paradigmas de Desenvolvimento de Software

Segundo John Hunt, “um paradigma de programação envolve uma filosofia

particular. Estas filosofias normalmente representam uma introspecção a um

Figura 11: Representação de um esquema Básico SOA

31

grupo de novos tipos de melhores práticas. Para uma linguagem de programação

suportar um paradigma em particular, ela deve não somente adotar este

paradigma (você pode utilizar técnicas de programação orientada a objetos em

assembler, mas você gostaria de fazer isso?), ela deve apoiar ativamente a

implementação baseada no paradigma. Isto normalmente significa que a

linguagem deve suportar construções que criem o desenvolvimento usando um

paradigma claro”, (HUNT, 2002, p.3).

Conforme apresentado, o paradigma de desenvolvimento é a forma de pensar,

planejar e criar um sistema, desta forma eles trabalham como sendo uma série de

regras que defendem uma forma de pensar.

Assim como diferentes grupos de engenharia de software propõem diferentes

metodologias, diferentes linguagens de programação propõem diferentes

paradigmas de programação.

Algumas das linguagens de programação podem ser implementadas em mais de

um paradigma de programação, como exemplo as linguagens C++ e Delphi que

podem ter seus códigos implementados tanto no paradigma estruturado como no

paradigma orientado a objetos. Entretanto o mais comum é uma linguagem

suportar apenas um tipo de paradigma de desenvolvimento.

A maioria dos paradigmas de programação que surgiram em ciências da

computação são os apresentados abaixo: (HUNT, 2002, p.3)

● Paradigma Funcional – Lisp é um exemplo clássico de linguagem

funcional, embora não seja a única. Estas linguagens dão ênfase em

aplicar funções (freqüentemente recursivas) para um grupo de um ou mais

itens de dados. A função então retorna um valor – o resultado avaliado da

função. Se a função mudar os itens de dados, este é um efeito colateral.

Há um apoio limitado para soluções algorítmicas que contam com

repetição via interação.

32

● Paradigma Procedural – Pascal e C exemplificam linguagens procedurais,

que tentam trabalhar num nível mais alto anterior a linguagem assember. A

ênfase está em soluções algorítmicas e procedimentos que operam em

itens de dados. Eles são extremamente efetivos, mas desenvolvedores de

software ainda encontram dificuldades. Isto acontece em partes pelo

aumento da complexidade ao longo do desenvolvimento de sistemas.

Entretanto, linguagens procedurais de alto nível removem a

possibilidadereferencia de alguns tipos de erros e aumentam a

produtividade, os desenvolvedores podem ainda encontrar problemas por

eles mesmos. Por exemplo, as interfaces entre diferentes partes do

sistema podem ser incompatíveis e isto pode não ser obvio até a

integração do sistema ou seus testes.

● Paradigma Modular – Em linguagens como Modula-2 e Ada, o módulo

esconde os dados dos usuários. Os usuários dos módulos podem apenas

acessar os dados por interfaces definidas. Estas interfaces são

“publicadas” então os usuários sabem as definições encontradas na

interface e podem checar se eles estão usando as versões corretas.

● Paradigma Orientado a Objetos – Este é o mais recente paradigma de

programação “comercial”. A aproximação da orientação a objetos pode ser

vista trazendo mais ainda a modularização. Não somente você tem que

explicitar módulos (neste caso objetos), mas estes objetos podem herdar

características de outros. Nós podemos é claro perguntar “Porque outro

paradigma de programação?”. A resposta para isto está no fracasso de

muitos projetos de desenvolvimento de software que erraram ao manter um

planejamento, permanecer dentro do prazo e dar aos usuários o que eles

querem. É claro, não podemos assumir que a orientação a objetos é a

resposta para todos estes problemas, esta é apenas outra ferramenta

disponível para os desenvolvedores de software.

É detalhado neste caso o paradigma mais atual que compõe a maior parte dos

33

sistemas que estão sendo desenvolvimento na atualidade, o paradigma orientado

a objetos.

2.3.1 Paradigma Orientado a Objetos

Segundo Ivan Ricarte “o termo orientação a objetos pressupõe uma organização

de software em termos de coleção de objetos discretos incorporando estrutura e

comportamento próprios”, (RICARTE, 2007).

Desta forma é possível compreender que a orientação a objetos define um grupo

de objetos que interagem entre si e onde cada um apresenta um comportamento

próprio dentro desta estrutura e organização.

“Um objeto é uma entidade do mundo real que tem uma identidade. Objetos

podem representar entidades concretas (um arquivo no meu computador, uma

bicicleta) ou entidades conceituais (uma estratégia de jogo, uma política de

escalonamento em um sistema operacional). Cada objeto ter sua identidade

significa que dois objetos são distintos mesmo que eles apresentem exatamente

as mesmas características” e “A estrutura de um objeto é representada em termos

de atributos. O comportamento de um objeto é representado pelo conjunto de

operações que podem ser executadas sobre o objeto”, (RICARTE, 2007).

Neste caso é possível entender que um objeto é composto por atributos que

apresentam as características do objeto, os comportamentos que são as ações

que este objeto pode executar e o estado do objeto que apóia a manter a sua

identidade.

Existem algumas outras terminologias importantes na orientação a objetos que

são importantes de se conhecer: (HUNT, 2002, p.21)

● Classe – A classe defina a combinação de dados e processos que operam

estes dados. Instâncias de outras classes somente podem acessar esses

dados ou processos por interfaces específicas. A classe não mantém

34

nenhum dado, mas é específica aos dados mantidos na instância.

● SubClasse – Uma subclasse é uma classe que herda de outra classe.

● SuperClasse – É a classe pai de outra classe. Isto é a classe da qual a

classe em questão herda.

● Instância ou Objeto – A instância é o exemplo de uma classe. Todas as

instâncias da classe processam variáveis de dados parecidos, mas

processam seus próprios dados. Cada instância da classe responde aos

mesmos conjuntos de requisições.

● Instância Variável – Este é um nome especial dado aos dados mantidos

num objeto. O “estado” de um objeto num momento particular revela os

valores atuais mantidos por esta instância de variável.

● Método – O método é um processo definido num objeto. Em versões

anteriores do Smalltalk os métodos eram utilizados para pedir ao objeto

para fazer algo e retornar algo. Isto tem se tornado mais largamente

utilizado; Linguagens como CLOS e Java também utilizam o termo.

● Mensagem – Um objeto manda mensagens para outro objeto solicitando

alguma operação ou dado. A mensagem pode ser considerada parecida

como uma chamada de processo em outras linguagens.

● This – Uma (pseudo) variável especial, this, é a referência ao objeto do

qual o método é chamado. Isto permite enviar mensagens para “this” (o

próprio) objeto.

● Herança simples ou múltipla – Herança simples ou múltipla se refere ao

número de superclasses de qual a classe pode herdar. Java é um sistema

baseado em herança simples, da qual uma classe pode herdar apenas de

35

uma classe. C++ é um sistema baseado em herança múltipla onde a classe

pode herdar de uma ou mais classes.

Muitas das definições apresentadas acima estão ilustradas nas figuras 12 e 13,

onde é possível visualizar as heranças das classes na figura 12 e as partes que

compões uma classe na figura 13.

Fonte: Adaptado de (HUNT, 2002, p.22)

Figura 12: O relacionamento entre Classe, SubClasse e SuperClasse

Fonte: Adaptado de (HUNT, 2002, p.23)

Figura 13: Definição parcial de uma classe java

36

Uma outra característica importante é o conceito de polimorfismo. John Hunt

apresenta em outro texto uma definição de polimorfismo como sendo “uma

palavra que soa estranho, derivada do grego15, para um conceito relativamente

simples. Isto é essencialmente a habilidade de requisitar que a mesma operação

seja respondida de muitas maneiras diferentes. A forma que a requisição é

processada depende da coisa que foi passada na solicitação. O desenvolvedor

não precisa se preocupar de como a informação é manipulada, ela simplesmente

é”, (HUNT, 2002, p.7).

Desta forma ele apresenta o conceito de polimorfismo como sendo a habilidade

de se trabalhar de diversas formas uma mesma solicitação, e a forma como esta

solicitação é processada depende apenas do tipo de parâmetro que foi informado

na chamada da operação. Por exemplo, se existe um método “dirigir” para uma

classe do tipo veículo, a forma como o veículo será dirigido depende do objeto

que será informado como parâmetro, ou seja, se eu informar um objeto do tipo

carro para a chamada do método “dirigir” eu estarei dirigindo um carro, no entanto

se eu passar um objeto do tipo trator para a chamada do método, eu estarei

dirigindo um trator.

Além das definições apresentadas, existem mais algumas definições importantes

na orientação a objeto, que são: (RICARTE, 2007)

● Encapsulamento - também referido como esconder informação, consiste

em separar os aspectos externos de um objeto, os quais são acessíveis a

outros objetos, dos detalhes internos de implementação do objeto, os quais

permanecem escondidos dos outros objetos. O uso de encapsulamento

evita que um programa torne-se tão interdependente que uma pequena

mudança tenha grandes efeitos colaterais.

● Ligações e associações - São os mecanismos para estabelecer

relacionamentos entre objetos e classes. Uma ligação é uma conexão

física ou conceitual entre duas instâncias de objetos.

15 Polymorphos significa “tem muitas formas”.

37

● Agregação - É um relacionamento do tipo “uma-parte-de”, nos quais

objetos representando os componentes de alguma coisa são associados

com objetos representando uma montagem. Por exemplo, o texto de um

documento pode ser visto como um conjunto de parágrafos, e cada

parágrafo é um conjunto de sentenças.

● Generalização - É o relacionamento entre uma classe e um ou mais

versões refinadas (especializadas) desta classe, ou seja, o relacionamento

entre uma superclasse e uma classe é que a superclasse é uma

generalização da classe.

38

3 QUALIDADE

Stephen H. Kan diz que “o maior problema na engenharia e gerenciamento da

qualidade é que o termo qualidade é ambíguo para nós, sendo assim é

comumente mau compreendido. A confusão pode ser atribuída a várias razões”,

(KAN, 2002).

As razões dadas por ele para a confusão com o termo qualidade são as

seguintes:

1. Qualidade não é uma idéia simples, mas sim um conceito multi

dimensional;

2. Para qualquer um dos conceitos apresentados, existem níveis de

abstração;

3. O termo qualidade faz parte do nosso uso diário e seu significado popular e

profissional podem ser muito diferentes.

Como é possível perceber qualidade é extremamente abrangente, devido a isto

este capítulo foca alguns conceitos básicos sobre qualidade de software, testes

de software e automação de testes de software.

O intuito com isto é ter uma base firme sobre o que é qualidade de software e o

que ela abrange, o que são testes de software e como estes podem ser aplicados

nos diferentes tipos de software além de como e porque podemos automatizar

testes de software.

3.1 Qualidade de Software

A norma ISO/IEC 9126 apresenta na introdução de seu texto que os

“computadores começaram a ser usados por uma crescente variedade de

39

aplicações em diversas áreas, e o correto funcionamento destas operações é

critica tanto para os negócios quanto para a segurança humana. Desenvolver ou

escolher produtos de software de alta qualidade portanto é de suma importância”,

(ISO/IEC, 2001).

Assim como apresentado, a importância da qualidade do software é muito grande,

onde suas falhas podem gerar desde prejuízos financeiros e até mesmo

falecimento de uma pessoa dependendo do tipo de atividade que o sistema

emprega, porém deve-se lembrar que implementar qualidade de software tem alto

custo que pode ser mais ou menos justificado de acordo com o ramo de negócio

ao qual o software pertence.

Stephen H. Kan nos adverte dizendo que “o mais estreito senso de qualidade de

produto está diretamente ligado a um leque de erros no produto. Este é apenas o

significado mais básico de conformidade com os requisitos, porque se o software

contém muitos defeitos funcionais, o requisito desejado não está sendo atendido”,

(KAN, 2002).

Desta forma é possível compreender que a qualidade do software está

diretamente ligada aos requisitos de sistema que foram definidos para este

software e que desta forma o padrão mínimo de qualidade que se espera de um

sistema é que ele atenda a todos os requisitos definidos.

Ao olhar qualidade de software por uma visão um pouco mais abrangente pode-

se perceber que não se deve preocupar somente com o teste do produto de

software em si, mas sim com todo o processo de construção do software.

Como descrito acima, sabe-se que a qualidade do software depende da qualidade

dos requisitos que estão sendo disponibilizados para que o software seja

desenvolvido, então deve-se considerar que a qualidade do requisito de software

também faz parte da qualidade de software, e desta forma é necessário

preocupar-se com o processo de desenvolvimento como um todo ao invés de se

40

preocupar apenas com a quantidade de Bugs16 encontrados após o

desenvolvimento do sistema.

Pensando neste problema, John W. Horch aponta em seu livro que os elementos

para a qualidade de um sistema de software são: Padrões, Revisões, Testes,

Analise dos Defeitos, Gerencia de Configuração, Segurança, Educação, Gerencia

de Vendas, Segurança e Gerencia de Riscos e cita ainda algumas adicionais

como Manutenção, Documentação, Considerações Organizacionais e a

Implementação de um Sistema Total de Qualidade de Software (HORCH, 2003).

Baseado nas preocupações acima, e visto que é possível ter um controle de

qualidade de software maior do que apenas a validação do produto resultante do

processo de desenvolvimento, a ISO/IEC criaram as normas 9126 e 14598 que

podem ser encaixadas no processo de desenvolvimento permitindo o

acompanhamento desta qualidade de software em diversos momentos da

construção do sistema, como apresentado na figura 14.

16 Bugs é o termo apresentado para uma falha ou erro encontrado no sistema

Fonte: (ISO/IEC, 2001)

Figura 14: Relacionamento entre os padrões ISO/IEC 9126 e ISO/IEC

14598

41

Stephen H. Kan nos apresenta ainda que a qualidade de software é divida em

dois níveis: Qualidade Intrínseca do Produto e Satisfação do Cliente, (KAN, 2002).

A qualidade intrínseca do produto é normalmente medida através do número de

erros existentes no projeto ou por quanto tempo esse sistema consegue executar

antes que seja encontrada uma falha grave no sistema. Já a satisfação do cliente

para ser avaliada depende de pesquisa em campo para levantamento e avaliação

das informações coletadas.

3.1.1 Atributos de Qualidade de Software

Stephen H. Kan nos diz que “Além de satisfação total do cliente com o produto de

software, satisfação em direção a atributos específicos também é estimada”,

(KAN, 2002).

Com o texto acima é apresentado que não basta apenas atender os requisitos de

sistema para garantir a satisfação do cliente em relação ao produto de software,

mas que se deve atender alguns outros atributos considerados pelos clientes.

Ele também complementa dizendo que “estes atributos de qualidade não são

sempre do mesmo tipo. Por exemplo, quanto mais alta a complexidade funcional

do software, mais difícil torna-se alcançar manutenabilidade. Dependendo do tipo

de software e do cliente, diferentes atributos de qualidade serão necessários”,

(KAN, 2002).

Alfs T. Berztiss diz que “um interesse da engenharia de requisitos é a ordenação

destes atributos de qualidade em ordem de importância para o particular software

em consideração, lembrando que o mais importante atributo de qualidade é a

aceitação do usuário”, (BERZTISS, 1996, p.73).

Considerando o texto acima, é possível entender que não existe um padrão de

atributos que devem ser respeitados em todos os projetos, mas sim que existem

42

atributos que deverão ser considerados para um determinado projeto. Apresenta

também que existem organizações interessadas em agrupar e organizar esses

atributos gerando padrões.

Para a organização dos atributos existem pelo menos duas classificações básicas

para eles:

1. Funcionais – São aqueles atributos que pertencem a funcionalidade do

sistema, normalmente são estes atributos que recebem boa parte da

atenção pois eles estão diretamente ligados aos requisitos identificados

para o sistema;

2. Não Funcionais – São a grande maioria e que estão implícitos na entrega,

algumas vezes eles são solicitados pelo usuários e outras vezes não,

porém podemos perder todo o trabalho de desenvolvimento do sistema ao

desconsiderar um destes atributos. Exemplo: Performance, Usabilidade,

etc.

A IBM por exemplo utiliza um grupo destes atributos que recebe o nome de

CUPRIMDSO, que atualmente foi atualizado para uma nova versão com o nome

de CUPRIMDSAPI que significa: (IPCOM, 2007)

● Capability (Capacidade) – Funcionalidade do sistema, ou seja, atender

aos requisitos funcionais;

● Usability (Usabilidade) – Quão intuitivo e fácil é o sistema para o usuário

final;

● Performance – Tempo de resposta do sistema para o usuário final;

● Reliability (Confiabilidade) – Livre de Falhas Operacionais, significa o

tempo entre as falhas;

● Installability (Instalabilidade) – De fácil instalação e configuração para

uso.

● Maintainability (Manutenabilidade) – Facilidade de corrigir problemas e

facilidade para criar e aplicar patchs17 de correção.

17 Patch, que significa Remendo em português é um pacote pequeno contendo uma atualização ou mais comumente correções a um sistema de software.

43

● Documentation/Information (Documentação/Informação) – Guias e

Publicações, Telas de ajuda em tempo real, ou seja, facilidade de encontrar

informação relevante na documentação existente e a efetividade destas

informações.

● Service (Serviço) – Facilidade na identificação e diagnóstico de problemas.

Facilidade para transportar esses problemas de suporte para central de

atendimento.

● Availability (Disponibilidade) – Habilidade do produto se manter útil ao

passar do tempo, preocupação com os outros atributos ao longo do tempo

de uso deste sistema.

● Personas (Imagens) – Preocupação do uso do produto por classes

específicas de clientes (Administrador, Operador, Cliente, etc..)

● Interoperability (Interoperabilidade) – Facilidade de integração com outros

produtos. Habilidade de receber, processar e transmitir dados para outros

sistemas.

Já a FURPS que é um modelo para classificar atributos de qualidade de software

criado pela HP(Hewlett-Packard) e muito utilizado pelo mercado:

● Functionality (Funcionalidade) – Representa todos os requisitos

funcionais;

● Usability (Usabilidade) – Recursos como Ajuda, o sistema ser intuitivo ao

usuário, acessibilidade;

● Reliability (Confiabilidade) – Requisitos de confiabilidade como por

exemplo capacidade de recuperação após uma falha, tolerância as falhas e

etc;

● Performance – Requisitos de desempenho como eficiência, consumo de

recursos do equipamento e tempo de resposta por exemplo;

● Supportability (Suportabilidade) – Requisitos de suporte como facilidade

de manutenção/configuração, internacionalização, compatibilidade,

manutenabilidade e etc.

44

3.2 Métricas de qualidade de software

Stephen H. Kan diz que “métricas de software podem ser classificadas em três

categorias: métricas de produto, métricas de processo e métricas de projeto”,

(KAN, 2002).

E explica dizendo que “Métricas de qualidade de software são um subgrupo de

métricas de software com um foco nos aspectos da qualidade do produto, do

processo e do projeto. Em geral, métricas de qualidade de software são mais

vinculadas as métricas de processos e produtos do que as métricas de projetos”,

(KAN, 2002).

Dentro dessa divisão:

● As métricas de produto descrevem características do produto como

tamanho, complexidade, características de layout, performance e nível de

qualidade.

● Métricas de processo podem ser utilizadas para melhorar o

desenvolvimento e manutenção. Exemplos incluem a eficácia de remoção

de erros durante o desenvolvimento, o padrão de nível de defeito e o

tempo de resposta do processo de correção do erro.

● Métricas de projeto descrevem as características e a execução do projeto.

Exemplos incluem o número de desenvolvedores de software, custo,

agendamento e produtividade.

E ele complementa descrevendo que “algumas métricas podem ser aplicadas a

múltiplas categorias. Por exemplo a métrica de improcess quality18 de um projeto

são ambos métrica de processo quanto métrica de projeto”, (KAN, 2002).

Dentro destas métricas de processos, produtos e de projetos, são classificados

três grupos de avaliação principal, nos quais estão os Defeitos, Problemas do

18 Não foi possível encontrar um termo adequado para a tradução desta métrica.

45

Cliente e Satisfação do Cliente. Cada um tem um escopo bem definido, como é

apresentado na figura 15.

3.2.1 Métrica de Defeito

Segundo Stephen H. Kan, para definir o indicador, primeiro precisa-se gerar o

numerador e o denominador e especificar o espaço de tempo, (KAN, 2002).

São apresentados abaixo cada uma das variáveis necessárias para que seja

gerado o indicador:

● O numerador neste caso é o número de defeitos válidos, ou seja, o número

conhecido de erros do sistema.

● O denominador é o tamanho do software, normalmente expressado em

milhares de linhas de código ou no número de pontos de função.

● Em termos de espaço de tempo, várias definições podem ser utilizadas

contando com o tempo a partir do lançamento do produto ao mercado.

Conta-se normalmente dois anos para sistemas de softwares.

Fonte: Adaptado de (KAN, 2002)

Figura 15: Escopo das Três Métricas de Qualidade

46

Este indicador é dependente de diversas informações para poder ser calculado e

requer um esforço relativo dos técnicos para sua implantação.

Para calcular o numerador por exemplo deve-se ter um controle dos defeitos do

sistema de forma atualizada e eficiente, para que o indicador resultante dos

cálculos sejam válidos e de uso confiável.

Entretanto para efetuar o cálculo ideal da quantidade de defeitos do sistema, não

se pode apenas confiar na perspectiva do desenvolvedor, a melhor maneira então

de gerar o número de defeitos é em relação a perspectiva do cliente, (KAN, 2002).

Para calcular o valor do denominador deve-se escolher uma das técnicas

existentes, das quais é possível citar como exemplo o cálculo de tamanho do

sistema através das linhas de código, que seguem algumas regras específicas

para sua geração. Manter esses valores atualizados e confiáveis é tão importante

quanto manter um controle exemplar dos defeitos do sistema.

Com base no resultado deste indicador, é possível ter um controle real de como

anda a “saúde” do software em questão, além de haver a possibilidade de

estimar quantos defeitos poderão ser encontrados numa próxima versão do

software, utilizando a base histórica dos defeitos por tamanho de software.

3.2.2 Métrica de Problemas do Cliente

Esta métrica foca principalmente nos problemas identificados pelo cliente durante

o seu uso, ao contrário da métrica de defeito onde apenas alguns tipos de erros

encontrados no sistema são selecionados para entrar no cálculo do indicador, na

métrica de problemas do cliente todos os problemas devem ser levados em

consideração, com algumas exceções.

“Problemas que não são considerados defeitos válidos podem ser problemas de

47

usabilidade, documentação ou informação incorreta, duplicidade de defeitos

válidos, e erros do usuário”, (KAN, 2002).

Esta métrica é normalmente calculada utilizando-se a fórmula de Problemas por

Usuário Mês(PUM)19, apresentada abaixo:

No caso da fórmula acima, tem-se que do total de defeitos reportados pelo cliente

no período são considerados apenas os defeitos válidos que se enquadram na

citação acima.

e onde:

“PUM normalmente é calculado durante cada mês depois que o software é

liberado ao mercado e também para retirada de médias mensais por ano”, (KAN,

2002).

Stephen H. Kan indica também três atividades que auxiliam a diminuir o valor do

PUM: (KAN, 2002)

1. Melhore o processo de desenvolvimento e reduza os defeitos do produto.

2. Reduza os problemas não orientados a defeito melhorando todos os

aspectos do produto (tal como usabilidade, documentação), educação de

cliente, e suporte.

19 Problemas por Usuário Mês foi retirado do termo “Problems per User Mounth”, por isso a sigla original PUM

PUM = Total de Defeitos Reportados pelos Clientes num período de tempo

+

Total de Licenças por Mês referente ao mesmo período

Número de Licenças por Mês = Número de Licenças Instaladas do Software

X

Número de Meses do período de cálculo

48

3. Aumente a venda (o número de licenças instaladas) do produto.

Com a execução dos itens um e dois indicados consegue-se diminuir o valor do

indicador PUM, já com o item três o resultado que se obtem é um aumento no

denominador de cálculo da fórmula, o que auxilia na confiabilidade do resultado

uma vez que por quanto mais clientes o software for utilizado, mais consistente

será seu valor.

É necessário lembrar que apesar deste indicador poder ser gerado sem o

indicador anterior e apresentar algum resultado, são obtidos apenas dados

comparativos de interesse real quando se segue a dependência apresentada na

Figura 15.

Com esta métrica é possível ter uma estimativa aproximada de como a evolução

do software está acontecendo numa visão mais macro do que em relação a

métrica de defeitos, em compensação o resultado deste indicador é totalmente

dependente de ações efetuadas diretamente sobre o produto que podem ser

decisões tomadas a partir da análise do resultado da métrica de defeitos.

3.2.3 Métrica de Satisfação do Cliente

Esta é uma métrica normalmente baseada em pesquisa de campo, onde a

empresa entra em contato com seus clientes e faz perguntas com o objetivo de

pontuar a satisfação do cliente numa faixa.

“Satisfação do cliente é freqüentemente medida por pesquisas de cliente numa

escala de cinco pontos”, (KAN, 2002).

Ele apresenta os cinco pontos da escala de satisfação como sendo:

● Very satisfied (Muito Satisfeito)

● Satisfied (Satisfeito)

49

● Neutral (Neutro)

● Dissatisfied (Insatisfeito)

● Very dissatisfied (Muito Insatisfeito)

Baseado nos dados resultantes desta pesquisa da escala dos cinco pontos, ele

sugere também alguns possíveis indicadores a serem retirados e afirma que

vários outros podem ser encontrados com os dados da pesquisa.

Entretanto ele aponta quatro exemplos de informações obtidas a partir da

pesquisa:

1. Porcentagem de Completa Satisfação dos Clientes.

2. Porcentagem de Clientes Satisfeitos (Contém os satisfeitos e os

completamente satisfeitos).

3. Porcentagem dos Clientes Insatisfeitos (Insatisfeitos e Complemente

Insatisfeitos).

4. Porcentagem de Clientes não Satisfeitos (Neutros, Insatisfeitos e

Completamente Insatisfeitos).

“Normalmente a segunda métrica, porcentagem de satisfação, é utilizada. Na

pratica o foco é em reduzir a porcentagem de insatisfação”, (KAN, 2002).

Como apresentado acima, com o resultado obtido nestas pesquisas é possível

gerar alguns indicadores que acompanham os apresentados anteriormente.

Quando o valor do indicador de problemas do cliente diminuir, e o indicador de

defeitos no sistema diminuir, conseqüentemente o indicador de porcentagem de

clientes satisfeitos deveria aumentar.

A conclusão acima pode parecer obvia, porém pode-se ter a situação onde os

primeiros indicadores foram reduzidos e o de porcentagem de clientes satisfeitos

50

não subiu. Segue alguns casos onde isto poderia ocorrer:

1. A qualidade do Software melhorou, porém requisitos não funcionais20(RNF)

não estão sendo verificados.

2. A qualidade do software melhorou e ele tem atendido aos RNF, porém o

cliente está descontente com o manual de ajuda, com o atendimento do

suporte técnico ou com o preço do sistema.

Assim como os exemplos acima, muitas outras informações podem ser obtidas a

partir de análises macro como estas.

É devido a estas necessidades que empresas como a IBM e a HP investem no

CUPRIMDSAPI e no FURPS como apresentado anteriormente21.

3.3 Estratégias de Teste de Software

Roger Pressman apresenta que “uma estratégia de teste de software integra

métodos de projeto de casos de teste em uma série bem planejada de passos,

que resultam na construção bem-sucedida de software. A estratégia fornece um

roteiro que descreve os passos a ser conduzidos como parte do teste, quando

esses passos são planejados e depois executados, e quanto de esforço, tempo e

recursos serão necessários. Assim, qualquer estratégia de teste deve incorporar

planejamento de teste, projetos de casos de teste, execução de teste e a coleta e

avaliação dos dados”, (PRESSMAN, 2006, p.288).

Conhecer as estratégias de teste é fundamental para que seja possível

compreender o que deverá ser testado no sistema e o que não deverá. Como

apresentado anteriormente não é viável implementar uma estratégia de teste sem

que haja um planejamento prévio. Desta forma, a estratégia de testes mostra o

20 Requisitos não funcionais (RNF) são requisitos de sistema que não dizem respeito diretamente as funcionalidades, mas que são de extrema importância para o bom funcionamento e para atender as necessidades dos usuários. Como exemplos temos: Performance, Usabilidade, e etc...

21 Detalhes desta informação foram citados no item 3.1.1

51

que pode ser testado no sistema de software.

A definição do RUP (Rational Unified Process) para casos de teste “é a definição

(geralmente formal) de um conjunto específico de entradas de teste, condições de

execução e resultados esperados, identificados com a finalidade de avaliar um

determinado aspecto de um Item de teste-alvo”, (WTHREEX, 2007).

Apesar de existir uma forma única documentar o planejamento dos testes (Casos

de Teste) independentemente da estratégia adotada, é de extrema importância

que cada estratégia de teste tenha seu próprio grupo de casos de teste, escritos e

planejados especificamente para aquele determinado tipo de estratégia escolhida.

As estratégias de teste podem ser entendidas como diferentes níveis de

abstração em que se planeja um teste, onde não existe uma estratégia de teste

que garanta a cobertura de uma outra. Elas são complementares.

Para fazer uma analogia do que foi apresentado, é possível imaginar que os

defeitos do software são como peixes num lago, e que cada estratégia de teste é

como uma das malhas que compõe a rede, elas são complementares e quanto

mais malhas mais peixes são capturados. A figura 16 ilustra parte desta analogia.

Figura 16: Exemplo de Rede de Pesca como Analogia as Estratégias de Teste

52

Desta forma, não existe uma melhor estratégia ou uma principal pela qual se deve

iniciar o trabalho, cabe a cada um conhecendo o seu negócio e seu sistema

escolher qual ou quais das estratégias irá gerar maior benefício ao ser

implementada.

Existem diversas estratégias de teste, dentre as quais são exploradas algumas

consideradas de maior utilidade prática. Para fornecer uma lista destas

estratégias num agrupamento padrão torna-se difícil devido a cada autor agrupar

as estratégias de teste de maneiras diferentes. Abaixo, segue uma lista seguindo

o agrupamento das estratégias conforme descrito no livro de Glenford Mayers,

(MAYERS, 2004):

● Teste de Unidade;

● Teste de Função;

● Teste de Sistema.

○ Teste de Facilidade

○ Teste de Volume

○ Teste de Estresse

○ Teste de Usabilidade

○ Teste de Segurança

○ Teste de Performance

○ Teste de Armazenamento

○ Teste de Configuração

○ Teste de Compatibilidade/Configuração/Conversão

○ Teste de Instalabilidade

○ Teste de Confiabilidade

○ Teste de Recuperação

○ Teste de Serviçabilidade22

○ Teste de Documentação

○ Teste de Processo

○ Teste de Aceitação

22 Não foi encontrada uma melhor forma de traduzir “Serviceability Test”.

53

Apesar de todas as estratégias citadas por Glenford Mayers, são detalhados

neste trabalho os testes mais comuns encontrados no mercado de trabalho, com

o objetivo de entregar a base mínima necessária para a compreensão do

trabalho.

3.3.1 Teste de Unidade

Roger Pressman defende que “o teste de unidade focaliza o esforço de

verificação na menor unidade de projeto do software”, (PRESSMAN, 2006, p.295).

Com isso entende-se que o teste de unidade utiliza a menor parte testável do

sistema como seu foco de trabalho.

Em teoria, o teste de unidade tem como objetivo testar isoladamente cada

pequena parte do sistema que tenha uma responsabilidade, desta forma entende-

se que se todas as partes do sistema estão funcionando isoladamente, existe

portanto muito menos chance de erro ao se testar o sistema de forma integrada.

Entretanto se há alguma destas unidades com problemas, as chances de que o

sistema como um todo apresente defeitos é muito alta, desta forma deve-se

descobrir e corrigir o defeito encontrado antes de passar para outras estratégias

de teste mais macro.

Nas linguagens convencionais a menor parte testável do sistema é o módulo, o

qual é testado isoladamente dos outros, porém para as linguagens orientadas a

objetos lida-se com outro paradigma que gera mais preocupações.

Roger Pressman comenta que “quando é considerado o software orientado a

objetos, o conceito de unidades se modifica. O encapsulamento guia a definição

de classes e objetos. Isto significa que cada classe e cada instância de uma

classe empacotam atributos e operações, que manipulam esses dados”,

(PRESSMAN, 2006, p.302).

54

Desta forma ao trabalhar com sistemas orientados a objetos passa-se a direcionar

os testes de unidade para as classes do sistema, garantindo desta forma que se

esteja lidando com a menor parte testável do sistema.

A linguagem orientada a objetos deixa mais uma dúvida em relação aos testes de

unidade, que tem a ver com a sua capacidade de trabalhar herança. Ao trabalhar

com heranças, tem-se várias subclasses partilhando atributos e operações de

uma superclasse. Quando é necessário testar estas classes no contexto de

unidade, deve-se testar sempre as subclasses, ignorando as classes abstratas,

(PRESSMAN, 2006, p.303).

“A interface do módulo é testada para garantir que a informação flui

adequadamente para dentro e fora da unidade de programa que está sendo

testada. A estrutura de dados local é examinada para garantir que os dados

armazenados temporariamente mantenham sua integridade durante todos os

passos da execução de um algoritmo”, (PRESSMAN, 2006, p.295).

Neste caso, tanto para as linguagens convencionais como para as orientadas a

objetos, é necessário testar as possibilidades de entrada e saída da unidade de

forma intensa, validando principalmente os limites oferecidos pela unidade.

“Casos de teste devem descobrir erros tais como (1) comparação de tipos de

dados diferentes, (2) operadores ou precedência lógica incorretos, (3) expectativa

de igualdade quando o erro de precisão torna a igualdade improvável, (4)

comparação incorreta de variáveis, (5) terminação de ciclo inadequada ou

inexistente, (6) falha na saída quando iteração divergente é encontrada, e (7)

variáveis de ciclo inadequadamente modificadas”, (PRESSMAN, 2006, p.295).

Como apresentado anteriormente, para que um teste de unidade seja executado

da forma adequada, é necessário executá-lo de forma isolada das demais

unidades do sistema. Entretanto existem dependências entre estas unidades que

55

serão testadas, e diversas vezes não há uma forma de se testar uma unidade

sem sua dependência.

Desta forma é necessário que sua dependência seja passada para um

pseudocontrolador (Driver) e/ou um pseudocontrolado (Stub), que precisam ser

criados para cada teste de unidade que for executado.

“Na maioria das aplicações um pseudocontrolador nada mais é do que um

'programa principal', que aceita os dados do caso de teste, passa tais dados ao

componente (a ser testado) e imprime os resultados relevantes. Os

pseudocontrolados servem para substituir módulos que são subordinados

(chamados pelo) ao componente a ser testado”, (PRESSMAN, 2006, p.296).

Com base nisto, é possível apresentar que um Driver(pseudocontrolador) é um

programa que irá chamar o componente a ser testado informando os parâmetros

de entrada necessários para a validação do teste de unidade, e que depois gera o

retorno deste resultado de alguma forma. E podemos dizer que um

Stub(pseudocontrolado) é um programa que simula uma dependência do

componente que está sendo testado, desta forma quando o componente que está

sendo testado precisa chamar a dependência, o stub recebe os parâmetros do

componente e retorna alguns valores pré-estabelecidos que favorecem o objetivo

do teste.

56

3.3.2 Teste de Integração

Roger Pressman define que “teste de integração é uma técnica sistemática para

construir a arquitetura do software enquanto, ao mesmo tempo, conduz testes

para descobrir erros associados às interfaces. O objetivo é, a partir de

componentes testados no nível de unidade, construir uma estrutura de programa

determinada pelo projeto”, (PRESSMAN, 2006, p.297).

A partir disto é possível entender que os testes de integração tem como objetivo

principal validar se todas as interfaces de comunicação entre as unidades estão

funcionando corretamente. Desta forma é possível assegurar que o sistema

trabalha em conjunto e que as informações trocadas entre os módulos funcionam

corretamente.

Fonte: (PRESSMAN, 2006, p.297)

Figura 17: Ambiente de teste de unidade

57

Existem duas abordagens a serem utilizadas quando se planeja testes de

integração, elas podem ser teste de integração descendente ou teste de

integração ascendente.

Teste de Integração Descendente

No teste de integração descendente23 a integração é inciada pelo modulo de

programa principal, ou seja, aquele de mais alto nível e conseqüentemente que

depende de todos os outros, em seguida é adicionado um módulo subordinado a

este e assim por diante.

O teste de integração descendente começa seu trabalho pelo alto nível da

hierarquia e faz testes em todas as regras de tomadas de decisão. Isto faz com

que este teste seja muito valorizado pelos profissionais responsáveis pelas regras

de negócio do sistema.

Roger Pressman nos indica cinco passos para implementar uma integração

descendente: (PRESSMAN, 2006, p.298)

1. O módulo de controle principal é usado como Driver24 do teste, e os Stubs

são substituídos por todos os componentes diretamente subordinados ao

módulo de controle principal.

2. Dependendo da abordagem de integração selecionada, os Stubs

subordinados são substituídos, um de cada vez pelos componentes reais.

3. Testes são conduzidos à medida que cada componente é integrado.

4. Ao término de cada conjunto de testes, outro Stub é substituído pelo

componente real.

5. O teste de regressão (Explicado no item 3.3.5) pode ser conduzido para

23 Esta abordagem é conhecida como Top-Down, de cima para baixo.24 A explicação sobre Stubs e Drivers encontram-se no item 3.3.1.

58

garantir que novos erros não tenham sido introduzidos.

O processo continua a partir do item 2 até que todo o programa esteja completo.

Com base nas informações acima é possível deduzir que os testes de integração

são trabalhosos de se gerar, devido a isto muitas empresas acabam por

simplificar os testes de integração executando os testes diretamente sobre o

módulo principal e com o sistema já completo. Desta forma consegue-se o

mesmo resultado testando a integração de todas as interfaces do sistema e

evitando o trabalho de criação dos Drivers e Stubs fazendo com que o sistema

seja testado de forma mais rápida.

Esta abordagem apesar de ser muito utilizada pode trazer consequências ruins,

como o objetivo dos testes de integração é descobrir problemas de comunicação

entre as interfaces de comunicação, testar o sistema inteiro de uma vez pode

fazer com que seja muito difícil identificar o erro quando este aparecer, pois se o

erro estiver ocorrendo num dos componentes da baixa hierarquia do qual muitos

dos testes dependam, todos estes testes podem apresentar erro ao final e desta

forma torna-se difícil descobrir em qual interação de componentes houve o erro.

Teste de Integração Ascendente

No teste de integração ascendente25 a integração dos componentes é iniciada da

parte mais baixa da hierarquia dos componentes. Desta forma inicia-se os testes

pelas unidades que não dependam de ninguém, adicionando em seguida os seus

dependentes até que o sistema esteja completo.

“Como os componentes são integrados de baixo para cima, o processamento

necessário para os componentes subordinados em um determinado nível está

sempre disponível e as necessidades de Stubs é eliminada”, (PRESSMAN, 2006,

p.299).

25 Esta abordagem é conhecida como Boton-Up, de baixo para cima.

59

Roger Pressman indica 4 passos para a implementação da integração

ascendente: (PRESSMAN, 2006, p.299)

1. Componentes de baixo nível são combinados em agregados (clusters,

algumas vezes chamados de construções), que realizam uma subfunção

específica do software.

2. Um Driver é escrito para coordenar a entrada e a saída do caso de teste.

3. O agregado é testado.

4. Drivers são removidos e agregados são combinados movendo-se para

cima na estrutura do programa.

Pode-se entender os agregados como sendo outras partes do software que

precisam ser testados, como por exemplo os bancos de dados. Desta forma

Pressman nos diz que “Cada um dos agregados é testado usando um Driver”,

(PRESSMAN, 2006, p.299).

Entretanto, além de testar os agregados separadamente, é preciso ligá-los aos

outros testes para garantir que toda a estrutura funciona em conjunto.

Algo que faz com que os testes de integração ascendentes não sejam tão

utilizados quanto os testes de integração descendentes é o fato de não haver

como saltar nenhuma etapa o que mantém o custo para a implantação do mesmo

alta.

Roger Pressman apresenta uma sugestão para diminuir este custo descrevendo

que “de fato, se os dois níveis superiores da estrutura do programa são

integrados descendentemente, o número de Drivers pode ser reduzido

substancialmente e a integração de agregados é grandemente simplificada”,

(PRESSMAN, 2006, p.299).

60

Teste de Integração Orientados a Objetos

Para os testes de integração em linguagens orientadas a objetos, as técnicas

convencionais mencionadas não são válidas e para estes casos podemos utilizar

duas abordagens: (BINDER, 1994)

● Teste Baseado no Caminho da Execução (Thread-Based Testing) – Este

teste é aplicado sobre um caminho de execução do sistema, integrando

todos os componentes deste caminho que são executados individualmente.

O teste de regressão26 é aplicado para garantir que nenhum efeito colateral

ocorra.

● Teste Baseado no Uso (Use-Based Testing) – Inicia o teste por aquelas

classes (chamadas classes independentes) que usam muito poucas ou

nenhuma classes servidoras. Depois que as classes independentes são

testadas, a camada seguinte de classes (chamadas classes dependentes)

que usam as classes independentes, são testadas. Esta seqüência de

teste de camadas de classes dependentes continua até que todo o sistema

seja concluído.

3.3.3 Teste de Sistema

Após a apresentação dos testes anteriores, também conhecidos como testes

técnicos, o foco do teste agora passa a ser o sistema completo com todos os

componentes preparados e configurados.

Neste nível de abstração de testes, a diferença apresentada anteriormente entre

os testes em sistemas clássicos ou orientados a objetos deixa de existir devido ao

foco do trabalho que passa a ser totalmente relacionado ao funcionamento do

software como um todo, o que envolve também outras partes do sistema que nos

testes anteriores foram ignorados, como Hardware, Pessoal, informação e etc.

26 Teste de Regressão é melhor explicado no item 3.3.6

61

“Teste de Sistema é na verdade uma série de diferentes testes cuja finalidade

principal é exercitar por completo o sistema baseado em computador. Apesar de

cada teste ter uma finalidade distinta, todos trabalham para verificar se os

elementos do sistema foram adequadamente integrados e executam as funções a

eles alocadas”, (PRESSMAN, 2006, p.306).

Um problema clássico do teste de sistema é ele ser “dedo-duro”. Isto acontece

porque ao expor um erro, cada desenvolvedor responsável por uma parte do

sistema culpa outro desenvolvedor sobre o erro acontecido.

Para diminuir este problema Roger Pressman indica ao engenheiro de software,

(PRESSMAN, 2006, p.305):

1. Projetar caminhos de manipulação de erros que testem toda a informação

que chegue de outros elementos do sistema;

2. Conduzir uma série de testes que simule maus dados ou outros erros em

potencial na interface do software;

3. Registrar os resultados dos testes para usá-los como “evidência”, se

houver um dedo-duro;

4. Participar do planejamento e projeto de testes de sistema para garantir que

o software seja adequadamente testado.

São apresentados neste trabalho apenas os testes que foram considerados os

mais importantes participantes da composição do teste de sistema, pois tratar

todos os testes que fazem parte do teste de sistema é considerado demasiado

grande para este capítulo do trabalho.

62

Teste de Recuperação

Quando um sistema sofre uma falha, normalmente em seus requisitos constam

informações de como o sistema deve se comportar, seja exibindo uma mensagem

de erro, seja reinicializando o sistema ou efetuando outra operação qualquer.

“O teste de recuperação é um teste de sistema que força o software a falhar de

diversos modos e verifica se a recuperação é adequadamente realizada. Se a

recuperação é automática (realizada pelo próprio sistema), a reinicialização, os

mecanismos de verificação, a recuperação dos dados e o reinicio são avaliados

quanto a correção. Se a recuperação requer intervenção humana, o tempo médio

para reparo (mean-time-to-repair, MTTR) é avaliado para determinar se está

dentro dos limites aceitáveis”, (PRESSMAN, 2006, p.306).

Com base no texto, podemos resumir que o teste de recuperação força falhas no

sistema para validar se as ações de recuperação estão de acordo com as

definições dos requisitos do sistema.

Teste de Segurança

Roger Pressman explica que “teste de segurança verifica se os mecanismos de

proteção incorporados a um sistema vão de fato protegê-lo de invasão imprópria”,

(PRESSMAN, 2006, p.306).

Como apresentado acima, o teste de segurança visa validar como o sistema está

preparado para sofrer tentativas de invasões, não somente invasões de hackers27,

mas de funcionários descontentes, de concorrentes, e etc...

Em teoria não há limites para o teste de segurança, tudo é permitido, desde

roubar senhas até implementar uma falha propositada no sistema com o intuito de

27 Hacker são pessoas com um alto grau de conhecimento em computadores, que utiliza deste conhecimento para invadir e obter informações de locais não autorizados, normalmente fazendo isso por diversão ou para testar seus próprios limites/conhecimentos.

63

facilitar uma invasão. Qualquer meio utilizado que consiga invadir o sistema de

qualquer forma deve ser comunicado e corrigido.

Roger Pressman aponta outra informação interessante ao descrever que “o papel

do projetista é tornar o custo da invasão maior do que o valor da informação que

será obtida”, (PRESSMAN, 2006, p.306).

Teste de Estresse

O teste de estresse tem como objetivo ultrapassar os limites do sistema, isto é,

ele tem como objetivo alimentar o sistema com uma condição extrema onde o

mesmo ultrapasse os níveis máximos aceitos pela documentação, a fim de

garantir o cumprimento destes valores por parte do sistema.

“O teste de estresse executa um sistema de tal forma que demanda recursos em

quantidade, freqüência ou volume anormais”, (PRESSMAN, 2006, p.306).

É extremamente aconselhável que ao executar um teste de estresse de algum

sistema, se tenha o sistema sendo executado num ambiente similar ao de

produção, pois qualquer diferença de hardware como memória, rede entre outros

podem alterar a confiabilidade dos testes.

Roger Pressman apresenta uma técnica variante do teste de estresse conhecida

como teste de sensibilidade onde “em algumas situações (a mais comum ocorre

em algoritmos matemáticos), um intervalo de dados muito pequeno, contido

dentro dos limites de validade dos dados para um programa, pode causar

processamento extremo e até errôneo, ou profunda degradação de desempenho”

e nos diz que “o teste de sensibilidade tenta descobrir combinações de dados,

dentro das classes de entrada válidas, que podem causar instabilidade ou

processamento inadequado”, (PRESSMAN, 2006, p.307).

Com isso é possível entender que o teste de sensibilidade pretende descobrir

64

situações dentro dos limites estipulados pelos requisitos que causam alguma

instabilidade ou comportamento estranho no sistema.

Teste de Desempenho

O teste de desempenho pode ocorrer em qualquer nível de testes, num teste de

unidade por exemplo pode-se avaliar o desempenho de um componente isolado

do sistema mas não se pode dizer que o desempenho do sistema é aceitável até

que o desempenho de todos os seus componentes sejam testados em conjunto.

“O teste de desempenho é projetado para testar o desempenho do software

durante a execução, no contexto de um sistema integrado”, (PRESSMAN, 2006,

p.307).

Ao trabalhar com testes de desempenho é necessário avaliar a condição dos

recursos do sistema de forma precisa, como ciclos do processador, leitura do

disco entre outras.

A instrumentação externa pode monitorar tempos de intervalos de execução do

sistema, registrando os eventos e a condição dos recursos informados.

“Instrumentando um sistema, o testador pode descobrir situações que levam à

degradação e possível falha do sistema”, (PRESSMAN, 2006, p.306).

O teste de desempenho é comumente aplicado junto com o teste de estresse

aproveitando que o teste de estresse já aplica uma sobrecarrega no sistema, e

com isto os dados colhidos pelo teste de desempenho podem informar a partir de

que ponto o sistema passa a se comportar de forma estranha.

3.3.4 Teste de Aceitação

Glenford Myers apresenta que “teste de aceitação é o processo de comparar o

65

programa com os requisitos iniciais e com as necessidades atuais dos usuários

finais”, (MYERS, 2004, p.144).

Com base no texto, é possível entender que o teste de aceitação é efetuado

sobre o produto final, ou seja, sobre o sistema completo e tem como objetivo

principal validar se todos os requisitos solicitados inicialmente pelo cliente estão

corretamente implementados e funcionando. Além disto, ele tem a intenção de

verificar se as necessidades atuais do cliente estão sendo atendidas com o

sistema.

O teste de aceitação muitas vezes não é executado pela empresa que

desenvolveu o software mas sim pelo cliente final. Algumas empresas de software

disponibilizam para o cliente ao final do desenvolvimento um ambiente chamado

Ambiente de Homologação, com acesso ao sistema final para que o cliente possa

então efetuar os testes de aceitação.

O teste de aceitação consiste basicamente em abrir o sistema e validar se todos

os requisitos documentados estão funcionando adequadamente, não existe uma

forma de automatizar este tipo de teste pois ele depende simplesmente do que foi

acordado com o cliente e por isso a melhor forma de efetuar esta validação é a

liberação do sistema para o cliente final.

3.3.5 Teste de Regressão

Ao corrigir uma falha encontrada no sistema, é necessário não somente testar se

a falha está corrigida, como também é necessário testar se todas as partes

envolvidas com a correção desta falha ainda funcionam corretamente. A esta

reavaliação de uma parte do sistema damos o nome de teste de regressão.

Roger Pressman define o teste de regressão como sendo “a reexecução de

algum subconjunto de testes que já foi conduzido para garantir que as

modificações não propagassem efeitos colaterais indesejados”, (PRESSMAN,

66

2006, p.300).

O teste de regressão então consiste na reexecução de casos de teste já

desenvolvidos e executados anteriormente, porém se torna inviável executar

todos os casos de teste novamente a cada modificação efetuada no sistema, para

evitar este problema Pressman nos indica três diferentes classes de casos de

testes que valem a pena ser reexecutados, (PRESSMAN, 2006, 300):

1. Uma amostra representativa de testes que vão exercitar todas as funções

do software.

2. Testes adicionais que focalizam funções do software, que serão

provavelmente afetadas pela modificação.

3. Testes que focalizam os componentes de software que foram modificados.

Desta forma, o teste de regressão pode garantir o funcionamento do sistema

após a modificação efetuada. Roger Pressman complementa descrevendo que “o

número de testes de regressão pode crescer significativamente. Assim sendo, a

suíte de testes de regressão deve ser projetada para incluir apenas aqueles que

cuidam de uma ou mais classes de erros em cada uma das principais funções do

programa”, (PRESSMAN, 2006, p.300).

3.4 Técnicas de Teste de Software

Um software é testado para que seja descoberto o maior número de erros

possíveis no sistema, desta forma é necessário planejar para que os testes

capturem a maior quantidade destes erros e as técnicas de teste de software são

técnicas que auxiliam a maximizar as chances de se encontrar erros no sistema

de software.

Roger Pressman defende que “essas técnicas fornecem diretrizes sistemáticas

para projetar testes que [1] exercitam a lógica interna e as interfaces de cada

67

componente de software, e [2] exercitam os domínios de entrada e saída do

programa para descobrir erros na função, no comportamento e no desempenho

do programa”, (PRESSMAN, 2006, p.315).

O resultado do trabalho para as técnicas de teste são casos de teste que

respeitam as regras apresentadas acima e aumentam as chances de captura de

erros no sistema.

“Diferentes técnicas de testes são adequadas em diferentes momentos”,

(PRESSMAN, 2006, p.289).

Desta forma é necessário que se conheça as técnicas de teste para poder

escolher a melhor para a situação existente no momento, garantindo uma solução

direcionada e garantindo a melhor qualidade possível dos casos de teste que

serão executados.

3.4.1 Teste de Caixa-Branca

Esta técnica de teste visa o planejamento dos testes com foco no código, ou seja,

o responsável pelo planejamento do teste deve escrever os casos de teste com o

conhecimento de como o sistema se comporta internamente, suas condições e

ciclos, e deve garantir que aos testes finalizados, todas as condições ou ciclos do

sistema foram testadas por completo.

Roger Pressman apresenta esta definição de outra forma, dizendo que “teste de

caixa branca de software é baseado em um exame rigoroso do detalhe

procedimental. Caminhos lógicos internos ao software e colaborações entre

componentes são testados, definindo-se casos de testes que exercitam conjuntos

específicos de condições e/ou ciclos”, (PRESSMAN, 2006, p.318).

Um indicador comum utilizado para saber quanto deste código foi testado ou não

é chamado de cobertura de código, ele indica qual a porcentagem das linhas de

68

código que estão sendo testadas pelo menos uma vez. Um sistema que tem cem

por cento do seu código coberto não está livre de erros, porém haverá menos

chances de acontecer um erro por não ter testado uma parte do sistema.

Glenford Myers apresenta dois problemas ao se pensar em testes de caixa

branca, o primeiro deles é o fato de que o número de caminhos lógicos para uma

função pode ser astronomicamente grande, o segundo é que mesmo se todos os

caminhos forem testados, não há uma garantia de que o sistema não contem

erros, (MYERS, 2004, p.12,13).

Ele apresenta três explicações para o fato do sistema com cem por cento de

cobertura de código ainda apresentar erros, e são, (MYERS, 2004, p.13):

1. Ao fazer um teste com cem por cento de cobertura de código você não tem

garantia de que está testando a coisa certa. Por exemplo, imagine que foi

solicitado a você fazer uma função para ordenação ascendente e por

engano você criou uma ordenação descendente, neste caso cobrir cem por

cento do código não irá descobrir o erro sendo que o teste está validando

uma ordenação descendente.

2. O programa pode estar incorreto devido a caminhos perdidos28. Teste de

cem por cento do código pode não detectar a ausência de caminhos

necessários.

3. Teste de cem por cento do código pode não descobrir erros de

sensibilidade de dados29. Isto é, erros causados por uma mudança no valor

das variáveis utilizadas pelo programa não são capturados através da

cobertura completa do código.

Desta forma fica claro que não basta uma cobertura completa do código para

garantir eficiência, é necessário novamente um bom planejamento dos testes para

28 Missing Paths é como está no original em inglês e o autor se refere a trechos do código que podem não ter sido implementados mesmo que fossem necessários.

29 Data-Sensitivity Errors refere-se a erros com devido a dados variáveis dentro do sistema.

69

capturar a maior quantidade de erros possíveis.

Dentro do teste de caixa branca, existem diversas técnicas de estruturas de

controle que podem ser aplicadas para garantir um maior resultado ao aplicar os

casos de teste.

Teste de Estrutura de Controle de Caminho Básico

Segundo Roger Pressman “o método de caminho básico permite ao projetista de

casos de teste originar uma medida de complexidade lógica de um projeto

procedimental e usar essa medida como guia para definir um conjunto básico de

caminhos de execução”, (PRESSMAN, 2006, p.319).

Conforme explicado, é possível entender que esta técnica de teste nos permite a

partir de um processo de sistema, gerar um conjunto de caminhos de execução

que podem originar casos de teste com grande probabilidade de captura de erros.

A estrutura de caminho básico gera muitos benefícios para o planejamento e o

resultado dos testes, porém para obter o melhor resultado deste método é

necessário que se entenda diversos componentes que juntos permitem o melhor

planejamento de casos de teste.

A lista que segue contém uma definição mínima de partes importantes que

compõem a estrutura de caminho básico segundo Roger Pressman,

(PRESSMAN, 2006, p.319-326):

● Notação de Grafo de Fluxo – Esta é uma notação que representa

graficamente o fluxo de dados do programa possibilitando uma visão

externa importante para visualizar e definir os testes, nesta notação cada

grupo lógico do programa é numerado, e estes números juntamente com a

notação gráfica fornecem uma base para definição dos casos de teste. Um

exemplo de notação de grafo de fluxo é a figura 18.

70

● Caminhos Independentes de Programa – Esta técnica utiliza o desenho

gerado pelo grafo de fluxo para definir diversos caminhos diferentes que o

programa pode executar. Desta forma, esta técnica utiliza os números do

grafo para escrever a seqüencia lógica que aquele teste deverá percorrer

dentro do programa. Para definir a quantidade de caminhos que devem ser

procurados esta técnica se utiliza da complexidade ciclomática30. Um

exemplo de caminho para o fluxo da figura 18 seria: 1-3-4-8-9-11.

● Matrizes de Grafos – Uma matriz de grafo é uma matriz quadrada onde é

representada dentro dela as conexões do grafo gerando informações

adicionais para definição dos casos de teste, como por exemplo a

probabilidade de que uma conexão seja executada. Um exemplo de matriz

de grafo pode ser encontrada na figura 19.

30 A complexidade ciclomática é uma métrica de software que fornece uma medida quantitativa da complexidade lógica de um programa.

Fonte: (KATIA, 2007)

Figura 18: Exemplo de Grafo de Fluxo de Controle

71

Teste de Estrutura de Condição

Roger Pressman afirma que “teste de condição é um método de projeto de caso

de teste que exercita as condições lógicas contidas em um módulo de programa”,

(PRESSMAN, 2006, p.325).

De acordo com a definição acima, conclui-se que o teste de condição se preocupa

em testar todas as operações de condição do sistema para garantir que eles não

apresentem problemas.

Neste caso a atenção deste teste é voltada aos operadores de comparação como:

<, >, = e etc e operadores compostos como E(&), OU(|) e NÃO(¬). Uma condição

sem estes operadores é considerada uma operação booleana, (PRESSMAN,

2006, p.325).

Desta forma, é possível concluir que o objetivo do teste de estrutura de condição

é identificar e testar todas as regras condicionais existentes na aplicação.

Fonte: (CYBIS, 2007)

Figura 19: Exemplo de Matriz de Grafo

72

Teste de Estrutura de Ciclos

Roger Pressman afirma que “teste de Ciclo é uma técnica de teste caixa branca

que focaliza exclusivamente a validade de construções de ciclo”, (PRESSMAN,

2006, p.326).

Com isto é possível entender que esta técnica tem como objetivo principal se

preocupar com os ciclos (loops) existentes no código da aplicação.

Boris Beizer indica quatro diferentes classes de cliclos, (BEIZER, 1990):

1. Ciclos Simples – Ciclos simples tratam apenas de passagens pelos ciclos,

onde é definida a quantidade de vezes em que o teste passa dentro deste

ciclo. Esta quantidade pode variar de nenhuma até N vezes, sendo criado

um caso de teste para cada caso do passagem pelo ciclo.

2. Ciclos Aninhados – Neste caso tem-se um ou mais ciclos dentro de um

outro, se fosse aplicada a técnica de ciclos simples o número de testes de

ciclos poderia ser impraticável. Para tanto, a técnica de ciclos aninhados

diz para trabalhar primeiro os ciclos internos deixando todos os outros

ciclos com valores mínimos, desta forma ir trabalhando estes ciclos de

dentro para fora, mantendo os valores de teste dos ciclos internos até que

todos os ciclos tenham sido testados.

3. Ciclos Concatenados – Neste caso é possível utilizar uma das duas

técnicas apresentadas acima, quando um ciclo é independente do outro, é

sugerido que se utilize a técnica de ciclos simples, se houver dependência

entre os ciclos então é recomendada a técnica de ciclos aninhados.

4. Ciclos Desestruturados – Sempre que possível, esta classe de ciclos

deve ser reprojetada para refletir o uso de construções de programação

estruturada.

73

3.4.2 Teste de Caixa-Preta

O teste de caixa preta ao contrario do teste de caixa branca não tem qualquer

preocupação com a estrutura interna do sistema. O teste de caixa preta é um

teste funcional e sua principal preocupação é se o componente ou o sistema

fazem o que foram projetados para fazer.

Roger Pressman afirma que “o teste de caixa preta permite ao engenheiro de

software derivar conjuntos de condições de entrada que vão exercitar plenamente

todos os requisitos funcionais de um programa”, (PRESSMAN, 2006, p.327).

Desta forma o teste de caixa preta pode encontrar erros nas seguintes categorias,

(PRESSMAN, 2006, p.327):

● Funções incorretas ou omitidas;

● Erros de interface;

● Erros de estrutura de dados ou de acesso a base de dados externas;

● Erros de comportamento ou desempenho;

● Erros de iniciação e termino.

Os testes de caixa preta são executados normalmente ao final do

desenvolvimento do componente ou do sistema. Isto faz com que ele se preocupe

mais com a percepção de um usuário do que a percepção dos desenvolvedores.

O teste de caixa preta assim como o teste de caixa branca também contém

técnicas de teste que geram maior valor aos resultados obtidos pelos casos de

teste, como apresentado a seguir.

Testes Baseados em Grafo

No caso do teste de caixa preta, o grafo representa os objetos do sistema e suas

relações, desta forma tem-se um desenho da estrutura do sistema para que

sejam gerados os casos de teste.

74

Roger Pressman apresenta da seguinte forma, que “o teste de software começa

criando um grafo dos objetos importantes e de suas relações e depois

estabelecendo uma série de testes que vão cobrir o grafo de modo que cada

objeto e relação sejam exercitados e que os erros sejam descobertos”,

(PRESSMAN, 2006, p.327).

Desta forma o grafo é apenas uma base que será utilizada por outros métodos

para gerar casos de teste que resultam em bons resultados. Boris Beizer

descreve alguns métodos de teste de comportamento que podem fazer uso dos

grafos, (BEIZER, 1990):

1. Modelagem de Fluxo de Transação – Os nós representam passos em

alguma transação (por exemplo, os passos necessários para fazer uma

reserva em uma linha aérea usando um serviço on-line), e as ligações

entre os nós do grafo representam as conexões lógicas entre os passos.

2. Modelagem de Estado Finito – Os nós representam diferentes estados do

software observáveis pelo usuário e as ligações entre os nós do grafo

representam as transições que ocorrem para ir de um estado para outro

estado.

3. Modelagem de Fluxo de Dados – Os nós representam objetos de dados e

as ligações entre os nós do grafo representam as transformações que

ocorrem para traduzir um objeto de dados em outro.

4. Modelagem de Tempo – Os nós representam objetos de programa e as

ligações, as conexões seqüenciais entre esses objetos. Os pesos das

ligações são usados para especificar os tempos de execução necessários

enquanto o programa é executado.

75

Particionamento de Equivalência

Roger Pressman informa que “o particionamento de equivalência é um método de

teste caixa-preta que divide o domínio de entrada de um programa em classes de

dados, das quais os casos de teste podem ser derivados. Um caso de teste ideal

descobre sozinho uma classe de erros, que poderia de outra forma exigir que

muitos casos fossem executados antes que um erro geral fosse observado”,

(PRESSMAN, 2006, p.329).

Neste caso é possível entender que o particionamento de equivalência tem como

objetivo principal a redução de casos de teste que gerem um retorno de erro

através dos valores de entrada informados a aplicação, gerados através da

análise das classes de equivalência31.

“Se o conjunto de objetos puder ser ligado por relações simétricas, transitivas e

reflexivas, uma classe de equivalência estará presente”, (BEIZER, 1995).

Roger Pressman nos informa algumas diretrizes que definem uma classe de

equivalência, (PRESSMAN, 2006, p.329):

1. Se uma condição de entrada especifica um intervalo, uma classe de

equivalência válida e duas inválidas são definidas.

2. Se uma condição de entrada exige um valor específico, uma classe de

equivalência válida e duas inválidas são definidas.

3. Se uma condição de entrada especifica o membro de um conjunto, uma

classe de equivalência válida e uma inválida são definidas.

4. Se uma condição de entrada é booleana, uma classe de equivalência

válida e uma inválida são definidas.

31 Uma classe de equivalência representa um conjunto de estados válidos ou inválidos para condições de entrada. Tipicamente uma condição de entrada é um valor numérico específico, um intervalo de valores, um conjunto de valores relacionados ou uma condição booleana. (PRESSMAN, 2006, p.329)

76

A partir destas diretrizes é possível gerar os casos de teste para cada um dos

valores de entrada definidos. Os casos de teste devem ser selecionados de modo

que o maior número de atributos de uma classe de equivalência seja exercitado

ao mesmo tempo, (PRESSMAN, 2006).

Os casos de teste criados a partir destas classes de equivalência tem uma grande

chance de encontrar um erro, a partir destes valores é possível gerar as

combinações mais adequadas de casos de teste para a aplicação.

Análise de Valor Limite

A técnica de análise de valor limite(AVL) tem como objetivo gerar casos de teste

que testem os valores de limite de um determinado parâmetro de entrada. Esta

técnica é um complemento a técnica de particionamento de equivalência, assim

ao invés de se selecionar todos os valores das classes de equivalência, a AVL

leva os casos de teste até as fronteiras da classe.

“Um grande número de erros ocorre nas fronteiras do domínio de entrada em vez

de no 'centro'. É por esta razão que a análise de valor limite (boundary value

analysis) foi desenvolvida”, (PRESSMAN, 2006, p.329).

É muito comum que os engenheiros de software apliquem os valores limite nos

casos de teste intuitivamente, entretanto os resultados obtidos podem não ser tão

satisfatórios como se houver a utilização de uma diretriz.

Devido a estas dificuldades, Roger Pressman indica algumas diretrizes para a

AVL, (PRESSMAN, 2006, p.329-330):

1. Se uma condição de entrada especifica um intervalo limitado pelos valores

a e b, casos de teste devem ser projetados com os valores a e b, e

imediatamente acima e imediatamente abaixo de a e b.

77

2. Se uma condição de entrada especifica vários valores, casos de teste

devem ser desenvolvidos para exercitar os números mínimo e máximo.

Valores imediatamente acima e imediatamente abaixo do mínimo e do

máximo também são testados.

3. Aplique as diretrizes 1 e 2 às condições de saída. Por exemplo, considere

que uma tabela de temperatura versus pressão é esperada como saída de

um programa de análise de engenharia. Casos de teste devem ser

projetados para criar um relatório de saída que produza o número máximo

(e mínimo) admissível de entradas na tabela.

4. Se as estruturas de dados internas do programa têm limites prescritos (por

exemplo um vetor tem um limite definido de 100 entradas), certifique-se de

projetar um caso de teste para exercitar a estrutura de dados no seu limite.

Ao seguir estas diretrizes, o engenheiro de software tem maiores chances de

encontrar um erro e se ele combinar esta técnica com a técnica de

particionamento de equivalência, há ainda a chance de diminuir a quantidade de

casos de teste que serão definidos para os valores do particionamento de

equivalência.

Teste de Matriz Ortogonal

O objetivo do teste de matriz ortogonal consiste em realizar testes que contém

valores múltiplos de entrada, e que nas técnicas convencionais ficariam

impraticáveis ou impossíveis devido a grande quantidade de valores a serem

testados, e propor uma técnica que distribui estes valores de modo a diminuir a

quantidade de combinações a ponto de reduzir a quantidade de casos de teste

necessários para a realização dos mesmos.

O “teste de matriz ortogonal pode ser aplicado a problemas nos quais o domínio

de entrada é relativamente pequeno, mas grande demais para acomodar o teste

78

exaustivo. O método de teste de matriz ortogonal é particularmente útil para

encontrar erros associados com falhas de regiões – uma categoria de erros

associada com lógica defeituosa em um componente de software”, (PRESSMAN,

2006, p.330).

Num exemplo do livro de Roger Pressman (PRESSMAN, 2006, p.330-331) onde

existem quatro parâmetros e cada um dos quatro parâmetros pode receber três

valores distintos, são gerados 81 possíveis casos de teste nas técnicas

combinatórias convencionais, no entanto ao aplicar a técnica de matriz ortogonal

o número de casos de teste para esta mesma situação passou para 9.

Para o caso acima foi apresentada uma avaliação dos resultados da matriz

ortogonal como, (PRESSMAN, 2006, p.331):

● Detecta e isola todas as falhas de modo singular. Uma falha singular é

um problema consistente com qualquer nível de qualquer parâmetro

singular.

● Detecta todas as falhas de modo duplo. Se existe um problema

consistente quando níveis específicos de dois parâmetros ocorrem

simultaneamente, ele é chamado de falha de modo duplo.

● Falhas de multimodo. Matrizes ortogonais podem garantir a detecção

apenas de falhas de modo singular e duplo. No entanto, muitas falhas de

multimodo são também detectadas por esses testes.

Desta forma é possível compreender que ao utilizar matrizes ortogonais para os

casos onde há uma grande quantidade de parâmetros de entrada, é possível

reduzir significativamente a quantidade de casos de teste necessários para a

garantia de uma determinada classe de erros.

79

3.5 Automação de Teste de Software

A automação de testes consiste em executar de forma automática casos de teste

escritos para basicamente três tipos de testes, os testes unitários, os testes de

integração e os testes de sistema (que incorporam todos os outros tipos de teste

como de performance, de carga entre outros). A automação de testes de software

não substitui o planejamento e a documentação dos testes, ao contrário disto ela

é dependente do planejamento e da documentação.

A automação de testes não é uma obrigação, ela é uma opção e deve ser

levantada a sua viabilidade a cada caso. Muitas vezes o teste manual pode ser

mais eficiente e provavelmente mais barato do que um teste automatizado, a

automação tem um custo elevado e sua implantação precisa ser justificada.

“Criar um teste automatizado custa normalmente mais caro do que rodar o teste

manualmente uma vez”, (MARICK, 2007).

O caso acima ocorre porque o custo de implementar um teste automatizado é

alto, entretanto o teste de regressão (item 3.3.5) é quem muitas vezes justifica

este custo. Isto porque normalmente quando se trabalha um software que será

utilizado por muito tempo, este sofre inúmeras modificações e a cada modificação

há a necessidade de executar os casos de teste novamente para garantir o

funcionamento do legado. Com o aumento do tamanho do sistema e

conseqüentemente com o aumento dos casos de teste a serem executados, o

tempo necessário para a execução manual dos testes aumenta absurdamente,

justificando assim uma automação de teste.

É possível perceber este aumento do custo dos testes manuais devido ao teste de

regressão na figura 20, que mostra o tempo necessário para testar cada versão

do sistema de forma manual, e como é aumentado o tempo necessário para

efetuá-lo.

80

Entretanto, na figura 21 é possível perceber a diferença entre o aumento do custo

dos testes manuais e automáticos quando são aplicadas as regressões ao longo

das versões.

Fonte: Adaptado de (MANJON, 2007)

Figura 20: Aumento do tempo gasto com testes manuais

Fonte: Adaptado de (MANJON, 2007)

Figura 21: Custo de testes manuais e automáticos ao longo do tempo.

81

“O custo diferencial varia, dependendo do produto e do estilo de automação”,

(MARICK, 2007).

Brian Marick aponta em seu artigo algumas perguntas que respondidas podem

auxiliar na escolha da viabilidade da automatização um determinado caso de

teste, (MARICK, 2007):

1. Automatizar este teste e executá-lo uma vez custa mais do que

simplesmente rodar o teste uma vez manualmente? Quanto é este custo a

mais?

2. Um teste automatizado tem um tempo de vida finito, durante este tempo

ele tem que recompensar o custo adicional. Que eventos são necessários

para completa-lo?

3. Durante este tempo de vida, qual a possibilidade deste teste encontrar

erros adicionais (além dos encontrados na primeira execução)? Como este

benefício incerto se equilibra com o custo da automação?

Destas perguntas a terceira é provavelmente a mais importante delas. Com ela é

possível estimar qual será o valor agregado da automação daquele teste, porém

apesar das três questões a decisão sobre automatizar ou não um determinado

teste pode ficar incerta, neste caso é necessário levar em consideração maiores

detalhes em relação ao teste, ao produto e a automação do mesmo.

“Automação não é uma bala de prata; ela apenas traz alguns problemas. Para

resolver o problema de automação, defina a metodologia de testes, então escolha

direito a tecnologia que irá ajudar você a implementar a metodologia”, (NGUYEN,

2006, p.34).

Os autores Hung Nguyen, Michael Hackett e Brent K. Whitlock após a citação

apresentada, mostram três características que devem ser analisadas ao escolher

a metodologia utilizada, (NGUYEN, 2006, p.34):

82

• Visibilidade – Deve mostrar exatamente o que está acontecendo, é

necessário que se possa obter informações da situação atual dos testes, a

metodologia deve estar visível para que seja acompanhada.

• Reusabilidade e Escalabilidade – Estes dois fatores permitem que esta

metodologia não seja descartada, desta forma a escalabilidade permite que

a metodologia cresça juntamente com o sistema e que não se perca o

trabalho anterior, e a reusabilidade permite que se economize tempo

reutilizando documentos, casos de uso entre outros.

• Manutenabilidade – Permite que a metodologia sofra manutenções,

correções e ajustes de forma simples para poder evoluir sem se

transformar num impecílio ao processo de desenvolvimento.

A figura 22 apresenta os benefícios tangíveis referentes a uma boa automação de

testes que contém as três características apresentadas. Estes benefícios ocorrem

apenas se a automação tiver sucesso total, se a escolha pela automação correta

não for bem planejada é possível gerar prejuízos ainda maiores do que os ganhos

apresentados.

Fonte: Adaptado de (NGUYEN, 2006, p.34)

Figura 22: Resultados de uma boa automação de testes.

83

“Pense na equação do retorno sobre investimento (return of investiment, ROI),

com os benefícios de um lado e os custos de outro. Para os benefícios considere

a produtividade, ambos em quantidade e qualidade dos testes. Para o lado da

equação do custo, pense sobre a reusabilidade, escalabilidade e

manutenabilidade dos testes em contexto com o esforço necessário para as fases

da automação de testes”, (NGUYEN, 2006, p.35).

Eles consideram como esforço de automação os seguintes itens:

● Custos de Implantação

● Custo da Criação dos testes automatizados

● Custo de execução

● Custo de Manutenção

E eles sugerem que o ROI seja avaliado considerando que estes custos sejam

justificados por:

● Maior Velocidade/Mais testes?

● Maior Velocidade/Mais ciclos de testes?

● Melhor cobertura de testes a cada ciclo?

● Melhor qualidade dos testes?

Para poder fazer todas estas avaliações é necessário que se tenha uma boa

visibilidade.

Uma atividade que auxilia muito a criação de testes automatizados é a existência

de um processo de Build32 Automatizado e/ou a intenção de implementar

Integração Contínua33 no desenvolvimento do software em questão.

32 Processo de Build é o processo de compilar o sistema gerando os binários, a automação deste processo tem a função de ocupar menos tempo com esta tarefa.

33 A integração contínua consiste numa série de regras para integrar o sistema, maiores detalhes podem ser encontrados em: http://www.martinfowler.com/articles/continuousIntegration.html

http://www.martinfowler.com/articles/continuousIntegration.html

84

3.5.1 Automação de testes de unidade

A automação dos testes de unidade são efetuados através de frameworks34

conhecidos como XUnit, que contém uma estrutura pré-definida e apóia uma

determinada linguagem a gerar testes de unidade.

“Kent Beck publicou um framework de teste unitário para a linguagem Smalltalk

em 1999. A arquitetura do SmalltalkUnit (SUnit) representa uma marca doce, um

balanço ideal entre simplicidade e utilidade. Depois, Erich Gamma portou o SUnit

para java, criando o JUnit. JUnit foi base por sua vez aos CppUnit, NUnit, PyUnit,

XMLUnit e foram portados para muitas outras linguagens. Esta estonteante

formação dos frameworks de teste unitário foram criados com modelos similares

aos utilizados hoje. Estes frameworks são conhecidos como familia de aplicativos

XUnit. Todos são livres e softwares open-source35”, (HAMILL, 2004, p.18).

De acordo com a história apresentada acima, é possível perceber que os

frameworks XUnit são dependentes de uma linguagem de programação

específica e devido a isto existe uma limitação de linguagens que tem este tipo de

software disponível, se não for encontrado nenhum framework disponível para a

linguagem desejada, ainda há a possibilidade de se desenvolver um pois como

este framework é livre e tem seu código aberto há uma grande facilidade para

portar uma destas aplicações.

Kent Back informa algumas recomendações sobre a automação dos testes de

unidade. “Eu recomendo que os desenvolvedores escrevam seus próprios casos

de teste, um por classe. O framework suporta a escrita de conjuntos de testes,

que podem ser vinculados a uma classe.” e faz outra recomendação. “Eu

recomendo que os desenvolvedores gastem 25-50% do tempo de

desenvolvimento em testes”, (BACK, 2007).

34 Um Framework ou Arcabouço é uma estrutura de suporte definida em que um outro projeto de software pode ser organizado e desenvolvido.

35 Softwares Open-Source são uma classificação de softwares que tem seu código fonte disponível para leitura e dependendo da licença também para modificação.

85

Desta forma ele reforça que os testes de unidade devem ser escritos por

desenvolvedores, e que os desenvolvedores devem investir um tempo

considerável do seu trabalho desenvolvendo estes testes unitários.

A automação dos testes de unidade são programados, ou seja, necessitam que

desenvolvedores escrevam um programa de teste para testar a unidade da

aplicação. Estes programas utilizam os frameworks XUnit como suporte para a

escrita, a validação e a apresentação dos testes.

Kent Back também diz que “tente montar um punhado de dados de teste, então

rode este punhado de testes e então limpe a sujeira”, (BACK, 2007).

Com isto ele defende que os testes sejam independentes um dos outros, e que ao

executar um teste, o ambiente deve ser limpo, ou seja, uma sujeira restante de

uma execução qualquer pode afetar diretamente os testes subseqüentes.

A arquitetura de um framework XUnit é relativamente simples e todos eles

apresentam os mesmos elementos básicos. Quando Kent Back criou o SUnit ele

definiu em seu paper um padrão básico para esta estrutura que consiste em,

(KENT, 2007):

● Fixture (Instalação) – É referente a uma série de configurações que são

efetuadas antes da execução do teste, por exemplo a declaração de

variáveis que serão utilizadas.

● Test Case (Caso de Teste) – É o caso de teste que será executado, neste

momento é chamada a função que está sendo testada com os parâmetros

configurados e o retorno pode ser devolvido numa das variáveis criadas na

Fixture por exemplo.

● Check (Checagem) – Este item é conhecido atualmente como Assert nos

XUnits mais novos, e consiste em validar a resposta do Test Case, se foi a

resposta esperada, ou se foi um erro.

86

● Test Suite (Conjunto de Testes) – É um agrupamento de testes que podem

ser executados ao mesmo tempo, isto auxilia podendo diminuir o tempo de

execução dos testes.

Esta estrutura básica permite ao desenvolvedor escrever casos de teste de

unidade de forma automatizada, o principal benefício disto é que o teste de

regressão passa a ser muito simples e barato já que tendo os casos de teste

escritos e atualizados basta executá-los. Outro benefício desta automação é que

os desenvolvedores de certa forma já fazem testes unitários quando testam os

componentes que estão desenvolvendo para validar se estão de acordo com o

esperado, ao automatizar este teste, a criação deste teste pode ser efetuada

apenas uma vez e ser executada automaticamente em outros momentos.

Um ponto negativo desta forma de trabalho é o consumo de tempo de

desenvolvimento que deve crescer como indicado entre 25-50% para permitir um

bom desenvolvimento dos testes automatizados.

3.5.2 Automação de testes de integração

A automação dos testes de integração é muito parecida com a automação de

testes unitários, inclusive para este tipo de automação normalmente são utilizados

os mesmos frameworks XUnit.

Os testes de integração também são testes que necessitam de um conhecimento

em desenvolvimento, desta forma eles estimulam os componentes mais altos da

hierarquia validando se toda a comunicação está ocorrendo corretamente

(maiores detalhes sobre testes de integração no item 3.3.2).

Os testes de integração são executados a partir dos casos de teste gerados para

esta estratégia de teste. A automação deste tipo de teste pode ser desenvolvida

tanto por testadores quanto por desenvolvedores, porém se for desenvolvida por

87

um testador, este necessita de um conhecimento básico de programação na

linguagem do programa que será testado.

Kent Back quando escreveu sobre o framework do SUnit36 faz uma recomendação

para os testes de integração. “Eu recomendo que um testador independente

escreva os testes de integração”, (KENT, 2007).

A recomendação de Kent é confirmada por uma explicação de Roger Pressman

quando diz que “do ponto de vista do construtor, o teste pode ser considerado

(psicologicamente) destrutivo. Assim, o construtor segue suavemente, projetando

e executando testes que vão demonstrar que o programa funciona, em vez de

descobrir erros”, (PRESSMAN, 2006, p.290).

Sendo assim, é arriscado que a pessoa que construiu o sistema seja a mesma

pessoa a criar e executar os testes. Uma boa alternativa para este caso é treinar

os testadores para conhecer o mínimo da linguagem de programação a ponto de

poderem desenvolver os testes de integração automatizados, ganhando tempo

dos desenvolvedores e evitando problemas.

Como explicado anteriormente a automação dos testes de integração é muito

parecida com a automação dos testes unitários. Sua maior diferença é que para

os testes de integração funcionarem, uma “configuração” mínima do ambiente de

teste deve ter sido efetuada preparando os componentes para a execução, o que

inclui muitas vezes uma configuração prévia de uma base de dados.

Em resumo para se automatizar um teste de integração, é preciso obedecer

alguns passos apresentados anteriormente. Seguem as atividades necessárias

para automação dos testes de integração ordenadas:

1. Preparar o ambiente para o teste, assim como todas as dependências

necessárias;

36 Todas as definições deste framework de XUnit são explicados no item 3.5.1.

88

2. Desenvolver o teste estimulando as regras de negócio encontradas nos

componentes de hierarquia mais alta;

3. Limpar o ambiente para que o próximo teste seja executado sem chance

de erros devido à algum vestígio do teste anterior.

Dentre alguns dos benefícios da automação dos testes de integração estão o

baixo custo do teste de regressão assim como para a automação dos testes

unitários, e a maior cobertura de testes em relação a regras de negócio devido ao

exercício das partes mais altas da hierarquia dos componentes.

Alguns dos pontos negativos são o alto custo para preparar o ambiente antes de

cada teste, a manutenção, o acompanhamento constante e o tempo utilizado

tanto por um desenvolvedor ou um testador que tenham que desenvolver este

teste de forma automatizada.

3.5.3 Automação de testes de sistema

Como apresentado no item 3.3.3, o teste de sistema engloba uma série de outros

testes. Desta forma são apresentadas as ferramentas mais comuns referentes a

automação de testes de sistema.

“As principais técnicas de automação de teste apresentadas na literatura são:

record & playback, programação de scripts, data-driven e keyword-driven”,

(ROMEU, 2007).

Leonardo Romeu, Luciana Belleza e Paulo Gil nos apresentam a definição de

cada uma das técnicas apresentadas como, (ROMEU, 2007):

● Record & Playback (Gravação e Reprodução) - Consiste em, utilizando

uma ferramenta de automação de teste, gravar as ações executadas por

um usuário sobre a interface gráfica de uma aplicação e converter estas

ações em scripts de teste que podem ser executados quantas vezes for

89

desejado. Cada vez que o script é executado, as ações gravadas são

repetidas, exatamente como na execução original. Para cada caso de teste

é gravado um script de teste completo que inclui os dados de teste (dados

de entrada e resultados esperados), o procedimento de teste (passo a

passo que representa a lógica de execução) e as ações de teste sobre a

aplicação.

A vantagem da técnica record & playback é que ela é bastante simples e

prática, sendo uma boa abordagem para testes executados poucas vezes.

Entretanto, são várias as desvantagens desta técnica ao se tratar de um

grande conjunto de casos de teste automatizados, tais como: alto custo e

dificuldade de manutenção, baixa taxa de reutilização, curto tempo de vida

e alta sensibilidade a mudanças no software a ser testado.

Um exemplo de problema desta técnica de automação de software é que

se for alterada a dimensão da interface gráfica do sistema, provavelmente

todos os testes gerados deverão ser regravados de acordo com a nova

configuração.

● Scripts (Manuscrito) - É uma extensão da técnica record & playback.

Através da programação, os scripts de teste gravados são alterados para

que desempenhem um comportamento diferente do script original durante

sua execução. Para que esta técnica seja utilizada, é necessário que a

ferramenta de gravação de scripts de teste possibilite a edição dos

mesmos. Desta forma, os scripts de teste alterados podem contemplar uma

maior quantidade de verificações de resultados esperados, as quais não

seriam realizadas normalmente pelo testador humano e, por isso, não

seriam gravadas. Além disso, a automação de um caso de teste similar a

um já gravado anteriormente pode ser feita através da cópia de um script

de teste e sua alteração em pontos isolados, sem a necessidade de uma

nova gravação. Em comparação com a técnica record & playback, esta

técnica apresenta maior taxa de reutilização, maior tempo de vida, melhor

manutenção e maior robustez dos scripts de teste. No exemplo de uma

alteração na interface gráfica da aplicação, seria necessária somente a

90

alteração de algumas partes pontuais dos scripts de teste já criados.

Entretanto um problema gerado por esta técnica é que a quantidade de

scripts é muito grande e com códigos difíceis de ler devido a dados de

teste e o procedimento de teste que estão contidos dentro do script.

● Data-Driven (Orientada a Dados) - Consiste em extrair, dos scripts de

teste, os dados de teste, que são específicos por caso de teste, e

armazená-los em arquivos separados dos scripts de teste. Os scripts de

teste passam a conter apenas os procedimentos de teste (lógica de

execução) e as ações de teste sobre a aplicação, que normalmente são

genéricos para um conjunto de casos de teste. Assim, os scripts de teste

não mantêm os dados de teste no próprio código, obtendo-os diretamente

de um arquivo separado, somente quando necessário e de acordo com o

procedimento de teste implementado. A principal vantagem da técnica

data-driven é que se pode facilmente adicionar, modificar ou remover

dados de teste, ou até mesmo casos de teste inteiros, com pequena

manutenção dos scripts de teste. Esta técnica de automação permite que o

projetista de teste e o implementador de teste trabalhem em diferentes

níveis de abstração, dado que o projetista de teste precisa apenas elaborar

os arquivos com os dados de teste, sem se preocupar com questões

técnicas da automação de teste.

● Keyword-Driven (Orientada a Palavras-Chave) - Consiste em extrair, dos

scripts de teste, o procedimento de teste que representa a lógica de

execução. Os scripts de teste passam a conter apenas as ações

específicas de teste sobre a aplicação, as quais são identificadas por

palavras-chave. Estas ações de teste são como funções de um programa,

podendo inclusive receber parâmetros, que são ativadas pelas palavras-

chave a partir da execução de diferentes casos de teste. O procedimento

de teste é armazenado em um arquivo separado, na forma de um conjunto

ordenado de palavras-chave e respectivos parâmetros. A principal

vantagem da técnica keyword-driven é que se pode facilmente adicionar,

91

modificar ou remover passos de execução no procedimento de teste com

necessidade mínima de manutenção dos scripts de teste, permitindo

também que o projetista de teste e o implementador de teste trabalhem em

diferentes níveis de abstração.

As ferramentas que fornecem suporte aos testes de sistema geralmente integram

uma ou mais destas técnicas de automação, desta forma o sistema passa a exibir

características que permitem ser empregadas na execução de vários tipos de

testes de sistema, como os testes funcionais, os testes de performance, os testes

de carga de dados e etc.

Um exemplo de combinação de técnicas é a geração dos scripts de teste a partir

da técnica de record & playback que permitem uma criação de scripts de forma

simples e rápida, e garante a facilidade de manutenção a partir dos scripts já

criados evitando o trabalho de uma nova gravação devido as mudanças.

Dentre as ferramentas que empregam uma ou mais destas habilidades podem ser

citadas:

1. Rational Functional Tester (RFT) – Ferramenta da IBM para automação

de testes de sistema.

2. Mercury WinRunner – Ferramenta da HP para automação de testes de

sistema.

3. E-Test – Ferramenta da Empirix para automação de testes de aplicações

Web.

4. JMeter – Ferramenta de código aberto da Jakarta, teve seu inicio voltado

para testes de carga porém evoluiu para outros tipos de teste de sistema.

5. Silk Test – Ferramenta da Borland para automação de testes de sistema.

92

Todas estas ferramentas utilizam uma ou mais técnicas de automação

apresentadas, cada qual com uma abrangência diferente em relação as

estratégias de teste que atendem.

“Três diferentes interfaces de produto podem ser interfaces de linha de comando

(Command Line Interfaces, CLI), Interfaces de Programação de Aplicação

(Application Programming Interfaces, API) e Interface Gráfica de Usuário

(Graphical User Interface, GUI). Alguns podem ter todas as três, mas a maioria

tem apenas uma ou duas. Estas são as interfaces disponíveis para você testar”,

(PETTICHORD, 2007).

De acordo com esta informação, as ferramentas apresentadas acima estão mais

direcionadas para os testes de GUI, deixando de testar as outras interfaces.

Entretanto Bret Pettichord nos apresenta que APIs e CLIs são mais fáceis de

serem testadas, e ainda apresenta que estas duas alternativas para teste evitam

muitos problemas encontrados em testes de GUI através da técnica record &

playback, (PETTICHORD, 2007).

Quando o sistema disponibiliza uma destas interfaces para teste, há a

possibilidade de se aproveitar a ferramenta xUnit apresentada como alternativa

para testes de unidade e de integração. Nos testes de sistema esta ferramenta

também pode ser utilizada, evitando os problemas que um teste de sistema

através da GUI possa apresentar.

Com as opções apresentadas acima, é possível entender que existem diversas

possibilidades para automação de testes de sistema, em diferentes interfaces da

aplicação e em diferentes níveis de abstração.

93

4 SISTEMAS DE SOFTWARES LEGADOS

Calvin Lawrence define legados como “sistemas de TI ativos que foram

desenvolvidos no passado. Estes sistemas podem ter sido instalados em qualquer

lugar, de ontem até vinte anos atrás” e que “software legado e aplicações são

muitas vezes considerados como ´carro chefe´ da organização, geralmente

gerando altos lucros” e complementa dizendo que “tipicamente os lucros

fornecidos por ele excedem o valor necessário para dar manutenção ao legado, e

o excedente é as vezes utilizado pela companhia para financiar outras iniciativas

estratégicas”, (LAWRENCE, 2007).

Uma outra definição para software legado é citada por Roger Pressman dizendo

que “Sistemas de software legado (...) foram desenvolvidos décadas atrás e tem

sido continuamente modificados para satisfazer as mudanças nos requisitos de

negócio e nas plataformas de computação. A proliferação de tais sistemas está

causando dor de cabeça para grandes organizações que os consideram

dispendiosos de manter e arriscados de evoluir”, (PRESSMAN, 2006, p.8).

Entretanto Roger Pressman aponta em seguida outra citação que complementa a

anterior alegando que “muitos sistemas legados permanecem dando suporte a

funções importantes do negócio e são indispensáveis para o negócio”,

(PRESSMAN, 2006, p.8).

Desta forma é possível concluir que um sistema legado é qualquer sistema que

tenha sido implantado e está em uso atualmente. É possível deduzir também que

se estes sistemas ainda estão em uso, ou ainda geram muito lucro (que

dificilmente poderia ser obtido com outro substituto), ou são operações vitais para

a empresa no qual o risco da migração seria muito alto.

De acordo com as definições é possível perceber que um software legado não

está vinculado a uma tecnologia, um paradigma de desenvolvimento, uma

metodologia de trabalho ou uma linguagem de programação. Como eles “podem

94

ter sido instalados em qualquer lugar, de ontem até vinte anos

atrás” (LAWRENCE, 2007), a quantidade de possibilidades de linguagens e

tecnologias utilizadas é extremamente abrangente.

Apenas para exemplificar um destes sistemas de software legado que tem

importância vital para a empresa, os bancos mantém seus sistemas de controle

das transações bancárias em Cobol até os dias de hoje pois o risco de migração

de um sistema destes é altíssimo, além do mais o risco de um sistema novo

incluir um erro no sistema é alto e os prejuízos seriam absurdos. É devido a estas

e outras razões que os bancos mantém seus controles num sistema legado.

Calvin Lawrence indica que os sistemas legados se classificam normalmente em

uma ou mais das classificações apresentadas abaixo, (LAWRENCE, 2007):

● Tela Verde (Green Screen) – É uma aplicação baseada em caracteres

típica, tal como um terminal 3270 acessando um sistema Mainframe

CICS®

● Cliente Gordo (Fat Client) – Permite acesso a uma única aplicação de

legado usando uma interface gráfica de usuário (GUI) que fica instalada na

estação de trabalho do cliente, tipicamente um Windows®-Based PC

(Computador Pessoal baseado em Janelas).

● Múltiplas Sessões (Multiple Sessions) - Indica um processo de negócio

que exige um único operador ter múltiplas sessões ativas através de

múltiplas aplicações, e o operador deve executar as atividades numa

seqüência prescrita.

● Muitos P2Ps – As interfaces com aplicações de legado foram

desenvolvidas ao longo do tempo, com uma interface ponto a ponto entre o

sistema legado e cada sistema dependente.

● Limitação de Legado (Legacy Constraint) – Significa que uma

95

implementação técnica limita a capacidade de expansão do legado.

● Legado Enterrado (Buried Legacy) – Indica que após passado o tempo,

por causa da indiferença da aplicação de legado e crescentes exigências

de melhorias, uma série de aplicações distribuídas cercou, estendeu e

enterrou a aplicação de legado, sendo que estes processos de negócio

estão espalhados através de múltiplos sistemas.

Ele também apresenta o termo “Reabilitação de Legado”37, que é o processo em

que se pega o sistema existente e possíveis informações e então faz com que

este sistema seja utilizado em novos processos de negócio, (LAWRENCE, 2007).

Esta parte da reabilitação de legado está melhor definida no item 4.2.

4.1 A qualidade do software legado

Roger Pressman nos apresenta que “infelizmente, existe uma característica

adicional que pode estar presente no software legado – má qualidade38. Sistemas

legados, algumas vezes, têm projetos não-extensíveis, código complicado,

documentação pobre ou inexistente, casos de teste e resultados que nunca foram

arquivados, um histórico de modificações mal gerido – a lista pode ser bem

longa”, (PRESSMAN, 2006, p.8).

De acordo com o texto, é possível entender que houveram muitos sistemas

legados que em sua época de criação utilizaram métodos hoje considerados

inadequados para o desenvolvimento de software, desta forma estes métodos são

considerados ruins na atualidade gerando a fama de que softwares legados tem

uma má qualidade.

37 O termo original em inglês é “Legacy enablement”.38 Neste caso, a qualidade é julgada com base no pensamento moderno de engenharia de

software – critério um pouco injusto, tendo em vista que alguns conceitos e princípios modernos de engenharia de software podem não ter sido bem entendidos na época em que o software legado foi desenvolvido.

96

Independentemente dos métodos utilizados na criação de alguns softwares

legados serem ultrapassados, houveram os softwares desenvolvidos com uma

má qualidade devido a pouca experiência dos desenvolvedores (problemas que

ocorrem até os dias de hoje, mesmo com os novos métodos). Isto é ainda mais

agravado quando este sistema evolui passando por muitos desenvolvedores

diferentes e cada um efetua as modificações do seu jeito.

Roger Pressman diz que a melhor solução para este problema de má qualidade

pode ser simplesmente não fazer nada, (PRESSMAN, 2006, 9).

Entretanto ele mesmo apresenta algumas razões pelas quais os sistemas legados

tendem a se manter em evolução constante, o que nos impede de simplesmente

não fazer nada, (PRESSMAN, 2006, 9):

● O software precisa ser adaptado para satisfazer as necessidades do novo

ambiente ou tecnologia computacional.

● O software precisa ser aperfeiçoado para implementar novos requisitos de

negócio.

● O software precisa ser estendido para torná-lo interoperável com os

sistemas ou bancos de dados modernos.

● O software precisa ser rearquitetado para torná-lo viável em um ambiente

de rede.

É possível deduzir então que todos os sistemas encontrados em uso no mundo

real sofrerão modificações com o passar do tempo, seja para correção de erros

encontrados, seja para aperfeiçoamento (melhoria de performance, melhoria da

escalabilidade, alguma evolução para compatibilidade com outro sistema e etc) ou

qualquer outro motivo.

Desta forma, o estudo da evolução dos sistemas se torna necessário para

97

conhecer as possíveis dificuldades pelas quais o sistema deverá passar, porém

como este assunto não é foco deste trabalho, será apresentada apenas uma

breve introdução.

Roger Pressman apresenta em seu livro que “durante os últimos 30 anos, Manny

Lehman e seus colegas realizaram análises detalhadas de software e sistemas de

qualidade industrial em um esforço para desenvolver uma teoria unificada para

evolução de software”, (PRESSMAN, 2006, p.9).

O resultado deste esforço foi um trabalho dos quais saíram algumas leis das

quais Roger Pressman cita algumas derivações, (PRESSMAN, 2006, p.9):

● Lei da Modificação Contínua (1974) – Sistemas tipo-E39 devem ser

continuamente adaptados ou então eles se tornam progressivamente

menos satisfatórios.

● Lei da Complexidade Crescente (1974) – À medida que um sistema tipo-

E evolui sua complexidade aumenta, a menos que seja realizado esforço

para mantê-la ou reduzi-la.

● Lei da Auto-Regulação (1974) – O processo de evolução de sistemas

tipo-E é auto-regulatório, com medidas de distribuição do produto e do

processo perto do normal.

● Lei da Conservação da Estabilidade Organizacional (1980) – A

velocidade média da atividade global efetiva em um sistema evolutivo tipo-

E é invariante ao longo do tempo de vida do produto.

● Lei da Conservação da Familiaridade (1980) – À medida que um sistema

tipo-E evolui, todos os que estão a ele associados, desenvolvedores,

pessoal de vendas e usuários, por exemplo, devem manter o domínio de

seu conteúdo e comportamento para conseguir evolução satisfatória. O

39 Sistemas Tipo-E são softwares que foram implementados em um sistema de computação do mundo real e, portanto, evoluirão com o tempo.

98

crescimento excessivo diminui esse domínio. Assim, o crescimento médio

incremental permanece invariante à medida que o sistema evolui.

● Lei do Crescimento Contínuo (1980) – O conteúdo funcional de sistemas

tipo-E deve ser continuamente aumentado para manter a satisfação do

usuário ao longo do tempo de vida do sistema.

● Lei da Qualidade Declinante (1996) – A qualidade de sistemas tipo-E

parecerá estar declinando a menos que eles sejam rigorosamente

mantidos e adaptados às modificações no ambiente operacional.

● Lei de Realimentação do Sistema (1996) – Os processos de evolução

tipo-E constituem sistemas de realimentação em multiníveis, em

multiciclos, por multiagentes, e precisam ser tratados como tal para

conseguir aperfeiçoamento significativo sobre qualquer base razoável.

A partir da leitura destas leis é possível compreender que boa parte delas

constituem parte do dia a dia das pessoas que trabalham com sistemas. Estas

leis representam de forma adequada problemas que podem se gerados se um

acompanhamento correto da evolução do sistema não estiver sendo efetuado.

Além disso, Calvin Lawrence apresenta quais são os pontos principais que

incomodam nos sistemas legados, (LAWRENCE, 2007):

● Alto custo de posse, incluindo custo de manutenção, operação e

atualização ambos de hardware e software. Exemplo: Preço por CPU

utilizada nos Mainframes.

● Diminui o tempo de vida por causa de complexidade e baixa compreensão

do código. Isto pode impedir o sistema de satisfazer os requisitos de

negócio porque mudanças simples se tornam muito longas de fazer e

testar. As mudanças tendem a causar efeitos significativos de ondulação e

exigem mais testes de regressão. Isto aumenta manutenção e custos de

99

evolução.

● Arquitetura monolítica com pouca ou nenhuma modularidade junto com

código redundante. Isto normalmente é relacionado a patches40 extensos e

modificações, assim como funcionalidades duplicadas e/ou muito parecidas

implementadas em sistemas diferentes por equipes distintas.

● Tecnologia fechada e antiga que é difícil de integrar e interfacear com

novas tecnologias abertas e arquiteturas distribuídas.

● Diminuição de desenvolvedores habilidosos no sistema legado e perda de

suporte do vendedor. O conhecimento destes sistemas normalmente é

ligado a um grupo de funcionários que se tornam difíceis de substituir.

● A falta de conhecimento da aplicação devido à partida de desenvolvedores

ou usuários, assim como documentação perdida ou obsoleta.

Desta forma podemos compreender que a existência do sistema legado para a

organização é ao mesmo tempo importante para o bom andamento do negócio,

como uma grande fonte de preocupações para quem é responsável por sua

administração.

Com base em todas estas informações, é possível perceber que os sistemas

legados normalmente apresentam problemas em relação a qualidade com a qual

foi desenvolvido, e para aumentar os problemas sua manutenção e

acompanhamento tem um custo muito alto para a organização.

A substituição ou reengenharia de um sistema legado é muitas vezes aceita,

assumindo-se os riscos desta migração, devido aos problemas causados por um

sistema legado. Infelizmente esta substituição e reengenharia não são viáveis e

as empresas continuam mantendo os legados.

40Patches são pacotes contendo atualizações ou evoluções do sistema, que são atualizados a um sistema em produção.

100

4.2 Transformação de sistema legado

Com o que foi visto até o momento é possível perceber que os sistemas legados ,

apesar de sua vital importância para o negócio tem se tornado um incomodo para

muitas empresas. Desta forma, como não é possível simplesmente substituir ou

ignorar o sistema legado, as empresas vêem tentado modificar o sistema legado

para que ele possa gerar ainda mais valor, justificando assim os seus custos.

“Um dos maiores problemas em solucionar os pontos de incomodo41 é descobrir e

identificar as funcionalidades úteis do sistema legado e as tarefas que podem ser

expostas como serviços para serem utilizadas por outras aplicações que podem

consumir estes serviços”, (LAWRENCE, 2007).

A transformação de um sistema legado pode acontecer de algumas formas,

entretanto é apresentado aqui como transformar o legado e aumentar seu valor

através da criação de serviços, utilizando o padrão de arquitetura orientada a

serviço (SOA, apresentada no item 2.2.3).

“Num ambiente de SOA, tarefas de negócio são realizadas por executar uma

série de 'serviços', que por sua vez participa do processo de negócio. Os serviços

têm uma maneira bem definida de conversar com outros serviços e maneiras

bem-definidas em que eles conversam de volta. A implementação de um serviço

não importa a um usuário, contanto que o serviço responda no tempo esperado e

ofereça a qualidade de serviço exigida por ele. Esta forma de contato com o

serviço deve ser segura, de confiança, e rápida, e isto faz do SOA ideal para

ambientes de TI onde software e hardware de muitos vendedores estão

instalados, ou em um ambiente em que os sistemas existentes são misturados

com novas aplicações, tecnologias de integração ou fontes de dados”,

(LAWRENCE, 2007).

41 Apresentados no item 4.1

101

Desta forma ele nos apresenta que a arquitetura SOA é ideal para ser

implementada em sistemas legados que necessitam de interação com outros

sistemas, fornecendo informações que antes só podiam ser efetuadas através de

processamento em lote, e que agora podem ser efetuadas em tempo real.

SOA aumenta o valor dos sistemas legados ao, (LAWRENCE, 2007):

● Diminuir a complexidade por fornecer uma maneira uniforme de ligar

serviços e uma estrutura uniforme para integrá-los.

● Substituir ligação estática de serviços por uma ligação dinâmica e reduzir a

resistência a mudança, permitindo que a TI encontre mudanças em

processos de negócio.

● Fornecer um ambiente para reuso e consistência encorajadora.

● Simplificar operações por fornecer uma maneira uniforme controlar e

administrar serviços.

● Simplificar implementações de serviço por manipular recursos e outras

tarefas de gerenciamento em grupos de serviços.

De acordo com isto, as empresas passam a ter uma revitalização do sistema

legado através da implementação da arquitetura SOA, que proporciona ao legado

novas fontes de integração em tempo real com outros sistemas, ou até mesmo

fornecendo estes serviços como fonte de integração ou acessos externos a

empresa, sem ter que se desfazer do sistema legado ou até mesmo sem ter que

fazer uma grande reengenharia no mesmo.

Desta forma Calvin Lawrence nos apresenta três estágios para transformar um

sistema legado em SOA, que são melhorar a experiência do usuário, adaptação

para aumento dos relacionamentos e inovação para novas capacidades,

(LAWRENCE, 2007). Estes estágios são apresentados na seqüência.

102

Melhorar a experiência do usuárioPara situações onde a interface usada pelos usuários é muito ruim (como nos

casos das telas verdes) e os processos de trabalho são ultrapassados, as

empresas estão fazendo ações para melhorar a experiência de aplicações tempo

real com seus clientes e usuários finais. Isto normalmente significa trocar as telas

verdes por novas interfaces que melhoram a produtividade, incorporam novas

tecnologias e permitem aos usuários finais uma facilidade no uso da aplicação.

Este estágio trás benefícios como:

● Provê um rápido retorno sobre o investimento (ROI).

● Melhora a experiência do usuário final.

● Exige um baixo investimento e é menos traumático.

● Aumenta a satisfação do usuário.

Adaptação para aumento dos relacionamentosOnde os sistemas legados são muito difíceis de integrar com outras aplicações,

as empresas tem investido no SOA para permitir ao sistema legado fazer estas

integrações sem riscos de modificações na plataforma inteira.

Este estágio trás benefícios como:

● Permite ao negócio estender o seu alcance.

● Requer pouca ou nenhuma mudança.

● Significa baixo investimento.

● Aumenta a satisfação do cliente.

Inovação para novas capacidadesEm situações onde é difícil de se adaptar a processos de missão critica para

mudanças de negócio ou condições do mercado, organizações tem utilizado seus

sistemas legados para construir aplicações completamente novas. Ao entender o

que contém estas aplicações de missão critica as empresas estão aptas a

reestruturar e componentizar o sistema, e integram parte deste sistema em novas

103

e diferenciadas soluções, chegando finalmente a arquitetura orientada a serviço.

Este estágio permite:

● Reengenharia da aplicação existente.

● Altos investimentos.

● Componentização.

● Reuso do código da API(Application Program Interface)

Desta forma é possível perceber que a arquitetura SOA aplicada a sistemas

legados pode revitalizar o sistema aos poucos, gerando maiores resultados

iniciais e permitindo um investimento maior no futuro para evoluir o sistema

legado sem a necessidade de enfrentar enormes riscos num processo de

evolução do produto.

104

5 PROPOSTA DE AUTOMAÇÃO DE TESTES EM SISTEMAS

LEGADOS

Este capítulo apresenta uma proposta de passos que podem ser efetuados para

automatizar testes em sistemas legados. Todo o conteúdo apresentado

anteriormente tem o intuito de fornecer uma base para esta proposta.

Como apresentado no item 4, os sistemas legados tem vital importância para as

empresas e normalmente não é viável substituí-los (caso contrário já teriam sido).

Entretanto, como apresentado, estes sistemas muitas vezes não foram criados da

forma mais adequada possível por diversas razões, gerando normalmente uma

baixa qualidade do produto.

O fato destes sistemas continuarem em evolução (sofrendo alteração, correções

de erros e integrações) obriga as empresas a conviverem com estes problemas

de qualidade, dificultando o trabalho, aumentando o risco e o custo de

manutenção a cada etapa de evolução do sistema.

Desta forma, quando se trata de um sistema legado que permanecerá em uso por

tempo indeterminado, uma alternativa interessante para melhorar a qualidade do

sistema pode ser iniciar um processo de automação de testes, evitando falhas,

aumentando a segurança e podendo servir como um suporte confiável para uma

futura transformação do sistema legado.

A diversidade dos sistemas legados tornam possíveis diversas soluções para a

criação e automação dos testes. Os passos propostos apresentam uma forma de

organizar as fases da automação de forma incremental, gerando um processo de

automação de testes que visa um melhor aproveitamento das fases iniciais da

automação, tentando reduzir os riscos para as partes mais críticas do sistema e

tentando gerar um processo evolutivo dos testes.

105

A figura 23 apresenta de forma gráfica a organização macro dos passos

propostos para o processo de automação de testes de sistemas legados.

Basicamente a proposta apresenta cinco passos necessários para um primeiro

ciclo do processo de automação do sistema, em seguida existe uma segunda fase

que da continuidade ao processo de automação.

A primeira fase segue a seguinte ordem dos passos apresentados:

1. Primeiramente é executado o item 5.1 onde são identificados os pontos

críticos ou de maior necessidade de serem automatizados, e são criados

projetos de automação de teste a serem executados.

2. Este segundo passo (item 5.2) acontece ao iniciar o primeiro projeto da

lista de projetos de automação de testes e consiste em identificar os casos

de teste que devem ser criados para este projeto.

3. O item 5.3 acontece ainda no projeto de automação de teste, onde define-

Figura 23: Proposta de Processo de Automação de Testes em Sistemas Legados

106

se quais são as ferramentas de automação de teste ideais para utilizar

neste projeto.

4. O item 5.4 consiste em implementar a automação dos testes deste projeto

nas ferramentas escolhidas, e ao concluir a implantação do projeto

transformar as regras e os padrões de teste definidos neste projeto, como

parte dos padrões de processo de desenvolvimento de software.

5. O item 5.5 consiste em acompanhar a execução periódica dos testes e

acompanhar as métricas de qualidade (se existirem) para verificar a

efetividade das automações que estão sendo executadas.

A segunda fase consiste na continuação da primeira, desta forma existe uma

seqüencia um pouco diferente, onde se utiliza apenas alguns dos passos

apresentados, a partir do próximo projeto da lista de prioridades:

1. Como já existe a lista de projetos, parte-se diretamente para o próximo

projeto da lista, executando o item 5.2 da mesma forma que foi executado

na primeira fase.

2. No item 5.3 existe uma pequena modificação, onde é avaliado se há a

necessidade de utilizar uma ferramenta diferente para automação de testes

das ferramentas existentes no processo de desenvolvimento do sistema,

se a ferramenta necessária já existir no processo, apenas partimos para o

item 5.4, caso contrário este passo deve ser executado para avaliar uma

nova ferramenta que realize a automação dos testes necessários.

3. No item 5.4, foi apresentada a implementação da automação dos testes

para o projeto, e se a ferramenta de automação de teste for diferente das

existentes no processo de desenvolvimento atual, também deve ser

incluída a utilização desta ferramenta no processo de desenvolvimento.

Esta segunda fase trata-se de um ciclo que se repete até que a lista dos projetos

107

de automação de testes terminem, ao terminar a lista é necessário avaliar se há

mais partes do sistema legado que necessite de testes automatizados. Se houver

mais necessidade de automação, inicia-se o processo a partir da primeira fase,

porém desta vez com uma base de ferramentas de automação em uso no

processo de desenvolvimento.

Desta forma a proposta de processo de automação evolui o sistema, sem que

para implementar a automação dos testes seja necessário parar os outros

projetos de melhoria ou manutenção do sistema legado.

5.1 Identificar pontos de necessidade de automação

O primeiro passo da proposta é a identificação dos pontos de maior prioridade

para automatizar o software legado. Para que esta identificação seja possível é

necessário ter um bom conhecimento do sistema a ser analisado.

Este conhecimento pode ser obtido através de:

1. Documentação existente do sistema - Podem ser manuais de usuário,

documentações de análise e ou documentos técnicos sobre o sistema

entre outros;

2. Profissional com muita experiência no sistema – Por exemplo um

analista, um desenvolvedor ou um usuário que acompanhem a evolução do

sistema a bastante tempo;

3. Analise do Sistema – Em casos onde não é possível encontrar nenhuma

documentação e não há mais nenhum profissional que trabalhe com o

sistema a bastante tempo, torna-se possível investir numa analise do

sistema existente, ou seja, separar uma equipe para efetuar uma análise

das partes consideradas fundamentais do sistema para que haja um ponto

de partida.

108

Este conhecimento é importante para poder definir quais partes do sistema devem

ser testadas (ou pelo menos que devem ser testadas com maior prioridade), desta

forma é possível conhecer onde a automação de testes do legado pode trazer

maiores benefícios.

Com este conhecimento prévio do sistema é possível levantar as seguintes

informações:

1. Pontos em que o sistema sofre mais melhorias – Todas as melhorias ou

modificações efetuadas no sistema podem indicar pontos onde

possivelmente haverá algum erro.

2. Pontos em que mais ocorrem erros no sistema – Esta informação

apresenta os locais onde o sistema é utilizado com freqüência pelos

usuários e onde provavelmente o sistema sofre alguma evolução periódica.

É um bom indicador para coincidir com o item 1.

3. Funcionalidades críticas do sistema – Estes são os pontos críticos do

sistema onde é ideal manter testes das funcionalidades básicas, que vão

garantir que nenhuma alteração efetuada possa danificar as

funcionalidades mais críticas.

Estas informações podem mostrar de forma simples onde há mais possibilidades

de acontecer novos erros (Devido a mudanças no sistema) e onde não pode

ocorrer erros (Devido a criticidade da funcionalidade). Estes são os dois pontos

principais do sistema que devem ser localizados para iniciar uma automação de

testes no sistema legado.

Ao analisar as funcionalidades críticas do sistema é possível definir requisitos não

funcionais (comentado no item 3.2.3) como sendo críticos para o sistema, desta

forma estes requisitos também são levados em consideração durante o

planejamento dos testes.

109

Após a identificação dos pontos que necessitam de automação de testes, deve-se

gerar uma listagem ordenada por prioridade para que sejam planejados e

implementados os testes de acordo com esta prioridade. Para auxiliar na

priorização dos itens, pode-se pontuar as partes do sistema levando em

consideração:

1. Criticidade desta parte do sistema para o negócio;

2. Chance de ocorrência de erros nesta parte do sistema devido a

modificações futuras (tanto devido a modificações em outras partes do

sistema como modificações nela mesma);

3. Quantidade de modificações planejadas para serem efetuadas nesta parte

do sistema.

A lista gerada por este passo do processo define quais são as partes do sistema

que podem encontrar mais erros ou trazer maior segurança para o sistema

legado. A ordenação da mesma é importante para definir quais partes do sistema

terão seus testes automatizados de forma prioritária, garantindo uma diminuição

dos erros ou uma garantia de que as modificações do sistema não irão danificar

uma determinada funcionalidade crítica do sistema legado.

5.2 Planejar os testes a serem efetuados

Como apresentado no item 2, existem diversos processos de desenvolvimento,

diversas arquiteturas de sistema e diversos paradigmas de desenvolvimento de

software, toda esta diversidade permite aos sistemas legados (apresentado no

item 4) ter uma grande variedade de composições.

Devido a esta variedade, toda a base apresentada no capítulo 3 torna-se

necessária para escolher uma ou mais estratégias e técnicas de teste de software

que podem gerar um maior resultado nos testes automatizados.

110

A partir do primeiro item da lista gerada (apresentado no item 5.1) deve-se

escolher a melhor estratégia e técnica de teste para este item, porém a escolha

não é limitada a uma única estratégia ou técnica, deve-se avaliar o tempo e

recursos disponíveis para escolher as técnicas e estratégias que apresentem

mais chances de cobrir as situações de risco do sistema.

A escolha das melhores estratégias de teste dependem de cada sistema e de

cada empresa na qual elas serão implementadas, o responsável pelos testes

deve conhecer as estratégias e técnicas para avaliar quais delas são mais

adequadas para a empresa e o software em questão.

Entretanto são apresentados a seguir alguns casos que podem favorecer uma

determinada estratégia de teste:

● Um sistema legado em evolução, onde existem desenvolvedores

trabalhando para incluir funcionalidades ou corrigir erros constantemente

pode indicar um ambiente adequado para automação de testes unitários ou

de integração, pois além de serem testes muito válidos por capturarem

erros em fases iniciais dos projetos, também são ideais para serem

integrados as tarefas dos desenvolvedores. Esta manutenção contínua ao

sistema legado fará com que a cobertura dos testes em relação ao sistema

aumente rapidamente;

● Um sistema que se encontra numa fase estável, onde ocorrem poucas

modificações ou correções, apresenta um ambiente mais propicio para

automação de testes de sistema voltados as visões do usuário final e que

garante que as funcionalidades existentes não sejam quebradas quando

houver uma modificação;

● Se a parte do sistema analisada exige algum requisito não funcional, como

performance por exemplo, a estratégia de teste de sistema pode ser ideal

para apresentar a situação de sobrecarga que o sistema precisa suportar.

111

A escolha da estratégia de testes pode variar dependendo de outras informações

relacionadas ao sistema, entretanto as sugestões apresentadas podem auxiliar

num primeiro momento.

Após a escolha das estratégias de teste, é necessário criar os casos de teste para

a estratégia escolhida. O item 3.4 nos apresenta as técnicas de teste de caixa

branca e caixa preta, estas duas técnicas de teste apresentam diversas formas

comprovadas que podem auxiliar na criação de casos de teste mais efetivos e

com maiores chances de captura de erros.

Não existe um padrão formal para a escrita de um caso de teste, entretanto

existem diversos modelos na internet que podem ser utilizados pela empresa. Um

deles é apresentado pelo RUP, (WTHREEX, 2007).

É interessante que esta documentação de casos de testes seja disponibilizada

num local de fácil acesso para consultas futuras, desta forma a escolha de como

e onde disponibilizar as informações dos casos de teste são importantes pois eles

são a documentação do que os testes estão garantindo ao sistema legado e o

que eles não estão garantindo.

5.3 Definir as ferramentas para a automação

A base para a escolha de uma ferramenta se encontra no item 3.5. Entretanto,

apenas conhecer os tipos existentes de ferramentas e escolher uma delas não é o

suficiente para o sucesso de uma automação de testes. A escolha da ferramenta

é de extrema importância, mas é preciso vincular a escolha da ferramenta as

condições da empresa. Por exemplo uma situação onde o planejamento mostrou

a necessidade de testes de sistema, e a única ferramenta encontrada foi uma

ferramenta proprietária com um custo inacessível não pode ser considerada uma

boa solução, desta forma é necessário o vinculo entre a expectativa da empresa,

os recursos disponíveis para a automação e uma ferramenta que atenda esta

realidade.

112

Algumas sugestões podem ser interessantes para auxiliar na avaliação de uma

ferramenta:

● Um sistema que apresente uma CLI (Command Line Interface) ou uma API

(Application Program Interface) apresentam um ambiente simples para

serem testados a partir de ferramentas xUnit. Como apresentado nos itens

3.5.1 e 3.5.2, as xUnit são ferramentas interessantes para se fazer testes

unitários e de integração, mas podem ser utilizadas para testes de sistema

(voltadas as visões do usuário final) se o sistema possuir uma destas

interfaces, como foi apresentado no item 3.5.3.

● Testes de estresse, carga e outros testes não funcionais do sistema são

testes muito específicos e que normalmente necessitam de um ambiente

similar ao de produção, desta forma estes testes são normalmente gerados

utilizando um sistema de record & playback somado a alguns scripts que

recebem dados de uma listagem separada (Apresentados no item 3.5.3) ,

simulando o mais próximo possível uma situação real.

● Sistemas antigos, que possuem uma interface bem definida e que

provavelmente não terão uma modificação na interface são fortes

candidatos a terem testes de sistema desenvolvidos a partir de ferramentas

de record & playback devido a facilidade de criação e reprodução dos

testes.

Como foi dito, a escolha da ferramenta de automação de teste depende muito a

situação da empresa e dos recursos disponíveis para que os testes sejam

efetuados, desta forma, uma pesquisa entre as ferramentas avaliadas no mercado

é interessante para chegar a uma ferramenta adequada as possibilidades da

empresa.

Neste caso, a escolha de ferramentas para automação dos testes em um sistema

legado é muito parecida com a escolha de ferramentas para automação de testes

113

em um sistema que está em fase inicial de desenvolvimento, a diferença está na

avaliação, que deve ser efetuada com base num sistema existente. Esta posição

apresenta mais uma vez a importância do conhecimento do sistema legado,

apresentada no item 5.1.

É interessante que ao escolher a ferramenta para automação dos testes, que o

responsável já tenha em mente uma periodicidade para a execução automática

dos testes. É muito comum as empresas executarem os testes automatizados

semanalmente ou até diariamente, isto varia dependendo da estratégia de teste

que foi adotada e da quantidade de testes que estão sendo executados.

5.4 Incluir a automação no processo de desenvolvimento

Quando o item de trabalho já foi planejado (item 5.2), e a escolha da ferramenta

de automação já foi efetuada (item 5.3), é o momento de implementar o projeto de

automação e depois definir como a automação de testes é disponibilizada para

integração com o processo de desenvolvimento.

O item trabalhado é registrado e incluído como um projeto em qualquer processo

de desenvolvimento (apresentados no item 2.1), desta forma, este item ganha um

escopo e um prazo bem definidos gerando um trabalho planejado que pode ter

seu resultado avaliado no final do projeto. Este projeto deve ser regido pelas

regras de projetos do sistema legado utilizado na empresa.

Após a conclusão do projeto, se a automação dos testes do sistema legado ficar

limitada aos projetos de automação desenvolvidos, o sistema continuará a evoluir

como apresentado no item 4 e após algum tempo, mesmo que sejam gerados

sempre mais projetos para automação de testes, o sistema legado não

conseguirá manter seu conteúdo de testes automatizados atualizado, tornando os

esforços de automação menos eficientes e provavelmente perdendo a sua

credibilidade.

114

Para evitar este tipo de problema, é necessário que as regras e padrões de

automação de testes gerados a partir deste projeto, sejam inclusos nos passos do

processo de desenvolvimento utilizado pela empresa, garantindo que as

modificações geradas no sistema legado avaliem a possibilidade de automação

dos testes desta melhoria.

Num exemplo, um primeiro projeto abrange uma parte crítica do sistema e teve

seus casos de teste automatizado através de uma ferramenta de record &

playback, no momento da conclusão do projeto, a empresa passa a ter um

conhecimento específico sobre esta estratégia e técnica de teste utilizado,

conhecimento este que pode ser replicado para o processo de desenvolvimento.

Desta forma, a empresa pode incluir em seu processo de desenvolvimento um

passo de análise que avalia se um determinado projeto do sistema legado tem

condições de ser testado de forma automatizada através da técnica conhecida.

Se houver a possibilidade, este próximo projeto deve conter também o passo do

item 5.2, que irá criar os casos de teste a serem automatizados para este projeto.

Outro caso onde a empresa pode incluir este passo é no processo de correção de

erros, onde cada erro encontrado e corrigido deve ser avaliado quanto a

possibilidade de automação do teste. Este processo possibilita que o erro sempre

seja verificado e impede um retorno deste mesmo erro num momento futuro.

A inclusão destes passos no processo de desenvolvimento garante a evolução

dos testes automáticos de forma que com o passar do tempo o sistema garante

uma maior cobertura dos testes. Ao trabalhar com projetos de automação de teste

ao invés de implantá-los diretamente no processo de desenvolvimento, a empresa

emprega um esforço calculado para uma iniciativa que irá afetar todo o processo

de desenvolvimento, desta forma a empresa acumula experiência em relação a

automação de teste antes de arriscar uma modificação no processo de

desenvolvimento.

115

Os outros projetos de automação de teste são necessários para definir as

melhores estratégias e técnicas de teste a serem utilizadas em cada parte do

sistema, gerando de forma gradual todos os testes necessários para a segurança

do sistema legado.

Há a possibilidade de que o projeto de automação de teste falhe, neste momento

é importante avaliar o que ocorreu com o projeto para validar em que passo do

processo houve uma falha, se foi no levantamento inicial das prioridades, se foi na

análise dos testes a serem efetuados, se foi na escolha da ferramenta de

automação ou se foi um erro na implementação do projeto.

Descobrir este erro e aprender com ele fará com que outros projetos de

automação não falhem, gerando uma maior confiabilidade no processo, o fato de

um projeto de automação ter falhado também significa que a empresa investiu

menos recursos do que se tivesse tentado implementar esta automação

diretamente no processo de desenvolvimento de sistemas, poupando assim

desenvolvedores, testadores e todos aqueles que teriam de conviver com a

mudança referente a automação de testes no seu dia a dia. Isto também faz com

que a equipe envolvida no projeto ganhe experiência em relação ao processo de

automação de testes, podendo auxiliar no aprendizado de outras equipes que

serão envolvidas nas automações de teste dos próximos projetos.

5.5 Acompanhamento e análise dos resultados

Após implementado o primeiro projeto de automação de testes, é necessário

haver um acompanhamento da execução destes testes automatizados de acordo

com a periodicidade com que eles ocorrem. Este acompanhamento permite saber

se alguma modificação no sistema gerou falha em parte do sistema que foi

testada, desta forma é possível encontrar e solucionar a causa do problema antes

que este seja entregue numa versão ou pacote de atualização, além de permitir

um acompanhamento da evolução da automação dos testes que estão sendo

gerados (principalmente nas fazes iniciais do processo de automação de testes).

116

As métricas de qualidade apresentadas no item 3.2 são uma boa forma de

acompanhar e analisar se os testes automatizados estão gerando resultado,

melhorando assim a qualidade geral do produto. A análise e divulgação destes

indicadores é importante para gerar credibilidade ao processo de automação dos

testes e para validar se as estratégias adotadas estão sendo realmente efetivas.

Sistemas que possuem um Build automatizado e/ou processo de Integração

Contínua automatizados (comentados no item 3.5) auxiliam e favorecem o

acompanhamento e divulgação dos testes entre os desenvolvedores e equipes de

teste.

117

6 CONCLUSÃO

Os sistemas de software legado constituem uma grande parcela dos sistemas

existentes no mercado. Estes sistemas desenvolvidos há muito ou pouco tempo

normalmente são de uma importância vital para as empresas que dependem

deles, desta forma manter um sistema legado exige muito esforço tanto da

empresa quanto da equipe, tornando a evolução deste sistema uma tarefa

tortuosa e custosa devido a vários aspectos, dentre estes aspectos podemos

citar: a qualidade destes sistemas onde em grande parte não foram utilizadas as

melhores práticas e as técnicas e padrões considerados na atualidade.

A má qualidade dos sistemas legados faz com que as empresas não tenham

condições de evoluir este sistema devido aos riscos de efetuar uma manutenção

ou evolução no mesmo. Por serem sistemas de importância vital para a empresa,

qualquer manutenção ou melhoria só é efetuada quando os benefícios

ultrapassam em muito os riscos apresentados para o projeto. Desta forma, a má

qualidade de um sistema legado pode impedi-lo de evoluir até chegar um ponto

onde o custo para mantê-lo ativo faz com que a empresa se torne menos

produtiva, diminuindo sua capacidade de se manter competitiva no mercado,

entretanto as informações contidas nestes sistemas são tão críticas quanto a

competitividade da empresa no mercado. Devido a estes problemas, o

investimento destas empresas no aumento da qualidade do software legado é

justificado, e desta forma a melhoria da qualidade deste sistema o torna mais

confiável, diminuindo o risco dos projetos de manutenção e melhoria e fazendo

com que o sistema legado volte a se tornar produtivo.

A qualidade dos sistemas de software entretanto é uma área de conhecimento

extensa, que exige conhecimento de diversas disciplinas e envolve um alto custo

a ser investido pela empresa. Desta forma, investir em testes e melhoria de

software sem um estudo prévio de qualidade e das áreas de conhecimento

necessárias podem fazer com que a empresa acumule mais problemas do que

soluções, aumentando os gastos e não melhorando a qualidade.

118

Mesmo as empresas que investem em qualidade da forma correta enfrentam

ainda outros problemas relativos aos custos de manter a qualidade do produto.

Conforme o sistema evolui e adquire mais funcionalidades, mais testes são

necessários para garantir todo o sistema. O custo de se fazer todos os testes

criados para o sistema de forma manual pode inviabilizar os testes, desta forma

muitas empresas tem investido na automação destes testes procurando

economizar recursos e poder continuar garantindo a confiabilidade e segurança

do sistema.

Os sistemas de software legados entretanto podem ter sido criados a tanto tempo,

que acumularam uma quantidade muito grande de funcionalidades neste período,

e desta forma pode não ter havido uma preocupação em relação a documentação

e registro dos testes efetuados, gerando assim um sistema enorme no qual seria

inviável investir na criação de testes automatizados para todo o sistema.

Para propor uma solução para estes problemas este trabalho desenvolveu uma

solução de automação de testes em sistemas legados para se obter uma melhoria

no processo de qualidade. A solução proposta é constituída de cinco passos, que

propõe uma implementação da automação dos testes de forma gradual e

incremental, possibilitando a evolução do produto em paralelo a este processo.

Esta proposta ainda necessita de uma comprovação prática para verificar se

todas as informações contidas em livros, bibliotecas e artigos sejam efetivas.

Esta proposta fornece uma base inicial para futuras pesquisas que possam

complementar e melhorar o processo desenvolvido pelo autor.

119

REFERÊNCIAS

BECK, Kent. Simple Smalltalk Testing: With Patterns: Disponível em:

<http://www.xprogramming.com/testfram.htm> Acesso em: 23 nov. 2007

BEIZER, Boris. Software Testing Techiniques: 2ª ed., Van Nostrand Reinhold,

1990.

____________. Black-Box Testing: Techniques for Funcional Testing of Software and Systems: NetLibrary Incorporated, 1995.

BERZTISS, Alfs T. Software Methods for Business Reengineering: Springer:

1996

BIEBERTEIN, Norbert. Service-Oriented Architecture Compass: Business Value, Planning and Entrerprise Roadmap: Financial Times Prentice Hall, 2006

BINDER, R. Testing Object-Oriented Systems: A Status Report:.v.7, n. 4, abril

1994, p. 23-28

BLANKE, K; Krafzig, D; Slama, D. Enterprise SOA: Prentice Hall PTR, 2004.

C.M.U, Carnegie Mellon University. Three Tier Software Architectures:

Disponível em: <http://www.sei.cmu.edu/str/descriptions/threetier_body.html>

Acesso em: 09 Nov. 2007.

CRAIG, Lain. Blackboard Systems: Intellect Books, 1995.

CYBIS, Walter de Abreu. Aula12_Teste_de_SW.pdf: Santa Catarina. Junho de

2007. 1 arquivo (308.648 bytes)

FELIZARDO, Katia Romero. Técnicas de VV&T - Validação, Verificação e

http://www.sei.cmu.edu/str/descriptions/threetier_body.html

http://www.xprogramming.com/testfram.htm

120

Teste: Disponível em: <http://www.linhadecodigo.com.br/Artigo.aspx?

id=492&pag=3> Acesso em: 22 nov. 2007

FILHO, W. de P. P. Engenharia de Software: Fundamentos, Métodos e Padrões: Primeira. [S.l.]: LTC, 2000.

HAMILL, Paul. Unit Test Frameworks: O'Reilly, 2004

HARRINGTON, Jan L. Database Design: Morgan Kaufmann, 2002

HASAN Jeffrey, Duran Mauricio. Expert Service-Oriented Architecture in C#:

Apress, 2006.

HENTENRYCK, Pascal Van. Practical Aspects of Declarative Languages:

Springer, 2006.

HOHPE, G.; Woolf B. Enterprise Integration Patterns: Addison-Wesley

Professional, 2004.

HORCH, John W. Practical Guide to Software Quality Management: Artech

House: 2003

HUNT, John. Java and Object Orientatin: An Introduction: Springer, 2002.

__________. Guide to C# and Object Orientation: Springer, 2002.

IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. [S.l.]: Institute of Electrical and Electronics Engineers,

New York, NY, 1990.

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION and

INTERNATIONAL ELECTROTECHNICAL COMISSION. Software Engineering –

http://www.linhadecodigo.com.br/Artigo.aspx?id=492&pag=3

http://www.linhadecodigo.com.br/Artigo.aspx?id=492&pag=3

121

Product Quality: Quality Model: ISO/IEC 9126 Part 1: 2001

IPCOM, PriorArtDatabase. Improved Scenario Verification Test Process:

Disponível em: <http://www.priorartdatabase.com/IPCOM/000076876/privacy.jsp>

Acesso em: 13 Nov. 2007.

KAN, Stephen H. Metrics and Models in Software Quality Engineering:

Addison-Wesley Professional: 2002

KAZMAN, R.; Clements, P.; Bass, L. Software Architecture in Practice: Second.

[S.l.]: Addilson-Wesley, 2003.

L.A.S.E, Laboratory of Automated Systems Engineering. Fundamentos do Desenvolvimento Baseados em Componentes: Disponível em:

<http://labase.nce.ufrj.br/cursos/fdbc/aulas/aula2/slide.html> Acesso em: 09 Nov.

2007.

LAWRENCE, Calvin. Adapting Legacy Systems for SOA: Disponível em:

<http://www.ibm.com/developerworks/library/ws-soa-adaptleg/index.html>

Acessado em: 24 nov 2007

LERNER, Michah. Middleware Networks: Concept, Design and Deployment of Internet Infrastructure: Springer, 2000

MANJON, Marcelo. apres_OPT.ppt: São Paulo. Novembro de 2007. 1 arquivo

(1.369.088 bytes)

MARICK, Brian. When Should a Test be Automated?: Disponível em:

<http://www.testing.com/writings/automate.pdf> Acesso em: 22 nov. 2007

MYERS, Glenford J. The Art of Software Testing: Segunda Edição: John Wiley &

http://www.ibm.com/developerworks/library/ws-soa-adaptleg/index.html

http://labase.nce.ufrj.br/cursos/fdbc/aulas/aula2/slide.html

http://www.priorartdatabase.com/IPCOM/000076876/privacy.jsp

122

Sons, Inc.: 2004.

NGUYEN, Hung;Hackett, Michael; Whitlock, Brent K. Happy About Global Software Test Automation. Happy About, 2006.

PETTICHORD, Bret. Seven Steps to Test Automation Success. Disponível em:

<http://www.io.com/~wazmo/papers/seven_steps.html> Acessado em: 23 nov

2007

PRESSMAN, R. S. Engenharia de Software. Sexta. [S.l.]: McGraw-Hill, 2006.

RICARTE, Ivan L. M. Programação Orientada a Objetos com C++. Disponível

em: <http://www.dca.fee.unicamp.br/cursos/POOCPP/POOCPP.html> Acessado

em: 23 nov 2007

ROMAN, Steven. Access Database Design and Programming: O' Reilly, 2002

ROMEU, Leonardo; Belleza, Luciana; Gil, Paulo. Teste de Software através de Ferramentas Automatizadas: Disponível em:

<http://www.inf.pucrs.br/~toacy/disciplinas/pos/ESA/g4.pdf> Acessado em: 30 nov

2007

SCHUSSEL, George. Client/Server: Past, Present and Future: Disponível em:

<http://www.dciexpo.com/geos/dbsejava.htm> Acesso em: 09 Nov. 2007.

SOMMERVILLE, I. F. Software Engineering: Fifth. [S.l.]: Addison-Wesley, 1995.

WILLIAMS H., Lane, Web Database Applications: O' Reilly, 2002

WIKIPEDIA. Modelos Ciclo de Vida: Disponível em:

<http://pt.wikipedia.org/wiki/Modelos_ciclo_de_vida> Acesso em: 19 nov. 2007.

http://pt.wikipedia.org/wiki/Modelos_ciclo_de_vida

http://www.dciexpo.com/geos/dbsejava.htm

http://www.inf.pucrs.br/~toacy/disciplinas/pos/ESA/g4.pdf

http://www.dca.fee.unicamp.br/cursos/POOCPP/POOCPP.html

http://www.io.com/~wazmo/papers/seven_steps.html

123

WTHREEX. Rational Unified Process: Disponível em:

<http://www.wthreex.com/rup/> Acessado em 02 dez 2007

VERMA, Dinesh. Legitimate Applications of Peer-to-Peer networks: Wiley-

IEEE, 2004.

http://www.wthreex.com/rup/

Qualidade sistemas legados

Software

Transcript of Qualidade sistemas legados