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

Why need AD-HOC Testing?

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

Who do AD-HOC Testing?

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

What is AD-HOC Testing?

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

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

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

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

When do AD-HOC Testing?

存在于進(jìn)入ST到版本release前的整個(gè)時(shí)間段。一般出現(xiàn)在ST第一輪以后，對ST和regression test補(bǔ)充測試（如果有資源，也可以和ST和RGT同時(shí)進(jìn)行）；也可根據(jù)實(shí)際需要安排時(shí)間點(diǎn)，功能，次數(shù)等。

注：ST后的ad hoc test一般都以測試用例的不足處為考量點(diǎn)出發(fā)，另外就是認(rèn)為軟件比較不穩(wěn)定的功能展開。另外RGT時(shí)候的ad hoc test一般是以改動(dòng)的功能點(diǎn)出發(fā)特別注重，修改的方案是不是會(huì)導(dǎo)致其他的side effect。

Where to AD-HOC Testing?

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

How to AD-HOC Testing?

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

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

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

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

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

其他測試

對比UI Review Note，檢查是否符合當(dāng)初討論的結(jié)果
對比相類似的市面產(chǎn)品（不怕不識(shí)貨就怕貨比貨，做測試也是一樣）

后續(xù)動(dòng)作

測試結(jié)果處理：將AD-HOC發(fā)現(xiàn)的Bug分類，是TC遺漏的就加入TC中
看看別的項(xiàng)目組都怎么測試的，找找靈感，好讓ad-hoc能穩(wěn)-準(zhǔn)-狠。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。