一個項目的整個測試流程

最近一直在進行接口自動化的測試工作，同時對于一個項目的整個測試流程進行了梳理，希望能對你有用~~~

?

需求分析：

• 整體流程圖：

需求提取 -> 需求分析 -> 需求評審 -> 更新后的測試需求跟蹤xmind

• 分析流程：

1. 需求提取：

• 分析依據（包括：需求矩陣、產品交互圖、需求說明書）
• 獲取需求的緯度
• 客戶價值
• 可以為客戶帶來哪些價值？
• 可以解決哪些問題？
• 根據以上問題定位功能是否合理
• ?UI功能 - 展示功能
• 模塊關聯-歷史模塊
• 新功能模塊關聯
• 考慮是否關聯？耦合部分是否需要支持？
• 客戶使用場景-部署方式
• 網絡特性
• 客戶使用服務器常見外設
• 性能參數-性能要求
• 網卡最低速率
• 硬件支持
• 輸出（提取最原始的測試需求）

2. 需求分析：

• 分析依據（五維分析）
• 用戶場景

1. 功能是否和場景強關聯
2. 網絡拓撲能否滿足客戶需求
3. 和競爭對手比較差異
4. 功能是否能滿足客戶實際應用場景
5. 是否考慮了用戶的實際操作

• 明確性

1. 范圍明確性（參數、類型長度范圍）
2. 清晰性限制等范疇
3. 無法預知影響的需求提出進行確定，風險

• 二義性

1. 概念模糊【大概念、第三方支持、與上個版本相同】
2. 支持與不支持等范疇
3. 一個需求描述能出現多種理解

• 完整性

1. 需求一致性【用戶需求、需求規格、需求矩陣三者是否同意】
2. 需求完整【隱形需求】
3. 關聯性【與新老功能、與外置軟件設備】

• 可測試性

1. 實現測試需要的工具、方法【調試、接口命令】
2. 定位方式【日志等形式觀察】
3. 復雜環境、容量邊界、操作時過程不可見

• 輸出

1. 測試需求跟蹤
2. 缺陷預防bug
3. 工具需求
4. 整理出明確的需求點
5. 測試地圖

• 分析思路誤區：需求和實現的區別【現有需求才有代碼實現，不能把代碼實現當作需求】
• 需求分析的意義

1. 明確產品給客戶帶來的價值
2. 明確產品支持和不支持的功能
3. 明確產品各個功能的約束性
4. 知道開發實現功能
5. 知道測試分析和產出測試點

?

測試設計：

• 測試分析：

1. 我們需要做什么？

1. 把明確的需求點轉換成測試項
2. 缺陷預防

2. 怎么做？

1. 整體模塊分析
2. 邏輯分析【這一點主要是從產品實現的原理上去分析可能的影響】

• 怎么做？
• 開發的設計文檔
• 補充和挖掘測試點

1. 全部服務的異常監控、服務重啟
2. 各類存儲對空間的占用、占滿、是否需要做存儲的接口測試
3. 所有類型的管理員、操作權限測試、支持的多少管理員并發操作
4. 對流程圖的挖掘 -- 流程圖全部流程測試、流程圖重要的節點異常測試
5. 對狀態的挖掘 -- 所有狀態的相互轉化需要覆蓋全、狀態轉化是否合理、每一個狀態下哪些操作可做哪些不可做，多個狀態是否可以共存
6. 對關聯項的挖掘 -- 流程進展到哪一步關機重啟/服務重啟、和備份配置的關聯，和操作日志的關聯等等
7. 任務的并發操作測試、是否可配置、是否會出現性能不足，是否符合用戶場景
8. 異常處理機制測試，異常處理機制是否完善
9. 指標測試，開發的指標設計是否合理

• 修正不合理的需求
• 如何分析
• 邏輯原理：

1. 該模塊是否涉及到一些全新的概念(比如我們的 bbc 全量包)，需要明確?
2. 該模塊包括哪些服務?
3. 該模塊涉及到哪些存儲技術(如 mysql、dap、redis)?具體怎么存儲的?占用大小如何?
4. 該模塊的操作流程有哪些?是否有子流程圖?
5. 該模塊是否有多個狀態的轉化?是否有明確的狀態轉化圖?
6. 該模塊對多個管理員是否區分，管理員權限如何設計?
7. 該模塊是否有一些特殊的操作限制?操作限制是否有明確的表格?
8. 該模塊的任務是否有并發需求?并發的設計?
9. 該模塊的所有指標如何?
10. 該模塊是否有異常處理機制?在設備各種異常時，該模塊的設計是否滿足能穩健運行?

• 場景分析

1. 從用戶的使用習慣和使用方法去分析影響
2. 檢查當前案例是否覆蓋到用戶場景

• 關聯測試分析：

1. 考慮你的模塊所在整個系統的地位，分析上下游的影響
2. 對老功能的影響

• 經驗補充分析

1. 版本分析
2. 模塊分析

• 輸出

1. 測試項
2. 補充測試地圖

?

• 測試設計：

1. 需要做什么？

• 把測試項細化成測試點?
• 缺陷預防?

2. 需要做什么？

• 基本設計方法

1. 等價類劃分法【將輸入域和輸出域劃分為不同的等價類，等價類之內的操作結果相同】，使用范圍：顯示輸入框輸入
2. 邊界值法【需要結合等價類劃分法方法，在劃分出來的等價類選取有代表性的值】
3. 正反對比【一般會放到同一個用例里覆蓋】
4. 字符多樣性【考慮不同字符的輸入】
5. 測試類型

• 產品專項測試
• 正交組合設計【正交矩陣，覆蓋各個參數間的組合情況】
• 業務邏輯設計【根據業務設計測試點】

3. 輸出：

• 基本測試點

?

用例設計：

1. 需要做什么？

• 把測試點用文字完整表述出來

2. 怎么做？

• 功能用例框架：
• 模塊框架模板
• 需求類
• UI測試【如果UI用例可以被功能用例覆蓋，這里可以不寫】
• 公共測試類：
• 鏈接

1. 選中會有高亮顯示
2. 點擊跳轉到對應頁面
3. 當前頁面對應的名稱下有區別顯示

• 翻頁
• 按鈕
• 輸入框【這個功能用例一般可以覆蓋】
• 下拉框
• 排序
• 條目選擇【這個很重要，第一次集成測試一定要保證每個選項都是有效的】
• 搜索

1. 所有字符類型驗證
2. 為空驗證
3. 模糊搜索
4. 精確搜索
5. 搜索不存在的關鍵詞

• 刷新

1. 驗證自動刷新
2. 驗證手動刷新
3. 驗證持續刷新

• 拖動
• 移動

1. 點擊下移，往下移動一行
2. 點擊上移，往上移動一行
3. 最上面的行，上移不能點擊，圖標灰色
4. 最下面的行，下移不能點擊，圖標灰色

• 功能測試
• 測試點：

1. 功能基本流程邏輯覆蓋
2. 業務流程多樣性覆蓋
3. 用戶操作習慣的多樣性
4. 模塊配置的多樣性
5. 數據流的多樣性覆蓋

• 測試目錄

1. 平級分類相對獨立
2. 上下級分類有關聯
3. 下級從上級細化而來

• 關聯類：

1. 模塊與模塊之間的
2. 模塊與功能之間
3. 模塊與硬件之間

• 場景類
• 建模思路

1. 部署方式【比如用戶一般使用2主機還是3主機部署集群】
2. 數據流
3. 業務流【用戶是怎么使用申請工單，是怎么樣的完整流程】
4. 操作順序【創建云主機的順序之類的】
5. 配置方法【用戶一般怎么配置使用靜態路由】
6. 使用時間【用戶會不會連續長時間開啟云主機】
7. 用戶角色【一般那些角色做什么操作】

• 用戶操作的設計方向

1. 最常用的功能
2. 最容易出現網上問題的功能
3. 典型客戶使用的功能
4. 版本的性能驗證

• 專項類

1. 兼容性
2. 可靠性【測試產品在異常情況下能否正常工作或者是恢復正常工作，可靠性重點測試對模塊自身處理的覆蓋】. 補充：容錯性測試【測試系統在非正常操作、非正常的外部環境下是否能夠處理錯誤和正常運行】

eg：

1. 1. 針對數據庫的測試：【磁盤空間不足、數據庫文件損壞、無讀寫數據權限、寫數據時斷電、寫數據時強制關閉mysql、讀寫速度】
   2. 針對網絡設備：【網絡中有攻擊數據、丟包時延大、IP沖突、網絡線路斷開、同時掉電】
   3. 針對程序：【 客戶端進程被手動停止、設備后臺資源cpu、內存占滿】

3. 安全性【主要是驗證程序有哪些缺陷可能會造成安全方面的問題】

eg：

1. 1. 密碼加密方式【什么時候用明文，什么時候用密碼顯示】?
   2. 隱私數據隱藏【用戶的隱私顯示】
   3. 設備的完整目錄【完整的目錄會增加后臺被攻擊的危險】
   4. 文件上傳功能【檢查上傳的文件類型；限制上傳文件的權限】
   5. 防暴力破解【對于連線認證之類的操作要凍結、禁用其連續錯誤嘗試操作】

4. 腳本測試

• 使用注意細節

1. 文件夾以01-xx，02-xx區分開
2. 每個文件夾下不能超過10個用例
3. 每個測試用例一個測試點
4. 在02-功能測試的描述中，備注說明功能測試框架的思路

• 用例整體規范
• 用例標題【好的標題需要準確的表達你的測試目的、要測試的測試點】

eg：

1. 測試。。。
2. 驗證。。。
3. 。。。的測試
4. 與。。。的關聯測試
5. 。。。的異常測試
6. 。。。的兼容性測試

• 用例屬性

1. 測試環境【默認的前置條件可以不用寫；寫的前置條件要準確，不要寫的模糊】
2. 測試方法
3. 優先級

• BVT【最最最基本的功能】-BVT(10%)：模塊最基本的功能驗證(含常用部署、基本關聯)，推薦1級用例的20%左右
• level1【基本操作、基本場景】-Leve1(30%)：基本需求點，基本邏輯，基本可靠性，基本關聯，基本用戶場景
• level2【比較少見的正常操作】-Leve2(40%)：常見功能/邏輯細化點/專項細化點，常見關聯/容錯/邊界值/用戶場景
• level3【異常操作；后續不需要再執行】-Leve3(20%)：錯誤提示、極少測試的用例、非常見部署方式/用戶場景/容錯/邊界值等
• 用例格式

1. 前置條件
2. 測試步驟【單個用例全部步驟不能超過8步】
3. 后置條件【不是必填的】
4. 預期結果
5. 備注【不是必填的】

• 語言規范

1. 語言簡練
2. 不能出現模糊的形容詞【比如說大概、可能、很多、差不多】

• 可維護性

1. 靈活運用模塊備注

• 設計原則

1. 目的明確【一個用例對應一個測試點；測試步驟和測試目的一致】
2. 用例效率

• 保證設計出來的用例10分鐘內可以執行完成；
• 用例需要的環境可以整理出來，然后寫到模塊備注中，讓執行者先準備好環境一次性執行全部用例；
• 執行的時候按照測試集方式來執行；
• 有工具可以實現的用例不要采用腳本方式實現

3. 測試步驟：

• 用戶角度

1. 1. 設計的用例要符合用戶的操作順序和操作習慣
   2. 符合用戶的使用環境
   3. 符合用戶的配置

• 可執行

1. 不要出現那種用例設計沒有錯，但是執行起來很復雜或者是依賴環境很夸張的用例

• 正反對比

1. 這一點很重要，很多時候我們會把有正反操作的用例分開寫，其實是可以合在一個用例里面寫

• 強弱關聯

1. 對于強關聯的步驟一定要寫清楚
2. 對于弱關聯的可以備注或者是不寫

• 測試用例不能出現操作步驟

1. 直接寫需要做的操作就可以了

4. 預期結果

• 用戶角度：

1. 反思用戶期望操作完會有什么結果
2. 反思客戶最關注的測試點

• 可檢查

1. 預期結果要可以觀察到，不要寫的很模糊
2. 把重點檢查的檢查點覆蓋到

• 用例編寫口訣

1. 強弱正反之業務
2. 重點突出之效率
3. 目的明確之語言
4. 框架覆蓋之檢查
5. 邏輯場景之經驗

?

用例執行和回歸

• 用例執行標準

1. 執行優先級

1. 建議用例級別執行順序【bvt、leve1、leve2、leve3】
2. 建議用例區域執行順序【基本功能、高風險區域、復雜邏輯優先測試】

2. 用例執行狀態

1. Not Complete：用例無效、用例錯誤、無測試環境等過程狀態
2. Passed：執行通過
3. No Run：默認狀態，未執行
4. N/A：無須執行，需填寫備注，需處理；
5. Failed：執行失敗，需填寫BUGID
6. Blocked：被其他問題阻塞
7. Not Modify：由Failed狀態而來，用例發現的bug不修改，bug為halt、Won't Fix

3. 自動化用例

1. 覆蓋全部bvt用例
2. 大部分level1（基本的功能一定要覆蓋）

4. 執行技巧總結

• 執行前：

1. 1. 首先要看執行備注（模塊備注、文件夾備注、用例備注），了解這個模塊是做什么的，需要注意哪些點和執行的輔助命令和工具
   2. 然后把一個模塊下的所有用例大概過下，能一起執行的可以一起執行

• 執行時：

1. 增改查刪順序執行用例
2. 一類的用例一并執行，比如說測試多種不同的nfv設備的授權之類操作，雖然每個nfv設備都是一個用例，但是都可以一起操作
3. 執行UI限制的用例，可以把限制條件整理出來，做成模版，直接套用
4. 執行的時候關注的測試點，遇到測試點很簡單但是測試步驟很復雜的，可以異測試點測試為主，和用例編寫的人協商優化一些執行步驟，或者是先自己優化再備注，后面統一和用例執行人討論可不可以這樣優化
5. 不理解的用例可以問執行過的人或者是寫用例的人
6. 耗時或者是異常的用例【可以在別人休息吃飯的空閑時間去執行，不要影響公共測試環境】

• 執行后

?

• bug回歸標準

1. bug分類：

• low【UI問題、體驗問題】
• medium【基本功能問題】
• high【性能問題】
• urge【宕機、無法使用、數據丟失、業務無法使用】

• 補充用例

1. 在執行用例或者是回歸bug的時候遇到level1級別的用例沒有覆蓋的一定要補充用例覆蓋
2. 用例覆蓋點過多，把幾個級別的用例覆蓋了，需要拆分用例

• 質量分析

1. Bug的類型主要是哪幾類？

包括：功能問題,性能問題,穩定性,可靠性,關聯,兼容性,需求方案等改進,易用體驗性,異常容錯；分析出主要類別后，在進一步分析各個類別產生的根本原因，比如用例編寫問題（測試步驟達不到測試目的，用例有歧義等）；改動引發（是需求、方案變動帶來的還是純粹的改一個bug引發另一個？）

2. 模塊質量分析

1. 缺陷分析
2. 用例質量分析
3. 測試漏側分析
4. 需求變更分析
5. 模塊改動分析
6. 發散測試分析
7. 重點難點分析
8. 開發人員評價
9. 回歸測試分析

bug定位

• 前端定位：

1. 工具

• 谷歌瀏覽器
• network
• 檢查參數【是否準確、是否有缺少】
• 檢查響應時間【查看加載時間】
• 檢查響應內容【查看響應內容是否有缺少{缺少的話是后端返回的問題；如果沒有缺少的話有可能是前端處理的問題}】
• source【在測試用例的時候可以打開source調試，有一些頁面的錯誤可以被俘獲到】
• postman【模擬請求發送是否正常】

• 后端定位：

1. 后臺報錯日志

• 方法一：

1. cd日志文件所在的目錄 | grep -rn "關鍵詞"
2. 根據行號查看異常日志內容 ：tail -n +203915 文件名 | head -n 200行 （顯示文件中第203915行之后的200行）

• 方法二：

1. less 具體的目錄文件 #進入指定的目錄文件
2. 然后 /關鍵詞

2. 數據庫【mysql】

?

• 非技術方法

• 對比法【比如說acmp上私有云的功能都是沿用acloud的功能，想判斷acmp上的問題可以對比查看acloud上是不是有也有這個問題，如果有很可能是acloud引入的問題】
• 客戶導向法【對于一些新功能，我們可以根據用戶場景去判斷這個功能實現是屬于正常的操作還是不合理的設計】
• 邏輯分析【有時候開發自己設計的產品實現原理不一定是合理的，可以分析下實現步驟，看看是不是有問題】

• 總結下排除思路

• 判斷是否是必現問題【先查看是否是必現的【到別的環境去試下問題是否能必現】；非必現的問題【排查網絡問題；資源不足的問題】】
• 判斷是我們平臺本身的問題
• 判斷是前端的問題還是后端的問題【抓包查看請求，請求中的返回數據是否顯示完整。顯示完整，那么一般就是前端沒有處理好數據顯示，找前端看看；如果返回數據有空缺或者是不完整，那就找后端看看】

?