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

①界面測(cè)試

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

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

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

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

②可靠性測(cè)試

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

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

百分比越高，可靠性越強(qiáng)，反之就越低。

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

可用性指標(biāo)一般要求達(dá)到4個(gè)或5個(gè)“9”，即99.99%或者99.999%

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

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

那么，可靠性怎么去測(cè)試呢?

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

③容錯(cuò)性測(cè)試

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

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

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

常見的容錯(cuò)性說明

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

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

【2】校驗(yàn)容錯(cuò)性

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

【3】界面容錯(cuò)性

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

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

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

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

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

④文檔測(cè)試

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

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

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

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

文檔測(cè)試的關(guān)注點(diǎn)：

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

⑤兼容性測(cè)試

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

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

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

兼容性測(cè)試是非常耗時(shí)的.

⑥易用性測(cè)試

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

主要是以下幾個(gè)方面:

a.標(biāo)準(zhǔn)性和規(guī)范性

對(duì)于現(xiàn)有的軟件運(yùn)行平臺(tái), 通常其UI標(biāo)準(zhǔn)已經(jīng)不知不覺地被確立了, 成為大家的共識(shí); 多數(shù)用戶已經(jīng)習(xí)慣并且接受了這些標(biāo)準(zhǔn)和規(guī)范, 或者說已經(jīng)認(rèn)同了這些信息所代表的的含義; 比如: 安裝軟件的界面的外觀, 在什么場(chǎng)合使用恰當(dāng)?shù)膶?duì)話框…

所以用戶界面上的各中信息應(yīng)該符合規(guī)范和習(xí)慣, 否則用戶使用起來會(huì)不舒適, 并得不到用戶的認(rèn)可; 測(cè)試人員需要把與標(biāo)準(zhǔn)規(guī)范, 習(xí)慣不一致的問題報(bào)告為缺陷

b.直觀性

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

c.靈活性

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

d.舒適性

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

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

⑦安裝卸載的測(cè)試

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

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

⑧安全測(cè)試

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

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

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

⑨性能測(cè)試

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

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

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

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

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

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

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

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

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

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

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

2.按是否查看代碼劃分

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

①黑盒測(cè)試(Black-box Testing)

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

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

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

黑盒測(cè)試的缺點(diǎn)是不可能覆蓋所有代碼.

黑盒測(cè)試用到的測(cè)試方法有，等價(jià)類，邊界值，因果圖，場(chǎng)景法，錯(cuò)誤猜測(cè)法等。

②白盒測(cè)試(White-box Testing)

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

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

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

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

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

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

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

冒泡排序測(cè)試用例

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;
}

我們要針對(duì)上面的冒泡排序代碼進(jìn)行測(cè)試, 可以從以下方面考慮設(shè)計(jì)測(cè)試用例.

1）從參數(shù)上進(jìn)行測(cè)試

使用等價(jià)類劃分法:

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

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

2）從代碼邏輯上進(jìn)行測(cè)試

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

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

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

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

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

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

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

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

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

③從代碼性能上面進(jìn)行測(cè)試

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

④錯(cuò)誤處理

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

進(jìn)行接口測(cè)試

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

③灰盒測(cè)試(Gray-Box Testing)

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

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

測(cè)試金字塔

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

1. 單元測(cè)試(Unit Tests)

單元測(cè)試是對(duì)軟件組成單元進(jìn)行測(cè)試, 其目的是檢驗(yàn)軟件基本組成單位的正確性, 測(cè)試的對(duì)象是軟件設(shè)計(jì)的最小單位: 模塊, 又稱為模塊測(cè)試.

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

要注意單元測(cè)試是白盒測(cè)試, 但是白盒測(cè)試不是單元測(cè)試.

2. 集成測(cè)試(Integration Testing)

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

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

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

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

新買手機(jī)都會(huì)有一個(gè)合格標(biāo)簽, 在出廠前手機(jī)廠會(huì)所某型號(hào)的手機(jī)上的所有功能全部測(cè)試一遍, 包括手機(jī)硬件本身, 手機(jī)上自帶的APP.

其實(shí)就是在對(duì)軟件系統(tǒng)進(jìn)行全面的功能和非功能測(cè)試.

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

4. 回歸測(cè)試(regression testing)

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

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

5. 冒煙測(cè)試(Smoke Testing)

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

6. 驗(yàn)收測(cè)試(Acceptance Testing)

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

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

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

1. α測(cè)試(Alpha Testing)

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

2. β測(cè)試(Beta Testing)

Beta測(cè)試是一種驗(yàn)收測(cè)試, Beta測(cè)試由軟件的最終用戶們?cè)谝粋€(gè)或多個(gè)場(chǎng)所進(jìn)行.

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

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

4. 第三方測(cè)試

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

5. 按照代碼是否運(yùn)行劃分

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

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

2. 動(dòng)態(tài)測(cè)試(Dynamic testing)

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

6. 按是否手工劃分

1. 手工測(cè)試(Manual testing)

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

2. 自動(dòng)化測(cè)試(Automation Testing)

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

自動(dòng)化實(shí)施步驟：

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

六. 按測(cè)試地域劃分

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

國(guó)際化測(cè)試

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

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

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

本地化測(cè)試

之前所有介紹的都是基于本地化進(jìn)行測(cè)試的.

?