沖天香陣透長安、滿城盡帶黃金甲

---黃巢《不第后賦菊》

轉自：阿里測試之道，******https://testerhome.com/topics/9640

一、前言

我從事測試工作將近八年了，從起初的不懂測試，懷疑測試，到相信測試，再到堅定測試，其中經(jīng)歷的辛酸、煎熬無法言表。在從事測試工作的這八年里，有人質疑，也有人追捧，唇槍舌劍，沒完沒了，貌似測試永遠都是個站在輿論風口浪尖的角色。本文乃在下之精血所作，是我對測試的高度概括，旨在幫助大家了解測試，新人可以更好地從事測試工作，老人可以進行測試探討，交流思想。為了盡量讓更多的人理解測試，本文重在述道，少說測試之術，相信看完之后，各位自有論斷，功過是非留于各位看官說。

二、測試的萬能模型

為什么上來就談這個？測試的模型既是我對測試認知的高度建模，也是幫助大家理解測試，理解我觀點的出發(fā)點，正所謂“風，生于地，起于青萍之末”，任何事情都是有本因的，大道至簡，理解了核心思想再看觀點，就有了論據(jù)，這正如修煉武功，根基決定了以后武術達到的高度，否則就如“無本之木，無源之水”，雖然我言之鑿鑿，但大家卻都不知吾之所云。

佛家修煉有三個境界：看山是山，看水是水；看山不是山，看水不是水；看山還是山，看水還是水。從我對測試的經(jīng)歷和認知來說非常吻合，起初開始做測試的時候感覺測試工作是無聊的，枯燥的，而且并沒有太大技術含量，以為這就是測試。但是隨著工作閱歷的增加，覺得測試越來越難，面對各種被測系統(tǒng)，我真的無法用一種通用的方法，或者通用工具滿足所有的測試需求。于是開始拼命學習各種系統(tǒng)的實現(xiàn)，嘗試去了解我的被測系統(tǒng)。我測試過的系統(tǒng)有java開發(fā)的，也有C++開發(fā)的，也有其它語言開發(fā)的，于是我對各種語言都有一定了了解，開始研究如何測試他們。隨著光陰流逝，對測試認識的逐步加深，我發(fā)現(xiàn)所有的測試理念都是相通的，漸漸的，我悟出了萬能的測試模型：y= f(x)。對，你沒看錯，就是我們所學的函數(shù)表達式。

[圖片上傳失敗...(image-2fac75-1648525270975)]

x是我們的輸入，y是f(x)的輸出，f(x)表示的是被測系統(tǒng)的功能。測試的思路就是：選擇適當?shù)膞，代入f(x)，得到y(tǒng)，跟我的預期結果y’進行對比，從而得出被測流程是pass還是fail。用圖表示：

對于測試人員來說SUT（System Under Test，被測系統(tǒng)）是個黑盒，測試人員一般不太會關注f(x)的具體實現(xiàn)邏輯，只會關注f(x)的功能。比如，假設f(x)= 2^x，程序可以用“x個2相乘”實現(xiàn)，也可以用“左移位”的方法實現(xiàn)，作為測試人員關注點只在于“有沒有正確實現(xiàn)需求？”，“功能滿足后性能如何？有沒有安全問題？”，關注點不在“怎么實現(xiàn)”，而在“實現(xiàn)的怎么樣”上面（這也是測試思維跟開發(fā)思維的本質區(qū)別）。是故，弄懂業(yè)務，理解產(chǎn)品需求是測試的前提。

也許有人會問，沒那么簡單吧，系統(tǒng)那么復雜，僅僅一個y= f(x)，怎么能全部歸納？你這里只有一個請求，一個響應，系統(tǒng)那是多復雜啊，數(shù)據(jù)庫，緩存，異步消息，日志等。這里得強調的是，x，y表示的絕不僅僅是request和response，而是廣義的輸入和輸出，什么區(qū)別？request和response只是輸入輸出的一種，對于SUT來說，只要是讀的數(shù)據(jù)都算輸入，比如：用戶登陸的功能，當我填入一個用戶名進行登錄時，我的輸入除了在頁面上填入的“用戶名”和“密碼”，DB中也必須有這條用戶記錄（當然用戶不存在也是一種測試場景），所以DB中的這條用戶記錄也算輸入，甚至如果登錄系統(tǒng)處理過程中去查詢安全系統(tǒng)，安全系統(tǒng)返回的“用戶安全策略”也算輸入。所以，這里的輸入是廣義的輸入，包含了用戶頁面填入的“用戶名/密碼”，DB中的“用戶記錄”，安全返回的“用戶安全策略”等。同理，輸出也是廣義的，包括“DB的寫”，“對其它系統(tǒng)的請求”，“打印的日志”，“對緩存的put”，“發(fā)出的異步消息”等。于是我們的測試萬能公式可以進化成下面的樣子：y1,y2,y3,…,yn= f(x1,x2,x3,…,xn)。我們測試工作其實就是確定每一個x的取值范圍，然后選用合適的x1到xn的組合數(shù)據(jù)（一組數(shù)據(jù)其實就是一個測試用例），代入f，然后將得到的y1…yn跟預期的y1’…yn’進行比較，從而判斷被測場景的正確性。用圖表示：

所以，一個合格的測試，必須理清“SUT的功能”，“SUT的所有輸入”，“每一個輸入的取值范圍”，“SUT的所有輸出”，“根據(jù)功能推出每一個輸出的預期值”。

這里還要強調的一點是，這里的SUT是很有講究的，在我看來除了靜態(tài)走讀代碼的方式算是白盒測試外，其它的一切測試都算黑盒，只是這個“盒子”的大小不同而已。單元測試中“盒子”比較小，就是一個或者若干個方法；接口測試的“盒子”就會擴大到應用級別；集成測試的“盒子”就會擴大到系統(tǒng)級別。
弄懂了測試的模型，就可以開始剖析測試各個的關鍵點。

三、測試的目的

測試的目的就是規(guī)避Bug。為什么用“規(guī)避”而不是“找”？因為對于所有的測試用例來說，并不是每一條都能測出Bug，對于沒能測出Bug的用例執(zhí)行，你能說測試工作沒有價值嗎？顯然不能，對于測試人員來說，在未執(zhí)行測試之前，假設的前提是所有的被測流程都處于未知狀態(tài)，只有執(zhí)行完對應的測試用例這個流程狀態(tài)才變得可知——pass或者fail，對于fail的測試用例我們是找到了Bug，而對于pass的測試用例我們沒有也不可能找到Bug，所以不管pass還是fail，測試執(zhí)行工作都是有價值的，這里只能用“規(guī)避Bug”來精確地闡述測試工作的目的。

四、測試的步驟

再來看一下測試的模型圖：

[圖片上傳失敗...(image-8557f3-1648525270975)]

如前面所述，測試工作其實就是確定每一個x的取值范圍，然后選用合適的x1到xn的組合數(shù)據(jù)（一組數(shù)據(jù)其實就是一個測試用例），代入f，然后將得到的y1…yn跟預期的y1’…yn’進行比較，從而判斷被測場景的正確性。由此可以總結出，測試工作步驟就是：

“確定x1至xn的組合數(shù)據(jù)”
“將每組數(shù)據(jù)傳入SUT”
“根據(jù)需求確定每組輸入數(shù)據(jù)輸入后產(chǎn)生的預期輸出結果y1’至yn’”
“將預期結果和實際結果y1,y2,…,yn進行比對，從而得出結論”

五、測試的難點

對于上面四步，第3點和第4點相對容易，測試的主要難點在于第1點和第2點：

1、如何找齊所有的x和y？

想要找齊所有的x和y，就必須要求你對系統(tǒng)非常熟悉，對流程非常熟悉。系統(tǒng)依賴如何？流程調用，系統(tǒng)如何處理、交互？產(chǎn)生哪些反應？典型的輸入有：調用請求，讀DB數(shù)據(jù)，讀緩存數(shù)據(jù)，被依賴系統(tǒng)的返回數(shù)據(jù)，收到的異步消息等；典型的輸出有：寫DB，寫緩存，寫日志，調用依賴系統(tǒng)的請求，發(fā)出的異步消息等。所以這個需要你對你的被測系統(tǒng)和流程必須非常非常的熟悉。

2、如何確定合適的x1至xn的組合？

首先，你要熟悉每個x的可能取值，除了正常值，還有異常值，這個對測試工程師的要求非常高。為了清楚所有x的可能取值：

不僅需要，你對業(yè)務、業(yè)務數(shù)據(jù)非常非常的熟悉。注意，這里我把“業(yè)務”和“業(yè)務數(shù)據(jù)”分開，指的是兩個不同的東西。“業(yè)務”指的是產(chǎn)品提供的功能，比如：登錄可以用賬密登錄，也可以用手機掃碼登錄。“業(yè)務數(shù)據(jù)”指的是產(chǎn)品在線上日以繼夜的運行后產(chǎn)生的數(shù)據(jù)，如，注冊功能，有通過淘寶注冊的淘寶用戶，也有通過支付寶注冊的支付寶用戶，甚至還有數(shù)據(jù)打通從其它地方同步過來的其它用戶數(shù)據(jù)，你要對這些個業(yè)務數(shù)據(jù)非常熟悉。
還需要，你要對系統(tǒng)間依賴的接口非常熟悉。這個主要是為了弄清楚你的SUT對依賴系統(tǒng)的調用，哪些調用請求的傳參是合法的？哪些是不合法的？依賴方會傳回給你哪些可能的數(shù)據(jù)或者響應，最好有規(guī)范的接口文檔（可惜現(xiàn)在奇缺）。
還需要，你對其它的輸入方式的數(shù)據(jù)類型有比較深刻的認識。針對我負責的系統(tǒng)，主要是前面兩個方面，當然根據(jù)不同的系統(tǒng)情況也有所不同，這個得具體問題具體分析。
其次，當所有的x可能取值確定以后，這里就會利用專業(yè)的測試用例設計方法，對x1至xn的組合進行設計。設計方法有：等價類，邊界值，因果圖，判定表，正交法等等，這些在很多的軟件測試書中都有詳細的介紹，在此不作細表，有興趣的可以自行查閱。

3、x1至xn如何傳入SUT

這個用一個詞來精準形容就是“驅動”，如何驅動你的測試流程？其實這個很體現(xiàn)測試工程師的水平。如果你用的是手工測試，那肯定得搭建測試環(huán)境，必須讓你的SUT運行起來，然后預置各種數(shù)據(jù)，調用你的流程。如果你是自動化測試，這里其實是有兩種方式：

部署被測系統(tǒng)，模擬客戶端發(fā)送請求驅動；
直接依賴被測系統(tǒng)代碼，用本地代碼調用的方式驅動。
總體來說，“驅動”的方式就是兩種，跟語言無關，各種語言通用：
代碼驅動。這個沒什么好說的，就是把你SUT的代碼直接依賴過來，通過代碼直接調用的方式進行驅動。
協(xié)議驅動。這個也包含廣義上的一些RPC調用，主要有http，https，ftp，telnet，hsf，dubbo等。

六、測試系統(tǒng)理念的提出

如前面所述，測試工作的步驟就是：

確定x1至xn的組合數(shù)據(jù)
將每組數(shù)據(jù)傳入SUT
根據(jù)需求確定每組輸入數(shù)據(jù)輸入后產(chǎn)生的預期輸出結果y1’至yn’
將預期結果和實際結果y1,y2,…,yn進行比對，從而得出結論
我們對上述步驟的產(chǎn)出進行分析，1、3兩點產(chǎn)出的是“數(shù)據(jù)”，2、4兩點產(chǎn)出的是“邏輯”。第4點的邏輯非常固定，就是預期輸出結果和實際輸出結果的比對邏輯，而第2點的“驅動”邏輯雖然有代碼驅動和協(xié)議驅動，而且協(xié)議驅動也有很多種，但是因為涉及到的是接口和協(xié)議，相對還是比較固定的，不容易發(fā)生變化，非常適合將2、4做成應用。我們想象一下，如果有一個測試系統(tǒng)，能根據(jù)傳給它的數(shù)據(jù)，完成對各種SUT的測試，那豈不是測試工程師只要產(chǎn)出數(shù)據(jù)（測試用例）就行了。思路完全可行，因為測試用例本質上就是一個“描述，”一個“用什么樣的數(shù)據(jù)，調用什么樣的流程，預期會產(chǎn)生什么樣的結果”的描述。這種描述可以是漢語，也可以是英文，也可以是xml格式，又或者是腳本，只要能描述清楚這種語義即可，只不過我們肯定需要對這種描述制定一些格式規(guī)范，保證測試系統(tǒng)能夠識別這種描述。這樣我們的測試系統(tǒng)就可以集用例管理、測試執(zhí)行、Bug提交、測試報告于一身，成為測試中臺（不知道這個用詞對不對）的完美轉身。我大膽畫出這種測試系統(tǒng)的架構示意圖：

目前我正在這個方面做一些研究，也有一些實質性的產(chǎn)出（驅動模塊和用例管理模塊），但還待琢磨完善，如果有人有興趣的也歡迎一起探討。

七、測試人員的價值

常常被人問起，測試人員的核心價值是什么？跟PD、開發(fā)比區(qū)別是什么？如果沒有經(jīng)過上面的一系列分析，被人炸一問起還真不好回答。可是今天就不一樣了，今天我就談一下自己認識的測試人員的核心價值。這些是每個測試Leader必須清楚的東西，否則你如何給你團隊的成長指明方向，為你的組員答疑解惑授業(yè)？

測試的核心價值就是：對于任何被測系統(tǒng)，能夠全面、高效地規(guī)避Bug——發(fā)現(xiàn)、定位、解決。注意，這里有四個要素：任何被測系統(tǒng)，全面，高效，Bug

1、要素一、任何被測系統(tǒng)

系統(tǒng)的多樣性可能會迷惑你的雙眼，正如人往往容易在這花花世界中迷失一般，認識不到什么才是真正值得追求的東西，什么才是真財富。有了上面的分析做鋪墊，這個就很簡單了，其實就是解決“驅動問題嘛”?？偸怯腥藢y試框架的搭建，測試環(huán)境的搭建產(chǎn)生畏懼，弄懂了這個原理，你就會變得一往無前，就兩種驅動嘛，萬變不離其宗，只是根據(jù)不同的語言略有差異而已，但是我們都已經(jīng)看到明燈的方向了還會恐懼嗎？

2、要素二、全面

這個其實就是測試用例的設計問題。這個上面已經(jīng)分析的很清楚了不在贅述，請參看上面x1,x2,…,xn組合數(shù)據(jù)的設定。

3、要素三、高效

這個主要體現(xiàn)在三個方面：數(shù)據(jù)準備服務，自動化測試，測試的維護和傳承。

目前做的最多的也是最成熟的就是數(shù)據(jù)準備服務，基本上每個產(chǎn)品線都有自己的數(shù)據(jù)準備工具，如，數(shù)據(jù)工廠，TAP等。
自動化測試也是提升測試效率的主要手段，但是手工測試是不可完全被取代的。自動化測試有其適用場景：手工無法測試；功能穩(wěn)定不容易變動；頻繁回歸。即使不可全部自動化，也要想辦法進行半自動化，半自動不行就1/4自動化。總之，條件允許我們要自動化，條件不允許我們創(chuàng)造條件也要自動化，將一切可以讓電腦干的事情堅決不能讓人來干，所以，自動化的程度也體現(xiàn)了一個測試工程師的能力水平。
測試的維護和傳承，這個是最容易造成勞動力浪費的地方?！皩幙扇恐貙懸膊辉父膭e人代碼”是工程師的通病，對于開發(fā)工程師來說這個問題還好一點，畢竟你不能單獨開一個應用，還得在原來的應用中去改，但是對于測試工程師來說，這個問題暴露的尤為嚴重。測試腳本的獨立性決定了每個人寫出的自動化腳本風格都不一樣，一旦換人，后來的人是能自己寫的就堅決不維護別人寫的腳本。對于自己寫的代碼還能做到一些復用和擴展，但也很難讓別人來復用你的代碼，再換人了繼續(xù)惡性循環(huán)。究根結底，測試腳本沒有統(tǒng)一的規(guī)劃，不僅沒有統(tǒng)一風格，也沒有統(tǒng)一架構，確實需要也很必要制定一些腳本編碼規(guī)范，規(guī)劃一下測試腳本的架構，讓測試腳本做到可維護，可復用，可擴展，并沉淀一些測試的服務供測試使用。另一方面，剛畢業(yè)的人在寫腳本，工作干了五六年的也在寫腳本，不信你去看，這兩者寫出來的腳本還是有很大差距的。剛寫腳本的人會把所有的邏輯放在一個testcase里，而一個老手就有了一定的架構意識，該抽象的抽象，該封裝的封裝。所以，對測試腳本的統(tǒng)一規(guī)劃，也為測試新人提供了成長的方向，有利于測試新人的迅速成長。另一個思路就是用上面說的“測試系統(tǒng)”來解決這個問題，大家只要按照固定的規(guī)范編寫用例，測試執(zhí)行的事情交給系統(tǒng)去做，這個應該是最完美地解決傳承問題的解決方案，但前提是“測試系統(tǒng)”需要足夠的穩(wěn)定、強大。

4、要素四、bug

什么是Bug？只要不能滿足預期的東西都可以稱之為Bug。所以，Bug也是廣義的Bug，可以分為功能Bug，性能Bug，安全Bug，甚至流程Bug。對于一個Bug，優(yōu)秀的測試工程師要能夠定位Bug原因，并給出解決方案。
對于功能性Bug，沒什么好說的，測試工程師的大部分時間都花在了這里。Bug定位的方法，主要的手段就是看日志，Debug。

對于非功能性Bug，就有點復雜了，不能一概而論，但還是有方法的。如性能測試中，發(fā)現(xiàn)程序卡住了，你會猜測是否出現(xiàn)了線程死鎖，對于java應用，你需要使用一些jvm工具去查看線程堆棧，根據(jù)線程狀態(tài)做出判斷。只要掌握了一些非功能性Bug的定位方法，定位起來也是有跡可循，最后做到游刃有余的。Bug的定位和解決考驗的不僅是測試人員的技術深度，更是知識的廣度，所以這一點也是判斷一個測試工程師能力水平的重要方面。
另外，對于一些流程上面的問題，考驗的又是測試工程師的溝通、協(xié)調能力。因為真的很難，主導權在PD、開發(fā)，作為最后一個環(huán)節(jié)的測試，有時候真的需要用一些溝通技巧，和修煉出的人格魅力去說服和推進。

八、測試崗位性質

總結來說，測試屬于軟件質量把控的最后一環(huán)，測試的好壞直接決定了軟件質量的好壞。歷史上面不乏因為測試不力而造成重大損失的案例：如，程序bug導致了天大的損失，要槍斃程序猿嗎？同時，測試又是一個支撐型的崗位，雖然它不直接產(chǎn)出代碼，但對測試人員的要求不但不低，而且還非常之高，很多業(yè)界的測試大牛都是先成為開發(fā)大牛以后再轉成測試的，邏輯很簡單，因為一個人的能力達到很高的水平以后，如何把自己的能力復制給別人就成了一門學問，最簡單直接的辦法是，去評估別人的代碼，指出別人代碼、架構的問題。測試是一個入門簡單，越做越難，甚至最后對人的要求高到極為苛刻的地步。測試的管理也是非常難做工作，現(xiàn)實中大家負責的都是不同的需求，你很難去評判兩個測試工程師之間的優(yōu)劣，因為測試的深度體現(xiàn)在思想上，也許你可以從測試用例上面去找到一點蛛絲馬跡，又或從溝通中去尋找，又或從發(fā)現(xiàn)的Bug上做參考，又或從線上產(chǎn)生的故障上面去找。

九、說一說測試的現(xiàn)狀

測試是個很容易被人誤解的一份工作，測試工作本身的復雜性和綜合性，決定了測試人員的成長不如單維度作戰(zhàn)的開發(fā)、PD快，以至于讓很多人對測試崗位產(chǎn)生誤解，也就不能責怪時不時興起的“我們需不需要專職QA”的口水戰(zhàn)，以至于很多測試人自己都會開始懷疑。這是由于對測試本質認識不清造成的，測試有點像練內家拳，很難修煉，甚至有人修煉三年都不得其門而入，這就不能責怪中途退場者甚眾，堅定信念者寥寥。一句話來說，懂測試的人太少了?，F(xiàn)在也有很多部門把測試人員強制轉成開發(fā)人員，試問真的行嗎？我從來不懷疑測試存在的價值，也堅定地認為測試不可能被砍掉。試問那些強制把測試轉成開發(fā)的，轉換后產(chǎn)品質量如何？有多少是頂著開發(fā)title干著測試的活？當然我沒有詳細調查過，知道的人可以說說。

測試工作的開展需要規(guī)范的合作流程，對于管理不嚴謹?shù)拈_發(fā)流程，測試工作的開展就顯得處處掣肘。阿里是個以結果為導向的公司，很多團隊對過程都疏于管理：項目延期對績效無影響；只要線上不出大故障，即使小故障不斷對績效也無影響；發(fā)布出故障又怎么樣，大不了回滾嘛。在這樣的環(huán)境里，開發(fā)的質量意識也達到了低谷，各種評審省掉，各種評審不叫測試，各種開發(fā)完了來找測試驗證一下，各種壓縮測試時間，甚至我遇到過項目經(jīng)理的項目計劃中竟然沒有測試計劃，開發(fā)完成還死活不肯提測（因為過不了冒煙），再加上鼓吹開發(fā)自測，開發(fā)完全可以繞過測試，自己隨便測測，發(fā)布代碼上線，出現(xiàn)問題了，再來找測試回歸。通過歷史經(jīng)驗來看，出現(xiàn)過幾次嚴重的大故障，大部分都是繞過測試，或者開發(fā)自測造成的。

十、測試與生活

生活又何嘗不是如此，試想生活中我們對什么東西是了解的很透徹呢？很多事物對于我們來說都是個“黑盒”，你無法了解其中的緣由，但是你知道該怎么使用它。你清楚中醫(yī)的原理嗎？我們的老祖宗還不是用它治病治了數(shù)千年；人也是一個“黑盒”，你如何得知你身邊都是什么樣的人？還不是通過日常中很多事情來測試，了解他，讓你交到知心朋友，讓你能夠知人善用，帶好團隊；CEO選接班人，一定會讓候選人經(jīng)歷不同的部門，通過順境、逆境來多方面測試，考察其在不同的環(huán)境中的表現(xiàn)，最后確定是否讓其上位；年終績效打好以后提交上去讓大老板審批，大老板如何審批？還不是通過設定的各個指標的內在關聯(lián)，整體比例等維度來對這份績效考評表進行測試的。這樣的例子舉不勝舉，生活處處皆測試，我們都是測試人。