SIPTEST System Intelligent Process Testing. Estudo Ferramentas de Automação

Transcrição

1 SIPTEST System Intelligent Process Testing. Estudo Ferramentas de Automação SIPTEST - System Intelligent Testing Link Consulting,SA Pág. 0 de 14

2 Índice 1 Introdução Objectivo do documento Contexto Estrutura do documento Ferramentas de automação de testes funcionais Estudos comparativos BadBoy BlueDuck SDA SoapUI Expert Marathon Maveryx Comparação e Conclusões Ferramentas de teste Web Ferramentas de teste de aplicações Desktop Referências Link Consulting,SA Pág. 1 de 14

3 1 Introdução 1.1 Objectivo do documento Este documento apresenta o resultado da pesquisa efectuada sobre ferramentas. Capture/Replay de testes funcionais, no âmbito do projecto SIPTEST. São nele descritas algumas das mais conceituadas ferramentas e suas funcionalidades. 1.2 Contexto O teste de software é um processo utilizado para identificar a exactidão, completude e qualidade do produto de software desenvolvido. Existem diferentes tipos de testes de software que podem ser aplicados nas diversas fases do desenvolvimento para aumentar a confiança na qualidade de uma aplicação de software, por exemplo, testes de compatibilidade, testes de conformidade, testes funcionais, testes de regressão, testes unitários, testes de desempenho, testes de carga/stress [1, 2]. Neste documento, serão apresentadas apenas ferramentas Capture/Replay de testes funcionais. TESTES FUNCIONAIS Este tipo de testes é baseado numa análise da especificação de funcionalidade de um componente ou sistema [3, 4]. Por oposição, os testes não funcionais são testes que testam os atributos de um componente ou sistema que não se relacionam à funcionalidade, por exemplo, confiabilidade, eficiência, usabilidade, mantenabilidade e portabilidade [3]. CAPTURE / REPLAY Os testes Capture/Replay são frequentemente utilizados para apoiar testes de regressão. Nestes testes, as entradas são registadas durante interacções manuais com a aplicação a testar a fim de gerar os scripts de teste automatizados que podem ser executados mais tarde (isto é, repetidos) [3]. 1.3 Estrutura do documento A secção 2 deste documento descreve as principais características e funcionalidades das ferramentas de Capture/Replay objecto deste estudo. A secção 3 faz uma análise comparativa dessas ferramentas. Na última secção apresenta-se o conjunto de referências consultadas para elaborar este documento e os portais das ferramentas descritas e comparadas. Link Consulting,SA Pág. 2 de 14

4 2 Ferramentas de automação de testes funcionais A técnica de Capture/Replay é muito utilizada em ferramentas de automação de testes funcionais por permitir a gravação de um script de teste por interacção com a aplicação a testar, registando os valores de input e os de output obtidos [9]. Após gravação de um script de teste com resultados positivos, este script pode ser executado mais tarde de maneira a testar um componente ou sistema, garantindo que modificações no código interno (evolução do componente ou sistema) não danificam o seu comportamento. Testes funcionais seguem normalmente os seguintes passos: Identificação de funções que o componente ou sistema deve desempenhar; Criação de dados de input, baseados nas necessidades de uma função específica; Determinação do output esperado considerando os dados estabelecidos; Execução do teste; Comparação com o resultado esperado. Ferramentas de Capture/Replay permitem executar várias vezes scripts de teste criados para garantir que os requisitos implementados são cumpridos ao longo da evolução da aplicação a testar. Os critérios escolhidos para a diferenciação das ferramentas de testes Capture/Replay foram os seguintes: Livre/Pago indica se a aplicação é proprietária e paga ou se é livre (freeware); Aplicação activa indica se a aplicação se encontra em desenvolvimento activo ou não; Testes de Interface Interface Desktop (GUI) ou interfaces WEB; Sistema Operativo sistema operativo em que a aplicação pode ser executada; Na tabela 1, são apresentadas as ferramentas mais significativas em termos de testes Capture/Replay. As ferramentas são diferenciadas usando os critérios acima. Para além das ferramentas de Capture/Replay, existem frameworks através dos quais é possível simular as acções dos utilizadores sobre uma interface gráfica que estão listadas e comparadas na tabela 2. Link Consulting,SA Pág. 3 de 14

5 Tabela 1 - Esta tabela representa a pesquisa efectuada sobre ferramentas Capture/Replay. Link Consulting,SA Pág. 4 de 14

6 Tabela 2 - Esta tabela representa a pesquisa efectuada sobre frameworks usadas para simular acções dos utilizadores e verificar o estado de componentes das interfaces. 2.1 Estudos comparativos Nesta secção são apresentadas algumas das ferramentas de automação mais conceituadas e usadas, segundo os estudos [5-10],:três ferramentas de testes de serviços Web e três de aplicações Desktop. Mais concretamente, as ferramentas são Badboy, BlueDuck SDA e SoapUI (para testes Web) e Expect, Marathon e Maveryx (para testes a aplicações Desktop) BadBoy A ferramenta de testes BadBoy [11] é uma ferramenta desenvolvida pela BadBoy Software cujo objectivo é efectuar testes funcionais, carga e de regressão em interfaces Web. Para isto, a aplicação conta com um browser integrado capaz de carregar portais da Internet. As interacções efectuadas através deste browser são gravadas (Capture) num script de teste que pode ser reproduzido mais tarde. A Figura 1 mostra um exemplo da interface do BadBoy. Link Consulting,SA Pág. 5 de 14

7 Figura 1 - Interface do BadBoy [11] onde se consegue ver o browser à direita da imagem e os passos do teste e sumário à esquerda Entre outras coisas, o BadBoy é capaz de gerar relatórios gráficos detalhados, importar dados de input a partir de ficheiros externos, guardar variáveis para serem usadas em mais do que um teste e agendar testes [11] BlueDuck SDA O BlueDuck SDA [12] é uma ferramenta desenvolvida para testar interfaces Web. Esta ferramenta é mantida pela BlueDuck Open Testing e é implementada com base na versão 3 da framework AutoIt. Com base nesta framework, o BlueDuck SDA é capaz de reproduzir testes usando o teclado e o rato virtualmente em qualquer plataforma Windows. Os testes reproduzidos por esta ferramenta não são capturados através de acções do utilizador (como é o caso do que acontece com o BadBoy), mas através da escrita de um script. Desta maneira, o BlueDuck SDA é capaz de testar páginas Web em qualquer browser ou mesmo numa aplicação de Desktop [12] SoapUI Esta ferramenta é desenvolvida pela SmartBear Software e suporta testes funcionais, de carga, regressão e aceitação a serviços. Suporta a maior parte dos protocolos e é capaz de modificar parâmetros intrínsecos dos mesmos, como por exemplo, timeouts ou tamanho dos requests. Esta ferramenta pode ser usada como ferramenta final ou como framework por ser adaptável e open-source [13]. A Figura 2 mostra a interface desta ferramenta. Link Consulting,SA Pág. 6 de 14

8 Figura 2 - Interface do SoapUI [13] onde se consegue ver a versão XML dos testes à direita da imagem e os passos do teste e propriedades à esquerda O SoapUI é capaz de agendar testes, simular serviços e gerar testes para uma página Web específica, além de gerar relatórios e suportar diferentes ambientes de desenvolvimento Expert A ferramenta Expect [14] foi das primeiras ferramentas de testes funcionais a chegar aos utilizadores de Linux. Apesar de descontinuada, esta ferramenta permite testar programas de linha de comandos, sendo capaz de simular inputs dos mais variados a nível do teclado. Esta ferramenta não possui uma interface gráfica nativa e os relatórios que produz são mostrados na linha de comandos, podendo ser útil para sistemas como servidores Linux ou teste de componentes Marathon A Marathon [15] é uma ferramenta de testes Capture/Replay para interfaces gráficas de aplicações Desktop desenvolvida pela Jalian Systems. Esta ferramenta testa interfaces Java/Swing e suporta testes por scripts em Jython e JRuby. Adicionalmente, a ferramenta é capaz de identificar objectos da interface automaticamente, através da análise de código, para conveniência do testador. A Figura 3 mostra um screenshot da criação de um teste. Link Consulting,SA Pág. 7 de 14

9 Figura 3 - Interface do Marathon [15] onde se consegue ver a criação de um teste Por ser desenvolvida em Java, é multi-plataforma e tem um debugger embutido, no entanto, não suporta o agendamento de testes criados à priori nem a construção automática de testes a partir do conhecimento dos objectos da interface Maveryx O Maveryx [16] é uma ferramenta de testes funcionais e de regressão para interfaces de aplicações de Desktop em Java/Swing, capaz de correr em Windows, Linux e Mac. Esta ferramenta conta com uma interface capaz de detectar objectos nas interfaces das aplicações que testa, de maneira a poder gerar testes automaticamente a partir, por exemplo, de botões e formulários disponíveis. A partir da sua integração com o IDE Eclipse, a ferramenta é capaz de detectar modificações e defeitos na interface da aplicação. Na Figura 4, é possível ver a ferramenta integrada com o Eclipse, a correr vários testes unitários. Link Consulting,SA Pág. 8 de 14

10 Figura 4 - Interface do Maveryx [16] integrada com a o IDE Eclipse, onde se pode ver os testes e relatórios Link Consulting,SA Pág. 9 de 14

11 3 Comparação e Conclusões Baseado nas descrições das ferramentas obtidas nas páginas Web oficiais das mesmas [11-16], foi feita uma comparação das ferramentas de testes de aplicações Web e aplicações Desktop. Devido a esta diferença fundamental nas aplicações, foram feitas duas comparações, uma para cada tipo. 3.1 Ferramentas de teste Web As ferramentas BadBoy, BlueDuck SDA e SoapUI são todas ferramentas capazes de efectuar testes funcionais a interfaces Web. Dentro deste tipo de testes, existem algumas características pelas quais as ferramentas que testam interfaces Web podem ser distinguidas. CAPTURA A ferramenta BadBoy, por possuir um browser integrado na aplicação, não é capaz de simular browsers específicos que possam ser usados pelos utilizadores finais nem testar as diferenças entre uma página renderizada nestes. Por outro lado, o BlueDuck SDA e o SoapUI não possuem uma interface de captura tão avançada pois não são capazes de gravar os passos do utilizador a interagir com a aplicação. Contudo, as três ferramentas baseiam-se na construção de scripts para guardar os testes automatizados. DADOS DE INPUT O facto de uma aplicação ser capaz de gerar dados de input, seguir regras para os mesmos (expressões regulares, por exemplo) ou mesmo importar os dados de um ficheiro ou base de dados externos é um factor importante na diferenciação das ferramentas. Concretamente, as ferramentas BlueDuck SDA e BadBoy são capazes de importar dados de ficheiros externos e de guardar variáveis para serem usados em diferentes testes, enquanto o SoapUI e o BlueDuck SDA são capazes de gerar testes automaticamente ao possuírem detecção de objectos da interface. AMBIENTE DE EXECUÇÃO O agendamento de testes, opções de debug e suporte para múltiplos ambientes de desenvolvimento são aspectos cruciais na escolha de uma ferramenta de testes Capture/Replay. O Badboy e o SoapUI são capazes de agendar testes ao contrário do BlueDuck DAS. As três ferramentas são capazes de fazer debug aos testes e de editar opções avançadas nos protocolos usados pelas aplicações Web. O SoapUI suporta um maior número de protocolos e é a única que suporta simulação de serviços e vários ambientes de desenvolvimento (Debug e Release). Das três ferramentas analisadas, o Badboy é a única capaz de executar testes de desempenho aquando na própria navegação pela página Web e executar testes passo por passo. A ferramenta BlueDuck SDA não é capaz de correr out-of-the-box em Windows, Linux e Mac, no entanto, é a única a usar o mesmo sistema de teste para aplicações Web e Desktop. RESULTADOS E OUTRAS INFORMAÇÕES Link Consulting,SA Pág. 10 de 14

12 As três ferramentas analisadas são capazes de gerar relatórios sobre os testes executados. De notar, no entanto, que os relatórios do BadBoy são apresentados, em parte, graficamente e apresentam dados de desempenho das páginas testadas. Os relatórios do BlueDuck SDA são mais configuráveis e esta ferramenta permite gravar os testes em screenshots e vídeos AVI. Adicionalmente, as ferramentas BadBoy e SoapUI são ainda capazes de efectuar testes de carga, além dos testes Capture/Replay. O SoapUI é uma ferramenta capaz de ser usada também como framework. 3.2 Ferramentas de teste de aplicações Desktop As ferramentas Expect, Marathon e Maveryx são todas ferramentas capazes de efectuar testes funcionais a aplicações Desktop. Dentro deste tipo de testes, existem algumas características pelas quais estas ferramentas podem ser distinguidas. CAPTURA E INPUT Tal como as ferramentas de testes Web, a captura dos movimentos de cada teste é um factor a ter em conta aquando da comparação deste tipo de ferramentas. Quanto à ferramenta Expect, esta não suporta nativamente testes por GUI, apenas por linha de comandos. Da mesma maneira, as ferramentas Marathon e Maveryx não são capazes de capturar os movimentos do testador a partir da interface, no entanto, ambas as ferramentas são capazes de detectar objectos automaticamente nas interfaces das aplicações a testar e gerar testes automaticamente. Os dados usados nestes testes são configuráveis e reutilizáveis entre os scripts dos testes podendo ser carregados de ficheiros externos. AMBIENTE DE EXECUÇÃO A ferramenta Expect pode ser usada como qualquer ferramenta de Linux e ser invocada num ficheiro de script com parâmetros especificados. O Marathon usa Jython ou JRuby (escolha do testador) para linguagem dos scripts de teste. O Maveryx e o Marathon podem ser corridos em qualquer ambiente que suporte Java ao contrário do Expect que apenas corre em Linux. O uso de aplicações baseadas em Java permite que a aplicação seja cross-platform, no entanto, induz a que ferramentas como o Marathon e o Maveryx apenas sejam capazes de testar interfaces Java/Swing. RELATÓRIOS E OUTRAS INFORMAÇÕES Em termos de relatórios produzidos, os que aparentam ter resultados mais significativos são os da ferramenta Maveryx. Esta ferramenta também é conhecida por apresentar relatórios inline (no código), algo impraticável em Expect e que requereria modificação avançada na ferramenta Marathon. Adicionalmente, a ferramenta Maveryx também está disponível como plug-in do IDE Eclipse, ao contrário das outras duas ferramentas. Link Consulting,SA Pág. 11 de 14

13 4 Referências 1. Myers, G., Sandler, C.: The art of software testing. (2004). 2. Weyuker, E.: Testing component-based software: A cautionary tale. Software, IEEE (1998). 3. Veenendaal, E.V.: Standard glossary of terms used in Software Testing, Version 2.1. ISTQB. 1, 1-51 (2010). 4. Kaner, Falk, Nguyen: Testing Computer Software. Wiley Computer Publishing. 42 (1999). 5. OpenSource Functional testing tools. (2012). 6. Capture Playback. (2012). 7. List of testing tools. (2012). 8. SoftwareQAtest: Web Site Test Tools and Site Management Tools. (2012). 9. SAPE: Software and Programmer Efficiency Research Group. replay-tools. (2012). 10. Sjösten-Andersson, E., Pareto, L.: Costs and Benefits of Structure-aware Capture/Replay tools. (2006). 11. Badboy Software Home Page: Badboy Testing tool, BlueDuck Open Testing: BlueDuck SDA, SmartBear Software: SoapUI - The Home of Functional Testing, The Expect Home Page, Jalian Systems: Marathon Home Page, Maveryx Java Testing Software, Ranorex: Avoiding common pitfalls when working with capture/replay. (2012). 18. GerrardConsulting: Selecting and Evaluating CAST Tools. (2012). 19. Chapter 6 Tool Support for Testing. CTFL. Referências adicionais Link Consulting,SA Pág. 12 de 14

14 20. A. William: Capture and Replay presentation. 21. N. Haché: GUI Testing presentation. 22. B. Marick: Classic testing mistakes. (1997). 23. OWASP: Capture-Replay. (2009). 24. Napatech: Capture Replay Cem Kaner, James Bach, Bret Pettichord: Lessons Learned in Software Testing: A Context-Driven Approach. Lesson Capture Replay fails. (2002). 26. Oracle Forums: Advice needed for functional test. (2007). 27. StackOverflow: Functional Testing tools Seeking advice. (2011). 28. Chris McMahon: Automation testing: Seven tips for functional test design. functional-test-design. (2011). 29. IBM: Tips and tricks for functional testing HTML applications. nd_tricks.html. 30. Peci.Org: Understanding the FT Guide. (). 31. SQA Forums: New to functional testing looking for advice &Searchpage=1&Main=384162&Words=+phanikumargk28&topic=&Search=true. (2007). 32. Software Testing Help: Top 20 practical software testing tips you should read before testing any application. (2008). 33. Info Tech Blog: 5 Tips for Starting Automated Functional Testing TechRepublic: Tips and Tricks of Functional Testing Licenses Gagan Talwar: Integration Testing Tips. functional/integrationtesting-tips. (2012). 36. SmartBear Software: 6 Tips to Get Started with Automated Testing (whitepaper).(2010). Link Consulting,SA Pág. 13 de 14