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

[[167176]]

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

現(xiàn)場實錄如下：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第三個選擇就是歷史上版本的限制，包括明確寫的他可能沒做好的，或者有高風(fēng)險的，調(diào)整版本的?；谶@三個方面的話進行一個綜合的評估，或者綜合的一個選擇，我哪些需要進行測試。一般就是很高風(fēng)險的，可能會出問題的，進行探索性測試。

右邊的圖就是針對我們的產(chǎn)品，我負責(zé)的一個產(chǎn)品的測試，排了一個優(yōu)先級。這是***個關(guān)鍵的動作。

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

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

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

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

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

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

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

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

提問：那沒辦法了。

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

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

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

嘉賓：尺度。

提問：對。

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

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

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

提問：滿意。

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

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

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

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

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

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

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

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

提問：我想問一下探索性測試跟傳統(tǒng)測試***的區(qū)別在哪里?第二個探索性測試的引入對整個產(chǎn)品的測試，流程和效率上有沒有一些質(zhì)的變化?

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

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

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

嘉賓：對開發(fā)人員的要求。

提問：對，測試人員有沒有開發(fā)方面的要求。第二個關(guān)于測試人員在整個產(chǎn)品設(shè)計的需求，過程之中應(yīng)該參與進去沒有，參加到哪一步?

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

提問：產(chǎn)品的開發(fā)過程中，需求的過程中參與到哪一步，測試人員怎么參與的。

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

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

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

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

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

提問：謝謝。

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

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

提問：對。

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

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

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

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