开发人员如何做好单元测试

如何做好单元测试
一． 什么是单元测试？
单元测试是开发人员在程序编写或修改过程中，完成某一功能模块后，对完成的模
块进行的测试。一个功能模块，一个类，一个方法，一个窗口，一个按钮，一个选择框，
一个输入列等等都可以成为一个测试单元。一般来说，单元测试由开发人员完成。
二． 为什么要进行单元测试？
1． 在集成测试前，开发人员做好单元测试，可以避免模块出现一些常见的错误，减少
BUG率；
2． 在集成测试或验收测试的过程中，开发人员修改问题之后，尤其要做好单元测试，
这样可以避免修改带来其他的问题，减少修改后的BUG率。开发人员将问题修改后，
不进行自我测试，直接交给测试人员的做法不是好习惯；
3． 在试运行和实施中，开发人员修改问题后，做好单元测试，减少面对用户的BUG，
减少出现错误数据的机会，可以提高软件的服务质量，提高实施的效率，否则由于
程序的问题带来的错误数据，将在很长一段时间内花费开发和维护人员大量的精力
进行调整和清理，还可能影响用户报表数据。
三． 单元测试的覆盖范围
单元测试覆盖在程序的编码和修改的所有过程，包括：编码阶段，测试阶段，实施
阶段，服务阶段。尤其是系统上线之后的实施阶段和服务阶段，修改问题后，需要严格
的单元测试，这种情况下，往往还要配合流程的测试，避免修改影响其他流程的运行和
流程数据。
四． 典型测试用例
1． 边界值测试
由长期的测试工作经验得知，大量的错误是发生在输入或输出的边界上。开发人员
对自己开发的模块的边界值情况是最了解的，因此针对各种边界情况进行测试，可以查
出更多的错误。
2． 路径测试
对开发人员来说，在编码中有多少分支情况是最清楚的，遍历所有的分支路径情况
进行测试，可以覆盖所有的路径，检查每一种情况的运行结果是否符合预期结果。
对于程序中的if。。。else，或case等编写的部分，应做好路径的充分测试。
3． 组合条件测试
如按条件组合进行查询的情况，需要测试多种组合形式。
4． 等价类测试
如：用户密码不能小于6位的情况测试，一个有效类指挑一个6位的正确密码；
二个无效类指小于6位的密码一个和位数过大的密码一个（比如50位）。
5． 具体功能点的功能测试
针对具体的模块的具体功能进行测试，测试基本的功能能否正常按要求完成。
五． 单元测试要注意的常见的问题
下面列出的都是在以往的测试过程中发现的常见的问题，这些问题的出现频率极高，往
往影响提交的软件的质量，这些问题在开发人员的单元测试中应该加以注意，使提交给测试
组或用户的软件达到可用性好，窗口统一美观，基本功能操作正常。
1． 基本功能是否能成功完成？
2． 窗口上的翻页功能是否能成功翻页？
3． 排序功能是否能成功按选择列排序？
4． 返回按钮是否能返回到应该的页面？
5． 继续增加是否能成功？
6． 组合查询是否所有的列参与组合查询都能成功进行？
7． 显示的详细信息中，是否有显示的是代码不是名称的？
8． 页面上是否因为其中的一列显示过长而使整个页面显示不美观的？
9． 删除等危险操作是否有警告提示信息？
10．录入或修改信息后，系统是否能对信息进行有效性检查？
11．录入窗口上，对非空列是否有明确标识？系统是否对非空列进行非空检查？
12．重复提交的信息是否有唯一性检查？
13．保存成功后的信息，查询显示的结果是否与保存的信息一致？
14．完成一个操作后，窗口是否能及时刷新？刷新信息是否正确？
15．调试信息对话框是否已经隐藏？
16．需要修改状态值的操作，最好通过前台的查询或后台的数据进行查看，检查状态是
否修改正确？
17．对数据库的操作的提示信息是否是用户能识别的信息？是否能避免用户的重复劳
动？
18．窗口的整体风格是否一致？字体类型和大小是否一致？
19．所有提示信息是否恰当、友好？
20．执行某一功能时，系统的反应速度是否在可接受范围内？（这个往往大家并不重视，
所以这个系统反应慢的问题在很多项目中都存在，其实通过调整SQL和索引后，
大多数慢的问题都可以明显得到改善。）
21．某些功能是否符合用户的操作习惯？
22．SQL是否最优化？
23．索引是否建立？建立是否合理？
六． 单元测试建议测试点清单
现在我们所开发的系统基本上都是图形用户界面的，针对这样的图形用户界面，我们
将它分解成以下的单元，并分别罗列出各单元的建议测试需求：
1． 窗口
1） 标题栏的文本是否准确？
2） 所有的菜单项是否恰当？
3） 帮助菜单项是否正常工作？
4） 最大化、最小化按钮是否可见？他们是否应该这样？是否能正常工作？
5） 如果一个窗口被最大化了，那么窗口上的对象（网格、数据窗口、按钮等其他控件）
是否可以被正确地调整？
6） 如果一个窗口被最小化了，是否可以显示恰当的图标？
7） 水平和垂直滚动条是否可见？是否需要？
8） 窗口是否可以改变大小？是否应该这样？
9） 如果窗口可以改变大小，窗口上的所有对象（网格、数据窗口、按钮等其他控件）
是否可以自动调整？
10） 窗口是否可以移动？是否应该这样？
11） 窗口的背景是否被设置为正确的颜色和模式？
12） 用户是否会认为TAB键的顺序是合理的和方便的？
13） 如果对窗口做了改变，用户是否在改变之前得到提示？
14） 窗口的前景色和背景色是否搭配恰当，使文本易读？
15） 需要用户操作的区域是否有可见的提示？
16） 需要回车执行命令的地方是否有明确提示？
17） 窗口的设计风格是否与整个系统的窗口设计风格一致？
2． 菜单
1） 所有的菜单项的分组是否符合逻辑？
2） 快捷键是否被定义？他们是否能正常工作？
3） 多级菜单项是否被恰当地用某种标识标记出来？
4） 多级菜单的使用是否影响窗口的整体美观？
5） 菜单地设计是否在整个系统中保持一致？
6） 不可用的菜单项是否变灰？
7） 如果一个不可用的菜单项变为可用，它是否仍然是灰的？
3． 对话框
1） 是否所有对话框的标题都有意义？
2） 对话框上的所有按钮是否被清楚地标记了？
3） 是否所有地对话框都能够提供一个中断当前操作的机会？
4） 对话框的文本是否清楚易懂？
5） 对话框是否可以移动？是否应该这样？
6） 对一些危险操作（如删除、提交）等，是否有对话框警告提示？
4． 静态文本
1） 是否静态文本受保护，不可以被用户修改？
2） 静态文本所使用的字体大小是否一致？
3） 如果静态文本被应用程序动态地更改了，它是否可以正确地工作？
4） 文本的前景色是否和窗口的背景色对比鲜明？
5． 控制按钮
1） 是否所有的控制按钮都被清楚地标记了？
2） 如果按钮被单击，用户是否可以得到一个可见的提示或按钮变化？
3） 窗口上的控制按钮是否被统一对齐？
4） 按钮风格是否一致？是否有同样的字体类型和大小？
5） 是否每个按钮都能按预计的要求工作？工作的结果是否正确？
6） 是否合理地安排了缺省功能（如：用回车实现）？
7） 是否合理安排了取消功能（如：用ESC键实现）？
6． 单选按钮
1） 是否窗口中的所有单选按钮都是互相排斥的？
2） 窗口中的单选按钮是否被合理地分组？他们是否按照要求工作？
3） 是否清楚地标记了单选按钮？
4） 是否最常用的功能被定为缺省？
5） 如果单选按钮被按下，所有相关的区域是否可以合理地变化？
7． 编辑框
1） 用户是否可以在编辑框中输入或修改文本？
2） 是否所有的编辑框都足够宽，能够放下用户可能的输入值？
3） 当窗口建立时，是否所有的编辑框被正确地初始化了？
4） 对编辑框的输入值是否进行了有效性检查？
8． 列表框
1） 列表框是单选还是多选？功能是否正常？
2） 当窗口建立时，是否所有的列表框被正确地初试化了？当列表框是按照条件进行初
始化时，如果条件具备和不具备的情况下初始化是否正常？
3） 所有列表框的输入值是否有效？
4） 如果一个非法数据被输入，用户是否可以立即得到提示？
5） 列表框显示的值是否符合用户的习惯？
9． 网格
1） 网格是否被正确初始化？
2） 当需要时，垂直或水平滚动条是否能正常工作？
3） 当数据不完整时，所有网格是否完好？
4） 网格是否风格一致？
5） 网格是否在任何情况下都显示齐整？
10． 多选框
1） 是否清楚地标记了多选框？
2） 是否有缺省选择？
3） 选择一个或选择多个是否都能成功完成？
4） 是否有全选按钮支持全选功能？是否能成功完成？
编制人：万翠琼 编制日期：