1,720,992 research outputs found
Software testing at industrial settings: A qualitative study
Em projetos de desenvolvimento a qualidade do produto de software é fundamental para o seu sucesso. Uma das etapas que busca garantir a qualidade do produto final é a validação, verificação e teste (VV&T). O teste é uma das atividades chave de VV&T realizada para garantir a qualidade. Técnicas de teste foram desenvolvidas para verificar e validar tanto requisitos funcionais como não funcionais. Além disso, essas técnicas são aplicadas nas organizações por meio de estratégias que definem os tipos de teste que serão realizados, a ordem de realização, a sua automatização e a frequência de ocorrência. Uma questão importante é verificar como essa atividade é realizada na indústria de software, como essas técnicas são utilizadas e a sua adoção em organizações desenvolvedoras de software. Este trabalho apresenta uma pesquisa qualitativa da atividade de teste. Ela utilizou a técnica teoria fundamentada aplicada em cinco empresas desenvolvedoras de software para estabelecer uma teoria da atividade de teste. Foram realizadas entrevistas com gestores de teste das empresas e, a partir dessas entrevistas, foi desenvolvido uma teoria sobre a organização da atividade de teste. Nesta teoria, observou-se que a estrutura organizacional direciona a escolha das técnicas e ferramentas, bem como o tipo do sistema; o prazo e orçamento condicionam a utilização de técnicas de automatizaçãoIn development projects the quality of the software product is critical to its success. One of the steps that enforces the quality of the final product is validation, verification and testing (VV&T). Testing is one of the key VV&T activities to ensure quality. Testing techniques were developed to verify and validate both functional and non-functional requirements. In addition, these techniques are applied in organizations using strategies that define the testing techniques that will be performed, the order of application, their automation and the frequency of occurrence. An important issue is to verify how testing is carried out in the software industry, how these techniques are used and their adoption in industrial settings. This work presents a qualitative research of the testing activity. It used the grounded theory technique applied in five software development organizations to establish a model of the testing activity. Interviews were conducted with testing managers and, from these interviews, an organizational theory of the testing activity was developed. In this theory, it was observed that the organizational structure directs the choice of techniques and tools, as well as the type of the system; project schedule and budget limit the use of automation technique
Architecture and lifecycle model for short-lived apps
Aplicativos simples e utilizados durante um curto período de tempo são cada vez mais comuns nos dispositivos móveis. Eles perdem a utilidade uma vez que seu objetivo específico é atingido. Porém, consomem memória e processamento do dispositivo, além de seu desenvolvimento consumir recursos humanos e tecnológicos. Para minimizar esses problemas, este trabalho apresenta uma nova abordagem para geração e controle desse tipo de aplicativo por meio de uma nova arquitetura e modelo de ciclo de vida para aplicações de curta duração. A abordagem permite que os aplicativos sejam gerados automaticamente e possam ser excluídos ou gerenciados de acordo com a vontade do usuário ou por outros critérios pré-estabelecidos (e.g., por tempo transcorrido ou por localização). A arquitetura e modelos desenvolvidos foram utilizados em três aplicativos típicos com funcionalidades básicas, layout trivial e processamento leve. Essa validação demonstrou que a abordagem atende às necessidades de aplicativos em diferentes domínios (restaurantes, shoppings e eventos) e pode ser aplicado em situações com diferentes restrições de tempo e localizaçãoSimple applications that are used over a short period of time are becoming increasingly popular on mobile devices. They lose their usefulness once their specific goal is achieved. However, they consume memory and processing of the device; furthermore, its development consume human and technological resources. To minimize these problems, this work presents a new approach for generation and control of this type of application by means of a new architecture and life cycle model for short lived applications. The approach allows applications to be automatically generated, excluded or managed according to the user\'s wishes or other pre-established criteria (e.g., by time elapsed or by location). The architecture and models developed were used in three typical applications with basic functionalities, trivial layout and light-weight processing. This validation demonstrated that the approach addresses the needs of applications in different domains (restaurants, malls and events) and can be applied in situations with different time and location constraint
Interprocedural semantic clone detection
Fragmentos de código duplicado, ou clones, são inseridos em aplicativos por serem uma maneira simples de reúso, dentre outros motivos. Clones são, portanto, comuns em programas. No entanto, a atividade de manutenção pode ficar custosa se o código do programa analisado possuir muitos clones, principalmente os semânticos, os quais podem possuir códigos distintos, mas realizam tarefas similares. Nesse sentido, a utilização de ferramentas que automatizam a tarefa de detectar clones é desejável. Ferramentas atuais de detecção de clones semânticos são capazes de identificar esses clones com altas taxas de acerto. No entanto, elas não são capazes de identificar clones semânticos considerando também os fluxos dos procedimentos ou funções que são invocados dentro dos fragmentos de código comparados. Essa limitação pode levar as ferramentas a indicarem clones semânticos falso positivos. Este trabalho apresenta uma técnica de detecção de clones semânticos que considera as chamadas de procedimentos presentes nos programas. Essa técnica apresentou uma taxa de acertos 2,5% maior do que técnicas convencionais de acordo com um benchmark, também desenvolvido neste trabalho. Esse benchmark foi criado com base nas classificações de clones fornecidas por programadores da indústria e da academia. A técnica interprocedimental de detecção de clones semânticos pode ser utilizada para evolução, manutenção, refatoração e entendimento de programas.Fragments of duplicated code, or clones, are embedded in applications as they are a simple way to reuse code, among other reasons. Clones are therefore common in programs. However, the maintenance activity may be costly if the program code has many clones to analyze, specially semantic clones, which are semantically similar but may have different syntax. In this regard, the use of tools that automate the task of detecting clones is desirable. Current tools for detecting semantic clones are able to identify those clones with high hit rates. However, they are not able to detect semantic clones also considering the flow of procedures or functions that are invoked within the compared code fragments. This limitation can lead the tools to indicate false positive semantic clones. This paper presents a technique that takes into account the procedure calls in programs to detect semantic clones. This technique showed a 2.5% higher hit rate than conventional techniques according to a benchmark also developed in this work. This benchmark was created based on evaluations provided by programmers from academic and industrial settings. The interprocedural semantic clone detection technique can be used for evolution, maintenance, refactoring and understanding of programs
Data flow Subsumption and its Impact on Spectrum-based Fault Localization
Depuração tem por objetivo localizar e corrigir os defeitos do software. Para auxiliar o desenvolvedor foram desenvolvidas técnicas de localização de defeitos que utilizam métricas de associação e dados de cobertura de código (espectros) para identificar os trechos de código mais suspeitos. Elas auxiliam o desenvolvedor por meio de um ranking dos espectros mais suspeitos que pode ser usado para orientar a caça aos defeitos. Essas técnicas, quando baseadas em espectros de fluxo de dados, utilizam as associações definição uso (ADU) para cálculo das posições no ranking. No entanto, a cobertura de dadas ADUs, muitas vezes, garantem a cobertura de outras ADUs, numa relação entre elas denominada subsunção. Na prática, a relação de subsunção significa que se uma determinada ADU é coberta, outras também são, em determinadas condições, garantidamente cobertas. Com base na propriedade de subsunção, esse trabalho apresenta um experimento no qual é avaliada a eficácia da localização de defeitos com a utilização apenas dos espectros do conjunto de ADUs não-limitadas, ou seja, o conjunto minimal de ADUs que garante a cobertura de todas as outras ADUs do software em teste. Para tal experimento são utilizados um subconjunto dos programas do repositório Defects4J, espectros de fluxo de dados e a métrica de associação Ochiai. Os resultados do experimento indicam que a maioria dos defeitos localizados por espectros de fluxo de dados podem ser localizados inspecionando apenas as ADUs não-limitadas, sobretudo quando são consideradas apenas as ADUs posicionadas nos primeiros rankings. Além disso, o número de linhas de código a serem inspecionadas pelo programador é reduzido.Debugging aims at finding and correcting software defects. To help the developer, fault localization techniques were developed using association metrics and code coverage data spectra to identify the most suspicious code snippets. They assist the developer by means of a ranking of the most suspicious spectra that guides the developer in his or her \"hunt\" for defects. These techniques, when based on data flow spectra, use definition use associations (DUA) for ranking calculation. However, the coverage of given DUAs often guarantees the coverage of other DUAs, in a relationship between DUAs called subsumption. In practice, the subsumption relationship means that if a given DUA is covered, others are also guaranteed to be covered in certain conditions. Based on the subsumption property, this work presents an experiment in which fault localization effectiveness is assessed using only the spectra of the set of unconstrained DUAs, that is, the minimal set of DUAs that may guarantee coverage of all other DUAs of the software under test. For this experiment, we use a subset of programs of the Defects4J repository, data flow spectra, and the Ochiai association metric. Our results compare the rankings produced by the set of unconstrained DUAs against those produced by all DUAs for fault localization. They indicate that most of the faults reached by DUA spectra can be found by inspecting only the unconstrained DUAs, especially when only the ADUs positioned at the first rankings are taken into account. Furthermore, the number of lines of code to be inspected by the programmer is reduced
Sobre o uso de fluxo de controle e de dados para a localizao de defeitos
Testing and debugging are key tasks during the development cycle. However, they are among the most expensive activities during the development process. To improve the productivity of developers during the debugging process various fault localization techniques have been proposed, being Spectrum-based Fault Localization (SFL), or Coverage-based Fault Localization (CBFL), one of the most promising. SFL techniques pinpoints program elements (e.g., statements, branches, and definition-use associations), sorting them by their suspiciousness. Heuristics are used to rank the most suspicious program elements which are then mapped into lines to be inspected by developers. Although data-flow spectra (definition-use associations) has been shown to perform better than control-flow spectra (statements and branches) to locate the bug site, the high overhead to collect data-flow spectra has prevented their use on industry-level code. A data-flow coverage tool was recently implemented presenting on average 38% run-time overhead for large programs. Such a fairly modest overhead motivates the study of SFL techniques using data-flow information in programs similar to those developed in the industry. To achieve such a goal, we implemented Jaguar (JAva coveraGe faUlt locAlization Ranking), a tool that employ control-flow and data-flow coverage on SFL techniques. The effectiveness and efficiency of both coverages are compared using 173 faulty versions with sizes varying from 10 to 96 KLOC. Ten known SFL heuristics to rank the most suspicious lines are utilized. The results show that the behavior of the heuristics are similar both to control- and data-flow coverage: Kulczynski2 and Mccon perform better for small number of lines investigated (from 5 to 30 lines) while Ochiai performs better when more lines are inspected (30 to 100 lines). The comparison between control- and data-flow coverages shows that data-flow locates more defects in the range of 10 to 50 inspected lines, being up to 22% more effective. Moreover, in the range of 20 and 100 lines, data-flow ranks the bug better than control-flow with statistical significance. However, data-flow is still more expensive than control-flow: it takes from 23% to 245% longer to obtain the most suspicious lines; on average data-flow is 129% more costly. Therefore, our results suggest that data-flow is more effective in locating faults because it tracks more relationships during the program execution. On the other hand, SFL techniques supported by data-flow coverage needs to be improved for practical use at industrial settingsTeste e depuração são tarefas importantes durante o ciclo de desenvolvimento de programas, no entanto, estão entre as atividades mais caras do processo de desenvolvimento. Diversas técnicas de localização de defeitos têm sido propostas a fim de melhorar a produtividade dos desenvolvedores durante o processo de depuração, sendo a localização de defeitos baseados em cobertura de código (Spectrum-based Fault Localization (SFL) uma das mais promissoras. A técnica SFL aponta os elementos de programas (e.g., comandos, ramos e associações definição-uso), ordenando-os por valor de suspeição. Heursticas são usadas para ordenar os elementos mais suspeitos de um programa, que então são mapeados em linhas de código a serem inspecionadas pelos desenvolvedores. Embora informações de fluxo de dados (associações definição-uso) tenham mostrado desempenho melhor do que informações de fluxo de controle (comandos e ramos) para localizar defeitos, o alto custo para coletar cobertura de fluxo de dados tem impedido a sua utilização na prática. Uma ferramenta de cobertura de fluxo de dados foi recentemente implementada apresentando, em média, 38% de sobrecarga em tempo de execução em programas similares aos desenvolvidos na indústria. Tal sobrecarga, bastante modesta, motiva o estudo de SFL usando informações de fluxo de dados. Para atingir esse objetivo, Jaguar (Java coveraGe faUlt locAlization Ranking), uma ferramenta que usa técnicas SFL com cobertura de fluxo de controle e de dados, foi implementada. A eficiência e eficácia de ambos os tipos de coberturas foram comparados usando 173 versões com defeitos de programas com tamanhos variando de 10 a 96 KLOC. Foram usadas dez heursticas conhecidas para ordenar as linhas mais suspeitas. Os resultados mostram que o comportamento das heursticas são similares para fluxo de controle e de dados: Kulczyski2 e Mccon obtêm melhores resultados para números menores de linhas investigadas (de 5 a 30), enquanto Ochiai é melhor quando mais linhas são inspecionadas (de 30 a 100). A comparação entre os dois tipos de cobertura mostra que fluxo de dados localiza mais defeitos em uma variação de 10 a 50 linhas inspecionadas, sendo até 22% mais eficaz. Além disso, na faixa entre 20 e 100 linhas, fluxo de dados classifica com significância estatstica melhor os defeitos. No entanto, fluxo de dados é mais caro do que fluxo de controle: leva de 23% a 245% mais tempo para obter os resultados; fluxo de dados é em média 129% mais custoso. Portanto, os resultados indicam que fluxo de dados é mais eficaz para localizar os defeitos pois rastreia mais relacionamentos durante a execução do programa. Por outro lado, técnicas SFL apoiadas por cobertura de fluxo de dados precisam ser mais eficientes para utilização prática na indústri
Graph representation for data-flow coverage and its application
O teste de fluxo de dados ajuda os testadores a projetar testes eficazes, exigindo que os testes executem sequências de comandos a partir de definições de variáveis para um ou mais subsequentes usos. Essas associações definição-uso são derivadas de grafos que modelam o comportamento do software. Um \"grafo de fluxo\" incluindo apenas caminhos que cobrem associações definição-uso, e não outros fluxos de controle, já foi definido em outro trabalho. Embora esses grafos de fluxo tenham várias vantagens sobre os grafos anteriores, quando calculados, eles omitem alguns caminhos válidos, que são necessários no uso dos grafos para descobrir relacionamentos de subsunção e geração de dados de teste. Essas omissões levam a erros nos resultados, por exemplo, no cálculo da relação de subsunção entre associações definição-uso. Este trabalho estende as soluções anteriores, introduzindo um grafo que representa todos os caminhos que cobrem uma dada associação definição-uso. A dissertação apresenta dados experimentais mostrando que este grafo pode ser gerado a um custo razoável e aplicado de forma eficiente para a descoberta da relação de subsunção de requisitos de fluxo de dados. Outras aplicações para as graphduas incluem a geração de dados de entrada e a análise de viabilidade de requisitos de teste de fluxo de dadosData flow testing helps testers design effective tests by requiring the tests to execute sequences of statements from definitions of variables to one or more subsequent uses. These def-use associations are derived from graphs that model software behaviour. A \"flow graph\" that only includes paths that cover def-use associations, and not other control flows, has been defined elsewhere. Although these flow graphs have several advantages over previous graphs, as computed, they omit some valid paths, which are needed to use the graphs to discover subsumption relationships and generate test data. These omissions lead to errors in the results, for example, in the calculation of the subsumption relationship among def-use associations. This work extends previous solutions by introducing a graph that represents all paths that cover a given def-use association. The dissertation presents empirical data showing that this graph can be generated at a reasonable cost and efficiently applied for data flow subsumption discovery. We envision other applications for graphduas such as input data generation and feasibility analysis of data-flow testing requirement
Edge-pair testing: automation and experiment
A técnica de teste estrutural é extensamente utilizada para detectar falhas em software. Porém, sem apoio automatizado é impossível sua utilização em programas desenvolvidos na indústria. O teste estrutural é realizado por meio de critérios de teste com base na cobertura de código do programa. O código do programa é comumente abstraído na forma de um grafo e a cobertura de código baseada em fluxo de controle é determinada em termos de elementos do grafo (e. g., nós e arestas). O critério de cobertura todos os pares de arestas é relativamente recente quando comparado com os critérios todos os nós e todas as arestas. Estudos apontam que o critério todos os pares de arestas apresenta uma eficácia promissora na detecção de falhas. Há diversas ferramentas de apoio à aplicação de critérios de teste estruturais, contudo, que seja de nosso conhecimento, o critério todos os pares de arestas não é apoiado por nenhuma. Este trabalho apresenta uma nova abordagem para rastrear pares de arestas com base em operações bit a bit que também é aplicável a nós e arestas. A nova abordagem foi implementada em uma ferramenta para rastreamento de nós, arestas e pares de arestas em tempo de execução. Dados experimentais indicam que todos os pares de arestas adicionam novos caminhos a serem testados a um custo de rastreamento indistinguível em comparação com os critérios todos os nós ou todas as arestas, usando operações bit a bit. Além disso, o custo da nova abordagem bit-a-bit é comparável ao custo de ferramentas utilizadas na indústria que rastreiam nós e arestasStructural testing is widely used to detect software failures and to assess test suites quality. Without automated support, though, its use on programs developed at industrial settings is hardly feasible. Structural testing is carried out by means of test criteria based on program code coverage. Program code is usually abstracted into a graph, and control flow-based code coverage is determined in terms of graph elements (e.g., nodes and edges). All edge-pairs is a relatively recent criterion when compared to all nodes and all edges criteria. Studies indicate that all edge-pairs shows promising results at detecting failures. There are several tools to support the application of structural test criteria, however, to the best of our knowledge, none of them supports the all edge-pairs criterion. We present a novel approach to track edge-pairs based on bit-wise operations that are also applicable to nodes and edges. The new approach was integrated into a tool for tracking nodes, edges and edge-pairs at runtime. Empirical data suggest that all edge-pairs adds new paths to be tested at a tracking cost is indistinguishable in comparison to criteria all nodes or all edges, using bit-wise operations. Furthermore, the cost of the novel bit-wise approach is comparable to the cost of production-grade tools that track nodes and edge
Visualization of debugging information: an empirical assessment
Depuração é a tarefa de localizar e corrigir defeitos em um programa. Apesar do esforço de pesquisa em depuração, especialmente nos últimos anos, ela ainda é realizada da mesma forma desde a década de 60, quando os primeiros depuradores simbólicos foram introduzidos. Localização de defeitos baseada em cobertura (LDC) é uma técnica de depuração promissora devido ao seu baixo custo de execução. LDC identifica os elementos mais suspeitos de um programa ao classificar linhas, métodos, classes e pacotes com maior valor de suspeição. Recentemente, ferramentas de visualização têm sido propostas para representar os valores de suspeição dos elementos de um programa. Entretanto, nenhuma delas foi introduzida em ambientes industriais e a utilização de depuradores simbólicos ainda é predominante. Nesta dissertação, foi avaliada a eficácia, a eficiência e a usabilidade de duas ferramentas de depuração, chamadas CodeForest e Jaguar, em ambientes reais. Jaguar apresenta os trechos mais suspeitos de um programa em uma lista ordenada por seus valores de suspeição. A CodeForest recebe informações de classes, métodos e blocos (conjunto de instruções executadas em sequência) suspeitos para construir uma floresta de cactus tridimensional representando o programa inspecionado. Na CodeForest, as classes são representadas como cactus, os métodos como galhos e os blocos como espinhos de um galho. Em ambas as ferramentas, os elementos do programa recebem cores que variam de acordo com o seu valor de suspeição. A questão básica respondida ao término deste trabalho é se as informações da depuração quando exibidas em uma metáfora visual melhoram a eficácia, a eficiência e a usabilidade na localização de defeitos. A eficácia e a eficiência foram avaliadas, respectivamente, pela capacidade da ferramenta direcionar o desenvolvedor ao método ou linha do defeito e o tempo necessário para localizá-los. A usabilidade das ferramentas foi avaliada por meio de um questionário baseado no modelo TAM (Technology Acceptance Model). Os resultados obtidos demonstram que a Jaguar foi mais eficaz, eficiente e com maior grau de usabilidade do que a CodeForest; entretanto, o tamanho do efeito estatístico é insignificante para a eficácia e eficiência e baixo para a usabilidadeDebugging is the task of locating and fixing defects in a program. Despite the research effort in debugging, especially in recent years, this task is still carried out in the same way since the 60s when the first symbolic debuggers were introduced. Spectrum-Based Fault Localization (SFL) is a promising debugging technique due to it is relative low execution cost. SFL pinpoints the most suspicious program elements by ranking lines, methods, classes and packages with greater suspicious values. Recently, visualization techniques have been proposed to represent the suspicious values of program elements. However, none of them have been introduced at industrial settings and the use of symbolic debuggers is still prevalent. This dissertation assessed the effectiveness, efficiency and usability of two debugging tools, called and CodeForest and Jaguar, in real environments. Jaguar presents the most suspicious elements of a program in a list sorted by suspicious values. CodeForest receives lists of suspicious classes, methods and blocks (set of statements executed in sequence) to build a three-dimensional cacti forest representing the program inspected. In CodeForest, classes are represented as cacti, methods as branches and blocks as thorns of a branch. In both tools, the program elements receive colors that vary according to the suspicious values. The basic question answered at the end of this research is whether debugging information when displayed as a visual metaphor improve the effectiveness, efficiency and usability during fault localization. The effectiveness and efficiency were assessed, respectively, by the tool\'s ability to direct the developer to the faulty method or line and the time spent to locate them. The tools\' usability was evaluated using the Technology Acceptance Model (TAM). The results show that Jaguar is more effective, efficient and presented greater usability than CodeForest; however, the statistical effect size is insignificant for effectiveness and efficiency and low for usabilit
Use of techniques and tools for vulnerability detection: a survey with members of agile software development teams
Métodos ágeis foram criados para sanar fraquezas reais e perceptíveis dos métodos tradicionais de desenvolvimento de software. Devido à pressão na entrega de produtos de software dentro do prazo, muitas vezes requisitos de segurança são pouco mensurados ou até deixados de lado. Durante o desenvolvimento ágil de software é importante detectar possíveis vulnerabilidades. Esta dissertação descreve um survey aplicado a membros de equipes de desenvolvimento de software que aplicam métodos ágeis. Para tanto, foram identificados por meio da rede de profissionais LinkedIn 110 membros de equipes ágeis que implantaram, estão em processo de implantação ou ainda irão implantar técnicas e ferramentas para detecção de vulnerabilidades. Além disso, foram entrevistados nove gerentes de equipes ágeis. O questionário e o roteiro da entrevista foram baseados em três conhecidos processos de desenvolvimento de software seguro, a saber, Processo de McGraw, OWASP CLASP e as atividades de Howard e Lipner. A coleta de dados se deu por meio de questionários e entrevistas. A análise dos resultados utilizou técnicas de estatística descritiva e análise de conteúdo. Elas indicaram os métodos ágeis mais utilizados, o uso atual das técnicas e ferramentas, as aptidões, os interesses e as necessidades em treinamento em técnicas e ferramenta para detecção de vulnerabilidades. Além disso, os benefícios obtidos com a implantação das técnicas e ferramentas, as motivações, as estratégias, as dificuldades, as limitações e as lições aprendidas foram identificadas. Os resultados indicam que existe motivação para a implantação de segurança, mas ainda não se dá atenção especial à detecção de vulnerabilidades nas equipes ágeis cujos membros participaram do surveyAgile methods were created to address real and perceived weaknesses of traditional software development methods. Due to the pressure to delivery software products on time, security requirements are often poorly addressed or even neglected. During agile software development it is important to detect possible vulnerabilities. This dissertation describes a survey applied to members of software development teams who apply agile methods. Thus, 110 members of agile teams were identified through LinkedIns network of professionals who deployed, are in the process of being deployed or will still implement techniques and tools for vulnerability detection techniques and tools were identified. The questionnaire was based on three known safe software development processes, namely, the McGraw Process, OWASP CLASP, and the activities of Howard and Lipner. Data were collected through questionnaires and interviews. The analysis of the results used techniques of descriptive statistics and content analysis. They indicated the most widely used agile methods, the current use of techniques and tools, the skills, interests and training needs of agile teams in vulnerability detection techniques and tools. In addition, the benefits of implementing the techniques and tools, the motivations, the strategies, the difficulties, the limitations and the lessons learned were identified. The results suggest that special attention is still not given to detection of vulnerabilities in the agile teams whose members participated in the surve
OAS DB: uma infraestrutura compartilhada para apoiar a pesquisa envolvendo OpenAPI
It is common knowledge the great success achieved by the Web in the last decades. Together with the rise of Web systems in general, it came the increase of the number of Web APIs. There are many specifications used to describe an Web API. One of the most popular ones is OpenAPI. This specification allows one to describe all the resources that can be accessed and manipulated through a REST Web API. An OpenAPI specification can be used to perform different kinds of analysis and verification of the service implementing the described API. A common challenge faced by researchers, however, is the lack of shared validation infrastructure or a standard benchmark. The main contribution of our research is a software artifact --- called OAS DB (OpenAPI Specifications Database) --- that aims to provide researchers and industry practitioners with a complete solution to streamline the validation of new OpenAPI related techniques and tools. OAS DB is able to generate complete OpenAPI specifications and their corresponding mock implementations. It is also both capable of injecting faults and anti-patterns in these generated specifications/mock implementations and of indicating --- through machine-readable files --- which issues and anti-patterns are present in the generated assets. We use OAS DB to assess tools relying on both static and dynamic techniques to detect faults and anti-patterns in OpenAPI specifications. Our results indicate that these tools fail to detect relevant faults and anti-patterns in the synthetic APIs generated by OAS DB, indicating that there is room to improve these tools and the ways in which they are applying static and dynamic analysis techniques. The present work also has as contributions: a) a proof of concept REST API anti-pattern detector (which we call Oasis) and b) the description of a novel REST anti-pattern not described in the literature so farJá é senso comum o grande sucesso alcançado pela Web nas últimas décadas. Junto à ascensão de sistemas Web em geral, veio também o aumento do número de APIs Web. Há muitas especificaçes usadas para descrever uma API Web. Uma das mais populares é a OpenAPI. Essa especificação permite descrever todos os recursos que podem ser acessados e manipulados por meio de uma API Web REST. Uma especificação OpenAPI pode ser usada para diferentes tipos de análises e verificaçes do serviço que implementa a API descrita. Um desafio comum enfrentado por pesquisadores, no entanto, é a inexistência de infra-estrutura compartilhada de validação ou de um benchmark padrão. A principal contribuição de nossa pesquisa é um artefato de software --- chamado OAS DB (OpenAPI Specifications Database) --- que tem por objetivo fornecer aos pesquisadores e profissionais da indústria uma solução completa para tornar mais eficiente a validação de novas técnicas e ferramentas relacionadas com OpenAPI. OAS DB consegue gerar especificaçes OpenAPI completas e as suas correspondentes implementaçes mock. É também capaz de injetar defeitos e anti-patterns nessas especificaçes/implementaçes mock geradas e também de indicar --- por meio de arquivos processáveis por software --- quais defeitos e anti-patterns estão presentes nesses arquivos gerados. Ferramentas que usam técnicas estáticas e dinâmicas para identificar defeitos e anti-patterns em especificações OpenAPI foram avaliadas usando o OAS DB. Os resultados indicam que essas ferramentas não detectam alguns defeitos e anti-patterns relevantes em APIs sintéticas geradas pela OAS DB. Esses resultados indicam que essas ferramentas e o modo como aplicam técnicas de análise dinâmica e estática podem ser melhorados. Este trabalho também tem como contribuiçes a) uma prova de conceito de dectector de anti-patterns REST (chamado Oasis) e b) a descrição de um novo anti-pattern REST ainda não documentado na literatura relevant
- …
