Teste em Ambiente Cliente-Servidor: Uma Estratégia e um Estudo de Caso - Parte 2

Autoras: Lisiane Maes Volpi e Silvia Regina Vergilio

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 conjunto de artigos 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. Este artigo trata da estratégia propriamente dita.

Palavras chaves: estratégia de teste, teste cliente-servidor, estudo de caso.

INTRODUÇÃO

No artigo anterior (BB nº 114 de Outubro 2001) foi apresentado um resumo da importância do teste e dos trabalhos encontrados na literatura que formaram a base para a estratégia de teste proposta para o ambiente cliente-servidor.

Além dos trabalhos descritos no artigo anterior, a ETACS também levou em consideração um estudo empírico realizado através da análise de informações obtidas através de uma pesquisa realizada em uma empresa que utiliza tecnologia cliente-servidor.

Com a finalidade de levantar a situação da atividade de teste realizada nos sistemas dentro desta empresa foi elaborado um questionário e distribuído para 138 pessoas, das quais 35% responderam, entre gerentes e coordenadores, analistas e líderes de projeto e programadores e técnicos de suporte. O objetivo é verificar a eficiência e os problemas existentes para a realização do teste.

As respostas coletadas foram analisadas estatisticamente e o resumo das principais conclusões que serviram como base para a ETACS são apresentadas a seguir:

  • o estabelecimento de uma estratégia é bastante importante, pois, a partir dela, roteiros e ferramentas poderão ser estabelecidos;

  • a estratégia deve fornecer uma maneira sistemática para realizar o teste, incluindo um conjunto de fases, e estabelecer os documentos a serem produzidos em cada fase;

  • esclarecer que tipos de teste e critérios devem ser aplicados, considerando a arquitetura cliente-servidor;

  • teste de performance e regressão devem ser enfatizados, bem como testes estruturais, pois estes raramente são realizados e podem revelar erros de lógica, apontados como os principais problemas;

  • prover um meio de auxiliar na aplicação dos testes funcionais com dados gerados a partir dos requisitos do usuário, pois testes funcionais são bem utilizados na empresa, e propor meios mais eficientes de geração de dados;

  • a elaboração de um plano e o registro dos recursos de tempo e dos defeitos encontrados durante a atividade de teste, pois auxiliam na obtenção de uma relação custo-benefício que pode justificar a importância de dedicar um tempo específico a essa atividade no cronograma do projeto;

  • contemplar uma maneira de manter arquivados os dados de teste usados, podendo atualizá-los a fim de manter um histórico e permitir que possam ser usados no teste de regressão, ou seja, um ambiente de teste;

  • fazer com que os testadores estejam motivados a encontrar erros nos programas;

  • comprovadas a necessidade e expectativa de um roteiro, o que pode ser simplista demais, que auxilie a atividade de teste. A maior expectativa é que a utilização de uma ferramenta auxilie a execução desta tarefa;

  • falta conhecimento formal de métodos de teste. Atualmente, os testes são realizados de maneira intuitiva. Um resultado observado é a necessidade de treinamento que comprove esse fato.

Com isso, conclui-se que é imprescindível a elaboração de uma estratégia de teste para auxiliar essa atividade na empresa.

ESTRATÉGIA PROPOSTA

Esta seção descreve a metodologia ETACS (Estratégia de Teste de Software para Ambiente Cliente-Servidor). Ela considera os resultados da pesquisa descrita na seção anterior e os pontos positivos de diferentes estratégias encontradas na literatura e abordadas no primeiro artigo desta série. Voltada para ambiente cliente-servidor 3 camadas, utiliza a abordagem de ciclo de vida de desenvolvimento de software iterativo e caso de uso para capturar e definir os requisitos funcionais do sistema de software [1], [3]. A Figura 1 mostra um esquema da visão global e estática da ETACS dentro das etapas de desenvolvimento do software, apresentadas resumidamente na seqüência.

1. Etapa inicial

Essa etapa é também conhecida como modelagem de negócio, em que, para efeito da atividade de teste, são definidas apenas as estimativas de custo. Para que possa ser gerada esta estimativa de custo, outras informações do sistema são necessárias além da definição do problema. Portanto, nessa etapa são geradas várias informações que propiciam entendimento sobre o projeto de sistema que deverá ser desenvolvido, do qual a estimativa de custo de teste deve fazer parte. Essas informações são utilizadas como entrada de dados para gerar o plano de teste, que é descrito a seguir.

2. Plano de teste

Depois de levantadas as informações iniciais que propiciam entendimento suficiente sobre o problema, conforme descrito na etapa inicial, pode-se iniciar a construção do plano de teste. É necessário que algumas questões importantes para o projeto tenham sido especificadas e bem definidas para se iniciar a atividade de teste propriamente dita, apesar da preocupação inicial com os custos e recursos do teste levantada na etapa anterior.

A estratégia propõe que o plano de teste contenha os itens especificados abaixo:

  • Identificação dos requisitos através de caso de uso - a partir dessa identificação, serão definidos que testes serão aplicados para cada caso de uso. Um caso de uso pode gerar nenhum, um ou mais dados de teste. Para complementar os casos de teste, além dos casos de uso, são utilizadas também entrevistas com o usuário final e outras documentações levantadas para o projeto, similarmente ao RUP [1], [3].

  • Avaliação dos riscos e definição de prioridades - depois que os casos de uso estão especificados é necessário identificar quais têm maior prioridade e devem ser mais criteriosamente testados. Para auxiliar nessa tarefa bastante complexa e importante, é proposto um roteiro passo a passo. Nesse roteiro, são utilizados os itens e pesos sugeridos na ferramenta da Rational [3] (Tabela 2). Para cada item, é atribuído um conceito, utilizando-se a Tabela 1 [4]. A cada conceito da Tabela 1 é associado um grau de importância de 1 a 5, seguindo uma escala elaborada por Karlsson et al [2], apresentada na Tabela 3. Para cada item avaliado, substituem-se os conceitos Crítico pelo valor correspondente 5, Prioritário por 4, Regular por 3, Pouca importância por 2 e Exceção de qualidade por 1. Os valores substituídos são, então, multiplicados pelo peso (Tabela 2), e em seguida calculam-se os valores obtidos para cada item. A prioridade de cada caso de uso poderá ser Alta, Média ou Baixa, de acordo com o valor da somatória dos conceitos obtidos para cada item associado ao caso de uso considerado.

 

  • Identificação dos tipos de teste, técnicas e critérios – considerando-se que, quanto mais se testar, mais caro fica, que testes aleatórios não podem ser medidos e que os critérios de testes aplicados são mais eficazes do que testes aleatórios, a ETACS propõe uma sugestão de técnicas e critérios de acordo com o grau de prioridade do caso de uso, ressaltando que a identificação dos tipos de teste está mais relacionada com a característica do componente, método ou função que será testado do que com a prioridade, mas a prioridade indica quão rigorosos devem ser os critérios utilizados. Para auxiliar nessa tarefa, a ETACS propõe um roteiro relacionando os níveis de teste apresentados pelo Pressmann [5], com as camadas do ambiente cliente-servidor [4], resultando na Tabela 4. Para cada nível, são sugeridos alguns critérios tradicionais e também os testes propostos por Mosley [4]. Essa sugestão de critérios não pode ser rigorosa, pois cada caso de uso tem de ser analisado segundo seus requisitos e características e então identificar quais dos diversos critérios tradicionais podem ser aplicados. O grau de prioridade define quão rigorosos serão esses critérios. Por exemplo: em um caso de uso que ocorra com bastante freqüência e não realiza atualizações, não são necessários testes de integridade, e testes de performance são altamente recomendados.

  • Revisão do plano de trabalho quanto aos recursos humanos - neste momento, é possível estimar um custo mais aproximado da realidade. Definem-se as pessoas que terão as responsabilidades pelas atividades de teste e o papel de cada uma.

  • Revisão do plano de trabalho quanto ao ambiente - nesta etapa, deve ser feita uma revisão no plano de trabalho quanto à estimativa de custos para o ambiente em termos de software e hardware.

  • Ajuste do cronograma - depois de levantadas as informações no plano de teste com relação aos tipos de testes, pessoas e ambientes, é possível ajustar o cronograma do projeto contemplando as atividades dessas pessoas, bem como os produtos intermediários com relação aos testes.

3. Projeto de casos de teste

A partir dos casos de uso e requisitos podem ser extraídos casos de teste e, posteriormente, dependendo do critério e técnica selecionados, adicionados casos de teste mais adequados, pois cada critério e tipo de teste determina como são gerados os casos de teste e indica coberturas. Quanto mais próximo do período de implementação, mais casos de teste podem ser adicionados para cobrir os critérios selecionados. Devem ser especificados os critérios de satisfação para cada tipo de teste (critérios de cobertura), quando não estiverem implícitos. A elaboração dos casos de teste não muda por causa do ambiente cliente-servidor para a maioria dos critérios tradicionais. A arquitetura afeta principalmente os testes de sistema.

4. Execução dos casos de teste

No ciclo de vida iterativo [4], é na fase de construção ou implementação que se concentra o maior esforço e tempo de teste. Só que para o ambiente cliente-servidor tem um detalhe a mais. Executa-se o teste de unidade para o componente, função ou método, testa-se este componente integrando-o com partes maiores e submetem-se essas partes integradas a um teste de sistema, como segurança, carga, desempenho, etc. Os testes devem ser executados dentro e fora do horário de pico, para considerar o tráfego de rede e a sobrecarga do gerenciador de base de dados.

Devem ser isoladas as camadas de apresentação, de negócio e de dados, e muitas vezes para isso são construídos stubs e drivers, mesmo nos testes de unidade. Deve-se construir um acesso direto ao banco e comparar os resultados. Deve ser construída uma maneira diferente de acessar a camada de negócio, alterando os tipos das chamadas da interface.

5. Avaliação dos casos de testes implementados

Analisando-se os dados, se for constatado algum defeito, ou mesmo alguma falha no ambiente, ou retorna-se ao passo anterior - execução dos casos de teste - e realiza-se o teste de regressão após a correção do problema; ou surge até mesmo a necessidade de projetar novos casos de teste, para atingir alguma camada específica, retornando para o passo de projeto de caso de teste. De acordo com as métricas estabelecidas e critérios de cobertura, pode-se verificar se os casos de teste aplicados foram suficientes para atingir a cobertura necessária para cada critério. Se não foram suficientes, novos casos de teste devem ser gerados.

Importante: implementar um ou dois casos de uso, um incluindo consulta pesada e outro, um cadastro pesado. Testar aspectos de segurança, desempenho, integridade, carga e estresse para validar a arquitetura antes de construir o sistema inteiro. Esses casos de uso devem ser selecionados pelo analista que conhece bem o negócio para extrair casos de usos não muito complexos e que contemplem necessidade de vários tipos de teste para avaliar a arquitetura.

6. Documentação dos casos de teste e resultados obtidos

 

É importante que se tenha documentado todos os casos de teste utilizados para cada caso de uso, pois, se algum dia for necessário fazer alguma manutenção pode-se refazer esses testes. Deve ser definido um diretório centralizado para essa documentação. Informações a serem documentadas: uma descrição de como foram efetuados os testes, os resultados obtidos e em que condição. Dessa forma, também é possível manter um registro do benefício gerado a partir dos testes e, de sua utilidade para que se possa justificar custos e acompanhar a evolução do desenvolvimento. É uma tarefa importante e que acompanha cada etapa dessa estratégia.

CONCLUSÃO

Este é segundo artigo de uma série que faz parte da elaboração da estratégia adaptada para o ambiente cliente-servidor.

O teste é muito importante para a garantia da qualidade dos sistemas produzidos ou gerenciados por qualquer empresa. O teste é necessário, para que se atinjam os níveis mais altos de qualidade e o grau de certificação que toda empresa almeja e para que seus produtos sejam formalmente testados, com critério. Um teste feito ao acaso estará fadado a um desastre quase inevitável. O planejamento não é a garantia de que tudo correrá tranqüilamente, mas é um passo necessário que aumenta muito as chances de sucesso.

Para a expectativa da utilização de uma ferramenta que auxilie a execução dos testes a ETACS procura relacionar ferramentas disponíveis comercialmente que podem auxiliar esta tarefa embora possa ser executada sem o auxílio de uma.

A natureza distribuída do ambiente cliente-servidor com toda a sua complexidade torna o teste do sistema mais difícil e representa um grande desafio e avanço na área de teste de software. A ETACS propõe que os requisitos sejam levantados através de casos de uso, que sejam estabelecidas prioridades, as quais apenas indicam quão criterioso deve ser o teste e, dependendo destas características, das prioridades definidas, das sugestões propostas por Mosley para cada camada e dos critérios de testes apontados na literatura, que sejam identificados os critérios de teste mais adequados.

No ambiente cliente-servidor, uma grande dificuldade do teste é a divisão em camadas, o que aumenta a complexidade do software e dificulta a atividade de teste. A ETACS propõe que, nos testes de unidade, utilizando técnicas e critérios convencionais, executem-se testes para componentes, métodos e funções que sejam mais complexas e cujo grau de prioridade seja ALTO. Testes de integração devem ser feitos conforme a necessidade e complexidade do sistema e os componentes devem ser testados a partir do término do desenvolvimento dos primeiros casos de uso com teste de estresse, performance, integridade e segurança. Esses testes são feitos com as três camadas e, quando os resultados são duvidosos, devem-se isolar as camadas. Para isso, muitas vezes, é necessário construir stubs e drivers.

Dessa forma, os testes serão feitos bem no começo, quando ainda não há pressão quanto ao tempo e podem ser encontrados os problemas com desempenho e até mesmo decidir por outra arquitetura. Uma vez que uma das grandes dificuldades apontadas de realizar teste nesta arquitetura é o desempenho no ambiente real, com muita carga de dados e muitos usuários. A falta de teste próprio para desempenho pode tornar um projeto recém concluído um fracasso ou necessitado de manutenção. Por isso, nesse tipo de arquitetura, os testes de segurança, integridade e performance são altamente recomendados e devem ser feitos no início do projeto, com uns cinco casos de uso, selecionados por alguém do negócio, para que a arquitetura seja validada o quanto antes.

Com a documentação, proposta pela ETACS, é possível analisar os benefícios de realizar a atividade de teste para justificar tempo no cronograma de projetos futuros. Outro detalhe é a recomendação de utilização de ferramentas para auxílio nos testes mais críticos, como estresse e carga, minimizando o trabalho repetitivo e aproveitando melhor o tempo pois os testes podem ser programados.

Referências

 

 

[1] JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. The unified software development process reading. Massachusetts: Addison-Wesley, 1999. 463 p.

[2] KARLSSON, J. Software requirements prioritizing. In: INTERNATIONAL CONFERENCE ON REQUIREMENTS ENGINEERING, 2., 1996, Colorado. Proceedings... Los Alamitos: IEEE CSP, 1996. 6 p.

[3] KRUCHTEN, P. A Rational development process: white paper. Disponível em: <http://www.rational.com/products/rup/prodinfo/whitepapers/>. Acesso em: abr. 2001

[4] MOSLEY, D. J. Client server software testing on the desktop and the web. Indianapolis: Prentice Hall, 2000.

[5] PRESSMAN, R. S. Software engineering: a practitioner's approach. 4. ed. New York: McGraw-Hill, 1997.