这里没有软件测试的泛泛理论,只有博主的最佳实践。
博主的研究方向为静态分析和性能测试,致力于各种测试工具的引入、评估和开发。
本博的测试文章均为作者原创,转载请务必注明出处。
我答“如何在有限的时间内编写完整有效的测试用例”
上一篇 /
下一篇 2008-04-10 12:11:29
51testing“每周一问”本周问题是“如何在有限的时间内编写有效完整的测试用例”
http://bbs.51testing.com/thread-110874-1-1.html
在测试工作中,“直接拿到软件就测试”的做法曾经很普遍,现今这种情况应该很少了,它只属于那个特定的时期。在回答这个问题之前,我觉得有必要展现这种特殊的情况所处的背景。
×它发生在那个软件开发不规范的年代,软件开发还处于原始的状态;
×由于不规范,所以不能指望它有完整的开发及测试文档。
在以上的前提条件下,要在有限的时间内编写有效且完整的测试用例,的确不是一般人可以做到的,对测试人员有特定的要求。
×业务专家型:对软件的业务流程、最终客户的主要使用角色及使用功能都非常熟悉
×精通黑盒测试用例的编写方法
有了符合以上要求的测试人员后,需要特别指定本次测试的主要目的。
×由于现状的制约,本次测试的主要目的可以定位成:在有限的时间内,站在用户的角度,按照软件最终验收的标准,验证软件的主要功能是否正常;
×在此基础之上,思考最终用户最有可能的失误或者异常操作,验证在这些条件下,软件是否能够正确处理。
在测试目的的指引下,然后再确定测试环境以及测试类型的取舍。如
×按照用户最流行的软硬件环境配置,搭建测试环境,配置测试和兼容性测试及其他无关的测试都可以暂时取消;
×明确功能测试是重点,压力测试次之。
走到这一步,测试人员已经明确了测试的主要目的和要进行哪些测试,就可以按照以下原则来设计测试用例了
×根据验收测试的标准,针对不同类型的软件,按照等价类划分、因果图、场景法等,设计有效测试用例;建议在设计测试数据时,如果有条件,可以多参考最终用户以前的历史数据,把有效的业务流程、有效的场景100%覆盖;
×上面的完成后,再最大可能的增加一些异常的测试用例,努力覆盖到用户最可能失误的操作或者异常的操作数据或者流程。
基于以上的原则,可以在有限的时间内,编写出“相对”完整且有效的测试用例,而不是“绝对”的。
收藏
举报
TAG: