最近一直在進(jìn)行接口自動(dòng)化的測試工作，同時(shí)對于一個(gè)項(xiàng)目的整個(gè)測試流程進(jìn)行了梳理，希望能對你有用~~~

?

需求分析：

• 整體流程圖：

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

• 分析流程：

1. 需求提取：

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

2. 需求分析：

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

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

網(wǎng)絡(luò)拓?fù)淠芊駶M足客戶需求

和競爭對手比較差異

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

是否考慮了用戶的實(shí)際操作

• 明確性

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

清晰性限制等范疇

無法預(yù)知影響的需求提出進(jìn)行確定，風(fēng)險(xiǎn)

• 二義性

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

支持與不支持等范疇

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

• 完整性

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

需求完整【隱形需求】

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

• 可測試性

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

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

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

• 輸出

測試需求跟蹤

缺陷預(yù)防bug

工具需求

整理出明確的需求點(diǎn)

測試地圖

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

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

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

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

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

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

?

測試設(shè)計(jì)：

• 測試分析：

1. 我們需要做什么？

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

缺陷預(yù)防

2. 怎么做？

整體模塊分析

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

• 怎么做？
• 開發(fā)的設(shè)計(jì)文檔
• 補(bǔ)充和挖掘測試點(diǎn)

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

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

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

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

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

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

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

異常處理機(jī)制測試，異常處理機(jī)制是否完善

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

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

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

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

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

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

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

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

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

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

該模塊的所有指標(biāo)如何?

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

• 場景分析

從用戶的使用習(xí)慣和使用方法去分析影響

檢查當(dāng)前案例是否覆蓋到用戶場景

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

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

對老功能的影響

• 經(jīng)驗(yàn)補(bǔ)充分析

版本分析

模塊分析

• 輸出

測試項(xiàng)

補(bǔ)充測試地圖

?

• 測試設(shè)計(jì)：

需要做什么？

• 把測試項(xiàng)細(xì)化成測試點(diǎn)?
• 缺陷預(yù)防?

2. 需要做什么？

• 基本設(shè)計(jì)方法

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

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

正反對比【一般會(huì)放到同一個(gè)用例里覆蓋】

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

測試類型

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

3. 輸出：

• 基本測試點(diǎn)

?

用例設(shè)計(jì)：

1. 需要做什么？

• 把測試點(diǎn)用文字完整表述出來

2. 怎么做？

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

選中會(huì)有高亮顯示

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

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

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

所有字符類型驗(yàn)證

為空驗(yàn)證

模糊搜索

精確搜索

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

• 刷新

驗(yàn)證自動(dòng)刷新

驗(yàn)證手動(dòng)刷新

驗(yàn)證持續(xù)刷新

• 拖動(dòng)
• 移動(dòng)

點(diǎn)擊下移，往下移動(dòng)一行

點(diǎn)擊上移，往上移動(dòng)一行

最上面的行，上移不能點(diǎn)擊，圖標(biāo)灰色

最下面的行，下移不能點(diǎn)擊，圖標(biāo)灰色

• 功能測試
• 測試點(diǎn)：

功能基本流程邏輯覆蓋

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

用戶操作習(xí)慣的多樣性

模塊配置的多樣性

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

• 測試目錄

平級分類相對獨(dú)立

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

下級從上級細(xì)化而來

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

模塊與模塊之間的

模塊與功能之間

模塊與硬件之間

• 場景類
• 建模思路

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

數(shù)據(jù)流

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

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

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

使用時(shí)間【用戶會(huì)不會(huì)連續(xù)長時(shí)間開啟云主機(jī)】

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

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

最常用的功能

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

典型客戶使用的功能

版本的性能驗(yàn)證

• 專項(xiàng)類

兼容性

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

eg：

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

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

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

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

eg：

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

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

設(shè)備的完整目錄【完整的目錄會(huì)增加后臺(tái)被攻擊的危險(xiǎn)】

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

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

4. 腳本測試

• 使用注意細(xì)節(jié)

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

每個(gè)文件夾下不能超過10個(gè)用例

每個(gè)測試用例一個(gè)測試點(diǎn)

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

• 用例整體規(guī)范
• 用例標(biāo)題【好的標(biāo)題需要準(zhǔn)確的表達(dá)你的測試目的、要測試的測試點(diǎn)】

eg：

測試。。。

驗(yàn)證。。。

。。。的測試

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

。。。的異常測試

。。。的兼容性測試

• 用例屬性

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

測試方法

優(yōu)先級

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

前置條件

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

后置條件【不是必填的】

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

備注【不是必填的】

• 語言規(guī)范

語言簡練

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

• 可維護(hù)性

靈活運(yùn)用模塊備注

• 設(shè)計(jì)原則

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

用例效率

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

3. 測試步驟：

• 用戶角度

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

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

符合用戶的配置

• 可執(zhí)行

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

• 正反對比

這一點(diǎn)很重要，很多時(shí)候我們會(huì)把有正反操作的用例分開寫，其實(shí)是可以合在一個(gè)用例里面寫

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

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

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

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

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

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

• 用戶角度：

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

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

• 可檢查

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

把重點(diǎn)檢查的檢查點(diǎn)覆蓋到

• 用例編寫口訣

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

重點(diǎn)突出之效率

目的明確之語言

框架覆蓋之檢查

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

?

用例執(zhí)行和回歸

• 用例執(zhí)行標(biāo)準(zhǔn)

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

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

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

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

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

Passed：執(zhí)行通過

No Run：默認(rèn)狀態(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. 自動(dòng)化用例

覆蓋全部bvt用例

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

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

• 執(zhí)行前：

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

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

• 執(zhí)行時(shí)：

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

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

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

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

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

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

• 執(zhí)行后

?

• bug回歸標(biāo)準(zhǔn)

1. bug分類：

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

• 補(bǔ)充用例

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

用例覆蓋點(diǎn)過多，把幾個(gè)級別的用例覆蓋了，需要拆分用例

• 質(zhì)量分析

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

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

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

缺陷分析

用例質(zhì)量分析

測試漏側(cè)分析

需求變更分析

模塊改動(dòng)分析

發(fā)散測試分析

重點(diǎn)難點(diǎn)分析

開發(fā)人員評價(jià)

回歸測試分析

bug定位

• 前端定位：

1. 工具

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

• 后端定位：

1. 后臺(tái)報(bào)錯(cuò)日志

• 方法一：

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

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

• 方法二：

less 具體的目錄文件 #進(jìn)入指定的目錄文件

然后 /關(guān)鍵詞

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

?

• 非技術(shù)方法

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

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

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

?

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

總結(jié)

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

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