二、详细用例的设计
　　划分好了测试项，接着是针对各个测试项，考虑具体的测试用例了。根据测试项的特点，测试用例的设计角度也有所不同。下面我们来看看通常的功能点测试用例，该从哪些角度出发来进行设计：
　　1、功能切面表面用例设计
　　（1）、具体功能测试
　　根据需求分析设计，按页面提供的各个功能项，采用黑盒测试的各种方法，设计用例。比如页面提供了增、删、改、查功能，那么这四个功能是否正确实现是我要验证的。这是简单、基本，同时也是必须的测试用例，通常我们的编码人员自测也是做到这个程度。^_^
　　（2）、组合操作的测试
　　这是从上一角度扩展出来的，相对而言也是编码人员不会去测试的，所以需要测试人员多作考虑。
　　所谓组合操作测试，也是选择某几个操作项，按一定的顺序进行操作，验证系统不会出现意外错误。当然要将所有功能项排列组合一遍来测试不仅不必要，也是不可能的。所以具体要将哪些功能项进行结合，要按怎样的步骤来操作，还是需要测试人员根据实际情况来作设计（所以说在IT业人才是一切呀，呵呵：）。
　　一般来说我们会考虑功能项之间的数据是否会存在关联，若有需要考虑这种组合了。常见的如查询功能，需要将各条件逐一累加进行测试；增完的数据能否改，改完能否删，删完能否再增，这之间能否查询到正确结果；按钮的连续多次点击会否出现异常；有严格前后顺序要求的几个操作，尝试颠倒顺序去操作，系统能否控制等等。
　　不仅在某功能内部，扩展到有关联的多个功能项之间，同样有组合操作测试的存在。如申报完了能才反馈；如申报成功或失败后再尝试申报等。当然对于这类用例既可以写到某个功能切面中，也可以单独写到完整业务流程的切面中，这取决于可能涉及用例的数量了，若关系比较复杂，当然是单独写比较好；若也是三五个用例数，那直接在某个功能的用例中补充好了。
　　（3）、GUI界面的测试
　　这类测试是测试人员的强项，具体测试项目如限长、非法输入等等，不必赘述了。要提醒的是在测试时，一定要从实际使用者的操作习惯出发。要知道界面原型所能确定的也只是页面的摆放显示，而实际操作时的控制实现仍是编码人员自行实现的，即使有编码指南，其所及范围也是十分有限。而许多编码人员在用户操作方便性上的考虑往往差强人意。所以测试人员必须要把好这一关。
　　（4）、数据初始化情况测试
　　不该为空的数据是否有校验；该有默认值的数据默认值是否正确；引用其它功能生成的数据，是否会实时刷新；页面关闭或系统重启后，数据的初始化设置等都是这类用例。
　　（5）、业务需求实现是否正确
　　这类问题往往是由于我们的需求说明欠详细，而编码人员的需求了解程度又较低造成。作为测试人员自然要对需求进行深刻研究，来对软件实现进行把关。这里常见的一些关注点有：
　　数据的长度、类型控制是否合理（比如控制纳税人识别号只能为数字，但实际业务中是会有字母出现的）；
　　业务逻辑控制是否合理（比如某数据项不提供修改，但实际业务中该数据项经常会需要改动）；
　　提供的实现方式是否合理（比如只在某一页面提供某数据的获取功能，但根据业务划分有些人员不能操作此页面，却必须要能看到该数据）；
　　所做的数据控制是否合理（比如必须在A功能中新增数据，然后才能在B功能中操作，但实际业务中有可能会出现相反操作）；
　　所做的数据控制是否完整（如授权的方式有普通按月、有买断、有按数量控制，那么当同一企业尝试同时存在以上几种授权方式时，系统是否能有必要的控制）；
　　还有其它一些操作细节上的满足（如业务上需要批量操作的数据有否提供批量操作功能、导入失败的结果文件是否能修改后直接再导入等）。
　　对于不满足的需求，经开发组长、需求经理等确认不作修改的，要作为软件的缺限或限制在测试报告中进行说明民。
　　2、功能切面隐含测试项用例设计：
　　（1）、数据完整性的测试
　　当某数据被其它功能引用；或当前功能要引用其它来源的数据，会涉及到数据完整性的测试。常见的如被引用的数据删除了，或关键字被修改了，引用的数据会否出错；两个途径进入的数据会否冲突或重复；此外还有因为相关的几个功能由不同人员编码，从而导致彼此的控制不一致，如A功能进入的数据在可允许的极端情况下，到B功能中引用会否异常（常见如用户名录入时允许长度10，但引用到某个单子填写时允许长度是8，此时会异常了）。
　　（2）、后台的特殊处理
　　是指某功能除了表面所见以外的程序处理。比如订单录入，表面所见的是订单的保存，但后台还会有重复数据的判断、非法数据的处理、业务逻辑上冲突情况的处理以及其它种种根据需求设计所特有的处理。又比如备份功能，在备份前可能有数据的清空、备份目录的清空、备份目标是否存在的校验、备份文件重复时的处理等等。类似这些在分析设计中未必会写全了，还是要测试人员多花心思去思考挖掘。
　　（3）、功能业务之间的关联与转换
　　相关联的几个功能之间数据的传递，会否产生影响。比如新增录入的某种特殊字符，要查询时会引起查询SQL语句异常；又如某下载文件名中存在中文等字符，下载时由于编码问题导致乱码的出现；再有报表填写时到小数点后四位，生成报文时会不会被忽略成两位了等等。象这种问题，通常只能是在每个功能设计用例时，尽量保证用例中的数据能涉及到允许范围的各种情况，即充分运用等价类划分+边界值的方法设计出各种“稀奇古怪”的数据，并需验证这些数据从头流到尾，都还是能保持其正确性，而不仅仅是在当前功能中正确。
　　（4）、从设计实现发掘测试点
　　这个是我们测试中难捉的BUG了，它往往是由编码人员自己在编码时创造出来的，连设计人员都不会知道。
　　比如内部管理系统中，正常的产品，其类别通常是2位数字；如果是模块，其类别以产品代码来取代。这时如何来判断该产品是模块呢？保险的当然是校验其产品类别字段的值能否在产品表中找到；也有比较简单的方法是直接判断类别代码大于2位还是小于等于2位。此时若能确切知道采用的是哪种实现方法，可以直接找到其漏洞所在。比如采用后一种方法，当产品类别长度变化时，明显系统会出错。那么即使确认该实现方式不改，测试人员也应将其作为限制写入测试报告，。让大家知道这个产品类别长度是不能随意变化的。
　　而让人郁闷的是，类似这样的实现，有太多的编码人员都是随性处理的，它们细而隐蔽，在系统数据正常情况下根本不会被发现；而在漫漫的软件使用道路中，由于需求变更等原因对原有一些设计做维护变化，这种问题会突然暴发出来让人措不及防。所以要杜绝这类漏洞，除了测试人员要做土拨鼠，不停地对软件各功能的实现细节进行挖掘外，也要多给编码人员灌输完美实现的理念，多用复杂但抗压性高的代码，来替代简单但依赖性强的代码。
　　（5）、并发操作时的测试
　　即两个或多个用户同时操作同一功能时，会否引起数据的混乱。通常在C/S结构下，如果有同时操作的可能，是需要作此测试的；而在B/S结构下由于其特殊性，此问题通常难以解决。除非是某用户一旦使用过某功能后，在一定时间内锁定不允许再用，但这也会带来实际应用中的不便，所以除非是特别核心的数据，一般我们也不会去做此控制，当然对于可能出现的并发冲突也作为系统的限制进行遗留了。