每次需求一出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表情

　　重复类：添加重复值、修改为重复值、删除重复值、修改为空值

　　要求类：个数、长度、精度、层次、深度、空值，以及其它不在范围内的情况

　　最后祝大家在产品道路上一去不复返。

作者：言水丫子 

来源：https://zhuanlan.zhihu.com/p/323694229