& & & 为什么我在这里主要讨论迭代式软件开发？本文在此抛开千篇一律的理论，拟就根据多年的实践，总结出一套比较务实、可操作性强的方法，以期望在有限的资源下确保软件质量得到较大保证。一家之见，纰漏之处还请大家多多指正。
迭代式软件开发模式简要流程如下：
& & & & 上图绿色大框内，我们就称之为一个迭代周期。每一个迭代，都可以形成一个可交付的小版本。事实上，每一个迭代周期内，对于编码和测试也可以进行多次迭代。通过快速发布测试构建的方式，验证开发完成的新功能，再通过测试发现问题来驱动开发人员对软件进行修改完善，循环往复。即：根据开发情况有针对性地组织测试，根据测试结果反作用于开发人员去完善软件质量。以这种小步快跑的方式，经过若干测试构建后，软件质量可以在较短时间内达到稳定状态。
质量保证，需要系统性的方法。那么在迭代式开发的各个阶段，都需要怎样的措施呢？
& & & & 这个阶段的主要工作是需求制定与评审。该阶段的工作分三步走：收集原始需求&-&制定产品需求&-&&产品需求评审。具体说来，首先我们通过各种渠道收集原始需求，由于原始需求多半是概念性的、模糊的，不能直接用来指导开发工作，所以需要进行归类、筛选，整合为产品需求。基本原则是，结合当前开发产品的特性，争取以最小的改动以及最大的可扩展性来制定产品需求。降低风险，同时提高灵活性。经验告诉我们，在需求没有考虑透彻的情况下，不要贸然开始设计并实现，可能导致大量返工，费时费力。产品需求制定好后，需要进行评审，一定不要觉得浪费时间而不去评审，磨刀不误砍柴工嘛！
& & & & &这个阶段的主要工作是将产品需求转化为设计需求，指导后续的编码工作。软件行业有一名老话是：软件质量是设计出来的，对于迭代式开发也是如此。设计的好坏直接决定了软件质量的高低。设计需求一般阐述了产品需求的详细设计方案，包括页面布局、数据结构、算法以及易用性、安全性、可扩展性、健壮性和性能等诸多方面的设计思路。即使让不同的开发人员根据设计需求来进行编码，开发出的功能也八九不离十。有此可见，设计需求是非常必要的。也就是说，我们在正式编码前，必须针对需求写出相应的设计文档来指导后续的编码工作。这样做有两大好处：一是在编码之前就充分预见到将来可能遇到的问题，可以尽早规避风险；二是为开发工作搭好框架，降低因开发人员的差异导致开发过程的不确定性，避免出现&一千个人心中有一千个对需求的理解&。
& & & & &这个阶段的主要工作是严格按照设计需求来完成编码，并组织进行代码评审。每一行代码都是软件大厦的一砖一瓦，我们拒绝豆腐渣工程，所以我们重视每一行代码。进行代码评审可以有效保证代码质量，借助一些IT管理工具可以轻松进行代码评审和代码管理。笔者曾经使用过青铜器RDM软件来做代码评审（CodeReview），十分方便。代码评审的重点应该是对程序结构的审查，发现深层次的软件错误，而不要停留在表面。同时，建议大家在做代码评审时，以代码的一个&提交&为单位进行评审。这样做的前提是，每个&提交&里包含相对完整的功能。对于迭代式开发，我们要尽量保证，每一个编码-测试迭代里，都要完成相对独立、可测试性强的功能点。
& & & & 测试实质上是一种鉴定性的工作，是对软件质量的鉴定和最后一道把关。这个阶段的主要工作是，在每一个测试构建中，尽可能多地覆盖需求点，并根据轻重缓急合理安排测试优先级，尽可能将影响较大的缺陷提前暴露出来。测试优先级的安排应遵循以下原则：
& & & &a、先测试经过变更的部分，然后测试没有变更的部分
& & & &b、先测试程序的核心功能，然后测试一般功能
& & & &c、先测试逻辑性的功能，然后测试业务性的功能
& & & &d、先测试常规情况，然后测试异常情况
& & & &e、先测试功能，然后测试性能
& & & &按照上述原则进行测试，可以更快地发现更多软件中的严重错误，这是使软件能尽快稳定下来的一个关键因素。除此以外，在每一个迭代周期结束之前还要进行系统测试。
& & & &编码-测试的不断迭代，保证了每个测试构建里的新功能没有问题，但整个软件系统的质量还没有得到充分验证，系统测试就是为此而生。在版本发布前的最后冲刺阶段，&车轮战&是很管用的一个手段，即：调集测试人员、开发人员等全面参与测试，将这些人员分为若干个小组，每个小组分别对系统进行测试。每个测试模块由多人进行测试，可以有效降低缺陷的遗漏率。但需要注意的是，开发人员应该避免测试自己开发的功能，即进行交叉测试。
& & & &软件质量保证的实质是，使用一些流程、方法来管控软件开发过程，从而使最终交付的软件产品质量得到最大程度的保证。同时，相信大家可以看出，在整个产品开发过程中会产生很多数据，如需求、设计文档、代码、测试用例、缺陷等。使用IT管理工具可以有效提高工作效率，青铜器RDM全面实现CodeReview+Testlink + Mantis功能组合，可以管理需求、测试用例、缺陷、代码评审等，对于小规模团队，已经足够用了。
阅读(...) 评论()[译]Quora是如何维持高质量代码的
招聘信息：
原文链接：译者：—程慧一个高质量的代码库可以加快长期开发的速度，因为它会使得迭代、协作和维护更加容易。在Quora，我们十分重视代码库的质量。除了会取得收益之外，要维护高质量的代码，会带来一大笔间接费用，还会牺牲实际开发周期。很多人发现，实际产生的收益很难抵消这一间接费用，这时人们会面临两个选择：要么以低质量代码提升开发速度，要么维护高质量代码而牺牲开发速度。而对于初创公司来说，他们希望开发速度能快一些，所以就不得不使用低质量的代码。我们开发了一系列工具和流程，这样就可以在维护高质量代码库的同时，提升开发的速度。在这篇文章中，我们将会介绍关于保证代码质量的一些方法，以及一些平衡这两方面的具体案例。维护高质量代码的目标维护高质量代码主要的好处在于能够长期推动开发速度，这也是我们所关注的重点。通过编写清晰代码而产生的短期成本，就可以换来长期的收益。记住这一点，然后下面是四点基本原则，我们发现对代码质量非常有帮助：Quara的代码质量基本原则1. 代码的阅读和理解都要很容易——现在的情况是更多的时间用在了代码的阅读上，而不是代码的编写上。实际上，应该把阅读的时间减少，即便这样意味着需要花费更多的时间来写代码。2. 代码的不同部分需要有不同的质量标准——不同的代码行需要有不同的使用时间、范围、被破坏的风险、被破坏后造成的成本及其修复的成本，等等。总体来讲，这些对长期迭代速度的影响不同，所以执行一个统一的质量标准是不合理的。3. 代码质量的间接费用是可以缩减的——维护高质量成本的间接费用一般是可以节省的，这可以通过使用自动化、更好的工具、更好的流程和培训更优质的开发人员来实现。4. 代码库一致性很重要——保持整个代码库的一致性是十分有价值的，即便这意味着有一部分代码不能是最优的。一个不一致的代码库是很难阅读和理解的（见第一点），也很难编写，很难通过自动化工具进行优化。下面，我来介绍几个我们将这几点原则用于实际开发的例子。提交后code review我们代码库的代码变更需要从六个维度进行评估——正确性、隐私、性能、架构、复用性和风格。读代码是code review的关键部分，所以说，code review在提升代码可读性方面起着至关重要的作用。但是有一点不好的是，code review同样会减缓开发速度。比如说，提交前code review在行业中目前是比较常见的，其中代码必须在推送之前就进行审查和修改。这样的话，即使是每一轮审查只需要2天的时间，这样重复2-3轮，也会耽误开发人员一周的时间，这是严重的时间浪费。在Quora，我们主要做的是提交后code review。也就是说，代码首先进入，然后再找人进行code review。为了让你对这一工作的规模有个认识，举个例子，昨天我们48个人总共推送了187次代码。提交后review是很好的办法，因为它解放了开发人员，可以去做其他的工作。code review人员也可以更好的管理自己的时间，可以在他们方便的时候做代码审查，而不是非得匆忙的完成这一工作，以便不影响其他人的工作。过程合理的话，预计代码审查一周内可以完成，而实际上大部分情况下，一到两天就可以完成。之所以说一周的时间，也是经过仔细考虑的，因为一周足够长，可以允许审查人员灵活安排，而一周的时间又有点短，因为它需要将不好结果的影响最小化，比如说有人读了代码之后将不好的代码在整个代码库中进行传播。实际还有这样一层原因，很多的开发人员都是按周进行个人工作安排的。我们之所以可以做提交后code review，是因为我们相信我们的每一位开发人员，我们选择的都是最优秀的人才，并且我们在他们的代码质量培训/工具方面投入了大量资金。这也督促我们对代码进行更好的测试，而好的测试能帮助检测代码的准确性，甚至在任何code review工作开始之前就可以检测。对此，我们采用的是，一个稳健的、高配置的审查工具。我们对它做了几点改进，这样就能与我们的提交后code review工作流更好的配合。比如说，我们构建了一个命令行工具，可以将代码推向生产阶段，并提出代码审查请求。有了该工具，Phabricator的diff就可以继续工作，而无需去修复那些commits。所有这些说明，对于不同类型的代码问题，我们有不同的代码审查标准。如果说我们事先发现了某一个潜在错误，问题比较大，可能会带来很大影响，那么我们会转而执行提交前审查，而不是平常的提交后审查。这方面的几个例子：1. 涉及用户隐私和匿名的代码。2. 涉及核心的抽象类（abstraction），因为很多其他的代码都可能依赖于它。3. 涉及基础设施的某些部分，其有些错误可能会导致宕机的风险。当然这还取决于开发人员如何决策——如果他们想要对某些代码进行提交前审查，从而从中获取更多想法，这也是可以的，而不用非得采用平常的提交后code review，只不过这种情况比较少见。code review任务分派为了做好code review，每一个变更都应该由有着相关经验的人员来审查。如果这些code review人员能负责“维护”这些他们审查过的代码的话那就更好了，这样他们可以获得一定物质报酬，进而形成长期的交易关系。我们之前实施了一个简单的系统，其模块和目录层级代码的“所有权”只需要在文件开头赋予一个元标签（meta tag）就可以指定了。比如：__reviewer__ = 'vanessa, kornel'如果某commit要对文件做一些修改，其reviewer就会根据文件（或结构树【ancestor tree】），进行分析，并自动作为reviewer添加到commit中。我们针对code review任务的分派或者说路由选择还有一些其他的规则，比如说，如果没有reviewer的话，一个数据科学家可自动作为一个reviewer添加到启动A/B测试的commit中。实际上我们已经搭建了一些工具，可以让我们更容易的制定更多这类自定义的“路由”规则。举个例子，如果我们想做，那就很容易就能增加一个规则，可以将某一个新任务所有的commits都路由指派给相应的人员。这样的一个智能系统，将所有的commits都分配给合适的人员进行代码审查，能有效减轻开发人员的负担，否则他们还需要四处寻找合适的审查人员，还要确保大部分的审查人员否能认真审查每条commit。测试测试对我们的开发流程来说是非常重要的一步，我们写了很多的单元测试、功能测试和UI测试代码，覆盖很大的测试范围。而一个综合性测试可以让开发人员并行工作，工作进行的更快，而不用担心会破坏现有功能。我们投入了大量时间来制定测试框架（建立在之上），使其容易使用、可快速应用，从而降低编写测试代码的间接费用。我们还开发了几项工具，可以实现测试的自动化。我们之前发布了一篇关于“”的文章，描述了一个中心服务器，可以在部署任何新代码之前运行所有测试。该测试服务器可以并行运行，这样的话运行所有的测试只需要不到5分钟的时间。这样的快速运转可以激励人们经常性的编写和执行测试程序。我们有一个叫做“test-local”的工具，只能识别和执行代码工作副本的测试变更相关的测试文件。为了能做的更好，我们的测试还需要进行模块化（这能进一步帮我们在测试失败的时候进行快速调试）。为了确保好的测试代码能得到期望的性能，我们维护了一个共享文档，描述了编写测试代码相关的最佳实践。这些指导方针在代码审查过程中会被严格执行。同code review一样，我们对不同类型的变更也有不同的测试标准，对测试范围有更高的要求，尤其是变更成本很高的情况。所有这些系统使得我们能够从写测试代码的过程中获取最大收益，可以以很小的间接费用节省很多的开发周期。代码质量指南我们非常热衷于共享代码质量标准的指南，它可以帮我们做很多事情：① 作为新开发人员培训的很好的工具。② 与整个团队分享每个人的智慧和最佳实践。③ 降低开发和代码审查过程的间接费用。比如说，我们讨论一次就可以得出一些有价值的结论的话，那么再在每次code review时讨论代码行应该是80个字符串还是100个字符串就完全没有意义了。除了针对不同语言的语法风格指南，我们还有一些针对抽象事务的指导，比如如何写一个好的测试用例，或者如何做出更好的模块架构，从而提高工作效率。这些指南不是一成不变的，是随着我们对不同的过程有了更深的理解而不断发展的。我们还有很多重构的工具（一些开源工具比如，还有一些内部开发的工具），以备我们改变指南的时候需要重新“修改”所有的历史代码。旧代码的清理一个快速发展的团队会尝试很多不同的工具，当然其中不乏有一些可以用而有一些不可用。到最后，任何一家快速发展的公司，随着时间的推移其代码库都会开发很多多余的东西，而这些可能永远都不会再用，放在那里只会使很多东西变得混乱。清理这些废弃代码可以使得代码库更健康的运行，还能提升开发的速度。我们会定期组织“清理周”，对这些多余代码进行清理。在清理周内，某一些团队或者有时会发动整个公司专门来清理旧代码。这种定期的清理模式可以降低在“正常工作”和“清理工作”之间来回转换的成本，还能使得清理工作更加社交化，更加有乐趣。代码库有些部分会比其他部分相对更好清理一些。同样地，清理代码库的不同部分会对开发速度产生不同的影响。为了能更好的利用好旧代码清理的时间，我们在考虑成本的基础上优化了相关模块，来进行清理工作，以及衡量清理工作对未来开发速度的影响。Linting我们很可能会低估在某一实例中不遵循上述代码质量指南（比如说docstring的格式或代码行长度）所造成的成本，但事实上成本的确是增加了。同时，要记住各种各样的规则并应用，也是一件很烦的事情，尤其是规则还在不断增加。最终造成的结果就是，很多人都选择不再遵循这些指导方针。我们开发了一个内部的linter，叫做qlint，可以相应减轻一些上述困扰。qlint是一个很智能的linter，可以读懂文本结构以及AST，是基于flake8和pylint的。它旨在使得未来增加自定义的lint规则变得更容易。比如说，我们其中一个做法是Python中任何一个“私有”变量都需要进行突出强调，所以我们在qlint中新增了一个规则，那就是可以检测出这类私有变量中任何不合理的地方。我们还将qlint与很多系统集成起来，提供无缝的开发环境，这样人们就不必亲自盯着lint错误。对于新手来说，qlint是一个与我们常用的文本编辑器——Vim，Emacs和Sublime——充分集成的工具，可以在规则被破坏的情况下提供可视的反馈（红色标记）。它还与我们的推送流程集成在了一起，任何人在进行code推送的时候都可以运行qlint（以互动的方式）。而实际上，如果某项规则被commit打破，它有可能就会影响到部署工作。我们还将我们的风格指南与qlint集成起来，这样对每一个lint错误，qlint都可以给出一个超链接，指向相关风格指导的相应规则。我们的Phabricator也可以用qlint。通过这种方式，所有被qlint找到的错误都被明显的标记出来，这样他们的代码审查工作就变得相当容易了。所有这些都帮我们实现了以很小的成本就能提升代码的一致性和质量。结论就像文章中所说的那样， Quora对代码的重视程度是很高的。我们讲求务实主义，搭建了很多好的系统、工具和流程，能帮我们增强并维护长期开发的生产效率。今天我们努力维持一个良好的平衡，我们的团队也在不断成长和发展，所以我们相信，未来我们还将生产更多的工具和系统。如果你想帮我们搭建这样的系统，或者想成为我们强大开发团队的一份子，帮助我们以这样一种务实的、深刻的方式提升代码质量，那么欢迎加入我们。
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
您还没有登录！请或
点击量8901点击量7988点击量6385点击量6361点击量4401点击量3930点击量3089点击量3018点击量2687
&2016 Chukong Technologies,Inc.
京公网安备89在敏捷开发中编写高质量Java代码（1）
在敏捷开发中编写高质量Java代码（1）
　　敏捷开发的理念已经流行了很长的时间，在敏捷开发中的开发迭代阶段中，我们可以通过五个步骤，来有效的提高整个项目的代码质量。　　Java项目开发过程中，由于开发人员的经验、Java代码编写习惯，以及缺乏统一的标准和管理流程，往往导致整个项目的代码质量较差，难于维护，需要较大的测试投入和周期等问题。这些问题在一个项目组初建、需求和设计均具有不完全可预期性和完备性的全新项目中将尤为突出。　　如图1所示，敏捷开发过程经历需求调研，用例分析和用例分解，进入开发迭代阶段。在每个迭代过程中，可以采用以下步骤来保证和提高整个项目的代码质量：统一编码规范、代码样式；静态代码分析（staticcodereview）；单元测试；持续集成；代码评审和重构（Review&Refactor）。下文将针对每个步骤和其所使用的工具、方法进行详细描述。　　　　图1.敏捷开发中的Java代码质量保证步骤　　步骤一：统一编码规范、代码样式　　规范统一的编码会增加项目代码的可读性和可维护性，但实际情况往往是项目组内的Java代码开发人员的编码风格常常各不相同，这可能是由于不同的经验习惯或者缺乏编码规范方面的学习造成的。这样一来，其他项目成员或者维护人员在阅读项目代码时就需要花费更多的时间来理解代码作者的意图，所以制定并采取统一的编码规范就显得很重要。编码规范主要应包含以下几个方面：　　◆一般规则和格式规范。例如代码缩进、程序块规范、每行最大代码长度等。　　◆命名规则。例如包名、类名、变量、方法、接口、参数等命名规范　　◆文档规范。例如类文件头声明、类注释、成员变量和方法注释等规范。　　◆编程规范。例如异常、并发、多线程等方面的处理方式。　　◆其他规范。例如日志格式、属性文件格式，返回值和消息格式。　　项目的编码规范可以参考已有的一些Java编程规范书籍和其他相关资料并结合项目的本身来制定，可供参考的书籍有《Java编程风格》（英文书名为：TheElementsofJavaStyle）。编码规范要形成文档，而且要简洁明了，并组织项目成员一起学习，确保所有成员正确理解所有条目。　　一旦编码规范确定，就可以利用Eclipse自身提供的功能来控制代码样式和格式。具体做法是，点击Eclipse的Windows-&Preference菜单项，在打开的Preferences对话框的左侧栏中找到Java节点下的子项CodeStyle（如图2），该项和它的子项允许您对Java代码的样式进行控制。　　　　图2.Eclipse代码样式设置窗口　　例如，为了使用自动格式化工具，可以在Eclipse提供的默认代码格式配置的基础上建立自定义的格式。在Formatter面板中，点击New，输入新的名字并选择一个默认的配置作为初始化格式，如图3所示。
　　图3.创建新的代码格式配置
　　单击OK后就可以在新打开的窗口中进行修改定制自己需要的格式。如图4所示。
　　图4.创建新的代码格式配置
　　修改完成后点击Apply保存所作修改。同时可以点击Export将当前的格式定义导出成一个XML文件，这样项目组的其他成员就可以很方便通过点击图3中的Import按钮来导入该XML文件来使用同一个代码格式定义。
　　这样每次在提交代码到版本控制服务器前就可以通过Eclipse界面里的Source-&Format菜单来对代码进行格式化，从而使整个项目的代码具有相同的格式。同样可以通过对CodeStyle下的其他项目进行设置来帮助对Java代码的样式进行控制。将所有这些样式文件导出成XML文件后，同编码规范一起归档，供所有项目成员使用。　　步骤二：静态代码分析
　　在完成源代码的开发以后，下面要进行的工作就是审视和测试代码。除了通过运行测试代码来检查功能之外，还能利用一些静态分析工具来快速、直接地提高代码质量。静态代码分析工具并不需要运行代码，可以直接对Java文件和Class文件进行分析，通过一些检查条件的设置，快速找到代码中的错误和潜在缺陷。现在的静态分析工具很多，有FindBugs、PMD、IBMRationalTool，等等。在这里，选择FindBugs作为静态代码分析工具。FindBugs可以和日常开发工具Eclipse进行集成，在开发过程中，就可以方便的开始静态代码的检查。通过检查Class文件或者JAR文件，将字节码和一组缺陷模式进行对比，来发现可能存在的代码问题。在Eclipse的开发环境中，用插件安装的方式安装了Findbugs后，在Eclipse的配置选项中就会多出来FindBugs的配置选项。可以对自己的项目进行配置，选择需要的Detector检查代码。
　　图5.FindBugs的配置选项
　　设置好自己的规则后，在需要检查的代码文件夹上点击右键，就可以启动FindBugs检查。代码可以是一个项目，也可以只是几个文件。
　　图6.运行FindBugs
　　检查完毕后，会出现FindBugs视图，把所有检查的结果根据错误分组展示。点击结果里面的每一个错误，会自动打开对应的代码。当根据规则改正了所有的错误，或者说潜在错误，这些代码也就通过了静态代码检查。FindBugs的检查结果可以是XML文件，也可以是文本文件，便于项目的集成管理和检查保存。
　　图7.FindBugs检查结果　　步骤三：单元测试
　　单元测试用例设计和评审
　　单元测试是软件开发过程中重要的质量保证环节，在此环节中，设计和评审对于保证整个单元测试过程的完整性和有效性来说十分重要。设计阶段需要具体考虑要对哪些代码单元进行测试，被测单元之间的关系，测试策略，以及单元测试用例设计等，并最终输出《单元测试用例设计》文档，用来指导具体的单元测试执行。在用例设计中，通过对代码单元输入和期待输出的定义来保证该单元的功能正确性，边界值的测试和异常测试非常重要。同时也配合测试用例和功能块的匹配方法来衡量用例设计的完整性。
　　在用例设计完成之后，下一步的工作就是进行测试用例的评审。个人的理解和经验始终是有限的，用例评审可以借集体之力，对用例设计进入查漏补缺，进一步保证测试用例的有效性。由于单元测试属于白盒测试范畴，它主要通过对代码的逻辑结构进行分析来设计测试用例，因此，评审员的选择最好以理解代码逻辑结构为前提，如果评审员来自相关模块，还能够有效的发现模块相关性和依赖性所带来的问题。
　　模拟对象技术
　　在实际项目中，开发人员自己的代码往往需要和其他的代码模块或系统进行交互，但在测试的过程中，这些需要被调用的真实对象常常很难被实例化，或者这些对象在某些情况下无法被用来测试，例如，真实对象的行为无法预测，真实对象的行为难以触发，或者真实对象的运行速度很慢。这时候，就需要使用模拟对象技术（Mock），利用一个模拟对象来模拟我们的代码所依赖的真实对象，来帮助完成测试，提高测试覆盖率，从而提高代码质量。模拟对象技术利用了在面向接口的编程中，由于代码直接对接口进行调用，所以代码并不知道引用的是真实对象还是模拟对象，这样就可以顺利的完成对代码的测试，模拟技术有很多种，如jMock，EasyMock，Mockito，PowerMock等等。其中Mockito消除了对期望行为的需求，避免了这些代码的大量初始化。
　　图8.Mockito示例
　　在模拟对象过程中，先模拟一个需要调用的List对象LinkedList，再设定这个对象的行为，当调用get(0)的时候，返回”first”。这样，测试代码就可以利用这个对象来测试我们的功能代码，需要调用和返回值的时候，可以顺利的得到模拟对象的返回值。也需要对模拟对象进行错误情况的模拟，保证代码对错误的处理的正确性。
　　测试覆盖率分析
　　为了衡量单元测试的质量和覆盖的范围，需要对单元测试的代码进行测试覆盖分析。常用的衡量测试覆盖率的指标主要有语句覆盖率、分支覆盖率、路径覆盖率、条件覆盖率和方法覆盖率等。具体采用哪些指标可以根据项目的实际情况来定，以避免因过高的指标增加了代码开发人员的工作量而影响了项目整体的进度。
　　EMMA是一款比较流行的开源Java测试覆盖率分析工具，支持类、方法、代码行、基本代码块等多种类型的测试覆盖率分析，支持将覆盖率分析结果导出为多种格式的报告，并采用多种颜色来高亮显示不同的覆盖率状态。EclEmma是一款基于EMMA的Eclipse插件，方便在EclipseIDE中进行测试覆盖率分析。如图9，在测试用例写好后，可以在右键点击测试类，选择CoverageAs-&JUnitTest。
　　图9.运行测试覆盖分析　　单元测试跑完后，Coverage视图中会显示所选择的测试的覆盖率。双击打开某一具体的类后，可以看到高亮显示的覆盖分析结果，如图10所示。红色代表测试没有覆盖到该行，黄色表示部分覆盖，绿色的行表示该行在本次测试中被覆盖到。
　　图10.查看测试覆盖分析结果
　　在Coverage视图中可以通过点击鼠标右键将测试覆盖分析的结果导出成需要的格式，例如HTML。
　　图11.导出测试覆盖分析结果
　　图12显示了导出的report。
　　图12.测试覆盖分析报告
　　为了保证单元测试的有效性和质量，可以规定一个测试覆盖率的下限，例如所有的包和类的覆盖率必须达到80%以上。不过值得注意的是，不要单纯追求高覆盖率，要同时注意测试用例的质量，如果测试用例本身就写的有错误，那么即使测试覆盖率很高也没有意义。
　　相关链接：
　　在敏捷开发中编写高质量Java代码（2）
H3C认证Java认证Oracle认证
基础英语软考英语项目管理英语职场英语
.NETPowerBuilderWeb开发游戏开发Perl
二级模拟试题一级模拟试题一级考试经验四级考试资料
软件测试软件外包系统分析与建模敏捷开发
法律法规历年试题软考英语网络管理员系统架构设计师信息系统监理师
高级通信工程师考试大纲设备环境综合能力
路由技术网络存储无线网络网络设备
CPMP考试prince2认证项目范围管理项目配置管理项目管理案例项目经理项目干系人管理
职称考试题目
招生信息考研政治
网络安全安全设置工具使用手机安全
生物识别传感器物联网传输层物联网前沿技术物联网案例分析
Java核心技术J2ME教程
Linux系统管理Linux编程Linux安全AIX教程
Windows系统管理Windows教程Windows网络管理Windows故障
数据库开发Sybase数据库Informix数据库
&&&&&&&&&&&&&&&
希赛网 版权所有 & &&