2016年5月28日，華為開發者匯南京站在安德門黑馬路演中心圓滿落幕。本次沙龍議題增加到六個，時間安排上也從之前的半天擴展到全天。講師有來自華為、蘇寧、途牛的多位好手，議題涵蓋”通訊即服務“、”內源開發“、”探索性測試“、”容器技術”、“電商平臺遷移”、“訂單架構優化”。

[[167176]]

經過中午的短暫休整，第三個議題——由華為測試專家葉飛池帶來的《CloudCube探索測試實踐》開始了。這個看似枯燥的議題居然成為當天最吸引女生的議題。葉飛池對大家分別闡述了劇本型測試和探索性測試的價值，并分享了幾個有意思案例。

現場實錄如下：

大家下午好，先介紹一下，我是2005年進入華為的，一直在做軟件測試，對開發也不太懂，剛畢業的時候做了一下開發，主要是做軟件測試的相關技術工作。我想問一下今天來到現場的朋友做測試的多嗎，能不能舉個手。也不是很多。我今天講的是做的云產品CloudCube，是一個云平臺，pass層的云平臺，在上面做探索性的實踐。

我想再提問一個問題，大家知道什么叫探索性測試，或者探索性測試和其他測試的區別嗎?

提問：探索性測試好像沒有固定的定位吧，以前我們傳統測試是有一套。

嘉賓：對，也可以這么說。探索性測試是針對原來的劇本，原來的一套一套測試來說的，發現原來的測試，一些問題不好解決，這時候就引入探索性測試的說法，也是這幾年在測試領域比較火的。探索性測試，之前劇本的測試里面我們跟著SE，或者跟著開發那邊，一個需求，一個迭代，一步一步的來。以前的劇本測試還能夠形成固定下來，很多模式都是定的情況，就可以比較好的一步一步的進行。但是現實的情況，我們現在的迭代越來越快，很多時候我們寫的劇本測試會跟不上。

我之前是做測試團隊的負責人，待了幾年，也是新員工，大概是2013年的時候做了一個實踐。今天時間很短，我講的不是很全面，大家有問題可以隨時提出來。今天就以四個維度來說一下，背景，策略，還有實施的效率。

開展的背景。以前是劇本測試，劇本測試依賴于前端相對比較穩定，我寫完之后跟著前端需求進來，寫完之后可以編下去。我之前實現的是云平臺，很大的特點很多需求是不穩定的，甚至是全新的產品，包括現在大數據之類的產品，你甚至不知道它應該是怎么樣的，包括前端的一些輸入可能也隨時變化，客戶需求隨時變化的。假如按照以前劇本測試的話，我們可能辛辛苦苦花一個禮拜寫的設計方案，寫的一個腳本，寫完之后他需求變了，你又要變，這是極其浪費的。這是我要開展的最重要的背景。

還有一個目的，大家做測試的時候，特別是帶測試團隊的時候，你會發現我給員工測的時候，這一輪測這些，下一輪測這些，可能***輪發現問題之后，后面測的還是那些東西，感覺測不到，發現不了新的問題，你帶測試團隊的時候就很糾結。這時候我就想到，我們有沒有一個方式改變這種狀態，這是第二個原因。

第三個原因，我們在做測試的時候會一輪一輪的，一般也是安排一個(05：08)，在以前做的時候，我們自己想想吧，發散一下吧，發散一下自己看看能不能發現一些問題。一般也能發現一些問題，一般只有那些責任心比較強的同事，或者思路比較強的同事，他可能會發現有生路的問題，很多時候大家基本沒有太多的產出，這是我之前帶測試團隊的經驗。

基于這三個方面的背景，我們可能引入了一個探索性測試的實踐。這是當初做探索性測試的流程，花一段時間做一個準備，什么叫探索性測試外界的專家，我也知道張波那邊，很多業界的理論是有很多的，包括很多探索性測試的方法，相關的東西，進行系統性的培訓。也結合我們團隊人員的特點和產品的特點，來進行一些策略，包括確定探索測試的范圍，這是***個步驟。

第二個步驟，探索測試之行，測試之行這里面強調測試的三個故事。在測試的過程中不斷的去調整你的策略，不斷的更新你的方法，類似于一個迭代過程，迭代的優化。

***是探索總結，能在我們部門的其他地方做些總結，做些方向，大家一起把這個做好。這是三個階段。

下面就是幾個關鍵的動作。***個關鍵的動作是我要確定初始的探索點，制定一個策略。探索點是什么呢，就是你要針對哪些范圍進行探索性測試。為什么要做這個呢，因為我們產品很多，如果每個地方做，能力是不夠的。二八原則，你要花多少精力解決20%的問題，80%的精力，要選擇你認為風險比較大的地方進行探索點。

這是怎么一個分析法呢，也是分享一下，大家有不同意見可以隨時提。在我們這邊，***個我們是平臺，從客戶那邊，或者如果是業務版面的話，也可以客戶那邊。像我們是平臺我的客戶就是我們的解決方案，從他那邊收集他的一些問題，包括在版本上網的時候，三個版本的一些問題，確定質量風險比較高的一個特性，首先這是***個選擇。

第二個選擇就是對于older的問題進行更新分析，older的問題是華為的一個特色，我們提問題單詞，測試的時候提一個older new就表示是我這個版本新的特性。older可能是三個版本，我上一次應該發現的而沒有發現的，到這一輪才發現，定義一個older。定義有什么好處呢，可以針對我為什么遺漏了這個older的問題，所以這個也拿來進行內部高風險的分析。

第三個選擇就是歷史上版本的限制，包括明確寫的他可能沒做好的，或者有高風險的，調整版本的。基于這三個方面的話進行一個綜合的評估，或者綜合的一個選擇，我哪些需要進行測試。一般就是很高風險的，可能會出問題的，進行探索性測試。

右邊的圖就是針對我們的產品，我負責的一個產品的測試，排了一個優先級。這是***個關鍵的動作。

第二個關鍵的動作。***個是選擇范圍，第二個是選擇誰來做的問題。誰來做，***個步驟首先要有一個經驗比較豐富的，測試領域比較豐富的人，首先要選擇探索性的測試方法，探索性的測試方法在業界好幾十種，今天也不細講了，其實基本上大家都用到的，在業界進行一些總結，進行一些梳理輸出的一個方法論，在外界都能搜到，感興趣的可以下載，也可以找我交流。***個是對測試比較有深入研究的，或者有些經驗的人，結合自己產品的特點，***步選取的內容來選擇探索性測試的實踐方法，這一步很關鍵，很重要。可能新員工一般是做不到的，要對產品理解，也要對測試的方法論理解，來選擇確定一個方法。我記得當初我選擇了大概是五個方法左右，針對我產品的一個選擇，這是第二步。

第三步就是選擇人員，當初我帶人員的時候，團隊都很新，我是做的比較久的，做了十多年。還有一兩個大概有三年的工作經驗，其他都是剛畢業一年的，還有一個是合作方過來的，也是剛過來的，也是一年之內的新員工。當初經過確定以后，還是選擇有三年左右員工的，有一定測試的經驗，有一定的邏輯思維，來進行測試。

這是第二個關鍵動作，怎么選擇探索性測試方法和人員。當然我說的不一定對，當初我在華為內部講這個東西的時候，不記得是哪個產品線測試的，也是做了14年了，他可能跟我想法不一樣，他覺得新員工更適合做，這個也不一定。

還有一個關鍵工作是通過故事講解或者是評測。大家都知道我們做測試的時候，測試報告由我們測試來出，大家要看到你的測試報告，覺得你的產品可用還是不可用，或者是哪些地方有問題。但是很多時候測試報告，我不知道大家是怎么樣的，很多地方都是固化的模板，信息可能不是很多。我當時的做法是這個故事講解，由測試人員，由特性測試負責人，或者測試的PL負責人，去跟利益相關方講解我們產品是怎么樣的，進行一個(13：11)，或者通過一個頭腦風暴，邀請我們的SE，我們的開發，我們的業務客戶，甚至現場給我們真正的客戶，就是在外面要使用我們的，比如說運營商，說明相關的問題。

這里一個關鍵的地方，就是測試的三個故事，等一下可以打開看。為什么是最關鍵的，因為我2013年做了這個實踐之后，后來我又換了一個部門，到了平臺集成部門，我一直在推我的三個測試故事。我要求所有的測試人員必須能講故事，我一直跟他們講，測試的人員應該把自己比喻為一個銷售員，你的產品就是經過測試人員去銷售的，你要能把它什么地方能用，什么地方不能用，什么地方可能有問題，你要跟你的客戶，跟你的利益相關人講的非常清楚，這樣才是一個合格的測試人員，這是我一直強調的。當然在2013年之后，我的測試團隊里面強勢運作的必須要搞一個測試故事的講解，這個效果也是挺好的，能引導測試人員理解我的產品是什么。很多時候我們做測試管理的知道，你去問執行程度怎么樣，執行完了沒有，其實是沒有太大的效果。他執行100%，或者他執行200%，代表什么呢，只能說(15：04)，他的問題發現了嗎，或者他的問題在哪里，或者說產品的質量到底怎么樣，通過執行比例是看不到的。所以我后來在團隊里面強勢要求三個故事。為什么三個故事講的那么多，因為我覺得探索性測試，我的理解，或者在我團隊的運用***的地方，或者最要關注的地方，就是測試三段故事，我要求測試所有人員必須能講故事。一會大家可以打開三個故事的格式看一下。

后面的效果就不用太講了，看看大家有什么問題，這是當初的一個比較。可以講一點，探索性測試里面我當初發現，效率就不用看了。探索性測試有一個好處，我如果在團隊里面給每個成員分解測試范圍的時候，都是一個一個特性給他的，他測的時候問題大部分都是單個的。探索性測試是可以讓人員能夠以端到端的方式來史考，把它串起來，這時候他會發現不是他負責特性的一個問題。哪里有一個BP，29個問題里面有9個不是這個成員他負責的問題。這是一個好處。

提問：(16：55)，探索性測試跟固定測試加起來不是***嗎，還有別的什么測試方法嗎?

嘉賓：這里探索性測試是一個效率比，組合之后的效率比，24.017是后面的，就是我能力發現問題的效率比。

提問：那沒辦法了。

嘉賓：這個是說我們當時做的幾個方法的總結，包括對面的探索性在應用產品里面的分析，包括測試模板的一些輸出。簡單講一個，快進測試法，強調的是我的數據流在我整個系統里面流動的方向。說實話有這方面經驗的人也不是讓他測試就能發現問題，只是他能測試，我能有這個總結的方法引導他看到我的數據流在系統里面是怎么流動的，基于這個流動才能發現這個問題。其實這里的問題很典型，當初我們是IM，是一個客戶的結權系統，在系統里面留了四五個模塊，還蠻復雜的，類似于有點亞馬遜里面的FM。測試了很多人，也沒有發現問題，***用探索性測試方法，我就讓他怎么思考這個流程，最終還是發現了這個比較深入的問題。

***一點，過程基本都講了，不用過多的強調了，這是華為用于時間的模板寫的，在座的華為的肯定知道，可以對外共享一些內容。

提問：問個問題，(19：20)互聯網公司有一個特點，產品過程中不太了解他最終想要做成什么樣的，或者是他雖然想要做成什么樣，但是不太清楚中間有哪些東西，我們是探索性測試，再這樣的一個過程中，它跟劇本型的，一般的測試怎么做一個區分，對于這種產品測試的PM應該怎么去把握這個策略。

嘉賓：尺度。

提問：對。

嘉賓：這個問題挺好，當初搞完探索性測試，在華為里面，包括業界，測試領域的張波不知道大家聽說過沒有，跟他也組織過討論。如果以我的理解，原來以KPI考核或者要求情況下去看的話，我覺得這個比例可能還是在于我們怎么真正的把這個質量把握住。如果你認為這個特性測的不充分，或者是很高的風險，你就可以去選取，如果認為那個特性很一般，劇本的測試變化也比較少的，我認為劇本的測試就可以了。確實這個問題我不太很好說，這個當初也討論很多次，這個東西我個人，剛剛是提到了為什么要有一個對產品策略熟悉的人來吧我，完全是有一個熟悉的人，或者多個熟悉的人一起討論的。在這個團隊里面，我認為這幾個特性高風險的，我就選擇探索性測試，其他的就是劇本測試，還要根據相關的特點。當然探索性測試和劇本測試不是完全對立的，很多時候我這輪做完探索性測試之后，探索出來的點就固化到了劇本測試里面去了，這是有一個來回交互的過程，并且每個都是一個迭代刷新的。

我覺得特別強調的是應該跟互聯網的迭代模式一樣，你不停的變化，不僅僅是根據產品的變化，還要根據你團隊人的變化。舉個例子，如果你發現這個經驗，我這個開發人員很牛，他開發的東西問題不大，一般測也測不出問題，基本上你可以判斷的，他做的東西我就不用太多的測，我簡單的測就可以了。然后發現這個開發人員這個特性就是新員工做的，你就要加強了，要注意了，要不斷的交流，甚至要跟他一起來做這個事情。

也是我的同事，不知道回答滿不滿意。

提問：滿意。

提問：我也想問一個問題，剛剛看您介紹了三種測試方法，主要為快遞測試法，我想問一下，相對于其他測試方法，那種方法的特點是什么，你們是根據什么東西，根據產品特性或者什么來選擇的測試方法?

嘉賓：是的，測試方法快遞法是一種，業界還有很多，有40多種，其實很多方法是應用老了，只不過我們沒有命過名字，類似于快遞法，就是數據流在流動，或者消息流在流動。你說的怎么結合，可能就是結合，比如我今后的產品是用戶的認證系統，里面的模塊有好幾個，一般傳遞認證用戶信息的話，很多用戶的ID或者是密鑰是一個傳遞的，這時候我們就想到從這個體系里面去確認這個信息流是怎么流動的，想到這個快遞的測試方法。這個當然肯定要深入的去理解，40個方法到底是什么。可能我們之前測試的，慢慢的研究，有些思路在里面，但是實際那個方法論不見得是全的。這個方法在網上一般都有，都可以去交流。重要的是必須有一個對產品測試熟悉的人來進行一個選擇，熟悉一個人，或者一個團隊，不見得是一個人。

提問：我想問一個問題，跟傳統的測試方法相比的話，探索性測試對人員能力的要求跟傳統測試有什么不一樣嗎?就是技術、非技術的。

嘉賓：我覺得也沒有太大的不一樣，類似于怎么去選擇人來做的時候，可能沒有做過測試一兩年的新員工，不太適合做這個。他可能是按劇本式的方式去測試，先培養他測試的能力，到了兩年左右的時間，就完全可以適應做探索性測試了。探索性測試***調的是測試的思路和想法，就是發散性思維，天馬行空的多想想。

提問：你這個探索性測試方法跟傳統的測試方法，比如說我們的常理分析法是一致的?

嘉賓：這個方法論理論上是一致的，我只不過用探索性測試，我剛才說有40多種測試方法，大家可能都運用到，但是沒有想到這是一個方法論。并且你在遇到問題的時候，可能沒有想到用這個方法解決這個問題，你可能選擇另外一個方法。這時候強調這個方法論的時候，可能更容易的發現問題。或者我理解你的問題，是不是我的劇本測試和探索性測試是對立的，其實應該是慢慢融合在里面的，才是最終的一個目標。

提問：第二個問題，這個測試你剛剛有講過有測試報告，這個測試報告是一個模板，你這個探索性測試(26：55)。

嘉賓：就像我說的探索性測試，我把***的東西融到劇本里面去，***的報告出一份。但是探索性測試強調剛才說的三個故事，三個故事就是一個評估，不是那種說我執行了多少，用你執行的排比，不是那種執行。是指三個故事的評估，***個故事是產品故事，產品故事包括三條，什么情況下可以公布。第二條什么情況會失效。第三條什么情況可能會失效。我覺得這個產品不是測試人員能夠基于這個故事告訴你的利益相關方，你的產品的質量是怎么樣，基于這三條。比如我測試一個云平臺，我一個應用的安裝部署，我就把它在什么主網情況下安裝是可以成功的，在什么主網情況下安裝是可以失敗的，在什么情況易滿足的條件下可能會失敗，這其實就是一種評估。不像我們測試報告里面，可能某一個發現局限比啊，發現問題的多少個啊，這種的評估。但是我自己個人認為，可能這個評估比那個更重要，比你完成了多少測試效率啊，發現多少問題，可能會更有效。

提問：我想問一下探索性測試跟傳統測試***的區別在哪里?第二個探索性測試的引入對整個產品的測試，流程和效率上有沒有一些質的變化?

嘉賓：***個問題基本的區別就是我這個測試是隨著，甚至說那個東西過來之后，就是我的測試對象，我開發的版過來之后，我才會不斷去測它。不像以前基本測試，我先準備好用例，準備好方案，我寫腳本，一步一步的去搞。這個時候就是等它來了，我一邊玩它，一邊去想，這是***的區別。

第二個你剛才說的流程，我認為可能有一點點影響吧，也不能說是影響。其實你說的一個流程去看效率的話，我不知道你是怎么評估，我理解我評估的話，我一天多少個效率，多少個用例，或者我投入了多少人力，發現了多少問題。這個問題本身在流程也沒有問題，但是我探索性測試應該是在這個基礎上補充我流程測試可能存在的風險，來去優化它們。

提問：不好意思，我問一個問題。問一下到底怎么選擇的問題，測試里面要不要講開發人員的要求，這塊從測試的角度，專家的角度講一下。

嘉賓：對開發人員的要求。

提問：對，測試人員有沒有開發方面的要求。第二個關于測試人員在整個產品設計的需求，過程之中應該參與進去沒有，參加到哪一步?

嘉賓：***個問題，對測試人員開發代碼能力的要求。我覺得這是分的，其實測試人員不是一個，不是一種，測試人人員有很多。像我理解的探索性測試適合于系統測試，不太適合于單元測試。這個問題可能要分幾類，我認為系統的測試對代碼的要求不強制，有的更好，但是系統化測試人員更強調他對產品的理解，對產品的理解更為重要。就是我怎么用的，客戶怎么用的產品更重要，但是對單元測試人員，或者相對于下面一層的測試人員肯定要知道代碼的。

提問：產品的開發過程中，需求的過程中參與到哪一步，測試人員怎么參與的。

嘉賓：可能還是測試人員的分類，我做系統測試多一些，我以我這邊的實例來講。我是這邊團隊的TSE，主要是做系統上面的測試，我可能參與就是跟著SE在前端需求上一起去做。華為這邊有一個實例化需求，所謂實例化需求就是TSE，就是測試設計人員，叫TSE，不知道外面怎么叫，華為這么講。和SE一起去分析這個需求，在SE輸出這個需求文檔的時候，你TSE要輸出用例，輸出驗收用例，就是跟他一起分析這個需求，當然主要分析還是在SE那邊，從TSE的角度主要是輸出我的驗收用例，驗收場景。驗收場景是要跟用戶，跟提交需求人，跟SE達成一致的，主要就是這種參與。比如說STV測試的，就是跟著開發，跟著Store一起去開發，一起去寫會好一點。

提問：再問一個問題，我覺得國內的好多地方測試人員跟開發人員占比比較小，這時候大家為了產品的質量肯定是要，測試力度肯定要大一點。這個時候開發人員也會充當測試人員的角色，我想問一下開發人員怎么轉變一個角度測這個功能，如果是自己測自己的開發功能，會有很多找不到的地方，用什么樣的管理方式，或者用什么樣的思維方式做這個事情比較好一點?

嘉賓：我覺得一個結隊的方式，所謂結隊的方式，比如說開發這個特性，你可以跟開發人員結隊，或者說在華為叫鐵三角。所謂鐵三角，一個開發，一個測試，一個SE，SE就是系統設計師，一起去做這個事情，就是互相協作做這個事情，這是一方面。第二個可能是交叉測試。

提問：我們做的比較多的就是交叉測試。

嘉賓：我覺得交叉測試也挺好，不同的人，換一下測試。還有一個我建議case，就是演示，頭腦風暴，把大家召集在一起，去想一想，大家一起來想一想，這個效果很好。我可能每周都要求TSE跟別人(35：14)，里面會發現很多問題，并且營造(35：21)。比如我這邊是平臺，我的客戶設計業務解決方案，到版本發布的時候才給他，發現一些問題，他可能會卡我的點，不讓我過點，不讓我發布。現在我們轉變做法，每一個迭代都要找他一起來談，也是學學互聯網的思路，迭代式的給別人使用，讓別人提早發現問題。

提問：謝謝。

提問：提個問題，您剛剛講到現在的測試方法有劇本測試和探索性測試，具體的實施過程中，不同的單元測試，我考核測試人員很好考核，就看他有沒有測。探索性測試，假如我沒有在這個點，讓手下人做，我怎么知道他究竟有沒有進行探索性測試。我的意思是說，在白客測試也沒有問題，黑客測試也沒有問題，探索性測試也沒有問題，有兩種情況，一種情況是真的沒有問題，第二種是真的有問題，他根本沒有測試，在具體實施過程中怎么實施?

嘉賓：我的理解就是怎么評估測試人員。

提問：對。

嘉賓：你剛才說***種，看他測試的效率之類的東西，你覺得評估準確嗎?

提問：我的意思還有一點，用這種方法在具體的實施過程中，怎樣把這種方法落到實處。這種方法論肯定是你在開發過程中總結出來的方法，現在目前情況下還沒有進入大規模的推廣，在華為內部是這樣的。如果說這種方法進行推廣的話，在實施的過程中，現在人都特別浮躁，真要沉下心很仔細的按照探索性測試，一步一步的探索每個方面各種思維去想，我想有很多情況下，雖然告訴他了，但是他不一定按照你的方法來做。

嘉賓：我明白你的意思，怎么評估，探索性測試就是以三個故事來評估，他能不能給我講清楚，什么地方可用。如果一個測試人員，他做的很深入的話，他講的東西你一聽就明白，他講的頭頭是道，什么樣的OK，什么樣的不OK，講的很清楚。如果一個人只是很淺的做，只是完成他的用例個數的話，比如原來我們評估他的測試效率，一天實現了多少用例，發生了多少問題。我覺得不一定的，零幾年我受過一個主管的影響比較大，他給我講一句話，測試是一個良心活，你看不出來，從他的數據來看很多時候是看不出來的，很多人一天可以發現十個問題，很多人一天就發現一個問題，但是這個問題的質量是怎么樣的，一個問題的拆分是什么樣的，一個問題可以拆分成十個問題給大家來提，絕對是可以的。從那個個數來評估，從那個效率來評估，我覺得只是作為一個參考，作為一個牽引的東西，不能作為主力的去評估。我覺得為主的評估，剛才舉的那個例子，在我的認為中，我覺得一個測試人員就是一個銷售員，你銷售員能不能把這個產品講的清楚，你講得清楚我覺得你就是OK。當然還有一些額外的，產品出去之后的問題，包括外界也有一些數據，我認為是可以結合的。華為各個部門也是在推，包括我也是選擇性的，不要強調探索性測試就是打破劇本測試，其實是一個融合，你如果作為革命者的時候，你的阻力很大，去挑戰一個大的流程是很大的。我們怎么做，我們是作為一個補充，慢慢的潛移默化的做一些事情。我也比較崇拜華為里面一個叫張波的，做測試體系的人，他是測試里面我們叫他布道者，測試文化怎么推廣出去。測試人員每個人都憑著自己的的良心去干活，而不是為了數據去干活。

三個故事大家感興趣的可以再探討，時間關系就講到這里，謝謝。