1.1 打开FindBugs视图:
Windows => Show View => Other… => FindBugs => Bug Info 、Bug Explorer、Bug Reviews
1.2 配置FindBugs
选择你的项目=>右键 => Properties => FindBugs => 选中“Run automatically” => OK
Findbugs各项属性的配置说明:
Enable project specific setting:该项目是否启用自身特殊设置(忽略全局设置)
Run automnaticaly:编译文件时自动运行。
Also on full build:编译工程时自动运行。必须同时勾选Enable project specific setting
Bug类型说明:
Minimum priority to report:根据bug的优先权级别报告bug。
Malicious code vulnerability:恶意代码。
Dodgy code:高危代码。FindBugs团队认为该类型下的问题代码导致bug的可能性很高。
Bad practice:最佳实践反例。这种类别下的代码违反了公认的最佳实践标准,比如某个类实现了equals方法但未实现hashCode方法等。
Correctness:正确性。这种归类下的问题在某种情况下会导致bug,比如错误的强制类型转换等。
Internationalization:国际化。
Performance:性能。潜在性能问题
Security:安全。
Mutithreaded correctness:多线程的正确性。关注于同步和多线程问题。
1.3 Bug设置
2.1 如下图:我们在工程的右键菜单中选择Find bugs的菜单项“Find bugs”。
2.2 当findBugs运行后,就可以在bug Explorer 视图中看到相应的信息,可以双击切换到相应代码 ,就可以对这个代码改进了,如下图:
这时我们就可以找到BUG所在并修改
2.3 查看Bug详细信息
显示详细信息如下:
2.4 过滤bug设置:
2.4.1 首先点击bug行号前的bug标志,进入bug detail视图,记下这个bug的id,如下图的[RCN]
2.4.2 在Bug Explorer窗口中单击“Filter Bugs by Id“
输入Type(RCN)或Pattern(RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE)即可找出相应的bug设置
ok确认即可。
2.5 分组查看
选择相应的分组依据
或者直接如下图所示分组。
当Checkstyle成功安装后,在"window->Preferences"中可以看到checkstyle的选项, 如图所示:
Checkstyle有两个渠道可以进行配置,一个是全局的,一个是单个项目(Project)的。全局的可以 在整个MyEclipse的workspace中生效, 而单个项目的配置可以在指定的项目中生效,它优先于全局 的配置。
对于单个项目:右键点某个项目,然后选择"Properties"就可以看到Checkstyle的窗口。在"Main"标签中,"Checkstyle active for this project"前面打勾, 然后在"Simple –use the following check configuration for all files" 下拉框中选择你的Checkstyle配置文件就可以了。如图:
对于全局的设置:"window->preferences"就可以看到。设置方法跟单个项目的设置是一样的。
经过上面的设置,Checkstyle就可以使用了。Checkstyle默认提供了基于Sun的检查配置文件,并不一定适合每个公司,因此提供了自定义检查模式。在全局设置中"Global Check Configurations"中单击"New"按钮。
起好名字后,单击"Import"按钮,选择文件后,确定即可。
另外,官方帮助可以在MyEclipse的"Help-> HelpeContents"中的" Checkstyle Plug-in " 中找到。内容还是很详尽的。
很简单,在项目设置中勾选Checkstyle active for this project后,重新编译即可。或者右击项目"Checkstyle -> Check Code with Checkstyle"。
运行方法是右键选择需要分析的包,选择 Run JDepend Analysis
于是会出现如下分析结果
JDepend为每个Package自动生成的依赖性度量指标,包括:
Number of Classes and Interfaces(CC):实现类与抽象接口的数目
面向的设计原则之一The Stable Abstractions Principle (SAP):稳定抽象等价原则指出了包的稳定程度与它的抽象程度(接口的数目)成正比,也就是说,一个包内包含的接口所占的比重越大,这个包就越稳定。
Afferent Couplings (Ca):向心耦合。依赖该包(包含的类)的外部包(类)的数目(i.e. incoming dependencies),该数值越大,说明该包的担当的职责越大,也就越稳定。
Efferent Couplings (Ce):离心耦合。被该包依赖的外部包的数目(i.e. outgoing dependencies),该数值越大,说明该包越不独立(因为依赖了别的包),也越不稳定。
Abstractness (A):包的抽象度。指一个包内包含的抽象类或接口占整个包中的类的比重。该值处于0,1之间,若A=0,说明包内不包含任何抽象类或接口;若A=1,说明包内全部是抽象类或接口。包的抽象度与稳定性之间的关系上面已经作了说明。
Instability (I):衡量一个包的不稳定程度。I=Ce/(Ce+Ca)。它的值处于[0,1]之间。I=0时说明包是最稳定的,反之I=1则说明包极不稳定。
Distance from the Main Sequence (D): 该指标主要用来评价包的抽象程度与稳定程度的平衡关系,它可以用二维直线图 A + I = 1 来表示。D=abs((A + I) - 1),也就是说D为 一个包的抽象度 + 包的不稳定程度 - 1 的绝对值。一个理想的包是:完全抽象的(A=1),非常稳定的(I=0),这时D=0;或者是:完全具体类构成的包(A=0),非常不稳定的 (I=1),这时同样也有D=0。D=0说明包的抽象程度与稳定程度是平衡的,反之D=1说明包的平衡程度被严重破坏。
Package Dependency Cycles:包的循环依赖度。
面向对象的设计原则之一:The Acyclic Dependencies Principle (ADP) - OO设计的无环依赖原则要求包之间不能有循环依赖关系。
如果EclEmma只能测试Java Application的测试覆盖率,那么它相对命令行版本的Emma来说,提供的增强就不多了。相反,EclEmma提供了很多与MyEclipse紧密结合的功能。它不仅能测试Java Application,还能计算JUnit单元测试,对MyEclipse插件测试的覆盖率。从图中我们可以看到EclEmma目前支持几种类型的程序。
打开EclEmma运行命令按钮
工具栏右键->Customize Perspective
选择Command Groups Availability->勾选Java Code Coverage->Ok
之后在工具栏就会出现按钮
首先建立一个 HelloWorld 类,其代码如下所示:
package cn.itkt.hotel; public class HelloWorld { public static void main(String[] args) { int rand = (int) (Math.random() * 100); if (rand % 2 == 0) { System.out.println("Hello, world! 0"); } else System.out.println("Hello, world! 1"); int result = rand % 2 == 0 ? rand + rand : rand * rand; System.out.println(result); } }
接下来,我们通过 EclEmma 运行 HelloWorld.main() 函数。
执行完毕之后,我们正在编辑 HelloWorld.java 的窗口将会变成如下所示:
在Java编辑器中,EclEmma用不同的色彩标示了源代码的测试情况。其中,绿色的行表示该行代码被完整的执行,红色部分表示该行代码根本没有被执行,而黄色的行表明该行代码部分被执行。黄色的行通常出现在单行代码包含分支的情况,例如上图 中16行就显示为黄色。由于程序中有一个随机确定的分支,因此读者的窗口可能与这里稍有不同(11行或者14 行中有且只有一个红色的行)。
除了在源代码编辑窗口直接进行着色之外,EclEmma 还提供了一个单独的视图来统计程序的覆盖测试率。
EclEmma提供的Coverage视图能够分层的显示代码的覆盖测试率,上图中的信息表明我们对HelloWorld的一次运行覆盖了大约68.6%的代码。
想在一次运行中覆盖所有的代码通常比较困难,如果能把多次测试的覆盖数据综合起来进行察看,那么我们就能更方便的掌握多次测试的测试效果。EclEmma提供了这样的功能。现在,让我们重复数次对HelloWorld的覆盖测试。我们注意到Coverage视图总是显示最新完成的一次覆盖测试。事实上,EclEmma为我们保存了所有的测试结果。接下来,我们将通过 Coverage视图的工具按钮来结合多次覆盖测试的结果。
当我们多次运行 Coverage 之后,我们可以单击图中所示工具栏按钮。之后,一个对话框将被弹出以供用户选择需要合并的覆盖测试。
在合并完成之后,我们可以观察到 Java 编辑器和 Coverage 视图中都显示了合并之后的结果:
图中,我们可以看到,通过多次运行覆盖测试,最终我们的代码达到了91.4%的测试覆盖率。有趣的是,图中第三行代码被标记为红色,而此行代码实际上是不可执行的。奥妙在于,我们没有生成任何HelloWorld类的实例,因此缺省构造函数没有被调用,而EclEmma将这个特殊代码的覆盖状态标记在类声明的第一行。
找到MyEclipse->Window->Preferences->Java->反编译器
上图为Eclipse Class Decompiler的首选项页面,可以选择缺省的反编译器工具,并进行反编译器的基本设置。缺省的反编译工具为JD-Core,JD-Core更为先进一些,支持泛型、Enum、注解等JDK1.5以后才有的新语法。
首选项配置选项:
1.1 重用缓存代码:只会反编译一次,以后每次打开该类文件,都显示的是缓存的反编译代码。
1.2 忽略已存在的源代码:若未选中,则查看Class文件是否已绑定了Java源代码,如果已绑定,则显示Java源代码,如果未绑定,则反编译Class文件。若选中此项,则忽略已绑定的Java源代码,显示反编译结果。
1.3 显示反编译器报告:显示反编译器反编译后生成的数据报告及异常信息。
1.4 使用MyEclipse代码格式化工具:使用Eclipse格式化工具对反编译结果重新格式化排版,反编译整个Jar包时,此操作会消耗一些时间。
1.5 使用MyEclipse成员排序:使用Eclipse成员排序对反编译结果重新格式化排版,反编译整个Jar包时,此操作会消耗大量时间。
1.6 以注释方式输出原始行号信息:如果Class文件包含原始行号信息,则会将行号信息以注释的方式打印到反编译结果中。
1.7 根据行号对齐源代码以便于调试:若选中该项,插件会采用AST工具分析反编译结果,并根据行号信息调整代码顺序,以便于Debug过程中的单步跟踪调试。
1.8 设置类反编译查看器作为缺省的类文件编辑器:默认为选中,将忽略MyEclipse自带的Class Viewer,每次MyEclipse启动后,默认使用本插件提供的类查看器打开Class文件。
配置完后检查class文件默认打开方式,MyEclipse->Window->Preferences->General->Editors->File Associations
我们可以看到class文件的打开方式有两个,类反编译查看器和MyEclipse自带的Class File Viewer,而类反编译查看器是默认的才行。
插件提供了系统菜单,工具栏,当打开了插件提供的类反编译查看器后,会激活菜单和工具栏选项,可以方便的进行首选项配置,切换反编译工具重新反编译,以及导出反编译结果。
类反编译查看器右键菜单包含了MyEclipse自带类查看器右键菜单的全部选项,并增加了一个“导出反编译源代码”菜单项。
打开项目路径下的Class文件,如果设置类反编译查看器为缺省的查看器,直接双击Class文件即可,如果没有设置为缺省查看器,可以使用右键菜单进行查看。
Eclipse Class Decompiler插件也提供了反编译整个Jar文件或者Java包的反编译。该操作支持Package Explorer对包显示布局的操作,如果是平铺模式布局,则导出的源代码不包含子包,如果是层级模式布局,则导出选中的包及其所有的子包。
注意:包的“平铺模式布局”和“层级模式布局”的设置
Debug调试:可以在首选项选中对齐行号进行单步跟踪调试,和普通的包含源代码时的调试操作完全一致,同样的也可以设置断点进行跟踪。
注意:首选项选择“根据对齐行号进行单步跟踪调试”后,必须重新反编译class文件才行,否则还是原来事先编译好的代码,会导致跟踪调试失败。重新编译的方法:1:上面图中菜单栏。2:上面图中类打开方式。