“Ad-Hoc” 原意是指 “特定的，一次性的”；就是為了某一個特定目的進行的測試，就這一次，以后一般也不會重復測試或是嘗試性測試某種情況，來檢測是否有問題

Why need AD-HOC Testing?

測試用例甚至是PRD（需求文檔）有遺漏的地方
某些功能需要進行類似排列組合的方法進行測試，如果都寫成Case會使測試用例的冗余，并影響測試時間
測試人員的疏忽，導致與問題擦肩而過。盡量減少和避免疏忽是我們必須努力去做到的，但是也要承認這個問題也是難免的。

Who do AD-HOC Testing?

System test engineers or other team member；每個測試工程師自然不能放過用ad-hoc testing補足系統測試可能的遺漏，在被測軟件得到一定的穩定度之后還可以考慮請其他的組員幫忙檢驗，從而避免自身可能存在的思維瓶頸。

What is AD-HOC Testing?

軟件測試中的ad-hoc “Ad-Hoc” 原意是指 “特定的，一次性的”，這里專指“隨機的，自由的”測試。

軟件測試中的ad-hoc “Ad-Hoc” 原意是指 “特定的，一次性的”，這里專指“隨機的，自由的”測試。
在軟件測試中除了根據測試樣例和測試說明書進行測試外，還需要進行隨機測試(Ad-hoc testing)，主要是根據測試者的經驗對軟件進行功能和性能抽查。隨機測試是根據測試說明書執行樣例測試的重要補充手段，是保證測試覆蓋完整性的有效 方式和過程。 隨機測試主要是對被測軟件的一些重要功能進行復測，也包括測試那些當前的測試樣例(TestCase)沒有覆蓋到的部分。另外，對于軟件更新和新增加的功 能要重點測試。重點對一些特殊點情況點、特殊的使用環境、并發性、進行檢查。尤其對以前測試發現的重大Bug，進行再次測試，可以結合回歸測試 (Regression testing)一起進行。

理論上，每一個被測軟件版本都需要執行隨機測試，尤其對于最后的將要發布的版本更要重視隨機測試。隨機測試最好由具有豐富測試經驗的熟悉被測軟件的測試人員進行測試。對于被測試的軟件越熟悉，執行隨機測試越容易。只有不斷的積累測試經驗，包括具體 的測試執行和對缺陷跟蹤記錄的分析，不斷總結，才能提高。

詞匯Ad-Hoc是一個拉丁詞匯，在拉丁語中的意思是“即興，臨時（improvised, impromptu）”
AD-HOC(抑或者叫做Free Style Test)是我們系統測試中的一個測試階段，是對ST和Regression test的補充，也是對我們ST Case的補漏和完善。AD-HOC沒有相應TC，是測試工程師憑借經驗和對產品的熟悉程度完成的測試，目的是找出系統測試和回歸測試覆蓋范圍以外的問題。（類似于ET，如何讓這種測試方法化，將人為因素減小到最小程度，并適用于所有功能。但這些方法是建立在對產品設計足夠熟悉的條件下進行的）

When do AD-HOC Testing?

存在于進入ST到版本release前的整個時間段。一般出現在ST第一輪以后，對ST和regression test補充測試（如果有資源，也可以和ST和RGT同時進行）；也可根據實際需要安排時間點，功能，次數等。

注：ST后的ad hoc test一般都以測試用例的不足處為考量點出發，另外就是認為軟件比較不穩定的功能展開。另外RGT時候的ad hoc test一般是以改動的功能點出發特別注重，修改的方案是不是會導致其他的side effect。

Where to AD-HOC Testing?

Not only in office, but in anywhere and anytime!――除了在辦公室里完成的AD HOC，其實下班后的User Trail（Free Trail）也是很重要的一部分。作為基于網絡的服務的應用，我們其實一般系統測試很難去覆蓋的一個問題就是動態測試，主要針對實際網絡中的切換，斷網恢復等。

How to AD-HOC Testing?

制定并執行AD-HOC CP（ad-hoc Test check Point）

在寫Case時
a.遇到需要排列組合的情況時，將組合和主要排列寫在TC中，其他排列情況則轉換成AD HO（特別的可以使用熱推中的smart）。
b.列出需要做多重Interruption和Interaction的點.
c.列出需要做重復操作的點（小于5次），比如：比如在音樂播放器下載音樂時提示空間滿，無視提示重復執行一些操作。
d.針對不同運營商的區別點，一般的兼容性測試，我們只跑一次網絡兼容性測試，為了避免后續一些bug修復引起side effect，可以實時的切換不同的手機簡單執行ad hoc，確保在各個運營商下是可用的。
e.一輪功能測試已經結束后Update的TC

在bug regression test時
a.記錄Design Change較大的小Function執行AD HOC，比如：比如在音樂盒上功能測試第一輪后增加了專輯隨機播放功能。
b.將沒有時間做Side Effect驗證而有必要做的bug進行記錄并轉換成AD HOC（一些bug在修復時可能引入的resolution比較復雜，在驗證bug的之后一般的需要查看有無side effect，但是如果遇到時間不足導致的執行沖突，應該列出該問題后續補充以Ad hoc test）。
注：在時間允許的前提下，對每個被驗證bug進行Side Effect驗證。因為這時候做比在AD HOC和RGT做更有針對性，發現問題也更早。

在AD-HOC前
Owner根據功能目前的狀態（過去的測試階段的執行情況、bug狀態、Design Change的情況等）列出所需的AD-HOC，比如：PM UE等修改了一些處理流程（上層UI可能沒有太大變化）。
TC和AD-HOC在多重Interruption和Interaction中的劃分規則
a. 2重及2重以下Interrupt寫在TC中，2重以上則列入AD-HOC
b. 3重以下包括3重Interaction寫在TC中，3重以上則列入AD-HOC

AD-HOC的測試方法
邊界值法，當處于邊界值時繼續進行操作，或是從其他的相關功能處嘗試同樣的操作。
采用更多Device(其他Brand手機，BT設備，FMR設備，SIM卡，Operator等)進行IOT，注意PC系統與手機系統間文件格式，交互命令等的差異，或是語言的差異，如一般我們都選擇在中文操作語言下選擇覆蓋功能測試，但是在ad hoc的時候，我們可以著重切換到中文繁體或者英文的語言界面查看一下。
長時間不重啟手機，連續測試，驗證Stack Leak, Heap Memory, Partition等
不相關功能設置后對被測功能的影響，比如：Display Settings, Audio Settings, Profile Settings, Power Saving Mode, Flight Mode, Charging, Insert earphone, MP3/WMA/FM Radio background play, Language, Network Settings, Security Settings …….
尋找更多格式的Image/Audio/Video進行測試
快速操作，對按鍵相應順序和Scenario之間的快速切換進行測試,在編輯窗口中的高強度按鍵輸入，挑戰處理速度。（很對monkey的隨機性，以及測試腳本執行的延遲特性，發揮人手和人腦的極致）
容錯性測試，驗證手機對于錯誤的操作步驟，無效的操作，錯誤的文件格式的處理能力。（有一種變態的手法是，同時按好幾個手機上的按鍵，比如方向鍵，上下一起按）
性能測試，驗證手機對多個任務同時處理的能力。比如測試download曲目，（背景讓BT下載，Browser下載，其他文件也在傳輸，還背景播放著歌曲）
同一資源的爭奪，如不同的文件類管理ap去處理同一個文件（比如音樂盒正在播放曲目，我最小化后用文件管理器去修改這個文件）。
多個功能的中斷，scenario的疊加，是否能正常的返回初始功能。
要對操作中的時間把握的很準確，主要進行一些操作的時間點，如在一個顯示時間很短的scenario下MT call打斷。
注意有些時候操作單個文件并沒有問題，但是當同時對包含這個文件的多個文件作操作時就容易出現問題。
畫UI Flow，幫助整理思路，發現邏輯或未測Scenario的問題

其他測試

對比UI Review Note，檢查是否符合當初討論的結果
對比相類似的市面產品（不怕不識貨就怕貨比貨，做測試也是一樣）

后續動作

測試結果處理：將AD-HOC發現的Bug分類，是TC遺漏的就加入TC中
看看別的項目組都怎么測試的，找找靈感，好讓ad-hoc能穩-準-狠。

總結

以上是生活随笔為你收集整理的Ad-hoc Testing（随机测试）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。