[pt] Os elementos de código geralmente mudam ao longo da evolução do sistema, o que implica em uma eventual degradação estrutural do código fonte. Sintomas recorrentes de tal degradação são chamados anomalias de código. Estudos sugerem que quanto mais anomalias de código afetam um sistema, mais alta se torna a propensão a bugs dos elementos de código. Para lidar com tal degradação da qualidade estrutural do código, desenvolvedores geralmente aplicam refatorações no código fonte. No entanto, aplicar refatorações pode não ser suficiente para reduzir a propensão a bugs dos elementos de código degradados. Um estudo recente sugere que refatorações induzem bugs frequentemente. No entanto, os autores não analisam se o código refatorado está, de fato, diretamente relacionado à introdução de bugs. Com isso, nesta dissertação, realizamos dois estudos longitudinais de múltiplos projetos para avaliar a propensão a bugs do código refatorado. Nossa metodologia teve como objetivo abordar várias limitações de estudos anteriores. Por exemplo, definimos duas propriedades complementares da propensão a bugs do código refatorado, sendo elas, frequência e distância. Enquanto a primeira propriedade quantifica a frequência com que um código refatorado está relacionado a bugs que emergiram no código fonte, a distância quantifica o quão próximo um bug surge depois que uma refatoração é aplicada. Nosso primeiro estudo tem como objetivo avaliar a propensão a bugs de refatorações isoladas. Primeiro, nossos resultados mostram que 80 porcento dos elementos degradados que se tornaram bugs não foram previamente refatorados. Este resultado implica que um código refatorado é menos propenso a bugs do que um código não refatorado. Em segundo lugar, em 75 porcento das vezes um bug surge depois de 7 mudanças feitas a partir da operação de refatoração, o que geralmente corresponde à 3 meses nos projetos analisados. Nosso segundo estudo tem como objetivo avaliar a propensão a bugs de refatorações em lote, ou seja, refatorações aplicadas em sequência. Nossos resultados mostram que, na maioria dos casos, o código refatorado em lotes é mais resiliente à introdução de bugs do que o código refatorado por meio de refatorações isoladas. / [en] Programs often change along the system evolution, which implies an eventual code structure degradation. Recurring symptoms of such degradation are code smells. Studies suggest that the more frequently code smells affect a system, the higher becomes the bug-proneness of the code elements. To tackle code structural quality degradation, developers often apply refactorings on smelly program elements. However, applying refactorings might not suffice to reduce the bug-proneness of such degraded program elements. Previous empirical studies do not systematically analyze the bug-proneness of refactored code. Even though a recent study suggests that refactoring induces bugs frequently, the authors do not analyze to what extent refactored code is indeed closely related to the bug occurrence. Thus, in this dissertation, we conducted two longitudinal multi-project studies to assess the bugproneness of refactored code. Our methodology aimed to address various limitations of previous studies. For instance, we have defined two complementary properties of the bug-proneness of refactored code, i.e., frequency and distance. While the former quantifies how often a refactored code is related to emerging bugs, the latter quantifies how close a bug emerges after a refactoring has been applied. The quantitative analysis of such properties was complemented by a manual analysis of refactorings closely related to the bug occurrence. Our first study aims at assessing the bug-proneness of code refactored through isolated refactorings, i.e., a single refactoring operation not performed in conjunction with other refactoring operations. This study reveals that 80 per cent of the smelly elements that became buggy were not previously refactored. This result suggests the refactored code is much less bug-prone than non-refactored code. Moreover, in 75 per cent of the times, a bug emerges in 7 changes far from the refactoring operation; this amount of changes usually corresponds to 3 months in the analyzed projects. Our second study aims at assessing the bug-proneness of code elements refactored through batch refactorings, i.e., a sequence of inter-related refactoring operations. Our results show that code refactored through batches is often more resilient to the introduction of bugs as compared to code refactored through isolated refactorings.