摘要：
直到最後幾天，測試工程師們才能見到軟體的“廬山真面目”，但是不見不知道一見嚇一跳，軟體的問題巨多，甚至很多功能沒有實現，然則距離“專案死期”（交付日）已經沒有幾天了！難道測試僅僅是專案後期的事情？曾經何時作為程式設計師的我是看不起測試的，不少程式設計師也不屑於去做測試這個職位，難道測試工程師真的比程式設計師低人一等？
說明：
這是“挨踢專案求生法則”系列文章，之前已經為大家分享了戰略篇、團隊建設篇、需求篇、設計篇、編碼篇，這篇是測試篇。
什麼叫挨踢專案？
IT專案，特別是軟體開發專案，都屬於“挨踢”專案的範疇。挨踢專案的幾大特點：
1.需求不確定。
2.技術不確定。
3.工期限死。
4.預算限死
兩大不確定和兩大限死，你想不“挨踢”都難！
測試之囧
我曾經招聘了一名美女測試，面試的時候我問：為什麼離開原來的公司？
美女測試答曰：原來公司測試流程不規範，給一頁紙的需求就要我來測試，我希望到更規範的公司工作。
我聽了後表示淡定，其實這位美女測試運氣算比較好的了，很多公司的測試工作場景是這樣的：
測試是沒有書面化的需求的，對需求或者軟體有不少不懂和困惑的地方，你可以找專案經理或某程式設計師尋求答案，但得到的回答是：這個你不用管，那個你也不用管，你這樣測就可以了！
程式設計師 VS 測試工程師 誰更重要？
下面做個調查：
1）如果你是程式設計師，請回答這個問題：讓你轉職做測試，你願意嗎？（假設工資不變。）
估計100%會回答：不願意！
2）如果你是測試，請回答這個問題：讓你轉職做程式設計師，你願意嗎？（也假設工資不變）
估計部分測試會回答：願意！
如果你的回答是“願意”，請繼續回答這個問題：你覺得你能做程式設計師嗎？
絕大部分測試是不會寫程式的，所以這個問題的回答就會變成：不能:(
當然你會說有測試懂開發的！確實是有這樣的情況，但這些懂開發的測試之所以懂開發，是因為他們最開始是做程式設計師的，後來發現自己不太喜歡技術，所以才轉做測試滴。
俺從高中的時候就寫程式碼了，非常喜歡做程式設計師。剛大學畢業想到北京某建築結構軟體公司做程式設計師，但發現人家要求是精通C++。很不好意思，我精通的是Basic，所以我退而求其次，那我應聘測試吧，希望通過測試這個跳板將來轉做程式設計師！我心目中已經將程式設計師和測試工程師的重要性排了位置了，剛開始工作的幾年我心裡面是“鄙視”測試的，後來發現自己這個想法很有問題，特別是自己成為專案經理和公司管理者後。
如果你來做一個選擇，你覺得程式設計師更重要，還是測試工程師呢？
我兼任測試主管的一個專案
我是專案經理，專案組中配有測試工程師，當時並不覺得自己兼任測試主管，後來總結一下才發現原來我幹了很多測試應該乾的活！
我做的幾個測試的活有：
1）我每天檢查程式設計師們開發的東西有沒有偏離需求方向。
2）我對測試工程師給出很多指導，讓他能規劃出符合專案需求及技術特點的測試方案。
3）我會讓開發也參與測試，讓開發之間交叉測試，這樣增加了測試的人手，保證了測試的充分度。另外一個好處就是讓程式設計師從測試的角度思考問題，提升程式設計師的程式設計素養。
4）測試並不是後期才做的，我們當時每週六都要加班，這天干的事情就是測試和修復缺陷。
這個專案工期是3個月，我們居然提前兩週搞定！
測試的工作其實相當重要，幫助整個專案小組始終在正確的方向上工作，減少返工和犯錯。我當時能做以上的工作，一方面是我具備了權力（我是專案經理），另外一方面是因為我具備了做好測試工作的幾方面的技能。
作為專案經理的我，因為正好滿足下面你將要看到的技能要求，所以我才能完成上述的4個測試工作。下面我們來看看測試工程師應該具備什麼技能？
測試工程師應該具備怎樣的技能？
廢話不說，請看圖：
圖1：測試人員應該具備的技能
不少測試只懂“測試理論和方法”，對業務一知半解，對“IT基礎架構知識”、“資料庫知識”、“開發知識”、“軟體設計知識”的認知幾乎為零。如果作為測試的你掌握的知識這麼少，你能有多大的能量呢？你能在專案中幹多少活呢？這樣你就不能怪程式設計師歧視你，也不能怪所謂的公司不重視測試。
當然這個圖列的要求好像太多了，如果我滿足這些要求，我幹嘛還做測試這個崗位呢？你說的太好了！不要急，後續為你慢慢拆解……
軟體公司真的不重視測試嗎？
有些公司配置的測試人員很少，有些專案測試時間不夠就直接給客戶用，美名其曰：給客戶測試！
某公司老闆的想法更加牛逼，他認為公司根本就不應該配備測試這個崗位，因為如果存在測試的崗位，會降低程式設計師的工作質量！（程式設計師會因為有人在後面測試，工作質量會更低）
專案出現了嚴重缺陷，管理者第一反應是測試質量不過關！但我們可憐的測試往往是在被縮減的時間，去內完成不可能完成的測試任務，質量又如何保證呢？
測試階段所爆發的問題，其實80%的原因並不在測試本身，而是前期的工作沒有做好。要改善這些問題，需要包括測試人員在內的全體成員一起努力！
其實很多公司並不是不重視測試，所有老闆都希望軟體能賺錢、專案能驗收，那麼一定的質量要求是必須的，測試就是保證質量的一個重要手段。下面為你分享一些求生法則，希望對你能有一些幫助。
法則1：測試必須具備“基本技能要求”和“進階技能要求”
先舉兩個測試人員因為不具備相應的技能而導致問題的例子。
1）例1：我無法開展測試
某測試人員的工作一直不能開展，我很鬱悶，他解釋：這個“增加”功能一直沒有做出來，雖然“修改”和“刪除”功能做出來了，但因為沒有“增加”功能可用，所以……
聽了後我有點惱火：為什麼你不能到資料庫中新增一條記錄，然後你不就可以去測“修改”和“刪除”功能羅！
他不好意思地說：我沒玩過資料庫……
2）例2：需要程式設計師幫忙的測試
我有事找某程式設計師，但他不在座位不知道幹嘛去了，後來我瞭解到原來他去幫助美女測試了，他幫忙設定測試環境，包括：安裝伺服器的作業系統、安裝資料庫、安裝程式、設好配置檔案等等。
我覺得他做得挺好的，大家就應該互相幫忙嘛。但下一個版本，他又重複做類似的事情。
我問：上次你沒有教會她嗎？這次讓她自己搞定就行了。
他說：她好像不太願意學……
類似的事情我遇到的不少，由於測試人員掌握得知識太少了，以致很多工作都需要別人準備好安排好他才能做。而更讓我氣憤的是，有些測試學習的慾望很弱，而且對測試工作的認識很膚淺。一些測試認為：測試工作就是軟體做好能見到介面後，我在介面上點滑鼠和敲鍵盤就可以了，高階一點的測試工作就是能用LoadRunner之類的工具來做效能測試。
其實大部分測試都是追求進步的，“學習慾望弱”很可能是沒有認識到自己需要學什麼，沒有打牌自己固有的思維框框，沒有能發揮自己的強大潛力。要改善測試工作，作為測試人員的你首先應該自我檢討，看看有什麼可以改善的地方。
“圖1：測試人員應該具備的技能” 中列出的要求，你必須至少要達到“基本技能要求”和“進階技能要求”這兩個層次。只要你有心去學，只需要3-6個月你就可以基本滿足這兩個層次的要求。而“高階技能要求”難度有點大，一般沒有3年以上的相關工作經驗是很難滿足的，你可以考慮將這方面列為你的發展方向。只要你達到“基本技能要求”和“進階技能要求”，你的能量將會成幾倍爆發！
法則2：拒絕二手需求
“二手需求”就是專案經理獲取需求後，將需求傳達給測試，這樣就變成二手需求了。
但這只是理想境界，通常是專案經理將需求傳遞給開發，然後開發告訴測試你怎樣測就可以了。所以實際情況是，我們測試得到的是三手甚至三手以上的需求！
讓測試獲取一手需求的做法：
1）測試人員參與到需求調研中來，甚至讓測試成為需求負責人；
2）需求文件不要等全部寫好才給測試看，每寫一部分就要與測試溝通。
法則3：測試至少要成為第二熟悉需求的人
專案中最熟悉需求的人通常就是專案經理，或者是需求分析師（產品經理）。
測試至少要成為第二個最熟悉需求的人，並且要爭取成為第一位，將專案經理“幹掉”！
法則4：拒絕半個人
不少專案後期才安排測試人員進入，而且測試人員還需要同時負責另外一個專案的測試，你最多隻能得到“半個測試工程師”。
測試需要從專案的一開始就介入，並且每個專案至少要配備一名“完整”的測試。
法則5：是不是缺陷，測試說了算！
有一個缺陷，測試認為是缺陷，但開發認為不是，並且用一堆測試聽不懂的話來解釋這不是缺陷。
這種狀況很常見，你們會用哪種方法裁決？
A）測試因為聽不懂，所以最終被開發“說服”，這個不是缺陷。
B）交專案經理裁決，專案經理通常是開發出身的，所以最後就會變成這個不是缺陷。
C）交客戶裁決。
D）少數服從多數。測試一定是少數，所以結果你懂的……
我以前的做法就是交專案經理裁決，後來覺得可以做得更好，我將做法改成：其他人可以提建議，但是不是缺陷的決定權在於測試！
我這樣做是因為：
1）測試的角度更接近客戶，他的判斷更靠譜。
2）測試因為有這樣的一個責任和權力，他工作會更投入，會更加努力提升水平。
3）“是不是缺陷”和“能不能按時釋出”，兩個問題要分開處理。不能因為要按時釋出而掩蓋質量問題，有質量問題也可以按時釋出的嘛，但如果缺陷被掩蓋掉了，就相當於埋下定時炸彈。
法則6：測試獲取開發程式碼
請先看一個案例。
案例：需要介面規格說明的測試
某測試提出這樣的要求，希望開發人員能提供介面的詳細規格說明，以便可以開始準備測試用例，為正式測試做好準備。
開發人員反對這樣的要求，因為這事情太浪費時間了，而且介面經常會變和調整的，這個文件我豈不是要天天改！
這是事情解決起來很簡單，每一位測試的電腦上都裝上開發工具，每天測試就好像開發一樣去獲取程式碼，測試每天干這些事情：
1）編譯程式碼，檢查是否編譯通過。如果發現編譯不通過，專案小組發達了，今天有人請吃飯，請客的人就是讓程式碼編譯不通過的程式碼提交者。
2）如果編譯通過，那就進行“冒煙測試”。冒煙測試乾的事情就是將主幹業務流程走一遍，將所有能點的按鈕和選單走一遍，看看會不會出錯。如果出錯，那恭喜你，又有人請吃飯了！
3）對照需求檢查程式是否在正確的軌道上，及時提出易用性方面的改進建議。
這樣幹其實就已經做到測試前置了，這樣做就不會出現直到正式測試階段才能見到軟體廬山真面目的情況，問題不會在最後才爆發出來，前期已經發現並避免了。
要做這個事情，測試並不需要懂開發，會用開發工具，會編譯軟體就可以了。有條件的時候，測試還可以去學習程式碼，甚至逐步開始寫一些測試程式碼呢！
法則7：人人都是測試
一般軟體公司開發與測試的人數比例，大概是 4-8:1，當然也會有比較悲劇的公司是 20+:1 的。
我覺得比較合理和比較符合現實的比例也就是 4-6:1。我們就是按這樣來配置的，但仍然會出現測試人數不夠的情況，那是不是需要招聘更多測試呢？
如果已經做到法則6，測試的工作已經前置，那麼到正式測試階段，測試工作量峰值將會下降不少，但仍然是不夠人數做測試的，這個時候本法則“人人都是測試”就適用了！
測試要實現做好測試方案，到正式測試階段，將測試方案中的工作分派給開發，讓開發也帶上測試的帽子進行測試，記住基本原則就是不要讓開發測自己負責的模組就行了。
法則8：測試設計的難度不亞於軟體設計
我將測試方案及工作的規劃，稱之為“測試設計”。
如果測試只懂業務是很難勝任測試工作的，請看以下案例。
案例：某技術要求高的系統
該系統有幾個技術難點和測試難點：
1）B/S架構，但介面的易操作性要求很高，寫了很多JS指令碼。系統需要在IE6、7、8上能正常執行。
2）系統需要部署在網路負載平衡的環境上。
3）系統有很多Windows Service服務，要定時生成很多資料。
4）系統需要滿足一定的併發訪問量要求。
如果不具備“圖1 測試人員需要具備的技能”中的“進階技能要求”和“高階技能要求”，你將會對這些測試難點素手無策。
當時我們的測試沒有這麼厲害，我相信很多專案的測試也不會這樣厲害，而很多專案其實是有很多技術要求和測試難點的，那我們該怎樣辦？
記住“法則7 人人都是測試”，專案經理或專案的技術大牛就應該承擔起測試設計的工作，但要注意要帶上測試一起來做，訓練測試逐步掌握這些技能。
法則9：不需要寫面面俱到的測試用例
曾經見過某領導對測試的要求很“苛刻”，他要求測試無論事無大小必須寫出面面俱到的測試用例。比方說一個登陸系統的功能，如果按照該領導的要求，要將所有測試資料都寫清楚，那麼寫出來的測試用例至少需要10頁以上的A4紙。
這是一個比較極端的真實案例，稍微沒有那麼極端的情況是，要求所有的需求都需要對應有文件化的測試用例。
在軟體開發工作當中，其實有些工作是屬於“常識性”的，你閉著眼睛也會做的，這些內容就沒有必要文件化。
比方說我讓你寫一個吃飯說明，你會這樣寫嗎？
1）用一隻手拿起筷子；
2）用另外一隻手捧起碗；
3）用筷子將碗中的飯扒到嘴中，記得要張大口噢；
……
你看了上面這段描述，不知道吐血了沒有？
我們只需要對比較複雜的、容易出錯的、有難度的地方，寫出相應的測試用例，測試用例的描述在於描述清楚測試思路，不需要事無大小都寫下來。
當條件成熟的時候，公司可以逐步建立測試用例庫，對常見的情況建立測試指南，讓所有的測試人員去學習和參考，專案中遇到類似的情況就可以直接參照用例庫了，不需要再寫一次測試用例。
法則10：測試也是開發，開發也是測試
當我是一個人寫程式的時候，我就是按照“法則10”來乾的；當我和另外一位程式設計師負責一個軟體的時候，那三年時間我們基本上也是按照“法則10”來乾的。
當我做的專案的人數是幾個人以上後，這個“法則10”就很難實施了，不是我不想實施，而是因為各種客觀條件並且我的領導不同意。
我的觀點是：一名優秀的測試同時也應該是一名優秀的開發，一名優秀的開發同時也應該是一名優秀的測試！
但目前常見的現狀是：
1）能做好測試的優秀開發有，但數量不多；更多的是沒有測試意識，程式碼質量很差的程式設計師。
2）測試大部分是不懂開發的，我們認為優秀的測試往往也是不懂開發。
我曾經想嘗試這樣的管理模式：
1）開發必須每年有一段時間換崗做測試工作。
2）測試也需要每年有一段時間換崗做開發工作。
3）乾脆就不招聘測試，只招聘開發，但要求該崗位也要負責測試工作。
第1）點很難實現，因為開發基本不願意去做測試。
第2）點基本無可能，因為測試編碼基本功通常為零，而且很多測試是因為不喜歡編碼才做測試的，悲劇！
對於第3）點，我承認，我是在“痴心妄想”！
現實可行的做法可能是這樣的：
1）讓有培養潛質的開發帶上測試的帽子，負責某些專案的測試工作。該方法能提升開發的程式設計素養，也可以培養綜合性人才。
2）讓具備條件的測試在某項中帶上程式設計師的帽子，讓他寫程式碼。
我一直沒有能在我管理的公司中嘗試這樣的管理模式，但我相信這樣的管理方法一定會極大的提升公司的生產力和戰鬥力，看你敢不敢和能不能去嘗試了？
小結：
要改善測試工作首先要從思想上重新定位：
1）測試並不是一個低技術含量的工作，相反，測試工作重要性和難度並不亞於軟體設計。
2）測試並不是專案後期才開展的工作，而是從頭到尾都需要的工作，是保證專案始終在正確軌道上的重要工作。
如果你是測試工程師，提升你的水平，發揮你更大的能量，這是你的當務之急。想別人和公司重視你，是靠你自己的實力去爭取的！
如果你是專案管理者，你要注意的是：
1）專案管理者最優先要做的事情就是保證大家都在做正確的事情，你要從測試的角度從專案一開始就進行監控。
2）給測試工程師權力和成長機會，幫助他們成長，讓測試工程師分擔你更多的工作。
3）測試其實是一種帽子，其實誰都可以戴，要善於安排測試人力資源。
如果你是程式設計師，你需要多從測試的角度來檢驗自己的工作，你的工作目標就是不讓測試工程師測出任何缺陷，將測試工程師“廢掉”！
如果本文對你有幫助，麻煩點一下“推薦”啦，謝謝！
作者：張傳波
創新工場創業課堂（敏捷課程）講師
軟體研發管理資深顧問
CMMI首席專家
《火球——UML大戰需求分析》作者
軟體知識原創基地創辦人