摘要：
直到最后幾天，測試工程師們才能見到軟件的“廬山真面目”，但是不見不知道一見嚇一跳，軟件的問題巨多，甚至很多功能沒有實現，然則距離“項目死期”（交付日）已經沒有幾天了！難道測試僅僅是項目后期的事情？曾經何時作為程序員的我是看不起測試的，不少程序員也不屑於去做測試這個職位，難道測試工程師真的比程序員低人一等？
說明：
這是“挨踢項目求生法則”系列文章，之前已經為大家分享了戰略篇、團隊建設篇、需求篇、設計篇、編碼篇，這篇是測試篇。
什么叫挨踢項目？
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大戰需求分析》作者
軟件知識原創基地創辦人