測試提前 技術方案評審

2021-09-23 13:47:44 字數 1574 閱讀 7702

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

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

效能考慮

關注方向:系統呼叫、單個\批量,序列\並行,讀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所有異常幷包裝乙個統一的返回值給業務系統,這種設計方式下,除非系統掛了服務找不到了才 可能對業務系統產生影響

測試評審初試

測試案例是貫穿了整個測試流程和專案研發流程的,用例也同時起著指導測試 保證質量度作用,因此用例至關重要。對於如何提高用例設計的質量,評審是必不可缺的一環。很多測試同學都知道應該做測試案例評審,並且也樂意做需求評審,但是很少有測試同學總結過如何做案例評審。那麼最基本的案例評審應該從哪些方面著手呢?在開...

靜態測試之評審

評審包括管理評審 審查 技術評查 走查和非正式評審等不同評審技術。評審的通用過程由以下6個階段組成。1 計畫階段 選擇評審員並分配角色 為正式的評審型別規定評審的入口和出口準則,以及選擇需要評審的文件和文件章節等 2 預備會階段 分發文件,向評審參與者解釋本次評審的目標 過程和文件,以及核對入口準則...

測試基礎 同行評審

同行評審 1.是由開發軟體產品作者以外的其他人檢查工作產品,以發現缺陷並尋找改進的機會 評審方法是評審參與者通常採用一行一行仔細閱讀被評審物件的形式發現被測物件中的缺陷 評審的時間點一般設在工作產品到達了乙個完成的里程碑並即將進入下乙個開發階段時 2.同行評審一般包括審查 小組評審 走查 桌面評審 ...