Why need AD HOC?

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

Who do AD HOC?

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

What is AD HOC?

以下內(nèi)容摘自百度百科

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

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

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

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

When do AD HOC?

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

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

Where to AD HOC?

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)測(cè)試很難去覆蓋的一個(gè)問(wèn)題就是動(dòng)態(tài)測(cè)試，主要針對(duì)實(shí)際網(wǎng)絡(luò)中的切換，斷網(wǎng)恢復(fù)等。

How to AD HOC?

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

• 在寫(xiě)Case時(shí)
  a.遇到需要排列組合的情況時(shí)，將組合和主要排列寫(xiě)在TC中，其他排列情況則轉(zhuǎn)換成AD HO（特別的可以使用熱推中的smart）。
  b.列出需要做多重Interruption和Interaction的點(diǎn)，規(guī)則請(qǐng)參考6.1.4
  c.列出需要做重復(fù)操作的點(diǎn)（小于5次），比如：比如在音樂(lè)播放器下載音樂(lè)時(shí)提示空間滿，無(wú)視提示重復(fù)執(zhí)行一些操作。
  d.針對(duì)不同運(yùn)營(yíng)商的區(qū)別點(diǎn)，一般的兼容性測(cè)試，我們只跑一次網(wǎng)絡(luò)兼容性測(cè)試，為了避免后續(xù)一些bug修復(fù)引起side effect，可以實(shí)時(shí)的切換不同的手機(jī)簡(jiǎn)單執(zhí)行ad hoc，確保在各個(gè)運(yùn)營(yíng)商下是可用的。
  e.一輪功能測(cè)試已經(jīng)結(jié)束后Update的TC
• 在bug regression test時(shí)
  a.記錄Design Change較大的小Function執(zhí)行AD HOC，比如：比如在音樂(lè)盒上功能測(cè)試第一輪后增加了專輯隨機(jī)播放功能。
  b.將沒(méi)有時(shí)間做Side Effect驗(yàn)證而有必要做的bug進(jìn)行記錄并轉(zhuǎn)換成AD HOC（一些bug在修復(fù)時(shí)可能引入的resolution比較復(fù)雜，在驗(yàn)證bug的之后一般的需要查看有無(wú)side effect，但是如果遇到時(shí)間不足導(dǎo)致的執(zhí)行沖突，應(yīng)該列出該問(wèn)題后續(xù)補(bǔ)充以Ad hoc test）。
  注：在時(shí)間允許的前提下，對(duì)每個(gè)被驗(yàn)證bug進(jìn)行Side Effect驗(yàn)證。因?yàn)檫@時(shí)候做比在AD HOC和RGT做更有針對(duì)性，發(fā)現(xiàn)問(wèn)題也更早。
• 在AD HOC前
  Owner根據(jù)功能目前的狀態(tài)（過(guò)去的測(cè)試階段的執(zhí)行情況、bug狀態(tài)、Design Change的情況等）列出所需的AD HOC，比如：PM UE等修改了一些處理流程（上層UI可能沒(méi)有太大變化）。
• TC和AD HOC在多重Interruption和Interaction中的劃分規(guī)則
  a. 2重及2重以下Interrupt寫(xiě)在TC中，2重以上則列入AD HOC
  b. 3重以下包括3重Interaction寫(xiě)在TC中，3重以上則列入AD HOC

AD HOC的測(cè)試方法

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

其他測(cè)試

• 對(duì)比UI Review Note，檢查是否符合當(dāng)初討論的結(jié)果
• 對(duì)比相類似的市面產(chǎn)品（不怕不識(shí)貨就怕貨比貨，做測(cè)試也是一樣）
• 手機(jī)處于負(fù)載較大的情況下

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

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

相關(guān)文章：

《再說(shuō)說(shuō)APP測(cè)試設(shè)計(jì)-1》
《再說(shuō)APP測(cè)試設(shè)計(jì)-2》
《關(guān)于ad hoc test》
《干了這碗蛋炒飯 繼續(xù)APP性能提升-1》
《突破測(cè)試的墨菲定律 -- 有感于一次UAT組織》