測試流程注意事項

 

一 需求分析階段

二 設計分析階段

三 開發聯調自測階段

四 提測階段

五 測試執行

六 上線階段

七 運營階段

 

 

一 需求分析階段

 

1.業務修改

現有業務修改是否清晰 核心邏輯是否遺漏

有無業務衝突

 

2.用戶體驗和影響

交互是否合理

會不會拉長交易流程

干擾用戶選擇

下單和支付響應時長

 

3.周邊業務線的影響 是否清晰描述上下游系統的影響

 

4.安全

黑白名單

反做弊

開關

規則和閾值

 

5.舊數據兼容

 

 

二 設計分析階段

 

系統結構：

針對項目需求，結合業務現狀來評估RD設計的系統修改點是否合理

模塊、系統間使用了什麼接口、中間件進行通信（http、dubbo、mq、緩存、數據庫、定時任務等），是否合理，例如dubbo循環依賴等

- 畫出當前的系統結構圖

- 標註出系統結構的改動點

 

數據流：

能不能拿到本身想要的數據，作出的修改是否會對現有系統形成負面影響，例如數據結構不兼容，緩存結構不兼容等

- 接口和接口字段的CUD（增、改、刪）

- 數據存儲的變化（表、字段）

 

三 開發聯調自測階段

 

1.根據需求和設計文檔進行case設計和評審（後續自動化case同步進行？）

 

2.測試環境準備

分支 sql ng 權限配置等

 

3.跨團隊項目的上下游溝通

 

測試計劃溝通

和上下游模塊溝通各自負責的測試計劃安排、測試範圍、測試重要場景、跨團隊 測試數據的構造、配合的方式，把團隊間的影響降到最低。

環境對接

咱們須要瞭解上下游關係，相互之間接口的調用問題，接口是否溝通清楚，接口是否知足需求等，確保聯調環境的進度。

熟悉業務

跨團隊項目須要瞭解對方的業務、申請權限等，避免後續影響測試進度。

 

4.測試策略溝通

 

提測方式

核心功能的單元測試

測試工具提供（dubbo、定時任務封裝http，異步轉同步，後門工具等）

 

注：關注聯調階段出現的問題

在後面測試階段有可能遇到的問題，絕大部分都會在這個階段暴露，並對case進行補充

 

 

四 提測階段

 

1.開發自測case執行,pm測試前置？

 

2.自動化經過

 

3.code review經過

 

4.code diff 前置？

 

一、爲何要code diff？

 

評估影響面

補充測試點

確認需求實現

提早發現問題

確認發佈步驟

QA加深對技術實現的理解

 

二、什麼時候進行code diff？

 

code diff 須要貫穿整個測試過程，主要是一下三個時間點。

提測時：獲得本次代碼的改動範圍、使用branch代碼與master代碼全量diff

改bug後：確認開發代碼的提交量、測試的迴歸量，使用修改先後打出的btag進行增量diff

發佈前：確保本次發佈的代碼與測試代碼一致，使用測試經過的btag與master代碼全量diff

 

三、code diff關注點

 

接口變動

提供方，入參和返回值發生變化須要，確認全部調用方是否能夠知足

調用方，調用新接口。須要注意是否添加異常處理？是否重試？超時時間是否合理？

 

代碼層面

循環結構、遞歸調用，要檢查退出條件，避免死循環

全局考慮代碼實現是否與需求文檔一致，功能是否都已經覆蓋，條件分支結構，結合業務判斷是否有遺漏分支；邏輯是否都是完整閉合的，注意邊界值，條件判斷語句參數爲空是否發生空指針異常

運算表達式，需注意精度計算問題

針對複製了一段代碼，確認業務邏輯

某個數據對象改了， 須要找到該數據對象被用在哪些地方，驗證其展現、存儲、對對外接口的影響；尤爲考慮模塊下游是否有影響，是否也應該作相應的變動。

基礎類修改，要檢查全部調用方，一層一層直到找到對應可進行驗證的UI或系統功能，補充對應的功能測試點

緩存使用，補充測試點

有沒有多改（搭車無關代碼）,少改（少改方法、少改入口等等）？

 

配置相關

確認第三方服務的配置，包括dubbo、mq、地址、超時時間等

prod配置是否正確。包括被調用方的地址，數據庫地址

beta的配置禁止使用的線上地址，反之亦然

pom.xml文件，版本號是否正確，線上不能有snapshot版本

 

監控

監控一般分爲系統監控和業務監控，在diff時須要與開發和產品充分討論哪些事件發生是須要技術/運營實時知道或每隔一段時間都須要瞭解狀態的

系統監控：一般虛機提供時，無需在代碼中添加

業務監控：一般在關鍵業務節點上添加，好比常見的接口調用次數、響應時長、任務成功/失敗/異常監控

dubbo監控：須要在代碼中添加dubboFilter對dubbo的調用進行監控（增長dubbo的Filter）

其餘需求：一般不方便進行測試或線上驗證的業務場景，能夠考慮添加監控驗證

 

日誌

業務日誌：通常在請求入參、出參處都要打印日誌方便排查問題，線上日誌需考慮性能相關問題（數據量、磁盤io問題、清理時間等）

異常日誌：須要在diff過程明確catch住可能存在異常的部分，打出異常堆棧以及重要參數，注意空指針；若是是正常業務的異常分支，那麼就須要有明確的業務輸出或記錄，而不是拋出exception

分級：日誌分級別，調試使用debug，運行時日誌使用info，系統遇到問題使用warn，系統遇到異常使用error

 

發佈相關

第三方服務發佈、以及權限申請

上線前發佈依賴jar包不含snapshot

根據調用依賴關係，確認發佈和回滾順序

 

安全

日誌、數據庫、緩存中不容許出現身份證號、手機號等敏感信息

鑑權，是否須要再校驗

 

異常

須要在diff過程明確catch住可能存在異常的部分，打出異常堆棧以及重要參數，注意空指針

若是是正常業務的異常分支，那麼就須要有明確的業務輸出或記錄，而不是拋出exception

 

性能

代碼中多重循環和if判斷不要超過三次

獲取大量數據時，分批次獲取；儘可能採用批量SQL語句

 

四、code diff產出

 

測試範圍/checklist

bug

發佈和回滾步驟

系統結構設計改進意見

 

 

五 測試執行

 

業務

1.檢查工具或者抓包工具看接口

2.服務器日誌

3.數據庫和緩存變化

 

接口

方法：http postman等。 dubbo 業務覆蓋、轉http、單元測試、工具

 

測試點：

功能：

 

數據

類型

a. 類型使用是否正確（尤爲是http接口）,例如使用String仍是原始類型

b. 枚舉的常量選項是否正確

精度

a. 是否符合要求，一般金額爲2位小數

b. 獲得的數據是否會自行調整精度(截斷或者四捨五入不可取，應該直接校驗傳入的精度)

時間

a. 該使用日期(2015-11-12), 仍是時間(2015-11-12 14:00:00), 仍是時間戳(1449849600000)

b. 時區：服務器的日期是否會根據請求者的時區進行轉換；或者在request中和response中直接帶上時區信息

單位

a. 時間單位時秒仍是毫秒

b. 金額單位是分仍是元

 

長度 是否夠長，超過部分是否截斷仍是發出警告

 

 

數據流

經過系統結構和數據流瞭解數據的流向、轉換、落地等，考慮數據傳遞過程當中的轉換、封裝、組裝、數據丟棄、精度丟失等狀況

1. 數據庫到bean

2. bean處理後(例如，filter)向下層吐數

a. bean之間的轉換

b. dubbo之間的傳遞

等等

 

接口異步和無序

對於一些依賴先後接口返回的邏輯，考慮接口異步、讀寫庫時間差、讀寫接口時間差是否形成業務異常

 

兼容和影響

先後端兼容（字段變動、返回值變動、枚舉等）

接口上下游兼容（包括外部系統的影響）

安全

權限

水平越界

垂直越界

敏感信息

 

mq消息

1.發送的mq消息內容是否正確

2.消費者是否成功

3.重複消費的冪等

4.消息無序

5.消息的積壓

 

緩存

緩存的更新時機有哪些（task定時更新、MQ消息推送、業務操做觸發、手動觸發後門接口、重啓應用加載等），是否存在未更新緩存時出現髒數據

緩存數據是否正確

緩存是否生效

緩存有效和失效時，業務是否正常

緩存的失效時間

緩存被擊穿後的處理

內存緩存多部署機器的數據同步

緩存容量

緩存的命中率

 

 

性能

1.正常的性能測試

2.分析：從業務量估算接口的調用次數，經過上線前監控獲得的接口訪問次數、時間、服務器負載，分析本次上線增長的調用量是否有性能問題

 

定時任務

測試點無需過多闡述

須要考慮的點：

1.執行時間

2.被打斷後，業務是否容許

 

 

六 上線階段

 

過程當中通常是開發觀察日誌、QA關注監控和業務數據

 

上線階段通常考慮的點：

 

1.ng

2.sql（確保跟測試環境一致）

3.db redis 申請或者執行

4.洗數據腳本

5.topic申請

6.菜單/權限等配置

7.收權限 周知相關人等

8.接口或者機器白名單

9.機器權限 發佈權限等

10.btag檢查

11.模塊發佈步驟

12.驗證步驟

13.回滾步驟

 

 

七 運營階段

 

1.核心監控和報警（新上線業務 數據穩定後檢查報警是否合理添加閾值）

2.日誌、功能巡檢或者郵件報警

3.問題反饋渠道

4.業務數據變化