産品中心

一(yī / yì ／yí).單元測試（模塊測試）

單元測試是(shì)對軟件組成單元進行測試。其目的(de)是(shì)檢驗軟件組成單位的(de)正确性。測試對象是(shì)：模塊。

對模塊進行測試，單獨的(de)一(yī / yì ／yí)個(gè)模塊測試，屬于(yú)靜态測試的(de)一(yī / yì ／yí)類

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

測試對象：最小模塊

測試人(rén)員：白盒測試工程師或開發工程師（測源碼）

測試依據：代碼和(hé / huò)注釋+詳細設計文檔

測試方法：白盒測試（因爲(wéi / wèi)要(yào / yāo)測源碼）

測試内容：模塊接口測試（測試模塊裏面的(de)參數傳遞是(shì)否正确）、局部數據結構測試（測試變量的(de)作用域範圍）、路徑測試（if-else 判斷必須覆蓋所有分支）、錯誤處理測試、邊界測試（ for 循環）

二.集成測試

集成測試也(yě)稱聯合測試，将程序模塊采用适當的(de)集成策略組裝起來(lái)，對系統的(de)接口（白盒測試）以(yǐ)及集成後的(de)功能（黑盒測試進行正确性檢測的(de)一(yī / yì ／yí)種測試。集成主要(yào / yāo)目的(de)是(shì)檢查軟件單位之(zhī)間的(de)接口是(shì)否正确。

測試階段：一(yī / yì ／yí)般單元測試之(zhī)後進行

測試對象：模塊間的(de)接口

測試人(rén)員：白盒測試工程師或開發工程師

測試依據：單元測試的(de)模塊+概要(yào / yāo)設計文檔

測試方法：黑盒測試與白盒測試相結合

測試内容：模塊之(zhī)間數據傳輸、模塊之(zhī)間功能沖突、模塊組裝功能正确性、全局數據結構、單個(gè)模塊缺陷對系統的(de)影響

三.系統測試

将軟件系統看成是(shì)一(yī / yì ／yí)個(gè)系統的(de)測試。包括對功能、性能以(yǐ)及軟件所運行的(de)軟硬件環境進行測試。時(shí)間大(dà)部分在(zài)系統測試執行階段，包括回歸測試和(hé / huò)冒煙測試。

測試階段：集成測試通過之(zhī)後

測試對象：整個(gè)系統（軟、硬件）

測試人(rén)員：黑盒測試工程師（對功能測試）

測試依據：需求規格說(shuō)明文檔

測試方法：黑盒測試

測試内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

回歸測試(Regression Testing)

四.回歸測試

回歸測試是(shì)指修改了(le／liǎo)舊代碼後，重新進行測試以(yǐ)确認修改沒有引入新的(de)錯誤或導緻其他(tā)代碼産生錯誤。

有了(le／liǎo)代碼修改後就(jiù)進行回歸測試，根據測試階段确定回歸範圍。

在(zài)整個(gè)軟件測試過程中占有很大(dà)的(de)工作量比重，軟件開發的(de)各個(gè)階段都會進行多次回歸測試。随着系統的(de)龐大(dà)，回歸測試的(de)成本越來(lái)越大(dà)，通過選擇正确的(de)回歸測試策略來(lái)改進回歸測試的(de)效率和(hé / huò)有效性是(shì)很有意義的(de)。

五.冒煙測試

這(zhè)一(yī / yì ／yí)術語源自硬件行業。

對一(yī / yì ／yí)個(gè)硬件或硬件組件進行更改或修複後，直接給設備加電。如果沒有冒煙，則該組件就(jiù)通過了(le／liǎo)測試。也(yě)可以(yǐ)理解爲(wéi / wèi)該種測試耗時(shí)短，僅用一(yī / yì ／yí)袋煙功夫足夠了(le／liǎo)。

冒煙測試的(de)對象是(shì)每一(yī / yì ／yí)個(gè)新編譯的(de)需要(yào / yāo)正式測試的(de)軟件版本，目的(de)是(shì)确認軟件基本功能正常，可以(yǐ)進行後續的(de)正式測試工作。冒煙測試的(de)執行者是(shì)版本編譯人(rén)員。

概念：對核心主幹流程進行測試，如果成功，就(jiù)認爲(wéi / wèi)成功

作用：判斷是(shì)否接受測試的(de)标準，若核心主幹都走不(bù)通，那麽直接打下去

六.驗收測試

買到(dào)新手機，一(yī / yì ／yí)般會有7天包退，一(yī / yì ／yí)個(gè)月包換，我們會盡量在(zài)7天内把手機的(de)所有功能都試一(yī / yì ／yí)遍。

驗收測試是(shì)部署軟件之(zhī)前的(de)最後一(yī / yì ／yí)個(gè)測試操作。它是(shì)技術測試的(de)最後一(yī / yì ／yí)個(gè)階段，也(yě)稱爲(wéi / wèi)交付測試。驗收測試的(de)目的(de)是(shì)确保軟件準備就(jiù)緒，按照項目合同、任務書、雙方約定的(de)驗收依據文檔，向軟件購買都展示該軟件系統滿足原始需求。

測試階段：系統測試通過之(zhī)後

測試對象：整個(gè)系統（包括軟硬件）。

測試人(rén)員：主要(yào / yāo)是(shì)最終用戶或者需求方。

測試依據：用戶需求、驗收标準

測試方法：黑盒測試（對功能進行測試）

測試内容：同系統測試(功能…各類文檔等)

七.靜态測試（不(bù)運行程序本身，測試文檔）

靜态測試是(shì)指不(bù)運行被測程序本身，僅通過分析或檢查源程序的(de)語法、結構、過程、接口等來(lái)檢查程序的(de)正确性。‘對需求規格說(shuō)明書、軟件設計說(shuō)明書、源程序做結構分析、流程圖分析、符号執行來(lái)找錯。

八.動态測試

動态測試方法是(shì)指通過運行被測程序，檢查運行結果與預期結果的(de)差異，并分析運行效率、正确性和(hé / huò)健壯性等性能。大(dà)多數軟件測試工作都屬于(yú)動态測試。

九.手工測試

就(jiù)是(shì)由人(rén)去一(yī / yì ／yí)個(gè)一(yī / yì ／yí)個(gè)的(de)輸入測試用例，然後觀察結果，和(hé / huò)機器測試相對應，屬于(yú)比較原始但是(shì)不(bù)可缺少的(de)一(yī / yì ／yí)個(gè)步驟。

總結優缺點：

（1）優點：自動化無法替代探索性測試、發散思維結果的(de)測試。

（2）缺點：執行效率慢，量大(dà)易錯。

十.自動化測試

就(jiù)是(shì)在(zài)預設條件下運行系統或應用程序，評估運行結果，預先條件應包括正常條件和(hé / huò)異常條件。

簡單說(shuō)自動化測試是(shì)把以(yǐ)人(rén)爲(wéi / wèi)驅動的(de)測試行爲(wéi / wèi)轉化爲(wéi / wèi)機器執行的(de)一(yī / yì ／yí)種過程。

自動化實施步驟：

1.完成功能測試，版本基本穩定

2.根據項目特性，選擇适合項目的(de)自動化工具，并搭建環境

3.提取手工測試的(de)測試用例轉化爲(wéi / wèi)自動化測試的(de)用例

4.通過工具、代碼實現自動化的(de)構造輸入，自動檢測輸出(chū)結果是(shì)否符合預期

5.生成自動測試報告

6.持續改進，腳本優化。

十一(yī / yì ／yí).業務測試

業務測試是(shì)測試人(rén)員把系統各個(gè)模塊串接起來(lái)運行、模拟真實用戶實際的(de)工作流程，滿足用戶需求定義的(de)功能來(lái)進行測試的(de)過程。

例如查看郵件：

登錄網站-輸入用戶名、密碼登錄-進入收件箱-查到(dào)郵件-點擊打開-查閱-關閉郵件-退出(chū)郵箱-關閉網站

業務測試關注需求和(hé / huò)用戶

所有業務流程進行測試，包過主幹流程，分支流程，甚至更小的(de)流程

測不(bù)同的(de)業務，必須對項目的(de)需求特别了(le／liǎo)解

十二.界面測試

界面測試（簡稱UI測試)，測試用戶界面的(de)功能模塊的(de)布局是(shì)否合理、整體風格是(shì)否一(yī / yì ／yí)緻、各個(gè)控件的(de)放置位置是(shì)否符合客戶使用習慣，此外還要(yào / yāo)測試界面操作便捷性、導航簡單易懂性，頁面元素的(de)可用性，界面中文字是(shì)否正确，命名是(shì)否統一(yī / yì ／yí)，頁面是(shì)否美觀，文字、圖片組合是(shì)否完美等。

十三.文檔測試

十四.兼容性測試

大(dà)家經常上(shàng)網，同一(yī / yì ／yí)網站在(zài)不(bù)同的(de)浏覽器上(shàng)表現不(bù)一(yī / yì ／yí)樣

WEB測試 ；APP測試

兼容性主要(yào / yāo)是(shì)指軟件之(zhī)間能否很好地(dì / de)運作，會不(bù)會有影響、軟件和(hé / huò)硬件之(zhī)間能否發揮很好的(de)效率工作，會不(bù)會影響導緻系統的(de)崩潰。

平台測試

浏覽器測試

軟件本身能否向前或者向後兼容

測試軟件能否與其它相關的(de)軟件兼容

數據兼容性測試

最常見的(de)就(jiù)是(shì)浏覽器的(de)兼容性測試，不(bù)同浏覽器在(zài)css，js解析上(shàng)的(de)不(bù)同會導緻頁面的(de)顯示不(bù)同。

十五.易用性測試

易用性（Useability）是(shì)交互的(de)适應性、功能性和(hé / huò)有效性的(de)集中體現。

手機拔打電話功能不(bù)放在(zài)首頁，放在(zài)一(yī / yì ／yí)個(gè)目錄下邊，點擊三四次才可以(yǐ)找到(dào)拔打電話功能，這(zhè)個(gè)功能好用嗎？

十六.性能測試

檢查系統是(shì)否滿足需求規格說(shuō)明書中規定的(de)性能。

通常表現在(zài)以(yǐ)下幾個(gè)方面：

對資源利用（如内存、處理機周期等）進行的(de)精确度量

對執行間隔

日志事件（如中斷，報錯）

響應時(shí)間

吞吐量（TPS）

輔助存儲區（例如緩沖區、工作區的(de)大(dà)小等）

處理精度等進行的(de)監測

十七.易用性測試

易用性（Useability）是(shì)交互的(de)适應性、功能性和(hé / huò)有效性的(de)集中體現。易用性屬于(yú)人(rén)體工程學的(de)範疇，人(rén)體工程學（ergonomics）是(shì)一(yī / yì ／yí)門将日常使用的(de)東西設計爲(wéi / wèi)易于(yú)使用和(hé / huò)實用性強的(de)學科。

手機拔打電話功能不(bù)放在(zài)首頁，放在(zài)一(yī / yì ／yí)個(gè)目錄下邊，點擊三四次才可以(yǐ)找到(dào)拔打電話功能，這(zhè)個(gè)功能好用嗎？

在(zài)某些大(dà)廠會有專門的(de)部門來(lái)進行易用性測試，又叫用戶體驗測試。

十八. 安裝測試

測試程序的(de)安裝、卸載

典型的(de)是(shì)app的(de)安裝、卸載

十九.安全測試

安全測試是(shì)一(yī / yì ／yí)個(gè)相對獨立的(de)領域，需要(yào / yāo)更多的(de)專業知識。例如web的(de)安全測試，需要(yào / yāo)熟悉各種網絡協議

TCP\HTTP，防火牆，CDN，熟悉各種操作系統的(de)漏洞，熟悉路由器等。從軟件來(lái)說(shuō)，熟悉各種攻擊手段，例如

SQL注入、Xss等。

作爲(wéi / wèi)web入門測試，可以(yǐ)IBM的(de)appscan。

二十.内存洩漏測試

電腦打開的(de)東西太多，機器反應慢甚至死機，重啓之(zhī)後就(jiù)好了(le／liǎo)，過會同樣的(de)問題出(chū)現

很多軟件系統都存在(zài)内存洩露的(de)問題，尤其是(shì)缺乏自動垃圾回收機制的(de)“非托管”語言 編寫的(de)程序，例如C、CH、Delphi等。從用戶使用的(de)角度來(lái)看，内存洩露本身不(bù)會造成什 麽危害，一(yī / yì ／yí)般用戶可能根本不(bù)會感覺到(dào)内存洩露的(de)存在(zài)。但是(shì)内存洩露是(shì)會累積的(de)，隻要(yào / yāo)執 行的(de)次數足夠多，最終會耗盡所有可用内存，使軟件的(de)執行越來(lái)越慢，最後停止響應。可以(yǐ) 把這(zhè)種軟件的(de)問題比喻成軟件的(de)“慢性病”。

造成内存洩露的(de)原因有很多，最常見的(de)有以(yǐ)下幾種。

1.分配完内存之(zhī)後忘了(le／liǎo)回收。

2.程序寫法有問題，造成沒辦法回收。

3.某些API函數的(de)使用不(bù)正确，造成内存洩露。

4.沒有及時(shí)釋放。

内存洩漏的(de)檢測：

1.對于(yú)不(bù)同的(de)程序可以(yǐ)使用不(bù)同的(de)方法來(lái)進行内存洩露的(de)檢查，還可以(yǐ)使用一(yī / yì ／yí)些專門的(de)工具來(lái)進行内存問題的(de)檢查，例如MemProof. AQTime、Purify、BundsChecker等。 有些開發工具本身就(jiù)帶有内存問題檢查機制．要(yào / yāo)确保程序員在(zài)編寫程序和(hé / huò)編譯程序的(de)時(shí)候打開這(zhè)些功能。

2.通過代碼掃描分析工具來(lái)檢查