1. 項目定位容災備份中心的第三方測試到底測什么接手“軍工信息系統(tǒng)容災備份中心建設軟件第三方測試方案”這個項目時第一反應不是去翻需求文檔而是先想清楚一個前提問題這套容災備份系統(tǒng)在建設完成之后為什么還要單獨拉一支第三方測試隊伍進場容災備份中心的核心價值就一句話業(yè)務數(shù)據(jù)不丟、核心業(yè)務不停。對應到技術指標上就是RPO Recovery Point Objective恢復點目標和RTORecovery Time Objective恢復時間目標。RPO決定了你能容忍丟多少數(shù)據(jù)RTO決定了你能容忍業(yè)務中斷多久。軍工信息系統(tǒng)的業(yè)務連續(xù)性要求極高RPO和RTO往往卡得非常緊數(shù)據(jù)丟失和業(yè)務中斷的代價都不是用金錢能衡量的。第三方測試的價值在于“獨立性”。研發(fā)方自測天然存在盲區(qū)開發(fā)人員對自己寫的代碼有路徑依賴測來測去總是繞著熟悉的功能打轉運維方關注的是日常運行很難站在“故意搞破壞”的角度去驗證系統(tǒng)的極限能力。第三方測試的核心思維是“假設它會壞然后想辦法讓它壞”。只有通過主動制造故障、故意中斷鏈路、模擬極端場景才能把容災系統(tǒng)真正的底牌摸清楚。這次項目的“部分內(nèi)容”定位也很明確不是從零開始寫一份完整測試方案而是針對容災備份中心建設中的關鍵測試專項進行細化設計。整體方案里已經(jīng)確定了測試范圍、測試資源、進度計劃這部分內(nèi)容重點解決的是“具體怎么測、判定標準是什么、故障怎么注入、數(shù)據(jù)怎么校驗”這些可落地的細節(jié)。適合讀這篇內(nèi)容的人主要是三類一是做容災備份系統(tǒng)測試的工程師可以參考測試項設計和判定準則二是做數(shù)據(jù)中心建設項目的管理人員可以用里面的檢查點去監(jiān)督第三方測試質(zhì)量三是剛入行想做測試方案設計的同學里面有很多實際執(zhí)行層面的坑和經(jīng)驗。2. 第三方測試的總體策略與方案設計要點2.1 測試策略四類測試的投入比例怎么定容災備份系統(tǒng)的第三方測試我習慣劃分為四大類功能性測試、性能測試、可靠性測試、安全性測試。這四類不是平均用力而是根據(jù)系統(tǒng)建設階段和風險等級動態(tài)調(diào)整。功能性測試重點驗證容災備份的基本能力包括數(shù)據(jù)同步是否正常、備份任務能否按策略執(zhí)行、切換流程是否完整、恢復操作是否可用。對于軍工信息系統(tǒng)功能測試要覆蓋“正常路徑”和“異常路徑”兩條腿很多人只測正常路徑結果故障演練的時候一步都走不通。性能測試關注的是同步延遲、備份窗口、恢復速度、并發(fā)處理能力等指標。這里有個關鍵點容災備份系統(tǒng)的性能指標必須在“接近真實負載”的條件下測試而不是在空庫、低并發(fā)環(huán)境下測一個好看的數(shù)字。我在模擬項目X中接過一個項目前期的性能測試報告非常漂亮數(shù)據(jù)同步幾乎零延遲結果真實業(yè)務接入后延遲暴漲原因就是測試環(huán)境的寫入并發(fā)只有生產(chǎn)環(huán)境的十分之一。可靠性測試是重頭戲包括故障注入測試、切換演練、斷電斷網(wǎng)模擬、數(shù)據(jù)損壞模擬等。這部分測試的投入占比至少要達到40%以上?？煽啃詼y試不是“走個過場”而是要真正制造故障觀察系統(tǒng)的真實反應。安全性測試在軍工場景下尤為重要包括備份數(shù)據(jù)的加密存儲、訪問控制、傳輸鏈路安全、備份介質(zhì)管理等方面必須確保容災數(shù)據(jù)本身不被泄露或篡改。2.2 測試環(huán)境搭建隔離、仿真、脫敏三原則測試環(huán)境是第三方測試的“試驗臺”搭建得好不好直接決定測試結果的可信度。容災備份系統(tǒng)的測試環(huán)境搭建我總結為三個原則隔離性、仿真性、數(shù)據(jù)脫敏。隔離性是底線。測試環(huán)境必須與生產(chǎn)環(huán)境完全隔離網(wǎng)絡不能互通存儲不能共用賬號體系也要分開。有些單位為了省事在生產(chǎn)環(huán)境的空閑網(wǎng)段上劃一塊出來做測試這種做法非常危險故障注入測試一旦失控可能直接影響生產(chǎn)業(yè)務。軍工信息系統(tǒng)對隔離性的要求更高物理隔離比邏輯隔離更穩(wěn)妥。仿真性決定了測試結果的有效性。網(wǎng)絡拓撲要仿照生產(chǎn)環(huán)境容災鏈路的帶寬、時延、抖動參數(shù)要盡量接近真實情況。存儲設備型號、磁盤陣列配置、備份軟件的版本也要與生產(chǎn)環(huán)境保持一致。如果測試環(huán)境和生產(chǎn)環(huán)境差異太大測出來的RPO、RTO數(shù)據(jù)就沒有參考價值。數(shù)據(jù)脫敏是軍工項目不可跳過的一環(huán)。用生產(chǎn)數(shù)據(jù)做測試必須經(jīng)過脫敏處理涉密字段要替換關鍵業(yè)務數(shù)據(jù)要變換。但脫敏有個度的問題脫的太狠數(shù)據(jù)特征失真測試結果不可信脫的不夠存在泄密風險。建議的做法是保留數(shù)據(jù)的結構特征、數(shù)據(jù)量級、分布規(guī)律只替換具體的內(nèi)容值。2.3 測試工具選型商業(yè)、開源、自研如何組合容災備份測試的工具鏈市面上沒有一套完全通用的方案實際項目中往往是商業(yè)工具、開源工具、自研腳本三者組合。商業(yè)工具方面磁盤陣列和備份軟件廠商一般會提供配套的測試工具比如存儲層的性能測試工具、備份軟件的驗證工具。我的建議是廠商工具必須用但不能只用。廠商工具通常用來證明“我的產(chǎn)品沒問題”第三方測試需要用獨立的視角去驗證完全依賴廠商工具相當于讓運動員自己當裁判。開源工具的靈活性更高。網(wǎng)絡層故障注入可以用Linux自帶的tc命令模擬延遲、丟包、亂序磁盤I/O故障可以用device-mapper工具模擬壞塊、讀寫超時數(shù)據(jù)庫層的數(shù)據(jù)校驗可以用Perl、Python腳本做比對。我在實際項目中網(wǎng)絡抖動模擬、數(shù)據(jù)一致性校驗大部分都是用腳本完成的。自研腳本主要解決兩類問題一是批量構造測試數(shù)據(jù)二是自動化執(zhí)行故障注入和結果采集。比如主備切換測試需要在高并發(fā)寫入的場景下觸發(fā)切換純手工操作很難捕捉到精確的RPO值寫一個數(shù)據(jù)生成腳本持續(xù)寫入同時另一個腳本控制切換觸發(fā)最后比對寫入序號和切換后數(shù)據(jù)庫中的數(shù)據(jù)就能算出真實的RPO。3. 核心測試項設計與實操過程3.1 主備切換與故障注入測試怎么“故意搞壞”系統(tǒng)主備切換是容災系統(tǒng)的核心動作也是測試中最容易出問題的環(huán)節(jié)。設計切換測試時我遵循一個原則先分級、后注入、再驗證。分級指的是切換場景分級。一級場景是計劃內(nèi)切換比如設備維護、軟件升級導致的主動切換二級場景是計劃外切換比如主機宕機、存儲故障、網(wǎng)絡中斷導致的被動切換。測試必須覆蓋兩個級別因為計劃外切換的判定邏輯和執(zhí)行路徑與計劃內(nèi)切換完全不一樣。故障注入方式要多樣化不能只測“拔網(wǎng)線”。物理層故障包括主機斷電、存儲離線、光纖鏈路中斷網(wǎng)絡層故障包括核心交換機宕機、鏈路丟包率飆升、網(wǎng)絡抖動加劇應用層故障包括數(shù)據(jù)庫進程崩潰、中間件服務假死、備份任務異常終止。我在模擬項目X中設計了一組故障用例對生產(chǎn)主機執(zhí)行了模擬斷電操作結果發(fā)現(xiàn)系統(tǒng)的雙機心跳檢測機制在8秒后才完成故障確認比設計指標多了3秒主要原因就是心跳探測的失敗重試次數(shù)配置了5次每次超時1.6秒正常情況下這個配置沒問題但在高負載條件下心跳響應變慢導致故障確認時間超標。切換功能的驗證點包括故障檢測是否及時、切換決策是否正確、數(shù)據(jù)同步是否完整、業(yè)務是否平滑接管、切回操作是否正常。每一步都要有明確的判定標準和預期結果不能只看“系統(tǒng)沒報錯”就判定通過。3.2 數(shù)據(jù)一致性校驗與RPO實測別只看工具報表RPO是容災系統(tǒng)最核心的指標之一但很多測試團隊測RPO的方法過于粗糙直接看同步軟件顯示“已同步到最新”就認為RPO為零。這種做法在軍工項目中是不可接受的。正確的RPO實測方法應該是這樣的在業(yè)務寫入持續(xù)不斷的場景下人為制造主中心故障然后檢查備用中心的數(shù)據(jù)狀態(tài)計算出故障發(fā)生時刻與備用中心實際恢復點之間的數(shù)據(jù)差。具體操作上我通常會寫一個帶有遞增序號的數(shù)據(jù)寫入程序持續(xù)向源端寫入數(shù)據(jù)同時在某個隨機時刻觸發(fā)主中心故障故障恢復后統(tǒng)計備用中心數(shù)據(jù)中最大的連續(xù)序號用“源端寫入總量減去備用中心已接收量”換算成時間差就是真實的RPO。這里有一個很隱蔽的坑如果數(shù)據(jù)同步是異步模式正常時段同步延遲很小但在大事務提交、批量導入、日志備份的瞬間同步隊列會積壓RPO會瞬間拉大。只測穩(wěn)態(tài)下的RPO遠遠不夠必須在高寫入壓力、大事務集中提交的場景下反復測試才能暴露真實的極端RPO。數(shù)據(jù)一致性校驗不能只依賴數(shù)據(jù)庫自身的事務日志要獨立做數(shù)據(jù)比對。文件級別的系統(tǒng)可以比文件MD5值數(shù)據(jù)庫系統(tǒng)可以抽查關鍵表的記錄數(shù)和關鍵字段值中間件系統(tǒng)要驗證消息隊列的未消費數(shù)量和順序號。比對的時間點要在切換完成之后立即進行拖的時間越長后續(xù)新增數(shù)據(jù)越會干擾判斷。3.3 恢復演練與RTO實測切換成功不等于恢復成功恢復測試是最容易被低估的工作因為“切換成功”和“業(yè)務恢復”是兩個概念。切換只是把服務從A點挪到了B點恢復則要求B點的服務能正常對外提供業(yè)務數(shù)據(jù)完整、權限正確、網(wǎng)絡可達、外部依賴都能工作。RTO的實測要精確到秒級。常規(guī)做法是定義一個計時起點和一個計時終點比如從“模擬故障注入完成”到“備用中心對外正常提供服務”之間的時長。實際操作中計時點的定義很關鍵。如果故障注入還沒完成就開始計時測出來的RTO會偏小如果把整個演練過程的準備時間都算進去RTO又會偏大。我的做法是在測試方案中明確約定故障注入生效的瞬間作為T0業(yè)務驗證請求返回成功的瞬間作為T1T1-T0就是RTO?；謴万炞C要分三個層次系統(tǒng)層驗證檢查服務進程狀態(tài)、監(jiān)聽端口、資源占用是否正常應用層驗證通過模擬業(yè)務請求確認核心業(yè)務流程可以跑通數(shù)據(jù)層驗證確認數(shù)據(jù)完整性和一致性達標。三層都通過才能判定恢復成功?；謴蜏y試還要覆蓋增量恢復和全量恢復兩種方式增量恢復看重的是日志回放效率和斷點續(xù)傳能力全量恢復看重的是數(shù)據(jù)拷貝速度和一致性校驗機制。我在某容災項目的恢復測試中就踩過一個坑備用中心的數(shù)據(jù)庫服務成功拉起后表面看一切正常但遺漏了數(shù)據(jù)庫序列號的同步校驗導致后續(xù)業(yè)務寫入主鍵沖突整整排查了四個小時才定位到問題。從那以后恢復驗證清單上就永久加上了“序列號/流水號一致性檢查”這一項。3.4 備份有效性驗證能備份更要能恢復容災和備份是兩條腿缺一不可。容災解決的是“業(yè)務連續(xù)性”備份解決的是“數(shù)據(jù)可恢復”。很多單位的備份系統(tǒng)每天都在跑備份任務全部顯示成功但真正到了要恢復數(shù)據(jù)的時候才發(fā)現(xiàn)備份文件損壞、恢復流程斷裂、備份介質(zhì)不可讀。備份有效性驗證的核心思想就是備份成功不等于備份可用只有恢復成功的備份才叫有效備份。備份驗證的測試設計要覆蓋備份的全生命周期備份策略配置是否合理增量備份和全量備份的組合是否滿足恢復需求備份文件的完整性是否經(jīng)過校驗備份介質(zhì)的生命周期管理是否到位異地備份的數(shù)據(jù)是否可以直接用于容災切換。實操中最常用的方法是“抽樣恢復驗證”。對所有備份任務按一定比例抽樣執(zhí)行恢復操作驗證備份數(shù)據(jù)可以直接用于恢復。抽樣要有代表性不能只挑小的備份任務驗證。我通常的做法是不同業(yè)務系統(tǒng)的備份至少各抽一個不同時間點的備份各抽一個不同存儲介質(zhì)上的備份各抽一個。抽到的備份必須完整執(zhí)行恢復流程不能只做文件列表比對要真正把數(shù)據(jù)恢復到可用狀態(tài)。備份數(shù)據(jù)的安全性測試也值得專項設計。備份文件往往比生產(chǎn)數(shù)據(jù)更容易被忽視權限管控做得不如業(yè)務系統(tǒng)嚴格。要驗證備份文件的存儲權限、傳輸加密、訪問審計是否符合要求防止備份數(shù)據(jù)變成數(shù)據(jù)泄露的缺口。4. 執(zhí)行過程中的典型問題與排查實錄4.1 故障注入后系統(tǒng)不切換心跳機制和仲裁策略的雙重陷阱故障注入后系統(tǒng)不切換是最常見也最頭疼的問題。正常情況下注入故障后系統(tǒng)應該在幾秒內(nèi)完成故障確認并觸發(fā)切換但實際執(zhí)行中經(jīng)常出現(xiàn)“故障已經(jīng)注入了系統(tǒng)毫無反應”的情況。我遇到過的一個典型案例是容災系統(tǒng)的雙機心跳機制配置了網(wǎng)卡直連心跳和以太網(wǎng)心跳雙鏈路按設計任意一條心跳鏈路中斷都不影響故障檢測。實際測試時我斷掉了網(wǎng)卡直連心跳系統(tǒng)沒有觸發(fā)切換再斷掉以太網(wǎng)心跳還是沒有觸發(fā)切換。后來排查發(fā)現(xiàn)心跳檢測的閾值配置了“兩條心跳鏈路同時中斷才判定故障”這在設計文檔里沒有明確說明配置人員和測試人員理解不一致導致測試預期和實際行為完全偏離。另一個典型問題是仲裁策略問題。分布式容災系統(tǒng)通常需要仲裁機制防止“腦裂”如果仲裁節(jié)點的網(wǎng)絡路徑同時被故障注入波及系統(tǒng)的自我保護機制會優(yōu)先選擇“保持現(xiàn)狀”而不是“發(fā)起切換”這是正常的安全機制但是在測試設計階段如果沒有考慮到這個細節(jié)就容易被判定為測試不通過。解決方案是在測試方案中明確區(qū)分“仲裁節(jié)點故障”和“數(shù)據(jù)節(jié)點故障”兩類場景分別定義預期行為。4.2 數(shù)據(jù)一致性校驗差異別急著報缺陷先查業(yè)務特征數(shù)據(jù)一致性校驗出現(xiàn)差異不一定都是容災系統(tǒng)的問題可能是業(yè)務數(shù)據(jù)自身的特點導致的。比如某些流水類業(yè)務表存在“邏輯刪除”機制數(shù)據(jù)行的物理內(nèi)容沒變但邏輯狀態(tài)已經(jīng)改變某些系統(tǒng)存在定時任務批量更新數(shù)據(jù)的窗口校驗時正好趕上更新過程中。我的排查路徑是這樣的第一步確認校驗比對的方法是否正確。是行數(shù)比對還是內(nèi)容比對是否考慮了表結構差異和字符集差異第二步確認比對的時間點是否有業(yè)務寫入。如果校驗直接在生產(chǎn)業(yè)務運行期間執(zhí)行出現(xiàn)短暫的數(shù)據(jù)不一致是正常的要先確認目標系統(tǒng)的同步狀態(tài)是否為“實時”還是“準實時”。第三步確認差異數(shù)據(jù)的具體內(nèi)容分析差異是否有規(guī)律性是集中在一個業(yè)務表還是分布在各表是增量數(shù)據(jù)還是存量數(shù)據(jù)的差異。曾有一次校驗發(fā)現(xiàn)備用中心某張表的行數(shù)比源端多了幾千行排查下來發(fā)現(xiàn)是備用庫上有人手動執(zhí)行過數(shù)據(jù)補入操作和容災系統(tǒng)本身沒有任何關系。這個經(jīng)驗告訴我們發(fā)現(xiàn)差異后要保留現(xiàn)場先定位差異數(shù)據(jù)的具體內(nèi)容再判斷原因不要一上來就報缺陷。4.3 恢復超時大部分不是恢復慢是驗證方法有問題RTO實測超時的原因一半以上不是系統(tǒng)真的恢復慢而是測量方法不嚴謹。最常見的錯誤是拿“服務進程啟動”當恢復成功的標志。數(shù)據(jù)庫進程起來了不代表數(shù)據(jù)庫可以對外提供服務還需要完成實例恢復、日志回放、網(wǎng)絡監(jiān)聽注冊等一系列工作。有些恢復測試把進程啟動時間作為RTO終點測出來的數(shù)據(jù)比真實RTO短了一大截。還有一類常見問題是恢復完成之后立刻做業(yè)務驗證發(fā)現(xiàn)業(yè)務請求超時就把責任算到恢復頭上。實際上切換完成后網(wǎng)絡路由收斂、負載均衡權重調(diào)整、客戶端連接池重建都需要時間這些不算恢復時間但在RTO測量中必須預留余量。我的建議是RTO指標應該拆分為“系統(tǒng)恢復時間”和“業(yè)務恢復時間”兩個子項分別測量、分別考核避免混在一起互相掩蓋問題。4.4 測試結果偏離指標先質(zhì)疑測試方法再質(zhì)疑系統(tǒng)能力當實測RPO、RTO偏離設計指標時不要急于斷定系統(tǒng)不達標。第三方測試的結論影響重大必須先排除測試方法本身的問題。要檢視的測試因素包括測試工具的計時精度是否足夠、故障注入的力度是否與實際故障場景一致、數(shù)據(jù)寫入的并發(fā)量是否達到預設值、網(wǎng)絡環(huán)境的背景流量是否模擬了生產(chǎn)情況。排除測試方法問題之后再分析系統(tǒng)配置層面的因素比如同步模式是否被意外修改、壓縮傳輸配置是否生效、備份窗口是否與業(yè)務高峰重疊。在一個實際項目中實測RTO是設計指標的2倍排查后發(fā)現(xiàn)是測試期間備用中心的殺毒軟件在進行全盤掃描占用了大量磁盤I/O。這個案例說明恢復測試必須保證備用中心的環(huán)境處于“干凈”狀態(tài)任何可能影響性能的維護操作都要提前禁止。測試執(zhí)行前我會專門發(fā)一份“測試期間環(huán)境約束清單”明確禁止在測試窗口內(nèi)執(zhí)行備份任務、系統(tǒng)升級、批量數(shù)據(jù)處理等操作。5. 測試記錄與交付要點5.1 測試記錄的可追溯性每一步都要能還原現(xiàn)場軍工項目的第三方測試測試記錄的要求比一般商用項目嚴格得多。每一項測試都要有完整的執(zhí)行記錄、原始數(shù)據(jù)、截圖佐證和操作人員簽名。這不僅是質(zhì)量管理的要求更是責任界定的依據(jù)。如果項目后續(xù)出現(xiàn)問題測試記錄就是第一手的追溯材料。我的習慣是每次測試執(zhí)行前先錄制一份“測試準備狀態(tài)確認單”記錄測試環(huán)境的初始狀態(tài)、數(shù)據(jù)基線、配置版本測試執(zhí)行過程中關鍵操作通過腳本自動記錄時間戳手工操作要在測試記錄表中注明操作人和操作時刻測試結束后立即輸出測試原始數(shù)據(jù)清單避免后續(xù)整理時信息丟失。測試記錄具體包括以下內(nèi)容測試用例編號、測試目的、前置條件、操作步驟、預期結果、實際結果、結論判定、問題描述、執(zhí)行人、執(zhí)行時間、環(huán)境狀態(tài)。判定為“通過”的用例要保留通過依據(jù)判定為“不通過”的用例要保留問題現(xiàn)象和故障現(xiàn)場數(shù)據(jù)。5.2 測試結論的表達問題分級與整改建議第三方測試的交付物不止是測試報告更重要的是結論的恰當表達。軍工項目的測試結論不能模棱兩可但也不能不加區(qū)分地一概否定。我的做法是對發(fā)現(xiàn)的問題做嚴重程度分級A級問題致命缺陷數(shù)據(jù)丟失、系統(tǒng)不可恢復、安全漏洞必須立即整改整改完成后重新測試。B級問題嚴重缺陷切換失敗、恢復超時、數(shù)據(jù)不一致必須在項目驗收前完成整改。C級問題一般缺陷流程不完善、配置項缺失、文檔不完整可以在后續(xù)優(yōu)化改進。D級問題建議項操作便利性、監(jiān)控告警完善、性能優(yōu)化空間。整改建議要具體可執(zhí)行。比如針對“故障檢測時間超長”的問題不能只寫“優(yōu)化心跳機制”而要寫明“調(diào)整心跳超時參數(shù)將失敗重試次數(shù)從5次降為3次同時增加心跳響應延遲的告警閾值”。針對“備份恢復流程文檔缺失”的問題要列出文檔應包含的章節(jié)和維護責任人。5.3 驗收指標核驗與回歸測試策略第三方測試的最后一環(huán)是配合驗收指標的核驗。軍工容災備份中心項目的驗收指標通常包含具體數(shù)值RPO不超過多少分鐘、RTO不超過多少小時、備份成功率不低于多少百分比、恢復驗證通過率不低于多少。每一項指標都要有對應的測試用例作為佐證。整改完成后的回歸測試策略要提前定好規(guī)則。我的經(jīng)驗是A級問題修復后進行全量回歸重點驗證問題涉及的功能域及其關聯(lián)功能B級問題修復后進行功能域回歸確認修復沒有引入新的問題C、D級問題的修復在后續(xù)測試輪次中附帶驗證即可。回歸測試不能只重復原用例還要補測與原問題相關的邊界場景。6. 寫在最后的幾點經(jīng)驗容災備份系統(tǒng)的第三方測試做了這么多年最大的體會是這套系統(tǒng)的測試不是驗證“正常情況下的可用性”而是驗證“異常情況下的生存能力”。很多系統(tǒng)在正常情況下運行得非常好數(shù)據(jù)同步及時、備份任務穩(wěn)定、監(jiān)控告警完善但一旦遇到真實故障就暴露出各種設計缺陷和配置問題。原因也很簡單正常路徑是開發(fā)人員天天走的路異常路徑是很少被走過的路。對于剛開始做容災測試的同行我給三點建議第一點測試方案要從指標反推設計。項目定了RPO和RTO指標你的測試方案就要圍繞驗證這兩個指標展開設計能夠精確測量這兩個指標的測試方法和工具。方案先于執(zhí)行測量方法先于系統(tǒng)實現(xiàn)這是保證測試不跑偏的前提。第二點故障注入不要只做一次。容災系統(tǒng)的穩(wěn)定性需要通過反復測試來驗證同一個故障場景至少執(zhí)行三次確認每次的行為一致。有些系統(tǒng)的故障切換帶有偶發(fā)性第一次成功不代表每次都成功。第三點測試記錄從第一天就要規(guī)范起來。不要等到要寫報告了再補記錄現(xiàn)場記錄哪怕潦草一點也比事后回憶可靠得多。項目收尾時整理的測試報告價值就藏在這些每天的原始記錄里。