核心:覆盖测试需求,尽可能的减少测漏,同时提高测试效率;这种核心本质上就是一种“提醒”的作用。
关键问题在于时间和可执行性,按照传统的方式,把用例写的很详细,各种前提条件,步骤,说明,预期结果,编写人,日期等等,这个时间成本是很高的,我觉得这样写的测试用例连编写人自己都懒得看,只会按照当前的想法来测试,更不用说让非编写人来执行,所以执行性就很低了,所以这种用例文档基本上就是摆设。
我认为,测试用例必须要写,而且必须精简,划分合理,见名知意
1.一看用例名就知道步骤以及预期结果的,只写用例名
2.仅看用例名不知道操作步骤/预期结果的,就把后者写出来(简写或直接以备注、提醒点、验证点、说明代替)
3.针对一些复杂的用例,步骤和预期结果都要写出来(比如一个用例中步骤繁多包括多个验证点)
4.技巧:适当备注(业务逻辑、规则、需求、预期结果、模块划分)
多研究产品,ui交互,对产品有感觉了自然就会发现哪个功能点击会出现什么结果
例子:
用例设计:
说明:
注意:
1.模块层级不能过多,有必要可以2-1子模块的形式;
2.模块下分“字段校验”“功能校验”,
划分依据:把可执行一个完整功能、业务功能的用例放在“功能校验”下,否则放在“字段校验”下;
3.这样写可以突出重点,必要时以功能校验优先。