“Ad-Hoc” 原意是指 “特定的，一次性的”，這里專指“隨機的，自由的”測試。在軟件測試中除了根據測試樣例和測試說明書進行測試外，還需要進行隨機測試(Ad-hoc testing)，主要是根據測試者的經驗對軟件進行功能和性能抽查。隨機測試是根據測試說明書執行樣例測試的重要補充手段，是保證測試覆蓋完整性的有效 方式和過程。
隨機測試主要是對被測軟件的一些重要功能進行復測，也包括測試那些當前的測試樣例(TestCase)沒有覆蓋到的部分。另外，對于軟件更新和 新增加的功能要重點測試。重點對一些特殊點情況點、特殊的使用環境、并發性、進行檢查。尤其對以前測試發現的重大Bug，進行再次測試，可以結合回歸測試 (Regression testing)一起進行。
理論上，每一個被測軟件版本都需要執行隨機測試，尤其對于最后的將要發布的版本更要重視隨機測試。隨機測試最好由具有豐富測試經驗的熟悉被測軟 件的測試人員進行測試。對于被測試的軟件越熟悉，執行隨機測試越容易。只有不斷的積累測試經驗，包括具體的測試執行和對缺陷跟蹤記錄的分析，不斷總結，才 能提高。
關于Ad-hoc測試的簡短問答
問：什么叫“特定”測試?或者“探索式”的測試?
就是為了某一個特定目的進行的測試，就這一次，以后一般也不會重復測試。在軟件工程的實踐中，“ad hoc”大部分是指隨機進行的，探索性的測試。比如：測試人員阿毛拿到了一個新的Build，按計劃是進行模塊A的功能測試，但是他靈機一動，想看看另一 個功能B做得如何，或者想看看模塊A在某種邊界條件下會出現什么問題，于是他就“ad hoc”一把，居然在這一功能模塊中發現了不少Bug。
“ad hoc”也意味著測試是嘗試性的，“我來試試，在這個對話框中一通亂按，然后隨意改變窗口大小，看看會出什么問題…”， 如果沒問題，那么以后也不會再這么做了。
一般情況下，測試人員不會花很多時間進行特定測試，但是在一些缺乏管理的團隊中，很多時候測試人員不知道自己此時應該做什么，只好做一些看似 “ad hoc” 的測試，比如隨機測試各個功能的各個方面。這些測試理論上都應該由測試管理人員規劃好屬于各個功能模塊的測試用例中。
在一個團隊中，“ad hoc”太多是一個管理不好的標志，因為“ad hoc”是指那些一時想到要做，但是以后也沒有計劃經常重復的測試計劃。
問：我聽說有人是“ad hoc”測試的高手，這是什么意思?
答：有很多測試人員會按部就班地進行測試，但是還有一些人頭腦比較靈活，喜歡另辟蹊徑，測試一些一般人不會想到的場景，這些人往往會發現更多的Bug。開發人員對這樣的“ad hoc”高手是又愛又恨。
問：同時看問題要分兩方面，有些“ad hoc”發現的Bug在正常使用軟件中幾乎不會出現，我們要不要花時間“ad hoc”?
答：現在一些成功的通用軟件的用戶以百萬計，按部就班的測試計劃很難包括很多實際的場景，這時，“ad hoc”測試能夠發現重要的問題;另外一些風險很大的領域，例如安全性，一旦出了問題，威脅就會相當大，這時要多鼓勵一些“ad hoc”測試，以彌補普通測試的不足。從這個意義上說，“ad hoc”測試可以用來衡量當前測試用例的完備性，如果你探索了半天，都沒有發現什么在現有測試用例之外的問題，那就說明現有的測試用例是比較完備的。
“ad hoc”測試的測試流程是不可重復的，因為它的測試都是“特定”測試，沒法重復。由于這一原因，“ad hoc”測試不能自動化，就這一點而言，還達不到CMM的第二級 – 可重復級。
作為管理人員來說，如果太多Bug是在“ad hoc”出來的，那我們就要看看測試計劃是否基于實際的場景，開發人員的代碼邏輯是否完善，等等。同時，要善于把看似“ad hoc”的測試用例抽象出來，包括到以后的測試計劃中。
問：做好“ad hoc”測試有什么竅門?
隨機測試有些小竅門，可以幫助測試人員更有效的發現bug。
竅門一，在發現很多bug的地方，一定可以發現更多的bug。我們在做隨機測試的時候，往往會先統計一下，上周哪些模塊被發現的bug最多，那么這周一定要狠狠的在那個模塊里發掘一下。
竅門二，做到知己知彼。知己就是要了解自己在哪些方面有特長，多發揮這些特長;知彼主要是了解兩方面，一是程序本身哪些地方最復雜，最薄弱，這 些地方最容易發生什么錯誤，二是程序員最容易在哪些地方犯哪些錯誤。前者通過對程序的熟悉可以比較好的掌握，后者可以通過CQ(BUG管理工具)分析得 到。
竅門三，多和程序員溝通。在和程序員溝通的過程中，你可以知道很多你前所未知的東西，你可以通過驗證這些東西，來發現未知的bug，并且可以激發你運用更多的測試手段來測試。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
