作为最受欢迎的开源代码仓库,GitHub以其特有的“社交编程”方式极大地促进了软件生态系统的发展。在GitHub软件生态系统中,下游项目依赖于上游项目提供的基础设施或功能组件,形成了复杂的项目间依赖关系。通过这些依赖关系,上游项目中的缺陷将其影响传递到下游项目中,形成软件生态系统中独有的跨项目缺陷。相比于项目内缺陷,跨项目缺陷影响范围更大,危害整个生态系统的健康;其处理过程更复杂,涉及多个项目开发者的协作;且由于一些影响仅暴露在下游,上游测试集无法捕获,导致其检测难度更高。随着GitHub的愈加流行和软件生态系统的高速发展,此类缺陷数量不断增加,其有别于项目内缺陷的特点导致已有的缺陷理解和分析结论以及检测修复等技术不再适用。然而当前软件生态系统和缺陷的相关工作仍缺少对该类缺陷的关注,尤其缺乏对其检测、诊断和修复过程的理解和特征总结,缺少适用于软件生态系统的跨项目缺陷检测和修复的支持技术与工具。因此,本文围绕GitHub软件生态系统中的跨项目缺陷理解和分析技术展开研究。具体而言,本文的第一项工作关注程序员处理跨项目缺陷时的应对措施,着重研究跨项目缺陷带来的两个难点:跨项目缺陷的根本原因追踪和多项目开发者协作,探索程序员在面对这两个难点时的惯常行为,并获取程序员处理跨项目缺陷时的技术与工具需求,用以启发后续工作并提供实证支持;然后,根据实证分析中获得的开发者需求,分别为提高跨项目缺陷修复质量和检测潜在跨项目缺陷设计相应的方法和工具。因而,本文的第二项工作是识别给定跨项目缺陷所影响的下游模块(方法或类)名单,以帮助开发者理解缺陷的影响范围和严重程度,从而与相应下游开发者沟通,提供令上下游满意的缺陷修复补丁;本文的第三项工作是设计适用于GitHub软件生态系统的跨项目回归测试框架,其目的是对一次上游代码修改挑选相关的下游测试用例以补充上游测试集,从而检测潜在的跨项目缺陷。本文的主要贡献总结如下:(1)为深入理解程序员如何应对跨项目缺陷,本文对其特有的表现形式——跨项目关联缺陷进行实证研究。跨项目关联缺陷是指报告到两个不同项目中具有因果关系的一对缺陷。该实证研究具体调查三个研究问题:1)跨项目缺陷根本原因追踪的难度;2)有助于跨项目根源追踪的因素;3)下游开发者配合上游修复的惯常行为。通过对GitHub上Python科学计算生态系统中的271对跨项目关联缺陷报告进行人工审查以及对116位程序员的在线问卷调查,本文总结了一系列开发者在跨项目缺陷诊断和修复过程中的惯常行为,并为缺陷追踪系统等工具的设计提出建议。(2)为识别跨项目缺陷具体影响哪些下游模块,本文提出了一个生态系统范围的跨项目缺陷影响分析方法。对于给定跨项目缺陷,已知其上游出错方法和缺陷触发条件,本方法首先通过生态系统范围的调用依赖分析识别使用该出错方法的下游候选模块(方法或类),然后通过符号分析将每个候选模块入口处到上游方法调用点的路径编码成符号约束,通过约束求解判断是否存在满足缺陷触发条件的下游模块输入。如存在,则该模块受给定缺陷影响。为验证该方法的有效性,本文实现了一个工具原型并在31个跨项目缺陷上进行实验。实验结果表明,该方法可以从25490个候选下游模块中共计找出1132个受这31个缺陷影响的模块;对于每个缺陷,平均剔除了 66.5%的不受影响模块,有效地减少了程序员的代码审查工作量。(3)为进行跨项目回归测试、检测潜在跨项目缺陷,本文提出了一个适用于GitHub软件生态系统的测试框架并设计了两步跨项目测试选择策略。测试框架由三部分组成:1)中心仓库,用以处理和存放细粒度的生态系统依赖网络、测试执行轨迹以及历史构建日志;2)两步测试挑选组件,用以挑选与一次上游修改最相关的下游项目和具体的下游测试用例;3)测试执行和反馈组件,用以生成特定于具体项目的测试脚本、执行测试并将结果通知给相关项目。两步跨项目测试选择策略首先基于项目在生态网络中的中心性和对上游被修改模块的依赖强度选择最重要的相关下游项目,然后提出基于上游方法覆盖率和基于上游文件中心性的测试选择策略,在下游项目中挑选能够补充上游测试集的测试文件。本文实现了一个GitHub集成工具,并在133个Python科学计算类项目上进行评估。对100次上游项目代码提交进行回归测试的结果表明,该测试框架能够有效地选择出可以补充上游测试集的下游测试用例。本文的研究结果有助于深入理解GitHub软件生态系统中的跨项目缺陷,所提出的支持技术与工具也能有效地帮助检测和修复此类缺陷,保障软件生态系统的健康发展。