989
技術社區[雲棲]
測試之道--阿裏巴巴八年測試專家傾情奉獻
一、 前言
我從事測試工作將近八年了，從起初的不懂測試，懷疑測試，到相信測試，再到堅定測試，其中經曆的辛酸、煎熬無法言表。在從事測試工作的這八年裏，有人質疑，也有人追捧，唇槍舌劍，沒完沒了，貌似測試永遠都是個站在輿論風口浪尖的角色。本文乃在下之精血所作，是我對測試的高度概括，旨在幫助大家了解測試，新人可以更好地從事測試工作，老人可以進行測試探討，交流思想。為了盡量讓更多的人理解測試，本文重在述道，少說測試之術，相信看完之後，各位自有論斷，功過是非留於各位看官說。
二、 測試的萬能模型
為什麼上來就談這個？測試的模型既是我對測試認知的高度建模，也是幫助大家理解測試，理解我觀點的出發點，正所謂“風，生於地，起於青萍之末”，任何事情都是有本因的，大道至簡，理解了核心思想再看觀點，就有了論據，這正如修煉武功，根基決定了以後武術達到的高度，否則就如“無本之木，無源之水”，雖然我言之鑿鑿，但大家卻都不知吾之所雲。
佛家修煉有三個境界：看山是山，看水是水；看山不是山，看水不是水；看山還是山，看水還是水。從我對測試的經曆和認知來說非常吻合，起初開始做測試的時候感覺測試工作是無聊的，枯燥的，而且並沒有太大技術含量，以為這就是測試。但是隨著工作閱曆的增加，覺得測試越來越難，麵對各種被測係統，我真的無法用一種通用的方法，或者通用工具滿足所有的測試需求。於是開始拚命學習各種係統的實現，嚐試去了解我的被測係統。我測試過的係統有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選接班人，一定會讓候選人經曆不同的部門，通過順境、逆境來多方麵測試，考察其在不同的環境中的表現，最後確定是否讓其上位；年終績效打好以後提交上去讓大老板審批，大老板如何審批？還不是通過設定的各個指標的內在關聯，整體比例等維度來對這份績效考評表進行測試的。這樣的例子舉不勝舉，生活處處皆測試，我們都是測試人。
我愛測試，測試教會了我很多，教會了我業務，教會了我技術，更重要的是教會了我全局的結構化思維能力，和對事物本因的思考方式，教會了我如何做好管理，教會了我如何做人。
看我辛辛苦苦寫了這麼多，最後的最後，容我打個小廣告吧，歡迎跟我誌同道合的，或有相同感觸的，或喜歡練太極的，或喜歡悟道的找我，我們來（轉）往（崗）吧！
ps：本文轉自阿裏巴巴技術專家雷藏博客。 如有興趣加入他的團隊，可直接發簡曆至leizang.cs@taobao.com勾搭！或者底部留言，小編可內推哦。
阿裏雲測移動質量中心（以下簡稱MQC）是為廣大企業客戶和移動開發者提供真機測試服務的雲平台，擁有大量熱門機型，提供7x24全天候服務。
我們致力於提供專業、穩定、全麵、高價值的自動化測試能力，以及簡單易用的使用流程、貼心的技術服務，並且幫助客戶以最低的成本、最高的效率發現APP中的各類隱患（APP崩潰、各類兼容性問題、功能性問題、性能問題等），減少用戶流失，提高APP質量和市場競爭力。
聯係我們：
網站地址：https://mqc.aliyun.com
開發者交流旺旺群：335334143
開發者交流QQ群：492028798
客服郵箱：mqc_group@service.alibaba.com；
更多精彩技術分享 歡迎關注 MQC公眾號
最後更新：2017-08-13 22:42:17