軟體測試用例對于測試進度的可控性建議——理論篇

從接觸軟體測試工作開始，相信所有人都希望減少軟體測試後漏測的問題（tester希望，開發經理希望，老闆希望），但事實是一直以來都沒有很好的真正解決産品漏測的問題以及如何減少功能組合爆炸的問題。過去幾年因為工作任務的緣故，我在曆經幾年自動化測試、系統測試和缺陷預防工作後，又回到測試的本源開始思考功能缺陷的測試應該如何做好？從2011年版本到2012年版本直到2013年終于優化完善出了自己的功能測試方法體系，沒想到居然在軟體測試行業從業近10年時才搞明白了10年前就開始的問題。過去的5年通過實踐補充了自己在缺陷預防領域的技能和認知、可測試性設計領域的技能和認知、産品可靠性測試（穩定性測試）領域的技能和認知，直到2年前才開始真正介入功能測試方法改進。最後才意識到原來我們不少漏測的問題，不是性能測試可以發現的，也不是穩定性測試可以發現的，更不是自動化測試能發現的，現有的功能測試用例及方法也發現不了－－多功能組合下和不同使用者操作序列下才發生的bug。怎麼辦？以及如何解決組合爆炸的問題－－我們一直都在回避。如何讓我們投入測試時間最多的功能測試用例該多的地方多，該少的地方少？搞了半天，原來測試領域最基本的工作都沒做好，然後就開始瘋狂追蹤上層建築，或是簡單實行拿來主義拿來一些工具或方法，雖然所拿來的這些工具或方法對局部的确是有優化作用，但你知道自己的全局全貌在哪裡嗎？知道全部漏測的測試根因在哪裡嗎（而不是産品技術根因）， 如果不知道則容易陷入盲目樂觀與更加保守的狀态。聽說有個工具或方法能發現很多bug－－于是開始盲目樂觀引入，希望能從此解決完所有測試漏測的問題，結果确實能發現一部分問題但是還是有不少漏測，結果－－開始更加保守，對新工具和新方法不再相信和信任，從此對漏測問題放在一邊交給其他人去關心。那我就是那位被迫要去關心和解決漏測問題的非主流測試工程師，幸運的是經過過去幾年的思考與學習，如今随着個人穩定性測試模型和功能測試模型方法體系的完善，終于讓我有信心有知識去應對任何軟體的漏測問題， 可以階段性的結束對漏測問題領域的專注思考，投入更多精力于其他測試技術和方法體系了， 故寫此文階段性紀念下。下面分享一部分如何減少功能缺陷漏測的幹貨吧，與各位共勉：

　　功能缺陷的測試方法流程

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

　　目的：提取功能測試對象

　　準備功能測試資料

　　減少因為功能測試對象遺漏的漏測

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

　　目的：檢查功能是否已基本正确實作

　　測試方法：

　　● 基于生命期：對象建立 -使用- 銷毀 的驗證

　　● 資料測試方法：靜态資料測試方法和動态資料測試方法 （邊界值和資料等價類、7因子資料類型）

　　減少功能的基本邏輯錯誤漏測和資料處理錯誤的漏測

　　第三步：單功能内測試 —功能測試階段

　　目的：發現功能是否存在分支情況、異常情況處理不足的缺陷

　　● 功能内子功能的場景插入法

　　● 重複法設計

　　● 反叛法設計

　　● 取消法設計

　　● 測一送一法設計

　　● 場景删除法設計

　　減少功能内代碼的漏測

第四步：多功能間組合測試 —系統測試階段的使用者場景測試

　　目的：發現功能間配合工作時存在的缺陷

　　測試方法

　　● 基于使用者場景的測試 （scenario test）

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

　　為什麼需要使用者場景的測試模型？

　　補充多個功能組合的測試用例解決傳統正交組合測試後3個及以上功能組合缺陷的漏測

　　通過常見使用者操作序列的場景設計解決數學式窮盡組合爆炸的問題減少組合測試時間和成本，獲得最佳投入産出比的組合測試

　　使用者場景測試的測試步驟是不同角色使用者最常用的基本操作序列

　　使用者場景的探索測試是不同角色使用者非常用的操作序列

　　使用者場景的探索測試

　　在使用者場景測試用例執行結束後 ， 再用專項時間進行多功能組合的探索測試，補充使用者場景測試用例之外的使用者操作序列，提高使用者操作序列的覆寫面。因為使用者最常用的操作序列已在使用者場景測試用例中覆寫，但又不能對非正常的操作序列不進行測試， 是以将非正常的操作序列的測試與測試成本進行一個平衡，通過專項的探索測試時間來補充這部分的測試。

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

　　收藏家法

　　同時開啟多個功能，同時工作。

　　技術根因

　　同時多個功能互動容易出現資源競争處理的錯誤。

　　地标法

　　改變一系列規定順序操作的先後順序。

　　在實際場景中使用者因為對操作不熟悉難免會操作的步驟不是标準的步驟順序，而程式實作時對于這些改變了操作順序的操作步驟缺乏容錯處理則會出現程式錯誤。

　　混票法

　　把最不常用的功能與常用功能進行組合

　　在功能測試階段由于時間及優先級限制，測試人員習慣把常用功能進行組合測試，時間一久就容易忘掉不常用功能與常用功能的組合，而使用者的使用習慣中也一定會出現不常用功能與常用功能一起組合的場景