1.按照測試對象劃分

①界面測試

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

而界面的設計是由 UI（User Interface - 用戶界面）設計師畫出來的，然后前端程序員照著 UI 的設計稿進行制作，因此，界面測試又可稱為 UI 測試。

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

1. 測試軟件界面元素的完整性、正確性、一致性、友好性。在 UI 設計稿上，對于每個界面元素的尺寸、位置、效果都有明確的標識，要保證和 UI 設計稿一模一樣。
2. 軟件界面的排版布局要合理，要站在用戶的角度去考慮。字體的設計、圖片的展示等，不合理的地方可以向 UI 設計師進行反饋。
3. 測試界面的自適應性。界面適應不同的頁面大小，界面必須功能完整、文字完整、圖片完整，不出現(xiàn)疊加、消失、功能無法使用的情況；PC端和移動端之間最大的區(qū)別就是屏幕的尺寸不同，如果對移動端使用PC端顯示的界面，很明顯尺寸上是不匹配的，很可能會導致頁面顯示錯亂！
4. 界面的控件功能正常。控件就是頁面上看到的最小化的圖型 (對話框、滾動條、各類按鈕…)，按鈕的有效狀態(tài)和失效狀態(tài)是否可以區(qū)分（比如：有效狀態(tài)：按鈕高亮；無效狀態(tài)：按鈕置灰，不能進行點擊操作)
5. 界面設計 (顏色、布局) 考慮當下時事。如一些特殊的紀念日/節(jié)日，根據(jù)其意義/氛圍進行界面設計。

②可靠性測試

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

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

百分比越高，可靠性越強，反之就越低。

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

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

如果可用性達到99.99%，對于一個全年不間斷（7*24的方式）運行的系統(tǒng)，意味著全年（252600min)不能正常工作的時間只有52min，不到一個小時。 如果可用性達到99.999%，意味著全年不能正常工作的時間只有5min。

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

那么，可靠性怎么去測試呢?

首先我們要知道，這里涉及到性能測試，只依靠人工測試是不現(xiàn)實的，可以借助一些工具，編寫一些腳本，讓這些腳本自動運行。我們只需要看最后運行出來的報告，然后總結(jié)結(jié)果即可?？梢韵茸屲浖\行 24 小時，通過腳本將出現(xiàn)故障的時間記下來，去計算百分比，然后是 7 * 24 小時，一個月，三個月，六個月，一年…

③容錯性測試

系統(tǒng)發(fā)生異常，或者由于用戶的錯誤操作導致軟件系統(tǒng)發(fā)生錯誤，軟件自我消化掉錯誤，或者進行修改/修復，不讓客戶感知到系統(tǒng)內(nèi)部的情況，就叫做系統(tǒng)的容錯性。

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

• 輸入異常數(shù)據(jù)或進行異常操作，以檢驗系統(tǒng)的保護性。如果系統(tǒng)的容錯性好，系統(tǒng)只給出提示或內(nèi)部消化掉，而不會導致系統(tǒng)出錯甚至崩潰。比如數(shù)據(jù)級測試、校驗測試、環(huán)境容錯性測試、界面容錯性測試。
• 災難恢復性測試，通過各種手段，讓軟件強制性地發(fā)生故障，然后驗證系統(tǒng)已保存的用戶數(shù)據(jù)是否丟失，系統(tǒng)和數(shù)據(jù)是否能盡快恢復。比如重要的數(shù)據(jù)庫服務器部署的地點發(fā)生了地震，海嘯等，這種情況下數(shù)據(jù)之所以能很快的恢復，是因為數(shù)據(jù)可能備份存儲到了若干臺其他的服務器對應的數(shù)據(jù)庫當中，每個服務器都部署在不同的地點，當災難發(fā)生時，就可以快速恢復數(shù)據(jù)保證正常的使用。

常見的容錯性說明

【1】數(shù)據(jù)的容錯性

比如：取款機輸入小于100的取款數(shù)目，我們知道取款機中只能取出能被100整除的數(shù)目。
一般取款機在遇到這個問題的時候，都會彈出溫馨提示 “請修改你的取款金額之類的信息”，此時我們只需要點擊確定，修改取款金額即可。
其實在提款機出現(xiàn)這個提示之前, 也就是我們輸入非整百的金額, 并點擊取款按鈕的時候, 這個數(shù)據(jù)已經(jīng)在軟件系統(tǒng)中走了一圈, 引發(fā)了異常; 只不過表現(xiàn)的形式不是報異常, 而是提示你重新輸入整百的取款金額.
簡單來說就是我們的輸入已經(jīng)觸發(fā)了異常, 但是系統(tǒng)并沒有報出異常, 而是給予正確的提示, 這就已經(jīng)是處理了異常這種行為, 就是容錯性的體現(xiàn).

【2】校驗容錯性

在搜索某些關(guān)鍵詞的時候, 在前后加上空格, 系統(tǒng)會進行自動化過濾(將前后的空格移除掉); 還有校驗忽略大小寫字母, 主要體現(xiàn)在驗證碼環(huán)節(jié), 在內(nèi)部驗證的時候, 自動的將我門將輸入的字母進行轉(zhuǎn)換了, 然后, 再去跟驗證碼進行比較.

【3】界面容錯性

界面的容錯性, 體現(xiàn)在復雜操作的提示, 有的時候, 軟件的操作有些復雜, 導致有些用戶就搞不清楚應該操做哪一步了, 此時, 就需要軟件界面給予下一步的操作提示, 以免用戶操作錯誤.
界面容錯性, 就是在用戶進行一些復雜/危險/有風險的操作時, 給予正確的提示, 一定程度上避免用戶在不知情的情況做出錯誤操作.

【4】環(huán)境容錯性

環(huán)境的容錯性, 主要體現(xiàn)于軟件所在環(huán)境發(fā)生故障的時候, 具有備用的處理方案, 可以讓用戶無感知切換, 環(huán)境的故障, 主要體現(xiàn)于: 網(wǎng)絡, 電源, 硬件環(huán)境, 軟件的部署環(huán)境.

比如淘寶的秒殺價活動, 這種情況下的用戶的請求是非常多的, 如果軟件所在環(huán)境發(fā)生故障, 導致用戶無法進行操作, 那么就會給淘寶造成巨大的損失, 因此, 對于環(huán)境要有各種各樣的備用方案, 以面對突發(fā)情況的發(fā)生, 在環(huán)境發(fā)生故障的時候, 運維感知到之后, 立馬就給你切換成備用方案, 這個切換的過程, 是用戶感知不到的.

總的來說這些容錯性都是對于軟件系統(tǒng)發(fā)生故障的時候, 具有備用的處理方案, 使得用戶在無感知的情況完成對應的操作.

④文檔測試

文檔測試就是針對與軟件開發(fā)相關(guān)的文檔所進行的測試.

國家有關(guān)計算機軟件產(chǎn)品開發(fā)文件編制指南中共有14 種文件, 可分為3 大類。

1. 開發(fā)文件: 可行性研究報告, 軟件需求說明書, 數(shù)據(jù)要求說明書, 概要設計說明書, 詳細設計說明書(技術(shù)文檔, 記錄每一個代碼的模塊如何實現(xiàn)), 數(shù)據(jù)庫設計說明書, 模塊開發(fā)卷宗, 開發(fā)文件的作用: 提高開發(fā)效率, 保證開發(fā)的一致性和正確性.
2. 用戶文件: 用戶手冊, 操作手冊, 用戶文檔的作用：改善易安裝性; 改善軟件的易學性與易用性; 改善軟件可靠性; 降低技術(shù)支持成本.
3. 管理文件: 項目開發(fā)計劃, 測試計劃, 測試分析報告, 開發(fā)進度月報, 項目開發(fā)總結(jié)報告, 管理文件的作用: 復習軟件質(zhì)量, 看開發(fā)和測試是否很好的配合完成了工作任務

在實際的測試中, 最常見的是用戶文件的測試, 例如: 手冊說明書等; 也會有一些公司對需求文檔進行測試, 來保證需求文檔的質(zhì)量.

文檔測試的關(guān)注點：

• 文檔的術(shù)語, 因為這是給業(yè)內(nèi)人士看的, 就可以不用把一些東西寫的太過于詳細, 直接一個專業(yè)術(shù)語就能帶過, 這樣能夠提升閱讀的效率.
• 文檔的完整性, 將一個軟件的所有的功能描述完整, 切勿遺漏重要功能！
• 文檔的一致性, 正確性
• 文檔的易用性

⑤兼容性測試

兼容性測試需求是指明確要測試的兼容環(huán)境, 考慮軟, 硬件的兼容, 就軟件兼容來說, 主要考慮以下幾個方面:

• 軟件系統(tǒng)自身的兼容性, 軟件 “向前向后” 的兼容性, 軟件開發(fā)的新功能, 不能影響舊功能的使用, 同時, 也不能影響后續(xù)功能的開發(fā).
• 軟件對于數(shù)據(jù)的兼容性 (特別是用戶數(shù)據(jù)), 在設計功能的時候, 要考慮到用戶已有的數(shù)據(jù)不能受到影響.
• 軟件對應用平臺的兼容性, 比如: 安裝的軟件環(huán)境 (Windows, iOS, Linux等操作系統(tǒng)), 安裝的硬件環(huán)境(電腦/手機配置是否能支持軟件的運行), APP環(huán)境(手機的應用商店等), 如果是網(wǎng)頁, 要考慮瀏覽器的版本…

軟件對于第三方軟件或者第三方軟件數(shù)據(jù)的兼容性, 一個軟件的使用不能影響其他軟件的正常使用, 就比如京東和微信, 京東付款, 就可以使用微信的, 它們之間肯定是做到軟件的兼容和數(shù)據(jù)的兼容; 京東在付款的時候, 會跳轉(zhuǎn)的微信的支付頁面, 這就是軟件兼容的體現(xiàn), 京東是可以使用微信來登錄的, 這就是數(shù)據(jù)的兼容.

兼容性測試是非常耗時的.

⑥易用性測試

許多產(chǎn)品都應用人體工程學的研究成果, 是產(chǎn)品在使用起來更加靈活和, 舒適; 軟件產(chǎn)品也始終關(guān)注用戶體驗, 讓用戶獲得舒適, 易用的體驗, 針對軟件這方面的測試稱之為易用性測試.
易用性在ISO25020標準中指容易發(fā)現(xiàn), 容易學習和容易使用, 易用性包含七個要素: 符合標準和規(guī)范, 直觀性, 一致性, 靈活性, 舒適性, 正確性和實用性.

主要是以下幾個方面:

a.標準性和規(guī)范性

對于現(xiàn)有的軟件運行平臺, 通常其UI標準已經(jīng)不知不覺地被確立了, 成為大家的共識; 多數(shù)用戶已經(jīng)習慣并且接受了這些標準和規(guī)范, 或者說已經(jīng)認同了這些信息所代表的的含義; 比如: 安裝軟件的界面的外觀, 在什么場合使用恰當?shù)膶υ捒颉?/p>

所以用戶界面上的各中信息應該符合規(guī)范和習慣, 否則用戶使用起來會不舒適, 并得不到用戶的認可; 測試人員需要把與標準規(guī)范, 習慣不一致的問題報告為缺陷

b.直觀性

用戶界面的直觀性, 要求軟件功能特性易懂, 清晰; 用戶界面布局合理, 對操作的響應在用戶的預期之中.
比如: 數(shù)據(jù)統(tǒng)計結(jié)果用報表的形式 (條形圖, 扇形圖等)展示清晰直觀; 現(xiàn)在主流的很多搜索引擎和日歷的設計也有直觀性的特點.

c.靈活性

軟件可以有不同的選項, 用來滿足不同使用習慣的用戶來完成相同的功能, 但是靈活性的設計要把握好度, 不然可能由于太多的用戶狀態(tài)和方式的選擇, 增加了軟件設計的復雜性, 和程序?qū)崿F(xiàn)的難度.
例如: 手機鍵盤有九宮格和全鍵盤, 還支持手寫, 滿足了不同用戶的需求

d.舒適性

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

總的來說, 軟件的設計要符合大眾審美, 要見名知意, 使用起來要靈活.

⑦安裝卸載的測試

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

• 軟件在不同的安裝和卸載方式的情況下。
• 應用是否可以在不同的環(huán)系統(tǒng)，版本下安裝(安裝兼容性)。
• 安裝或者卸載過程中是否可以手動暫停，或者取消，并且后續(xù)還可以正常安裝和卸載。
• 安裝所需的內(nèi)存空間不足的時候，系統(tǒng)是否有提示。
• 是否可以正常的卸載，以及應用軟件的各種卸載方式，并且如果在執(zhí)行取消卸載命令之后，軟件可以正常使用(數(shù)據(jù)恢復)。
• 卸載和安裝過程中出現(xiàn)環(huán)境問題，軟件是否可以正常并且合理的應對，比如死機、斷電、斷網(wǎng)等情況。

⑧安全測試

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

• 輸入域(輸入框中的內(nèi)容), 如輸入惡性或者帶有病毒的腳本或長字符串
• 代碼中的安全性問題, 如SQL/XSS注入
• 不安全的數(shù)據(jù)存儲或者傳遞
• 數(shù)據(jù)文件, 郵件文件, 系統(tǒng)配置文件等里面有危害系統(tǒng)的信息或者數(shù)據(jù)
• 有問題的訪問控制, 權(quán)限分配等
• 假冒ID: 身份欺騙
• 篡改, 對數(shù)據(jù)的惡意修改, 破壞數(shù)據(jù)的完整性，權(quán)限要合理分配, 防止用戶看到它不該看到的東西(超出自身權(quán)限)

安全性測試的方法有代碼評審, 滲透測試, 安全運維等, 常用的靜態(tài)安全測試工具有 Coverity, IBM, Appscan Source, HPFortify, 常用的動態(tài)安全測試有 OWASP的ZAP, HP WebInspect 等; 其中靜態(tài)安全測試是常用的安全性測試的方法.

⑨性能測試

我們在使用軟件的時候有時會碰到軟件網(wǎng)頁打開時越來越慢, 查詢數(shù)據(jù)時很長時間才顯示列表, 軟件運行越來越慢等問題, 這些問題都是系統(tǒng)的性能問題引起的.
要解決軟件產(chǎn)品的性能問題, 要對產(chǎn)品的性能需求進行分析, 然后基于系統(tǒng)的性能需求和系統(tǒng)架構(gòu), 完成性能測試的設計和執(zhí)行, 最后要進行持續(xù)的性能調(diào)優(yōu); 常見的性能問題如下:

• 資源泄露, 當我們的軟件運行越來越慢, 加載一個頁面需要半天的時候, 其原因就是資源泄露.
• 資源瓶頸, 在不同壓力下觀察系統(tǒng)是否仍能正常運行, 且各項性能指標滿足要求? 當無法滿足指標要求或出現(xiàn)異常時, 即判定為瓶頸出現(xiàn).
• 線程死鎖, 線程阻塞
• 查詢速度慢或效率低
• 受外部系統(tǒng)影響越來越大
• 響應速度越來越慢

衡量一個系統(tǒng)性能好壞的關(guān)鍵性指標有:

• 用戶響應時間
• 事務平均響應時間(TPS)
• 吞吐量
• 每秒點擊次數(shù)
• 內(nèi)存和CPU使用率等

⑩內(nèi)存泄漏測試

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

雖然內(nèi)存泄露的問題不會一下子要了 “我們的命”, 但是放任不管, 是絕對不行的.
這是一個很重要的bug! 需要我們?nèi)ブ匾?

造成內(nèi)存泄露的原因有很多, 最常見的有以下幾種

• 分配完內(nèi)存之后忘了回收
• 程序?qū)懛ㄓ袉栴}, 造成沒辦法回收(如死循環(huán)造成無法執(zhí)行到回收步驟)
• 某些API函數(shù)的使用不正確, 造成內(nèi)存泄露

內(nèi)存泄漏的檢測方法

• 人工靜態(tài)法: 代碼走讀, 人工查找未被回收的內(nèi)存
• 自動工具法: 借助相應測試內(nèi)存泄漏的工具, 如 Visual Leak Detector, 記錄每次內(nèi)存分配, 清楚告訴用戶內(nèi)存是如何泄漏的.

2.按是否查看代碼劃分

要注意下面三種形式的測試, 并不會區(qū)分哪個好哪個壞, 只要適合當前的業(yè)務, 能夠保證軟件的質(zhì)量, 就是好的測試方法.

①黑盒測試(Black-box Testing)

黑盒測試也稱為功能測試, 測試中把被測的軟件當成一個黑盒子, 不關(guān)心盒子內(nèi)部的代碼實現(xiàn), 只關(guān)心軟件的輸入數(shù)據(jù)和輸出數(shù)據(jù), 通過一些科學的方法, 常用到的測試方法有, 等價類, 邊界值, 因果圖, 場景法, 錯誤猜測法等, 向測試系統(tǒng)發(fā)起測試數(shù)據(jù), 關(guān)注測試執(zhí)行結(jié)果和預期結(jié)果是否一致.

黑盒測試的優(yōu)點：

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

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

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

②白盒測試(White-box Testing)

白盒測試又稱結(jié)構(gòu)測試, 透明盒測試, 邏輯驅(qū)動測試或基于代碼的測試; 白盒指的是打開的盒子, 去研究里面的源代碼和程序結(jié)果, 接口測試也是一種白盒測試.
白盒測試的測試目的是, 通過檢查軟件內(nèi)部的邏輯結(jié)構(gòu), 對軟件中的邏輯路徑進行覆蓋測試, 在程序不同地方設立檢查點, .檢查程序的狀態(tài), 以確定實際運行狀態(tài)與預期狀態(tài)是否一致.

白盒測試的優(yōu)點是關(guān)注代碼的內(nèi)部實現(xiàn), 代碼覆蓋率高; 缺點是只關(guān)注了模塊代碼的邏輯, 但是將模塊組合到一起就可能會出現(xiàn)問題.
白盒測試主要包含六種測試方法:

1. 語句覆蓋, 簡單來說, 就是把所有行代碼都執(zhí)行一遍, 看看有沒有問題, 語句覆蓋, 就是要覆蓋到所有行的代碼.但是, 程序是非常講究邏輯性的, 一個簡單的語句覆蓋測試是不行的, 還需要搭配其它的測試方法來使用.
2. 判定覆蓋, 就是每一個判斷語句, 為 true 和 false 都進行驗證.
3. 條件覆蓋, 就是比如 a > 1 && b == 0, 這種布爾類型的條件, 每個條件下都要進行驗證, a>1, a<=1, b=0, b ! = 0.
4. 判定條件覆蓋, 就是將條件的兩個判定結(jié)果 (true和false) 的所有判定組合進行覆蓋, 比如:
5. 條件組合覆蓋, 就是將多個可以連接起來的條件組合起來驗證, 要將所有的組合進行覆蓋, 即將 3 中的條件兩兩組合, 全部驗證.
6. 路徑覆蓋, 將代碼執(zhí)行的每條路徑都進行覆蓋測試.

其實判定條件覆蓋和條件組合覆蓋在某種程度上是相似的, 它們都關(guān)注于覆蓋條件語句的不同結(jié)果和組合情況, 但它們在覆蓋的粒度和策略上存在一些區(qū)別.

判定條件覆蓋更關(guān)注于每個判定條件的不同結(jié)果, 包括邏輯運算符的不同組合和布爾表達式的真假結(jié)果, 它確保每個判定條件的每個可能結(jié)果都至少執(zhí)行一次, 以驗證邏輯判斷的正確性.

條件組合覆蓋更加細致, 它要求覆蓋每個條件的所有可能組合, 它考慮了不同條件之間的交互作用, 確保測試用例能夠覆蓋所有可能的條件組合, 這有助于發(fā)現(xiàn)條件之間的依賴或沖突, 以及不同組合對程序行為的影響.

盡管兩者在目標上存在一些相似之處, 但條件組合覆蓋更加細致和全面, 它強調(diào)了條件之間的相互作用和組合, 以便更全面地檢查程序的邏輯和正確性, 判定條件覆蓋可以視為條件組合覆蓋的一種較為簡化的形式, 它關(guān)注于判定條件的不同結(jié)果而不涉及所有可能的組合.

冒泡排序測試用例

public static void bubbleSort(int[] array) {boolean flag = true;for (int i = 0; i < array.length-1; i++) {for (int j = 0; j < array.length-1-i; j++) {if(array[j] > array[j+1]) {swap(array, j, j+1);flag = false;}}if(flag) {break;}}
}private static void swap(int[] array, int i, int j) {int tmp = array[i];array[i] = array[j];array[j] = tmp;
}

我們要針對上面的冒泡排序代碼進行測試, 可以從以下方面考慮設計測試用例.

1）從參數(shù)上進行測試

使用等價類劃分法:

有效等價類: 參數(shù)是 int 數(shù)組

無效等價類: 參數(shù)是 float 數(shù)組, String 數(shù)組, double 數(shù)組, 字符串, 集合等

2）從代碼邏輯上進行測試

這里考慮代碼邏輯上的實現(xiàn), 就涉及到白盒測試了, 可以使用以下方法設計測試用例:

??? 語句覆蓋: 確保每個語句都至少執(zhí)行一次, 這里可以設計一個包含多個元素的亂序數(shù)組, 以覆蓋排序循環(huán)中的每個語句.

??? 測試用例1: 空數(shù)組作為輸入, 例如 []
??? 測試用例2: 包含一個元素的數(shù)組, 例如 [5]
??? 測試用例3: 包含多個元素的亂序數(shù)組, 例如 [3, 1, 4, 2, 5]

??? 判定覆蓋: 確保每個判定條件的每個可能結(jié)果都至少執(zhí)行一次, 可以設計一個包含兩個元素的數(shù)組, 一個元素比另一個元素大, 以確保兩個分支都被覆蓋到.
??? 條件覆蓋: 確保每個判定條件的每個子條件都至少執(zhí)行一次, 對于我們冒泡排序算法中的比較語句, 可以設計一個包含多個元素的數(shù)組, 并確保每個元素之間的比較都能夠被覆蓋到.
??? 判定條件覆蓋, 要使得每個條件的每個可能結(jié)果都能夠被覆蓋到.

??? 測試用例1: 輸入數(shù)組為空, 例如 []
??? 測試用例1: 輸入數(shù)組包含兩個相等的元素, 例如 [2, 2]
??? 測試用例2: 輸入數(shù)組包含兩個不相等的元素, 例如 [3, 1], [7, 8]

??? 條件組合覆蓋, 考慮每個條件的所有可能組合.

??? 測試用例2: 輸入數(shù)組包含兩個相等的元素且不需要交換例, 如 [5, 5]
??? 測試用例3: 輸入數(shù)組包含兩個不相等的元素且需要交換, 例如 [3, 1]
??? 測試用例4: 輸入數(shù)組包含兩個不相等的元素且不需要交換, 例如 [1, 3]

??? 路徑覆蓋: 確保覆蓋每個可能的路徑, 對于冒泡排序算法, 可能的路徑包括循環(huán)內(nèi)部的比較和交換操作, 以及循環(huán)的執(zhí)行次數(shù).

??? 路徑1: 輸入數(shù)組為空, 測試用例: 輸入數(shù)組為空, []
??? 路徑2: 輸入數(shù)組包含一個元素, 測試用例: 輸入的數(shù)組包含一個元素, [5]
??? 路徑3: 輸入數(shù)組包含多個元素且需要交換, 測試用例: 輸入數(shù)組包含多個元素, 其中存在需要交換的元素, [3, 1, 4, 2, 5]
??? 路徑4: 輸入數(shù)組包含多個元素且不需要交換, 測試用例: 輸入數(shù)組包含多個元素, 其中元素已經(jīng)按升序排列, [1, 2, 3, 4, 5]
??? 路徑5: 輸入數(shù)組包含多個元素且需要多次交換, 測試用例: 輸入數(shù)組包含多個元素, 需要多次交換才能完成排序, [5, 1, 4, 2, 3]

③從代碼性能上面進行測試

測試算法在大規(guī)模數(shù)據(jù)集上的性能, 生成一個包含大量元素的數(shù)組, 并記錄排序所需的時間; 考慮時間復雜度和空間復雜度等.

④錯誤處理

測試算法對于不符合要求的輸入數(shù)據(jù)的處理方式, 例如, 當傳入的參數(shù)為空或無效時, 算法應該如何處理并返回適當?shù)腻e誤或異常.

進行接口測試

這里只進行簡單的介紹, 我們要知道, 接口至少由請求地址(url), 請求方法(get/post), 請求參數(shù)(入?yún)⒑统鰠?組成, 可以使用一些工具針對接口進行測試, 比如可以使用postman, 它是谷歌的一款接口測試插件, 它使用簡單, 支持用例管理, 支持get, post, 文件上傳, 響應驗證, 變量管理, 環(huán)境參數(shù)管理等功能, 可以批量運行, 并支持用例導出, 導入.

③灰盒測試(Gray-Box Testing)

灰盒測試, 是介于白盒測試與黑盒測試之間的一種測試.
灰盒測試多用于集成測試階段, 不僅關(guān)注輸出, 輸入的正確性, 同時也關(guān)注程序內(nèi)部的情況.

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

測試金字塔

這個金字塔, 越靠近頂部, 就越接近用戶層(應用層); 越靠近底部, 就越接近代碼層.
另外, 越靠近低層, 測試效率越高; 定位問題就越容易, 而且, 測試獨立性越高(代碼的耦合性越低).
越靠近頂層, 就越接近用戶層, 而用戶操作的是一個個功能模塊的集成體, 操作起來, 功能的耦合性就很強, 所以, 出現(xiàn)問題, 想要定位問題也是較為不易.

1. 單元測試(Unit Tests)

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

??? 測試階段: 編碼后或者編碼前 (TDD - Test Driven Development - 測試驅(qū)動開發(fā))
??? 測試對象: 最小模塊 (一個接口方法, 單一功能的模塊)
??? 測試人員: 白盒測試工程師或開發(fā)工程師
??? 測試依據(jù): 代碼和注釋+詳細設計文檔
??? 測試方法: 白盒測試
??? 測試內(nèi)容: 模塊接口測試, 局部數(shù)據(jù)結(jié)構(gòu)測試 (局部變量測試), 路徑測試, 錯誤處理測試 (try catch), 邊界測試 (for, while, 測試是否存在越界問題)

要注意單元測試是白盒測試, 但是白盒測試不是單元測試.

2. 集成測試(Integration Testing)

集成測試也稱聯(lián)合測試(聯(lián)調(diào)), 組裝測試, 將程序模塊采用適當?shù)募刹呗越M裝起來, 對系統(tǒng)的接口及集成后的功能進行正確性檢測的測試工作.
集成主要目的是檢查軟件單位之間的接口是否正確.

??? 測試階段: 一般單元測試之后進行
??? 測試對象: 模塊間的接口
??? 測試人員: 白盒測試工程師或開發(fā)工程師
??? 測試依據(jù): 單元測試的模塊 + 概要設計文檔
??? 測試方法: 黑盒測試與白盒測試相結(jié)合, 即灰盒測試
??? 測試內(nèi)容: 模塊之間數(shù)據(jù)傳輸, 模塊之間功能沖突, 模塊組裝功能正確性(黑盒), 全局數(shù)據(jù)結(jié)構(gòu), 單模塊缺陷對系統(tǒng)的影響

3. 系統(tǒng)測試(System Testing)

將軟件系統(tǒng)看成是一個系統(tǒng)的測試, 包括對功能, 性能以及軟件所運行的軟硬件環(huán)境進行測試,.

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

其實就是在對軟件系統(tǒng)進行全面的功能和非功能測試.

??? 測試階段: 集成測試通過之后
??? 測試對象: 整個系統(tǒng) (軟, 硬件)
??? 測試人員: 黑盒測試工程師
??? 測試依據(jù): 需求規(guī)格說明文檔
??? 測試方法: 黑盒測試
??? 測試內(nèi)容: 功能, 界面, 可靠性, 容錯性, 易用性, 可移植性, 兼容性, 安全性, 性能, 安裝卸載等.

4. 回歸測試(regression testing)

回歸測試是指修改了舊代碼后, 重新進行測試以確認修改沒有引入新的錯誤或?qū)е缕渌a產(chǎn)生錯誤.

自動回歸測試將大幅降低系統(tǒng)測試, 維護升級等階段的成本; 在整個軟件的過程中占有很大的工作量比重, 軟件開發(fā)的各個階段都會運行多次回歸測試.

5. 冒煙測試(Smoke Testing)

在軟件開發(fā)完成后, 要對軟件的基礎功能和核心流程進行測試, 只有測試通過后, 才可以進入正式的測試環(huán)境.
反之, 測試不通過, 則測試人員是有權(quán)利打回項目, 讓開發(fā)人員進行修改, 直到冒煙測試成功.
也就是說, 冒煙測試就是先驗證軟件的核心功能是否能正常工作, 如果核心功能可以正常工作, 就可以測試軟件的其它功能了, 反之, 如果核心功不能正常工作, 也就沒法展開后續(xù)的測試了.

6. 驗收測試(Acceptance Testing)

驗收測試是部署軟件之前的最后一個測試操作, 它是技術(shù)測試室的最后一個階段, 也叫做交付測試, 驗收測試的目的是保證軟件的準備就緒, 按照項目合同, 任務書, 雙方約定的驗收依據(jù)文檔, 向軟件的購買者展示該軟件的原始的需求.

??? 測試階段: 系統(tǒng)測試之后
??? 測試對象: 整體軟件系統(tǒng)
??? 測試人員: 主要是最終用戶或者需求方.
??? 測試依據(jù): 用戶需求, 驗收標準
??? 測試方法: 黑盒測試
??? 測試內(nèi)容: 同系統(tǒng)測試(功能…各類文檔等)

4.按測試實施組織

1. α測試(Alpha Testing)

α測試是由一個用戶在開發(fā)環(huán)境下進行的測試, 也可以是公司內(nèi)部的用戶在模擬實際操作環(huán)境下進行的測試, α測試的目的是評價軟件產(chǎn)品的FLURPS(即功能, 局域化, 可使用性, 可靠性, 性能和支持).

2. β測試(Beta Testing)

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

3. α測試與β測試的區(qū)別

??? 測試的場所不同: Alpha測試是指把用戶請到開發(fā)方的場所來測試, 而beta測試是指在一個或多個用戶的場所進行的測試.
??? Alpha測試的環(huán)境是受開發(fā)方控制的, 用戶的數(shù)量相對比較少, 時間比較集中; beta測試的環(huán)境是不受開發(fā)方控制的, 用戶數(shù)量相對比較多, 時間不集中.
??? alpha測試先于beta測試執(zhí)行, 通用的軟件產(chǎn)品需要較大規(guī)模的beta測試, 測試周期比較長.

4. 第三方測試

介于開發(fā)方和用戶方之間的組織的測試, 該測試是有第三方測評機構(gòu)來進行的, 嚴格按照軟件行業(yè)的標準規(guī)范進行測試的, 就類似于國家指定的食品安全標準, 它都是有規(guī)定指標的, 測試行業(yè)也是存在這樣的指標的.

5. 按照代碼是否運行劃分

1. 靜態(tài)測試(Static testing)

所謂靜態(tài)測試 (static testing) 就是不實際運行被測軟件, 而只是靜態(tài)地檢查程序代碼, 界面或文檔中可能存在的錯誤的過程; 不以測試數(shù)據(jù)的執(zhí)行進行, 而是對測試對象的分析過程, 僅通過分析或檢查源程序的設計, 內(nèi)部結(jié)構(gòu), 邏輯, 代碼風格和規(guī)格等來檢查程序的正確性.

2. 動態(tài)測試(Dynamic testing)

動態(tài)測試 (dynamic testing), 指的是實際運行被測程序, 輸入相應的測試數(shù)據(jù), 檢查實際輸出結(jié)果和預期結(jié)果是否相符的過程, 所以判斷一個測試屬于動態(tài)測試還是靜態(tài)的, 唯一的標準就是看是否運行程序.
大多數(shù)軟件測試工作都屬于動態(tài)測試.

6. 按是否手工劃分

1. 手工測試(Manual testing)

手工測試就是由人去一個一個的輸入用例, 然后觀察結(jié)果, 和機器測試相對應, 屬于比較原始但是必須的一個步驟。
優(yōu)點: 自動化無法替代探索性測試, 發(fā)散思維結(jié)果的測試, 就是說手工測試很靈活.
缺點: 執(zhí)行效率慢, 量大易錯.

2. 自動化測試(Automation Testing)

就是按照人為預設條件下運行系統(tǒng)或應用程序, 評估運行結(jié)果, 預先條件應包括正常條件和異常條件; 簡單說, 自動化測試是把以人為驅(qū)動的測試行為轉(zhuǎn)化為機器執(zhí)行的一種過程.
自動化測試比如: 功能測試自動化, 性能測試自動化, 安全測試自動化.
自動化測試按照測試對象來分, 還可以分為接口測試, UI測試等.
接口測試的 ROI (產(chǎn)出投入比) 要比UI測試高.

自動化實施步驟：

??? 完成功能測試, 版本基本穩(wěn)定
??? 根據(jù)項目特性, 選擇適合項目的自動化工具, 并搭建環(huán)境
??? 提取手工測試的測試用例轉(zhuǎn)化為自動化測試的用例
??? 通過工具, 代碼實現(xiàn)自動化構(gòu)造輸入, 自動檢測輸出結(jié)果是否符合預期
??? 生成自動測試報告
??? 持續(xù)改進, 腳本優(yōu)化

六. 按測試地域劃分

軟件國際化是在軟件設計和文檔開發(fā)過程中, 使得功能和代碼設計能處理多種語言和文化習俗, 使創(chuàng)建不同語言版本時, 不需要重新設計源程序代碼的軟件工程方法, 就是說軟件具有很強的通用性.
國際化測試和本地化測試

國際化測試

軟件的國際化和軟件的本地化是開發(fā)面向全球不同地區(qū)用戶使用的軟件系統(tǒng)的兩個過程, 而本地化測試和國際化測試則是針對這類軟件產(chǎn)品進行的測試, 由于軟件的全球化普及, 還有軟件外包行業(yè)的興起, 軟件的本地化和國際化測試儼然成為了一個獨特的測試專門領域.
本地化和國際化測試與其它類型的測試存在很多不同之處, 下面是本地化和國際化測試的一些要點:

??? 本地化后的軟件在外觀上與原來版本是否存在很大的差異, 外觀是否整齊, 不走樣
??? 是否對所有界面元素都進行了本地化處理, 包括對話框, 菜單, 工具欄, 狀態(tài)欄, 提示信息(包括聲音的提示), 日志等
??? 在不同的屏幕分辨率下界面是否正常顯示
??? 是否存在不同的字體大小, 字體樣式設置是否恰當
??? 日期, 數(shù)字格式, 貨幣等是否能適應不同國家的文化習俗; 例如, 中文是年月日, 而英文是月日年.
??? 排序的方式是否考慮了不同語言的特點, 例如, 中文按照第一個字的漢語拼音順序排序, 而英文按照首字母排序
??? 在不同的國家采用不同的度量單位, 軟件是否能自適應和轉(zhuǎn)換
??? 軟件是否能在不同類型的硬件上正常運行, 特別是在當?shù)厥袌錾箱N售的流行硬件上
??? 軟件是否能在Windows或者其它操作系統(tǒng)的當?shù)匕姹旧险＿\行
??? 聯(lián)機幫助和文檔是否已經(jīng)翻譯, 翻譯后的鏈接是否正常; 正文翻譯是否正確, 恰當, 是否有語法錯誤

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

本地化測試

之前所有介紹的都是基于本地化進行測試的.

?