周六，深夜，我拖著滿是疲倦的身軀，四處閑逛，來到小巷一家還閃著霓虹的酒吧，我略一猶豫走了進去。

酒吧冷冷清清，寥寥幾對男女，在昏暗的燈光下切切私語，我沒興趣知道他們在說些什么，懶懶趴在吧臺，酒保一臉賊像，笑嘻嘻問我想喝點什么，并向我推銷他們的新品雞尾酒，我不看他，只說：啤酒。

酒保自討沒趣，把酒擺在我面前，我眼神空洞，一口口喝酒。

吧臺上還坐著個戴著墨鏡，滿臉胡茬的大叔，喝著的也是啤酒。

這時我的手機鈴聲響起，我掙扎兩下，拿出手機，卻看到是總監打來的.

沒辦法，接吧：喂，總監。

總監：“朝聆夕改，你在干嘛？”

我：“我....我在回家路上。”

總監：“BUG處理得怎么樣，是不是要發新版？”

我：“嗯，BUG處理得差不多了，要發新版。不過研發的同事說怕再說問題，要多測兩天再上......”

總監：“那你還回什么家，好好測啊！當時測試的時候不好好測，現在倒想起來謹慎了.....”

我：“好的，我周末繼續測....”

掛了電話，我木木地喝了口寒徹心扉的啤酒，準備再坐幾分鐘就回去。

這時，旁邊的大叔冷笑一聲：“小伙子，你是做產品的吧？”

我一激靈：“你怎么知道？”

大叔抿了一口啤酒：“我不僅知道你是個產品經理，還知道你們公司人不多，你們公司沒QA。”

我手抖了抖，杯子掉在桌上，濺起的啤酒，冰涼了我的神經，我一下子清醒了。

他猜的沒錯。我是個產品經理，移動產品經理，公司剛B輪，人確實不多，沒有QA。

我轉過身去，看他，才發現其實他邋遢之余很是瀟灑，昏暗的燈光下那閃閃的墨鏡遮住了他深邃的眼睛，嘴角泛著淺淺笑意，胡茬還留存著啤酒漬....

我一抱拳：“請問前輩高名？”

他笑了：“別來那套文縐縐的，老子姓高，你可以叫我老高。以前是移動互聯網創業公司的產品總監，現在下海做生意，兼職算命。”

得道高人！我知道我今天遇到高人了。

他不看我：“是不是測試遇到麻煩了？”

我低頭：“嗯，公司沒測試，我負責組織研發同事測試，結果測完上線，出現了機型適配的問題，只能重新發布...”

他說：“你知道測試是什么嗎？為什么你們公司沒測試？你作為產品經理，卻得做測試的工作？”

我有點蒙：“測試，就是一群人拿著手機測BUG啊，公司不是沒招過測試，上次來的那個測試，看所有人下班了都沒走，第二天就不愿意來了.......我對產品最熟啊，再說也缺人。”

老高咂兩下嘴：“錯，錯，錯！測試是產品策劃到上線維護中不可缺少的一環，測試質量的高低直接關系到產品的可用性，友好性，可靠性。雖然測試是必要的，但測試人員不是必要的，因此大多數的初創公司并不設置QA的崗位。同時，沒有測試人員，其實也是一種敏捷的方式，facebook在從創立起很長一段時間里都是沒有測試的。產品經理做測試，一方面是因為對產品最熟，另外也是因為開發思維與測試思維是不同思維的原因，說了你也不懂。”

我不服氣，猛地喝了一口酒：“那你說說測試是什么？”

他又笑：“從測試內容上看，測試主要分為UI測試、功能測試、兼容性和性能測試。UI測試就是界面視覺的測試，找設計師測就行了，兼容性和性能測試人力不可為，一般要借助工具測，但是必須測，像你們這種手機適配問題肯定是沒走過這個流程。一般來說，產品跟研發做的就是功能測試。測試是有許多方法的，但主要分為三類.....”

“黑盒測試、白盒測試和沙盤測試！”原來是酒保打斷，這廝在旁邊偷聽許久了，我還以為他是想趁我不注意給我倒酒。

我說：“你還懂這個。”

酒保賤賤一笑：“略懂，略懂，以前做測試的，花名測三通。”

老高也有興趣了：“那你說說什么是黑盒測試。”

測三通：“黑盒測試，也可以叫不透明測試，它著眼于程序外部結構，不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。主要方法有等價類劃分法、因果圖法和錯誤推測法。等價類劃分法就是把產品按照模塊進行劃分成若干個部分，分人測試，一般公司都用這。因果圖法就是根據流程圖，測試前、后置條件，從而推斷是否可以正常使用的辦法。”

見我不太明白，他又補充說：“比如在購物車點擊確定，但是購物車里是空的——返回“用戶名錯誤”提醒，就是一條因果圖法的測試用例。白盒測試與黑盒測試互補，是透明測試，在于全面了解程序內部邏輯結構、對所有邏輯路徑進行測試。沙盤測試就像你們產品經理做競品分析的時候做的那個什么....“

老高提醒：“任務走查。”

測三通：“嗷~任務走查，模擬用戶在實際環境中的測試，也就是把一個個用戶場景都走通一遍把重要的邏輯漏洞過濾掉，一般產品上線前的回歸測試就用它。”

真是人不可貌相，我深深看了測三通一眼，然后溫柔地對他說：“倒酒。”

老高補充說：“其實還有許多測試內容，比如：

排序測試

字符測試

緩存測試

必要信息測試

準確性測試

在測試中是很容易忘記的，你最好記住。”

我拼命點頭：“前輩教導的是，我們平時用的就是黑盒測試，那你能跟我講講測試的流程嗎？”

老高用酒杯砸了砸桌子：“這個要講好久（好酒）呀.....”

我定睛一看：果然酒杯空了。

我看了測三通一看:“倒酒，算我的！”

測三通這小子早就在旁邊等著了，趕緊給老高倒了杯12年的人頭牛。

老高喝了口：“好酒，既然你這么有誠意我就好好跟你說說。”

我跟測三通都聚精會神地看著他。

老高：“測試流程主要分為這么幾步，1、測試資源準備；2、測試人員分工與選擇測試方式；3、測試FIX任務。除此之外你還要準備相關文檔。話說你叫什么名？”

我這才想起我沒做自我介紹：“哦哦，我叫朝聆夕改，你叫我小朝就行了。”

老高：“小改呀，你平時測試資料準備都準備些什么呀”

我想了想：“主要就是各種型號、操作系統的手機，有時候還需要給他們準備點紙筆。”

老高點點頭：“嗯，你說的是測試設備的準備。測試資料一般要準備下面幾項：

測試設置，除了你說的手機、紙筆外，你還要借場所，就是會議室之類的，準備點小零食也是有好處的；

測試壞境，一般就是內測壞境、正式環境；

測試賬號，普通賬號和特殊賬號，都要多準備些，臨時準備會影響測試人員的士氣；

測試人員，要預約好，安排規劃，不然臨時就叫走，把你氣的半死；

測試用例，這兒是產品測試的核心，是對產品的所有節目的視覺、交互和功能邏輯的匯總。”

測三通插嘴：“這個測試用例可得好好講講。”

我冷冷地看了他一眼：“你也要請喝酒嗎？”

測三通閉嘴。

老高呵呵一笑：“當然，不講測試用例算什么測試。

測試用例撰寫的原則有這么幾種：

有效性，就是說測試用例必須是真實有效的，不同的測試人員依據相同的測試用例所得到的輸出應該是一致的；

復用性，不用寫的太死，能復制最好，要不然一個小產品就隨隨便便幾千個，累都累死你了；

易組織性，寫用例的時候最好能考慮到測試的場景，別上一個用例寫的是A頁面，下一個又跑到C頁面去了，當然產品經理還是有這個思維的；

還有其他原則，比如可評估性，可管理性，太專業了不太重要，原則有幾個就夠了。

得，我先上個廁所。”

說罷，他扶著墻去廁所了。

老高真是教科書一樣的人物，只可惜，人到中年就雙目失明...我正在替他感到悲哀，就聽到老高遠遠地就在廁所門口喊：“你這賊酒保，又趁我不在給我倒酒是不是！"

測三通，僵住了正在偷偷倒酒的手臂，尷尬地說：“哎呀，你老身體健康就好，沒事戴什么墨鏡算命吶，我就想做點好事，請您喝杯酒......“

老高大步流星走到位置，不客氣地猛喝一口：“原來是這樣，三通你這年輕人不錯，我看好你。”

測三通訕訕而退，我看看老高，他正摘下眼鏡朝我眨眼：原來是裝的，騙酒喝！

我苦笑：“前輩，咱們接著說測試用例吧。”

老高：“好嘞，剛說了原則，下面說說類型，類型就這么幾種：

基本功能用例、交互用例、臨界用例還有壓力測試。前面三種你應該都懂，最后一種壓力測試一般人就不懂了，壓力測試一般是指在比較短的一段時間內，被測手機執行比較多的任務或者操作，來檢測被測手機承受壓力的能力。這個測試還是比較有必要的，知道了也可以裝X。”

我深以為然：“前輩，我也寫了一些測試用例，請您指點。”

老高看完我的測試用例，點點頭：“小改，其實這就夠了。測試用例在內容上可以分為兩個部分：測試信息和用例信息。

測試信息包涵了測試人、測試時間、測試版本號、測試機型、操作系統以及測試的結果統計；

用例信息主要包涵用例所屬模塊、用例ID、用例事件描述、前置條件、期望結果以及測試結果等。”

老高頓了頓，說：“這是黑盒測試的用例，如果是沙盤測試或者白盒測試，用例就會復雜許多，往往需要流程圖之類的，比如說成熟的，或者傳統公司對測試的流程就要多許多，你是用不著學的。”

我得到了前輩的認可，還是有些欣喜：“那該說說測試分工的事情了。”

老高：“那你們平時怎么分工的。”

我說：“就找兩端的主管要些人，然后隨即分模塊給他們，把測試用例分給他們，下午的時候組織一下集中測試。”

老高搖搖頭：“效果怎么樣。”

我品了品苦澀的啤酒：“不太好。”

老高：“具體表現呢，列舉出來，你個產品總得有點邏輯能力吧。”

我掐了掐自己已經快麻木的大腿，強打起精神：“那我可得好好吐槽一下：

1、集中測試的時間縮水太嚴重，每次召集人手都要幾十分鐘，還經常檢查出BUG就馬上去改，一次集中測試要測1~2小時；

2、集中測試效率低下，測試時很容易被與自己測試內容不相關的部分打斷；

3、負責測試的研發同事對產品不熟悉，要跟他們講，特費時間，效果還不好；

4、單獨測試不能很好執行，不可控；

5、經常性被不同的人提出重復的BUG，浪費時間。”

老高哈哈一笑：“看來你很清楚出現的問題呀，可是你還是不能解決是不是。”

我：“是啊，請前輩指教。”

老高揮揮手：“叫老高就行了，指教談不上，兵法有云：知己知彼，百戰不殆。你既然知道問題，也應該知道出現問題的原因。第一條，集中測試太費時間，主要的原因是這么幾個方面：

1、沒有很好的時間規劃，測試人員不知道什么時候測什么時候停止測，建議你們的集中測試由下午改成中午，到午休的時候自動停止，這樣至少有個停止的時候，讓測試人員能夠自覺調節測試的速度，同時下午的時間其實更有彈性，你懂得，改不完的可以加班嘛；

2、人氣不足，可能是你在公司呆的不久，跟開發不是很熟，更重要的是沒有建立那種說一不二的威信，所以你得以身作則，樹立形象；

3、測試人員責任心不足，這是怎么回事，你知道烏合之眾這個詞吧，差不多就是說群體會降低每個人的智慧，大家嘻嘻哈哈沒當回事，自然不行。這時候我建議你使用交叉結對測試的方法測試。

4、測試人員動力不足。沒獎勵呀，你得多鼓勵鼓勵才行，有鼓勵師沒？”

我張張嘴，還沒說話，老高就打斷了我：“沒有是吧，那就物質獎勵，前面說測試資料準備的時候不是也提了準備零食嗎，這時候就得上啊。”

我皺皺眉：“老高，那個什么交叉結對測試是什么意思？我只聽說過交叉測試。”

老高瞇了瞇眼睛：“交叉結對測試，就是指安卓和iOS兩端的負責同一個模塊的開發人員，組成隊伍，相互測試對方的客戶端。有點拗口，但很有用處：

1、由于是負責自己開發的模塊，所以不需要學習，能夠很快投入狀態；

2、測試對方的模塊，能夠在測試的同時檢查自己的錯誤，測試的時候能夠心中有數；

3、既是合作也是競爭，同時由于測試必須同時進行，一個人不來，另一個人也沒辦法開展工作，所以時間被拖延，這樣也是培養他們的責任心。

這樣，使用交叉結對測試的方法，其實也很好地緩解了第二、三、五個問題。”

我搶過測三通手上的酒，給老高滿上：“高哥，這個我算明白了，你給我講講其他的吧。”

老高滿意地點點頭：“集中測試效率低下，很容易被打斷。其實這個也很好理解，集中測試就是發現一些重要、明顯的BUG的嘛，不要指望它能夠帶來多大的效果，但是由于單獨測試不可控，所以集中測試是很有必要的，你就把集中測試當成一個測試的熱身，調動熱血與氣氛的工具就好了，可以適當地縮短集中測試的時間。”

我把手機調成的錄音機，放在老高面前，生怕漏了一句。

老高頓了頓，說：“你說了許多集中測試的事，卻不說單獨對照測試，肯定不是因為單獨測試很順利，而是因為沒人單獨測試是不是。”

”是啊，除了我跟個別的開發，其他人都不照著測試用例測。”我如遇知己。

老高嘆了口氣：“這也難怪，我以前也遇到這種問題，原因無非以下幾點：

1、BUG改不完，沒有時間單獨測試；

2、利用測試用例做單獨測試的習慣未養成，同時也缺乏良好的監督；

3、認為自己的本職不是測試，所以對測試有排斥。

怎么破呢？我的建議是：

1、規范測試用例，以及單獨測試的任務，甚至可以作為績效指標；

2、招聘專業測試。”

我已經打開自己的筆記本在做筆記了:“

1、使用交叉結對測試；

2、在中午午休之前做集中測試，并減少集中測試時間；

3、做測試激勵，規范單獨測試的任務；

4、招聘專業測試。”

老高：“嗯，你這小產品，做整理的本事還是不賴的嘛。行，那我就傾囊而出，下面講講測試流程的第三環--FIX任務流程。”

見我有些疑惑，老高點了根煙，狠狠抽了一口：“測試出問題，就得歸類、整理、分配嘛。我現在隨便給它起個名字，叫FIX任務流程。自創的名字，不用回憶了。”

原來如此，我對老高更崇拜了。我想我要是個女生，現在的樣子肯定很花癡。

老高見我認可了他的命名，很高興地繼續講了下去：“我按照任務的生命周期，把整個流程分成了四步：任務創建、任務處理、任務審核、任務歸檔。現在都是在線辦公了，咱們也不能總用SVN這種傳統工具不是，多不方便，如果公司沒有開發自己的任務系統，那也可以用現成的。”

我急說：“是，我們公司用的就是在線辦公，還不錯。”

老高得意地吐個煙圈：“看來我還沒過時。那你覺得怎么好用了，有哪些不好用的地方嗎。”

我說：“還不錯，不過確實也有不對勁的地方。

1、任務創建的時候，有的開發把自己發現的BUG提交上去，但他們描述的任務的風格不一樣，有的描述問題，有的描述正確的做法，讓那些修BUG的人看不懂；有的開發把BUG給負責人，讓他們去提交BUG，結果修BUG的人不知道這個BUG是誰提交的，到處找，遇到一個人就描述一遍，費勁；

2、改BUG的時候，有時候需要跨部門合作，可能需要產品、設計、服務端、前端等部門的同事參與，周期太長，他們也不見得有時間幫忙，總是拖拖拖；

3、有的問題，其實不是BUG，是產品設計上的問題，這時候要找負責該模塊的產品確定，但是常常就是一個客戶端改了，另一個根本不知道，好麻煩；

4、任務太多的時候，就需要歸檔，可是一個個歸檔特別耗時間，然后就是歸檔任務之后就不知道這個任務是怎么發現，怎么處理得了。”

老高笑道：“這些簡單，我教你幾招：

第一招，集中測試時，每個人一張紙，將BUG寫在紙上，然后署名，由負責人去記錄，同時任務創建的同事需要關注BUG的發現人；單獨測試時，創建的任務默認關注自己。這樣有幾個好處：

1、集中測試時，BUG多、亂，這時候做記錄很麻煩，不如用筆記；

2、由負責人做記錄，文風統一了，理解起來不困難；

3、關注了BUG的發現人，遇到不理解的，或者不能重現的，可以快速準確地找到發現人；

4、為BUG的修復檢查做準備，須BUG的發現人去檢查BUG是否被修復，之后才能做歸檔處理。

其實，還有個好處。”老高露出一絲與剛才騙酒喝一樣的詭異笑容：“出了問題，可以追究責任。但真實目的是讓大家更有責任意識。”

我覺得老高真是個妙人，隨便支了一招居然解決了五個問題。

老高接著說：“第二招，記錄與通知。”

說完就靜靜地看著我，我當然知道什么意思，趕緊順著他的意思，裝成傻子：“什么意思。”

老高看看杯中的酒，緩緩地晃晃杯子：“記錄就是時刻記錄這些產品設計上的改動，不一定需要PRD，但一定要記著；通知就是做了修改后就通知兩端的負責人，記住啦，別把別人當傻子，就敘述就好了，別過去就傻愣愣地問別人改了沒。”

我拼命點頭。

老高：“就這兩招吧。跨部門的事情，其實你需要做的就是：

1、處好關系；

2、把問題整理好，別找到了別人還說不出個所以然來；

3、把測試的重要性強調強調再強調。至于任務歸檔這件事，我建議你不要隨便歸檔，最好就是等到新版本上線并穩定后，再歸檔。”

老高喘了口氣：“最后就是文檔了，測試日報、周報，目的就是評估開發質量、對問題進行分析。你們既然用了在線工具，那么這個日報也不是問題。”

我沒想到今夜居然有如此大的收獲，三謝老高，準備離開。

測三通不知道什么時候已經冷冷地站在我背后，看我要離開，就冷冷地來了一句：“你沒有把話講完。”

我跟老高都看著他。

他好不容易有點存在感了，又在哪里賣關子：“我就看不慣你們這些做產品的，有什么話講.......“

我跟老高同時冷冷地道：“有話就說，沒事就滾。”

測三通徹底蔫了：“你們都避著人的事情不說，我當初就是處不好人情才出來做酒保的。”

我心一驚，沒想到這衰貨居然還有這種思考深度。

老高也把臉對著我，他的墨鏡后面深邃的眼睛也一定盯著我看。

我喝了口酒：“好吧，人的確是很大的問題。除了前面的責任感與專業程度外，還有幾個麻煩：

1、不可控的外界原因，比如緊急事件處理、測試場所被占、測試機不足等都會影響測試，甚至讓測試停止；

2、人員的不可控，緊急任務的人員抽調，請假、離職都會導致人員不足；

3、非測試人員的參與，由于不了解測試的進展，胡亂創建任務、歸檔任務，導致了大量的重復任務，甚至有些人還直接來詢問產品和開發，一個個都要講清楚才行。增加了開發的負擔，歸檔任務的就更麻煩了，直接找不回來了。”

“還有在測試的時候集中提需求的。”測三通補充道。

我看著老高，老高沉默良久，說：“這件事情，是解決不了了，只能緩解：

1、盡量做足準備，比如預約多個會議室，向公司多申請些測試機，或者讓同事們借出等，做好備用方案；

2、強調，提升測試的重要性，不能因為周期長而認為測試不緊急；

3、盡可能地調整人員調派的時間，不予固定的測試時間沖突；

4、提高人員出借的難度，如果有人要借人，那么需要找負責人說明原因；

5、盡量控制非測試人員的權限，不允許直接向測試項目組添加、修改、歸檔任務；

6、非測試人員創建的人員，需要測試審核通過后，才能由測試負責人創建任務；

7、BUG修復審核完成后，應該先歸類到特別的任務組中，等到產品上線并穩定后才可以歸檔；

8、由項目負責人整理測試日報、周報發送給非測試人員，打消他們對測試進度的疑惑。”

我設置的零點鬧鐘響起，我必須回家了，明天還有許多工作去做。我再謝了老高，也辭別了測三通，離開酒吧。

出了酒吧，寒風襲來，我被酒染紅的燥熱的耳朵，感受到今年入冬以來最刺骨的寒意，但我還很興奮，我的手機收到一條短信，原來是老高送我的十六字箴言：寫好用例，處好關系，做好溝通，招個測試。

我回頭看看這家不起眼的酒吧，霓虹燈上的有些燈泡已經熄滅，但我還是能夠辨認：測馬奔騰。

再會，離場不散場。我心說，然后扭過頭，疾步離開。

12.02筆者受邀，在多貝優課急送做了一場直播講座，但由于網絡不好致使大家上了一堂難以想象的糟糕講座，所以對參與直播的朋友感到萬分抱歉。寫下此文送給當時堅持到最后也沒離場的三十余位朋友以及優課的cc。

個人微信：cunzai437049590