從2011年版本到2012年版本直到2013年終于優(yōu)化完善出了自己的功能測試方法體系，沒想到居然在軟件測試行業(yè)從業(yè)近10年時才搞明白了10年前就開始的問題。過去的5年通過實踐補充了自己在缺陷預(yù)防領(lǐng)域的技能和認(rèn)知、可測試性設(shè)計領(lǐng)域的技能和認(rèn)知、產(chǎn)品可靠性測試（穩(wěn)定性測試）領(lǐng)域的技能和認(rèn)知，直到2年前才開始真正介入功能測試方法改進。最后才意識到原來我們不少漏測的問題，不是性能測試可以發(fā)現(xiàn)的，也不是穩(wěn)定性測試可以發(fā)現(xiàn)的，更不是自動化測試能發(fā)現(xiàn)的，現(xiàn)有的功能測試用例及方法也發(fā)現(xiàn)不了－－多功能組合下和不同用戶操作序列下才發(fā)生的bug。怎么辦？以及如何解決組合爆炸的問題－－我們一直都在回避。

如何讓我們投入測試時間最多的功能測試用例該多的地方多，該少的地方少？搞了半天，原來測試領(lǐng)域最基本的工作都沒做好，然后就開始瘋狂追蹤上層建筑，或是簡單實行拿來主義拿來一些工具或方法，雖然所拿來的這些工具或方法對局部的確是有優(yōu)化作用，但你知道自己的全局全貌在哪里嗎？知道全部漏測的測試根因在哪里嗎（而不是產(chǎn)品技術(shù)根因）， 如果不知道則容易陷入盲目樂觀與更加保守的狀態(tài)。聽說有個工具或方法能發(fā)現(xiàn)很多bug－－于是開始盲目樂觀引入，希望能從此解決完所有測試漏測的問題，結(jié)果確實能發(fā)現(xiàn)一部分問題但是還是有不少漏測，結(jié)果－－開始更加保守，對新工具和新方法不再相信和信任，從此對漏測問題放在一邊交給其他人去關(guān)心。那我就是那位被迫要去關(guān)心和解決漏測問題的非主流測試工程師，幸運的是經(jīng)過過去幾年的思考與學(xué)習(xí)，如今隨著個人穩(wěn)定性測試模型和功能測試模型方法體系的完善，終于讓我有信心有知識去應(yīng)對任何軟件的漏測問題， 可以階段性的結(jié)束對漏測問題領(lǐng)域的專注思考，投入更多精力于其他測試技術(shù)和方法體系了， 故寫此文階段性紀(jì)念下。下面分享一部分如何減少功能缺陷漏測的干貨吧，與各位共勉：

功能缺陷的測試方法流程

第一步： 功能測試分析 —功能測試階段

目的：提取功能測試對象，準(zhǔn)備功能測試數(shù)據(jù)， 減少因為功能測試對象遺漏的漏測。

第二步：功能驗證—功能測試階段

目的：檢查功能是否已基本正確實現(xiàn)  。

測試方法：

• 基于生命期: 對象創(chuàng)建 -使用- 銷毀 的驗證
• 數(shù)據(jù)測試方法: 靜態(tài)數(shù)據(jù)測試方法和動態(tài)數(shù)據(jù)測試方法 (邊界值和數(shù)據(jù)等價類、7因子數(shù)據(jù)類型)

減少功能的基本邏輯錯誤漏測和數(shù)據(jù)處理錯誤的漏測

第三步：單功能內(nèi)測試 —功能測試階段

目的：發(fā)現(xiàn)功能是否存在分支情況、異常情況處理不足的缺陷。

測試方法 ：

• 功能內(nèi)子功能的場景插入法
• 重復(fù)法設(shè)計
• 反叛法設(shè)計
• 取消法設(shè)計
• 測一送一法設(shè)計
• 場景刪除法設(shè)計

減少功能內(nèi)代碼的漏測

第四步：多功能間組合測試 —系統(tǒng)測試階段的用戶場景測試

目的：發(fā)現(xiàn)功能間配合工作時存在的缺陷

測試方法：

• 基于用戶場景的測試 (Scenario Test)

減少多功能間組合錯誤的漏測

為什么需要用戶場景的測試模型?

• 補充多個功能組合的測試用例解決傳統(tǒng)正交組合測試后3個及以上功能組合缺陷的漏測。
• 通過常見用戶操作序列的場景設(shè)計解決數(shù)學(xué)式窮盡組合爆炸的問題減少組合測試時間和成本，獲得最佳投入產(chǎn)出比的組合測試。
• 用戶場景測試的測試步驟：是不同角色用戶最常用的基本操作序列。
• 用戶場景的探索測試：是不同角色用戶非常用的操作序列。

用戶場景的探索測試

在用戶場景測試用例執(zhí)行結(jié)束后 , 再用專項時間進行多功能組合的探索測試，補充用戶場景測試用例之外的用戶操作序列，提高用戶操作序列的覆蓋面。因為用戶最常用的操作序列已在用戶場景測試用例中覆蓋，但又不能對非常規(guī)的操作序列不進行測試，   因此將非常規(guī)的操作序列的測試與測試成本進行一個平衡，通過專項的探索測試時間來補充這部分的測試。

在補充用戶操作序列的探索測試中可用的探索測試方法有：

• 收藏家法：同時開啟多個功能，同時工作。
  技術(shù)根因：同時多個功能交互容易出現(xiàn)資源競爭處理的錯誤。
• 地標(biāo)法： 改變一系列規(guī)定順序操作的先后順序。（ A->B->C->D->E）改為 (A->D->C->B->E)。
  技術(shù)根因：在實際場景中用戶因為對操作不熟悉難免會操作的步驟不是標(biāo)準(zhǔn)的步驟順序，而程序?qū)崿F(xiàn)時對于這些改變了操作順序的操作步驟缺乏容錯處理則會出現(xiàn)程序錯誤。
• 混票法：把最不常用的功能與常用功能進行組合。
  技術(shù)根因：在功能測試階段由于時間及優(yōu)先級限制，測試人員習(xí)慣把常用功能進行組合測試，時間一久就容易忘掉不常用功能與常用功能的組合，而用戶的使用習(xí)慣中也一定會出現(xiàn)不常用功能與常用功能一起組合的場景

轉(zhuǎn)載自：