賣點測試法：
新需求必需強調功能特性的賣點，關鍵功能點，核心業務點（哪些必須實現），以user story的故事提出。并且要說明場景的特性，差異化優勢，
必備條件：規劃經理提交需求時明確客戶可能的用戶場景
備注：當前的需求經常是一句話就列出了需求，必須細分
質疑測試法：
為什么是這樣的客戶場景？場景是否合理不是規劃經理一個人的事，需要進行討論。我們要敢于質疑場景的合理性，做出來的產品不能脫離客戶，我感覺市場人員對需求可能會比測試人員更加清楚；研發體系的模塊專家對設計更加清楚；市場人員會質疑，如果客戶這樣操作會怎么樣；而模塊專家會從模塊實現的關聯分析提出自己的質疑
必備條件：測試團隊，模塊專家和市場人員對規劃經理的需求進行質疑，模塊專家可以對這樣的場景從設計上進行一定的質疑，這樣設計有什么缺陷。4.2R1后期發現問題后才召集模塊專家對規劃經理提出質疑，取得了一定的效果，但我相信這個配合提前的話會更有效。
破壞測試法：
這個是基于風險測試策略的，一般我們實現功能會有一些業務節點，項目的轉發功能業務大概是 A -->B -->C。考慮如果B掛了怎么處理？C掛了怎么辦？（通過這樣的質疑，發現了2個需求問題）其實這個也是質疑軟件的實現，就是講我們的業務實現分解成一個個小的功能特性，考慮如果下個業務節點失敗，程序會怎么處理。
必備條件：畫出功能特性實現邏輯圖，可以提前和開發一起代碼走讀（先粗略再細化）
買一送一測試法：
這個主要是考慮程序并發，如cgi同時下發，程序同時讀取，結合AC可以想自動升級的，如果點一次就去請求一次升級，那還得了，所以最終實現是點一次升級后建立一個標志？。所以涉及到腳本，cgi，程序時可以考慮同時下發測試。
快遞測試法：
用快遞來比喻數據經過程序到達別的地方。其實現在我們更多的就是關聯的數據分析不到位。我們要對功能特性進行分解，還是結合4.2R1分析，轉發注銷信息，那么注銷信息的數據來源是什么？城市熱點的注銷命令，網關強制注銷，無流量超時注銷，心跳超時注銷。。。我的思路是我們的功能肯定是用戶操作什么的功能（功能就帶著數據的流動），要對這個數據進行分析，還有哪些地方用到了這樣的數據？（可以搜索版本project進行分析）。這個是數據的輸入，輸出同理。
必備條件：和開發共同確認功能特性，列出影響到的數據
上面的測試方法，在最近做的項目用到了一部分，也有部分是后期測試發現了問題后用的方法保證的質量。1，2可以在測試前期用于發現需求或設計問題。