探索性測試需求思路

　　新需求必需強調功能特性的賣點，關鍵功能點，核心業務點（哪些必須實作），以user story的故事提出。并且要說明場景的特性，差異化優勢，

　　必備條件：規劃經理送出需求時明确客戶可能的使用者場景

　　備注：目前的需求經常是一句話就列出了需求，必須細分

　　質疑測試法：

　　為什麼是這樣的客戶場景？場景是否合理不是規劃經理一個人的事，需要進行讨論。我們要敢于質疑場景的合理性，做出來的産品不能脫離客戶，我感覺市場人員對需求可能會比測試人員更加清楚；研發體系的子產品專家對設計更加清楚；市場人員會質疑，如果客戶這樣操作會怎麼樣；而子產品專家會從子產品實作的關聯分析提出自己的質疑

　　必備條件：測試團隊，子產品專家和市場人員對規劃經理的需求進行質疑，子產品專家可以對這樣的場景從設計上進行一定的質疑，這樣設計有什麼缺陷。4.2r1後期發現問題後才召集子產品專家對規劃經理提出質疑，取得了一定的效果，但我相信這個配合提前的話會更有效。

　　破壞測試法：

　　這個是基于風險測試政策的，一般我們實作功能會有一些業務節點，項目的轉發功能業務大概是 a -->b -->c。考慮如果b挂了怎麼處理？c挂了怎麼辦？（通過這樣的質疑，發現了2個需求問題）其實這個也是質疑軟體的實作，就是講我們的業務實作分解成一個個小的功能特性，考慮如果下個業務節點失敗，程式會怎麼處理。

　　必備條件：畫出功能特性實作邏輯圖，可以提前和開發一起代碼走讀（先粗略再細化）

　　買一送一測試法：

　　這個主要是考慮程式并發，如cgi同時下發，程式同時讀取，結合ac可以想自動更新的，如果點一次就去請求一次更新，那還得了，是以最終實作是點一次更新後建立一個标志？。是以涉及到腳本，cgi，程式時可以考慮同時下發測試。

　　快遞測試法：

　　用快遞來比喻資料經過程式到達别的地方。其實作在我們更多的就是關聯的資料分析不到位。我們要對功能特性進行分解，還是結合4.2r1分析，轉發登出資訊，那麼登出資訊的資料來源是什麼？城市熱點的登出指令，網關強制登出，無流量逾時登出，心跳逾時登出。。。我的思路是我們的功能肯定是使用者操作什麼的功能（功能就帶着資料的流動），要對這個資料進行分析，還有哪些地方用到了這樣的資料？（可以搜尋版本project進行分析）。這個是資料的輸入，輸出同理。

　　必備條件：和開發共同确認功能特性，列出影響到的資料

　　上面的測試方法，在最近做的項目用到了一部分，也有部分是後期測試發現了問題後用的方法保證的品質。1，2可以在測試前期用于發現需求或設計問題。

====================================分割線================================

最新内容請見作者的github頁：http://qaseven.github.io/