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

?

需求分析：

• 整體流程圖：

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

• 分析流程：

1. 需求提取：

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

2. 需求分析：

• 分析依據(jù)（五維分析）
• 用戶場景

功能是否和場景強關(guān)聯(lián)

網(wǎng)絡(luò)拓撲能否滿足客戶需求

和競爭對手比較差異

功能是否能滿足客戶實際應(yīng)用場景

是否考慮了用戶的實際操作

• 明確性

范圍明確性（參數(shù)、類型長度范圍）

清晰性限制等范疇

無法預(yù)知影響的需求提出進行確定，風險

• 二義性

概念模糊【大概念、第三方支持、與上個版本相同】

支持與不支持等范疇

一個需求描述能出現(xiàn)多種理解

• 完整性

需求一致性【用戶需求、需求規(guī)格、需求矩陣三者是否同意】

需求完整【隱形需求】

關(guān)聯(lián)性【與新老功能、與外置軟件設(shè)備】

• 可測試性

實現(xiàn)測試需要的工具、方法【調(diào)試、接口命令】

定位方式【日志等形式觀察】

復(fù)雜環(huán)境、容量邊界、操作時過程不可見

• 輸出

測試需求跟蹤

缺陷預(yù)防bug

工具需求

整理出明確的需求點

測試地圖

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

明確產(chǎn)品給客戶帶來的價值

明確產(chǎn)品支持和不支持的功能

明確產(chǎn)品各個功能的約束性

知道開發(fā)實現(xiàn)功能

知道測試分析和產(chǎn)出測試點

?

測試設(shè)計：

• 測試分析：

1. 我們需要做什么？

把明確的需求點轉(zhuǎn)換成測試項

缺陷預(yù)防

2. 怎么做？

整體模塊分析

邏輯分析【這一點主要是從產(chǎn)品實現(xiàn)的原理上去分析可能的影響】

• 怎么做？
• 開發(fā)的設(shè)計文檔
• 補充和挖掘測試點

全部服務(wù)的異常監(jiān)控、服務(wù)重啟

各類存儲對空間的占用、占滿、是否需要做存儲的接口測試

所有類型的管理員、操作權(quán)限測試、支持的多少管理員并發(fā)操作

對流程圖的挖掘 -- 流程圖全部流程測試、流程圖重要的節(jié)點異常測試

對狀態(tài)的挖掘 -- 所有狀態(tài)的相互轉(zhuǎn)化需要覆蓋全、狀態(tài)轉(zhuǎn)化是否合理、每一個狀態(tài)下哪些操作可做哪些不可做，多個狀態(tài)是否可以共存

對關(guān)聯(lián)項的挖掘 -- 流程進展到哪一步關(guān)機重啟/服務(wù)重啟、和備份配置的關(guān)聯(lián)，和操作日志的關(guān)聯(lián)等等

任務(wù)的并發(fā)操作測試、是否可配置、是否會出現(xiàn)性能不足，是否符合用戶場景

異常處理機制測試，異常處理機制是否完善

指標測試，開發(fā)的指標設(shè)計是否合理

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

該模塊是否涉及到一些全新的概念(比如我們的 bbc 全量包)，需要明確?

該模塊包括哪些服務(wù)?

該模塊涉及到哪些存儲技術(shù)(如 mysql、dap、redis)?具體怎么存儲的?占用大小如何?

該模塊的操作流程有哪些?是否有子流程圖?

該模塊是否有多個狀態(tài)的轉(zhuǎn)化?是否有明確的狀態(tài)轉(zhuǎn)化圖?

該模塊對多個管理員是否區(qū)分，管理員權(quán)限如何設(shè)計?

該模塊是否有一些特殊的操作限制?操作限制是否有明確的表格?

該模塊的任務(wù)是否有并發(fā)需求?并發(fā)的設(shè)計?

該模塊的所有指標如何?

該模塊是否有異常處理機制?在設(shè)備各種異常時，該模塊的設(shè)計是否滿足能穩(wěn)健運行?

• 場景分析

從用戶的使用習慣和使用方法去分析影響

檢查當前案例是否覆蓋到用戶場景

• 關(guān)聯(lián)測試分析：

考慮你的模塊所在整個系統(tǒng)的地位，分析上下游的影響

對老功能的影響

• 經(jīng)驗補充分析

版本分析

模塊分析

• 輸出

測試項

補充測試地圖

?

• 測試設(shè)計：

需要做什么？

• 把測試項細化成測試點?
• 缺陷預(yù)防?

2. 需要做什么？

• 基本設(shè)計方法

等價類劃分法【將輸入域和輸出域劃分為不同的等價類，等價類之內(nèi)的操作結(jié)果相同】，使用范圍：顯示輸入框輸入

邊界值法【需要結(jié)合等價類劃分法方法，在劃分出來的等價類選取有代表性的值】

正反對比【一般會放到同一個用例里覆蓋】

字符多樣性【考慮不同字符的輸入】

測試類型

• 產(chǎn)品專項測試
• 正交組合設(shè)計【正交矩陣，覆蓋各個參數(shù)間的組合情況】
• 業(yè)務(wù)邏輯設(shè)計【根據(jù)業(yè)務(wù)設(shè)計測試點】

3. 輸出：

• 基本測試點

?

用例設(shè)計：

1. 需要做什么？

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

2. 怎么做？

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

選中會有高亮顯示

點擊跳轉(zhuǎn)到對應(yīng)頁面

當前頁面對應(yīng)的名稱下有區(qū)別顯示

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

所有字符類型驗證

為空驗證

模糊搜索

精確搜索

搜索不存在的關(guān)鍵詞

• 刷新

驗證自動刷新

驗證手動刷新

驗證持續(xù)刷新

• 拖動
• 移動

點擊下移，往下移動一行

點擊上移，往上移動一行

最上面的行，上移不能點擊，圖標灰色

最下面的行，下移不能點擊，圖標灰色

• 功能測試
• 測試點：

功能基本流程邏輯覆蓋

業(yè)務(wù)流程多樣性覆蓋

用戶操作習慣的多樣性

模塊配置的多樣性

數(shù)據(jù)流的多樣性覆蓋

• 測試目錄

平級分類相對獨立

上下級分類有關(guān)聯(lián)

下級從上級細化而來

• 關(guān)聯(lián)類：

模塊與模塊之間的

模塊與功能之間

模塊與硬件之間

• 場景類
• 建模思路

部署方式【比如用戶一般使用2主機還是3主機部署集群】

數(shù)據(jù)流

業(yè)務(wù)流【用戶是怎么使用申請工單，是怎么樣的完整流程】

操作順序【創(chuàng)建云主機的順序之類的】

配置方法【用戶一般怎么配置使用靜態(tài)路由】

使用時間【用戶會不會連續(xù)長時間開啟云主機】

用戶角色【一般那些角色做什么操作】

• 用戶操作的設(shè)計方向

最常用的功能

最容易出現(xiàn)網(wǎng)上問題的功能

典型客戶使用的功能

版本的性能驗證

• 專項類

兼容性

可靠性【測試產(chǎn)品在異常情況下能否正常工作或者是恢復(fù)正常工作，可靠性重點測試對模塊自身處理的覆蓋】. 補充：容錯性測試【測試系統(tǒng)在非正常操作、非正常的外部環(huán)境下是否能夠處理錯誤和正常運行】

eg：

針對數(shù)據(jù)庫的測試：【磁盤空間不足、數(shù)據(jù)庫文件損壞、無讀寫數(shù)據(jù)權(quán)限、寫數(shù)據(jù)時斷電、寫數(shù)據(jù)時強制關(guān)閉mysql、讀寫速度】

針對網(wǎng)絡(luò)設(shè)備：【網(wǎng)絡(luò)中有攻擊數(shù)據(jù)、丟包時延大、IP沖突、網(wǎng)絡(luò)線路斷開、同時掉電】

針對程序：【 客戶端進程被手動停止、設(shè)備后臺資源cpu、內(nèi)存占滿】

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

eg：

密碼加密方式【什么時候用明文，什么時候用密碼顯示】?

隱私數(shù)據(jù)隱藏【用戶的隱私顯示】

設(shè)備的完整目錄【完整的目錄會增加后臺被攻擊的危險】

文件上傳功能【檢查上傳的文件類型；限制上傳文件的權(quán)限】

防暴力破解【對于連線認證之類的操作要凍結(jié)、禁用其連續(xù)錯誤嘗試操作】

4. 腳本測試

• 使用注意細節(jié)

文件夾以01-xx，02-xx區(qū)分開

每個文件夾下不能超過10個用例

每個測試用例一個測試點

在02-功能測試的描述中，備注說明功能測試框架的思路

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

eg：

測試。。。

驗證。。。

。。。的測試

與。。。的關(guān)聯(lián)測試

。。。的異常測試

。。。的兼容性測試

• 用例屬性

測試環(huán)境【默認的前置條件可以不用寫；寫的前置條件要準確，不要寫的模糊】

測試方法

優(yōu)先級

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

前置條件

測試步驟【單個用例全部步驟不能超過8步】

后置條件【不是必填的】

預(yù)期結(jié)果

備注【不是必填的】

• 語言規(guī)范

語言簡練

不能出現(xiàn)模糊的形容詞【比如說大概、可能、很多、差不多】

• 可維護性

靈活運用模塊備注

• 設(shè)計原則

目的明確【一個用例對應(yīng)一個測試點；測試步驟和測試目的一致】

用例效率

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

3. 測試步驟：

• 用戶角度

設(shè)計的用例要符合用戶的操作順序和操作習慣

符合用戶的使用環(huán)境

符合用戶的配置

• 可執(zhí)行

不要出現(xiàn)那種用例設(shè)計沒有錯，但是執(zhí)行起來很復(fù)雜或者是依賴環(huán)境很夸張的用例

• 正反對比

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

• 強弱關(guān)聯(lián)

對于強關(guān)聯(lián)的步驟一定要寫清楚

對于弱關(guān)聯(lián)的可以備注或者是不寫

• 測試用例不能出現(xiàn)操作步驟

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

4. 預(yù)期結(jié)果

• 用戶角度：

反思用戶期望操作完會有什么結(jié)果

反思客戶最關(guān)注的測試點

• 可檢查

預(yù)期結(jié)果要可以觀察到，不要寫的很模糊

把重點檢查的檢查點覆蓋到

• 用例編寫口訣

強弱正反之業(yè)務(wù)

重點突出之效率

目的明確之語言

框架覆蓋之檢查

邏輯場景之經(jīng)驗

?

用例執(zhí)行和回歸

• 用例執(zhí)行標準

1. 執(zhí)行優(yōu)先級

建議用例級別執(zhí)行順序【bvt、leve1、leve2、leve3】

建議用例區(qū)域執(zhí)行順序【基本功能、高風險區(qū)域、復(fù)雜邏輯優(yōu)先測試】

2. 用例執(zhí)行狀態(tài)

Not Complete：用例無效、用例錯誤、無測試環(huán)境等過程狀態(tài)

Passed：執(zhí)行通過

No Run：默認狀態(tài)，未執(zhí)行

N/A：無須執(zhí)行，需填寫備注，需處理；

Failed：執(zhí)行失敗，需填寫B(tài)UGID

Blocked：被其他問題阻塞

Not Modify：由Failed狀態(tài)而來，用例發(fā)現(xiàn)的bug不修改，bug為halt、Won't Fix

3. 自動化用例

覆蓋全部bvt用例

大部分level1（基本的功能一定要覆蓋）

4. 執(zhí)行技巧總結(jié)

• 執(zhí)行前：

首先要看執(zhí)行備注（模塊備注、文件夾備注、用例備注），了解這個模塊是做什么的，需要注意哪些點和執(zhí)行的輔助命令和工具

然后把一個模塊下的所有用例大概過下，能一起執(zhí)行的可以一起執(zhí)行

• 執(zhí)行時：

增改查刪順序執(zhí)行用例

一類的用例一并執(zhí)行，比如說測試多種不同的nfv設(shè)備的授權(quán)之類操作，雖然每個nfv設(shè)備都是一個用例，但是都可以一起操作

執(zhí)行UI限制的用例，可以把限制條件整理出來，做成模版，直接套用

執(zhí)行的時候關(guān)注的測試點，遇到測試點很簡單但是測試步驟很復(fù)雜的，可以異測試點測試為主，和用例編寫的人協(xié)商優(yōu)化一些執(zhí)行步驟，或者是先自己優(yōu)化再備注，后面統(tǒng)一和用例執(zhí)行人討論可不可以這樣優(yōu)化

不理解的用例可以問執(zhí)行過的人或者是寫用例的人

耗時或者是異常的用例【可以在別人休息吃飯的空閑時間去執(zhí)行，不要影響公共測試環(huán)境】

• 執(zhí)行后

?

• bug回歸標準

1. bug分類：

• low【UI問題、體驗問題】
• medium【基本功能問題】
• high【性能問題】
• urge【宕機、無法使用、數(shù)據(jù)丟失、業(yè)務(wù)無法使用】

• 補充用例

在執(zhí)行用例或者是回歸bug的時候遇到level1級別的用例沒有覆蓋的一定要補充用例覆蓋

用例覆蓋點過多，把幾個級別的用例覆蓋了，需要拆分用例

• 質(zhì)量分析

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

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

2. 模塊質(zhì)量分析

缺陷分析

用例質(zhì)量分析

測試漏側(cè)分析

需求變更分析

模塊改動分析

發(fā)散測試分析

重點難點分析

開發(fā)人員評價

回歸測試分析

bug定位

• 前端定位：

1. 工具

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

• 后端定位：

1. 后臺報錯日志

• 方法一：

cd日志文件所在的目錄 | grep -rn "關(guān)鍵詞"

根據(jù)行號查看異常日志內(nèi)容 ：tail -n +203915 文件名 | head -n 200行 （顯示文件中第203915行之后的200行）

• 方法二：

less 具體的目錄文件 #進入指定的目錄文件

然后 /關(guān)鍵詞

2. 數(shù)據(jù)庫【mysql】

?

• 非技術(shù)方法

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

• 總結(jié)下排除思路

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

?

轉(zhuǎn)載于:https://www.cnblogs.com/sunshine-blog/p/9782201.html

總結(jié)

以上是生活随笔為你收集整理的一个项目的整个测试流程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。