bate byte

18/06/12 Bate Byte

1/8www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=1728

Software Público Livre

O Governo do Paraná é um dos principais usuários e desenvolvedores de software livre de todo o país.

A opção pelos programas de código aberto faz parte das políticas estratégicas de governo. Sua execução é

de responsabilidade da CELEPAR.

O Governo do Paraná é um dos principais usuários e desenvolvedores de software livre de todo o país.

A opção pelos programas de código aberto faz parte das políticas estratégicas de governo. Sua execução é

de responsabilidade da CELEPAR.

Teste em ambiente cliente-servidor: uma estratégia e um estudo de caso - Parte 1

Autoras: Lisiane Mes Volpi - GPT Silvia Regina Vergilio - UFPR

RESUMO

Devido à complexidade da tecnologia dos sistemas com arquitetura cliente-servidor, muitospesquisadores têm apontado que o teste deve ser conduzido de uma maneira diferente. Estetrabalho apresenta a ETACS, uma Estratégia de Teste de Software para Ambiente Cliente-Servidor. A ETACS foi aplicada em um estudo de caso real com o objetivo de melhorar aqualidade do sistema, minimizar os custos e validar a estratégia. Os resultados obtidos serãoapresentados em uma série de artigos.

Palavras chaves: estratégia de teste, teste cliente-servidor, critério de teste

INTRODUÇÃO

O processo de desenvolvimento de software envolve uma série de atividades onde é muitocomum a ocorrência de um erro ou a interpretação incorreta da informação por causa defalhas na comunicação humana. Estes erros podem acontecer durante todo o processo, desdea concepção até a construção do software. A atividade de teste se propõe a auxiliar nadescoberta destes erros, o quanto antes, para que o custo da correção dos mesmos seja omenor possível. Apesar disso, muitos sistemas, após a entrega, apresentam problemas pornão terem sido testados adequadamente. O teste, portanto, é uma atividade crítica paragarantia de qualidade de software.

A empresa, departamento, setor ou área de informática tem buscado uma melhor qualidadeem seus produtos e serviços, para melhor atender às necessidades de seus clientes emanter–se em um mercado altamente competitivo [17]. Existe uma série de certificações epadronizações para a área de desenvolvimento de software dentre as quais destaca-se omodelo SEI/CMM (Software

Engineering Institute/Capability Maturity Model) [8] [16] [17]. Hoje há um maiorcomprometimento das empresas com a garantia de qualidade no desenvolvimento eimplantação de um programa desenvolvido por organizações de padronização ou quepromovem a certificação como ISO e IEEE. Nesse sentido, uma melhor organização da

18/06/12 Bate Byte


atividade de teste é fundamental.

Na arquitetura cliente-servidor o processamento não é feito somente em uma máquina, édividido no mínimo entre duas camadas, uma cliente e uma servidor, sendo que essas duascamadas estão fisicamente conectadas através de uma rede.

Conforme Mosley [12] lembrou, o fato da arquitetura cliente-servidor estar rapidamente setornando a abordagem de desenvolvimento preferida em muitas empresas está forçando ostestadores de software a reavaliarem os "frameworks" de testes tradicionais. O processo deteste deve ser modificado baseando-se nas questões de projeto utilizando a tecnologiacliente-servidor [3].

O Gartner Group [5], faz uma série de considerações sobre as diferenças do teste deaplicações tradicionais com relação ao teste de aplicações cliente-servidor. Por que édiferente testar aplicações cliente-servidor? A resposta simples e direta é porque o ambienteé mais complexo, conseqüentemente, requer mais teste do que as aplicações tradicionais e adificuldade para se isolar um defeito é muito maior. Neste ambiente cliente-servidor éimportante testar se todas as camadas estão funcionando bem, com desempenho, quandosendo executados em rede ou sob uma carga maior de informação.

É necessário, portanto, adotar uma metodologia mais adequada ao ambiente cliente-servidor.Entretanto, muitas empresas não adotam metodologia de testes em seus processos dedesenvolvimento.

Foi desenvolvido um trabalho para propor uma estratégia que fosse adequada a este tipo deambiente e, para isso, primeiramente, um estudo empírico foi realizado em uma empresa queadota este tipo de tecnologia. O estudo consistiu em avaliar, através de questionários eentrevistas, como a atividade de teste era realizada e quais as principais dificuldadesencontradas. Numa segunda etapa, as estratégias de teste, específicas ou não, para oambiente cliente servidor e diversos trabalhos da literatura foram estudados. Considerando osresultados empíricos, a estratégia ETACS foi proposta reunindo os pontos positivos de cadatrabalho estudado e combinando-os numa série de passos.

O objetivo deste primeiro artigo é apresentar a fundamentação teórica, metodologias,processos, técnicas e critérios de teste encontrados na literatura e utilizados para elaboraçãoda estratégia de teste proposta. Em artigos subseqüentes serão apresentados os principaisresultados do estudo empírico, também considerados, uma descrição da estratégia propostae os resultados de sua aplicação em um estudo de caso em uma empresa que desenvolvesoftwares adotando o modelo cliente-servidor.

FUNDAMENTAÇÃO TEÓRICA

O teste de software é definido como o processo de executar um programa com o objetivo derevelar defeitos ainda não descobertos [13]. Para que dados de teste com alta probabilidadede revelar defeitos sejam executados, diferentes critérios de teste surgiram nas últimasdécadas [6], [11], [15]. Esses critérios guiam a seleção dos dados de entrada para oprograma e auxiliam a avaliação de um determinado conjunto de casos de teste, fornecendomedidas de cobertura. Eles foram estabelecidos considerando diferentes aspectos: estrutural,funcional e baseado em erros.

O teste estrutural considera a estrutura interna do software e o código do programa.

18/06/12 Bate Byte


Exemplos de critérios estruturais: 1) Critérios baseados em fluxo de controle: que usamgeralmente um grafo de desvio de fluxo de controle associado ao programa para derivaros casos de teste [14], [15] (critério todos-nós; todos-arcos, todos-caminhos); 2)Critérios baseados em fluxo de dados: testa definição e conseqüentes usos de variáveis(todas-definições; todos-usos [15]; todos-potenciais-usos [11]).

O teste funcional não leva em consideração como o programa foi implementado. Osdados de teste são derivados a partir da especificação e dos requisitos de software.Exemplos de critérios funcionais [14]: 1) Particionamento em classes de equivalência; 2)Análise do valor limite; 3) Grafo de causa e efeito.

O teste baseado em erros utiliza certos tipos de defeitos comuns em programação, para

derivar requisitos de teste. Os casos de teste gerados são específicos para mostrar apresença ou ausência desses defeitos. A ênfase da técnica está nos erros que oprogramador ou o projetista pode cometer durante o desenvolvimento e nas abordagensque podem ser usadas para detectar a sua ocorrência. Exemplos de critérios: 1)Estimativa de erro [7]; 2) Semeadura de Erros (Error Seeding) [7]; 3) Análise demutantes (Mutation Analysis) [4], [6].

Trabalhos têm sido propostos na literatura dando ênfase em teste de ambientes cliente-servidor. Esses trabalhos destacam a dificuldade de teste devido à complexidade datecnologia cliente-servidor e quantidade de componentes envolvidos. Basicamente, elesconsideram os dois tipos de arquiteturas cliente-servidor mais conhecidas e utilizadas:arquitetura duas-camadas e três-camadas [12]. A primeira, mais simples, prevê a existênciade uma camada do cliente chamada camada de apresentação, e uma camada do servidor. Asegunda prevê a existência de uma camada intermediária que é um servidor de aplicação.

Mosley [12] afirma que os testes em ambiente cliente-servidor devem levar em consideraçãocada camada isoladamente. Exemplos de teste para a arquitetura três-camadas são: 1)Camada da apresentação: devem ser realizados teste de usabilidade, teste de intuitividadede ícones, etc. 2) Camada do servidor: devem ser realizados teste de carga e volume, teste deestresse, teste de performance, teste de recuperação ou devolução de dados, teste de cópiade segurança e restauração dos dados, teste de segurança dos dados, teste de integridadedos dados, etc. 3) Camada do meio, camada de negócio ou também camada de aplicação:nesta camada, onde os componentes executam toda a lógica de negócio da aplicação.Devem ser realizados muitos dos testes apontados na camada do servidor.

Muitos autores têm apontado a complexidade de ambientes cliente-servidor e a necessidadede estratégias de teste específicas [5], [12]. Abaixo são relacionados os principais trabalhosencontrados na literatura, específicos ou não para ambientes cliente-servidor, que serviramcomo base para a estratégia ETACS, mais detalhada nos próximos artigos.

Segundo Pressman [14], uma estratégia de teste de software, integra técnicas de projeto decasos de teste numa série bem definida de passos que resultam na construção bem sucedidado software, Esses passos podem envolver uma combinação das técnicas e aplicação dediferentes critérios de teste. Geralmente, a escolha de um critério de teste é guiada pelosfatores eficácia (número de defeitos revelados), e custo (número de casos de testerequeridos). No entanto, as técnicas e critérios devem ser aplicadas em diferentes etapas doteste e são consideradas complementares, pois podem revelar diferentes classes de defeitos[14]. Essas técnicas dizem respeito à etapa de projeto de casos de teste, entretanto, éimportante executar todos os passos da atividade de teste e não reduzir esse prazo em

18/06/12 Bate Byte


detrimento de outros problemas [1].

Para se desenvolver uma atividade de teste de maneira a atingir o objetivo de qualidade quese espera, não existe um teste único a ser realizado e sim uma combinação de vários testesao longo do projeto. A estratégia descrita por Pressman [14] prevê as seguintes etapas: 1)teste de unidade: inicialmente os testes focalizam cada módulo individualmente, garantindoque ele funcione adequadamente como uma unidade; 2) teste de integração visa a construir oprograma a partir dos módulos testados no nível de unidade, realizando-se ao mesmo tempo,testes para descobrir defeitos associados a interfaces entre os módulos; 3) teste devalidação: tem por objetivo testar o software depois de integrado e validar os requisitosfuncionais e de desempenho estabelecidos durante a fase de análise; 4) teste de sistema:testa o programa com outros elementos: hardware, pessoas, banco de dados. SegundoBeizer [2] são propostos alguns tipos de testes válidos: teste de recuperação ou tolerância afalhas, teste de segurança ou invasão, teste de estresse e teste de desempenho.

Geralmente, essa atividade envolve algumas fases tais como [14]: planejamento, projeto decasos de teste, execução dos casos de teste e avaliação dos resultados obtidos. Segundo oGartner Group [5], grandes empresas e seus consultores propõem um modelo de estratégiapara o teste de software cliente-servidor que situa estas fases de teste ao longo do processode desenvolvimento, segundo o paradigma espiral [14]. São elas:

Planejamento do Teste: produz o plano de teste. O plano de teste definirá as etapas e

categorias de teste a serem conduzidos, e inclui uma lista de: requisitos a seremtestados ou verificados; critério de aceitação, aprovados pelo responsável do negócio(incluindo considerações de desempenho); regras e responsabilidades; ferramentas etécnicas a serem utilizadas e um cronograma para o teste.

Projeto de Caso de Teste: transforma os requisitos do sistema e comportamentos

esperados pela aplicação, como especificados, em casos de teste documentados.

Desenvolvimento do Teste: transforma os casos de teste em programas, "scripts", que

exercitarão o sistema em desenvolvimento; ferramentas próprias devem ser usadas.

Execução do Teste e análise dos resultados: executa propriamente os "scripts" que irãogerar resultados para serem confrontados com os valores entrados.

A utilização de um processo de teste padrão contribui para melhorar a efetividade e eficiênciado teste em um projeto. O Teste-Rx [12] é um processo padronizado de teste de software cujopropósito é fornecer uma linha base para as atividades de teste de software que fazem partede um projeto. O processo consiste de uma série de passos. Cada passo consiste de umconjunto de tarefas. No momento em que os primeiros passos estão terminados é possívelproduzir um produto parcial que pode ser entregue. Conceitualmente, o processo poderia serconsiderado como um modelo espiral e adaptado às fases descritas acima. Um interessantepasso do Teste-Rx é a análise de risco que utiliza a Tabela 1 como balizadora. A ETACS,também utiliza essa tabela como balizadora e a análise de risco, mas de uma forma um poucodiferente.

Tabela 1: Classificação para os defeitos utilizada no Test-RX

18/06/12 Bate Byte


Grau Descrição Ação

1. Crítico Os defeitos resultam em falhas do sistema ou departe dele e não existe outra possibilidade, ou seja, osoftware pára completamente.

Resolverimediatamente

2.Prioritário

Os defeitos resultam em falhas do sistema,entretanto existem alternativas de processo (manuais,por exemplo) que produzirão os resultados desejados.

Dar atençãoalta

3. Regular Os defeitos não resultam em falhas mas produzemresultados inconsistentes, incompletos ou incorretosou prejudicam a usabilidade do software.

Fila normal

4. Pouca

importância

Os defeitos não causam uma falha, não prejudicam ausabilidade e os resultados do processamentodesejado são obtidos contornando-se o problema.

BaixaPrioridade

5. Exceçãodequalidade

O defeito resulta de uma requisição de alteração oumelhoria, que pode ser indeferida.

Deferir ou não(longo prazo)

Outro trabalho que também incorpora análise de riscos é o Rational Unified Process - RUP,apresentado por Kruntchen [10] e descrito por JACOBSON, BOOCH e RUMBAUGH [9], cujacaracterística fundamental é ser baseado em componentes que se comunicam através deinterfaces bem definidas. O padrão adotado para representação dos modelos é a "UnifiedModeling Language - UML" e são dirigidos por Caso de Uso [9]. Este trabalho define asseguintes fases para o teste: planejamento, projeto e implementação dos testes, execução eintegração e avaliação. A ênfase é dada no plano de teste que deverá conter quatro pontosprincipais:

Propósito - informações sobre o propósito e objetivos do teste dentro do projeto.

Também identifica as estratégias a serem utilizadas para implementar e executar ostestes e os recursos necessários.

Requisitos para os testes - os requisitos devem ter um comportamento mensurável e

observável. Não há um relacionamento de um para um dos requisitos com um Caso deUso. Cada Caso de Uso pode ter um ou mais requisitos para testar.

Avaliação de risco para estabelecer as prioridades de teste - estabelecer as

prioridades é importante para garantir que os esforços dos testes estejam focados nosrequisitos com maior risco e que são mais críticos e significativos. A classificação dosriscos é estabelecida classificando os itens da Tabela 2 conforme as características daTabela 3.

Estratégias de teste - estabelecem em que fase são especificados os tipos de testes a

serem implementados e seus objetivos, o estágio em que o teste será implementado, as

18/06/12 Bate Byte


técnicas utilizadas, as medidas e critérios usados para avaliar o término e os resultadosdo teste e algumas considerações especiais que podem afetar o esforço de teste.

Tabela 2: Itens a serem avaliados

Item Descrição abreviada Peso

1Efeitos de uma falha no Caso de Uso 3

2Causas de uma falha no Caso de Uso 3

3Probabilidade do Caso de Uso falhar 3

4Número de acessos a este Caso de Uso 2

5Perfil dos usuários que utilizarão o Caso de Uso 1

6Contrato com fornecedor deste Caso de Uso 3

Tabela 3: Classificação dos riscos utilizada no RUP

ClassificaçãoCaracterísticas

Alta to risco, defeito não pode ser tolerado.Provoca uma exposição externa forte. Aempresa sofrerá grandes perdas financeiras,endividamento ou uma perda irrecuperávelda reputação.

Média Risco médio, tolerável mas não desejável.Exposição externa mínima. A empresapode sofrer financeiramente, mas há umendividamento ou perda da reputação sobcontrole.

BaixaBaixo risco, tolerável. Pouca ou nenhumaexposição externa, a empresa pode terpouca ou nenhuma perda financeira. A

18/06/12 Bate Byte


reputação da empresa não é afetada.

CONCLUSÃO

Todos os trabalhos acabam focalizando de uma maneira um pouco diferente os mesmos itens,porque realmente eles são os mais importantes. Alguns fornecem mais detalhes de comofazer as coisas, outros são extremamente genéricos, outros ainda dependentes de umaferramenta. A ETACS procurou se apoiar nestas metodologias, processos e estratégias como foco no ambiente cliente-servidor.

Este é primeiro artigo de uma série que faz parte da elaboração da estratégia adaptada parao ambiente cliente-servidor que serão publicadas em outras edições.

REFERÊNCIAS

[1] ATKINS, W.; SHAW, J. C. Managing computer system projects. New York: McGraw Hill,

1980.

[2] BEIZER, B. Software system testing and quality assurance. New York: Van Nostrand

Reinhold, 1984.

[3] BINDER, Robert A. A CASE-based system for object-oriented programming: the FREE

approach. Chicago: Robert Binder Systems Consulting, 1992.

[4] BUDD, T. A. Mutation analysis: ideas, examples, problems and prospects, computer

program testing. USA: North-Holand Publishing, 1981.

[5] CONWAY, B. Testing client/server applications: challenges, strategies and solutions for

success. Stamford: Gartner Group, 22 Nov. 1996. (Strategic Analysis Report).

[6] DEMILLO, R. A; LIPTON, R. J. Hints on test data selection: help for practicing programmer.IEEE Computer, v. 11, n. 4, p. 34-41, 1978.

[7] GRAHAM, D. R. Testing. In: ENCYCLOPEDIA of software engineering. USA: J. Wiley, 1994.v. 2, p. 1330-1353.

[8] HUMPHREY, W. S. Managing the software process. Massachusetts: Addison-Wesley,

1989.

[9] JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. The unified software development

process reading. Massachusetts: Addison-Wesley, 1999. 463 p.

[10] KRUCHTEN, P. A Rational development process: white paper. Disponível em:

18/06/12 Bate Byte


http://www.rational.com/products/rup/prodinfo/whitepapers/. Acesso em: jan. 2001.

[11] MALDONADO, J. C. Critérios potenciais usos: uma contribuição ao teste estrutural de

software. 1991. Tese (Doutorado) - DCA/FEE/UNICAMP, Campinas, jul. 1991.

[12] MOSLEY, D. J. Client server software testing on the desktop and the web.

Indianapolis: Prentice Hall, 2000.

[13] MYERS, G. The art of software testing. New York: J. Wiley, 1979.

[14] PRESSMAN, R. S. Software engineering: a practitioner's approach. 4. ed. New York:

McGraw-Hill, 1997.

[15] RAPPS, S.; WEYUKER, E. J. Data flow analysis techniques for test data selection. In:INTERNATIONAL CONFERENCE ON SOFTWARE, Tokio. 1982. Proceedings... Tokio,

1982. 272-278 p

[16] ROCHA, A. R. C.; MALDONADO, J. C.; WEBER, K. C. Qualidade de software - teoria e

prática. São Paulo: Prentice Hall, 2001.

[17] VAZ, R. Rumo ao nível II da Capability Maturity Model - CMM. Developers’ Cio Magazine,

Rio de Janeiro, v. 5, n. 49, p. 20-23, set. 2000.

© 2009 - Companhia de Informática do Paraná - Celepar

Rua Mateus Leme 1561 - Centro Cívico

80530-010 - Curitiba - PR - 41 3350-5000

bate byte

Documents