敏捷項目中的探索性測試

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

后來(lái)，我逐漸參與了很多敏捷項目，從簡(jiǎn)單的單體應用到幾十個(gè)微服務(wù)交互的大型復雜系統，探索性測試的思路幫我一路升級打怪，我也對其逐漸有了更加深刻的認識。

什么是探索性測試

“探索性測試（Exploratory Testing）”作為一個(gè)技術(shù)術(shù)語(yǔ)，是測試專(zhuān)家Cem Kaner博士于1983年提出的。有人稱(chēng)其為一種”測試風(fēng)格“、也有人稱(chēng)之為”測試方法“、還有人將其等價(jià)于手工測試，但我更傾向于將其定義為一種”測試思路“。它區別于某一種具體的測試技術(shù)（等價(jià)類(lèi)劃分、邊界值測試、自動(dòng)化測試等），強調依據當前的上下文選擇合適的測試方法，因地制宜、避免南橘北枳。它可以用來(lái)幫助測試人員分析測試場(chǎng)景、制定測試策略、甚至指導自動(dòng)化測試。

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

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

與傳統的測試方法相比，探索性測試 主張學(xué)習 ，強調 同時(shí)展開(kāi)測試設計、執行、并從結果中獲得反饋，從而持續優(yōu)化測試 。這是一種主張即興發(fā)揮、快速試驗、快速學(xué)習和動(dòng)態(tài)調整的測試思維方式。這也是個(gè)迭代的過(guò)程，剛開(kāi)始并不需要考慮地絕對充分，快速設計一些場(chǎng)景，然后從結果中獲得反饋，再進(jìn)一步優(yōu)化測試，從而使測試更加豐富。這與敏捷開(kāi)發(fā)“小步迭代、快速反饋”的理念不謀而合。

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

敏捷項目中如何運用探索性測試

這幾年我參與了多個(gè)敏捷項目，我不斷嘗試學(xué)習和運用探索性測試，它不僅幫助我梳理測試策略，還能在測試過(guò)程中給予指導，對自動(dòng)化測試的設計也起到至關(guān)重要的作用。

1.運用探索性測試梳理測試策略

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

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

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

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

• 商業(yè)區：用戶(hù)花錢(qián)買(mǎi)軟件就是因為軟件的特性使得他們的業(yè)務(wù)得以完成。商業(yè)區測試類(lèi)型著(zhù)重于測試軟件的主要特性，因此，需要頻繁地進(jìn)行回歸測試，以持續保證這些主要特性的可用性。由于具有很高的重復性，”商業(yè)區“的測試將是自動(dòng)化測試關(guān)注的重點(diǎn)。

• 旅游區：對于軟件，有些特性對新用戶(hù)更有吸引力。這一點(diǎn)也涉及到部分用戶(hù)權限的測試。

• 歷史區：軟件也一樣具有前版本的歷史遺留代碼，這個(gè)區域的測試目的就是測試遺留代碼和遺留缺陷。這一點(diǎn)在遺留系統改造項目中體現的尤為明顯。”新開(kāi)發(fā)特性不影響原有特性”將成為測試重點(diǎn)。

• 旅館區：當軟件“休息”時(shí)，它實(shí)際上還是非常忙碌的。旅館區模型關(guān)注的是一些輔助功能，比如軟件后臺運行等。

• 娛樂(lè )區：對于軟件，比如一個(gè)購物網(wǎng)站，商業(yè)區是搜索商品、加入購物車(chē)、生成訂單、付款等，而其娛樂(lè )區就是指漂亮美觀(guān)的UI、友好的用戶(hù)界面等。這就需要關(guān)注到用戶(hù)體驗和兼容性測試。

• 破舊區：不同于旅游，軟件的破舊區可能存在嚴重的缺陷、安全及性能問(wèn)題。這部分可能是軟件的重災區，需要關(guān)注異常測試、性能測試和安全測試。

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

2.運用探索性測試指導敏捷測試過(guò)程

在敏捷開(kāi)發(fā)中，我們以小步迭代的方式逐步完成產(chǎn)品的研發(fā)。舉個(gè)例子：我們在開(kāi)發(fā)一個(gè)小型系統，該系統包含4個(gè)Feature（功能特性），每個(gè)Feature又被分解為若干個(gè)Story（用戶(hù)故事），每個(gè)Story就是系統中最小的業(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

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

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

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

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

• 首先，由于每個(gè)Story為最小業(yè)務(wù)單元，每個(gè)Story都需要在當前迭代獨立完成測試，這就是所謂的 單個(gè)特性測試 ；

• 其次，由于部分Story之間有依賴(lài)關(guān)系，比如迭代1中的Story A和Story B、當A和B獨立完成測試之后，我們要關(guān)注這兩個(gè)Story之間交互的測試。一個(gè)典型例子就是，A為某個(gè)頁(yè)面的UI、B為后端實(shí)現。測試Story A時(shí)，我們關(guān)心前端展示、校驗、交互等；測試Story B時(shí)，很可能A還沒(méi)有完成開(kāi)發(fā)，我們需要通過(guò)API測試，人為地通過(guò)控制入參來(lái)完成后端邏輯的驗證。然而，我們如何保證前端在與后端交互時(shí)，傳遞給后端的入參是正確的呢？對于開(kāi)發(fā)同學(xué)來(lái)說(shuō)，“聯(lián)調”就是在解決這個(gè)問(wèn)題，對于測試人員，這便是最小 交互特性測試 。

• 再者，通過(guò)迭代1和迭代2，我們基本完成了Feature 1和Feature 2的所有story的開(kāi)發(fā)和測試，可以完成第一次Release啦。在Release之前，我們需要完成一輪回歸測試，測試范圍為Feature 1和Feature 2。假設Feature 1為“注冊”、Feature 2為“登錄”，我們已經(jīng)分別完成了注冊和登錄功能的驗收，但是“新注冊的賬號是否能夠正常登錄”并沒(méi)有完全得到驗證。這就是 交互特性測試 ，旨在發(fā)現特性在各個(gè)特性在交互時(shí)的潛在缺陷。

• 然后，在迭代3中，Story N與已經(jīng)發(fā)布在生產(chǎn)環(huán)境的Story I發(fā)生關(guān)聯(lián)，為了更好地是適配，很有可能Story N的需要被重構。那么我們在測試Story I時(shí)，要同同時(shí)關(guān)注與Story N的交互。

• 最后，在迭代4以后，我們完成了全部4個(gè)Feature的開(kāi)發(fā)和測試，又要進(jìn)行一次上線(xiàn)發(fā)布啦。同樣，在上線(xiàn)之前，我們又要進(jìn)行一輪回歸測試。不過(guò)這次的回歸測試范圍不僅包括迭代3和迭代4新開(kāi)發(fā)的內容，還要包含之前所有已經(jīng)發(fā)布在線(xiàn)上的特性，也就是截至目前整個(gè)系統的測試。這就是 系統交互測試 ，以便發(fā)現整個(gè)系統中各業(yè)務(wù)單元之間交互的潛在缺陷。

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

3.運用探索性測試完善自動(dòng)化測試

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

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

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

在敏捷開(kāi)發(fā)中，我們運用測試金字塔的分層思想來(lái)制定自動(dòng)化測試策略：

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

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

探索性測試方法有很多，這里對我幫助最大的是《探索式軟件測試》一書(shū)中定義的四個(gè)分類(lèi)：

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

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

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

2). 基于場(chǎng)景的探索性測試

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

3). 基于測試策略的探索性測試

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

已有的測試策略是基于測試策略的探索性測試成功的關(guān)鍵，測試人員的測試知識和經(jīng)驗越豐富，測試效率就會(huì )越高、效果越好。測試新人可以從測試老手的測試路徑中學(xué)習和提取一些新的測試場(chǎng)景，補充到自動(dòng)化測試中。

4). 基于反饋的探索性測試

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

舉個(gè)例子，你由于肚子疼去醫院檢查，大夫輕輕按你壓腹部某個(gè)部位，如果你沒(méi)有反應，他會(huì )試著(zhù)調整部位；如果你輕微”啊“一聲，大夫便知道這個(gè)部位存在嫌疑，他很可能會(huì )再按一次，并且力道稍大一些。”啊“一聲就是你給予大夫本次測試的反饋。

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

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

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

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

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

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

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

參考：

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

原文轉自：https://insights.thoughtworks.cn/exploratory-testing-in-agile/