軟件測試基本概念

1、 軟件測試基本概念Document No.:Effective Date:Controlled No.:Priority: NormalVersion: V1.0Edit Status:All Pages14Text Pages12AddendaAuthorized by: Sam/FredAudited by:Confirmed by:Document Modification ManagementNo. of Modified RecordsModified StatusModified Pages or RecordsModified byAudited byConfirmed byMo

2、dified Date目錄一、軟件測試基本概念3二、測試階段42.1、單元測試（Unit Testing）42.2、集成測試（Integration Testing）42.3、確認(rèn)測試（Validation Testing)42.4、系統(tǒng)測試（System Testing）42.5、用戶驗(yàn)收測試（User Acceptance testing）4三、測試分類5四、常用的測試64.1、常用測試概述64.2、常用測試詳述7五、測試術(shù)語大全10六、缺陷管理136.1、Bug的嚴(yán)重級別 (Severity)136.2、Bug的優(yōu)先級 (Priority)136.3、Bug的類型 (Type)136.4

3、、Bug狀態(tài) (Status)136.5、提交Bug的注意事項(xiàng)146.6、常見的Bug管理工具14七、常見易混概念匯總15一、軟件測試基本概念1、軟件=程序+文檔，軟件測試=程序測試+文檔測試。v “程序”是指能夠?qū)崿F(xiàn)某種功能的指令的集合，v “文檔”是指軟件在開發(fā)、使用和維護(hù)過程中產(chǎn)生的圖文集合。 User Requirement：簡稱UR，用戶需求。 Design Spec：簡稱DS，設(shè)計(jì)說明書。 Function Requirement Spec：簡稱FRS，功能需求規(guī)格說明書。 Function Design Spec：功能設(shè)計(jì)說明書。 Test Plan：測試計(jì)劃，根據(jù)整個(gè)項(xiàng)目的進(jìn)度

4、和開發(fā)的進(jìn)度來編寫。 Test Spec：還有Test Case（測試用例），根據(jù)UR和FRS來編寫。 Log Report：缺陷報(bào)告，記錄該系統(tǒng)存在的Bug。 Test Report：測試報(bào)告，測試完后需對所做的測試工作進(jìn)行總結(jié)和對系統(tǒng)的評價(jià)、建議。 User Manual：用戶手冊。 User Guide：用戶指導(dǎo)。2、軟件的分類：v 按功能：系統(tǒng)軟件、應(yīng)用軟件；v 按技術(shù)架構(gòu)：單機(jī)版軟件、C/S結(jié)構(gòu)軟件(C:客戶端,S:服務(wù)器端)、B/S結(jié)構(gòu)軟件(B:瀏覽器）v 按照用戶劃：產(chǎn)品軟件、項(xiàng)目軟件；v 按開發(fā)規(guī)模：小型、中型、大型。3、軟件環(huán)境的分類：軟件開發(fā)環(huán)境；軟件測試環(huán)境；軟件生產(chǎn)運(yùn)行

5、環(huán)境。測試環(huán)境=軟件+網(wǎng)絡(luò)+硬件。搭建環(huán)境：真實(shí)、干凈、無毒、獨(dú)立。4、Bug的定義：v 從內(nèi)部看：軟件的缺陷是軟件產(chǎn)品開發(fā)或維護(hù)過程中存在的錯(cuò)誤、毛病等各種問題。v 從外部看：軟件的缺陷是系統(tǒng)所需要實(shí)現(xiàn)的某種功能的失效或違背。常見的BUG分三種類型：完全沒有實(shí)現(xiàn)的功能；基本實(shí)現(xiàn)了用戶需求的功能；實(shí)現(xiàn)了用戶不需要的功能。5、測試用例：測試用例=輸入+輸出+測試環(huán)境。指在測試執(zhí)行之前設(shè)計(jì)的一套詳細(xì)的測試方案，包括測試環(huán)境、測試步驟、測試數(shù)據(jù)和與其結(jié)果！測試用例有兩個(gè)模板，word和excel，前者適合性能測試，后者適合功能測試。6、優(yōu)秀的軟件測試工程師應(yīng)該具備的基本職業(yè)素質(zhì)：三心二意一能力：v

6、三心：細(xì)心、耐心、信心；v 二意：服務(wù)意識、團(tuán)隊(duì)意識；v 一能力：溝通能力。二、測試階段2.1、單元測試（Unit Testing）是在軟件開發(fā)過程中要進(jìn)行的最低級別的測試活動(dòng)，在單元測試活動(dòng)中，軟件的獨(dú)立單元將在與程序的其他部分相隔離的情況下進(jìn)行測試。是開發(fā)者編寫的一小段代碼，用于檢驗(yàn)被測代碼的一個(gè)很小的、很明確的功能是否正確。通常而言，一個(gè)單元測試是用于判斷某個(gè)特定條件（或者場景）下某個(gè)特定函數(shù)的行為。2.2、集成測試（Integration Testing）也叫組裝測試或聯(lián)合測試。在單元測試的基礎(chǔ)上，將所有模塊按照設(shè)計(jì)要求，如根據(jù)結(jié)構(gòu)圖組裝成為子系統(tǒng)或系統(tǒng)，進(jìn)行集成測試。 它的最簡單的形

7、式是：兩個(gè)已經(jīng)測試過的單元組合成一個(gè)組件，并且測試它們之間的接口。從這一層意義上講，組件是指多個(gè)單元的集成聚合。測試范圍：單元間的接口以及集成后的功能。2.3、確認(rèn)測試（Validation Testing)又稱有效性測試。有效性測試是在模擬的環(huán)境下，運(yùn)用黑盒測試的方法，驗(yàn)證被測軟件是否滿足需求規(guī)格說明書列出的需求。有兩項(xiàng)工作：1. 進(jìn)行確認(rèn)測試；2. 軟件配置復(fù)審。2.4、系統(tǒng)測試（System Testing）是將通過確認(rèn)測試的軟件，作為整個(gè)基于計(jì)算機(jī)系統(tǒng)的一個(gè)元素，與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實(shí)際運(yùn)行環(huán)境下，對計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的組裝測試和確

8、認(rèn)測試。2.5、用戶驗(yàn)收測試（User Acceptance testing）系統(tǒng)開發(fā)生命周期方法論的一個(gè)階段，這時(shí)相關(guān)的用戶或獨(dú)立測試人員根據(jù)測試計(jì)劃和結(jié)果對系統(tǒng)進(jìn)行測試和接收。 測試 (alpha testing) 在開發(fā)一個(gè)應(yīng)用軟件即將完成時(shí)所進(jìn)行的測試；是指軟件開發(fā)公司組織內(nèi)部人員模擬各類用戶行對即將面市軟件產(chǎn)品（稱為版本）進(jìn)行測試，試圖發(fā)現(xiàn)錯(cuò)誤并修正。 測試 (beta testing) 當(dāng)開發(fā)和測試已基本完成，需要在正式發(fā)行之前最后尋找毛病而進(jìn)行的測試。開發(fā)者通常不在測試現(xiàn)場，由最終用戶或其他人進(jìn)行這種測試，而不是由程序員和測試人員來進(jìn)行。 回歸測試:根據(jù)修復(fù)好了的缺陷再重新進(jìn)行的

9、測試。目的在于驗(yàn)證以前出現(xiàn)過但已經(jīng)修復(fù)好的缺陷不再重新出現(xiàn)。一般指對某已知修正的缺陷再次圍繞它原來出現(xiàn)時(shí)的步驟重新測試。通常確定所需的再測試的范圍時(shí)是比較困難的，特別當(dāng)臨近產(chǎn)品發(fā)布日期時(shí)。因?yàn)闉榱诵拚橙毕輹r(shí)必需更改源代碼，因而就有可能影響這部分源代碼所控制的功能。所以在驗(yàn)證修好的缺陷時(shí)不僅要服從缺陷原來出現(xiàn)時(shí)的步驟重新測試，而且還要測試有可能受影響的所有功能。因此應(yīng)當(dāng)鼓勵(lì)對所有回歸測試用例進(jìn)行自動(dòng)化。三、測試分類軟件測試按照不同的劃分依據(jù)可以有多種分類：按測試階段按測試目的按測試對象按測試過程按是否需要執(zhí)行被測軟件其他測試技術(shù)單元測試Unit test組件測試Component test集成

10、測試Integration test系統(tǒng)測試System test驗(yàn)收測試Acceptance test 安裝測試Installation testA、 正確性測試Correctness test白盒測試White-box黑盒測試Black-boxB、性能測試Performance testC、可靠性測試Reliability test強(qiáng)壯性測試Robustness, Strong test異常處理測試Exception handing test負(fù)載測試Stress test,Load testD、安全性測試Security test單元測試Unit test組件測試Component tes

11、t模塊測試Module test程序測試Program test系統(tǒng)測試System test文檔測試Document test需求階段的測試Requirements phase test設(shè)計(jì)階段的測試Design phase test程序階段的測試Program phase test測試結(jié)果的評估Evaluating test result安裝測試Installation phase test驗(yàn)收測試Acceptance test測試變化: 維護(hù)Testing changes:Maintenance靜態(tài)測試Static test動(dòng)態(tài)測試Dynamic test冒煙測試Smoke test回歸

12、測試Regression test恢復(fù)測試Recovery test隨機(jī)測試Random test兼容性測試Compatibility test 手工測試Manual Test自動(dòng)化測試Automated Test注：同一個(gè)測試，既有可能屬于黑盒測試，也有可能屬于動(dòng)態(tài)測試；既有可能屬于靜態(tài)測試，也有可能屬于白盒測試。他們之間也有可能交叉。四、常用的測試4.1、常用測試概述黑盒測試：又稱功能測試，完全基于軟件的功能和需求的測試。 白盒測試：又稱結(jié)構(gòu)測試，已知程序的內(nèi)部邏輯，覆蓋代碼的測試?；液袦y試: 介于白盒與黑盒測試之間的測試。既關(guān)注輸出對于輸入的正確性，同時(shí)也關(guān)注內(nèi)部表現(xiàn)。單元測試：最小函數(shù)

13、或模塊的測試。增量集成測試：增加新的功能后進(jìn)行新的測試。 集成測試：對由各部分組合起來的程序進(jìn)行測試。系統(tǒng)測試：黑盒類測試，基于全部需求說明，覆蓋系統(tǒng)所有組合部分。 驗(yàn)收測試：獲知消費(fèi)者對該軟件是否滿意。 測試：在軟件開發(fā)將結(jié)束時(shí)進(jìn)行該測試。測試：當(dāng)開發(fā)和測試工作實(shí)質(zhì)上完成時(shí)進(jìn)行該類測試。功能測試：黑盒類測試，使軟件適合應(yīng)用程序的功能需求。 負(fù)載測試：測試應(yīng)用程序在重負(fù)載之下的承受能力。壓力測試：是在一種需要反常數(shù)量、頻率或資源的方式下運(yùn)行系統(tǒng)。 性能測試：關(guān)注性能參數(shù)指標(biāo)，用來測試軟件在系統(tǒng)中的運(yùn)行性能。健全性測試：常作為初始測試，確定一個(gè)新的軟件版本是否表現(xiàn)正常，以應(yīng)付更強(qiáng)的測試。冒煙測試

14、：冒煙測試的對象是每一個(gè)新編譯的需要正式測試的軟件版本，目的是確認(rèn)軟件基本功能正常，可以進(jìn)行后續(xù)的正式測試工作。冒煙測試的執(zhí)行者是版本編譯人員。回歸測試：修復(fù)或調(diào)整好的軟件的環(huán)境之后重新測試，自動(dòng)的測試工具適用于這種類型。 認(rèn)同測試：基于最終用戶說明書,或者基于最終用戶/消費(fèi)者使用一段時(shí)間的最后測試?？捎眯詼y試：測試該軟件的用戶界面是否友好。兼容性測試：測試軟件在特別的硬件/軟件/操作系統(tǒng)/網(wǎng)絡(luò)/等等環(huán)境中是否能很好地執(zhí)行。安全性測試：測試系統(tǒng)自身保護(hù)并且防止非法的內(nèi)部或外部的訪問,故意的損害等等的能力。 比較測試：在同類產(chǎn)品中比較軟件的優(yōu)缺點(diǎn)。安裝/卸載測試：測試軟件的安裝、卸載或升級過程。

15、 恢復(fù)能力測試：測試系統(tǒng)在崩潰,硬件失效,或者遇到其他災(zāi)難性的問題時(shí)是否能很好地恢復(fù)。 健壯性測試（容錯(cuò)能力/恢復(fù)能力測試）：側(cè)重于程序容錯(cuò)能力的測試。本測試在單元測試階段和系統(tǒng)測試階段都要進(jìn)行。如數(shù)據(jù)邊界測試、非法數(shù)據(jù)測試、異常中斷測試等等，主要是驗(yàn)證程序?qū)Ω鞣N異常情況是否進(jìn)行正確處理。為了執(zhí)行方便，建議健壯性的大部分測試用例盡量編寫在功能測試用例中。文檔測試：主要測試開發(fā)過程中針對用戶的文檔，以需求、用戶手冊、安裝手冊等為主，檢驗(yàn)文檔是否和實(shí)際應(yīng)用存在差別。文檔測試不需要編寫測試用例。靜態(tài)測試：是指不實(shí)際運(yùn)行被測軟件，而只是靜態(tài)的代碼檢查，文檔檢查和評審等。動(dòng)態(tài)測試：是指實(shí)際運(yùn)行被測程序，

16、輸入相應(yīng)的測試數(shù)據(jù)，檢查實(shí)際輸出結(jié)果和預(yù)期結(jié)果是否相符的過程，所以我們判斷一個(gè)測試屬于動(dòng)態(tài)測試還是靜態(tài)測試，唯一的標(biāo)準(zhǔn)就是看是否運(yùn)行程序。4.2、常用測試詳述黑盒測試（Black box testing）：指測試人員不關(guān)心程序具體如何實(shí)現(xiàn)的一種測試方法。根據(jù)軟件的規(guī)格對軟件進(jìn)行各種輸入和觀察軟件的各種輸出結(jié)果來發(fā)現(xiàn)軟件的缺陷的測試，這類測試不考慮軟件內(nèi)部的運(yùn)作原理，因此軟件對用戶來說就像一個(gè)黑盒子。白盒測試（White box testing）：根據(jù)軟件內(nèi)部的工作原理分析來進(jìn)行測試,基于代碼的測試，測試人員通過閱讀程序代碼或者通過使用開發(fā)工具中的單步調(diào)試來判斷軟件的質(zhì)量，一般白盒測試由項(xiàng)目經(jīng)理

17、在程序員開發(fā)中來實(shí)現(xiàn)。功能測試（Functional testing）：也稱為behavioral testing（行為測試），根據(jù)產(chǎn)品特征、操作描述和用戶方案，測試一個(gè)產(chǎn)品的特性和可操作行為以確定它們滿足設(shè)計(jì)需求。本地化軟件的功能測試，用于驗(yàn)證應(yīng)用程序或網(wǎng)站對目標(biāo)用戶能正確工作。使用適當(dāng)?shù)钠脚_、瀏覽器和測試腳本，以保證目標(biāo)用戶的體驗(yàn)將足夠好，就像應(yīng)用程序是專門為該市場開發(fā)的一樣。性能測試（Performance testing）：通常驗(yàn)證軟件的性能在正常環(huán)境和系統(tǒng)條件下重復(fù)使用是否還能滿足性能指標(biāo)?；蛘邎?zhí)行同樣任務(wù)時(shí)新版本不比舊版本慢。一般還檢查系統(tǒng)記憶容量在運(yùn)行程序時(shí)會(huì)不會(huì)流失(memor

18、y leak)。比如，驗(yàn)證程序保存一個(gè)巨大的文件新版本不比舊版本慢。廣義的性能測試包括負(fù)載測試、強(qiáng)度測試、數(shù)據(jù)庫容量測試、基準(zhǔn)測試等類型。 負(fù)荷/負(fù)載試驗(yàn) (Load testing)：在大負(fù)荷條件下對應(yīng)用軟件進(jìn)行測試。通過測試系統(tǒng)在資源超負(fù)荷情況下的表現(xiàn)，以發(fā)現(xiàn)設(shè)計(jì)上的錯(cuò)誤或驗(yàn)證系統(tǒng)的負(fù)載能力。在這種測試中，將使測試對象承擔(dān)不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行為，以及持續(xù)正常運(yùn)行的能力。負(fù)載測試的目標(biāo)是確定并確保系統(tǒng)在超出最大預(yù)期工作量的情況下仍能正常運(yùn)行。此外，負(fù)載測試還要評估性能特征，例如，響應(yīng)時(shí)間、事務(wù)處理速率和其他與時(shí)間相關(guān)的方面。例如測試一個(gè)網(wǎng)站在不同負(fù)荷情

19、況下的狀況，以確定在什么情況下系統(tǒng)響應(yīng)速度下降或是出現(xiàn)故障。 壓力測試 (Stress testing)：經(jīng)?？梢耘c“負(fù)荷測試”或“性能測試”相互代替。這種測試是用來檢查系統(tǒng)在下列條件下的情況：在非正常的巨大負(fù)荷下、某些動(dòng)作和輸入大量重復(fù)、輸入大數(shù)、對數(shù)據(jù)庫進(jìn)行非常復(fù)雜的查詢，等等。強(qiáng)力測試：它通常驗(yàn)證軟件的性能在各種極端的環(huán)境和系統(tǒng)條件下是否還能正常工作。或者說是驗(yàn)證軟件的性能在各種極端環(huán)境和系統(tǒng)條件下的承受能力。比如，在最低的硬盤驅(qū)動(dòng)器空間或系統(tǒng)記憶容量條件下，驗(yàn)證程序重復(fù)執(zhí)行打開和保存一個(gè)巨大的文件1000次后也不會(huì)崩潰或死機(jī)。 恢復(fù)測試 (Recovery testing) ：在系統(tǒng)崩

20、潰、硬件故障、或者其他災(zāi)難發(fā)生之后，重新恢復(fù)系統(tǒng)的情況。 安全測試 (Security testing) ：測試系統(tǒng)在應(yīng)付非授權(quán)的內(nèi)部/外部訪問、故意的損壞時(shí)的防護(hù)情況。這需要精密復(fù)雜的測試技術(shù)。可移植性測試(Portability testing）:測試軟件是否可以被成功移植到指定的硬件或軟件平臺上。用戶界面測試（User interface testing）：測試分析軟件用戶界面的風(fēng)格設(shè)計(jì)是否合乎用戶期望或要求，文字是否正確，頁面是否美觀，文字，圖片組合是否完美，操作是否友好等等。它常常包括菜單，對話框及對話框上所有按鈕，文字，出錯(cuò)提示，幫助信息 (Menu 和Help content)等

21、方面的測試。比如，測試Microsoft Excel中插入符號功能所用的對話框的大小，所有按鈕是否對齊，字符串字體大小，出錯(cuò)信息內(nèi)容和字體大小，工具欄位置/圖標(biāo)等等。UI 測試的目標(biāo)是確保用戶界面會(huì)通過測試對象的功能來為用戶提供相應(yīng)的訪問或?yàn)g覽功能。確保用戶界面符合公司或行業(yè)的標(biāo)準(zhǔn)。包括用戶友好性、人性化、易操作性測試。 可用性測試 (Usability testing) ：是專為“對用戶友好”的特性進(jìn)行測試。這是一種主觀的感覺，取決于最終用戶或顧客。可以進(jìn)行用戶會(huì)見、檢查、對用戶會(huì)議錄像、或者使用其他技術(shù)。程序員和測試人員通常不參加可用性測試。邊界條件測試：是環(huán)繞邊界值的測試。通常意味著測試

22、軟件各功能是否能正確處理最大值，最小值或者所設(shè)計(jì)軟件能夠處理的最長的字符串等等。集成與兼容性測試（Compatibility Testing）：驗(yàn)證該功能能夠如預(yù)期的那樣與其他程序或者構(gòu)件協(xié)調(diào)工作。兼容性經(jīng)常意味著新舊版本之間的協(xié)調(diào)，也包括測試的產(chǎn)品與其它產(chǎn)品的兼容使用。比如用同樣產(chǎn)品的新版本時(shí)不影響與用舊版本用戶之間保存文件，格式，和其他數(shù)據(jù)等操作。總的來說就是測試軟件是否和系統(tǒng)的其它與之交互的元素之間兼容，如：瀏覽器、操作系統(tǒng)、硬件等。驗(yàn)證測試對象在不同的軟件和硬件配置中的運(yùn)行情況。裝配/安裝測試（Installing testing）：確保該軟件在正常情況和異常情況的不同條件下，例如，進(jìn)

23、行首次安裝、升級、完整的或自定義的安裝都能進(jìn)行安裝。異常情況包括磁盤空間不足、缺少目錄創(chuàng)建權(quán)限等。核實(shí)軟件在安裝后可立即正常運(yùn)行。安裝測試包括測試安裝代碼以及安裝手冊。安裝手冊提供如何進(jìn)行安裝，安裝代碼提供安裝一些程序能夠運(yùn)行的基礎(chǔ)數(shù)據(jù)。驗(yàn)證軟件程序在不同廠家的硬件上，所支持的不同語言的新舊版本平臺上，和不同方式安裝的軟件都能夠如預(yù)期的那樣正確運(yùn)行。比如，把英文版的 Microsoft Office 2003安裝在韓文版的Windows Me上，再驗(yàn)證所有功能都正常運(yùn)行。國際化支持測試（International testing）：國際化測試的目的是測試軟件的國際化支持能力，發(fā)現(xiàn)軟件的國際化的

24、潛在問題，保證軟件在世界不同區(qū)域中都能正常運(yùn)行。國際化測試使用每種可能的國際輸入類型，針對任何區(qū)域性或區(qū)域設(shè)置檢查產(chǎn)品的功能是否正常，軟件國際化測試的重點(diǎn)在于執(zhí)行國際字符串的輸入/輸出功能。國際化測試數(shù)據(jù)必須包含東亞語言、德語、復(fù)雜腳本字符和英語（可選）的混合字符。驗(yàn)證軟件程序在不同國家或區(qū)域的平臺上也能夠如預(yù)期的那樣運(yùn)行，而且還可以按照原設(shè)計(jì)尊重和支持使用當(dāng)?shù)爻Ｓ玫娜掌?，字體，文字表示，特殊格式等等。比如，用英文版的 Windows XP 和 Microsoft Word 能否展示阿拉伯字符串?用阿拉伯版的 Windows XP 和 阿拉伯版的Microsoft Word 能否展示阿拉伯字符

25、串?又比如，日文版的Microsoft Excel對話框是否顯示正確翻譯的日語?一旦來說執(zhí)行國際化支持測試的測試人員往往需要基本上了解這些國家或地區(qū)的語言要求和期望行為是什么。本地化能力測試(Localizability testing)：本地化能力是指不需要重新設(shè)計(jì)或修改代碼，將程序的用戶界面翻譯成任何目標(biāo)語言的能力。為了降低本地化能力測試的成本，提高測試效率，本地化能力測試是通常在軟件的偽本地化版本上進(jìn)行。本地化能力測試中發(fā)現(xiàn)的典型錯(cuò)誤包括：字符的硬編碼（即軟件中需要本地化的字符寫在了代碼內(nèi)部），對需要本地化的字符長度設(shè)置了國定值，在軟件運(yùn)行時(shí)以控件位置定位，圖標(biāo)和位圖中包含了需要本地化的

26、文本，軟件的用戶界面與文檔術(shù)語不一致等。要驗(yàn)證所有已計(jì)劃要發(fā)布的不同語言版本軟件如預(yù)期的那樣被正確地翻譯成當(dāng)?shù)卣Z言。這類測試一般包括驗(yàn)證菜單，對話框，出錯(cuò)信息，幫助內(nèi)容等所有用戶界面上的文字都能夠顯示正確翻譯好的當(dāng)?shù)匚淖帧１镜鼗瘻y試（Localization testing）：本地化測試的對象是軟件的本地化版本。本地化測試的目的是測試特定目標(biāo)區(qū)域設(shè)置的軟件本地化質(zhì)量。本地化測試的環(huán)境是在本地化的操作系統(tǒng)上安裝本地化的軟件。從測試方法上可以分為基本功能測試，安裝/卸載測試，當(dāng)?shù)貐^(qū)域的軟硬件兼容性測試。測試的內(nèi)容主要包括軟件本地化后的界面布局和軟件翻譯的語言質(zhì)量，包含軟件、文檔和聯(lián)機(jī)幫助等部分。

27、靜態(tài)測試（Static testing）：是指不實(shí)際運(yùn)行被測軟件，而只是靜態(tài)的檢查程序代碼、界面或文檔中可能存在的錯(cuò)誤的過程。 動(dòng)態(tài)測試（Dynamic testing）：是指實(shí)際運(yùn)行被測程序，輸入相應(yīng)的測試數(shù)據(jù)，檢查實(shí)際輸出結(jié)果和預(yù)期結(jié)果是否相符的過程，所以我們判斷一個(gè)測試屬于動(dòng)態(tài)測試還是靜態(tài)測試，唯一的標(biāo)準(zhǔn)就是看是否運(yùn)行程序。冒煙測試（Smoke testing）：是指在對一個(gè)新版本進(jìn)行大規(guī)模的測試之前，先驗(yàn)證一下軟件的基本功能是否可以實(shí)現(xiàn)，是否具備可測性，目的是確認(rèn)軟件基本功能正常，可以進(jìn)行后續(xù)的正式測試工作。健全測試（Sanity testing）：軟件主要功能成分的簡單測試以保證它是

28、否能進(jìn)行基本的測試?？山邮苄詼y試：是在把測試的版本交付測試部門大范圍測試以前進(jìn)行的對最基本功能的簡單測試。因?yàn)樵诎褱y試的版本交付測試部門大范圍測試以前應(yīng)該先驗(yàn)證該版本對于所測試的功能基本上比較穩(wěn)定。必須滿足一些最低要求。比如不會(huì)很容易程序就掛起或崩潰。如果一個(gè)新版本沒通過可測試性的驗(yàn)證，就應(yīng)該阻攔測試部門花時(shí)間在該測試版本上測試。同時(shí)還要找到造成該版本不穩(wěn)定的主要缺陷并督促盡快加以修正。 BVT（Build Verification Test，構(gòu)建驗(yàn)證測試）是微軟內(nèi)部的一個(gè)標(biāo)準(zhǔn)說法，指的是每天都要運(yùn)行的測試，以確保前一天入庫的內(nèi)容沒有破壞重要功能。隨機(jī)測試(Random testing)：沒有

29、書面測試用例、記錄期望結(jié)果、檢查列表、腳本或指令的測試。主要是根據(jù)測試者的經(jīng)驗(yàn)對軟件進(jìn)行功能和性能抽查。隨機(jī)測試是根據(jù)測試說明書執(zhí)行用例測試的重要補(bǔ)充手段，是保證測試覆蓋完整性的有效方式和過程。不是按部就班的按照一個(gè)又一個(gè)正式的測試用例來進(jìn)行，也不局限于測試用例特定的步驟。這種測試是測試人員在理解該軟件功能的基礎(chǔ)上運(yùn)用靈活多樣的想象力和創(chuàng)造力去模擬用戶需求來使用該軟件的多種功能。通常涉及很多的測試用例或通過更復(fù)雜的步驟來使用該軟件。探索測試：通常用于沒有產(chǎn)品說明書的測試，這需要把軟件當(dāng)作產(chǎn)品說明書來看待，分步驟逐項(xiàng)探索軟件特性，記錄軟件執(zhí)行情況，詳細(xì)描述功能，綜合利用靜態(tài)和動(dòng)態(tài)技術(shù)來進(jìn)行測試。

30、自動(dòng)化測試（Automated Testing）:使用自動(dòng)化測試工具來進(jìn)行測試，這類測試一般不需要人干預(yù)，通常在GUI、性能等測試中用得較多。引導(dǎo)測試（Pilot testing）:軟件開發(fā)中，驗(yàn)證系統(tǒng)在真實(shí)硬件和客戶基礎(chǔ)上處理典型操作的能力。在軟件外包測試中，引導(dǎo)測試通常是客戶檢查軟件測試公司測試能力的一種形式，只有通過了客戶特定的引導(dǎo)測試，軟件測試公司才能接受客戶真實(shí)軟件項(xiàng)目的軟件測試?；貧w測試（Regression testing）：在發(fā)生修改之后重新測試先前的測試以保證修改的正確性。理論上，對軟件的任何新版本，都需要進(jìn)行回歸測試，驗(yàn)證以前發(fā)現(xiàn)和修復(fù)的錯(cuò)誤是否在新軟件版本上再現(xiàn)。五、測試

31、術(shù)語大全Test（測試）執(zhí)行軟件以驗(yàn)證其滿足指定的需求并檢測錯(cuò)誤的過程。檢測已有條件之間的不同，并評價(jià)軟件項(xiàng)的特性軟件項(xiàng)的分析過程。軟件工程過程的一個(gè)活動(dòng)，它將軟件在預(yù)定的條件下運(yùn)行以判斷軟件是否符合預(yù)期結(jié)果。Test case（測試用例）為特定目標(biāo)而開發(fā)的一組測試輸入、執(zhí)行條件和預(yù)期結(jié)果，其目標(biāo)可以是測試某個(gè)程序路徑或核實(shí)是否滿足某個(gè)特定的需求。Testing coverage（測試覆蓋）指測試系統(tǒng)覆蓋被測試系統(tǒng)的程度，一項(xiàng)給定測試或一組測試對某個(gè)給定系統(tǒng)或構(gòu)件的所有指定測試用例進(jìn)行處理所達(dá)到的程度。Testing environment（測試環(huán)境）進(jìn)行測試的環(huán)境，包括測試平臺、測試基礎(chǔ)設(shè)施

32、、測試實(shí)驗(yàn)室和其他設(shè)施。Testing item（測試項(xiàng)）作為測試對象的工作版本。Testing plan（測試計(jì)劃）描述了要進(jìn)行的測試活動(dòng)的范圍、方法、資源和進(jìn)度的文檔。它確定測試項(xiàng)、被測特性、測試任務(wù)、誰執(zhí)行任務(wù)、各種可能的風(fēng)險(xiǎn)。Testing procedure（測試過程）指設(shè)置、執(zhí)行給定測試用例并對測試結(jié)果進(jìn)行評估的一系列詳細(xì)步驟。Testing script（測試腳本）一般指的是一個(gè)特定測試的一系列指令，這些指令可以被自動(dòng)化測試工具執(zhí)行。Testing suite（測試包）一組測試用里的執(zhí)行框架；一種組織測試用例的方法。在測試包里，測試用例可以組合起來創(chuàng)造出獨(dú)特的測試條件。Valid

33、 case（有效用例或者叫合法輸入用例）是那些已知軟件程序能正確地處理的測試用例。一般是指軟件輸入的測試用例。比如說，在 Microsoft Excel 中，用鍵盤輸入“=1+1”, 看到的結(jié)果是“2”。 這里輸入的有效用例是“=1+1”。 Invalid case (無效用例有人叫不合法輸入用例) 或者出錯(cuò)用例 (error case)是那些事先就知道軟件程序不支持處理的測試用例。比如說在 Microsoft Excel 中，用鍵盤輸入“=a+1”, 看到的結(jié)果是“#NAME?”。這里輸入的“=a+1”既是無效用例同時(shí)也是出錯(cuò)用例。Boundary Cases（邊界條件）環(huán)繞邊界值的測試。通

34、常意味著最大值，最小值或者所設(shè)計(jì)軟件能夠處理的最長的字符串等等。比如說某軟件字體的字號支持范圍是:從8到72。那么邊界測試用例應(yīng)該包括:小于8, 等于8, 等于72 和大于72。Equivalent classes (等價(jià)類)等價(jià)類測試用例指的是如果有很多測試用例執(zhí)行再多也不會(huì)找到新的中的缺陷。因?yàn)殡m然輸入和輸出結(jié)果有所不同，但是它們都通過同樣的軟件的源代碼路徑。通常只要一個(gè)源代碼程序的路徑是用于處理一定數(shù)值范圍內(nèi)的所有數(shù)值，那么除了邊界值以外，在邊界值范圍以內(nèi)的所有數(shù)值一般都屬于等價(jià)類。因?yàn)槿绻浖绦蚰苷_處理一個(gè)值，也就意味著該程序能正確處理在這個(gè)范圍內(nèi)的除了邊界值以外的其他任何有效輸入

35、值。我們來用以上軟件字體的字號來舉例說明。軟件支持的字號范圍是:從8到72。那么8和72之間的所有支持的字號都可以被認(rèn)為是等價(jià)類的測試用例。再比如:測試超鏈接時(shí)兩個(gè)用例 / 和 / 也是等價(jià)類的測試用例。User interface（用戶界面，UI）廣義是指使用戶可以和計(jì)算機(jī)進(jìn)行交互的硬件和/或軟件。狹義是指軟件中的可見外觀及其底層與用戶交互的部分（菜單、對話框、窗口和其它控件）。Bug (錯(cuò)誤)有時(shí)稱作defect（缺陷）或error（錯(cuò)誤），軟件程序中存在的編程錯(cuò)誤，可能會(huì)帶來不必要的副作用，軟件的功能和特性與設(shè)

36、計(jì)規(guī)格說明書或用戶需求不一致的方面。軟件缺陷表現(xiàn)特征為：軟件未達(dá)到產(chǎn)品說明書標(biāo)明的功能；軟件出現(xiàn)產(chǎn)品說明書指明不會(huì)出現(xiàn)的錯(cuò)誤；軟件功能超出產(chǎn)品說明書指明的范圍；雖然產(chǎn)品說明書未指出但是軟件應(yīng)達(dá)到的目標(biāo)；軟件測試人員或用戶認(rèn)為軟件難以理解，不易使用，運(yùn)行速度緩慢等問題。 Bug report（錯(cuò)誤報(bào)告），也稱為“Bug record（錯(cuò)誤記錄）”，記錄發(fā)現(xiàn)的軟件錯(cuò)誤信息的文檔，通常包括錯(cuò)誤描述、復(fù)現(xiàn)步驟、抓取的錯(cuò)誤圖像和注釋等。Bug tracking system（錯(cuò)誤跟蹤系統(tǒng)，BTS）也稱為“Defect tracking system，DTS”，管理軟件測試缺陷的專用數(shù)據(jù)庫系統(tǒng)，可以高效率

37、地完成軟件缺陷的報(bào)告、驗(yàn)證、修改、查詢、統(tǒng)計(jì)、存儲(chǔ)等任務(wù)。尤其適用于大型多語言軟件的測試管理。Exception（異常/例外）一個(gè)引起正常程序執(zhí)行掛起的事件。Crash（崩潰）計(jì)算機(jī)系統(tǒng)或組件突然并完全的喪失功能，例如軟件或系統(tǒng)突然退出或沒有任何反應(yīng)（死機(jī)）。Build（工作版本）軟件開發(fā)過程中用于內(nèi)部測試的功能和性能等不完善的軟件版本。工作版本既可以是系統(tǒng)的可操作版本，也可以是展示要在最終產(chǎn)品中提供的部分功能的部分系統(tǒng)。Priority（優(yōu)先權(quán)）從商業(yè)角度出發(fā)是指錯(cuò)誤的重要性，尤其是從客戶和用戶的角度出發(fā)，是指錯(cuò)誤對于系統(tǒng)的可行性和可接受性的影響。與“Severity（嚴(yán)重性）”相對照。Se

38、verity（嚴(yán)重性）錯(cuò)誤對被測系統(tǒng)的影響程度，在終端用戶條件下發(fā)生的可能性，軟件錯(cuò)誤妨礙系統(tǒng)使用的程度。Capture/Replay Tool (捕獲/回放工具)一種測試工具，能夠捕獲在測試過程中傳遞給軟件的輸入，并且能夠在以后的時(shí)間中，重復(fù)這個(gè)執(zhí)行的過程。這類工具一般在GUI測試中用的較多。Debug（調(diào)試）開發(fā)人員確定引起錯(cuò)誤的根本原因和確定可能的修復(fù)措施的過程。一般發(fā)生在子系統(tǒng)或單元模塊編碼完成時(shí)，或者根據(jù)測試錯(cuò)誤報(bào)告指出錯(cuò)誤以后，開發(fā)人員需要執(zhí)行調(diào)試過程來解決已存在的錯(cuò)誤。Deployment（部署）也稱為shipment(發(fā)布)，對內(nèi)部IT系統(tǒng)而言，指它的第一個(gè)版本通過徹底的測試、

39、形成產(chǎn)品、交付給付款客戶的階段。 Dynamic testing（動(dòng)態(tài)測試），通過執(zhí)行軟件的手段來測試軟件。Garbage characters（亂碼字符）程序界面中顯示的無意義的字符，如程序?qū)﹄p字節(jié)字符集的字符不支持時(shí)，這些字符不能正確顯示GB 18030 testing（GB 18030測試）軟件支持GB 18030字符集標(biāo)準(zhǔn)能力的測試，包括GB 18030字符的輸入、輸出、顯示、存儲(chǔ)的支持程度。Quality assurance（質(zhì)量保證QA）采取相關(guān)活動(dòng)，以保證一個(gè)開發(fā)組織交付的產(chǎn)品滿足性能需求和已確立的標(biāo)準(zhǔn)和過程。Review（評審）在產(chǎn)品開發(fā)過程中，把產(chǎn)品提交給項(xiàng)目成員、用戶、管理

40、者或其它相關(guān)人員評價(jià)或批準(zhǔn)的過程。Screen shot（抓屏、截圖）軟件測試中，將軟件界面中的錯(cuò)誤（窗口、菜單、對話框等）的全部或一部分，使用專用工具存儲(chǔ)成圖像文件，以便于后續(xù)處理。Software life cycle（軟件生命周期）開始于一個(gè)軟件產(chǎn)品的構(gòu)思，結(jié)束于該產(chǎn)品不再被使用的這段期間。Structured query language（結(jié)構(gòu)化查詢語句，SQL）在一個(gè)關(guān)系數(shù)據(jù)庫中查詢和處理數(shù)據(jù)的一種語言。TBD (To be determined，待定)在測試文檔中標(biāo)是一項(xiàng)進(jìn)行中的尚未最終確定的工作。TBC (To be confirm，待確認(rèn))SQA（Software Qualit

41、y Assurance，軟件質(zhì)量保證）Interface（接口）六、缺陷管理6.1、Bug的嚴(yán)重級別 (Severity) 是指因缺陷引起的故障對軟件產(chǎn)品的影響程度。由測試人員指定。級別代表意義A錯(cuò)誤導(dǎo)致了死機(jī)、產(chǎn)品失?。ā氨罎ⅰ保?、系統(tǒng)懸掛無法操作；B功能未實(shí)現(xiàn)或?qū)е乱粋€(gè)特性不能運(yùn)行并且不可能有替代方案（包括計(jì)算錯(cuò)誤）；C錯(cuò)誤導(dǎo)致了一個(gè)特性不能運(yùn)行但可有一個(gè)替代方案；D錯(cuò)誤是表面化或微小的（提示信息不太準(zhǔn)確友好、錯(cuò)別字、UI布局或罕見故障等），對功能幾乎沒有影響，產(chǎn)品及屬性仍可使用；E建設(shè)性的意見或建議。6.2、Bug的優(yōu)先級 (Priority)指缺陷必須被修復(fù)的緊急程度。由Bug分配者（

42、開發(fā)組長/經(jīng)理）指定。優(yōu)先級代表意義5阻止相關(guān)開發(fā)人員的進(jìn)一步開發(fā)活動(dòng)，立即進(jìn)行修復(fù)工作；阻止與此密切相關(guān)功能的進(jìn)一步測試；4必須修改，發(fā)版前必須修正；3必須修改，不一定馬上修改，但需確定在某個(gè)特定里程碑結(jié)束前須修正；2如果時(shí)間允許應(yīng)該修改；1允許不修改。6.3、Bug的類型 (Type)是根據(jù)缺陷的自然屬性劃分的缺陷種類。類型代表意義Build由于配置庫、變更管理或版本控制引起的錯(cuò)誤。GUIUser Interface人機(jī)交互特性：屏幕格式，頁面排版、控件位置等方面的缺陷。Data數(shù)據(jù)、數(shù)據(jù)庫、計(jì)算錯(cuò)誤等。Function影響了重要的特性、產(chǎn)品接口、硬件結(jié)構(gòu)接口和全局?jǐn)?shù)據(jù)結(jié)構(gòu)。如邏輯，指針，

43、循環(huán)，遞歸，功能等缺陷。Interface與其他組件、模塊或設(shè)備驅(qū)動(dòng)程序、調(diào)用參數(shù)、控制塊或參數(shù)列表相互影響的接口缺陷Performance不滿足系統(tǒng)可測量的屬性值，如：執(zhí)行時(shí)間，事務(wù)處理速率等。Requirement需求方面缺陷如（不明確、錯(cuò)誤、考慮不全面等等）。Others其它未知錯(cuò)誤6.4、Bug狀態(tài) (Status)指缺陷通過一個(gè)跟蹤修復(fù)過程的進(jìn)展情況。包括Open、Fixed、Closed及Postponed等狀態(tài)代表意義Open為測試人員新問題提交所標(biāo)志的狀態(tài)。為任務(wù)分配人（開發(fā)組長/經(jīng)理）對該問題準(zhǔn)備進(jìn)行修改并對該問題分配修改人員所標(biāo)志的狀態(tài)。Bug解決中的狀態(tài)，由任務(wù)分配人改變

44、。對沒有進(jìn)入此狀態(tài)的Bug，程序員不用管。Fixed為開發(fā)人員修改問題后所標(biāo)志的狀態(tài)，修改后還未測試。Closed為測試人員對修改問題進(jìn)行驗(yàn)證后通過所標(biāo)志的狀態(tài)。由測試人員改變。Postponed1、由于開發(fā)時(shí)間、進(jìn)度、重要程度或者技術(shù)/設(shè)計(jì)/需求等方面的原因，認(rèn)為不能解決、須延期解決、或者本版不做留待到后續(xù)版本解決的Bug； 2、因設(shè)計(jì)結(jié)構(gòu)問題無法修改。測試人員認(rèn)為是Bug，不符合邏輯，也不符合用戶的要求，但開發(fā)人員則認(rèn)為是按照設(shè)計(jì)做的、只能如此處理，否則修改代價(jià)太大 ，這種問題可以拖后處理。Duplicatedbug重復(fù)提交。Not error測試人員理解錯(cuò)了，不是Bug。Cancel需求改變了或者其他原因取消了。6.5、提交Bug的注意事項(xiàng)v 確保重現(xiàn)；v 要用最少并且必要的步驟描述BUG，簡潔、準(zhǔn)確、完整；v 一個(gè)Bug一條報(bào)告；v 最好附帶截圖或Java Log等內(nèi)部報(bào)錯(cuò)信息。6.6、常見的Bug管理工具TD、Track Record、Clearquest、Bugzilla、Mantis、JIRABug Free、QCNMT用Timesheet七、常見易混概念匯總 Retest/Regression TestRetest即回歸測試，即對一個(gè)Bu