功能缺陷的測試方法流程
第一步：功能測試分析—功能測試階段
目的：
提取功能測試物件
準備功能測試資料
減少因為功能測試物件遺漏的漏測
第二步：功能驗證—功能測試階段
目的：檢查功能是否已基本正確實現
測試方法
:基於生命期
:物件建立-使用
-銷毀的驗證資料測試方法
:靜態資料測試方法和動態資料測試方法
(邊界值和資料等價類、7因子資料型別
)減少功能的基本邏輯錯誤漏測和資料處理錯誤的漏測
第三步：單功能內測試—功能測試階段
目的：發現功能是否存在分支情況、異常情況處理不足的缺陷
測試方法
:
功能內子功能的場景插入法
重複法設計
反叛法設計
取消法設計
測一送一法設計
場景刪除法設計
減少功能內**的漏測
第四步：多功能間組合測試—系統測試階段的使用者場景測試
目的：發現功能間配合工作時存在的缺陷
測試方法
基於使用者場景的測試
(scenariotest)
減少多功能間組合錯誤的漏測
為什麼需要使用者場景的測試模型?
補充多個功能組合的測試用例解決傳統正交組合測試後3個及以上功能組合缺陷的漏測
通過常見使用者操作序列的場景設計解決數學式窮盡組合**的問題減少組合測試時間和成本，獲得最佳投入產出比的組合測試
使用者場景測試的測試步驟 是 不同角色使用者最常用的基本操作序列
使用者場景的探索測試 是 不同角色使用者非常用的操作序列
使用者場景的探索測試
在使用者場景測試用例執行結束後
,再用專項時間進行多功能組合的探索測試
，補充使用者場景測試用例之外的使用者操作序列，提高使用者操作序列的覆蓋面。因為使用者最常用的操作序列已在使用者場景測試用例中覆蓋，但又不能對非常規的操作序列不進行測試，
因此將非常規的操作序列的測試與測試成本進行乙個平衡，通過專項的探索測試時間來補充這部分的測試。
在補充使用者操作序列的探索測試中可用的探索測試方法有：
收藏家法
同時開啟多個功能，同時工作。
技術根因
同時多個功能互動容易出現資源競爭處理的錯誤。
地標法改變一系列規定順序操作的先後順序。（
a->b->c->d->e
）改為(a->d->c->b->e)
技術根因
在實際場景中使用者因為對操作不熟悉難免會操作的步驟不是標準的步驟順序，而程式
實現時對於這些改變了操作順序的操作步驟缺乏容錯處理則會出現程式錯誤。
混票法把最不常用的功能與常用功能進行組合
技術根因
在功能測試階段由於時間及優先順序限制，測試人員習慣把常用功能進行組合測試，時間一久就容易忘掉不常用功能與常用功能的組合，而使用者的使用習慣中也一定會出現
不常用功能與常用功能一起組合的場景
如何盡可能的避免漏測
在總結線上問題的時候，我們發現大部分的線上問題是由於功能漏測所導致的。原本應該測試的流程沒有測到，或者是根本沒有考慮到一些情況，這些都會產生漏測。在大部分的產品中，漏測是難以避免的，只要不出大問題，漏測的危害會被人為的粉飾和縮小，但是在某些跟貨幣或貨幣等價物打交道的行業，漏測往往意味著經濟損失，一次...
BUG漏測的原因總結，以及如何處理
一 漏測的概率 漏測，是指軟體產品的缺陷沒有在測試過程中被發現，而是在版本發布之後，使用者在使用過程中發現存在的缺陷。二 預防漏測的意義 我們都知道，缺陷越早被發現，發現和解決缺陷所花的成本就越小，如果缺陷是在測試中發現的，那麼所花的成本將小得多。測試 是保證軟體質量的最重要手段之一，因此，進行漏測...
移動app測試中出現bug漏測的原因分析
bug 其實是任何產品都無法避免的乙個問題，不是所有的 bug 都能被發現，包括資深測試，或多或少的會出現線上缺陷，誰也不能把軟體所有的功能操作 運用場景想周全。雖說不能做到完全零缺陷，但是每次發布的產品，我們需要追求缺陷越來越少，產品投訴越來越少。為什麼會出現缺陷漏測，主要有以下幾點 需求評審階段...