軟件測試方法流程類型缺陷

1、I. 測試類型功能指的是系統(tǒng)能做什么 。系統(tǒng)子系統(tǒng)或組件要實現(xiàn)的功能可以在工作產(chǎn)品中，如需求規(guī)格說明書，用戶用例或 功能規(guī)格說明書予以描述，不過也可能沒有相應(yīng)的文檔。功能測試基于功能和特征以及專門的系統(tǒng)之間的交互，系統(tǒng)的功能來設(shè)計測試條件和 測試用例。1 專門的系統(tǒng)之間的交互，我們又叫做功能交互2 可以采用基于規(guī)格說明書的技術(shù)（有正式的需求或設(shè)計規(guī)格說明書時）3 也可以基于測試人員對功能和特征的理解（如果沒有相應(yīng)文檔時）4 功能測試主要是考慮軟件的外部表現(xiàn)行為（黑盒測試）5 功能測試可以在個級別的測試中進行（例如組件測試、集成測試和系統(tǒng)測試等級別 都有基于設(shè)計或需求規(guī)格說明書的功能測試）1.

2、功能測試舉例1 安全性測試也是功能測試的一種，它會對安全性相關(guān)的功能（比如防火墻）進行 測試，從而檢測系統(tǒng)和數(shù)據(jù)是否能抵御外部惡意的威脅，比如病毒等。2 互操作性測試是另一種功能性測試，評估軟件產(chǎn)品與其他一個或多個組件或系統(tǒng) 交互的能力。2. 非功能測試非功能性測試就是測試系統(tǒng)工作的怎樣 非功能測試包括但不限于：性能測試、負(fù)載測試、壓力測試、可用性測試、可維護性 測試、可靠性測試和可移植性測試非功能測試可以在任何測試級別上執(zhí)行3. 非功能測試舉例負(fù)載測試：一種通過增加負(fù)載來測量組件或系統(tǒng)的測試方法。例如：通過并發(fā)用戶數(shù) 和事務(wù)數(shù)量來測量組件或系統(tǒng)能夠承受的負(fù)載。壓力測試：在規(guī)定的或超過規(guī)定的需

3、求條件下測試組件 系統(tǒng)，以對其進行評估。 健壯性測試：判定軟件產(chǎn)品健壯性(在出現(xiàn)無效輸入或壓力環(huán)境條件下，組件、系統(tǒng) 能夠正常工作的程度，參見 fault-tolerance )的測試。性能測試：判定軟件產(chǎn)品性能(組件、系統(tǒng)在給定的處理周期和吞吐率( throughputrate )等約束下，完成指定功能的程度)的測試過程。參見 efficiencytesting.4. 與變更相關(guān)的測試與變更相關(guān)的測試：當(dāng)軟件被修改、缺陷被修復(fù)、新增了功能、軟件運行環(huán)境發(fā)生變 化等，需要開展與變更有關(guān)的測試。根據(jù)經(jīng)驗，修改一個現(xiàn)存的程序，比編寫一個新程序更容易產(chǎn)生錯誤(依每寫一行代 碼的錯誤數(shù)量計)再測試：重

4、新執(zhí)行上次失敗的測試用例，以驗證糾錯的正確性。參見確認(rèn)測試( confirmationtesting ) 回歸測試：測試先前測試過并修改過的程序，確保更改沒有給軟件其他未改變的部分 帶來退化缺陷( regressionbung ). 軟件修改后或使用環(huán)境變更后要執(zhí)行回歸測試。 回歸測試策略：回歸測試的規(guī)?？梢愿鶕?jù)在已運行的軟件中發(fā)現(xiàn)新的缺陷的風(fēng)險大小來決定，比 如可以只重新運行所有發(fā)現(xiàn)缺陷的用例(即只進行確認(rèn)測試)、測試所有經(jīng)過修改的 功能、測試所有新增功能、對整個系統(tǒng)進行完美的回歸測試等，對變更進行影響分析 ( impactanalysis )有助于確定回歸測試的深度。將回歸測試自動化是很好

5、的選擇回歸測試可以在所有的測試級別上進行， 構(gòu)測試。同時適用于功能測試、非功能測試和結(jié)5. 維護測試維護測試是在一個現(xiàn)有的運行系統(tǒng)上進行，且一旦對軟件或系統(tǒng)進行修改、移植或退 役處理時，就需要進行維護測試。除了對已變更的部分進行測試外，維護測試還包括對系統(tǒng)沒有發(fā)生變更的其他部 分進行大范圍的回歸測試。維護測試的范圍取決于變更的風(fēng)險、現(xiàn)有系統(tǒng)的規(guī)模和變 更的大小。維護測試根據(jù)變更情況的不同，可以在某一或所有的測試級別和測試類型上進 行。修改可以是計劃中的功能增強（例如：根據(jù)版本發(fā)布的計劃）、糾正和應(yīng)急變更、環(huán) 境的變化比如計劃中的操作系統(tǒng)或數(shù)據(jù)庫升級，或由于新發(fā)現(xiàn)或暴露的軟件、操作系 統(tǒng)、硬件漏

6、洞而大打的補丁等。為軟件移植（如從一個平臺移植到另外一個平臺）而進行的維護測試應(yīng)該包括新環(huán)境 的運行測試（ operationaltesting ），以及對變更以后的軟件的運行測試。為系統(tǒng)退役而進行的維護測試應(yīng)該包括數(shù)據(jù)移植或者存檔測試，如果需要長時間的數(shù) 據(jù)保存的話。II. 測試方法軟件測試方法是指測試軟件性能的方法。隨著軟件測試技 術(shù)的不斷發(fā)展，測試方法也越來越多樣化，針對性更強； 選擇合適的軟件測試方法可以讓用戶事半功倍。軟件測試 方法有系統(tǒng)測試、動態(tài)測試、單元測試、集成測試等多種B 測試，英文名是 Beta testing 。又稱 Beta 測試用戶驗收測試（ uat ）B測試是軟件的

7、多個用戶在一個或多個用戶的實際使用環(huán)境下進行的測試。當(dāng)開發(fā)和測試要完成所做的測試，而最終的錯誤和問題需要在最終發(fā)行前找到。這種 測試一般由最終用戶或其他人員完成，不能由程序員或測試員完成。A測試-Alpha 測試A 測試，英文名是 Alpha testing 。又稱 Alpha 測試。Alpha 測試是由用戶在開發(fā)環(huán)境下進行的測試，也可以是公司內(nèi)部的用戶在模擬實際操 作環(huán)境下進行的受控測試， Alpha 測試不能由該系統(tǒng)的程序員或測試員完成。在系統(tǒng)開發(fā)接近完成時對應(yīng)用系統(tǒng)的測試；測試后仍然會有少量的設(shè)計變更。這種測 試一般由最終用戶或其他人員來完成，不能由程序員或測試員完成?？梢浦残詼y試，英文

8、名是 Portability testing 。又稱兼容性測試?？梢浦残詼y試是指測試軟件是否可以被成功移植到指點的硬件或軟件平臺上。1. UI 測試用戶界面測試，英文名是 User interface testing 。又稱 UI 測試。用戶界面，英文名是 User interface 。是指軟件中的可見外觀及其底層與用戶交互的 部分（菜單、對話框、窗口和其他控件）。用戶界面測試是指測試用戶界面的風(fēng)格是否美觀，文字，圖片組合是否完美，操作是 否友好等等。 UI 測試的目標(biāo)是確保用戶界面會通過測試對象的功能來為用戶提供相應(yīng) 的訪問或瀏覽功能。確保用戶界面符合公司或行業(yè)的標(biāo)準(zhǔn)。包括用戶友好性、人性

9、 化、易操作性測試。用戶界面測試用戶 分析軟件用戶界面的設(shè)計是否合乎用戶期望或要求。它常常包括等 菜單，對話框及對話框上所有的按鈕，文字，出錯提示，幫助信息（ Menu 和 heipcontent ）等方面的測試。比如，測試 Microsoft Excel 中插入符合功能所用的對 話框的大小，所有按鈕是否對齊，字符串字體大小，出錯信息內(nèi)容和字體大小，工具 欄位置、圖標(biāo)等等。2. 冒煙測試冒煙測試，英文名是 Snoke testing 。冒煙測試的名稱可以理解為該種測試耗時短，僅用一袋煙功夫足夠了。也有人認(rèn)為是 形象地類比新電路板基本功能檢查。任何新電路板焊好后，先通電檢查，如果存在設(shè) 計缺陷，

10、電路板可能會短路，板子冒煙了。冒煙測試的對象是新編譯的每一個需要正式測試的軟件版本，目的是確認(rèn)軟件基本功 能正常，可以進行后續(xù)的正式測試工作。冒煙測試的執(zhí)行者是版本編譯人員。3. 隨機測試隨機測試，英文名是 Ad hoc testing 。隨機測試沒有書面測試用例、記錄期望結(jié)果、檢查列表、腳本或指令的測試。主要是 根據(jù)測試者的經(jīng)驗對軟件進行功能和性能抽查。隨機測試是根據(jù)說明書執(zhí)行用例測試 的只要補充手段，是保證測試覆蓋完整性的有效方法和過程。隨機測試主要是對被測軟件的一些重要功能進行復(fù)測，也包括測試那些當(dāng)前的測試樣 例( TestCase )沒有覆蓋到的部分。另外，對于軟件更新和新增加的功能要

11、重點測 試。重點對一些特殊點情況點、特殊的使用環(huán)境、并發(fā)性、進行檢查。尤其對以前測 試發(fā)現(xiàn)的直達 Bug ，進行再次測試，可以結(jié)合回歸測試( Regressive testing )一起進 行。本地化測試 本地化測試，英文是 Localization testing 。本地化就是將軟件版本語言進行更改，比如將英文的 windows 改成中文的 windows 就是本地化。 本地化測試 的對象是軟件的本地化版本。本地化測試的目的是測試特定目標(biāo) 區(qū)域設(shè)置 的軟件本地化 質(zhì)量。本地化測試的環(huán)境是在本地化的操作系統(tǒng)上安裝本地化的軟 件。從測試方法上可以分為基本功能測試，安裝/卸載 測試，當(dāng)?shù)貐^(qū)域的軟硬

12、件兼容性測試。測試的內(nèi)容主要包括軟件本地化后的界面布局和軟件翻譯的語言質(zhì)量，包含軟件、文 檔和聯(lián)機幫助等部分。1. 基礎(chǔ)化本地化能力測試 ，英文是 Localizability testing 。本地化能力測試是指不需要重新設(shè)計或修改代碼，將程序的用戶界面翻譯成任何目標(biāo) 語言的能力。為了降低本地化能力測試的成本，提高測試效率，本地化能力測試通常在軟 件的 偽本地化 版本上進行。本地化能力測試中發(fā)現(xiàn)的典型錯誤包括：字符 的硬編碼（即軟件中需要本地化的字符寫在了代碼內(nèi)部），對需要本地化的字符長度設(shè)置了固定值，在軟件運行時以控件位置定 位，圖標(biāo)和 位圖 中包含了需要本地化的文本，軟件的用戶界面與文檔

13、術(shù)語不一致等。2. 國際化國際化測試，英文是 International testing 。又稱國際化支持測試。國際化測試 的目的是測試軟件的國際化支持能力，發(fā)現(xiàn)軟件的國際化的潛在問題，保 證軟件在世界不同區(qū)域都能正常運行。國際化測試使用每種可能的國際輸入類型，針對任 何區(qū)域性或 區(qū)域設(shè)置 檢查產(chǎn)品的功能是否正常， 軟件國際化 測試的重點在于執(zhí)行國際字符 串的輸入 /輸出功能。國際化測試數(shù)據(jù)必須包含 東亞語言 、德語、復(fù)雜腳本字符和英語（可 選）的混合字符。國際化支持測試是指驗證軟件程序在不同國家或區(qū)域的平臺上也能夠如預(yù)期的那樣運 行，而且還可以按照原設(shè)計尊重和支持使用當(dāng)?shù)爻Ｓ玫娜掌?，字體，文

14、字表示，特殊格式 等等。比如，用英文版的 Windows XP 和 Microsoft Word 能否展示阿拉伯字符串 ? 用阿拉 伯版的 Windows XP 和 阿拉伯版的 Microsoft Word 能否展示阿拉伯字符串 ?又比如，日文 版的 Microsoft Excel 對話框是否顯示正確翻譯的日語 ? 一旦來說執(zhí)行國際化支持測試的測 試人員往往需要基本上了解這些國家或地區(qū)的語言要求和期望行為是什么。3. 安裝測試安裝測試，英文是 Installing testing 。安裝測試 是確保軟件在正常情況和異常情況下，例如，進行首次安裝、升級、完整的 或自定義的安裝都能進行安裝的測試。

15、異常情況包括磁盤空間不足、缺少目錄創(chuàng)建權(quán)限等 場景。核實軟件在安裝后可立即正常運行。安裝測試包括測試安裝代碼以及安裝手冊。安 裝手冊提供如何進行安裝，安裝代碼提供安裝一些程序能夠運行的基礎(chǔ)數(shù)據(jù)。B. 白盒測試白盒測試，英文是 White Box Testing 。又稱結(jié)構(gòu)測試或者邏輯 驅(qū)動 測試。白盒測試 是把測試對象看作一個打開的盒子。利用白盒測試法進行 動態(tài)測試 時，需要 測試軟件產(chǎn)品的內(nèi)部結(jié)構(gòu)和處理過程，不需測試軟件產(chǎn)品的功能。白盒測試法的覆蓋標(biāo)準(zhǔn)有 邏輯覆蓋 、循環(huán)覆蓋和基本 路徑測試 。其中邏輯覆蓋包括 語 句覆蓋 、判定覆蓋 、條件覆蓋 、判定 /條件覆蓋、 條件組合覆蓋 和 路徑

16、覆蓋 。白盒測試是知道產(chǎn)品內(nèi)部工作過程，可通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說 明書的規(guī)定正常進行，按照程序內(nèi)部的結(jié)構(gòu) 測試程序 ，檢驗程序中的每條通路是否都有能 按預(yù)定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅(qū)動、基路測試等， 主要用于軟件驗證。白盒測試 常用工具有： Jtest 、 VcSmith 、 Jcontract 、C+ Test 、 CodeWizard 、 logiscope 。C. 黑盒測試黑盒測試 ，英文是 Black Box Testing 。又稱 功能測試 或者 數(shù)據(jù)驅(qū)動測試 。黑盒測試是根據(jù)軟件的規(guī)格對軟件進行的測試，這類測試不考慮軟件內(nèi)部的運作原

17、理，因此軟件對用戶來說就像一個黑盒子。軟件測試人員 以用戶的角度，通過各種輸入和觀察軟件的各種輸出結(jié)果來發(fā)現(xiàn)軟件存 在的缺陷，而不關(guān)心程序具體如何實現(xiàn)的一種軟件測試方法。黑盒測試常用工具有： AutoRunner 、 winrunnerD. 自動化自動化測試，英文是 Automated Testing 。使用自動化測試工具來進行測試，這類測試一般不需要人干預(yù)，通常在 GUI 、性能等 測試和 功能測試 中用得較多。通過錄制 測試腳本 ，然后執(zhí)行這個測試腳本來實現(xiàn) 測試過程 的自動化。國內(nèi)領(lǐng)先的 自動化測試 服務(wù)提供商是澤眾軟件。自動化測試工具有 QTP 、 Testcomplete 、 Aut

18、oRunner 和 TAR 等。1. 回歸測試回歸測試，英文是 Regression testing ?；貧w測試 是指在發(fā)生修改之后重新測試先前的測試以保證修改的正確性。理論上，軟 件產(chǎn)生新版本，都需要進行回歸測試，驗證以前發(fā)現(xiàn)和修復(fù)的錯誤是否在新軟件版本上再 次出現(xiàn)。根據(jù)修復(fù)好了的缺陷再重新進行測試?；貧w測試的目的在于驗證以前出現(xiàn)過但已經(jīng)修 復(fù)好的缺陷不再重新出現(xiàn)。一般指對某已知修正的缺陷再次圍繞它原來出現(xiàn)時的步驟重新 測試。通常確定所需的再測試的范圍時是比較困難的，特別當(dāng)臨近產(chǎn)品發(fā)布日期時。因為 為了修正某缺陷時必需更改 源代碼 ，因而就有可能影響這部分源代碼所控制的功能。所以 在驗證修好

19、的缺陷時不僅要服從缺陷原來出現(xiàn)時的步驟重新測試，而且還要測試有可能受 影響的所有功能。因此應(yīng)當(dāng)鼓勵對所有回歸測試用例進行 自動化測試 。2. 驗收測試驗收測試，英文是 Acceptance testing 。驗收測試是指 系統(tǒng)開發(fā)生命周期 方法論的一個階段，這時相關(guān)的用戶或獨立測試人員 根據(jù)測試計劃 和結(jié)果對系統(tǒng)進行測試和接收。它讓 系統(tǒng)用戶 決定是否接收系統(tǒng)。它是一項 確定產(chǎn)品是否能夠滿足合同或用戶所規(guī)定需求的測試。驗收測試 一般有三種策略：正式驗收、非正式驗收或 Alpha 測試、 Beta 測試。E. 靜態(tài)測試靜態(tài)測試，英文是 Static Testing 。靜態(tài)測試 指測試不運行的部分

20、，例如測試產(chǎn)品說明書，對此進行檢查和審閱.。 靜態(tài)方法 是指不運行被測程序本身，僅通過分析或檢查源程序的文法、結(jié)構(gòu)、過程、接口等來 檢查程序的正確性。靜態(tài)方法通過程序靜態(tài)特性的分析，找出欠缺和可疑之處，例如不匹 配的參數(shù)、不適當(dāng)?shù)?循環(huán)嵌套 和分支嵌套、不允許的遞歸、未使用過的變量、空指針的引 用和可疑的計算等。靜態(tài)測試結(jié)果可用于進一步的查錯，并為 測試用例 選取提供指導(dǎo)。靜態(tài)測試常用工具有： Logiscope 、PRQA ；F. 動態(tài)測試動態(tài)測試 ，英文是 Moment Testing 。動態(tài)測試是指通過運行軟件來檢驗軟件的動態(tài)行為和運行結(jié)果的正確性。根據(jù)動態(tài)測試在軟件開發(fā)過程中所處的階段

21、和作用，動態(tài)測試可分為如下幾個步驟：1、單元測試2、集成測試3、系統(tǒng)測試4、驗收測試5、回歸測試G. 單元測試單元測試，英文是 Unit Testing 。單元測試 是最微小規(guī)模的測試 ;以測試某個功能或代碼塊。典型地由程序員而非測試 員來做，因為它需要知道內(nèi)部程序設(shè)計和編碼的細節(jié)知識。這個工作不容易做好，除非應(yīng) 用系統(tǒng)有一個設(shè)計很好的 體系結(jié)構(gòu) ; 還可能需要開發(fā)測試驅(qū)動器模塊或測試套具。H. 集成測試集成測試，英文是 Integration Testing 。集成測試 是指一個應(yīng)用系統(tǒng)的各個部件的聯(lián)合測試，以決定它們能否在一起共同工作 并沒有沖突。部件可以是代碼塊、獨立的應(yīng)用、網(wǎng)絡(luò)上的客戶

22、端或服務(wù)器端程序。這種類 型的測試尤其與客戶服務(wù)器和 分布式系統(tǒng) 有關(guān)。一般集成測試以前， 單元測試 需要完成。集成測試是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經(jīng)測試過的單元組合 成一個組件，并且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚 合。在現(xiàn)實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是 測試片段的組合，并最終擴展進程，將您的模塊與其他組的模塊一起測試。最后，將構(gòu)成 進程的所有模塊一起測試。此外，如果程序由多個進程組成，應(yīng)該成對測試它們，而不是 同時測試所有進程。集成測試 識別組合單元時出現(xiàn)的問題。通過使用要求在組合單元前測試每個單元，

23、并 確保每個單元的生存能力的 測試計劃 ，可以知道在組合單元時所發(fā)現(xiàn)的任何錯誤很可能與 單元之間的接口有關(guān)。這種方法將可能發(fā)生的情況數(shù)量減少到更簡單的分析級別I. 系統(tǒng)測試系統(tǒng)測試，英文是 System Testing 。系統(tǒng)測試是基于系統(tǒng)整體需求說明書的黑盒類測試，應(yīng)覆蓋系統(tǒng)所有聯(lián)合的部件。 系 統(tǒng)測試 是針對整個產(chǎn)品系統(tǒng)進行的測試，目的是驗證系統(tǒng)是否滿足了需求規(guī)格的定義，找 出與需求規(guī)格不相符合或與之矛盾的地方。系統(tǒng)測試的對象不僅僅包括需要測試的產(chǎn)品系統(tǒng)的軟件，還要包含軟件所依賴的硬 件、外設(shè)甚至包括某些數(shù)據(jù)、某些支持軟件及其接口等。因此，必須將系統(tǒng)中的軟件與各 種依賴的資源結(jié)合起來，在系

24、統(tǒng)實際運行環(huán)境下來進行測試。J. 端到端端到端測試，英文是 End to End Testing 。端到端測試類似于 系統(tǒng)測試 ，測試級的 “宏大 ”的端點，涉及整個應(yīng)用系統(tǒng)環(huán)境在一個 現(xiàn)實世界使用時的模擬情形的所有測試。例如與數(shù)據(jù)庫對話，用網(wǎng)絡(luò)通訊，或與外部硬 件、應(yīng)用系統(tǒng)或適當(dāng)?shù)南到y(tǒng)對話。端到端架構(gòu)測試包含所有訪問點的 功能測試 及性能測 試。端到端架構(gòu)測試實質(zhì)上是一種 灰盒 測試，一種集合了 白盒測試 和黑盒測試 的優(yōu)點的 測試方法。K. 卸載測試卸載 測試，英文是 Uninstall Testing卸載測試是對軟件的全部、部分或升級卸載處理過程的測試。主要是測試軟件能否卸 載，卸載是否

25、干凈，對系統(tǒng)有無更改，在系統(tǒng)中的殘留與后來的生成文件如何處理等。還 有原來更改的系統(tǒng)值是否修改回去L. 驗收測試接受測試，英文是 Accept Testing 。接受測試是基于客戶或最終用戶的規(guī)格書的最終測試，或基于用戶一段時間的使用 后，看軟件是否滿足客戶要求。一般從功能、用戶界面、性能、業(yè)務(wù)關(guān)聯(lián)性進行測試。M. 性能測試性能測試，英文是 Performance Testing 。性能測試 是在交替進行負(fù)荷和 強迫測試 時常用的術(shù)語。理想的 “性能測試 ”和(其他類型 的測試 )應(yīng)在需求文檔或質(zhì)量保證、 測試計劃 中定義。性能測試一般包括 負(fù)載測試 和壓力測 試。通常驗證軟件的性能在正常環(huán)境

26、和系統(tǒng)條件下重復(fù)使用是否還能滿足性能指標(biāo)。或者 執(zhí)行同樣任務(wù)時新版本不比舊版本慢。一般還檢查系統(tǒng)記憶容量在運行程序時會不會出現(xiàn) 內(nèi)存泄露 (memory leak) 。比如，驗證程序保存一個巨大的文件新版本不比舊版本慢。1. 健全測試健全測試，英文是 Sanity testing 。健全測試 是指一個初始化的測試工作，以決定一個新的軟件版本測試是否足以執(zhí)行下 一步大的測試能力。例如，如果一個新版軟件每5 分鐘與系統(tǒng)沖突，使系統(tǒng)陷于泥潭，說明該軟件不夠 “健全 ”，不具備進一步測試的條件。2. 衰竭測試衰竭測試，英文是 Failure Testing 。衰竭測試是指軟件或環(huán)境的修復(fù)或更正后的 “

27、再測試 ”?？赡芎茈y確定需要多少遍再次 測試。尤其在接近開發(fā)周期結(jié)束時。自動測試工具對這類測試尤其有用。3. 負(fù)載測試負(fù)載測試，英文是 Load testing 。Web 站點在大量的負(fù)荷負(fù)載測試 是測試一個應(yīng)用在重負(fù)荷下的表現(xiàn)。例如測試一個 下，何時系統(tǒng)的響應(yīng)會退化或失敗，以發(fā)現(xiàn)設(shè)計上的錯誤或驗證系統(tǒng)的負(fù)載能力。在這種 測試中，將使測試對象承擔(dān)不同的工作量，以評測和評估測試對象在不同工作量條件下的 性能行為，以及持續(xù)正常運行的能力。負(fù)載測試的目標(biāo)是確定并確保系統(tǒng)在超出最大預(yù)期工作量的情況下仍能正常運行。此 外，負(fù)載測試還要評估性能特征，例如，響應(yīng)時間、事務(wù)處理速率和其他與時間相關(guān)的方 面。4

28、. 強迫測試強迫測試，英文是 Force Testing 。強迫測試 是在交替進行負(fù)荷和 性能測試 時常用的術(shù)語。也用于描述對象在異乎尋常的 重載 下的系統(tǒng)功能測試之類的測試，如某個動作或輸入大量的重復(fù)，大量數(shù)據(jù)的輸入，對 一個 數(shù)據(jù)庫系統(tǒng) 大量的復(fù)雜查詢等。5. 壓力測試壓力測試，英文是 Stress Testing 。和 負(fù)載測試 差不多。壓力測試是一種基本的質(zhì)量保證行為，它是每個重要軟件測試工作的一部分。壓力測 試的基本思路很簡單：不是在常規(guī)條件下運行手動或自動測試，而是在計算機數(shù)量較少或 系統(tǒng)資源匱乏的條件下運行測試。通常要進行壓力測試的資源包括內(nèi)部內(nèi)存、 CPU 可用 性、磁盤空間和

29、網(wǎng)絡(luò)帶寬等。一般用并發(fā)來做壓力測試。6. 恢復(fù)測試恢復(fù)測試，英文是 Recovery testing ?；謴?fù)測試 是測試一個系統(tǒng)從如下災(zāi)難中能否很好地恢復(fù)，如遇到 系統(tǒng)崩潰 、硬件損壞 或其他災(zāi)難性問題?；謴?fù)測試指通過人為的讓軟件(或者硬件)出現(xiàn)故障來檢測系統(tǒng)是否 能正確的恢復(fù)，通常關(guān)注恢復(fù)所需的時間以及恢復(fù)的程度?；謴?fù)測試主要檢查系統(tǒng)的容錯能力。當(dāng)系統(tǒng)出錯時，能否在指定時間間隔內(nèi)修正錯誤 并重新啟動系統(tǒng)。恢復(fù)測試首先要采用各種辦法強迫系統(tǒng)失敗，然后驗證系統(tǒng)是否能盡快 恢復(fù)。對于 自動恢復(fù) 需驗證重新初始化( reinitialization )、檢查點 (checkpointing mech

30、anisms) 、 數(shù)據(jù)恢復(fù) (data recovery) 和重新啟動 (restart) 等機制的正確性；對于人工干 預(yù)的恢復(fù)系統(tǒng)，還需估測 平均修復(fù)時間 ，確定其是否在可接受的范圍內(nèi)。N. 安全測試安全測試，英文是 Security Testing 。安全測試 是測試系統(tǒng)在防止非授權(quán)的內(nèi)部或外部用戶的訪問或故意破壞等情況時怎么樣。這可能需要復(fù)雜的測試技術(shù)。安全測試檢查系統(tǒng)對非法侵入的防范能力。安全測試期 間，測試人員假扮非法入侵者，采用各種辦法試圖突破防線。例如： 想方設(shè)法截取或破譯口令； 專門定做軟件破壞系統(tǒng)的保護機制； 故意導(dǎo)致系統(tǒng)失敗，企圖趁恢復(fù)之機非法進入； 試圖通過瀏覽非保密數(shù)

31、據(jù)，推導(dǎo)所需信息，等等。理論上講，只要有足夠的時間和 資源，沒有不可進入的系統(tǒng)。因此系統(tǒng)安全設(shè)計的準(zhǔn)則是，使非法侵入的代價超過被保護 信息的價值。此時非法侵入者已無利可圖。O. 兼容性兼容測試 ，英文是 Compatibility Testing 。兼容測試是測試軟件在一個特定的硬件 /軟件 /操作系統(tǒng) /網(wǎng)絡(luò)等環(huán)境下的性能如何。向 上兼容向下兼容， 軟件兼容 硬件兼容。軟件的兼容性有很多需要考慮的地方。P. 可用性可用性測試，英文是 Practical Usability Testing 。可用性測試是對 “用戶友好性 ”的測試。顯然這是主觀的，且將取決于目標(biāo)最終用戶或 客戶。用戶面談、調(diào)查

32、、用戶對話的錄象和其他一些技術(shù)都可使用。程序員和測試員通常 都不宜作可用性測試員。Q. 比較測試 比較測試，英文是 Compare Testing 。 比較測試是指與競爭伙伴的產(chǎn)品的比較測試，如軟件的弱點、優(yōu)點或?qū)嵙?。來取長補 短，以增強產(chǎn)品的競爭力。R. 可接受性可接受性測試，英文是 Acceptability Testing 。可接受性測試是在把測試的版本交付測試部門大范圍測試以前進行的對最基本功能的 簡單測試。因為在把測試的版本交付測試部門大范圍測試以前應(yīng)該先驗證該版本對于所測 試的功能基本上比較穩(wěn)定。必須滿足一些最低要求。比如不會很容易程序就掛起或崩潰。 如果一個新版本沒通過 可測試性

33、 的驗證，就應(yīng)該阻攔測試部門花時間在該測試版本上測 試。同時還要找到造成該版本不穩(wěn)定的主要缺陷并督促盡快加以修正S. 邊界條件邊界條件測試 ，英文是 Boundary Testing 。又稱 邊界值測試 。一種 黑盒測試 方法，適度等價類分析方法的一種補充,由長期的測試工作經(jīng)驗得知，大量的錯誤是發(fā)生在輸入或輸出的邊界上。因此針對各種邊界情況設(shè)計 測試用例 ，可以查 出更多的錯誤。邊界條件測試是環(huán)繞邊界值的測試。通常意味著測試軟件各功能是否能正確處理最大 值，最小值或者所設(shè)計軟件能夠處理的最長的字符串等等。T. 強力測試強力測試，英文是 Mightiness Testing 。強力測試通常驗證軟

34、件的性能在各種極端的環(huán)境和系統(tǒng)條件下是否還能正常工作?；?者說是驗證軟件的性能在各種極端環(huán)境和系統(tǒng)條件下的承受能力。比如，在最低的硬盤驅(qū) 動器空間或系統(tǒng)記憶容量條件下，驗證程序重復(fù)執(zhí)行打開和保存一個巨大的文件 1000 次 后也不會崩潰或 死機 。U. 裝配安裝裝配/安裝/配置測試是驗證軟件程序在不同廠家的硬件上，所支持的不同語言的新舊 版本平臺上，和不同方式安裝的軟件都能夠如預(yù)期的那樣正確運行。比如，把英文版的 Microsoft Office 2003 安裝在韓文版 的 Windows Me 上，再驗證所有功能都正常運行。V. 隱藏數(shù)據(jù)隱藏數(shù)據(jù)測試在軟件驗收和確認(rèn)階段是十分必要和重要的一部

35、分。程序的質(zhì)量不僅僅 通過用戶界面的可視化數(shù)據(jù)來驗證，而且必須包括遍歷系統(tǒng)的所有數(shù)據(jù)。假設(shè)一個應(yīng)用程序要求用戶兩條信息 用戶名和密碼來創(chuàng)建帳戶。這個用戶輸入這兩條數(shù)據(jù)后保存。最后，一個確認(rèn)窗口將通過數(shù)據(jù)庫中找到這條數(shù)據(jù)來顯示用戶名和密碼 給用戶。為了驗證所有的數(shù)據(jù)保存是否正確，一個 QA 測試人員會在這個確認(rèn)窗口簡單的 查看下用戶名和密碼。如果他們成功了？假設(shè)數(shù)據(jù)庫記錄了第三條信息 創(chuàng)建日期，它可能不會出現(xiàn)在確認(rèn)窗口，而只在存檔中才出現(xiàn)。如果創(chuàng)建日期保留的不正確，而 QA 測試 人員只驗證屏幕上的數(shù)據(jù)，那么這個問題就不可能被發(fā)現(xiàn)。創(chuàng)建日期可能就是一個bug ，由于一個用戶帳戶保存了一個錯誤的日

36、期到數(shù)據(jù)庫中，這個問題也不可能會被引起注意， 因為它被用戶界面所隱藏。這只是一個簡單的例子，但是它卻演化出了一點：隱藏數(shù)據(jù)測試的重要性。W. 等價劃分等價劃分測試的英文是 equivalence partition testing 。等價劃分測試是根據(jù)等價類設(shè)計 測試用例 的一種技術(shù)。是 黑盒測試 的典型方法之一， 通過把被 測試程序 所有可能的輸入數(shù)據(jù)域劃分成若干部分。從每一部分中選取少數(shù)有代表 性的數(shù)據(jù)作為測試用例，可有效減少測試次數(shù)，極大提高軟件測試效率，縮短軟件開發(fā)周 期等價類劃分測試的目的就是為了在有限的測試資源的情況下，用少量有代表性的數(shù)據(jù) 得到比較好的測試效果。有效等價類和 無效

37、等價類 。有效等價類中的數(shù)據(jù)代表的是一組符 合需求文檔的正確的有意義數(shù)據(jù)。無效等價類則正相反。X. 判定表判定表的英文是 decision table ，是指一個表格，用于顯示條件和條件導(dǎo)致動作的集 合。定義： 判定表 是分析和表達多邏輯條件下執(zhí)行不同操作的情況的工具。判定表的優(yōu)點：能夠?qū)?fù)雜的問題按照各種可能的情況全部列舉出來，簡明并避免遺 漏。因此，利用判定表能夠設(shè)計出完整的 測試用例 集合。在一些數(shù)據(jù)處理問題當(dāng)中，某些操作的實施依賴于多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執(zhí)行不同的操作。判定表很適合于處理這類問題Y. 深度測試深度測試的英文 Depth test ，是指執(zhí)

38、行一個產(chǎn)品的一個特性的所有細節(jié)，但不測試所 有特性。當(dāng)比較函數(shù)返回真的時候才顯示出效果來。必須啟用 “#深度測試 ”，才能執(zhí)行測試。不 使用的時候需要關(guān)閉。Z. 基于設(shè)計基于設(shè)計的測試的英文是 design-based testing ，是根據(jù)軟件的構(gòu)架或 詳細設(shè)計 引出 測試用例 的一種方法。一種基于設(shè)計模型的測試方法 (Model Based TestIng System,MATIS).該方法利用用戶界面自動生成方法 ,把設(shè)計模型中的類屬性定義和實現(xiàn)中的控件屬性組織在一起,構(gòu)建描述界面的邏輯對照表 ,輔助 測試腳本 引擎執(zhí)行自動測試腳本 .借助設(shè)計模型中擴展的類定 義,MATIS 方法可以

39、自動生成測試用例和測試數(shù)據(jù)。AA. 文檔測試文檔測試的英文是 documentation testing ，測試關(guān)注于文檔的正確性。文檔測試 有三大類分別是開發(fā)文件、用戶文件、管理文件。1. 開發(fā)文件：可行性研究報告、 軟件需求說明書 、數(shù)據(jù)要求說明書、 概要設(shè)計說明 書、 詳細設(shè)計說明書 、數(shù)據(jù)庫設(shè)計 說明書、模塊開發(fā)卷宗。2. 用戶文件：用戶手冊、操作手冊。3. 管理文件：項目開發(fā)計劃、 測試計劃 、測試分析報告、開發(fā)進度月報、項目開發(fā)總 結(jié)報告。軟件測試中的文檔測試主要是對相關(guān)的設(shè)計報告和用戶使用說明進行測試，對于設(shè)計 報告主要是 測試程序 與設(shè)計報告中的設(shè)計思想是否一致；對于用戶使用說

40、明進行測試時，主要是測試用戶使用說明書中對程序操作方法的描述是否正確，重點是用戶使用說明中提 到的操作例子要進行測試，保證采用的例子能夠在程序中正確完成操作。一般來說，文檔是軟件的重要組成部分，因此 文檔測試 也是軟件測試的主要內(nèi)容。在 軟件的整個生命周期中會出現(xiàn)很多文檔，通?？梢园盐臋n粗略地分為三類：開發(fā)文檔,管理文檔和 用戶文檔 。由于文檔與代碼不同，不能直接運行，對于文檔的測試通常只能以文檔審查的方式進 行。對于管理文檔和審查通常歸屬于管理范疇，而不是軟件測試范疇,因為對于管理文檔審查的目的不是為了發(fā)現(xiàn)和消除用戶所看到的軟件中的缺陷，而是為了更好地管理軟件開發(fā) 的過程。對于開發(fā)文檔，由于

41、這些文檔本身體現(xiàn)了所在開發(fā)階段的軟件實際形態(tài)，對于這 些文檔的測試實際上是早期軟件測試的主要活動。用戶文檔是那些隨程序一起交付給用戶 的文檔 ,它們實際上是交付給用戶的軟件的重要組成部分。對于這些文檔的測試是對最終軟件產(chǎn)品測試 的一部分。BB. 域測試域測試的英文是 domain testing ，定義參考等價劃分測試( equivalence partition testing )；一般分為單 域測試 和多域測試，其中單域測試包括設(shè)備測試和業(yè)務(wù)測試，設(shè)備測試包 括測試某個系統(tǒng)的 軟交換 設(shè)備、中繼媒體網(wǎng)關(guān)設(shè)備、 信令網(wǎng)關(guān) 設(shè)備、接入媒體網(wǎng)關(guān)和 IAD 等設(shè)備。等價類劃分有兩種不同的情況：有效

42、等價類和 無效等價類 。設(shè)計時要同時考慮這兩種 等價類，因為軟件不僅要能接收合理的數(shù)據(jù)，也要能經(jīng)受意外的考驗。一有效等價類：是指對于程序的規(guī)格說明來說是合理的、有意義的輸入數(shù)據(jù)構(gòu)成的集 合。利用有效等價類可檢驗程序是否實現(xiàn)了規(guī)格說明中所規(guī)定的功能和性能。二無效等價類：與有效等價類的定義恰巧相反。CC. 接口測試接口測試的英文是 interface testing ，接口測試測試系統(tǒng)組件間接口的一種測試。接口測試 的好處：由于接口測試代碼本身就是用 junit (當(dāng)然接口的類型不同，不一定是 Junit 來實現(xiàn)) 來實現(xiàn)的，是屬于 自動化測試 的范疇，因此必定也包含自動化測試所固有的優(yōu)勢。1)

43、提高測試質(zhì)量軟件開發(fā)的過程是一個 持續(xù)集成 和改進的過程，而每一次的改進都可能引進新bug, 因此當(dāng)軟件的一部，或者全部修改時，都需要對軟件產(chǎn)品重新進行測試。其目的是要驗證修 改后的產(chǎn)品是符合需求的，而當(dāng)沒有自動化測試代碼時，往往會由于各種各樣的原因，回 歸不充分，導(dǎo)致 bug 遺漏。2) 提高測試效率 軟件系統(tǒng)的規(guī)模越來越大，功能點越來越多，開發(fā)人員的自測或者測試人員的人工測 試非常耗時和繁瑣，勢必導(dǎo)致測試效率的低下，而 自動化測試 正好解決這些耗時繁瑣的任 務(wù)，在對外接口功能不變的情況下，達到了一次編寫，永久使用的效果。3) 提高 測試覆蓋通過 手工測試 很難測試到一些更深層次的異常和安全

44、的問題，通過一些輔助的一些測 試工具，能分析出代碼的覆蓋率，通過覆蓋率的提高來提高測試的深度。4) 更好地重現(xiàn) 軟件缺陷由于每次執(zhí)行都是相同的代碼，一旦代碼出錯，必定回歸出錯5) 更好定位錯誤由于 接口測試 是一種自下向上的測試，因此一量出錯，非常容易定位出錯，不向 系統(tǒng) 測試 那樣了，一旦有 Bug ，需要幾層驗證之后才能確定出錯位置6) 降低修改 bug 的成本接口測試基本和開發(fā)人員的編碼平行工作，因此發(fā)現(xiàn)問題會 比系統(tǒng)測試早很多，因此減少了修改 bug 的成本。7) 增進測試人員和開發(fā)人員之間的合作關(guān)系，測試工程師 為了更好地開展工作，需要對開發(fā)技術(shù)有深入的理解和實踐，有了與開發(fā)工程師更

45、多的交流。8) 降低了項目不能按時發(fā)布的風(fēng)險由于接口測試很早就介入，在提交給系統(tǒng)測試前 對項目代碼的核心模塊已經(jīng)做了詳盡的測試，必定加速系統(tǒng)測試的時間，由此來保證項目 的按時發(fā)布。9) 提升測試人員的技能。做 接口測試 必須了解開發(fā)人員的開發(fā)流程和一些開發(fā)技 能，也需要了解測試工具的一些使用方法和一些測試思想，提升了測試人員的技術(shù)附加 值，提高了自身的競爭力。10) 促使項目開發(fā)過程的規(guī)范化要進行接口，需要完善的文檔進行保障，沒有測試文檔，接口測試將寸步難行，接口 測試將增加開發(fā)過程規(guī)范化產(chǎn)出，而規(guī)范化產(chǎn)出也保證了項目質(zhì)量。DD. 逆向測試逆向測試 /反向測試 / 負(fù)面測試 的英文是 Nega

46、tive Testing ，測試瞄準(zhǔn)于使系統(tǒng)不能工 作。負(fù)面測試與正面測試的比較：負(fù)面測試( Negative testing )是相對于正面測試( Positive testing )而言的。它們也 是測試設(shè)計時的兩個非常重要的劃分。簡單點說，正面測試就是測試系統(tǒng)是否完成了它應(yīng) 該完成的工作；而負(fù)面測試就是測試系統(tǒng)是否不執(zhí)行它不應(yīng)該完成的操作。形象一點，正 面測試就象一個畢恭畢敬的小學(xué)生，老師叫我做什么，我就做什么；而負(fù)面測試就象一個 調(diào)皮搗蛋的孩子，你叫我這樣做，我偏不這樣做，而且和你對著干。開發(fā)人員也是最討厭 修改此類 bug 的。EE. 非功能性非功能性需求測試的英文是 non-fun

47、ctional requirements testing ，是與功能不相關(guān)的 需求測試，如： 性能測試 、可用性測試等。為什么非功能性需求很重要？在您設(shè)計解決方案的過程中滿足功能性需求當(dāng)然是很重要的。但是，如果沒有考慮非 功能性需求，您的解決方案則很難取得實效。非功能性需求特點： 1.不要脫離實際環(huán)境； 2. 可靠性； 3.可用性； 4.有效性； 5.可維護 性； 6.可移植性。FF. 極限測試簡介極限測試本質(zhì)上是為了滿足極限測試的思想和流程而設(shè)計的一套測試策略和流程,其本身并不局限于使用特定的測試技術(shù)和方法。III. 軟件測試的基本流程測試需求分析，測試計劃編寫，測試用例編寫，測試，缺陷記錄

48、，回歸測試，判斷測 試結(jié)束，測試報告提交。測試流程依次如下：一：單元測試、集成測試、系統(tǒng)測試和驗收測試（確認(rèn)測1. 需求：閱讀需求， 試）；理解需求，與客戶、開發(fā)、架構(gòu)多方交流，深入了解需求。 -testing team2. 測試計劃 : 根據(jù)需求估算測試所需資源（人力、設(shè)備等）、所需時間、功 能點劃分、如何合理分配安排資源等。 -testing leader or testing manager3. 用例設(shè)計：根據(jù)測試計劃、任務(wù)分配、功能點劃分，設(shè)計合理的測試用 例。 -testing leader, senior tester4. 執(zhí)行測試：根據(jù)測試用例的詳細步驟，執(zhí)行測試用例。 -eve

49、ry tester（ 主 要是初級測試人員 ）5. 執(zhí)行結(jié)果記錄和 bug 記錄：對每個 case 記錄測試的結(jié)果，有 bug 的在測試 管理工具中編寫 bug 記錄。 -every tester（ 主要是初級測試人員 ）6. defect tracking：追蹤 leader 分配給你追蹤的 bug.直到 bug fixed 。-every tester7. 測試報告：通過不斷測試、追蹤，直到被測軟件達到測試需求要求，并沒 有重大 bug.8. 用戶體驗、軟件發(fā)布等 IV. 什么是缺陷一切不滿足用戶需求的都是缺陷 。 下面我們對缺陷的概念在詳細的介紹一下。1、軟件未達到產(chǎn)品說明書標(biāo)明的功能。

50、2、軟件出現(xiàn)了產(chǎn)品說明書中指明不會出現(xiàn)的錯誤。3、軟件功能超出了產(chǎn)品說明書指明的范圍。4、軟件未達到產(chǎn)品說明書中雖未指出但應(yīng)達到的目標(biāo)。5、軟件 測試 員認(rèn)為軟件難以理解、不易使用、運行速度緩慢，或最終用戶認(rèn)為不好。 關(guān)于這 5 點我們舉例來說明一下。第一點，比如說我們開發(fā)一個記事本的軟件，說明書中 明確說了可以輸入文字，結(jié)果開發(fā)的軟件不具備輸入文本的功能，肯定就是一個 defect 了。第二點，說明書中明確說了在記事本軟件中輸入 “聯(lián)通 ”可以正確的保存并打開瀏覽， 結(jié)果我們的記事本軟件打開保存了的輸入 “聯(lián)通”的文件出 現(xiàn)了亂 碼，這也是一個 defect 了。第三點，比如說我們的說明書中沒有定義記事本會自動的 對關(guān)鍵字高亮顯示(這個主要是針對編程語言)，結(jié)果我們的記事本 程序自動對關(guān)鍵字高亮顯示了，這也是 defect ，盡管這樣對用戶使用 會更好，但是他超出了產(chǎn)品說明書中指明的功能范圍，所以還是 defect 。第四點 不太好說，所以就不用記事本舉例了，原諒我，呵 呵。比如在我國開發(fā)財務(wù)管理軟件必須要符合財政部的規(guī)定，盡管說 明書中一般不