二、详细用例的设计

　　划分好了测试项，接着是针对各个测试项，考虑具体的测试用例了。根据测试项的特点，测试用例的设计角度也有所不同。下面我们来看看通常的功能点测试用例，该从哪些角度出发来进行设计：

　　1、功能切面表面用例设计

　　（1）、具体功能测试

　　根据需求分析设计，按页面提供的各个功能项，采用黑盒测试的各种方法，设计用例。比如页面提供了增、删、改、查功能，那么这四个功能是否正确实现是我要验证的。这是简单、基本，同时也是必须的测试用例，通常我们的编码人员自测也是做到这个程度。^_^

　　（2）、组合操作的测试

　　这是从上一角度扩展出来的，相对而言也是编码人员不会去测试的，所以需要测试人员多作考虑。

　　所谓组合操作测试，也是选择某几个操作项，按一定的顺序进行操作，验证系统不会出现意外错误。当然要将所有功能项排列组合一遍来测试不仅不必要，也是不可能的。所以具体要将哪些功能项进行结合，要按怎样的步骤来操作，还是需要测试人员根据实际情况来作设计（所以说在IT业人才是一切呀，呵呵：）。

　　一般来说我们会考虑功能项之间的数据是否会存在关联，若有需要考虑这种组合了。常见的如查询功能，需要将各条件逐一累加进行测试；增完的数据能否改，改完能否删，删完能否再增，这之间能否查询到正确结果；按钮的连续多次点击会否出现异常；有严格前后顺序要求的几个操作，尝试颠倒顺序去操作，系统能否控制等等。

　　不仅在某功能内部，扩展到有关联的多个功能项之间，同样有组合操作测试的存在。如申报完了能才反馈；如申报成功或失败后再尝试申报等。当然对于这类用例既可以写到某个功能切面中，也可以单独写到完整业务流程的切面中，这取决于可能涉及用例的数量了，若关系比较复杂，当然是单独写比较好；若也是三五个用例数，那直接在某个功能的用例中补充好了。

　　（3）、GUI界面的测试

　　这类测试是测试人员的强项，具体测试项目如限长、非法输入等等，不必赘述了。要提醒的是在测试时，一定要从实际使用者的操作习惯出发。要知道界面原型所能确定的也只是页面的摆放显示，而实际操作时的控制实现仍是编码人员自行实现的，即使有编码指南，其所及范围也是十分有限。而许多编码人员在用户操作方便性上的考虑往往差强人意。所以测试人员必须要把好这一关。

　　（4）、数据初始化情况测试

　　不该为空的数据是否有校验；该有默认值的数据默认值是否正确；引用其它功能生成的数据，是否会实时刷新；页面关闭或系统重启后，数据的初始化设置等都是这类用例。

　　（5）、业务需求实现是否正确

　　这类问题往往是由于我们的需求说明欠详细，而编码人员的需求了解程度又较低造成。作为测试人员自然要对需求进行深刻研究，来对软件实现进行把关。这里常见的一些关注点有：

　　●数据的长度、类型控制是否合理（比如控制纳税人识别号只能为数字，但实际业务中是会有字母出现的）；

　　●业务逻辑控制是否合理（比如某数据项不提供修改，但实际业务中该数据项经常会需要改动）；

　　●提供的实现方式是否合理（比如只在某一页面提供某数据的获取功能，但根据业务划分有些人员不能操作此页面，却必须要能看到该数据）；

　　●所做的数据控制是否合理（比如必须在A功能中新增数据，然后才能在B功能中操作，但实际业务中有可能会出现相反操作）；

　　●所做的数据控制是否完整（如授权的方式有普通按月、有买断、有按数量控制，那么当同一企业尝试同时存在以上几种授权方式时，系统是否能有必要的控制）；

　　●还有其它一些操作细节上的满足（如业务上需要批量操作的数据有否提供批量操作功能、导入失败的结果文件是否能修改后直接再导入等）。

　　对于不满足的需求，经开发组长、需求经理等确认不作修改的，要作为软件的缺限或限制在测试报告中进行说明民。