軟件測試流程分享

1、軟件測試流程分享目 錄整體流程各階段質(zhì)量評審方式和標準Bug分布CodeReview單元測試測試用例設計功能測試性能測試異常測試1. 整體流程測試溝通溝通紀要測試設計測試設計文檔測試執(zhí)行測試報告2. 各階段質(zhì)量評審方式和標準階段評審方式通過標準啟動MRD需求設計評審項目相關人員達成一致，預判能實現(xiàn)項目目標。編碼階段CodeReview代碼走查核心模塊和邏輯復雜模塊走查。單元測試由程序開發(fā)人員完成函數(shù)覆蓋率90%行覆蓋率80%分支覆蓋率60%全面測試階段集成測試性能測試異常測試場景化測試與開發(fā)人員共同review確認達成項目設計目標。預上線階段線上監(jiān)控設計災備、預案小流量上線確認穩(wěn)定性。上線線上

2、回歸測試 邏輯BUG 代碼做了錯誤的事情，例如條件語句寫錯，變量未賦值等 銜接BUG 對象之間銜接時候出現(xiàn)錯誤，例如接口之間傳遞參數(shù)出錯等 渲染BUG 能夠用眼睛看出來的錯誤，出現(xiàn)在UI 例如頁面布局與MRD不一致典型的BUG分布情況邏輯BUG銜接BUG渲染BUG邏輯銜接渲染出現(xiàn)概率高中低發(fā)現(xiàn)難度難一般容易修復代價高中低最理想的測試方法單元測試接口測試系統(tǒng)測試3. Bug分布DAODataServicePageServiceAction模板UTST，針對渲染和銜接BUGIT，針對銜接BUGhttp請求http應答UT 針對邏輯BUGUTUTUT3. Bug分布并非所有的類都要做UT4. Cod

3、eReview何時進行開發(fā)人員每次提交代碼前，都應通過本地單測并將代碼提交team間及測試人員Review，Reveiw通過后才能入庫。優(yōu)點 保持項目整體代碼風格一致 團隊間互相熟悉代碼 提前發(fā)現(xiàn)錯誤 CodeReview 要點 遵守代碼規(guī)范，保持項目整體代碼風格一致 邏輯錯誤 異常條件考慮不足5. 單元測試單元測試開發(fā)原則 短：一般在10行以內(nèi) 平：基本上都是順序執(zhí)行，沒有分支語句，沒有循環(huán)語句 快：一個用例執(zhí)行時間在毫秒級別 一致性：測試用例多次執(zhí)行，結果一致 原子性：測試用例的執(zhí)行結果，要么是PASS，要么是FAIL 獨立性：測試用例之間獨立，即測試用例的執(zhí)行順序不影響結果單元測試架構工

4、具 c+單測框架：Gtest c+覆蓋率分析：Lcov python單測框架：unittest,nose java單測框架：Junit java覆蓋率分析：cobertura6. 測試用例設計輸入 細化的測試需求 測試的方法 相關的資源輸出 完成測試需求的數(shù)據(jù)設計 完成測試步驟 完成測試預期 可選：標識別用例的優(yōu)先級 可選：和測試需求綁定 用例間的執(zhí)行順序測試分類： 功能測試 性能測試 異常測試6.1 功能測試對產(chǎn)品的各功能進行驗證，檢查產(chǎn)品是否達到用戶要求的功能。構造輸入（正常/異常）測試數(shù)據(jù)（正常數(shù)據(jù)）配置文件（正常配置）測試環(huán)境（正常環(huán)境）測試步驟針對系統(tǒng)功能進行驗證檢查輸出數(shù)據(jù)：正確性

5、、新舊diff功能：正確性針對namespace、database 的增刪改查功能的系統(tǒng)測試。 測試輸入 測試數(shù)據(jù)：系統(tǒng)對外部數(shù)據(jù)沒有強依賴，測試使用數(shù)據(jù)可以進行構造 測試環(huán)境：單點server、后臺數(shù)據(jù)庫 系統(tǒng)配置：使用線上配置 測試步驟針對namespace、database的增刪改查，及交叉功能應用常用測試設計方法進行測試設計。 測試輸出檢查增刪改查的功能是否實現(xiàn)，數(shù)據(jù)是否正確。6.1 功能測試 舉例6.2 性能測試 - 基本概念極限性能穩(wěn)定性能預期負載性能性能壓力常態(tài)負載極限負載 壓力評估通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統(tǒng)的各項性能指標進行測試?；靖拍頒P

6、UIO內(nèi)存帶寬成功率超時率響應時間并發(fā)用戶數(shù)資源指標產(chǎn)品指標資源指標與硬件消耗直接相關。本質(zhì)反映的是成本問題。產(chǎn)品指標與場景需求直接相關。本質(zhì)反映的是效果問題。 6.2 性能測試 關鍵指標14step1分析對象設計原理 確認資源消耗類型 確認具體關注指標性能測試場景設計 架構部署方案設計 性能預期設計（穩(wěn)定、極限） 壓力方案設計step2step3step4step5環(huán)境、數(shù)據(jù)與工具選擇 環(huán)境（超時、線程、日志、硬件資源等） 數(shù)據(jù)（大小、讀寫方式、cache機制） 工具選擇（線程池、連接方式、通信方式、壓力增加方式）執(zhí)行方案 執(zhí)行輪次優(yōu)化（對比方案）結果指標分析 指標組合判斷 性能指標評估 瓶

7、頸判斷 優(yōu)化方案設計6.2 性能測試 測試方案設計6.2 性能測試 舉例消息發(fā)送平臺接口測試 測試目的：測試線上單臺機器消息發(fā)送接口的發(fā)送能力（系統(tǒng)入口接受外部請求的能力） 期望值：系統(tǒng)入口：2000QPS，單機500QPS（線上共四臺機器）；CUP_IDLE : 30以上。 性能測試過程：(1) 搭建性能測試環(huán)境，準備線上測試機器并構造壓測數(shù)據(jù)(2) 起壓線程，從10300，依次增加，遇到瓶頸后，尋找臨界屆值的點(3) 發(fā)送請求數(shù)：隨著線程的增加，請求數(shù)略有增加，保證壓測時間不低于200s6.2 性能測試 舉例性能測試結果分析：線程線程數(shù)數(shù)總請總請求數(shù)求數(shù)壓測時壓測時間間s入口平入口平均均Q

8、PS接口接口平均平均響應響應時間時間Min響應響應時間時間Max響應響應時間時間ErrCPU_IDLE平均值平均值CPU_IDLE最低值最低值（min）備注備注11010w427234.142354740.00%98.3959125010w92.41082.144356760.00%98.0094壓力時間太短，后續(xù)增加請求數(shù)。3100100w9571044.9943521060.00%98.12595QPS負增長。壓測時間過長，減少數(shù)據(jù)量。410050w4231181.3833511580.00%98.54895可以繼續(xù)開大線程數(shù)嘗試。520050w1702934.9653512110.00%

9、94.83387QPS增長明顯。但壓測時間偏短630090w2883127.4903530010.34%（3056）36.96629Cpu_idle降至28接口部分請求丟失。CPU_IDLE也低至30左右。考慮需要調(diào)低線程數(shù)，減少發(fā)送頻率。7 725075w2443072.4763513750.00%(7)31.96029發(fā)送發(fā)送75w個請求，丟個請求，丟失失7個。錯誤率接近個。錯誤率接近0。接近臨界點。接近臨界點。構造系統(tǒng)的異常場景，檢查系統(tǒng)的穩(wěn)定性、正確性 構造輸入測試數(shù)據(jù)（異常數(shù)據(jù)）配置文件（異常配置）測試環(huán)境（異常環(huán)境：CPU、內(nèi)存、磁盤、網(wǎng)絡、依賴系統(tǒng)異常） 測試步驟構造各種異常場景 檢查輸出數(shù)據(jù)：是否正常，是否與正常場景存在diff性能：性能是否有波動日志：查看系統(tǒng)內(nèi)部是否走進異常分支，異常處理是否正確功能：是否與預期一致6.3 異常測試6.3 異常測試 舉例Id1標題請求字段異常步驟構造請求字段缺失、為空的情況，查看接口返回。http:/xxx/api/getrealtimeinfobynopost參數(shù)“flightno”:”5J110”,”token”:” 12345”預期接口會有相應的錯誤提示執(zhí)行結果通過1. 當flightno取值為空