可測性需求

彙總了各種資源，總結了一份系統可測性需求。制定可測性需求時，應結合當前組織的技術基礎和項目特點，以下內容並不適用於所有組織和項目。
歡迎大家拍磚討論。

1. 可觀察性

1.1 更容易觀察到測試結果

1.1.1 交易記錄是否完整

清晰完整的交易日誌能夠提升問題分析和定位的效率和準確率，並能夠用於復現問題。交易日誌記錄應滿足如下要求：在測試環境通過調整日誌記錄的級別，實現記錄包括系統內及系統間接口調用的輸入、返回報文，及請求數據庫的SQL和存儲過程（包括傳參）。系統記錄的交易全鏈路日誌必須完整，建議在應用開發設計過程中，根據交易重要程度、交易調用鏈複雜度和便於問題跟蹤排查等因素綜合考慮，將交易日誌寫入數據庫日誌表或者交易日誌文件中。

如果系統面向互聯網開放，用戶訪問和操作存在較大不確定性，因此建議對用戶操作行爲和路徑進行埋點統計，便於持續迭代過程中系統功能設計與測試案例的設計。系統埋點應覆蓋客戶端操作界面的主要業務操作所涉及的頁面和交互控件，並在相關設計文檔中體現埋點的覆蓋範圍，以及埋點統計信息的保存方式和訪問方式，便於通過接口或數據庫對埋點統計數據進行分析。

1.1.2 交易異常是否有明確輸出

遵守開發規範，將系統或交易異常寫入日誌文件。

1.2 版本狀態可查

應用系統各個節點中應記錄當前版本號和版本更新實踐（例如應用節點操作系統的文件、數據庫表），並將更新版本狀態標誌的操作集成進版本實體中，在版本安裝過程中實現自動更新。

1.3 交易路徑可查

1.3.1 業務執行狀態和過程可觀察

通過獲取業務執行的過程狀態，並配合相關係統功能設計文檔，可以準確的判斷交易的各類過程狀態與功能設計是否一致。對於業務狀態的記錄需要滿足以下要求：對於交易的當前狀態和終態結果有明確的記錄（包括狀態標誌、更新時間、操作用戶），並且能夠記錄在日誌或數據庫表中。

1.3.2 調用鏈可查

如果系統交易爲長流程交易，通過調用鏈監控可以準確的識別系統內和系統間調用鏈，提升問題分析定位效率，輔助測試案例設計與執行。對於全鏈路調用鏈監控，主要有以下三種實現方案，取得的效果也不盡相同，項目組可以結合自身技術架構進行參考。具體如下：

對於分佈式架構的系統，可以通過在日誌中記錄交易唯一流水號實現分佈式架構系統內調用鏈的展現。
對於跨系統交易，通過系統間全局交易流水號或利用APM技術在報文頭中打入序列號實現系統間調用鏈的展現。
利用商用或開源APM技術，通過埋點或字節碼增強技術，實現測試環境系統內和系統間的全鏈路調用鏈展現。

2 可控制性

2.1 適於自動化測試

2.1.1 測試數據準備

測試過程中需要大量測試數據支持，尤其對於消費型測試數據，需要持續補充可用的測試數據。通過手工模擬真實業務交易準備測試數據效率較低，而且受限於各類交易控制，難以滿足所有測試數據需求，因此需要支持通過自動化交易或後臺數據庫方案完成各類測試數據準備的需求。

2.1.2 界面穩定性

爲了保證補丁頻繁迭代下的測試環境穩定性和持續迴歸測試的需求，需要對核心業務流程通過自動化的方式進行驗證。自動化測試方法主要通過UI和接口兩種方式發起，對於UI發起的自動化測試，實施步驟首先定位頁面元素/控件，然後操作元素/控件，通過模擬手工操作的過程完成業務流程的測試。因此前端頁面元素的穩定性和標準化對於自動化測試腳本的穩定性和可用性至關重要。因此在頁面組件屬性、佈局等發生變動後，即便是不影響業務功能也需告知測試，便於測試人員相應調整自動化測試腳本，保證測試腳本的可用性。

2.1.3 組件標準化

同模塊開發時使用統一標準的組件，避免出現不同模塊相同類型的組件（例如輸入框、級聯下拉框等）開發方式不同的情況，開發過程應遵守統一的組件設計規範。通過上述策略，可以儘可能保證前端功能的正確性和可操作性，減少UI層面的缺陷。

2.1.4 驗證碼開關控制

出於系統安全的需求，系統在登錄或資金操作環節都會設計動態或圖形驗證碼。在自動化測試和性能測試過程中難以有效從UI層面模擬驗證碼的操作，需要應用設計時同步考慮，主要有以下幾種解決方案：

通過臨時替換程序的方式，屏蔽驗證碼的功能。替換臨時程序的步驟可以集成在啓動腳本中，將需替換的程序（包含程序相對路徑）先放到系統臨時目錄下，在啓動時先判斷臨時目錄是否存在文件，如果存在則將替換成copy到對應的目錄，再啓動服務。
通過系統後臺開關的方式，屏蔽驗證碼的功能。建議通過數據庫參數開關進行控制，避免每次裝版後都需要手工修改應用配置。
能夠從後臺數據庫或接口服務獲取驗證碼實際校驗值。

2.1.5 前後臺調用記錄可查

對於利用C/S架構開發的客戶端程序，能夠有方法獲取前後臺接口調用情況，同時可以通過調試工具或端口捕獲前後臺調用中出現的錯誤和異常信息，用於發現和定位問題。

2.2 適於功能測試

2.2.1 支持測試環境跳日期場景

爲了模擬生產環境特殊日的驗證需求（如月末、年初、年末、閏年2月29日等），測試環境日期無法與自然日期保持一致，且有可能存在多個自然日保持同一個系統日期的情況。因此在系統需要支持測試環境日期不連續的特點，比如跳過某段時間的日終批量，對於無法支持跳日期的功能要有記錄。

2.2.2 配置參數實時生效

主要業務配置參數重新調整後，不需要重啓應用即可生效。

2.2.3 KEY開關控制

對於需要外設KEY（類似U盾）驗證的業務操作，有開關控制、程序模擬或單獨的不插KEY校驗的客戶端等方法跳過驗證。

2.2.4 報文模擬器

對於涉及第三方聯調的接口，對於第三方返回接口內容定義清晰，可以通過模擬第三方發起和返回報文在測試環境完成相關交易流程，無需第三方的真實接入。

3 可分解性

3.1 投產風險可控

應用面向互聯網接入，應用架構設計時應具有灰度發佈的能力，控制應用投產對客戶使用引入的風險。
生產系統應具有投產後的專用測試驗證用戶，用於在系統投產後第一時間在生產環境驗證項目修改的內容。

3.2 配置分級原則

應對版本安裝過程中需要客戶化的參數進行統一管理。
應用外部劃分出全局級變量，在頂層進行管理。
在應用內部劃分應用級、服務羣組級、環境級3層變量，每層都遵循統一的命名前綴和規則。
環境級支持對變量進行應用服務節點級和應用服務節點實例級（IP級）的管理，進行特定值的維護。

4 穩定性

4.1 准入測試案例及標準

集成測試、SIT測試、UAT測試複用核心測試案例，保證各個階段的測試工作對於需求和測試對象理解的一致性。

4.2 各階段測試質量門禁

在項目的開發、測試階段應有每個階段明確的准入和準出標準：
開發階段：

代碼檢查覆蓋率；
單元測試代碼覆蓋率；
集成測試&上下游聯調測試案例通過率；
集成測試缺陷修復率；

系統測試階段：

系統測試准入案例通過率；
核心功能測試覆蓋率；
系統測試案例執行通過率；
系統測試缺陷修復率；

對於以上各個階段的質量標準應有明確的定義，以項目質量管理文檔和測試總體方案爲準。

4.3 問題及缺陷管理流程

4.3.1 問題及缺陷管理

缺陷類型明確，不存在交叉；
缺陷責任人明確，誰處理誰答覆；
缺陷狀態明確，儘量減少擱置類的狀態；
提高缺陷提交質量，對於嚴重缺陷和疑似環境問題，需要經乙方測試組長和甲方測試經理把關；
建立缺陷升級機制，每週設瓶頸&爭議缺陷推動會。

4.3.2 補丁管理

缺陷管理與補丁管理應能夠聯動，或具備缺陷與補丁信息關聯的方法，能夠通過版本補丁部署獲取到缺陷的修復信息，並能夠同步更新缺陷狀態。

4.4 需求變更可控

4.4.1 體驗測試

在SIT階段，當系統核心功能穩定後，儘可能提前安排一輪體驗測試，邀請業務驗收測試人員參與體驗測試，用於驗證系統功能實現與業務實際需求的一致性，提前暴露需求層面的風險和用戶體驗方面的問題，減少測試中後期的業務需求變更。

4.4.2 需求變更

對於測試期間的需求變更，應有嚴格的需求變更管控機制和審批流程，並提供需求變更影響性分析說明，相關信息能夠同步至研發、測試干係人，用於需規和案例的調整。

5 易理解性

5.1 文檔完備性

5.1.1 系統功能清單

建議建立程序實體與業務功能的映射關係，包含功能名稱、所屬系統（例如登記、客戶管理、結算等）、性質（新增或修改）、功能類型（聯機程序、批量程序、接口、作業等）、負責開發人員等信息，通過上述信息構建測試用例與程序實體間的聯繫，便於後續分析定位問題原因和精準測試，同時便於測試規劃分工和與開發人員的日常溝通。

5.1.2 系統操作說明

提供系統使用手冊，在測試過程中進行參考，並針對手冊中的問題反饋應用開發組進行修改。

5.1.3 項目文檔

《業務需求說明書》：確認客戶需求或產品的質量需求都是明確的、可預見的並被描述在文檔中，將來可以用於某種方法來判斷、驗證這種需求或特性是否已經得到了實現；需求描述足夠的清楚和明確，可以作爲開發設計說明書和功能性測試數據的基礎；系統的非功能需求（如性能、可用性等）有明確的定義和標準；各種故障模式和錯誤類型都有明確的處理方式。
《系統用例設計》：用例能夠在業務需求中找到相關方法、模板、輸入輸出等要求；按照模板要求填寫系統用例描述表中的各項內容；按要求描述用例的基本事件流；按要求描述系統用例的備選流和異常流；引入業務建模4級任務定義中的業務規則定義；根據《錯誤信息編寫規範》定義系統用例執行中可能拋出的錯誤；按標準輸出完整的用例場景圖；描述系統用例中所需調用的交易服務、本地構建、應用批處理等服務的名稱、服務版本及服務提供方等相關信息。

5.1.4 接口文檔

接口文檔應明確以下內容：

功能明確；
參數有意義，遵循新一代接口設計規範；
提供完整的接口調用方清單（不僅限於當前項目）。對於微服務或服務化接口，建議被調用方接口對調用方應用進行白名單配置，避免未知情況下的調用引發的接口服務性能容量的風險。