编辑
作用域 功能 快捷键
全局 查找并替换 Ctrl+F
文本编辑器 查找上一个 Ctrl+Shift+K
文本编辑器 查找下一个 Ctrl+K
全局 撤销 Ctrl+Z
全局 复制 Ctrl+C
全局 恢复上一个选择 Alt+Shift+↓
全局 剪切 Ctrl+X
全局 快速修正 Ctrl1+1
全局 内容辅助 Alt+/
全局 全部选中 Ctrl+A
全局 删除 Delete
全局 上下文信息 Alt+？
Alt+Shift+?
Ctrl+Shift+Space
Java编辑器 显示工具提示描述 F2
Java编辑器 选择封装元素 Alt+Shift+↑
Java编辑器 选择上一个元素 Alt+Shift+←
Java编辑器 选择下一个元素 Alt+Shift+→
文本编辑器 增量查找 Ctrl+J
文本编辑器 增量逆向查找 Ctrl+Shift+J
全局 粘贴 Ctrl+V
全局 重做 Ctrl+Y

?
查看
作用域 功能 快捷键
全局 放大 Ctrl+=
全局 缩小 Ctrl+-

?
窗口
作用域 功能 快捷键
全局 激活编辑器 F12
全局 切换编辑器 Ctrl+Shift+W
全局 上一个编辑器 Ctrl+Shift+F6
全局 上一个视图 Ctrl+Shift+F7
全局 上一个透视图 Ctrl+Shift+F8
全局 下一个编辑器 Ctrl+F6
全局 下一个视图 Ctrl+F7
全局 下一个透视图 Ctrl+F8
文本编辑器 显示标尺上下文菜单 Ctrl+W
全局 显示视图菜单 Ctrl+F10
全局 显示系统菜单 Alt+-

?
导航
作用域 功能 快捷键
Java编辑器 打开结构 Ctrl+F3
全局 打开类型 Ctrl+Shift+T
全局 打开类型层次结构 F4
全局 打开声明 F3
全局 打开外部javadoc Shift+F2
全局 打开资源 Ctrl+Shift+R
全局 后退历史记录 Alt+←
全局 前进历史记录 Alt+→
全局 上一个 Ctrl+,
全局 下一个 Ctrl+.
Java编辑器 显示大纲 Ctrl+O
全局 在层次结构中打开类型 Ctrl+Shift+H
全局 转至匹配的括号 Ctrl+Shift+P
全局 转至上一个编辑位置 Ctrl+Q
Java编辑器 转至上一个成员 Ctrl+Shift+↑
Java编辑器 转至下一个成员 Ctrl+Shift+↓
文本编辑器 转至行 Ctrl+L

搜索
作用域 功能 快捷键
全局 出现在文件中 Ctrl+Shift+U
全局 打开搜索对话框 Ctrl+H
全局 工作区中的声明 Ctrl+G
全局 工作区中的引用 Ctrl+Shift+G

?
文本编辑
作用域 功能 快捷键
文本编辑器 改写切换 Insert
文本编辑器 上滚行 Ctrl+↑
文本编辑器 下滚行 Ctrl+↓

?
文件
作用域 功能 快捷键
全局 保存 Ctrl+X
Ctrl+S
全局 打印 Ctrl+P
全局 关闭 Ctrl+F4
全局 全部保存 Ctrl+Shift+S
全局 全部关闭 Ctrl+Shift+F4
全局 属性 Alt+Enter
全局 新建 Ctrl+N

项目
作用域 功能 快捷键
全局 全部构建 Ctrl+B

源代码
作用域 功能 快捷键
Java编辑器 格式化 Ctrl+Shift+F
Java编辑器 取消注释 Ctrl+\
Java编辑器 注释 Ctrl+/
Java编辑器 添加导入 Ctrl+Shift+M
Java编辑器 组织导入 Ctrl+Shift+O
Java编辑器 使用try/catch块来包围 未设置，太常用了，所以在这里列出,建议自己设置。
也可以使用Ctrl+1自动修正。

?
运行
作用域 功能 快捷键
全局 单步返回 F7
全局 单步跳过 F6
全局 单步跳入 F5
全局 单步跳入选择 Ctrl+F5
全局 调试上次启动 F11
全局 继续 F8
全局 使用过滤器单步执行 Shift+F5
全局 添加/去除断点 Ctrl+Shift+B
全局 显示 Ctrl+D
全局 运行上次启动 Ctrl+F11
全局 运行至行 Ctrl+R
全局 执行 Ctrl+U

重构
作用域 功能 快捷键
全局 撤销重构 Alt+Shift+Z
全局 抽取方法 Alt+Shift+M
全局 抽取局部变量 Alt+Shift+L
全局 内联 Alt+Shift+I
全局 移动 Alt+Shift+V
全局 重命名 Alt+Shift+R
全局 重做 Alt+Shift+Y

4.1 结果是否正确 Right-BICEP

如果代码能够运行正确，我要怎么才知道它是正确的呢

  如果你不能很好地回答这个问题，那么编写代码——或者测试——完全就是在浪费时间。

  在代码的整个生命期中，“正确”的定义可能会不断在变；但是无论如何，你至少需要确认代码所做的和你的期望是一致的。

·使用数据文件

  对于许多有大量测试数据的测试，你可能会考虑用一个独立的数据文件来存储这些测试数据，然后让单元测试读取该文件。

  多注意一下测试数据。经验告诉我们，测试数据比代码更有可能是错的，特别是人工计算的，或者来自原有系统计算结果的测试数据。因此，当测试数据显示有错误发生的时间，你应该在怀疑代码前先对测试数据检查两三遍。

  一个原则是：对于验证被测方法是正确的这件事情，如果某些做法能够使它变得更加容易，那么就采纳它吧。

4.2 边界条件 Right-BICEP

找边界条件是做单元测试中最有价值的工作之一，因为bug一般就出现在边界上。一些需要你考虑得条件有。

·完全伪造或者不一致的输入数据，例如一个名为“!*W:X\&Gi/w~>g/h#WQ@”的文件。

·格式错误的数据，例如没有顶层域名的电子邮件地址就像fred@foobar这样的。

·控制或者不完整的值（如0, 0.0, “”和null）。

·一些与意料中的合理值相去甚远的数值。例如一个人的岁数为10000岁。

·如果要求的是一个不允许出现重复数值的list，但是传入的是一个存在重复数值的list。

·如果要求的是一个有序list，但是传入的是一个无序的list；或者反之。例如，给一个要求排好序的算法传入一个未排序的list——甚至一个反序的list。

·事情到达的次序是错误的，或者碰巧和期望的次序不一致。例如，在未登录系统之前，就尝试打印文档。

一个向导可能的边界条件CORRECT。对于其中的每一条，都应该想想它是否与存在于被测方法中的某个条件非常类似，而当这些条件被违反的时，出现的又是什么情况。

·Conformance（一致性）——值是否和预期的一致。

·Ordering（顺序性）——值是否如应该的那样，是有序或者无序的。

·Range（区间性）——值是否位于合理的最小值和最大值之内。

·Reference（依赖性）——代码是否引用了一些不再代码本身控制范围之内的外部资源。

·Existence（存在性）——值是否存在（例如，是否是非null，非0，再一个集合中等等）

·Cardinatity（基数性）——是否恰好有足够的值？

·Time（相对或者绝对的时间性）——所有事情的发生是否是有序的？是否是在正确的时刻？是否恰好及时？

4.3 检查反向关联 Right-BICEP

  对于一些方法，我们可以使用反向的逻辑关系来验证它们。

要注意的是：当你同时编写了原方法和它的反向测试时，一些bug可能会被在两个函数中都出现的错误所掩盖。在可能的情况下，应该使用不同的原理来编写反向测试。

4.4 使用其他手段来实现交叉检查 Right-BICEP

通常而言，计算一个量会有一种以上的算法。我们可能会基于运行效率或者其他的特性，来选择算法。那是我们要在产品中使用的；但是在测试用的系统中，可以使用剩下算法中的一个来交叉测试结果。当确实存在一种经过验证并能完成任务的算法，只是由于速度太慢或者太不灵活而没有在产品代码中使用，这种交叉检查的技术将非常有效。

另一种办法就是：使用类本身不同组成部分的数据，并且确信它们能和“合起来”。

4.5 强制产生错误条件 Right-BICEP

在真实世界中，错误总是会发生：磁盘会慢，网络连线会断开，电子邮件会多的像掉进了黑洞，而程序会崩溃。你应当能够通过强制引发错误，来测试你的代码是如何处理所有这些真实世界中的问题的。

4.6 性能特性 Right-BICEP

一个检查起来会很有益处的部分是性能特性，而不是性能本身。

你也许需要一些测试辅助工具。它们嫩构提供对单个测试进行计时，模拟告负在情况之类的功能，比如免费的JUnitPerf。

第1章 序言

·什么是单元测试

单元测试是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。

·为什么要使用单元测试

单元测试不但会使你的工作完成得更轻松，而且会令你的设计变得更好。甚至大大减少你花在调试上面的时间。

·不写测试的借口

编写单元测试太花时间了

运行测试的时间太长了

测试代码并不是我的工作

我并不清楚代码的行为，所以也就无从测试

但是这些代码都能够编译通过

公司请我来试我是为了写代码，而不是写测试

如果我让测试员或者QA人员没有工作，那么我会觉得很内疚

我的公司并不会让我在真实系统中运行单元测试

第3章 使用JUnit编写测试

3.1 构建单元测试

  测试代码必须要做以下几件事情：

·准备测试所需要的各种条件（创建所有必须的对象，分配必要的资源等等）。

·调用要测试的方法。

·验证被测试方法的行为和期望是否一致。

·完成后清理各种资源。

3.2 JUnit的各种断言

  JUnit提供了一些辅助函数，用于帮助你确定某个被测试函数是否工作正常。通常而言，我们把所有这些函数统称为断言。断言是单元测试最基本的组成部分。

  当一个失败或错误出现的时候，当前测试方法的执行流程将会被种植，但是（位于同一个测试类中的）其他测试将会继续运行。

 · assertEquals

assertEquals([String message],

expected,

actual)

这是使用得最多的断言形式。在上面的参数中，expected是你的期望值（通常都是硬编码的），actual是被测试代码实际产生的值，message是一个可选的消息，如果提供的话，将会在发生错误的时候报告这个消息。当然，你完全可以不提供这个message参数，而只提供expected和value这两个值。

任何对象都可以拿来做相等性测试：适当的相等性判断方法会被用来做这样的比较。值得注意的是使用原生数组的equals方法时，它并不是比较数组的内容，而只是比较数组引用本身，而这大概不是你希望的吧。

计算机并不能精确地表示所有的浮点数，通常都会有一些偏差。因而，如果你想用断言来比较浮点数（在Java中，是类型为float或者double的数），则需要制定一个额外的误差参数。它表明你需要多接近才能认为两数“相等”。

assertEquals([String message],

expected,

actual,

tolerance)

·assertNull

assertNull([String message], java.lang.Object object)

assertNotNull([String message], java.lang.Object object)

验证一个给定的对象是否为null（或者为非null），如果答案为否，则将会失败。message参数是可选的。

·assertSame

assertSame([String message], expected, actual)

验证expected参数和actual参数所引用的是否为同一个对象，如果不是的话，将会失败。message参数是可选的。

assertNotSame([String message], expected, actual)

验证expected参数和actual参数所应用的是否为不同的对象，如果是相同的话，将会失败。message参数是可选的。

·assertTrue

assertTrue([String message], Boolean condition)

验证给定的二元条件是否为真，如果为假的话，将会失败。meesage参数是可选的。

如果你发现测试代码像下面这样，宛如废话一般：

asserTrue(true);

那么你就该好好想想这些代码了。对于这种写法，除非是被用于确认某个分支，或者一场逻辑才有可能是正确的选择；否则的话，很可能就是一个糟糕的主意。

assertFalse([String message], Boolean condition)

上面的代码用于验证给定的二元条件是否为假。如果不是的话，该测试将会失败。

·fail

fail([String message])

上面的断言将会使测试立即失败，其中message参数是可选的。这种断言通常被用于标记某个不应该被到达的分支（譬如，在一个与预期发生的异常之后）。

·使用断言

一般而言，一个测试方法会包含有多个断言，因为你需要验证该方法的多个方面以及内在的多种联系。

当有测试失败的时候，无论如何都不能给原有代码再添加新的特性！此时你应该尽快地修复这个错误，直到让所有的测试都能顺利通过。

3.3 JUnit框架

每个包含测试的类都必须如所示那样由TestCase继承而来。基类TestCase提供了我们所需的大部分单元测试功能，包括所有在前面讲述过的断言方法。

基类需要一个以String为参数的构造函数，因而我们必须调用super以传递这么一个名字。

测试类包含了名为test…的方法。而所有以test开头的方法都会被JUnit自动运行。你还可以通过定义suite方法制定特殊的函数来运行。

3.4 JUnit测试的组成

一个测试类包含一些测试方法；每个方法包含一个或者多个断言语句。但是测试类也能调用其它测试类：单独的类、包、甚至完整的一个系统。可以通过创建test suite来取得。任何测试类都能包含一个名为suite的静态方法。

public static Test suite();

你可以提供suite()方法来返回任何你想要的测试集合（没有suite()方法，JUnit会自动运行所有的test…方法）。但是你可能需要手工添加特殊的测试，包括其他suite。

· Per-method的Setup和Tear-down

JUnit的TestCase基类提供两个方法供你改写，分别用于环境的建立和清理：

protected void setup();

protected void teardown();

· Per-suite Setup和Tear-down

一般而言，你只须针对每个方法设置运行环境；但是在某些情况下，你须为整个test suite设置一些环境，以及在test suite中的所有方法都执行完成后做一些清理工作。要达到这种效果，你需要per-suite setup和per-suite teardown。

Per-suite的setup要复杂一些。你需要提供所需测试的一个suite（无论通过什么样的方式）并且把它包装进一个TestSetup对象。

注意你可以在同一个类中同时使用per-sutie和per-test的setup()和teardown。

3.5 自定义JUnit断言

如果你有需要在整个项目中共享的断言或者公共代码，你也许需要考虑从TestCase继承一个类并且使用这个字类来进行所有的测试。

事实上，开始新项目时总是从自己的自定义基类继承而不直接从JUnit的类继承通常是一个好主意——即便你的基类在一开始没有添加任何额外的功能。这样做的好处是当你需要添加一个所有测试类都需要的方法或者能力时，可以简单地编辑你的基类而不需要改动项目中的所有test case。

3.6 JUnit和异常

对于测试而言，下面两种异常是我们可能会感兴趣的：

1．  从测试代码抛出的可预测异常。

2．  由于某个模块（或代码）发生严重错误，而抛出的不可预测异常。

任何对assertTrue(true)的使用都应该被翻译为“我预期控制流程会达到这个地方”。这对将来可能的误解来说会起到强有力的文档的作用。然而，不要忘记一个assertTrue(true)没有被调用不会产生任何错误的。

通常而言，对于方法中每个被期望的异常，你都应该写一个专门的测试来确认该方法在应该抛出异常的时候确实会抛出异常。

对于处于出乎意料的异常，你最好简单的改变你的测试方法的声明让它能抛出可能的异常。JUnit框架可以捕获任何异常，并且把它报告为一个错误，这些都不需要你的参与。

3.7 关于命名的更多说明

如果编写了一个测试，但是实现代码还没有准备好，可以将以“test”打头的测试方法名米功能为别的，譬如把“test”去掉，然后等准备好了要来运行测试的时候再改回来。

无论如何，你要避免养成忽略“失败的测试结果”的习惯。

3.8 JUnit测试骨架

用JUnit写测试真正所需要的就三件事：

1．  一个import语句引入所有junit.framework.*下的类。

2．  一个extends语句让你的类从TestCase继承。

3．  一个调用super(string)的构造函数。

Eclipse官方主页：http://www.eclipse.org

Myeclipse：一个基于Eclipse的很全面好用的J2EE开发平台（需付费使用）
主页：http://www.myeclipseide.com

VE Editor：图形化的开发GUI界面的插件。
主页：http://www.eclipse.org/vep/
     先决条件是安装EMF和GET。
         EMF：http://www.eclipse.org/emf/
         GEF：www.eclipse.org/gef/

XMLBuddy：很不错的开发XML插件。
主页：http://xmlbuddy.com

Lomboz：开发J2EE首选插件。
主页：http://www.objectlearn.com/

sysdeo Tomcat Plugin：一个方便实用的tomcat插件。
主页：http://www.sysdeo.com/eclipse/tomcatPlugin.html

UML2：一个支持UML开发的插件。
主页：http://www.eclipse.org/uml2/
        先决条件是安装EMF。
        EMF：http://www.eclipse.org/emf/

Easy Struts：开发struts的插件。
主页：http://easystruts.sourceforge.net/

JInto：开发资源文件的一个插件。
主页：http://www.guh-software.de/jinto_en.html

KeePresident：加快Eclipse速度的插件。（仅适用于Windows平台）
主页：http://suif.stanford.edu/pub/keepresident/

JBossIDE：在JBOSS服务器上的开发J2EE的插件。
主页：http://www.jboss.com/products/jbosside

如果想采取link方式安装插件，可看这篇文章（点击这里）。
一些介绍eclipse插件使用的地方（点击这里）。

你有什么好用的插件吗？留言告诉我，大家一起分享吧：）

直接在struts-config.xml中右键data-sources然后New。

默认的type是：

org.apache.struts.util.GenericDataSource

struts自带的一个数据库连接池。

然后正确输入各种property的value。

测试，好用。

如果将type选择为：

org.apache.commons.dbcp.BasicDataSource

这个DBCP的数据库连接池。

然后键入正确的value。

测试，提示各种异常&找不到Driver。

查看DBCP的文档，发现MYECLIPSE生成的配置XML元素有问题。

DBCP需要的是driverClassName和username这两个propertys。

而Myeclipse自动生成的是driverClass和user这两个propertys。

改过来之后发现DBCP的数据库连接池也好用了：）

这应该算是MYECLIPSE开发struts的一个BUG吧，数据库连接池的配置是按照struts默认的GenericDataSource来的。如果能动态的在选择数据库连接池的时候，找寻set()/get()方法来生成属性的名字应该更好。

也看出来不同的数据库连接池在命名规则方面存在的一些差异。

其实很简单的东西，我却花费了半天的时间，原因是我太相信工具了，以为生成的东西一定是正确的，所以一直在想是不是别的方面出错了。得到这次教训之后，要更加清晰的对工具持怀疑态度了。不能太过相信和依靠，还是自己对这些技术的了解最重要。

PS：TOMCAT有自带DBCP。不过我是自己从jakarta上面下的commons dbcp放到自己的lib里面的，当然，官方doc上面有这样的说明：

Commons-DBCP depends at runtime on commons-pool and commons-collections .

所以记得要把这两项也下回来和dbcp的jar文件一起放进lib才能保证不出错。

总之，认真＋心细，才能更好的解决问题。

本文环境：
Win2003  + jdk1.5.0_01
Tomcat 5.5 +  MySql4.1
Eclipse 3.0.1 + Myeclipse 3.8.4

本文提到的一些软件的下载地址：

J2SE 5.0（SUN弄的这些乱七八糟的名字真讨厌，混乱的感觉）：
http://java.sun.com/j2se/1.5.0/download.jsp

Tomcat：
http://jakarta.apache.org/site/downloads/downloads_tomcat-5.cgi

MySql4.1：
http://dev.mysql.com/downloads/

Eclipse：
http://www.eclipse.org/downloads/index.php

Jakarta commons（DBCP和其所需要的commons pool和commons collections都是在这里下）：
http://jakarta.apache.org/site/downloads/downloads_commons.html