测试方法

测试方法

1：具体功能的测试：

验证需求分析设计的具体功能实现

2：组合操作的测试：

操作项按一定的顺序进行操作，验证系统不会出现意外错误。 考虑功能项之间的数据是否会存在关联（如查询功能，需要将个条件逐一累加进行测试；增完的数据能否改，改完能否删，删完能否在增，这之间能否查询到正确的结果；按钮的连续多次点击是否会出现异常；有严格前后顺序要求的几个操作，尝试颠倒顺序操作，系统能否控制等）；

3：GUI界面的测试：

限长、非法输入等（在测试时，要从实际使用者的操作习惯出发。）

4：数据初始化情况测试：

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

5：业务需求实现是否正确：

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

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

c：提供的实现方式是否合理（比如只在某一页面提供某数据的获取功能，但根据业务划分有些人员不能操作此页面，却必须要能看到该数据）； d：所做的数据控制是否何理（比如必须在A功能中新增数据，然后才能在B功能中操作，但实际业务中可能出现相反操作）；

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

f：其他操作细节上的满足（业务上需要批量操作的数据是否提供批量操作的功能、导入失败的结果文件是否能修改后直接再导入）；

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

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

a:数据完整性测试：当某数据被其他功能引用、或者当前功能要引用其他来源的数据，就会涉及到完整性从测试。最常见的如被引用的数据删除了，或者关键字被修改了，引用的数据是否会出错；两个途径进入的数据是否会冲突或重复；此外还有因为相关功能由不同人员编码，从而导致彼此的控制不一致，如A功能进入的数据可允许的极端情况下，到B功能中引用是否会异常（如A功能允许长度为10，但引用到B项中填写时运行长度为8，就会显示异常）；

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

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

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

7：测试数据的设计：

a：尽量避免可能出现歧义测试结果的数据，即你设计的数据必须能唯一正确地反映出你所希望测试的结果。比如一组测试数据，有可能得到结果A或结果B，此时单用此数据来测试预期结果为A的用例，那明显就产生了歧义。

b：对于不便具体列示的数据，则必须详细描述其各项特性：有时我们在设计用例时为节约时间，不一定要到具体的一个数值，这也是允许的，但前提是你必须要详细描述清楚你要测试的数据特性。比如数据库字段限长20，要测试超长数据时，可以描述为：尝试输入长度为21位的半角英文字符；尝试输入长度为19位的半角英文字符，然后切换到中文全角再输入一位全角字符等。千万不能写成：尝试输入超长字符，因为这只能是测试方案，作为方案是可以这样写，但到用例阶段，必须要是具体的、明确的、可操作的。

c：测试数据的设计必须有明确目的性：即测试数据是从测试方案衍生而来的。如上例测试方案是测超长字符输入控制，所以测试数据就要根据具体字段长度来录入超长数据，如果一味录入长15位、长16位的数据那就没意义了。好的测试数据是可以同时针对多个测试方案的，此时可以在用例边注明一下该数据的测试目的，因为随着时间推移，对着具体的数据你也许会忘了它到底是测什么的，而这对你最后总结测试，查验测试覆盖率是非常不利的，所以随时记下你的思路想法吧，好记性不如烂笔头。

d：测试数据可省略描述：测试数据描述以能让人看懂为准则。所以写用例时当碰到连续几个用例，仅某几个关键数据值改动，其余均是一样的情况下，不必每个用例都要重复描述所有数据，可以在第一个用例描述完整之后，其余用例中仅列示不同的数据，并标明其余数据同上第X个用例，即可。这样测试时仍能复原测试数据，且该用例的测试目的一眼就明，增加了用例的清晰性。