Você está na página 1de 27

UNIVERSIDADE FEDERAL DO PIAU

PR-REITORIA DE PESQUISA E PS-GRADUAO COORDENADORIA GERAL DE PESQUISA

PROGRAMA DE BOLSAS DE INICIAO EM DESENVOLVIMENTO TECNOLGICO E INOVAO - PIBITI

RELATRIO FINAL
(2010 - 2011)

UMA FERRAMENTA PARA GERAO AUTOMTICA DE RELATRIO DE MUDANAS

REA DO CONHECIMENTO: SUB-REA DO CONHECIMENTO: CENTRO/UNIDADE: BOLSISTA: ORIENTADOR (A): FONTE DE FINANCIAMENTO DO PROJETO DE PESQUISA: DATA DE INCIO: Agosto/2010

Engenharia de Software Testes de Software CCN/DIE Cleiton dos Santos Moura Pedro de Alcntara dos Santos Neto PIBITI/UFPI DATA DA CONCLUSO: Julho/2011

Relatrio Final de Iniciao Cientfica sob o ttulo: Uma Ferramenta para Gerao Automtica de Relatrio de Mudanas, escrito pelo bolsista do PIBITI/UFPI Cleiton dos Santos Moura sob a orientao do Professor Doutor Pedro de Alcntara dos Santos Neto.

Cleiton dos Santos Moura Bolsista PIBITI/UFPI

Pedro de Alcntara dos Santos Neto Professor Orientador

Teresina, 04 de Agosto de 2011

Plano de Trabalho do Bolsista


Ttulo: Uma Ferramenta para Gerao Automtica de Relatrio de Mudanas Nome do Bolsista: Cleiton dos Santos Moura Orientador: Pedro de Alcntara dos Santos Neto Resumo dos objetivos do trabalho do aluno: O principal objetivo deste trabalho criar uma ferramenta que permita reduzir, ou mesmo eliminar, o esforo necessrio documentao das mudanas que foram feitas em um software em manuteno. Isso ser alcanado atravs do desenvolvimento de uma ferramenta que ir gerar relatrios de mudanas de software utilizando como insumo testes funcionais do software que fora alterado. A partir disso, o aluno dever documentar a ferramenta desenvolvida e escrever um artigo sobre a ferramenta construda. Isso ser feito de acordo com as fases do trabalho, detalhadas a seguir e exibidas na forma de um cronograma abaixo. Cronograma de atividades para um ano: As atividades previstas para o bolsista para o perodo de um ano esto diretamente relacionadas s fases apresentadas na metodologia do trabalho, ou seja, envolvem a Fase Terica (FT), Fase de Anlise (FA), Fase de Desenvolvimento (FD),Fase de Experimentao(FE), Fase de Finalizao (FF). As atividades dessas fases so mostradas na Tabela 1, a seguir. Deve ser observado, desde o primeiro ms de realizao do projeto, o desenvolvimento do Relatrio Parcial que apresentar os resultados da Fase Terica e da Fase de Anlise. A Fase de Desenvolvimento a maior delas, pois nessa fase que a ferramenta dever ser construda. Tabela 1: Cronograma a ser realizada pelo bolsista.

FASES
FT FA Relatrio Parcial FD FE FF Relatrio Final

Ago

Set

2010 Out Nov

Dez

Jan

Fev

Mar

2011 Abr Mai

Jun

Jul

____________________________ Cleiton dos Santos Moura Bolsista ___________________________________ Pedro de Alcntara dos Santos Neto Orientador

Resumo
Com a necessidade de desenvolver softwares com mais qualidade, testes esto sendo cada vez mais importantes e com isso est se tornando uma prtica comum nas etapas de desenvolvimento de softwares. Existem diversos tipos de testes, estando entre essas divises o teste funcional que tem como objetivo verificar se o software est de acordo com as especificaes definidas pelo usurio. Com as constantes modificaes em softwares, as empresas necessitam informar aos seus clientes relatrios das mudanas feitas no software, a fim de deix-los cientes das alteraes realizadas. O trabalho aqui descrito trata da criao de uma ferramenta para gerar relatrios de mudanas entre diferentes verses do software a partir de scripts de testes funcionais. Sero mostrados neste trabalho definies sobre testes de softwares, com nfase em testes funcionais e o algoritmo de extrao dos dados a partir dos testes. O principal diferencial deste trabalho a forma como criado o relatrio, a reduo de tempo e custo com o uso da ferramenta. Palavras-chave: teste de software, relatrio de mudanas

Sumrio
Introduo..........................................................................................................................6 Fundamentao Terica.....................................................................................................6 Teste de Software......................................................................................................6 Teste de Funcionalidade...........................................................................................8 Trabalhos Relacionados....................................................................................................8 Metodologia.......................................................................................................................8 Resultados e Discusso......................................................................................................9 Relatrio de Mudana................................................................................................9 Ferramentas de Teste Funcional ............................................................................10 Canoo WebTest.......................................................................................................11 Selenium .................................................................................................................11 TChangeReport a ferramenta desenvolvida..........................................................14 Arquitetura da ferramenta .......................................................................................14 Utilizao da Ferramenta.........................................................................................16 Estudo Experimental................................................................................................19 Concluses e Trabalhos Futuros......................................................................................26 Referncias Bibliogrficas...............................................................................................26

Introduo
No desenvolvimento de programas a Documentao de Usurio muito importante para manter o usurio informado de como realizar determinadas tarefas. A Documentao de Usurio de Software um material impresso ou eletrnico que prov informaes para os usurios de um software [16]. Esta documentao serve para informar ao usurio como realizar determinada tarefa passo a passo e tambm para tirar dvidas[16]. O relatrio de alteraes faz parte desta documentao, podendo informar ao usurio tudo o que foi alterado e o que foi modificado no software. O Teste consiste em comparar os resultados esperados de um programa com os resultados esperados com seus requisitos. Se possuir diferena entre estes resultados, significa que o produto possui problema e necessita ser corrigido. Assim, o teste de software muito importante no desenvolvimento de software e reduz riscos no uso do software [8]. Quando os testes realizados so de boa qualidade indica que o software tem grande chance de no ter erros. Entre os vrios tipos de teste existe o teste funcional, onde ser utilizado para se desenvolver o relatrio de alteraes. Dentre os softwares criados atualmente, quase todos sofrem algum tipo de mudana, seja do tipo corretivo, seja do tipo de acrscimo de funes, tornando-se necessrio passar a informao ao cliente, relatando o que mudou de uma atualizao para outra, ajudando assim aos mesmos a ficarem sabendo qual vantagem existe entre uma atualizao e outra do software. Caso a empresa no fornea um manual com as informaes das atualizaes, seus clientes ficaro muito insatisfeitos, pois iro ter que aprender novamente tudo para poderem utilizar o software, causando muitas vezes at a desistncia do uso. Os testes funcionais foram escolhidos porque possuem uma grande informao em seus scripts para a gerao do relatrio de mudana. So dados que podem ser recolhidos dos scripts identificao de campos, links, botes e entre outras informaes. Com relao ao que foi visto nesta introduo notamos que o relatrio de alterao muito importante para as empresas e usurios. Este trabalho esta dividido em seis sees. Apresenta na seo 2 introduo Fundamentao Terica onde introduz conceito de Teste de Software com nfase em Teste de funcionalidade, j que neste trabalho ser enfatizada essa tcnica. Seo 3 ser mostrada a diferena e alguns pontos idnticos ao trabalho aqui realizado. Na seo 4 so mostradas todas as fases da pesquisa. Na seo 5 so relatadas todas as decises, problemas enfrentados para a criao da ferramenta. Na ltima seo so apresentadas as contribuies desta pesquisa e trabalhos futuros.

Fundamentao Terica
Teste de Software Com o crescente aumento do nmero de softwares s cobranas por meio dos usurios veem aumentando por qualidade. Estas cobranas tm motivado a definio de

mtodos e tcnicas para o desenvolvimento de softwares que atinjam os padres de qualidade impostos. Com isso, o interesse pela atividade de teste de software vem aumentando nos ltimos anos[3]. Pode-se definir teste como uma atividade que tem como objetivo verificar se o software construdo est de acordo com sua especificao e se satisfaz as expectativas do cliente e ou utilizador do sistema [3]. Os softwares implementados sobre o uso de teste adicionado um valor ao produto, uma vez que o teste corretamente executado tende a descobrir defeitos, que devem ser corrigidos, aumentando assim a qualidade e confiabilidade de um sistema. A construo de produtos sem teste aumenta a chance de defeitos no software, o que pode ocasionar em riscos como: perda de dinheiro, de tempo, at mesmo de vidas e prejudica a empresa desenvolvedora. Existem alguns conceitos de grande importncia para este projeto na rea de teste. So eles caso de teste, procedimento de teste, sute de teste, outputs e inputs. Inputs so as entradas de dados no sistema, enquanto que os outputs so as sadas esperadas pelo teste. Caso de teste uma especificao de como deve ser testada uma parte do software. Essas especificaes so de condies de como os testes devem ocorrer sobre os inputs e outputs. Procedimento de teste so um conjunto passos que devem acontecer para especifico caso de teste. Sute de teste um conjunto de vrios ou um caso de teste para um sistema que est sendo testado[14]. As figuras 1 e 2 a seguir mostram um exemplo de um procedimento de teste e um caso de teste.

Figura 1 Procedimento de teste de login

Figura 2 Caso de Teste para login invlido

Na Figura 2 podemos perceber que as Entradas so os inputs e que as Sadas esperadas so os outputs. importante observar que um caso de teste est ligado a um ou a vrios procedimentos de teste e que um procedimento de teste independe dos dados de um caso de teste. Os testes so classificados em vrios tipos um para cada tarefa que realiza. Os testes feitos por um grupo restrito de usurios finais (teste de aceitao); testes realizados para verificar o limite do software e avaliar seu comportamento (teste de estresse); teste usado para verificar a boa usabilidade do sistema por meio de usurios final (teste de usabilidade); teste usado para verificar se as funcionalidades do sistema esto agindo como esperado (teste funcional), onde se ter uma nfase neste trabalho. Teste de Funcionalidade Na tcnica dos testes funcionais so analisados as funcionalidades do sistema sem se preocupar com a forma de implementao do software. Por isto este tipo de teste conhecido como teste caixa preta, por tratar o software como uma caixa que s possvel visualizar o lado externo, ou seja, os inputs e outputs[3]. Os testes funcionais em empresas desenvolvedoras de softwares so realizados por pessoas que simulam usurios finais, em busca de encontrar diferenas do que foi solicitado ao que foi desenvolvido. Os testes funcionais podem ser realizados de forma automtica ou de forma manual, sendo o de forma manual mais rpida. O esforo para criao e manuteno de um teste automtico normalmente maior que para um teste manual equivalente. Mas quando construdo o teste automtico tende a ser mais econmico que o teste manual, o esforo de execuo e verificao ser uma pequena parte do esforo de construo[5]. Os testes funcionais automticos so realizados por algumas ferramentas de gravao-execuo, ou seja, elas gravam um procedimento de testes em forma de scripts, onde possvel a fcil alterao dos scripts e a partir destes criar vrios casos de teste sem a necessidade de nova captura do procedimento de teste.

Trabalhos Relacionados
No mbito de suporte a alteraes em softwares foi encontrado uma ferramenta multiplataforma open source1 desenvolvida em Java chamada jDiffChaser[2]. A ferramenta jDiffChaser compara duas verses de um software atravs de imagens capturadas pela mesma, que sero comparadas estas duas telas e relatados todas as diferenas entre elas. A principal diferena encontrada em relao a este trabalho que este realiza o relatrio de alteraes atravs de testes funcionais e apresenta um relatrio de alteraes orientado diretamente para o usurio final, ou seja, consumidor, enquanto o jDiffChaser analisa as imagens, e gera um relatrio com imagens destacando as diferenas encontradas na tela.

Metodologia

Software de cdigo aberto.

Para alcanar os objetivos e metas traados para este projeto ele foi dividido em cinco fases: Fase Terica (FT); para levantamento do estado da arte sobre o tema; Fase de anlise (FA), para o estudo sobre as principais ferramentas de apoio aos testes funcionais; Fase de Desenvolvimento (FD), para criao da ferramenta; Fase de Experimentao (FE), para realizao de um estudo experimental envolvendo a ferramenta; Fase Final (FF), para descrio do documento descritivo da ferramenta e do artigo sobre seu uso no estudo experimental realizado. Durante a Fase Terica foi realizado a pesquisa sobre trabalhos que tratem de testes funcionais de software e da utilizao desses testes para gerao de artefatos. Nesta fase foi criado o nosso padro para os relatrios de mudanas de software. O resultado desta fase serviu de base para as prximas fases. Na Fase de Anlise foram selecionadas duas ferramentas de teste funcionais open source para uma anlise detalhada dos artefatos gerados por tais ferramentas. Como a Fase de Desenvolvimento ocorreu uma parte junto a Fase de Anlise, foi analisado e criado a obteno dos dados proveniente da leitura dos scripts dos testes. Na Fase de Desenvolvimento foi implementado a ferramenta TChangeReport, que realiza de forma semiautomtica a gerao do Relatrio de Alterao, por meio de scripts de testes. Na Fase de Experimentao foi realizado um estudo experimental com o intuito de comparar o tempo necessrio para a criao dos relatrios com e sem o uso da ferramenta desenvolvida. Alm, de comparar a qualidade dos relatrios gerados com e sem o da TchangeReport. Por fim, na Fase Final foi escrito um documento e publicado na pgina http://ufpi.br/pasn a documentao da Ferramenta. Onde consta tutorial de uso da mesma e cdigo fonte. O cdigo fonte de extrema importncia para facilitar a expanso e melhorias futuras. Alm disso, nesta fase foi realizada a entrada do processo de registro da ferramenta junto ao Ncleo de Inovao e Transferncia de TecnologiaNINTEC, o processo ainda no foi concludo. Nesta fase o maior feito foi a publicao de um artigo para um congresso nacional de Engenharia de Software na Seo de ferramentas, o Congresso Brasileiro de Software CBSoft 2011.

Resultados e Discusso
Nesta seo sero apresentados os resultados finais do projeto na qual sero descritos detalhes sobre o relatrio de mudanas, as principais ferramentas open source de Teste Funcional, a ferramenta TChangeReport e o experimento realizado. Relatrio de Mudana Assim como quase todos os tipos de produtos, softwares de sucesso evoluem constantemente com o decorrer do tempo. Tal evoluo, tambm chamada de manuteno [10], muito comum nos sistemas computacionais. Manuteno de software o conjunto de atividades associadas com a modificao de software operacional em sintonia com as exigncias dos seus utilizadores e operadores, e de todas as outras pessoas e sistemas com os quais interage o sistema operacional [8].

A Manuteno de software o processo de melhoria e aperfeioamento de um software j desenvolvido como tambm reparo de defeitos e aumento de novas funes e considerada com uma das fases do desenvolvimento de software. A manuteno normalmente dividida de acordo com o seu objetivo, podendo ser: Corretiva: para reparar defeitos; Adaptativa: para adaptar o software a alguma mudana no seu ambiente de execuo; Evolutiva: para fazer acrscimo de funcionalidade, para o qual no havia sido originalmente previsto; Perfectiva: para melhorar algo j funcional, sem alterao no comportamento visvel ao usurio. Os tipos de manuteno citados anteriormente englobam todos os tipos de mudanas necessrias durante o ciclo de vida de um software. De acordo com muitos autores, a manuteno de um software corresponde parte mais onerosa do desenvolvimento, podendo representar at 90% do custo total envolvido. Por conta da importncia da manuteno, e pelo fato dela sempre estar associada a mudanas no software, foi criado uma rea especfica da Engenharia de Software denominada Gerncia de Configurao de Software (GCS) [9]. A GCS tem como responder as seguintes perguntas: O que mudou e quando?; Por que mudou?; E quem fez a mudana? .

A GCS definida como uma disciplina que visa identificar e documentar as caractersticas de itens de configurao, controlar as suas alteraes, armazenar e relatar as modificaes aos interessados e garantir que foi feito o que deveria ter sido feito [7]. Uma das tarefas da GCS gerao de relatrios que detalhem as mudanas que foram feitas em um software, o que exige um tempo significativo para analisar o status do software antes e aps as mudanas. Alm da GCS exigir a criao de um relatrio detalhando as mudanas realizadas em um software, todo e qualquer usurio gostaria de saber o que foi modificado de uma verso para outra. Isso evita erros durante a operao do sistema, alm da economia de recursos, uma vez j sabendo o que foi alterado muitos chamados tcnicos poderiam ser evitados. Essa tarefa cansativa e bastante propensa a erros. Se imaginarmos uma grande equipe trabalhando em um mesmo software, pode ficar bastante difcil sua execuo. Ferramentas de Teste Funcional Existem diversas ferramentas de teste funcional. A maioria dessas ferramentas, baseiam-se em gravar todas as aes executadas nas telas da aplicao, gerando um script dos passos executados. Todas estas aes podem ser reexecutados o permite a automatizao dos testes. Os scripts gerados podem ser alterados facilmente sem a necessidade de reexecuo dos testes[14]. Dentre recursos importantes nesse tipo de

ferramenta, tem-se a possibilidade de acessar o valor dos diversos elementos existentes nas telas do software, com o intuito de verificar os dados existentes. A partir disso que os testes so criados. Existem ferramentas voltadas para aplicaes desktop quanto para aplicaes WEB. Como ferramentas Open Source para teste de aplicaes desktop, podem citar o Abbot [1], Marathon [12] e o WindowTester Pro [22]. Dentre as Open Source para aplicaes Web mais populares so: Canoo WebTest [4],WatiN [20], Watir[23] e Selenium [17]. As ferramentas escolhidas para este trabalho so a Canoo WebTest e o Selenium. Quanto plataforma e linguagens suportadas, elas so as mais avanadas em relao s outras. Nos prximos tpicos relatado com detalhes estas duas ferramentas. Canoo WebTest Canoo WebTest uma ferramenta de cdigo aberto para testes automatizados de aplicaes web. Os testes podem ser escrito em arquivos no formato XML ou como cdigo Groovy, que uma linguagem de programao orientada a objetos desenvolvida para a plataforma Java como alternativa de programao Java. Dentre as caractersticas do Canoo WebTest podemos citar: Simplicidade: os testes podem facilmente criados mesmo se a pessoa no tiver noo de Web testes. Rapidez: pois no preciso fazer o download de imagens ou CSS e no necessita de calcular renderizao de pginas. Facilmente extensvel: dependendo da necessidade o programador pode facilmente estender a ferramenta, deixando a personalizvel a partir das necessidades do mesmo. Portabilidade: Pode ser executado em qualquer sistema operacional, que possua a maquina virtual Java. Boa visualizao dos Resultados: ele prove, inclusive com grficos, todas as informaes para permitir ao testador verificar facilmente se o teste encontrou uma falha e qual a causa dessa falha.

Selenium Selenium uma ferramenta Open Source que utilizado para a gerao de testes funcionais automatizados para ferramentas Web, gerando scripts atravs da gravao de aes do sistema[19]{Please_Select_Citation_From_Mendeley_Desktop}. Selenium possui uma vantagem em que seus testes podem ser rodados em qualquer navegador que possua JavaScript2, ou seja, a maioria dos navegadores utilizados atualmente dentre eles Mozila, Internet Explorer, Google Chrome ,etc. O Selenium possui trs ferramentas que a compe: Selenium Remote Controle(RC), Selenium-IDE e Selenium-Grid[15]. Sendo que o Selenium-Ide o que iremos dar nfase neste trabalho.

Linguagem de criao de script criado pela Netscape, usada em milhes de pginas Web pelo mundo.

Selenium-Ide uma extenso de fcil instalao para navegador Mozila. Essa ferramenta do tipo record-and-playback, ou seja, ela captura as aes executadas pelo testador e gera um script que permite a reexecuo das aes feitas, automatizando assim, o teste. .Onde seus testes podem ser salvos em diversos tipos de linguagens como: Java, PHP, Phyton, Ruby e entre outras mais. A figura 3 a seguir mostra a ferramenta Selenium-Ide.

Figura 3: Selenium-Ide

O Selenium possui uma grande variedade de funes, que faz com que os testes sejam mais bem elaborados e ajuda muito a vida do testador. Os comandos Selenium so divididos em trs grupos distintos [8]: Assertions: Comparam um valor esperado com um valor da pgina. Exemplo de comandos assertions temos AssertText e verifyText que verificam se um determinado texto apresenta na tela. Actions: Representa as aes executados numa pgina, onde estas aes so os inputs na aplicao. Exemplos de comandos actions temos open (abre uma pgina usando seu endereo como parmetro),type (entra com um valor em um determinado campo da pgina) e click(corresponde a clicar em um boto ou link).

Acessors: Semelhante aos Assertions, porm armazena o resultado numa varivel. Exemplo de comando Acessors tem o storeText que verifica se um determinado texto esta presente na tela e armazena o valor do resultado numa varivel. A Figura 4 a seguir ilustra o script de um procedimento de teste login realizado com sucesso realizado no Selenium-Ide. Na figura possvel a analisar o script e obter todos os passos do procedimento de teste. Os passos obtidos atravs da figura so: 1. Abrir a pgina uniplam2Old/getRoles.do;jsessionid=DEAD299CAD1F64F1BA486DBDBA63 3436. 2. Preencher o campo login com o valor cleiton. 3. Preencher o campo senha com o valor pibit. 4. Clicar no boto submit. 5. Verificar se o texto Entrada no sistema efetuada com sucesso. est presente na tela.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head profile="http://selenium-ide.openqa.org/profiles/test-case"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <link rel="selenium.base" href="http://localhost:8080/" /> </head> <body> <table cellpadding="1" cellspacing="1" border="1"> <thead> <tr><td rowspan="1" colspan="3">exemplo</td></tr> </thead><tbody> <tr> <td>open</td> <td>uniplam2Old/getRoles.do;jsessionid=DEAD299CAD1F64F1BA486DBDBA633436</td> <td></td> </tr> <tr> <td>type</td> <td>login</td> <td>cleiton</td> </tr> <tr> <td>type</td> <td>senha</td> <td>pibit</td> </tr> <tr> <td>click</td> <td>submit</td> <td></td> </tr> <tr> <td>assertText</td> <td>//div[@id='content']/div[14]/span</td> <td>Entrada no sistema efetuada com sucesso.</td> </tr> </tbody></table> </body> </html>

Figura 4: Script Selenium-Ide

TChangeReport a ferramenta desenvolvida A TChangeReport o prottipo de uma ferramenta desenvolvida com a tecnologia J2SE3, voltada para gerao semiautomtica do relatrio de alterao de software. Ela uma implementao de um mtodo de automao do relatrio baseado no reuso de duas verses de scripts de testes funcionais. Esse mtodo surgiu a partir de estudos recentes [13] [16] [9] que demonstraram o reuso de testes para gerao de outros artefatos do desenvolvimento de software. Nesta seo ser mostrada com detalhes a arquitetura da ferramenta e funcionamento da mesma. Arquitetura da ferramenta A TChangeReport faz parte de um projeto maior, chamado TTDD (Totally Tests Driven Development, em portugus Desenvolvimento Totalmente Dirigido por Testes). Esse projeto tem como objetivo gerar diversos artefatos relacionados ao desenvolvimento de software a partir do reuso de testes. Nesse projeto foi desenvolvido o TWork, um arcabouo voltado para servir de base para todos os trabalhos do projeto TTDD.

Figura 5 Arquitetura Twork

Na Figura 5 mostrado o esquema de Funcionamento da TWork. O TWork responsvel pela extrao de dados dos scripts de testes funcionais e, a partir desses, gerar um modelo de representao de teste funcional independente da tecnologia utilizada. Os dados desse modelo podem, ento, ser utilizadas como insumo de qualquer ferramenta de automao de artefatos baseada em teste. A Figura 6 demonstra o esquema de funcionamento da TChangeReport integrada com o TWork.

Java 2 Standard Edition

Figura 6 Arquitetura TChangeReport

De acordo com a Figura 6, a arquitetura da ferramenta dividida em trs mdulos: TestExtractor, TestComparator e ChangeReportGenerator. O mdulo TestExtractor responsvel por extrair os dois conjuntos de scripts de testes funcionais das duas verses do software e, para isso, usa o TWork que atualmente, s permite a extrao de testes criados com as ferramentas Selenium, escritos em Selenese HTML, e Canoo Web Test, escritos em XML. No entanto, pode-se estender o mdulo TestExtractor adicionando-se novos componentes extratores para scripts de outras ferramentas. Isso possvel porque esse mdulo foi arquitetado para ser extensvel, oferecendo suporte extrao de script de qualquer ferramenta de teste funcional. O mdulo TestComparator recebe os dois modelos de representao de teste do mdulo anterior e cria, a partir deles, o modelo da TChangeReport de representao de funcionalidades de uma aplicao. Em seguida, so realizadas comparaes entre as funcionalidades contidas nesse modelo. As principais entidades do modelo da TChangeReport esto demonstradas no diagrama de classes na Figura 7.

Figura 7 Trecho do diagrama de classes da TChangeReport

Para criao do modelo da TChangeReport (Funo da entidade ChangeReportGenerator da Figura 7), adotou-se a conveno de que cada procedimento de teste representa uma funcionalidade do sistema sob teste, pois parte-se

do princpio de que um procedimento de teste correto e coeso se refere a uma nica funcionalidade. Observando-se a Figura 7, cada funcionalidade (SystemFeature) constituda por campos (fields), extrados das aes de um procedimento de teste e por mensagens (outputs), extradas das sadas dos casos de teste daquele procedimento. Os campos e as mensagens de cada SystemFeature presente nas duas verses so comparados. A partir dessas comparaes surgem as alteraes, representadas por entidades FeatureChange. Essa entidade informa os campos ou as mensagens que foram adicionadas, removidas ou alteradas. As SystemFeature exclusivas de uma das verses representaro funcionalidades adicionadas, se contidas somente na verso nova, ou removidas, se contidas somente na verso antiga. O modelo de alteraes gerado pelo mdulo TestComparator contm, dessa forma, as SystemFeatures adicionadas, removidas e alteradas, alm de um conjunto de FeatureChanges para cada funcionalidade alterada. O mdulo ChangeReportGenerator responsvel por utilizar o modelo de alteraes do mdulo TestComparator para construir o relatrio de alteraes. Todas as informaes contidas naquele modelo so convertidas em frases que iro compor o relatrio de alteraes. Para gerao completa do relatrio, h outras informaes que so essenciais, mas que no podem ser extradas dos testes funcionais. So exemplos dessas informaes: o nome e a verso do software, os objetivos do documento, descrio geral das mudanas, entre outras. Essas informaes devem, ento, ser inseridas manualmente pelo usurio da ferramenta. Alm disso, mudanas em valores retornados por um teste, de uma verso para outra do software, podem indicar mudanas em regras de negcio. No entanto, a descrio detalhada da mudana cabe ao responsvel pela gerao do relatrio de alterao. A ferramenta TChangeReport gera uma indicao de que algo mudou, sendo necessrio um detalhamento da descrio. Contudo, essa dica de mudana bastante til para o responsvel pelo relatrio, pois ela indica locais com mudanas. A sada do mdulo ChangeReportGenerator o relatrio de alterao no formato Rich Text Format (RTF), criado com uso da biblioteca iText [11]. Essa biblioteca tambm pode ser usada para gerar arquivos em Portable Document Format (PDF). Foi escolhido o formato RTF porque ele permite a edio do documento pelo usurio final. Assim, possvel o aperfeioamento manual do relatrio aps sua gerao. Utilizao da Ferramenta O primeiro passo para uso da TChangeReport obter as duas verses dos testes funcionais previamente criados e verificar se eles esto organizados segundo algumas convenes exigidas. A Figura 8 mostra as duas verses dos testes SeleneseHTML da aplicao exemplo.

Figura 8 Testes funcionais das duas verses da aplicao

Observa-se, na Figura 8, que os casos de testes de um mesmo procedimento de teste esto organizados em um nico diretrio. Os casos de testes de inserir novo cliente, por exemplo, esto todos no mesmo diretrio inserirNovoCliente. Alm disso, os nomes dos diretrios e dos arquivos seguem o padro CamelCase. No caso dos diretrios, os nomes iniciam com letra minscula e as demais palavras vm juntas iniciando com letra maiscula. J no caso dos arquivos de teste, as palavras que compem o nome do arquivo vm juntas e todas iniciam com letra maiscula. Aps verificar que os testes seguem as convenes, o prximo passo executar a TChangeReport e preencher as informaes que no podem ser extradas, como o caso do nome da empresa, do software, das verses, da equipe de desenvolvimento, dentre outras. A Figura 9 mostra a interface do prottipo da ferramenta TChangeReport.

Figura 9 O prottipo TChangeReport

Aps preencher os campos da tela da Figura 9, os dois diretrios testesFuncionaisV2 e testesFuncionaisV1, mostrados na Figura 8, devem ser informados respectivamente nos campos Diretrio Novo e Diretrio Antigo. Em seguida, a ferramenta mostra uma tela solicitando demais informaes, como descrio do software, causas das mudanas e descries do uso do documento. Ao final solicitado para o usurio escolher o diretrio onde deseja salvar o relatrio de alterao.

Figura 10 Relatrio gerado

Na Figura 10, possvel visualizar a principal parte do documento gerado. Nela, o relatrio de alterao descreve as funcionalidades adicionadas, removidas e alteradas. Como se pode observar e conforme conveno da TChangeReport, cada procedimento de teste (ou, por conveno, diretrio que contm testes) da Figura 8 representa uma funcionalidade do sistema analisado. No relatrio, Municpio uma funcionalidade adicionada porque o procedimento de teste municpio somente se encontra na nova verso. J Estado uma funcionalidade removida por que somente se encontra na antiga verso. Como se pode observar, mesmo ao final da comparao dos testes para as duas verses do software, o relatrio gerado ainda no est concludo. Nas descries das alteraes da funcionalidade Inserir Novo Cliente, os campos esto identificados por nomes no intuitivos para o usurio final, como endereco_municipio_descricao, por exemplo.

Figura 11 Relatrio aps alteraes manuais

A Figura 11 demonstra esse trecho do relatrio aps alteraes manuais. Nela pode-se observar que, aps poucas alteraes nos nomes dos campos e em algumas mensagens, foi possvel criar uma verso do relatrio de alterao, que pode ser mais bem entendida pelo usurio final. Esse um aspecto interessante da ferramenta, pois ela possibilita a criao da verso final do relatrio de alterao a partir de poucas alteraes no relatrio gerado automaticamente. Essa abordagem permite menores erros na gerao do documento e tambm maior produtividade, pois no necessrio verificar manualmente as alteraes no sistema analisado.

Estudo Experimental
1.1.1.1 Definio dos objetivos

O objetivo deste estudo avaliar se a ferramenta TChangeReport pode promover reduo do esforo na criao do relatrio de alterao de software e ainda manter ou melhorar a qualidade do documento gerado. Para mensurar o esforo, usamos o tempo em minutos como unidade de medida, e para mensurar a qualidade, comparamos os relatrios criados, com e sem apoio da ferramenta, com relatrios considerados ideais.

Este experimento um estudo de caso, conduzido em um ambiente controlado (in vitro), com alunos de uma turma da disciplina de Engenharia de Software (ES) do curso de Cincia da Computao da Universidade Federal do Piau. Como os participantes do experimento foram escolhidos dentre uma turma especfica, faltou-se aleatorizao, um ingrediente essencial para que o experimento fosse considerado completamente controlado. Por esse motivo, esse estudo classificado como um quasiexperiment [21].

Apresentamos para a turma diferentes verses de parte de um sistema de gerncia de plano de sade desenvolvido baseado em um sistema real e com contextos de alteraes similares aos reais. Em um primeiro momento, os participantes analisaram mudanas entre duas verses V1xV2, observando especificamente as funcionalidades Titulares, Municpios e Estados. Em um segundo momento, os participantes analisaram outras duas verses V3xV4, observando as funcionalidades Marcar Consulta, Mdicos e Especialidades. Foram comparados os relatrios de alterao criados a partir dessas verses com e sem apoio da ferramenta TChangeReport. Resumo da definio Analisar a criao de relatrios de alterao de software com e sem apoio da ferramenta TChangeReport, objetivando-se avaliar o esforo e a qualidade dos documentos gerados no contexto de uma turma de Engenharia de Software.
1.1.1.2 Planejamento

Contexto de seleo Foram utilizados como participantes do experimento alunos do curso de Cincia da Computao da Universidade Federal do Piau. Os alunos participantes do estudo tinham cursado de 4 a 7 semestres. O experimento foi executado off-line (fora do ambiente industrial). Geralmente, estudantes do 4 semestre no possuem habilidade em criao de relatrios de alterao de software. Mesmo assim, entrevistamos os participantes levantando algumas questes sobre as experincias deles, no intuito de evitar algum vis que pudesse perturbar o estudo.

Figura 12 Distribuio dos participantes do estudo.

Aps entrevistar todos os 17 alunos participantes, confirmou-se que nenhum possua habilidades em criao de relatrio de alterao de software. A Figura 12 exibe uma classificao do perfil dos participantes do estudo. A maioria dos voluntrios

(41%) trabalha com desenvolvimento de software e tem at um ano de experincia. Cerca de 24% trabalha com suporte e manuteno de computadores. O restante no trabalha. Formulao de hipteses O estudo foi focado nas seguintes hipteses:
Hiptese Nula, H0Esforo: No h diferena no esforo para criar o relatrio de alterao com e sem apoio da ferramenta TChangeReport, ou seja, EsforoRelatrio (ComFerramenta) = EsforoRelatrio (Manual). Hiptese Alternativa, H1Esforo: EsforoRelatrio (ComFerramenta) EsforoRelatrio (Manual). Foi usado o tempo em minutos para medir o esforo. Hiptese Nula, H0Qualidade: No h diferena na qualidade do relatrio criado com e sem uso da ferramenta TChangeReport, ou seja, QualidadeRelatrio (ComFerramenta) = QualidadeRelatrio (Manual). Hiptese Alternativa, H1Qualidade: QualidadeRelatrio (ComFerramenta) QualidadeRelatrio (Manual).

Seleo de variveis As variveis independentes so os processos de criao do relatrio de alterao de forma manual e com uso da ferramenta TChangeReport. As variveis dependentes so o esforo, medido em minutos, necessrio para se criar o relatrio de alterao e a qualidade do documento gerado com e sem apoio da ferramenta. Seleo de participantes Os participantes do experimento foram escolhidos baseados na convenincia, ou seja, os participantes so estudantes de uma turma especfica de ES. Os estudantes foram avisados de que estavam participando de um estudo experimental e que seus dados seriam usados nas anlises do estudo. Dezessete alunos concluram todas as etapas do experimento. Projeto do experimento O estudo foi planejado para ser feito em dois estgios, como mostrado na Tabela 1. Antes do incio dos estgios, dividiram-se os estudantes em dois grupos de forma aleatria. No primeiro estgio, o grupo 1 criou o relatrio de alterao manualmente e o grupo 2 criou o relatrio com apoio da ferramenta TChangeReport. Os relatrios associados ao estgio 1 (tanto manual, quanto automtico) foram feitos a partir das mesmas verses do software (V1xV2). No segundo estgio, inverteram-se os papis. O grupo 1 criou, inicialmente, o relatrio com uso da ferramenta e o grupo 2 iniciou de forma manual. Os relatrios para o segundo estgio foram gerados a partir de verses diferentes (V3xV4) das utilizadas no estgio 1 do experimento.
Tabela 1 Projeto do Experimento

Estgio 2 Experimento Gerao com a Grupo 1 Gerao Manual Gerao Manual Gerao com a TChangeReport (v1, v2) TChangeReport (v3,v4) Treinamento Treinamento

Grupo

Estgio 1 Experimento

Gerao com a Grupo 2 Gerao com a TChangeReport Gerao Manual Gerao Manual TChangeReport (v1,v2) (v3, v4)

Como mostra a Tabela 1, em cada estgio, cada grupo passou por uma sesso de treinamento antes de iniciar uma sesso de experimento. No treinamento do estgio 1 foram apresentados conceitos iniciais sobre relatrio de alterao e da aplicao de plano de sade que seria utilizada para a prtica. Alm disso, ensinamos como se fazer o relatrio manual para o Grupo 1 e automtico para o Grupo 2, ambos voltados para funcionalidades diferentes das utilizadas durante a sesso de experimento. Para relatar as alteraes, os estudantes utilizaram um template de relatrio de alterao, contendo os padres de mensagens a serem relatadas. Isso foi feito para evitar grandes divergncias entre o padro gerado pela ferramenta e o manual, permitindo que a posterior comparao entre os relatrios, para anlise da qualidade, fosse feita de forma objetiva e no subjetiva. No treinamento do estgio 2, ensinamos como deveria ser feito o relatrio para outras funcionalidades tambm diferentes das utilizadas na sesso de experimento. Nesse treinamento, eles novamente tiveram que usar o template de relatrio de alterao. Ao final dos treinamentos, mostramos aos estudantes os relatrios de alterao considerados ideais para os casos praticados com o intuito de faz-los verificar possveis erros cometidos e permitir maior eficcia do treinamento. importante destacar que todas as alteraes existentes na aplicao utilizada so baseadas em alteraes de uma aplicao de plano de sade real. H alteraes como incluso e remoo de funcionalidades, incluso, alterao e remoo de campos e mensagens, mudanas em regras de negcio, alterao em mensagens de erros. Optouse por no utilizar o sistema real porque ele grande e bastante complexo. Isso exigiria mais tempo para realizao do experimento dificultando a participao voluntria. No experimento, os estudantes executaram as mesmas atividades do treinamento, s que para funcionalidades diferentes. Para coletar os dados relacionados ao esforo, utilizamos um formulrio eletrnico. Cada um dos participantes, ao final de um estgio, teve que preencher esse formulrio informando o tempo gasto na atividade. Os formulrios podiam ser acessados por meio da Web. Ameaas para validade Validade interna: O experimento foi projetado para minimizar os efeitos de ameaas validade interna. Planejamos o estudo em dois estgios e, em cada um, os participantes tiveram que criar o relatrio de alterao para funcionalidades diferentes. Isso foi feito para minimizar os efeitos de Maturao. As diferenas nas funcionalidades de cada estgio ajudaram a minimizar uma influncia positiva no experimento, que poderia ser causada ao se usar a ferramenta para execuo de uma tarefa similar a outra j realizada no estgio anterior. Ns tambm acreditamos que isso nos ajudou a evitar uma influncia negativa devido execuo de atividades repetitivas, que poderia causar desinteresse dos participantes. Para evitar ameaas relacionadas ao uso de um nico grupo, ns planejamos o estudo dividindo os participantes em dois grupos, aplicando tratamentos diferentes a

cada grupo. A associao dos estudantes em grupos foi feita de forma aleatria, conforme mencionado na Seo 5.3.3.2 , no tpico Projeto do experimento. Ns fizemos isso para evitar algumas ameaas validade (compensatory equalization of treatments, compensatory rivalry e resentful demoralization [21]). Isso permite tambm que um grupo seja o controle do outro grupo. Assim, analisamos os dados cruzando os grupos, o que refora a indicao que os resultados foram obtidos por conta dos tratamentos utilizados e no por conta de fatores no controlados. Validade externa. O uso de estudantes como voluntrios uma ameaa capacidade de generalizao dos resultados do estudo. Contudo, parte dos estudantes j trabalha. A grande maioria deles encontra-se aps a metade do curso, o que os torna parecidos com profissionais iniciantes. Os exemplos utilizados, embora pequenos, refletem bem um sistema real, uma vez que foram extrados de um sistema que se encontra em produo. Eles tiveram que ser reduzidos por conta do tempo total para concluso do estudo, que poderia ser muito alto e afastar a participao voluntria conforme dito no tpico anterior, Projeto do experimento. Dessa forma, acreditamos que os resultados obtidos possam ser estendidos para profissionais com pouca experincia atuando no desenvolvimento de sistemas de informao.
1.1.1.3 Operao

Preparao Durante a preparao para inicio do estudo, apresentamos aos participantes as atividades relacionadas, mas eles no foram avisados das atuais hipteses declaradas. Cada um teve sua anonimidade garantida. Ns tambm descrevemos como os dados seriam usados e publicados. Execuo Como mencionado anteriormente, o estudo experimental foi dividido em dois estgios de acordo com as verses analisadas. Em cada estgio, cada grupo teve uma sesso de treinamento e uma sesso de experimento. Nas sesses de experimento, utilizaram-se as verses V1xV2 e V3xV4, conforme j descrito na Tabela 1 da Seo 5.3.3.2, no tpico Projeto do experimento. Para realizao dessas sesses, solicitou-se aos estudantes que seguissem os mesmos passos aprendidos no treinamento (Citados na Seo 5.3.3.2, tpico Projeto do experimento), porm sem orientao dos autores. Ao final de cada estgio, os participantes tiveram que preencher um formulrio eletrnico informando o nome, o grupo, o tipo de relatrio feito, se manual ou automtico, e o tempo gasto, em minutos, com a atividade. Cada relatrio gerado nas sesses de experimento foi comparado com seu respectivo relatrio considerado ideal com o intuito de se mensurar a qualidade. Um avaliador externo, que no fazia parte nem dos condutores do experimento, nem dos participantes, analisou a qualidade de cada relatrio gerado, comparando-o com o relatrio considerado ideal. A partir da comparao foi estabelecido se o relatrio poderia ou no ser considerado aceito. Os possveis erros encontrados durante a comparao foram divididos em: grave (falta de informao de funcionalidade), mdio

(falta de informao de campos e de mensagens) e pequeno (erros de portugus e de formatao). Um erro grave, trs mdios ou mais de quinze pequenos causou a no aceitao do documento. Assim, um relatrio aceito contm nenhum ou poucos erros que viabilizam seu entendimento. Um relatrio no aceito possui erros que comprometem seu entendimento.
1.1.1.4 Anlise e Interpretao

Dezessete voluntrios conseguiram encerrar o estudo. Os dados colhidos no estudo so apresentados na Tabela 2 Resultados obtidos no estudo e na Figura 13 Tempos obtidos no estudo por participantes.
Tabela 2 Resultados obtidos no estudo

Figura 13 Tempos obtidos no estudo por participantes

Analisando os dados obtidos, foi aplicado o teste Kolmogorov-Smirnov [6][21] para uma populao, para avaliarmos se os tempos registrados para gerao do relatrio de alterao seguem a distribuio normal. Isso foi confirmado pelo teste, tanto feito nos dados por completo, quando os dividindo por tipo de gerao (manual ou com apoio da TChangeReport). Dessa forma, foi possvel utilizar o Teste t de Student [18][21] para comparao das mdias registradas. A aplicao do teste t de Student, com um nvel de significncia de 95% nos mostrou que existe diferena significativa entre o tempo para construir o relatrio manual, quando comparado com o uso da TChangeReport. O uso da ferramenta diminui significativamente o tempo total para essa tarefa. Tambm realizamos a comparao dos tempos para se gerar o relatrio de forma manual nos dois grupos, para avaliar se houve diferena nos tempos para realizao dessa tarefa, uma vez que ela foi realizada antes do uso da TChangeReport em um grupo e aps seu uso em outro. Os resultados obtidos indicam que no houve uma diferena significativa, indicando que o fato de ter feito isso antes ou depois do uso da ferramenta no resultou em qualquer diferena considervel. Da mesma forma, o uso da TChangeReport antes ou depois de se gerar o relatrio de alterao para um software tambm no gera diferena significativa. Com relao qualidade, todos os relatrios gerados com o apoio da TChangeReport foram considerados aceitos. J os relatrios gerados de forma manual obtiveram cerca de 40% de rejeio. Conforme relatado, a rejeio acontecia quando os erros registrados ultrapassavam um limite pr-estabelecido, que comprometia o entendimento das alteraes relatadas. Discusso Conforme era esperado, o uso da TChangeReport para gerar o relatrio de alterao gera um ganho de tempo nesta atividade. Isso foi confirmado a partir dos dados do experimento. necessrio ressaltar que os exemplos apresentados eram pequenos, o que poderia no resultar em ganho para a TChangeReport. No entanto, mesmo em um estudo como esse, os ganhos j foram considerveis. Se elevarmos o tamanho e a complexidade dos sistemas, certamente os ganhos sero bem maiores. Com relao qualidade, pudemos constatar tambm algo j esperado: a chance de se cometer erros sem o apoio da ferramenta muito grande. Para se construir um relatrio de alterao completo necessrio verificar cada funcionalidade da aplicao, analisando seu comportamento. A TChangeReport relata todas as alteraes refletidas nos testes, que normalmente devem cobrir todo o conjunto de funcionalidades existentes. Assim, a comparao do relatrio gerado a partir dos testes existentes, que cobriam todas as funcionalidades, contra o relatrio gerado manualmente foi arrasadora. Todos os relatrios gerados com a TChangeReport foram considerados aceitos, enquanto cerca de 40% dos relatrios gerados manualmente foram rejeitados. Acreditamos que se os participantes fossem profissionais atuantes no desenvolvimento, teriam bem mais cuidados com essa tarefa. No entanto, isso poderia refletir em mais tempo ainda para a gerao do relatrio.

Concluses e Trabalhos Futuros


O Relatrio de alteraes um timo artefato para contribuir com as empresas na forma de ajuda em custos e tempo, pois sua criao demanda muito tempo e uma anlise de tudo o que foi alterado, passando muitas vezes funes despercebidas na criao do relatrio, pelo fato s vezes de uma alterao ser feita por muitos programadores. Assim, dado a complexidade e os custos envolvidos, existe a necessidade de utilizar ferramentas que automatizem a gerao do mesmo. Neste relatrio foi apresentado o que um relatrio de mudana, para que serve sua utilizao e uma ferramenta para gerao do relatrio de mudanas. Essa ferramenta inovadora, pois utiliza os testes funcionais para sua execuo. Aps um estudo experimental, verificamos que seu uso pode reduzir os esforo na criao do relatrio de alterao e ainda melhorar a qualidade do documento. Como trabalhos futuros pode-se destacar transforma a ferramenta para uma aplicao Web (esta em processo de implementao), realizar um estudo experimental em ambiente industrial, fazer o uso de Inteligncia Artificial e processamento de Linguagem natural. Por fim, podemos constatar que os testes funcionais so ricos em informaes, podendo com eles gerar diversas ferramentas que ajudam os usurios finais e os desenvolvedores na utilizao de softwares.

Referncias Bibliogrficas
[1] ABBOT. Abbot framework for automated testing of Java GUI components and programs. 2011. http://abbot.sourceforge.net/doc/overview.shtml. ltimo acesso em 08/08/2011 [2] Apiwattanapong, T., Orso, A., & Harrold, M. J. (2006). JDiff: A differencing technique and tool for object-oriented programs. Automated Software Engineering, 14(1), 3-36. doi: 10.1007/s10515-006-0002-0. [3] Barbosa, E. F., Marcelo, A., Vincenzi, R., Jino, M., Delamaro, E., & Mar, D. (2004). Introduo ao Teste de Software. [4] Canoo Web Test. Web Test tool. http://webtest.canoo.com/webtest/manual/ WebTestHome.html. ltimo acesso em 08/08/2011. [5] Correia, S. A., & Rodrigues, A. (2004). Tcnicas para Construo de Testes Funcionais Automticos, 111-117. [6] Eadie, W.T.; D. Drijard, F.E. James, M. Roos and B. Sadoulet (1971). Statistical Methods in Experimental Physics. Amsterdam: North-Holland. pp. 269271. [7] Filho, W. P. (2003). Engenharia de Software: Fundamentos, Mtodos e Padres. LTC, 2nd edition.

[8] Foster, John R., Software Maintenance An Overview, R11 Divisional Memorandum, British Telecom Research Laboratories [9] IEEE (1990). IEEE Standard Glossary of Software Engineering Terminol- ogy IEEE Std.610.12-1990. IEEE Computer Society. [10] IEEE (1998). Standard for Software Test Documentation IEEE Std 829-1998. IEEE Computer Society. [11] Itext. Itext. 2011. http://itextpdf.com/. ltimo acesso em 09/08/2011 [12] MARATHON. Marathon. 2009. http://www.marathontesting.com/Marathon.html. ltimo acesso em 08/08/2011 [13] MCT, Programa Brasileiro da Qualidade e Produtividade de Software, 4 ed. Ministrio da Cincia e Tecnologia: 2007. [14] Oliveira, W. P. D., & Alcntara, P. D. (2009). Imaginarium : Um protipo para auxlio automao de testes funcionais para aplicaes WEB. [15] Santos, I. D. S., & Alcntara, P. D. (2009). Automao de testes funcionais com o Selenium. [16] Santos, I. D. S., Alcntara, P. D., & Santos, R. (2010). Documentao Dirigida por Testes. Simpsio Brasileiro de Qualidade de Software (SBQS), 2010, in press. [17] Selenium. Web application testing system. http://seleniumhq.org/. ltimo acesso em 08/08/2011. [18] Senn, S. and W. Richardson (1994). The first t-test. Statist. Med. 13, 785-803. [19] Siqueira, H. L. de F. (2010). TaRGeT Scripts Generation : Um plug-in de gerao automtica de scripts de teste . [20] WATIN. Web Application Testing In .Net. 2011. http://watin.sourceforge.net/. ltimo acesso em 08/08/2011. [21] Wohlin C., P. Runeson, M. Host, M. Ohlsson, B. Regnell, and A. Wesslen. Experimentation in Software Engineering: An Introduction. Kluwer Academic Publishers, 2000. [22] WindowTester. WindowTester Pro. 2011. http://code.google.com/intl/ptBR/javadevtools/wintester/html/index.html /. ltimo acesso em 09/08/2011 [23] WTR. Web App Testing in Ruby. 2011. http://wtr.rubyforge.org/. ltimo acesso em 08/08/2011