作者： 姜全尧

原帖来自：http://tech.it168.com/a2009/0903/673/000000673684.shtml

附件来自51testing     

1.前言:

　　LoadRunner 最重要也是最难理解的地方--测试结果的分析.其余的录制和加压测试等设置对于我们来讲通过几次操作就可以轻松掌握了.针对 Results Analysis 我用图片加文字做了一个例子,希望通过例子能给大家更多的帮助.这个例子主要讲述的是多个用户同时接管任务,测试系统的响应能力,确定系统瓶颈所在.客户要求响应时间是1 个人接管的时间在5S 内.

　　2.系统资源:

　　2.1 硬件环境：

　　CPU：奔四2.8E

　　硬盘：100G

　　网络环境：100Mbps

　　2.2 软件环境：

　　操作系统：英文windowsXP

　　服务器：tomcat 服务

　　浏览器：IE6.0

　　系统结构：B/S 结构

　　3.添加监视资源

　　下面要讲述的例子添加了我们平常测试中最常用到的一些资源参数.另外有些特殊的资源暂时在这里不做讲解了.我会在以后相继补充进来。

　　Mercury Loadrunner Analysis 中最常用的5 种资源.

　　1. Vuser

　　2. Transactions

　　3. Web Resources

　　4. Web Page Breakdown

　　5. System Resources

　　在Analysis 中选择“Add graph”或“New graph”就可以看到这几个资源了.还有其他没有数据的资源,我们没有让它显示.

　　

　　如果想查看更多的资源,可以将左下角的display only graphs containing data 置为不选.然后选中相应的点“open graph”即可.

　　打开Analysis 首先可以看的是Summary Report.这里显示了测试的分析摘要.应有尽有.但是我们并不需要每个都要仔细去看.下面介绍一下部分的含义：

　　Duration(持续时间)：了解该测试过程持续时间.测试人员本身要对这个时期内系统一共做了多少的事有大致的熟悉了解.以确定下次增加更多的任务条件下测试的持续时间。

　　Statistics Summary(统计摘要)：只是大概了解一下测试数据,对我们具体分析没有太大的作用.

　　Transaction Summary(事务摘要)：了解平均响应时间Average单位为秒.

　　其余的看不看都可以.都不是很重要.
4.分析集合点

　　在录制脚本中通常我们会使用到集合点,那么既然我们用到了集合点,我们就需要知道Vuser 是在什么时候集合在这个点上,又是怎样的一个被释放的过程.这个时候就需要观察Vuser-Rendezvous 图.

　　

　　图1

　　可以看到大概在3 分50 的地方30 个用户才全部集中到start 集合点,持续了3 分多,在7 分30 的位置开始释放用户,9 分30 还有18 个用户,11 分10 还有5 个用户,整个过程持续了12 分.

　　

　　图2

　　上面图2 是集合点与平均事务响应时间的比较图.

　　注:在打开analysis 之后系统LR 默认这两个曲线是不在同一张图中的.这就需要自行设置了.具体步骤如下:

　　点击图上.右键选择merge graphs.然后在select graph to merge with 中选择即将用来进行比较的graph.如图3:

　　

　　图3

　　图2 中较深颜色的是平均响应时间,浅色的为集合点,当Vuser 在集合点持续了1分后平均响应时间呈现最大值,可见用户的并发对系统的性能是一个很大的考验.接下来看一下与事务有关的参数分析.下看一张图.

　　

　　图4

　　这张图包括Average Transaction Response Time 和Running Vuser 两个数据图.从图中可以看到Vuser_init_Transaction(系统登录)对系统无任何的影响,Vuser 达到15 个的时候平均事务响应时间才有明显的升高,也就是说系统达到最优性能的时候允许14 个用户同时处理事务,Vuser 达到30 后1 分,系统响应时间最大,那么这个最大响应时间是要推迟1 分钟才出现的,在系统稳定之后事务响应时间开始下降说明这个时候有些用户已经执行完了操作.同时也可以看出要想将事务响应时间控制在10S 内.Vuser 数量最多不能超过2 个.看来是很难满足用户的需求了.

　　做一件事有时候上级会问你这件事办得怎么样了.你会说做完一半了.那么这个一半的事情你花了多少时间呢?所以我们要想知道在给定时间的范围内完成事务的百分比就要靠下面这个图(Transaction Response Time(Percentile)

　　

　　图中画圈的地方表示10%的事务的响应时间是在80S 左右.80S 对于用户来说不是一个很小的数字,而且只有10%的事务,汗.你觉得这个系统性能会好么!

　　实际工作中遇到的事情不是每一件事都能够在很短的时间内完成的,对于那些需要时间的事情我们就要分配适当的时间处理,时间分配的不均匀就会出现有些事情消耗的时间长一些,有些事情消耗的短一些,但我们自己清楚.LR 同样也为我们提供了这样的功能,使我们可以了解大部分的事务响应时间是多少?以确定这个系统我们还要付出多少的代价来提高它.

　　Transaction Response Time(Distribution)-事务响应时间(分布)

　　显示在方案中执行事务所用时间的分布.如果定义了可以接受的最小和最大事务性能时间,可以通过此图确定服务器性能是否在可接受范围内.

　　

　　很明显大多数事务的响应时间在60-140S.在我测试过的项目中多数客户所能接受的最大响应时间也要在20S 左右.140S 的时间!很少有人会去花这么多的时间去等待页面的出现吧!

　　通过观察以上的数据表.我们不难看到此系统在这种环境下并不理想.世间事有果就有因,那么是什么原因导致得系统性能这样差呢?让我们一步一步的分析.

　　系统性能不好的原因多方面,我们先从应用程序看.有的时候我不得不承认LR 的功能真的很强大,这也是我喜欢它的原因.先看一张页面细分图.

　　

　　一个应用程序是由很多个组件组成的,整个系统性能不好那我们就把它彻底的剖析一下.图片中显示了整个测试过程中涉及到的所有web 页.web page breakdown中显示的是每个页面的下载时间.点选左下角web page breakdown 展开,可以看到每个页中包括的css 样式表,js 脚本,jsp 页面等所有的属性.

　　在select page to breakdown 中选择页面.

　　

　　见图.

　　在 Select Page To Breakdown 中选择http://192.168.0.135:8888/usertasks 后,在下方看到属于它的两个组件,第一行中Connection 和First Buffer 占据了整个的时间,那么它的消耗时间点就在这里,我们解决问题就要从这里下手.

　　

　　

　　也有可能你的程序中client 的时间最长.或者其他的,这些就要根据你自己的测试结果来分析了.下面我们来看一下CPU,内存.硬盘的瓶颈分析方法:

　　首先我们要监视CPU,内存.硬盘的资源情况.得到以下的参数提供分析的依据.
       %processor time(processor_total):器消耗的处理器时间数量.如果服务器专用于sql server 可接受的最大上限是80% -85 %.也就是常见的CPU 使用率.

　　%User time(processor_total)::表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。

　　%DPC time(processor_total)::越低越好。在多处理器系统中，如果这个值大于50%并且Processor:% Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。

　　%Disk time(physicaldisk_total):指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大，那么硬盘不是瓶颈。如果只有%Disk Time比较大，另外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在Windows 2000 的命令行窗口中运行diskperf -yD。若数值持续超过80%，则可能是内存泄漏。

　　Availiable bytes(memory):用物理内存数. 如果Available Mbytes的值很小(4 MB 或更小)，则说明计算机上总的内存可能不足，或某程序没有释放内存。

　　Context switch/sec(system): (实例化inetinfo 和dllhost 进程) 如果你决定要增加线程字节池的大小，你应该监视这三个计数器(包括上面的一个)。增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。

　　%Disk reads/sec(physicaldisk_total):每秒读硬盘字节数.

　　%Disk write/sec(physicaldisk_total):每秒写硬盘字节数.

　　Page faults/sec:进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。

　　Pages per second:每秒钟检索的页数。该数字应少于每秒一页Working set:理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。

　　Avg.disk queue length:读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘。

　　Average disk read/write queue length: 指读取(写入)请求(列队)的平均数Disk reads/(writes)/s:理磁盘上每秒钟磁盘读、写的次数。两者相加，应小于磁盘设备最大容量。

　　Average disk sec/read:以秒计算的在此盘上读取数据的所需平均时间。Average disk sec/transfer:指以秒计算的在此盘上写入数据的所需平均时间。

　　Bytes total/sec:为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较Page read/sec:每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据库间的物理页读取总数。由于物理 I/O 的开销大，可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，使开销减到最小。

　　Page write/sec:(写的页/秒)每秒执行的物理数据库写的页数。

1. 判断应用程序的问题

　　如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换(context switches/sec显示的上下文切换次数太高)那么就会占用大量的系统资源,如果系统的吞吐量降低并且CPU的使用率很高,并且此现象发生时切换水平在15000以上,那么意味着上下文切换次数过高.

　　

　　从图的整体看.context switches/sec变化不大,throughout曲线的斜率较高,并且此时的contextswitches/sec已经超过了15000.程序还是需要进一步优化.

　　2. 判断CPU瓶颈

　　如果processor queue length显示的队列长度保持不变(>=2)个并且处理器的利用率%Processortime超过90%,那么很可能存在处理器瓶颈.如果发现processor queue length显示的队列长度超过2,而处理器的利用率却一直很低,或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈.

　　

　　%processor time平均值大于95,processor queue length大于2.可以确定CPU瓶颈.此时的CPU已经不能满足程序需要.急需扩展.

　　3. 判断内存泄露问题

　　内存问题主要检查应用程序是否存在内存泄漏,如果发生了内存泄漏,process\private bytes计数器和process\working set 计数器的值往往会升高,同时avaiable bytes的值会降低.内存泄漏应该通过一个长时间的,用来研究分析所有内存都耗尽时,应用程序反应情况的测试来检验.

　　

　　图中可以看到该程序并不存在内存泄露的问题.内存泄露问题经常出现在服务长时间运转的时候,由于部分程序对内存没有释放,而将内存慢慢耗尽.也是提醒大家对系统稳定性测试的关注.

　　附件:

　　CPU信息：

　　Processor\ % Processor Time 获得处理器使用情况。

　　也可以选择监视 Processor\ % User Time 和 % Privileged Time 以获得详细信息。

　　Server Work Queues\ Queue Length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。

　　System\ Processor Queue Length 用于瓶颈检测通过使用 Process\ % Processor Time 和 Process\ Working Set

　　Process\ % Processor Time过程的所有线程在每个处理器上的处理器时间总和。

　　硬盘信息：

　　Physical Disk\ % Disk Time

　　Physical Disk\ Avg.Disk Queue Length

　　例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。

　　Physical Disk\ % Disk Time

　　Physical Disk\ Avg.Disk Queue Length

　　例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。

　　请观察 Processor\ Interrupts/sec 计数器的值，该计数器测量来自输入/输出 (I/O) 设备的服务请求的速度。如果此计数器的值明显增加，而系统活动没有相应增加，则表明存在硬件问题。

　　Physical Disk\ Disk Reads/sec and Disk Writes/sec

　　Physical Disk\ Current Disk Queue Length

　　Physical Disk\ % Disk Time

　　LogicalDisk\ % Free Space

　　测试磁盘性能时，将性能数据记录到另一个磁盘或计算机，以便这些数据不会干扰您正在测试的磁盘。

　　可能需要观察的附加计数器包括 Physical Disk\ Avg.Disk sec/Transfer 、Avg.DiskBytes/Transfer，和Disk Bytes/sec。

　　Avg.Disk sec/Transfer 计数器反映磁盘完成请求所用的时间。较高的值表明磁盘控制器由于失败而不断重试该磁盘。这些故障会增加平均磁盘传送时间。对于大多数磁盘，较高的磁盘平均传送时间是大于 0.3 秒。

　　也可以查看 Avg.Disk Bytes/Transfer 的值。值大于 20 KB 表示该磁盘驱动器通常运行良好;如果应用程序正在访问磁盘，则会产生较低的值。例如，随机访问磁盘的应用程序会增加平均 Disk sec/Transfer 时间，因为随机传送需要增加搜索时间。

　　Disk Bytes/sec 提供磁盘系统的吞吐率。

　　决定工作负载的平衡要平衡网络服务器上的负载，需要了解服务器磁盘驱动器的繁忙程度。使用 Physical Disk\ %Disk Time 计数器，该计数器显示驱动器活动时间的百分比。如果 % Disk Time 较高(超过90%)，请检查 Physical Disk\ Current Disk Queue Length 计数器以查看正在等待磁盘访问的系统请求数量。等待 I/O 请求的数量应当保持在不大于组成物理磁盘的主轴数的 1.5 到2倍。

　　尽管廉价磁盘冗余阵列 (RAID) 设备通常有多个主轴，大多数磁盘有一个主轴。硬件 RAID设备在“系统监视器”中显示为一个物理磁盘;通过软件创建的 RAID 设备显示为多个驱动器(实例)。可以监视每个物理驱动器(而不是 RAID)的 Physical Disk 计数器，也可以使用 _Total 实例来监视所有计算机驱动器的数据。

　　使用 Current Disk Queue Length 和 % Disk Time 计数器来检测磁盘子系统的瓶颈。如果Current Disk Queue Length 和 % Disk Time 的值始终较高，可以考虑升级磁盘驱动器或将某些文件移动到其他磁盘或服务器。

【注】 51Testing授权IT168独家转载，未经明确的书面许可，任何人或单位不得对本文内容复制、转载或进行镜像，否则将追究法律责任。

转自（http://www.ibm.com/developerworks/cn/java/j-ap01117/#rate）

如果能在构建代码前发现代码中潜在的问题会怎么样呢？很有趣的是，Eclipse 插件中就有这样的工具，比如 JDepend 和 CheckStyle，它们能帮您在软件问题暴露前发现这些问题。在 让开发自动化 的本期文章中，自动化专家 Paul Duvall 将带来一些关于 Eclipse 插件的例子，您可以安装、配置和使用这些静态分析插件，以便在开发生命周期的早期预防问题。

开发软件时，我的主要目标之一是：要么防止将缺陷引入代码库，要么限制缺陷的生存期；换言之，要尽早找到缺陷。很显然，越是了解如何编写更好的代码以及如何有效测试软件，就越能及早地捕捉到缺陷。我也很想要一张能发现潜在缺陷的安全之网。

在本系列 八月份 的那期文章中，我得出了这样的结论：将检验工具集成到构建过程（例如，使用 Ant 或 Maven）中，能够建立起一种寻找潜在缺陷的方法。尽管这种方法使一致性成为可能并超越了 IDE，但它也有一点反作用。必须在本地构建软件或等待 Continuous Integration 构建的运行。如果使用 Eclipse 插件，就可以在通过 Continuous Integration 构建或集成前 发现一些这样的冲突。这就促成了我称为渐进编程 的编程方式，在这种方式下，允许在编码过程中进行一定程度的质量检验 —— 再也不能比这个更早了！

本文涵盖了我所认为的 “五大” 代码分析领域：

• 编码标准
• 代码重复
• 代码覆盖率
• 依赖项分析
• 复杂度监控

可以用接下来的几个灵活的 Eclipse 插件来揭示这些分析领域：

• CheckStyle：用于编码标准
• PMD 的 CPD：帮助发现代码重复
• Coverlipse：测量代码覆盖率
• JDepend：提供依赖项分析
• Eclipse Metric 插件：有效地查出复杂度

安装 Eclipse 插件

安装 Eclipse 插件再简单不过了，只需要几个步骤。在开始之前，最好把该插件下载站点的 URL 准备好。表 1 是本文用到的插件的列表：

表 1. 代码改进插件和相应的下载站点 URL

工具	目的	Eclipse 插件的 URL
CheckStyle	编码标准分析	http://eclipse-cs.sourceforge.net/update/
Coverlipse	测试代码覆盖率	http://coverlipse.sf.net/update
CPD	复制/粘贴检验	http://pmd.sourceforge.net/eclipse/
JDepend	包依赖项分析	http://andrei.gmxhome.de/eclipse/
Metrics	复杂度监控	http://metrics.sourceforge.net/update

 

用 CheckStyle. 校正标准

代码库的可维护性直接影响着软件的整个成本。另外，不佳的可维护性还会让开发人员十分头痛（进而导致开发人员的缺乏）—— 代码越容易修改，就越容易添加新的产品特性。像 CheckStyle. 这样的工具可以协助寻找那些可影响到可维护性、与编码标准相冲突的地方，比方说，过大的类、太长的方法和未使用的变量等等。

有关 PMD 另一个叫做 PMD 的开源工具提供的功能和 CheckStyle. 类似。我偏爱 CheckStyle，但 PMD 也有很多执着的追随者，所以我建议您了解一下这个工具，毕竟它也颇受一些人的青睐。

使用 Eclipse 的 CheckStyle. 插件的好处是能够在编码过程中了解到源代码上下文的各种编码冲突，让开发人员更可能在签入该代码前真正处理好这些冲突。您也几乎可以把 CheckStyle. 插件视作一个连续的代码复查工具！

安装 CheckStyle. 插件并做如下配置（参见图 4）：

1. 选择 Project，然后选择 Eclipse 菜单中的 Properties 菜单项。
   
   
2. 选择 CheckStyle. active for this project 复选框，单击 OK。
   
   
   
   图 4. 在 Eclipse 中配置 CheckStyle. 插件
   
   
   

Eclipse 重新构建工作空间，并在 Eclipse 控制台中列示已发现的编码冲突，如图 5 所示：

图 5. Eclipse 中 CheckStyle. 的代码冲突列表

使用 CheckStyle. 插件在 Eclipse 内嵌入编码标准检验是一种很棒的方法，用这种方法可以在编码时 积极地改进代码，从而在开发周期的早期发现源代码中潜在的缺陷。这么做还有更多的好处，如节省时间、减少失败，也因此会减少项目的成本。没错，这就是一种积极主动的方式！

回页首

用 Coverlipse 确认覆盖率

Coverlipse 是一个用于 Cobertura 的 Eclipse 插件，Cobertura 是一个代码覆盖率工具，可以用它来评估具有相应测试的源代码的比率。Cobertura 也提供一个 Ant 任务和 Maven 插件，但用 Cobertura，您可以在编写代码时 评估代码覆盖率。您见过这样的模式吗？

通过选择 Eclipse 菜单项 Run 安装 Coverlipse 插件并将其和 JUnit 关联起来，该操作会显示一系列运行配置选项，例如 JUnit、SWT 应用程序和 Java™ 应用程序。右键单击它并选择 JUnit w/Coverlipse 节点中的 New。在这里，需要确定 JUnit 测试的位置，如图 6 所示：

图 6. 配置 Coverlipse 以获取代码覆盖率

一旦单击了 Run，Eclipse 会运行 Coverlipse 并在源代码（如图 7 所示）中嵌入标记，该标记显示了具有相关 JUnit 测试的代码部分：

图 7. Coverlipse 生成的具有嵌入类标记的报告

正如您所见，使用 Coverlipse Eclipse 插件可以更快地确定代码覆盖率。例如，这种实时数据功能有助于在将代码签入 CM 系统前 更好地进行测试。这对渐进编程来说意味着什么呢？

回页首

用 CPD 捕捉代码重复

Eclipse 的 PMD 插件提供了一项叫做 CPD（或复制粘贴探测器）的功能，用于寻找重复的代码。为在 Eclipse 中使用这项便利的工具，需要安装具有 PMD 的 Eclipse 插件，该插件具有 CPD 功能。

为寻找重复的代码，请用右键单击一个 Eclipse 项目并选择 PMD | Find Suspect Cut and Paste，如图 8 所示：

图 8. 使用 CPD 插件运行复制粘贴检验

一旦运行了 CPD，您的 Eclipse 根目录下就会创建出一个 report 文件夹，其中包含一个叫做 cpd.txt 的文件，文件中列示了所有重复的代码。图 9 中是一个 cpd.txt 文件的例子：

图 9. Eclipse 插件生成的 CPD 文本文件

靠人工来寻找重复的代码是一项挑战，但使用像 CPD 这样的插件却能在编码时轻松地发现重复的代码。

回页首

使用 JDepend 进行依赖项检查

JDepend 是个可免费获取的开源工具，它为包依赖项提供面向对象的度量值，以此指明代码库的弹性。换句话说，JDepend 可有效测量一个架构的健壮性（反之，脆弱性）。

除了 Eclipse 插件，JDepend 还提供一个 Ant 任务、Maven 插件和一个 Java 应用程序，用以获取这些度量值。对于相同的信息，它们有着不同的传递机制；但 Eclipse 插件的特别之处和相应优点是：它能以更接近源代码（即，编码时）的方式传递这条信息。

图 10 演示了使用 Eclipse JDepend 插件的方法：通过右键单击源文件夹并选择 Run JDepend Analysis。一定要选择一个含源代码的源文件夹；否则看不到此菜单项。

图 10. 使用 JDepend Analysis 分析代码

图 11 显示了运行 JDepend Analysis 时生成的报告。左边显示包，右边显示针对每个包的依赖项度量值。

图 11. Eclipse 项目中的包依赖项

正如您所见，JDepend 插件提供了有助于不断观察架构可维护性变化的大量信息 —— 这其中最大的好处是您可以在编码时看到这些数据。

回页首

用 Metrics 测量复杂度

“五大”代码分析最后的一项是测量复杂度。Eclipse 提供一种叫做 Metrics 的插件，使用该插件可以进行许多有用的代码度量，包括圈复杂度度量，它用于测量方法中惟一路径的数目。

安装 Metrics 插件并重启 Eclipse；然后遵循下列步骤：

1. 右键单击您的项目并选择 Properties 菜单。在结果窗口中，选择 Enable Metrics plugin 复选框并单击 OK，如图 12 所示：
   
   
   
   图 12. 为项目配置 Metrics
   
   
   
   
   
2. 从 Eclipse 中选择 Window 菜单打开 Metrics 视图，然后选择 Show View | Other...。
   
   
3. 选择 Metrics | Metrics View 打开如图 13 中显示的窗口。您需要使用 Java 透视图并重新构建项目，从而显示这些度量值。
   
   
   
   图 13. 打开 Eclipse 中的 Metrics View
   
   
   
   
   
4. 单击 OK 来显示如图 14 中的窗口。
   
   在此例中，我正在查看一个单独方法的圈复杂度。真正妙的是您可以双击 Metrics 列表中的方法，该插件会在 Eclipse 编辑器中为此方法打开源代码。这就让修正变得超级简单（如果需要的话）！
   
   
   
   图 14. 查看方法的圈复杂度
   
   
   

正如我之前提到过的，Eclipse Metrics 插件还提供了许多功能强大的度量值，有助于您在开发软件的过程中改进代码 —— 可见，它是一个渐进编程意义上的插件!

回页首

合适的才是最好的

正如您从本文中看到的那样，将“五大”测量方法，即编码标准、代码重复、代码覆盖率、依赖项分析和复杂度监控，用于改进代码质量十分重要。但适合您的才是好的。请记住还有其他许多可用的 Eclipse 插件（比如 PMD 和 FindBugs）能够帮助您在开发周期的早期改进代码质量。不管您想要的工具或偏爱的方法是什么，重要的是：行动起来去积极改进代码质量并让手工代码检验的过程变得更加有效。我估计您使用这些插件一段时间后，就再也离不开它们了。

 

参考资料

学习

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
  
  
• 让开发自动化 （Paul Duvall，developerWorks）：阅读完整的系列。
  
  
• “Improving Code Quality with PMD and Eclipse” （Levent Gurses，Jacoozi，2005 年 1 月）：这篇文章将 PMD 视为 Eclipse 插件，介绍了使用 PMD 改进代码质量并缩短代码检验过程的方法。
  
  
• “用 Cobertura 测量测试覆盖率” （Elliotte Rusty Harold，developerWorks，2005 年 5 月）：Elliotte Rusty Harold 分享了他的经验，即如何使用代码覆盖率的最佳实践来利用 Cobertura。
  
  
• “不要被覆盖报告所迷惑” （Andrew Glover，developerWorks，2006 年 1 月）：这篇文章进一步揭示了覆盖率报告中的数字所代表的真正含义，也给出了这些数字所不能代表的含义。
  
  
• “Managing Your Dependencies with JDepend” （Glen Wilcox，OnJava，2004 年 1 月）：在这篇文章中，Glen Wilcox 介绍了 JDepend，这是一个可以免费获取的工具，它能洞悉软件架构中的许多质量问题。
  
  
• “软件架构的代码质量” （Andrew Glover，developerWorks，2006 年 4 月）：Andrew Glover 介绍了如何持续监控以及如何改正能够影响软件架构长期存续性的代码质量问题。
  
  
• “ 让开发自动化: 持续检查” （Paul Duvall，developerWorks，2006 年 8 月）：Paul Duvall 介绍了自动化的检查工具（如 CheckStyle、JavaNCSS 和 CPD ）是如何增强开发过程的以及何时应该使用这些工具。
  
  
• “Detecting Duplicate Code with PMD's CPD” （Tom Copeland，OnJava，2003 年 3 月）：Tom Copeland 介绍了一种叫做 CPD（复制/粘贴检测器）的开源工具，该工具用于寻找重复的 Java 代码。
  
  
• “Maintain organizational standards with code audits” （testearly.com）：编码标准有利于广大开发人员对代码库达成共识。
  
  
• developerWorks Java 技术专区：数百篇关于 Java 编程各方面的文章。
  
  

获得产品和技术

• Eclipse plugin for PMD：使用 PMD 插件在代码中寻找复制粘贴问题。
  
  
• Eclipse plugin for JDepend：此插件有助于分析代码库中的包依赖项。
  
  
• Eclipse plugin for Cobertura：Coverlipse 是 用于 Cobertura 的 Eclipse 插件，它提供代码覆盖率信息。
  
  
• Eclipse Metrics：此插件提供度量值，如圈复杂度，非常有助于寻找复杂代码。
  
  
• Eclipse plugin for CheckStyle：检验项目编码标准的遵循情况。
  
  

讨论

• 提高代码质量论坛：developerWorks 的积极贡献者 Andrew Glover 是一名专注于改进代码质量的顾问，他为这个由他主持的论坛带来了很多相当专业的知识。

 

关于作者

		Paul Duvall 是 Stelligent Incorporated 的 CTO，该公司利用有效的开发人员测试策略，以及能够让团队尽早尽多地监视和提高代码质量的持续集成技术，帮助其他企业解决软件的质量问题。他还是 UML™ 2 Toolkit 一书的作者之一，目前正在与他人合作撰写 Continuous Integration: Improving Software Quality and Reducing Risk (Addison-Wesley) 一书。