传统编写测试用例的缺点
,可执行性差
第一页
为什么使用思维导图
把需求文档中的需求点整理到思维导图中,就不用一遍遍的去看文档,节省一些时间;
思维导图更符合人的认知规律;
在时间紧张时,思维导图可以替代用例,省去“写用例”的时间,将更多的时间放到测试执行上;
利于评审。评审思维导图整理出的测试点比评审测试用例更清晰明了。对参加评审的产品和研发人员来说,看到测试点就能了解到测试覆盖是否全面,如果有的测试点不清楚输入输出,可以标出来单独提问;
整理思维导图不会花费很多时间,不会因为增加了这个环节就导致测试时间不够用。
第二页
如何用Xmind编写精简的测试用例
1. 一看用例名,就知道步骤及预期结果的,仅写用例名
这里的用例名,也就是我们的测试点、需求验证点。
2. 仅看用例名,不能预知操作步骤的,还须把操作步骤写出来
3. 仅看用例名,不能预知预期结果的,还须把预期结果写出来
4. 针对一些步骤比较复杂的用例,步骤和预期结果都要写出来。
5. 预期结果、操作步骤有时候都可简写:直接以备注、说明、提醒点替代
注:用例粒度可粗可细,结合时间成本考虑,做到合理的划分即可。
6. 技巧
根据具体情况,可以适当做些备注(可以是一些业务逻辑、规则、需求、预期结果等),让人看得更明白
为了避免模块层级过多,可以不进行模块划分就不划分,当然也可以采用其它技巧,比如模块名称写成“大模块-子模块”的形式
第三页
Xmind使用方法
第四页
子模块
功能1
功能2
如果给出界面原型,则截图粘贴即可
页面元素及对应校验
一看用例名,就知道步骤及预期结果的,仅写用例名
如果预期结果是下一用例的条件,则按逻辑顺序接着写
步骤、预期结果分开写
第五页
测试用例执行
发现bug
回归并验证通过
测试通过
第六页
如何使用xmind编写测试用例 来自淘豆网www.taodocs.com转载请标明出处.