從接觸軟件測試工作開始，相信所有人都希望減少軟件測試后漏測的問題（tester希望，開發經理希望，老板希望），但事實是一直以來都沒有很好的真正解決產品漏測的問題以及如何減少功能組合爆炸的問題。過去幾年因為工作任務的緣故，我在歷經幾年自動化測試、系統測試和缺陷預防工作后，又回到測試的本源開始思考功能缺陷的測試應該如何做好？從2011年版本到2012年版本直到2013年終于優化完善出了自己的功能測試方法體系，沒想到居然在軟件測試行業從業近10年時才搞明白了10年前就開始的問題。過去的5年通過實踐補充了自己在缺陷預防領域的技能和認知、可測試性設計領域的技能和認知、產品可靠性測試（穩定性測試）領域的技能和認知，直到2年前才開始真正介入功能測試方法改進。最后才意識到原來我們不少漏測的問題，不是性能測試可以發現的，也不是穩定性測試可以發現的，更不是自動化測試能發現的，現有的功能測試用例及方法也發現不了－－多功能組合下和不同用戶操作序列下才發生的bug。怎么辦？以及如何解決組合爆炸的問題－－我們一直都在回避。如何讓我們投入測試時間最多的功能測試用例該多的地方多，該少的地方少？搞了半天，原來測試領域最基本的工作都沒做好，然后就開始瘋狂追蹤上層建筑，或是簡單實行拿來主義拿來一些工具或方法，雖然所拿來的這些工具或方法對局部的確是有優化作用，但你知道自己的全局全貌在哪里嗎？知道全部漏測的測試根因在哪里嗎（而不是產品技術根因）， 如果不知道則容易陷入盲目樂觀與更加保守的狀態。聽說有個工具或方法能發現很多bug－－于是開始盲目樂觀引入，希望能從此解決完所有測試漏測的問題，結果確實能發現一部分問題但是還是有不少漏測，結果－－開始更加保守，對新工具和新方法不再相信和信任，從此對漏測問題放在一邊交給其他人去關心。那我就是那位被迫要去關心和解決漏測問題的非主流測試工程師，幸運的是經過過去幾年的思考與學習，如今隨著個人穩定性測試模型和功能測試模型方法體系的完善，終于讓我有信心有知識去應對任何軟件的漏測問題， 可以階段性的結束對漏測問題領域的專注思考，投入更多精力于其他測試技術和方法體系了， 故寫此文階段性紀念下。下面分享一部分如何減少功能缺陷漏測的干貨吧，與各位共勉：
功能缺陷的測試方法流程
第一步：功能測試分析 —功能測試階段
目的：提取功能測試對象
準備功能測試數據
減少因為功能測試對象遺漏的漏測
第二步：功能驗證—功能測試階段
目的：檢查功能是否已基本正確實現
測試方法：
● 基于生命期：對象創建 -使用- 銷毀 的驗證
● 數據測試方法：靜態數據測試方法和動態數據測試方法 （邊界值和數據等價類、7因子數據類型）
減少功能的基本邏輯錯誤漏測和數據處理錯誤的漏測
第三步：單功能內測試 —功能測試階段
目的：發現功能是否存在分支情況、異常情況處理不足的缺陷
測試方法：
● 功能內子功能的場景插入法
● 重復法設計
● 反叛法設計
● 取消法設計
● 測一送一法設計
● 場景刪除法設計
減少功能內代碼的漏測
第四步：多功能間組合測試 —系統測試階段的用戶場景測試
目的：發現功能間配合工作時存在的缺陷
測試方法
● 基于用戶場景的測試 （Scenario Test）
減少多功能間組合錯誤的漏測
為什么需要用戶場景的測試模型？
補充多個功能組合的測試用例解決傳統正交組合測試后3個及以上功能組合缺陷的漏測
通過常見用戶操作序列的場景設計解決數學式窮盡組合爆炸的問題減少組合測試時間和成本，獲得最佳投入產出比的組合測試
用戶場景測試的測試步驟是不同角色用戶最常用的基本操作序列
用戶場景的探索測試是不同角色用戶非常用的操作序列
用戶場景的探索測試
在用戶場景測試用例執行結束后 ， 再用專項時間進行多功能組合的探索測試，補充用戶場景測試用例之外的用戶操作序列，提高用戶操作序列的覆蓋面。因為用戶最常用的操作序列已在用戶場景測試用例中覆蓋，但又不能對非常規的操作序列不進行測試， 因此將非常規的操作序列的測試與測試成本進行一個平衡，通過專項的探索測試時間來補充這部分的測試。
在補充用戶操作序列的探索測試中可用的探索測試方法有：
收藏家法
同時開啟多個功能，同時工作。
技術根因
同時多個功能交互容易出現資源競爭處理的錯誤。
地標法
改變一系列規定順序操作的先后順序。
技術根因
在實際場景中用戶因為對操作不熟悉難免會操作的步驟不是標準的步驟順序，而程序實現時對于這些改變了操作順序的操作步驟缺乏容錯處理則會出現程序錯誤。
混票法
把最不常用的功能與常用功能進行組合
技術根因
在功能測試階段由于時間及優先級限制，測試人員習慣把常用功能進行組合測試，時間一久就容易忘掉不常用功能與常用功能的組合，而用戶的使用習慣中也一定會出現不常用功能與常用功能一起組合的場景