从测试用例看测试的问题及变化(3)

　　再进一步的话“数据库”就开始涉及到程序内部的接口，属于单元和集成测试，这需要开发人员的配合。

　　2、为用例标明时间(版本)和优先级

　　为测试用例标明时间或版本可以起到一种基准的作用，标明项目进度过程中的每一个阶段，使用例直接和需求基线、软件版本对应。同样这需要规范流程，也是对变更的一种确认和控制。或者可以为用例增加一个状态，指明这个用例目前是否与程序冲突，当程序变更时改变用例的状态，并更新用例版本。

　　为测试用例标明优先级可以指出软件的测试重点、用例编写的重点，减少用例回归的时间，增加重点用例执行的次数，帮助项目组新人尽快了解需求，在自动化测试的初期也可以参考这个优先级录制脚本。

　　3、功能用例与业务用例分开组织

　　为业务用例单独开辟出一种分类，将功能用例与业务用例分开组织，按照不同关注点列举执行路径。业务用例应在开发前或同期编写，帮助测试人员和开发人员明确业务，了解正确流程和错误流程。功能用例更依赖于程序界面的描述，但功能用例并不等于使用说明。对某些模块的等价类、边界值测试会发现很多严重的bug，也许与业务无关，但用户往往很容易这样操作(例如登录名，你是否考虑到很长的名字，或者用户的键盘有问题，总是敲入n多空格在里面，这与业务无关，但程序将会怎样处理?)。

　　4、审核用例，结对编写

　　测试组长或经理对用例进行审核可以做到用例的补充和校对，但一般情况下是很难做到的，我们可以采用另一种方法，就是结对编写测试用例(前提是你有两个以上的测试人员)，内部审核。

　　测试用例不是自己编写自己执行，它需要其他测试人员都能读懂且明白目标所指。结对编写可以尽量减少个人的“偏好习惯”，同时也能拓展思维，加强测试重点的确认，小组内部达到统一。一定程度上结对编写也可以减少组长或经理对用例的管理负担，提高组员的参与积极性。

　　四、发展

　　上面的这些解决方法只是一种建议，具体如何实施到项目中还需根据情况而定。同时即使我们正在积极的寻求改变，我们还是会碰到无数的新问题和新苦恼，也许会比以前更为众多，这是我们必须付出的。

　　可以看到测试的发展方向很多很广，即使传统的黑盒测试并不是毫无新意，高级的测人员必须同时在测试技巧和专业领域方面都有很高的“修为”。测试工作怎样更适合我们而发展，将给予我们更多的思考。

原文转自：http://www.uml.org.cn/Test/201005192.asp