如何编写产品的黑盒测试用例

发表于:2020-12-07 10:03  作者:言水丫子   来源:知乎

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 测试用例 黑盒测试

  每次需求一出bug,不管最后追责杀到谁的头上,前边一定是产品刚在第一线。为了少出事,就在测试阶段多干活。
  建议不管有多忙,产品也要在需求上线前验一遍。这样至少有两个好处:
  ·少背锅。需求上线前,什么事情都比较好解决,比上线后扯皮强。
  ·多露脸。部门那么大,不一定都认识,行走江湖靠朋友,各部门混个脸熟才是正道。
  在不看触代码和接口,仅看功能逻辑的测试,就是黑盒测试
  那末,从产品的角度,黑盒测试该如何编写用例,才显得比较专业呢?
  STEP1 改造测试的测试用例
  找测试要一份测试用例文档,有些公司还会要求开测试用例评审会。
  假如要不到,网上也能百度搜下来一份,然后删掉一些测试部门统一要求方便管理,但是产品不需要的内容,比如案例作者、案例工号之类的内容。我们再整合一下作为产品需要哪些信息,最终就能整理出一份用例框架。
  STEP2 找出需求主流程/拆分条件分支
  产品要梳理出系统主流程那简直是分分钟能搞定的事情。假如是临时接手的需求,也可以参考业务流程图来找出主流程。
  找出主流程后,开始将主流程拆分,每个点击跳转、每个条件判断,都要作为一条用例写下。
  并拆分出分支,例如判断,内容,可以先测否定判断,再测肯定判断等等。
  STEP3 找出需求边界
  找出需求边界,即测试需求要求的边界内容。比如此行内容限定18位数值,那就可以测试四类场景:
  ·未填写
  ·填写少于18位、
  ·填写大于18位
  ·填写符号
  测试需求边界,查看极限状态下逻辑能否正常运行,页面展示正常程度等等,可以有效分担测试的工作量,同时也能探查到测试容易忽略的bug。
  STEP4 找出异常测试
  异常类型测试,通常来说是白盒较为方便,更改参数,模拟异常场景更加简单;但黑盒也可以完成部分异常场景。比如:
  A:余额不足、断网/断电/死机;
  B:产品状态变化引起的异常;
  C:操作中应该选的选项没有选的场景等等。
  上面列举的AC实现都非常容易, B需要稍加举例,假如用户正在订购已上架的α商品,在加入购物车前下架此商品和在加入购物车后下架此商品会不会有表述不同。
  这四步完成,产品的黑盒测试用例就完成了。等到需求转测时,拿出来无脑按步骤测试吧,装装13的同时,也能保证自己尽最大努力推进需求,少背锅。剩下那些莫名其妙的BUG,那都开发跟测试的....
  最后再列举一些常用的测试内容。
  特殊类:特殊数字(小数点后10位数的正数、负数、0)、特殊空值(NULL,NONE)、特殊字符(True\Flase\and\or)、特殊符号(全角、半角)、中文(繁体、简体)、emoji表情
  重复类:添加重复值、修改为重复值、删除重复值、修改为空值
  要求类:个数、长度、精度、层次、深度、空值,以及其它不在范围内的情况
  最后祝大家在产品道路上一去不复返。

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(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官方微博

扫一扫 测试知识全知道