《現(xiàn)代軟件工程》課件

1、現(xiàn)代軟件工程第七部分現(xiàn)代軟件工程的質(zhì)量保證 現(xiàn)代軟件工程的質(zhì)量保證過程-1軟件測(cè)試組織與管理-2質(zhì)量評(píng)審與軟件可靠性設(shè)計(jì)-3配置管理方法與實(shí)踐-4第七部分 現(xiàn)代軟件工程的質(zhì)量保證第二章 軟件測(cè)試組織與管理 軟件測(cè)試的方法選擇和運(yùn)用-2.1軟件測(cè)試的組織與計(jì)劃-2.2軟件測(cè)試活動(dòng)的過程管理-2.3軟件測(cè)試結(jié)果評(píng)價(jià)與應(yīng)用-2.4 第七部分 現(xiàn)代軟件工程的質(zhì)量保證四、軟件測(cè)試軟件開發(fā)過程必須伴有質(zhì)量保證活動(dòng)。 軟件測(cè)試是軟件質(zhì)量保證的關(guān)鍵元素，代表了規(guī)約、設(shè)計(jì)和編碼的最終檢查。 軟件產(chǎn)品最大的成本是檢測(cè)軟件錯(cuò)誤、修正軟件錯(cuò)誤的成本。 在整個(gè)軟件開發(fā)中，測(cè)試工作量 一般占 30%40%，甚至50%。

2、在人命關(guān)天的軟件(如飛機(jī)控制、核反應(yīng)堆等）測(cè)試所花費(fèi)的時(shí)間往往是其它軟件工程活動(dòng)時(shí)間之和的三到五倍軟件測(cè)試背景軟件是人編的所以不完美實(shí)例:1994-1995,迪斯尼的獅子王系統(tǒng)不支持問題Intel 的 pentium 處理器1994 年浮點(diǎn)除法缺陷2000 年 8 月 28 日，1.13 MHZ 處理器一個(gè)可能導(dǎo)致運(yùn)行程序被掛起的執(zhí)行指令問題1999年12月3日,美國航天局火星極地登陸飛船失蹤1991年愛國者導(dǎo)彈防御系統(tǒng)系統(tǒng)時(shí)鐘錯(cuò)誤積累造成跟蹤系統(tǒng)失去精確度千年蟲,世界各地解決2000年錯(cuò)誤超過數(shù)億美元測(cè)試模仿測(cè)試與開發(fā)前期工作的關(guān)系測(cè)試過程：依相反順序安排的自底向上、逐步集成的過程。軟件測(cè)試

3、的重要性及其工作步驟測(cè)試是保證軟件質(zhì)量,提高軟件可靠性的關(guān)鍵測(cè)試階段工作步驟單元測(cè)試: 檢驗(yàn)每個(gè)模塊能否單獨(dú)工作.集成測(cè)試: 檢驗(yàn)概要設(shè)計(jì)中模塊接口設(shè)計(jì)問題確認(rèn)測(cè)試: 以需求規(guī)格說明書為檢驗(yàn)尺度系統(tǒng)測(cè)試: 綜合檢驗(yàn) 測(cè)試可視為分析、設(shè)計(jì)、編碼三個(gè)階段的最終復(fù)審,以保證軟件質(zhì)量.測(cè)試原則（9條）所有的測(cè)試都應(yīng)追溯到用戶需求概要設(shè)計(jì)時(shí)應(yīng)完成測(cè)試計(jì)劃pareto原則：測(cè)試發(fā)現(xiàn)的錯(cuò)誤中80%很可能起源于20%的模塊中。應(yīng)孤立這些疑點(diǎn)模塊重點(diǎn)測(cè)試。窮舉測(cè)試是不可能的。應(yīng)由獨(dú)立的第三方構(gòu)造測(cè)試(開發(fā)和測(cè)試隊(duì)伍分別建立)。測(cè)試用例應(yīng)由輸入數(shù)據(jù)和預(yù)期的輸出結(jié)果兩部分組成.兼顧合理的輸入和不合理的輸入數(shù)據(jù)程序修

4、改后要回歸測(cè)試應(yīng)長期保留測(cè)試用例，直至系統(tǒng)廢棄。測(cè)試的方法與技術(shù)軟件測(cè)試的策略和方法靜態(tài)測(cè)試方法動(dòng)態(tài)測(cè)試方法人工測(cè)試方法計(jì)算機(jī)輔助靜態(tài)分析方法白盒測(cè)試方法黑盒測(cè)試方法靜態(tài)測(cè)試約可找出3070%的邏輯設(shè)計(jì)錯(cuò)誤.動(dòng)態(tài)黑盒測(cè)試 閉著眼睛測(cè)試軟件軟件輸入 不深入代碼細(xì)節(jié)的測(cè)試方法稱為動(dòng)態(tài)黑盒測(cè)試。軟件測(cè)試員充當(dāng)客戶來使用它。輸出動(dòng)態(tài)白盒測(cè)試 帶上X光眼鏡測(cè)試軟件?3581322.293419985680302829734315250*(1+0.015)*(1+0.015)360-1)/0.015250*(1+0.015)*(1+0.015)360-1)/0.015 假如知道一個(gè)盒子包含一臺(tái)計(jì)算機(jī),而另

5、一個(gè)盒子是人用紙筆計(jì)算,就會(huì)選擇不同的測(cè)試用例了解軟件的運(yùn)作方式會(huì)影響測(cè)試手段黑盒測(cè)試與白盒測(cè)試比較黑盒測(cè)試:功能測(cè)試、 數(shù)據(jù)驅(qū)動(dòng)測(cè)試、 基于規(guī)格說明書的測(cè)試 是從用戶觀點(diǎn)，按規(guī)格說明書要求的輸入數(shù)據(jù) 與輸出數(shù)據(jù)的對(duì)應(yīng)關(guān)系設(shè)計(jì)測(cè)試用例,是根據(jù)程序外部特征進(jìn)行測(cè)試。白盒測(cè)試：開盒測(cè)試 結(jié)構(gòu)測(cè)試 玻璃盒測(cè)試 基于覆蓋的測(cè)試. 是根據(jù)程序內(nèi)部邏輯結(jié)構(gòu)進(jìn)行測(cè)試黑盒測(cè)試與白盒測(cè)試優(yōu)缺點(diǎn)比較黑盒測(cè)試 白盒測(cè)試 優(yōu)點(diǎn)缺點(diǎn)性質(zhì)適用于各階段測(cè)試從產(chǎn)品功能角度測(cè)試容易入手生成測(cè)試數(shù)據(jù)可構(gòu)成測(cè)試數(shù)據(jù)使特定程 序部分得到測(cè)試有一定的充分性度量手段可或較多工具支持某些代碼得不到測(cè)試如果規(guī)格說明有誤， 則無法發(fā)現(xiàn)不易進(jìn)行

6、充分性測(cè)試不易生成測(cè)試數(shù)據(jù)(通常)無法對(duì)未實(shí)現(xiàn)規(guī)格說明的 部分進(jìn)行測(cè)試工作量大，通常只用于單 元測(cè)試，有應(yīng)用局限是一種確認(rèn)技術(shù)，回答“我們?cè)跇?gòu)造一個(gè)正確 的系統(tǒng)嗎？”是一種驗(yàn)證技術(shù)，回答“我們?cè)谡_ 地構(gòu)造一個(gè)系 統(tǒng)嗎？”自頂向下和自底向上的測(cè)試區(qū)別 自頂向下 自底向上優(yōu)點(diǎn) 可在測(cè)試早期 實(shí)現(xiàn)并驗(yàn)證系 設(shè)計(jì)測(cè)試用例容易 統(tǒng)主要功能 缺點(diǎn) 不需驅(qū)動(dòng)模塊 不需樁模塊 需樁模塊 只有到最后程序才 能作為一個(gè)整體混合集成測(cè)試方法一般對(duì)軟件結(jié)構(gòu)的上層使用自頂向下結(jié)合的方法;對(duì)下層使用自底向上結(jié)合的方法;測(cè)試避免 軟件測(cè)試不等于程序測(cè)試 軟件測(cè)試應(yīng)貫穿于軟件定義與開發(fā)的整個(gè)期間； 據(jù)美國一家公司統(tǒng)計(jì)，查出

7、的軟件錯(cuò)誤中，屬于需求分析和軟件設(shè)計(jì)的錯(cuò)誤約占 64%，屬于程序編寫的錯(cuò)誤僅占 36%。程序編寫的許多錯(cuò)誤是“先天的”。 不論黑盒還是白盒測(cè)試都不能進(jìn)行窮盡測(cè)試, 所以軟件測(cè)試不可能發(fā)現(xiàn)程序中存在的所有錯(cuò)誤, 因此需精心設(shè)計(jì)測(cè)試方案,力爭盡可能少的次數(shù),測(cè)出盡可能多的錯(cuò)誤課程設(shè)計(jì)提交文檔： 可行性研究報(bào)告 項(xiàng)目開發(fā)計(jì)劃 需求規(guī)格說明書 概要設(shè)計(jì)說明書 詳細(xì)設(shè)計(jì)說明書 數(shù)據(jù)庫設(shè)計(jì)說明書 測(cè)試計(jì)劃 測(cè)試分析報(bào)告 項(xiàng)目總結(jié)報(bào)告操作手冊(cè)用戶手冊(cè)開發(fā)進(jìn)度周報(bào)目錄1. 測(cè)試的常識(shí)與道理 2. 測(cè)試的分類與比較3. 測(cè)試人員的組織4. 企業(yè)的測(cè)試策略5. 測(cè)試規(guī)范6. 軟件產(chǎn)品的主要測(cè)試內(nèi)容及技術(shù)世上不存在

8、沒有缺陷的軟件1. 測(cè)試的常識(shí)與道理1.1 你真的懂測(cè)試嗎 編程大師說：沒有錯(cuò)誤的程序世間難求。 （編程之道）你在學(xué)校里學(xué)過測(cè)試嗎？（讀到博士可能也不懂測(cè)試）你所在的企業(yè)重視測(cè)試嗎？ （小公司程序員的技能更加全面）臨時(shí)抱佛腳行嗎？你以為有文檔模板就會(huì)測(cè)試了嗎？ 如果不懂得有效地進(jìn)行測(cè)試，你不僅得不到功勞，也沒人欣賞你的苦勞，你擁有最多的將只是疲勞。 職業(yè)軟件工程師應(yīng)當(dāng)掌握需求開發(fā)、系統(tǒng)設(shè)計(jì)、編程、測(cè)試、維護(hù) 所有技能。1.2 測(cè)試的目的是什么測(cè)試的目的是為了發(fā)現(xiàn)盡可能多的缺陷，不是為了說明軟件中沒有缺陷。 推論：成功的測(cè)試在于發(fā)現(xiàn)了迄今尚未發(fā)現(xiàn)的缺陷。所以測(cè)試人員的職責(zé)是設(shè)計(jì)這樣的測(cè)試用例，它

9、能有效地揭示潛伏在軟件里的缺陷。 千萬不要將“測(cè)試”與“演示”混為一談。例如科研鑒定會(huì)。如果產(chǎn)品通過了嚴(yán)格的測(cè)試，大家不要不吭氣，應(yīng)當(dāng)好好地宣傳一把 。1. 測(cè)試的常識(shí)與道理1.3 一些常識(shí)和經(jīng)驗(yàn)之談測(cè)試能提高軟件的質(zhì)量，但是提高質(zhì)量不能依賴測(cè)試。 測(cè)試只能證明缺陷存在，不能證明缺陷不存在。“徹底地測(cè)試”難以成為現(xiàn)實(shí)，要考慮時(shí)間、費(fèi)用等限制，不允許無休止地測(cè)試。我們應(yīng)當(dāng)祈禱：軟件的缺陷在產(chǎn)品被淘汰之前一直沒有機(jī)會(huì)發(fā)作。 測(cè)試的主要困難是不知道如何進(jìn)行有效地測(cè)試，也不知道什么時(shí)候可以放心地結(jié)束測(cè)試。 每個(gè)開發(fā)人員應(yīng)當(dāng)測(cè)試自己的程序（份內(nèi)之事），但是不能作為該程序已經(jīng)通過測(cè)試的依據(jù)（所以項(xiàng)目需要獨(dú)

10、立測(cè)試人員）。 80-20原則：80的缺陷聚集在20的模塊中，經(jīng)常出錯(cuò)的模塊改錯(cuò)后還會(huì)經(jīng)常出錯(cuò)測(cè)試應(yīng)當(dāng)循序漸進(jìn)，不要企圖一次性干完，注意“欲速則不達(dá)”。 2. 測(cè)試的分類與比較2.1 測(cè)試方式白盒測(cè)試：關(guān)心軟件內(nèi)部設(shè)計(jì)和程序?qū)崿F(xiàn)，主要測(cè)試依據(jù)是設(shè)計(jì)文檔黑盒測(cè)試：不關(guān)心軟件內(nèi)部，只關(guān)心輸入輸出，主要測(cè)試依據(jù)是需求文檔2.2 測(cè)試階段單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試。是“從小到大”、“由內(nèi)至外”、“循序漸進(jìn)”的測(cè)試過程，體現(xiàn)了“分而治之”的思想。 單元測(cè)試的粒度最小，一般由開發(fā)小組采用白盒方式來測(cè)試，主要測(cè)試單元是否符合“設(shè)計(jì)”。 集成測(cè)試界于單元測(cè)試和系統(tǒng)測(cè)試之間，起到“橋梁作用”，一般由

11、開發(fā)小組采用白盒加黑盒的方式來測(cè)試，既要驗(yàn)證“設(shè)計(jì)”又要驗(yàn)證“需求”。 系統(tǒng)測(cè)試的粒度最大，一般由獨(dú)立測(cè)試小組采用黑盒方式來測(cè)試，主要測(cè)試系統(tǒng)是否符合“需求規(guī)格說明書”。 驗(yàn)收測(cè)試與系統(tǒng)測(cè)試非常相似，主要區(qū)別是測(cè)試人員不同，驗(yàn)收測(cè)試由用戶執(zhí)行。 2. 測(cè)試的分類與比較2.3 開發(fā)與測(cè)試的 V 型關(guān)系如果軟件開發(fā)過程采用嚴(yán)格的瀑布模型，那么開發(fā)與測(cè)試有“V”型的對(duì)應(yīng)關(guān)系 。需求開發(fā)高層設(shè)計(jì)詳細(xì)設(shè)計(jì)編程單元測(cè)試集成測(cè)試系統(tǒng)測(cè)試驗(yàn)收測(cè)試2. 測(cè)試的分類與比較2.4 測(cè)試內(nèi)容接口與路徑測(cè)試。 功能測(cè)試、健壯性測(cè)試、性能測(cè)試、用戶界面測(cè)試、安全性測(cè)試、壓力測(cè)試、可靠性測(cè)試、安裝/反安裝測(cè)試 測(cè)試階段 主

12、要依據(jù) 測(cè)試人員、測(cè)試方式 主要測(cè)試內(nèi)容 單元測(cè)試系統(tǒng)設(shè)計(jì)文檔由開發(fā)小組執(zhí)行白盒測(cè)試 接口測(cè)試、路徑測(cè)試 集成測(cè)試系統(tǒng)設(shè)計(jì)文檔需求文檔由開發(fā)小組執(zhí)行白盒測(cè)試和黑盒測(cè)試 接口測(cè)試、路徑測(cè)試功能測(cè)試、性能測(cè)試 系統(tǒng)測(cè)試需求文檔由獨(dú)立測(cè)試小組執(zhí)行黑盒測(cè)試 功能測(cè)試、健壯性測(cè)試、性能測(cè)試、用戶界面測(cè)試、安全性測(cè)試、壓力測(cè)試、可靠性測(cè)試、安裝/反安裝測(cè)試 驗(yàn)收測(cè)試需求文檔由用戶執(zhí)行黑盒測(cè)試 2. 測(cè)試的分類與比較2.5 問題問題1：有了“黑盒”測(cè)試為什么還要“白盒”測(cè)試？黑盒測(cè)試只能觀察軟件的外部表現(xiàn)，即使軟件的輸入輸出都是正確的，卻并不能說明軟件就是正確的。因?yàn)槌绦蛴锌赡苡缅e(cuò)誤的運(yùn)算方式得出正確的結(jié)果

13、，例如“負(fù)負(fù)得正，錯(cuò)錯(cuò)得對(duì)”，只有白盒測(cè)試才能發(fā)現(xiàn)真正的原因。白盒測(cè)試能發(fā)現(xiàn)程序里的隱患，象內(nèi)存泄漏、誤差累計(jì)問題。在這方面，黑盒測(cè)試存在嚴(yán)重的不足。 問題2：由于單元測(cè)試要寫測(cè)試驅(qū)動(dòng)程序，非常麻煩，能否等到整個(gè)系統(tǒng)全部開發(fā)完后，再集中精力進(jìn)行一次性地單元測(cè)試呢？ 如果這樣做，在開發(fā)過程中，缺陷會(huì)越積越多并且分布得更廣、隱藏得更深，反而導(dǎo)致測(cè)試與改錯(cuò)的代價(jià)大大增加。最糟糕的是無法估計(jì)測(cè)試與改錯(cuò)的工作量，使進(jìn)度失去控制。因此為圖眼前省事而省略單元測(cè)試或者“偷工減料”，是“得不償失”的做法。 問題3：如果每個(gè)單元都通過了測(cè)試，把它們集成一起難道會(huì)有什么不妥嗎？集成測(cè)試是否多此一舉？要把N個(gè)單元集成

14、一起肯定靠接口耦合，這時(shí)可能會(huì)產(chǎn)生在單元測(cè)試中無法發(fā)現(xiàn)的問題。例如：數(shù)據(jù)通過不同的接口時(shí)可能出錯(cuò)；幾個(gè)函數(shù)關(guān)聯(lián)在一起時(shí)可能達(dá)不到預(yù)期的功能；在某個(gè)單元里可以接受的誤差可能在集成后被擴(kuò)大到無法接受的程度。所以集成測(cè)試是必要的，不是多此一舉。2. 測(cè)試的分類與比較2.5 問題問題4：在集成測(cè)試的時(shí)候，已經(jīng)對(duì)一些子系統(tǒng)進(jìn)行了功能測(cè)試、性能測(cè)試等等，那么在系統(tǒng)測(cè)試時(shí)能否跳過相同內(nèi)容的測(cè)試? 不能！因?yàn)榧蓽y(cè)試是在仿真環(huán)境中開展的，那不是真正的目標(biāo)系統(tǒng)。再者，單元測(cè)試和集成測(cè)試通常由開發(fā)小組執(zhí)行。根據(jù)測(cè)試心理學(xué)的分析，開發(fā)人員測(cè)試自己的工作成果雖然是必要的，但不能作為成果已經(jīng)通過測(cè)試的依據(jù)。 問題5：既

15、然系統(tǒng)測(cè)試與驗(yàn)收測(cè)試的內(nèi)容幾乎是相同的，為什么還要驗(yàn)收測(cè)試？首先是“信任”問題。對(duì)于合同項(xiàng)目而言，如果測(cè)試小組是開發(fā)方的人員，客戶怎么能夠輕易相信“別人”呢? 所以當(dāng)項(xiàng)目進(jìn)行系統(tǒng)測(cè)試之后，客戶再進(jìn)行驗(yàn)收測(cè)試是情理之中的事。否則，那是客戶失職。 不論是合同項(xiàng)目還是非合同項(xiàng)目，軟件的最終用戶各色各樣（如受教育程度不同、使用習(xí)慣不同等等）。測(cè)試小組至多能夠模仿小部分用戶的行為，但并不具有普遍的代表性。 問題6：能否將系統(tǒng)測(cè)試和驗(yàn)收測(cè)試“合二為一”？ 系統(tǒng)測(cè)試不是一會(huì)兒就能做完的，比較長時(shí)間的用戶測(cè)試很難組織。用戶還有自己的事情要做，他們?yōu)槭裁匆獮閯e人測(cè)試呢？即使用戶愿意做系統(tǒng)測(cè)試，他們消耗的時(shí)間、花

16、費(fèi)的金錢大多比測(cè)試小組的高。系統(tǒng)測(cè)試時(shí)會(huì)找出相當(dāng)多的軟件缺陷，軟件需要反反復(fù)復(fù)地改錯(cuò)。如果讓用戶發(fā)現(xiàn)“內(nèi)幕”，一是丟臉，二是會(huì)嚇跑買主。所以還是關(guān)起門來，先讓測(cè)試小組做完系統(tǒng)測(cè)試的好。 3. 測(cè)試人員的組織3.1 了解開發(fā)人員的測(cè)試心理測(cè)試的目的是找出盡可能多的缺陷。所以測(cè)試是“破壞性”的，而開發(fā)卻是“建設(shè)性”的。開發(fā)人員總是喜歡欣賞程序的成功之處，而不愿看到失敗之處。讓開發(fā)者去做“蓄意破壞”的測(cè)試，就象殺自己的孩子一樣難以接受。 開發(fā)者對(duì)自己的程序印象深刻，并總以為是正確的（自信是應(yīng)該的）。倘若在設(shè)計(jì)時(shí)就存在理解錯(cuò)誤，或因不良的編程習(xí)慣而流下了隱患，他本人很難發(fā)現(xiàn)這類錯(cuò)誤.開發(fā)者對(duì)自己的程序

17、的功能、接口十分熟悉，他自己幾乎不可能因?yàn)槭褂貌划?dāng)而引發(fā)錯(cuò)誤，這與大眾用戶的情況不太相似，所以測(cè)試自己的程序不具備典型性。 結(jié)論：開發(fā)人員應(yīng)當(dāng)測(cè)試自己的程序，這是他分內(nèi)的工作。但是開發(fā)人員在測(cè)試自己的程序時(shí)，很難做到客觀、公正，所以自我測(cè)試不具有說服力。 3.2 如何組織測(cè)試人員：應(yīng)當(dāng)視企業(yè)的人力資源而定條件特別好的公司，可以為每一個(gè)開發(fā)人員分配一名獨(dú)立的測(cè)試人員。這樣的測(cè)試人員職業(yè)化程度很高，可以完成單元測(cè)試、集成測(cè)試和系統(tǒng)測(cè)試工作，能夠?qū)崿F(xiàn)開發(fā)與測(cè)試同步進(jìn)行。條件比較好的公司，可以設(shè)置一個(gè)獨(dú)立的測(cè)試小組，該測(cè)試小組輪流參加各個(gè)項(xiàng)目的系統(tǒng)測(cè)試。而單元測(cè)試、集成測(cè)試工作由項(xiàng)目的開發(fā)小組承擔(dān)。

18、條件一般的公司，養(yǎng)不起獨(dú)立的測(cè)試小組。單元測(cè)試、集成測(cè)試工作由項(xiàng)目開發(fā)小組承擔(dān)。當(dāng)項(xiàng)目進(jìn)展到系統(tǒng)測(cè)試階段，可以從項(xiàng)目外抽調(diào)一些人員，加上開發(fā)人員，臨時(shí)組織系統(tǒng)測(cè)試小組。 條件比較差的公司，也許只有一個(gè)項(xiàng)目和為數(shù)不多的一些開發(fā)人員。那么就讓開發(fā)人員一直兼任測(cè)試人員的角色，相互測(cè)試對(duì)方的程序。如果人員實(shí)在太少了，只好讓開發(fā)者測(cè)試自己的程序，有測(cè)試總比沒有測(cè)試好吧！ 3. 測(cè)試人員的組織3.3 避免開發(fā)人員與測(cè)試人員產(chǎn)生矛盾開發(fā)人員的注意事項(xiàng)： 不要敵視測(cè)試人員。要理解測(cè)試的目的就是發(fā)現(xiàn)缺陷，是測(cè)試人員的工作職責(zé)。不要以為測(cè)試人員吃飽了沒事干，存心找茬。 不要輕視測(cè)試人員，別說人家技術(shù)水平差，不配搞

19、開發(fā)只好搞測(cè)試。 測(cè)試人員的注意事項(xiàng)： 發(fā)現(xiàn)缺陷時(shí)不要嘲笑開發(fā)人員，別說他的程序真臭、到處是Bug。 在開發(fā)人員壓力太大時(shí)或心情不好時(shí)不要火上澆油，發(fā)現(xiàn)缺陷時(shí)別大聲嚷嚷。 請(qǐng)留意另一種極端：如果測(cè)試人員與開發(fā)人員的關(guān)系非常好，可能會(huì)導(dǎo)致在測(cè)試的時(shí)候“手下留情”，這對(duì)項(xiàng)目也是一種傷害。 4. 企業(yè)的測(cè)試策略4.1 理念：企業(yè)的主要目的是獲取利潤，降低測(cè)試成本也是盈利的一種方式。 用較低的代價(jià)實(shí)現(xiàn)有效的測(cè)試，不應(yīng)為了追求完美的測(cè)試而不失一切代價(jià)。4.2 如何合理地減少測(cè)試工作量減少冗余的測(cè)試白盒測(cè)試與黑盒測(cè)試的方式雖然不同，但往往有“異曲同工”之妙。在很多地方，白盒測(cè)試與黑盒測(cè)試會(huì)產(chǎn)生一模一樣的效

20、果（或者能推理出來），這樣的測(cè)試是冗余的。在集成測(cè)試、系統(tǒng)測(cè)試階段，可能要執(zhí)行多次“回歸測(cè)試”。每一次“回歸測(cè)試”都會(huì)存在不少的冗余，應(yīng)當(dāng)設(shè)法剔除不必要的重復(fù)測(cè)試工作。 減少無價(jià)值的測(cè)試無價(jià)值的測(cè)試通常是由于不懂得測(cè)試技術(shù)引起的。例如功能測(cè)試，在等價(jià)區(qū)間之中，本來只要測(cè)試一個(gè)典型的輸入就行了，如果有人在此區(qū)間測(cè)試了100次，那么其中99次就是無價(jià)值的。 如何“偷工減料” 有一些“短、平、快”的項(xiàng)目，經(jīng)費(fèi)本來就少，用戶對(duì)質(zhì)量要求也馬馬虎虎。為了能多掙一點(diǎn)錢，開發(fā)方不得不采用“偷工減料”的方式來降低測(cè)試代價(jià)。偷工減料的途徑無非就是減少測(cè)試的內(nèi)容和頻度。但不能砍得太狠，否則軟件拿不出手?；痉椒ㄊ钦?/p>

21、出軟件中需要優(yōu)先測(cè)試的部分（見下表），其它次要部分可以忽略或?qū)碓贉y(cè)試。 4. 企業(yè)的測(cè)試策略“偷工減料”方法的測(cè)試優(yōu)先級(jí)：哪些功能是軟件的特色？ 哪些功能是用戶最常用的？ 如果系統(tǒng)可以分塊賣的話，哪些功能塊在銷售時(shí)最昂貴？ 哪些功能出錯(cuò)將導(dǎo)致用戶不滿或索賠？哪些程序是最復(fù)雜、最容易出錯(cuò)的？哪些程序是相對(duì)獨(dú)立，應(yīng)當(dāng)提前測(cè)試的？哪些程序最容易擴(kuò)散錯(cuò)誤？哪些程序是全系統(tǒng)的性能瓶頸所在？哪些程序是開發(fā)者最沒有信心的？ 4.3 測(cè)試何時(shí)結(jié)束基于測(cè)試用例的規(guī)則 基于“測(cè)試期缺陷密度”的規(guī)則基于“運(yùn)行期缺陷密度”的規(guī)則4.4 測(cè)試獎(jiǎng)勵(lì)機(jī)制根據(jù)缺陷的危害程度，把獎(jiǎng)金分等級(jí)。每個(gè)新缺陷對(duì)應(yīng)一份獎(jiǎng)金，把獎(jiǎng)金發(fā)給

22、第一個(gè)發(fā)現(xiàn)該缺陷的人。獎(jiǎng)金額要適當(dāng)，太低了人們不感興趣，太高了會(huì)讓項(xiàng)目破產(chǎn)的。 5. 測(cè)試規(guī)范5.1 測(cè)試流程第一步：制定測(cè)試計(jì)劃。該計(jì)劃被批準(zhǔn)后轉(zhuǎn)向第二步。 第二步：設(shè)計(jì)測(cè)試用例。該用例被批準(zhǔn)后轉(zhuǎn)向第三步。 第三步：如果滿足“啟動(dòng)準(zhǔn)則” ，那么執(zhí)行測(cè)試。 第四步：撰寫測(cè)試報(bào)告。 第五步：消除軟件缺陷。如果滿足“完成準(zhǔn)則”，那么正常結(jié)束測(cè)試。制定測(cè)試計(jì)劃設(shè)計(jì)測(cè)試用例執(zhí)行測(cè)試撰寫測(cè)試報(bào)告消除軟件缺陷審批審批回歸測(cè)試完成測(cè)試完成準(zhǔn)則啟動(dòng)準(zhǔn)則5. 測(cè)試規(guī)范5.2 測(cè)試啟動(dòng)準(zhǔn)則同時(shí)滿足以下條件，允許開始測(cè)試：（1）測(cè)試計(jì)劃已經(jīng)制定并且通過了審批；（2）測(cè)試用例已經(jīng)設(shè)計(jì)并且通過了審批；（3）被測(cè)試對(duì)象已

23、經(jīng)開發(fā)完畢并等待測(cè)試。 5.3 測(cè)試完成準(zhǔn)則對(duì)于非嚴(yán)格系統(tǒng)可以采用“基于測(cè)試用例”的準(zhǔn)則。同時(shí)滿足以下條件允許結(jié)束測(cè)試：（1）功能性測(cè)試用例通過率達(dá)到100；（2）非功能性測(cè)試用例通過率達(dá)到90時(shí)。對(duì)于嚴(yán)格系統(tǒng)，應(yīng)當(dāng)補(bǔ)充“基于測(cè)試期缺陷密度”的規(guī)則：（3）相鄰n個(gè)CPU小時(shí)內(nèi)“測(cè)試期缺陷密度”全部低于某個(gè)值m。例如n大于10，m小于等于1。 5.4 測(cè)試文檔模板測(cè)試計(jì)劃參考模板 測(cè)試用例參考模板測(cè)試報(bào)告參考模板5.5 測(cè)試計(jì)劃的參考模板5.6 測(cè)試用例5.7 測(cè)試報(bào)告的參考模板6. 軟件系統(tǒng)的主要測(cè)試內(nèi)容及技術(shù)6.1 接口與路徑測(cè)試6.2 功能測(cè)試6.3 健壯性測(cè)試6.4 性能測(cè)試6.5 用戶

24、界面測(cè)試6.6 信息安全測(cè)試6.7 壓力測(cè)試6.8 可靠性測(cè)試6.9 安裝/反安裝測(cè)試6. 軟件系統(tǒng)的主要測(cè)試內(nèi)容及技術(shù)6.1 接口與路徑測(cè)試數(shù)據(jù)一般通過接口輸入和輸出，所以接口測(cè)試是白盒測(cè)試的第一步。每個(gè)接口可能有多個(gè)輸入?yún)?shù)，每個(gè)參數(shù)有“典型值”、“邊界值”、“異常值”之分，所以輸入的組合數(shù)可能并不少。根據(jù)接口的定義，可以推斷某種輸入應(yīng)當(dāng)產(chǎn)生什么樣的輸出。輸出包括函數(shù)的返回值和輸出參數(shù)。如果實(shí)際輸出與期望的輸出不一致，那么說明程序有錯(cuò)誤。白盒方式的接口測(cè)試和黑盒方式的功能測(cè)試，其方法十分相似。 一個(gè)函數(shù)體內(nèi)的語句可能只有十幾條，但邏輯路徑可能有成千上萬條。想遍歷測(cè)試幾乎是不可能的，不測(cè)試或

25、者胡亂找?guī)讞l路徑測(cè)試卻又不行。 對(duì)于非嚴(yán)格系統(tǒng)而言，在分析路徑方面化費(fèi)很多精力是不值得的。我認(rèn)為在構(gòu)造接口測(cè)試的同時(shí)已經(jīng)建立了測(cè)試路徑。因?yàn)槊恳环N輸入將產(chǎn)生唯一的輸出，輸入與輸出之間的路徑也是唯一的。由于接口測(cè)試中的輸入是有代表性的，因此相應(yīng)的路徑也具有代表性，不用得著費(fèi)煞苦心地去找測(cè)試路徑。路徑測(cè)試的檢查表數(shù)據(jù)類型、變量值、邏輯判斷、循環(huán)、內(nèi)存管理、文件I/O、錯(cuò)誤處理 由于接口測(cè)試是枚舉的，有可能漏掉某些狀況，導(dǎo)致一些重要的路徑?jīng)]有被測(cè)試。預(yù)防措施有：觀察是否有程序語句從來沒有被執(zhí)行過。如果發(fā)生在這種情況，要么是程序有錯(cuò)誤，存在無用的代碼；要么是接口測(cè)試不充分，漏掉了一些路徑。要特別留意函

26、數(shù)體內(nèi)的錯(cuò)誤處理程序塊（如果存在的話），這是最易被人疏忽的路徑，隱患最多。 6. 軟件系統(tǒng)的主要測(cè)試內(nèi)容及技術(shù)接口與路徑測(cè)試用例的參考模板6. 軟件系統(tǒng)的主要測(cè)試內(nèi)容及技術(shù)6.2 功能測(cè)試功能測(cè)試的基本方法是構(gòu)造一些合理輸入（在需求范圍之內(nèi)），檢查輸出是否與期望的相同。如果兩者不一致，即表明功能有誤。也有例外的情況，如需求規(guī)格說明書中的某個(gè)功能寫錯(cuò)了，而實(shí)際上軟件的功能卻是正確的，這時(shí)要更改的是需求規(guī)格說明書。 功能測(cè)試看起來比較簡單，只要看得懂需求規(guī)格說明書，誰都會(huì)做。難點(diǎn)在于如何構(gòu)造有效的輸入。由于輸入空間通常是無限的，窮舉測(cè)試顯然行不通。那么隨便輸入一些東西，碰運(yùn)氣行不行？ 功能測(cè)試有兩

27、種比較好的測(cè)試方法：等價(jià)劃分法和邊界值分析法。 等價(jià)劃分是指把輸入空間劃分為幾個(gè)“等價(jià)區(qū)間”，在每個(gè)“等價(jià)區(qū)間”中只需要測(cè)試一個(gè)典型值就可以了。等價(jià)劃分法來源于人們的直覺與經(jīng)驗(yàn)，可令測(cè)試事半功倍。 “缺陷遺漏在角落里，聚集在邊界上”。邊界值測(cè)試法是對(duì)等價(jià)劃分法的補(bǔ)充。如果A和B是輸入空間的邊界值，那么除了典型值外還要用A和B作為測(cè)試用例。 例如測(cè)試函數(shù)。憑直覺，等價(jià)區(qū)間應(yīng)是（0, 1）和（1, +）。可取典型值x=0.5以及x=2.0進(jìn)行“等價(jià)劃分”測(cè)試。再取 x=0以及x=1進(jìn)行“邊界值”測(cè)試。 6. 軟件系統(tǒng)的主要測(cè)試內(nèi)容及技術(shù)功能測(cè)試用例的參考模板6. 軟件系統(tǒng)的主要測(cè)試內(nèi)容及技術(shù)6.3

28、 健壯性測(cè)試健壯性是指在異常情況下，軟件還能正常運(yùn)行的能力。健壯性有兩層含義：一是容錯(cuò)能力，二是恢復(fù)能力。 容錯(cuò)性測(cè)試通常構(gòu)造一些不合理的輸入來引誘軟件出錯(cuò)，例如：（1）輸入錯(cuò)誤的數(shù)據(jù)類型。如“猴”年“馬”月。（2）輸入定義域之外的數(shù)值。如上海人常說的“十三點(diǎn)”粗暴一些方式俗稱“大猩猩”測(cè)試法。除了不能拳打腳踢嘴咬外，什么招術(shù)都可以使出來。例如在測(cè)試客戶機(jī)服務(wù)器模式的軟件時(shí)，把網(wǎng)絡(luò)線拔掉，造成通信異常中斷。 恢復(fù)測(cè)試重點(diǎn)考察一下幾項(xiàng)：（1）系統(tǒng)能否重新運(yùn)行；（2）有無重要的數(shù)據(jù)丟失；（3）是否毀壞了其它相關(guān)的軟件硬件。 6. 軟件系統(tǒng)的主要測(cè)試內(nèi)容及技術(shù)健壯性測(cè)試用例的參考模板6. 軟件系統(tǒng)的

29、主要測(cè)試內(nèi)容及技術(shù)6.4 性能測(cè)試性能測(cè)試即測(cè)試軟件處理事務(wù)的速度，一是為了檢驗(yàn)性能是否符合需求，二是為了得到某些性能數(shù)據(jù)供人們參考（例如用于宣傳）。 有時(shí)人們關(guān)心測(cè)試的“絕對(duì)值”，如數(shù)據(jù)送輸速率是每秒多少比特。有時(shí)人們關(guān)心測(cè)試的“相對(duì)值”，如某個(gè)軟件比另一個(gè)軟件快多少倍。在獲取測(cè)試的“絕對(duì)值”時(shí)，我們要充分考慮并記錄運(yùn)行環(huán)境對(duì)測(cè)試的影響。例如網(wǎng)絡(luò)環(huán)境、計(jì)算機(jī)主頻，總線結(jié)構(gòu)和外部設(shè)備都可能影響軟件的運(yùn)行速度。 性能測(cè)試的一些注意事項(xiàng)：不要試圖讓人拿著鐘表去測(cè)時(shí)間，應(yīng)當(dāng)編寫一段程序用于計(jì)算時(shí)間以及相關(guān)數(shù)據(jù)。 應(yīng)當(dāng)測(cè)試軟件在標(biāo)準(zhǔn)配置和最低配置下的性能。 為了排除干擾，應(yīng)當(dāng)關(guān)閉那些消耗內(nèi)存、占用CP

30、U的其它應(yīng)用軟件（如殺毒軟件）。 不同的輸入情況會(huì)得到不同的性能數(shù)據(jù)，應(yīng)當(dāng)分檔記錄。例如傳輸文件的容量從100K到1M可以分成若干等級(jí)。 由于環(huán)境的波動(dòng)，同一種輸入情況在不同的時(shí)間可能得到不同的性能數(shù)據(jù)，可以取其平均值。 6. 軟件系統(tǒng)的主要測(cè)試內(nèi)容及技術(shù)性能測(cè)試用例的參考模板6. 軟件系統(tǒng)的主要測(cè)試內(nèi)容及技術(shù)6.5 用戶界面測(cè)試絕大多數(shù)軟件擁有圖形用戶界面。圖形用戶界面的測(cè)試重點(diǎn)是正確性、易用性和視覺效果。在評(píng)價(jià)易用性和視覺效果時(shí)，主觀性非常強(qiáng)，應(yīng)當(dāng)考慮多個(gè)人的觀點(diǎn)。用戶界面測(cè)試用例的參考模板： 6. 軟件系統(tǒng)的主要測(cè)試內(nèi)容及技術(shù)6.6 信息安全測(cè)試信息安全性（security）是指防止系統(tǒng)

31、被非法入侵的能力，既屬于技術(shù)問題又屬于管理問題。信息安全性測(cè)試有如下步驟：（1）為非法入侵設(shè)立目標(biāo)，例如“盜竊某個(gè)文件”或“更改數(shù)據(jù)庫記錄”等。（2）邀請(qǐng)（或懸賞）一些人扮演黑客，讓他們想盡辦法入侵系統(tǒng)，實(shí)現(xiàn)“目標(biāo)”。（3）如果有人成功了，請(qǐng)他詳述入侵的過程。別忘了給予獎(jiǎng)勵(lì)。 信息安全性測(cè)試用例的參考模板6. 軟件系統(tǒng)的主要測(cè)試內(nèi)容及技術(shù)6.7 壓力測(cè)試壓力測(cè)試也叫負(fù)荷測(cè)試，即獲取系統(tǒng)能正常運(yùn)行的極限狀態(tài)。了解“極限”是很有價(jià)值的，例如潛艇下潛極限深度。 壓力測(cè)試的主要任務(wù)是：構(gòu)造正確的輸入，使勁折騰系統(tǒng)卻讓它剛好不癱瘓。 壓力測(cè)試的一個(gè)變種是敏感測(cè)試。在某種情況下，微小的輸入變動(dòng)會(huì)導(dǎo)致系統(tǒng)的

32、表現(xiàn)（如性能）發(fā)生急劇的變化。敏感測(cè)試目的是發(fā)現(xiàn)什么樣的輸入可能會(huì)引發(fā)不穩(wěn)定現(xiàn)象。 壓力測(cè)試用例的參考模板6. 軟件系統(tǒng)的主要測(cè)試內(nèi)容及技術(shù)6.8 可靠性測(cè)試可靠性是指在一定的環(huán)境下、在給定的時(shí)間內(nèi)、系統(tǒng)不發(fā)生故障的概率。由于軟件不像硬件那樣可以“加速老化”，按此定義，軟件可靠性測(cè)試可能會(huì)花費(fèi)很長時(shí)間。 比較實(shí)用的辦法是，讓用戶使用該系統(tǒng)，記錄每一次發(fā)生故障的時(shí)刻。計(jì)算出相鄰故障的時(shí)間間隔，注意要去掉非工作時(shí)間。這樣我們可以方便地統(tǒng)計(jì)出不發(fā)生故障的“最小時(shí)間間隔”、“最大時(shí)間間隔”和“平均時(shí)間間隔”。其中“平均時(shí)間間隔”會(huì)讓人們大體了解到系統(tǒng)“可靠”的程度。 6. 軟件系統(tǒng)的主要測(cè)試內(nèi)容及技術(shù)

33、6.9 安裝 / 反安裝測(cè)試安裝 / 反安裝測(cè)試的目的：避免“大風(fēng)浪都挺過來了，卻在陰溝里翻了船” 目前市面上有非常流行的、專門制作安裝/反安裝程序的一些工具，如Install Shelled。制作安裝/反安裝程序不再是件難事，關(guān)鍵是不要麻痹大意。主要測(cè)試工作： （1）至少在標(biāo)準(zhǔn)配置和最低配置兩種環(huán)境下測(cè)試；（2）如果有安裝界面，應(yīng)當(dāng)嘗試各種選項(xiàng)，如選擇“全部”、“部分”、“升級(jí)”等。 單元測(cè)試 單元測(cè)試的內(nèi)容主要是： 算法邏輯、數(shù)據(jù)定義的理解和使用、接口、各種CASE路徑、邊界條件、錯(cuò)誤處理等。 單元測(cè)試的目的通常是: 在開發(fā)環(huán)境中，程序設(shè)計(jì)工程師為了檢查單元程序模塊內(nèi)部的邏輯、算法和數(shù)據(jù)處

34、理結(jié)果的正確性等。單元測(cè)試通常由負(fù)責(zé)編碼的工程師自己在代碼完成后測(cè)試，也有在項(xiàng)目組內(nèi)，由工程師相互交叉測(cè)試。 調(diào)試與測(cè)試的最大的不同點(diǎn)是二者的目的和視角的區(qū)別： 調(diào)試包括查找BUG、定位BUG、修改并最終確認(rèn)BUG已經(jīng)被修復(fù)的軟件故障排除過程。 測(cè)試是在一個(gè)相對(duì)獨(dú)立的環(huán)境下（測(cè)試應(yīng)盡可能地模擬運(yùn)行環(huán)境，調(diào)試是在開發(fā)環(huán)境），運(yùn)行系統(tǒng)單元，觀察和記錄運(yùn)行結(jié)果，對(duì)結(jié)果進(jìn)行獨(dú)立評(píng)價(jià)的過程。 單元測(cè)試（模塊測(cè)試） 實(shí)際上，在單元測(cè)試級(jí)，一般項(xiàng)目組很難做到把調(diào)試與測(cè)試分開。因?yàn)槎叩墓ぷ鲀?nèi)容比較接近，擔(dān)負(fù)人常常是一個(gè)人，環(huán)境區(qū)別并不大或者重新搭建環(huán)境在時(shí)間、成本和人力上，都比較困難。這些都是一般項(xiàng)目組并沒

35、有獨(dú)立的單元測(cè)試的原因。 將單元測(cè)試與模塊調(diào)試合并可能帶來的問題是：（1）單元測(cè)試沒有任何記錄和文檔。少有筆頭勤快的工程師，會(huì)把他每天測(cè)了什么、改了什么，記錄下來。軟件工程師要的就是沒有BUG的程序，任何中間結(jié)果都是垃圾。（2）由于調(diào)試的目標(biāo)是獲得沒有故障的程序，因此，與功能無關(guān)的程序?qū)傩酝缓雎?，或者要到集成測(cè)試、確認(rèn)測(cè)試時(shí)才被發(fā)現(xiàn)。例如：命名標(biāo)準(zhǔn)、程序形式規(guī)范等。 不論怎么說，現(xiàn)實(shí)情況，單元測(cè)試與模塊調(diào)試經(jīng)常是混為一談的，要想改變，也不太容易。 由于單元測(cè)試在項(xiàng)目組中，常常由編碼工程師完成，項(xiàng)目經(jīng)理的管理一般并不深入到單元測(cè)試層。 集成測(cè)試（子系統(tǒng)測(cè)試）集成測(cè)試又稱組裝測(cè)試，它是在單元測(cè)

36、試完成后，組裝為一個(gè)子系統(tǒng)后，對(duì)下列只有組裝后才能發(fā)生和測(cè)試到的問題，進(jìn)行檢查：（1）組裝后一個(gè)模塊對(duì)一個(gè)模塊的影響；（2）合并功能是否是預(yù)期的；（3）獨(dú)立的誤差在合并后的變化，是擴(kuò)大還是減小，是否在可接受的范圍內(nèi)；（4）實(shí)際的接口測(cè)試；包括：模塊之間對(duì)實(shí)際銜接的標(biāo)準(zhǔn)、時(shí)序（實(shí)時(shí)性）、應(yīng)答響應(yīng)、容錯(cuò)與錯(cuò)誤處理等；（5）模塊間的資源競爭等。 集成測(cè)試也很重視集成的階段性。最壞的情況是系統(tǒng)只有一次集成，就是系統(tǒng)全部模塊完成后進(jìn)行集成。實(shí)際上，這就像一部汽車，直到要出廠時(shí)，才來一次總測(cè)試。而當(dāng)你每天生產(chǎn)一部完全不同規(guī)格、型號(hào)的汽車時(shí)，這個(gè)時(shí)候的測(cè)試，可能是非常要命的。 比較好的辦法是通常采用的增量組

37、裝法，包括自頂向下或自低向上的增量組裝。分階段的增量組裝測(cè)試，可以解決一次集成，問題的隔離和區(qū)分不易的困難。 確認(rèn)測(cè)試（系統(tǒng)測(cè)試） 確認(rèn)測(cè)試的目的是按照與用戶確認(rèn)的軟件需求規(guī)格說明書的要求，檢查系統(tǒng)的需求實(shí)現(xiàn)。確認(rèn)需求的測(cè)試依據(jù)是需求階段產(chǎn)生的測(cè)試腳本（測(cè)試用例）。 國內(nèi)項(xiàng)目組的現(xiàn)實(shí)情況有以下幾種：（1）沒有確認(rèn)測(cè)試；（2）沒有獨(dú)立的確認(rèn)測(cè)試，測(cè)試與設(shè)計(jì)、編碼不分離；（3）有獨(dú)立的確認(rèn)測(cè)試，但測(cè)試用例是設(shè)計(jì)和編碼人員寫的，因此，獨(dú)立測(cè)試人員相當(dāng)于按設(shè)計(jì)和編碼人員的設(shè)計(jì)思路再測(cè)一遍。 上述這些情況，就喪失了確認(rèn)測(cè)試的大部分意義。正確的確認(rèn)測(cè)試是獨(dú)立的測(cè)試組中，具有相應(yīng)知識(shí)的測(cè)試設(shè)計(jì)師，根據(jù)需求規(guī)

38、格說明書，并依據(jù)該軟件在用戶方面將會(huì)是在什么環(huán)境下，用戶將如何使用該軟件，來設(shè)計(jì)測(cè)試方案和測(cè)試用例，安排測(cè)試人員進(jìn)行測(cè)試。很顯然，現(xiàn)實(shí)離理想的距離還比較遙遠(yuǎn)。 確認(rèn)測(cè)試還包括軟件經(jīng)修改后的再測(cè)試（回歸測(cè)試）?；貧w測(cè)試是對(duì)已測(cè)試并發(fā)現(xiàn)故障的部分，修改后進(jìn)行再測(cè)試。回歸測(cè)試不應(yīng)修改測(cè)試程序、測(cè)試內(nèi)容或測(cè)試標(biāo)準(zhǔn)。它與正常測(cè)試不同的僅是：它可能并不需要再完整地走一遍所有的確認(rèn)測(cè)試，而是小心地選擇部分確認(rèn)測(cè)試程序，選擇的標(biāo)準(zhǔn)是不減低原標(biāo)準(zhǔn)的整體要求。 測(cè)試和測(cè)試 為了實(shí)際檢驗(yàn)軟件的功能和性能，有時(shí)，常邀請(qǐng)?zhí)囟ǖ挠脩魩椭囉茫y(cè)試）系統(tǒng)正式發(fā)布前的版本，請(qǐng)用戶對(duì)系統(tǒng)進(jìn)行評(píng)價(jià)。這就是通常所說的測(cè)試和測(cè)試。測(cè)

39、試是由一個(gè)用戶在開發(fā)者的場(chǎng)所，在開發(fā)者指導(dǎo)下進(jìn)行的測(cè)試。開發(fā)者記錄下問題和錯(cuò)誤，是在開發(fā)者“控制”下的測(cè)試。測(cè)試是用戶的環(huán)境中，開發(fā)者可能并不在現(xiàn)場(chǎng)，由用戶“活用”系統(tǒng)情況下的測(cè)試。用戶記錄下問題，報(bào)告給開發(fā)者。在商用套裝軟件中，這種情況比較多見，在行業(yè)應(yīng)用系統(tǒng)中，由于現(xiàn)實(shí)環(huán)境并不允許不成功的軟件直接投入使用，用戶也沒有參與測(cè)試義務(wù)、時(shí)間和資源的投入和配合的積極性，因此，這種測(cè)試很少發(fā)生。 驗(yàn)收測(cè)試在行業(yè)應(yīng)用軟件環(huán)境中，驗(yàn)收測(cè)試是項(xiàng)目過程非常重要的一環(huán)，也是項(xiàng)目經(jīng)理非常關(guān)注的一項(xiàng)工作。驗(yàn)收測(cè)試與確認(rèn)測(cè)試非常相似，所不同的是，確認(rèn)測(cè)試是項(xiàng)目組或組織內(nèi)部的測(cè)試，驗(yàn)收測(cè)試是用戶主導(dǎo)、現(xiàn)場(chǎng)參與、現(xiàn)場(chǎng)環(huán)

40、境下的測(cè)試。驗(yàn)收測(cè)試通常由項(xiàng)目組先提出測(cè)試大綱，定義測(cè)試目的、范圍、方法、測(cè)試用例、預(yù)期結(jié)果、驗(yàn)收標(biāo)準(zhǔn)等。經(jīng)用戶同意批準(zhǔn)，可能包括用戶的修改、增加后，確定測(cè)試時(shí)間，開始進(jìn)入驗(yàn)收測(cè)試。用戶在完成按測(cè)試用例的測(cè)試后，在測(cè)試記錄上逐條確認(rèn)、簽字，最后，在測(cè)試報(bào)告上簽字，完成驗(yàn)收測(cè)試。一般地、驗(yàn)收測(cè)試報(bào)告是項(xiàng)目初驗(yàn)、終驗(yàn)的依據(jù)和主要驗(yàn)收形式。 單元測(cè)試與驗(yàn)收測(cè)試 單元測(cè)試和驗(yàn)收測(cè)試沒有什么區(qū)別？單元測(cè)試可以類比為一個(gè)建筑的質(zhì)檢人員對(duì)建筑進(jìn)行的檢測(cè)， 他關(guān)注的重點(diǎn)是建筑的內(nèi)部結(jié)構(gòu)、地基、框架以及墻壁是否垂直等。他的檢測(cè)是要保證建筑的各個(gè)部分是正常的、安全的，換句話說，就是要保證施工滿足建筑上面的質(zhì)量標(biāo)準(zhǔn)

41、。驗(yàn)收測(cè)試可以類比為建筑的使用者來對(duì)建筑進(jìn)行的檢測(cè)。他關(guān)心建筑的外觀是否美觀、各個(gè)房間的大小是否合適，窗戶的位置是否合適，是否能夠滿足家庭的需要等。這里，建筑的使用者執(zhí)行的就是驗(yàn)收測(cè)試，他是從用戶的角度出發(fā)的。正是這種角度的不同決定了單元測(cè)試和驗(yàn)收測(cè)試之間的區(qū)別。它們是對(duì)系統(tǒng)的不同的方面進(jìn)行的測(cè)試，二者是互相補(bǔ)充的。不管我們?cè)谙到y(tǒng)的構(gòu)建中使用了多么聰明的方法，不管我們的系統(tǒng)是多么的靈活，但是首先我們的產(chǎn)品必須是可用的，否則我們所做的就是浪費(fèi)時(shí)間，從這一點(diǎn)上來說驗(yàn)收測(cè)試要比單元測(cè)試顯得更加重要。 測(cè)試方法測(cè)試所處的階段不同，方法也不同：白盒測(cè)試在單元測(cè)試階段，由于測(cè)試者對(duì)被測(cè)對(duì)象的內(nèi)部結(jié)構(gòu)、邏輯

42、思路、接口關(guān)系等比較熟悉，一般采取白盒測(cè)試的方法，它是根據(jù)模塊的內(nèi)部邏輯，進(jìn)行測(cè)試設(shè)計(jì)的方法。有些集成測(cè)試也采用白盒方法，關(guān)鍵看集成階段的劃分。黑盒測(cè)試在集成測(cè)試以至此后的各階段，測(cè)試設(shè)計(jì)和測(cè)試人員，對(duì)被測(cè)對(duì)象的內(nèi)部結(jié)構(gòu)不了解也不需要了解，他的目的是按需求功能進(jìn)行確認(rèn)。因此，黑盒測(cè)試是嚴(yán)格按軟件需求進(jìn)行測(cè)試設(shè)計(jì)的方法。代碼走查 測(cè)試類型在不同階段，測(cè)試的類型也不相同，常有的測(cè)試類型是：（1）功能測(cè)試：軟件實(shí)現(xiàn)的功能是否符合需求規(guī)格說明書中定義的功能；（2）性能測(cè)試：軟件在規(guī)定配置下的性能是否符合需求規(guī)定；（3）算法測(cè)試：確認(rèn)實(shí)現(xiàn)的算法的正確性；（4）正向測(cè)試：按照用戶正常的理解、操作方式、思維

43、和使用習(xí)慣使用軟件，得到的結(jié)果是否與需求一致。（5）逆向測(cè)試：如果不按用戶正常的理解、操作發(fā)生、思維和使用習(xí)慣使用軟件，軟件是否能正確地進(jìn)行處理。如：無效操作、錯(cuò)誤的數(shù)據(jù)輸入處理、非法進(jìn)入等。（6）邊界測(cè)試：按軟件的限制、假設(shè)條件的邊界輸入，進(jìn)行測(cè)試。（7）配置測(cè)試：對(duì)軟件環(huán)境進(jìn)行配置變化，軟件需求實(shí)現(xiàn)，特別是性能實(shí)現(xiàn)是否能符合需求規(guī)定要求。（8）負(fù)載測(cè)試：在業(yè)務(wù)處理量、數(shù)據(jù)負(fù)載量、通訊負(fù)載量達(dá)到何種情況，系統(tǒng)的性能變化和承載能力情況。測(cè)試計(jì)劃測(cè)試估計(jì)在擬定測(cè)試計(jì)劃時(shí)，首先需要對(duì)以下情況，做出估計(jì)：（1） 完成測(cè)試設(shè)計(jì)所需要的工作量：（2） 完成測(cè)試設(shè)計(jì)所需要的工作時(shí)間：（3） 完成測(cè)試所需要

44、的時(shí)間：根據(jù)以上三個(gè)部分的結(jié)果，我們已經(jīng)知道了測(cè)試的范圍、內(nèi)容、任務(wù)分配、時(shí)間等，這樣，項(xiàng)目經(jīng)理可以能比較充分地規(guī)劃資源，制訂出一份比較全面和切實(shí)的測(cè)試工作計(jì)劃。測(cè)試分配測(cè)試計(jì)劃確定了測(cè)試的范圍、內(nèi)容和估計(jì)時(shí)間，根據(jù)WBS方法，測(cè)試計(jì)劃還應(yīng)說明具體測(cè)試任務(wù)的分解和測(cè)試工作的分配。測(cè)試組的成員根據(jù)分工，各自完成一部分測(cè)試任務(wù)。測(cè)試組與項(xiàng)目開發(fā)組還需要保持一定的同步，使測(cè)試與開發(fā)、修改在協(xié)調(diào)的步驟下進(jìn)行，以節(jié)約寶貴的項(xiàng)目總時(shí)間。測(cè)試確認(rèn)測(cè)試用例名稱工號(hào)權(quán)限被測(cè)子系統(tǒng)名卡/號(hào)資源管理測(cè)試用例來源 公司測(cè)試組 內(nèi)部測(cè)試抽查參考文檔序號(hào)測(cè)試用例描述XWYY001測(cè)試目的能否正確識(shí)別合法的操作員進(jìn)入應(yīng)用系

45、統(tǒng)測(cè)試步驟1.啟動(dòng)“卡/號(hào)資源管理”應(yīng)用程序。2. 輸入系統(tǒng)中不存在的工號(hào)1000，再輸入密碼12345，檢查能否進(jìn)入系統(tǒng)。3.輸入系統(tǒng)中存在的工號(hào)nj001和正確的密碼，檢查能否進(jìn)入系統(tǒng)。4. 輸入系統(tǒng)中存在的工號(hào)yd002和正確的密碼，檢查能否進(jìn)入系統(tǒng)。輸入數(shù)據(jù)描述1、工號(hào)1000根本不是系統(tǒng)合法的工號(hào)。2、工號(hào)nj001是前臺(tái)營業(yè)受理的工號(hào)，不能進(jìn)行卡號(hào)資源管理系統(tǒng)。3、工號(hào)yd002是卡號(hào)資源管理系統(tǒng)的工號(hào)。期望的結(jié)果1. 工號(hào)1000無論如何進(jìn)入不了系統(tǒng)，系統(tǒng)提示無此員工2. 工號(hào)nj001也不能進(jìn)入系統(tǒng)，系統(tǒng)提示該操作員無權(quán)執(zhí)行卡號(hào)資源管理系統(tǒng)3工號(hào)yd002可以進(jìn)入系統(tǒng)，并能打開

46、所有的功能菜單測(cè)試結(jié)果描述相符測(cè)試人員測(cè)試日期2003-03-08復(fù)測(cè)人員復(fù)測(cè)日期備注測(cè)試用例： 測(cè)試用例由誰設(shè)計(jì)？ 設(shè)計(jì)測(cè)試用例的依據(jù)是什么？ 測(cè)試設(shè)計(jì)的重點(diǎn)是什么？ 測(cè)試報(bào)告： 收集齊上述的所有測(cè)試用例，構(gòu)成了測(cè)試報(bào)告的基本要件。 測(cè)試報(bào)告是對(duì)所有測(cè)試用例測(cè)試過程的總結(jié)。 在測(cè)試報(bào)告中，應(yīng)反映： （1）測(cè)試中出現(xiàn)問題的統(tǒng)計(jì)匯總和分析； （2）未解決問題的匯總和解決方案建議； （3）回歸測(cè)試的統(tǒng)計(jì)和分析（度量） ； （4）對(duì)測(cè)試計(jì)劃的總結(jié)或修改。以一個(gè)獨(dú)立的測(cè)試小組為例，測(cè)試過程一般如下：（1）測(cè)試準(zhǔn)備：制定人員、環(huán)境、工具、培訓(xùn)和外部支持計(jì)劃。（2）測(cè)試計(jì)劃：確定測(cè)試策略、建立測(cè)試計(jì)劃。（

47、3）測(cè)試用例：建立測(cè)試順序樹、確定測(cè)試的優(yōu)先級(jí)、詳細(xì) 列出測(cè)試程序和測(cè)試數(shù)據(jù)，設(shè)計(jì)測(cè)試用例。（4）測(cè)試環(huán)境：了解需求、搭建環(huán)境、安裝備份和恢復(fù)程序， 記錄初始環(huán)境、測(cè)試環(huán)境、恢復(fù)環(huán)境等。（5）測(cè)試執(zhí)行：從測(cè)試計(jì)劃復(fù)審測(cè)試計(jì)劃進(jìn)度表、恢復(fù)測(cè)試執(zhí) 行環(huán)境。（6）結(jié)果分析：執(zhí)行結(jié)果分析、度量。（7）測(cè)試報(bào)告：錯(cuò)誤趨勢(shì)圖、測(cè)試變動(dòng)指示、產(chǎn)品檢查點(diǎn)建議。測(cè)試過程組織PART I ：軟件質(zhì)量保證的基本方法一、評(píng)審 A： 軟件窮舉測(cè)試不現(xiàn)實(shí)。 B：結(jié)構(gòu)化走查和審查是比單純測(cè)試更有效的缺陷排除手段。 C：評(píng)審能早期清除缺陷，很大程度上減低了成本。二、測(cè)試 作為評(píng)審的有力補(bǔ)充來保證軟件的質(zhì)量。 軟件缺陷分布評(píng)審

48、是軟件質(zhì)量管理的最重要手段如果一個(gè)軟件未經(jīng)評(píng)審或評(píng)審不充分是否實(shí)施評(píng)審項(xiàng)目其開發(fā)成本比較 PART II:軟件測(cè)試組織配置(人員)其它公司的軟件測(cè)試組織配置(人員)上海愛立信通訊軟件研發(fā)中心 開發(fā)人員：測(cè)試人員=4：1 測(cè)試工作：確認(rèn)測(cè)試、系統(tǒng)測(cè)試杭州東方通信 開發(fā)人員：測(cè)試人員=4：1（不包括兼職測(cè)試人員） 測(cè)試工作：確認(rèn)測(cè)試廣東電信科學(xué)技術(shù)研究院 開發(fā)人員：測(cè)試人員=5：1 測(cè)試工作：確認(rèn)測(cè)試南京欣網(wǎng)視訊科技股份有限公司 開發(fā)人員：測(cè)試人員=？：？我們公司的定位 我們的軟件質(zhì)量 軟件測(cè)試組織配置(成本)軟件類型開發(fā)成本按階段百分比分布需求與設(shè)計(jì)實(shí)現(xiàn)測(cè)試控制軟件462034航空航天軟件342

49、046操作系統(tǒng)331750科技計(jì)算軟件442630商業(yè)應(yīng)用軟件442828PART III：測(cè)試管理在工程化的軟件研制過程中，軟件測(cè)試活動(dòng)作為質(zhì)量管理的一部分，貫穿了整個(gè)軟件項(xiàng)目的生存周期；要求建立獨(dú)立的軟件測(cè)試組織，實(shí)現(xiàn)第三方測(cè)試，并始終與設(shè)計(jì)/實(shí)現(xiàn)/維護(hù)組織并行工作；軟件測(cè)試涉及的人/物/時(shí)間甚至可能超過軟件項(xiàng)目總消耗的一半以上。因此，軟件測(cè)試本身就是軟件工程中值得專門計(jì)劃和管理的一項(xiàng)子工程。軟件工程體系 測(cè)試組織與開發(fā)組織的界面 I軟件測(cè)試組織與軟件開發(fā)組織的界面指：軟件開發(fā)組織完成編碼、調(diào)試、集成后通過軟件配置管理組織移交給軟件測(cè)試組織的軟件成分的層次，簡稱“軟件測(cè)試界面”。對(duì)低于軟件

50、測(cè)試界面的軟件成分進(jìn)行的排錯(cuò)的過程一般被稱為“軟件調(diào)試”；而對(duì)高于軟件測(cè)試界面的軟件成分進(jìn)行的找錯(cuò)的過程被稱為“軟件測(cè)試”，應(yīng)軟件測(cè)試而進(jìn)行開發(fā)修改的過程被稱為“軟件更動(dòng)”。 測(cè)試組織與開發(fā)組織的界面 II一旦軟件成分被提交到配置管理庫中，則對(duì)其的修改就必須遵循軟件更動(dòng)控制規(guī)范，將涉及不少人員，媒體轉(zhuǎn)移較頻繁，軟件修改周期也較長。為了減少整個(gè)軟件測(cè)試過程（發(fā)現(xiàn)問題改動(dòng)軟件）的人力/物力/時(shí)間的消耗，測(cè)試組織與開發(fā)組織應(yīng)達(dá)成共識(shí)：盡可能提高軟件測(cè)試界面。定義較高的軟件測(cè)試界面的益處還在于：有利于開發(fā)組織更加主動(dòng)關(guān)注其軟件開發(fā)過程的質(zhì)量控制；同時(shí)，還有利于測(cè)試組織集中時(shí)間和資源來執(zhí)行軟件高層測(cè)試（

51、功能/性能的確認(rèn)）。測(cè)試組織與開發(fā)組織的界面 III由于軟件更動(dòng)控制與軟件回歸測(cè)試的內(nèi)在聯(lián)系緊密，因此測(cè)試組織應(yīng)參與制訂軟件更動(dòng)控制規(guī)范，以使該規(guī)范能在適用于系統(tǒng)的前提下更節(jié)省軟件研制的總消耗。軟件測(cè)試結(jié)果通過軟件配置管理組織返回給軟件開發(fā)組織；測(cè)試結(jié)果是軟件質(zhì)量控制的數(shù)據(jù)來源之一。規(guī)范的軟件項(xiàng)目文檔進(jìn)行一個(gè)軟件第三方測(cè)試應(yīng)具備的條件應(yīng)確保得到以下資源：需求說明書；（強(qiáng)調(diào)需求的可測(cè)試性、穩(wěn)定性）設(shè)計(jì)說明書；（如果需求說明書足夠清楚則可以不用）項(xiàng)目開發(fā)者所進(jìn)行的測(cè)試報(bào)告；運(yùn)行環(huán)境及配置說明；遵循的相關(guān)標(biāo)準(zhǔn)； （測(cè)試評(píng)估的標(biāo)準(zhǔn)也在里面體現(xiàn)）可能需要相關(guān)的工具；預(yù)算、人員、時(shí)間要求等。不滿足這些條件

52、進(jìn)行測(cè)試是沒有意義的。一個(gè)測(cè)試結(jié)束后應(yīng)形成相關(guān)的文檔測(cè)試計(jì)劃；測(cè)試用例；測(cè)試報(bào)告；沒有形成相關(guān)文檔的測(cè)試過程是不完整的。軟件測(cè)試的層次結(jié)構(gòu)類型方法階段舉例：功能算法正向反向可用性邊界驗(yàn)收測(cè)試確認(rèn)測(cè)試集成測(cè)試單元測(cè)試白盒黑盒自頂向下自底向上模擬用戶操作需求分析概要設(shè)計(jì)詳細(xì)設(shè)計(jì)編碼模塊測(cè)試集成測(cè)試確認(rèn)測(cè)試系統(tǒng)測(cè)試決定軟件與系統(tǒng)的配合關(guān)系測(cè)試與開發(fā)前期工作的關(guān)系（I）需求分析設(shè)計(jì)編碼確認(rèn)組裝單元修正修正修正通過通過通過1. 測(cè)試步驟 （集成）測(cè)試與開發(fā)前期工作的關(guān)系（II）測(cè)試活動(dòng)測(cè)試階段的信息流測(cè)試階段與方法測(cè)試階段目的執(zhí)行者測(cè)試方法單元測(cè)試查找獨(dú)立模塊中邏輯錯(cuò)誤、數(shù)據(jù)錯(cuò)誤和算法錯(cuò)誤開發(fā)人員白盒測(cè)

53、試集成測(cè)試查找模塊之間接口錯(cuò)誤開發(fā)人員白盒測(cè)試、自頂向下或自底向上確認(rèn)測(cè)試確認(rèn)軟件是否滿足軟件需求測(cè)試人員黑盒測(cè)試模擬用戶操作系統(tǒng)測(cè)試對(duì)系統(tǒng)中各個(gè)組成部分進(jìn)行綜合性檢驗(yàn)測(cè)試人員黑盒測(cè)試模擬用戶操作回歸測(cè)試確認(rèn)軟件變更后是否仍滿足軟件需求測(cè)試人員黑盒測(cè)試模擬用戶操作 測(cè)試用戶黑盒測(cè)試模擬用戶操作驗(yàn)收測(cè)試確認(rèn)軟件是否滿足用戶需求用戶測(cè)試人員黑盒測(cè)試模擬用戶操作測(cè)試的經(jīng)濟(jì)學(xué)-重要的是何時(shí)停止測(cè)試缺陷數(shù)量測(cè)試費(fèi)用過量現(xiàn)代軟件工程 軟件測(cè)試的定義 軟件測(cè)試基礎(chǔ) 軟件測(cè)試用例設(shè)計(jì) 軟件測(cè)試策略第七部分 軟件測(cè)試 軟件測(cè)試的定義 軟件測(cè)試基礎(chǔ) 軟件測(cè)試用例設(shè)計(jì) 軟件測(cè)試策略軟件測(cè)試是在軟件投入運(yùn)行前，對(duì)軟件

54、需求分析，設(shè)計(jì)規(guī)格說明和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵步驟。如果下定義：軟件測(cè)試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程?；蛘哒f軟件測(cè)試是根據(jù)軟件開發(fā)各階段的規(guī)格說明和程序的內(nèi)部結(jié)構(gòu)而精心設(shè)計(jì)一批測(cè)試用例，并利用這些測(cè)試用例去運(yùn)行程序，以發(fā)現(xiàn)程序錯(cuò)誤的過程。軟件測(cè)試的定義軟件測(cè)試的基礎(chǔ)軟件測(cè)試的目的軟件測(cè)試的原則測(cè)試與軟件開發(fā)各階段的關(guān)系軟件測(cè)試的目的基于不同的立場(chǎng)，存在著兩種完全不同的測(cè)試目的。從用戶的角度出發(fā)，普遍希望通過軟件測(cè)試暴露軟件中隱藏的錯(cuò)誤和缺陷，以考慮是否可接受該產(chǎn)品。從軟件開發(fā)者的角度出發(fā)，則希望測(cè)試成為表明軟件產(chǎn)品中不存在錯(cuò)誤的過程，驗(yàn)證該軟件已正確地實(shí)現(xiàn)了用戶的要求，確立人們

55、對(duì)軟件質(zhì)量的信心。Myers軟件測(cè)試目的(1) 測(cè)試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯(cuò)誤；(2) 一個(gè)好的測(cè)試用例在于能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯(cuò)誤；(3) 一個(gè)成功的測(cè)試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試。換言之，測(cè)試的目的是系統(tǒng)地找出軟件中潛在的各種錯(cuò)誤和缺陷。 能夠證明軟件的功能和性能與需求說明相符合。測(cè)試不能表明軟件中不存在錯(cuò)誤，它只能說明軟件中存在錯(cuò)誤。軟件測(cè)試的原則1. 應(yīng)當(dāng)把“盡早地和不斷地進(jìn)行軟件測(cè)試”作為軟件開發(fā)者的座右銘。2. 測(cè)試用例應(yīng)由測(cè)試輸入數(shù)據(jù)和對(duì)應(yīng)的預(yù)期輸出結(jié)果這兩部分組成。3. 程序員應(yīng)避免檢查自己的程序。4. 在設(shè)計(jì)測(cè)試用例時(shí)，應(yīng)當(dāng)包括合理的輸入條件和不合理的輸入條件。5.

56、 充分注意測(cè)試中的群集現(xiàn)象。經(jīng)驗(yàn)表明，測(cè)試后程序中殘存的錯(cuò)誤數(shù)目與該程序中已發(fā)現(xiàn)的錯(cuò)誤數(shù)目成正比。6. 嚴(yán)格執(zhí)行測(cè)試計(jì)劃，排除測(cè)試的隨意性。7. 應(yīng)當(dāng)對(duì)每一個(gè)測(cè)試結(jié)果做全面檢查。8. 妥善保存測(cè)試計(jì)劃，測(cè)試用例，出錯(cuò)統(tǒng)計(jì)和最終分析報(bào)告，為維護(hù)提供方便。測(cè)試與軟件開發(fā)各階段的關(guān)系軟件開發(fā)過程是一個(gè)自頂向下，逐步細(xì)化的過程軟件計(jì)劃階段定義軟件作用域軟件需求分析建立軟件信息域、功能和性能需求、約束等軟件設(shè)計(jì)把設(shè)計(jì)用某種程序設(shè)計(jì)語言轉(zhuǎn)換成程序代碼測(cè)試過程是依相反順序安排的自底向上，逐步集成的過程。軟件測(cè)試用例設(shè)計(jì)兩種常用的測(cè)試方法 黑盒測(cè)試 白盒測(cè)試黑盒測(cè)試這種方法是把測(cè)試對(duì)象看做一個(gè)黑盒子，測(cè)試人員

57、完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能說明。黑盒測(cè)試又叫做功能測(cè)試或數(shù)據(jù)驅(qū)動(dòng)測(cè)試。黑盒測(cè)試方法是在程序接口上進(jìn)行測(cè)試，主要是為了發(fā)現(xiàn)以下錯(cuò)誤: 是否有不正確或遺漏了的功能? 在接口上，輸入能否正確地接受? 能否輸出正確的結(jié)果? 是否有數(shù)據(jù)結(jié)構(gòu)錯(cuò)誤或外部信息(例如數(shù)據(jù)文件)訪問錯(cuò)誤? 性能上是否能夠滿足要求? 是否有初始化或終止性錯(cuò)誤?用黑盒測(cè)試發(fā)現(xiàn)程序中的錯(cuò)誤，必須在所有可能的輸入條件和輸出條件中確定測(cè)試數(shù)據(jù)，來檢查程序是否都能產(chǎn)生正確的輸出。但這是不可能的。假設(shè)一個(gè)程序P有輸入量X和Y及輸出量Z。在字長為32位的計(jì)算機(jī)上運(yùn)行。若X、

58、Y取整數(shù)，按黑盒方法進(jìn)行窮舉測(cè)試：可能采用的 測(cè)試數(shù)據(jù)組： 232232 264 如果測(cè)試一 組數(shù)據(jù)需要1毫秒，一年工作365 24小時(shí)，完成所有測(cè)試需5億年。白盒測(cè)試此方法把測(cè)試對(duì)象看做一個(gè)透明的盒子，它允許測(cè)試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設(shè)計(jì)或選擇測(cè)試用例，對(duì)程序所有邏輯路徑進(jìn)行測(cè)試。通過在不同點(diǎn)檢查程序的狀態(tài)，確定實(shí)際的狀態(tài)是否與預(yù)期的狀態(tài)一致。因此白盒測(cè)試又稱為結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試。軟件人員使用白盒測(cè)試方法，主要想對(duì)程序模塊進(jìn)行如下的檢查： 對(duì)程序模塊的所有獨(dú)立的執(zhí)行路徑至少測(cè)試一次； 對(duì)所有的邏輯判定，取“真”與取“假”的兩種情況都至少測(cè)試一次； 在循環(huán)的邊界和運(yùn)行界限內(nèi)

59、執(zhí)行循環(huán)體； 測(cè)試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性，等。對(duì)一個(gè)具有多重選擇和循環(huán)嵌套的程序，不同的路徑數(shù)目可能是天文數(shù)字。給出一個(gè)小程序的流程圖，它包括了一個(gè)執(zhí)行20次的循環(huán)。包含的不同執(zhí)行路徑數(shù)達(dá)520條，對(duì)每一條路徑進(jìn)行測(cè)試需要1毫秒，假定一年工作365 24小時(shí)，要想把所有路徑測(cè)試完，需3170年。邏輯覆蓋 語句覆蓋 判定覆蓋 條件覆蓋 判定條件覆蓋 條件組合覆蓋 路徑覆蓋。邏輯覆蓋是以程序內(nèi)部的邏輯結(jié)構(gòu)為基礎(chǔ)的設(shè)計(jì)測(cè)試用例的技術(shù)。它屬白盒測(cè)試。白盒測(cè)試的測(cè)試用例設(shè)計(jì)舉例：所有路徑為：L1(a-c-e) ,L2(a-b-d), L3(a-b-e), L4(a-c-d)依據(jù)以上推導(dǎo)出來的結(jié)果就可以設(shè)計(jì)

60、滿足要求的測(cè)試用例。測(cè)試用例的設(shè)計(jì)格式如下【輸入的(A, B, X)，輸出的(A, B, X)】為圖例設(shè)計(jì)滿足語句覆蓋的測(cè)試用例是:【(2, 0, 4)，(2, 0, 3)】 覆蓋 ace【L1】語句覆蓋語句覆蓋就是設(shè)計(jì)若干個(gè)測(cè)試用例，運(yùn)行被測(cè)程序，使得每一可執(zhí)行語句至少執(zhí)行一次。在圖例中，正好所有的可執(zhí)行語句都在路徑L1上，所以選擇路徑 L1設(shè)計(jì)測(cè)試用例，就可以覆蓋所有的可執(zhí)行語句。 判定覆蓋判定覆蓋就是設(shè)計(jì)若干個(gè)測(cè)試用例，運(yùn)行被測(cè)程序，使得程序中每個(gè)判斷的取真分支和取假分支至少經(jīng)歷一次。判定覆蓋又稱為分支覆蓋。對(duì)于圖例，如果選擇路徑L1和L2，就可得滿足要求的測(cè)試用例:【(2, 0, 4)