作者：京東工業 宛煜昕
測驗的覆寫通常是指需求范圍的執行程度，如需求、測驗用例、缺陷的正向與逆向的雙向追溯，便于對其相關屬性的度量，即使用了覆寫率，
一、覆寫率與測驗策略
覆寫率是度量測驗完整性的一個手段，是測驗有效性的一個度量，測驗覆寫是對測驗完全程度的評測，
測驗策略按測驗程序一般分為單元測驗、集成測驗、系統測驗和驗收測驗四大階段；按軟體內部作業程序又有白盒、灰盒、黑盒；從程序是否執行軟體又可將測驗方法分為靜態和動態，這樣白盒測驗對應著軟體測驗程序中的單元測驗，一般由開發人員完成，而灰盒測驗與黑盒測驗一般測驗人員介入較多，對應著集成測驗、系統測驗和驗收測驗，
二、覆寫率的基本應用
測驗時擔心之一就是無止境的、沒有范圍的，比如代碼的改動或調整一個需求，需要全量回歸測驗，影響范圍不清楚，某個功能或功能點是否需要測驗，測驗的程度如何不清楚等等的問題，
舉個例子：需求是查詢id與展示id相關資料的功能，進一步分析要做（開發）id輸入框，【查詢】按鈕，顯示的串列，涉及1個查詢介面（HTTP），查庫（資料庫）的話，需要1條SQL陳述句，
開發后得到前端id輸入框，【查詢】按鈕和結果串列，
后端是通過一個查詢方法調到資料庫得到資料，顯示在前端頁面，
應用測驗覆寫率
1、建立測驗范圍，這里簡單些了，只是功能的
| 模塊/功能 | 功能點 |
|---|---|
| 查詢 | 輸入框 |
| 查詢 | 查詢按鈕 |
| 結果串列 | 顯示結果串列 |
2、需求分析、用例設計、執行、提bug等，就是執行測驗的程序
3、得到功能測驗的結果
| 模塊/功能 | 功能點 | 測驗結果 |
|---|---|---|
| 查詢 | 輸入框 | 測驗通過 |
| 查詢 | 查詢按鈕 | 測驗通過 |
| 結果串列 | 顯示結果串列 | 測驗通過 |
這么看上去沒什么問題，雙相的追溯（需求、用例、缺陷）已經是全覆寫了，那怕在算上介面，但也僅僅是功能上的覆寫，實則缺失了對代碼等層面上的覆寫，
比如：代碼中要有對查詢id的判斷，這里可能會有所遺漏，因為僅從功能或黑盒測驗來講，不知道這個判斷是否執行，
這時測驗覆寫是要由測驗需求和測驗用例的覆寫或已執行代碼的覆寫表示，建立在對測驗結果的評估和對測驗程序中確定的變更請求（缺陷）的分析的基礎上，
在"2、需求分析、用例設計、執行、提bug等，就是執行測驗的程序"要介入代碼覆寫率的工具，彌補這一缺失，覆寫率的表格也需要優化下，
后邊的類、方法的覆寫率可以根據情況不同自行獲取
| 功能/模塊 | 功能點 | HTTP介面型別 | HTTP介面 | 類名 | 方法名 | 覆寫率 | 測驗結果 |
|---|---|---|---|---|---|---|---|
| 查詢 | 輸入框 | 無 | 無 | 無 | 無 | 100% | 測驗通過 |
| 查詢 | 查詢按鈕 | POST | /api/queryById | query | queryById | 100% | 測驗通過 |
| 結果串列 | 顯示結果串列 | POST | /api/results | query | results | 100% | 測驗通過 |
覆寫率的計算由淺入深來說一般從功能、功能點、介面、代碼中類、方法等得到，如：兩個功能、三個功能點，以功能點為覆寫，覆寫率公式為（至少執行一次的功能點 / 功能點總數）* 100% = (1 / 1)*100%，查詢按鈕的覆寫率為100%
注：測驗結果是否通過，不單是看覆寫率，還要通過測驗用例的執行，缺陷的關閉等情況來決定，
三、可視化系統
通過完全手工繪制已經有了初步概念，考慮些許情況，這種已經不能滿足于此，
面對復雜的業務系統，經驗已經把業務功能、邏輯關系等相關知識點深深的印在當事人的腦子里，而要沉淀、展示于旁人，這就是一個讓人很頭疼的問題，就像告訴一個人從哪里到哪里一樣，講的人清楚，但聽得人卻有些一頭霧水，此時如果有個地圖就一目了然了，
通過一些維度的圖形展示，誰都可以直觀、更好的加深對系統的了解，"知識庫"中保存著涉及到的功能、介面等資訊，簡單實作，現在有了共享表格，可以直接維護上去，形式是哪種并不重要，主要是掌握了方法，
鏈路關系像這樣，業務系統-頁面-功能-介面-代碼（拓撲圖），業務系統-頁面-功能-介面-架構（拓撲圖），
·功能層面
實作方式上比如可以像檔案目錄那樣實作一顆樹，某個頁面下有哪些功能，功能中有哪些介面，而介面中有代碼的類、方法及覆寫率等資訊，
或者可以采用類似知識圖譜來構建一個結構化的語意知識庫，頁面、功能、介面資訊，可視為物體-節點，而彼此間的關系既是連接的線，或者介面資訊也可看做是屬性值，
·代碼層面
從介面下去就到了代碼層面，可以看到代碼的關系拓撲圖
這里不僅能看到單個介面中代碼和關系圖，還能展示出不同介面與代碼的關系
當關注到代碼層面的覆寫后，好處很多，其中之一是可以更好幫助開發提高或約束代碼質量，比如：代碼中有時判斷會使用常量，而不是列舉或宏/全域變數，當然也可以看到執行的代碼分支，每條代碼邏輯分支是否執行到，
·架構層面
通過平臺獲取到的資料，不僅可以做功能、代碼層面的覆寫，系統架構也可完成可視化的呈現，
比如：應用服務的環境模塊拓撲圖
分布式呼叫鏈的拓撲圖
還是用查詢功能舉例，有時因為一些需要，該功能下使用了快取，當第一次查詢是直接從資料庫中查詢回來的資料，同時也在快取中記錄了該條資料，而在一定時間內再查詢，實則是從快取中查詢回來的，同樣的，如果只覆寫了功能，這里可能會有所遺漏，從功能來看，查詢后資料是回傳了，而至于是從資料庫還是從快取獲取到的，就不得而知了，再有是獲取到的資料可能未必是想要的，奇怪的是，為什么輸入/請求的資料，功能、介面都是一樣的，而回傳的資料在一段時間后就發生了變化，中間發生了什么不清楚，真的是"黑盒子"，想要知道SQL陳述句，只能費勁的從日志、代碼或xml中查找，還有等等的不便問題，
除此之外，還可以展示不同介面與資料庫的關系
只要腦洞夠大，通過資料還可以實作出很多覆寫，并呈現出各種可視化圖形，
四、未來已來
使用資料驅動將抽象的字符、邏輯等等可視化展示，從而得到想要的效果，但這種效果無論是靜態或動態產生的、主動或被動的等等，都會遇到時間的問題，而對時間有著強依賴的我們，無論采用哪種開發方式，即使在快，有著時間的限制和約束，這種苦惱始侄訓伴隨著，在現實世界中目前是無法解決，但有了虛擬世界，現在叫元宇宙，那就不同了，里面有還原現實一切的1比1模型，在虛擬世界里，可以搭建出想要的系統，每一個環節，無論是從專案或需求、產品設計、開發、測驗到上線等，都可以清晰的關注到，無論功能與非功能均可以進行模擬，原來的專案或開發周期可能要1年，而現在可能半年不到的時間，虛擬世界的一切貼近現實，最終是通過空間換取時間從而得到這寶貴的經驗，然后這種虛擬產物可以搬到現實世界進行應用，從而避免很多試錯，也大大壓縮、節省了時間，目前這種方式已經慢慢被應用到各個行業、領域，這種虛擬與現實的結合可以更好地服務我們的生活，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/541699.html
標籤：大數據