時間穿透測試
一、概述
性能測試的最終目的在於提升系統的性能和穩定性，測試的過程就是不斷優化的過程，傳統方法就是使用如：LoadRunner、Jmeter、Postman等等測試工具，模擬客戶端的並發情況，對於每個客戶端的每條發往伺服器的消息在各個關鍵環節所消耗的時間並不清楚，只能通過監測伺服器記憶體、CPU以及網路等等資源情況和測試客戶端本身來的監控結果來判定系統性能，這對於如何優化或優化點在什麼地方基本幫助不大，而時間穿透測試，就是解決每條消息從客戶端發送開始到伺服器返回消息為止，其數據流向及其業務處理的關鍵環節所在的時間點監測，從而計算這些環節的耗時情況，並通過所有測試客戶端的所有並發消息的這些時間節點的組合分析，找出整個後台服務在哪些環節需要優化或改進，並對優化後的效果進行驗證的測試方法。
二、定義
時間穿透測試就是在整套系統或平台的測試過程中，從客戶端發送消息開始，就在消息結構中添加初始編碼及其時間戳資訊，在各伺服器收到、拆解、快取、提取、轉移、轉換、處理、存儲等等過程環節以及消息逆向返回至客戶端的各個關鍵節點中均在消息體中增加各自的環節編碼和時間戳資訊，然後不斷解析、匯總所有客戶端在測試期間發送的同類業務中所有這類消息結構中的環節編碼和時間戳資訊，並從中分析出各個消息在各伺服器承受壓力的各個階段、各環節在處理消息的各種維度時間曲線，並以這些曲線的分析結果為基礎，同時結合各伺服器、網路等資源的監控數據，找出系統改進或配置優化的環節和方向，從而輔助研發或部署人員進行系統性能優化的測試方法和過程。
中文名：時間穿透測試， 英文名：Time Through Testing， 同義詞：TTT測試 或 ３Ｔ測試
三、原理
時間穿透測試的原理就是通過在系統或平台的各個時間易耗環節或過程中設置採集點，所有經過這些節點的消息體均在其後增加當前採集點編碼及時間戳，通過一個業務所經歷的服務環節編碼表，可直接計算出一條消息在各個環節之間所經歷的時長，通過對這些時長的分析，可以得到各個環節在不同壓力和資源情況下處理消息的效率，匯同系統設計時的預期或整合整個平台的時效耗損異常點，就可以找出需要優化改進或配置調整的地方，並且通過對這些時間耗損環節的優化或資源調整，在最大化的利用系統資源的基礎上，提升整個系統或平台的性能。
時間穿透測試概念圖（基於下面案例的平台架構）
四、方法
使用時間穿透測試，一般採用廣撒網重異常或由淺入深層層遞進等等策略進行，在分別介紹之前，先給出一個平台測試環境以便於進行案例說明。
平台服務端環境（客戶端由模擬單一核心業務並發測試工具擔任）：外網應用服務１提供消息的非同步收發，其收到客戶端業務消息後快取到RabbitMQ之類的消息快取服務（MQ）中，（會話快取可能存入Redis，在本測試過程中視為透明），協議應用服務２負責從MQ中提取客戶端消息進行協議解析，然後將解析後的明文業務消息繼續快取到MQ中，業務應用服務３再次從MQ中提取明文業務消息進行業務處理，然後將相應的業務數據保存到資料庫中，並將返回資訊再次保存到MQ中，外網應用服務１再從MQ中提取返回消息發送給客戶端，客戶端收到伺服器返回，業務流程處理結束。我們做測試的在測試階段不應再對系統架構指手畫腳，因此我們不管整個平台的架構是否合理，我們只管測試這個平台的性能瓶頸在哪裡，哪些地方必須要提升處理效率才能提升整個平台的性能。整個平台的簡單架構圖如下所示：
案例涉及的測試平台簡單架構及數據流
我們初步分析這個平台架構，發現中間的消息快取極有可能是整個平台的性能瓶頸所在，因此消息快取的進、出將是我們測試的重點，下面分別通過前面所述的兩種策略來對這個平台進行時間穿透測試。
策略一：廣撒網、重異常策略
廣撒網，顧名思義，就是測試業務所涉及到所有系統的重要時間節點，先粗略的設置一個採集點。在本案例中，需要先設置在的採集點為：外網應用服務１的接收和ＭＱ寫入；協議應用服務２的ＭＱ提取和ＭＱ寫入；業務應用伺服器的ＭＱ提取、資料庫寫入及完成、返回資訊的ＭＱ寫入；外網應用伺服器１的ＭＱ提取和消息發送。再結合測試客戶端的消息發送和返回資訊接收採集點（可參照「原理」中的概念圖），整個平台各個子系統的進出的時間點都有了。採集點定了並植入源程式碼之後，再同步一下各伺服器以及測試機的系統時間後，就可以開始初步測試了。
經過幾輪不同並發的壓力測試，初步測試一下系統的性能和穩定性，當然測試期間仍然需要對相關資源監控並記錄，對壓力測試期間的時間進行分析，正常情況下，一個平台在充分利用資源之前，總會有這個或那個系統的瓶頸，導致忙的忙不過來，閑的又無事可做，從而造成整個平台的性能低下且資源利用率不足的情況。
比如說本案例中，MQ的性能在高並發下可能嚴重影響平台的整體性能，這時就需要優化MQ配置或增加MQ的資源，如部署成集群或者根據本案例的特點，將不同類型的消息快取到單獨部署的兩台甚至三台伺服器中以提升讀寫性能並降低相互之間的並發乾擾等等，而一旦MQ的性能提升上來後，又可能是外網應用伺服器１的性能不足，同樣部署為集群或多伺服器後，還有可能其它服務系統出現瓶頸……這一輪的處理主要是基於系統級時間粒度判定各應用系統瓶頸所在，並調整資源配置，一旦所有可伸縮資源分配完或者在某應用服務獲得足夠資源的情況下也無法提升性能並始終處於瓶頸狀態時，廣撒網策略則進入第二階段：重異常。
此時需要重點攻克瓶頸應用或者說在更細粒度調整系統性能，假設本案例在協議應用服務２處始終處理平台瓶頸，則需要在該系統中增加採集點，比如在協議解析的各個階段增加採集點，並按照從粗到細的過程逐步細化定位異常耗時點，通過優化程式碼甚至調整架構等等方法來提升其效率，完成對這些異常耗時點的逐個優化後，同時就實現了該應用服務性能的整體提升，而逐步對所有成為瓶頸的應用服務的性能優化，則將實現整個平台的性能提升和資源利用最大化。
策略二：由淺入深、層層遞進
由淺入深的過程，即是涉及處理消息的後台應用服務處理由少到多的過程。
我們首先只運行外網應用服務１，並調整其程式碼讓其接收消息後正常處理，但將寫入ＭＱ的方法暫時替換為生成臨時消息並調用消息返回的方法。此時，消息將只在第一層應用伺服器進行了處理，在不涉及消息快取和其它服務處理的時候進行直接返回，這時的性能必然是最高的，但是，需要高到什麼程度合適呢。
對於一個平台而言，業務消息所經歷的應用服務層級越多，平台的整體性能就會越低，平台的整體性能從外網應用到核心服務的性能因各種原因將出現層層衰減的情況，根據各層級處理的複雜度，可以預測一個各層衰減指數，在本案例中，為了方便，則假定每層固定衰減10%的性能，那整體性能由淺入深分別為：外網應用服務１：100%、MQ快取：90%、協議應用服務２：80%、MQ快取：70%、業務應用伺服器３：60%（這時假定資料庫服務在核心業務處理上不會出現明顯的性能衰減）、MQ快取：50%、外網應用服務１：40%，由此可見，整個過程對於同一業務的消息而言，平台整體性能將為單獨外網應用服務１的40%，因此，假如案例平台設計的並發性能為5萬，那麼，單獨的外網應用服務１的系統性能應該至少為12.5萬，這就是我們測試第一層外網應用服務１的並發性能目標。（注意：這裡的分析是針對高峰期性能，如果是日常性能指標，則不能按這種方式來處理，不然消息持續積壓將很快使系統崩潰）
有了每個層級的性能測試目標，就可以逐層累加測試了，首先是單獨外網應用服務１層，在按設計的部署方式和資源進行部署後，直接測試其並發性能，如果性能達不到要求，則適當增加資源（如增加頻寬、增加應用服務集群點等等），如果仍不能滿足性能要求，則需要在外網應用服務１內部增加採集點，監測在收到消息的處理和返回消息的處理過程中消耗時間異常的點，逐一優化，直至達到性能要求；而如果在不作任何優化的條件下性能遠遠超過性能目標，則逐漸減少資源，使其性能在目標性能之上一定比例如５％或１０％等，以適應將來整體平台性能更高要求的可能，多餘出來的資源則可以分配給後面的應用服務，以實現資源最佳分配和最大化利用的目的。當然，也可以根據情況測試平台並髮指數（案例中為5萬）時的第一層資源佔用情況，這個資源則為第一層的最低資源佔用限額，在後面層級資源嚴重不足時，可以在最低資源佔用限額之上適當降低第一層或前面幾層的資源佔用，從而保證整個平台的整體高性能和最佳資源利用率。當然，也可以作為彈性資源自動調整的基礎依據。
一般來說，第一層的性能和優化最為簡單，因為它不涉及複雜的業務處理和大量資源佔用，只要架構不出大的問題，就很容易達到性能要求（話說第一層都無法達到要求，後面幾層基本就更難達到要求了），本案例中的第一層也可以稱之為空載層。當第一層測試達標後，其資源分配就固定下來，然後接入第二層，因本案例的第二層為第三方的ＭＱ服務，因此主要是應用配置和部署優化，當然，第一層的寫入和讀取方法也可能會涉及到優化調整，但這並不會影響之前單獨的第一層的性能，因為這部分本身就屬於第二層的性能範疇，涉及的也是第二層的資源。在策略一中說過，MQ的優化有很多種方案，集群、分功能單獨部署等等，在本案例中將在第二、四、六層分別需要對MQ進行優化調整，需要根據平台的業務具體情況具體處理，這裡就不再贅述。
通過逐層優化，只要每層都達到自己的性能要求，最終整個平台的性能自然能夠滿足設計要求。
時間穿透測試當然不僅僅只有兩種策略，就如同兩個點在平面、在球面、在立方體表面等等情況下的最短路線各有不同一樣，系統不同、構架不同、需求不同等等都會有不同的策略，但作為性能測試方法，最終的目標都是一樣的：就是快速、準確的提供影響系統或平台性能的瓶頸癥結所在，以供相關人員對其進行調整和優化。
五、優缺點
（一）、時間穿透測試有如下優點：
1、簡單易懂
時間穿透測試就如同其字面意思，即讓每條消息在穿越各應用服務的各個環節時打上時間標籤後再返回客戶端的測試過程，就如同照X光一樣檢測各應用服務的各個環節工作過程及其效率是否正常。
2、定位準確
通過對各個伺服器的各個處理環節的耗時分析，能夠準確知道時間都消耗在哪些地方，正常與否，是否需要進行程式碼級優或資源級調整。
3、效果顯著
精益求精是性能測試的基本原則，性能測試工作本身就是一個對系統或平台性能的持續優化調整提供輔助的過程，而採用時間穿透測試方法，這個持續的過程將變為間歇性過程，因為通過本方法可以快速準確的定位需要優化的環節和方向，極大的降低研發人員查找和定位優化點的時間，從而在快速提升系統性能的同時大大的節約的系統性能優化的過程成本。
4、模式支援
本方法除了可測試並優化系統或平台性能及其資源配置的合理性外，還能在系統設計初期通過此方法來驗證和選擇各個技術框架是否能夠滿足系統設計的需要。此外，如果各種中間件、服務和框架都能夠按統一標準給出其外露介面或服務的相應時間穿透測試模式，則對於整個系統或平台選擇其最為契合的中間件、服務和框架提供非常寶貴的一體化性能和資源利用的完整數據基礎，這對於追求高效的系統或平台而言，是非常重要的。
（二）、時間穿透測試的缺點為：
1、能力要求高
要想進行時間穿透測試，首要的就是必須能修改整個系統和平台的源程式碼，在了解整個系統架構和業務的基礎上，在對應環節的源程式碼中設立採集點，這些如果沒有研發人員的輔助，單靠測試人員，對其綜合能力要求就比較高了，不僅要能做常規的性能測試和資源監控，還要有修改各種開發語言乃至各種資料庫存儲過程、函數和觸發器的能力，更要懂得各個伺服器資源、中間件、資料庫等各種第三方應用服務等等的配置和調整……
而要降低這些能力要求，就需要出台一些時間穿透測試的行業標準或模式支援，研發人員只需要根據標準預留相應的測試模式下的標準支援即可，各第三方應用伺服器、中間件或框架也能夠給予這種測試模式下的標準支援，這樣測試人員只需要正常的客戶端腳本模擬的編寫和對測試結果數據進行分析（如果有了標準，相信對應的分析工具也會很快出來的）即可。當然，也可以自己寫工具來進行分析：
自己編寫工具對測試結果進行自動化分析
2、環境要求高
時間穿透測試最理想的環境當然是在生產環境中進行測試，這樣系統的最佳性能和資源分配才能根生產環境相匹配，因此這個測試一般是在試運行期間或正式上線前進行。
但實際上系統或平台的優化、資源的分配或資源的增加都是持續性的，可能生產環境上線後需要增加業務功能或增加系統資源，這時就不能直接在生產環境上進行測試了，此時只能在模擬環境中進行測試，而要達到與生產環境的最佳匹配度，就需要提供一套與生產環境基本一致的測試環境，這無疑將增加測試的環境成本。
本缺點的解決方法就是去第三方專業測試公司或直接從雲平台上臨時獲取相應的生產環境模擬
3、採集點易失
因為時間穿透測試需要單獨提取一份源程式碼出來進行測試修改，一旦源程式碼有變動，特別是變化比較多的時候，重新獲取的最新程式碼將替換已做採集點的源碼，從而導致需要重新分析源碼並編寫對應的採集點程式碼。
解決方法暫時在設計時或研發時考慮本測試的預留測試模式支援和設置，通過配置參數開啟或關閉時間穿透測試模式，當然，這也會增加研發的工作量。
4、數據難追加
除了增加採集點本身將對業務處理產生一定的影響外，增加採集點和時間戳也很可能導致後續的業務處理對追加的環節編碼及時間戳數據無法解析而無法繼續處理，此時就需要對該測試業務所涉及的所有流程處理進行相應調整和修改，這將進一步加大測試難度和系統的不穩定因素，再結合上面的易失性，這些都將加大測試過程的難度。
這需要在設計或研發時增加對測試模式的設置，處於測試模式時不對數據結構進行嚴格檢查或校驗，以便於以後在開啟測試模式時減少測試人員的兼容性數據解析的工作量或者乾脆就在設計中增加相應的測試模式下的冗餘數據的支援。
六、應用
本測試方法可應用於需要進行性能測試的所有完整系統或平台，也可為系統或平台的資源擴張提供方向和依據，還可應用於對框架理論或DEMO的性能驗證，並根據測試結果提供理論或驗證的數據支撐。
資源擴展這塊單獨簡要說下：主要是在原有系統或平台運行一段時間後，用戶增長量超過預期，需要通過增加硬體資源來提昇平台的整體性能，此時則可通過進行新的時間穿透測試或根據上線前進行過的時間穿透測試結果，就能夠精準的找到提升整體性能所需要的各系統的部署方式和需要增加的硬體資源種類和資源數量，以及各資源如何分配等等。
綜述：一切測試方法和過程僅僅是找到問題的方法和手段，就如同定期體檢和病症檢查，其結果能夠反映整個人體系統的部分真實問題，但並不能解決問題，要解決問題，還需要研發、運維甚至需求、設計、構架等等崗位人員的共同努力。但無論如何，快速、準確的找到系統問題的癥結所在，是高效解決問題的根本基礎。
