作者：王兴亚 等
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
开发者测试试读：
前言
当前，信息需求的持续增长和信息技术的快速发展加快了软件产品的研发速度，同时也大大增加了软件产品的测试压力。以互联网、移动应用等产品为例，众多软件公司普遍采用微小改进、快速迭代、反馈收集、及时响应等手段来提高软件的迭代速度，缩短软件产品的发布流程。显然，仅仅依赖测试人员已经难以满足市场和客户对产品质量的需求，这就要求开发人员也深入参与到软件测试过程中，与测试人员共同完成软件产品的质量保证工作。在本书中，我们定义由开发者承担的与代码相关的软件测试工作为开发者测试。
本书从开发者测试出现的背景与意义、开发者所应掌握的基本和高级程序分析方法以及软件测试技术、开发者所应掌握的软件测试分析辅助工具、用于开发者测试教学和竞赛的慕测平台等多个方面对开发者测试进行系统性介绍。相信通过本书的学习，读者可以对开发者参与测试的必要性、开发者测试所涵盖的内容有初步的认识和了解，同时能够结合本书的示例及平台锻炼自己的测试能力。
本书适用于两类不同的读者：1）在高等院校学习和工作的教师和学生，本书有助于他们理解和认识测试工作承担者的责任，并为他们学习和锻炼自身的测试能力提供方向和平台；2）软件产业的开发人员、测试人员和管理人员，本书有助于他们认识开发者在测试工作中的重要性和所应承担的工作内容，以及开发者所应具备的测试技能。
本书讲述的方法是通用的，可以用于测试任何类型的计算机软件。但是，为了使读者更好地理解和学习本书的开发者测试方法，本书提供了大量Java示例代码以及面向Java的程序分析、测试工具。这些示例和工具可以在任何支持Java的操作系统（如Windows、Linux、Mac）、开发环境（如Eclipse、IntelliJ、Sublime Text）中开发、测试和运行。
本书共包含8章及一个附录，除第7章与第8章外，其他章节的内容互不相关，因而读者可选择其中部分章节进行阅读。
第1章：开发者测试概述。本章在研究和分析开发者与软件测试关系的基础上，介绍了开发者测试的定义、背景与意义。同时，本章还从静态测试与动态测试、白盒测试与黑盒测试、不同测试工具间的对比中分析得到开发者测试所涉及的方法、技术与工具。此外，本章还讨论了开发者测试技术未来的趋势，并介绍了支持开发者测试教学与竞赛的慕测平台。
第2章：程序静态分析。本章对软件静态测试的基础——程序静态分析方法进行了介绍。通过代码评审、结构分析等方法可以有效地检测出程序中的逻辑错误，而程序流程分析（如控制流分析、数据流分析）则可以更细粒度地反映程序中语句间、变量间的关联。此外，本章还介绍了辅助程序正确性证明的静态/动态符号执行方法，便于读者了解更高级的程序分析方法。
第3章：白盒测试。白盒测试要求软件内部的逻辑结构透明可见，因此更适合由软件项目的开发者来承担。本章介绍了两类主要的白盒测试方法，包括以程序内部逻辑结构为基础的逻辑覆盖测试方法和以程序路径为基础的路径覆盖测试方法。与此同时，本章还比较了不同白盒测试方法的测试强度，并介绍了用于度量程序复杂度的环复杂度方法。
第4章：程序插桩与变异测试。本章介绍了用于获取程序运行时信息的程序插桩方法，以及用于度量测试用例集缺陷检测能力的变异测试方法。对于程序插桩方法，本章详细介绍了插桩位置、类型、数量的选择方法；对于变异测试方法，本章详细介绍了变异算子的设计与选择方法。同时，本章还介绍了工具JaCoCo和PITest，以便读者体验Java程序的运行时信息收集和变异测试过程。
第5章：单元测试。单元测试是对软件基本组成单元（如方法、函数、过程）的测试。在测试过程中要完成初始状态的创建、测试结果的验证、测试资源的释放等工作，这些工作适合开发者使用代码控制开展。本章在介绍单元测试框架的基础上，进一步阐述了单元测试的各项内容，使读者能针对不同的测试对象分析、建立相应的测试模型。
第6章：集成测试。通过单元测试的软件模块并不能保证在整合后依然运行正确，因此需要做集成测试以进一步验证。本章介绍了集成测试过程、集成测试所面向的缺陷类型以及分析方法，并详细介绍了多种集成测试策略。同时，本章还讨论了不同集成测试策略的优缺点，并对它们各自的适用场景进行了分析，测试人员可据此选择合适的集成测试策略。
第7章：JUnit基础。工欲善其事，必先利其器。JUnit是开发者开展单元测试的一把利器。本章对Java单元测试框架的基本功能（如注解、测试类与测试方法、错误与异常处理、批量测试）进行了详细的介绍，使读者对JUnit的功能和适用范围有了详细的了解。本章还穿插了数个JUnit示例程序，帮助读者更快、更方便地学习Java单元测试。
第8章：JUnit深入应用。在前一章介绍JUnit基本功能的基础上，本章对JUnit的高级功能进行了介绍，包括用于提高测试代码开发效率的匹配器功能，面向Controller和Private函数的测试功能、Stup测试功能和Mock测试功能。同时，本章还介绍了JUnit与常用Java开发框架（如Ant、Maven）的集成方法，读者可据此配置来构建更方便的Java单元测试环境。
附录：慕测科技——开发者测试平台。实践练习是提高开发者测试能力的有效方法。本附录介绍了支持开发者测试教学的慕测平台，并说明了面向教师的账号注册、班级管理、考试管理等功能。同时，还对由慕测平台提供技术支持的全国大学生软件测试大赛进行了介绍，该赛事为软件测试专业的宣传及开发者测试理念的普及做出了重要贡献。第1章开发者测试概述
早期软件规模小且复杂程度低，软件测试常常包含于调试工作中，由软件开发人员完成。在当今规模化和工程化的软件研发中，为了提高生产效率和专业化程度，相关工作逐步细分，出现了专门的软件测试岗位。
为了获得更高的用户忠诚度，扩大产品市场份额，在当前移动互联网迅速普及的背景下，众多软件公司纷纷采用了微小改进、快速迭代、反馈收集、及时响应等手段来迅速改进软件产品，满足用户需求。软件的持续快速迭代需求大大压缩了软件开发的发布流程，使得一部分测试任务开始迁移，由软件开发人员担任的这部分与代码相关的软件测试工作，我们统称为开发者测试。开发者测试包括传统的单元测试、集成测试、接口测试，甚至部分与系统测试相关的任务。1.1 开发者与软件测试
开发者需要对自己开发的程序代码承担质量责任。在软件质量管理机制下，一般要求开发者首先自行对自己编写的代码进行审查和测试，并保证提交的代码已达到一定的质量标准。开发者测试中的单元测试和集成测试主要采用白盒测试方法，要求测试人员对软件代码非常熟悉。这样的测试任务由软件开发人员来做效率会更高。1.1.1 测试和调试
在软件开发过程中，开发者需要对程序进行测试和调试。测试和调试极其相关但含义完全不同。简单来说，测试是为了发现缺陷，调试是为了修复缺陷。调试往往需要依赖已有的测试信息或者补充更多测试信息，需要先找出缺陷根源和缺陷的具体位置，再进行修复以消除缺陷。而从职责上说，测试只需要发现缺陷，并不需要修复缺陷。在软件开发过程中，开发者需要同时肩负这两种职责，对自己开发的程序进行测试，发现缺陷并对其进行调试以修复缺陷。调试的过程如图1-1所示。图1-1 调试的过程
调试时如果已经识别或者找到测试中所发现缺陷的产生原因，就可以直接修复，然后进行回归测试。如果没有找到缺陷的产生原因，可以先假设一个最有可能的原因，并通过附加测试来验证这样的假设是否成立，直到找出原因为止。
调试工作是程序员能力和水平的一个重要体现。软件开发调试有时难度很大，原因如下：1）失效症状和缺陷原因可能相隔很远，高度耦合的程序结构加重了这种情况；2）失效症状可能在另一缺陷修复后消失或暂时性消失；3）失效症状由不太容易跟踪的人为错误引发；4）失效症状可能是由不同原因耦合引发的。因此，程序员有时会因为在调试程序时找不到问题所在，而使软件开发工作陷入困境。
程序调试方法多种多样，更多时候是依赖程序员的经验及其对程序本身的理解。调试方法的具体实施可以借助调试工具来完成，如带调试功能的编译器、动态调试辅助工具“跟踪器”、内存映像工具等。
回溯法是指从程序出现不正确结果的地方开始，沿着程序的运行路径向上游寻找错误的源头，直到找出程序错误的实际位置。例如，程序有5000行，测试发现最后输出的结果是错误的，采用回溯法，可以先在第4500行插桩，检查中间结果是否正确。若正确，则错误很可能发生在第4500～5000行之间。若不正确，则在第4000行插桩，以此类推，直到找出程序错误的具体位置。1.1.2 开发者测试
从履行职责、提高效率、保护源代码、方便实现等角度来说，开发者需要完成的测试工作主要集中在单元测试和集成测试阶段。程序代码开发出来之后，开发者先对自己开发的代码进行单元测试，然后再把多个已经通过单元测试的模块按照设计书组装起来进行集成测试。当然，在实践中也会出现后期的系统测试需要开发者配合甚至主导的情况。
静态测试与动态测试都是开发者需要掌握的测试方法，在实践中一般将两者结合起来使用。开发者对自己开发的程序代码进行检查，这是静态测试；而开发者运行代码，给定输入数据，检查程序能否正常运行并给出预期结果，则是动态测试。对静态测试存疑的代码部分，加强动态测试进行结果验证，是实践中常用的开发者测试策略。
白盒测试是开发者最主要的测试方法，也是在软件测试工作上体现开发者优势的地方。然而，并不是说开发者测试不需要黑盒测试方法。恰恰相反，我们建议开发者在实践中对程序代码进行等价类和边界值分析，这有助于提高开发者测试的效率和质量。而在集成测试或者配合一些复杂模块的测试中，开发者也可能会用到灰盒测试等方法。
在开发者测试中，手工测试与自动化测试都会用到。随着软件技术的发展，软件测试的自动化程度会越来越高。开发者在测试中应尽可能通过自动化测试工具来提高测试工作效率。但并不是所有测试工作都能够自动化完成，也不是所有场景都适用自动化测试。
为了提高软件质量和缩短软件项目总工期，测试常常与开发同步进行。研发人员应综合运用多种软件测试方法和技术，针对不同的测试场景合理选择测试方法和工具，并在测试时尽可能采用自动化测试工具来提高软件测试的效率。
总体上，开发者测试一般采取先静态后动态的组合方式：先进行静态结构分析、代码评审，再进行代码的覆盖性测试。利用静态分析的结果作为导引，通过代码评审和动态测试的方式对静态测试结果进行进一步的确认，使测试工作更为有效。代码覆盖测试是白盒测试的重点，通常可采用语句覆盖、分支覆盖等。对于软件的重点模块，可使用逻辑覆盖、路径覆盖、数据流覆盖等更复杂的准则。在不同的测试阶段，测试重点有所不同。在单元测试阶段，以代码审查和语句覆盖为主；在集成测试阶段，需要增加接口测试和模块集成结构分析等。1.1.3 PIE模型
软件测试的主要目的之一是发现缺陷。动态测试工作中通常会出现复杂而有趣的现象。假设某个程序中有一行代码存在缺陷，在该软件的某次运行中，这个存在缺陷的代码行并不一定会被执行。即使这存在缺陷的代码被执行，若没有达到某个特定条件，程序状态也不一定会出错。即只有在运行错误代码，并达到某个特定的条件，程序状态出错并传播出去被外部感知后，测试人员才能发现程序中的缺陷。
软件测试的一个基本模型称为PIE（Propagation-Infection-Execution）模型。PIE模型对于理解软件测试方法、测试过程、缺陷定位和程序修复等都具有重要作用。在介绍PIE模型之前，我们首先理解缺陷在不同阶段的不同名称及其含义：
·Fault（故障）：故障是指静态存在于程序中的缺陷代码，有时也称之为程序缺陷（Defect）。
·Error（错误）：错误是指程序运行缺陷代码后导致的错误状态。
·Failure（失效）：失效是指程序错误状态传播到外部被感知的现象。
针对缺陷不同阶段的性质，我们可以构建一个PIE模型来解释缺陷产生的整体过程。PIE提示我们，发现一个缺陷需要满足以下三个必要条件：
1）Execution（运行）：测试必须运行到包含缺陷的程序代码。
2）Infection（感染）：程序必须被感染出一个错误的中间状态。
3）Propagation（传播）：错误的中间状态必须传播到外部并被观察到。
上述三个条件是缺陷被检测出来的必要条件，三个必要条件组合成检测出缺陷的充分条件，即充要条件。我们不难理解，一个测试满足条件1不一定能满足条件2，即测试运行到包含缺陷的代码，但不一定能感染出错误的中间状态。一个测试满足条件2不一定能满足条件3，即测试能感染出错误的中间状态（当然也运行到了包含缺陷的代码），但不一定能成功传播出去并被测试人员发现。
为了进一步理解这些现象，以图1-2中的示例程序MY_AVG来进行说明。程序语句s4存在缺陷，循环控制变量i的初值应为0，而不是1。图1-2 一个示例程序MY_AVG
在程序的某次运行中，调用了上述代码段MY_AVG，并输入测试数据0，4，5，预期（正确）输出结果是3。程序运行到了s（条件14满足），中间变量V_sum应该为0+4+5=9。由于缺陷导致数组第一个数字“0”被遗漏，中间变量V_sum为4+5=9（条件2不满足）。但由于0的累加不影响最终结果，最终的平均值为3，与预期输出结果一致。
我们将上述程序做一下微调，缺陷依然是循环初值1，如图1-3所示。图1-3 简单修改后的示例程序MY_AVG
在程序的某次运行中，调用了上述代码段MY_AVG，并输入测试数据4，3，5，预期（正确）输出结果是4。程序运行到了语句s（条4件1满足），中间变量V_sum应该为4+3+5=12。由于缺陷导致数组第一个数字“4”被遗漏，中间变量V_sum为3+5=8（条件2满足）。但个数变量n的累加也减少了1，即n原来应该为3，现在是2（条件2满足）。这两个错误的中间状态叠加后，V_avg=12/3=8/2=4，导致最终结果正确（条件3不满足）。
PIE模型表明发现Bug并不是一件容易的事情。要全面发现软件Bug，不仅需要针对特定需求和软件特性进行测试设计，还需要学会利用不同的软件测试方法，如有效地结合使用白盒测试和黑盒测试方法。1.2 开发者测试方法与技术
软件测试方法有很多分类。本节仅介绍与开发者测试相关的分类。软件测试依据是否需要运行程序可以分为静态测试与动态测试，依据是否需要了解软件内部结构可以分为黑盒测试和白盒测试。1.2.1 静态测试与动态测试
静态测试不运行被测程序，而是手工或者借助专用的软件测试工具来检查软件文档或程序是否符合标准、度量程序静态信息、审查软件中的问题和不足，以降低软件缺陷的出现概率。在学术文献中，静态测试不归于传统软件测试，通常称为静态分析。
针对源程序的静态测试主要包括代码评审、代码结构分析、代码质量度量等。静态分析可以由单人、结对或者团队进行代码人工检查，也可以借助静态检查工具自动分析并辅助人工对分析结果进行审核。
代码评审通常在动态测试之前进行。在审查前，应准备好需求描述文档、程序设计文档、源代码清单、代码编码标准和代码缺陷检查表等。在实践中根据检查流程和操作细节不同，代码评审可以细分为代码走查、桌面检查、代码审查等。代码评审主要检查代码与设计的一致性、代码对标准的遵循情况、代码的可读性、代码逻辑表达的正确性、代码结构的合理性等方面。代码评审项目包括变量检查、命名和类型审查、程序逻辑审查和程序结构检查等。
动态测试是指通过运行被测程序，输入测试数据，检查运行结果与预期结果是否相符来检验被测程序的功能是否正确。传统的软件测试通常指的是动态测试。测试用例是动态测试中的关键所在。测试用例至少要包含两方面内容：测试输入数据和测试预期输出。动态测试通过对待测程序输入测试数据，收集实际的测试输出，并与预期输出进行对比做出结果判断。在实际应用中，一个测试用例还可能包括测试环境、测试步骤、测试脚本、历史关联等信息。测试用例信息的完善有利于测试人员运行和分析相关任务，也有利于后期软件测试及相关开发流程的自动化实施。
静态测试具有发现缺陷早、加快调试过程等优点。但即使是经验丰富的开发者，人工开展静态测试也会消耗大量时间成本。在实践中，通常采用静态测试工具，这些工具不运行程序代码，却能够在很短时间完成程序的扫描分析，因而成本很低。然而由于不实际运行程序，静态测试工具常常会产生大量误报，给审查工作带来极大的挑战。动态测试需要运行程序，成本较高，但对测试结果具有很高的确认度。我们通常采用静态测试进行代码分析，结合动态测试对静态测试结果进行筛选审查。通过动静态技术的结合，既降低了测试成本，又提高了测试精度，这是未来软件测试的发展趋势。1.2.2 黑盒测试与白盒测试
黑盒测试是不需要了解软件内部结构的测试方法的统称。待测程序被看作一个黑盒子，不考虑程序的内部结构和特性，测试者只知道该程序输入和输出之间的关系，依靠这些关系确定测试用例，然后运行程序，检查输出结果的正确性。
例如，一个程序的功能是输入一个数x，输出这个数的两倍y。如果对它进行黑盒测试，那么我们并不需要知道程序内部是使用加法（y=x+x），还是使用乘法（y=x*2），或者其他方法来求得一个数的两倍。我们只需要通过输入一个数2并看结果是否等于4这种简单易行的方法来检查程序运行结果是否正确。最常用的黑盒测试方法是等价类测试和边界值测试，想了解这方面的详细信息读者可以参阅其他测试教材或参考书。
白盒测试是需要了解软件内部结构的测试方法的统称。它把待测程序看成一个可以透视的盒子，能看清楚盒子内部的结构以及它是如何运作的。白盒测试依赖于对程序内部结构的分析，针对特定条件或要求设计测试用例，对软件的逻辑路径进行测试。白盒测试可以在程序的不同位置检验程序状态以判定其实际情况是否与预期的状态相一致。最常用的白盒测试方法是程序代码的覆盖测试，我们将在后面章节详细阐述。
黑盒测试多是动态测试，因为黑盒测试一般需要运行待测程序。白盒测试既有静态测试（如代码评审、静态结构分析等），也有动态测试（如逻辑覆盖测试等）。动态测试有可能是黑盒测试（如根据软件规格说明书进行功能测试），也有可能是白盒测试（如针对源程序进行逻辑覆盖测试）。
在黑盒测试与白盒测试之间还有一种方法，称为灰盒测试。灰盒测试是指只有部分程序代码信息的测试方法。例如，我们对程序进行反编译以后获取了部分代码信息，针对这部分代码信息，我们很难完全采用白盒测试方法。这时候通常需要结合一些黑盒测试方法以完成完整的测试。还有一类情况可采用灰盒测试方法，即在做黑盒测试时，有时候输出是正确的，但内部其实已经出错。为了进行更加完整的测试，我们不需要完整的程序代码信息，但需要对程序内部状态进行监测，借助一些白盒测试方法以辅助完成有效的黑盒测试。1.2.3 失效重现
当测试发现软件Bug，即发现了软件失效后，开发者需要重现失效以进行失效理解和缺陷修改。失效重现并不是一件容易的事情。一个软件失效除了与缺陷代码有关外，还可能有很多我们没有注意到的因素，如环境、配置等。软件失效依赖的因素有很多，有些失效出现的概率很小，但一旦满足了确切条件，失效还是会再次重现的。
失效重现是调试和缺陷修复的重要基础。我们通常要求测试人员尽可能详细地描述失效的测试步骤和失效特性，这样做一方面是为了提高失效重现的概率，另一方面是为调试提供更加充分的信息。
有些软件失效非常微妙和隐蔽，重现具有很大的难度。当我们难以重现失效时，可以考虑以下情况：首先审视那些可能被遗忘的细节，如原始数据、原始环境；还需要考虑失效是否依赖时间、内存、网络、传感器（GPS等）及其他资源；对于并发程序尤其需要考虑并发调度及其竞争条件。1.3 开发者测试工具1.3.1 静态测试扫描工具
当前存在大量静态测试（又称静态分析）工具，包括开源和非开源的工具。本小节简要介绍四种常用的开源静态测试工具Checkstyle、FindBugs、PMD、P3C。
Checkstyle是SourceForge的开源项目，通过对代码编码格式、命名约定、Javadoc、类设计等方面进行代码规范和风格的检查，有效约束开发人员更好地遵循代码编写规范。Checkstyle提供了支持大多数常见IDE的插件，本书主要使用Eclipse中的Checkstyle插件。Checkstyle对代码进行编码风格检查，并将检查结果显示在Problems视图中，开发人员可在Problems视图中查看错误或警告详细信息。此外，Checkstyle支持用户根据需求自定义代码评审规范，用户可以在已有检查规范如命名约定、Javadoc、块、类设计等方面的基础上添加或删除自定义检查规范。具体页面如图1-4所示。图1-4 Checkstyle页面展示
FindBugs是由马里兰大学提供的一款开源Java静态代码分析工具。FindBugs通过检查类文件或JAR文件，将字节码与一组缺陷模式进行对比来发现代码缺陷，完成静态代码分析。FindBugs既提供可视化UI界面，同时也可以作为Eclipse插件使用。在安装成功后会在Eclipse中增加FindBugsperspective，用户可以对指定Java类或JAR文件运行FindBugs，此时FindBugs会遍历指定文件，进行静态代码分析，并将代码分析结果显示在FindBugsperspective的Bug Explorer中。此外，FindBugs还为用户提供定制BugPattern的功能，用户可以根据需求自定义FindBugs的代码评审条件。FindBugs运行结果如图1-5所示。图1-5 FindBugs结果页面展示
PMD是由DARPA在SourceForge上发布的开源Java代码静态分析工具。PMD通过其内置的编码规则对Java代码进行静态检查，主要包括对潜在的缺陷、未使用的代码、重复的代码、循环体创建新对象等问题的检验。PMD提供了与多种Java IDE的集成，如Eclipse、IDEA、NetBean等。PMD同样支持开发人员对代码评审规范进行自定义。PMD会在其结果页中将检测出的问题按照严重程度依次列出，如图1-6所示。图1-6 PMD结果页面展示
P3C项目组是由阿里巴巴开发爱好者自发组织形成的虚拟项目组，他们根据《阿里巴巴Java开发手册》实现了一个Java开发规约插件P3C，用于扫描代码中的潜在隐患。如图1-7所示，在扫描后，P3C可将代码中不符合规约的部分按Blocker/Critical/Major三个等级进行显示。P3C具有良好的可扩展性，支持在Intellij IDEA、Eclipse等开发环境中部署和使用。图1-7 P3C规约提示1.3.2 测试覆盖分析工具
覆盖是开发者测试重要的工作度量和测试引导方式。本小节简要介绍一下常用的Java开源测试覆盖率工具JaCoCo、JCov和Cobertura。
JaCoCo（Java Code Coverage）是一种分析单元测试覆盖率的工具，使用它运行单元测试后，可以给出代码中哪些部分被单元测试测到了，哪些部分没有被测到，并且给出整个项目的单元测试覆盖情况百分比，看上去一目了然。JaCoCo是作为EMMA的替代品被开发出来的，可以看作EMMA的升级版，它可以集成到Ant、Maven中，也可以使用Java Agent技术监控Java程序，并提供了各种版本插件以供Eclipse、IntelliJ IDEA、Gradle、Jenkins等平台使用。Eclipse使用不同的颜色来表示测试结果中的不同情况，如图1-8所示。图1-8 不同颜色表示不同覆盖情况
在图1-8中我们可以看到，JaCoCo将代码进行不同的着色表示不同的覆盖情况：标注红色表示测试未覆盖，标注绿色表示测试已覆盖，标注黄色表示分支测试部分覆盖（if、switch）。同时JaCoCo具备完整的图形页面来进行分数的展示，如图1-9所示。图1-9 JaCoCo分数展示页面
JCov由Sun JDK开发，用于收集与测试套件生产相关的质量指标。自1.1版本开始，JCov就可以对Java代码覆盖进行测试和报告了。JCov由Java实现，它提供了一种方法来测量和分析Java程序的动态代码覆盖率。JCov提供了指令覆盖、分支覆盖、方法覆盖和未被覆盖运行路径的显示功能，也能够显示一个程序的源代码注释覆盖信息。从测试的角度来看，JCov对于确定测试套件的运行路径是非常有用的。JCov支持JDK 1.0及更高版本（包括JDK 8）、CDC/CLDC 1.0及更高版本，以及JavaCard 3.0及更高版本的应用程序。JCov在易用性上稍差，主要是通过运行Ant来进行相关的配置，不过JCov同样具备可视化的HTML展示页面，如图1-10所示。图1-10 JCov结果展示页
Cobertura是一款开源测试覆盖率统计工具，它与单元测试代码结合，标记并分析在测试包运行时运行了哪些代码和没有运行哪些代码，以及所经过的条件分支，从而测量测试覆盖率。除了找出未测试到的代码并发现Bug外，Cobertura还可以通过标记无用的、运行不到的代码来优化代码，最终生成一份美观详尽的HTML覆盖率检测报告，如图1-11所示。图1-11 Cobertura结果展示页
Cobertura虽然没有提供Eclipse、IntelliJ IDEA等平台的定制插件，但也对Maven、Gradle、Ant提供了支持。同时Cobertura提供了可定制的包、类、函数过滤方法，因而可以定制相应的测试部分，如图1-12所示。图1-12 Cobertura过滤结果展示页1.4 开发者测试趋势1.4.1 软件开发和运营困境
很多组织将开发和系统管理划分成不同的部门。开发部门的驱动力通常是频繁交付新特性，而运营部门则更关注IT服务的可靠性和IT成本投入的效率。两者目标的不匹配在开发与运营部门之间造成了鸿沟，从而减慢了IT交付业务价值的速度。
开发人员经常不考虑自己写的代码会对运营造成什么影响。他们在交付代码之前，很少邀请运营人员参与架构决策或代码评审；开发人员对配置或环境进行修改之后，也经常会因为没有及时与运营人员沟通，导致新的代码不能运行；开发人员在自己的机器上手工修改配置，却有记录所有需要的步骤；而运营人员想找到需要的参数配置，通常需要尝试很多不同的参数组合。
开发人员倾向于使用有利于快速开发的工具，如对代码修改实现更快的反馈、更低的内存消耗等。这样的工具集与运营人员面对的目标运行时环境非常不同，后者对稳定性和性能的要求远胜于灵活性。由于开发人员平时使用桌面计算机，他们倾向于使用为桌面用户优化的操作系统，而生产环境的运行时系统通常都运行在服务器操作系统上。在开发过程中，系统在开发者的本地机器上运行；而在运营过程中，系统经常分布在多台服务器上，如Web服务器、应用服务器、数据库服务器等。
开发是由功能性需求（通常与业务需求直接相关）驱动的，运营是由非功能性需求（如可获得性、可靠性、性能等）驱动的。运营人员希望尽量避免修改功能，从而降低满足非功能性需求的风险；如果运营人员拒绝了小的修改，但给定时间段内需要修改的总量不变，那么每次变更的规模就会变大；变更规模越大，风险也越高，因为其中涉及的区域越多；而由于运营人员尝试避免变更，新功能流入生产环境的速度因此被延缓，从而延缓了开发人员将特性交付给用户使用的速度。运营人员可能对应用程序内部缺乏了解，从而难以正确地选择运行时环境和发布流程；而开发人员可能对运行时环境缺乏了解，从而难以正确地对代码进行调整。
企业在开发过程中希望产品更新更小、更频繁，从而降低更新风险。因此，开发人员应更多地控制生产环境的复杂度，更多地以应用程序为中心来理解基础设施。产品的流程尽量定义得简洁明了，所有流程尽量自动化，以促进开发与运营的协作。
一般而言，当企业希望将原本笨重的开发与运营之间的工作移交过程变得流畅无碍时，他们通常会遇到以下三类问题：
1）发布管理问题：很多企业有发布管理问题。他们需要更好的发布计划方法，而不只是一份共享的电子数据表。他们需要清晰了解发布的风险、依赖、各阶段的入口条件，并确保各个角色遵守既定流程行事。
2）发布/部署协调问题：有发布/部署协调问题的团队需要关注发布/部署过程中的运行。他们需要更好地跟踪发布状态，更快地将问题上升，严格执行流程控制和细粒度的报表。
3）发布/部署自动化问题：这些企业通常有一些自动化工具，但他们还需要以更灵活的方式来管理和驱动自动化工作——不必要将所有手工操作都在命令行中加以自动化。在理想情况下，自动化工具应该能够在非生产环境下由非运营人员使用。1.4.2 DevOps介绍
在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备DevOps能力的组织中，应用程序发布的风险很低。与传统大规模、不频繁的发布（通常以季度或年为单位）相比，敏捷方法大大提升了发布频率（通常以天或周为单位）。与传统的瀑布式开发模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。由于经常部署，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长。
DevOps是Development和Operations的组合词，通常看作敏捷开发的延续，其重视软件开发人员（Dev）和IT运维技术人员（Ops）之间的沟通合作，将敏捷精神由开发阶段拓展到构建、测试、发布等过程，达到快速响应变化、交付价值的目的。DevOps依靠强有力的发布协调人来弥合开发与运营之间的技能鸿沟和沟通鸿沟；采用电子数据表、电话会议、即时消息、企业门户（WiKi、SharePoint）等协作工具来确保所有相关人员理解变更的内容并全力合作。同时，DevOps还采用了强大的部署自动化手段以确保部署任务的可重复性、减少部署出错的可能性。
传统组织将开发、IT运营和质量保障设为各自分离的部门。部门隔离带来管理简单的同时，给软件开发整体生产链带来极大挑战——开发的内容难以完成有效测试和运维。在互联网环境下如何采用新的开发模式是一个重要的课题。对于以前的开发模式，开发和部署不需要IT支持或者QA深入的跨部门支持，而现在我们需要极其紧密的多部门协作。DevOps不是简单的开发与运维的结合，它是一套针对这几个部门间沟通与协作问题的流程和方法。
DevOps的引入对产品交付、测试、功能开发和维护产生意义深远的影响。在缺乏DevOps能力的组织中，开发与运营之间常常存在信息鸿沟：运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。
DevOps经常被描述为开发团队与运营团队之间更具协作性、更高效的关系。由于团队间协作关系的改善，整个组织的效率因此得到提升，伴随频繁变化而来的生产环境的风险也能因此降低。1.4.3 DevOps中的开发者测试
在当前环境下，基于敏捷的要求，企业不仅仅要求传统的测试人员进行测试，开发者也需要对自己的代码负责，进行一定水准的测试。开发者在本地进行测试后，应将代码提交服务器进行自动化的集成测试。相较于以往的测试，现在的开发者测试需要更多的依赖多样化的自动化测试工具，使用自动化测试来提高开发者测试的效率。自动化测试能够有效提高开发和运维的效率，开发者可以很快获得自动化测试的结果，并根据自动化测试的情况对自己的代码进行更正。
作为测试人员，简单测试工具的使用已经无法满足现阶段的需求。测试人员需要充实自己的知识库。无论是静态扫描还是动态的覆盖检测，测试人员都需要有一定的了解，并将自动化测试工具集成到现有系统之中，减轻自身压力，提高测试效率，同时也提高了开发效率。
在这个快速变化发展的时代，任何一款产品想要在市场中具备竞争力，必须能够快速适应和应对变化，并要求产品开发过程具备快速持续的高质量交付能力。而要做到快速持续的高质量交付，自动化测试必不可少。同时，自动化测试也不是用代码或者工具替代手工测试那么简单，它有了新的特点和趋势：针对不同的产品开发技术框架有着不同的自动化技术支持，针对不同的业务模式需要不同的自动化测试方案，从而使得自动化测试有着更好的可读性、更低的实现成本、更高的运行效率和更有效的覆盖率。
自动化测试工具云集，但实践自动化应避免冲动，需要重视以下几点：综合考虑项目技术栈和人员能力，采用合适的框架来实现自动化；结合测试金字塔和项目具体情况，考虑合适的测试分层，能够在底层测试覆盖的功能点一定不要放到上层的端到端测试来覆盖；自动化测试用例设计需要考虑业务价值，尽量从用户真实使用的业务流程/业务场景来设计测试用例，让自动化优先覆盖到最关键的用户场景；同等看待测试代码和开发代码，让其作为产品不可分割的一部分。
测试环境的准备在过去是一个比较麻烦和昂贵的工作，很多组织由于没有条件准备多个测试环境，导致测试只能在有限的环境下进行，从而可能遗漏一些非常重要的缺陷，总之测试的成本和代价很高。随着云技术的发展，多个测试环境不再需要大量昂贵的硬件设备来支持，加上以Docker为典范的容器技术生态系统也在逐步成长和成熟，创建和复制测试环境变得简单多了，成本也大大降低。
另外是大量开源工具的出现，这些工具往往都是轻量级的，简单易用，相对于那些重量级的昂贵的测试工具更容易被人们接受。测试工作有了这些开源工具的帮助将更加全面、真实地覆盖到要测试的平台、环境和数据，将加快测试速度、降低测试成本。更重要的一点，有了这些工具，测试人员能够腾出更多的时间来做测试设计和探索性测试等更有意思的事情，使得测试工作变得更加有趣。在企业级应用中，对组件进行良好的测试至关重要，尤其是对于服务的分离和自动化部署这两个关系到微服务架构是否成功的关键因素，我们更需要合适的工具来对其进行测试。1.5 慕测开发者测试
作为测试教育的推广者，慕测提供了一整套包含JaCoCo覆盖工具、PITest变异工具及其他分析功能的开发者测试方案，以便广大测试专业的师生有效提高开发者测试专业水准。首先我们进入慕测官网（www.mooctest.net），并进行相应的注册和登录，如图1-13所示。图1-13 进入慕测官网
进行登录操作后可以看到工具下载的选项，如图1-14所示。
用户根据计算机系统的版本和自身计算机的配置情况选择不同的Eclipse版本进行下载，用户也可以单独下载插件安装到本地Eclipse，如图1-15所示。
配置好Java环境并解压运行Eclipse.exe，如图1-16所示。
除了下载Eclipse外，正常运行慕测的插件还需要JDK和Maven环境的支持。JDK的配置较为简单，下面介绍一下Maven的安装配置，用户需要登录Maven官网（http://maven.apache.org），下载Maven最新版本的压缩包，并解压到本地，如图1-17和图1-18所示。
在完成下载解压操作后，还需配置环境变量来使Maven失效，环境变量的配置如图1-19所示。图1-14 慕测客户端下载目录图1-15 下载系统对应版本Eclipse图1-16 解压并运行Eclipse图1-17 Maven最新版本压缩包下载图1-18 解压Maven到本地目录图1-19 Maven环境变量的配置
其中，MAVEN_HOME是用户下载解压的Maven地址。在完成基础环境的配置后，用户即可使用Eclipse的慕测插件来完成慕测网站的练习。
学生用户登录慕测网站后，单击“参加练习”按钮，进入练习界面，如图1-20所示。图1-20 进入个人的练习页面
用户单击练习名称以进入具体练习页面，选择“查看详情”和复制个人密钥以登录Eclipse中的慕测插件，如图1-21所示。图1-21 查看及复制个人密钥
打开Eclipse，在菜单栏选择MoocTest→Login目录，如图1-22所示。图1-22 进入Eclipse的登录目录
系统会提示清空Eclipse原有项目，如图1-23所示。图1-23 清空Eclipse的原有工作目录
在清空现有工作目录之后，系统提示输入登录密码，如图1-24所示。图1-24 输入复制的密钥
在输入密码登录之后，系统会提示是否登录成功，如图1-25所示。图1-25 系统提示登录是否成功
进入Mooctest目录，选择Download下载测试题，如图1-26所示。图1-26 下载最近的测试题
题目下载完成后会自动更新到Eclipse的工作目录，如图1-27所示。图1-27 系统自动更新试题到工作目录
在程序编写完成后，选择MoocTest→Run and Submit，运行程序并提交到服务器，如图1-28所示。图1-28 程序编写完成后进行运行并提交
在运行提交完成后，慕测插件会计算出相应的分数并返回提交结果，如图1-29所示。图1-29 分数展示和结果返回
试读结束[说明：试读内容隐藏了图片]