軟件測試分析

概念：是根據需求提取被測軟件中需要測試的地方，即找到要測試的地方。

測試項：又叫做應測特性，還可以叫做測試點、功能點，即要測試的地方。

學習測試分析的目的：把要測試的地方全部找到，防止漏測。

分析設計工作的前提：一定要根據需求來熟悉，熟悉被測軟件，軟件越熟悉對將來的測試分析工作就越好，分析的越全面。

熟悉需求的途徑

1. 根據文檔熟悉：

a)?需求文檔——需求人員提供；

b)?測試用例——測試人員提供

c)?開發的設計文檔——開發人員

d)?代碼——開發人員（使用較少）

e)?幫助文檔（用戶手冊）——資料人員（測試人員、需求人員兼職）

2.?可以直接到被測軟件中操作來熟悉

3. 參考被測軟件的同類型產品

對于新功能的途徑：根據文檔只能參考需求文檔，參考同類型軟件

對于老功能的途徑：以上方法都可以

更科學的熟悉需求的方法：SFDPOT思路，從6方面來熟悉軟件。

SFDPOT思路

01?? ? ? ?S—Structure：結構

建議熟悉被測軟件時，可以了解被測軟件的架構和構成

架構：

B/S：服務器+瀏覽器——不用測試瀏覽器

C/S：服務器+客戶端——測試客戶端的安裝、升級、卸載

單機版：客戶端——測試客戶端的安裝、升級、卸載

構成：

1）?啟動文件：要測試，雙擊能否打開，不會漏測

2）?卸載文件：要測試，雙擊打開卸載窗口，一步一步卸載軟件，可能會漏測

3）?代碼文件（dll）：要測試，怎么測試？

a)?單元測試：一行一行代碼進行測試，代碼成本過高，測試要求較高，測試開發比例：1:1，甚至更高

b)?系統測試：測試和開發比例：1:3，節省成本

4）?配置文件

常見的配置文件后綴：.ini、.xml、.conf

要測試，容易漏測，如何測試？

測試配置選項，修改配置選項的value值，改成正確的、錯誤的分別測試

5）?幫助文檔（help）：要測試

打開幫助文檔查看文檔中的內容是否正確合理——文檔測試

02? ? ? ??F—Function：功能

提醒測試人員要熟悉被測軟件的功能模塊，梳理所有的功能模塊

例如：定時任務

03? ? ? ??D—Data：數據

提醒測試人員熟悉被測軟件需要的測試數據，提前準備這些測試數據，節省測試時間

一般軟件中包含三類數據：

1）?預置數據：搭建測試環境時，預先往數據庫中準備的數據；操作之前需要提前準備的前提

2）?輸入數據：考慮合法的（正確的）、非法的（錯誤的）

Eg：全能 合法：音視頻文件（mp3、mp4、rmvb…）

非法：非音視頻文件（txt、docx、py、sql…）、將txt改成mp3后綴

3）?輸出數據：數據輸入進去后會得到的正確的輸出是什么？即：結果（預期結果）

04? ? ? ??P—Platform：平臺

了解被測軟件會在哪些環境中來使用（更加側重于客戶端的環境）

即：分析兼容性測試需要覆蓋的環境

B/S：不同的瀏覽器：火狐、谷歌、IE、360、QQ瀏覽器…

C/S、單機版：不同的操作系統

PC：win7、win10…

終端：ios、android（設備廠商）、鴻蒙

05? ? ? ??O—Operation：操作

提醒測試人員了解客戶通過哪些不同的方式使用軟件，站在客戶的角度考慮問題

06? ? ? ??T—Time：時間

提醒測試人員了解被測軟件中是否有跟系統時間有關聯的功能，如果有，需要分析系統時間的變化會不會影響對應功能

練習：利用SFDPOT思路熟悉QQ（PC）

注意：數據、操作 分別選擇一個功能進行分析

1.結構：

架構：C/S架構：要測試客戶端的安裝、卸載、升級

構成：測試啟動文件、卸載文件、系統功能測試、配置文件、幫助文件

2.功能：

根據功能模塊覆蓋，避免遺漏：登錄、個人設置、消息管理、添加好友、刪除好友、系統設置、qq空間

3.數據：登錄模塊

1）預置數據：賬號已注冊

2）輸入：

合法：已注冊賬號

非法：未注冊賬號、字母、下劃線、特殊字符

3）輸出：

合法輸入的輸出：登錄成功，看到QQ主界面——消息列表，增加登錄成功日志記錄

非法輸入的輸出：登錄失敗，界面異常提示，增加登錄失敗日志記錄

4.平臺

PC：win7、win8、win10、win11、MAC

5.操作：消息管理——發送消息

發送消息目標：好友、陌生人、群、黑名單

發送內容：文字、圖片、文件、視頻、音頻

發送提交方式：按鈕、Enter鍵

6.時間

會員：設備時間變更能否讓過期會員繼續使用會員特權

消息信息顯示：本地設備時間變更會不會影響消息顯示時間；聊天雙方處于不同地理位置，界面顯示時間是否收到各自客戶端設備所處地域限制變化而變化

驗證消息時間限制：接收驗證消息超期后，修改本地系統時間是否能繼續驗證

提取測試項的方法：3種

1.質量模型分析法

2.功能交互分析法

3.用戶使用場景分析法

1.質量模型分析法（最重要）

質量模型：6大特性27個子特性，告訴測試人員：質量不是單由一個方面來決定的，質量是多方面考慮的。

01、功能性

a)?適合性

功能適合當前這個軟件，需求人員來把控的；

提醒測試人員需求中的功能在被測軟件中都要有，即：所有的需求都要被開發，防止漏開發。

至于這個需求是否加到被測軟件中，由需求人員把控，以及需求評審控制。

b)?準確性

被測軟件提供的功能要正確，即：被測軟件能正常使用

c)?互操作性

先分析被測軟件和其它軟件有無交互，如果有，針對交互進行測試

Eg：淘寶軟件和支付寶、物流軟件有交互；滴滴和高德地圖有交互…

d)?保密安全性

先分析是否有敏感數據，再分析被測軟件的安全級別要求高不高。

如果有敏感數據，安全級別要求高，就需要進行安全方面的測試。

Eg：全能音頻轉換通：不需要測試

銀行系統：需要測試

總結：

適合性、準確性：屬于功能測試，每個軟件都要測試；

互操作性、保密安全性：需要進行分析，并不是每個軟件都需要測試的。

02、易用性

a)?易理解性

提醒測試人員在測試時注意界面上的信息顯示是否容易理解

b)?易學性

先分析有沒有幫助文檔、用戶手冊，如果有就需要測試——文檔測試

c)?易操作性

提醒測試人員測試被測軟件操作簡便，即：操作上要簡單、步驟少，用起來順手

d)?吸引性

提醒測試人員測試時要考慮軟件的外觀（排版、布局、色彩、大小）

總結：

易理解性、吸引性：都是關注軟件的界面，即GUI測試，基本上每個軟件都要做GUI測試；

易學性：不一定每個軟件都有

易操作性：基本上每個軟件都要測試

03、效率

對于性能測試：一般有壓力的情況下才需要測試性能。

軟件的壓力：

多用戶帶來的壓力，主要測試服務器端的抗壓能力；

大數據帶來的壓力，主要測試服務端數據庫的抗壓能力；

a)?時間特性：考慮用戶在有壓力的情況下使用軟件是快還是慢

b)?資源利用率：一般考慮的是服務器的資源消耗情況（CPU、內存）

總結：性能不是每個軟件都需要測試，先分析有沒有壓力（多用戶、數據量比較大），如果有壓力，就需要測試性能。

04、可移植性

a)?適應性

提醒測試人員在測試時要注意被測軟件能否在不同的環境使用，主要是適應不同的客戶端環境，即：測試客戶端的兼容性

B/S：不同瀏覽器

C/S、單機版：不同的操作系統

b)?易安裝性

先分析有沒有客戶端，如果被測軟件有客戶端，就需要測試客戶端的安裝；

c)?易替換性

升級：從低版本升級到高版本

兩種：直接覆蓋（不卸載舊版本直接安裝新版本）、先卸載舊版本再安裝新版本

d)?共存性

也是兼容性的一種，但是測試的不多

提醒測試人員在測試時要考慮被測軟件和其它同類型軟件或者有關聯的軟件能在一起使用，相互之間不影響。

總結：

適應性：每個軟件都要測試——兼容性測試；

易安裝、易替換性：不是每個軟件都要測試，只有有客戶端的軟件才需要測試；

共存性：bug基本不會有，優先級低，一般不測試

05、可靠性

a)?成熟性

一般是和時間有關系，提醒測試人員：分析被測軟件是否有長時間使用的情況，如果有就需要進行長時間的測試——穩定性測試

b)?容錯性

提醒測試人員在測試時要考慮軟件有容納外來錯誤的能力

外來錯誤：輸入進去的錯誤，即：輸入的非法數據（屬于功能測試中的異常測試）

c)?易恢復性

當前的運行環境出現一些問題后，被測軟件的應對能力——可靠性測試

Eg：word未保存，斷電，重新啟動word后自動打開未保存的緩存內容

磁盤空間滿：軟件下載占用磁盤，下載過程中將磁盤占滿，下載任務暫停，磁盤清理后下載任務能否繼續

總結：

成熟性：不會每個軟件都需要測試，如果軟件沒有長時間使用的情況就不需要測試；

容錯性：屬于功能測試，一般都需要測試；

易恢復性：想要測試的話，每個軟件都可以測試，優先級低

測試類型總結

測試類型（工作中的說法）

質量模型（理論上的說法）

功能測試	適合性、準確性、容錯性、互操作性
GUI測試	易理解性、吸引性
易用性測試	易操作性
兼容性測試	適應性、共存性
性能測試	時間特性、資源利用率

安裝測試	易安裝性、易替換性
文檔測試	易學性
穩定性測試	成熟性
可靠性測試	易恢復性
安全性測試	保密安全性

練習：針對全能音頻轉換通軟件進行質量模型分析法提取測試項，要求以添加文件為目標進行分析

針對全能音頻轉換通軟件進行質量模型分析法提取測試項，要求以添加文件為目標進行分析

功能測試

適合性：在全能中有添加文件功能

準確性：測試全能中添加音視頻文件

容錯性：測試全能添加非音視頻文件、非音視頻文件改為音視頻后綴的文件添加

互操作性：無

GUI測試

易理解性：全能添加文件界面文字信息顯示

吸引性：全能添加文件界面布局、排版、色彩美觀大方、放大縮小界面后的顯示

易用性測試

易操作性：測試直接拖拽文件到全能中

兼容性測試

適應性：測試全能在不同操作系統（win7、win10、win11）中都能正常添加文件

共存性：測試全能和其它軟禁一起使用不沖突

性能測試

單機版軟甲，無服務器壓力，當前添加文件操作實際讀取文件名稱和路徑消耗資源很少，不會對設備造成太大資源消耗，所以不需要測試性能。

時間特性：

資源利用率：

安裝測試

易安裝性：測試全能安裝、卸載

易替換性：測試全能升級

文檔測試

易學性：測試全能添加文件幫助文檔

穩定性測試

成熟性：添加文件很快，不存在長時間使用的情況，不需要測試

可靠性測試

易恢復性：添加文件很快，一瞬間完成，很難破壞，不考慮測試可靠性

安全性測試

保密安全性：沒有敏感數據，安全級別要求不高，不需要測試

2.功能交互分析法

提醒測試人員不要只關注自己的模塊，還要關注跟其他模塊之間的交互、關聯，如果有關聯，需要針對關聯進行測試（容易漏測）

關聯有兩種：

1）?需求中明確說明的，按照需求來測試

Eg：未添加文件時，轉換操作調用添加文件

2）?需求中沒有說明，但是需要關注，用戶的操作——經驗、發散思維

Eg：測試打開多個窗口，一個進行批量轉換、一個進行合并轉換、一個進行截取轉換，都是對同一個音頻文件處理

3.用戶使用場景分析法

分析客戶使用軟件的整體的過程，需要了解客戶使用軟件是為了做什么

軟件分類：

1）?如果是針對特定群體：和客戶端溝通了解

Eg：全能音頻轉換通（音樂愛好者、剪輯配音）

2）?如果是針對大眾群體：問自己、問朋友、問家人

3）?如果軟件的客戶不是人：軟件的客戶可以是另外一個軟件

Eg：滴滴是高德的客戶；淘寶是支付寶的客戶

分析完客戶，了解客戶的使用場景，針對客戶的使用場景進行測試

Eg：全能音頻轉換通

A.?格式轉換，使用過程：打開全能—》添加音頻文件—》批量轉換—》播放試聽—》關閉全能

B.?做歌曲串燒，使用過程：打開全能—》添加音頻文件—》截取轉換（多次）--》添加截取后的音頻文件—》合并轉換—》播放試聽—》關閉

總結：

質量模型分析法：要求針對每一個功能模塊都要借助質量模型分析法提取測試項，針對單一一個功能模塊考慮

功能交互分析法：不是只考慮一個模塊，還要考慮模塊之間的關聯

用戶使用場景分析法：考慮用戶使用的全過程，即：業務流程，多個功能模塊全部串起來

提取一個軟件的測試項以上三個方法都要用到，三個方法配合使用。

如果我的博客對你有幫助、如果你喜歡我的博客內容，請 “點贊” “評論” “收藏” 一鍵三連哦！

---

最后基礎知識、Linux必備、Shell、互聯網程序原理、Mysql數據庫、抓包工具專題、接口測試工具、測試進階-Python編程、Web自動化測試、APP自動化測試、接口自動化測試、測試高級持續集成、測試架構開發測試框架、性能測試、安全測試等學習資源。

總結

以上是生活随笔為你收集整理的软件测试基础 ——— 测试分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。