18/06/12

Bate Byte

Software Pblico Livre

O Governo do Paran um dos principais usurios e desenvolvedores de software livre de todo o pas. A opo pelos programas de cdigo aberto faz parte das polticas estratgicas de governo. Sua execuo de responsabilidade da CELEPAR. O Governo do Paran um dos principais usurios e desenvolvedores de software livre de todo o pas. A opo pelos programas de cdigo aberto faz parte das polticas estratgicas de governo. Sua execuo de responsabilidade da CELEPAR. Teste em ambiente cliente-servidor: uma estratgia 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, muitos pesquisadores tm apontado que o teste deve ser conduzido de uma maneira diferente. Este trabalho apresenta a ETACS, uma Estratgia de Teste de Software para Ambiente ClienteServidor. A ETACS foi aplicada em um estudo de caso real com o objetivo de melhorar a qualidade do sistema, minimizar os custos e validar a estratgia. Os resultados obtidos sero apresentados em uma srie de artigos. Palavras chaves: estratgia de teste, teste cliente-servidor, critrio de teste INTRODUO O processo de desenvolvimento de software envolve uma srie de atividades onde muito comum a ocorrncia de um erro ou a interpretao incorreta da informao por causa de falhas na comunicao humana. Estes erros podem acontecer durante todo o processo, desde a concepo at a construo do software. A atividade de teste se prope a auxiliar na descoberta destes erros, o quanto antes, para que o custo da correo dos mesmos seja o menor possvel. Apesar disso, muitos sistemas, aps a entrega, apresentam problemas por no terem sido testados adequadamente. O teste, portanto, uma atividade crtica para garantia de qualidade de software. A empresa, departamento, setor ou rea de informtica tem buscado uma melhor qualidade em seus produtos e servios, para melhor atender s necessidades de seus clientes e manterse em um mercado altamente competitivo [17]. Existe uma srie de certificaes e padronizaes para a rea de desenvolvimento de software dentre as quais destaca-se o modelo SEI/CMM (Software Engineering Institute/Capability Maturity Model) [8] [16] [17]. Hoje h um maior comprometimento das empresas com a garantia de qualidade no desenvolvimento e implantao de um programa desenvolvido por organizaes de padronizao ou que promovem a certificao como ISO e IEEE. Nesse sentido, uma melhor organizao da
www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=1728 1/8

18/06/12

Bate Byte

atividade de teste fundamental. Na arquitetura cliente-servidor o processamento no feito somente em uma mquina, dividido no mnimo entre duas camadas, uma cliente e uma servidor, sendo que essas duas camadas esto fisicamente conectadas atravs de uma rede. Conforme Mosley [12] lembrou, o fato da arquitetura cliente-servidor estar rapidamente se tornando a abordagem de desenvolvimento preferida em muitas empresas est forando os testadores de software a reavaliarem os "frameworks" de testes tradicionais. O processo de teste deve ser modificado baseando-se nas questes de projeto utilizando a tecnologia cliente-servidor [3]. O Gartner Group [5], faz uma srie de consideraes sobre as diferenas do teste de aplicaes tradicionais com relao ao teste de aplicaes cliente-servidor. Por que diferente testar aplicaes cliente-servidor? A resposta simples e direta porque o ambiente mais complexo, conseqentemente, requer mais teste do que as aplicaes tradicionais e a dificuldade para se isolar um defeito muito maior. Neste ambiente cliente-servidor importante testar se todas as camadas esto funcionando bem, com desempenho, quando sendo executados em rede ou sob uma carga maior de informao. necessrio, portanto, adotar uma metodologia mais adequada ao ambiente cliente-servidor. Entretanto, muitas empresas no adotam metodologia de testes em seus processos de desenvolvimento. Foi desenvolvido um trabalho para propor uma estratgia que fosse adequada a este tipo de ambiente e, para isso, primeiramente, um estudo emprico foi realizado em uma empresa que adota este tipo de tecnologia. O estudo consistiu em avaliar, atravs de questionrios e entrevistas, como a atividade de teste era realizada e quais as principais dificuldades encontradas. Numa segunda etapa, as estratgias de teste, especficas ou no, para o ambiente cliente servidor e diversos trabalhos da literatura foram estudados. Considerando os resultados empricos, a estratgia ETACS foi proposta reunindo os pontos positivos de cada trabalho estudado e combinando-os numa srie de passos. O objetivo deste primeiro artigo apresentar a fundamentao terica, metodologias, processos, tcnicas e critrios de teste encontrados na literatura e utilizados para elaborao da estratgia de teste proposta. Em artigos subseqentes sero apresentados os principais resultados do estudo emprico, tambm considerados, uma descrio da estratgia proposta e os resultados de sua aplicao em um estudo de caso em uma empresa que desenvolve softwares adotando o modelo cliente-servidor. FUNDAMENTAO TERICA O teste de software definido como o processo de executar um programa com o objetivo de revelar defeitos ainda no descobertos [13]. Para que dados de teste com alta probabilidade de revelar defeitos sejam executados, diferentes critrios de teste surgiram nas ltimas dcadas [6], [11], [15]. Esses critrios guiam a seleo dos dados de entrada para o programa e auxiliam a avaliao de um determinado conjunto de casos de teste, fornecendo medidas 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 cdigo do programa.
www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=1728 2/8

18/06/12

Bate Byte

Exemplos de critrios estruturais: 1) Critrios baseados em fluxo de controle: que usam geralmente um grafo de desvio de fluxo de controle associado ao programa para derivar os casos de teste [14], [15] (critrio todos-ns; todos-arcos, todos-caminhos); 2) Critrios baseados em fluxo de dados: testa definio e conseqentes usos de variveis (todas-definies; todos-usos [15]; todos-potenciais-usos [11]). O teste funcional no leva em considerao como o programa foi implementado. Os dados de teste so derivados a partir da especificao e dos requisitos de software. Exemplos de critrios funcionais [14]: 1) Particionamento em classes de equivalncia; 2) Anlise do valor limite; 3) Grafo de causa e efeito. O teste baseado em erros utiliza certos tipos de defeitos comuns em programao, para derivar requisitos de teste. Os casos de teste gerados so especficos para mostrar a presena ou ausncia desses defeitos. A nfase da tcnica est nos erros que o programador ou o projetista pode cometer durante o desenvolvimento e nas abordagens que podem ser usadas para detectar a sua ocorrncia. Exemplos de critrios: 1) Estimativa de erro [7]; 2) Semeadura de Erros (Error Seeding) [7]; 3) Anlise de mutantes (Mutation Analysis) [4], [6]. Trabalhos tm sido propostos na literatura dando nfase em teste de ambientes clienteservidor. Esses trabalhos destacam a dificuldade de teste devido complexidade da tecnologia cliente-servidor e quantidade de componentes envolvidos. Basicamente, eles consideram os dois tipos de arquiteturas cliente-servidor mais conhecidas e utilizadas: arquitetura duas-camadas e trs-camadas [12]. A primeira, mais simples, prev a existncia de uma camada do cliente chamada camada de apresentao, e uma camada do servidor. A segunda prev a existncia de uma camada intermediria que um servidor de aplicao. Mosley [12] afirma que os testes em ambiente cliente-servidor devem levar em considerao cada camada isoladamente. Exemplos de teste para a arquitetura trs-camadas so: 1) Camada da apresentao: devem ser realizados teste de usabilidade, teste de intuitividade de cones, etc. 2) Camada do servidor: devem ser realizados teste de carga e volume, teste de estresse, teste de performance, teste de recuperao ou devoluo de dados, teste de cpia de segurana e restaurao dos dados, teste de segurana dos dados, teste de integridade dos dados, etc. 3) Camada do meio, camada de negcio ou tambm camada de aplicao: nesta camada, onde os componentes executam toda a lgica de negcio da aplicao. Devem ser realizados muitos dos testes apontados na camada do servidor. Muitos autores tm apontado a complexidade de ambientes cliente-servidor e a necessidade de estratgias de teste especficas [5], [12]. Abaixo so relacionados os principais trabalhos encontrados na literatura, especficos ou no para ambientes cliente-servidor, que serviram como base para a estratgia ETACS, mais detalhada nos prximos artigos. Segundo Pressman [14], uma estratgia de teste de software, integra tcnicas de projeto de casos de teste numa srie bem definida de passos que resultam na construo bem sucedida do software, Esses passos podem envolver uma combinao das tcnicas e aplicao de diferentes critrios de teste. Geralmente, a escolha de um critrio de teste guiada pelos fatores eficcia (nmero de defeitos revelados), e custo (nmero de casos de teste requeridos). No entanto, as tcnicas e critrios devem ser aplicadas em diferentes etapas do teste e so consideradas complementares, pois podem revelar diferentes classes de defeitos [14]. Essas tcnicas dizem respeito etapa de projeto de casos de teste, entretanto, importante executar todos os passos da atividade de teste e no reduzir esse prazo em
www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=1728 3/8

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 que se espera, no existe um teste nico a ser realizado e sim uma combinao de vrios testes ao longo do projeto. A estratgia descrita por Pressman [14] prev as seguintes etapas: 1) teste de unidade: inicialmente os testes focalizam cada mdulo individualmente, garantindo que ele funcione adequadamente como uma unidade; 2) teste de integrao visa a construir o programa a partir dos mdulos testados no nvel de unidade, realizando-se ao mesmo tempo, testes para descobrir defeitos associados a interfaces entre os mdulos; 3) teste de validao: tem por objetivo testar o software depois de integrado e validar os requisitos funcionais e de desempenho estabelecidos durante a fase de anlise; 4) teste de sistema: testa o programa com outros elementos: hardware, pessoas, banco de dados. Segundo Beizer [2] so propostos alguns tipos de testes vlidos: teste de recuperao ou tolerncia a falhas, teste de segurana ou invaso, teste de estresse e teste de desempenho. Geralmente, essa atividade envolve algumas fases tais como [14]: planejamento, projeto de casos de teste, execuo dos casos de teste e avaliao dos resultados obtidos. Segundo o Gartner Group [5], grandes empresas e seus consultores propem um modelo de estratgia para o teste de software cliente-servidor que situa estas fases de teste ao longo do processo de desenvolvimento, segundo o paradigma espiral [14]. So 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 serem testados ou verificados; critrio de aceitao, aprovados pelo responsvel do negcio (incluindo consideraes de desempenho); regras e responsabilidades; ferramentas e tcnicas a serem utilizadas e um cronograma para o teste. Projeto de Caso de Teste: transforma os requisitos do sistema e comportamentos esperados pela aplicao, como especificados, em casos de teste documentados. Desenvolvimento do Teste: transforma os casos de teste em programas, "scripts", que exercitaro o sistema em desenvolvimento; ferramentas prprias devem ser usadas. Execuo do Teste e anlise dos resultados: executa propriamente os "scripts" que iro gerar resultados para serem confrontados com os valores entrados. A utilizao de um processo de teste padro contribui para melhorar a efetividade e eficincia do teste em um projeto. O Teste-Rx [12] um processo padronizado de teste de software cujo propsito fornecer uma linha base para as atividades de teste de software que fazem parte de um projeto. O processo consiste de uma srie de passos. Cada passo consiste de um conjunto de tarefas. No momento em que os primeiros passos esto terminados possvel produzir um produto parcial que pode ser entregue. Conceitualmente, o processo poderia ser considerado como um modelo espiral e adaptado s fases descritas acima. Um interessante passo do Teste-Rx a anlise de risco que utiliza a Tabela 1 como balizadora. A ETACS, tambm utiliza essa tabela como balizadora e a anlise de risco, mas de uma forma um pouco diferente.

Tabela 1: Classificao para os defeitos utilizada no Test-RX

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

4/8

18/06/12

Bate Byte

Grau

Descrio

Ao

1. Crtico

Os defeitos resultam em falhas do sistema ou de parte dele e no existe outra possibilidade, ou seja, o software pra completamente.

Resolver imediatamente

2. Prioritrio

Os defeitos resultam em falhas do sistema, Dar ateno entretanto existem alternativas de processo (manuais, alta por exemplo) que produziro os resultados desejados.

3. Regular

Os defeitos no resultam em falhas mas produzem resultados inconsistentes, incompletos ou incorretos ou prejudicam a usabilidade do software.

Fila normal

4. Pouca

Os defeitos no causam uma falha, no prejudicam a usabilidade e os resultados do processamento importncia desejado so obtidos contornando-se o problema.

Baixa Prioridade

5. Exceo O defeito resulta de uma requisio de alterao ou de melhoria, que pode ser indeferida. qualidade

Deferir ou no (longo prazo)

Outro trabalho que tambm incorpora anlise de riscos o Rational Unified Process - RUP, apresentado por Kruntchen [10] e descrito por JACOBSON, BOOCH e RUMBAUGH [9], cuja caracterstica fundamental ser baseado em componentes que se comunicam atravs de interfaces bem definidas. O padro adotado para representao dos modelos a "Unified Modeling Language - UML" e so dirigidos por Caso de Uso [9]. Este trabalho define as seguintes fases para o teste: planejamento, projeto e implementao dos testes, execuo e integrao e avaliao. A nfase dada no plano de teste que dever conter quatro pontos principais: Propsito - informaes sobre o propsito e objetivos do teste dentro do projeto. Tambm identifica as estratgias a serem utilizadas para implementar e executar os testes e os recursos necessrios. Requisitos para os testes - os requisitos devem ter um comportamento mensurvel e observvel. No h um relacionamento de um para um dos requisitos com um Caso de Uso. Cada Caso de Uso pode ter um ou mais requisitos para testar. Avaliao de risco para estabelecer as prioridades de teste - estabelecer as prioridades importante para garantir que os esforos dos testes estejam focados nos requisitos com maior risco e que so mais crticos e significativos. A classificao dos riscos estabelecida classificando os itens da Tabela 2 conforme as caractersticas da Tabela 3. Estratgias de teste - estabelecem em que fase so especificados os tipos de testes a serem implementados e seus objetivos, o estgio em que o teste ser implementado, as
www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=1728 5/8

18/06/12

Bate Byte

tcnicas utilizadas, as medidas e critrios usados para avaliar o trmino e os resultados do teste e algumas consideraes especiais que podem afetar o esforo de teste.
Tabela 2: Itens a serem avaliados

Item Descrio abreviada 1 Efeitos de uma falha no Caso de Uso 2 Causas de uma falha no Caso de Uso 3 Probabilidade do Caso de Uso falhar 4 Nmero de acessos a este Caso de Uso 5 Perfil dos usurios que utilizaro o Caso de Uso 6 Contrato com fornecedor deste Caso de Uso

Peso

Tabela 3: Classificao dos riscos utilizada no RUP

Classificao Caractersticas

Alta

to risco, defeito no pode ser tolerado. Provoca uma exposio externa forte. A empresa sofrer grandes perdas financeiras, endividamento ou uma perda irrecupervel da reputao.

Mdia

Risco mdio, tolervel mas no desejvel. Exposio externa mnima. A empresa pode sofrer financeiramente, mas h um endividamento ou perda da reputao sob controle.

Baixa

Baixo risco, tolervel. Pouca ou nenhuma exposio externa, a empresa pode ter pouca ou nenhuma perda financeira. A
6/8

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

18/06/12

Bate Byte

reputao da empresa no afetada.

CONCLUSO Todos os trabalhos acabam focalizando de uma maneira um pouco diferente os mesmos itens, porque realmente eles so os mais importantes. Alguns fornecem mais detalhes de como fazer as coisas, outros so extremamente genricos, outros ainda dependentes de uma ferramenta. A ETACS procurou se apoiar nestas metodologias, processos e estratgias com o foco no ambiente cliente-servidor. Este primeiro artigo de uma srie que faz parte da elaborao da estratgia adaptada para o ambiente cliente-servidor que sero publicadas em outras edies. REFERNCIAS [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. Disponvel em:
www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=1728 7/8

18/06/12

Bate Byte

http://www.rational.com/products/rup/prodinfo/whitepapers/. Acesso em: jan. 2001. [11] MALDONADO, J. C. Critrios potenciais usos: uma contribuio 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 prtica. So Paulo: Prentice Hall, 2001. [17] VAZ, R. Rumo ao nvel II da Capability Maturity Model - CMM. Developers Cio Magazine, Rio de Janeiro, v. 5, n. 49, p. 20-23, set. 2000. 2009 - Companhia de Informtica do Paran - Celepar Rua Mateus Leme 1561 - Centro Cvico 80530-010 - Curitiba - PR - 41 3350-5000

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

8/8