賣點測試法：
新需求必需強調功能特性的賣點，關鍵功能點，核心業務點(哪些必須實現)，以user story的故事提出。並且要說明場景的特性，差異化優勢，
必備條件：規劃經理提交需求時明確客戶可能的使用者場景
備註：當前的需求經常是一句話就列出了需求，必須細分
質疑測試法：
為什麼是這樣的客戶場景？場景是否合理不是規劃經理乙個人的事，需要進行討論。我們要敢於質疑場景的合理性，做出來的產品不能脫離客戶，我感覺市場人員對需求可能會比測試人員更加清楚；研發體系的模組專家對設計更加清楚；市場人員會質疑，如果客戶這樣操作會怎麼樣；而模組專家會從模組實現的關聯分析提出自己的質疑
必備條件：測試團隊，模組專家和市場人員對規劃經理的需求進行質疑，模組專家可以對這樣的場景從設計上進行一定的質疑，這樣設計有什麼缺陷。4.2r1後期發現問題後才召集模組專家對規劃經理提出質疑，取得了一定的效果，但我相信這個配合提前的話會更有效。
破壞測試法：
這個是基於風險測試策略的，一般我們實現功能會有一些業務節點，專案的**功能業務大概是 a -->b -->c。考慮如果b掛了怎麼處理？c掛了怎麼辦？(通過這樣的質疑，發現了2個需求問題)其實這個也是質疑軟體的實現，就是講我們的業務實現分解成乙個個小的功能特性，考慮如果下個業務節點失敗，程式會怎麼處理。
必備條件：畫出功能特性實現邏輯圖，可以提前和開發一起**走讀(先粗略再細化)
買一送一測試法：
這個主要是考慮程式併發，如cgi同時下發，程式同時讀取，結合ac可以想自動公升級的，如果點一次就去請求一次公升級，那還得了，所以最終實現是點一次公升級後建立乙個標誌。所以涉及到指令碼，cgi，程式時可以考慮同時下發測試。
快遞測試法：
用快遞來比喻資料經過程式到達別的地方。其實現在我們更多的就是關聯的資料分析不到位。我們要對功能特性進行分解，還是結合4.2r1分析，**登出資訊，那麼登出資訊的資料**是什麼？城市熱點的登出命令，閘道器強制登出，無流量超時登出，心跳超時登出。。。我的思路是我們的功能肯定是使用者操作什麼的功能(功能就帶著資料的流動)，要對這個資料進行分析，還有哪些地方用到了這樣的資料？(可以搜尋版本project進行分析)。這個是資料的輸入，輸出同理。
必備條件：和開發共同確認功能特性，列出影響到的資料
上面的測試方法，在最近做的專案用到了一部分，也有部分是後期測試發現了問題後用的方法保證的質量。1,2可以在測試前期用於發現需求或設計問題
探索性測試需求思路
賣點測試法 新需求必需強調功能特性的賣點，關鍵功能點，核心業務點 哪些必須實現 以user story的故事提出。並且要說明場景的特性，差異化優勢，必備條件 規劃經理提交需求時明確客戶可能的使用者場景 備註 當前的需求經常是一句話就列出了需求，必須細分 質疑測試法 為什麼是這樣的客戶場景？場景是否合...
探索性測試
每乙個好的缺陷背後，都可能藏著乙個更好的缺陷，在你確實了解缺陷的影響程度和破壞力之前永遠不要停止探索。探索性測試的目標 理解應用程式如何工作，他的介面看起來怎樣，實現了什麼功能 強迫軟體展示其全部能力 找到缺陷 探索性測試的方 賣點測試法 此方法鼓勵測試人員 銷售部門給客戶演示的demo，理解從銷售...
探索性測試
探索性測試概念 摘 探索性測試 et 是敏捷世界裡的一種重要測試方法，作為乙個研究性的工具，它是使用者故事測試和自動化回歸集的重要補充。它是一種經過深思熟慮的測試方式，沒有測試指令碼，可以使你的測試超出各種明顯已經測試過的場景。探索測試將學習，測試設計和測試執行整合在一起，形成一種測試方法。探索性測...