關於ad-hoc測試的基本知識
「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，並且可以激發你運用更多的測試手段來測試。
測試基本知識
測試用例 功能，效能，介面，安全，易用 412教室 椅子 功能 效能 介面 安全 易用 軟體開發的流程 立項 說明該專案是做什麼的，要耗費多少資金，時間等資訊 產品說明書 對立項的詳細說明 需求文件 有些時候可能沒有產品說明書，而是使用需求文件 需求測試 開發人員，需求人員等在需求文件編寫完之後會對...
測試基本知識
在規定條件下對程式進行操作，以發現程式錯誤，衡量軟體質量，並對其是否能滿足設計要求進行評估的過程 要點 規定條件 發現程式錯誤 衡量軟體質量 是否滿足設計要求 程式操作過程 用最少人力物力財力找到軟體中問題，修復問題，降低商業風險。是為特定的目的而設計的一組測試輸入 執行條件和預期結果的文件。測什麼...
介面測試基本知識
一 介面測試是指測試介面的功能 效能和穩定性以及安全性。二 介面測試的分類 1 按協議分，可以為http和https協議 2 按內外部，可以分為內部介面和外部介面 內部介面 公司內部自己開發的介面 三 http請求方法分類 根據http標準，http請求可以使用多種請求方法。http1.0定義了三種...