軟件工程電子教案

1、軟件測(cè)試軟件學(xué)院 內(nèi)容提綱You are here!你在這兒！軟件測(cè)試基礎(chǔ)測(cè)試的概念與原則、測(cè)試文檔軟件測(cè)試活動(dòng)軟件測(cè)試技術(shù)黑盒測(cè)試與白盒測(cè)試等價(jià)類劃分、邊界值分析路徑測(cè)試、基于狀態(tài)的測(cè)試面向?qū)ο蟮臏y(cè)試2驗(yàn)證與確認(rèn) 驗(yàn)證與確認(rèn)的基本概念與活動(dòng)模型 靜態(tài)方法：走查、檢查 基本術(shù)語(yǔ)錯(cuò)誤（Error）錯(cuò)誤是指導(dǎo)致系統(tǒng)可能包含故障的人的行為，如輸入錯(cuò)誤、需求錯(cuò)誤、設(shè)計(jì)錯(cuò)誤等。缺陷（Defect，Bug）缺陷是錯(cuò)誤的表現(xiàn)，包括過(guò)錯(cuò)缺陷和遺漏缺陷。故障（Fault）故障是指系統(tǒng)的規(guī)格說(shuō)明與其行為之間的偏差，通常由一個(gè)或多個(gè)缺陷引起。3 基本術(shù)語(yǔ)驗(yàn)證（Verification）我們是否在正確地？軟件驗(yàn)證試圖

2、證明在軟件生存周期的各個(gè)階段，軟件或中間確性。是否能夠滿足客戶需求，包括一致性、完整性和正確認(rèn)（Validation）我們是否在正確的？軟件確認(rèn)的目的是保證所開發(fā)的最終軟件的需求。能夠符合用戶說(shuō)明：驗(yàn)證強(qiáng)調(diào)對(duì)于過(guò)程的檢驗(yàn)，確認(rèn)強(qiáng)調(diào)對(duì)于結(jié)果的檢驗(yàn)。4 軟件錯(cuò)誤或缺陷軟件錯(cuò)誤（或軟件缺陷）的表現(xiàn)軟件未達(dá)到軟件出現(xiàn)了說(shuō)明書標(biāo)明的功能；說(shuō)明書指明出現(xiàn)的錯(cuò)誤；軟件功能超出了軟件未達(dá)到說(shuō)明書指明的范圍；說(shuō)明書雖未指出但應(yīng)達(dá)到的目標(biāo)；軟件測(cè)試認(rèn)為軟件難以理解、不易使用、運(yùn)行速度緩慢、或者最終用戶不滿意。有錯(cuò)是軟件的屬性，而且是無(wú)法改變的。因此，關(guān)鍵在于如何避免錯(cuò)誤的產(chǎn)生和消除已經(jīng)產(chǎn)生的錯(cuò)誤，使程序中的錯(cuò)誤密

3、度達(dá)到盡可能低的程度。5 驗(yàn)證與確認(rèn)錯(cuò)誤修復(fù)錯(cuò)誤錯(cuò)誤缺陷錯(cuò)誤缺陷故障缺陷6 這是什么？7 錯(cuò)誤的狀態(tài)8 算法錯(cuò)誤9 機(jī)械錯(cuò)誤10 處理錯(cuò)誤或缺陷：驗(yàn)證？11 處理錯(cuò)誤或缺陷：冗余？12 處理錯(cuò)誤或缺陷：特性？13 處理錯(cuò)誤或缺陷：補(bǔ)丁？14 處理錯(cuò)誤或缺陷：測(cè)試？15 另一種觀點(diǎn)錯(cuò)誤預(yù)防（在系統(tǒng)發(fā)布之前實(shí)施）使用好的程序設(shè)計(jì)方法來(lái)減少?gòu)?fù)雜性使用版本來(lái)防止系統(tǒng)的不一致應(yīng)用驗(yàn)證技術(shù)來(lái)防止算法錯(cuò)誤錯(cuò)誤檢測(cè)（運(yùn)行時(shí)實(shí)施）的方式發(fā)現(xiàn)錯(cuò)誤測(cè)試：以事先調(diào)試：假設(shè)從意外故障著手可以找到錯(cuò)誤：狀態(tài)信息，發(fā)現(xiàn)性能錯(cuò)誤錯(cuò)誤恢復(fù)（一旦系統(tǒng)發(fā)布后出現(xiàn)錯(cuò)誤時(shí)實(shí)施）數(shù)據(jù)庫(kù)系統(tǒng)：提供從故障中恢復(fù)的基本事務(wù)處理模塊冗余：將不止

4、一個(gè)組件分配執(zhí)行同一個(gè)操作恢復(fù)程序：該程序處理錯(cuò)誤信息，使系統(tǒng)從故障中恢復(fù)過(guò)來(lái)16 驗(yàn)證與確認(rèn)的活動(dòng)模型17 驗(yàn)證與確認(rèn)的活動(dòng)模型需求分析與規(guī)格說(shuō)明階段用例表示待的場(chǎng)景，有助于建立完整的系統(tǒng)，可以用于在后續(xù)的實(shí)現(xiàn)階段生成測(cè)試用例；形式化方法（如狀態(tài)機(jī)）可以自動(dòng)地檢驗(yàn)一致性和完整性等 特性；需求檢查、需求評(píng)審、原型方法設(shè)計(jì)階段斷言、抽象數(shù)據(jù)類型、契約設(shè)計(jì)等是詳細(xì)設(shè)計(jì)的驗(yàn)證工具設(shè)計(jì)走查、設(shè)計(jì)檢查、設(shè)計(jì)評(píng)審18 驗(yàn)證與確認(rèn)的活動(dòng)模型軟件實(shí)現(xiàn)階段軟件測(cè)試是一種主要的驗(yàn)證與確認(rèn)工具代碼走查、代碼檢查、代碼評(píng)審動(dòng)態(tài)工具（如斷言的動(dòng)態(tài)）驗(yàn)證與確認(rèn)的方式靜態(tài)方法：通過(guò)人工分析或程序正確性證明的方式來(lái)確認(rèn)程序的

5、正確性，包括走查、檢查等方法；動(dòng)態(tài)方法：通過(guò)動(dòng)態(tài)分析和程序測(cè)試來(lái)檢查程序執(zhí)行狀態(tài)，以確認(rèn)程序是否有問題。19 評(píng)審評(píng)審（Review）評(píng)審是由若干開發(fā)、項(xiàng)目經(jīng)理、測(cè)試、用戶或領(lǐng)域等組成一個(gè)會(huì)審小組，通過(guò)閱讀、討論和爭(zhēng)議，對(duì)工作 制品進(jìn)行靜態(tài)分析的過(guò)程。類型：需求評(píng)審、設(shè)計(jì)評(píng)審和代碼評(píng)審。評(píng)審過(guò)程小組提前把需求規(guī)格說(shuō)明、設(shè)計(jì)說(shuō)明或程序代碼及有關(guān)要求、規(guī)范等分發(fā)給小組成員，作為評(píng)審的依據(jù)；在充分閱讀有關(guān)材料后召開評(píng)審會(huì)議，主要開發(fā)進(jìn)行講解，其他成員提出問題并展開討論，是否錯(cuò)誤；評(píng)審小組形成評(píng)審的報(bào)告。20 走查走查（Walkthrough）走設(shè)計(jì)或編程組成一個(gè)走查小組，通過(guò)閱讀一段文檔或代碼，并進(jìn)

6、行提問和討論，從而發(fā)現(xiàn)可能的缺陷、遺漏和的地方。類型：設(shè)計(jì)走查、代碼走查。走查過(guò)程與評(píng)審過(guò)程類似，即先把材料先發(fā)給走查小組每個(gè)成員，讓他們認(rèn)真研究程序，然后再開會(huì)；與評(píng)審的區(qū)別：評(píng)審?fù)ǔＪ呛?jiǎn)單地讀程序或?qū)φ斟e(cuò)誤檢查表進(jìn)行檢查；走機(jī)運(yùn)行一遍，并是按照所提交的測(cè)試用例，人工模仿計(jì)算跟蹤情況。21 走查走開發(fā)者的一次友好的會(huì)議，需要仔細(xì)，并有明確的目的、日程、持續(xù)時(shí)間和參與，許多小組以為走查。走幾天：召集人將收集的一些要在會(huì)上的材料（模型、文檔、程序代碼等）分發(fā)給參與者，參與者研究這些材料并在會(huì)議之前提交意見。會(huì)議期間：召集人提出大家的意見并對(duì)每一項(xiàng)進(jìn)行討論。會(huì)議時(shí)間比較短，一般 23 小時(shí)。會(huì)議的

7、目的是查明問題，而不是干擾開發(fā)者。會(huì)議的思想是確認(rèn)問題的，甚至不必去謀求問題的解決。進(jìn)行解決。會(huì)后：將問題分發(fā)給相應(yīng)22 檢查檢查（Inspection）檢一些經(jīng)過(guò)嚴(yán)格訓(xùn)練的根據(jù)評(píng)估標(biāo)準(zhǔn)，對(duì)于開發(fā)過(guò)程中的或中間制品進(jìn)行檢查，發(fā)現(xiàn)其中的錯(cuò)誤。檢查一般是按規(guī)定程序和時(shí)間計(jì)劃進(jìn)行的，參與者來(lái)自開發(fā)、測(cè)試、質(zhì)量保證或用戶，以37人組成小組。檢查過(guò)程檢查遵循一個(gè)嚴(yán)格的過(guò)程，標(biāo)準(zhǔn)；經(jīng)過(guò)培訓(xùn)，檢查過(guò)程有評(píng)估檢查過(guò)程包括計(jì)劃、會(huì)議準(zhǔn)備、會(huì)議召開、修改錯(cuò)誤、問題跟蹤等環(huán)的是獲得項(xiàng)目管理和質(zhì)量評(píng)估的數(shù)據(jù)，并改進(jìn)檢查過(guò)程本身。23 檢查檢查也是一次友好會(huì)議但要在項(xiàng)目管理的密切監(jiān)督下完成，其目的是識(shí)別故障、驗(yàn)證它們是

8、否真的失效、這些故障點(diǎn)并安排何時(shí)及由解決。檢查之前：可能需要安排一個(gè)較短的信息通報(bào)會(huì)，一般在檢之前一個(gè)召開。在信息通報(bào)會(huì)上，由檢查的開發(fā)者先一下主題，而且檢查材料要在通報(bào)會(huì)期間或之前交給參與者。檢議：識(shí)別、軟件故障并記下個(gè)數(shù)。會(huì)議之后：召集者要做好故障日志，驗(yàn)證這些故障是否已經(jīng)解決，并決定是否需要進(jìn)一步檢查。24 內(nèi)容提綱驗(yàn)證與確認(rèn)驗(yàn)證與確認(rèn)的基本概念與活動(dòng)模型靜態(tài)方法：走查、檢查You are here!你在這兒！軟件測(cè)試技術(shù)黑盒測(cè)試與白盒測(cè)試等價(jià)類劃分、邊界值分析路徑測(cè)試、基于狀態(tài)的測(cè)試面向?qū)ο蟮臏y(cè)試25 軟件測(cè)試的概念測(cè)試的定義傳統(tǒng)：測(cè)試是一種旨在評(píng)估一個(gè)程序或系統(tǒng)的屬性或能力，確定它是

9、否符合其所需結(jié)果的活動(dòng)。Myers：測(cè)試是為了發(fā)現(xiàn)錯(cuò)誤而IEEE：測(cè)試是使用人工和自動(dòng)個(gè)程序或系統(tǒng)的過(guò)程。來(lái)運(yùn)行或檢測(cè)某個(gè)系統(tǒng)的過(guò)程，其目的在于檢驗(yàn)系統(tǒng)是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別。測(cè)試的目的測(cè)試是為了證明程序有錯(cuò)，而不是證明程序無(wú)錯(cuò)誤；一個(gè)好的測(cè)試用例在于能夠發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯(cuò)誤；一個(gè)的測(cè)試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試。26 軟件測(cè)試的概念對(duì)待軟件測(cè)試的態(tài)度從用戶的角度出發(fā) 普遍希望通過(guò)軟件測(cè)試軟件中隱藏的錯(cuò)誤和缺陷，以考慮是否可接受該。從軟件開發(fā)者的角度出發(fā) 希望測(cè)試成為表明軟件中不錯(cuò)誤的過(guò)程，驗(yàn)證該軟件已正確地實(shí)現(xiàn)了用戶的要求，確立人們對(duì)軟件質(zhì)量的信心。一種正確

10、的態(tài)度發(fā)現(xiàn)錯(cuò)誤時(shí)關(guān)注于改正錯(cuò)誤，而不是埋怨具體的開發(fā)。27 軟件測(cè)試的概念軟件測(cè)試的原則應(yīng)當(dāng)把“盡早地和不斷地測(cè)試”作為軟件開發(fā)者的座右銘程序員應(yīng)避免檢查的程序設(shè)計(jì)測(cè)試用例時(shí)，應(yīng)包括合理的輸入和不合理的輸入，以及各種邊界條件，特殊情況下要充分注意測(cè)試中的群集現(xiàn)象對(duì)測(cè)試錯(cuò)誤結(jié)果一定要有一個(gè)確認(rèn)過(guò)程狀態(tài)和意外狀態(tài)制定嚴(yán)格的測(cè)試計(jì)劃，排除測(cè)試的隨意性注意回歸測(cè)試的關(guān)聯(lián)性，往往修改一個(gè)錯(cuò)誤會(huì)引起錯(cuò)誤妥善保存一切測(cè)試過(guò)程文檔，測(cè)試重現(xiàn)往往要靠測(cè)試文檔28 軟件測(cè)試文檔測(cè)試計(jì)劃（Test Plan）測(cè)試計(jì)劃是測(cè)試工作的指導(dǎo)性文檔，規(guī)定測(cè)試活動(dòng)的范圍、方法、和進(jìn)度；明確正在測(cè)試的項(xiàng)目、要測(cè)試的特性、要執(zhí)行的

11、測(cè)試任務(wù)、每個(gè)任務(wù)的風(fēng)險(xiǎn)。，以及與計(jì)劃相主要內(nèi)容：測(cè)試目標(biāo)、測(cè)試方法、測(cè)試范圍、測(cè)試試環(huán)境和工具、測(cè)試體系結(jié)構(gòu)、測(cè)試進(jìn)度表、測(cè)舉例：Test Plan for VS.NET Speech SDK Beta129 軟件測(cè)試文檔測(cè)試規(guī)范（Test Specification）測(cè)試規(guī)范是從整體上規(guī)定測(cè)試案例的運(yùn)行環(huán)境、測(cè)試方法、生成步驟、執(zhí)行步驟以及調(diào)試和驗(yàn)證的步驟。 主要內(nèi)容：系統(tǒng)運(yùn)行環(huán)境、總體測(cè)試方法、測(cè)試用例的生成步驟、測(cè)試用例的執(zhí)行步驟、調(diào)試和驗(yàn)證舉例：Test Specification for VS.NET Speech SDK Beta130 軟件測(cè)試文檔測(cè)試用例（Test Case）

12、測(cè)試用例是數(shù)據(jù)輸入和期望結(jié)果組成的對(duì)，其中“輸入”是對(duì)被測(cè)軟件接收外界數(shù)據(jù)的描述，“期望結(jié)果”是對(duì)于相應(yīng)輸入軟件 應(yīng)該出現(xiàn)的輸出結(jié)果的描述，測(cè)試用例還應(yīng)明確指出使用具體測(cè)試案例產(chǎn)生的測(cè)試程序的任何限制。測(cè)試用例可以被組織成一個(gè)測(cè)試系列，即為實(shí)現(xiàn)某個(gè)特定的 測(cè)試目的而設(shè)計(jì)的一組測(cè)試用例。例如，一部分測(cè)試用例用來(lái)測(cè)試系統(tǒng)的兼容性，另一部分是用來(lái)測(cè)試系統(tǒng)在特定的環(huán)境中，系統(tǒng)的典型應(yīng)用是否能夠很好地。舉例：Test Case for VS.NET Speech SDK Beta131 軟件測(cè)試文檔缺陷報(bào)告 （Bug Report）缺陷報(bào)告是編寫在需要，簡(jiǎn)而言之，就是研究的測(cè)試過(guò)程期間發(fā)生的任何軟件缺陷

13、。主要內(nèi)容：缺陷編號(hào)、題目、狀態(tài)、提出、解決、所屬項(xiàng)目、測(cè)試環(huán)境、缺限報(bào)告步驟、期待結(jié)果、附件在報(bào)告缺陷時(shí)，一般要講明缺陷的嚴(yán)重性和優(yōu)先級(jí)。嚴(yán)重性表示軟件的惡劣程度，反映其對(duì)和用戶的影響。優(yōu)先級(jí)表示修復(fù)缺陷的重要程度和應(yīng)該何時(shí)修復(fù)。舉例：Bug Report for VS.NET Speech SDK Beta132 軟件測(cè)試Professional TesterProgammertoo familiar with codeAnalystTest TeamSystem DesignerUserConfiguration Management Specialist33軟件測(cè)試的綜合素質(zhì)能力理想的

14、測(cè)試必須能與測(cè)試涉及到的所有人，具有與技）的交流能力。術(shù)移情能力（開發(fā)者）和（客戶、管理和系統(tǒng)開發(fā)有所有（用戶、開發(fā)者、管理者）都處于一種既關(guān)心又擔(dān)心的狀態(tài)中。測(cè)試必須和每一類人打交道，因此需要對(duì)每一類人都具有足夠的理解和同情，從而將測(cè)試與相關(guān)人員之間的技術(shù)能力和對(duì)抗減少到最低程度。一個(gè)測(cè)試必須既明白被測(cè)軟件系統(tǒng)的概念又要會(huì)使用工程中的那些工具，最好有幾年以上的編程經(jīng)驗(yàn)，從而有助于對(duì)軟件開發(fā)過(guò)程的較深入理解。34軟件測(cè)試的綜合素質(zhì)自信心開發(fā)指責(zé)測(cè)試出了錯(cuò)是常有的事，測(cè)試必須對(duì)的觀點(diǎn)有足夠的自信心。外交能力當(dāng)你告訴他出了錯(cuò)時(shí)，就必須使用一些外交方法，機(jī)智老練和外交手法有助于維護(hù)與開發(fā)幽默感之間的

15、協(xié)作關(guān)系。在遇到狡辯的情況下，一個(gè)幽默的批評(píng)將是很有幫助的。很強(qiáng)的記憶力理想的測(cè)試應(yīng)該有能力將以前曾經(jīng)遇到過(guò)的類似的錯(cuò)誤從記憶深處挖掘出來(lái)，這一能力在測(cè)試過(guò)程中的價(jià)值是無(wú)法衡量的。35軟件測(cè)試的綜合素質(zhì)耐心一些質(zhì)量保證工作需要難以置信的耐心，有時(shí)你需要花費(fèi)驚人的時(shí)間去分離、識(shí)別和分派一個(gè)錯(cuò)誤。懷疑精神開發(fā)會(huì)盡他們最大的努力將所有的錯(cuò)誤解釋過(guò)去，測(cè)式必每個(gè)人的說(shuō)明，但他必須保持懷疑直到他自我督促看過(guò)以后。干測(cè)試工作很容易使你變得懶散，只有那些具有自我督促能力的人才能夠使洞察力每天正常地工作。一個(gè)好的測(cè)試具有“測(cè)試是為了破壞”的觀點(diǎn)，捕獲用戶觀點(diǎn)的能力，強(qiáng)烈的質(zhì)量追求，對(duì)細(xì)節(jié)的關(guān)注能力。36 軟件

16、測(cè)試活動(dòng)Subsystem CodeUnit TestTested SubsystemSystem Design SpecificationRequirement SpecificationSubsystem CodeUnit TestUser ManualTested SubsystemIntegration TestFunctional TestIntegrated SubsystemsFunctioning SystemTested SubsystemSubsystem CodeUnit Test37 軟件測(cè)試活動(dòng)Functioning SystemValidated SystemAcc

17、epted SystemPerformance TestAcceptance TestInstallation TestUsable SystemSystem in Use38 軟件測(cè)試的 V 模型39 單元測(cè)試單元測(cè)試（Unit Testing）單元測(cè)試是對(duì)軟件基本組成單元進(jìn)行的測(cè)試，有時(shí)也稱“組件測(cè)試”。單元測(cè)試一般由編寫該單元代碼的開發(fā)執(zhí)行，該負(fù)責(zé)設(shè)計(jì)和運(yùn)行一系列的測(cè)試以確保該單元符合需求。單元測(cè)試的目的驗(yàn)證代碼是與設(shè)計(jì)相符的跟蹤需求和設(shè)計(jì)的實(shí)現(xiàn)發(fā)現(xiàn)設(shè)計(jì)和需求中的錯(cuò)誤發(fā)現(xiàn)在編碼過(guò)程中引入的錯(cuò)誤40 單元測(cè)試單元測(cè)試分析模塊接口局部數(shù)據(jù)結(jié)構(gòu)出錯(cuò)處理單元測(cè)試路徑邊界條件41 單元測(cè)試單元測(cè)試

18、環(huán)境驅(qū)動(dòng)模塊：模擬被測(cè)模塊的上一級(jí)模塊樁模塊：模擬被測(cè)單元需調(diào)用的其他函數(shù)接口 單元測(cè)試的動(dòng)態(tài)環(huán)境：生成測(cè)試數(shù)據(jù)測(cè)試結(jié)果被測(cè)單元樁模塊 2樁模塊 342 單元測(cè)試：Junit43 集成測(cè)試集成測(cè)試（Integration Testing）集成測(cè)試是在單元測(cè)試的基礎(chǔ)上，將所有模塊按照總體設(shè)計(jì)的要求組裝成為子系統(tǒng)或系統(tǒng)進(jìn)行的測(cè)試。集成測(cè)試的對(duì)象是模塊間的接口，其目的是找出在模塊接口 上，包括系統(tǒng)體系結(jié)構(gòu)上的問題。集成測(cè)試策略基于層次的集成：自頂上下與自底向上基于功能的集成：按照功能的優(yōu)先級(jí)逐步將模塊加入系統(tǒng)中 基于進(jìn)度的集成：把最早可獲得的代碼進(jìn)行集成基于使用的集成：通過(guò)類的使用關(guān)系進(jìn)行集成44

19、系統(tǒng)測(cè)試系統(tǒng)測(cè)試（System Testing）系統(tǒng)測(cè)試是將已經(jīng)集成好的軟件系統(tǒng)作為一個(gè)元素，與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和等其他元素結(jié)合在一起，在實(shí)際運(yùn)行環(huán)境下進(jìn)行的一系列測(cè)試。系統(tǒng)測(cè)試方法功能測(cè)試、協(xié)議一致性測(cè)試性能測(cè)試、測(cè)試、容量測(cè)試、安全性測(cè)試、恢復(fù)測(cè)試備份測(cè)試、GUI 測(cè)試、健壯性測(cè)試、兼容性測(cè)試、可用性測(cè)試安裝測(cè)試、文檔測(cè)試、測(cè)試、數(shù)據(jù)轉(zhuǎn)換測(cè)試45 系統(tǒng)測(cè)試功能測(cè)試（Functional Testing）功能測(cè)試是系統(tǒng)測(cè)試中最基本的測(cè)試，它不管軟件內(nèi)部的實(shí)現(xiàn)邏輯，主要根據(jù)軟件需求規(guī)格說(shuō)明和測(cè)試需求列表，驗(yàn)證 的功能實(shí)現(xiàn)是否符合需求規(guī)格。功能測(cè)試主要發(fā)現(xiàn)以下錯(cuò)誤：是否有不正

20、確或遺漏的功能？功能實(shí)現(xiàn)是否滿足用戶需求和系統(tǒng)設(shè)計(jì)的隱藏需求？ 能否正確地接受輸入？能否正確地輸出結(jié)果？常用的測(cè)試技術(shù) 黑盒測(cè)試方法：等價(jià)類劃分、邊界值測(cè)試46 系統(tǒng)測(cè)試測(cè)試（Press Testing）測(cè)試是檢查系統(tǒng)在超負(fù)荷情況下的表現(xiàn)，特別是對(duì)系統(tǒng)的處理時(shí)間有什么影響。測(cè)試的例子對(duì)于一個(gè)固定輸入速率（如每分鐘 120 個(gè)單詞）的單詞處理響應(yīng)時(shí)間在一個(gè)非常短的時(shí)間內(nèi)引入超負(fù)荷的數(shù)據(jù)容量成千上萬(wàn)的用戶在同一時(shí)間從網(wǎng)上登錄到系統(tǒng)引入需要大量?jī)?nèi)存的操作測(cè)試采用邊界值和錯(cuò)誤猜測(cè)方法，且需要工具的支持。47 系統(tǒng)測(cè)試安全性測(cè)試（Security Testing）安全性測(cè)試檢查系統(tǒng)對(duì)安全性測(cè)試期間，測(cè)試

21、侵入的防范能力。假扮者，采用各種辦法試圖防線。安全性測(cè)試的例子想方設(shè)法截取或破譯口令專門定做軟件破壞系統(tǒng)的保護(hù)機(jī)制故意導(dǎo)致系統(tǒng)失敗，企圖趁恢復(fù)之機(jī)進(jìn)入試圖通過(guò)瀏覽非數(shù)據(jù)，推導(dǎo)所需信息48 系統(tǒng)測(cè)試恢復(fù)測(cè)試（Recovery Testing）恢復(fù)測(cè)試是檢驗(yàn)系統(tǒng)從軟件或者硬件失敗中恢復(fù)的能力，即采用各種人工干預(yù)方式使軟件出錯(cuò)，而不能正常工作，從而 檢驗(yàn)系統(tǒng)的恢復(fù)能力?；謴?fù)性測(cè)試的例子當(dāng)供電出現(xiàn)問題時(shí)的恢復(fù)恢復(fù)程序的執(zhí)行對(duì)選擇的文件和數(shù)據(jù)進(jìn)行恢復(fù)恢復(fù)處理日志方面的能力通過(guò)切換到一個(gè)并行系統(tǒng)來(lái)進(jìn)行恢復(fù)49 系統(tǒng)測(cè)試 GUI 測(cè)試（Graphic User Interface Testing）GUI 測(cè)

22、試一是檢查用戶界面實(shí)現(xiàn)與設(shè)計(jì)的符合情況，二是確認(rèn)用戶界面處理的正確性。GUI 測(cè)試提倡界面與功能的設(shè)計(jì)分離，其重點(diǎn)關(guān)注在界面層和界面與功能接口層上。GUI 自動(dòng)化測(cè)試工具 WinRunner，QARun，QARobot，Visual Test常用的測(cè)試技術(shù) 等價(jià)類劃分、邊界值分析、基于狀態(tài)圖方法、錯(cuò)誤猜測(cè)法50 系統(tǒng)測(cè)試安裝測(cè)試（Installation Testing）系統(tǒng)驗(yàn)收之后，需要在目標(biāo)環(huán)境中進(jìn)行安裝，其目的是保證應(yīng)用程序能夠被安裝測(cè)試應(yīng)考慮地安裝。應(yīng)用程序是否可以應(yīng)用程序是否可以地安裝在以前從未安裝過(guò)的環(huán)境中？地安裝在以前已有的環(huán)境中？配置信息定義正確嗎？考慮到以前的配置信息嗎？ 文

23、檔安裝正確嗎？安裝應(yīng)用程序是否會(huì)影響其他的應(yīng)用程序嗎？安裝程序是否可以檢測(cè)到的情況并做出適當(dāng)?shù)姆磻?yīng)？51 驗(yàn)收測(cè)試驗(yàn)收測(cè)試（Acceptance Testing）驗(yàn)收測(cè)試是以用戶為主的測(cè)試，一般使用用戶環(huán)境中的實(shí)際數(shù)據(jù)進(jìn)試。在測(cè)試過(guò)程中，除了考慮軟件的功能和性能外，還應(yīng)對(duì)軟件的兼容性、可維護(hù)性、錯(cuò)誤的恢復(fù)功能等進(jìn)行確認(rèn)。測(cè)試與測(cè)試測(cè)試與測(cè)試是在正式發(fā)布前經(jīng)常進(jìn)行的兩種測(cè)試； 測(cè)試是由用戶在開發(fā)環(huán)境下進(jìn)行的測(cè)試； 測(cè)試是由軟件的多個(gè)用戶在實(shí)際使用環(huán)境下進(jìn)行的測(cè)試。問題：微軟公司如何進(jìn)行其的測(cè)試？52 回歸測(cè)試回歸測(cè)試（Regression Testing）回歸測(cè)試是驗(yàn)證對(duì)系統(tǒng)的變更沒有影響以前的

24、功能，并且保證當(dāng)前功能的變更是正確的。回歸測(cè)試可以發(fā)生在軟件測(cè)試的任何階段，包括單元測(cè)試、集成測(cè)試和系統(tǒng)測(cè)試，其令人煩惱的勞動(dòng)?；貧w測(cè)試應(yīng)考慮的因素 范圍：有選擇地執(zhí)行以前的測(cè)試用例；在于頻繁的重復(fù)性 自動(dòng)化：測(cè)試程序的自動(dòng)執(zhí)行和自動(dòng)配置、測(cè)試用例的管理和自動(dòng)輸入、測(cè)試結(jié)果的自動(dòng)和比較、測(cè)試結(jié)論的自動(dòng)輸出。53 內(nèi)容提綱驗(yàn)證與確認(rèn)驗(yàn)證與確認(rèn)的基本概念與活動(dòng)模型靜態(tài)方法：走查、檢查軟件測(cè)試基礎(chǔ)測(cè)試的概念與原則、測(cè)試文檔軟件測(cè)試活動(dòng)You are here!你在這兒！54 黑盒測(cè)試黑盒測(cè)試（Black Box Testing）又稱功能測(cè)試，它將測(cè)試對(duì)象看做一個(gè)黑盒子，完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和

25、內(nèi)部特性，只依據(jù)程序的需求規(guī)格說(shuō) 明書，檢查程序的功能是否符合它的功能說(shuō)明。問題：用黑盒測(cè)試發(fā)現(xiàn)程序中的錯(cuò)誤，必須在所有可能的輸 入條件和輸出條件中確定測(cè)試數(shù)據(jù)，來(lái)檢查程序是否生正確的輸出，但這是不可能的。55 白盒測(cè)試白盒測(cè)試（White Box Testing）又稱結(jié)構(gòu)測(cè)試，它把測(cè)試對(duì)象看做一個(gè)透明的盒子，它測(cè)試?yán)贸绦騼?nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設(shè)計(jì)或選擇測(cè)試用例，對(duì)程序所有邏輯路徑進(jìn)試。問題：對(duì)一個(gè)具有多重選擇和循環(huán)嵌套的程序，不同的路徑數(shù)目可能是天文數(shù)字。56 等價(jià)類劃分等價(jià)類劃分等價(jià)類劃分是黑盒測(cè)試技術(shù)，可將測(cè)試用例數(shù)量降到最少。等價(jià)類劃分是將可能的輸入劃分成若干等價(jià)的類，每一個(gè)類

26、選擇一個(gè)測(cè)試用例，這種方法假設(shè)對(duì)于一個(gè)類的所有成員來(lái) 說(shuō)，系統(tǒng)通常按照類似的方式運(yùn)行。關(guān)鍵步驟：確定等價(jià)類和選擇測(cè)試輸入基本原則：每個(gè)可能的輸入屬于某一個(gè)等價(jià)類任何輸入都屬于多個(gè)等價(jià)類用等價(jià)類的某個(gè)成員作為輸入時(shí)，如果證明執(zhí)行誤差，那么用該類的任何其他成員作為輸入，也能檢查到同樣的誤差。57 邊界值分析邊界值分析邊界值分析是等價(jià)類測(cè)試的特例，主要是考慮等價(jià)類的邊界條件，在等價(jià)類的“邊緣”選擇元素。在 R1, R2 的取值區(qū)間中，應(yīng)如何選擇？等價(jià)類與邊界測(cè)試的缺點(diǎn)沒有考慮測(cè)試輸入數(shù)據(jù)的組合，在很多情況下程序出現(xiàn)故障是因?yàn)槟承┲档慕M合引起了誤差。58 舉例：Date舉例：設(shè)計(jì) Date:incre

27、ment ( ) 的測(cè)試用例問題：你認(rèn)為以下的等價(jià)類劃分是否恰當(dāng)？D1 = 1day31 M1 = 1month12 Y1 = 1812year2012 59Datedd : Daymm : Month yy : YearDate(pDay : Integer, pMonth : Integer, pYear : Integer) increment()printDate() 舉例：Date另一種劃分方法D1 = 1datelast day of the month D2 = last day of the month D3 = Dec. 31 M1 = 30-day months M2 =

28、31-day months M3 = Feb. Y1 = 2000 Y2 = leap year Y3 = not leap year 60 舉例：Date61序號(hào)MonthDayYear期望輸出1234567891011122222222222221414142828282929293030302000199620022000199620022000199620022000199620022000年2月15日1996年2月15日2002年2月15日2000年2月29日1996年2月29日2002年3月 1日2000年3月 1日1996年3月 1日無(wú)效的輸入日期無(wú)效的輸入日期無(wú)效的輸入日期無(wú)效

29、的輸入日期 舉例：Date62序號(hào)MonthDayYear期望輸出1314151617181920212223246666666666661414142929293030303131312000199620022000199620022000199620022000199620022000年6月15日1996年6月15日2002年6月15日2000年6月30日1996年6月30日2002年6月30日2000年7月 1日1996年7月 1日2002年7月 1日無(wú)效的輸入日期無(wú)效的輸入日期無(wú)效的輸入日期 舉例：Date63序號(hào)MonthDayYear期望輸出25262728293031323334

30、35368888888888881414142929293030303131312000199620022000199620022000199620022000199620022000年8月15日1996年8月15日2002年8月15日2000年8月30日1996年8月30日2002年8月30日2000年8月31日1996年8月31日2002年8月31日2000年9月 1日1996年9月 1日2002年9月 1日 舉例：Date64序號(hào)MonthDayYear期望輸出37383940414243444546474812121213131333901 1131313101412000199620

31、022000199620022000199600200020022001年1月 1日1997年1月 1日2003年1月 1日無(wú)效的輸入日期無(wú)效的輸入日期無(wú)效的輸入日期無(wú)效的輸入日期無(wú)效的輸入日期無(wú)效的輸入日期無(wú)效的輸入日期無(wú)效的輸入日期無(wú)效的輸入日期 路徑測(cè)試路徑測(cè)試路徑測(cè)試是確定組件實(shí)現(xiàn)中錯(cuò)誤的白盒測(cè)試技術(shù)，它假設(shè)通過(guò)至少一次代碼的所有可能路徑，大多數(shù)錯(cuò)誤將引起故障。路徑測(cè)試是在程序流圖的基礎(chǔ)上，分析構(gòu)造的環(huán)路復(fù)雜性，導(dǎo)出基本可執(zhí)行路徑集合，由此設(shè)計(jì)測(cè)試用例，并保證在測(cè)試中程序的每一個(gè)可執(zhí)行語(yǔ)句至少要次。程序流圖符號(hào) 為程序語(yǔ)句。流圖的一個(gè)結(jié)點(diǎn)，表示一個(gè)或多個(gè)無(wú)分支的源箭頭為邊，表示流的方向

32、。65 路徑測(cè)試path1：111 path2：1234510111path3：12368910111 path4：1236791011166 舉例：SelectSort舉例：函數(shù) SelectSort ( ) 的代碼Void SelectSort( datalist & list ) for (int i=0; i<list.n-1; i+) int k=i;for (int j=i+1; j<list.n; j+)if (list.Vj.getKey() < list.Vk.getKey()k=j;if (k!=i)Swap(list.Vi, list.Vk);問

33、題：如何使用路徑測(cè)試方法設(shè)計(jì)測(cè)試用例？67 舉例：SelectSort1returni<n-135path1: 13path2: 1258 path3: 1259 path4: 1246 path5: 1247 i<>k987Vi<->Vki=i+1;68j<n4Vj<Vk6k=j;j=j+1;2k=i; j=i+1; 舉例：SelectSort測(cè)試用例Path1：取 n=1Path2：取 n=2預(yù)期結(jié)果：路徑 583 不可到達(dá)Path3：取 n=2預(yù)期結(jié)果：路徑 593 不可到達(dá)路徑1246583：取 n=2，v0=2, v1=1預(yù)期結(jié)果： k=1,

34、 v0=1, v1=2路徑1246593：取 n=2，v0=2, v1=1預(yù)期結(jié)果： k=1, 路徑 93 不可到達(dá)69 舉例：SelectSort測(cè)試用例路徑1247583：取 n=2，v0=1, v1=2預(yù)期結(jié)果： k=0, 路徑 83 不可到達(dá)路徑1247593：取 n=2，v0=1, v1=2預(yù)期結(jié)果： k=0, v0=1, v1=2說(shuō)明：路徑測(cè)試技術(shù)不適合面向?qū)ο笳Z(yǔ)言，例如多態(tài)性可以與不同的方法綁定，因此所有的綁定都需要確定并測(cè)試。70 基于狀態(tài)的測(cè)試基于狀態(tài)的測(cè)試基于狀態(tài)的測(cè)試主要考慮面向?qū)ο笙到y(tǒng)，它根據(jù)系統(tǒng)的特定狀態(tài)選擇大量的測(cè)試輸入，測(cè)試某個(gè)組件或系統(tǒng)，并將實(shí)際的輸出與預(yù)期的結(jié)

35、果相比較。在類環(huán)境中，從類的 UML 狀態(tài)圖中得出測(cè)試用例組成基于狀態(tài)的測(cè)試。舉例：測(cè)試 CourseOffering 類71<<entity>> CourseOfferingcourseID : String startTime : Time endTime : Time days : Enum/ numStudents : Int offeringStatus : Enum<<class>> new ()addStudent(studentS chedule : Schdule) removeStudent(studentS chedule

36、: Schdule) getNumberOfStudents() : int addProfessor(theProfessor : Professor) removeProcessor(theProfessor : Professor) offeringStillOpen() : BooleancloseRegistration() cancelOffering() closeOffering() getCourseOffering()setCourseID(courseID : String) setStartTime(startTim e : Time) setEndTime(endTi

37、me : Time) setDays(days : Enum) 舉例：CourseOffering72 舉例：CourseOffering73IDPreconditionEventPredicted Result1Initial statenew ( )offeringStatus = unassigned; numStudents = 02“unassigned” state numStudents = 0addStudent ()offeringStatus = unassigned; numStudents = 13“unassigned” state numStudents = 0re

38、moveStudent ()offeringStatus = unassigned; numStudents = 0;Display error message4“unassigned” state numStudents = 10addStudent ()offeringStatus = unassigned; numStudents = 10;Display message5“unassigned” state numStudents = 10removeStudent ()offeringStatus = unassigned; numStudents = 9;6“unassigned”

39、 stateaddProfessor ()offeringStatus = assigned7“unassigned” statecloseOffering ( )offeringStatus = cancelled 舉例：CourseOffering74IDPreconditionEventPredicted Result8“unassigned” statecloseRegistration ( )offeringStatus = cancelled9“unassigned” statecancelOffering ( )offeringStatus = cancelled10“assig

40、ned” state numStudents = 0addStudent ()offeringStatus = assigned; numStudents = 111“assigned” state numStudents = 0removeStudent ()offeringStatus = assigned; numStudents = 0;Display error message12“assigned” state numStudents = 9addStudent ()offeringStatus = full; numStudents = 10;13“assigned” state

41、 numStudents = 9removeStudent ()offeringStatus = assigned; numStudents = 8;14“assigned” stateremoveProfessor ()offeringStatus = unassigned15“assigned” stateaddProfessor ()offeringStatus = assigned; Display message 舉例：CourseOffering75IDPreconditionEventPredicted Result16“assigned” state numStudents =

42、 2closeOffering ( )offeringStatus = cancelled17“assigned” state numStudents = 3closeOffering ( )offeringStatus = committed18“assigned” state numStudents = 3closeRegistration ( )offeringStatus = committed19“assigned” statecancelOffering ( )offeringStatus = cancelled20“full” statecancelOffering ( )off

43、eringStatus = cancelled21“full” statecloseOffering ( )offeringStatus = committed22“full” statecloseRegistration ( )offeringStatus = committedYou can choose some cases for exceptional transition in any state 舉例：二進(jìn)制加法器.5.Press button “C”：clear the resultPress button “0”：input 0 Press button “1”

44、：input 1 Press button “+”：addPress button “=”：display the result76 舉例：二進(jìn)制加法器KeyPress( "C" ) / Op1="0":Op2="0"Enter Op1KeyPress( "1" ) / Op1="1"do/ Dis play Op1 in the resultevent KeyPress( "0" ) Op1<>"0" and Len(Op1)<20 /

45、 Add "0" after Op1 event KeyPress( "1" ) Op1<>"0" and Len(Op1)<20 / Add "1" after Op1 event KeyPress( "1" ) Op1="0 " / Op1="1"KeyPress( "0" ) / Op1="0"KeyPress( "C" ) / Op1="0":Op2="0"Display resultKeyPress( "=" ) / Op2="0"KeyPre ss( "+" ) / Op2="0"KeyPress( "+" ) / Op2="0 &quo