卖点测试法：

　　新需求必需强调功能特性的卖点，关键功能点，核心业务点（哪些必须实现），以user story的故事提出。并且要说明场景的特性，差异化优势，

　　必备条件：规划经理提交需求时明确客户可能的用户场景

　　备注：当前的需求经常是一句话列出了需求，必须细分

　　质疑测试法：

　　为什么是这样的客户场景？场景是否合理不是规划经理一个人的事，需要进行讨论。我们要敢于质疑场景的合理性，做出来的产品不能脱离客户，我感觉市场人员对需求可能会比测试人员更加清楚；研发体系的模块专家对设计更加清楚；市场人员会质疑，如果客户这样操作会怎么样；而模块专家会从模块实现的关联分析提出自己的质疑

　　必备条件：测试团队，模块专家和市场人员对规划经理的需求进行质疑，模块专家可以对这样的场景从设计上进行一定的质疑，这样设计有什么缺陷。4.2R1后期发现问题后才召集模块专家对规划经理提出质疑，取得了一定的效果，但我相信这个配合提前的话会更有效。

　　破坏测试法：

　　这个是基于风险测试策略的，一般我们实现功能会有一些业务节点，项目的转发功能业务大概是 A -->B -->C。考虑如果B挂了怎么处理？C挂了怎么办？（通过这样的质疑，发现了2个需求问题）其实这个也是质疑软件的实现，是讲我们的业务实现分解成一个个小的功能特性，考虑如果下个业务节点失败，程序会怎么处理。

　　必备条件：画出功能特性实现逻辑图，可以提前和开发一起代码走读（先粗略再细化）

　　买一送一测试法：

　　这个主要是考虑程序并发，如cgi同时下发，程序同时读取，结合AC可以想自动升级的，如果点一次去请求一次升级，那还得了，所以终实现是点一次升级后建立一个标志？。所以涉及到脚本，cgi，程序时可以考虑同时下发测试。

　　快递测试法：

　　用快递来比喻数据经过程序到达别的地方。其实现在我们更多的是关联的数据分析不到位。我们要对功能特性进行分解，还是结合4.2R1分析，转发注销信息，那么注销信息的数据来源是什么？城市热点的注销命令，网关强制注销，无流量超时注销，心跳超时注销。。。我的思路是我们的功能肯定是用户操作什么的功能（功能带着数据的流动），要对这个数据进行分析，还有哪些地方用到了这样的数据？（可以搜索版本project进行分析）。这个是数据的输入，输出同理。

　　必备条件：和开发共同确认功能特性，列出影响到的数据

　　上面的测试方法，在近做的项目用到了一部分，也有部分是后期测试发现了问题后用的方法保证的质量。1，2可以在测试前期用于发现需求或设计问题。