软件测试用例设计方法之切面设计(2)

　　(3)、GUI界面的测试

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

　　(4)、数据初始化情况测试

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

　　(5)、业务需求实现是否正确

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

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

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

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

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

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

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

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

　　2、功能切面隐含测试项用例设计：

　　(1)、数据完整性的测试

　　当某数据被其它功能引用;或当前功能要引用其它来源的数据，就会涉及到数据完整性的测试。最常见的如被引用的数据删除了，或关键字被修改了，引用的数据会否出错;两个途径进入的数据会否冲突或重复;此外还有因为相关的几个功能由不同人员编码，从而导致彼此的控制不一致，如A功能进入的数据在可允许的极端情况下，到B功能中引用会否异常(最常见如用户名录入时允许长度10，但引用到某个单子填写时允许长度是8，此时就会异常了)。

　　(2)、后台的特殊处理

　　是指某功能除了表面所见以外的程序处理。比如订单录入，表面所见的就是订单的保存，但后台还会有重复数据的判断、非法数据的处理、业务逻辑上冲突情况的处理以及其它种种根据需求设计所特有的处理。又比如备份功能，在备份前可能有数据的清空、备份目录的清空、备份目标是否存在的校验、备份文件重复时的处理等等。类似这些在分析设计中就未必会写全了，还是要测试人员多花心思去思考挖掘。

　　(3)、功能业务之间的关联与转换

　　相关联的几个功能之间数据的传递，会否产生影响。比如新增录入的某种特殊字符，要查询时会引起查询SQL语句异常;又如某下载文件名中存在中文等字符，下载时由于编码问题导致乱码的出现;再有报表填写时到小数点后四位，生成报文时会不会被忽略成两位了等等。象这种问题，通常只能是在每个功能设计用例时，尽量保证用例中的数据能涉及到允许范围的各种情况，即充分运用等价类划分+边界值的方法设计出各种“稀奇古怪”的数据，并需验证这些数据从头流到尾，都还是能保持其正确性，而不仅仅是在当前功能中正确。

　　(4)、从设计实现发掘测试点

　　这个就是我们测试中最难捉的BUG了，它往往是由编码人员自己在编码时创造出来的，连设计人员都不会知道。

　　比如内部管理系统中，正常的产品，其类别通常是2位数字;如果是模块，其类别就以产品代码来取代。这时如何来判断该产品是模块呢?最保险的当然是校验其产品类别字段的值能否在产品表中找到;也有比较简单的方法就是直接判断类别代码大于2位还是小于等于2位。此时若能确切知道采用的是哪种实现方法，就可以直接找到其漏洞所在。比如采用后一种方法，当产品类别长度变化时，明显系统会出错。那么即使确认该实现方式不改，测试人员也应将其作为限制写入测试报告，。让大家知道这个产品类别长度是不能随意变化的。

　　而让人郁闷的是，类似这样的实现，有太多的编码人员都是随性处理的，它们细而隐蔽，在系统数据正常情况下根本不会被发现;而在漫漫的软件使用道路中，由于需求变更等原因对原有一些设计做维护变化，这种问题就会突然暴发出来让人措不及防。所以要杜绝这类漏洞，除了测试人员要做土拨鼠，不停地对软件各功能的实现细节进行挖掘外，也要多给编码人员灌输完美实现的理念，多用复杂但抗压性高的代码，来替代简单但依赖性强的代码。

　　(5)、并发操作时的测试

　　即两个或多个用户同时操作同一功能时，会否引起数据的混乱。通常在C/S结构下，如果有同时操作的可能，是需要作此测试的;而在B/S结构下由于其特殊性，此问题通常难以解决。除非就是某用户一旦使用过某功能后，在一定时间内锁定不允许再用，但这也会带来实际应用中的不便，所以除非是特别核心的数据，一般我们也不会去做此控制，当然对于可能出现的并发冲突也就作为系统的限制进行遗留了。

　　3、特定切面用例设计

　　所谓特定切面，其实就是从另一个角度切割出来的用例面，所以具体的用例撰写方式其实与功能切面是一致的。

　　4、隐含切面用例设计

　　隐含切面分以下几种情况：

　　(1)、无界面的后台功能

　　对这类测试项，需要通过参数设置、代码调用等方式来实现测试，但具体的测试设计其实与普通功能测试并无二致。这里要注意，因为测试时往往前台、后台是分开来分别进行的，而实际运行时两者很可能是交集的，所以测试时要多注意后台功能的执行与前台的一些功能执行会否产生冲突?比如后台有个文件搬运的服务，那有没有可能在前台文件生成过程中，后台执行文件搬运了?若有可能就要注意会否出现问题了。

原文转自：http://www.ltesting.net