“探索性測試”在敏捷項(xiàng)目中的運(yùn)用 | IDCF

內(nèi)容來源：七姑娘日記

作者：是七姑娘呀

第一次接觸“探索性測試”，是在三年前加入ThoughtWorks時(shí)的第一次QA社區(qū)活動上。同事妮子講了一個(gè)很長的PPT，細(xì)致地將所有的探索性測試方法羅列了一遍。我只覺得有趣，卻不完全記得住。但我了解到探索性測試的關(guān)鍵就是，打破常規(guī)套路，先去設(shè)計(jì)一部分測試，然后去執(zhí)行，再基于執(zhí)行的結(jié)果發(fā)散一些新的測試思路。這不正是我平常的工作方式嗎？我為自己的“野路子”居然有如此良好的理論依據(jù)而暗自竊喜。

后來，我逐漸參與了很多敏捷項(xiàng)目，從簡單的單體應(yīng)用到幾十個(gè)微服務(wù)交互的大型復(fù)雜系統(tǒng)，探索性測試的思路幫我一路升級打怪，我發(fā)現(xiàn)探索性測試的思路與敏捷開發(fā)“小步迭代、快速反饋”的理念不謀而合。

一、什么是探索性測試

“探索性測試（Exploratory Testing）”作為一個(gè)技術(shù)術(shù)語，是測試專家Cem Kaner博士于1983年提出的。有人稱其為一種“測試風(fēng)格”，也有人稱之為“測試方法”，還有人將其等價(jià)于手工測試，但我更傾向于將其定義為一種“測試思路”。

它區(qū)別于某一種具體的測試技術(shù)（等價(jià)類劃分、邊界值測試、自動化測試等），強(qiáng)調(diào)依據(jù)當(dāng)前的上下文選擇合適的測試方法，因地制宜、避免南橘北枳。它可以用來幫助測試人員分析測試場景、制定測試策略，甚至指導(dǎo)自動化測試。

我們對“測試”常規(guī)的理解是，知道期待結(jié)果是什么，通過一些測試手段來驗(yàn)證實(shí)際結(jié)果是否與期待一致。有點(diǎn)像小時(shí)候玩過的“蒙娜麗莎拼圖”：游戲的目標(biāo)很明確，你只需要設(shè)計(jì)好拼圖的步驟，再按照步驟移動，然后就能夠看到著名的蒙娜麗莎的微笑。區(qū)別是，有經(jīng)驗(yàn)的玩家能夠做到以最快的速度、最少的步數(shù)完成拼圖，而初級玩家則需要較多代價(jià)。

傳統(tǒng)的測試方法是“先設(shè)計(jì)、再測試”。也就是說，先分析出測試點(diǎn)，然后針對測試點(diǎn)設(shè)計(jì)好測試用例，最后執(zhí)行測試。這種方法在測試目標(biāo)明確的情況下是可行的。然而在實(shí)際的項(xiàng)目中，我們面臨的測試活動要復(fù)雜的多。它更像是“打地鼠”游戲，總體目標(biāo)是將冒出頭的地鼠給打回去，但你卻不知道下一秒，它的小腦袋將從哪個(gè)洞里探出來。

與傳統(tǒng)的測試方法相比，探索性測試主張學(xué)習(xí)，強(qiáng)調(diào)同時(shí)展開測試設(shè)計(jì)、執(zhí)行、并從結(jié)果中獲得反饋，從而持續(xù)優(yōu)化測試。這是一種主張即興發(fā)揮、快速試驗(yàn)、快速學(xué)習(xí)和動態(tài)調(diào)整的測試思維方式。

就我看來，傳統(tǒng)測試與探索性測試并無好壞之分，反而相輔相成。傳統(tǒng)的測試方法強(qiáng)調(diào)有計(jì)劃地進(jìn)行，而探索性測試旨在帶著使命在某個(gè)空間中漫游，但沒有預(yù)先設(shè)定的路線，從而發(fā)現(xiàn)更多沒有提前預(yù)見到的問題。

二、敏捷項(xiàng)目中如何運(yùn)用探索性測試

這幾年我參與了多個(gè)敏捷項(xiàng)目，我不斷嘗試學(xué)習(xí)和運(yùn)用探索性測試，也逐漸對其有了更深刻的認(rèn)識。探索性測試不僅有助于我們梳理測試策略，還能在測試過程中給予指導(dǎo)，對自動化測試的設(shè)計(jì)也起到至關(guān)重要的作用。

2.1 運(yùn)用探索性測試梳理測試策略

所謂測試策略，簡單來講，就是從“系統(tǒng)承載的業(yè)務(wù)”、“系統(tǒng)涉及的平臺”及“系統(tǒng)架構(gòu)”三個(gè)角度出發(fā)，綜合解決“測什么”和“怎么測”的問題。

不同產(chǎn)品往往有不同的特征，如何合理的規(guī)劃和分解被測產(chǎn)品，就是在解決“測什么”的問題。

《探索性測試實(shí)踐之路》一書提到一種“漫游地圖模型”，它將測試比擬為游客在城市中漫游，幫助測試人員將被測產(chǎn)品劃分成不同的區(qū)域，再針對各個(gè)區(qū)域的特征，采取有針對性的測試方案。

如上圖所示，對于游客，旅游攻略幫助游客了解一個(gè)城市什么地方值得去、什么地方不值得去。那么，對于測試人員，可以運(yùn)用“漫游地圖模型”將軟件從邏輯上進(jìn)行劃分：

• 商業(yè)區(qū)：用戶花錢買軟件就是因?yàn)檐浖奶匦允沟盟麄兊臉I(yè)務(wù)得以完成。商業(yè)區(qū)測試類型著重于測試軟件的主要特性，因此，需要頻繁地進(jìn)行回歸測試，以持續(xù)保證這些主要特性的可用性。由于具有很高的重復(fù)性，“商業(yè)區(qū)”的測試將是自動化測試關(guān)注的重點(diǎn)。
• 旅游區(qū)：對于軟件，有些特性對新用戶更有吸引力。這一點(diǎn)也涉及到部分用戶權(quán)限的測試。
• 歷史區(qū)：軟件也一樣具有前版本的歷史遺留代碼，這個(gè)區(qū)域的測試目的就是測試遺留代碼和遺留缺陷。這一點(diǎn)在遺留系統(tǒng)改造項(xiàng)目中體現(xiàn)的尤為明顯?！靶麻_發(fā)特性不影響原有特性”將成為測試重點(diǎn)。
• 旅館區(qū)：當(dāng)軟件“休息”時(shí)，它實(shí)際上還是非常忙碌的。旅館區(qū)模型關(guān)注的是一些輔助功能，比如軟件后臺運(yùn)行等。
• 娛樂區(qū)：對于軟件，比如一個(gè)購物網(wǎng)站，商業(yè)區(qū)是搜索商品、加入購物車、生成訂單、付款等，而其娛樂區(qū)就是指漂亮美觀的UI、友好的用戶界面等。這就需要關(guān)注到用戶體驗(yàn)和兼容性測試。
• 破舊區(qū)：不同于旅游，軟件的破舊區(qū)可能存在嚴(yán)重的缺陷、安全及性能問題。這部分可能是軟件的重災(zāi)區(qū)，需要關(guān)注異常測試、性能測試和安全測試。

至于“怎么測”，每個(gè)項(xiàng)目實(shí)際情況都不太一樣，項(xiàng)目的各個(gè)階段也不盡相同。我們要依據(jù)當(dāng)前的實(shí)際情況，運(yùn)用測試分層理論、進(jìn)行測試設(shè)計(jì)、做好工具選型。更重要的是，要根據(jù)測試執(zhí)行給予的反饋及時(shí)調(diào)整策略、把控風(fēng)險(xiǎn)。

2.2 運(yùn)用探索性測試指導(dǎo)敏捷測試過程

在敏捷開發(fā)中，我們以小步迭代的方式逐步完成產(chǎn)品的研發(fā)。舉個(gè)例子：我們在開發(fā)一個(gè)小型系統(tǒng)，該系統(tǒng)包含4個(gè)Feature（功能特性），每個(gè)Feature又被分解為若干個(gè)Story（用戶故事），每個(gè)Story就是系統(tǒng)中最小的業(yè)務(wù)單元。

• Feature 1：包含Story A、B、C、C、D、E、F
• Feature 2：包含Story G、H、I、J、K
• Feature 3：包含Story L、M、N、O、P、Q
• Feature 4：包含Story R、S、T、U

其中，F(xiàn)eature 1中的Story A和B相互交互；Feature 1中的Story E與Feature 2中的Story K相互依賴；Feature 2中的Story I與Fature 3中的Story N相互關(guān)聯(lián)；Feature 3中的Story L與Fature 4中的Story R相互依賴。

假設(shè)按照產(chǎn)品計(jì)劃，我們即將在4個(gè)迭代中完成開發(fā)，每兩個(gè)迭代完成一次版本發(fā)布（Release）。那么，按照需求優(yōu)先級、需求依賴關(guān)系、團(tuán)隊(duì)速率等因素，story被合理的安排到迭代1至迭代4，如下圖所示。

那么我們如何有效地運(yùn)用探索性測試來幫助我們實(shí)施測試呢？

探索性測試中提到三種常見的測試方法：單個(gè)特性測試、交互特性測試、以及系統(tǒng)交互測試。運(yùn)用到敏捷開發(fā)中是這樣的：

• 首先，由于每個(gè)Story為最小業(yè)務(wù)單元，每個(gè)Story都需要在當(dāng)前迭代獨(dú)立完成測試，這就是所謂的單個(gè)特性測試；
• 其次，由于部分Story之間有依賴關(guān)系，比如迭代1中的Story A和Story B、當(dāng)A和B獨(dú)立完成測試之后，我們要關(guān)注這兩個(gè)Story之間交互的測試。一個(gè)典型例子就是，A為某個(gè)頁面的UI、B為后端實(shí)現(xiàn)。測試Story A時(shí)，我們關(guān)心前端展示、校驗(yàn)、交互等；測試Story B時(shí)，很可能A還沒有完成開發(fā)，我們需要通過API測試，人為地通過控制入?yún)硗瓿珊蠖诉壿嫷尿?yàn)證。然而，我們?nèi)绾伪ＷC前端在與后端交互時(shí)，傳遞給后端的入?yún)⑹钦_的呢？對于開發(fā)同學(xué)來說，“聯(lián)調(diào)”就是在解決這個(gè)問題，對于測試人員，這便是最小交互特性測試。
• 再者，通過迭代1和迭代2，我們基本完成了Feature 1和Feature 2的所有story的開發(fā)和測試，可以完成第一次Release啦。在Release之前，我們需要完成一輪回歸測試，測試范圍為Feature 1和Feature 2。假設(shè)Feature 1為“注冊”、Feature 2為“登錄”，我們已經(jīng)分別完成了注冊和登錄功能的驗(yàn)收，但是“新注冊的賬號是否能夠正常登錄”并沒有完全得到驗(yàn)證。這就是交互特性測試，旨在發(fā)現(xiàn)特性在各個(gè)特性在交互時(shí)的潛在缺陷。
• 然后，在迭代3中，Story N與已經(jīng)發(fā)布在生產(chǎn)環(huán)境的Story I發(fā)生關(guān)聯(lián)，為了更好地是適配，很有可能Story N的需要被重構(gòu)。那么我們在測試Story I時(shí)，要同同時(shí)關(guān)注與Story N的交互。
• 最后，在迭代4以后，我們完成了全部4個(gè)Feature的開發(fā)和測試，又要進(jìn)行一次上線發(fā)布啦。同樣，在上線之前，我們又要進(jìn)行一輪回歸測試。不過這次的回歸測試范圍不僅包括迭代3和迭代4新開發(fā)的內(nèi)容，還要包含之前所有已經(jīng)發(fā)布在線上的特性，也就是截至目前整個(gè)系統(tǒng)的測試。這就是系統(tǒng)交互測試，以便發(fā)現(xiàn)整個(gè)系統(tǒng)中各業(yè)務(wù)單元之間交互的潛在缺陷。

當(dāng)然，這只是個(gè)比較理想的例子，在真正的敏捷開發(fā)中，我們不僅要關(guān)注功能的單點(diǎn)測試和回歸測試，還要關(guān)注性能、安全、及兼容性測試。但是無論哪種測試類型，測試范圍都是從“單個(gè)特性 – 交互特性 – 系統(tǒng)交互”逐漸演進(jìn)的過程。

2.3 運(yùn)用探索性測試完善自動化測試

由于敏捷開發(fā)節(jié)奏快，幾乎每個(gè)迭代、每個(gè)版本都需要完成或大或小的回歸測試。系統(tǒng)演進(jìn)得越來越大，回歸測試的量也與日俱增。而在敏捷全功能團(tuán)隊(duì)中，往往是四五個(gè)Dev配備一名QA，就算是千手觀音，恐怕也很難純粹靠手工完成所有的回歸測試，那么自動化測試就該登臺亮相了。

• 將需求明確的、業(yè)務(wù)穩(wěn)定的、需要重復(fù)回歸測試的部分用自動化測試來實(shí)現(xiàn)；
• 將需求不明確、變動頻繁的、無需重復(fù)測試的、或者需要日志等特殊形式驗(yàn)證結(jié)果的部分，配合探索性測試思路，通過手工測試來完成。

在手工測試的過程中，也可以逐漸抽取出一些新的測試點(diǎn)補(bǔ)全到自動化測試當(dāng)中，這將極大地提高測試效率。

在敏捷開發(fā)中，我們運(yùn)用測試金字塔的分層思想來制定自動化測試策略：

• 單元測試：旨在測試程序中的最小可測單元，隔離性很高、無需其他依賴、執(zhí)行速度較快，因此建議在每次提交完代碼并且通過編譯之后、部署測試環(huán)境之前完成“單元測試”。
• API測試：主要關(guān)注在系統(tǒng)架構(gòu)的業(yè)務(wù)邏輯層，我們通過工具或代碼方式去調(diào)用特定的API，給定輸入、獲取輸出，驗(yàn)證響應(yīng)結(jié)果。API測試不僅要關(guān)注正常場景，更要關(guān)注異常場景。API測試執(zhí)行效率比較高，可以根據(jù)項(xiàng)目環(huán)境穩(wěn)定情況，設(shè)置每次部署環(huán)境之后啟動測試，也可以每天在固定的時(shí)間執(zhí)行測試。
• UI測試：UI測試關(guān)注用戶界面及用戶體驗(yàn)。通過代碼或工具模擬用戶通過鍵盤輸入或鼠標(biāo)操作等行為來與系統(tǒng)交互。由于UI測試執(zhí)行效率相對較低，建議在每天環(huán)境相對穩(wěn)定的時(shí)間段執(zhí)行測試。
• E2E測試：端到端測試應(yīng)該覆蓋那些業(yè)務(wù)價(jià)值最高的路徑，并不關(guān)注異常場景。要做到這一點(diǎn)，需要在設(shè)計(jì)測試時(shí)，從最終用戶的角度來考慮，通過用戶畫像和User Journey來確定測試場景。E2E測試是回歸測試的好幫手，可能會在版本發(fā)布前的一段時(shí)間頻繁執(zhí)行。
• 冒煙測試：冒煙測試是一種針對軟件版本包的快速驗(yàn)證策略，如果冒煙測試沒有通過，則不必進(jìn)行更深入的測試。因此，我們可以從E2E測試中抽取兩到三條最核心的場景設(shè)置為冒煙測試，在每次環(huán)境部署之后啟動測試，從而快速驗(yàn)證本次版本的可用性。

無論什么樣的自動化測試，都需要設(shè)定特定的輸入，有明確的輸出。但是敏捷開發(fā)是個(gè)演進(jìn)式開發(fā)的過程，一些驗(yàn)收條件在這個(gè)迭代是這個(gè)樣子，在下個(gè)迭代很可能就是截然不同的了；此外，我們對系統(tǒng)的理解也必將經(jīng)歷一個(gè)逐漸深入的過程。因此，探索性測試中的一些方法正好可以幫我們彌補(bǔ)這個(gè)過程。

探索性測試方法有很多，這里對我?guī)椭畲蟮氖恰短剿魇杰浖y試》一書中定義的四個(gè)分類：

1）自由風(fēng)格的探索性測試

自由風(fēng)格的探索性測試（Freestyle Exploratory Testing）對一個(gè)應(yīng)用程序以任意次序和方法進(jìn)行隨機(jī)測試，不提前設(shè)定測試范圍和規(guī)則，也無需大量準(zhǔn)備工作。

在上面我們提到，冒煙測試是從E2E測試中提取的基本場景。但是，E2E測試實(shí)際上是整個(gè)測試中最困難的，它很大程度的依賴于環(huán)境，而一個(gè)完整的環(huán)境的創(chuàng)建與維護(hù)可能需要花費(fèi)很大的精力，特別是當(dāng)有多個(gè)不同的團(tuán)隊(duì)在獨(dú)立開發(fā)時(shí)。因此，當(dāng)自動化冒煙測試無法進(jìn)行時(shí)，我們就可以通過這種自由風(fēng)格的探索性測試來指導(dǎo)手工冒煙測試，以快速驗(yàn)證軟件包是否存在重大崩潰或嚴(yán)重缺陷。

2）基于場景的探索性測試

基于場景的探索性測試（Scenario-based exploratory testing）和傳統(tǒng)的測試方法有些類似，要有明確的測試的起點(diǎn)和終點(diǎn)。比如在E2E測試中，它可能基于基于user journal、用戶故事、程序的生命周期等。不同的是，它不限制路線。好比我們設(shè)定的場景是，從西安到北京，但并不限制出行方式和路線，你可以乘坐汽車、高鐵、飛機(jī)，你甚至可以繞地球一圈，只要最終能夠到達(dá)。

3）基于測試策略的探索性測試

基于策略的探索性測試（Strategy-based exploratory testing）是指將自由式探索與經(jīng)驗(yàn)、方法、技能和第六感結(jié)合，它屬于但不完全等同于自由式探索，它是在經(jīng)驗(yàn)和技能的指導(dǎo)下完成，比較適合有經(jīng)驗(yàn)的玩家。

已有的測試策略是基于測試策略的探索性測試成功的關(guān)鍵，測試人員的測試知識和經(jīng)驗(yàn)越豐富，測試效率就會越高、效果越好。測試新人可以從測試?yán)鲜值臏y試路徑中學(xué)習(xí)和提取一些新的測試場景，補(bǔ)充到自動化測試中。

4）基于反饋的探索性測試

基于反饋的探索性測試（Feedback-based exploratory testing）是指測試人員基于“上一次”或“上一條”測試的結(jié)果來動態(tài)調(diào)整自己的測試。

舉個(gè)例子，你由于肚子疼去醫(yī)院檢查，大夫輕輕按你壓腹部某個(gè)部位，如果你沒有反應(yīng)，他會試著調(diào)整部位；如果你輕微“啊”一聲，大夫便知道這個(gè)部位存在嫌疑，他很可能會再按一次，并且力道稍大一些?！鞍　币宦暰褪悄憬o予大夫本次測試的反饋。

再舉個(gè)例子，團(tuán)建的時(shí)候，大家常常玩一個(gè)“猜數(shù)字游戲”。法官在紙上寫下一個(gè)0-100的數(shù)字，由剩余的人從左往右依次猜數(shù)字，猜中的人將作為“幸運(yùn)兒”接受懲罰。這完全符合基于反饋的探索性測試。

• Case 1：第一個(gè)人猜“66”，法官回答“大了”。

那么第二個(gè)人便推測這個(gè)數(shù)字位于0-66之間。于是他調(diào)整自己的數(shù)字。

• Case 2：第二個(gè)人猜“63”，法官回答“小了”。

那么測試范圍就被縮小到64-66之間，很顯然，答案就在64和65當(dāng)中，那么第三位或第四位將會是那個(gè)“中獎”的人，最精彩的部分也就來了。

測試中我們也常常碰到類似的情況，一開始我們并不知道期待結(jié)果具體應(yīng)該是什么，因此無法通過自動化腳本來完成測試。所以我們按照自己的經(jīng)驗(yàn)或推測先進(jìn)行一組測試、再通過測試結(jié)果分析和設(shè)定下一組測試，依次循環(huán)直到找到最終結(jié)。等到所有的步驟和結(jié)果明確之后，就可以通過自動化腳本去完成了。

最后，由于探索性測試只是一種思路，并不是特定的測試方法，在實(shí)際運(yùn)用起來并沒有固定的套路，每個(gè)人也對它有不同的理解。但希望我們在完成測試工作的同時(shí)，能夠時(shí)不時(shí)停下來總結(jié)和思考，從而使得測試更完善、也更高效。

參考：

• 《探索性軟件測試》James A. Whittaker
• 《探索性測試實(shí)踐之路》史亮、高翔

八月伊始，乘風(fēng)破浪。IDCF【冬哥有話說】8月特別邀請到四位美女，帶來四個(gè)主題分享，分別從組織建設(shè)、績效考核、品牌營銷，以及技術(shù)卓越等不同角度，圍繞“數(shù)字化”展開，這也體現(xiàn)了IDCF一直秉承的理念“培養(yǎng)端到端的人才”，我們希望可以通過本系列的分享，給你不同的視角去看待一個(gè)企業(yè)，從單純的技術(shù)視角跳出來，去盡可能的看到一個(gè)更加完整的全貌。

本周四晚8點(diǎn)，天澤智云市場營銷副總裁夏鑫琪分享《VUCA時(shí)代的B2B市場營銷體系與品牌價(jià)值構(gòu)建》，識別下圖二維碼，回復(fù)“乘風(fēng)破浪”即可獲取直播地址。

---