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

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

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

一碌识、前言

我從事測試工作將近八年了，從起初的不懂測試浪南，懷疑測試浅役，到相信測試，再到堅定測試瞻凤，其中經(jīng)歷的辛酸憨攒、煎熬無法言表。在從事測試工作的這八年里鲫构，有人質(zhì)疑浓恶，也有人追捧玫坛，唇槍舌劍结笨，沒完沒了，貌似測試永遠都是個站在輿論風口浪尖的角色湿镀。本文乃在下之精血所作炕吸，是我對測試的高度概括，旨在幫助大家了解測試勉痴，新人可以更好地從事測試工作赫模，老人可以進行測試探討，交流思想蒸矛。為了盡量讓更多的人理解測試瀑罗，本文重在述道胸嘴，少說測試之術，相信看完之后斩祭，各位自有論斷劣像，功過是非留于各位看官說。

二摧玫、測試的萬能模型

為什么上來就談這個耳奕？測試的模型既是我對測試認知的高度建模，也是幫助大家理解測試诬像，理解我觀點的出發(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ā)思維的本質(zhì)區(qū)別）。是故惕虑，弄懂業(yè)務坟冲，理解產(chǎn)品需求是測試的前提磨镶。

也許有人會問，沒那么簡單吧健提，系統(tǒng)那么復雜琳猫，僅僅一個y= f(x)，怎么能全部歸納私痹？你這里只有一個請求脐嫂，一個響應，系統(tǒng)那是多復雜啊紊遵，數(shù)據(jù)庫账千，緩存，異步消息暗膜，日志等匀奏。這里得強調(diào)的是，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ù)功能推出每一個輸出的預期值”捺僻。

這里還要強調(diào)的一點是，這里的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)依賴如何？流程調(diào)用埃难，系統(tǒng)如何處理莹弊、交互？產(chǎn)生哪些反應涡尘？典型的輸入有：調(diào)用請求忍弛，讀DB數(shù)據(jù)，讀緩存數(shù)據(jù)考抄，被依賴系統(tǒng)的返回數(shù)據(jù)剧罩，收到的異步消息等；典型的輸出有：寫DB座泳，寫緩存惠昔，寫日志，調(diào)用依賴系統(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)的調(diào)用，哪些調(diào)用請求的傳參是合法的几颜？哪些是不合法的倍试？依賴方會傳回給你哪些可能的數(shù)據(jù)或者響應，最好有規(guī)范的接口文檔（可惜現(xiàn)在奇缺）蛋哭。
還需要县习，你對其它的輸入方式的數(shù)據(jù)類型有比較深刻的認識。針對我負責的系統(tǒng)谆趾，主要是前面兩個方面躁愿，當然根據(jù)不同的系統(tǒng)情況也有所不同，這個得具體問題具體分析沪蓬。
其次彤钟，當所有的x可能取值確定以后，這里就會利用專業(yè)的測試用例設計方法跷叉，對x1至xn的組合進行設計逸雹。設計方法有：等價類营搅，邊界值，因果圖梆砸，判定表转质，正交法等等，這些在很多的軟件測試書中都有詳細的介紹帖世，在此不作細表休蟹，有興趣的可以自行查閱。

3狮暑、x1至xn如何傳入SUT

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

部署被測系統(tǒng)，模擬客戶端發(fā)送請求驅(qū)動于毙；
直接依賴被測系統(tǒng)代碼敦冬，用本地代碼調(diào)用的方式驅(qū)動。
總體來說唯沮，“驅(qū)動”的方式就是兩種脖旱，跟語言無關，各種語言通用：
代碼驅(qū)動介蛉。這個沒什么好說的萌庆，就是把你SUT的代碼直接依賴過來，通過代碼直接調(diào)用的方式進行驅(qū)動币旧。
協(xié)議驅(qū)動践险。這個也包含廣義上的一些RPC調(diào)用，主要有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點的“驅(qū)動”邏輯雖然有代碼驅(qū)動和協(xié)議驅(qū)動示罗，而且協(xié)議驅(qū)動也有很多種惩猫，但是因為涉及到的是接口和協(xié)議，相對還是比較固定的蚜点，不容易發(fā)生變化轧房，非常適合將2、4做成應用绍绘。我們想象一下奶镶，如果有一個測試系統(tǒng)，能根據(jù)傳給它的數(shù)據(jù)陪拘，完成對各種SUT的測試厂镇，那豈不是測試工程師只要產(chǎn)出數(shù)據(jù)（測試用例）就行了。思路完全可行左刽，因為測試用例本質(zhì)上就是一個“描述捺信，”一個“用什么樣的數(shù)據(jù)，調(diào)用什么樣的流程欠痴，預期會產(chǎn)生什么樣的結果”的描述迄靠。這種描述可以是漢語，也可以是英文斋否，也可以是xml格式梨水，又或者是腳本，只要能描述清楚這種語義即可茵臭，只不過我們肯定需要對這種描述制定一些格式規(guī)范疫诽，保證測試系統(tǒng)能夠識別這種描述。這樣我們的測試系統(tǒng)就可以集用例管理旦委、測試執(zhí)行奇徒、Bug提交、測試報告于一身缨硝，成為測試中臺（不知道這個用詞對不對）的完美轉身摩钙。我大膽畫出這種測試系統(tǒng)的架構示意圖：

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

七、測試人員的價值

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

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

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

系統(tǒng)的多樣性可能會迷惑你的雙眼杂抽，正如人往往容易在這花花世界中迷失一般诈唬，認識不到什么才是真正值得追求的東西，什么才是真財富缩麸。有了上面的分析做鋪墊铸磅，這個就很簡單了，其實就是解決“驅(qū)動問題嘛”杭朱≡淖校總是有人對測試框架的搭建，測試環(huán)境的搭建產(chǎn)生畏懼弧械，弄懂了這個原理八酒，你就會變得一往無前，就兩種驅(qū)動嘛刃唐，萬變不離其宗羞迷，只是根據(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)了一個測試工程師的能力水平辱挥。
測試的維護和傳承飒责，這個是最容易造成勞動力浪費的地方》淞郑“寧可全部重寫也不愿改別人代碼”是工程師的通病签则，對于開發(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é)調(diào)能力卸亮。因為真的很難忽妒，主導權在PD、開發(fā)，作為最后一個環(huán)節(jié)的測試锰扶，有時候真的需要用一些溝通技巧献酗，和修煉出的人格魅力去說服和推進。

八坷牛、測試崗位性質(zhì)

總結來說罕偎，測試屬于軟件質(zhì)量把控的最后一環(huán)，測試的好壞直接決定了軟件質(zhì)量的好壞京闰。歷史上面不乏因為測試不力而造成重大損失的案例：如颜及，程序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)官帘，以至于很多測試人自己都會開始懷疑。這是由于對測試本質(zhì)認識不清造成的昧谊，測試有點像練內(nèi)家拳刽虹，很難修煉，甚至有人修煉三年都不得其門而入呢诬，這就不能責怪中途退場者甚眾涌哲，堅定信念者寥寥。一句話來說尚镰，懂測試的人太少了》Щ現(xiàn)在也有很多部門把測試人員強制轉成開發(fā)人員，試問真的行嗎狗唉？我從來不懷疑測試存在的價值初烘，也堅定地認為測試不可能被砍掉。試問那些強制把測試轉成開發(fā)的分俯，轉換后產(chǎn)品質(zhì)量如何肾筐？有多少是頂著開發(fā)title干著測試的活？當然我沒有詳細調(diào)查過澳迫，知道的人可以說說局齿。

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

十贸营、測試與生活

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