Teste em Ambiente Cliente-Servidor: Uma Estratégia e um Estudo de Caso - Parte 3
|
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 qual 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 principais resultados desse estudo são apresentados neste artigo. Palavras chaves: estratégia de teste, teste cliente-servidor, estudo de caso. INTRODUÇÃO No primeiro artigo 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 adaptada para o ambiente cliente-servidor proposta. No segundo artigo foram apresentadas as principais conclusões com relação à pesquisa que serviu como base para definição da estratégia ETACS e a apresentação da estratégia propriamente dita. Neste artigo são apresentados resultados da aplicação da estratégia em um estudo de caso, que serviu para validá-la e refiná-la. O estudo foi realizado em uma empresa que desenvolve aplicações cliente-servidor. Na próxima seção, cada estágio da ETACS é ilustrado. ESTUDO DE CASO O software utilizado na aplicação trata do controle financeiro de arrecadações com multas dos autos de infrações do Código de Trânsito Brasileiro nos diversos documentos disponíveis. O escopo do projeto é grande e para efeitos desse artigo, apenas um módulo foi utilizado. Maiores detalhes estão em [1]. 1 Etapa inicial Seguindo as etapas da ETACS, foram descritas informações genéricas para solução do problema. Nesta etapa inicial foram identificadas a tecnologia e arquitetura adotadas, a infra-estrutura de hardware e software para desenvolvimento, volume das informações que podem ser geradas, produtos a serem gerados, etc. 2 Plano de Teste Associados ao módulo foram identificados 8 Casos de Uso e estabelecidas as prioridades conforme orienta o roteiro da ETACS. Nas primeiras iterações foram identificados requisitos de tempo e segurança. Alguns critérios de aceitação com relação a tempo e segurança foram estabelecidos. O tempo aceitável para as consultas com poucos dados é de 2 a 3 segundos para uma consulta simples, que retorne uns 500 bytes. O sistema deve bloquear a execução de métodos por pessoas não autorizadas, e não permitir a entrada direta no banco de dados garantindo a segurança. A Tabela 1 mostra os resultados obtidos a partir da aplicação do roteiro para estabelecimento do grau das prioridades, que vai auxiliar na identificação dos tipos de testes. Devem ser propostos critérios mais rigorosos de teste para casos de uso que tenham grau de prioridade mais altos. Foram propostos alguns testes com base na especificação de requisitos, no grau de prioridade e nas sugestões de testes indicados pela ETACS, bem como a revisão da alocação dos recursos e máquinas que farão parte do teste, o que deve estar instalado e configurado nas máquinas e as pessoas que serão responsáveis pela execução do mesmo. Foram feitos os devidos ajustes no cronograma, considerando 3 horas para cada caso de uso para a realização dos testes de integridade e segurança; 12 horas para o primeiro caso de uso e 4 horas para os demais para testes de carga, volume, estresse e desempenho; 6 horas para cada caso de uso para os testes de unidade e integração e testes principais de acordo com a especificação. Um dos maiores problemas da arquitetura cliente-servidor é que no ambiente de desenvolvimento o desempenho é normal mas quando o sistema é colocado em produção o tempo é muito prejudicado. Diante deste fato a ETACS ressalta a importância do teste de performance.
3. Projeto e Execução de Casos de Teste Nesta etapa são planejados os casos de teste para os critérios identificados na etapa anterior e estabelecem-se os critérios de parada para estes critérios. Exemplo de alguns dos testes feitos encontram-se na Tabela 2. As etapas de projeto e execução dos testes realizados em alguns casos de uso são descritas conjuntamente a seguir. Teste de condição: Na execução do teste de condicão foram obtidos resultados diferentes do esperado. Aconteceu uma falha no sistema, isso aconteceu devido a uma falha na especificação dos requisitos que, com a aplicação da estratégia, foi possível identificar. Este teste valida o negócio e não o ambiente apesar de que se houvesse uma falha no ambiente o teste sofreria impacto.
Teste de segurança: O teste de segurança foi realizado antes mesmo do início do sistema, com o objetivo de validar o aspecto de segurança da arquitetura a ser utilizada. Os casos de teste foram gerados utilizando-se a arquitetura da Figura 1. Os resultados obtidos na avaliação dos casos de teste estão resumidos na Tabela 3. Como pode ser visto nesta tabela, o dado de entrada 5 não apresentou o resultado esperado, acontecendo uma falha.
Figura 1: Arquitetura simplificada para o Teste de Segurança
Teste de estresse: a dificuldade desse tipo de teste está na geração de uma grande variedade de dados. No entanto, para o Caso de Uso, os dados existem e foram colocados em um arquivo batch texto. Foram utilizados 50.000 registros e implementado um programa para controlar os tempos com 10 usuários simultâneos acessando os componentes automaticamente por 1 hora e meia direto. O resultado esperado é de que todas as consultas fossem executadas sem problemas. Na execução deste teste foram obtidos os resultados: quando mais de um usuário estava acessando, algumas máquinas apresentaram um tipo de erro: "3704 - Operation is not allowed when the object is closed" enquanto outras (mais de uma) estavam acessando normalmente os mesmos componentes. Parece que foi um problema com o servidor mas a razão do problema não tinha sido detectada. Teste de performance: como para o Caso de Uso 4 - Consultar Árvore por Docto, o fator desempenho é primordial, um esforço maior de teste de performance foi gasto. Foi utilizado como entrada o mesmo arquivo batch texto utilizado para teste de estresse. O resultado esperado é de que em 90% dos casos atinja-se no mínimo um tempo de 1 segundo e no máximo 5, com 1 ou vários usuários acessando. Na etapa de execução do caso de teste foram obtidos os seguintes resultados: Como não há disponibilidade de ferramenta, foi construído a partir de um programa em visual basic, chamadas contínuas a componentes e marcando tempo. O programa toma por base uma entrada de dados em arquivo texto de 10.740 linhas e sorteia um número múltiplo de 500 para ser o ponto de partida. Também controla o tempo para que possa ser programado um horário de início. Para que isso funcione todos os micros devem estar com o horário sincronizado com um mesmo servidor. O programa também chama aleatoriamente um dos 3 casos de usos, ou seja, este teste já está englobando Caso de Uso 2 e Caso de Uso 3. Conforme observado na Tabela 4, que apresenta o resultado em apenas duas máquinas, é calculado o tempo de chamadas das funções (TpCmp) e outro tempo considerando a apresentação do resultado em tela inclusive (TpTran); também é calculado o número de distribuições que retorna para cada consulta e também o número de bytes que retornou. Os resultados dos tempos são gravados em arquivo texto e, posteriormente, foram agrupados por função e por número de máquinas que executou o teste. A análise mais justa é feita considerando a mesma máquina, pois desconsidera aspectos de ambiente de máquina.
4. Avaliação dos casos de teste Durante o teste de performance o tempo em que os componentes levam para executar a função para uma máquina é bastante aceitável, e não muda muito quando tem 11 usuários acessando. Isto pode ser verificado para todas as máquinas, 2 delas com dados resumidos na Tabela 4. Mas algo que chamou a atenção é o tempo que leva para mostrar os resultados na tela, que foi muito além do esperado. Demonstrando algum problema na lógica dessa apresentação, algum componente ou software não está bem configurado, ou algo a ser descoberto. É intrigante o fato de uma média de 5 registros levar 1,2 segundos para serem trazidos da base de dados e levar 9 segundos, em média, para serem exibidos dados na tela. (As Figuras 8 e 9 apresentam uma tabulação dos dados obtidos para uma máquina) Para tentar identificar a origem do problema foi construída uma aplicação para acesso direto ao banco sem passar pelo componente, identificada na tabela por CS2, e outro componente sendo executado no MTS só que em vez de passar um Recordset como retorno passa um vetor, identificado pelo sufixo Ar. E em ambos os casos o tempo de receber o componente e mostrar é praticamente o mesmo. Novos testes foram então gerados e obtidos os resultados em uma das máquinas que foram submetidas ao teste. Observou-se o comportamento semelhante às demais e a diferença de tempo que um componente precisava para executar, sem considerar interface. Observe a Tabela 5 e a Figura 2. Foram calculados tempo total para executar o componente e mostrar na interface, chamado tempo de transação (Figura 3) e o número de bytes que era passado pela rede para cada máquina. Em outras máquinas foram avaliadas outras variações de arquiteturas com base nestes resultados.
Figura 2: Tempo de componente do teste de performance na máq07vvvv
Figura 3: Tempo de transação do teste de performance na maq07vvvv 5. Documentação dos casos e resultados obtidos Os casos de testes executados foram documentados em arquivos juntamente com outros do projeto em um diretório. CONCLUSÃO Este é terceiro e último artigo de uma série que faz parte da elaboração da estratégia adaptada para o ambiente cliente-servidor. Resultados positivos da execução dos testes:
REFERÊNCIAS 1. MICROSOFT. The Windows interface guidelines for software design. Washington: Microsoft Press, 1995. 2. VOLPI, L. M. Estratégia de teste para ambiente cliente-servidor. Curitiba: DInf UFPR, 2002. Relatório Técnico em elaboração. |
