一個項目的整個測試流程

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

 

需求分析：

• 總體流程圖：

需求提取 -> 需求分析 -> 需求評審 -> 更新後的測試需求跟蹤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、leve一、leve二、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引入的問題】
• 客戶導向法【對於一些新功能，咱們能夠根據用戶場景去判斷這個功能實現是屬於正常的操做仍是不合理的設計】
• 邏輯分析【有時候開發本身設計的產品實現原理不必定是合理的，能夠分析下實現步驟，看看是否是有問題】

• 總結下排除思路

• 判斷是不是必現問題【先查看是不是必現的【到別的環境去試下問題是否能必現】；非必現的問題【排查網絡問題；資源不足的問題】】
• 判斷是咱們平臺自己的問題
• 判斷是前端的問題仍是後端的問題【抓包查看請求，請求中的返回數據是否顯示完整。顯示完整，那麼通常就是前端沒有處理好數據顯示，找前端看看；若是返回數據有空缺或者是不完整，那就找後端看看】