軟件測試技術(shù)高職PPT完整全套教學(xué)課件

軟件測試技術(shù)

全套可編輯PPT課件本書目錄第1章軟件測試概述第2章軟件測試流程和過程模型第3章軟件測試計(jì)劃第4章測試用例概述第5章高效設(shè)計(jì)測試用例第6章軟件缺陷報(bào)告第7章軟件測試報(bào)告第8章易用性測試第9章Web測試第10章測試人員的職業(yè)能力和技術(shù)支持第1章軟件測試概述1.1軟件測試介紹1.1.1軟件測試的概念1.1.2軟件測試的目的1.1.3軟件測試的重要性1.1.4軟件質(zhì)量保證和軟件測試的區(qū)別1.2軟件測試技術(shù)分類1.3常見的軟件測試工具軟件的概念軟件是計(jì)算機(jī)系統(tǒng)中與硬件相互依存的一部分，它是包括程序、數(shù)據(jù)以及相關(guān)文檔的完整集合軟件=程序+數(shù)據(jù)+文檔軟件測試的概念1983年，IEEE對測試的定義：使用人工或自動的手段來運(yùn)行或測定某個系統(tǒng)的過程，其目的是在于檢驗(yàn)它是否滿足規(guī)定的需求或是弄清楚預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別。GB/T對軟件測試進(jìn)行了新的定義：依據(jù)規(guī)范的軟件檢測過程和檢測方法，按照測試計(jì)劃和測試需求對被檢測軟件的文檔、程序和數(shù)據(jù)進(jìn)行測試的技術(shù)活動。不同時期的關(guān)于軟件測試的定義確信程序做了它應(yīng)該做的事（Hetzel，1973年）。為找出錯誤而運(yùn)行程序或系統(tǒng)的過程（Myers，1979年）。查出規(guī)格說明中的錯誤，以及與規(guī)格說明不符的地方。一切以評價程序或系統(tǒng)的屬性、能力為目的的活動（Hetzel，1983年）。對軟件質(zhì)量的度量（Hetzel，1983年）。評價程序或系統(tǒng)的過程。驗(yàn)證系統(tǒng)滿足需求，或確定實(shí)際結(jié)果與預(yù)期結(jié)果之間的區(qū)別。確認(rèn)程序正確實(shí)現(xiàn)了所要求的功能。測試是與軟件開發(fā)或維護(hù)工作并行進(jìn)行的一個過程。是在用戶需求和開發(fā)技術(shù)之間找一個平衡點(diǎn)。GB/T

15532-2008軟件測試的目的驗(yàn)證軟件是否滿足軟件開發(fā)合同或項(xiàng)目開發(fā)計(jì)劃、系統(tǒng)設(shè)計(jì)文檔、軟件需求規(guī)格說明、軟件設(shè)計(jì)說明和軟件產(chǎn)品說明等規(guī)定的軟件質(zhì)量要求。通過測試，發(fā)現(xiàn)缺陷。為軟件產(chǎn)品的質(zhì)量測量和評價提供依據(jù)。軟件測試至少要達(dá)到下列目標(biāo)確保產(chǎn)品完成了它所承諾或公布的功能確保產(chǎn)品滿足性能和效率的要求確保產(chǎn)品是健壯的，適應(yīng)用戶環(huán)境的軟件測試的重要性第一、軟件測試可以減少軟件的不正確執(zhí)行導(dǎo)致的資金、時間和商業(yè)信譽(yù)的損失，甚至能減少人員傷亡風(fēng)險(xiǎn)。人類歷史上第一次真正意識到軟件缺陷的存在的案例其他不完全案例放射性治療儀軟件測試的重要性其他不完全案例12306訂票網(wǎng)站癱瘓迪斯尼的獅子王游戲京東積分兌換話費(fèi)2008年奧運(yùn)訂票網(wǎng)站癱瘓溫州動車追尾事故軟件測試的重要性第二、軟件測試可以降低軟件開發(fā)成本，強(qiáng)化項(xiàng)目進(jìn)度和質(zhì)量上的控制。有調(diào)查顯示，通過必要的測試，軟件缺陷可以減少75%，而軟件的投資回報(bào)率則可增長到350%。第三、軟件測試的發(fā)展推動了軟件工程的發(fā)展，通過分析在若干項(xiàng)目中發(fā)現(xiàn)的缺陷和引起缺陷的根本原因，我們就可以改進(jìn)軟件開發(fā)過程。過程的改進(jìn)又可以預(yù)防相同的缺陷再次發(fā)生，從而提高以后系統(tǒng)的質(zhì)量。軟件質(zhì)量保證的概念軟件質(zhì)量保證（SoftwareQualityAssurance,SQA）是一種有計(jì)劃的、貫穿于產(chǎn)品生命周期的質(zhì)量管理方法。目的是提供一種有效的人員組織形式和管理方法，通過客觀地檢查和監(jiān)控“過程質(zhì)量”與“產(chǎn)品質(zhì)量”，從而實(shí)現(xiàn)持續(xù)地改進(jìn)質(zhì)量。軟件測試是軟件質(zhì)量保證的一部分。軟件質(zhì)量保證和軟件測試的區(qū)別角色差別。軟件質(zhì)量保證人員的主要職責(zé)是創(chuàng)建和加強(qiáng)促進(jìn)軟件開發(fā)并防止軟件缺陷的標(biāo)準(zhǔn)和方法。軟件測試工程師的目標(biāo)是在最短的時間內(nèi)發(fā)現(xiàn)盡可能多的缺陷，并確保這些缺陷得以修復(fù)。質(zhì)量保證側(cè)重于事前預(yù)防，而軟件測試側(cè)重于事后檢測；質(zhì)量保證要管理和控制軟件開發(fā)流程的各個過程，軟件測試只能保證盡量暴露軟件的缺陷。1.2軟件測試技術(shù)分類1.1軟件測試介紹1.2軟件測試技術(shù)分類1.2.1黑盒測試和白盒測試1.2.2手工測試和自動化測試1.2.3V模型的測試級別1.2.4功能和非功能測試1.2.5靜態(tài)和動態(tài)測試1.2.6其他測試術(shù)語1.3常見的軟件測試工具按是否查看程序內(nèi)部代碼結(jié)構(gòu)劃分黑盒測試（Black-boxTesting）黑盒測試又稱數(shù)據(jù)驅(qū)動測試或基于規(guī)格說明書的測試。白盒測試（White-boxTesting）白盒測試只能在單元測試階段使用，黑盒測試只能在系統(tǒng)測試階段使用。按測試的執(zhí)行方式劃分手工測試（ManualTesting）利用人工的方式去執(zhí)行測試，由人一個一個的輸入用例數(shù)據(jù)，然后觀察結(jié)果，和自動化測試相對應(yīng)，屬于最基本的測試方法自動化測試（AutomaticTesting）自動化測試是利用工具或程序來代替人工的測試方法。按測試的執(zhí)行方式劃分自動化測試的優(yōu)缺點(diǎn)按照V模型的測試級別劃分單元測試（unittesting）對軟件中最小可測試單元進(jìn)行檢查和驗(yàn)證，如一個模塊、一個過程等等。它的目的是檢驗(yàn)軟件基本組成單元的正確性。樁（Stub）驅(qū)動器（Driver）單元測試人員：需要具備一些測試知識，比如開發(fā)編碼技能，基本的測試技能，還要會部分單元測試工具的使用等；缺點(diǎn)：一些接口問題和大環(huán)境的缺陷在該階段無法發(fā)現(xiàn)。按照V模型的測試級別劃分集成測試（integrationtesting）通過測試的單元模塊組裝成系統(tǒng)或子系統(tǒng)再進(jìn)行測試，目的是檢查軟件單元之間的接口是否正確。自底向上的集成

自頂向下的集成集成測試人員：需要具備開發(fā)技能、具備有關(guān)組件間的交互知識，還要具備一些測試基礎(chǔ)技能。缺點(diǎn)：組件外的缺陷，還有程序?qū)φ麄€系統(tǒng)的需求不滿足，這樣的缺陷，測試不出來。按照V模型的測試級別劃分系統(tǒng)測試（systemtesting）將整個軟件系統(tǒng)全部集成好之后作為一個整體進(jìn)行測試，以驗(yàn)證軟件系統(tǒng)的正確性和性能是否滿足規(guī)約所指定的要求。測試人員：需要具備測試技術(shù)、熟悉軟件系統(tǒng)的需求，還有性能測試知識和工具的使用。缺點(diǎn)：它發(fā)現(xiàn)的是非功能性缺陷、概念性缺陷、設(shè)計(jì)整個系統(tǒng)的缺陷，但是可能會遺漏一些缺陷，比如如果對用戶需求的理解存在錯誤，沒有實(shí)現(xiàn)或者沒有完全實(shí)現(xiàn)用戶的隱性需求，在系統(tǒng)測試中無法發(fā)現(xiàn)。按照V模型的測試級別劃分驗(yàn)收測試（acceptancetesting）根據(jù)用戶需求、業(yè)務(wù)流程進(jìn)行的正式測試以確保系統(tǒng)符合所有驗(yàn)收準(zhǔn)則。按照V模型的測試級別劃分α測試有用戶在開發(fā)環(huán)境下進(jìn)行的測試，也可以是公司內(nèi)部的用戶在模擬實(shí)際操作環(huán)境下進(jìn)行的測試，試圖發(fā)現(xiàn)錯誤并修正。α測試的關(guān)鍵在于盡可能逼真的模擬實(shí)際運(yùn)行環(huán)境、用戶對軟件產(chǎn)品的操作要盡可能涵蓋所有可能的用戶的操作方式。β測試經(jīng)過α測試的軟件稱為β版本。Β測試是由最終用戶們在客戶場所進(jìn)行的測試。與α不同的是，開發(fā)者通常不在現(xiàn)場。驗(yàn)收測試用戶驗(yàn)收測試運(yùn)行驗(yàn)收測試合同和法規(guī)性驗(yàn)收測試Α和β測試按測試目標(biāo)的不同劃分功能測試（FunctionalTesting/BehavioralTesting）功能測試就是指系統(tǒng)能做什么。功能測試是一個試圖發(fā)現(xiàn)程序與其外部規(guī)格說明之間存在不一致的過程非功能測試性能測試（performancetesting）通過工具模擬多種正常、峰值以及異常負(fù)載條件來對系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測試。（比如：處理速度、響應(yīng)時間、CPU使用、內(nèi)存使用情況等）負(fù)載測試(Functiontesting)確定在各種工作負(fù)載下系統(tǒng)的性能，目標(biāo)是測試當(dāng)負(fù)載逐漸增加時，系統(tǒng)各項(xiàng)性能指標(biāo)的變化情況。壓力測試(Securitytesting)在規(guī)定的或超過規(guī)定的需求條件下測試組件/系統(tǒng)，以對其進(jìn)行評估。它是為了評價一個系統(tǒng)或組件達(dá)到或超過需求規(guī)定的界限時的反應(yīng)的測試。可以檢查系統(tǒng)在超負(fù)荷的情況的性能反應(yīng)。按測試目標(biāo)的不同劃分非功能測試可靠性測試（ReliabilityTesting）是度量軟件如何在主流情形下和非預(yù)期情況下維持它的功能，有時也包括軟件出錯時的自恢復(fù)能力?？捎眯裕ㄒ子眯裕y試（UsabilityTesting）是用戶學(xué)習(xí)和控制軟件以達(dá)到用戶需求的容易程度?？删S護(hù)性測試（MaintainabilityTesting）描述的是修改軟件而不引入新缺陷所需要的工作量?？梢浦残詼y試（PortabilityTesting)指一種計(jì)算機(jī)上的軟件裝置到其他計(jì)算機(jī)上的能力。兼容性測試（CompatibilityTesting軟件之間是否能夠正確地交互和共享信息。例如，不同的瀏覽器在圖片的顯示、HTML語言的解釋上有細(xì)微的差異，可能導(dǎo)致應(yīng)用程序的錯誤。配置測試（ConfigurationTesting）使用各種硬件來測試軟件運(yùn)行的過程。基于標(biāo)準(zhǔn)Windows的PC機(jī)有很多配置的可能性，比如：PC機(jī)、模塊化部件、外部設(shè)備、接口、可選項(xiàng)和內(nèi)存、設(shè)備驅(qū)動程序等。按測試目標(biāo)的不同劃分非功能測試安全性測試（SecurityTesting）檢查系統(tǒng)對非法侵入的防范能力。本地化測試（LocalizabilityTesting）指測試特定目標(biāo)區(qū)域設(shè)置的軟件本地化質(zhì)量。按是否需要運(yùn)行程序劃分靜態(tài)測試（statictesting）：不運(yùn)行被測軟件，只是靜態(tài)地檢查程序代碼、界面或文檔可能存在的錯誤的過程。動態(tài)測試（dynamictesting）實(shí)際運(yùn)行被測程序，輸入相應(yīng)的測試數(shù)據(jù)，檢查輸出結(jié)果和預(yù)期結(jié)果是否相符的過程其他測試術(shù)語確認(rèn)測試（confirmtesting）重新執(zhí)行上次失敗的測試用例，以驗(yàn)證是否已經(jīng)修復(fù)回歸測試（regressiontesting）對軟件進(jìn)行修改之后進(jìn)行的測試，目的是檢驗(yàn)對軟件進(jìn)行的修改是否正確。冒煙測試（smokingtesting）對一個新版本進(jìn)行大規(guī)模測試之前，先驗(yàn)證一下軟件的基本功能是否實(shí)現(xiàn)。隨機(jī)測試（Ad-hoctesting）臨時準(zhǔn)備的、隨機(jī)的缺陷搜索的測試過程。不按照用例進(jìn)行測試，發(fā)揮想象，模擬用戶的真實(shí)操作。常見考點(diǎn)什么是黑盒測試？什么是白盒測試？自動化測試的優(yōu)缺點(diǎn)阿爾法測試和貝塔測試的區(qū)別壓力測試和負(fù)責(zé)測試的區(qū)別V模型測試級別有哪些？1.3常見的軟件測試工具1.1軟件測試介紹1.2軟件測試技術(shù)分類1.3常見的軟件測試工具1.3.1功能自動化測試工具1.3.2性能自動化測試工具1.3.3測試管理工具1.3.1功能自動化測試工具UFT（UnifiedFunctionalTesting）MicroFocus公司，bs架構(gòu)，錄制回放的方式，VBSeleniumThoughtWorks公司專門為web應(yīng)用而開發(fā)的自動化測試工具。開源+代碼基礎(chǔ)WinRunnerMercury公司的一款企業(yè)級自動化功能測試工具。可以對復(fù)雜的企業(yè)級應(yīng)用的不同發(fā)布版本進(jìn)行測試。SilkTestSegue

Software開發(fā)，2006年被Borland公司收購，面向web、Java應(yīng)用和傳統(tǒng)的CS應(yīng)用的一款自動化測試工具。1.3.2性能自動化測試工具LoadRunner適用于各種體系架構(gòu)，支持廣泛的協(xié)議和技術(shù)，為特殊環(huán)境提供特殊的解決方案JmeterApache組織的開源，是接口測試和性能測試的綜合體，而且小巧；WebLOADRadview公司推出的性能測試和分析工具。通過模擬真實(shí)操作生成壓力負(fù)載來測試web的性能。WAS（WebApplicationStressTool）微軟開發(fā)的，專門用來進(jìn)行實(shí)際網(wǎng)站壓力測試的一套工具。測試管理工具QC管理測試需求、測試計(jì)劃、測試用例、測試執(zhí)行、測試結(jié)果、缺陷跟蹤BugFree借鑒微軟的開發(fā)流程和Bug管理理念，使用PHP+MySQL獨(dú)立寫出的一個Bug管理系統(tǒng)。開源，簡單，實(shí)用。禪道開源，國產(chǎn)-青島易軟天創(chuàng)公司研發(fā)的將產(chǎn)品管理、項(xiàng)目管理、質(zhì)量管理三個核心流程融合在一起核心管理思想是基于Scrum。測試工具的選擇要遵循以下幾個原則：只買對的，不買貴的。選擇主流測試工具。分階段、初步引入測試工具。選擇技術(shù)支持完善的產(chǎn)品。如果需要多種測試工具，盡量選擇同一家公司的產(chǎn)品。練習(xí)題目一、單選題（1）下列關(guān)于軟件測試的說法中正確的是（）A．使用人工或自動的手段來運(yùn)行或預(yù)測某個系統(tǒng)的過程，其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或弄清楚預(yù)期結(jié)果和實(shí)際結(jié)果之間的差距。B．軟件測試是用來證明軟件中不存在錯誤。C．軟件測試只能采用手工測試。D．軟件測試可以只采用自動化測試。（2）關(guān)于QA的說法正確的是（）。A．QA是質(zhì)量保證 B．QA是質(zhì)量控制C．QA是測試控制 D．QA是軟件控制二、多選題（1）軟件包括以下哪幾個部分？（）A．程序

B．?dāng)?shù)據(jù)

C．文檔 D．包裝練習(xí)題目（2）以下關(guān)于軟件測試目的的說法中正確的是（）。A．確保產(chǎn)品完成了它所承諾或公布的功能。B．確保產(chǎn)品滿足性能和效率的要求。C．確保產(chǎn)品是健壯的、適應(yīng)用戶環(huán)境的。D．確保軟件當(dāng)中沒有缺陷。（3）關(guān)于QA和軟件測試的說法正確的是（ ）A. QA人員的主要職責(zé)是創(chuàng)建和加強(qiáng)促進(jìn)軟件開發(fā)并防止軟件缺陷的標(biāo)準(zhǔn)和方法。B. 軟件測試工程師的目標(biāo)是在最短的時間內(nèi)發(fā)現(xiàn)盡可能多的缺陷。C. QA側(cè)重于對軟件開發(fā)流程的管理和控制，杜絕軟件缺陷的產(chǎn)生。軟件測試是事后檢查，智能保證盡量暴露軟件的缺陷。（4）V模型的測試級別包括（）。A．需求分析 B．集成測試 C．系統(tǒng)測試

D．驗(yàn)收測試練習(xí)題目（5）以下關(guān)于白盒測試與黑盒測試的說法中正確的是（）。A．白盒測試只能在單元測試階段使用，黑盒測試只能在系統(tǒng)測試階段使用。B．黑盒測試又稱數(shù)據(jù)驅(qū)動測試或基于規(guī)格說明書的測試。C．白盒測試是對程序內(nèi)部邏輯結(jié)構(gòu)的測試，黑盒測試是對系統(tǒng)需求方面的測試。D．白盒測試的優(yōu)點(diǎn)是能夠定位系統(tǒng)需求的缺陷。（6）自動化測試的優(yōu)點(diǎn)有哪些？請從以下選項(xiàng)中選出（）。A．可以節(jié)省測試時間 B．可以處理精確的事務(wù)

C．可以處理大數(shù)據(jù)事務(wù)

D．自動化工具可以代替手工測試（7）驗(yàn)收測試包括哪幾種典型類型（）。（多選題）A．運(yùn)行（驗(yàn)收）測試 B．合同或法規(guī)性驗(yàn)收測試

C．α測試

D．β測試（8）以下屬于性能自動化測試工具的是（）。A．LoadRunner B．JMeter C．UFT D．Selenium練習(xí)題目三、判斷題（1）軟件測試只是軟件質(zhì)量保證的一個重要的手段，它只能盡量暴露軟件中的缺陷。（）（2）回歸測試包含確認(rèn)測試。（

）（3）配置測試指軟件之間能否正確地交互和共享信息的測試。兼容性測試是指使用各種硬件來測試軟件運(yùn)行的過程。（

）下節(jié)更精彩軟件測試技術(shù)

本書目錄第1章軟件測試概述第2章軟件測試流程和過程模型第3章軟件測試計(jì)劃第4章測試用例概述第5章高效設(shè)計(jì)測試用例第6章軟件缺陷報(bào)告第7章軟件測試報(bào)告第8章易用性測試第9章Web測試第10章測試人員的職業(yè)能力和技術(shù)支持第2章軟件測試流程和過程模型2.1軟件測試流程2.2軟件測試過程模型2.3軟件測試原則2.1軟件測試流程2.1.1測試需求分析2.1.2測試計(jì)劃制定2.1.3測試用例設(shè)計(jì)2.1.4測試環(huán)境搭建2.1.5測試數(shù)據(jù)準(zhǔn)備2.1.6測試執(zhí)行及缺陷處理2.1.7測試總結(jié)報(bào)告2.1.8測試文件歸檔2.1.1軟件需求分析dongling2.1.2軟件測試計(jì)劃制定dongling2.1.3軟件測試用例設(shè)計(jì)dongling2.1.4軟件測試環(huán)境搭建軟件測試環(huán)境是指為了完成軟件測試工作所必須的計(jì)算機(jī)硬件、軟件、網(wǎng)絡(luò)設(shè)備、歷史數(shù)據(jù)的總稱。測試環(huán)境要與開發(fā)環(huán)境分開。2.1.4軟件測試環(huán)境搭建大數(shù)據(jù)的特點(diǎn)：數(shù)據(jù)規(guī)模大、數(shù)據(jù)多樣、計(jì)算復(fù)雜度高、分布式結(jié)構(gòu)等；需要考慮？根據(jù)對大數(shù)據(jù)所測場景的不同，所需要的測試環(huán)境有不同：如果是大數(shù)據(jù)新業(yè)務(wù)上線前對系統(tǒng)功能做驗(yàn)證測試，通常需要構(gòu)造單獨(dú)的類生產(chǎn)的迷你測試環(huán)境；如果是測試實(shí)時數(shù)據(jù)處理業(yè)務(wù)或是做系統(tǒng)組件的升級測試，則可以按照系統(tǒng)生產(chǎn)環(huán)境進(jìn)行等比例縮放；如果是測試重要業(yè)務(wù)功能或是做性能測試，則需要直接在生產(chǎn)環(huán)境上進(jìn)行測試。2.1.5測試數(shù)據(jù)準(zhǔn)備Datagenerator、databenerator、Testgen、datatect、turbodata自建腳本：Ruby、Python、Fit、FitNesse、Shell腳本傳統(tǒng)的創(chuàng)建測試數(shù)據(jù)的方法手動創(chuàng)建自動化創(chuàng)建手動模擬用戶實(shí)際操作來創(chuàng)建重要業(yè)務(wù)流程的測試數(shù)據(jù)；通過SQL語句中where和update方法來修改數(shù)據(jù)庫數(shù)據(jù)；導(dǎo)入本地機(jī)器上存儲的一些符合條件的測試數(shù)據(jù)；導(dǎo)入并加工線上數(shù)據(jù)變成測試數(shù)據(jù)。大數(shù)據(jù)測試數(shù)據(jù)準(zhǔn)備5V大規(guī)模Volume類型多樣Variety產(chǎn)生速度快Velocity商業(yè)價值高Value數(shù)據(jù)真實(shí)Veracity大數(shù)據(jù)測試數(shù)據(jù)準(zhǔn)備大數(shù)據(jù)數(shù)據(jù)獲取常用的通過網(wǎng)絡(luò)爬蟲爬取免費(fèi)數(shù)據(jù)向一些數(shù)據(jù)機(jī)構(gòu)購買有價值的數(shù)據(jù)共享合作公司提供的數(shù)據(jù)使用自己公司的自有數(shù)據(jù)。大數(shù)據(jù)測試數(shù)據(jù)準(zhǔn)備使用自己公司的自有數(shù)據(jù)（可以直接使用真實(shí)數(shù)據(jù)，也可以按照某種算法構(gòu)造）（1）真實(shí)數(shù)據(jù)引流：（2）真實(shí)環(huán)境數(shù)據(jù)復(fù)制（3）構(gòu)造數(shù)據(jù)大數(shù)據(jù)測試數(shù)據(jù)的預(yù)處理數(shù)據(jù)預(yù)處理是一種數(shù)據(jù)挖掘技術(shù)，本質(zhì)就是為了把原始數(shù)據(jù)轉(zhuǎn)換為可以理解的格式或者符合我們挖掘的格式。為什么要進(jìn)行預(yù)處理？數(shù)據(jù)可能是不完整的，缺少某些屬性值；高緯度，數(shù)據(jù)的屬性或字段太多；數(shù)據(jù)可能存在重復(fù)；數(shù)據(jù)可能會有由于包含代碼或者名稱的差異導(dǎo)致跟實(shí)際需要的數(shù)據(jù)不一致；可能含噪聲。即數(shù)據(jù)中存在著錯誤或異常數(shù)據(jù)。2.1.6測試執(zhí)行及缺陷處理2.1.7軟件測試報(bào)告2.1.8測試文件歸檔SVNVSSGitFTPWiki軟件測試流程總結(jié)P(Plan)D(Design)C(4C管理）A（2A）目標(biāo)Goal實(shí)施計(jì)劃Plan收支預(yù)算Budget設(shè)計(jì)方案和布局Check檢查Communicate溝通Clean清理Control控制Act執(zhí)行，對總結(jié)檢查的結(jié)果進(jìn)行處理Aim，按照目標(biāo)要求行事，如改善、提高軟件測試流程總結(jié)PDCA循環(huán)：（1）大的測試流程中：制定好測試計(jì)劃、執(zhí)行測試、通過測試結(jié)果來檢查測試計(jì)劃制定的合理性，然后分析計(jì)劃偏離的原因，再把總結(jié)出來的經(jīng)驗(yàn)用于指導(dǎo)下一次測試的計(jì)劃，這樣就形成了一個PDCA循環(huán)過程。（2）提交一個缺陷也可以應(yīng)用PDCA循環(huán)，先寫下來，再檢查，然后提交審核，對提出的意見進(jìn)行分析，總結(jié)寫的不好的地方，把總結(jié)的經(jīng)驗(yàn)用于指導(dǎo)下一次報(bào)告的編寫，這樣的過程同樣是一個PDCA。（3）編寫測試用例也是一個PDCA，選擇好測試用例的編寫方法，開始設(shè)計(jì)測試用例，然后通過評審來發(fā)現(xiàn)更多問題，或者通過執(zhí)行測試用例來發(fā)現(xiàn)bug，再根據(jù)執(zhí)行的情況和bug的情況來分析測試用例的有效性，把這些總結(jié)出來的經(jīng)驗(yàn)用于指導(dǎo)下一次的測試用例設(shè)計(jì)。這也是一個PDCA循環(huán)。2.2軟件測試過程模型軟件開發(fā)過程模型：軟件開發(fā)全部過程、活動和任務(wù)的結(jié)構(gòu)框架。是無數(shù)前輩們通過無數(shù)項(xiàng)目總結(jié)出來的軟件開發(fā)的全過程，從而沉淀下來的固有模型，是前人智慧的結(jié)晶。大爆炸模型編寫邊改模型瀑布模型原型模型增量模型Scrum2.2軟件測試過程模型軟件測試專家也通過實(shí)踐總結(jié)了很多過程模型V模型W模型H模型2.2.1V模型2.2.1V模型V模型是最具有代表意義的測試模型。V模型最早由PaulRook在20世紀(jì)80年代后期提出。V模型是軟件開發(fā)瀑布模型的變種。V模型的推出就是對此認(rèn)識的改進(jìn)，它反映了測試活動與分析、設(shè)計(jì)、開發(fā)的關(guān)系，從左到右，描述了基本的開發(fā)過程和測試行為，非常明確地表明了測試過程中存在不同的測試級別，并且清楚地描述了這些測試階段和開發(fā)過程各階段的對應(yīng)關(guān)系。V模型的局限性：它僅僅把測試作為在編碼之后的一個階段，是針對程序進(jìn)行的尋找錯誤的活動，而忽視了測試活動對需求分析、系統(tǒng)設(shè)計(jì)等活動的驗(yàn)證和確認(rèn)功能2.2.2W模型2.2.2W模型W模型又叫雙v模型。W模型是由Evolutif公司提出的。它強(qiáng)調(diào)軟件測試伴隨著整個軟件開發(fā)周期，而且測試的對象不僅僅是程序，還包括需求、設(shè)計(jì)以及開發(fā)輸出的文檔。W模型也是有局限性的。最大的局限性就是無法支持迭代。2.2.3H模型在H模型中，軟件測試模型是一個獨(dú)立的流程，貫穿于整個產(chǎn)品周期，與其他流程并發(fā)地進(jìn)行。當(dāng)某個測試條件就緒時，軟件測試即從測試準(zhǔn)備階段進(jìn)入執(zhí)行階段。軟件測試不僅僅指測試的執(zhí)行，還有測試準(zhǔn)備工作；2.2.3H模型概括地說，H模型揭示了：（1）軟件測試不僅僅指測試的執(zhí)行，還包括測試準(zhǔn)備工作。（2）軟件測試是一個獨(dú)立的流程，貫穿產(chǎn)品整個生命周期，與其他流程并發(fā)地進(jìn)行。（3）軟件測試要盡早準(zhǔn)備，盡早執(zhí)行。（4）軟件測試是根據(jù)被測物的不同而分層次進(jìn)行的，支持被測物的多次迭代。三種模型的綜合運(yùn)用在實(shí)際工作中，不能為了使用模型而使用模型，要靈活運(yùn)用各種模型的優(yōu)點(diǎn)，取其精華，去其糟粕。例如可以在W模型的框架下，運(yùn)用H模型的思想進(jìn)行獨(dú)立測試，并同時將測試和開發(fā)緊密結(jié)合，尋找恰當(dāng)?shù)木途w點(diǎn)開始測試并反復(fù)迭代測試，最終保證按期完成預(yù)定目標(biāo)。常見考題請列出V模型的各個環(huán)節(jié)請說出V模型/W模型/H模型的優(yōu)缺點(diǎn)？2.3軟件測試的原則（1）所有的測試都應(yīng)該追溯到用戶需求軟件測試的目的是尋找實(shí)際結(jié)果和預(yù)期結(jié)果之間的差異。從用戶角度來看，最嚴(yán)重的錯誤就是那些導(dǎo)致程序無法滿足需求的錯誤。如果系統(tǒng)不能完成客戶的需求和期望，那么，這個系統(tǒng)的研發(fā)是失敗的。通常，所有的測試都是依據(jù)用戶需求來進(jìn)行的，一旦在測試過程中發(fā)生爭執(zhí)，所有問題的解決都要依據(jù)需求說明中的規(guī)定，追溯用戶需求。（2）盡早開展軟件測試工作軟件項(xiàng)目中40%~60%的問題都是需求分析階段埋下的“禍根”（Leffingwell1997）。而軟件項(xiàng)目在軟件生命周期的各個階段都可能產(chǎn)生錯誤。實(shí)踐證明，缺陷發(fā)現(xiàn)的越早，修改缺陷的成本越低。隨著時間的推移，修復(fù)軟件缺陷的費(fèi)用在成倍的增長，在維護(hù)階段發(fā)現(xiàn)缺陷修復(fù)成本甚至是在需求階段的200倍2.3軟件測試的原則（3）軟件測試中的Pareto法則軟件測試發(fā)現(xiàn)的80%的錯誤很可能起源于20%的程序模塊。也可以表示，在分析、設(shè)計(jì)、實(shí)現(xiàn)階段的復(fù)審和測試工作能夠發(fā)現(xiàn)和避免80%的缺陷，而系統(tǒng)測試又能找出其余缺陷的80%（其余20%的80%），最后4%的軟件缺陷可能只有在用戶大范圍、長時間使用后才會暴露出來2.3軟件測試的原則（4）程序員應(yīng)該盡量避免測試自己編寫的程序并不是測試自己的程序不可能，而是讓獨(dú)立的第三方來測試會更客觀、有效，并容易取得成功；不愿意否定自己的工作的心里。需求理解錯誤的缺陷無法找出來。（5）窮盡測試是不可能的即使是功能很簡單的程序，輸入的組合數(shù)量也非常龐大（6）軟件測試是有風(fēng)險(xiǎn)的因?yàn)楦F盡測試不可能，所以遺漏缺陷的可能性就存在。（7）Good-Enough原則既不要做過多的測試，也不要做不充分的測試，這就是“Good-Enough原則，也就是說當(dāng)軟件測試到達(dá)一個“最優(yōu)工作量”的時候就停止測試。2.3軟件測試的原則（8）程序中存在軟件缺陷的可能性與該部分已經(jīng)發(fā)現(xiàn)的缺陷成正比通常一段程序中已發(fā)現(xiàn)的錯誤數(shù)越多，意味著這段程序的潛在錯誤也較多，這是軟件缺陷的集群現(xiàn)象。人總是會反復(fù)犯下自己容易犯的錯誤，程序員也不例外。另外一個可能是，錯誤聚集的模塊是軟件的底層架構(gòu)，這樣的位置牽一發(fā)而動全身。（9）軟件測試經(jīng)常會有免疫現(xiàn)象發(fā)生在軟件測試中，免疫現(xiàn)象用來描述測試人員對同一測試對象進(jìn)行的測試次數(shù)越多，發(fā)現(xiàn)的缺陷就會越來越少的現(xiàn)象。這是1990年，BorisBeizer在其編著的《軟件測試技術(shù)》第二版一書中提出的。為了克服免疫現(xiàn)象，軟件測試人員必須常常采用新技術(shù)，編寫不同的測試程序，對程序的不同部分進(jìn)行測試，以發(fā)現(xiàn)更多的缺陷。也可以引入新人來測試軟件，往往新人能發(fā)現(xiàn)一些意想不到的問題。（10）無法通過軟件測試發(fā)現(xiàn)所有的軟件缺陷軟件測試是質(zhì)量保證中的一環(huán)，只能保證盡量暴露軟件中的缺陷。通過軟件測試可以證明缺陷存在，但不能證明系統(tǒng)不存在缺陷。測試可以減少軟件中遺漏的缺陷數(shù)量，但即使測試沒有發(fā)現(xiàn)任何缺陷，也不能證明軟件或系統(tǒng)是完全沒有缺陷的，軟件測試無法揭示潛伏的軟件缺陷。2.3軟件測試的原則（11）并非所有的軟件缺陷都會修復(fù)到項(xiàng)目發(fā)布時間了，沒有足夠的時間修復(fù)缺陷了不是真正的缺陷，而是理解錯誤或測試錯誤或者說明書變更導(dǎo)致的修復(fù)一個缺陷，有可能會引入更多或者更嚴(yán)重的缺陷一些隨機(jī)缺陷或者出現(xiàn)在不常使用的模塊中的軟件缺陷是可以暫時放過的（12）前進(jìn)兩步，后退一步這是指修復(fù)軟件缺陷，總會以20%~50%的幾率引入新的缺陷，所以整個過程是前進(jìn)兩步，后退一步的。通過合理的回歸測試可以有效的解決部分這種問題。常見的題目一、單選題（1）下面哪一項(xiàng)不是常見的軟件測試過程模型？（ ）A．H模型

B．V模型

C．W模型 D．瀑布模型（2）以下哪一項(xiàng)屬于W模型的測試環(huán)節(jié)？（

）A．需求分析 B．概要設(shè)計(jì)

C．詳細(xì)設(shè)計(jì) D．驗(yàn)收測試（3）下面不屬于測試原則的是（ ）A.軟件測試是有風(fēng)險(xiǎn)的行為

B.窮盡測試程序是不可能的C.測試無法顯示潛伏的軟件缺陷 D.找到的缺陷越多，證明軟件的潛在缺陷就越少（4）關(guān)于軟件測試的原則，以下說法錯誤的是（

）A.所有的測試都應(yīng)追溯到用戶需求 B.軟件測試應(yīng)盡早啟動C.程序員自己測試自己的程序可以達(dá)到最佳效果 D.軟件測試是有風(fēng)險(xiǎn)的常見的題目二、多選題（1）下面哪幾個項(xiàng)是屬于軟件測試流程中的重要環(huán)節(jié)？（）。A．編寫需求文檔 B．設(shè)計(jì)測試用例 C．執(zhí)行軟件測試 D．進(jìn)行項(xiàng)目總結(jié)（2）W模型中，以下哪些文檔需要測試人員參與評審？（ ）A．需求說明書 B．詳細(xì)設(shè)計(jì)文檔

C．測試用例 D．測試總結(jié)報(bào)告（3）關(guān)于二八原則，以下說法正確的是（ ）A. 80%的缺陷來自于20%的程序模塊中。B. 在需求、設(shè)計(jì)、實(shí)現(xiàn)階段，測試能發(fā)現(xiàn)80%的軟件缺陷。C. 系統(tǒng)測試能找出其余20%的缺陷中的80%，也就是16%的軟件缺陷。用戶可能會在長時間、大范圍的使用中發(fā)現(xiàn)20%的缺陷。（4）軟件測試需要由第三方去執(zhí)行，關(guān)于這一點(diǎn)說法正確的是（ ）A. 開發(fā)人員找自己程序的缺陷可能會有心里障礙。B. 開發(fā)人員可能對需求理解有誤，導(dǎo)致無法找出缺陷。C. 第三方測試一般都有專業(yè)成熟的測試技術(shù)。D. 開發(fā)人員比較忙，沒有時間測試自己的程序。常見的題目（5）獲取自有數(shù)據(jù)常用的方法有幾種？（ ）A.購買數(shù)據(jù)

B.生產(chǎn)環(huán)境真實(shí)數(shù)據(jù)引流

C.生產(chǎn)環(huán)境數(shù)據(jù)復(fù)制

D.構(gòu)造數(shù)據(jù)（6）H模型揭示了以下幾個內(nèi)容，說法正確的是（ ）A. 軟件測試不僅僅指測試的執(zhí)行，還包括很多其他的活動。B. 軟件測試是一個獨(dú)立的流程，貫穿產(chǎn)品生命周期，與其他流程并行。C. 軟件測試要盡早準(zhǔn)備、盡早執(zhí)行軟件測試是根據(jù)被測物的不同而分層次進(jìn)行的。（7）大數(shù)據(jù)測試環(huán)境有什么特點(diǎn)？（ ）A.數(shù)據(jù)規(guī)模大

B.數(shù)據(jù)多樣

C.計(jì)算復(fù)雜度高

D.分布式結(jié)構(gòu)等常見的題目三、判斷題（1）V模型存在一定的局限性，是指V模型僅僅把軟件測試過程作為在需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)及編碼之后的一個階段。容易使人誤解軟件測試是軟件開發(fā)過程的最后一個階段，有可能需求分析階段隱藏的問題會一直到后期的驗(yàn)收測試才被發(fā)現(xiàn)。（ ）（2）W模型不能很好的支持迭代，不能體現(xiàn)測試流程的完整性。（ ）（3）軟件測試報(bào)告可以展示軟件測試人員的工作成果。（ )下節(jié)更精彩軟件測試技術(shù)本書內(nèi)容第1章軟件測試概述第2章軟件測試流程和過程模型第3章軟件測試計(jì)劃第4章測試用例概述第5章高效設(shè)計(jì)測試用例第6章軟件缺陷報(bào)告第7章軟件測試報(bào)告第8章易用性測試第9章Web測試第10章測試人員的職業(yè)技能和技術(shù)支持第3章軟件測試計(jì)劃3.1軟件測試需求分析3.2軟件測試計(jì)劃概述3.3軟件測試計(jì)劃的內(nèi)容需求規(guī)格說明書

<安裝/卸載>用例概述需求描述用戶安裝、卸載愛郵客戶端行為者終端用戶前置條件擁有該功能點(diǎn)權(quán)限<安裝>界面描述界面元素業(yè)務(wù)規(guī)則序號規(guī)則1用戶可以在wap網(wǎng)站下載安裝包也可以在web網(wǎng)站下載安裝包到電腦，再傳送至手機(jī)2選擇手機(jī)中安裝包即可直接安裝3將PushMail程序安裝到手機(jī)內(nèi)存或者是內(nèi)存卡中都可以4當(dāng)手機(jī)已有舊版本新浪PushMail，新版本可以直接覆蓋安裝，覆蓋安裝不會保留原有的用戶數(shù)據(jù)根據(jù)需求來源的不同，軟件分類產(chǎn)品類軟件沒有特定用戶以合同形式明確要求，由市場分析人員分析潛在的客戶的潛在需求獲得方式：市場調(diào)查、問卷、類似產(chǎn)品用戶回饋、心里分析研究等方式要求：要有深厚的業(yè)務(wù)背景、敏銳的洞察力、前瞻和預(yù)測能力以及創(chuàng)造性思維項(xiàng)目類軟件由特定用戶以合同等契約形式明確下來；方式：可通過訪談、交流、一起工作等方式要求：具有業(yè)務(wù)背景、很好的交流溝通能力和親和力，還需要很強(qiáng)的分析能力需求分析的作用非常重要一項(xiàng)調(diào)查的結(jié)果表明：56%的軟件缺陷其實(shí)是在軟件需求階段被引入的，而這其中的50%是由于需求文檔編寫不明確、不清晰、不正確等問題導(dǎo)致的，剩下的50%則是由于需求的遺漏導(dǎo)致的。所以經(jīng)常會發(fā)生這樣的現(xiàn)象：項(xiàng)目組開發(fā)出來的軟件，雖然已經(jīng)通過了嚴(yán)格的測試和質(zhì)量保證人員的確認(rèn)，但依然會收到很多用戶抱怨，甚至開發(fā)者團(tuán)隊(duì)自身可能都不喜歡使用。原因就是需求從一開始就是錯誤的。什么是評審？為了避免出現(xiàn)“需求從一開始就是錯誤的”現(xiàn)象，軟件測試人員需要對軟件的需求規(guī)格說明書進(jìn)行測試，而且要盡早參與需求評審會。IEEE729-1983規(guī)定：在正式的會議上將軟件項(xiàng)目的成果（包括各階段的文檔、產(chǎn)生的代碼等）提交給用戶、客戶或有關(guān)部門人員對軟件產(chǎn)品進(jìn)行評審和批準(zhǔn)。其目的是找出可能影響軟件產(chǎn)品質(zhì)量、開發(fā)過程、維護(hù)工作的適用性和環(huán)境方面的設(shè)計(jì)缺陷，并采取補(bǔ)救措施，以及找出在性能、安全性和經(jīng)濟(jì)方面的可能的改進(jìn)。需求評審的重要性需求評審會才是真正的讓大家接收信息的途徑，重要的事必須當(dāng)面說清保證需求分析的正確和準(zhǔn)確性是決定軟件項(xiàng)目成敗的關(guān)鍵因素經(jīng)驗(yàn)再豐富的需求分析人員也可能犯錯需求在傳達(dá)過程中存在很大的偏差。如果不做評審軟件測試工程師需求評審檢查單1需求中的每個規(guī)格是否都有明確的說明？2軟件的需求的表述是否清晰？3軟件的需求是否存在二義性？4是否對特定含義的術(shù)語給予了定義？5需求是否有自相矛盾的情況？6需求中有沒有遺漏一些異常的約束關(guān)系？7需求中有沒有包含不確定行描述，如：大約、可能、等8環(huán)境搭建是否有困難或可能有困難？第3章軟件測試計(jì)劃3.1軟件測試需求分析3.2軟件測試計(jì)劃概述3.3軟件測試計(jì)劃的內(nèi)容什么是軟件測試計(jì)劃？IEEE定義測試計(jì)劃為：軟件測試計(jì)劃是一個敘述了預(yù)定的測試活動的范圍、途徑、資源及進(jìn)度安排的文檔。它確認(rèn)了測試項(xiàng)、被測特征、測試任務(wù)、人員安排，以及任何偶發(fā)事件的風(fēng)險(xiǎn)。編寫測試計(jì)劃有利于測試組成員對測試工作的資源、時間、風(fēng)險(xiǎn)、測試范圍及預(yù)算做綜合評估。制定測試計(jì)劃有什么作用呢？（1）軟件測試計(jì)劃是保證項(xiàng)目成功的重要因素之一（2）管理者可以根據(jù)測試計(jì)劃做宏觀調(diào)控，進(jìn)行相應(yīng)資源的配置管理；（3）可以增加團(tuán)隊(duì)間交流，使測試人員了解整個項(xiàng)目不同階段所要進(jìn)行的工作安排；（4）便于其他成員了解測試人員的工作內(nèi)容，配合有關(guān)工作（5）如果是項(xiàng)目式軟件的話，可以通過測試計(jì)劃交代的內(nèi)容，比如測試過程、人員技能、資源、使用工具等信息，給客戶信心。如何做好軟件測試計(jì)劃工作（1）測試計(jì)劃的制定越早越好測試計(jì)劃越早制定越好，通常需求文檔評審?fù)ㄟ^后，測試組就需要開始測試計(jì)劃工作了，并通過計(jì)劃過程形成測試計(jì)劃文檔。當(dāng)然，對于開發(fā)過程不是十分清晰和穩(wěn)定的項(xiàng)目，測試計(jì)劃也可以在總體設(shè)計(jì)完成后開始編寫。（2）堅(jiān)持5W1H的基本思路，明確軟件測試計(jì)劃內(nèi)容的6要素如何做好軟件測試計(jì)劃工作（3）采用評審和更新機(jī)制如果沒有經(jīng)過評審，直接發(fā)送給測試團(tuán)隊(duì)，測試計(jì)劃內(nèi)容可能不準(zhǔn)確或遺漏。因?yàn)榭赡苄枨蟀l(fā)生了變更，而測試計(jì)劃沒有及時更新，也有可能受編寫人員自身經(jīng)驗(yàn)和對軟件需求的理解所限而導(dǎo)致內(nèi)容不完善。所以一定要對軟件測試計(jì)劃進(jìn)行評審，而且根據(jù)審閱意見和建議進(jìn)行修正和更新。即便如此，在后續(xù)的軟件測試執(zhí)行過程中，仍然會出現(xiàn)“計(jì)劃趕不上變化”的情況，所以軟件測試計(jì)劃需要不斷更新。（4）軟件測試計(jì)劃要簡潔、易讀避免“大而全”，無所不包，長篇大論，既浪費(fèi)寫作時間，也浪費(fèi)測試人員的閱讀時間?！按蠖钡囊粋€常見表現(xiàn)就是測試計(jì)劃文檔包含詳細(xì)的測試技術(shù)指標(biāo)和測試用例。最好的方法是分開創(chuàng)建測試計(jì)劃和測試用例以及詳細(xì)的測試技術(shù)指標(biāo)。測試計(jì)劃和測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測試計(jì)劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源配置，而測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù)。常見考題測試計(jì)劃定義測試計(jì)劃的作用5W原則為什么要對測試計(jì)劃進(jìn)行評審3.3軟件測試計(jì)劃的內(nèi)容3.3.1項(xiàng)目概述3.3.2測試范圍3.3.3測試策略3.3.4測試資源3.3.5測試進(jìn)度3.3.6測試準(zhǔn)則3.3.7風(fēng)險(xiǎn)及應(yīng)對方案3.3.8測試提交的文檔3.3.1項(xiàng)目概述1.項(xiàng)目背景：列出測試計(jì)劃所從屬的軟件系統(tǒng)的名稱。說明沒有這個產(chǎn)品的時候所處的“悲慘境地”；還要說明這個產(chǎn)品解決了什么問題，能達(dá)到什么樣的美好未來，以及促成這個改變所需要的產(chǎn)品功能點(diǎn)。軟件系統(tǒng)的名稱：《學(xué)生考試系統(tǒng)》組織學(xué)生考試工作是教學(xué)管理中的一項(xiàng)重要工作內(nèi)容，但現(xiàn)在學(xué)院對于學(xué)生考試的管理還采取人工出題、組卷、紙張打印的方式，效率明顯太低，而且成本也相對比較大，也不環(huán)保。隨著信息時代的發(fā)展以及計(jì)算機(jī)廣泛的普及，人們的日常學(xué)習(xí)辦公越來越離不開計(jì)算機(jī)，而對于學(xué)校的教務(wù)管理中心和老師來說，若能有一套有效的學(xué)生考試系統(tǒng)，無疑會大大的提高效率，方便對學(xué)生考試的管理。因此，項(xiàng)目組準(zhǔn)備開發(fā)一套功能完善的考試系統(tǒng)軟件，快速處理出題、組卷、發(fā)布試卷、以及參加考試等功能。該系統(tǒng)包含學(xué)生端和教師端2個部分。學(xué)生端的功能主要是：學(xué)生信息展示、學(xué)生登錄功能、學(xué)生參與考試及查看考試解析等；而教師端的功能主要是：學(xué)生信息錄入、試題錄入、組卷、發(fā)布考試、教師閱卷等。2.編寫目的：編寫這個文檔要達(dá)到的目的。3.計(jì)劃受眾：可能會閱讀和參考這份文檔的人員。預(yù)期的讀者有兩類：項(xiàng)目管理人員和測試人員。3.3.1項(xiàng)目概述4.術(shù)語定義：文中出現(xiàn)的專門術(shù)語和外文首字母組詞的原詞組，包括通用詞語在本文中的專用解釋。作用：讓小組內(nèi)全體人員說法一致；讓非專業(yè)人士能看懂文檔3.3.1項(xiàng)目概述5.參考資料：本項(xiàng)目經(jīng)核準(zhǔn)的計(jì)劃任務(wù)書、合同或上級機(jī)關(guān)的批文；屬于本項(xiàng)目的其他已發(fā)表的文件；本文件中各處引用的文件、資料，包括所要用到的軟件開發(fā)標(biāo)準(zhǔn)。列出標(biāo)題、文件編號、發(fā)表日期和出版單位，說明這些文件資料的來源。比如：《計(jì)算機(jī)軟件工程規(guī)范國家標(biāo)準(zhǔn)匯編2003》，中國標(biāo)準(zhǔn)出版社；《GBT15532-2008計(jì)算機(jī)軟件測試規(guī)范2008》；《GBT9386-2008計(jì)算機(jī)軟件測試文檔編制規(guī)范2008》；《某某項(xiàng)目需求規(guī)格說明書》V1.5版，項(xiàng)目小組內(nèi)部文檔；《某某項(xiàng)目開發(fā)計(jì)劃書》V1.2版，項(xiàng)目小組內(nèi)部文檔；《某某項(xiàng)目產(chǎn)品原型圖》V1.7版，項(xiàng)目小組內(nèi)部文檔；3.3.2測試范圍測試策略/方法測試策略是描述測試小組用于測試整體和每個階段的方法。需要注意以下幾點(diǎn)：列出對測試對象進(jìn)行測試的推薦方法；對于每種測試，都應(yīng)提供測試說明，并解釋其實(shí)施的原因；將要使用的測試技術(shù)以及完成標(biāo)準(zhǔn)。3.3.4測試資源測試資源包括軟硬件資源和人力資源。在項(xiàng)目期間測試可能用到的任何資源都要考慮到。軟硬件資源：測試人員配置測試工具3.3.4測試資源測試資源包括軟硬件資源和人力資源。在項(xiàng)目期間測試可能用到的任何資源都要考慮到。軟硬件資源：測試人員配置測試工具3.3.5測試進(jìn)度1.任務(wù)分工：每個人所負(fù)責(zé)的測試內(nèi)容2.測試?yán)锍瘫宏P(guān)鍵性事件的時間節(jié)點(diǎn)。在測試中，通常有幾個里程碑，比如系統(tǒng)測試、制定測試計(jì)劃、設(shè)計(jì)測試用例、執(zhí)行測試用例、軟件測試報(bào)告。序號測試活動計(jì)劃開始日期計(jì)劃結(jié)束日期所需工時1系統(tǒng)培訓(xùn)2025-08-042025-08-085個工作日2制定測試計(jì)劃2025-08-112025-08-155個工作日3設(shè)計(jì)測試用例2025-08-182025-09-3034個工作日4執(zhí)行測試用例2025-10-082025-11-0722個工作日5軟件測試報(bào)告2025-11-102025-11-134個工作日測試員測試任務(wù)分配張三測試字符格式：字體、大小、顏色、樣式李四測試布局：項(xiàng)目符號、段落、制表位、換行王五配置和兼容性測試趙六用戶界面測試：易用性、外觀、輔助特性壓力測試和負(fù)載測試3.3.5測試進(jìn)度最大關(guān)鍵路徑法：比如：如果張三負(fù)責(zé)的A模塊需要3天完成，李四負(fù)責(zé)的B模塊需要5天完成，王五負(fù)責(zé)的C模塊需要4天完成，那么這輪測試計(jì)劃的時間就按照5天來算。這個時間計(jì)算的前提是這3人的工作是并行的。倒推法：簡單的說，如果一個項(xiàng)目是3個月，其中2個月是開發(fā)時間，那最終的測試時間就只有1個月了，測試就只能在這1個月之內(nèi)進(jìn)行計(jì)劃和安排。序號測試活動計(jì)劃開始日期計(jì)劃結(jié)束日期所需工時1第一輪測試2025-10-082025-10-2212個工作日2第二輪測試2025-10-232025-10-317個工作日3第三輪測試2025-11-032025-11-075個工作日3.3.5測試進(jìn)度進(jìn)度破壞：由于項(xiàng)目中某部分提交給測試組的時間推遲了導(dǎo)致測試時間壓縮的情況。采用相對日期序號測試活動計(jì)劃開始日期所需工時1制定測試計(jì)劃說明書完成后7天2個星期2設(shè)計(jì)測試用例測試計(jì)劃完成6個星期3執(zhí)行第1輪測試代碼構(gòu)建完成3個星期4執(zhí)行第2輪測試Beta版代碼構(gòu)建完成3個星期5執(zhí)行第3輪測試發(fā)行版構(gòu)建完成2個星期6測試總結(jié)報(bào)告軟件測試到達(dá)最佳平衡點(diǎn)1個星期3.3.5測試進(jìn)度測試人員數(shù)量歲時間變化的趨勢圖3.3.6測試準(zhǔn)則（1）測試進(jìn)入的準(zhǔn)則：是指開始執(zhí)行測試的時機(jī)；（2）測試暫停的準(zhǔn)則：描述系統(tǒng)在什么情況下暫停全部或部分測試工作；（3）測試恢復(fù)的準(zhǔn)則：描述系統(tǒng)恢復(fù)測試的必要條件；（4）測試退出的準(zhǔn)則：描述測試退出的條件，有正常退出，也有非正常或意外的退出。3.3.6測試準(zhǔn)則測試通過的標(biāo)準(zhǔn)功能性測試用例通過率達(dá)到100%，非功能性測試用例通過率從達(dá)到85%，對于不能通過的測試項(xiàng)，在提交測試報(bào)告前與項(xiàng)目經(jīng)理確認(rèn)S1和S2的bug不允許存在；S3的bug可以遺留5%，最多不超過10個；S4的bug可以遺留20%，最多不超過25個Bug趨勢處于收斂狀態(tài)3.3.7風(fēng)險(xiǎn)及應(yīng)對方案（1）需求風(fēng)險(xiǎn)：需求變更或理解不準(zhǔn)確；（2）測試用例風(fēng)險(xiǎn)：設(shè)計(jì)不完整；（3）缺陷風(fēng)險(xiǎn)：難以復(fù)現(xiàn)或沒有很好的被跟蹤；（4）代碼風(fēng)險(xiǎn)：代碼質(zhì)量差、修改難度大；或系統(tǒng)架構(gòu)擴(kuò)展性不足；（5）測試環(huán)境風(fēng)險(xiǎn)：數(shù)量不足導(dǎo)致測試結(jié)果誤差。（6）測試技術(shù)風(fēng)險(xiǎn)：技術(shù)局限性（7）回歸測試風(fēng)險(xiǎn)：回歸時，業(yè)務(wù)流程不通導(dǎo)致延后（8）溝通協(xié)調(diào)風(fēng)險(xiǎn)：部門之間的溝通協(xié)調(diào)不暢，比如需求變更沒有及時通知（9）研發(fā)流程風(fēng)險(xiǎn)：流程不規(guī)范導(dǎo)致一些臨時風(fēng)險(xiǎn)（10）其他不可預(yù)計(jì)的風(fēng)險(xiǎn)：如法狀況、不可抗力的因素3.3.8測試提交的文檔測試完成后測試人員需要?dú)w檔的文檔。如軟件測試計(jì)劃、軟件測試用例、軟件缺陷報(bào)告、缺陷處理日志、軟件測試報(bào)告等。一頁紙測試計(jì)劃核心三要素TRQ范圍花多長時間去做軟硬件、人力要測試的內(nèi)容以及重點(diǎn)測試范圍測試進(jìn)度計(jì)劃測試?yán)锍瘫疁y試資源測試計(jì)劃和測試方案的區(qū)別序號角度測試計(jì)劃測試方案1組織方式不同管理文件技術(shù)文件2目的不同強(qiáng)調(diào)“做什么”強(qiáng)調(diào)“怎么做”3具體要求不同組織架構(gòu)、工作任務(wù)分配、工作量估計(jì)、人力物力資源的分配、進(jìn)度的安排、風(fēng)險(xiǎn)的估計(jì)和規(guī)避、各任務(wù)通過準(zhǔn)則等測試需求的細(xì)化、測試組網(wǎng)圖的設(shè)計(jì)、自動化測試框架的設(shè)計(jì)、測試數(shù)據(jù)和測試腳本的設(shè)計(jì)、測試用例設(shè)計(jì)的原則等常見題目一、單選題（1）關(guān)于做好軟件測試計(jì)劃工作的說法錯誤的是（ ）測試計(jì)劃越早制定越好。堅(jiān)持5W1H的基本思路。在測試計(jì)劃中包含測試詳細(xì)規(guī)格和測試用例。采取評審和更新機(jī)制。（2）關(guān)于編寫軟件測試計(jì)劃的好處說法錯誤的是（ ）A.為組織、安排和管理測試提供一個整體框架。B.可以增進(jìn)團(tuán)隊(duì)間的交流，明確不同測試階段所要進(jìn)行的工作。C.有利于其他成員了解測試人員的工作。D.測試計(jì)劃是一個形式上的文檔，主要是為了測試文件存檔。（3）軟件測試所需要的資源應(yīng)該包含哪三大類？（ ）A. 硬件資源、軟件資源、人力資源B. 網(wǎng)絡(luò)資源、軟件資源、人力資源C. 硬件資源、軟件資源、開發(fā)資源D. 硬件資源、軟件資源、風(fēng)險(xiǎn)資源常見題目二、多選題（1）在軟件項(xiàng)目中，影響項(xiàng)目的關(guān)鍵約束有哪幾個？（ ）A.項(xiàng)目范圍 B.項(xiàng)目資源 C.項(xiàng)目進(jìn)度 D.項(xiàng)目質(zhì)量（2）根據(jù)需求來源的不同，軟件分為哪幾種類型？（ ）A. 系統(tǒng)類軟件 B. 產(chǎn)品類軟件 C.功能類軟件 D. 項(xiàng)目類軟件（3）軟件測試計(jì)劃中為什么要進(jìn)行術(shù)語定義？（ ）A. 可以讓小組內(nèi)全體人員對于術(shù)語定義的說法一致。B. 為了讓非專業(yè)人士也能看懂測試計(jì)劃文檔，減少溝通。C. 術(shù)語定義應(yīng)該包括專門術(shù)語和外文首字母組詞的原詞組。術(shù)語定義包括通用詞語在本文中的專用解釋。（4）在測試中，可能遇到的風(fēng)險(xiǎn)有哪些？（ ）A. 需求風(fēng)險(xiǎn) B. 缺陷風(fēng)險(xiǎn)C. 溝通協(xié)調(diào)風(fēng)險(xiǎn) D. 研發(fā)流程風(fēng)險(xiǎn)E. 測試環(huán)境風(fēng)險(xiǎn) F. 代碼風(fēng)險(xiǎn)

常見題目三、判斷題（1）軟件測試計(jì)劃一般是由測試經(jīng)理去編寫，測試新手不需要學(xué)習(xí)如何編寫測試計(jì)劃。（

）（2）軟件測試計(jì)劃的模板是固定的，所以記住軟件測試計(jì)劃的模板內(nèi)容，就可以寫好一份軟件測試計(jì)劃。（ ）（3）調(diào)查結(jié)果表明：56%的缺陷是在軟件需求階段引入的，而這其中的50%是由于需求文檔編寫有問題、不明確導(dǎo)致的，剩下的50%是由于需求的遺漏導(dǎo)致的。（ ）（4）編寫軟件測試計(jì)劃占用很多時間，而且計(jì)劃趕不上變化，所以不需要花費(fèi)太多時間在測試計(jì)劃上面。（ ）

下節(jié)更精彩軟件測試技術(shù)目錄內(nèi)容第1章軟件測試概述第2章軟件測試流程和過程模型第3章軟件測試計(jì)劃第4章測試用例概述第5章高效設(shè)計(jì)測試用例第6章軟件缺陷報(bào)告第7章軟件測試報(bào)告第8章易用性測試第9章Web測試第10章測試人員的職業(yè)能力和技術(shù)支持第4章測試用例概述4.1測試用例簡介4.2測試用例的設(shè)計(jì)獲取需求的測試點(diǎn)測試用例模板測試用例的優(yōu)先級測試用例的設(shè)計(jì)原則4.3測試用例的維護(hù)4.1測試用例簡介什么是軟件測試用例？軟件測試用例是指對一項(xiàng)特定的軟件產(chǎn)品進(jìn)行測試任務(wù)的描述，體現(xiàn)測試方案、方法、技術(shù)和策略，內(nèi)容包括測試目標(biāo)、測試環(huán)境、輸入數(shù)據(jù)、測試步驟、預(yù)期結(jié)果、測試腳本等，并形成文檔。IEEEStandard829-1983中定義測試用例為：測試用例是指定輸入，預(yù)期結(jié)果和一組測試項(xiàng)的執(zhí)行條件的文檔。4.1測試用例簡介測試用例的作用（1）避免盲目測試，提高測試效率編寫測試用例有利于測試的組織。在開始實(shí)施測試之前設(shè)計(jì)好測試用例，可以避免盲目測試，提高測試效率，特別是對于測試人員中的新手，好的測試用例可以幫助他們更好地完成復(fù)雜的測試任務(wù)，提高測試工作的效率。（2）確保功能需求不被遺漏測試用例是根據(jù)功能需求細(xì)細(xì)推敲而來的并且通過了嚴(yán)格的評審，按照測試用例執(zhí)行測試，可以使軟件測試的實(shí)施重點(diǎn)突出、目的明確，確保功能不會被漏測。（3）便于回歸測試在項(xiàng)目執(zhí)行測試期間會有多次回歸測試，以保證老的缺陷被成功修復(fù)，同時沒有引入新的缺陷。如果沒有測試用例，憑腦子記住之前的操作步驟是不可能的，這樣就無法復(fù)原原有的測試過程。（4）為測試的度量提供評估基準(zhǔn)測試完畢后需要對測試結(jié)果進(jìn)行評估，并且編制測試報(bào)告。判斷軟件測試是否完成、衡量軟件測試質(zhì)量都需要一些量化的結(jié)果。比如測試用例的執(zhí)行率是多少、成功測試用例的執(zhí)行率是多少、需要的測試合格率是多少，等等。測試用例可以為這些結(jié)果提供量化數(shù)據(jù)和評估的基準(zhǔn)。第4章測試用例概述4.1測試用例簡介4.2測試用例的設(shè)計(jì)4.2.1獲取需求的測試點(diǎn)4.2.2測試用例模板4.2.3測試用例的優(yōu)先級4.2.4測試用例的設(shè)計(jì)原則4.3測試用例的維護(hù)測試用例的設(shè)計(jì)步驟（1）獲取需求的測試點(diǎn)分析系統(tǒng)程序的工作流程，明確各個功能模塊的需求，明確測試范圍，提取所要測試的具體測試點(diǎn)，為編寫測試用例提供依據(jù)和思路。（2）設(shè)計(jì)測試用例模板，設(shè)計(jì)測試步驟確定一份符合規(guī)范的測試用例模板，結(jié)合軟件需求文檔，在掌握一定測試用例設(shè)計(jì)方法的基礎(chǔ)上（測試用例設(shè)計(jì)方法在第5章中會詳細(xì)講解），設(shè)計(jì)出比較全面、合理的測試用例，并且生成規(guī)范的測試用例表。（3）確定測試數(shù)據(jù)根據(jù)測試用例表的內(nèi)容，復(fù)審測試用例，并確定支持這些測試用例的實(shí)際值，包括用作輸入的測試數(shù)據(jù)、用作預(yù)期結(jié)果的數(shù)據(jù)值、用作支持測試用例所需的其他數(shù)據(jù)。如果是自動化測試的話，在這里需要寫自動化測試腳本。（4）評審測試用例軟件測試用例在形成文檔后還需要評審、更新之后才能算是有效的測試用例。評審會議一般至少會進(jìn)行兩輪。第一輪一般是測試負(fù)責(zé)人召集測試人員進(jìn)行小組內(nèi)部評審；第二輪是與項(xiàng)目有關(guān)的其他部門的人員進(jìn)行的評審，比如項(xiàng)目經(jīng)理、產(chǎn)品人員、開發(fā)人員等。一方面可以再次確認(rèn)需求和預(yù)期結(jié)果，另一方面可以讓各方再次就需求達(dá)成共識，減少出錯的可能性。4.2.1獲取需求的測試點(diǎn)做好測試用例的關(guān)鍵就是，對需求和設(shè)計(jì)文檔的理解，以及對系統(tǒng)的熟悉，所以測試用例的基礎(chǔ)是軟件需求。軟件需求決定了測試點(diǎn)，但測試點(diǎn)卻不完全來自于軟件需求，測試點(diǎn)的來源有顯性的和隱性的兩種。需求文檔是顯性需求，而一些通過測試的原則、行業(yè)傳統(tǒng)和常識推理出來的需求則屬于隱性需求，它們無法從需求文檔中直接導(dǎo)出。一份可測試的、完整的和詳細(xì)的需求說明書是對測試工作最大的幫助。但是在實(shí)際工作中，需求的定義通常是不完善的，有的項(xiàng)目甚至根本沒有需求文檔，雖然這從流程上來說絕對是不規(guī)范的，但是確實(shí)常常因?yàn)轫?xiàng)目比較緊張存在不少這種缺胳膊少腿的現(xiàn)象。那作為軟件測試人員，該如何在這種情況下突圍呢？沒有需求文檔時，應(yīng)該怎么做：閱讀遺留文檔，收集整理已有的需求向有關(guān)人員咨詢參考同類產(chǎn)品的需求說明書采用探索性測試的解決方案它并不預(yù)先設(shè)計(jì)測試用例或者精確地按照一個計(jì)劃來執(zhí)行，它依靠的是測試員的知識水平和創(chuàng)造力。探索性測試可以運(yùn)用在整個計(jì)劃、編寫用例和執(zhí)行測試過程中。4.2.2測試用例模板測試用例模板4.2.3測試用例的優(yōu)先級在實(shí)際軟件測試項(xiàng)目中，經(jīng)常無法在每一個應(yīng)用程序的版本上執(zhí)行全部的測試用例。所以在測試資源和時間都有限的情況下，你必須知道哪些測試用例應(yīng)該被優(yōu)先執(zhí)行，哪些測試用例是在有富裕時間的時候可以被增加執(zhí)行，這很大程度上是由測試用例的優(yōu)先級來決定的。制定測試用例優(yōu)先級的好處：可以優(yōu)先執(zhí)行優(yōu)先級高的測試用例，即使測試時間不足，也能盡量保證測試工作達(dá)到了良好的效果；可以根據(jù)優(yōu)先級策略，高效分配測試資源，從而達(dá)到成本、質(zhì)量的平衡；可以為待定的自動化測試做一個好的起點(diǎn)。4.2.3測試用例的優(yōu)先級RossCollard在“UseCaseTesting”一文中說：“測試用例的前10%到15%可以發(fā)現(xiàn)75%到90%的重要缺陷?！睖y試用例的優(yōu)先級別劃分在不同的公司會有所差異，以下推薦一種常見的測試用例優(yōu)先級別的定義4.2.3測試用例的優(yōu)先級1-小版本確認(rèn)測試（BuildVerificationTests，BVTs）冒煙測試。這是一組需要有限執(zhí)行以確認(rèn)該軟件版本是否可以繼續(xù)測試的測試用例。10%~15%。2-高（High）最常被執(zhí)行的、保證功能穩(wěn)定、目標(biāo)的行為和能力正常工作的、能發(fā)現(xiàn)重要錯誤的測試用例的集合。20%~30%。3-中（Medium）更全面的驗(yàn)證功能的各個方面，主要指異常測試，如邊界、斷網(wǎng)、容錯和配置測試的測試用例。40%~60%。4-低（Low）一組最少被執(zhí)行的測試用例。如GUI、錯誤信息、可用性、壓力和性能測試。10%~15%。4.2.3測試用例的優(yōu)先級如何把設(shè)計(jì)好的測試用例放到對應(yīng)的級別中去，是另一件比較復(fù)雜的事情第一步：按照一定的邏輯把軟件測試用例先隨意進(jìn)行分級。（1）把所有功能性驗(yàn)證的測試用例標(biāo)記為“高”優(yōu)先級；（2）把所有錯誤和邊界值的測試用例標(biāo)記為“中”優(yōu)先級；（3）把所有非功能性的測試用例（如性能和可用性）標(biāo)記為“低”優(yōu)先級。第二步：提級或降級（1）把“高”優(yōu)先級的分為：重要的和不十分重要的。把“不十分重要的”降級為“中”優(yōu)先級；（2）把“中”優(yōu)先級的分成兩組，把“重要的”升級為“高”優(yōu)先級。（3）把“低”優(yōu)先級的分成兩組，把“重要的”升級為“中”優(yōu)先級第三步：識別BVTs測試用例。把“高”優(yōu)先級的分成兩組：嚴(yán)重和重要的，把“嚴(yán)重的”測試用例升級為BVTs優(yōu)先級。4.2.4測試用例的設(shè)計(jì)原則測試用例除了應(yīng)該符合基本的測試用例編寫規(guī)范，還要遵守以下幾條基本設(shè)計(jì)原則：（1）測試用例的描述要明確測試用例的描述必須是明確的，比如“用戶正確操作，系統(tǒng)正常運(yùn)行”或者“用戶非法操作，系統(tǒng)不能正常運(yùn)行”這樣的描述就是不明確的，什么是正確操作？什么是正常運(yùn)行？這就必然導(dǎo)致測試人員對測試用例的理解不確定，從而引發(fā)測試中的錯誤發(fā)生。除了操作步驟的描述要明確，預(yù)期結(jié)果的描述也必須是明確唯一的。（2）測試用例的描述要簡潔雖然我們要求測試用例的操作步驟要足夠詳細(xì)、準(zhǔn)確和清晰，但同時也要保證測試用例的簡潔性。冗長和復(fù)雜的測試用例可讀性太差、不利于測試人員理解和操作，甚至有時候自己設(shè)計(jì)的測試用例，自己都不想執(zhí)行。但過于簡潔也會容易使人產(chǎn)生誤解，所以要做到恰到好處，好好鍛煉自己語言組織的基本功吧。（3）測試用例對需求的覆蓋采用最小化原則比如說，有一個系統(tǒng)功能模塊，有3個子功能，那么我們是用一個測試用例覆蓋三個子功能呢？還是用三個單獨(dú)的測試用例分別覆蓋三個子功能呢？對于稍微有點(diǎn)規(guī)模的項(xiàng)目，推薦后者。因?yàn)橐坏┌l(fā)現(xiàn)了缺陷，指向性更強(qiáng)，便于調(diào)試。（4）測試用例編寫要有條理、邏輯性強(qiáng)測試用例可以按照功能點(diǎn)分類、操作順序等邏輯順序編寫，而不要一會測試這里，一會測試那里，會讓人無所適從。（5）功能覆蓋全面、深入，能夠發(fā)現(xiàn)軟件中更多的缺陷除了通過測試外，可以多想一些異常的操作流程進(jìn)行失敗測試，試圖破壞軟件，查看軟件的響應(yīng)情況。4.3測試用例的維護(hù)在測試過程中，測試用例并不是一成不變的，它需要不斷的更新和維護(hù)，這是一個不斷修改完善的過程。無論事先把測試用例設(shè)計(jì)的如何好，開始執(zhí)行測試后，肯定又會考慮編寫新的測試用例。原因有三（1）在實(shí)際項(xiàng)目中，所有需求和設(shè)計(jì)文檔都存在而且包含所有功能路徑和場景說明的情況非常罕見，導(dǎo)致編寫測試用例時也會有遺留；（2）有時候系統(tǒng)架構(gòu)和設(shè)計(jì)階段錯過的細(xì)節(jié)，直到執(zhí)行測試階段才浮出水面，這時候就需要補(bǔ)充測試用例。（3）軟件自身的新增功能以及軟件版本的更新，導(dǎo)致測試用例也必須同時更新。缺點(diǎn)：耗時，維護(hù)量非常大。常見題目二、多選題（1）測試人員甲對測試用例有如下理解，其中正確的是（ ）A.測試用例中不要求必須給定明確的預(yù)期結(jié)果。B.測試用例可以使用管理軟件來維護(hù)。C.編寫測試用例費(fèi)時費(fèi)力，且實(shí)際意義不大，所以不如把這些時間用來做實(shí)際的測試。D.測試用例的最終形態(tài)是一份文檔。（2）測試人員乙對測試用例有如下理解，其中正確的是（ ）A. 測試用例是不需要更新的。B. 對每一個測試項(xiàng)目，測試用例必須嚴(yán)格按照模板以相同的細(xì)致程度進(jìn)行文檔化。C. 測試用例控制軟件測試的執(zhí)行過程，它是對每個測試需求的進(jìn)一步實(shí)例化。D. 自動化測試執(zhí)行過程中，測試用例也要不斷進(jìn)行跟蹤和優(yōu)化。常見題目三、判斷題（1）測試用例有利于測試的組織，可以避免盲目測試，提高測試效率，并為測試報(bào)告提供量化數(shù)據(jù)和評估的基準(zhǔn)。（ ）（2）測試用例設(shè)計(jì)完畢后要進(jìn)行評審，根據(jù)評審意見進(jìn)行更新。更新之后就盡量不要再改動，以免影響測試的執(zhí)行。（ ）（3）在測試項(xiàng)目中，如果沒有明確的需求文檔，測試人員可以通過閱讀遺留文檔、向相關(guān)人員咨詢、參考競爭對手的產(chǎn)品說明、探索性測試這幾種方式獲取需求。（ ）（4）探索性測試本身是一個非常強(qiáng)大的測試技術(shù)，它可以加強(qiáng)測試，只通過探索性測試就可以保證重要的測試路徑不會被遺漏。（ ）（5）測試用例文檔中的“用例編號”主要是便于檢索。（ ）（6）測試數(shù)據(jù)可以是數(shù)據(jù)，也可以是文件或具體操作。（ ）（7）劃分測試用例的優(yōu)先級，可以為待定的自動化測試做一個好的起點(diǎn)，比如BVTs測試用例。（）（8）測試用例中，應(yīng)重視測試用例的優(yōu)先級別的劃分：BVTS、高、中、低。嚴(yán)格遵守這四個級別不隨意變動。下節(jié)更精彩軟件測試技術(shù)目錄內(nèi)容第1章軟件測試概述第2章軟件測試流程和過程模型第3章軟件測試計(jì)劃第4章測試用例概述第5章高效設(shè)計(jì)測試用例第6章軟件缺陷報(bào)告第7章軟件測試報(bào)告第8章易用性測試第9章Web測試第10章測試人員的職業(yè)能力和技術(shù)支持第5章高效設(shè)計(jì)測試用例5.1邊界值分析5.2等價類5.3判定表法5.4因果圖法5.5場景法5.6正交實(shí)驗(yàn)法5.7大綱法5.8錯誤推測法黑盒測試的基本思路黑盒測試是軟件測試技術(shù)最重要的基本方法之一，在各類測試中都是必備的測試技術(shù)。在第1章中介紹過，黑盒測試又稱為“功能測試”或“數(shù)據(jù)驅(qū)動測試”，它將軟件看成是一個黑盒子，不考慮程序或者系統(tǒng)內(nèi)部結(jié)構(gòu)和內(nèi)部特性，檢查程序的功能是否按照需求規(guī)格說明書的規(guī)定正常運(yùn)行，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出結(jié)果。5.1等價類劃分法測試中的疑問做計(jì)算器程序的加法測試時，測試了1+1，1+2，1+3和1+4之后，還有必要測試1+5和1+6嗎?字長為32位的計(jì)算機(jī)上運(yùn)行，隨意取2個整數(shù)相加，232x232=264，測試一組需要1毫秒，一天工作24小時，一年工作365天，大概需要5億年。如果不測，能否放心地認(rèn)為它們是正確的?為了解決這個難題，又保證我們設(shè)計(jì)出來的測試用例具有完整性和代表性，我們引入等價類劃分法，它將不能窮舉的測試過程進(jìn)行區(qū)域劃分，減少測試的數(shù)量，從而使測試過程合理化。5.1.1等價類劃分法概述基本思路：把程序的輸入域劃分成若干部分，然后從每個部分中選取少數(shù)代表性數(shù)據(jù)作為測試用例。每一類的代表性數(shù)據(jù)在測試中的作用等價于這一類中的其他值：如果某一類中的一個數(shù)據(jù)發(fā)現(xiàn)了錯誤，這一等價類中的其他數(shù)據(jù)也能發(fā)現(xiàn)同樣的錯誤；反之，如果某一類中的一個數(shù)據(jù)沒有發(fā)現(xiàn)錯誤，則這一類中的其他數(shù)據(jù)也不會查出錯誤。有效等價類指對軟件規(guī)格說明來說，合理、有意義的輸入數(shù)據(jù)等構(gòu)成的集合，利用有效等價類可以檢驗(yàn)程序是否滿足需求規(guī)格說明書所規(guī)定的功能和性能?！皹?biāo)準(zhǔn)等價類測試”。無效等價類指不滿足程序輸入要求或者無效的輸入數(shù)據(jù)所構(gòu)成的集合，利用無效等價類可以檢驗(yàn)程序異常情況的處理。“健壯性等價類測試”。5.1.1等價類劃分法概述劃分原則：1）如果規(guī)定了輸入域的取值范圍或者個數(shù)，則可以確定一個有效等價類和2個無效等價類。如：60<=x<=1002）如果規(guī)定了輸入值的集合，不是一個范圍，則可以確定一個有效等價類和一個無效等價類。如：求x的平方根1個有效等價類：60<=x<=1002個無效等價類：小于60，大于1001個有效等價類：x>=01個無效等價類：x<05.1.1等價類劃分法概述劃分原則：3）如果規(guī)定了輸入數(shù)據(jù)的一組值，并且程序要對每一個輸入值分別進(jìn)行處理，則可以每一個值確定一個有效等價類，然后再選擇一個無效等價類。如：X={2，3，4，5}4）如果規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則，則可以確定一個有效等價類和若干個無效等價類。如：程序要求輸入一個5位數(shù)字n個有效等價類：2、3、4、51個無效等價類：1或者101個有效等價類：5位數(shù)字n個無效等價類：不是5位（大于或小于5位）；5位非數(shù)字（字符、英文、中文）5.1.1等價類劃分法概述確定等價類的原則5）如果已知的等價類中各個元素在程序中的處理方式不同，則應(yīng)將該等價類進(jìn)一步劃分成更小的等價類。5.1.1等價類劃分法概述等價類劃分法基本步驟第三步第一步第二步分析程序的規(guī)格說明，劃分等價類有效等價類無效等價類列出等價類表一一列出輸入條件中可能的組合輸入情況·選取合適的數(shù)據(jù)，編寫測試用例5.1.2等價類劃分法案例【案例1】：某網(wǎng)站用戶申請注冊時，要求必須輸入“用戶名”、“密碼”及“確認(rèn)密碼”。對每一項(xiàng)輸入有如下要求：用戶名：3-12位，只能使用英文字母、數(shù)字、中劃線-、下劃線_這幾個字符的組合，并且首字符必須為字母或數(shù)字；密碼：6-20位，只能使用英文字母、數(shù)字、中劃線-、下劃線_的組合；確認(rèn)密碼：與密碼必須一致，并且區(qū)分大小寫。請使用等價類劃分法設(shè)計(jì)測試用例【案例1】：第一步：分析程序的規(guī)格說明，列出等價類表（包括有效等價類和無效等價類）【案例1】：第二步：一一列出條件中可能的輸入組合情況，得出等價類組合表：用戶名正確、密碼正確，確認(rèn)密碼正確用戶名無效、密碼正確、確認(rèn)密碼正確用戶名正確、密碼無效、確認(rèn)密碼正確用戶名正確、密碼正確、確認(rèn)密碼無效【案例1】：【案例1】：第三步：選擇測試數(shù)據(jù)，編寫測試用例【案例2】某程序規(guī)定：輸入三個整數(shù)a、b、c分別作為三角形的三邊長度，通過三條邊長度來判斷三角形的類型分別為：一般三角形、等腰三角形或等邊三角形，并產(chǎn)生對應(yīng)的輸出。請運(yùn)用等價類劃分法來設(shè)計(jì)該題的測試用例?！景咐?】第一步：分析程序規(guī)格，列出等價類表（根據(jù)題目，得出程序輸入值的顯式和隱式要求以及輸出值的等價類）顯式要求：整數(shù)、三個數(shù)、正數(shù)隱式要求：兩邊之和大于第三邊、三邊均不相等、兩邊相等但不等于第三邊、三邊相等。輸出值的等價類為：不構(gòu)成三角形、一般三角形、等腰三角形、等邊三角形【案例2】第2步：一一列出條件中可能的組合情況（1）①②③④⑤⑥：輸出一般三角形（2）①②③④⑤⑥+⑦/⑧/⑨：輸出等腰三角形（3）①②③④⑤⑥+⑩：輸出等邊三角形（4）?~37：輸出非三角形【案例2】第3步：選擇測試數(shù)據(jù)，編寫測試用例課堂練習(xí)有一個用戶反饋功能模塊，3個輸入框的要求為：“問題標(biāo)題”允許輸入不超過20個字符，不允許為空；“問題描述”允許輸入不超過500個字符，不允許為空；5.1.3等價類劃分法總結(jié)和應(yīng)用場景在等價類劃分法中，每一類的代表性數(shù)據(jù)（也就是被選為測試用例的測試數(shù)據(jù)），在測試中的作用等價于這一類中的其他值，如案例1中的密碼“test_123”和“abcd_123”就是等效的，他們都屬于有效的密碼數(shù)據(jù)。也就是說如果等價類中的一個測試數(shù)據(jù)能捕獲一個缺陷，那么該等價類中的其他測試數(shù)據(jù)也能捕獲該缺陷；如果等價類中的一個測試數(shù)據(jù)不能捕獲缺陷，那么選擇該等價類中的其他測試數(shù)據(jù)也不能捕獲缺陷。只要有數(shù)據(jù)輸入的地方，就可以采用等價類劃分法，它可以從無限多的數(shù)據(jù)中選取少數(shù)代表性的數(shù)據(jù)進(jìn)行測試以減少測試人員的工作量。注意：在測試用例中，可以先測試全部輸入條件的有效等價類組合，再每次只測試一個輸入條件的無效等價類情況。無效等價類在開始測試的時候不能一起組合，避免“屏蔽”現(xiàn)象發(fā)生（前面輸入條件的錯誤提示一出現(xiàn)，后面控件的錯誤提示就不出現(xiàn)了）。然后可以再適當(dāng)考慮無效等價類的組合，驗(yàn)證軟件處理極端數(shù)據(jù)的能力。5.2邊界值分析法由長期的測試工作經(jīng)驗(yàn)得知，大量的錯誤是發(fā)生在輸入或輸出的邊界上，因此針對各種邊界情況設(shè)計(jì)測試用例，可以查出更多的錯誤。5.2.1邊界值分析法的概述邊界值分析法的測試用例來自于等價類的邊界，是等價類劃分法的補(bǔ)充。不是選取等價類中的任意值，而是選取正好等于、剛剛大于、剛剛小于邊界的值作為測試數(shù)據(jù)。一些常見的邊界：對int類型的整數(shù)而言，-215和215-1是它的邊界，也就是-32768和32767是邊界屏幕上光標(biāo)最左上、最右下位置報(bào)表的第一行和最后一行數(shù)組元素的第一個和最后一個循環(huán)的第0次、第1次和倒數(shù)第2次、最后一次5.2.1邊界值分析法的概述原則（1）如果輸入/輸出條件規(guī)定了值的范圍，則應(yīng)該取剛達(dá)到這個范圍的邊界的值，剛剛大于最小值以及剛剛小于最大值的值作為測試輸入數(shù)據(jù)。假設(shè)有一個函數(shù)f（x），唯一的輸入?yún)?shù)x的取值范圍為1<=x<=31（2）如果有多個輸入/輸出變量，可用邊界值+正常值的組合模式，即其中一個變量取邊界值，其他變量取正常值。假設(shè)有一個二元函數(shù)f（x、y），取值范圍為：1<=x<=31，1<=y<=12。標(biāo)準(zhǔn)邊界值為：{1、2、30、31}健壯性邊界值為：{0、1、2、30、31、32}X的健壯性邊界值為{0、1、2、30、31、32}Y的健壯性邊界值為{0、1、2、11、12、13}組合邊界值為：{<0,6>、<1,6>、