RESUMO

Devido à complexidade da tecnologia dos sistemas com arquitetura cliente-servidor, muitos pesquisadores têm apontado que o teste deve ser conduzido de uma maneira diferente. Este trabalho 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 a qualidade do sistema, minimizar os custos e validar a estratégia. Os resultados obtidos serão apresentados 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 é muito comum a ocorrência de um erro ou a interpretação incorreta da informação por causa de falhas na comunicação humana. Estes erros podem acontecer durante todo o processo, desde a concepção até a construção do software. A atividade de teste se propõe a auxiliar na descoberta destes erros, o quanto antes, para que o custo da correção dos mesmos seja o menor possível. Apesar disso, muitos sistemas, após a entrega, apresentam problemas por não terem sido testados adequadamente. O teste, portanto, é uma atividade crítica para garantia de qualidade de software.

A empresa, departamento, setor ou área de informática tem buscado uma melhor qualidade em seus produtos e serviços, para melhor atender às necessidades de seus clientes e manter–se em um mercado altamente competitivo [17]. Existe uma série de certificações e padronizações 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 implantação de um programa desenvolvido por organizações de padronização ou que promovem a certificação como ISO e IEEE. Nesse sentido, uma melhor organização da 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 duas camadas estão fisicamente conectadas através 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á forçando os testadores de software a reavaliarem os "frameworks" de testes tradicionais. O processo de teste deve ser modificado baseando-se nas questões de projeto utilizando a tecnologia cliente-servidor [3].

O Gartner Group [5], faz uma série de considerações sobre as diferenças do teste de aplicaçõ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 a dificuldade para se isolar um defeito é muito maior. Neste ambiente cliente-servidor é importante testar se todas as camadas estão funcionando bem, com desempenho, quando sendo 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 de desenvolvimento.

Foi desenvolvido um trabalho para propor uma estratégia que fosse adequada a este tipo de ambiente e, para isso, primeiramente, um estudo empírico foi realizado em uma empresa que adota este tipo de tecnologia. O estudo consistiu em avaliar, através de questionários e entrevistas, como a atividade de teste era realizada e quais as principais dificuldades encontradas. Numa segunda etapa, as estratégias de teste, específicas ou não, para o ambiente cliente servidor e diversos trabalhos da literatura foram estudados. Considerando os resultados empíricos, a estratégia ETACS foi proposta reunindo os pontos positivos de cada trabalho 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ção da estratégia de teste proposta. Em artigos subseqüentes serão apresentados os principais resultados do estudo empírico, também considerados, uma descrição da estratégia proposta e os resultados de sua aplicação em um estudo de caso em uma empresa que desenvolve softwares adotando o modelo cliente-servidor.

FUNDAMENTAÇÃO TEÓRICA

O teste de software é definido como o processo de executar um programa com o objetivo de revelar defeitos ainda não descobertos [13]. Para que dados de teste com alta probabilidade de revelar defeitos sejam executados, diferentes critérios de teste surgiram nas últimas décadas [6], [11], [15]. Esses critérios guiam a seleção dos dados de entrada para o programa e auxiliam a avaliação 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 código do programa. Exemplos de critérios estruturais: 1) Critérios 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] (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. Os dados 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 a presença ou ausência desses defeitos. A ênfase da técnica 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 ocorrência. Exemplos de critérios: 1) Estimativa de erro [7]; 2) Semeadura de Erros (Error Seeding) [7]; 3) Análise de mutantes (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 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 três-camadas [12]. A primeira, mais simples, prevê a existência de uma camada do cliente chamada camada de apresentação, e uma camada do servidor. A segunda 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ção cada 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 intuitividade de ícones, etc. 2) Camada do servidor: devem ser realizados teste de carga e volume, teste de estresse, teste de performance, teste de recuperação ou devolução de dados, teste de cópia de segurança e restauração dos dados, teste de segurança dos dados, teste de integridade dos 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 necessidade de estratégias de teste específicas [5], [12]. Abaixo são relacionados os principais trabalhos encontrados na literatura, específicos ou não para ambientes cliente-servidor, que serviram como 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 de casos de teste numa série bem definida de passos que resultam na construção bem sucedida do software, Esses passos podem envolver uma combinação das técnicas e aplicação de diferentes critérios de teste. Geralmente, a escolha de um critério de teste é guiada pelos fatores eficácia (número de defeitos revelados), e custo (número de casos de teste requeridos). No entanto, as técnicas e critérios devem ser aplicadas em diferentes etapas do teste 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 detrimento de outros problemas [1].

Para se desenvolver uma atividade de teste de maneira a atingir o objetivo de qualidade que se espera, não existe um teste único a ser realizado e sim uma combinação de vários testes ao 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, garantindo que ele funcione adequadamente como uma unidade; 2) teste de integração visa a construir o programa 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 de validação: tem por objetivo testar o software depois de integrado e validar os requisitos funcionais 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. Segundo Beizer [2] são propostos alguns tipos de testes válidos: teste de recuperação ou tolerância a falhas, 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 de casos de teste, execução dos casos de teste e avaliação dos resultados obtidos. Segundo o Gartner Group [5], grandes empresas e seus consultores propõem um modelo de estratégia para o teste de software cliente-servidor que situa estas fases de teste ao longo do processo de 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 serem testados ou verificados; critério de aceitação, aprovados pelo responsável do negócio (incluindo considerações de desempenho); regras e responsabilidades; ferramentas e té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ão gerar 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ência do teste em um projeto. O Teste-Rx [12] é um processo padronizado de teste de software cujo propósito é fornecer uma linha base para as atividades de teste de software que fazem parte de um projeto. O processo consiste de uma série de passos. Cada passo consiste de um conjunto de tarefas. No momento em que os primeiros passos estão terminados é possível 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 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 pouco diferente.

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

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], cuja característica fundamental é ser baseado em componentes que se comunicam através de interfaces bem definidas. O padrão adotado para representação dos modelos é a "Unified Modeling Language - UML" e são dirigidos por Caso de Uso [9]. Este trabalho define as seguintes fases para o teste: planejamento, projeto e implementação dos testes, execução e integração e avaliação. A ênfase é dada no plano de teste que deverá conter quatro pontos principais:

• 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 os testes 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 de Uso. 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 nos requisitos com maior risco e que são mais críticos e significativos. A classificação dos riscos é estabelecida classificando os itens da Tabela 2 conforme as características da Tabela 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 técnicas utilizadas, as medidas e critérios usados para avaliar o término e os resultados do teste e algumas considerações especiais que podem afetar o esforço de teste.

Tabela 2: Itens a serem avaliados

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

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 como fazer as coisas, outros são extremamente genéricos, outros ainda dependentes de uma ferramenta. A ETACS procurou se apoiar nestas metodologias, processos e estratégias com o foco no ambiente cliente-servidor.

Este é primeiro artigo de uma série que faz parte da elaboração da estratégia adaptada para o 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: 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.