沖天香陣透長安、滿城盡帶黃金甲
---黃巢《不第後賦菊》
轉自：阿里測試之道，http://www.fujian9.com
一、前言
我從事測試工作將近八年了，從起初的不懂測試，懷疑測試，到相信測試，再到堅定測試，其中經歷的辛酸、煎熬無法言表。在從事測試工作的這八年裏，有人質疑，也有人追捧，脣槍舌劍，沒完沒了，貌似測試永遠都是個站在輿論風口浪尖的角色。本文乃在下之精血所作，是我對測試的高度概括，旨在幫助大家瞭解測試，新人可以更好地從事測試工作，老人可以進行測試探討，交流思想。爲了儘量讓更多的人理解測試，本文重在述道，少說測試之術，相信看完之後，各位自有論斷，功過是非留於各位看官說。
二、測試的萬能模型
爲什麼上來就談這個？測試的模型既是我對測試認知的高度建模，也是幫助大家理解測試，理解我觀點的出發點，正所謂“風，生於地，起於青萍之末”，任何事情都是有本因的，大道至簡，理解了核心思想再看觀點，就有了論據，這正如修煉武功，根基決定了以後武術達到的高度，否則就如“無本之木，無源之水”，雖然我言之鑿鑿，但大家卻都不知吾之所云。
佛家修煉有三個境界：看山是山，看水是水；看山不是山，看水不是水；看山還是山，看水還是水。從我對測試的經歷和認知來說非常吻合，起初開始做測試的時候感覺測試工作是無聊的，枯燥的，而且並沒有太大技術含量，以爲這就是測試。但是隨着工作閱歷的增加，覺得測試越來越難，面對各種被測系統，我真的無法用一種通用的方法，或者通用工具滿足所有的測試需求。於是開始拼命學習各種系統的實現，嘗試去了解我的被測系統。我測試過的系統有java開發的，也有C++開發的，也有其它語言開發的，於是我對各種語言都有一定了瞭解，開始研究如何測試他們。隨着光陰流逝，對測試認識的逐步加深，我發現所有的測試理念都是相通的，漸漸的，我悟出了萬能的測試模型：y= f(x)。對，你沒看錯，就是我們所學的函數表達式。
x是我們的輸入，y是f(x)的輸出，f(x)表示的是被測系統的功能。測試的思路就是：選擇適當的x，代入f(x)，得到y，跟我的預期結果y’進行對比，從而得出被測流程是pass還是fail。用圖表示：
對於測試人員來說SUT（System Under Test，被測系統）是個黑盒，測試人員一般不太會關注f(x)的具體實現邏輯，只會關注f(x)的功能。比如，假設f(x)= 2^x，程序可以用“x個2相乘”實現，也可以用“左移位”的方法實現，作爲測試人員關注點只在於“有沒有正確實現需求？”，“功能滿足後性能如何？有沒有安全問題？”，關注點不在“怎麼實現”，而在“實現的怎麼樣”上面（這也是測試思維跟開發思維的本質區別）。是故，弄懂業務，理解產品需求是測試的前提。
也許有人會問，沒那麼簡單吧，系統那麼複雜，僅僅一個y= f(x)，怎麼能全部歸納？你這裏只有一個請求，一個響應，系統那是多複雜啊，數據庫，緩存，異步消息，日誌等。這裏得強調的是，x，y表示的絕不僅僅是request和response，而是廣義的輸入和輸出，什麼區別？request和response只是輸入輸出的一種，對於SUT來說，只要是讀的數據都算輸入，比如：用戶登陸的功能，當我填入一個用戶名進行登錄時，我的輸入除了在頁面上填入的“用戶名”和“密碼”，DB中也必須有這條用戶記錄（當然用戶不存在也是一種測試場景），所以DB中的這條用戶記錄也算輸入，甚至如果登錄系統處理過程中去查詢安全系統，安全系統返回的“用戶安全策略”也算輸入。所以，這裏的輸入是廣義的輸入，包含了用戶頁面填入的“用戶名/密碼”，DB中的“用戶記錄”，安全返回的“用戶安全策略”等。同理，輸出也是廣義的，包括“DB的寫”，“對其它系統的請求”，“打印的日誌”，“對緩存的put”，“發出的異步消息”等。於是我們的測試萬能公式可以進化成下面的樣子：y1,y2,y3,…,yn= f(x1,x2,x3,…,xn)。我們測試工作其實就是確定每一個x的取值範圍，然後選用合適的x1到xn的組合數據（一組數據其實就是一個測試用例），代入f，然後將得到的y1…yn跟預期的y1’…yn’進行比較，從而判斷被測場景的正確性。用圖表示：
所以，一個合格的測試，必須理清“SUT的功能”，“SUT的所有輸入”，“每一個輸入的取值範圍”，“SUT的所有輸出”，“根據功能推出每一個輸出的預期值”。
這裏還要強調的一點是，這裏的SUT是很有講究的，在我看來除了靜態走讀代碼的方式算是白盒測試外，其它的一切測試都算黑盒，只是這個“盒子”的大小不同而已。單元測試中“盒子”比較小，就是一個或者若干個方法；接口測試的“盒子”就會擴大到應用級別；集成測試的“盒子”就會擴大到系統級別。
弄懂了測試的模型，就可以開始剖析測試各個的關鍵點。
三、測試的目的
測試的目的就是規避Bug。爲什麼用“規避”而不是“找”？因爲對於所有的測試用例來說，並不是每一條都能測出Bug，對於沒能測出Bug的用例執行，你能說測試工作沒有價值嗎？顯然不能，對於測試人員來說，在未執行測試之前，假設的前提是所有的被測流程都處於未知狀態，只有執行完對應的測試用例這個流程狀態才變得可知——pass或者fail，對於fail的測試用例我們是找到了Bug，而對於pass的測試用例我們沒有也不可能找到Bug，所以不管pass還是fail，測試執行工作都是有價值的，這裏只能用“規避Bug”來精確地闡述測試工作的目的。
四、測試的步驟
再來看一下測試的模型圖：
如前面所述，測試工作其實就是確定每一個x的取值範圍，然後選用合適的x1到xn的組合數據（一組數據其實就是一個測試用例），代入f，然後將得到的y1…yn跟預期的y1’…yn’進行比較，從而判斷被測場景的正確性。由此可以總結出，測試工作步驟就是：
“確定x1至xn的組合數據”
“將每組數據傳入SUT”
“根據需求確定每組輸入數據輸入後產生的預期輸出結果y1’至yn’”
“將預期結果和實際結果y1,y2,…,yn進行比對，從而得出結論”
五、測試的難點
對於上面四步，第3點和第4點相對容易，測試的主要難點在於第1點和第2點：
1、如何找齊所有的x和y？
想要找齊所有的x和y，就必須要求你對系統非常熟悉，對流程非常熟悉。系統依賴如何？流程調用，系統如何處理、交互？產生哪些反應？典型的輸入有：調用請求，讀DB數據，讀緩存數據，被依賴系統的返回數據，收到的異步消息等；典型的輸出有：寫DB，寫緩存，寫日誌，調用依賴系統的請求，發出的異步消息等。所以這個需要你對你的被測系統和流程必須非常非常的熟悉。
2、如何確定合適的x1至xn的組合？
首先，你要熟悉每個x的可能取值，除了正常值，還有異常值，這個對測試工程師的要求非常高。爲了清楚所有x的可能取值：
不僅需要，你對業務、業務數據非常非常的熟悉。注意，這裏我把“業務”和“業務數據”分開，指的是兩個不同的東西。“業務”指的是產品提供的功能，比如：登錄可以用賬密登錄，也可以用手機掃碼登錄。“業務數據”指的是產品在線上日以繼夜的運行後產生的數據，如，註冊功能，有通過淘寶註冊的淘寶用戶，也有通過支付寶註冊的支付寶用戶，甚至還有數據打通從其它地方同步過來的其它用戶數據，你要對這些個業務數據非常熟悉。
還需要，你要對系統間依賴的接口非常熟悉。這個主要是爲了弄清楚你的SUT對依賴系統的調用，哪些調用請求的傳參是合法的？哪些是不合法的？依賴方會傳回給你哪些可能的數據或者響應，最好有規範的接口文檔（可惜現在奇缺）。
還需要，你對其它的輸入方式的數據類型有比較深刻的認識。針對我負責的系統，主要是前面兩個方面，當然根據不同的系統情況也有所不同，這個得具體問題具體分析。
其次，當所有的x可能取值確定以後，這裏就會利用專業的測試用例設計方法，對x1至xn的組合進行設計。設計方法有：等價類，邊界值，因果圖，判定表，正交法等等，這些在很多的軟件測試書中都有詳細的介紹，在此不作細表，有興趣的可以自行查閱。
3、x1至xn如何傳入SUT
這個用一個詞來精準形容就是“驅動”，如何驅動你的測試流程？其實這個很體現測試工程師的水平。如果你用的是手工測試，那肯定得搭建測試環境，必須讓你的SUT運行起來，然後預置各種數據，調用你的流程。如果你是自動化測試，這裏其實是有兩種方式：
部署被測系統，模擬客戶端發送請求驅動；
直接依賴被測系統代碼，用本地代碼調用的方式驅動。
總體來說，“驅動”的方式就是兩種，跟語言無關，各種語言通用：
代碼驅動。這個沒什麼好說的，就是把你SUT的代碼直接依賴過來，通過代碼直接調用的方式進行驅動。
協議驅動。這個也包含廣義上的一些RPC調用，主要有http，https，ftp，telnet，hsf，dubbo等。
六、測試系統理念的提出
如前面所述，測試工作的步驟就是：
確定x1至xn的組合數據
將每組數據傳入SUT
根據需求確定每組輸入數據輸入後產生的預期輸出結果y1’至yn’
將預期結果和實際結果y1,y2,…,yn進行比對，從而得出結論
我們對上述步驟的產出進行分析，1、3兩點產出的是“數據”，2、4兩點產出的是“邏輯”。第4點的邏輯非常固定，就是預期輸出結果和實際輸出結果的比對邏輯，而第2點的“驅動”邏輯雖然有代碼驅動和協議驅動，而且協議驅動也有很多種，但是因爲涉及到的是接口和協議，相對還是比較固定的，不容易發生變化，非常適合將2、4做成應用。我們想象一下，如果有一個測試系統，能根據傳給它的數據，完成對各種SUT的測試，那豈不是測試工程師只要產出數據（測試用例）就行了。思路完全可行，因爲測試用例本質上就是一個“描述，”一個“用什麼樣的數據，調用什麼樣的流程，預期會產生什麼樣的結果”的描述。這種描述可以是漢語，也可以是英文，也可以是xml格式，又或者是腳本，只要能描述清楚這種語義即可，只不過我們肯定需要對這種描述制定一些格式規範，保證測試系統能夠識別這種描述。這樣我們的測試系統就可以集用例管理、測試執行、Bug提交、測試報告於一身，成爲測試中臺（不知道這個用詞對不對）的完美轉身。我大膽畫出這種測試系統的架構示意圖：
目前我正在這個方面做一些研究，也有一些實質性的產出（驅動模塊和用例管理模塊），但還待琢磨完善，如果有人有興趣的也歡迎一起探討。
七、測試人員的價值
常常被人問起，測試人員的核心價值是什麼？跟PD、開發比區別是什麼？如果沒有經過上面的一系列分析，被人炸一問起還真不好回答。可是今天就不一樣了，今天我就談一下自己認識的測試人員的核心價值。這些是每個測試Leader必須清楚的東西，否則你如何給你團隊的成長指明方向，爲你的組員答疑解惑授業？
測試的核心價值就是：對於任何被測系統，能夠全面、高效地規避Bug——發現、定位、解決。注意，這裏有四個要素：任何被測系統，全面，高效，Bug
1、要素一、任何被測系統
系統的多樣性可能會迷惑你的雙眼，正如人往往容易在這花花世界中迷失一般，認識不到什麼纔是真正值得追求的東西，什麼纔是真財富。有了上面的分析做鋪墊，這個就很簡單了，其實就是解決“驅動問題嘛”。總是有人對測試框架的搭建，測試環境的搭建產生畏懼，弄懂了這個原理，你就會變得一往無前，就兩種驅動嘛，萬變不離其宗，只是根據不同的語言略有差異而已，但是我們都已經看到明燈的方向了還會恐懼嗎？
2、要素二、全面
這個其實就是測試用例的設計問題。這個上面已經分析的很清楚了不在贅述，請參看上面x1,x2,…,xn組合數據的設定。
3、要素三、高效
這個主要體現在三個方面：數據準備服務，自動化測試，測試的維護和傳承。
目前做的最多的也是最成熟的就是數據準備服務，基本上每個產品線都有自己的數據準備工具，如，數據工廠，TAP等。
自動化測試也是提升測試效率的主要手段，但是手工測試是不可完全被取代的。自動化測試有其適用場景：手工無法測試；功能穩定不容易變動；頻繁迴歸。即使不可全部自動化，也要想辦法進行半自動化，半自動不行就1/4自動化。總之，條件允許我們要自動化，條件不允許我們創造條件也要自動化，將一切可以讓電腦幹的事情堅決不能讓人來幹，所以，自動化的程度也體現了一個測試工程師的能力水平。
測試的維護和傳承，這個是最容易造成勞動力浪費的地方。“寧可全部重寫也不願改別人代碼”是工程師的通病，對於開發工程師來說這個問題還好一點，畢竟你不能單獨開一個應用，還得在原來的應用中去改，但是對於測試工程師來說，這個問題暴露的尤爲嚴重。測試腳本的獨立性決定了每個人寫出的自動化腳本風格都不一樣，一旦換人，後來的人是能自己寫的就堅決不維護別人寫的腳本。對於自己寫的代碼還能做到一些複用和擴展，但也很難讓別人來複用你的代碼，再換人了繼續惡性循環。究根結底，測試腳本沒有統一的規劃，不僅沒有統一風格，也沒有統一架構，確實需要也很必要制定一些腳本編碼規範，規劃一下測試腳本的架構，讓測試腳本做到可維護，可複用，可擴展，並沉澱一些測試的服務供測試使用。另一方面，剛畢業的人在寫腳本，工作幹了五六年的也在寫腳本，不信你去看，這兩者寫出來的腳本還是有很大差距的。剛寫腳本的人會把所有的邏輯放在一個testcase裏，而一個老手就有了一定的架構意識，該抽象的抽象，該封裝的封裝。所以，對測試腳本的統一規劃，也爲測試新人提供了成長的方向，有利於測試新人的迅速成長。另一個思路就是用上面說的“測試系統”來解決這個問題，大家只要按照固定的規範編寫用例，測試執行的事情交給系統去做，這個應該是最完美地解決傳承問題的解決方案，但前提是“測試系統”需要足夠的穩定、強大。
4、要素四、bug
什麼是Bug？只要不能滿足預期的東西都可以稱之爲Bug。所以，Bug也是廣義的Bug，可以分爲功能Bug，性能Bug，安全Bug，甚至流程Bug。對於一個Bug，優秀的測試工程師要能夠定位Bug原因，並給出解決方案。
對於功能性Bug，沒什麼好說的，測試工程師的大部分時間都花在了這裏。Bug定位的方法，主要的手段就是看日誌，Debug。
對於非功能性Bug，就有點複雜了，不能一概而論，但還是有方法的。如性能測試中，發現程序卡住了，你會猜測是否出現了線程死鎖，對於java應用，你需要使用一些jvm工具去查看線程堆棧，根據線程狀態做出判斷。只要掌握了一些非功能性Bug的定位方法，定位起來也是有跡可循，最後做到遊刃有餘的。Bug的定位和解決考驗的不僅是測試人員的技術深度，更是知識的廣度，所以這一點也是判斷一個測試工程師能力水平的重要方面。
另外，對於一些流程上面的問題，考驗的又是測試工程師的溝通、協調能力。因爲真的很難，主導權在PD、開發，作爲最後一個環節的測試，有時候真的需要用一些溝通技巧，和修煉出的人格魅力去說服和推進。
八、測試崗位性質
總結來說，測試屬於軟件質量把控的最後一環，測試的好壞直接決定了軟件質量的好壞。歷史上面不乏因爲測試不力而造成重大損失的案例：如，程序bug導致了天大的損失，要槍斃程序猿嗎？同時，測試又是一個支撐型的崗位，雖然它不直接產出代碼，但對測試人員的要求不但不低，而且還非常之高，很多業界的測試大牛都是先成爲開發大牛以後再轉成測試的，邏輯很簡單，因爲一個人的能力達到很高的水平以後，如何把自己的能力複製給別人就成了一門學問，最簡單直接的辦法是，去評估別人的代碼，指出別人代碼、架構的問題。測試是一個入門簡單，越做越難，甚至最後對人的要求高到極爲苛刻的地步。測試的管理也是非常難做工作，現實中大家負責的都是不同的需求，你很難去評判兩個測試工程師之間的優劣，因爲測試的深度體現在思想上，也許你可以從測試用例上面去找到一點蛛絲馬跡，又或從溝通中去尋找，又或從發現的Bug上做參考，又或從線上產生的故障上面去找。
九、說一說測試的現狀
測試是個很容易被人誤解的一份工作，測試工作本身的複雜性和綜合性，決定了測試人員的成長不如單維度作戰的開發、PD快，以至於讓很多人對測試崗位產生誤解，也就不能責怪時不時興起的“我們需不需要專職QA”的口水戰，以至於很多測試人自己都會開始懷疑。這是由於對測試本質認識不清造成的，測試有點像練內家拳，很難修煉，甚至有人修煉三年都不得其門而入，這就不能責怪中途退場者甚衆，堅定信念者寥寥。一句話來說，懂測試的人太少了。現在也有很多部門把測試人員強制轉成開發人員，試問真的行嗎？我從來不懷疑測試存在的價值，也堅定地認爲測試不可能被砍掉。試問那些強制把測試轉成開發的，轉換後產品質量如何？有多少是頂着開發title幹着測試的活？當然我沒有詳細調查過，知道的人可以說說。
測試工作的開展需要規範的合作流程，對於管理不嚴謹的開發流程，測試工作的開展就顯得處處掣肘。阿里是個以結果爲導向的公司，很多團隊對過程都疏於管理：項目延期對績效無影響；只要線上不出大故障，即使小故障不斷對績效也無影響；發佈出故障又怎麼樣，大不了回滾嘛。在這樣的環境裏，開發的質量意識也達到了低谷，各種評審省掉，各種評審不叫測試，各種開發完了來找測試驗證一下，各種壓縮測試時間，甚至我遇到過項目經理的項目計劃中竟然沒有測試計劃，開發完成還死活不肯提測（因爲過不了冒煙），再加上鼓吹開發自測，開發完全可以繞過測試，自己隨便測測，發佈代碼上線，出現問題了，再來找測試迴歸。通過歷史經驗來看，出現過幾次嚴重的大故障，大部分都是繞過測試，或者開發自測造成的。
十、測試與生活
生活又何嘗不是如此，試想生活中我們對什麼東西是瞭解的很透徹呢？很多事物對於我們來說都是個“黑盒”，你無法瞭解其中的緣由，但是你知道該怎麼使用它。你清楚中醫的原理嗎？我們的老祖宗還不是用它治病治了數千年；人也是一個“黑盒”，你如何得知你身邊都是什麼樣的人？還不是通過日常中很多事情來測試，瞭解他，讓你交到知心朋友，讓你能夠知人善用，帶好團隊；CEO選接班人，一定會讓候選人經歷不同的部門，通過順境、逆境來多方面測試，考察其在不同的環境中的表現，最後確定是否讓其上位；年終績效打好以後提交上去讓大老闆審批，大老闆如何審批？還不是通過設定的各個指標的內在關聯，整體比例等維度來對這份績效考評表進行測試的。這樣的例子舉不勝舉，生活處處皆測試，我們都是測試人。