我們需要測試人員嗎?

　　先說一個故事。

　　接手一個小項目，是因為之前的項目經(jīng)理被調(diào)走了。當(dāng)時跟我介紹項目情況的時候，這牛人項目經(jīng)理說，項目完全沒問題，功能那么一點點，很容易搞定的。我隨口問了一句，有測試人員嗎?答曰，這么簡單的小項目，還需要測試人員嗎?我茫然。

　　這牛人于是介紹完了，把這個當(dāng)時運(yùn)行很流暢的項目組交給我。每個人都把客戶需要的功能做出來了，也已經(jīng)拼接好了，好像我接手是來拿做好的成果一樣。

　　忘了介紹這牛人了。這牛人為什么叫牛人，是因為特能加班。每每在項目交貨的時候，跟客戶耗上那么幾個通宵。并且，還帶著整個項目組去耗。我自認(rèn)沒有他那么牛。

　　接手項目，并不是馬上插手亂指揮，這是我的原則。但是還有2周要交付了，我也沒有太多時間去慢慢了解項目。于是，在項目的第二天，我去找部門要測試人員了。問我理由，答曰，沒有理由，是要2個測試人員。

　　很容易的要到了兩個PLMM？粗鳰M我心里舒坦。而且兩個MM之前還沒測過手機(jī)項目。沒關(guān)系，有測試行。

　　熟悉了之后，PLMM們第二天發(fā)現(xiàn)了一個很簡單的BUG。簡單的說，是ListView的數(shù)據(jù)，在一些操作之后，亂套了。本以為很簡單的BUG，也沒多問了。

　　第三天，項目組成員們很緊張的忙著。第四天，還在忙。我有點坐不住了，去看了一圈代碼，感覺有點暈乎。再看，猛然發(fā)現(xiàn)，這些代碼的數(shù)據(jù)結(jié)構(gòu)不對，需要重做!

　　我的乖乖啊。這是神馬啊。如果我放任這情況下去，在項目交貨的時候，我也要被逼做牛人了啊!

　　還好測試人員進(jìn)入的早，這BUG帶來的影響，在重構(gòu)代碼后，終于平息下來。我們在交付的時候，沒有為業(yè)務(wù)邏輯而通宵。當(dāng)然，客戶的硬件和框架著實讓我們牛了一回。我們只是晚上在等客戶解決問題的時候，打打牌而已，沒有被客戶追著改BUG。

　　故事說完了！肮省北硎疽呀(jīng)發(fā)生，“事”表示有這么一個經(jīng)過。

　　我不禁要問，難道有那么多人，認(rèn)為手機(jī)項目，真的不要測試了嗎?

　　傳統(tǒng)業(yè)務(wù)領(lǐng)域，測試人員的重要性已經(jīng)被大家所接受。我在做項目經(jīng)理的時候，一般是偏袒測試的，因為我對他們的支持，他們才可以放心的發(fā)表不同的意見，才能把問題盡早的暴露出來。當(dāng)然，也因為我的支持，測試人員經(jīng)常犯錯，把一些正確的當(dāng)作不對的。不過，我寧愿測試人員犯錯，也不希望BUG和問題隱藏到后，到后客戶發(fā)現(xiàn)了，那非要“！辈豢闪恕

　　測試人員 ，在傳統(tǒng)業(yè)務(wù)領(lǐng)域，做的幾個驗證工作，可以用一個V字模型來說明。

　　1， 單元測試，是對編碼的驗證，保證編碼無誤，也是保證某個單元(可以是頁面，可以是某個流程等等)被正確的編碼。

　　2， 結(jié)合測試，是對詳細(xì)設(shè)計的驗證，保證各個單元串起來之后，能夠完成基本的業(yè)務(wù)流轉(zhuǎn)。

　　3， 功能測試，是對功能設(shè)計的驗證，保證系統(tǒng)的各個大功能得以正常流轉(zhuǎn)。

　　4， 用戶體驗，是對需求分析的驗證，保證系統(tǒng)是用戶想要的東西。

　　左邊的開發(fā)流程，在手機(jī)項目中，因為項目的短平快，導(dǎo)致了很多缺失。簡單的和客戶溝通之后，客戶可能只是給了一個大致的描述，幾張效果圖。開發(fā)組立即對這些客戶給的資料進(jìn)行設(shè)計，這個設(shè)計把功能設(shè)計、框架設(shè)計、詳細(xì)設(shè)計、程序設(shè)計等等都包括了進(jìn)去。以至于，只有開發(fā)人員才知道客戶的需求。

　　在這種情況下，整個項目組對測試人員是排斥的。而且測試人員對項目組也是排斥的。測試人員拿不到測試的依據(jù)和準(zhǔn)繩，對測試無從下手。開發(fā)人員不愿意再去復(fù)述客戶的需求，也不愿意再去整理各種設(shè)計，因為他們覺得代碼是一切，設(shè)計都是為了代碼而做的。現(xiàn)在代碼已經(jīng)有了，還要再去整理設(shè)計干什么。

　　因為手機(jī)不如PC的屏幕大，所以很多人認(rèn)為手機(jī)操作比PC程序簡單，邏輯也相對簡單，所以沒必要加入測試人員。開發(fā)人員自己跑跑行了。

　　以上的各種理由，都造成了短平快的Android項目排斥測試人員。甚至大型的Android項目也對測試不重視，認(rèn)為有行了，比沒有好。

　　我在項目做完之后，認(rèn)真的思考了測試人員在Android項目中，可以并且應(yīng)該起到的作用。

　　1. 用戶需求的理解

　　現(xiàn)在講究的是用戶體驗。對于開發(fā)人員來說，天生的自信往往讓他們以技術(shù)的角度去想問題。技術(shù)越牛，往往越會有這種傾向：這個技術(shù)多先進(jìn)啊，用上去之后肯定是好東西。慢著，技術(shù)先進(jìn)是用戶的需求嗎?所以，我們需要測試人員去理解用戶需求，真正把握用戶希望要的東西。因為測試人員的獨立性，他們不會被技術(shù)細(xì)節(jié)所蒙蔽。

　　2. 系統(tǒng)的整理操作流程

　　手機(jī)因為屏幕小，操作少，所以操作流程往往被忽視。其實，手機(jī)程序一點不比PC程序簡單。大量的關(guān)聯(lián)操作，將極大的考驗我們程序的健壯性。可以這么說，相對PC程序，手機(jī)程序的大段的邏輯不多，但是邏輯分支卻比PC程序更多。也是說，手機(jī)程序有更多的路徑需要覆蓋。

　　這些操作流程，在缺少設(shè)計的情況下，由測試人員來整理，肯定比開發(fā)人員整理要專業(yè)。測試人員可以只憑用戶的一些簡單信息，例如客戶給的效果圖、客戶口述等，把一份大而全的Case分支給整理出來。當(dāng)然有些是無法走到的，那個不會有太多影響，多浪費(fèi)點驗證和思考的時間，但是不會把一些細(xì)小的分支給漏了。

　　手機(jī)程序必須比PC程序健壯。手機(jī)程序會經(jīng)受用戶的各種操作，正常的和異常的。畢竟手里拿著手機(jī)，很可能突然朋友嚇一跳，不小心按到了某個鍵。所以說，縝密的操作流程，需要測試人員來整理。

　　3. 細(xì)致的回歸測試

　　為什么我跳過測試，直接說回歸測試呢?因為測試工作本身，不值得一提。那是測試人員的基本工作，像開發(fā)人員寫if - else 一樣。而且，很多人都認(rèn)為，手機(jī)測試，開發(fā)人員互相測試也是可以的。但是回歸測試不同。開發(fā)人員沒有大量的時間去做測試。哪怕有這個時間，開發(fā)人員也不會有足夠的耐心去走回頭路。放心，我們的測試人員有，他們耐心細(xì)致的工作，會告訴那些不小心犯錯的開發(fā)人員，你們要當(dāng)心了……