uma linguagem específica de domínio para geração de testes ... · marinho, thiago david dos...

Thiago David dos Santos Marinho

Uma Linguagem Específica de Domínio paraGeração de Testes de Performance

Brasil

30 de Agosto de 2016


Uma Linguagem Específica de Domínio para Geração deTestes de Performance

Dissertação de Mestrado apresentada ao Pro-grama de Pós-graduação em Engenharia deSoftware da Universidade Federal do RioGrande do Norte como requisito parcial paraa obtenção do grau de Mestre em Engenhariade Software.

Universidade Federal do Rio Grande do Norte – UFRN

Instituto Metrópole Digital – IMD

Programa de Pós-Graduação em Engenharia de Software

Orientador: Uirá KuleszaCoorientador: Felipe Alves Pereira Pinto

Brasil30 de Agosto de 2016

Marinho, Thiago David Dos Santos. Uma linguagem específica de domínio para geração de testes deperformance / Thiago David Dos Santos Marinho. - 2016. 121 f.: il.

Mestrado (Dissertação) - Universidade Federal do Rio Grandedo Norte, Instituto Metrópole Digital, Programa de Pós-Graduaçãoem Engenharia de Software. Natal, RN, 2016. Orientador: Uirá Kulesza. Coorientador: Prof. Dr. Felipe Alves Pereira Pinto.

1. Engenharia de software - Dissertação. 2. Testes deperformance - Dissertação. 3. Geração de código - Dissertação.I. Kulesza, Uirá. II. Pinto, Felipe Alves Pereira. III. Título.

RN/UF/Biblioteca Central Zila Mamede CDU 004.41

Universidade Federal do Rio Grande do Norte - UFRNSistema de Bibliotecas - SISBI

Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede


Uma Linguagem Específica de Domínio para Geração deTestes de Performance

Trabalho aprovado. Brasil, 30 de Agosto de 2016:

Uirá KuleszaOrientador

Felipe Alves Pereira Pinto (IFRN)Co-Orientador

Sérgio Medeiros (ECT/UFRN)Convidado 1

Franklin de Souza Ramalho (UFCG)Convidado 2

Brasil30 de Agosto de 2016

Dedico este trabalho à minha família.

Agradecimentos

Agradeço à Deus por essa e outras oportunidades que tive. Ao meu orientador Uiráe meu co-orientador Felipe, pela paciência e por compartilharem seu conhecimento comigo.À minha mãe Jaudete, meu pai Carlos e minha irmã Thaise, pelo carinho e apoio. Aosmeus amigos, pelo apoio e compreensão pela distância. À Dataprev pela oportunidade,especialmente ao Solon, Jefferson, Breno (não mais na empresa) e outros colegas detrabalho pela confiança e ajuda.

“Cada ano que passa desperta em seu interior as lembranças e a força.Empunhe seu coração e o mundo tremerá.”

(Doran, the Siege Tower)

ResumoEste trabalho apresenta a ferramenta GenMeter, composta por: (i) uma linguagem especí-fica de domínio utilizada para descrever textualmente testes de performance; e (ii) umcomponente que utiliza os testes descritos para gerar projetos em diferentes plataformasde execução de testes de performance. O objetivo é utilizar os conceitos definidos nalinguagem para abstrair os conceitos de cada plataforma, que muitas vezes são modeladosdiferentemente, quanto à nomenclatura e/ou estrutura, e até dependentes da ferramenta,ao invés de apenas do domínio. A ferramenta proposta oferece suporte para testes deserviços SOAP, REST e de aplicações web para JMeter e Silk Performer. Ela tambémpermite a customização para novos tipos de testes e plataformas alvo. Foram feitos estudospara avaliar o uso da ferramenta: 3 testes de aplicações Web, REST e SOAP foram rees-critos na linguagem específica de domínio (DSL - domain specific language) e então foramgerados projetos nas plataformas de destino, para que fossem executados. A partir dosajustes e novas implementações necessários para a geração dos projetos, obteve-se feedbackreferente a capacidade de customização da ferramenta em relação aos tipos de aplicaçõese características de plataformas e organizações. Além disso, os scripts também foramavaliados em relação à sua concisão: além dos testes implementados com a DSL e com o SilkPerformer, foram criados testes com a ferramenta Gatling.io (também baseados no testeda empresa). Comparou-se o total de palavras necessárias para a definição de cada teste,além da relação entre o número de palavras reservadas e o total de palavras, e a relaçãoentre o número de palavras reservadas fora do contexto e o total de palavras reservadas.Os testes criados com a DSL GenMeter possuem, em média, 59,15% menos palavras emrelação aos testes de Silk Performer e 39,43% em relação aos testes de Gatling.io, comexceção de um tipo de teste, em que a especificação com a DSL ficou com pouco maisque o dobro (138,35%) de palavras. Na segunda comparação, em média, os testes coma GenMeter apresentaram um percentual de 56,33% de palavras reservadas em relaçãoao total, contra 39,98% do Silk Performer e 67,03% do Gatling.io. Esta comparaçãopode ser interpretada como a quantidade de informação adicional que o usuário precisafornecer pra cada linguagem, além das estruturas fornecidas pela mesma. Já na terceiracomparação, que pode ser interpretada como o quanto a sintaxe da linguagem hospedeirapode interferir na visualização das informações dos testes, a GenMeter teve em média23,57% de palavras reservadas fora do contexto em relação ao total de palavras reservadas,contra 53,38% do Silk Performer e 54,60% do Gatling. Dessa forma, foi possível observaros benefícios de utilizar a DSL para diferentes tipos de aplicações, customizando-a deacordo com determinados conceitos e características de plataformas e organizações.

Palavras-chave: Linguagens específicas de domínio, Testes de performance, Geração decódigo

AbstractThis work presents GenMeter, a tool composed of: (i) a domain-specific language (DSL)used to describe textually performance tests; and (ii) a component that uses thosedescribed test specifications to generate projects in different performance test executionplatforms. The purpose is to use concepts defined in the language to abstract the conceptsof each platform, which are often modeled differently regarding nomenclature and/orstructure and even dependent on the tool rather than just the domain. The proposedtool supports SOAP, REST and web applications performance tests to JMeter and SilkPerformer. It also allows customization to new test types and target platforms. Studieswere conducted to evaluate the use of the tool: 3 tests of web applications, REST andSOAP services have been rewritten in the DSL and then were generated projects to thetarget platforms, to be executed. After the adaptation and new implementations necessaryfor the project generation, we obtained feedback regarding the ability to customize thetool for the applications types and platforms and organizations features. Moreover, thescripts were also evaluated for their conciseness: tests were created with Gatling.io tool(also based on the company’s test) to compare with existing DSL and Silk Performer tests.Our study also compared the total number of words needed to define each test and therelation between the number of reserved words and the total number of words; and therelationship between the number of reserved words out of context, and the total of reservedwords. Tests created with GenMeter have, on average, 59,15% less words in relation toSilk Performer tests and 39,43% in relation to Gatling.io tests, except by one test type,where GenMeter’s tests get little more than the double (138,35%) of words. In secondcomparison, on average, tests with the GenMeter presented a percentage of 56.33% ofreserved words in relation to the total, against 39.98% from Silk Performer and 67.03%from Gatling.io. This first comparison can be interpreted as the amount of additionalinformation that the user needs to provide for each language, in addition to the structuresprovided by them. In the third comparison, which can be interpreted as how the syntaxof the host language may interfere with viewing of the test information, GenMeter hadan average of 23.57% of reserved words out of context relative to the total of reservedwords against 53.38% from Silk Performer and 54.60% from Gatling. Thus, it was possibleto observe the benefits of using DSL for different types of applications, customizing itaccording to certain concepts and features platforms and organizations.

Keywords: Domain-specific languages, Performance tests, Code generation.

Lista de ilustrações

Figura 1 – Interface do JMeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Figura 2 – Exemplo de plano de teste no JMeter . . . . . . . . . . . . . . . . . . 29Figura 3 – Interface do LoadRunner . . . . . . . . . . . . . . . . . . . . . . . . . 30Figura 4 – Interface do Silk Performer . . . . . . . . . . . . . . . . . . . . . . . . 32Figura 5 – Visão Geral da Abordagem . . . . . . . . . . . . . . . . . . . . . . . . 36Figura 6 – Representação do Metamodelo . . . . . . . . . . . . . . . . . . . . . . 42Figura 7 – Organização da ferramenta . . . . . . . . . . . . . . . . . . . . . . . . 47Figura 8 – Representação das Camadas da Ferramenta nos Projetos Base e JMeter 48Figura 9 – Diagrama de Classes da Camada de DSL . . . . . . . . . . . . . . . . 49Figura 10 – Diagrama de Classes da Camada de Modelo . . . . . . . . . . . . . . . 50Figura 11 – Diagrama de Classes da Camada do Gerador . . . . . . . . . . . . . . 51Figura 12 – Contagem de palavras dos testes implementados com a GenMeter . . . 62Figura 13 – Contagem de palavras dos testes implementados com o Silk Performer 63Figura 14 – Contagem de palavras dos testes implementados com o Gatling.io . . . 63Figura 15 – Representação gráfica de um modelo de cenário de teste de performance

(BERNARDINO et al., 2014) . . . . . . . . . . . . . . . . . . . . . . . 70Figura 16 – Modelo de domínio da DSLBench . . . . . . . . . . . . . . . . . . . . 73

Lista de códigos

Código 1 – Comando para geração do projeto JMeter . . . . . . . . . . . . . . . . 37Código 2 – Exemplo de teste descrito com a DSL . . . . . . . . . . . . . . . . . . 43Código 3 – Definição de dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Código 4 – Definição de cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Código 5 – Definição de caso de teste web . . . . . . . . . . . . . . . . . . . . . . 45Código 6 – Definição de caso de teste REST . . . . . . . . . . . . . . . . . . . . . 46Código 7 – Definição de caso de teste SOAP . . . . . . . . . . . . . . . . . . . . . 46Código 8 – Requisição para serviço SOAP utilizando template e substituindo valores 55Código 9 – Asserções de resposta de requisição SOAP . . . . . . . . . . . . . . . . 55Código 10 – Requisição e asserção em serviço REST . . . . . . . . . . . . . . . . . 56Código 11 – Trecho do teste da DSL configuração de autenticação Basic . . . . . . 56Código 12 – Trecho do teste da DSL com acesso à URL . . . . . . . . . . . . . . . 57Código 13 – Trecho do teste da DSL com clique em link . . . . . . . . . . . . . . . 57Código 14 – Trecho do teste da DSL com o submit de formulário . . . . . . . . . . 57Código 15 – Trecho do teste da DSL em que é necessário efetuar login . . . . . . . 57Código 16 – Trecho do teste da DSL em que é necessário definir o encoding . . . . . 58Código 17 – Trecho do teste do Silk Performer em que é necessário definir o encoding 59Código 18 – Definição da propriedade encoding sem atalho . . . . . . . . . . . . . . 59Código 19 – Criação do atalho para a propriedade encoding . . . . . . . . . . . . . 59Código 20 – Trecho do teste do Silk Performer em que é necessário definir a quanti-

dade de vezes que o texto deve estar presente (segundo argumento da funçãoWebVerifyData) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Código 21 – Trecho do teste na DSL em que é necessário definir o parâmetro daasserção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Código 22 – Ajuste no método de asserção . . . . . . . . . . . . . . . . . . . . . . . 60Código 23 – Exemplo de utilização de EL com o Gatling; o trecho $bar será

interpretado como o atributo de nome bar presente na sessão da ferramenta . 64Código 24 – Exemplo de teste em Ruby JMeter . . . . . . . . . . . . . . . . . . . . 67Código 25 – Comando necessário para geração do teste em JMeter . . . . . . . . . 68Código 26 – Trecho de código com a DSL da ferramenta Gatling. O teste faz

chamadas ao recurso http://localhost/json durante 10 minutos e com 5 usuáriossimultâneos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Código 27 – Exemplo de teste gerado a partir de especificação com a DSL (SilkPerformer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Código 28 – Gramática da DSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Código 29 – Tokens definidos para a gramática . . . . . . . . . . . . . . . . . . . . 88

Código 30 – Teste do webservice dos correios . . . . . . . . . . . . . . . . . . . . . 91Código 31 – Teste do webservice dos correios . . . . . . . . . . . . . . . . . . . . . 93Código 32 – Teste do G1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Código 33 – Teste Secal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Código 34 – Teste Cadprevic REST . . . . . . . . . . . . . . . . . . . . . . . . . . 99Código 35 – Teste Cadprevic Web . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Código 36 – Teste Secal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Código 37 – Teste Cadprevic REST . . . . . . . . . . . . . . . . . . . . . . . . . . 103Código 38 – Teste Cadprevic Web . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Código 39 – Teste de performance da aplicação Secal . . . . . . . . . . . . . . . . . 107Código 40 – Teste de performance da aplicação Cadprevic (casos não executados

foram removidos) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Código 41 – Teste de performance da aplicação Cadprevic REST. . . . . . . . . . . 118Código 42 – Teste de performance da aplicação Cadprevic Web. . . . . . . . . . . . 120

Lista de tabelas

Tabela 1 – Ferramentas de teste de performance. . . . . . . . . . . . . . . . . . . . 19Tabela 2 – Exemplos de conceitos presentes em algumas ferramentas. . . . . . . . 20Tabela 3 – Abstrações da ferramenta JMeter. . . . . . . . . . . . . . . . . . . . . 40Tabela 4 – Abstrações da ferramenta Silk Performer. . . . . . . . . . . . . . . . . 40Tabela 5 – Abstrações da ferramenta Loadrunner. . . . . . . . . . . . . . . . . . . 41Tabela 6 – Relação entre conceitos e entidades das ferramentas e Metamodelo. . . 41Tabela 7 – Aplicações selecionadas por tipo de teste. . . . . . . . . . . . . . . . . 54Tabela 8 – Percentual de palavras reservadas em relação ao total de palavras . . . 64Tabela 9 – Percentual de palavras reservadas fora do contexto em relação ao total

de palavras reservadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Tabela 10 – Ferramentas e trabalhos relacionados. . . . . . . . . . . . . . . . . . . 67Tabela 11 – Sumário dos Trabalhos Relacionados. . . . . . . . . . . . . . . . . . . 75Tabela 12 – Contagem de palavras dos testes implementados com a DSL . . . . . . 86Tabela 13 – Contagem de palavras dos testes implementados com o Silk Performer 86Tabela 14 – Contagem de palavras dos testes implementados com o Gatling . . . . 86

Lista de abreviaturas e siglas

DSL Domain-Specific Language

SaaS Software as a Service

MDD Model Driven Development

GUI Graphical User Interface

IDE Integrated Development Environment

JDK Java Development Kit

EBNF Extended Backus–Naur Form

RFB Receita Federal do Brasil

JSF Java Server Faces

EL Expression Language

Sumário

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.2 Problema Abordado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.3.1 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.4 Escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.4.1 Testes de Performance na Dataprev . . . . . . . . . . . . . . . . . . . . . 221.4.2 Plataformas alvo da geração . . . . . . . . . . . . . . . . . . . . . . . . . 231.4.3 Elementos e artefatos fora do escopo . . . . . . . . . . . . . . . . . . . . 231.5 Questões de pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.6 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.7 Organização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . 262.1 Testes de performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.1.1 Testes de Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.1.2 Testes de Estresse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.1.3 Testes de Carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.1.4 Testes de sanidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2 Ferramentas Atuais de Teste de Performance . . . . . . . . . . . . . 272.2.1 JMeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2.2 Loadrunner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.3 Silk Performer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.3 Linguagens Específicas de Domínio . . . . . . . . . . . . . . . . . . . 322.3.1 DSL Externa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.3.2 DSL Interna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.3.3 Bancada de Linguagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.3.3.1 XText . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.3.3.2 MPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.3.3.3 MetaEdit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.3.4 Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.3.5 Analisador Sintático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3 LINGUAGEM ESPECÍFICA DE DOMÍNIO PARA GERAÇÃO DETESTES DE PERFORMANCE . . . . . . . . . . . . . . . . . . . . . 36

3.1 Visão Geral da Abordagem . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2 Requisitos e Decisões de Projeto . . . . . . . . . . . . . . . . . . . . . 373.2.1 Requisitos da Ferramenta . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.2.2 Decisões de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.3 O Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.4 A Linguagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.4.1 Definição de dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.4.2 Definição de cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.4.3 Definição de caso de teste . . . . . . . . . . . . . . . . . . . . . . . . . . 453.5 Arquitetura da Ferramenta . . . . . . . . . . . . . . . . . . . . . . . . 473.5.1 DSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.5.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.5.3 Gerador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4 AVALIAÇÃO DA ABORDAGEM PROPOSTA . . . . . . . . . . . . 524.1 Projeto do Estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.1.1 Objetivos e Questões de Pesquisa . . . . . . . . . . . . . . . . . . . . . . 524.1.2 Procedimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.3 Ameaças à Validade do Estudo . . . . . . . . . . . . . . . . . . . . . . 654.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.4.1 Discussões e Lições Aprendidas . . . . . . . . . . . . . . . . . . . . . . . . 66

5 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . 675.1 DSL para criação de projetos JMeter . . . . . . . . . . . . . . . . . . 675.2 Modelagem utilizando DSL Visual . . . . . . . . . . . . . . . . . . . . 685.3 Plataforma com suporte ao desenvolvimento e execução de testes

com DSL própria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.4 Geração de aplicações para testes de performance . . . . . . . . . . 725.5 Modelagem analítica de performance . . . . . . . . . . . . . . . . . . 745.6 Sumário dos Trabalhos Relacionados . . . . . . . . . . . . . . . . . . 74

6 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.1 Limitações do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 766.2 Contribuições da Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . 766.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

APÊNDICES 82

APÊNDICE A – EXEMPLO DE TESTE DE PERFORMANCE COMA DSL . . . . . . . . . . . . . . . . . . . . . . . . . 83

APÊNDICE B – CONTAGEM DE PALAVRAS DOS TESTES . . . 86

APÊNDICE C – GRAMÁTICA DA DSL . . . . . . . . . . . . . . . 87

APÊNDICE D – WEBSERVICE CORREIOS (SOAP) - TESTE COMA DSL . . . . . . . . . . . . . . . . . . . . . . . . . 91

APÊNDICE E – JSON TEST (REST) - TESTE COM A DSL . . . 93

APÊNDICE F – G1 (WEB) - TESTE COM A DSL . . . . . . . . . 95

APÊNDICE G – SECAL (SOAP) - TESTE COM A DSL . . . . . . 96

APÊNDICE H – CADPREVIC (REST) - TESTE COM A DSL . . . 99

APÊNDICE I – CADPREVIC (WEB) - TESTE COM A DSL . . . 100

APÊNDICE J – SECAL (SOAP) - TESTE COM O GATLING.IO . 102

APÊNDICE K – CADPREVIC (REST) - TESTE COMO GATLING.IO103

APÊNDICE L – CADPREVIC (WEB) - TESTE COMO GATLING.IO104

ANEXOS 106

ANEXO A – SECAL (SOAP) - TESTE ORIGINAL . . . . . . . . . 107

ANEXO B – CADPREVIC - TESTE ORIGINAL (ARQUIVO IN-CLUÍDO COM CONFIGURAÇÕES BÁSICAS) . . . . 115

ANEXO C – CADPREVIC (REST) - TESTE ORIGINAL . . . . . . 118

ANEXO D – CADPREVIC (WEB) - TESTE ORIGINAL . . . . . . 120

17

1 Introdução

Este capítulo apresenta a motivação, o problema, contexto, limitações de soluçõesexistentes, objetivos gerais e específicos da proposta, e metodologia usada no desenvolvi-mento desta dissertação.

1.1 MotivaçãoA engenharia de software utiliza diferentes tipos de requisitos como base no projeto

de sistemas de software (BASS; CLEMENTS; KAZMAN, 2012): requisitos funcionais,requisitos não funcionais (também chamados de atributos de qualidade) e restrições. O pri-meiro tipo descreve quais as responsabilidades atribuídas ao sistema, isto é, que funções eledeve fornecer aos atores. O segundo tipo representa propriedades mensuráveis ou testáveisde um sistema, usadas para indicar o quão bem o sistema satisfaz a necessidade de seusinteressados. Alguns exemplos são: disponibilidade, interoperabilidade, manutenibilidade,performance, segurança e usabilidade. Já o terceiro diz respeito a premissas baseadas nanecessidade das partes envolvidas no projeto; características que restringem o leque deescolhas a serem tomadas na definição da arquitetura do mesmo, ou que simplesmenteimpõem uma opção. Por exemplo, utilização de uma linguagem específica, reutilização deum módulo existente ou a necessidade de que o sistema seja orientado a serviços.

O cumprimento dos requisitos é verificado através da realização de testes. SegundoMyers et al. (2004): “testes de software é um processo, ou uma série de processos, designadospara garantir que o código faz aquilo que foi especificado a fazer e que ele não realizanenhuma ação não esperada. O software deve ser previsível e consistente, sem oferecersurpresas aos usuários”.

Podemos classificar os testes de acordo com os tipos de requisitos que eles verificam:testes funcionais verificam se a aplicação executa suas tarefas da forma como foramespecificadas (STARK, 2014). Em geral, dados de entrada são fornecidos, o teste éexecutado e o resultado obtido é comparado a um resultado esperado. São aplicáveis atodas as fases de testes (unitário, integração, sistema, aceitação e regressão).

Já os testes não funcionais verificam o quanto o sistema avaliado cumpre o quefoi definido em seus atributos de qualidade. Dentre estes, estão os testes de performance.Um dos objetivos principais destes é prever quando níveis futuros de carga esgotarão osistema, para que assim seja possível estabelecer estratégias para garantir que um nívelaceitável de experiência do usuário seja mantido (NGUYEN; JOHNSON; HACKETT,2003). Através de sua execução pode-se determinar características como responsividade,

Capítulo 1. Introdução 18

taxa de transferência, confiabilidade e/ou escalabilidade do sistema sob uma determinadacarga de trabalho (MEIER et al., 2007).

Existem várias classificações para testes de performance propostas na literatura. Serádestacada aqui alguns tipos da classificação proposta por Menascé e Almeida (2000): testesde desempenho, carga e de estresse. Os testes de desempenho buscam extrair informaçõessobre o desempenho do sistema em cenários normais de uso (JOBS, 2010). Testes decarga são usados para ajudar a identificar a capacidade máxima do sistema e possíveisgargalos que podem vir a interferir na operação do mesmo (ALVARES JOSE CARRERA,2009). Eles permitem avaliar como uma aplicação suporta sua carga esperada através daexecução de scripts de teste que simulam o comportamento dos usuários (MENASCE,2002). Os testes de estresse, diferentemente dos anteriores, consistem em submeter osistema a situações anormais de uso, como grandes quantidades de carga, redução dosrecursos computacionais disponíveis e entradas não realistas de dados (SANTOS; NETO;RESENDE, 2010).

A natureza dos testes de performance demanda a utilização de ferramentas específi-cas para sua execução e análise. Não é viável (ou até possível), por exemplo, a mobilizaçãode uma equipe para que faça centenas de requisições por segundo a uma aplicação. Tambémé necessário, durante a execução, monitorar diversos componentes e variáveis como tempode resposta, taxa de erros, tráfego na rede, consumo de recursos nas máquinas hospedeiras(memória, processamento, acesso ao disco rígido), etc.

Para tal, existem diversas ferramentas de apoio. Algumas delas são simples pro-gramas de linha de comando que, de acordo com configurações informadas através deparâmetros, fazem requisições a uma URL. Exemplos de programas deste tipo são o AB1

e o siege2. Ambos são normalmente utilizados apenas para testes rápidos, já que possuempoucos recursos de monitoramento.

Existem também algumas ferramentas mais robustas, como JMeter3, Silk Performer4

e Flood.io5, que servem não só para execução como também para criação de casos de teste ecenários mais complexos de monitoramento. São oferecidas em diversas formas (aplicaçõesdesktop, SaaS – Software as a Service) e cada uma delas utiliza suas próprias abstraçõese recursos, oferecendo interfaces gráficas, wizards e até linguagens de propósito geral eespecíficas de domínio (DSL), que nem sempre são ideais para um rápido entendimentosobre os testes que estão sendo representados.1 <http://httpd.apache.org/docs/2.2/programs/ab.html>2 <https://www.joedog.org/siege-home/>3 <http://jmeter.apache.org/>4 <http://www.borland.com/pt-BR/Products/Software-Testing/Performance-Testing/

Silk-Performer>5 <https://flood.io/>

http://httpd.apache.org/docs/2.2/programs/ab.html

https://www.joedog.org/siege-home/

http://jmeter.apache.org/

http://www.borland.com/pt-BR/Products/Software-Testing/Performance-Testing/Silk-Performer

http://www.borland.com/pt-BR/Products/Software-Testing/Performance-Testing/Silk-Performer

https://flood.io/


1.2 Problema AbordadoExistem várias ferramentas para criação e execução de testes de performance, com

diferentes abordagens; algumas dessas ferramentas estão descritas na Tabela 1. Um aspectoimportante é que boa parte das ferramentas oferece suporte a aplicações web. Comopode ser visto na Tabela 2, as ferramentas não seguem as mesmas abstrações, conceitos elinguagens. Muitas destas abstrações e conceitos têm mais a ver com características daplataforma do que propriamente com conceitos de testes de performance. Essas diferençasacabam dificultando a migração para um novo ambiente e a adaptação dos especificadoresà novas ferramentas, já que é necessário aprender um novo conjunto de conceitos. Elastambém fazem com que seja difícil converter os testes de uma plataforma para outra,dificultando o reuso de uma implementação de teste em outros ambientes, pois é necessárioque o mesmo seja refeito.

Tabela 1 – Ferramentas de teste de performance.

Ferramenta DescriçãoJMeter Software open source 100% feito em Java desenhado para testes

de carga e medição de desempenho, originalmente criado para usocom aplicações web.

Loadrunnera Solução para testes de desempenho, carga e estresse, que pode serutilizada para testar aplicações web, desktop e mobile.

Silk Performer Ferramenta para criação e execução de testes de performance.Segue uma abordagem de desenvolvimento programática, tambémpermitindo a gravação de testes. A execução dos testes ocorrelocalmente ou através de agentes remotos.

RationalPerformanceTesterb

Solução de testes de performance criada pela IBM, baseada noEclipsec e que funciona com a gravação dos testes através danavegação no website sendo testado ou implementação manual.

AB Ferramenta simples de linha de comando para teste de servidoresHTTP e aplicações web.

Flood.io Ferramenta que permite a execução de testes de performance emsua própria infraestrutura. Oferece uma DSL em Rubyd, chamadaRuby JMetere para a descrição desses testes, permitindo inclusiveque os testes gerados possam ser executados localmente, no JMeter.Não permite geração para outras ferramentas.


Gatling.iof Produto que oferece ferramentas para gravação de testes de per-formance diretamente no browser, uma API e uma DSL (interna,em Scalag) para edição dos scripts, e também uma plataformapara execução dos testes gerados e/ou criados manualmente. ADSL faz parte da plataforma, e não foi feita com o intuito de gerarprojetos de outras plataformas.

DSLBench(BUI et al.,2007)

Implementada com a ferramenta Microsoft Domain Specific Lan-guage Toolkit (atualmente Modeling SDK for Visual Studioh), ebaseada em MDD (Model Driven Development). Funciona comoplugin do Visual Studio 2005 Team Suite.

Revel8or(ZHU et al.,2007)

Toolkit que utiliza as ferramentas DSLBench, MDAPerf e MDA-Bench para a implementação, modelagem e execução dos testes,análise preditiva e também de seus resultados.

a <http://www8.hp.com/br/pt/software-solutions/loadrunner-load-testing/>b <http://www-03.ibm.com/software/products/pt/performance>c <https://eclipse.org>d <https://www.ruby-lang.org/pt/>e <https://github.com/flood-io/ruby-jmeter>f <http://gatling.io/>g <http://www.scala-lang.org/>h <https://msdn.microsoft.com/en-us/library/bb126259.aspx>

Tabela 2 – Exemplos de conceitos presentes em algumas ferramentas.

Significado JMeter Silk Performer LoadrunnerGrupo de testes, cenáriose configurações

Test Plan Project Solution

Características de umcaso de teste

Thread User Script

Casos de testes Sampler Transaction ActionMassa de dados Datasource Datasource Parameter

http://www8.hp.com/br/pt/software-solutions/loadrunner-load-testing/

http://www-03.ibm.com/software/products/pt/performance

https://eclipse.org

https://www.ruby-lang.org/pt/

https://github.com/flood-io/ruby-jmeter

http://gatling.io/

http://www.scala-lang.org/

https://msdn.microsoft.com/en-us/library/bb126259.aspx


Muitas vezes informações essenciais sobre o requisito não-funcional que será testadonão são exibidas na interface das ferramentas, seja porque ficam escondidas, porque sãoinferidas a partir de outros dados, ou porque a ferramenta simplesmente não tem aqueletipo de informação em seu conjunto de conceitos e abstrações. Isso pode fazer com queseja mais complicado entender o que de fato são os testes de performance na ferramenta, eo que eles estão avaliando.

Considerando ferramentas e processos presentes em ambientes corporativos, algunsproblemas adicionais podem ser listados:

• Boas práticas e padrões precisam ser verificados e aplicados a códigos gerados porferramentas de gravação e manualmente, quando este código poderia ser gerado jácom essas características levadas em conta;

• Caso haja mudança na ferramenta utilizada para execução dos testes (por conta deuma nova licitação, por exemplo), os projetos que foram descritos na ferramentasubstituída deverão ser migrados para a nova. Por exemplo, caso uma empresa precisemudar de ferramenta, deverá refazer manualmente todas as implementações de testesque já possui. Existem poucas aplicações criadas para conversão de testes. A únicaencontrada durante a pesquisa, lr2jm6, possui algumas limitações:

– Escopo limitado (converte apenas projetos do Loadrunner para JMeter);

– Pouca documentação disponível;

– Projeto sem contribuições há muito tempo.

Algumas plataformas também permitem a extensão de suas funcionalidades atravésda criação de plugins7 e/ou bibliotecas8 9, o que dificulta ainda mais a criação deum conversor universal.

1.3 ObjetivosEste trabalho propõe o desenvolvimento de uma plataforma baseada em uma

linguagem específica de domínio, GenMeter, que permita a geração de scripts de testesde performance para diferentes ferramentas de testes. As plataformas alvo da geração nestetrabalho serão JMeter e Silk Performer, oferecendo suporte a testes de serviços REST,SOAP, e de aplicações web com interface gráfica.6 Ferramenta que serve para converter testes do Loadrunner para JMeter: <https://code.google.com/p/

lr2jm/source/browse/trunk/lr2jm.pl>7 <https://jmeter.apache.org/extending/jmeter_tutorial.pdf>8 <http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.microfocus.silkperformer.

doc%2FSILKPERF-B1759FD9-CUSTOMDLLS-CON.html>9 <https://ptfrontline.wordpress.com/2009/02/24/using-a-custom-dll-in-loadrunner/>

https://code.google.com/p/lr2jm/source/browse/trunk/lr2jm.pl

https://code.google.com/p/lr2jm/source/browse/trunk/lr2jm.pl

https://jmeter.apache.org/extending/jmeter_tutorial.pdf

http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.microfocus.silkperformer.doc%2FSILKPERF-B1759FD9-CUSTOMDLLS-CON.html

http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.microfocus.silkperformer.doc%2FSILKPERF-B1759FD9-CUSTOMDLLS-CON.html

https://ptfrontline.wordpress.com/2009/02/24/using-a-custom-dll-in-loadrunner/


1.3.1 Objetivos Específicos

• Criar uma linguagem que permita descrever os testes de performance em altonível, que utilize apenas conceitos relacionados a este domínio, mas que permita acustomização para utilização de conceitos específicos de uma plataforma;

• Criar infra-estrutura que permita a geração de especificações na DSL para diferentesambientes e ferramentas de testes de performance;

• Avaliar a solução proposta através de um estudo de caso na Dataprev, comparandoo seu uso com o do Silk Performer.

1.4 EscopoEsta seção apresenta o escopo deste trabalho.

1.4.1 Testes de Performance na Dataprev

Os estudos realizados neste trabalho foram feitos na Dataprev10. Lá, os testes deperformance são especificados e executados com a ferramenta Silk Performer. Abaixo éapresentado um resumo do processo de testes11:

1. É criado um documento chamado Plano de Teste de Desempenho, onde sãoespecificados os casos de teste, cenários, massas de dados e outras informaçõesrelevantes aos atores envolvidos neste processo;

2. Com base nos casos de testes definidos neste documento, o codificador deverácriar os scripts de testes, manualmente ou através de gravação com a ferramentadisponibilizada para isso pelo Silk Performer (que gera código a partir do passo apasso executado). Após isso, deverá fazer ajustes referentes a parametrização devalores dinâmicos, sequência de transações dos scripts e pontos de think time12;

3. O ambiente onde os testes serão executados é preparado;

4. Testes de sanidade13 são executados para garantir que a aplicação está estável;10 <http://portal.dataprev.gov.br/>11 Material que contém um diagrama mostrando como é o processo de realização de testes de per-

formance: <http://desenvolvimento.dataprev.gov.br/pddataprev_internet/visualizar_processo.php?idprocesso=1&idfluxo=4,20,36>

12 Think times são usados para simular o comportamento humano ao interagir com uma página, fazendocom que o computador espere algum tempo entre interações com um website (<https://msdn.microsoft.com/en-us/library/ms184790%28v=vs.90%29.aspx?f=255&MSPPError=-2147217396>).

13 Tipo especial de teste, usado para avaliar se uma aplicação está estável o suficiente para ser submetidaa testes mais detalhados, como testes funcionais e de performance (DATAPREV, 2014).

http://portal.dataprev.gov.br/

http://desenvolvimento.dataprev.gov.br/pddataprev_internet/visualizar_processo.php?idprocesso=1&idfluxo=4,20,36

http://desenvolvimento.dataprev.gov.br/pddataprev_internet/visualizar_processo.php?idprocesso=1&idfluxo=4,20,36

https://msdn.microsoft.com/en-us/library/ms184790%28v=vs.90%29.aspx?f=255&MSPPError=-2147217396

https://msdn.microsoft.com/en-us/library/ms184790%28v=vs.90%29.aspx?f=255&MSPPError=-2147217396


5. O teste de performance é executado.

Os ajustes feitos para parametrização e adequação dos testes são feitos manualmente.Existe um roteiro14 com diversos itens que devem ser verificados durante esta tarefa; estesitens dizem respeito a padrões que devem ser considerados na confecção dos testes e boaspráticas.

1.4.2 Plataformas alvo da geração

As plataformas escolhidas para geração de projetos neste trabalho são:

• Silk Performer: escolhida por ser a ferramenta utilizada no local onde o estudo foiaplicado, a Dataprev;

• JMeter: escolhida por ser uma ferramenta largamente utilizada na comunidade paraexecução de testes de performance.

1.4.3 Elementos e artefatos fora do escopo

Os seguintes elementos não fazem parte do escopo deste trabalho:

• Configurações adicionais, que não fazem parte da descrição do teste em si (comodefinições de diretórios base, localização de ferramentas necessárias - JDK, porexemplo);

• A forma como os testes necessários são especificados e/ou inicialmente documentados(em, por exemplo, um plano de teste), pois a ferramenta não necessariamentesubstituiria documentos já existentes em organizações onde seria aplicada.

1.5 Questões de pesquisaAs seguintes perguntas foram propostas para guiar este trabalho:

Q1. É possível descrever testes de performance para diferentes tipos de aplicações com aDSL proposta? Uma das características da DSL é que ela deve ser capaz de descrevertestes para diferentes tipos de aplicações, por padrão ou provendo meios para quedesenvolvedores a estendam (Seção 4.2, Q1).

14 <http://desenvolvimento.dataprev.gov.br/pddataprev_internet/visualizar_artefato.php?idprocesso=1&idartefato=209&iddisciplina=5>

http://desenvolvimento.dataprev.gov.br/pddataprev_internet/visualizar_artefato.php?idprocesso=1&idartefato=209&iddisciplina=5

http://desenvolvimento.dataprev.gov.br/pddataprev_internet/visualizar_artefato.php?idprocesso=1&idartefato=209&iddisciplina=5


Q2. A abordagem permite que a DSL seja customizada para se adequar aos conceitosespecíficos de plataformas e/ou necessidades de organizações onde seria utilizada?Em complemento à primeira pergunta, também é necessário que a ferramenta possaser ajustada para usar conceitos diferentes dos originais, facilitando a adoção delaem diferentes cenários (Secao 4.2, Q2).

Q3. Quão concisas são as especificações na DSL proposta em comparação com outras re-presentações textuais de testes existentes? Os testes especificados com a DSL propostasão mais concisos que os testes criados com outras ferramentas, facilitando assima visualização das informações pertinentes ao contexto dos testes de performance?(Secao 4.2, Q3).

1.6 MetodologiaAs seguintes atividades foram realizadas durante o desenvolvimento deste trabalho:

• Levantamento bibliográfico através de buscas por artigos e outros trabalhos relaci-onados ao assunto abordado. Este levantamento resultou no estudo dos seguintestrabalhos: DSLBench, Revel8or, Aspen e abordagem de BERNARDINO et al. (2014);

• Estudo de ferramentas e ambientes de testes de performance atuais: JMeter, SilkPerformer, Loadrunner, Rational Performance Tester, flood.io e Gatling.io;

• Definição e implementação da DSL:

– Definição do metamodelo (a partir do estudo da literatura e de ambientesexistentes de teste de performance);

– Definição da DSL de forma que reflita conceitos que foram escolhidos para ometamodelo;

– Definição de tecnologias a serem utilizadas;

• Implementação da ferramenta que utiliza a linguagem para geração de testes emdiferentes plataformas:

– Definir plataformas-alvo suportadas inicialmente;

– Definir tipos de testes suportados inicialmente;

• Avaliação da abordagem proposta:

– Escolha de projetos de teste de performance na Dataprev;

– Implementação dos projetos escolhidos na DSL;

– Geração dos projetos para as plataformas-alvo Silk Performer e JMeter;

– Execução dos testes gerados.


1.7 OrganizaçãoEste trabalho está organizado da seguinte forma:

O Capítulo 2 descreve conceitos relevantes de testes de performance, linguagens dedomínio específico e de algumas possíveis ferramentas que podem ser alvo de geração decódigo.

O Capítulo 3 apresenta detalhes sobre a solução que foi desenvolvida com estetrabalho: seus requisitos, decisões de design que foram tomadas, arquitetura e organizaçãodo código.

O Capítulo 4 traz detalhes sobre o estudo feito para avaliar a solução proposta eseu uso como ferramenta de especificação de testes de performance.

O Capítulo 5 fala sobre trabalhos e soluções relacionados que são referentes àutilização de DSLs de testes de performance.

Finalmente, o Capítulo 6 traz uma discussão sobre as limitações do trabalho,contribuições de pesquisa e possíveis trabalhos futuros.

26

2 Fundamentação Teórica

Este capítulo descreve diversos conceitos referentes ao tema deste trabalho. Pri-meiramente são apresentados alguns conceitos de testes de performance na seção 2.1. Emseguida, algumas possíveis ferramentas alvo de geração de código são apresentadas naseção 2.2. Finalmente, alguns conceitos referentes à linguagens específicas de domínio sãodescritos na seção 2.3.

2.1 Testes de performanceO teste de performance é parte crucial de um processo de qualidade e teste

de software em uma aplicação. Tem como objetivo determinar características como:responsividade, taxa de transferência, confiabilidade e/ou escalabilidade de um sistemasobre uma determinada carga de trabalho (MEIER et al., 2007). É muito importante naanálise do sistema e, caso não seja executado da maneira correta, seus resultados são inúteisou até enganosos, fazendo com que uma empresa menospreze ou superestime a capacidadede sua aplicação (SAVOIA, 2000). Pode ser classificado em testes de desempenho, estressee carga.

2.1.1 Testes de Desempenho

Tipo de teste que busca extrair informações sobre o desempenho do sistema emcenários normais de uso (JOBS, 2010). São voltados para a investigação de aspectosrelacionados à responsividade, velocidade e estabilidade do sistema. Testes focados nessesaspectos nos permitem avaliar a velocidade de resposta do sistema em diversos níveis decarga e cenários. Com eles, podemos também realizar testes de confiabilidade no sistema eanalisar os aspectos que nos indicam o nível de escalabilidade permitido em relação aosistema, possibilitando o planejamento de estratégias para futuros aumentos de capacidade(ALVARES JOSE CARRERA, 2009).

2.1.2 Testes de Estresse

É um tipo de teste de performance focado em determinar a robustez, disponibilidadee confiança da aplicação diante de condições extremas, sendo que seu objetivo é identificarproblemas na aplicação que tornam-se aparentes somente diante dessas condições. Taiscondições podem ser cargas de trabalho muito pesadas, alta simultaneidade de usuários oulimitações de recursos computacionais (CAMPOS, 2011). Assim, consistem em submeter

Capítulo 2. Fundamentação Teórica 27

o sistema a situações anormais de uso, como grandes quantidades de carga, redução dosrecursos computacionais disponíveis e entradas não realistas de dados.

2.1.3 Testes de Carga

São usados para ajudar a identificar a capacidade máxima do sistema e possíveisgargalos que podem vir a interferir na operação do mesmo. São diversas as circunstânciasonde é indicada a realização de testes de carga. Exemplo de tais circunstâncias são aantecipação de um aumento significativo de carga na aplicação decorrente de ações demarketing ou mudanças na aplicação, como a adição de novas funcionalidades ou o redesigndo sistema (ALVARES JOSE CARRERA, 2009).

2.1.4 Testes de sanidade

Esse é um tipo especial de teste, usado para avaliar se uma aplicação está estávelo suficiente para ser submetida a testes mais detalhados, como testes funcionais e deperformance. Este tipo de teste também é conhecido como Smoke test e tem o propósito deevitar que se desperdicem recursos de testes com uma versão que não esteja suficientementeestável para ser testada (DATAPREV, 2014).

2.2 Ferramentas Atuais de Teste de Performance

2.2.1 JMeter

Apache JMeter é uma aplicação desktop, desenvolvida em Java, para realizartestes de carga de comportamentos funcionais e medir a performance. Originalmente foicriada para testar aplicações web, porém foi expandida para outros tipos de teste. Elapode ser usada para testar performance tanto de recursos estáticos, como dinâmicos.Simula altas cargas em um servidor, rede ou objeto para testar sua capacidade ou paraanalisar a performance geral sob diferentes tipos de carga. Pode também ser usadopara analisar a performance através de gráficos ou para testar o comportamento de seuservidor/script/objeto sob alta carga concorrente (ALVARES JOSE CARRERA, 2009).Os scripts de testes de performance são mantidos no formato XML. Sua interface pode servista na Figura 1.

Para criar um teste no JMeter, primeiramente devemos criar um plano de teste(Test Plan) com os elementos do teste, que podem ser (ALVARES JOSE CARRERA,2009):

• Grupo de Usuários ou Thread Group: é o ponto principal que agrega todos os outroselementos do plano de teste, ele controla os grupos de usuários, que serão executados;


Figura 1 – Interface do JMeter

• Controladores ou Controllers: divididos em Testador ou Sampler e ControladoresLógicos ou Logic Controllers. Testadores: são controladores já prontos para requi-sições específicas. Controladores Lógicos: são controladores genéricos, podendo sercustomizados com a inserção de outros controladores, elementos de configuração,asserções, etc;

• Ouvintes ou Listeners: fornecem acesso às informações obtidas pelo JMeter duranteos testes;

• Temporizador ou Timers: utilizado para incluir pausas ou delays entre as transações;

• Elemento de Configuração ou Configuration Elements: elemento que pode modificaras requisições;

• Pré-Processadores ou Pre-Processor Elements: executa alguma ação antes de fazer arequisição;

• Pós-Processadores ou Post-Processor Elements: executa alguma ação depois de fazera requisição;

• Asserções ou Assertions: usadas para verificar se uma requisição feita ao alvo doteste obteve os resultados esperados;


• Fontes de dados ou Datasources: tipo de elemento de configuração que permite o usode arquivos CSV como fontes de dados para preenchimento de valores em templatesde requisições, asserções, etc.;

Um exemplo de plano de teste pode ser visto na Figura 2.

Figura 2 – Exemplo de plano de teste no JMeter

2.2.2 Loadrunner

O Loadrunner é uma solução para testes de desempenho, carga e estresse que podeser utilizada para testar diversos tipos de aplicativos em desktop e mobile. Pode ser inte-grada com diversas aplicações para desenvolvedores, como IDEs, ambientes de integraçãocontínua e ferramentas de compilação. Possui uma versão gratuita que disponibiliza até 50usuários virtuais para a execução dos testes. É possível gerar os códigos ou implementá-losmanualmente, conforme descrito adiante.

• O processo inicia com a execução do Virtual User Generator : a criação de um usuáriovirtual é feita através da gravação da interação do cliente com a aplicação em nívelabaixo da interação através da GUI. Desta forma, não é necessário que a execuçãoinicie de fato a interface gráfica para executar o teste;

• A gravação é feita de forma programática na linguagem C, em um arquivo de texto.Este script contém todas as ações executadas, com os valores informados pelo usuáriopara cada uma, quando aplicável;

• É possível criar parâmetros e então utilizar massa de dados para os valores identifi-cados na gravação e registrados no script;

• Os resultados do teste mostram a renderização da tela de acordo com os dadosinformados;

• Algumas configurações como número de iterações, tempo entre iterações, think timesão feitas através de caixas de diálogo e não ficam representados no script gerado;

• Através desta aplicação é possível executar “pré-testes” para validação do script.


Após a criação dos scripts, utiliza-se uma opção para criar cenários e então executarde fato o teste. Esta execução é feita através de outra ferramenta, chamada Controller. Ainterface do Loadrunner pode ser vista na Figura 3.

Figura 3 – Interface do LoadRunner

Um teste nesta plataforma possui os seguintes elementos:

• Solution: container usado para agrupar os elementos do teste de performance (scripts,etc);

• Script: é um agrupador de configurações utilizadas na execução de um teste. Podeser interpretado como uma “unidade de execução de testes” com seus insumos;

• Parameters: são chaves criadas que referenciam campos de massas de dados disponí-veis para a execução dos testes;

• Action: contém uma ou mais funções que executam os passos do teste, asserções, etc.Existem inicialmente 3 ações:

– vuser_init: equivalente a um método setup de um teste unitário; onde configu-rações iniciais são feitas;

– Action: onde ficam os testes de fato;

– vuser_end: equivalente a um método tearDown de um teste unitário; onde, senecessário, recursos são liberados.


• Function: código utilizado em mais de um lugar pode ser extraído para um bloco,evitando duplicação de código, basicamente como em qualquer linguagem de progra-mação;

• Asserção ou Assertion: usada para verificar se o resultado de uma requisição está deacordo com o esperado.

2.2.3 Silk Performer

Silk Performer é a solução da Microfocus1 para criação e execução de testes deperformance. Segue uma abordagem de desenvolvimento programática, também permitindoa gravação de testes. A execução dos testes pode ser feita local ou utilizando agentes remotos.Seus scripts são escritos com a linguagem BDL (Benchmark Description Language), espéciede subset do Pascal. Também é possível estender funcionalidades da linguagem com o usode bibliotecas personalizadas e classes Java. A criação dos testes ocorre da seguinte forma:

• A ferramenta oferece uma caixa de diálogo para escolha do tipo de aplicação queserá testada. Alguns dos vários tipos de aplicações disponíveis são aplicações web,serviços FTP, SOAP, etc;

• Após a seleção do tipo de aplicação, é possível criar os scripts de teste programati-camente ou utilizar o recurso de gravação para registrar os passos em um site, porexemplo;

• O script criado/gravado é estruturado como um arquivo pascal: possui seções paradeclaração e implementação dos “usuários” e “transações”.

A Figura 4 mostra a Interface do Silk Performer.

Alguns dos elementos disponíveis na plataforma Silk Performer são:

• Users: o conceito de usuários é utilizado para separar diferentes tipos de configuraçõesaplicadas a cada conjunto de testes efetuados;

• Functions: é possível organizar códigos em funções, para evitar duplicação de código;

• Transactions: podem ser consideradas como os testes executados nos cenários;

• Datasources: existem funções nativas para leitura de massa de dados provenientesde arquivos CSV, que são configurados em funções no script de teste;

1 <http://www.microfocus.com.br/>

http://www.microfocus.com.br/


Figura 4 – Interface do Silk Performer

• Measure bounds: são marcações de tempos que podem ser definidas para operações deum teste. Por exemplo, posso definir dois measure bounds para o tempo de respostada requisição para um teste, de 3 e 5 segundos, e a aplicação mostrará no relatórioquantas requisições tiveram valores dentro destes tempos.

2.3 Linguagens Específicas de DomínioSegundo Fowler (2010), uma linguagem específica de domínio (do inglês, Domain-

Specific Language - DSL) é uma linguagem de programação de computadores de expressi-vidade limitada focada em um domínio específico. Existem quatro elementos-chave em taldefinição:

• Linguagem de programação de computadores: uma DSL é usada por humanos afim de instruir um computador a fazer algo. Assim como em qualquer linguagem deprogramação moderna, sua estrutura é projetada para facilitar seu entendimentopor humanos, mas também deve ser executável por um computador;

• Natureza da linguagem: uma DSL é uma linguagem de programação, e como tal deveter um senso de fluência, em que a expressividade não vem apenas das expressõesindividuais, mas também das maneiras pelas quais elas podem ser compostas;

• Expressividade limitada: uma linguagem de programação de propósito geral fornecemuitos recursos – suporta estruturas de dados, de controle e de abstração variadas.Tudo isso é útil, mas dificulta o aprendizado e o uso. Uma DSL suporta um mínimo


de recursos necessários para ser útil ao seu domínio. Você não consegue desenvolverum sistema de software inteiro em uma DSL; em vez disso, você usa uma DSL paraum aspecto específico de um sistema;

• Foco no domínio: uma linguagem limitada é útil apenas se tiver um foco claro emum domínio pequeno. O foco no domínio é o que faz uma linguagem limitada valer apena.

Fowler (2010) classifica as DSLs em Externas, Internas e de Bancada de Linguagem:

2.3.1 DSL Externa

DSL externa é uma linguagem específica de domínio representada separadamenteda linguagem de programação principal com que se está trabalhando. Essa linguagempode usar uma sintaxe customizada ou seguir a sintaxe de outra representação, comoXML. A análise de uma DSL externa se dá através da quebra do seu texto em algum tipode estrutura para que seja possível descobrir o que ele diz. Tal estruturação é chamadade análise sintática. Alguns exemplos de DSLs externas são: expressões regulares, SQL earquivos de configuração em XML.

2.3.2 DSL Interna

É uma maneira específica de usar uma linguagem de propósito geral. Um scriptem uma DSL interna é um código válido em sua linguagem de propósito geral, mas usaapenas um subconjunto dos recursos da linguagem em um estilo determinado para tratarde um pequeno aspecto do sistema como um todo. O resultado deve ter a cara de umalinguagem customizada, e não a cara de uma linguagem hospedeira. O exemplo clássicodesse estilo é Lisp; os programadores Lisp, em geral, falam sobre a programação nessalinguagem como a criação e o uso de DSLs. Ruby também desenvolveu uma cultura deDSLs forte: muitas bibliotecas Ruby vêm no estilo de DSLs. Em especial, o frameworkmais famoso de Ruby, Rails2, é normalmente visto como uma coleção de DSLs.

2.3.3 Bancada de Linguagem

Bancadas de linguagem são IDEs especializadas em definir e desenvolver DSLs;assim, uma DSL de bancada de linguagem é uma criada com este tipo de ferramenta.Especificamente, são usadas não apenas para determinar a estrutura de uma DSL, mastambém como ambiente customizado de edição para que as pessoas escrevam seus scripts2 <http://rubyonrails.org/>

http://rubyonrails.org/


nessa linguagem: servem tanto para a construção da linguagem quanto para sua utilização.Algumas das principais ferramentas são XText3, MPS4 e MetaEdit5.

2.3.3.1 XText

É um framework para desenvolvimento de linguagens de programação e DSLsdisponível como um plugin do Eclipse. Sua abordagem requer a descrição da gramática dalinguagem através de um dialeto próprio. A partir deste dialeto e da implementação deprocessadores e/ou geradores de código é gerada uma infraestrutura completa para uso dalinguagem, que pode ser gerada com plugin para o Eclipse, IntelliJ IDEA6 e navegadoresweb.

2.3.3.2 MPS

MPS (Meta Programming System) é uma ferramenta criada pela JetBrains para odesenvolvimento de DSLs. Funciona armazenando as informações em formato específico(ou seja, é necessário o uso de programas especiais para utilizar estes dados), apesar dousuário sempre trabalhar e visualizar apenas texto plano. Esta característica permitediversas vantagens, como incorporação de linguagens em outras (por exemplo, é possívelutilizar expressões regulares dentro de SQLs dentro de um código Java). A ferramenta foiinclusive usada para criar outra IDE da empresa, o YouTrack7.

2.3.3.3 MetaEdit

É particularmente focada em projeções gráficas, apesar de suportar também proje-ções tabulares (mas não textuais). Ela não é um ambiente auto-expressável; é necessárioutilizar um ambiente especial para a definição de esquemas e de projeções (FOWLER,2010).

2.3.4 Metamodelo

O metamodelo (ou modelo semântico) é, em poucas palavras, o modelo que épreenchido por uma DSL. É uma representação, tal como um modelo de objetos emmemória, do assunto que a DSL descreve. Se ela descreve uma máquina de estados, entãoseu modelo semântico pode ser um modelo de objetos com classes para estados, eventos,etc. Um script DSL que defina estados e eventos em particular corresponderia a umpreenchimento em particular desse esquema, com uma instância de evento para cada3 <https://eclipse.org/Xtext/>4 <https://www.jetbrains.com/mps/>5 <http://www.metacase.com/mep/>6 <https://www.jetbrains.com/idea/>7 <https://www.jetbrains.com/youtrack/>

https://eclipse.org/Xtext/

https://www.jetbrains.com/mps/

http://www.metacase.com/mep/

https://www.jetbrains.com/idea/

https://www.jetbrains.com/youtrack/


evento declarado no script DSL. O modelo semântico, é, então, a biblioteca ou o frameworkque a DSL preenche.

Muitas vezes o modelo semântico pode preceder a DSL. Isso acontece quando sedecide que uma porção do modelo de domínio da aplicação poderia ser melhor preenchidaa partir de uma DSL do que a partir de uma interface normal do tipo comando-consulta.Alternativamente, pode-se desenvolver uma DSL e seu modelo semântico juntos usandoas discussões com os especialistas em domínio para refinar tanto as expressões da DSLquanto a estrutura do modelo de domínio. O modelo semântico pode manter o códigopara ele mesmo executar (estilo de interpretador) ou ser a base para a geração de código(estilo de compilador).

É possível criar uma DSL sem modelo semântico, mas é preferível que este sempreseja usado, por diversas vantagens (FOWLER, 2010):

• É possível testar a semântica e a análise sintática da DSL separadamente:

– Pode-se testar a semântica preenchendo o modelo diretamente e executando ostestes em relação ao modelo, ou;

– Pode-se testar o analisador sintático vendo se ele preenche o modelo semânticocom os objetos corretos;

• Facilita o suporte a múltiplas DSLs e a evolução da mesma separadamente do modelosemântico;

• Permite dissociar a geração de código da DSL, facilitando a existência de múltiplosgeradores.

2.3.5 Analisador Sintático

É o componente responsável por interpretar o script da DSL e então preencher omodelo semântico. Faz mais sentido falar em análise sintática no escopo de DSLs externas,já que em linguagens internas não há uma entidade dedicada para esta análise; isso é feitoem conjunto pelo analisador sintático da linguagem hospedeira e pelos construtores deexpressão que esta utiliza. Porém, é possível traçar paralelos entre o processamento deDSLs internas e externas. Com a análise sintática tradicional, obtem-se um fluxo de texto,organiza-se esse texto em uma árvore de análise sintática e então esta é processada paraproduzir uma saída útil. Na análise sintática de uma DSL interna, sua chamada é umasérie de chamadas a funções. Ainda há a organização dessas chamadas em uma hierarquiapara produzir uma saída útil.

36

3 Linguagem Específica de Domínio para Ge-ração de Testes de Performance

Este capítulo apresenta detalhes sobre a abordagem proposta, forma como foiidealizada, seus requisitos, decisões de design e como seu código foi organizado.

3.1 Visão Geral da AbordagemNa abordagem proposta por este trabalho, o usuário da ferramenta GenMeter deverá

implementar seus testes com a DSL fornecida. Após isso, basta executar um programa queacompanha a ferramenta correspondente à plataforma alvo para a geração do projeto. Casoa plataforma alvo não seja suportada ainda, será necessário implementar os componentesresponsáveis pela geração. A Figura 5 mostra em alto nível como a abordagem seriautilizada em processos de criação de testes de performance:

Figura 5 – Visão Geral da Abordagem

As atividades estão detalhadas abaixo:

• Implementação do teste na DSL: os testes devem ser descritos utilizando es-truturas já presentes na linguagem, e, se necessário, novas estruturas podem serimplementadas (ver próxima atividade);

• Adaptação da ferramenta à nova plataforma alvo: para gerar projetos emnovas plataformas além das inicialmente englobadas será necessário criar um novoprojeto, seguindo a estrutura dos já existentes. Este projeto utilizará a base dabiblioteca (gem) genérica, que possui o metamodelo padrão e a gramática quecorresponde a ele. Caso seja necessário customizar a DSL também é possível fazê-loatravés de uma nova biblioteca;

Capítulo 3. Linguagem Específica de Domínio para Geração de Testes de Performance 37

• Geração do projeto na plataforma alvo: após definido o script do teste, para ageração do projeto é necessário executá-lo, como pode ser visto no Código 1;

Código 1 – Comando para geração do projeto JMeter$ ds l_jmeter s c r i p t_ t e s t e . rb

Isso fará com que o código seja interpretado e então, caso não tenha erros, gere oprojeto na plataforma onde os testes devem ser executados.

• Execução dos testes na plataforma alvo: o usuário deverá abrir o projeto naferramenta pra qual ele foi gerado, e então fazer as devidas configurações paraexecutar os testes de performance.

3.2 Requisitos e Decisões de ProjetoEsta seção lista os requisitos da ferramenta e da linguagem e algumas decisões de

projeto.

3.2.1 Requisitos da Ferramenta

R1. A DSL deve permitir a representação de artefatos e características relevantes epresentes na literatura e ferramentas de teste de performance. Com base no estudofeito, os artefatos levantados inicialmente são:

– Projeto de teste de performance: agrupador das informações referentesaos testes;

– Cenário: características da execução de cada caso de teste de performance(quantidade de usuários virtuais, quantidade de execuções, etc.);

– Caso de teste: definição dos passos que devem ser executados;

– Teste de sanidade: execução única de cada teste disponível para verificar sea aplicação e o ambiente estão estáveis e prontos para os testes;

– Massa de dados: arquivos utilizados para organizar e fornecer dados usadosdurante os testes.

R2. A DSL deve permitir a representação de testes de performance de aplicações web cominterface gráfica, serviços REST e SOAP. Estes são os principais tipos de aplicaçõesdesenvolvidos na Dataprev e, portanto, considerados neste trabalho;

R3. A ferramenta e a DSL devem permitir a inclusão de novas funcionalidades e estrutu-ras. Dessa forma é possível adequá-las à realidade de diferentes empresas e processosde teste.


R4. A ferramenta deve ser capaz de gerar código para diferentes projetos. Este requisito,em conjunto com o R3, permitirá que a linguagem seja usada em diferentes organi-zações, independente do programa utilizado para a execução dos testes, desde que aabordagem seja compatível com aquele programa.

3.2.2 Decisões de Projeto

D1. Desenvolvimento da linguagem como DSL Interna. Escolheu-se essa abordagem parao desenvolvimento da DSL. Abaixo, algumas características que fizeram com que amesma fosse escolhida:

– Conhecimento prévio do autor na linguagem hospedeira (Ruby);

– Com a liberdade que se tem quanto a forma como os artefatos de softwaresão organizados, é possível isolar cada projeto de plataforma a fim de que eleconheça apenas o que for necessário para seu funcionamento; em outras palavras,ele não teria acesso às características pertencentes a outras ferramentas;

– Possibilidade de configurar a ferramenta de forma simples, através da extensãodas classes necessárias;

– É possível utilizar a linguagem hospedeira livremente como base para customiza-ção (inclusive dentro do próprio script), coisa que não é possível ao trabalhar-secom uma DSL externa.

Apesar das facilidades fornecidas pelas bancadas de linguagem (XText e MPS,especialmente), a característica de isolar conceitos de diferentes ferramentas-alvo porprojeto é essencial, o que justifica a escolha de usar DSL interna. No entanto, talescolha traz algumas desvantagens:

– Ausência de IDE com higlight, autocomplete, etc. gerada a partir das definiçõesda DSL;

– A concisão pode ser comprometida caso a linguagem escolhida como hospedeirapossua muitas palavras reservadas, por exemplo;

– A DSL estará presa à sintaxe da linguagem hospedeira, o que pode comprometersua expressividade;

– Necessidade de definição da gramática da linguagem como uma atividadeadicional: utilizando a abordagem de DSL interna não é necessária a criaçãode uma gramática, mas caso haja necessidade de criá-la por algum outromotivo, normalmente ela será criada manualmente. Na abordagem descritaneste trabalho, a gramática foi criada para melhor documentar os métodos eestruturas disponíveis para uso. Ela está representada com a notação EBNF


(Extended Backus–Naur Form) (ISO/IEC, 1996), contempla as estruturasnecessárias para preencher as entidades do metamodelo básico e pode serencontrada no Apêndice C

D2. Utilizar Ruby como linguagem hospedeira para a DSL. Ruby possui uma forte culturade DSLs, em grande parte por conta de sua sintaxe flexível e relativamente próximada linguagem natural (FOWLER, 2010). Em relação às desvantagens apontadasno item anterior, sua legibilidade minimiza a necessidade de funcionalidades comoautocompletar e highlight (apesar deste segundo ser oferecido por diversos editoresde texto populares como Notedpad++1, Sublime Text2, Gedit3, Atom4, Nano5, Vim6,etc).

D3. Inglês como linguagem escolhida para a DSL. Escolha feita para permitir maiorabrangência da DSL, que poderá ser utilizada por uma quantidade maior de pessoassem que precisem aprender termos em outra língua. Além disso, evita-se a cacofo-nia pelo uso de termos em português e palavras-chave em inglês do Ruby, o queprejudicaria a legibilidade.

D4. A ferramenta deve permitir inicialmente a geração de projetos SilkPerformer eJMeter. A escolha dessas ferramentas deve-se aos seguintes fatores:

– Uma das aplicações pesquisadas (e que é explicitamente comparada com nossaabordagem), Ruby JMeter, também desenvolvida em Ruby, gera apenas projetosJMeter, e não provê formas de estender a geração para outras plataformas;

– O JMeter é uma ferramenta open source bastante utilizada para testes deperformance;

– Silk Performer é a ferramenta utilizada na Dataprev, onde o estudo de caso foirealizado.

D5. O código não deve ser diretamente gerado a partir dos métodos utilizados pela DSL.Os métodos que a compõem devem preencher o modelo semântico para que entãoeste gere o código na plataforma alvo. A estrutura que permite isso será discutidana seção 3.5.

1 <https://notepad-plus-plus.org/>2 <https://www.sublimetext.com/>3 <https://wiki.gnome.org/Apps/Gedit>4 <https://atom.io/>5 <http://www.nano-editor.org/>6 <http://www.vim.org/>

https://notepad-plus-plus.org/

https://www.sublimetext.com/

https://wiki.gnome.org/Apps/Gedit

https://atom.io/

http://www.nano-editor.org/

http://www.vim.org/


3.3 O MetamodeloO metamodelo (ou modelo semântico) é importante nesta abordagem porque

permite que DSL e gerador sejam desenvolvidos separadamente. Assim, o único papel daDSL é preencher este modelo. Para seu desenvolvimento foram considerados conceitos detrês ferramentas inicialmente candidatas como alvo da geração: JMeter, Silk Performer eLoadrunner. As Tabelas 3, 4 e 5 mostram algumas das abstrações dessas ferramentas, jáapresentadas no Capítulo 2.

Tabela 3 – Abstrações da ferramenta JMeter.

Conceito DescriçãoTest Plan Container onde todos os elementos de teste são colocados.Thread Define características referentes à quantidade de execu-

ções do teste.Datasource Tipo de elemento de configuração que permite o uso de

arquivos CSV como fontes de dados.Sampler Representa o que deve ser feito no teste.Assertion Utilizadas para verificar se o retorno de uma interação

com o alvo do teste contém os resultados esperados.

Tabela 4 – Abstrações da ferramenta Silk Performer.

Conceito DescriçãoProject Corresponde a um conjunto de cenários de um teste de

performance, com suas configurações, etc.User Utilizado para separar diferentes tipos de configurações

aplicadas a cada conjunto de testes (quais casos de testesão executados, número de execuções, etc).

Datasource Gerenciados através de funções que lêem arquivos CSV.Transaction Correspondem a um container que tem os passos do caso

de teste executado em um cenário.Assertion Verificação de retornos de chamadas ao alvo do teste.


Tabela 5 – Abstrações da ferramenta Loadrunner.

Conceito DescriçãoSolution Container de testes e configurações; equivale ao conceito

de “projeto”.Script Agrupador de configurações utilizadas na execução de

um teste.Parameter Chaves que referenciam campos de massas de dados.Action Container de funções que executam os passos dos testes,

asserções, etc.Assertion Verificação de retornos de chamadas ao alvo do teste.

Com este levantamento, foi possível desenhar um paralelo entre o conjunto deconceitos de cada ferramenta. A Tabela 6 mostra a relação entre os conceitos e entidadesde cada ferramenta e do metamodelo da abordagem.

Tabela 6 – Relação entre conceitos e entidades das ferramentas e Metamodelo.

Metamodelo JMeter Silk Performer LoadrunnerProject Test Plan Project SolutionScenario Thread User ScriptDataset Datasource Datasource ParameterProperty Customizávela Customizávela CustomizávelaTest Case Sampler Transaction ActionAssertion Assertion Assertion Assertiona Customizável porque é possível definir qualquer tipo de propriedade em qualquer pontodo script. Serve como um coringa.

Finalmente, a Figura 6 mostra o metamodelo adotado para a solução, baseado nastrês ferramentas consideradas neste estudo (dentre elas, as duas que serão alvo inicial dageração de projetos); ela representa as classes criadas e seus relacionamentos:

• Project: modelo que representa o projeto completo e que contém propriedades quesão válidas e/ou visíveis para todo o projeto. Ele pode conter datasets, scenarios eproperties;

• Dataset: representa arquivos de massa de dados utilizados nos testes de performance.Os campos destes arquivos que são usados nos testes são representados por fields;

• Field: modelo usado para guardar informações sobre o nome e/ou posição de umcampo em um arquivo de massa de dados;

• Scenario: agrupa configurações específicas do test case definido internamente. Possuiconfigurações como loop, timeout, etc;


• TestCase: agrupa os elementos que definem os passos que devem ser executados noteste. Pode possuir requests e assertions;

• Request: define cada ação feita ao servidor onde a aplicação ou serviço fica implan-tada. Pode representar algo como um clique em um link (e posterior request à URLdeste link), um formulário submetido, ou um request direto à uma URL. Compostopor parameters;

• Parameter: representa o nome e valor de possíveis parâmetros utilizados na requi-sição;

• Assertion: representa as verificações feitas no conteúdo retornado pelo servidorpara que seja identificado se o teste feito teve sucesso;

• Property: modelo simples (apenas chave/valor) usado para guardar informações deprojects, scenarios e test cases.

Figura 6 – Representação do Metamodelo

3.4 A LinguagemA linguagem usada para descrever os testes no GenMeter é, como dito anteriormente,

uma DSL interna implementada em Ruby em forma de API (é disponibilizada uma interface,que corresponde aos métodos que podem ser utilizados pelo desenvolvedor ao especificaros testes). Segue o paradigma de programação declarativa, ou seja, o foco é no que deve


ser feito, e não em como deve ser feito. Um exemplo de teste simples descrito com a DSLpode ser visto no Código 2.

Código 2 – Exemplo de teste descrito com a DSL1 project ’ g1 ’ do2 website ’ http :// g1 . g lobo . com ’34 scenario ’ busca s imple s ’ do5 loop 167 test_case ’ buscar por t e s t e ’ do8 open_homepage910 assert_that t i t l e . equa l s ? ’G1 − O por t a l de n o t í c i a s da

Globo ’1112 submit_form ac t i on : ’ /busca ’ , params : {13 q : ’ t e s t e ’14 }1516 assert_that t i t l e . equa l s ? ’ Resultado da busca por t e s t e ’17 end18 end19 end

O Código 2 pode ser interpretado da seguinte forma:

• Na linha 1 o projeto de teste de performance é definido; a única informação necessárianeste ponto é seu nome;

• A linha 2 define a URL da aplicação que será testada. Quando a aplicação é umserviço, o método endpoint pode ser utilizado para definir essa propriedade;

• A linha 4 define o cenário “Busca simples”, que é executado apenas uma vez (deacordo com o definido na linha 5);

• O cenário também possui o caso de teste “Buscar por teste” (definido na linha 7),que consiste em duas ações:

– Abrir a página inicial (linha 8);

– Submeter o formulário de busca, procurando pela palavra “teste” (linha 12);


• São feitas algumas asserções para validar o retorno da aplicação:

– Na linha 10 o título da página inicial é verificado;

– Na linha 16 o título da página de busca é verificado.

3.4.1 Definição de dataset

O Código 3 mostra um exemplo de definição de um dataset:

Código 3 – Definição de dataset1 dataset ’ dados . csv ’ do2 f i e ld nome : 13 f i e ld cp f : 24 f i e ld t e l e f o n e : 35 end

A linha 1 define um dataset, tendo como parâmetro o nome do arquivo. Já aslinhas 2, 3 e 4 mapeiam os campos que serão utilizados no teste, definindo os nomes pelosquais serão referenciados e a sua coluna correspondente (o campo “nome” fica na primeiracoluna; o campo “cpf” fica na segunda coluna).

3.4.2 Definição de cenário

O Código 4 traz um exemplo de descrição de um cenário:

Código 4 – Definição de cenário1 scenario ’ busca s imple s ’ do2 loop 134 timeout 300056 before_all_tests ’ l o g i n ’ do7 # . . .8 end910 test_case ’ buscar por t e s t e ’ do11 # . . .12 end13 end

O cenário é inicialmente definido através da instrução scenario (linha 1), tendocomo parâmetro o nome pelo qual o cenário é identificado. A linha 2 configura o número


de vezes que o teste definido nesse cenário será executado. A instrução timeout, da linha4 define, em milissegundos, o tempo máximo que a execução do teste deve durar. A linha6 é utilizada para definir ações que devem ser executadas antes do teste (como login nosistema), e tem os mesmos comandos disponíveis no bloco test_case (linha 10), que serávisto na subseção 3.4.3.

3.4.3 Definição de caso de teste

O GenMeter suporta testes de aplicações web, serviços REST e SOAP, que sãoexemplificados adiante. O código Código 5 mostra um caso de teste de uma aplicação web:

Código 5 – Definição de caso de teste web1 test_case ’ buscar por t e s t e ’ do2 open_homepage34 think_time 256 assert_that t i t l e . equals_to ? ’ T í tu lo da página ’78 open ’ / busca ’910 assert_that page . conta in s ? ’ Buscar por ’1112 think_time 31314 submit_form method : : get , a c t i on : ’ /busca ’ , params : {15 q : ’ t e s t e ’16 }1718 assert_that page . conta in s ? ’ Resultado da busca ’1920 end

O bloco de especificação do caso de teste é declarado com a palavra chave test_case(linha 1). A linha 2 é responsável por abrir a página inicial da aplicação, sendo este umatalho para o comando que define que uma página deve ser aberta (visto na linha 8).As linhas 4 e 12 definem tempos de think time, em segundos. As asserções de conteúdoda página e do título são feitas através das instruções presentes nas linhas 6, 10 e 18.Finalmente, a 14 mostra um exemplo de submissão de formulário, usando método “GET”,para a URL “/busca”, e passando o parâmetro “q” com o valor “teste” (linha 15).


O código Código 6 traz um caso de teste de um serviço REST:

Código 6 – Definição de caso de teste REST1 project ’ t e s t ’ do2 endpoint ’ http :// l o c a l h o s t ’34 scenario ’ t e s t ’ do5 loop 167 test_case ’ buscar por t e s t e ’ do8 rest_request method : : get , path : ’ i t e n s ’9 assert_that r e s t_response . conta in s ? ’nome ’10 end11 end12 end

A linha 8 mostra uma chamada ao caminho “/itens” do serviço presente emhttp://localhost (linha 2), utilizando o método GET. Logo abaixo, na linha 9 é feita umaasserção que verifica se a resposta do serviço contém o texto “nome”.

O código Código 7 traz um caso de teste de um serviço SOAP:

Código 7 – Definição de caso de teste SOAP1 project ’ t e s t ’ do2 endpoint ’ http :// l o c a l h o s t ’34 scenario ’ t e s t ’ do5 loop 167 test_case ’ buscar por t e s t e ’ do8 soap_request template : ’ template . txt ’ ,9 dataset : ’ da ta se t . csv ’ ,10 r ep l a c e : {11 ’ {nome} ’ => from_dataset ( : nome)12 }1314 assert_that soap_response . not . c onta in s ? ’ e r r o ’1516 assert_that soap_response . body17 . node ( ’ r e sponse / r e su l t ado / cp f ’ )18 . equals_to ? expected : from_dataset ( : cp f )


19 end20 end21 end

A linha 8 traz uma requisição a um serviço SOAP (acessado através da definição deseu endpoint, definido na linha 2), utilizando um arquivo de template (template.txt) comocorpo. É possível substituir trechos do arquivo usado como template através do parâmetroreplace (linha 10): no exemplo, todos os tokens {nome} do arquivo serão substituídos porcampos da massa de dados (através da definição from_dataset presente na linha 11). Asduas asserções presentes no caso de teste verificam se a resposta retornada pela aplicaçãopossui a palavra “erro” (linha 14) e se o corpo da resposta possui o valor de CPF esperadopara a requisição que foi feita (18).

3.5 Arquitetura da FerramentaA ferramenta foi desenvolvida com Ruby e foi organizada em diversos projetos

(gems). O projeto base possui a estrutura básica e comum a todos os modelos e versões daDSL, usados na representação sugerida por diferentes ferramentas alvo. Cada projeto (SilkPerformer e JMeter) corresponde a uma plataforma alvo, e no mínimo deve interpretar omodelo gerado para criar os artefatos de testes daquela plataforma. Também é possívelestender um desses projetos para incluir particularidades da organização onde a DSL seráutilizada, tal como o projeto Silk Performer - Dataprev, apresentado na Figura 7, ondepode ser visto como a ferramenta foi organizada.

Figura 7 – Organização da ferramenta

O uso de Ruby permite que se aproveite não só da sua sintaxe clara, mas de váriasfeatures de metaprogramação que permitem que a DSL se aproxime de como ficaria se


fosse feita como DSL externa ou com alguma bancada de linguagem, com destaque paramonkey patching7 e o uso de blocos.

A aplicação está dividida em três camadas: DSL, Modelo e Gerador, representadasna Figura 8. Ela ilustra a responsabilidade de cada camada e como elas se comunicampara que o artefato Projeto (JMeter, no exemplo) seja criado. Os tópicos seguintes definemcada camada.

Figura 8 – Representação das Camadas da Ferramenta nos Projetos Base e JMeter

7 Monkey patching é uma forma de estender ou modificar código em execução de linguagens dinâmicassem alterar o código-fonte original. Em Ruby, o termo ganhou um significado diferente, se referindo aqualquer modificação dinâmica em uma classe, e é frequentemente utilizado como um sinônimo paramudanças em qualquer classe em tempo de execução (<http://stackoverflow.com/questions/394144/what-does-monkey-patching-exactly-mean-in-ruby>).

http://stackoverflow.com/questions/394144/what-does-monkey-patching-exactly-mean-in-ruby

http://stackoverflow.com/questions/394144/what-does-monkey-patching-exactly-mean-in-ruby


3.5.1 DSL

Esta camada está ilustrada na Figura 9 e é implementada na biblioteca base daaplicação, podendo ser estendida em outras bibliotecas não abstratas (isto é, usadas parageração de código em alguma plataforma alvo) para implementação de características espe-cíficas, através, basicamente, de monkey patching. Contempla classes e módulos utilizadosdiretamente na criação dos scripts de teste de performance pelo usuário final. Os métodosdas classes representadas são os métodos que ficam disponíveis para o desenvolvedor doteste, com exceção dos métodos build, que são internos, usados para geração dos modelos.O papel desta camada é, através destes métodos disponibilizados para o desenvolvedor,obter as informações do teste para gerar os objetos da camada de modelo, que serãofinalmente usados pelo gerador para a criação dos testes na plataforma alvo. A classeContext é utilizada na classe Project para armazenar valores necessários em outrasentidades que não são acessíveis em seu escopo. Neste exemplo foram considerados apenasrequests para serviços SOAP.

Figura 9 – Diagrama de Classes da Camada de DSL

3.5.2 Modelo

Esta camada, representada na Figura 10 possui as estruturas que serão preenchidasatravés do que foi descrito na camada superior. Também pode ser estendida em outrasbibliotecas para adição de características exclusivas. A classe Replacement é utilizadacomo ligação entre as classes Request e Dataset, relacionando valores que devem sersubstituído em requisições com os campos definidos nas massas de dados.


Figura 10 – Diagrama de Classes da Camada de Modelo

3.5.3 Gerador

Implementada apenas nas bibliotecas não abstratas, esta camada possui as entidadesque, através da leitura do modelo gerado pela DSL, geram os artefatos necessários para aexecução do teste na plataforma alvo. Esta camada também foi implementada em Ruby eé representada na Figura 11, tendo como exemplo o gerador do Silk Performer. A classeGenerator::SilkPerformer implementa o método generate, que é responsável por geraros arquivos do projeto a partir da classe de modelo Project e outras. Ela também utilizaalguns métodos úteis da classe Generator::GeneratorUtils, como métodos para lerarquivos de templates, incluir outros arquivos dentro de templates, etc.


Figura 11 – Diagrama de Classes da Camada do Gerador

52

4 Avaliação da Abordagem Proposta

Este capítulo descreve o estudo conduzido para avaliar a ferramenta proposta nestetrabalho e sua utilização na atividade de especificação de testes de performance. O capítuloestá organizado da seguinte maneira: a seção 4.1 apresenta a forma como a avaliação foiorganizada, incluindo objetivos, questões de pesquisa (subseção 4.1.1) e procedimentos(subseção 4.1.2). A seção 4.2 traz os resultados da avaliação e respostas das questões depesquisa. A seção 4.3 traz as ameaças ao estudo que foram identificadas. E a seção 4.4conclui o capítulo e traz algumas discussões sobre os resultados.

4.1 Projeto do Estudo

4.1.1 Objetivos e Questões de Pesquisa

O objetivo principal do estudo é avaliar a possibilidade de uso da aplicação comoplataforma para desenvolvimento dos testes, além de adaptar a solução a novos conceitos,caso seja necessário. As seguintes perguntas serviram como guia para o estudo:

Q1. É possível descrever testes de performance para diferentes tipos de aplicações com aDSL proposta? Foram especificados testes reais de diversas aplicações web, RESTe SOAP da Dataprev para verificar se a abordagem proposta era adequada pararepresentar suas características. É importante verificar se os artefatos gerados pelasolução são válidos (se compilam e/ou são abertos normalmente nas plataformasalvo) e se os testes de performance poderiam ser feitos a partir destes artefatos.

Q2. A abordagem permite que a DSL seja customizada para se adequar aos conceitosespecíficos de plataformas alvo de geração de código e/ou necessidades de organizaçõesonde seria utilizada? Esta pergunta está relacionada à primeira, mas seu objetivo édefinir se a ferramenta permite que novas estruturas sejam criadas, seja na camadade DSL, modelo, geração, nos sub-projetos já existentes ou em projetos filhos, com ointuito de dar suporte à características exclusivas de ferramentas e organizações.

Q3. Quão concisas são as especificações na DSL proposta em comparação com outrasrepresentações textuais de testes existentes? A partir da análise e comparação doscomponentes gramaticais de cada teste pode-se ter uma estimativa do quão fácil oudifícil é obter informações relevantes sobre o teste em relação a outras.

Capítulo 4. Avaliação da Abordagem Proposta 53

4.1.2 Procedimentos

A análise feita para trazer respostas às questões de pesquisa envolve a especificaçãode testes com a DSL para geração dos projetos nas plataformas e posterior execução paravalidação. O procedimento foi dividido em quatro etapas:

1. Implementação de teste escolhido como prova de conceito na DSL. Nestaetapa foram escolhidas aplicações externas à Dataprev correspondentes a cada tipode aplicação suportada e, com base nelas, foram criados rascunhos de testes, levandoem consideração a gramática já existente da DSL e o modelo semântico já definido.Isso foi feito para que estes rascunhos servissem como guias para a implementaçãoda versão inicial que oferece suporte ao teste do tipo de aplicação correspondente.O único critério para escolha das aplicações foi que não exigissem testes complexos.As escolhidas foram:

• Webservice dos Correios (SOAP) 1. O teste aciona o método que calcula o prazode envio de encomendas, e pode ser visto no Apêndice D.

• Webservice jsontest.com (REST) 2. Trata-se de uma aplicação usada paraverificar a validade de expressões JSON, sendo justamente esta a funcionalidadetratada. O teste pode ser visto no Apêndice E.

• Site de notícias G1 (Web) 3. O teste dessa aplicação consiste em acessar apágina inicial e então fazer uma busca pela palavra “teste”. O Apêndice Fmostra esse teste.

Também faz parte dessa etapa o desenvolvimento da parte da aplicação responsávelpela geração desses projetos no JMeter e Silk Performer. Esta etapa é importantepor permitir que um suporte básico a cada tipo de aplicação esteja disponível paradiminuir o esforço ao implementar o suporte à aplicações mais complexas.

2. Implementação do teste escolhido na Dataprev e ajustes. Após o desenvol-vimento de elementos básicos do tipo de aplicação escolhido, foi a vez de transcreverpara a DSL testes já existentes em Silk Performer de uma aplicação da Dataprevdaquele tipo. A criação de testes a partir de testes já existentes traz algumasvantagens:

• Principalmente no início, são identificadas novas funcionalidades, novos termospara a gramática e novas entidades para o modelo semântico. Por exemplo, umdos testes implementados exige autenticação usando HTTP Basic4;

1 Disponível em <http://ws.correios.com.br/calculador/CalcPrecoPrazo.asmx>2 <http://www.jsontest.com/>3 Portal de notícias: <http://g1.globo.com>4 Tipo de autenticação em que o usuário e a senha são enviados no cabeçalho da requisição

http://ws.correios.com.br/calculador/CalcPrecoPrazo.asmx

http://www.jsontest.com/

http://g1.globo.com


• É possível comparar o resultado da geração com o teste original. Esse tipo deverificação tem sua importância ao avaliar a possibilidade de utilizar a DSLpara substituir testes já existentes, ou verificar a compatibilidade dos testesgerados e de sua estrutura, por exemplo.

As seguintes aplicações foram escolhidas:

• Secal (SOAP). Secal é um serviço da RFB5 que serve para cálculo de acréscimoslegais, que são usados para calcular valores de juros; seu teste pode ser visto noAnexo A. Já o teste na DSL está no Apêndice G.

• Cadprevic (REST) Cadprevic REST é um serviço que provê acesso às infor-mações referentes às entidades e planos de previdência complementar. O testeselecionado está disponível no Anexo C. O teste na DSL está no Apêndice H.

• Cadprevic (Web). O Cadprevic web permite o gerenciamento das informaçõesde entidades e planos de previdência complementar. O teste escolhido estádisponível no Anexo D, enquanto o teste implementado com a DSL está noApêndice I.

Um resumo das aplicações utilizadas durante os procedimentos pode ser visto naTabela 7.

Tabela 7 – Aplicações selecionadas por tipo de teste.

Tipo de teste Aplicação (Dataprev) Aplicação (Externa)SOAP Secal Webservice CorreiosREST Cadprevic jsontest.comAplicações web Cadprevic G1

3. Geração e execução dos testes. Através da geração e execução do teste é quepode-se descobrir se o que foi gerado corresponde: a) ao que foi especificado na DSL,e; b) ao projeto em que foi baseado (no caso dos testes de aplicações da Dataprev).A sua execução foi necessária para identificar eventuais problemas de integração commassa de dados, comunicação com os sistemas, etc. Com os resultados dessa etapa(principalmente os erros) foi possível fazer correções na ferramenta para o projetogerado ser considerado funcional.

4. Avaliação. Com base nos artefatos de software desenvolvidos (projetos dsl_base,dsl_jmeter e dsl_silk_performer) e nos testes já existentes, criados e gerados foramlevantadas informações que serviram de insumo para a discussão sobre cada etapa esobre as questões de pesquisa. Essa discussão é feita na seção 4.2. Apesar de listadapor último, em vários momentos a avaliação foi feita durante outras etapas.

5 Receita Federal do Brasil: <http://idg.receita.fazenda.gov.br/>

http://idg.receita.fazenda.gov.br/


4.2 ResultadosEsta seção traz uma discussão sobre os resultados obtidos através da avaliação,

considerando as questões de pesquisa levantadas na subseção 4.1.1.

Q1: É possível descrever testes de performance para diferentes tipos de aplica-ções com a DSL proposta?

As etapas 1 e 2 descritas na subseção 4.1.2 mostram que a DSL pode ser usada ouadaptada para representar testes dos tipos de aplicações propostos no trabalho (SOAP,REST e Web). Durante essas etapas a ferramenta foi adaptada aos novos requisitos efuncionalidades inerentes a cada tipo:

• Requisições e asserções de respostas SOAP. Testes de requisições SOAP con-sistem em requisições HTTP, normalmente POST6 para o endpoint do serviço. Algunsde seus diferenciais são:

– A possibilidade de utilização de templates para preencher o conteúdo dasrequisições. Com isso, basta substituir no template o que varia em cada iteraçãodo teste. Tal característica foi representada como o Código 8 mostra;

Código 8 – Requisição para serviço SOAP utilizando template e substituindovalores

test_case ’ c on su l t a r vencimento ’ dosoap_request template : TEMPLATE_CONSULTA,

dataset : MASSA_CONSULTAR_VENCIMENTO,r ep l a c e : {

’ { competencia } ’ => from_dataset ( : competencia)

}

– Suas asserções podem verificar o conteúdo da resposta em texto plano, ouconsiderando seu cabeçalho e corpo, como pode ser visto no Código 9.

Código 9 – Asserções de resposta de requisição SOAPassert_that soap_response . not . c onta in s ? ’ ns2 : e r r o ’

assert_that soap_response . header6 Teoricamente é possível fazer requisições SOAP usando o método GET, mas sua complexidade

faz com que praticamente todas as implementações ofereçam suporte apenas a métodos POST.Discussões mais aprofundadas podem ser vistas em <http://stackoverflow.com/a/26339467> e <http://stackoverflow.com/questions/4646146/http-soap-get-post>.

http://stackoverflow.com/a/26339467

http://stackoverflow.com/questions/4646146/http-soap-get-post

http://stackoverflow.com/questions/4646146/http-soap-get-post


. node (COMPETENCIA)

. equals_to ? expected : from_dataset ( : competencia )

assert_that soap_response . body. node (VENCIMENTO_COMPETENCIA). equals_to ? expected : from_dataset ( :

vencimento_competencia )

• Requisições e asserções de respostas REST. Requisições REST seguem umpadrão diferente das requisições SOAP. Não é necessário utilizar templates, pois osdados podem ser representados como hashes; em outros casos não é necessário enviarparâmetros, como em requisições GET. A diferença na forma como as asserções derespostas REST são feitas (como a ausência de namespaces e a comparação diretade strings com a resposta) justifica a necessidade da criação de um objeto especial(rest_response) para a verificação dos valores nesta versão da implementação. Umexemplo de requisição e asserção pode ser visto no Código 10

Código 10 – Requisição e asserção em serviço RESTtest_case ’ ConsultarListaEFPCs ’ do

rest_request method : : get , path : ’ e fpc ’assert_that r e s t_response . conta in s ? ’ t o t a l ’ , t imes : 2

end

• Autenticação Basic. A aplicação Cadprevic REST requer autenticação via HTTPBasic, conforme explicando no Item 2. Para isso, inicialmente foram criadas proprie-dades com os nomes basic_user e basic_password, que posteriormente passarama ser métodos específicos da linguagem, conforme mostrado no Código 11.

Código 11 – Trecho do teste da DSL configuração de autenticação Basicperformance_test ’ cadprev i c r e s t ’ do

endpoint ’ http :// l o c a l h o s t :8080/ cadprev i c / r e s t ’basic_user ’ u suar io ’basic_password ’ senha ’

• Requisições a páginas web. Foram mapeadas duas formas de requisição a páginasweb:

– Acesso direto: acontece quando o usuário acessa a página diretamente, digitandoo endereço na barra de endereços de seu navegador. Para representar estas açõesforam criados os métodos open e open_homepage (que é um atalho para abrira página inicial da aplicação); o método open pode ser visto no Código 12.


Código 12 – Trecho do teste da DSL com acesso à URLbefore_all_tests ’ Efetuar Login ’ doopen ’ l o g i n ’assert_that page . conta in s ? ’ Acesso v ia Senha ’

– Acesso via link: acontece quando o usuário acessa uma página clicando em umlink que existe na página atual. Para representar esta ação o método click_linkfoi criado; ele pode ser visto no Código 13.

Código 13 – Trecho do teste da DSL com clique em linktest_case ’ ConsultarDocumentoSucesso ’ do

think_time 2c l i c k_ l i n k ’Manter Documento ’assert_that page . conta in s ? ’Manter Documento ’

• Submissão de formulários web. Aplicações web requerem este tipo de interação,seja numa simples busca ou no preenchimento de um cadastro. No teste utilizadodo Cadprevic Web é feita uma busca por um documento, cujo valor é preenchido apartir da massa de dados disponibilizada. Para tal, foi criado o método submit_form,que pode ser visto no Código 14. Para utilizar valores de um dataset é necessáriofazer referência ao nome do mesmo, como também é mostrado no trecho de código.

Código 14 – Trecho do teste da DSL com o submit de formuláriosubmit_form name : ’ formPesquisarDocumento ’ , dataset :

DADOS_CONSULTAR_DOCUMENTO, params : {’ formPesquisarDocumento ’ : ’ form ’ ,’ numeroDocumentoPesquisa ’ : from_dataset ( : documento )

}

• Setup de testes. A aplicação Cadprevic Web requer que o usuário se autentiquepara acessar suas funcionalidades: o teste deve fazer a autenticação do usuário antesde executar o passo a passo. Para representar a especificação que foi feita no SilkPerformer para essas ações, foi criado o bloco before_all_tests. Um exemplo desua utilização pode ser visto no Código 15. Esta estrutura pode receber qualquer tipode interação possível de ser feita em blocos de casos de teste, dando a flexibilidadenecessária ao processo de configuração da execução do teste.

Código 15 – Trecho do teste da DSL em que é necessário efetuar loginbefore_all_tests ’ Efetuar Login ’ doopen ’ l o g i n ’


assert_that page . conta in s ? ’ Acesso v ia Senha ’

submit_form name : ’ Entrar ’ , dataset : DADOS_LOGIN, params: {

username : from_dataset ( : username ) ,password : ’ senha ’

}assert_that page . conta in s ? ’ Cadastro de Entidades e

Planos − CADPREVIC ’end

Conclusão

Os pontos listados acima mostram que foi possível adaptar e incluir funcionalidadesà abordagem para que diferentes tipos de aplicações sejam suportadas; tais funcionalidadessão incluídas com a API da GenMeter ou usando recursos próprios de Ruby. Além disso, anecessidade de adaptar a solução sob demanda é algo esperado e faz parte do desejado: apossibilidade de incluir novas funcionalidades à abordagem. A cada inclusão ela se tornarámais completa, alcançando cada vez mais diferentes tipos de testes, demandando cada vezmenos mudanças.

Q2: A abordagem permite que a DSL seja customizada para se adequar aosconceitos específicos de plataformas alvo de geração de código e/ou necessidadesde organizações onde seria utilizada?

Inicialmente, a estratégia adotada para esses casos é preparar a DSL para preenchero metamodelo com essas informações em todos os casos e cada gerador decide se utilizaessas informações ou as ignora. Os casos considerados foram estes:

• Encoding da aplicação. O Silk Performer requer que encodings sejam definidos noscript de teste quando é necessário tratar strings com caracteres especiais (acentua-ções, ideogramas, etc.). No teste da aplicação G1 foi necessário especificar que seuencoding é UTF-8, por conta da asserção do título, como pode ser visto no Código 16.O Código 17 mostra o resultado da geração desse trecho.

Código 16 – Trecho do teste da DSL em que é necessário definir o encodingperformance_test ’ g1 ’ do

website ’ http :// g1 . g lobo . com ’encoding ’UTF−8 ’


Código 17 – Trecho do teste do Silk Performer em que é necessário definir o encodingt r an sa c t i on In i tTestCasevarbegin

WebSetBrowser (WEB_BROWSER_MSIE10) ;WebModifyHttpHeader ( " Accept−Language " , NULL,

WEB_MODIFY_OPT_Remove) ;SetEnconding ( "UTF−8") ;

end In i tTestCase ;

A informação de encoding é tratada como um elemento propriedade da entidadeProjeto do metamodelo. Para que seu valor seja atribuído é necessário que ele sejainformado como mostrado no Código 18, através do método property. Este tipo deelemento contribui para a flexibilidade da ferramenta, e é possível atribuir valores depropriedades inicialmente não mapeados; o nome da propriedade não é definido nagramática da DSL.

Código 18 – Definição da propriedade encoding sem atalhoproperty encoding : ’UTF−8 ’

Para tornar a informação mais legível, é possível encapsular a chamada acima em ummétodo que tenha o nome apropriado para o valor que está sendo atribuído, tendocomo resultado a atribuição que pôde ser vista no Código 16. O encapsulamento éfeito através do Código 19.

Código 19 – Criação do atalho para a propriedade encodingdef encoding value

property encoding : va lueend

Para este caso, não existe a necessidade de configurar o encoding no teste do JMeter,e essa informação acaba sendo algo desnecessário para ele. Assim, optou-se pordefinir o atalho para a atribuição da propriedade encoding no projeto base e ignoraresta propriedade no projeto de geração JMeter.

• Informações extras em asserções. Algumas asserções de testes do Silk Performerda Dataprev foram definidas com a especificação da quantidade de vezes que o quese espera deve estar presente no texto verificado, como pode ser visto no Código 20.Novamente, esta é uma informação que não é necessária para o JMeter. Optou-sepor utilizar um parâmetro do método da DSL responsável por descrever a asserção,como mostrado em Código 21.


Código 20 – Trecho do teste do Silk Performer em que é necessário definir a quan-tidade de vezes que o texto deve estar presente (segundo argumento da funçãoWebVerifyData)

t r an sa c t i on ConsultarEFPCvarbegin

ThinkTime ( 2 . 0 ) ;WebVerifyData (ToEncoding ( " t o t a l " ) , 2 ,

WEB_FLAG_IGNORE_WHITE_SPACE | WEB_FLAG_EQUAL |WEB_FLAG_CASE_SENSITIVE, NULL, SEVERITY_ERROR) ;

WebPageUrl (sURLWs + " e fpc " , " ConsultarListaEFPC − Enviarr e qu i s i ç ã o de consu l ta " ) ;

end ConsultarEFPC ;

Código 21 – Trecho do teste na DSL em que é necessário definir o parâmetro daasserção

te s t_case ’ ConsultarListaEFPCs ’ dor e s t_reques t method : : get , path : ’ e fpc ’a s se r t_that re s t_response . conta in s ? ’ t o t a l ’ , t imes : 2

end

A implementação desta mudança consistiu na inclusão de um parâmetro no métodoque é utilizado para atribuir parte dos dados usados na asserção, como pode servisto no Código 22.

Código 22 – Ajuste no método de asserçãodef conta in s ? value , t imes : 1

@comparison_type = : conta in s@expected_value = value@times = timess e l f

end

Definir estruturas no projeto base e então utilizá-las ou ignorá-las é uma soluçãopossível, mas trata-se da abordagem mais simples. Uma discussão sobre outras formas detratar a situação pode ser vista na seção 6.3, no Item 3.

Conclusão

A discussão apresentada mostra que é possível customizar a DSL GenMeter para


que se adeque a variados conceitos e características de plataformas e organizações: nosdois casos apresentados, a estratégia utilizada foi disponibilizar a opção de adicionar ainformação extra na DSL e então o componente gerador de cada plataforma alvo serianecessário por decidir se deveria ou não utilizar aquela informação na geração do código.

Q3: Quão concisas são as especificações na DSL proposta em comparação comoutras representações textuais de testes existentes?

Para responder esta pergunta, foram considerados:

1. Os testes originais de aplicações da Dataprev, implementados em Silk Performer;

2. Os testes que foram criados na DSL a partir dos testes da Dataprev;

3. Testes de aplicações da Dataprev implementados na DSL do Gatling.io baseados nosanteriores. Testes em JMeter não foram considerados porque não é possível avaliara sua representação com as métricas definidas. O código do JMeter é XML e nãoé editado diretamente pelos especificadores dos testes; assim, para que esses testesfossem considerados na avaliação seria necessária uma análise diferente da utilizadaneste estudo. Uma discussão sobre este ponto pode ser vista na seção 6.1. Por contadessa particularidade, escolheu-se implementar os testes em Gatling.io por ser umaabordagem textual que também foi estudada neste trabalho (seção 5.3)

As seguintes métricas foram utilizadas:

1. Quantidade de palavras reservadas7, constantes e métodos definidos na API dalinguagem em relação ao total de palavras;

2. Quantidade de palavras reservadas, constantes e métodos definidos na API dalinguagem que não fazem referência direta ao contexto de testes em relação ao totalde palavras reservadas.

Com a definição dessas métricas considerou-se que um teste cujas informaçõespossuem boa visibilidade é aquele que é conciso e que faz uso de baixa quantidade depalavras reservadas em relação ao seu total de palavras. Para esta comparação, todosos comentários foram desconsiderados e funções com seus parâmetros são consideradaspalavras diferentes, cada parâmetro equivalendo a uma palavra apenas, mesmo que possuaespaços em branco. Além disso, símbolos isolados também devem ser considerados comopalavras:7 Palavra que não pode ser usada como identificador por já ser utilizada para uso da gramática da

linguagem.


• A expressão SetEnconding(“UTF-8”) possui duas palavras, e uma palavra reservada;

• A expressão WebVerifyData(SetEnconding(“UTF-8”)) possui três palavras, e duaspalavras reservadas;

• A expressão FunctionFromSilkPerformerAPI(“Texto com várias palavras”) pos-sui duas palavras, e uma palavra reservada (a função que faz parte da API do SilkPerformer);

• A expressão MASSA_CONSULTAR_VENCIMENTO = ’massa.csv’; possui três palavras,e nenhuma palavra reservada (pois a constante foi definida pelo usuário);

• A expressão HttpHeader(“Accept-Language”, NULL, WEB_MODIFY_OPT_Remove);possui quatro palavras e três palavras reservadas (pois WEB_MODIFY_OPT_Remove eNULL são definidas pela própria API ).

A Figura 12 mostra os totais de palavras dos testes da DSL. Os totais dos testes doSilk Performer são mostrados na Figura 13; não foram considerados os trechos referentesaos seus measure bounds (conceito apresentado na subseção 2.2.3), por ainda não seremcompletamente suportados pela GenMeter durante o estudo. A Figura 14 mostra os totaisdos testes feitos com o Gatling.io. Os dados utilizados para a geração dos gráficos podemser vistos no Apêndice B.

Figura 12 – Contagem de palavras dos testes implementados com a GenMeter

SECAL Cadprevic Web Cadprevic REST0

50

100

150

174

90

31

89

48

2014 12 6

Núm

erode

palavras

Total de palavrasTotal de palavras reservadasTotal de palavras reservadas fora do contexto


Figura 13 – Contagem de palavras dos testes implementados com o Silk Performer


100

200

300

400 388

216

86

143

7442

8642 23

Núm

erode

palavras

Total de palavrasTotal de palavras reservadasTotal de palavras reservadas fora do contexto

Figura 14 – Contagem de palavras dos testes implementados com o Gatling.io


20

40

60

80

100

120

140

73

128

6151

78

4329 29 30N

úmerode

palavras

Pode-se observar que a DSL precisa de menos palavras que o Silk Performer paradescrever os testes, em todos os casos apresentados. Em relação ao Gatling, a especificaçãodo teste da aplicação Cadprevic Web apresenta bem mais palavras que a feita com a DSL,fruto principalmente da quantidade de parâmetros adicionais necessária nas definições dosformulários e datasets para que a execução do teste funcione adequadamente. Em Gatling,não é necessário informar explicitamente os campos utilizados no arquivo de massa de


dados; a ferramenta utiliza uma engine de EL8 que permite referenciar valores de arquivosde massas de dados, como no Código 23.

Código 23 – Exemplo de utilização de EL com o Gatling; o trecho $bar será interpretadocomo o atributo de nome bar presente na sessão da ferramenta

reque s t ( " page " ) . get ( " / foo ?${bar} " ) ;

A relação entre o número total de palavras e o número de palavras reservadas podeser interpretada como o quanto cada linguagem precisa de dados informados pelo usuáriopara definir as especificações de testes, além das estruturas que ela própria fornece. ATabela 8 mostra um comparativo entre o percentual de palavras reservadas em relação aototal de palavras pra cada teste criado em cada plataforma. Considerando o significadoestabelecido pra essa relação, pode-se concluir que o Gatling possui um número maior depalavras reservadas e precisa de menos informações do especificador; em seguida encontra-se a DSL e por último o Silk Performer. É importante também ressaltar que para dois tiposde aplicações a diferença de valores entre os percentuais do Gatling e da DSL GenMeternão foram tão significativos (nos casos do Cadprevic Web e Cadprevic REST: 7,61% e5,97%, respectivamente).

Tabela 8 – Percentual de palavras reservadas em relação ao total de palavras

Aplicação GenMeter Silk Performer GatlingSECAL 51,15% 36,86% 69,86%CadprevicWeb

53,33% 34,26% 60,94%

CadprevicREST

64,52% 48,84% 70,49%

Outra informação importante que pode ser extraída desses dados é o quanto asintaxe da linguagem hospedeira e/ou estruturas que não fazem parte podem interferirna visualização das características dos testes (ou seja, quantas dessas palavras reservadasdizem ou não respeito ao contexto de testes: uma função ToEncoding não diz respeito,enquanto uma função ThinkTime diz.). A Tabela 9 mostra um comparativo entre essesdados e, a partir deste, é possível perceber que os testes especificados com a DSL possuemmenos palavras reservadas fora do contexto. Com base no que foi apresentado, uma possívelconclusão é que as informações relevantes de testes de performance especificados com aDSL são mais visíveis do que as informações presentes em testes especificados com o SilkPerformer ou Gatling.io.8 Expression Language, forma de embutir expressões de linguagens em strings <http://gatling.io/docs/

2.2.2/session/expression_el.html>.

http://gatling.io/docs/2.2.2/session/expression_el.html

http://gatling.io/docs/2.2.2/session/expression_el.html


Tabela 9 – Percentual de palavras reservadas fora do contexto em relação ao total de palavrasreservadas

Aplicação GenMeter Silk Performer GatlingSECAL 15,73% 59,44% 56,86%CadprevicWeb

25,00% 45,95% 37,18%

CadprevicREST

30,00% 54,76% 69,77%

Conclusão

Esta seção apresentou uma avaliação da concisão das especificações feitas comGenMeter, Silk Performer e Gatling. Foram escolhidos testes das três plataformas (um paracada tipo de aplicação abordado: web, REST e SOAP) , comparando-se: a) o número totalde palavras; b) o número de palavras reservadas, e; c) o número de palavras reservadasfora do contexto presentes em cada especificação de teste. Os resultados mostraram que,no geral, testes criados com a DSL GenMeter são mais concisos que aqueles desenvolvidoscom as outras linguagens consideradas, considerando as métricas desta avaliação.

Esta seção apresentou uma avaliação da concisão das especificações feitas comGenMeter, Silk Performer e Gatling. Foram escolhidos testes das três plataformas

4.3 Ameaças à Validade do EstudoAs seguintes ameaças ao estudo realizado foram identificadas:

• Número de testes considerados na avaliação: 3 testes foram considerados paracada ferramenta, cada um representando um tipo de aplicação diferente suportadopela GenMeter (web, SOAP e REST); o resultado da avaliação considera apenas estestipos de testes. Um maior número de testes e de tipos de testes traria uma avaliaçãocom valores ainda mais realistas (mas também trazendo a necessidade de novosestudos para a confirmação dos resultados). O número de tipos de testes consideradostambém limita a quantidade de funcionalidades customizadas consideradas nosestudos; a inclusão de funcionalidades também demandaria novos estudos;

• Número de organizações participantes do estudo: apenas uma organizaçãoteve testes considerados nos estudos (a Dataprev). Assim, é importante considerarque características culturais da empresa (como a forma como o código é organizado,nomes de variáveis, etc) podem estar presentes nos scripts de testes utilizados comoexemplos e impactar de alguma forma no resultado do estudo.


• Autoria de parte dos testes considerados nos estudos: os testes em JMeter,GenMeter e Gatling, também utilizados na avaliação, foram criados pelo autor destadissertação; todos foram baseados nos testes da Dataprev, criados com Silk Performer.Embora sejam implementações funcionais, o conhecimento de que os testes seriamutilizados em uma avaliação pode vir a impactar de alguma forma no resultado doestudo.

4.4 ConclusãoEste capítulo apresentou detalhes do estudo realizado para desenvolvimento e

avaliação da abordagem deste trabalho. A subseção 4.4.1 discute alguns pontos pertinenteslevantados durante o estudo.

4.4.1 Discussões e Lições Aprendidas

• Equivalência entre os testes de origem e os testes gerados. Os testes geradoscom base em testes já existentes nunca serão 100% iguais a estes; além de questõescomo nomes de variáveis e comentários, não é viável reproduzir diferentes estilos deorganização no gerador. Portanto, foi necessário basear a geração em uma propostade correspondência de conceitos da DSL e das ferramentas-alvo, descrita na seção 3.3.Mesmo que gerado de forma diferente, o resultado precisa ser capaz de reproduzircenários de testes equivalentes aos que estão definidos no original. Durante a avaliaçãoda abordagem proposta, a equivalência entre o teste original e o gerado foi verificadaem um processo que consistiu na observação e execução do projeto gerado; verificou-se se as suas ações eram válidas e correspondiam às ações do teste em que ele foibaseado.

• Geração de testes já existentes para diferentes plataformas. É importanteque haja equivalência entre testes portados a partir de outra plataforma (testesgerados para JMeter, a partir de um já existente em Silk Performer, por exemplo), semque se percam conceitos e funcionalidades. Em alguns casos a perda de informaçõesé inevitável: por exemplo, não existe no JMeter conceito similar ao de measurebound e uma futura implementação que trate este conceito deverá levar isso emconsideração; mesmo assim, a natureza do teste (passos executados, dados utilizados)não é alterada.

67

5 Trabalhos Relacionados

Este capítulo apresenta trabalhos relacionados e soluções já existentes referentes àutilização de DSLs para geração e execução de testes de performance. A Tabela 10 mostraum resumo destes trabalhos. As principais características analisadas foram: extensibili-dade (capacidade de gerar projetos para diferentes ferramentas), abordagem utilizada emecanismos usados para dar suporte à criação dos artefatos de testes.

Tabela 10 – Ferramentas e trabalhos relacionados.

Ferramenta DescriçãoRuby JMeter DSL interna em Ruby que gera testes para JMeter.BERNARDINOet al. (2014)

Trabalho que define requisitos, decisões e caracte-rísticas para a criação de uma DSL visual.

Gatling.io Framework de teste de performance open sourcebaseado em Scala.

DSLBench BUIet al. (2007)

Plugin do Visual Studio 2005 Team Suite usadopara geração de aplicações de benchmark.

Aspen SPAF-FORD e VET-TER (2012)

Abordagem para modelagem analítica de perfor-mance de arquiteturas de software e hardware.

5.1 DSL para criação de projetos JMeterRuby JMeter é uma DSL externa, feita em Ruby e que gera projetos JMeter. Ela

é uma alternativa para confecção de testes para a ferramenta flood.io. Sua abordagemconsiste em descrever os testes com a linguagem e então, através de comandos em umterminal, gerar o projeto JMeter para execução posterior ou solicitar a execução imediatautilizando a infraestrutura que a empresa mantém na nuvem. Também é possível criar oteste diretamente no site. O trecho de código 24, por exemplo, gera um plano de testecom 10 threads, cada uma visitando a página inicial do google. Isso é feito com o comandomostrado em 25, onde “testplan.rb” é o arquivo que contém o código escrito na DSL.

Código 24 – Exemplo de teste em Ruby JMetert e s t do

threads count : 10 dov i s i t name : ’ Google Search ’ , u r l : ’ http :// goog l e . com ’

endend . jmx

Capítulo 5. Trabalhos Relacionados 68

Código 25 – Comando necessário para geração do teste em JMeter$ ruby t e s tp l an . rb

Pontos positivos

• Comunidade: o projeto no github1 possui mais de 90 forks, uma base considerávelde colaboradores em potencial que podem auxiliar em novas versões e implementaçõesda ferramenta, e que já contribuiu com boa parte das funcionalidades existentes.

Pontos negativos

• Dependência entre DSL e gerador: a geração do código é feita no interpretadorda DSL, o que dificulta a capacidade de estendê-la, por tornar a solução dependenteda plataforma alvo original.

• Documentação escassa: existem poucos e resumidos documentos orientando ousuário da DSL a explorar todo seu potencial, o que foi inclusive motivo para criaçãode um issue2.

Comparação com a abordagem proposta

Ambas as abordagens são feitas em Ruby, como DSL interna, a fim de tirar proveitode sua cultura de DSLs, sintaxe limpa, etc. Apesar de ser uma ferramenta já consolidada,a forte ligação entre a camada de DSL e de geração é um dos principais motivos pelosquais não se escolheu estender esta linguagem.

5.2 Modelagem utilizando DSL VisualO trabalho de BERNARDINO et al. (2014) traz um conjunto de requisitos levanta-

dos de acordo com a expertise do grupo e relatos de engenheiros de software do laboratóriode desenvolvimento tecnológico de uma empresa global de TI parceira. Alguns dessesrequisitos estão listados abaixo:

• A DSL deve permitir a representação de características de testes de performance;

• A DSL deve ser desenvolvida com uma ferramenta de bancada de linguagem. Ajustificativa para isso foi evitar empregar esforços criando editores ou compiladores,

1 <https://github.com/flood-io/ruby-jmeter/>2 O issue fala sobre a falta de documentação da ferramenta; o usuário fala que a única forma de descobrir

se ela suportava um random order controller foi buscando no código fonte, pois isso não estavadocumentado: <https://github.com/flood-io/ruby-jmeter/issues/75>

https://github.com/flood-io/ruby-jmeter/

https://github.com/flood-io/ruby-jmeter/issues/75


como seria com uma DSL externa, ou escolhendo uma linguagem que poderia nãoser apropriada à DSL desejada, caso de uma DSL interna;

• A bancada de linguagem deve permitir que o teste de performance seja desenvolvidoatravés de uma “DSL visual” (um editor gráfico);

• A bancada de linguagem também deve oferecer suporte a uma versão textual daDSL, próxima da linguagem natural, para facilitar a adoção por parte de engenheirosde teste que estejam acostumados com esse tipo de abordagem;

• Deve ser possível exportar seus modelos para formatos de diferentes aplicações, comoHP LoadRunner, MS Visual Studio ou Apache JMeter.

O artigo também traz algumas decisões de projeto tomadas, de acordo com asnecessidades da empresa:

• Usar uma ferramenta de bancada de linguagem que ofereça suporte a DSL visuais;

• Fornecer uma linguagem visual capaz de representar o comportamento de perfis deusuários para diferentes cenários de testes de performance;

• Criar uma representação textual em uma linguagem semi-natural;

• Prover rastreio automático entre as representações gráfica e textual.

Os requisitos e decisões listados serviram como base na criação de uma DSL paramodelagem de testes de performance de aplicações web; isso faz com que o trabalho tragauma base de conhecimento que pode ser reusada em diferentes situações que compartilhemrequisitos similares aos dele. A Figura 15 mostra um exemplo de representação de umteste de performance: um cenário que representa as funcionalidades do sistema sendotestado divididas em três scripts: Browser, Shop e Order. Cada script tem um percentualde usuários virtuais que irá executá-lo. O modelo também apresenta a interação de trêsperfis de usuário: Browsing, Shopping e Ordering, que se diferem basicamente quanto àprobabilidade que cada um tem de executar cada script.

Pontos positivos

• Flexibilidade: o fato da ferramenta permitir a criação dos testes através de umaDSL visual ou textual é uma característica que pode ser relevante em diversasempresas;

• Portabilidade: o artigo prevê a funcionalidade de exportação para formatos dediversas ferramentas.


Figura 15 – Representação gráfica de um modelo de cenário de teste de performance (BER-NARDINO et al., 2014)

Pontos negativos

• Ferramenta fechada: de acordo com o artigo, a ferramenta foi desenvolvida parauma empresa parceira; assim, até onde se sabe, a mesma não foi disponibilizada parauso de outras organizações, sendo impossível adquirir a licença de uso por compra,assinatura, etc.


Apesar da abordagem prever a possibilidade de exportação para diferentes formatos,ele não prevê a possibilidade de personalização por parte de outras organizações e não cita apossibilidade de exportação para o formato de novas ferramentas após seu desenvolvimento.Afinal, ela foi idealizada para ser utilizada apenas pela empresa parceira.

5.3 Plataforma com suporte ao desenvolvimento e execução detestes com DSL própriaGatling (TOLLEDO, 2014) é uma ferramenta de testes de performance que foi

lançada em dezembro de 2011. Ela traz como premissa tratar seus testes de performancecomo se fosse parte do código da aplicação. Com sua DSL escrita em Scala é possívelescrever os cenários de testes da mesma forma que com outros frameworks de automação


de testes (como JUnit3 e TestNG4, por exemplo), como é possível ver no trecho de código26.

Código 26 – Trecho de código com a DSL da ferramenta Gatling. O teste faz chama-das ao recurso http://localhost/json durante 10 minutos e com 5 usuáriossimultâneos.

class MySimulation extends Simulat ion {

va l conf = http . baseUrl ( " http :// l o c a l h o s t " )

va l scn = s c ena r i o ( " Gat l ing " ). exec ( http ( " index " ) . get ( " / " ) ). dur ing (10 minutes ) {

exec (http ( " j son " ) . get ( " / j son " ). check ( jsonPath ( " $ . id " ) . saveAs ( " id " ) )

)}

setUp ( scn . i n j e c t ( atOnceUsers (5 ) ) ). p r o t o c o l s ( conf )

}

A ferramenta se integra com diversas ferramentas de integração contínua, comoo Jenkins5 6, permitindo o feedback constante da performance da aplicação. Também épossível rodar os testes através do Maven7 e Gradle8, utilizando plugins9 10.

Os testes podem ser gravados através de uma ferramenta que, através de um proxya ser configurado no navegador, intercepta as requisições feitas durante a solicitação eutiliza essas informações para gerar o script na DSL. O teste pode então ser refinado parapermitir o uso de massa de dados, asserções, loops, etc.3 <http://junit.org/junit4/>4 <http://testng.org/>5 <https://jenkins.io/>6 <https://github.com/excilys/gatling/wiki/Jenkins-Plugin>7 <https://maven.apache.org/>8 <http://gradle.org/>9 <https://github.com/excilys/gatling/wiki/Maven-plugin>10 <https://github.com/vincentkok/gradle-gatling>

http://junit.org/junit4/

http://testng.org/

https://jenkins.io/

https://github.com/excilys/gatling/wiki/Jenkins-Plugin

https://maven.apache.org/

http://gradle.org/

https://github.com/excilys/gatling/wiki/Maven-plugin

https://github.com/vincentkok/gradle-gatling


Pontos positivos

• Gravação de testes: a possibilidade de criar os scripts de teste através da gravaçãodas ações feitas durante uma simulação reduz o tempo de desenvolvimento dosmesmos;

• Integração com ferramentas: essa característica faz com que seja muito maisfácil executar testes de performance, tornando esta atividade (e as informações úteisque ele traz) mais presente no dia a dia dos desenvolvedores.


A abordagem da ferramenta, diferente da proposta neste trabalho, é de forneceruma plataforma completa para criação e execução de testes: ela não oferece apenas a DSLpara que os testes sejam criados. Com isso, também não existe a possibilidade de gerarcódigo para ferramentas de terceiros.

5.4 Geração de aplicações para testes de performanceO trabalho de BUI et al. (2007) apresenta o conceito de performance benchmarks

applications, aplicações de domínio específico usadas para execução de testes de perfor-mance. O desenvolvimento desse tipo de aplicação requer o mapeamento dos conceitosde domínio de performance, e a produção de código para tecnologias complexas e plata-formas específicas. Outro conceito apresentado é o de modelagem específica de domínio(DSM - Domain Specific Modeling): ele promete ser a ponte entre domínios de aplicação esuas implementações, permitindo que os designers especifiquem soluções em abstrações esemânticas específicas de domínio através de DSLs.

Com base nisso, o trabalho propõe uma abordagem baseada em DSM para criaruma DSL, chamada de DSLBench, para geração destas aplicações de benchmark. Elapermite o desenho e geração de uma aplicação para execução dos testes a partir de modelosde alto nível. A linguagem DSLBench é implementada usando o toolkit Microsoft DomainSpecific Language e é utilizada como um plugin do Visual Studio 2005 Team Suite, queprovê capacidades extras de modelagem para testes de performance. Em síntese, alguns deseus propósitos apresentados no artigo são:

• Prover uma nova linguagem visual para geração de benchmark;

• Automatizar tarefas repetitivas e propensas a erros;

• Permitir a configuração do teste em alto nível;

• Prover recursos para modelagem de dados de casos de teste.


A execução dos testes gerados pelo DSLBench é feito através do Visual Studio11; aferramenta gera arquivos XML compatíveis e, além disso, é possível manter código e modelosincronizados, bidirecionalmente. Mudanças feitas no modelo refletirão na configuração doVisual Studio, e vice-versa. A Figura 16 traz a representação do modelo de domínio daDSL.

Figura 16 – Modelo de domínio da DSLBench

A DSL também é utilizada por outra abordagem de ZHU et al. (2007) que apresentao Revel8tor, uma suíte para planejamento de capacidade para aplicações baseadas emcomponentes. Além dela, outras duas ferramentas compõem a solução:

• MDAPerf - que serve para, através de anotações em diagramas de caso de uso, desequência e implantação, gerar arquivos XMI (XML Metadata Interchange), quecapturam valores e semânticas do que foi anotado nos diagramas e então gerar ummodelo de análise de performance da aplicação. Este componente é um plugin doEclipse;

• MDABench - que gera implantáveis para benchmark de aplicações a partir deanotações nos seus diagramas de classes.

Pontos positivos

• Representação de modelos de alto nível: a representação de modelos e diagra-mas que a linguagem possui ajuda no desenvolvimento dos testes.

11 <https://msdn.microsoft.com/en-us/library/dd293540(v=vs.110).aspx>

https://msdn.microsoft.com/en-us/library/dd293540(v=vs.110).aspx


Pontos negativos

• Falta de suporte a geração para outras plataformas: no artigo é dito que aferramenta, na data da publicação deste, possui apenas um gerador de código C#.


Apesar de ter proposta similar, DSLBench é uma DSL visual, enquanto a propostaaqui é uma DSL textual. A abordagem proposta por BUI et al. (2007) é integrada àsuite de desenvolvimento da Microsoft, enquanto a proposta neste trabalho não possuiintegração com suítes de desenvolvimento e/ou IDEs. A abordagem também difere daproposta neste trabalho ao se basear nos modelos e metadados das aplicações que serãotestadas.

5.5 Modelagem analítica de performanceO trabalho de SPAFFORD e VETTER (2012) apresenta uma abordagem para

modelagem analítica de performance usando a DSL Aspen (Abstract Scalable PerformanceEngineering Notation). A linguagem vem para preencher uma lacuna nas técnicas demodelagem de performance existentes e foi desenhada para permitir a exploração rápida denovas arquiteturas de software e hardware, e de algoritmos que as utilizam. Basicamente,ela serve de input para diversas ferramentas de análise apresentadas no trabalho e permiteque seus usuários identifiquem tradeoffs de aplicações e arquiteturas.


Apesar desta abordagem utilizar uma técnica similar (o uso de uma DSL pararepresentar conceitos de performance) para endereçar problemas referentes à performance,o foco do trabalho é completamente diferente do proposto neste documento; trata-se daanálise de performance de artefatos num nível mais baixo.

5.6 Sumário dos Trabalhos RelacionadosA Tabela 11 mostra um comparativo das características das abordagens vistas

neste capítulo.


Tabela 11 – Sumário dos Trabalhos Relacionados.

Ferramenta Tipo Possui plataformaprópria para execu-ção dos testes?

Suporta geraçãopara outras ferra-mentas?

Ruby JMeter Textual Sim NãoBERNARDINOet al. (2014)

Visual/Textual Não Sim

Gatling.io Textual Sim NãoDSLBench BUIet al. (2007)

Visual Não Não

Aspen SPAF-FORD e VET-TER (2012)

Textual - -

76

6 Conclusão

Este trabalho apresentou uma abordagem para especificar e gerar testes de perfor-mance através do uso de uma DSL interna em Ruby e de diferentes projetos especializados,sendo cada um responsável por gerar projetos para uma plataforma alvo. Através dadefinição de um modelo capaz de abstrair conceitos de diferentes plataformas, e uma DSLque reflete tal modelo, esta abordagem tenta simplificar a criação de testes de performance,permitindo que um único script possa ser utilizado para gerar projetos em diferentesplataformas. Os resultados obtidos na avaliação da solução indicam que seu uso é factível,como pode ser visto na seção 6.2.

6.1 Limitações do TrabalhoEsta seção discute sobre as limitações deste trabalho.

• Aprofundamento nas características específicas das plataformas e orga-nizações. Este trabalho levou em consideração características de uma empresa(Dataprev) e de três ferramentas (JMeter, Silk Performer e Loadrunner; apesar denão gerar testes para o Loadrunner). O resultado pode ser enriquecido caso novasempresas e ferramentas sejam consideradas em estudos futuros, conforme sugeridona seção 6.3.

• Avaliação de legibilidade e inclusão do JMeter na avaliação de concisão daDSL. Este trabalho apresentou uma avaliação sobre a solução proposta considerandoa questão do quão concisos os testes especificados na DSL são em relação a outrasferramentas. Uma característica ligada a esta que não avaliada é a legibilidade: apesarde estar de certa forma relacionada à concisão (considerando que o pouco que éescrito é o suficiente para transmitir a informação), não foram feitos experimentoscom desenvolvedores para reunir suas percepções e assim definir se a DSL é ounão mais legível que alternativas. Da mesma forma, a comparação da ferramentaJMeter com as outras deveria ser avaliada através de experimentos, por conta de suanatureza (não seria interessante comparar o número de palavras de uma linguagemdeclarativa com um arquivo XML).

6.2 Contribuições da PesquisaAs principais contribuições do estudo realizado nessa dissertação são listadas a

seguir.

Capítulo 6. Conclusão 77

• Definição de modelo e DSL para especificação de testes de performance.Este trabalho propôs, com base em conceitos da área e de ferramentas de teste deperformance, um modelo que é utilizado para representar estes testes, e uma DSLtextual que preenche este modelo. Ambos foram idealizados para serem configuráveis,permitindo, se necessário, a especialização para uso com ferramentas e cenáriosespecíficos.

• Ferramentas para geração de código. Tendo como base o modelo desenhadoinicialmente, foram implementadas duas ferramentas para gerar projetos a partirda especificação de testes na DSL para as aplicações Silk Performer e JMeter. Elasficam disponíveis para o usuário na forma de um executável disponível em linha decomando, sendo necessário informar o arquivo onde o teste foi implementado comoparâmetro.

• Estudo de caso. Foi realizado um estudo para avaliação da abordagem proposta,que trouxe como resultado o exposto abaixo:

– A discussão no resultado da questão 1 mostra que é possível adaptar a ferramentapara que represente diferentes tipos de aplicações;

– O resultado da questão 2 traz casos em que foi necessário adaptar a ferramenta acaracterísticas específicas de uma das plataformas-alvo, mostrando que tambémé possível representar testes especificados a serem gerados em diferentes ferra-mentas. Esta funcionalidade torna mais fácil eventuais trabalhos de migraçãode plataforma (fazendo com que isso seja possível através de adaptações dosmétodos específicos da ferramenta de origem para a de destino).

– O resultado da questão 3 traz uma discussão sobre o quão concisa é a DSLem relação às formas que outras ferramentas representam textualmente o teste.Algumas das conclusões tiradas é que é: a) os testes com a DSL precisam demenos palavras para serem descritos, e; b) a DSL precisa de poucas palavrasreservadas fora do contexto de testes de performance para que eles sejamdescritos. Com isso, pode-se afirmar que os desenvolvedores dos testes podemfocar nos conceitos dos testes de fato, ao invés dos conceitos das ferramentasque são utilizadas para sua execução.

Além disso, o estudo foi essencial para o desenvolvimento da ferramenta, pois atravésdele foi possível aprimorá-la constantemente, através de ajustes na gramática, paraque novos conceitos fossem agregados, e de correções na geração dos projetos.


6.3 Trabalhos FuturosEsta seção apresenta alguns trabalhos futuros, identificados durante o desenvolvi-

mento da aplicação, pesquisa e escrita da dissertação como possíveis extensões.

1. Uso em novas empresas e organizações. Inicialmente avaliado apenas comtestes da Dataprev, a solução pode ser aplicada em novas empresas, permitindoo amadurecimento de seu metamodelo e natural suporte a novas ferramentas eabstrações.

2. Aprimoramento da geração de testes de aplicações web para JMeter. Oatual suporte a testes de aplicações web para JMeter pode ser expandido para queseja possível a geração de projetos para sites construídos com a tecnologia JSF1.

3. Estratégia para permitir que instruções da DSL específicas de uma fer-ramenta não causem erro ao serem interpretadas pelo gerador de outra.Atualmente, se uma instrução da DSL não for encontrada dentre as existentes umerro é lançado, o que significa que um teste com características exclusivas escritopara plataforma X deve ser corrigido para que possa ser gerado um equivalentena nova plataforma alvo. Apesar de inicialmente este comportamento ser essencialpara chamar atenção para novas funcionalidades que devem ser implementadas, estepode não ser o comportamento padrão ideal no futuro. Assim, é interessante estudarformas de tratar estes problemas sem que a geração do teste seja cancelada; o usode avisos sem interromper o processamento é uma alternativa.

4. Suporte a novas ferramentas e novos tipos de aplicações. O suporte a novasplataformas e tipos de testes é uma evolução natural e desejada, que tem o potencialde aumentar o número de usuários da ferramenta e de desenvolvedores colaborandopara adaptá-la às suas necessidades. A abordagem inicialmente gera projetos paraas plataformas JMeter e Silk Performer. Alguns exemplos de novas ferramentas aserem suportadas são HP Loadrunner e SoapUI2. Já os tipos de testes inicialmentesuportados são aplicações web, serviços REST e SOAP; alguns dos diversos tiposde testes que podem vir a ser suportados são: servidores de email, FTP3, LDAP4,JMS5 e EJB6.

5. Documentação da ferramenta. A ferramenta carece de documentação, que atual-mente estão presentes apenas no formato de comentários no código e de especificações

1 Java Server Faces2 <https://www.soapui.org/>3 File Transfer Protocol4 Lightweight Directory Access Protocol5 Java Message Service6 Enterprise JavaBeans

https://www.soapui.org/


de testes usadas como base para seu desenvolvimento. Assim, é necessário que se criedocumentação adequada para ela, para auxiliar o ingresso de novos colaboradores eo esforço no suporte à novas plataformas e tipos de testes.

6. Funcionalidade de engenharia reversa. A migração manual de testes de pla-taformas X para Y é uma tarefa que exige muito esforço manual e é propensa aerros. Para solucionar estes problemas seria interessante fazer com que a ferramentapudesse, a partir do projeto de uma ferramenta suportada, gerar automaticamentesua versão equivalente na DSL.

7. Criação de testes através da gravação de simulações. Diversas ferramentas deteste de performance disponibilizam interfaces7 8 9 pelas quais é possível interceptarrequisições feitas em um navegador web para que seja possível gerar seus scriptsde testes a partir dos dados coletados. A inclusão desta funcionalidade permitiria acriação de testes mais rapidamente, e sem que seja necessário profundo conhecimentoda DSL e linguagem em que ela foi implementada.

8. Introduzir conceitos de testes de desempenho, stress e carga na DSL.Definir as diferenças entre esses tipos de teste e preparar a DSL para que a descriçãodo teste receba os parâmetros necessários para cada caso (definir quais atributossão necessários para cada tipo, por exemplo), permitindo melhor descrição dascaracterísticas de cada.

7 <https://www.digitalocean.com/community/tutorials/how-to-use-jmeter-to-record-test-scenarios>8 <http://gatling.io/docs/2.2.2/quickstart.html#using-the-recorder>9 <http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.microfocus.silkperformer.

doc%2FSILKPERF-D81CAF02-SILKPERFORMERRECORDER-CON.html>

https://www.digitalocean.com/community/tutorials/how-to-use-jmeter-to-record-test-scenarios

http://gatling.io/docs/2.2.2/quickstart.html#using-the-recorder

http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.microfocus.silkperformer.doc%2FSILKPERF-D81CAF02-SILKPERFORMERRECORDER-CON.html

http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.microfocus.silkperformer.doc%2FSILKPERF-D81CAF02-SILKPERFORMERRECORDER-CON.html

80

Referências

ALVARES JOSE CARRERA, N. Uma abordagem para reuso e customização de scriptsde teste de performance para aplicações web. Dissertação (Mestrado) — Centro deEstudos e Sistemas Educacionais do Recife - CESAR.EDU, 2009. Citado 3 vezes naspáginas 18, 26 e 27.

BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture in Practice. PearsonEducation, 2012. (SEI Series in Software Engineering). ISBN 9780132942782. Disponívelem: <https://books.google.com.br/books?id=-II73rBDXCYC>. Citado na página 17.

BERNARDINO, M. et al. A domain-specific language for modeling performance testing.ICSEA, 2014. Citado 6 vezes nas páginas 9, 24, 67, 68, 70 e 75.

BUI, N. B. et al. Benchmark generation using domain specific modeling. In: IEEE.Software Engineering Conference, 2007. ASWEC 2007. 18th Australian. [S.l.], 2007. p.169–180. Citado 5 vezes nas páginas 20, 67, 72, 74 e 75.

CAMPOS, F. M. Teste de desempenho: Conceitos, Objetivos e Aplicação - Parte 1.2011. Online; Acesso em: 09/05/2016. Disponível em: <http://www.linhadecodigo.com.br/artigo/3256/teste-de-desempenho-conceitos-objetivos-e-aplicacao-parte-1.aspx#ixzz48AsLW1w3>. Citado na página 26.

DATAPREV. Orientação – Visão Conceitual em Testes. 2014. Online; Acesso em:19/07/2016. Disponível em: <http://desenvolvimento.dataprev.gov.br/ativos_processo/padrao_desenvolvimento_software/r_pddataprev_201404/arquivos/testes/ori_Visao_Conceitual_Testes.pdf>. Citado 2 vezes nas páginas 22 e 27.

FOWLER, M. Domain-Specific Languages. Pearson Education, 2010. (Addison-Wesley Signature Series (Fowler)). ISBN 9780131392809. Disponível em: <https://books.google.com.br/books?id=ri1muolw\_YwC>. Citado 5 vezes nas páginas 32, 33,34, 35 e 39.

ISO/IEC. Information technology – Syntactic metalanguage – Extended BNF. 1996.Online; Acesso em: 24/07/2016. Disponível em: <http://www.dataip.co.uk/Reference/iso-14977.pdf>. Citado 2 vezes nas páginas 39 e 87.

JOBS, M. F. Classificação dos testes de software. 2010. Online; Acesso em:27/09/2015. Disponível em: <http://vivenciandoti.blogspot.com.br/2010/09/classificacao-dos-testes-de-software.html.html>. Citado 2 vezes nas páginas 18 e 26.

MEIER, J. D. et al. Performance testing guidance for web applications. MicrosoftCorporation, 2007. Online; Acesso em: 11/05/2016. Disponível em: <https://msdn.microsoft.com/en-us/library/bb924375.aspx>. Citado 2 vezes nas páginas 18e 26.

MENASCÉ, D.; ALMEIDA, V. Scaling for E-business: Technologies, Models, Performance,and Capacity Planning. Prentice Hall PTR, 2000. ISBN 9780130863287. Disponível em:<https://books.google.com.br/books?id=eRQxsN6rFE0C>. Citado na página 18.

https://books.google.com.br/books?id=-II73rBDXCYC

http://www.linhadecodigo.com.br/artigo/3256/teste-de-desempenho-conceitos-objetivos-e-aplicacao-parte-1.aspx#ixzz48AsLW1w3



http://desenvolvimento.dataprev.gov.br/ativos_processo/padrao_desenvolvimento_software/r_pddataprev_201404/arquivos/testes/ori_Visao_Conceitual_Testes.pdf



https://books.google.com.br/books?id=ri1muolw\_YwC

https://books.google.com.br/books?id=ri1muolw\_YwC

http://www.dataip.co.uk/Reference/iso-14977.pdf

http://www.dataip.co.uk/Reference/iso-14977.pdf

http://vivenciandoti.blogspot.com.br/2010/09/classificacao-dos-testes-de-software.html.html

http://vivenciandoti.blogspot.com.br/2010/09/classificacao-dos-testes-de-software.html.html



https://books.google.com.br/books?id=eRQxsN6rFE0C

Referências 81

MENASCE, D. A. Load testing of web sites. IEEE Internet Computing, v. 6, n. 4, p.70–74, Jul 2002. ISSN 1089-7801. Citado na página 18.

MYERS, G. et al. The Art of Software Testing. Wiley, 2004. (Business DataProcessing: A Wiley Series). ISBN 9780471678359. Disponível em: <https://books.google.ro/books?id=86rz6UExDEEC>. Citado na página 17.

NGUYEN, H.; JOHNSON, B.; HACKETT, M. Testing Applications on the Web: TestPlanning for Mobile and Internet-Based Systems. Wiley, 2003. ISBN 9780471201007.Disponível em: <https://books.google.com.br/books?id=Unvn1a3lOg8C>. Citado napágina 17.

SANTOS, I. d. S.; NETO, P. d. A. d. S.; RESENDE, R. S. F. Geração de testes dedesempenho e estresse a partir de testes funcionais. Revista de Informática Teórica eAplicada, v. 17, n. 2, 2010. Disponível em: <http://seer.ufrgs.br/index.php/rita/issue/view/rita_v17_n2>. Citado na página 18.

SAVOIA, A. The science of web-site load testing. Keynote Systems, 2000. Citado napágina 26.

SPAFFORD, K. L.; VETTER, J. S. Aspen: a domain specific language for performancemodeling. In: SC12: ACM/IEEE International Conference for High PerformanceComputing, Networking, Storage, and Analysis. [S.l.: s.n.], 2012. Citado 3 vezes naspáginas 67, 74 e 75.

STARK, M. Functional vs. Non-Functional Testing: What’s the Difference?2014. Online; Acesso em: 21/07/2016. Disponível em: <http://www.ibeta.com/functional-vs-non-functional-testing-whats-difference/>. Citado na página 17.

TOLLEDO, R. Gatling: Take Your Performance Tests to the next Level. 2014. Online;Acesso em: 17/04/2016. Disponível em: <https://www.thoughtworks.com/insights/blog/gatling-take-your-performance-tests-next-level>. Citado na página 70.

ZHU, L. et al. Revel8or: Model driven capacity planning tool suite. In: IEEE. 29thInternational Conference on Software Engineering (ICSE’07). [S.l.], 2007. p. 797–800.Citado 2 vezes nas páginas 20 e 73.

https://books.google.ro/books?id=86rz6UExDEEC

https://books.google.ro/books?id=86rz6UExDEEC

https://books.google.com.br/books?id=Unvn1a3lOg8C

http://seer.ufrgs.br/index.php/rita/issue/view/rita_v17_n2

http://seer.ufrgs.br/index.php/rita/issue/view/rita_v17_n2

http://www.ibeta.com/functional-vs-non-functional-testing-whats-difference/

http://www.ibeta.com/functional-vs-non-functional-testing-whats-difference/

https://www.thoughtworks.com/insights/blog/gatling-take-your-performance-tests-next-level

https://www.thoughtworks.com/insights/blog/gatling-take-your-performance-tests-next-level

Apêndices

83

APÊNDICE A – Exemplo de teste deperformance com a DSL

Código 27 – Exemplo de teste gerado a partir de especificação com a DSL (Silk Performer)//−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−// Sc r i p t generated on 24/07/2016 17 :27// Generated by Ds lS i lkPer fo rmer 0 . 0 . 2//−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

benchmark g1

use " Kernel . bdh "use "WebAPI . bdh "

dclparam

endpoint : s t r i n g ;

d c l u s e ruser

JavaUser

t r an s a c t i on sIn i tTestCase : begin ;Scenar ioBuscaSimples : 1 ;EndTestCase : end ;

var

dc l func// ==============// Casos de t e s t e// ==============

// Casos de t e s t e do c ená r i o " busca s imple s "

APÊNDICE A. Exemplo de teste de performance com a DSL 84

// Função do caso de t e s t e " buscar por t e s t e "function BuscarPorTestevarbegin

// AsserçõesWebVerifyHtmlTitle ( ToEncoding ( "G1 − O por t a l de n o t í c i a s da

Globo " ) ) ;WebPageUrl ( " http :// g1 . g lobo . com/" ) ;

// AsserçõesWebVerifyHtmlTitle ( ToEncoding ( " Resultado da busca por t e s t e |

G1" ) ) ;WebFormGet ( " http :// g1 . g lobo . com/busca " , FORM_2) ;

end BuscarPorTeste ;

d c l t r an s

t r an sa c t i on In i tTestCasevarbegin

SetEncoding ( "UTF−8") ;end In i tTestCase ;

t r an sa c t i on EndTestCasebeginend EndTestCase ;

// −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−// Transação Scenar ioBuscaSimples// −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−t r an sa c t i on Scenar ioBuscaSimplesvarbegin

BuscarPorTeste ( ) ;end Scenar ioBuscaSimples ;

// ===========// Formulár ios

APÊNDICE A. Exemplo de teste de performance com a DSL 85

// ===========

dcl formFORM_2:

" q " := " t e s t e " ;

86

APÊNDICE B – Contagem de palavras dostestes

Tabela 12 – Contagem de palavras dos testes implementados com a DSL

Aplicação Total Total Reservadas Total ReservadasFora do Contexto

SECAL 174 89 14CadprevicWeb

90 48 12

CadprevicREST

31 20 6

Tabela 13 – Contagem de palavras dos testes implementados com o Silk Performer



216 74 34

CadprevicREST

86 42 23

Tabela 14 – Contagem de palavras dos testes implementados com o Gatling



128 78 29

CadprevicREST

61 43 30

87

APÊNDICE C – Gramática da DSL

A gramática da DSL foi definida utilizando a notação EBNF (ISO/IEC, 1996).

Código 28 – Gramática da DSL(∗ Pro j ec t ∗)p r o j e c t = ’ pro j e c t ’ , p r o j e c t name , ’ do ’ ,

{ datase t } ,{ property } ,s cenar i o ,{ s c ena r i o } ,

’ end ’ ;

(∗ Dataset ∗)datase t = ’ dataset ’ , da tase t name , ’ do ’ ,

datase t f i e l d ,{ datase t f i e l d } ,

’ end ’ ;

(∗ Property ∗)property = ’ property ’ | ’ endpoint ’ | ’ website ’ | ’ app l i c a t i on ’ |

’ bas ic_user ’ | ’ basic_password ’ , property value , new l i n e ;

(∗ Scenar io ∗)s c ena r i o = ’ scenar i o ’ , s c ena r i o name , ’ do ’ ,

[ loop ] ,[ t imeout ] ,[ b e f o r e a l l t e s t s ] ,t e s t case ,{ t e s t case }

’ end ’ ;

(∗ Block be f o r e a l l t e s t s ∗)be f o r e a l l t e s t s = ’ be fo r e_a l l_te s t s ’ , b e f o r e a l l t e s t s

d e s c r i p t i on , ’ do ’ ,t e s t statement ,{ t e s t statement } ,

’ end ’ ;

APÊNDICE C. Gramática da DSL 88

(∗ Test Case ∗)t e s t case = ’ test_case ’ , t e s t case name , ’ do ’ ,

t e s t statement ,{ t e s t statement }

’ end ’ ;

t e s t statement = [ th ink time ] , [ t imeout ] , [ open homepage ] , [ open] , soap reque s t | r e s t r eque s t | web request , { a s s e r t i o n } ;

web reque s t = ’ submit_form ’ , ( form ac t i on | form name) , [ ’ , ’ ,da ta se t r e f e r e n c e ] , { ’ , ’ , form opt ion } , ’ , ’ , parameters ;

soap reque s t = ’ soap_request ’ [ soap method , ’ , ’ ] , soap template ,[ ’ , ’ , da ta se t r e f e r e n c e ] , ’ , ’ , r ep lacements ;

r e s t r eque s t = ’ res t_request ’ , r e s t method , ’ , ’ , r e s t data ;

rep lacements = ’ r ep l a c e : { ’ ,parameter ,{ ’ , ’ , parameter } ,’ } ’ ;

parameters = ’ params : { ’ ,parameter ,{ ’ , ’ , parameter } ,

’ } ’ ;

a s s e r t i o n = ’ assert_that ’ ( ’ rest_response ’ | ’ t i t l e ’ | soapa s s e r t i o n ) , [ ’ . not ’ ] , ( ’ . equa l s ? ’ | ’ . c onta in s ? ’ ) , a s s e r t i o nexpected value ;

Código 29 – Tokens definidos para a gramáticas t r i n g = l e t t e r , { l e t t e r | decimal d i g i t } ;s t r i n g without space = s t r i n g − space cha rac t e r ;quoted s t r i n g = " ’ " , l e t t e r , { l e t t e r | decimal d i g i t } , " ’ " ;i n t e g e r = decimal d i g i t , { decimal d i g i t } ;decimal = in tege r , [ ’ . ’ , i n t e g e r ]


p r o j e c t name = quoted s t r i n g ;

datase t f i e l d = ’ f i e l d ’ , datase t f i e l d name , ’ : ’ , da ta se t f i e l dva lue ;

datase t name = quoted s t r i n g ;

datase t f i e l d name = s t r i n g without space ;datase t f i e l d va lue = in t e g e r ;

property value = quoted s t r i n g ;

s c ena r i o name = quoted s t r i n g ;loop = ’ loop ’ , i n t e g e r ;t imeout = ’ timeout ’ , i n t e g e r ;

b e f o r e a l l t e s t s d e s c r i p t i o n = quoted s t r i n g ;

t e s t case name = quoted s t r i n g ;

th ink time = ’ think_time ’ , decimal ;t imeout = ’ timeout ’ , dec imal ;open homepage = ’ open_homepage ’ ;open = ’ open ’ , quoted s t r i n g ;

form ac t i on = ’ ac t i on : ’ , quoted s t r i n g ;form name = ’name : ’ , quoted s t r i n g ;

soap method = ’method : ’ , quoted s t r i n g ;soap template = ’ template : ’ , quoted s t r i n g ;

r e s t method = ’method : ’ , ( ’ : get ’ | ’ : post ’ ) ;r e s t data = ’ data : ’ , ’{ j son : ’ , j s on value , ’ } ’ ;j s on value = ? va l i d j son data in ruby syntax ? ;

parameter = parameter name , ’ : ’ , parameter va lue ;parameter name = s t r i n g without space ;parameter va lue = quoted s t r i n g ;

datase t r e f e r e n c e = ’ datase t : ’ , quoted s t r i n g ;


soap a s s e r t i o n = ’ soap_response ’ , [ soap element ] ;soap element = ’ . body ’ | ’ . header ’ , [ ’ . node ’ ] ;a s s e r t i o n expected value = quoted s t r i n g ;

91

APÊNDICE D – Webservice Correios(SOAP) - Teste com a DSL

Código 30 – Teste do webservice dos correiosENTREGA_DOMICILIAR = ’ CalcPrazoResponse /CalcPrazoResult / Se rv i c o s

/ cSe rv i co /EntregaDomic i l i a r ’ENTREGA_AOS_SABADOS = ’ CalcPrazoResponse /CalcPrazoResult /

Se rv i c o s / cSe rv i co /EntregaSabado ’

per formance_test ’ c o r r e i o s ’ doendpoint ’ http ://ws . c o r r e i o s . com . br/ ca l cu l ado r /CalcPrecoPrazo .

asmx ’action_namespace ’ http :// tempuri . org ’

datase t ’ ceps . csv ’ dof i e l d origem : 1f i e l d de s t ino : 2

end

s c ena r i o ’ Consulta SEDEX’ dot imeout 2050loop 1

tes t_case ’ Calcu lo prazo SEDEX’ dosoap_request method : ’ CalcPrazo ’ ,

template : ’ Requis icaoPrazoSedex . xml ’ ,datase t : ’ ceps . csv ’ ,r ep l a c e : {

’ {origem} ’ => from_dataset ( : origem ) ,’ { de s t ino } ’ => from_dataset ( : d e s t i no ) ,

}

as se r t_that soap_response . body . node (ENTREGA_DOMICILIAR) .equals_to ? expected : ’S ’

a s se r t_that soap_response . body . node (ENTREGA_AOS_SABADOS) .equals_to ? expected : ’S ’

APÊNDICE D. Webservice Correios (SOAP) - Teste com a DSL 92

endend

s c ena r i o ’ Consulta PAC’ dot imeout 1500loop 1

tes t_case ’ Calcu lo prazo PAC’ dosoap_request method : ’ CalcPrazo ’ , template : ’

Requis icaoPrazoPac . xml ’a s se r t_that soap_response . body . node (ENTREGA_DOMICILIAR) .

equals_to ? expected : ’S ’a s se r t_that soap_response . body . node (ENTREGA_AOS_SABADOS) .

equals_to ? expected : ’N ’end

endend

93

APÊNDICE E – JSON Test (REST) - Testecom a DSL

Código 31 – Teste do webservice dos correiosper formance_test ’ j son_tes t ’ do

endpoint ’ http :// va l i d a t e . j s o n t e s t . com ’

s c ena r i o ’ Teste de array ’ dot imeout 2000loop 1

tes t_case ’ Array s imple s ’ dor e s t_reques t method : : get , data : { j son : [ 1 , 1 ]}as se r t_that re s t_response . conta in s ? ’ " v a l i d a t e " : t rue ’

end

te s t_case ’ Array de array ’ dor e s t_reques t method : : get , data : { j son : [ [ 2 , 2 ] , [ 3 , 3 ] ] }as se r t_that re s t_response . conta in s ? ’ " v a l i d a t e " : t rue ’

endend

s c ena r i o ’ Teste de ob j e to ’ dot imeout 2000loop 1

tes t_case ’ Objeto s imple s ’ dor e s t_reques t method : : get , data : { j son : {name : ’ foo ’ }}as se r t_that re s t_response . conta in s ? ’ " v a l i d a t e " : t rue ’

end

te s t_case ’ Objeto de array ’ dor e s t_reques t method : : get , data : { j son : {name : ’ foo ’ ,

parents : {mother : ’ bar ’ , f a t h e r : ’ abc ’ }}}asse r t_that re s t_response . conta in s ? ’ " v a l i d a t e " : t rue ’

end

APÊNDICE E. JSON Test (REST) - Teste com a DSL 94

endend

95

APÊNDICE F – G1 (Web) - Teste com aDSL

Código 32 – Teste do G1performance_test ’ g1 ’ do

webs i te ’ http :// g1 . g lobo . com ’encoding ’UTF−8 ’

s c ena r i o ’ busca s imple s ’ doloop 1

tes t_case ’ buscar por t e s t e ’ doopen_homepage

as se r t_that t i t l e . equals_to ? ’G1 − O por t a l de n o t í c i a s daGlobo ’

submit_form method : : get , a c t i on : ’ /busca ’ , params : {q : ’ t e s t e ’

}

as se r t_that t i t l e . equals_to ? ’ Resultado da busca por t e s t e| G1 ’

endend

end

96

APÊNDICE G – Secal (SOAP) - Teste coma DSL

Código 33 – Teste SecalMASSA_CONSULTAR_VENCIMENTO = ’massa_ConsultarVencimentoGPS_CSV .

csv ’MASSA_VALORAR_CREDITO = ’massa_Valorar_Credito_CSV . csv ’TEMPLATE_CONSULTA = ’msg_template_consultarVencimentoGPS . txt ’TEMPLATE_CREDITO = ’ msg_template_valorarCredito . txt ’COMPETENCIA = ’ params/ entrada / competencia ’VENCIMENTO_COMPETENCIA = ’ consultarVencimentoGPSResponse/

r e su l t ado /vencimento−comp ’DATA_CREDITO = " params/ entrada / dataCredito "VALOR_ORIGINAL = " params/ entrada / va l o rOr i g i n a l "DATA_VALORACAO = " params/ entrada /dataValoracao "VALOR_ATUALIZADO = " va lorarCred i toResponse / r e su l t ado / valor−

a tua l i z ado "

per formance_test ’ s e c a l ’ doendpoint ’ http :// ap l i c a cao / s e c a l /SECALWS/SECALService ’

datase t MASSA_CONSULTAR_VENCIMENTO dof i e l d competencia : 3f i e l d vencimento_competencia : 4

end

datase t MASSA_VALORAR_CREDITO dof i e l d data_credito : 3f i e l d data_valoracao : 4f i e l d va l o r_o r i g i n a l : 5f i e l d va lo r_atua l i zado : 6

end

s c ena r i o ’ Consultar Vencimento GPS ’ dote s t_case ’ c on su l t a r vencimento ’ do

soap_request template : TEMPLATE_CONSULTA,

APÊNDICE G. Secal (SOAP) - Teste com a DSL 97

datase t : MASSA_CONSULTAR_VENCIMENTO,r ep l a c e : {

’ { competencia } ’ => from_dataset ( : competencia )}

as se r t_that soap_response . not . c onta in s ? ’ ns2 : e r r o ’

a s se r t_that soap_response . header. node (COMPETENCIA). equals_to ? expected : from_dataset ( : competencia )

as se r t_that soap_response . body. node (VENCIMENTO_COMPETENCIA). equals_to ? expected : from_dataset ( :

vencimento_competencia )end

end

s c ena r i o ’ Valorar Crédito ’ dote s t_case ’ va l o r a r c r é d i t o ’ do

soap_request template : TEMPLATE_CREDITO,datase t : MASSA_VALORAR_CREDITO,r ep l a c e : {

’ { dataCredito } ’ => from_dataset ( : data_credito ) ,’ { v a l o rOr i g i n a l } ’ => from_dataset ( : v a l o r_o r i g i n a l ) ,’ { dataValoracao } ’ => from_dataset ( : data_valoracao )

}

as se r t_that soap_response . not . c onta in s ? ’ ns2 : e r r o ’

a s se r t_that soap_response . header. node (DATA_CREDITO). equals_to ? expected : from_dataset ( : data_credito )

as se r t_that soap_response . header. node (VALOR_ORIGINAL). equals_to ? expected : from_dataset ( : v a l o r_o r i g i n a l )

a s se r t_that soap_response . header

APÊNDICE G. Secal (SOAP) - Teste com a DSL 98

. node (DATA_VALORACAO)

. equals_to ? expected : from_dataset ( : data_valoracao )

as se r t_that soap_response . body. node (VALOR_ATUALIZADO). equals_to ? expected : from_dataset ( : va lo r_atua l i zado )

endend

end

99

APÊNDICE H – Cadprevic (REST) - Testecom a DSL

Código 34 – Teste Cadprevic RESTperformance_test ’ cadprev i c r e s t ’ do

endpoint ’ http :// l o c a l h o s t :8080/ cadprev i c / r e s t ’bas ic_user ’ u suar io ’basic_password ’ senha ’

s c ena r i o ’ Consultar l i s t a de EFPCs ’ doloop 1

tes t_case ’ ConsultarListaEFPCs ’ dor e s t_reques t method : : get , path : ’ e fpc ’a s se r t_that re s t_response . conta in s ? ’ t o t a l ’ , t imes : 2

endend

end

100

APÊNDICE I – Cadprevic (Web) - Testecom a DSL

Código 35 – Teste Cadprevic WebDADOS_LOGIN = ’MTD_Gerid . csv ’DADOS_CONSULTAR_DOCUMENTO = ’MTD_ConsultarDocumento . csv ’

per formance_test ’ cadprev i c web ’ dowebs i te ’ http :// l o c a l h o s t :8080/ cadprev i c ’

datase t DADOS_LOGIN dof i e l d username : 0

end

datase t DADOS_CONSULTAR_DOCUMENTO dof i e l d documento : 0

end

be f o r e_a l l_ t e s t s ’ Efetuar Login ’ doopen ’ l o g i n ’a s se r t_that page . conta in s ? ’ Acesso v ia Senha ’

submit_form name : ’ Entrar ’ , da tase t : DADOS_LOGIN, params : {username : from_dataset ( : username ) ,password : ’ senha ’

}as se r t_that page . conta in s ? ’ Cadastro de Entidades e Planos −

CADPREVIC ’end

s c ena r i o ’ Consultar documento com suce s so ’ doloop 1

tes t_case ’ ConsultarDocumentoSucesso ’ dothink_time 2c l i c k_ l i n k ’Manter Documento ’

APÊNDICE I. Cadprevic (Web) - Teste com a DSL 101

asse r t_that page . conta in s ? ’Manter Documento ’

think_time 11submit_form name : ’ formPesquisarDocumento ’ , datase t :

DADOS_CONSULTAR_DOCUMENTO, params : {’ formPesquisarDocumento ’ : ’ form ’ ,’ numeroDocumentoPesquisa ’ : from_dataset ( : documento )

}as se r t_that page . conta in s ? ’ Total de 1 r e g i s t r o ( s )

encontrado ( s ) . ’end

endend

102

APÊNDICE J – Secal (SOAP) - Teste como Gatling.io

Código 36 – Teste Secalimport s c a l a . concurrent . durat ion ._

import i o . g a t l i n g . core . Predef ._import i o . g a t l i n g . http . Predef ._

class Seca l extends Simulat ion {

ob j e c t ConsultarVencimento {va l soap = exec ( http ( "SOAP Request " )

. post ( " " )

. body ( ElFileBody ( " msg_template_consultarVencimentoGPS .txt " ) ) . asXML

. check ( bodyStr ing . not ( " ns2 : e r r o " ) ,xpath ( " //∗ [ l o c a l−name ( )=’ competencia ’ ] " ) . i s ( " ${

competencia } " ) ,xpath ( " //∗ [ l o c a l−name ( )=’vencimento−comp ’ ] " ) . i s ( " ${

vencimento_competencia} " ))

)}

va l scn = s c ena r i o ( " user " ). f e ed ( csv ( "massa_ConsultarVencimentoGPS_CSV . csv " ) . random). exec ( ConsultarVencimento . soap )

setUp ( scn . i n j e c t ( atOnceUsers (1 ) ) ) . p r o t o c o l s ( http . baseURL( " http:// l o c a l h o s t / s e c a l /SECALWS/SECALService " ) )

}

103

APÊNDICE K – Cadprevic (REST) - Testecom o Gatling.io

Código 37 – Teste Cadprevic RESTimport s c a l a . concurrent . durat ion ._


class CadprevicRest extends Simulat ion {

ob j e c t ConsultarListaEFPCs {va l r e s t = exec ( http ( "REST Request " )

. get ( " / e fpc " )

. basicAuth ( " usuar io " , " senha " )

. check ( regex ( " t o t a l " ) . f i nd (1 ) . e x i s t s ))

}

va l scn = s c ena r i o ( " user " ) . exec ( ConsultarListaEFPCs . r e s t )

setUp ( scn . i n j e c t ( atOnceUsers (1 ) ) ) . p r o t o c o l s ( http . baseURL( " http:// l o c a l h o s t :8080/ cadprev i c / r e s t " ) )

}

104

APÊNDICE L – Cadprevic (Web) - Testecom o Gatling.io

Código 38 – Teste Cadprevic Web

import s c a l a . concurrent . durat ion ._


class CadprevicWeb extends Simulat ion {

va l ht tpProtoco l = http. baseURL( " http :// l o c a l h o s t " ). in fe rHtmlResources ( )

va l scn = s c ena r i o ( " CadprevicWeb " ). f e ed ( csv ( "MTD_ConsultarDocumento . csv " ) . random)

. exec ( http ( " Página de l o g i n " ). get ( " / cadspc " )

. check (regex ( " Acesso v ia Senha " ) . f i nd (0 ) . e x i s t s ,regex ( " " "<form id=" fm1 " ac t i on=" ( [ ^ " ] ∗ ) " method=" post ">"

" " ) . saveAs ( " l og in_act ion " ) ,regex ( " " "<input type=" hidden " name=" l t " va lue=" ( [ ^ " ] ∗ ) "

/>" " " ) . saveAs ( " l t " ) ) ). pause (10). exec ( http ( " Submit l o g i n " )

. post ( " ${ log in_act ion } " )

. formParam( " username " , " u suar io " )

. formParam( " password " , " senha " ). formParam( " l t " , " ${ l t } " ). formParam( " execut ion " , " e1s1 " ). formParam( " _eventId " , " submit " ). formParam( " submit " , " Entrar " )

APÊNDICE L. Cadprevic (Web) - Teste com o Gatling.io 105

. check ( regex ( " Cadastro de Entidades e Planos − CADPREVIC" ). f i nd (0 ) . e x i s t s ) )

. pause (3 )

. exec ( http ( " I r para página de documentos " ). get ( " / cadspc /pages /documento/documento .

xhtml " ). check ( regex ( "Manter Documento " ) . f i nd (0 ) . e x i s t s ) )

. pause (10)

. exec ( http ( " Buscar por documento " ). post ( " / cadspc /pages /documento/documento

. xhtml " ). formParam( " formPesquisarDocumento " , "

formPesquisarDocumento " ). formParam( " numeroDocumentoPesquisa " , " $

{NumeroDocumento} " ). check ( regex ( " Aguarde enquanto os dados são car regados ! " ) .

f i nd (0 ) . e x i s t s ) )

setUp ( scn . i n j e c t ( atOnceUsers (1 ) ) ) . p r o t o c o l s ( ht tpProtoco l)

}

Anexos

107

ANEXO A – Secal (SOAP) - Teste Original

Código 39 – Teste de performance da aplicação Secalbenchmark S i lkPer formerRecorder

use " Kernel . bdh "use "WebAPI . bdh "

dclparamven_competencia : s t r i n g ;ven_vencCompetencia : s t r i n g ;

d c l u s e ruser

VUsert r an s a c t i on s

TInit : begin ;T_ConsultarVencimentoGPS : 10 ;T_ValorarCredito : 10 ;EndTestCase : end ;

constPOSICAO_DO_NOME_DO_AMBIENTE := 1 ;POSICAO_DO_NOME_DO_SERVIDOR := 2 ;POSICAO_DO_ARQUIVO_DE_MASSA_PARA_CONSULTAR_VENCIMENTO := 3 ;POSICAO_DO_ARQUIVO_DE_MASSA_PARA_VALORAR_CREDITO := 4 ;

vars e rv ido r , msgTemplateConsultarVencimento ,

msgTemplateValorarCredito : s t r i n g ;massaConsultarVencimento , massaValorarCredito : number ;arquivoDeConf iguracao : number ;

dc l func// −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−// Função r e sponsáve l pe la d e f i n i ç ã o das métr i cas u t i l i z a d a s

no t e s t e

ANEXO A. Secal (SOAP) - Teste Original 108

// −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−function con f i gu ra rMet r i c a sbegin

MeasureSetBound ( "01 _ConsultarVencimentoGPS " ,MEASURE_PAGE_PAGETIME , 1 , 5 . 0 , SEVERITY_SUCCESS) ;

MeasureSetBound ( "01 _ConsultarVencimentoGPS " ,MEASURE_PAGE_PAGETIME , 2 , 11 . 0 , SEVERITY_SUCCESS) ;

MeasureSetBound ( "02 _ValorarCredito " , MEASURE_PAGE_PAGETIME ,1 , 5 . 0 , SEVERITY_SUCCESS) ;

MeasureSetBound ( "02 _ValorarCredito " , MEASURE_PAGE_PAGETIME ,2 , 11 . 0 , SEVERITY_SUCCESS) ;

end con f i gu ra rMet r i c a s ;

// −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−// Função r e sponsáve l por ca r r ega r os templates de r e qu i s i ç ã o// −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−function carregaTemplate ( nomeArquivo : s t r i n g ) : s t r i n gvar

hFi le1 , nS ize : number ;begin

FOpen( hFi le1 , nomeArquivo , OPT_FILE_ACCESS_READ) ;FSizeGet ( hFi le1 , nS ize ) ;FRead( hFi le1 , carregaTemplate , nS ize ) ;FClose ( hF i l e1 ) ;

end carregaTemplate ;

// −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−// Função r e sponsáve l por c on f i gu r a r qual é o ambiente

dese jado// −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−function conf igurarAmbientevar

ambienteDesejado : s t r i n g ;nomeDoArquivoDeMassa : s t r i n g ;ambiente : s t r i n g ;

begin//Recuperando o ambiente de t e s t e s dese jado para execuçãoAttr ibuteGetSt r ing ( " ambienteDesejado " , ambienteDesejado , 0 ,

true ) ;


ambiente := " " ;

//Procurando o ambiente de t e s t e s dese jado no arquivo decon f i gu ração

FileCSVLoadGlobal ( arquivoDeConfiguracao , " con f i gu racao . csv " ," , " ) ;

loopi f ambiente = ambienteDesejado then e x i t end ;FileGetNextRow ( arquivoDeConf iguracao ) ;ambiente := Fi leGetCol ( arquivoDeConfiguracao ,

POSICAO_DO_NOME_DO_AMBIENTE, STRING_COMPLETE) ;end ;

//Obtendo o nome do s e r v i d o r e nome do arquivo de massa dedados a p a r t i r do arquivo de con f i gu ração

s e r v i d o r := Fi leGetCol ( arquivoDeConfiguracao ,POSICAO_DO_NOME_DO_SERVIDOR, STRING_COMPLETE) ;

//Obtendo os nomes dos arqu ivos de massas de dados a p a r t i rdo arquivo de con f i gu ração

//Carregando o arquivo de massa de dadosnomeDoArquivoDeMassa := Fi leGetCol ( arquivoDeConfiguracao ,

POSICAO_DO_ARQUIVO_DE_MASSA_PARA_CONSULTAR_VENCIMENTO,STRING_COMPLETE) ;

FileCSVLoadGlobal ( massaConsultarVencimento ,nomeDoArquivoDeMassa , " , " ) ;

nomeDoArquivoDeMassa := Fi leGetCol ( arquivoDeConfiguracao ,POSICAO_DO_ARQUIVO_DE_MASSA_PARA_VALORAR_CREDITO,STRING_COMPLETE) ;

FileCSVLoadGlobal ( massaValorarCredito , nomeDoArquivoDeMassa ," , " ) ;

end conf igurarAmbiente ;

/∗I n i c i a l i z a r a execução do t e s t e

∗/dc l t r an s


t r an sa c t i on TInitbegin

con f i gu ra rMet r i c a s ( ) ;

WebSetBrowser (WEB_BROWSER_MSIE10) ;WebModifyHttpHeader ( " Accept−Language " , NULL,

WEB_MODIFY_OPT_Remove) ;

conf igurarAmbiente ( ) ;

msgTemplateConsultarVencimento := carregaTemplate ( "msg_template_consultarVencimentoGPS . txt " ) ;

msgTemplateValorarCredito := carregaTemplate ( "msg_template_valorarCredito . txt " ) ;

end TInit ;

/∗Transação T_ConsultarVencimentoGPS , o xml enviado é baseado

em um template que f o i l i d o no TInit .∗/t r an sa c t i on T_ConsultarVencimentoGPSvar

competencia , mensagemConsultarVencimentoGPS : s t r i n g ;begin

// Lendo os parâmetros de r e qu i s i ç ã o e r e spo s ta esperada doarquivo de massa de dados

FileGetNextRow (massaConsultarVencimento ) ;ven_competencia := Fi leGetCol ( massaConsultarVencimento ,

3 , STRING_COMPLETE) ;ven_vencCompetencia := Fi leGetCol ( massaConsultarVencimento ,

4 , STRING_COMPLETE) ;

// Subst i tu indo , no template l i d o para a va r i a v e lmensagemConsultarVencimentoGPS , a s t r i n g { competencia }pe la v a r i a v e l competencia

mensagemConsultarVencimentoGPS :=msgTemplateConsultarVencimento ;

FStrReplace (mensagemConsultarVencimentoGPS , " { competencia } " ,ven_competencia ) ;


// Gerando e r ro se no xml de re to rno e x i s t i r ns2 : e r r oWebVerifyData (ToEncoding ( " ns2 : e r r o " ) , 1 , WEB_FLAG_SMALLER ,

1 , SEVERITY_ERROR) ;

// Validando se o va l o r e s dos parametros re tornados sãoi d e n t i c o s aos enviados

WebXmlVerifyNodeValue (ToEncoding ( " / soap : Envelope [ 1 ] / soap :Header [ 1 ] / ns2 : params [ 1 ] / ns2 : entrada [ 1 ] / ns1 : competencia[ 1 ] " ) , ven_competencia , 1 , WEB_FLAG_EQUAL,

ToEncoding ( " xmlns : soap=\"http ://www.w3 . org /2003/05/ soap−enve lope \" xmlns : ns2=\"http :// puc . dataprev . gov . br /\"xmlns : ns1=\"http :// s e c a l . dataprev . gov . br /\" " ) , 1 ,

ToEncoding ( " app l i c a t i o n / soap+xml ; cha r s e t=UTF−8") ,SEVERITY_ERROR) ;

// Validando se o va l o r e s re tornados são i d e n t i c o s aosesperados

WebXmlVerifyNodeValue (ToEncoding ( " / soap : Envelope [ 1 ] / soap :Body [ 1 ] / ns1 : consultarVencimentoGPSResponse [ 1 ] / r e su l t ado[ 1 ] / ns1 : vencimento−comp [ 1 ] " ) , ven_vencCompetencia , 1 ,WEB_FLAG_EQUAL,ToEncoding ( " xmlns : soap=\"http ://www.w3 . org /2003/05/ soap−

enve lope \" xmlns : ns2=\"http :// puc . dataprev . gov . br /\"xmlns : ns1=\"http :// s e c a l . dataprev . gov . br /\" " ) , 1 ,


// Enviando a r e qu i s i c a o do s e r v i c o passando a va r i a v e l comxml baseado no template . O ult imo parametro ( "01_ConsultarVencimentoGPS " ) da funcao é o nome dar e qu i s i ç ã o que s e rá ex ib ido no r e l a t o r i o do S i l kPerformer

WebPagePost ( " http ://"+ s e r v i d o r +"/ s e c a l /SECALWS/SECALService" , mensagemConsultarVencimentoGPS , STRING_COMPLETE, "app l i c a t i o n / soap+xml ; cha r s e t=UTF−8" , "01_ConsultarVencimentoGPS " ) ;

end T_ConsultarVencimentoGPS ;


/∗Transação T_ValorarCredito , o xml enviado é baseado em um

template que f o i l i d o no TInit .∗/t r an sa c t i on T_ValorarCreditovar

mensagemValorarCredito : s t r i n g ;va l_va lorOr ig ina l , val_dataCredito , val_dataValoracao ,

va l_valorAtua l i zado : s t r i n g ;begin

// Lendo os parâmetros de r e qu i s i ç ã o e r e spo s ta esperada doarquivo de massa de dados

FileGetNextRow ( massaValorarCredito ) ;val_dataCredito := Fi leGetCol ( massaValorarCredito , 3 ,

STRING_COMPLETE) ;val_dataValoracao := Fi leGetCol ( massaValorarCredito , 4 ,

STRING_COMPLETE) ;va l_va lo rOr ig ina l := Fi leGetCol ( massaValorarCredito , 5 ,

STRING_COMPLETE) ;va l_valorAtua l i zado := Fi leGetCol ( massaValorarCredito , 6 ,

STRING_COMPLETE) ;

// Subst i tu indo , no template l i d o para a va r i a v e lmensagemConsultarVencimentoGPS , a s t r i n g { competencia }pe la v a r i a v e l competencia

mensagemValorarCredito := msgTemplateValorarCredito ;FStrReplace ( mensagemValorarCredito , " { dataCred i to } " ,

val_dataCredito ) ;FStrReplace ( mensagemValorarCredito , " { va l o rOr i g i n a l } " ,

va l_va lo rOr ig ina l ) ;FStrReplace ( mensagemValorarCredito , " {dataValoracao } " ,

val_dataValoracao ) ;

// Gerando e r ro se no xml de re to rno e x i s t i r ns2 : e r r oWebVerifyData (ToEncoding ( " ns2 : e r r o " ) , 1 , WEB_FLAG_SMALLER ,

1 , SEVERITY_ERROR) ;


// Validando se o va l o r e s dos parametros re tornados sãoi d e n t i c o s aos enviados

WebXmlVerifyNodeValue (ToEncoding ( " / soap : Envelope [ 1 ] / soap :Header [ 1 ] / ns2 : params [ 1 ] / ns2 : entrada [ 1 ] / ns1 : dataCredito[ 1 ] " ) , val_dataCredito , 1 , WEB_FLAG_EQUAL,



WebXmlVerifyNodeValue (ToEncoding ( " / soap : Envelope [ 1 ] / soap :Header [ 1 ] / ns2 : params [ 1 ] / ns2 : entrada [ 1 ] / ns1 : v a l o rOr i g i n a l[ 1 ] " ) , va l_va lorOr ig ina l , 1 , WEB_FLAG_EQUAL,



WebXmlVerifyNodeValue (ToEncoding ( " / soap : Envelope [ 1 ] / soap :Header [ 1 ] / ns2 : params [ 1 ] / ns2 : entrada [ 1 ] / ns1 : dataValoracao[ 1 ] " ) , val_dataValoracao , 1 , WEB_FLAG_EQUAL,



// Validando se o va l o r e s re tornados são i d e n t i c o s aosesperados

WebXmlVerifyNodeValue (ToEncoding ( " / soap : Envelope [ 1 ] / soap :Body [ 1 ] / ns1 : va lorarCred i toResponse [ 1 ] / r e su l t ado [ 1 ] / ns1 :va lor−a tua l i z ado [ 1 ] " ) , va l_valorAtual izado , 1 ,WEB_FLAG_EQUAL,ToEncoding ( " xmlns : soap=\"http ://www.w3 . org /2003/05/ soap−

enve lope \" xmlns : ns2=\"http :// puc . dataprev . gov . br /\"xmlns : ns1=\"http :// s e c a l . dataprev . gov . br /\" " ) , 1 ,



// Enviando a r e qu i s i c a o do s e r v i c o passando a va r i a v e l comxml baseado no template . O ult imo parametro ( "02_ValorarCredito " ) da funcao é o nome da r e qu i s i ç ã o ques e rá ex ib ido no r e l a t o r i o do S i l k Performer

WebPagePost ( " http ://"+ s e r v i d o r +"/ s e c a l /SECALWS/SECALService" , mensagemValorarCredito , STRING_COMPLETE, " app l i c a t i o n /soap+xml ; cha r s e t=UTF−8" , "02 _ValorarCredito " ) ;

end T_ValorarCredito ;

t r an sa c t i on EndTestCasebegin

FileUnload ( massaConsultarVencimento ) ;Fi leUnload ( massaValorarCredito ) ;

end EndTestCase ;

115

ANEXO B – Cadprevic - Teste Original(Arquivo incluído com configurações básicas)

Código 40 – Teste de performance da aplicação Cadprevic (casos não executados foramremovidos)

@codepage (1252)

use "WebAPI . bdh "

varmassaGerid : number ;massaConsultarDocumento : number ;

sConsultarDocumento : s t r i n g ;

sLogin : s t r i n g ;sEntidade : s t r i n g ;sURL : s t r i n g ;sURLWs : s t r i n g ;

dc l funcfunction InitMeasureBoundsbegin

MeasureSetBound("#Overa l l Response Time#" ,MEASURE_PAGE_PAGETIME, 1 , 2 . 5 , SEVERITY_INFORMATIONAL) ;

MeasureSetBound("#Overa l l Response Time#" ,MEASURE_PAGE_PAGETIME, 2 , 5 . 0 , SEVERITY_INFORMATIONAL) ;

MeasureSetBound ( " ConsultarListaEFPC − Enviar r e qu i s i ç ã o deconsu l ta " , MEASURE_PAGE_PAGETIME, 1 , 3 . 0 ,

SEVERITY_INFORMATIONAL) ;MeasureSetBound ( " ConsultarListaEFPC − Enviar r e qu i s i ç ã o de

consu l ta " , MEASURE_PAGE_PAGETIME, 2 , 4 . 0 ,SEVERITY_INFORMATIONAL) ;

ANEXO B. Cadprevic - Teste Original (Arquivo incluído com configurações básicas) 116

MeasureSetBound ( " ConsultarDocumento − Navegar no Menu" ,MEASURE_PAGE_PAGETIME, 1 , 2 . 0 , SEVERITY_INFORMATIONAL) ;

MeasureSetBound ( " ConsultarDocumento − Navegar no Menu" ,MEASURE_PAGE_PAGETIME, 2 , 3 . 0 , SEVERITY_INFORMATIONAL) ;

MeasureSetBound ( " ConsultarDocumento − Consultar comsuce s so " , MEASURE_PAGE_PAGETIME, 1 , 4 . 0 ,SEVERITY_INFORMATIONAL) ;

MeasureSetBound ( " ConsultarDocumento − Consultar comsuce s so " , MEASURE_PAGE_PAGETIME, 2 , 5 . 0 ,SEVERITY_INFORMATIONAL) ;

end InitMeasureBounds ;

//−−−− Login no Gerid −−−−//function LogaGeridbegin

//−−−− Carregar arquivo de massa de dados com usuá r i o s doGerid −−−−//

FileCSVLoadGlobal (massaGerid , "MTD_Gerid . csv " , " , " ) ;

//−−−− Carregar arquivo de massa de dados com os números dosDocumentos a serem i n s e r i d a s −−−−//

FileCSVLoadGlobal (massaConsultarDocumento , "MTD_ConsultarDocumento . csv " , " , " ) ;

//−−−− Obter o próximo usuár io do Gerid −−−−//FileGetNextUniqueRow (massaGerid ) ;sLogin := Fi leGetCol (massaGerid , 0 , STRING_COMPLETE) ;

//−−−− Logar no Gerid −−−−//Attr ibuteGetSt r ing ( "URL" , sURL) ;WebVerifyHtml (ToEncoding ( " Acesso v ia Senha " ) , 1 ,


WebPageUrl (sURL, " Login − Acessa Página I n i c i a l " ) ;WebVerifyHtml ( " Cadastro de Entidades e Planos − CADPREVIC" ,

1 , WEB_FLAG_IGNORE_WHITE_SPACE | WEB_FLAG_EQUAL |WEB_FLAG_CASE_SENSITIVE, NULL, SEVERITY_ERROR) ;

ANEXO B. Cadprevic - Teste Original (Arquivo incluído com configurações básicas) 117

WebPageSubmit ( " Entrar " , ENTRAR, " Login − Submete Usuário eSenha " ) ;

InitMeasureBounds ( ) ;end LogaGerid ;

function LoadWSbegin

Attr ibuteGetSt r ing ( "URLWs" , sURLWs) ;Att r ibuteGetSt r ing ( " idEntidade " , sEntidade ) ;

//−−−− Logar no WebService −−−−//ThinkTime ( 2 . 0 ) ;WebSetUserAuthBasic ( " usuar io " , " senha " ) ;InitMeasureBounds ( ) ;

end LoadWS;

dcl formENTRAR:

" username " := sLogin ," password " := " senha " ," l t " := " " <USE_HTML_VAL> ," execut ion " := " " <USE_HTML_VAL> ," _eventId " := " " <USE_HTML_VAL> ," submit " := " " <USE_HTML_VAL> ;

118

ANEXO C – Cadprevic (REST) - TesteOriginal

Código 41 – Teste de performance da aplicação Cadprevic REST.@codepage (1252)

benchmark S i lkPer formerRecorder

use "WebAPI . bdh "use " cadprev i cBas i c . bdh "

d c l u s e ruser

VU_ConEfpct r an s a c t i on s

TInit : begin ;ConsultarEFPC : 56 ; // 5 : WS

userVU_San_ConEfpc

t r an s a c t i on sTInit : begin ;ConsultarEFPC : 1 ;

var

dclrand

dc l t r an s

t r an sa c t i on TInitbegin

LoadWS( ) ;end TInit ;

t r an s a c t i on ConsultarEFPC

ANEXO C. Cadprevic (REST) - Teste Original 119

varbegin

ThinkTime ( 2 . 0 ) ;WebVerifyData (ToEncoding ( " t o t a l " ) , 2 ,


WebPageUrl (sURLWs + " e fpc " , " ConsultarListaEFPC − Enviarr e qu i s i ç ã o de consu l ta " ) ;

end ConsultarEFPC ;

120

ANEXO D – Cadprevic (Web) - TesteOriginal

Código 42 – Teste de performance da aplicação Cadprevic Web.@codepage (1252)

benchmark S i lkPer formerRecorder

use "WebAPI . bdh "use " cadprev i cBas i c . bdh "

d c l u s e ruser

VU_ConDoct r an s a c t i on s

TInit : begin ;ConsultarDocumento : 10 ; // 4 : IE , 2 : FF

userVU_San_ConDoc

t r an s a c t i on sTInit : begin ;ConsultarDocumento : 1 ;

d c l t r an st r an sa c t i on TInitbegin

LogaGerid ( ) ;end TInit ;

t r an s a c t i on ConsultarDocumento //−−−− CTD749706 − Consultardocumento com suce s so − 12% −−−−//

varbegin

//−−−− Obter o próximo Número do Documento a s e r consu l tado−−−−//

ANEXO D. Cadprevic (Web) - Teste Original 121

FileGetNextUniqueRow (massaConsultarDocumento ) ;sConsultarDocumento := Fi leGetCol (massaConsultarDocumento ,

0 , STRING_COMPLETE) ;

ThinkTime ( 2 . 0 ) ;WebVerifyHtml (ToEncoding ( " Manter Documento " ) , 2 ,


WebPageLink ( " Manter Documento " , " ConsultarDocumento −Navegar no Menu" ) ;

ThinkTime ( 1 1 . 0 ) ;WebVerifyHtml (ToEncoding ( " Detalhar " ) , 1 ,


WebPageSubmit ( " formPesquisarDocumento " ,FORMCONSULTARDOCUMENTO0, " ConsultarDocumento − Consultarcom suce s so " ) ;

end ConsultarDocumento ;

dc l form

FORMCONSULTARDOCUMENTO0:" formPesquisarDocumento " := " form " ,"DTPINFRA_TOKEN" := " " <USE_HTML_VAL> ," numeroDocumentoPesquisa " := sConsultarDocumento ," da ta In i c i a lPe squ i s a_ input " := " " <USE_HTML_VAL> ," dataFinalPesquisa_input " := " " <USE_HTML_VAL> ," tiposDocumentoPesquisa_focus " := " " <USE_HTML_VAL> ," tiposDocumentoPesquisa_input " := " " ," botaoConsultar " := " " ," javax . f a c e s . ViewState " := " " <USE_HTML_VAL> ;

uma linguagem específica de domínio para geração de testes ... · marinho, thiago david dos...

Documents