1. 按照測(cè)試對(duì)象進(jìn)行劃分

1）界面測(cè)試

界面是直接和用戶進(jìn)行交互的，界面設(shè)計(jì)的好壞決定了用戶使用軟件的直觀感受

界面測(cè)試（UI 測(cè)試）一般包括以下內(nèi)容：

1. 對(duì)比 UI 設(shè)計(jì)稿，驗(yàn)證系統(tǒng)顯示界面的一致性和正確性
2. 驗(yàn)證界面上每個(gè)功能的正確性
3. 驗(yàn)證界面排版布局是否合理。字體大小、圖片排版、清晰程度等
4. 驗(yàn)證界面控件的功能是否正常。滾動(dòng)條、按鈕、文本框等
5. 對(duì)不同分辨率下的界面進(jìn)行測(cè)試
   • 保證頁(yè)面從大變?。ɑ驈男∽兇螅┑淖兓^(guò)程是絲滑順暢、不卡頓的
   • 保證頁(yè)面的字體不模糊、不重影、不消失
   • 保證頁(yè)面中的圖片不消失、排版布局合理
   • 保證頁(yè)面的功能正常使用

2）可靠性測(cè)試

可靠性 是指系統(tǒng)正常運(yùn)行的能力或者程度，一般用百分比表示

可靠性 = 正常運(yùn)行時(shí)間 / （正常運(yùn)行時(shí)間 + 非正常運(yùn)行時(shí)間）

影響軟件可靠性的因素：

• 軟件本身
• 外界因素，包括電、網(wǎng)絡(luò)、硬件設(shè)備等

3）容錯(cuò)性測(cè)試

容錯(cuò)性 是指因?yàn)樽陨砘蛘咄獠恳恍┊惓５牟僮魇沟孟到y(tǒng)發(fā)生異常，系統(tǒng)能夠自我處理異?；蛘咤e(cuò)誤的能力

容錯(cuò)性測(cè)試包含以下幾個(gè)方面：

• 用戶輸入異常數(shù)據(jù)時(shí)，系統(tǒng)會(huì)不會(huì)給出提示，或者系統(tǒng)內(nèi)部是否做一些處理

• 在用戶做出一些復(fù)雜操作或者可能危害數(shù)據(jù)安全的操作時(shí)，會(huì)不會(huì)給出提示信息

• 斷電、斷網(wǎng)或者硬件設(shè)備出問(wèn)題了，是否可以無(wú)縫切換到備用服務(wù)器

• 災(zāi)難恢復(fù)性測(cè)試

  人為使服務(wù)器發(fā)生故障，測(cè)試軟件系統(tǒng)的環(huán)境恢復(fù)能力、系統(tǒng)數(shù)據(jù)恢復(fù)能力、以及恢復(fù)的時(shí)間

4）文檔測(cè)試

對(duì)整個(gè)開發(fā)過(guò)程中產(chǎn)生的各種文檔，需求文檔、設(shè)計(jì)文檔、功能文檔、用戶使用手冊(cè)進(jìn)行測(cè)試，驗(yàn)證文檔的正確性、一致性和完整性

5）兼容性測(cè)試

• 平臺(tái)的兼容： 驗(yàn)證系統(tǒng)對(duì)不同瀏覽器、操作系統(tǒng)、不同品牌手機(jī)或者電腦的兼容性
• 軟件本身的兼容： 驗(yàn)證軟件新功能對(duì)舊功能的兼容性，新開發(fā)的功能不能影響舊功能的使用
• 軟件對(duì)用戶數(shù)據(jù)的兼容性： 比如數(shù)據(jù)庫(kù)中的一張表新增加一個(gè)字段，不能影響用戶之前數(shù)據(jù)的存儲(chǔ)
• 軟件對(duì)第三方軟件的兼容性： 在與第三方軟件有功能或者數(shù)據(jù)交互時(shí)，不能影響第三方軟件的使用

6）易用性測(cè)試

易用性測(cè)試 是指驗(yàn)證用戶在使用軟件過(guò)程中的是否靈活舒適、簡(jiǎn)單易用

易用性測(cè)試一般包括以下幾點(diǎn)：

• 符合標(biāo)準(zhǔn)和規(guī)范

  對(duì)于現(xiàn)在的軟件，其 UI 設(shè)計(jì)的標(biāo)準(zhǔn)已經(jīng)慢慢被確立，多數(shù)用戶已經(jīng)習(xí)慣了這種標(biāo)準(zhǔn)和規(guī)范。比如，軟件發(fā)生嚴(yán)重錯(cuò)誤時(shí)給出提示時(shí)圖片或者字體的顏色

• 直觀性

  要求界面布局合理，軟件功能操作簡(jiǎn)單、清晰易懂

• 靈活性

  用戶可以根據(jù)自己的習(xí)慣選擇適合自己的操作方式

  比如，手機(jī)上的鍵盤可以切換九宮格、全鍵盤、手寫和五筆輸入

• 舒適性

  讓用戶對(duì)自己的操作有感知，不產(chǎn)生焦慮情緒

  安裝或者下載軟件時(shí)，添加上進(jìn)度條

7）軟件安裝卸載的測(cè)試

主要的測(cè)試點(diǎn)有以下幾點(diǎn)：

• 是否可以使用不同方式正常安裝和卸載軟件
• 安裝或者卸載時(shí)是否可以手動(dòng)暫停或者取消
• 安裝空間不足時(shí)，是否給出提示
• 卸載中途，取消卸載，軟件是否可以正常使用
• 卸載或者安裝過(guò)程中的異常測(cè)試（如：斷網(wǎng)、斷電、死機(jī)等）
• 卸載完成之后，軟件的數(shù)據(jù)文件信息是否清理干凈

8）安全測(cè)試

安全性 是指信息安全，指網(wǎng)絡(luò)和系統(tǒng)保護(hù)用戶的數(shù)據(jù)和隱私不被侵犯和泄露

防病毒、防黑客、防 XSS 注入、防 SQL 注入、防爬蟲

9）性能測(cè)試

在使用軟件時(shí)，有時(shí)會(huì)碰到網(wǎng)頁(yè)打開時(shí)越來(lái)越慢，查詢數(shù)據(jù)時(shí)很長(zhǎng)時(shí)間才顯示列表，這些都是系統(tǒng)的性能問(wèn)題引起的

常見的性能問(wèn)題如下：

• 資源泄露
• 資源瓶頸
• 線程死鎖，線程阻塞
• 查詢速度慢或效率低

衡量一個(gè)系統(tǒng)性能好壞的關(guān)鍵性指標(biāo)有，用戶操作的響應(yīng)時(shí)間、吞吐量、內(nèi)存和 CPU 的使用率

10）內(nèi)存泄漏測(cè)試

內(nèi)存泄漏會(huì)使軟件運(yùn)行越來(lái)越慢，最終停止響應(yīng)

常見的導(dǎo)致內(nèi)存泄露的原因：

• 內(nèi)存分配后，沒(méi)有回收
• 程序的寫法有問(wèn)題，無(wú)法回收（比如死循環(huán)造成無(wú)法執(zhí)行到回收步驟）
• API 函數(shù)的使用不正確，無(wú)法回收

2. 按照是否查看代碼劃分

1）黑盒測(cè)試

黑盒測(cè)試 就是完全不關(guān)心軟件內(nèi)部代碼的實(shí)現(xiàn)和邏輯結(jié)構(gòu)，只關(guān)心系統(tǒng)的輸入輸出是否符合預(yù)期，功能是否符合需求說(shuō)明書的規(guī)定

黑盒測(cè)試的優(yōu)點(diǎn)：

• 不需要了解代碼的內(nèi)部結(jié)構(gòu)，代碼能力差的人員也可以進(jìn)行測(cè)試
• 站在用戶的角度對(duì)系統(tǒng)功能進(jìn)行測(cè)試，有利于培養(yǎng)測(cè)試人員的用戶思維
• 測(cè)試用例是按照需求說(shuō)明書設(shè)計(jì)的，不容易遺漏需求

黑盒測(cè)試的缺點(diǎn)： 由于黑盒測(cè)試不關(guān)心系統(tǒng)內(nèi)部代碼的實(shí)現(xiàn)，導(dǎo)致代碼得不到測(cè)試

黑盒測(cè)試的測(cè)試方法：

等價(jià)類法、邊界值法、錯(cuò)誤猜測(cè)發(fā)、因果圖法、場(chǎng)景法、正交法

2）白盒測(cè)試

白盒測(cè)試 就是針對(duì)代碼進(jìn)行測(cè)試，根據(jù)代碼的邏輯結(jié)構(gòu)設(shè)計(jì)測(cè)試用例，驗(yàn)證代碼的實(shí)際運(yùn)行狀態(tài)是否符合預(yù)期狀態(tài)

白盒測(cè)試的測(cè)試方法：

1. 語(yǔ)句覆蓋：

   設(shè)計(jì)足夠的測(cè)試用例，使得程序中的 每條語(yǔ)句都被至少執(zhí)行一次

2. 判定覆蓋：

   設(shè)計(jì)足夠的測(cè)試用例，使得程序中 每個(gè)判定語(yǔ)句的每個(gè)分支都被至少執(zhí)行一次。

   如： if else 語(yǔ)句中 if 條件為真、為假都要被測(cè)試；switch case 語(yǔ)句中每個(gè) case 都要被測(cè)試

3. 條件覆蓋：

   設(shè)計(jì)足夠的測(cè)試用例，使得判定語(yǔ)句中 每個(gè)邏輯條件為真和為假都至少出現(xiàn)一次

   如： if (a > 0 && b < 0) 中，要確保 a > 0、b < 0 兩個(gè)邏輯條件分別為真和為假的情況都至少出現(xiàn)一次

4. 判定 – 條件覆蓋：

   設(shè)計(jì)足夠的測(cè)試用例，使得判定語(yǔ)句中 每個(gè)邏輯條件為真為假都至少出現(xiàn)一次，同時(shí) 判定語(yǔ)句的所有可能結(jié)果也至少出現(xiàn)一次

   如： if (a > 0 && b < 0) 中，要確保 a > 0、b < 0 兩個(gè)邏輯條件分別為真和為假的情況都至少出現(xiàn)一次，同時(shí) if (a > 0 && b < 0) 判定語(yǔ)句為真和為假的情況也至少出現(xiàn)一次

5. 條件組合覆蓋：

   設(shè)計(jì)足夠的測(cè)試用例，使得判定語(yǔ)句中 邏輯條件結(jié)果的所有可能組合至少出現(xiàn)一次

   如： if (A && B) 中，存在兩個(gè)條件 A 和 B，則條件組合覆蓋要求測(cè)試用例包含以下幾種情況：

   • A 為真，B 為真
   • A 為真，B 為假
   • A 為假，B 為真
   • A 為假，B 為假

6. 路徑覆蓋：

   設(shè)計(jì)足夠的測(cè)試用例，使得程序中 每一條可能走過(guò)的路徑都至少執(zhí)行一次

3）灰盒測(cè)試

介于黑盒測(cè)試和白盒測(cè)試之間的一種測(cè)試，多用于集成測(cè)試階段，不僅關(guān)注程序的輸入和輸出，同時(shí)也關(guān)注程序內(nèi)部的情況

3. 按照開發(fā)階段劃分

測(cè)試金字塔： 越往下測(cè)試效率越高，定位問(wèn)題越容易

1）單元測(cè)試（結(jié)合 V 模型）

單元測(cè)試 是對(duì)軟件組成的最小單元 —— 模塊進(jìn)行測(cè)試，驗(yàn)證軟件基本組成模塊的正確性

測(cè)試階段： 編碼后或者編碼前（TDD）

TDD：測(cè)試驅(qū)動(dòng)開發(fā)，在開發(fā)人員編寫功能代碼之前，先設(shè)計(jì)好測(cè)試用例的代碼，然后根據(jù)測(cè)試用例的代碼編寫功能代碼，最終目的是讓開發(fā)前設(shè)計(jì)的測(cè)試用例全部都能執(zhí)行通過(guò)

測(cè)試對(duì)象： 軟件的各個(gè)模塊

測(cè)試方法： 白盒測(cè)試

測(cè)試人員： 白盒測(cè)試工程師或者開發(fā)人員

測(cè)試依據(jù)： 詳細(xì)設(shè)計(jì)文檔

測(cè)試內(nèi)容： 模塊的接口、邊界測(cè)試、異常測(cè)試、路徑測(cè)試、局部數(shù)據(jù)結(jié)構(gòu)的測(cè)試

Java 中使用 Junit 框架進(jìn)行單元測(cè)試

2）集成測(cè)試

按照一定的策略把單元模塊組合起來(lái)形成一個(gè)大的功能模塊，對(duì)這個(gè)大的功能模塊進(jìn)行測(cè)試

測(cè)試階段： 單元測(cè)試之后

測(cè)試對(duì)象： 集成的大模塊

測(cè)試方法： 灰盒測(cè)試

測(cè)試依據(jù)： 概要設(shè)計(jì)文檔

測(cè)試人員： 白盒測(cè)試人員或者開發(fā)人員

測(cè)試內(nèi)容： 整個(gè)模塊功能的正確性、單元模塊之間接口的正確性、單個(gè)模塊的缺陷對(duì)整個(gè)模塊功能的影響、模塊之間功能的沖突、全局?jǐn)?shù)據(jù)結(jié)構(gòu)的測(cè)試

3）系統(tǒng)測(cè)試

對(duì)整個(gè)軟件系統(tǒng)的功能、性能以及軟件運(yùn)行的軟硬件環(huán)境進(jìn)行全面測(cè)試

測(cè)試階段： 集成測(cè)試通過(guò)之后

測(cè)試對(duì)象： 整個(gè)軟件系統(tǒng)

測(cè)試方法： 黑盒測(cè)試

測(cè)試人員： 黑盒測(cè)試人員

測(cè)試依據(jù)： 需求規(guī)格說(shuō)明文檔

測(cè)試內(nèi)容： 功能、界面、兼容性、安全性、性能、可靠性、易用性、容錯(cuò)性

系統(tǒng)測(cè)試中還包含有回歸測(cè)試和冒煙測(cè)試：

• 回歸測(cè)試： 當(dāng)系統(tǒng)引入新的代碼或者修改了舊代碼之后，重新進(jìn)行測(cè)試以確保系統(tǒng)各項(xiàng)功能正常使用

  回歸測(cè)試一般采用自動(dòng)化測(cè)試

• 冒煙測(cè)試： 正式測(cè)試之前，會(huì)對(duì)系統(tǒng)的基本流程和核心功能進(jìn)行測(cè)試，測(cè)試通過(guò)之后，才會(huì)開始正式測(cè)試

4）驗(yàn)收測(cè)試

軟件上線前的最后一道測(cè)試，由用戶或者產(chǎn)品交付方依據(jù)用戶需求進(jìn)行測(cè)試

測(cè)試階段： 系統(tǒng)測(cè)試之后

測(cè)試對(duì)象： 整個(gè)系統(tǒng)

測(cè)試人員： 用戶或者產(chǎn)品交付方

測(cè)試依據(jù)： 用戶需求

測(cè)試方法： 黑盒測(cè)試

測(cè)試內(nèi)容： 同系統(tǒng)測(cè)試

5）將上面四種測(cè)試方法同 V 模型的階段進(jìn)行對(duì)應(yīng)

4. 按照測(cè)試實(shí)施組織劃分

1）α 測(cè)試

α 測(cè)試 是指讓用戶或 除了開發(fā)人員和測(cè)試人員之外 的公司內(nèi)部人員到開發(fā)現(xiàn)場(chǎng)去進(jìn)行測(cè)試

2）β 測(cè)試

β 測(cè)試 是指 實(shí)際用戶在實(shí)際使用環(huán)境下 進(jìn)行測(cè)試，不限時(shí)間、不限地點(diǎn)

比如：某些游戲在正式上線之前會(huì)開啟測(cè)試服，并邀請(qǐng)一部分玩家進(jìn)行測(cè)試

α 測(cè)試和 β 測(cè)試的區(qū)別：

• α 測(cè)試在 β 測(cè)試之前
• 兩者的測(cè)試環(huán)境不同，α 測(cè)試是在開發(fā)環(huán)境下，β 測(cè)試是在實(shí)際用戶使用環(huán)境下
• 相較于 α 測(cè)試，β 測(cè)試的規(guī)模較大，測(cè)試周期也比較長(zhǎng)

3）第三方測(cè)試

由第三方軟件測(cè)試機(jī)構(gòu) 按照業(yè)內(nèi)的標(biāo)準(zhǔn)和規(guī)范 對(duì)軟件進(jìn)行測(cè)試

5. 按照是否運(yùn)行進(jìn)行劃分

1）靜態(tài)測(cè)試

不運(yùn)行代碼，靜態(tài)的檢查代碼中可能出現(xiàn)錯(cuò)誤的地方，分析代碼的邏輯結(jié)構(gòu)和具體的方法實(shí)現(xiàn)是否滿足需求

2）動(dòng)態(tài)測(cè)試

運(yùn)行代碼，執(zhí)行測(cè)試用例進(jìn)行測(cè)試

6. 按照是否手工劃分

1）手工測(cè)試

手工的一個(gè)一個(gè)的執(zhí)行測(cè)試用例，查看測(cè)試結(jié)果

優(yōu)點(diǎn)： 有利于做探索性測(cè)試，無(wú)法被自動(dòng)化測(cè)試替代

缺點(diǎn)： 用例很多時(shí)容易出錯(cuò)，效率也比較低

2）自動(dòng)化測(cè)試

機(jī)器按照事先設(shè)定好的條件去執(zhí)行測(cè)試，這些條件包括正常的和異常的

自動(dòng)化測(cè)試按照測(cè)試對(duì)象還可分為：UI 自動(dòng)化、接口自動(dòng)化、性能自動(dòng)化

自動(dòng)化的價(jià)值和意義： 節(jié)省人力，自動(dòng)化腳本運(yùn)用率越高，越有價(jià)值

不是所有項(xiàng)目都適合自動(dòng)化測(cè)試

自動(dòng)化測(cè)試不適合于項(xiàng)目不穩(wěn)定，功能頻繁變動(dòng)的功能，一般多用于回歸測(cè)試和冒煙測(cè)試

7. 按照地域劃分

按照地域劃分可以劃分為：本地化測(cè)試 和 國(guó)際化測(cè)試

軟件的國(guó)際化： 開發(fā)軟件時(shí)使用的一種工程技術(shù)，使得軟件在適用不同國(guó)家的語(yǔ)言、風(fēng)俗以及使用習(xí)慣的時(shí)候不用更改軟件的源碼就可以做到

軟件的國(guó)際化和本地化是面向全球不同地區(qū)用戶使用的軟件系統(tǒng)的兩個(gè)過(guò)程，而本地化測(cè)試和國(guó)際化測(cè)試則是針對(duì)這類軟件產(chǎn)品進(jìn)行的測(cè)試文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-438010.html

到了這里，關(guān)于軟件測(cè)試之測(cè)試的分類（重點(diǎn)：黑盒測(cè)試、白盒測(cè)試、單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試）的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！