如何写出高质量的测试用例呢?

发表于:2020-9-28 09:35  作者:NET.Dzreal   来源:知乎

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 用例设计

  第一步、明确测试范围
  有些需求是多个部门一起合作的,可能会有多个测试和你一起分工合作。
  你需要明确自己主要负责测试哪些地方,细化到功能模块。
  这个时候,你应该明确两点:
  1.你测试的模块到底依赖哪些其他模块
  2.有哪些模块依赖你所负责测试的模块
  设计测试用例的时候,把重点放在设计你自己负责的测试范围上;
  对于有依赖的模块,也需要考虑降级和容错,也就是你要考虑,你负责的模块出问题了,对人家造成什么影响;
  或者,人家负责的模块出问题了,对你所负责的模块有什么影响。
  明确测试范围的2个好方法:
  1.需求评审会一般产品会按功能模块去划分,分别评审,你需要和与你对接的产品和开发步调一致。
  2.测前沟通,找开发和产品去做测试前的沟通,必要时,甚至要找关联的测试人员去做一次沟通,明确测试范围。
  第二步、熟悉需求文档
  需求文档至少要看三遍!
  在你熟悉需求文档的时候,也相当于已经进入测试了,像一些公司美其名曰:文档测试。
  产品经理写需求没想到的,你想到了,都可以大胆的提出来,要有质疑的精神。
  另外这里还有一个小建议:尽量让产品经理把产品的流程图画上,流程图可以反映出数据流向是怎样的,这可比文字更加直观。
  这样你会对整个需求文档有更深的理解。
  第三步、熟悉开发文档
  开发的系统设计文档、接口设计文档、数据库表结构,如果有的话,最好都看一遍。
  第四步、设计和编写测试用例
  现在大部分测试工程师手工测试都喜欢用Excel或者Xmind来编写测试用例。
  ·Excel 比较适合用例较少、操作步骤简单、可能性有限、结果预期比较明确的功能。
  ·Xmind 比较适合用例较多、功能相对复杂、结果预期比较多样的功能。
  以下分别举两个使用场景:
  (1)假如说测app的话,个人感觉用Xmind可能会更合适
  用Excel的话,由于功能比较繁琐,可能用例条数会很庞大,一方面测试起来,看太多表格,容易头晕。另一方面维护起来也比较麻烦。
  而Xmind可以只是把功能点写上,本身结构化的设计思维会让测试思路比较清晰,测试用例维护起来比较方便。
  (2)对于上线后的回归测试验证点(CheckList),我们可以用Excel去表达,主要是针对主流程主功能的正向操作进行验证,逐条操作也防止漏测。
  但其实用哪种软件编辑测试用例,都是看个人的使用习惯,关键是自己能看懂,别人也可以看懂就可以了。
  设计测试用例时的,需要结合需求文档,把测试点罗列清楚,尽量用简洁的语句表述,非常忌讳写出过于啰嗦的用例。
  另外,设计测试用例的几条思路我也简单介绍一下:
  1.按模块把功能点罗列全,切记不要照抄需求文档,这样写不写有什么区别?
  2.软件测试的基本测试方法要有效利用上,像边界值法、等价划分类、场景法等等,都是特别实用测试方法。
  3.不要在细枝末节上纠结太多,根据二八法则,80%的bug都集中在主流程里面,要确保主功能主流程没问题。
  第五、用例评审
  测试用例设计完,一定要和产品研发一起评审测试用例,漏掉的测试点要及时补充。

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理 

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海信义律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2021, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道