Uma linguagem específica de domínio para geração de testes de performance

Texto

(1)Thiago David dos Santos Marinho. Uma Linguagem Específica de Domínio para Geração de Testes de Performance. Brasil 30 de Agosto de 2016.

(2) Thiago David dos Santos Marinho. Uma Linguagem Específica de Domínio para Geração de Testes de Performance. Dissertação de Mestrado apresentada ao Programa de Pós-graduação em Engenharia de Software da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Engenharia de 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á Kulesza Coorientador: Felipe Alves Pereira Pinto. Brasil 30 de Agosto de 2016.

(3) Universidade Federal do Rio Grande do Norte - UFRN Sistema de Bibliotecas - SISBI Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede. Marinho, Thiago David Dos Santos. Uma linguagem específica de domínio para geração de testes de performance / Thiago David Dos Santos Marinho. - 2016. 121 f.: il. Mestrado (Dissertação) - Universidade Federal do Rio Grande do Norte, Instituto Metrópole Digital, Programa de Pós-Graduação em Engenharia de Software. Natal, RN, 2016. Orientador: Uirá Kulesza. Coorientador: Prof. Dr. Felipe Alves Pereira Pinto.. 1. Engenharia de software - Dissertação. 2. Testes de performance - 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.

(4) Thiago David dos Santos Marinho. Uma Linguagem Específica de Domínio para Geração de Testes de Performance. Trabalho aprovado. Brasil, 30 de Agosto de 2016:. Uirá Kulesza Orientador. Felipe Alves Pereira Pinto (IFRN) Co-Orientador. Sérgio Medeiros (ECT/UFRN) Convidado 1. Franklin de Souza Ramalho (UFCG) Convidado 2. Brasil 30 de Agosto de 2016.

(5) Dedico este trabalho à minha família..

(6) 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. Aos meus 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 de trabalho pela confiança e ajuda..

(7) “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).

(8) Resumo Este trabalho apresenta a ferramenta GenMeter, composta por: (i) uma linguagem específica de domínio utilizada para descrever textualmente testes de performance; e (ii) um componente que utiliza os testes descritos para gerar projetos em diferentes plataformas de execução de testes de performance. O objetivo é utilizar os conceitos definidos na linguagem para abstrair os conceitos de cada plataforma, que muitas vezes são modelados diferentemente, 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 de serviços SOAP, REST e de aplicações web para JMeter e Silk Performer. Ela também permite a customização para novos tipos de testes e plataformas alvo. Foram feitos estudos para avaliar o uso da ferramenta: 3 testes de aplicações Web, REST e SOAP foram reescritos na linguagem específica de domínio (DSL - domain specific language) e então foram gerados projetos nas plataformas de destino, para que fossem executados. A partir dos ajustes e novas implementações necessários para a geração dos projetos, obteve-se feedback referente a capacidade de customização da ferramenta em relação aos tipos de aplicações e características de plataformas e organizações. Além disso, os scripts também foram avaliados em relação à sua concisão: além dos testes implementados com a DSL e com o Silk Performer, foram criados testes com a ferramenta Gatling.io (também baseados no teste da 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ção entre 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 em relação aos testes de Silk Performer e 39,43% em relação aos testes de Gatling.io, com exceção de um tipo de teste, em que a especificação com a DSL ficou com pouco mais que o dobro (138,35%) de palavras. Na segunda comparação, em média, os testes com a GenMeter apresentaram um percentual de 56,33% de palavras reservadas em relação ao total, contra 39,98% do Silk Performer e 67,03% do Gatling.io. Esta comparação pode ser interpretada como a quantidade de informação adicional que o usuário precisa fornecer pra cada linguagem, além das estruturas fornecidas pela mesma. Já na terceira comparação, que pode ser interpretada como o quanto a sintaxe da linguagem hospedeira pode interferir na visualização das informações dos testes, a GenMeter teve em média 23,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 observar os benefícios de utilizar a DSL para diferentes tipos de aplicações, customizando-a de acordo com determinados conceitos e características de plataformas e organizações. Palavras-chave: Linguagens específicas de domínio, Testes de performance, Geração de código.

(9) Abstract This 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 those described test specifications to generate projects in different performance test execution platforms. The purpose is to use concepts defined in the language to abstract the concepts of each platform, which are often modeled differently regarding nomenclature and/or structure and even dependent on the tool rather than just the domain. The proposed tool supports SOAP, REST and web applications performance tests to JMeter and Silk Performer. It also allows customization to new test types and target platforms. Studies were conducted to evaluate the use of the tool: 3 tests of web applications, REST and SOAP services have been rewritten in the DSL and then were generated projects to the target platforms, to be executed. After the adaptation and new implementations necessary for the project generation, we obtained feedback regarding the ability to customize the tool for the applications types and platforms and organizations features. Moreover, the scripts 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 the relation between the number of reserved words and the total number of words; and the relationship between the number of reserved words out of context, and the total of reserved words. Tests created with GenMeter have, on average, 59,15% less words in relation to Silk 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 second comparison, on average, tests with the GenMeter presented a percentage of 56.33% of reserved 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 additional information that the user needs to provide for each language, in addition to the structures provided by them. In the third comparison, which can be interpreted as how the syntax of the host language may interfere with viewing of the test information, GenMeter had an average of 23.57% of reserved words out of context relative to the total of reserved words against 53.38% from Silk Performer and 54.60% from Gatling. Thus, it was possible to observe the benefits of using DSL for different types of applications, customizing it according to certain concepts and features platforms and organizations.. Keywords: Domain-specific languages, Performance tests, Code generation..

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

(11) Lista de códigos Código 1 – Comando para geração do projeto JMeter . . . . . . . . . . . . . . . . Código 2 – Exemplo de teste descrito com a DSL . . . . . . . . . . . . . . . . . . Código 3 – Definição de dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . Código 4 – Definição de cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . Código 5 – Definição de caso de teste web . . . . . . . . . . . . . . . . . . . . . . Código 6 – Definição de caso de teste REST . . . . . . . . . . . . . . . . . . . . . Código 7 – Definição de caso de teste SOAP . . . . . . . . . . . . . . . . . . . . . Código 8 – Requisição para serviço SOAP utilizando template e substituindo valores Código 9 – Asserções de resposta de requisição SOAP . . . . . . . . . . . . . . . . Código 10 – Requisição e asserção em serviço REST . . . . . . . . . . . . . . . . . Código 11 – Trecho do teste da DSL configuração de autenticação Basic . . . . . . Código 12 – Trecho do teste da DSL com acesso à URL . . . . . . . . . . . . . . . Código 13 – Trecho do teste da DSL com clique em link . . . . . . . . . . . . . . . Código 14 – Trecho do teste da DSL com o submit de formulário . . . . . . . . . . Código 15 – Trecho do teste da DSL em que é necessário efetuar login . . . . . . . Código 16 – Trecho do teste da DSL em que é necessário definir o encoding . . . . . Código 17 – Trecho do teste do Silk Performer em que é necessário definir o encoding Código 18 – Definição da propriedade encoding sem atalho . . . . . . . . . . . . . . Código 19 – Criação do atalho para a propriedade encoding . . . . . . . . . . . . . Código 20 – Trecho do teste do Silk Performer em que é necessário definir a quantidade de vezes que o texto deve estar presente (segundo argumento da função WebVerifyData) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Código 21 – Trecho do teste na DSL em que é necessário definir o parâmetro da asserção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Código 22 – Ajuste no método de asserção . . . . . . . . . . . . . . . . . . . . . . . Có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 . Código 24 – Exemplo de teste em Ruby JMeter . . . . . . . . . . . . . . . . . . . . Código 25 – Comando necessário para geração do teste em JMeter . . . . . . . . . Có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ários simultâneos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Código 27 – Exemplo de teste gerado a partir de especificação com a DSL (Silk Performer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Código 28 – Gramática da DSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Código 29 – Tokens definidos para a gramática . . . . . . . . . . . . . . . . . . . .. 37 43 44 44 45 46 46 55 55 56 56 57 57 57 57 58 59 59 59. 60 60 60 64 67 68. 71 83 87 88.

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

(13) Lista de tabelas Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela. 1 2 3 4 5 6 7 8 9 10 11 12 13 14. – – – – – – – – – – – – – –. Ferramentas de teste de performance. . . . . . . . . . . . . . . . . . . . Exemplos de conceitos presentes em algumas ferramentas. . . . . . . . Abstrações da ferramenta JMeter. . . . . . . . . . . . . . . . . . . . . Abstrações da ferramenta Silk Performer. . . . . . . . . . . . . . . . . Abstrações da ferramenta Loadrunner. . . . . . . . . . . . . . . . . . . Relação entre conceitos e entidades das ferramentas e Metamodelo. . . Aplicações selecionadas por tipo de teste. . . . . . . . . . . . . . . . . Percentual de palavras reservadas em relação ao total de palavras . . . Percentual de palavras reservadas fora do contexto em relação ao total de palavras reservadas . . . . . . . . . . . . . . . . . . . . . . . . . . . Ferramentas e trabalhos relacionados. . . . . . . . . . . . . . . . . . . Sumário dos Trabalhos Relacionados. . . . . . . . . . . . . . . . . . . Contagem de palavras dos testes implementados com a DSL . . . . . . Contagem de palavras dos testes implementados com o Silk Performer Contagem de palavras dos testes implementados com o Gatling . . . .. 19 20 40 40 41 41 54 64 65 67 75 86 86 86.

(14) 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.

(15) Sumário 1 1.1 1.2 1.3 1.3.1 1.4 1.4.1 1.4.2 1.4.3 1.5 1.6 1.7. INTRODUÇÃO . . . . . . . . . . Motivação . . . . . . . . . . . . . . Problema Abordado . . . . . . . . Objetivos . . . . . . . . . . . . . . Objetivos Específicos . . . . . . . . . Escopo . . . . . . . . . . . . . . . . Testes de Performance na Dataprev . Plataformas alvo da geração . . . . . Elementos e artefatos fora do escopo Questões de pesquisa . . . . . . . Metodologia . . . . . . . . . . . . . Organização . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. 17 17 19 21 22 22 22 23 23 23 24 25. 2 2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.2 2.2.1 2.2.2 2.2.3 2.3 2.3.1 2.3.2 2.3.3. FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . Testes de performance . . . . . . . . . . . . . . . . . . . . . . . Testes de Desempenho . . . . . . . . . . . . . . . . . . . . . . . . Testes de Estresse . . . . . . . . . . . . . . . . . . . . . . . . . . Testes de Carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testes de sanidade . . . . . . . . . . . . . . . . . . . . . . . . . . Ferramentas Atuais de Teste de Performance . . . . . . . . . JMeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loadrunner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Silk Performer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Linguagens Específicas de Domínio . . . . . . . . . . . . . . . DSL Externa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DSL Interna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bancada de Linguagem . . . . . . . . . . . . . . . . . . . . . . . . XText . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MetaEdit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analisador Sintático . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. 26 26 26 26 27 27 27 27 29 31 32 33 33 33. 2.3.3.1 2.3.3.2 2.3.3.3. 2.3.4 2.3.5 3 3.1. . . . . . . . . . . . .. . . . . . . . . . . . .. 34 34 34. 34 35. LINGUAGEM ESPECÍFICA DE DOMÍNIO PARA GERAÇÃO DE TESTES DE PERFORMANCE . . . . . . . . . . . . . . . . . . . . . 36 Visão Geral da Abordagem . . . . . . . . . . . . . . . . . . . . . . . . 36.

(16) 3.2 3.2.1 3.2.2 3.3 3.4 3.4.1 3.4.2 3.4.3 3.5 3.5.1 3.5.2 3.5.3. Requisitos e Decisões de Projeto . Requisitos da Ferramenta . . . . . . . Decisões de Projeto . . . . . . . . . . O Metamodelo . . . . . . . . . . . A Linguagem . . . . . . . . . . . . Definição de dataset . . . . . . . . . Definição de cenário . . . . . . . . . Definição de caso de teste . . . . . . Arquitetura da Ferramenta . . . . DSL . . . . . . . . . . . . . . . . . . Modelo . . . . . . . . . . . . . . . . Gerador . . . . . . . . . . . . . . . .. 4 4.1 4.1.1 4.1.2 4.2 4.3 4.4 4.4.1. AVALIAÇÃO DA ABORDAGEM Projeto do Estudo . . . . . . . . Objetivos e Questões de Pesquisa . Procedimentos . . . . . . . . . . . Resultados . . . . . . . . . . . . . Ameaças à Validade do Estudo . Conclusão . . . . . . . . . . . . . Discussões e Lições Aprendidas . . .. 5 5.1 5.2 5.3. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. 37 37 38 40 42 44 44 45 47 49 49 50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. 52 52 52 53 55 65 66 66 67 67 68. 5.4 5.5 5.6. TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . DSL para criação de projetos JMeter . . . . . . . . . . . . . . . . . . Modelagem utilizando DSL Visual . . . . . . . . . . . . . . . . . . . . Plataforma com suporte ao desenvolvimento e execução de testes com DSL própria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Geração de aplicações para testes de performance . . . . . . . . . . Modelagem analítica de performance . . . . . . . . . . . . . . . . . . Sumário dos Trabalhos Relacionados . . . . . . . . . . . . . . . . . .. 70 72 74 74. 6 6.1 6.2 6.3. CONCLUSÃO . . . . . . . Limitações do Trabalho . . Contribuições da Pesquisa . Trabalhos Futuros . . . . .. 76 76 76 78. REFERÊNCIAS. . . . .. . . . .. . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. PROPOSTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . .. . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . .. . . . .. . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80.

(17) APÊNDICES. 82. APÊNDICE A – EXEMPLO DE TESTE DE PERFORMANCE COM A 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 COM A 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 COM O GATLING.IO103 APÊNDICE L – CADPREVIC (WEB) - TESTE COM O GATLING.IO104. ANEXOS. 106. ANEXO A – SECAL (SOAP) - TESTE ORIGINAL . . . . . . . . . 107 ANEXO B – CADPREVIC - TESTE ORIGINAL (ARQUIVO INCLUÍDO COM CONFIGURAÇÕES BÁSICAS) . . . . 115 ANEXO C – CADPREVIC (REST) - TESTE ORIGINAL . . . . . . 118 ANEXO D – CADPREVIC (WEB) - TESTE ORIGINAL . . . . . . 120.

(18) 17. 1 Introdução Este capítulo apresenta a motivação, o problema, contexto, limitações de soluções existentes, objetivos gerais e específicos da proposta, e metodologia usada no desenvolvimento desta dissertação.. 1.1 Motivação A 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 primeiro tipo descreve quais as responsabilidades atribuídas ao sistema, isto é, que funções ele deve fornecer aos atores. O segundo tipo representa propriedades mensuráveis ou testáveis de um sistema, usadas para indicar o quão bem o sistema satisfaz a necessidade de seus interessados. Alguns exemplos são: disponibilidade, interoperabilidade, manutenibilidade, performance, segurança e usabilidade. Já o terceiro diz respeito a premissas baseadas na necessidade das partes envolvidas no projeto; características que restringem o leque de escolhas a serem tomadas na definição da arquitetura do mesmo, ou que simplesmente impõem uma opção. Por exemplo, utilização de uma linguagem específica, reutilização de um 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. Segundo Myers et al. (2004): “testes de software é um processo, ou uma série de processos, designados para garantir que o código faz aquilo que foi especificado a fazer e que ele não realiza nenhuma ação não esperada. O software deve ser previsível e consistente, sem oferecer surpresas 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 foram especificadas (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 a todas 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 que foi 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 o sistema, para que assim seja possível estabelecer estratégias para garantir que um nível aceitá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,.

(19) Capítulo 1. Introdução. 18. taxa de transferência, confiabilidade e/ou escalabilidade do sistema sob uma determinada carga 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): testes de desempenho, carga e de estresse. Os testes de desempenho buscam extrair informações sobre o desempenho do sistema em cenários normais de uso (JOBS, 2010). Testes de carga são usados para ajudar a identificar a capacidade máxima do sistema e possíveis gargalos 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 da execução de scripts de teste que simulam o comportamento dos usuários (MENASCE, 2002). Os testes de estresse, diferentemente dos anteriores, consistem em submeter o sistema a situações anormais de uso, como grandes quantidades de carga, redução dos recursos 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íficas para sua execução e análise. Não é viável (ou até possível), por exemplo, a mobilização de 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 tempo de 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 programas de linha de comando que, de acordo com configurações informadas através de parâ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 possuem poucos 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 e cenários mais complexos de monitoramento. São oferecidas em diversas formas (aplicações desktop, SaaS – Software as a Service) e cada uma delas utiliza suas próprias abstrações e recursos, oferecendo interfaces gráficas, wizards e até linguagens de propósito geral e específicas de domínio (DSL), que nem sempre são ideais para um rápido entendimento sobre os testes que estão sendo representados. 1 2 3 4. 5. <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> <https://flood.io/>.

(20) Capítulo 1. Introdução. 19. 1.2 Problema Abordado Existem 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 aspecto importante é que boa parte das ferramentas oferece suporte a aplicações web. Como pode ser visto na Tabela 2, as ferramentas não seguem as mesmas abstrações, conceitos e linguagens. Muitas destas abstrações e conceitos têm mais a ver com características da plataforma do que propriamente com conceitos de testes de performance. Essas diferenças acabam 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. Elas també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ário que o mesmo seja refeito. Tabela 1 – Ferramentas de teste de performance. Ferramenta. Descrição. JMeter. Software open source 100% feito em Java desenhado para testes de carga e medição de desempenho, originalmente criado para uso com aplicações web.. Loadrunnera. Solução para testes de desempenho, carga e estresse, que pode ser utilizada 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ém permitindo a gravação de testes. A execução dos testes ocorre localmente ou através de agentes remotos.. Rational Performance Testerb. Solução de testes de performance criada pela IBM, baseada no Eclipsec e que funciona com a gravação dos testes através da navegação no website sendo testado ou implementação manual.. AB. Ferramenta simples de linha de comando para teste de servidores HTTP e aplicações web.. Flood.io. Ferramenta que permite a execução de testes de performance em sua própria infraestrutura. Oferece uma DSL em Rubyd , chamada Ruby JMetere para a descrição desses testes, permitindo inclusive que os testes gerados possam ser executados localmente, no JMeter. Não permite geração para outras ferramentas..

(21) Capítulo 1. Introdução. Gatling.iof. 20. Produto que oferece ferramentas para gravação de testes de performance diretamente no browser, uma API e uma DSL (interna, em Scalag ) para edição dos scripts, e também uma plataforma para execução dos testes gerados e/ou criados manualmente. A DSL faz parte da plataforma, e não foi feita com o intuito de gerar projetos de outras plataformas.. DSLBench Implementada com a ferramenta Microsoft Domain Specific Lan(BUI et al., guage Toolkit (atualmente Modeling SDK for Visual Studioh ), e 2007) baseada em MDD (Model Driven Development). Funciona como plugin do Visual Studio 2005 Team Suite. Revel8or Toolkit que utiliza as ferramentas DSLBench, MDAPerf e MDA(ZHU et al., Bench para a implementação, modelagem e execução dos testes, 2007) 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 Grupo de testes, cenários e configurações Características de um caso de teste Casos de testes Massa de dados. JMeter Test Plan. Silk Performer Project. Loadrunner Solution. Thread. User. Script. Sampler Datasource. Transaction Datasource. Action Parameter.

(22) Capítulo 1. Introdução. 21. Muitas vezes informações essenciais sobre o requisito não-funcional que será testado não são exibidas na interface das ferramentas, seja porque ficam escondidas, porque são inferidas a partir de outros dados, ou porque a ferramenta simplesmente não tem aquele tipo de informação em seu conjunto de conceitos e abstrações. Isso pode fazer com que seja mais complicado entender o que de fato são os testes de performance na ferramenta, e o que eles estão avaliando. Considerando ferramentas e processos presentes em ambientes corporativos, alguns problemas adicionais podem ser listados: • Boas práticas e padrões precisam ser verificados e aplicados a códigos gerados por ferramentas 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 de uma nova licitação, por exemplo), os projetos que foram descritos na ferramenta substituída deverão ser migrados para a nova. Por exemplo, caso uma empresa precise mudar de ferramenta, deverá refazer manualmente todas as implementações de testes que já possui. Existem poucas aplicações criadas para conversão de testes. A única encontrada 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és da criação de plugins7 e/ou bibliotecas8 9 , o que dificulta ainda mais a criação de um conversor universal.. 1.3 Objetivos Este 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 testes de performance para diferentes ferramentas de testes. As plataformas alvo da geração neste trabalho 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. 7 8. 9. Ferramenta que serve para converter testes do Loadrunner para JMeter: <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> <https://ptfrontline.wordpress.com/2009/02/24/using-a-custom-dll-in-loadrunner/>.

(23) Capítulo 1. Introdução. 22. 1.3.1 Objetivos Específicos • Criar uma linguagem que permita descrever os testes de performance em alto nível, que utilize apenas conceitos relacionados a este domínio, mas que permita a customizaçã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 diferentes ambientes e ferramentas de testes de performance; • Avaliar a solução proposta através de um estudo de caso na Dataprev, comparando o seu uso com o do Silk Performer.. 1.4 Escopo Esta 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 de performance 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ão especificados os casos de teste, cenários, massas de dados e outras informações relevantes 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 ferramenta disponibilizada para isso pelo Silk Performer (que gera código a partir do passo a passo executado). Após isso, deverá fazer ajustes referentes a parametrização de valores dinâmicos, sequência de transações dos scripts e pontos de think time 12 ; 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 11. 12. 13. <http://portal.dataprev.gov.br/> Material que contém um diagrama mostrando como é o processo de realização de testes de performance: <http://desenvolvimento.dataprev.gov.br/pddataprev_internet/visualizar_processo.php? idprocesso=1&idfluxo=4,20,36> Think times são usados para simular o comportamento humano ao interagir com uma página, fazendo com 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>). Tipo especial de teste, usado para avaliar se uma aplicação está estável o suficiente para ser submetida a testes mais detalhados, como testes funcionais e de performance (DATAPREV, 2014)..

(24) Capítulo 1. Introdução. 23. 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; estes itens dizem respeito a padrões que devem ser considerados na confecção dos testes e boas prá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 foi aplicado, a Dataprev; • JMeter: escolhida por ser uma ferramenta largamente utilizada na comunidade para execuçã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 (como definições de diretórios base, localização de ferramentas necessárias - JDK, por exemplo); • 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 necessariamente substituiria documentos já existentes em organizações onde seria aplicada.. 1.5 Questões de pesquisa As seguintes perguntas foram propostas para guiar este trabalho: Q1. É possível descrever testes de performance para diferentes tipos de aplicações com a DSL proposta? Uma das características da DSL é que ela deve ser capaz de descrever testes para diferentes tipos de aplicações, por padrão ou provendo meios para que desenvolvedores a estendam (Seção 4.2, Q1). 14. <http://desenvolvimento.dataprev.gov.br/pddataprev_internet/visualizar_artefato.php? idprocesso=1&idartefato=209&iddisciplina=5>.

(25) Capítulo 1. Introdução. 24. Q2. A abordagem permite que a DSL seja customizada para se adequar aos conceitos específicos de plataformas e/ou necessidades de organizações onde seria utilizada? Em complemento à primeira pergunta, também é necessário que a ferramenta possa ser ajustada para usar conceitos diferentes dos originais, facilitando a adoção dela em diferentes cenários (Secao 4.2, Q2). Q3. Quão concisas são as especificações na DSL proposta em comparação com outras representações textuais de testes existentes? Os testes especificados com a DSL proposta são mais concisos que os testes criados com outras ferramentas, facilitando assim a visualização das informações pertinentes ao contexto dos testes de performance? (Secao 4.2, Q3).. 1.6 Metodologia As seguintes atividades foram realizadas durante o desenvolvimento deste trabalho: • Levantamento bibliográfico através de buscas por artigos e outros trabalhos relacionados ao assunto abordado. Este levantamento resultou no estudo dos seguintes trabalhos: DSLBench, Revel8or, Aspen e abordagem de BERNARDINO et al. (2014); • Estudo de ferramentas e ambientes de testes de performance atuais: JMeter, Silk Performer, 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 ambientes existentes de teste de performance); – Definição da DSL de forma que reflita conceitos que foram escolhidos para o metamodelo; – Definição de tecnologias a serem utilizadas; • Implementação da ferramenta que utiliza a linguagem para geração de testes em diferentes 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..

(26) Capítulo 1. Introdução. 25. 1.7 Organização Este trabalho está organizado da seguinte forma: O Capítulo 2 descreve conceitos relevantes de testes de performance, linguagens de domínio específico e de algumas possíveis ferramentas que podem ser alvo de geração de código. O Capítulo 3 apresenta detalhes sobre a solução que foi desenvolvida com este trabalho: seus requisitos, decisões de design que foram tomadas, arquitetura e organização do código. O Capítulo 4 traz detalhes sobre o estudo feito para avaliar a solução proposta e seu 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..

(27) 26. 2 Fundamentação Teórica Este capítulo descreve diversos conceitos referentes ao tema deste trabalho. Primeiramente são apresentados alguns conceitos de testes de performance na seção 2.1. Em seguida, algumas possíveis ferramentas alvo de geração de código são apresentadas na seção 2.2. Finalmente, alguns conceitos referentes à linguagens específicas de domínio são descritos na seção 2.3.. 2.1 Testes de performance O 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 sistema sobre uma determinada carga de trabalho (MEIER et al., 2007). É muito importante na análise do sistema e, caso não seja executado da maneira correta, seus resultados são inúteis ou até enganosos, fazendo com que uma empresa menospreze ou superestime a capacidade de sua aplicação (SAVOIA, 2000). Pode ser classificado em testes de desempenho, estresse e carga.. 2.1.1 Testes de Desempenho Tipo de teste que busca extrair informações sobre o desempenho do sistema em cenários normais de uso (JOBS, 2010). São voltados para a investigação de aspectos relacionados à responsividade, velocidade e estabilidade do sistema. Testes focados nesses aspectos nos permitem avaliar a velocidade de resposta do sistema em diversos níveis de carga e cenários. Com eles, podemos também realizar testes de confiabilidade no sistema e analisar os aspectos que nos indicam o nível de escalabilidade permitido em relação ao sistema, 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, disponibilidade e confiança da aplicação diante de condições extremas, sendo que seu objetivo é identificar problemas na aplicação que tornam-se aparentes somente diante dessas condições. Tais condições podem ser cargas de trabalho muito pesadas, alta simultaneidade de usuários ou limitações de recursos computacionais (CAMPOS, 2011). Assim, consistem em submeter.

(28) Capítulo 2. Fundamentação Teórica. 27. o sistema a situações anormais de uso, como grandes quantidades de carga, redução dos recursos 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íveis gargalos que podem vir a interferir na operação do mesmo. São diversas as circunstâncias onde é indicada a realização de testes de carga. Exemplo de tais circunstâncias são a antecipação de um aumento significativo de carga na aplicação decorrente de ações de marketing ou mudanças na aplicação, como a adição de novas funcionalidades ou o redesign do 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ável o suficiente para ser submetida a testes mais detalhados, como testes funcionais e de performance. Este tipo de teste também é conhecido como Smoke test e tem o propósito de evitar que se desperdicem recursos de testes com uma versão que não esteja suficientemente está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 realizar testes de carga de comportamentos funcionais e medir a performance. Originalmente foi criada para testar aplicações web, porém foi expandida para outros tipos de teste. Ela pode 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 para analisar a performance geral sob diferentes tipos de carga. Pode também ser usado para analisar a performance através de gráficos ou para testar o comportamento de seu servidor/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 ser vista 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 outros elementos do plano de teste, ele controla os grupos de usuários, que serão executados;.

(29) Capítulo 2. Fundamentação Teórica. 28. Figura 1 – Interface do JMeter. • Controladores ou Controllers: divididos em Testador ou Sampler e Controladores Lógicos ou Logic Controllers. Testadores: são controladores já prontos para requisições específicas. Controladores Lógicos: são controladores genéricos, podendo ser customizados 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 durante os testes; • Temporizador ou Timers: utilizado para incluir pausas ou delays entre as transações; • Elemento de Configuração ou Configuration Elements: elemento que pode modificar as requisições; • Pré-Processadores ou Pre-Processor Elements: executa alguma ação antes de fazer a requisição; • Pós-Processadores ou Post-Processor Elements: executa alguma ação depois de fazer a requisição; • Asserções ou Assertions: usadas para verificar se uma requisição feita ao alvo do teste obteve os resultados esperados;.

(30) Capítulo 2. Fundamentação Teórica. 29. • Fontes de dados ou Datasources: tipo de elemento de configuração que permite o uso de arquivos CSV como fontes de dados para preenchimento de valores em templates de 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 pode ser utilizada para testar diversos tipos de aplicativos em desktop e mobile. Pode ser integrada com diversas aplicações para desenvolvedores, como IDEs, ambientes de integração contínua e ferramentas de compilação. Possui uma versão gratuita que disponibiliza até 50 usuários virtuais para a execução dos testes. É possível gerar os códigos ou implementá-los manualmente, conforme descrito adiante. • O processo inicia com a execução do Virtual User Generator: a criação de um usuário virtual é feita através da gravação da interação do cliente com a aplicação em nível abaixo da interação através da GUI. Desta forma, não é necessário que a execução inicie 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ário para cada uma, quando aplicável; • É possível criar parâmetros e então utilizar massa de dados para os valores identificados na gravação e registrados no script; • Os resultados do teste mostram a renderização da tela de acordo com os dados informados; • Algumas configurações como número de iterações, tempo entre iterações, think time sã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..

(31) Capítulo 2. Fundamentação Teórica. 30. Após a criação dos scripts, utiliza-se uma opção para criar cenários e então executar de fato o teste. Esta execução é feita através de outra ferramenta, chamada Controller. A interface 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. Pode ser 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 configuraçõ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, se necessário, recursos são liberados..

(32) Capítulo 2. Fundamentação Teórica. 31. • 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 programação; • Asserção ou Assertion: usada para verificar se o resultado de uma requisição está de acordo com o esperado.. 2.2.3 Silk Performer Silk Performer é a solução da Microfocus1 para criação e execução de testes de performance. Segue uma abordagem de desenvolvimento programática, também permitindo a 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écie de subset do Pascal. Também é possível estender funcionalidades da linguagem com o uso de 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 que será 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 programaticamente ou utilizar o recurso de gravação para registrar os passos em um site, por exemplo; • O script criado/gravado é estruturado como um arquivo pascal: possui seções para declaraçã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ções aplicadas 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 provenientes de arquivos CSV, que são configurados em funções no script de teste; 1. <http://www.microfocus.com.br/>.

(33) Capítulo 2. Fundamentação Teórica. 32. Figura 4 – Interface do Silk Performer • Measure bounds: são marcações de tempos que podem ser definidas para operações de um teste. Por exemplo, posso definir dois measure bounds para o tempo de resposta da requisição para um teste, de 3 e 5 segundos, e a aplicação mostrará no relatório quantas requisições tiveram valores dentro destes tempos.. 2.3 Linguagens Específicas de Domínio Segundo Fowler (2010), uma linguagem específica de domínio (do inglês, DomainSpecific Language - DSL) é uma linguagem de programação de computadores de expressividade limitada focada em um domínio específico. Existem quatro elementos-chave em tal definição: • Linguagem de programação de computadores: uma DSL é usada por humanos a fim de instruir um computador a fazer algo. Assim como em qualquer linguagem de programação moderna, sua estrutura é projetada para facilitar seu entendimento por humanos, mas também deve ser executável por um computador; • Natureza da linguagem: uma DSL é uma linguagem de programação, e como tal deve ter um senso de fluência, em que a expressividade não vem apenas das expressões individuais, mas também das maneiras pelas quais elas podem ser compostas; • Expressividade limitada: uma linguagem de programação de propósito geral fornece muitos 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.

(34) Capítulo 2. Fundamentação Teórica. 33. de recursos necessários para ser útil ao seu domínio. Você não consegue desenvolver um sistema de software inteiro em uma DSL; em vez disso, você usa uma DSL para um aspecto específico de um sistema; • Foco no domínio: uma linguagem limitada é útil apenas se tiver um foco claro em um domínio pequeno. O foco no domínio é o que faz uma linguagem limitada valer a pena. 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 separadamente da linguagem de programação principal com que se está trabalhando. Essa linguagem pode usar uma sintaxe customizada ou seguir a sintaxe de outra representação, como XML. A análise de uma DSL externa se dá através da quebra do seu texto em algum tipo de estrutura para que seja possível descobrir o que ele diz. Tal estruturação é chamada de análise sintática. Alguns exemplos de DSLs externas são: expressões regulares, SQL e arquivos de configuração em XML.. 2.3.2 DSL Interna É uma maneira específica de usar uma linguagem de propósito geral. Um script em uma DSL interna é um código válido em sua linguagem de propósito geral, mas usa apenas um subconjunto dos recursos da linguagem em um estilo determinado para tratar de um pequeno aspecto do sistema como um todo. O resultado deve ter a cara de uma linguagem customizada, e não a cara de uma linguagem hospedeira. O exemplo clássico desse estilo é Lisp; os programadores Lisp, em geral, falam sobre a programação nessa linguagem como a criação e o uso de DSLs. Ruby também desenvolveu uma cultura de DSLs forte: muitas bibliotecas Ruby vêm no estilo de DSLs. Em especial, o framework mais 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, mas também como ambiente customizado de edição para que as pessoas escrevam seus scripts 2. <http://rubyonrails.org/>.

(35) Capítulo 2. Fundamentação Teórica. 34. 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 DSLs disponível como um plugin do Eclipse. Sua abordagem requer a descrição da gramática da linguagem através de um dialeto próprio. A partir deste dialeto e da implementação de processadores e/ou geradores de código é gerada uma infraestrutura completa para uso da linguagem, que pode ser gerada com plugin para o Eclipse, IntelliJ IDEA6 e navegadores web. 2.3.3.2 MPS MPS (Meta Programming System) é uma ferramenta criada pela JetBrains para o desenvolvimento 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 do usuário sempre trabalhar e visualizar apenas texto plano. Esta característica permite diversas vantagens, como incorporação de linguagens em outras (por exemplo, é possível utilizar expressões regulares dentro de SQLs dentro de um código Java). A ferramenta foi inclusive 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ário utilizar 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 em memória, do assunto que a DSL descreve. Se ela descreve uma máquina de estados, então seu 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 um preenchimento em particular desse esquema, com uma instância de evento para cada 3 4 5 6 7. <https://eclipse.org/Xtext/> <https://www.jetbrains.com/mps/> <http://www.metacase.com/mep/> <https://www.jetbrains.com/idea/> <https://www.jetbrains.com/youtrack/>.

(36) Capítulo 2. Fundamentação Teórica. 35. evento declarado no script DSL. O modelo semântico, é, então, a biblioteca ou o framework que a DSL preenche. Muitas vezes o modelo semântico pode preceder a DSL. Isso acontece quando se decide que uma porção do modelo de domínio da aplicação poderia ser melhor preenchida a 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 usando as discussões com os especialistas em domínio para refinar tanto as expressões da DSL quanto a estrutura do modelo de domínio. O modelo semântico pode manter o código para 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 sempre seja 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 os testes em relação ao modelo, ou; – Pode-se testar o analisador sintático vendo se ele preenche o modelo semântico com os objetos corretos; • Facilita o suporte a múltiplas DSLs e a evolução da mesma separadamente do modelo semântico; • Permite dissociar a geração de código da DSL, facilitando a existência de múltiplos geradores.. 2.3.5 Analisador Sintático É o componente responsável por interpretar o script da DSL e então preencher o modelo 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 é feito em conjunto pelo analisador sintático da linguagem hospedeira e pelos construtores de expressão que esta utiliza. Porém, é possível traçar paralelos entre o processamento de DSLs 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 para produzir uma saída útil. Na análise sintática de uma DSL interna, sua chamada é uma série de chamadas a funções. Ainda há a organização dessas chamadas em uma hierarquia para produzir uma saída útil..

(37) 36. 3 Linguagem Específica de Domínio para Geração de Testes de Performance Este capítulo apresenta detalhes sobre a abordagem proposta, forma como foi idealizada, seus requisitos, decisões de design e como seu código foi organizado.. 3.1 Visão Geral da Abordagem Na 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 que acompanha a ferramenta correspondente à plataforma alvo para a geração do projeto. Caso a plataforma alvo não seja suportada ainda, será necessário implementar os componentes responsáveis pela geração. A Figura 5 mostra em alto nível como a abordagem seria utilizada 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 estruturas já presentes na linguagem, e, se necessário, novas estruturas podem ser implementadas (ver próxima atividade); • Adaptação da ferramenta à nova plataforma alvo: para gerar projetos em novas plataformas além das inicialmente englobadas será necessário criar um novo projeto, seguindo a estrutura dos já existentes. Este projeto utilizará a base da biblioteca (gem) genérica, que possui o metamodelo padrão e a gramática que corresponde a ele. Caso seja necessário customizar a DSL também é possível fazê-lo através de uma nova biblioteca;.

(38) 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 a geraçã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 $ d s l _ j m e t e r 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 o projeto na plataforma onde os testes devem ser executados. • Execução dos testes na plataforma alvo: o usuário deverá abrir o projeto na ferramenta pra qual ele foi gerado, e então fazer as devidas configurações para executar os testes de performance.. 3.2 Requisitos e Decisões de Projeto Esta 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 e presentes na literatura e ferramentas de teste de performance. Com base no estudo feito, os artefatos levantados inicialmente são: – Projeto de teste de performance: agrupador das informações referentes aos 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 se a aplicação e o ambiente estão estáveis e prontos para os testes; – Massa de dados: arquivos utilizados para organizar e fornecer dados usados durante os testes. R2. A DSL deve permitir a representação de testes de performance de aplicações web com interface gráfica, serviços REST e SOAP. Estes são os principais tipos de aplicações desenvolvidos na Dataprev e, portanto, considerados neste trabalho; R3. A ferramenta e a DSL devem permitir a inclusão de novas funcionalidades e estruturas. Dessa forma é possível adequá-las à realidade de diferentes empresas e processos de teste..