測試提前進行的越深入，越體會到了解系統架構的重要性，參與到技術方案評審，不僅是聽，還要評，進一步學會審。這個階段可以更關注可測性、性能考慮、可拓展性等
舉幾個技術方案階段關注并改進的例子.
性能考慮
關注方向：系統調用、單個\批量，串行\并行，讀tair\讀db
例子：
qc系統資質驗證的過程是，業務系統發起驗證一顆資質樹（多個資質）的請求，資質系統獲取請求后，從多個業務方系統獲取數據并和要求值進行對比，將對比驗證結果返回到業務系統
以下是技術方案時對老系統的改進.
1. 單條驗證 -> 提供批量驗證接口，避免多次HSF調用
2. 單顆資質樹資質獲取 -> 資質數據讀取方式從原有的懶加載改為預加載。合并多個資質樹的資質，一次讀取
3. 串行讀取 -> 并行數據讀取。資質數據涉及多個系統，將多個HSF調用從串行改為并行
4. 串行驗證 -> 并行驗證。批量驗證時采用并行的方式驗證
5. 提供服務方式：HSF -> JAR，本地調用和hsf調用的性能差別
6. 緩存讀取方式：只讀取所需 -> 讀取所有,減少二次讀取時對DB的訪問
DB設計 關注方向：避免分庫查詢、分表查詢、多表查詢
例子：
服務評價項目的項目目標是對客服小二處理case的服務進行評價。record表（評價任務表，一個case對應買賣家共兩條record記錄即兩個評價 問卷）、answer表（買賣家的答卷記錄，一個問卷對應多條答案記錄，recordId作為answer表外鍵），record為單表，answer分 表按recordId進行分表
問題點在answer表的分表是按照recordId進行取模分表。
這種方式下，查詢一個case對應的評價記錄：先根據caseId查詢record表獲得兩個recordId，再根據recordId取模查詢兩個answer表的記錄，再返回結果
改進方案是：在answer表增加一個caseId字段，根據caseId分表，這樣查詢答題記錄只一個caseId查詢一個answer表即獲取買賣家答題記錄。只查詢一次和查詢兩次且有分表查詢的對比，效率提升是顯而易見的
hsf設計
關注方向：異常處理
例子：
服務評價系統對外提供一個重要hsf服務，業務系統case在完結時調用該hsf服務觸發評價任務開啟。下圖是開發設計的調用流程， 主要關注紅框中的調用方式。
業務case完結是業務主流程，開啟評價是分支流程，分支流程應該是不能影響到主流程的，一個p1級應用最好不要去依賴一個p3級應用。所以，評價系統的 hsf服務不能拋任何異常給業務系統，hsf服務需要catch所有異常并包裝一個統一的返回值給業務系統，這種設計方式下，除非系統掛了服務找不到了才 可能對業務系統產生影響