Automação De Testes Em 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

Instituto de Engenharia Eletro-Eletrônica

SGBD

Sistema Gerenciador de Banco de Dados

TI

Tecnologia da Informação

SOA

Service Oriented Architecture(Arquitetura Orientada a Serviço)

XML

eXtensible Markup Language(Linguagem de Marcação Extensível)

ISO

International Organization for Standardization(Organização Internacional para padronização)

IEC

International Eletrotechinical Comission(Comissão Eletrotecnica Internacional)

PUM

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

RNF

Requisitos não Funcionais

RUP

Rational Unified Process(Processo Unificado Rational)

MTTR

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

AVL

Analise de Valor Limite

GUI

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

CLI

Command Line Interface(Interface de linha de comando)

API

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.

Figura 2: Modelo de Ciclo de Vida Codifica-Remenda Fonte: (PADUA, 2000)

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;

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

Figura 3: Ciclo de Vida Clássico ou Cascata Fonte: (PADUA, 2000)

Vantagens deste ciclo de Vida: 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.

Desvantagens deste ciclo de Vida: 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

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).

Figura 4: Ciclo de Vida Cascata do Tipo Sashimi Fonte: (PADUA, 2000)

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

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

Figura 5: Ciclo de Vida em Espiral Fonte: (WIKIPEDIA, 2007)

Vantagens deste ciclo de Vida: 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. Desvantagens deste ciclo de Vida: 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.

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 cliente6 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.

Figura 6: Arquitetura Mista - Fase Cliente-Servidor.

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.

23

Figura 7: Arquitetura Mista - Fase Final

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.

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.

Figura 8: Exemplo de Modelo Cliente-Servidor Distribuído Fonte: (ROMAN, 2002)

26

Figura 9: Exemplo de Modelo Cliente-Servidor de Banco de Dados Remoto Fonte: (ROMAN, 2002)

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 Requests 12 Estas respostas também são conhecidas por Responses

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.

Figura 10: Arquitetura Três Camadas numa aplicação baseada em Web Fonte: (WILLIAMS, 2002) 13 Query é a definição dada as consultas efetuadas nos Bancos de Dados através de uma linguagem específica

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.

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

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

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

possibilidadereferencia

procedurais de

alguns

de

tipos

alto de

nível

erros

removem

e aumentam

a 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.

Figura 12: O relacionamento entre Classe, SubClasse e SuperClasse Fonte: Adaptado de (HUNT, 2002, p.22)

Figura 13: Definição parcial de uma classe java Fonte: Adaptado de (HUNT, 2002, p.23)

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 podese 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.

Figura 14: Relacionamento entre os padrões ISO/IEC 9126 e ISO/IEC 14598 Fonte: (ISO/IEC, 2001)

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

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,

manutenabilidade e etc.

internacionalização,

compatibilidade,

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.

Figura 15: Escopo das Três Métricas de Qualidade Fonte: Adaptado de (KAN, 2002)

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.

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: PUM = Total de Defeitos Reportados pelos Clientes num período de tempo + Total de Licenças por Mês referente ao mesmo período

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: 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

“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

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 entendese 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

Figura 17: Ambiente de teste de unidade Fonte: (PRESSMAN, 2006, p.297)

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.

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 hackers 27, 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.

Figura 18: Exemplo de Grafo de Fluxo de Controle Fonte: (KATIA, 2007)

30 A complexidade ciclomática é uma métrica de software que fornece uma medida quantitativa da complexidade lógica de um programa.

71

Figura 19: Exemplo de Matriz de Grafo Fonte: (CYBIS, 2007)

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.

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):

Os

●

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. 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

Figura 20: Aumento do tempo gasto com testes manuais Fonte: Adaptado de (MANJON, 2007) 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.

Figura 21: Custo de testes manuais e automáticos ao longo do tempo. Fonte: Adaptado de (MANJON, 2007)

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.

Figura 22: Resultados de uma boa automação de testes. Fonte: Adaptado de (NGUYEN, 2006, p.34)

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

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 palavraschave 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á qualidade 38. 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 tipoE 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 tipoE é 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ário Para 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 relacionamentos Onde 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 capacidades Em 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.

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

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-

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: 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: 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

120 Teste: Disponível em: 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 –

121 Product Quality: Quality Model: ISO/IEC 9126 Part 1: 2001

IPCOM, PriorArtDatabase. Improved Scenario Verification Test Process: Disponível em: 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: Acesso em: 09 Nov. 2007. LAWRENCE, Calvin. Adapting Legacy Systems for SOA: Disponível em: 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: Acesso em: 22 nov. 2007 MYERS, Glenford J. The Art of Software Testing: Segunda Edição: John Wiley &

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: 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: 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: Acessado em: 30 nov 2007 SCHUSSEL, George. Client/Server: Past, Present and Future: Disponível em: 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: Acesso em: 19 nov. 2007.

123 WTHREEX. Rational Unified Process: Disponível em: Acessado em 02 dez 2007 VERMA, Dinesh. Legitimate Applications of Peer-to-Peer networks: WileyIEEE, 2004.