測試提前-技術方案評審

　　測試提前進行的越深入，越體會到了解系統架構的重要性，參與到技術方案評審，不僅是聽，還要評，進一步學會審。這個階段可以更關注可測性、性能考慮、可拓展性等

　　舉幾個技術方案階段關注并改進的例子.

　　性能考慮

　　關注方向：系統調用、單個\批量，串行\并行，讀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所有異常并包裝一個統一的返回值給業務系統，這種設計方式下，除非系統掛了服務找不到了才可能對業務系統產生影響

原文轉自：http://www.taobaotest.com/blogs/2532