軟件測試學習體會Vol34

1、軟件測試學習體會Vol 34中間件的核心功能測試內(nèi)容分析目前，市場上常用的中間類型有交易中間件、消息中間件和應用服務器。本文主要對這三類中間的核心功能測試內(nèi)容及指標作相應分析。一、交易中間件測試內(nèi)容：1、名字服務：測試中間件對透明的名字服務的支持和正確性2、負載均衡：測試中間件對自動在系統(tǒng)中完成負載平衡的支持和正確性3、請求優(yōu)先權：測試中間件對服務請求優(yōu)先級的支持和正確性4、可用性支持：測試中間件對進程可用性檢查、超時檢查等可用性支持和正確性，保證應用運行環(huán)境穩(wěn)定5、安全性：測試中間件對保證應用服務安全運行和數(shù)據(jù)傳輸加密的支持和正確性6、動態(tài)配置：測試中間件對動態(tài)重配置節(jié)點和參數(shù)的支持和正確性

2、7、分布式事務處理：測試對跨多個數(shù)據(jù)源、數(shù)據(jù)源異構(gòu)異地的事務，中間件提供保證其數(shù)據(jù)完整性的支持和正確性8、交易通信機制：測試中間件對同步、異步和會話等交易通訊模式的支持和正確性9、交易運行模式：測試中間件對一階段提交、兩階段提交、請求轉(zhuǎn)發(fā)和請求嵌套等交易模式的支持和正確性10、隊列服務：測試中間件對應用請求回答隊列及其LIFO、FIFO、用戶定義的出隊和原始的ATMI調(diào)用特性隊機制的支持和正確性二、消息中間件核心測試內(nèi)容1、通信服務：測試中間件對端到端實時通信的支持和正確性2、同步傳輸服務：測試中間件對端到端同步傳輸服務的支持和正確性3、異步傳輸服務：測試中間件對端到端異步傳輸服務的支持和正確

3、性4、應用編程接口API支持：測試中間件對各種應用編程借口API(如C/C+、JAVA、COM、IDL)的支持和正確性5、安全性：測試中間件對保證應用服務安全運行和數(shù)據(jù)傳輸加密的支持和正確性6、可靠性：中間件是否具有髙可用性、有效的狀態(tài)恢復機制和自動故障切換功能，始終保持其基礎框架處于應用狀態(tài)，保證系統(tǒng)能夠自動進行故障切換，并有效兼容應用系統(tǒng)和人為操作的錯誤。7、軟件的可管理性及其易用性：測試中間件是否提供統(tǒng)一集成管理環(huán)境，能夠?qū)崿F(xiàn)從底層平臺到業(yè)務應用的統(tǒng)一管理；是否提供多種管理方式，如支持Web、命令行和控制臺方式的管理監(jiān)控；是否提供豐富的部署和管理工具及友好的用戶界面。8、可擴展性：測試中

4、間件是否支持SOA等先進的體系架構(gòu)，支持JMX、JMS、J2CA、WebService等集成標準；由其構(gòu)成的核心功能是否可擴展，是否提供服務總線，以插件式的方式不斷延伸內(nèi)核功能，并集成其他的組件、應用、服務，使之在現(xiàn)有或遺留系統(tǒng)之上或之外增加新的功能模塊，并能與原有系統(tǒng)無縫集合。9、處理效率：是否提供集群的負載均衡技術、支持大規(guī)模并發(fā)客戶數(shù)量并保證效率10、分布式事務處理：測試對跨多個數(shù)據(jù)源、數(shù)據(jù)源異構(gòu)異地的事務，中間件提供保證其數(shù)據(jù)完整性的支持和正確性11、集群和隊列服務：測試中間件對集群、優(yōu)先級消息隊列、先進先出消息隊列的支持和正確性12、兼容性：是否支持各種硬件；能否在目前流行的Wind

5、ows、Unix、Linux等操作系統(tǒng)上應用；能否有效支持目前流行的Oracle、DB2、Sybase、SQL Server等多種數(shù)據(jù)庫13、對標準規(guī)范的支持：測試中間件對目前流行的J2EE、.NET、CORBA、WEBSERVICE、XML、HTTP等標準的支持程度14、對多語言的支持：測試中間件對多語言的支持和正確性三、應用服務器測試內(nèi)容1、功能測試：測試應用服務器是否符合企業(yè)級的J2EE標準2、性能測試：測試在大壓力和大數(shù)據(jù)量情況下，應用服務器最大處理能力和系統(tǒng)響應時間，同時測試不同壓力情況下應用服務器處理能力和系統(tǒng)響應時間3、兼容性測試：是否支持各種硬件配置；是否支持系統(tǒng)兼容性、數(shù)據(jù)庫

6、兼容性、Web服務器兼容性、研發(fā)工具兼容性、和其他中間件產(chǎn)品的兼容性、J2EE組件的兼容性等多個方面4、可靠性測試：測試應用范圍器在大壓力和大數(shù)據(jù)量情況下系統(tǒng)的穩(wěn)定性，連同驗證系統(tǒng)的SSL認證加密機制是否有效等多個方面5、安全性測試：測試應用服務器用戶權限限制、輸入數(shù)據(jù)有效性檢查等內(nèi)容=分割線=分割線=測試進度和成本的控制項目的進度管理是一門藝術，是一個動態(tài)的過程，需要不斷調(diào)度、協(xié)調(diào)，保證項目的均衡發(fā)展，實現(xiàn)項目整體的動態(tài)平衡。項目開始前的計劃，對任務的測試需求有一個大體的認識，但深度不夠，進度表可能只是一個時間上的框架，其中一定程度上是靠計劃制定者的經(jīng)驗來把握的。隨著時間的推移、測試的不斷深

7、入，對任務會有進一步的認識，對很多問題都不再停留在比較粗的估算上，項目進度表會變得越來越詳細、越準確。項目的進度管理主要通過里程碑、關鍵路徑的控制并借助工具來實現(xiàn)，同時要把握好進度與質(zhì)量、成本的關系，以及充分了解進度的數(shù)量和質(zhì)量的雙重特性。1.進度的數(shù)量和質(zhì)量的雙重特性任何一項工作，最開始總是很容易看到進度，就比如蓋房子，從無到有，變化是很明顯的。可是越到后來，它的進度越來越不明顯。軟件測試也是如此，開始測試之初，Bug比較容易發(fā)現(xiàn)，但測試的進展并不是按Bug的數(shù)量來計算的，越到后面，Bug越來越難發(fā)現(xiàn)。要提高測試進度的質(zhì)量，將嚴重的、關鍵的問題在第一時間發(fā)現(xiàn)出來，這樣才不至于在最后階段使得開

8、發(fā)人員要對代碼做大規(guī)模的變動，無法保證測試的時間，從而影響軟件的質(zhì)量。這就是測試項目進度的數(shù)量和質(zhì)量的雙重特性，我們在關注進度的同時要把握好這兩個特性，在注重進度速度的同時，還要看進度前期的質(zhì)量。2.測試進度的管理方法首先，盡量利用歷史數(shù)據(jù)，從以前完成過的項目來進行類比分析，以確定質(zhì)量和進度所存在的某種數(shù)量關系，來控制進度和管理質(zhì)量?？梢圆捎脤M度管理計劃添加質(zhì)量參數(shù)的方法，也就是通過參數(shù)調(diào)整進度和質(zhì)量的關系。其次，可以采用測試項目進度的度量方法：測試進度S曲線法和缺陷跟蹤曲線法。在進度壓力之下，被壓縮的時間通常是測試時間，這導致實際的進度隨著時間的推移，與最初制定的計劃相差越來越遠。而如果有

9、了正式的度量方法，這種情況就很難出現(xiàn)，因為在其出現(xiàn)之前就有可能采取了行動。=分割線=分割線=為何要從開發(fā)轉(zhuǎn)向測試(由暗澗幽火那年我從開發(fā)轉(zhuǎn)向了測試，其實沒有什么原因，只是愛好，愛好測試，喜歡測試！所以就從開發(fā)轉(zhuǎn)向了測試，就這么簡單，這么干脆！可是在我面試測試崗位的期間，幾乎好幾家公司的面試官都問我的第一個問題就是：為什么要從開發(fā)轉(zhuǎn)向測試?，當時也悶過。因為之前壓根沒有思考過這個問題！三秒鐘過后我是這么回答的：我的技術不過關，不能勝任開發(fā)崗位的工作！，我是吱吱唔唔的并且聲音壓的很底，是心虛還是因為別的?傷感??！糾結(jié)??！明顯自己把自己看低了，好像測試的技術含量總比開發(fā)的技術含量低很多，或者幾乎可以

10、說沒有什么技術含量。那時的我是這么認為的，可能面試官也這么認為的！其實我之前做JAVA開發(fā)也兩年了，曾獨立完成幾個大模塊的開發(fā)工作，事實并不是自己說的那樣。為了能應聘上這份工作，我只能這么說。因為我知道面試官是做開發(fā)的！開發(fā)人員一向自我感覺良好，認為自己是牛人，當然最喜歡聽的就是別人說自己的技術很爛！想抬高面試官，讓面試官知道自己在這么個高深技術領域有今天的成就不容易??！我應該敬仰才是！果然面試官會心的笑了說：很誠實嘛小伙子，明天來報道吧！我當時很開心，雖不是第一份工作，但畢竟是第一次嘗試的崗位！后來在工作上也特別的努力，這里省去1000字！從開發(fā)轉(zhuǎn)向測試，應該說基礎是非常好的，至少以后做單元

11、測試、集成測試會有一定的優(yōu)勢。要完成這種工作的轉(zhuǎn)變，首先要了解測試的基本理論、基本方法和適合自己項目的測試工具。比如：黑盒測試案例設計技術，白盒測試技術，面向?qū)ο蟮能浖y試技術，web應用測試，網(wǎng)絡測試，安全測試知識，應用負載壓力測試工具LoadRunner，自動化測試工具QTP等等！其次要完成思維方式的轉(zhuǎn)變，測試和開發(fā)的思維方式是完全不一樣的。開發(fā)人員可能只想著實現(xiàn)一個功能，但測試人員不僅僅想著這個功能可用，還要考慮這個功能是否符合客戶要求，是否美觀，是否需要優(yōu)化使之更加完美！另外軟件開發(fā)人員可能更關注于自己負責模塊的實現(xiàn)，對于軟件的整體關注不會那么多，而測試人員更需要從全系統(tǒng)的角度整體的來

12、看問題，了解可以從哪些方面去評價一個軟件的質(zhì)量，逐漸轉(zhuǎn)換自己看問題的角度。最后要逐漸建立從客戶角度看問題的方式。在測試崗位工作了一段時間后，回頭再思考這個問題，我想這可能與我的性格有關吧?我認為軟件測試人員需要有耐心，細心，并且喜歡追求完美的那種，我的性格比較適合！軟件開發(fā)需要有想象力，我比較欠缺，所以不喜歡開發(fā)工作。本人一貫主張：做自己喜歡做的事情，才能在工作中真正的體會到工作帶給自己的樂趣！才會熱愛工作。在自己喜歡的崗位上才能有所收獲！做了開發(fā)后再做測試，才發(fā)現(xiàn)我更喜歡測試，喜歡找到錯誤的感覺，雖然我很喜歡代碼但是我更喜歡去找BUG。雖然測試的過程比開發(fā)的過程更無趣而且要很反復地工作，但對

13、于我這種有耐心和細心，追求完美性格的人來說也是一件樂事！為什么要從開發(fā)轉(zhuǎn)向測試?，不想再回答這樣的問題了！還是堅持己見：做自己喜歡做的事情！從開發(fā)轉(zhuǎn)向測試，就這么簡單，這么干脆！=分割線=分割線=分布式程序的自動化回歸測試本文所談的測試全部指的是開發(fā)者測試/developer testing，由程序員自己來做，不是由QA團隊進行的系統(tǒng)測試。這兩種測試各有各的用途，不能相互替代。我在樸實的C+設計一文中談到為了確保正確性，我們另外用Java寫了一個測試夾具(test harness)來測試我們這個C+程序。這個測試夾具模擬了所有與我們這個C+程序打交道的其他程序，能夠測試各種正?；虍惓５那闆r?；?/p>

14、本上任何代碼改動和bug修復都在這個夾具中有體現(xiàn)。如果要新加一個功能，會有對應的測試用例來驗證其行為。如果發(fā)現(xiàn)了一個bug，先往夾具里加一個或幾個能復現(xiàn)bug的測試用例，然后修復代碼，讓測試通過。我們積累了幾百個測試用例，這些用例表示了我們對程序行為的預期，是一份可以運行的文檔。每次代碼改動提交之前，我們都會執(zhí)行一遍測試，以防低級錯誤發(fā)生。今天把test harness這個做法仔細說一說。自動化測試的必要性我想自動化測試的必要性無需贅言，自動化測試是absolutely good stuff。基本上，要是沒有自動化的測試，我是不敢改產(chǎn)品代碼的(改包括添加新功能和重構(gòu))。自動化測試的作用是把程序

15、已經(jīng)實現(xiàn)的features以test case的形式固化下來，將來任何代碼改動如果破壞了現(xiàn)有的功能需求就會觸發(fā)測試failure。好比DNA雙鏈的互補關系，這種互補結(jié)構(gòu)對保持生物遺傳的穩(wěn)定有重要作用。類似的，自動化測試與被測程序的互補結(jié)構(gòu)對保持系統(tǒng)的功能穩(wěn)定有重要作用。單元測試的能與不能一提到自動化測試，我猜很多人想到的是單元測試(unit testing)。單元測試確實有很大的用處，對于解決某一類型的問題很有幫助。粗略地說，單元測試主要用于測試一個函數(shù)、一個class或者相關的幾個classes。最典型的是測試純函數(shù)，比如計算個人所得稅的函數(shù)，輸出是起征點、扣除五險一金之后的應納稅所得額、稅

16、率表，輸出是應該繳的個稅。又比如我在程序中的日期與時間第一章日期計算中用單元測試來驗證Julian day number算法的正確性。再比如我在過家家版的移動離線計費系統(tǒng)實現(xiàn)和模擬銀行窗口排隊叫號系統(tǒng)的運作中用單元測試來檢查程序運行的結(jié)果是否符合預期。(最后這個或許不是嚴格意義上的單元測試，更像是驗收測試。)為了能用單元測試，主代碼有時候需要做一些改動。這對Java通常不構(gòu)成問題(反正都編譯成jar文件，在運行的時候指定entry point)。對于C+，一個程序只能有一個main()入口點，要采用單元測試的話，需要把功能代碼(被測對象)做成一個library，然后讓單元測試代碼(包含main

17、()函數(shù))link到這個library上；當然，為了正常啟動程序，我們還需要寫一個普通的main()，并link到這個library上。單元測試的缺點根據(jù)我的個人經(jīng)驗，我發(fā)現(xiàn)單元測試有以下缺點。阻礙大型重構(gòu)。單元測試是白盒測試，測試代碼直接調(diào)用被測代碼，測試代碼與被測代碼緊耦合。從理論上說，測試應該只關心被測代碼實現(xiàn)的功能，不用管它是如何實現(xiàn)的(包括它提供什么樣的函數(shù)調(diào)用接口)。比方說，以前面的個稅計算器函數(shù)為例，作為使用者，我們只關心它算的結(jié)果是否正確。但是，如果要寫單元測試，測試代碼必須調(diào)用被測代碼，那么測試代碼必須要知道個稅計算器的package、class、method name、pa

18、rameter list、return type等等信息，還要知道如何構(gòu)造這個class。以上任何一點改動都會造成測試失敗(編譯就不通過)。在添加新功能的時候，我們常會重構(gòu)已有的代碼，在保持原有功能的情況下讓代碼的形狀更適合實現(xiàn)新的需求。一旦修改原有的代碼，單元測試就可能編譯不過：比如給成員函數(shù)或構(gòu)造函數(shù)添加一個參數(shù)，或者把成員函數(shù)從一個class移到另一個class。對于Java，這個問題還比較好解決，因為IDE的重構(gòu)功能很強，能自動找到references，并修改之。對于C+，這個問題更為嚴重，因為一改功能代碼的接口，單元測試就編譯不過了，而C+通常沒有自動重構(gòu)工具(語法太復雜，語意太微妙

19、)可以幫我們，都得手動來。要么每改動一點功能代碼就修復單元測試，讓編譯通過；要么留著單元測試編譯不通過，先把功能代碼改成我們想要的樣子，再來統(tǒng)一修復單元測試。這兩種做法都有困難，前者，C+編譯緩慢，如果每改動一點就修復單元測試，一天下來也前進不了幾步，很多時間浪費在等待編譯上；后者，問題更嚴重，單元測試與被測代碼的互補性是保證程序功能穩(wěn)定的關鍵，如果大幅修改功能代碼的同時又大幅修改了單元測試，那么如何保證前后的單元測試的效果(測試點)不變?如果單元測試自身的代碼發(fā)生了改動，如何保證它測試結(jié)果的有效性?會不會某個手誤讓功能代碼和單元測試犯了相同的錯誤，負負得正，測試還是綠的，但是實際功能已經(jīng)亮了

20、紅燈?難道我們要為單元測試寫單元測試嗎?有時候，我們需要重新設計并重寫某個程序(有可能換用另一種語言)。這時候舊代碼中的單元測試完全作廢了(代碼結(jié)構(gòu)發(fā)生巨大改變，甚至連編程語言都換了)，其中包含的寶貴的業(yè)務知識也付之東流，豈不可惜?為了方便測試而施行依賴注入，破壞代碼的整體性。為了讓代碼具有可測試性，我們常會使用依賴注入技術，這么做的好處據(jù)說是解耦(其實，有人一句話道破真相：但凡你在某個地方切斷聯(lián)系，那么你必然會在另一個地方重新產(chǎn)生聯(lián)系)，壞處就是割裂了代碼的邏輯：單看一塊代碼不知道它是干嘛的，它依賴的對象不知道在哪兒創(chuàng)建的，如果一個interface有多個實現(xiàn)，不到運行的時候不知道用的是哪個

21、實現(xiàn)。(動態(tài)綁定的初衷就是如此，想來讀過以面向?qū)ο笏枷雽崿F(xiàn)的代碼的人都明白我在說什么。)以Muduo網(wǎng)絡編程示例之二：Boost.Asio的聊天服務器中出現(xiàn)的聊天服務器ChatServer為例，ChatServer直接使用了muduo：net：TcpServer和muduo：net：TcpConnection來處理網(wǎng)絡連接并收發(fā)數(shù)據(jù)，這個設計簡單直接。如果要為ChatServer寫單元測試，那么首先它肯定不能在構(gòu)造函數(shù)里初始化TcpServer了。稍微復雜一點的測試要用mock object。ChatServer用TcpServer和TcpConenction來收發(fā)消息，為了能單元測試，我們要

22、為TcpServer和TcpConnection提供mock實現(xiàn)，原本一個具體類TcpServer就變成了一個interface TcpServer加兩個實現(xiàn)TcpServerImpl和TcpServerMock，同理TcpConnection也一化為三。ChatServer本身的代碼也變得復雜，我們要設法把TcpServer和TcpConnection注入到其中，ChatServer不能自己初始化TcpServer對象。這恐怕是在C+中使用單元測試的主要困難之一。Java有動態(tài)代理，還可以用cglib來操作字節(jié)碼以實現(xiàn)注入。而C+比較原始，只能自己手工實現(xiàn)interface和implemen

23、tations。這樣原本緊湊的以concrete class構(gòu)成的代碼結(jié)構(gòu)因為單元測試的需要而變得松散(所謂面向接口編程嘛)，而這么做的目的僅僅是為了滿足源碼級的可測試性，是不是有一點因小失大呢?(這里且暫時忽略虛函數(shù)和普通函數(shù)在性能上的些微差別。)對于不同的test case，可能還需要不同的mock對象，比如TcpServerMock和TcpServerFailureMock，這又增加了編碼的工作量。此外，如果程序中用到的涉及IO的第三方庫沒有以interface方式暴露接口，而是直接提供的concrete class(這是對的，因為C+中應該避免使用虛函數(shù)作為庫的接口)，這也讓編寫單元變

24、得困難，因為總不能自己挨個wrapper一遍吧?難道用link-time的注入技術?某些failure場景難以測試，而考察這些場景對編寫穩(wěn)定的分布式系統(tǒng)有重要作用。比方說：網(wǎng)絡連不上、數(shù)據(jù)庫超時、系統(tǒng)資源不足。對多線程程序無能為力。如果一個程序的功能涉及多個線程合作，那么就比較難用單元測試來驗證其正確性。如果程序涉及比較多的交互(指和其他程序交互，不是指圖形用戶界面)，用單元測試來構(gòu)造測試場景比較麻煩，每個場景要寫一堆無趣的代碼。而這正是分布式系統(tǒng)最需要測試的地方?？偟膩碚f，單元測試是一個值得掌握的技術，用在適當?shù)牡胤酱_實能提高生產(chǎn)力。同時，在分布式系統(tǒng)中，我們還需要其他的自動化測試手段。分布

25、式系統(tǒng)測試的要點在分布式系統(tǒng)中，class與function級別的單元測試對整個系統(tǒng)的幫助不大，當然，這種單元測試對單個程序的質(zhì)量有幫助；但是，一堆磚頭壘在一起是變不成大樓的。分布式系統(tǒng)測試的要點是測試進程間的交互：一個進程收到客戶請求，該如何處理，然后轉(zhuǎn)發(fā)給其他進程；收到響應之后，又修改并應答客戶。測試這些多進程協(xié)作的場景才算測到了點子上。假設一個分布式系統(tǒng)由四五種進程組成，每個程序有各自的開發(fā)人員。對于整個系統(tǒng)，我們可以用腳本來模擬客戶，自動化地測試系統(tǒng)的整體運作情況，這種測試通常由QA團隊來執(zhí)行，也可以作為系統(tǒng)的冒煙測試。對于其中每個程序的開發(fā)人員，上述測試方法對日常的開發(fā)幫助不大，因為

26、測試要能通過必須整個系統(tǒng)都正常運轉(zhuǎn)才行，在開發(fā)階段，這一點不是時時刻刻都能滿足(有可能你用到的新功能對方還沒有實現(xiàn)，這反過來影響了你的進度)。另一方面，如果出現(xiàn)測試失敗，開發(fā)人員不能立刻知道這是自己的程序出錯，有可能是環(huán)境原因造成的錯誤，這通常要去讀程序日志才能判定。還有，作為開發(fā)者測試，我們希望它無副作用，每天反復多次運行也不會增加整個環(huán)境的負擔，以整個QA系統(tǒng)為測試平臺不可避免要留下一些垃圾數(shù)據(jù)，而清理這些數(shù)據(jù)又會花一些寶貴的工作時間。(你得判斷數(shù)據(jù)是自己的測試生成的還是別人的測試留下的，不能誤刪了別人的測試數(shù)據(jù)。)作為開發(fā)人員，我們需要一種單獨針對自己編寫的那個程序的自動化測試方案，一方

27、面提高日常開發(fā)的效率，另一方面作為自己那個程序的功能驗證測試集(即回歸測試/regression tests)。分布式系統(tǒng)的抽象觀點一臺機器兩根線形象地來看，一個分布式系統(tǒng)就是一堆機器，每臺機器的屁股上拖著兩根線：電源線和網(wǎng)線(不考慮SAN等存儲設備)，電源線插到電源插座上，網(wǎng)線插到交換機上。這個模型實際上說明，一臺機器的表現(xiàn)出來的行為完全由它接出來的兩根線展現(xiàn)，今天不談電源線，只談網(wǎng)線。(在乎服務器的功耗在我看來就是公司利潤率很低的標志，要從電費上摳成本。)如果網(wǎng)絡是普通的千兆以太網(wǎng)，那么吞吐量不大于125MB/s。這個吞吐量比起現(xiàn)在的CPU運算速度和內(nèi)存帶寬簡直小得可憐。這里我想提的是，對

28、于不特別在意latency的應用，只要能讓千兆以太網(wǎng)的吞吐量飽和或接近飽和，用什么編程語言其實無所謂。Java做網(wǎng)絡服務端開發(fā)也是很好的選擇(不是指web開發(fā)，而是做一些基礎的分布式組件，例如ZooKeeper和Hadoop之類)。盡管可能C+只用了15%的CPU，而Java用了30%的CPU，Java還占用更多的內(nèi)存，但是千兆網(wǎng)卡帶寬都已經(jīng)跑滿，那些省下在資源也只能浪費了；對于外界(從網(wǎng)線上看過來)而言，兩種語言的效果是一樣的，而通常Java的開發(fā)效率更高。(Java是比C+慢一些，但是透過千兆網(wǎng)絡不一定還能看得出這個區(qū)別來。)進程間通過TCP相互連接陳碩在多線程服務器的常用編程模型第5節(jié)進

29、程間通信中提倡僅使用TCP作為進程間通信的手段，今天這個觀點將再次得到驗證。以下是Hadoop的分布式文件系統(tǒng)HDFS的架構(gòu)簡圖。HDFS有四個角色參與其中，NameNode(保存元數(shù)據(jù))、DataNode(存儲節(jié)點，多個)、Secondary NameNode(定期寫check point)、Client(客戶，系統(tǒng)的使用者)。這些進程運行在多臺機器上，之間通過TCP協(xié)議互聯(lián)。程序的行為完全由它在TCP連接上的表現(xiàn)決定(TCP就好比前面提到的網(wǎng)線)。在這個系統(tǒng)中，一個程序其實不知道與自己打交道的到底是什么。比如，對于DataNode，它其實不在乎自己連接的是真的NameNode還是某個調(diào)皮的

30、小孩用Telnet模擬的NameNode，它只管接受命令并執(zhí)行。對于NameNode，它其實也不知道DataNode是不是真的把用戶數(shù)據(jù)存到磁盤上去了，它只需要根據(jù)DataNode的反饋更新自己的元數(shù)據(jù)就行。這已經(jīng)為我們指明了方向。一種自動化的回歸測試方案假如我是NameNode的開發(fā)者，為了能自動化測試NameNode，我可以為它寫一個test harness(這是一個獨立的進程)，這個test harness仿冒(mock)了與被測進程打交道的全部程序。如下圖所示，是不是有點像缸中之腦?對于DataNode的開發(fā)者，他們也可以寫一個專門的test harness，模擬Client和Name

31、Node。Test harness的優(yōu)點完全從外部觀察被測程序，對被測程序沒有侵入性，代碼該怎么寫就怎么寫，不需要為測試留路。能測試真實環(huán)境下的表現(xiàn)，程序不是單獨為測試編譯的版本，而是將來真實運行的版本。數(shù)據(jù)也是從網(wǎng)絡上讀取，發(fā)送到網(wǎng)絡上。允許被測程序做大的重構(gòu)，以優(yōu)化內(nèi)部代碼結(jié)構(gòu)，只要其表現(xiàn)出來的行為不變，測試就不會失敗。(在重構(gòu)期間不用修改test case。)能比較方便地測試failure場景。比如，若要測試DataNode出錯時NameNode的反應，只要讓test harness模擬的那個mock DataNode返回我們想要的出錯信息。要測試NameNode在某個DataNode失

32、效之后的反應，只要讓test harness斷開對應的網(wǎng)絡連接即可。要測量某請求超時的反應，只要讓Test harness不返回結(jié)果即可。這對構(gòu)建可靠的分布式系統(tǒng)尤為重要。幫助開發(fā)人員從使用者的角度理解程序，程序的哪些行為在外部是看得到的，哪些行為是看不到的。有了一套比較完整的test cases之后，甚至可以換種語言重寫被測程序(假設為了提高內(nèi)存利用率，換用C+來重新實現(xiàn)NameNode)，測試用例依舊可用。這時test harness起到知識傳承的作用。發(fā)現(xiàn)bug之后，往test harness里添加能復現(xiàn)bug的test case，修復bug之后，test case繼續(xù)留在harness

33、中，反正出現(xiàn)回歸(regression)。實現(xiàn)要點Test harness的要點在于隔斷被測程序與其他程序的聯(lián)系，它冒充了全部其他程序。這樣被測程序就像被放到測試臺上觀察一樣，讓我們只關注它一個。Test harness要能發(fā)起或接受多個TCP連接，可能需要用某個現(xiàn)成的NIO網(wǎng)絡庫，如果不想寫成多線程程序的話。Test harness可以與被測程序運行在同一臺機器，也可以運行在兩臺機器上。在運行被測程序的時候，可能要用一個特殊的啟動腳本把它依賴的host：port指向test harness。Test harness只需要表現(xiàn)得跟它要mock的程序一樣，不需要真的去實現(xiàn)復雜的邏輯。比如mock

34、 DataNode只需要對NameNode返回Yes sir，數(shù)據(jù)已存好，而不需要真的把數(shù)據(jù)存到硬盤上。若要mock比較復雜的邏輯，可以用記錄+回放的方式，把預設的響應放到test case里回放(replay)給被測程序。因為通信走TCP協(xié)議，test harness不一定要和被測程序用相同的語言，只要符合協(xié)議就行。試想如果用共享內(nèi)存實現(xiàn)IPC，這是不可能的。陳碩在在muduo中實現(xiàn)protobuf編解碼器與消息分發(fā)器中提到利用protobuf的跨語言特性，我們可以采用Java為C+服務程序編寫test harness。其他跨語言的協(xié)議格式也行，比如XML或Json。Test harness

35、運行起來之后，等待被測程序的連接，或者主動連接被測程序，或者兼而有之，取決于所用的通信方式。一切就緒之后，Test harness依次執(zhí)行test cases。一個NameNode test case的典型過程是：test harness模仿client向被測NameNode發(fā)送一個請求(eg.創(chuàng)建文件)，NameNode可能會聯(lián)絡mock DataNode，test harness模仿DataNode應有的響應，NameNode收到mock DataNode的反饋之后發(fā)送響應給client，這時test harness檢查響應是否符合預期。Test harness中的test cases以配

36、置文件(每個test case有一個或多個文本配置文件，每個test case占一個目錄)方式指定。test harness和test cases連同程序代碼一起用version controlling工具管理起來。這樣能復現(xiàn)以外任何一個版本的應有行為。對于比較復雜的test case，可以用嵌入式腳本語言來描述場景。如果test harness是Java寫的，那么可以嵌入Groovy，就像陳碩在過家家版的移動離線計費系統(tǒng)實現(xiàn)中用Groovy實現(xiàn)計費邏輯一樣。Groovy調(diào)用test harness模擬多個程序分別發(fā)送多份數(shù)據(jù)并驗證結(jié)果，groovy本身就是程序代碼，可以有邏輯判斷甚至循環(huán)。這

37、種動靜結(jié)合的做法在不增加test harness復雜度的情況下提供了相當高的靈活性。Test harness可以有一個命令行界面，程序員輸入run 10就選擇執(zhí)行第10號test case。幾個實例Test harness這種測試方法適合測試有狀態(tài)的、與多個進程通信的分布式程序，除了Hadoop中的NameNode與DataNode，我還能想到幾個例子。1.chat聊天服務器聊天服務器會與多個客戶端打交道，我們可以用test harness模擬5個客戶端，模擬用戶上下線，發(fā)送消息等情況，自動檢測聊天服務器的工作情況。2.連接服務器、登錄服務器、邏輯服務器這是云風在他的blog中提到的三種網(wǎng)游服

38、務器(http：//2007/02/user_authenticate.html，http：//2006/04/iocp_kqueue_epoll.html，http：//2010/11/go_prime.html)，我這里借用來舉例子。如果要為連接服務器寫test harness，那么需要模擬客戶(發(fā)起連接)、登錄服務器(驗證客戶資料)、邏輯服務器(收發(fā)網(wǎng)游數(shù)據(jù))，有了這樣的test harness，可以方便地測試連接服務器的正確性，也可以方便地模擬其他各個服務器斷開連接的情況，看看連

39、接服務器是否應對自如。同樣的思路，可以為登錄服務器寫test harness。(我估計不用為邏輯服務器再寫了，因為肯定已經(jīng)有自動測試了。)3.多master之間的二段提交這是分布式容錯的一個經(jīng)典做法。用test harness能把primary master和secondary masters單獨拎出來測試。在測試primary master的時候，test harness扮演name service和secondary masters。在測試secondary master的時候，test harness扮演name service、primary master、其他secondary ma

40、sters?？梢员容^容易地測試各種failure情況。如果不這么做，而直接部署多個masters來測試，恐怕很難做到自動化測試。4.paxos的實現(xiàn)Paxos協(xié)議的實現(xiàn)肯定離不了單元測試，因為涉及多個角色中比較復雜的狀態(tài)變遷。同時，如果我要寫paxos實現(xiàn)，那么test harness也是少不了的，它能自動測試paxos節(jié)點在真實網(wǎng)絡環(huán)境下的表現(xiàn)，并且輕易模擬各種failure場景。局限性如果被測程序有TCP之外的IO，或者其TCP協(xié)議不易模擬(比如通過TCP連接數(shù)據(jù)庫)，那么這種測試方案會受到干擾。對于數(shù)據(jù)庫，如果被測程序只是簡單的從數(shù)據(jù)庫select一些配置信息，那么或許可以在test harness里內(nèi)嵌一個in-memory H2 DB engine，然后讓