编写完整有效的测试用例

发表于:2008-09-11来源:作者:点击数: 标签:编写
在测试工作中,“直接拿到软件就测试”的做法曾经很普遍,现今这种情况应该很少了,它只属于那个特定的时期。在回答这个问题之前,我觉得有必要展现这种特殊的情况所处的背景。 ● 它发生在那个软件 开发 不规范的年代,软件开发还处于原始的状态; ● 由于

  在测试工作中,“直接拿到软件就测试”的做法曾经很普遍,现今这种情况应该很少了,它只属于那个特定的时期。在回答这个问题之前,我觉得有必要展现这种特殊的情况所处的背景。

  ● 它发生在那个软件开发不规范的年代,软件开发还处于原始的状态;

  ● 由于不规范,所以不能指望它有完整的开发及测试文档。

  在以上的前提条件下,要在有限的时间内编写有效且完整的测试用例,的确不是一般人可以做到的,对测试人员有特定的要求。

  ● 业务专家型:对软件的业务流程、最终客户的主要使用角色及使用功能都非常熟悉

  ● 精通黑盒测试用例的编写方法

  有了符合以上要求的测试人员后,需要特别指定本次测试的主要目的。

  ● 由于现状的制约,本次测试的主要目的可以定位成:在有限的时间内,站在用户的角度,按照软件最终验收的标准,验证软件的主要功能是否正常;

  ● 在此基础之上,思考最终用户最有可能的失误或者异常操作,验证在这些条件下,软件是否能够正确处理。

  在测试目的的指引下,然后再确定测试环境以及测试类型的取舍。如

  ● 按照用户最流行的软硬件环境配置,搭建测试环境,配置测试和兼容性测试及其他无关的测试都可以暂时取消;

  ● 明确功能测试是重点,压力测试次之。

  走到这一步,测试人员已经明确了测试的主要目的和要进行哪些测试,就可以按照以下原则来设计测试用例了

  ● 根据验收测试的标准,针对不同类型的软件,按照等价类划分、因果图、场景法等,设计有效测试用例;建议在设计测试数据时,如果有条件,可以多参考最终用户以前的历史数据,把有效的业务流程、有效的场景100%覆盖;

  ● 上面的完成后,再最大可能的增加一些异常的测试用例,努力覆盖到用户最可能失误的操作或者异常的操作数据或者流程。

  基于以上的原则,可以在有限的时间内,编写出“相对”完整且有效的测试用例,而不是“绝对”的。

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