Neste captulo apresentamos conclus~oes obtidas sobre a denic~ao da linguagem WSat, assim como sobre as ferramentas de apoio desenvolvidas. Trabahos relacionados s~ao comentados, assim como s~ao sugeridos trabalhos futuros que permitam melhorar os re- sultados alcancados.
Neste cap tulo apresentamos nossas conclus~oes, indicando primeiramente as contri- buic~oes fornecidas com a denic~ao da linguagem WSat, assim como a construc~ao das suas ferramentas de apoio. Em seguida, discutimos sobre trabalhos relacionados a es- te. Por m, apresentamos sugest~oes de trabalhos futuros para melhorar os resultados obtidos.
6.1 Conclus~oes
A principal contribuic~ao deste trabalho e a denic~ao da linguagem WSat, utilizada para descric~ao de casos de teste de aceitac~ao de sistemas Web. Esta linguagem possui carac- ter sticas que lhe permitem possuir um alto n vel de abstrac~ao e reuso de codigo. Em WSat, os testes s~ao estruturados em duas partes. A primeira delas e a descric~ao estru- tural da GUI do sistema, onde s~ao denidos tipos para representar os componentes Web presentes na GUI. Nestes tipos s~ao denidas propriedades que indicam as caracter sticas que os componentes Web testados devem satisfazer. Tambem e poss vel denir tipos de forma an^onima, tornando a descric~ao estrutural mais concisa.
A segunda parte dos testes e a descric~ao comportamental desta GUI, onde os tipos denidos s~ao utilizados para manipular os componentes Web simulando a execuc~ao do sistema. Atraves dos servicos fornecidos pelos tipos especiais previamente denidos em WSat, podemos simular ac~oes dos usuarios como, por exemplo, cliques em links e o preenchimento e submiss~ao de formularios. Servicos tambem podem ser utilizados para vericar o conteudo din^amico gerado por paginas Web.
Para n~ao perder abstrac~ao, WSat permite um conjunto limitado de express~oes e operadores logicos. Entretanto, n~ao foi denida para WSat uma forma abstrata de parametrizac~ao dos dados de teste e acessos a banco de dados, assim como a vericac~ao de performance e concorr^encia. Atualmente,estas tarefas s~ao realizadas com a utilizac~ao de codigo Java 19] embutido, o que pode comprometer a abstrac~ao do codigo.
Outra contribuic~ao importante deste trabalho foi a criac~ao de ferramentas de apoio a realizac~ao dos testes WSat, como um ambiente de execuc~ao para WSat e geradores de codigo. O ambiente de execuc~ao foi utilizado para validar e viabilizar o uso de WSat. Para sua implementac~ao, utilizamos o ambiente de execuc~ao de Java e APIs externas, como por exemplo, a API HttpUnit 18]. Com isto, conseguimos reduzir boa parte do esforco necessario para a sua implementac~ao
Para reduzir o impacto causado na produtividade, a curto prazo, pela criac~ao dos casos de teste, foram denidos geradores de codigo. Isto so foi poss vel devido a carac- ter stica de WSat descrever de forma expl cita a GUI do sistema testado a partir dos tipos WSat denidos. A construc~ao de geradores de codigo a partir de outras lingua- gens de teste que n~ao WSat s~ao praticamente inviaveis, devido a mistura das descric~oes estruturais e comportamentais da GUI do sistema .
Estes geradores utilizam o parser de WSat constru do no ambiente de execuc~ao de WSat. Isto porque a arvore sintatica de WSat foi estruturada de acordo com o padr~ao
Visitor, desacoplando o codigo da arvore sintatica do codigo que manipula a mesma. O primeiro dos geradores criados e um gerador de codigo de teste, capaz de gerar parte do codigo que descrevea estrutura da GUI do sistema testado a partir de prototipos de interface em HTML. O segundo e um gerador de codigo de sistema Web, onde e poss vel gerar codigo Java seguindo padr~oes de projeto como, por exemplo, o padr~ao
Web Handler 2], assim como codigos de validac~ao de par^ametros e congurac~ao do sistema.
A alterac~ao ou adic~ao de tipos de codigo de sistema gerados e facilmente realizada, devido a utilizac~ao de templates de codigo e da facilidade de implementac~ao de novos
visitors. Para se tornar mais poderoso, este gerador faz uso de informac~oes adicionais que podem ser adicionadas em programas WSat, atraves da palavra chavestatice da clausulavalidate, por exemplo.
Outra contribuic~ao fornecida foi a especializac~ao do padr~ao de projetoWeb Handler
para a utilizac~ao da API de validac~ao de par^ametros atraves de arquivos XML e da API FreeMarker, 17] para separac~ao entre codigos Java e HTML.
Foi realizado um experimento com um sistema Web real, de pequeno porte, para validar e analisar a viabilidade da utilizac~ao de WSat e das ferramentas de apoio desen- volvidas. Este experimento provou que a utilizac~ao de WSat e dos geradores pode trazer um ganho na corretude dos sistemas sem comprometer a produtividade do seu desenvol- vimento. De fato, o ganho com a gerac~ao de trecho de codigos de sistema mostrou ter sido suciente para a programac~ao dos programas WSat. Entretanto, se a cobertura do sistema pelos testes fosse ampliada com um numero grande de casos de teste, o ganho de tempo com a gerac~ao de codigo n~ao seria suciente para compensar totalmente o tempo gasto com a denic~ao dos casos de teste.
Para provar os benef cios gerados pela utilizac~ao do processo de teste e ferramentas de apoio denidos, faz-se necessaria a realizac~ao de um numero maior de experimentos. Entretanto, atraves do experimento realizado pudemos vericar a ordem de magnitude da perda de produtividade, a curto prazo, obtida com a utilizac~ao do processo de teste denido. O fato de obtermos uma reduc~ao no tempo de desenvolvimento ao inves do acrescimo que era esperado sugere que, mesmo obtendo resultados inferiores com a realizac~ao de outros experimentos,n~ao devemosvericarimpactos negativos signicantes na produtividade com a realizac~ao dos testes.
Vericamos tambem, atraves da impress~ao dos programadores participantes do ex- perimento, um maior n vel de abstrac~ao e facilidade de entendimento do que programas escritos em outras linguagens de teste. Com isto, os programadores aparentaram estar mais dispostos para a realizac~ao de atividades de teste.
Inicialmente WSat foi projetada para visando a realizac~ao de testes de aceitac~ao em sistemas Web. Entretanto, com a realizac~ao do experimento, vericamos tambem a utilidade de WSat para a realizac~ao de outros tipos de teste de sistemas Web que n~ao os de aceitac~ao, como os testes de performance, concorr^encia e carga.
Estre trabalho mostra que testes de aceitac~ao vericam a corretude do sistema, podendo tambem ser utilizados para acompanhar o progresso dos sistemas em desenvol- vimentos, assim como para o monitoramento dos sistemas produzidos e em operac~ao. Alem disto, eles prov^eem informac~oes uteis para poss veis gerac~oes de codigo. Espera- mos com isto incentivar a utilizac~ao deste tipo de teste no desenvolvimento de sistemas Web.
Na analise de duas ferramentas de teste realizada no Cap tulo 2, vericamos o su- porte inadequado de suas linguagens de teste. Mesmo poderosas, estas linguagens n~ao apresentam um n vel de abstrac~ao satisfatorio. Alem disto, vericamos que, embora o modo mais facil para criac~ao de casos de teste e atraves de ferramentas que gravem as ac~oes de usuarios durante a execuc~ao do sistema, o papel das linguagens de teste con-
tinua importante. Isto porque para a realizac~ao de testes mais elaborados, e necessario recorrer para recursos contidos nas linguagens de teste que os casos de teste s~ao gra- vados. Este mesmo fato acontece durante a manutenc~oes dos casos de teste existentes, assim como na utilizac~ao da pratica Test First Design 12], indicada pela metodologia
Extreme Programming 3], onde os testes s~ao criados antes da implementac~ao do codigo testado.
Para analisar ferramentas e linguagens de teste dispon veis no mercado, denimos criterios de analise que levam em considerac~ao os suportes fornecidos por estas ferra- mentas e o impacto dos mesmos na qualidade do processo de desenvolvimento e dos produtos desenvolvidos. Estes criterios identicam as principais caracter sticas que es- tas ferramentas e linguagens devem possuir, podendo ser utilizados como base para a analise ou desenvolvimento de outras ferramentas e linguagens de teste.
6.2 Trabalhos Relacionados
A linguagem TestTalk 28], utilizada para descric~ao de casos de testes, inclusive testes de aceitac~ao, foi denida com o objetivo de ser uma linguagem compreensiva e portavel. Programas escritos em TestTalk, para serem executados, necessitam ser compilados para uma outra linguagem de teste. Desta forma, programas TestTalk s~ao, a princ pio, independente de plataforma e de ferramentas de teste.
TestTalk utiliza termos espec cos do dom nio que podem ser denidos pelo testador. Para cada termo denido, uma regra de transformac~ao tem que ser denida para que este termo seja transformado em codigo executavel na linguagem da ferramenta de teste destindo. Os programas TestTalk s~ao estruturados de forma a separar os dados de entrada, a execuc~ao e a vericac~ao do resultado de cada passo do teste. Entretanto, so esta estruturac~ao dos programas e a utilizac~ao de termos do dom nio n~ao conseguem produzir o n vel de abstrac~ao conseguido por WSat com a representac~ao de tipos que representam componentes Web.
Ferramentas como a QARun, mostrada no Cap tulo 2, possuem o poder de progra- mac~ao encontrados nas linguagens convencionais. Este poder, no entanto, traz com- plexidades desnecessarias ao codigo de teste, dicultando a sua criac~ao e manutenc~ao. Facilidades como a gravac~ao de casos de teste reduzem bastante este problema durante a criac~ao dos testes, sem poder auxiliar signicantemente nas manutenc~oes.
Outras ferramentas desenvolvidas e dispon veis s~ao baseadas em XML. Exemplos disto s~ao a JXWeb, tambemmostrada no Cap tulo 2, e a Canoo WebTest 10], lancada no mercado recentemente. Estas ferramentas fornecem a facilidade do aprendizado, ja que a linguagem XML e bastante difundida no mercado. Embora de facil aprendizado, XML n~ao foi constru da com foco na sua programac~ao por pessoas, mas sim por programas durante as suas comunicac~oes com outros programas. Desta forma, o n vel de abstrac~ao destas linguagens tambem ca comprometido.
6.3 Trabalhos Futuros
Com relac~ao a linguagem WSat, sugerimos como trabalho futuro a denic~ao de sua sem^antica formal. Alem disto, para uma melhor estruturac~ao dos programas WSat, a
linguagem pode ser estendida atraves da criac~ao de modulos. Isto facilita a manipulac~ao do codigo de teste, principalmente quando se tratando de testes em sistemas Web de medio e grande porte. Podemos tambem denir formas abstratas de parametrizac~ao dos dados de teste, acessos a banco de dados, entre outros, com o intuito de reduzir e ate eliminar a utilizac~ao de codigo Java embutido, garantindo a abstrac~ao do codigo.
As associac~oes entre paginas Web representadas por comolinkse ac~oes de formularios HTML n~ao foram exploradas neste trabalho. Estudando mais profundamente estas associac~oes, podemos vericar se as mesmas podem permitir que os geradores de codigo gerem de outros tipos de codigo que n~ao os ja implementados.
O ambiente de execuc~ao de WSat pode ser incrementado com vericac~oes sem^anticas como, por exemplo, a vericac~ao dos tipos. Alem disto, podemos implementar a exe- cuc~ao dos servicos fornecidos por tipos WSat que s~ao utilizados para a vericac~ao do conteudo din^amico de paginas Web.
Para o gerador de codigo de teste, mesmo sem ser atividades de pesquisa, e inte- ressante sua extens~ao atraves da criac~ao de uma ferramenta para gravac~ao de casos de teste de aceitac~ao de sistemas Web na linguagem WSat, visando fornecer uma alternati- va mais simples para a criac~ao dos casos de teste. A implementac~ao deste gravador pode se utilizar do gerador de codigo de teste, capaz de extrair a denic~ao de tipos WSat a partir de arquivos HTML.
O gerador de codigo de sistema pode ser estendido, por exemplo, para gerar codigo de validac~ao de par^ametros atraves de JavaScript 13]. O gerador pode realizar o car- regamento devisitors dinamicamente, facilitando assim a sua extens~ao para gerac~ao de novos tipos de codigo. Otmizac~oes podem ser realizadas no gerador, como por exemplo, a gerac~ao de codigo de sistema percorrendo-se apenas uma vez a arvore sintatica dos programas WSat ao inves da utilizac~ao de um visitor para cada tipo de codigo gerado, que e mais simples porem menos eciente.
Limitac~oes das ferramentas podem ser removidas e funcionalidades novas podem ser adicionadas. A implementac~ao atual do gerador de codigo de teste, por exemplo, n~ao permite o uso de arquivos HTML de mesmo nome no prototipo de telas, mesmo que em diretorios diferentes. Para a utilizac~ao ecaz das ferramentas produzidas, tambem faz-se necessario a implementac~ao de interfaces de usuarios que facilitem sua execuc~ao. Por m, sugerimos tambem a realizac~ao de um estudo de caso utilizando tambem um sistema real, porem de medio ou grande porte, visando identicar poss veis proble- mas, como por exemplo, um grande numero de linhas de codigo de teste. Tambem e interessante realizar a gerac~ao de codigo de sistema em outros padr~oes e tecnologias, como a gerac~ao de codigo C++ 40], por exemplo.