大家好，我是曉星航。今天為大家帶來的是 測試進階篇 相關的講解！😀

1.按測試對像劃分

1.1界面測試

軟件只是一種工具，軟件與人的信息交流是通過界面來進行的，界面是軟件與用戶交流的最直接的一層，界面的設計決定了用戶對我們設計的軟件的第一印象；界面如同人的面孔，具有吸引用戶的直接優勢，設計合理的界面能給用戶帶來輕松愉悅的感受。

界面測試（簡稱UI測試)，指按照界面的需求（一般是UI設計稿）和界面的設計規則，對我們軟件界面所 展示的全部內容進行測試和檢查，一般包括如下內容：

• 驗證界面內容顯示的完整性，一致性，準確性，友好性。比如界面內容對屏幕大小的自適應，換行，內容是否全部清晰展示；
• 驗證整個界面布局和排版是否合理，不同板塊字體的設計，圖片的展示是否符合需求；
• 對界面不同控件的測試，比如，對話框，文本框，滾動條，選項按鈕等是否可以正常使用，有效和無效的狀態是否設計合理；
• 界面的布局和色調符合當下時事的發展。

思考：常見的界面錯誤有哪些？

重疊，截斷，文字不合理自動換行等。

1.2可靠性測試

可靠性（Availability）即可用性，是指系統正常運行的能力或者程度，一般用正常向用戶提供軟件服務 的時間占總時間的百分比表示。

可靠性 = 正常運行時間/（正常運行時間+非正常運行時間）*100%

系統非正常運行的時間可能是由于硬件，軟件，網絡故障或任何其他因素（如斷電）造成的，這些因素 能讓系統停止工作，或者連接中斷不能被訪問，或者性能急劇降低導致不能使用軟件現有的服務等。

可用性指標一般要求達到4個或5個“9”，即99.99%或者99.999%

如果可用性達到 99.99%，對于一個全年不間斷（7*24的方式）運行的系統，意味著全年（252600min)不能

正常工作的時間只有 52min，不到一個小時。

如果可用性達到 99.999%，意味著全年不能正常工作的時間只有5min。

不同的應用系統，可用性的要求是不一樣的，非實時性的信息系統或一般網站要求都很低，99%和 99.5%就可以了，但是軍事系統，要求則很高；

1.3容錯性測試

容錯性測試是指系統能夠處理異常，用戶的錯誤操作而不至于系統崩潰，從而能夠提高系統的可用性。

容錯性測試包含以下方面：

• 輸入異常數據或進行異常操作，以檢驗系統的保護性。如果系統的容錯性好，系統只給出提示或內部消化掉，而不會導致系統出錯甚至崩潰。

比如數據級測試，校驗測試，環境容錯性測試，界面容錯性測試

• 災難恢復性測試。

通過各種手段，讓軟件強制性地發生故障，然后驗證系統已保存的用戶數據是否丟失，系統和數據是否能盡快恢復。

1.4文檔測試

國家有關計算機軟件產品開發文件編制指南中共有14 種文件，可分為3大類。

–開發文件：可行性研究報告、軟件需求說明書、數據要求說明書、概要設計說明書、詳細設計說明 書、數據庫設計說明書、模塊開發卷宗。

–用戶文件:用戶手冊、操作手冊，用戶文檔的作用：改善易安裝性；改善軟件的易學性與易用性；改善 軟件可靠性；降低技術支持成本。

–管理文件：項目開發計劃、測試計劃、測試分析報告、開發進度月報、項目開發總結報告。

在實際的測試中，最常見的是用戶文件的測試，例如：手冊說明書等。也會有一些公司對需求文檔進行測試，來保證需求文檔的質量。

文檔測試的關注點：

• 文檔的術語
• 文檔的正確性
• 文檔的完整性
• 文檔的一致性
• 文檔的易用性

1.5兼容性測試

大家經常上網，同一網站在不同的瀏覽器上表現不一樣，有遇到過嗎？IE-工具-兼容視圖設置

兼容性測試需求是指明確要測試的兼容環境，考慮軟，硬件的兼容，就軟件兼容來說，主要考慮以下幾個方面：

• 系統自身版本的兼容，用戶已有數據的兼容，數據兼容是重中之重，對用戶來說，數據是最有價值的。
• 測試與應用環境的兼容性，比如操作系統，應用平臺，瀏覽器的兼容
• 測試與第三方系統以及第三方數據的兼容性

對于環境（操作系統，應用平臺）兼容性的測試不僅僅局限在操作系統，瀏覽器這兩個因素，還包括以下，32 位，64位CPU；手機平臺Android ，iOS，Windows Phone；支持不同的Internet連接速度。

對于iOS和Android兩個平臺，還要區分手機和平板電腦，考慮不同的型號（屏幕尺寸，分辨率等）。

1.6易用性測試

許多產品都應用人體工程學的研究成果，是產品在使用起來更加靈活和，舒適。軟件產品也始終關注用 戶體驗，讓用戶獲得舒適，易用的體驗，針對軟件這方面的測試稱之為易用性測試。

易用性在ISO25020標準中指容易發現，容易學習和容易使用。易用性包含七個要素：符合標準和規 范，直觀性，一致性，靈活性，舒適性，正確性和實用性。我們主要討論以下幾個方面

1，標準性和規范性

對于現有的軟件運行平臺，通常其UI標準已經不知不覺地被確立了，成為大家的共識。多數用戶已經習 慣并且接受了這些標準和規范，或者說已經認同了這些信息所代表的的含義。比如安裝軟件的界面的外觀，在什么場合使用恰當的對話框等。

所以用戶界面上的各中信息應該符合規范和習慣，否則用戶使用起來會不舒適，并得不到用戶的認可。

測試人員需要把與標準規范，習慣不一致的問題報告為缺陷

2，直觀性

用戶界面的直觀性，要求軟件功能特性易懂，清晰。用戶界面布局合理，對操作的響應在用戶的預期之 中。比如數據統計結果用報表的形式（條形圖，扇形圖等）展示清晰直觀；現在主流的很多搜索引擎和 日歷的設計也有直觀性的特點；

3，靈活性

軟件可以有不同的選項以滿足不同使用習慣的用戶來完成相同的功能。但是靈活性的設計要把握好度， 不然可能由于太多的用戶狀態和方式的選擇，增加了軟件設計的復雜性，和程序實現的難度。

例如手機鍵盤有九宮格和全鍵盤，還支持手寫，滿足了不同用戶的需求

4，舒適性

舒適性主要強調界面友好，美觀，操作過程順暢，色彩用運恰當，按鈕的立體感等。例如左手鼠標的設 置給習慣用左手的人帶來了便利，也為右手十分勞累時提供了另一種途徑；

1.7安裝卸載測試

應用的安裝和卸載在任何一款APP中都屬于最基本功能。一旦出錯，就屬于優先級為緊要Critical的缺 陷。主要需要考慮以下方面：

• 軟件不同的安裝和卸載方式；
• 應用是否可以在不同的環系統，版本下安裝（安裝兼容性）
• 安裝或者卸載過程中是否可以手動暫停，或者取消
• 安裝空不足的時候系統是否有提示
• 是否可以正常的卸載，以及應用軟件的各種卸載方式
• 卸載和安裝過程中出現環境問題，軟件是否可以正常并且合理的應對，比如死機，斷電，斷網等

1.8安全測試

安全性是指信息安全，是指計算機系統或網絡保護用戶數據隱私，完整，保護數據正常傳輸和抵御黑客，病毒攻擊的能力。安全性測試屬于非功能性測試很重要的一個方面，系統常見的安全漏洞和威脅如下

• 輸入域，如輸入惡性或者帶有病毒的腳本或長字符串；
• 代碼中的安全性問題，如SQL/XML注入
• 不安全的數據存儲或者傳遞
• 數據文件，郵件文件，系統配置文件等里面有危害系統的信息或者數據；
• 有問題的訪問控制，權限分配等
• 假冒ID：身份欺騙
• 篡改，對數據的惡意修改，破壞數據的完整性

安全性測試的方法有代碼評審，滲透測試，安全運維等，常用的靜態安全測試工具有，Coverity，IBM Appscan Source，HPFortify，常用的動態安全測試有OWASP的ZAP，HP WebInspect等。其中靜態安 全測試是常用的安全性測試的方法。

問題： 對于上傳和下載的安全性該如何測試？

1.9性能測試

我們在使用軟件的時候有時會碰到軟件網頁打開時越來越慢，查詢數據時很長時間才顯示列表，軟件運行越來越慢等問題，這些問題都是系統的性能問題引起的。

要進行軟件產品的性能問題，要對產品的性能需求進行分析，然后基于系統的性能需求和系統架構，完成性能測試的設計和執行，最后要進行持續的性能調優。常見的性能問題如下：

• 資源泄露
• 資源瓶頸
• 線程死鎖，線程阻塞
• 查詢速度慢或效率低
• 受外部系統影響越來越大

衡量一個系統性能好壞的關鍵性指標有，用戶響時間，事務平均響應時間（TPS），吞吐率，每秒點擊 次數，內存和CPU使用率等。

事務四個特性：原子性，一致性，隔離性，持久性

1.10內存泄漏測試

很多軟件系統都存在內存泄露的問題，尤其是缺乏自動垃圾回收機制的“非托管”語言編寫的程序，例如 C、CH、Delphi等。從用戶使用的角度來看，內存泄露本身不會造成什么危害，一般用戶可能根本不會 感覺到內存泄露的存在。但是內存泄露是會累積的，只要執行的次數足夠多，最終會耗盡所有可用內存，使軟件的執行越來越慢，最后停止響應。可以把這種軟件的問題比喻成軟件的“慢性病”。

造成內存泄露的原因有很多，最常見的有以下幾種。

• 分配完內存之后忘了回收。
• 程序寫法有問題，造成沒辦法回收（如死循環造成無法執行到回收步驟）。
• 某些API函數的使用不正確，造成內存泄露。

內存泄漏的檢測方法

• 人工靜態法：代碼走讀，人工查找未被回收的內存。
• 自動工具法：借助相應測試內存泄漏的工具，如Visual Leak Detector，記錄每次內存分配，清楚 告訴用戶內存是如何泄漏的。

2.按是否查看代碼劃分

在軟件測試崗位的面試中，常常被面試官問到的概念就是黑盒和白盒的測試了，下面就來徹底討論一下

2.1黑盒測試(Black-box Testing)

黑盒測試就是在完全不考慮程序邏輯和內部結構的情況下，檢查系統功能是否按照需求規格說明書的規定正常使用、是否能適當的接收輸入數據而輸出正確的結果，滿足規范需求。

所以，黑盒測試又稱之為數據驅動測試，只注重軟件的功能

黑盒測試的優點

• 不需要了解程序內部的代碼以及實現，不關注軟件內部的實現。
• 從用戶角度出發設計測試用例，很容易的知道用戶會用到哪些功能，會遇到哪些問題，鍛煉測試人員的產品思維
• 測試用例是基于軟件需求開發文檔，不容易遺漏軟件需求文檔中需要測試的功能。

黑盒測試的缺點是不可能覆蓋所有代碼。

黑盒測試用到的測試方法有，等價類，邊界值，因果圖，場景法，錯誤猜測法等。

2.2白盒測試(White-box Testing)

白盒測試又稱為結構測試或邏輯測試，它一般用來分析程序的內部結構，針對程序的邏輯結構來設計測試用例進行測試。

白盒測試的測試目的是，通過檢查軟件內部的邏輯結構，對軟件中的邏輯路徑進行覆蓋測試；在程序不同地方設立檢查點，檢查程序的狀態，以確定實際運行狀態與預期狀態是否一致。

主要包含六種測試方法：語句覆蓋、判定覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋、路徑覆蓋。

白盒測試的缺點是：對業務功能有一定的漏洞。

2.3灰盒測試(Gray-Box Testing)

灰盒測試，是介于白盒測試與黑盒測試之間的一種測試，灰盒測試多用于集成測試階段，不僅關注輸出、輸入的正確性，同時也關注程序內部的情況。

3.按開發階段劃分

測試金字塔

3.1單元測試(Unit Testing)

單元測試是對軟件組成單元進行測試。其目的是檢驗軟件基本組成單位的正確性。測試的對象是軟件設 計的最小單位：模塊。又稱為模塊測試

測試階段：編碼后或者編碼前（TDD）

測試對象：最小模塊

測試人員：白盒測試工程師或開發工程師

測試依據：代碼和注釋+詳細設計文檔 測試方法：白盒測試

測試內容：模塊接口測試、局部數據結構測試、路徑測試、錯誤處理測試、邊界測試

Java如何進行單元測試？

3.2集成測試(Integration Testing)

集成測試也稱聯合測試（聯調）、組裝測試，將程序模塊采用適當的集成策略組裝起來，對系統的接口 及集成后的功能進行正確性檢測的測試工作。集成主要目的是檢查軟件單位之間的接口是否正確。

• 測試階段：一般單元測試之后進行
• 測試對象：模塊間的接口
• 測試人員：白盒測試工程師或開發工程師
• 測試依據：單元測試的模塊+概要設計文檔 測試方法：黑盒測試與白盒測試相結合
• 測試內容：模塊之間數據傳輸、模塊之間功能沖突、模塊組裝功能正確性、全局數據結構、單模塊 缺陷對系統的影響

3.3系統測試(System Testing)

新買手機都會有一個合格標簽，在出廠前手機廠會所某型號的手機上的所有功能全部測試一遍。包括手機硬件 本身，手機上自帶的APP。

將軟件系統看成是一個系統的測試。包括對功能、性能以及軟件所運行的軟硬件環境進行測試。

• 測試階段：集成測試通過之后
• 測試對象：整個系統（軟、硬件）
• 測試人員：黑盒測試工程師
• 測試依據：需求規格說明文檔
• 測試方法：黑盒測試
• 測試內容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

3.4回歸測試(Regression Testing)

接著上邊的美顏功能不可用的例子，拿去維修點進行了維修，拿到手機后第一件事情是先看美顏功能修好了沒有，第二事情就是看看手機的其它常用功能是否正常。

回歸測試是指修改了舊代碼后，重新進行測試以確認修改沒有引入新的錯誤或導致其他代碼產生錯誤。

在整個軟件測試過程中占有很大的工作量比重，軟件開發的各個階段都會進行多次回歸測試。隨著系統 的龐大，回歸測試的成本越來越大，通過選擇正確的回歸測試策略來改進回歸測試的效率和有效性是很有意義的。

3.5冒煙測試（smoke testing）

冒煙測試的對象是每一個新編譯的需要正式測試的軟件版本，目的是確認軟件主要功能和核心流程正常，在正式進行系統測試之前執行。冒煙測試一般在開發人員開發完畢后提交給測試人員來進行測試 時，先進行冒煙測試，保證基本功能正常，不阻礙后續的測試。

如果冒煙測試通過，則測試人員開始進行正式的系統測試，如果不通過，則測試人員可以讓開發人員重新修復代碼直到冒煙測試通過，再開始進行系統測試。

回歸測試和冒煙測試都屬于系統測試。

3.6驗收測試(Acceptance Testing)

買到新手機，一般會有 7天包退，一個月包換，我們會盡量在7天內把手機的所有功能都試一遍。

驗收測試是部署軟件之前的最后一個測試操作。它是技術測試的最后一個階段，也稱為交付測試。驗收測試的目的是確保軟件準備就緒，按照項目合同、任務書、雙方約定的驗收依據文檔，向軟件購買都展 示該軟件系統滿足原始需求。

• 測試階段：系統測試通過之后
• 測試對象：整個系統（包括軟硬件）。
• 測試人員：主要是最終用戶或者需求方。 測試依據：用戶需求、驗收標準
• 測試方法：黑盒測試
• 測試內容：同系統測試(功能…各類文檔等)

4.按測試實施組織

α測試(Alpha Testing)

手機出廠前最后一次測試，開發和測試人員不參與。

α測試是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的測試。α測試的目的是評價軟件產品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。

大型通用軟件，在正式發布前，通常需要執行Alpha和Beta測試。α測試不能由程序員或測試員完成。

β測試(Beta Testing)

新手機購買回來，參與測試的人是購買者，使用的場所及環境已不再是手面廠商的環境及場所。

Beta測試是一種驗收測試。Beta測試由軟件的最終用戶們在一個或多個場所進行。

α測試與Beta測試的區別：

測試的場所不同：Alpha測試是指把用戶請到開發方的場所來測試,beta測試是指在一個或多個用戶的場所進行的測試。

Alpha測試的環境是受開發方控制的,用戶的數量相對比較少,時間比較集中。beta測試的環境是不受開發方控制的,用戶數量相對比較多,時間不集中。

alpha測試先于beta測試執行。通用的軟件產品需要較大規模的beta測試,測試周期比較長。 第三方測試 介于開發方和用戶方間的組織的測試。

第三方測試

介于開發方和用戶方間的組織的測試。

5.按是否運行劃分

靜態測試(Static testing)

所謂靜態測試（static testing）就是不實際運行被測軟件，而只是靜態地檢查程序代碼、界面或文檔中 可能存在的錯誤的過程。不以測試數據的執行而是對測試對象的分析過程，僅通過分析或檢查源程序的設計、內部結構、邏輯、代碼風格和規格等來檢查程序的正確性。

動態測試(Dynamic testing)

動態測試（dynamic testing），指的是實際運行被測程序，輸入相應的測試數據，檢查實際輸出結果 和預期結果是否相符的過程，所以判斷一個測試屬于動態測試還是靜態的，唯一的標準就是看是否運行 程序。

大多數軟件測試工作都屬于動態測試。

6.按是否手工劃分

手工測試(Manual testing)

手工測試就是由人去一個一個的輸入用例，然后觀察結果，和機器測試相對應，屬于比較原始但是必須 的一個步驟。總結優缺點：

• 優點：自動化無法替代探索性測試、發散思維結果的測試。
• 缺點：執行效率慢，量大易錯。

自動化測試(Automation Testing)

就是在預設條件下運行系統或應用程序，評估運行結果，預先條件應包括正常條件和異常條件。簡單說 自動化測試是把以人為驅動的測試行為轉化為機器執行的一種過程。

自動化測試比如功能測試自動化、性能測試自動化、安全測試自動化。

自動化測試按照測試對象來分，還可以分為接口測試、UI測試等。接口測試的ROI（產出投入比）要比 UI測試高。

自動化實施步驟：
1.完成功能測試，版本基本穩定
2.根據項目特性，選擇適合項目的自動化工具，并搭建環境
3.提取手工測試的測試用例轉化為自動化測試的用例
4.通過工具、代碼實現自動化的構造輸入，自動檢測輸出結果是否符合預期
5.生成自動測試報告
6.持續改進，腳本優化。

7.按測試地域劃分

什么是軟件國際化？
是在軟件設計和文檔開發過程中，使得功能和代碼設計能處理多種語言和文化習俗，使創建不同語言版本時，
不需要重新設計源程序代碼的軟件工程方法。

7.1國際化測試

軟件的國際化和軟件的本地化是開發面向全球不同地區用戶使用的軟件系統的兩個過程。而本地化測試 和國際化測試則是針對這類軟件產品進行的測試。由于軟件的全球化普及，還有軟件外包行業的興起， 軟件的本地化和國際化測試儼然成為了一個獨特的測試專門領域。

本地化和國際化測試與其他類型的測試存在很多不同之處。下面是本地化和國際化測試 的一些要點。

1、本地化后的軟件在外觀上與原來版本是否存在很大的差異，外觀是否墼齊、不走樣。

2、是否對所有界面元素都進行了本地化處理，包括對話框、菜單、工具欄、狀態欄、提示信息（包括 聲音的提示）、日志等。

3、在不同的屏幕分辨率下界面是否正常顯示。

4、是否存在不同的字體大小，字體設置是否恰當。

5、日期、數字格式、貨幣等是否能適應不同國家的文化習俗。例如，中文是年月日，而英文是月日 年。

6、排序的方式是否考慮了不同語言的特點。例如，中文按照第一個字的漢語拼音順序排序，而英文按 照首字母排序。

7、在不同的國家采用不同的度量單位，軟件是否能自適應和轉換。

8、軟件是否能在不同類型的硬件上正常運行，特別是在當地市場上銷售的流行硬件上。

9、軟件是否能在Windows或者其他操作系統的當地版本上正常運行。

10、聯機幫助和文檔是否已經翻譯，翻譯后的鏈接是否正常。正文翻譯是否正確、恰當， 是否有語法錯誤。

軟件本地化和國際化測試是一個綜合了翻譯行業和軟件測試行業的測試類型。它要求測 試人員具備一定 的翻譯能力、語言文化，同時具備測試人員的基本技能。

7.2本地化測試

之前我們所講的全是本地化測試。

感謝各位讀者的閱讀，本文章有任何錯誤都可以在評論區發表你們的意見，我會對文章進行改正的。如果本文章對你有幫助請動一動你們敏捷的小手點一點贊，你的每一次鼓勵都是作者創作的動力哦！😘