軟件測試技術(shù)完整教程

1、第一章第一章 概概 述述 本章要點本章要點 l 軟件測試的發(fā)展歷史；l 軟件測試技術(shù)的分類方法；l 軟件測試原則；l 軟件測試的定義；l 軟件測試同軟件開發(fā)之間的關(guān)系；l 軟件測試與開發(fā)模型；l 軟件測試工作流程。 本章目標(biāo)本章目標(biāo) u 了解軟件測試的發(fā)展歷程和行業(yè)現(xiàn)狀；u 掌握軟件測試技術(shù)的分類；u 理解軟件測試的目的和軟件測試原則，以及了解 人們對軟件測試行業(yè)的錯誤認(rèn)識；u 掌握軟件測試中的基本定義、基本知識;u 理解軟件開發(fā)與軟件測試的關(guān)系。 1.1軟件測試的發(fā)展歷程及現(xiàn)狀軟件測試的發(fā)展歷程及現(xiàn)狀 1.1.1軟件測試的發(fā)展歷程軟件測試的發(fā)展歷程 20世紀(jì)50-60年代，軟件仍然處于次要位

2、置,測試?yán)碚摵头椒ǖ陌l(fā)展比較緩慢。 70年代以后，軟件技術(shù)的成熟和完善使得軟件測試的規(guī)模和復(fù)雜度加大，軟件測試也逐漸形成了一套完整的體系，逐漸走向規(guī)范化。 1.1.2軟件測試的現(xiàn)狀軟件測試的現(xiàn)狀 與一些發(fā)達(dá)國家相比，國內(nèi)測試工作還存在一定的差距。國內(nèi)測試人員所占比例小，但是，在軟件測試實現(xiàn)方面都是相當(dāng)?shù)?，而且向產(chǎn)業(yè)化方向發(fā)展。 1.2 1.2 什么是軟件測試什么是軟件測試 1.2.11.2.1軟件測試的定義軟件測試的定義 根據(jù)側(cè)重點的不同，主要有以下三種觀點： 1）1983年IEEE將軟件測試定義為：“使用人工或自動手段運行或測定某個系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的需求或是弄清預(yù)期結(jié)

3、果與實際結(jié)果之間的差別”，該定義明確地提出了軟件測試以檢驗是否滿足需求為目標(biāo)。 2）Myers認(rèn)為：“是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程”，明確提出了“尋找錯誤”是測試目的。 3）從軟件質(zhì)量保證的角度看：是一種重要的軟件質(zhì)量保證活動，其動機是通過一些經(jīng)濟(jì)、高效的方法，捕捉軟件中的錯誤，從而達(dá)到保證軟件內(nèi)在質(zhì)量的目的。 測試過程中的活動包括“分析”軟件（靜態(tài)測試）和“運行”軟件（動態(tài)測試）。 也有人認(rèn)為軟件測試（software testing）就是在軟件投入運行前，對軟件需求分析、設(shè)計規(guī)格說明和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵步驟。 軟件測試有兩個基本職責(zé)：即驗證和確認(rèn)。 注意：區(qū)分軟件測試和

4、軟件調(diào)試。 1.2.21.2.2軟件測試生命周期軟件測試生命周期 測試的生命周期（software testing life cycle）分為幾個階段（如圖1-1所示 ）。 前三個階段就是引入程序錯誤階段； 后三個階段就是清除程序錯誤的階段。 需求規(guī)格說明設(shè)計編碼測試缺陷分類缺陷分離缺陷排除修復(fù)錯誤錯誤錯誤錯誤錯誤錯誤錯誤錯誤3(失效)圖1-1 測試生命周期 1.2.3 1.2.3軟件開發(fā)與測試模型軟件開發(fā)與測試模型 下面我們將介紹幾種典型的軟件開發(fā)與測試模型。 一、軟件開發(fā)與測試一、軟件開發(fā)與測試V V模型模型 在傳統(tǒng)開發(fā)過程中測試不受重視，僅把它作為在需求分析、概要設(shè)計、詳細(xì)設(shè)計及編碼之后

5、的一個階段。尤其在瀑布模型中。 如圖1-2所示，在V模型中，描述了一些不同的測試級別，并說明了這些級別所對應(yīng)的生命周期中不同的階段，清楚地描述了這些測試階段和開發(fā)過程期間的對應(yīng)關(guān)系。 用戶需求獲取需求定義需求分析需求分析書概要設(shè)計概要設(shè)計書詳細(xì)設(shè)計詳細(xì)設(shè)計書編碼程序軟件產(chǎn)品可交付軟件系統(tǒng)測試已確認(rèn)軟件確認(rèn)測試已集成軟件集成測試已測試模塊單元測試需求分析評審評審評審評審評審評審評審評審圖1-2 V模型示意圖 V模型適用于所有類型的開發(fā)過程，但并不一定適用于開發(fā)和測試過程的所有方面。 二、軟件開發(fā)與測試二、軟件開發(fā)與測試WW模型模型 由于各種原因，開發(fā)的每一個環(huán)節(jié)都可能產(chǎn)生錯誤，如果堅持各個階段的

6、技術(shù)評審,就能夠盡早發(fā)現(xiàn)和預(yù)防錯誤。 圖1-3為軟件開發(fā)與測試的W 模型，形象地說明了軟件測試與開發(fā)的這種同步性。 需求測試需求分析功能測試概要設(shè)計設(shè)計測試詳細(xì)設(shè)計單元測試編碼系統(tǒng)測試驗收確認(rèn)測試確認(rèn)集成測試集成圖1-3 W模型示意圖 應(yīng)用該模型的優(yōu)點在于，每個軟件開發(fā)活動結(jié)束后就可以執(zhí)行相應(yīng)的測試，如：在需求分析結(jié)束后，就可以進(jìn)行需求分析測試。 三、軟件開發(fā)與測試三、軟件開發(fā)與測試HH模型模型 與前兩種模型相比，H模型充分地體現(xiàn)了測試過程。如圖1-4所示的H 模型揭示了: 1、 軟件測試不僅僅指測試的執(zhí)行, 還包括很多其他的活動。 2、軟件測試是一個獨立的流程, 貫穿產(chǎn)品的整個開發(fā)周期, 與

7、其它流程并發(fā)進(jìn)行。 3、軟件測試要盡早準(zhǔn)備, 盡早執(zhí)行。 測試準(zhǔn)備測試執(zhí)行測試流程其他流程測試就緒點圖1-4 H模型示意圖 4、軟件測試根據(jù)被測物的不同是分層次的. 不同層次的測試活動可以是按照某個次序先后進(jìn)行的, 但也可能是反復(fù)的。 1.2.4 1.2.4與軟件測試相關(guān)的術(shù)語與軟件測試相關(guān)的術(shù)語 1.錯誤（Error） 程序員在編寫代碼時會出錯，我們把這種錯誤稱之為bug。隨著開發(fā)過程的進(jìn)行，錯誤會不斷的放大。 2.缺陷(Default) 缺陷是錯誤的結(jié)果，更精確的說是錯誤的表現(xiàn)。 3.失效（Failure） 在缺陷運行時，常常會發(fā)生失效的情況。一種是過錯缺陷對應(yīng)的失效；一種是遺漏缺陷對應(yīng)的

8、失效。 4.測試（Test） 測試是一項采用測試用例執(zhí)行軟件的活動，在這項活動中某個系統(tǒng)或組成的部分將在特定的條件下運行，然后要觀察并記錄結(jié)果，以便對系統(tǒng)或組成部分進(jìn)行評價。 5.測試用例(Test Case) 測試用例是為特定的目的而設(shè)計的一組測試輸入、執(zhí)行條件和預(yù)期的結(jié)果。 6.回歸測試（Regression testing） 回歸測試的目的是為了測試由于修正缺陷而更新的應(yīng)用程序，以確保徹底修正了上一個版本的缺陷，并且沒有引入新的軟件缺陷。 1.31.3軟件測試技術(shù)分類軟件測試技術(shù)分類 從不同的角度，可以把軟件測試技術(shù)分成不同種類，如： 一 、從是否需要執(zhí)行被測軟件的角度，可分為靜態(tài)測試和

9、動態(tài)測試。 那些不利用計算運行被測程序，而是通過其他手段達(dá)到測試目的的方法稱作靜態(tài)測試。下面我們對這幾種靜態(tài)測試分別加以介紹： 代碼檢查 代碼走查 桌面檢查 同行評分 下面我們將要介紹的黑盒測試和白盒測試就屬于動態(tài)測試。 二、從軟件測試用例設(shè)計方法的角度，可分為黑盒測試（Black-Box Testing）和白盒測試（White-Box Testing）。 三、按照軟件測試的策略和過程分類，軟件測試可分為單元測試(Unit Testing)、集成測試(Integration Testing)、確認(rèn)測試(Validation Testing)、系統(tǒng)測試(System Testing)和驗收測試(

10、Verification Testing)。 1.41.4軟件測試的目的軟件測試的目的 測試真正的目的是使我們通過對軟件錯誤的原 因和分布進(jìn)行歸納，來發(fā)現(xiàn)并排除當(dāng)前軟件產(chǎn)品的 缺陷，對在需求和設(shè)計過程中存在的問題查缺補漏，從而確保軟件產(chǎn)品的質(zhì)量。 GMyers給出了關(guān)于測試的一些規(guī)則，我們也可以把這些規(guī)則看作是測試的目標(biāo)： 1)軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。 2)測試是為了證明程序有錯，而不是證明程序無錯。 3)一個好的測試用例在于他能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤。 4)一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。 這里要強調(diào)的一點是，軟件測試不只是軟件測試人員的工作，也是軟件開發(fā)人員和軟

11、件使用者的工作。 1.51.5軟件測試的原則軟件測試的原則 1.5.11.5.1盡早地和不斷地進(jìn)行軟件測試盡早地和不斷地進(jìn)行軟件測試 IBM的研究結(jié)果表明，缺陷存在放大趨勢。圖1-5表示了缺陷放大模型大致狀況。需求階段缺陷概要設(shè)計階段缺陷詳細(xì)設(shè)計階段缺陷代碼階段缺陷放大n1倍放大n2倍放大n3倍圖1-5 缺陷放大模型 由此可見，問題發(fā)現(xiàn)越早，解決問題的代價就越小，這是軟件開發(fā)過程中的黃金法則。 1.5.21.5.2不可能完全的測試不可能完全的測試 對一個程序進(jìn)行完全測試就是意味著在測試結(jié)束之后，再也不會發(fā)現(xiàn)其它的軟件錯誤了。其實，這是不可能的，主要原因有以下幾點： 一、不可能測試程序?qū)λ锌赡?/p>

12、輸入的響應(yīng)。 二、不可能測試到程序每一條可能的執(zhí)行路徑 三、無法找出所有的設(shè)計錯誤 四、不能采用邏輯來證明程序的正確性 1.5.3 1.5.3增量測試，由小到大增量測試，由小到大 測 試 時 間測 試 范 圍可 用 資 源系 統(tǒng) 測 試集 成 測 試單 元 測 試單 元 測 試圖1-7 測試資源關(guān)系圖 由小到大，指的是軟件測試的粒度。無論是傳統(tǒng)的軟件測試還是面向?qū)ο蟮能浖y試都要遵循這樣的原則。如圖1-7所示，多個單元組合過渡到集成測試階段，集成測試階段過渡到更高級別的系統(tǒng)測試階段，虛線是各個測試階段的發(fā)布基線。隨著測試的逐步深入，范圍的逐步擴大，測試時間、可用資源也隨之增大。 1.5.41.

13、5.4避免測試自己的程序避免測試自己的程序 避免程序員測試自己的代碼的主要原因歸納如下： 1.程序員輕易不會承認(rèn)自己寫的程序有錯誤。 2.程序員的測試思路有局限性，在做測試時很容易受到編程思路的影響。 3.多數(shù)程序員沒有嚴(yán)格正規(guī)的職業(yè)訓(xùn)練，缺乏專業(yè)測試人員的意識。 4.程序員沒有養(yǎng)成錯誤跟蹤和回歸測試的習(xí)慣. 1.5.5 1.5.5設(shè)計周密的測試用例設(shè)計周密的測試用例 軟件測試的本質(zhì)就是針對要測試的內(nèi)容確定一組測試用例。測試用例至少應(yīng)該包括如下幾個基本信息： 1、在執(zhí)行測試用例之前，應(yīng)滿足的前提條件。 2、輸入（合理的、不合理的）。 3、預(yù)期輸出（包括后果和實際輸出）。 圖1-8顯示了一個典型

14、的測試用例所應(yīng)該具有的基本信息。測試用例ID：目的：前提：輸入：預(yù)期輸出：后果：執(zhí)行歷史：日期： 結(jié)果： 版本： 執(zhí)行人：圖1-8 典型的測試用例信息 測試用例是測試工作的核心，應(yīng)該盡量設(shè)計的周密細(xì)致，這樣才能更好的保證測試工作的質(zhì)量。 下面舉例來說明這一點。 以一個實現(xiàn)登錄功能的小程序為例，它允許用戶選擇城市和地區(qū)，輸入自己的賬號和密碼。 如圖1-9所示，通過Alt-F4組合鍵和“Exit”按鈕來終止程序，Tab鍵在區(qū)域中間移動。 操操 作作 員員 登登 錄錄 選 擇 城 市 選 擇 地 區(qū) 城 市地 區(qū)操 作 員密 碼提 交退 出圖1-9 登錄窗口下面根據(jù)組成頁面的具體元素，分別從幾個方面

15、做了一些比較全面的測試用例：1. 下拉框和輸入框測試用例 表1-1 下拉框和輸入框測試用例測試內(nèi)容測試內(nèi)容輸入操作輸入操作預(yù)期輸出預(yù)期輸出實際結(jié)果實際結(jié)果下拉框下拉框未和后臺數(shù)據(jù)庫綁定未和后臺數(shù)據(jù)庫綁定（顯示列表元素固（顯示列表元素固定）定）不允許列表中出不允許列表中出現(xiàn)現(xiàn)NULL現(xiàn)現(xiàn)象，固定象，固定“請選擇請選擇-”已和后臺數(shù)據(jù)庫綁定已和后臺數(shù)據(jù)庫綁定（顯示列表元素活（顯示列表元素活動）動）不允許列表中出不允許列表中出現(xiàn)現(xiàn)NULL現(xiàn)現(xiàn)象，固定象，固定“請選擇請選擇-”輸輸入入框框限定字符型限定字符型輸入輸入12、6無無#，*等等錯誤提示錯誤提示限定型數(shù)字限定型數(shù)字輸入輸入測試數(shù)據(jù)測試數(shù)據(jù)無無

16、12月、月、7*、0錯誤提示錯誤提示2、功能測試 （表1-2 功能測試用例）用 例應(yīng)產(chǎn)生行為結(jié)果失敗原因1.基本功能測試1.1在輸入框內(nèi)輸入資料并且執(zhí)行存儲程序必須能夠接受使用者的輸入并且將輸入值存在登錄文件內(nèi)1.2在輸入框內(nèi)不輸入資料但執(zhí)行儲存程序必須能夠檢查使用者輸入是否為空白，同時必須能夠告知使用者原因1.3檢查city字段儲存結(jié)果City字段輸入 后存入cookies1.4檢查area字段儲存結(jié)果Area字段輸入 后存入cookies儲存結(jié)果1.5檢查ID 字段儲存結(jié)果ID字段輸入 后存入cookies2.使用接口功能測試2.1檢查輸入字段的輸入值必須組織使用者輸入空白，同時部分字段只

17、能輸入數(shù)字2.2檢查使用者接口的Tab Order所有的Tab Order必須按照正常順序2.2檢查所有的Button所有的Button必須能夠起作用2.3檢查所有的Hot Key所有的Hot Key必須能夠起作用3、各種錯誤數(shù)據(jù)的測試表1-3 錯誤數(shù)據(jù)的測試用例測試內(nèi)容測試內(nèi)容輸入操作輸入操作預(yù)選測試數(shù)預(yù)選測試數(shù)據(jù)據(jù)預(yù)期輸出預(yù)期輸出實際結(jié)果實際結(jié)果點擊登錄點擊登錄按鈕按鈕不完整的數(shù)不完整的數(shù)據(jù)據(jù)CityCity，areaarea，IDID，pswdpswd略略提示錯誤對話提示錯誤對話框框不正確的數(shù)不正確的數(shù)據(jù)據(jù)CityCity，areaarea，IDID，pswdpswd略略提示錯誤對話提示

18、錯誤對話框框回車操作回車操作不完整的數(shù)不完整的數(shù)據(jù)據(jù)CityCity，areaarea，IDID，pswdpswd略略提示錯誤對話提示錯誤對話框框點擊點擊“退退出出”按鈕按鈕無無無無無無關(guān)閉當(dāng)前應(yīng)用關(guān)閉當(dāng)前應(yīng)用系統(tǒng)系統(tǒng)4、特殊測試 表1-4 特殊測試用例測試內(nèi)容測試內(nèi)容輸入操作輸入操作預(yù)選測試數(shù)預(yù)選測試數(shù)據(jù)據(jù)預(yù)期輸出預(yù)期輸出操作焦點逃操作焦點逃逸逸連續(xù)連續(xù)TabTab切換，察看異常切換，察看異常無無焦點可準(zhǔn)確回歸焦點可準(zhǔn)確回歸當(dāng)前操作窗口當(dāng)前操作窗口分配內(nèi)存不分配內(nèi)存不足足啟動多個應(yīng)用程序或模擬啟動多個應(yīng)用程序或模擬多個程序運行多個程序運行無無是否可以正常運是否可以正常運行行網(wǎng)絡(luò)斷線網(wǎng)絡(luò)斷線切

19、斷網(wǎng)絡(luò)連接切斷網(wǎng)絡(luò)連接無無是否可正常拋出是否可正常拋出異常異常 1.5.6 1.5.6注意錯誤集中的現(xiàn)象注意錯誤集中的現(xiàn)象 軟件缺陷的“扎堆”現(xiàn)象的常見形式： 1、對話框的某個控件功能不起作用，可能其他控件的功能也不起作用。 2、某個文本框不能正確顯示雙字節(jié)字符，則其他文本框也可能不支持雙字節(jié)字符。 3、聯(lián)機幫助某段文字的翻譯包含了很多錯誤，與其相鄰的上下段的文字可能也包含很多的語言質(zhì)量問題。 4、安裝文件某個對話框的“上一步”或“下一步”按鈕被截斷，則這兩個按鈕在其他對話框中也可能被截斷。 1.5.7 1.5.7確認(rèn)確認(rèn)BUGBUG的有效性的有效性 有時候測試人員提交的BUG并不是真正的BU

20、G。圖1-10具體地描述了無效BUG的來源。一般由A測試人員發(fā)現(xiàn)的BUG，一定要由另外一個B測試人員來進(jìn)行確認(rèn)，如果發(fā)現(xiàn)嚴(yán)重的BUG可以召開評審會進(jìn)行討論和分析。圖1-10 無效BUG來源構(gòu)成圖 1.5.8 1.5.8合理安排測試計劃合理安排測試計劃 合理的測試計劃有助于測試工作順利有序地進(jìn)行，因此要求在對軟件進(jìn)行測試之前所作的測試計劃中，應(yīng)該結(jié)合了多種針對性強的測試方法、列出所有可使用資源，建立一個正確的測試目標(biāo)； 要本著嚴(yán)謹(jǐn)、準(zhǔn)確的原則，周到細(xì)致地做好測試前期的準(zhǔn)備工作，避免測試的隨意性。尤其是要盡量科學(xué)合理地安排測試時間。 ABABCABCDEF基本結(jié)構(gòu)（a）（b）（c）單純依賴多重依賴

21、復(fù)合依賴圖1-11 錯誤依賴關(guān)系1.5.91.5.9回歸測試回歸測試 這些錯誤之間存在單純的依賴或者復(fù)雜的多重依賴關(guān)系，如圖1-11所示。 其中，（a）圖中的A、B 關(guān)系表達(dá)為：A錯誤依賴于B錯誤的關(guān)閉而關(guān)閉。如果多了一條路徑（如（b）圖中A、B、C關(guān)系），A錯誤依賴于B錯誤和C錯誤的同時關(guān)閉而關(guān)閉。（c）圖是（a）和（b）的復(fù)合方式，因程序中的錯誤存在著一對多，多對多的復(fù)雜關(guān)系而變得難以處理，并且有些錯誤關(guān)聯(lián)和依賴關(guān)系處于隱性狀態(tài)。 1.5.101.5.10測試結(jié)果的統(tǒng)計和分析測試結(jié)果的統(tǒng)計和分析 只有對這些輸出信息進(jìn)行深入地統(tǒng)計、分析和比較，才能夠正確的鑒別測試后輸出的數(shù)據(jù)，給出清晰的錯誤

22、原因分析報告。當(dāng)輸出的信息很龐大時，我們可以借助專業(yè)的測試工具。 1.5.11 1.5.11及時更新測試及時更新測試 事實上，有可能導(dǎo)致測試失敗的原因還有很多，可大致歸納為如下幾點： 1、測試團(tuán)隊管理者失職； 2、測試團(tuán)隊中溝通不好； 3、測試團(tuán)隊和項目團(tuán)隊溝通不良； 4、測試過程中，執(zhí)行角色無準(zhǔn)確定義； 5、測試團(tuán)隊缺乏良好的培訓(xùn)。 1.6 1.6軟件測試工作流程軟件測試工作流程 一般的軟件測試總體工作流程如圖1-12所示： 立項階段需求階段設(shè)計階段編碼單元測試階段集成測試階段系統(tǒng)測試階段驗收測試階段結(jié)項總結(jié)階段圖1-12 軟件測試工作總體流程圖 1、需求階段 需求階段是軟件測試活動的前提。

23、需求階段測試工作流程如圖1-13所示： 需 求 工 作 培 訓(xùn)編 寫 需 求業(yè) 務(wù) 、 用 戶 、 功 能需 求 評 審需 求 規(guī) 格 說 明 書需 求 變 更需 求 變 更 記 錄需 求 報 警總 體 測 試 計 劃系 統(tǒng) 測 試 方 案需 求 報 警 信 號需 求 跟 蹤 矩 陣進(jìn) 入 下 一 階 段需需求求階階段段測測試試工工作作流流程程圖1-13 需求階段測試活動流程圖2、設(shè)計&編碼階段測試工作流程 圖1-14 設(shè)計&編碼階段測試流程圖上一階段需求相關(guān)文擋概要設(shè)計評審詳細(xì)設(shè)計單元測試方案編碼單元測試測試抽檢單元測試總結(jié)報告進(jìn)入下一階段集成測試方案自動測試方案抽象出驗證標(biāo)

24、準(zhǔn)設(shè)設(shè)計計& &編編碼碼階階段段測測試試工工作作流流程程以模塊為單位，不斷循環(huán) 這一環(huán)節(jié)以模塊為單位循環(huán)：單元測試方案制定編碼單元測試是否通過測試抽檢是否通過，重新編寫沒有通過單元測試和測試抽檢的代碼。最終形成一份單元測試總結(jié)報告。具體流程如圖1-14所示。 3、集成測試、系統(tǒng)測試和驗收測試階段 該測試階段流程如圖1-15所示： 上一階段集成測試方案集成測試系統(tǒng)測試申請測試部評估自動測試方案系統(tǒng)測試方案系統(tǒng)測試系統(tǒng)測試綜合報告驗收測試質(zhì)量合格證書產(chǎn)品化工作產(chǎn)品工作報告測試工作總結(jié)集集成成、系系統(tǒng)統(tǒng)、驗驗收收測測試試階階段段圖1-15 集成測試、系統(tǒng)測試和驗收測試階段流程圖 1.

25、7 1.7軟件測試中的誤區(qū)軟件測試中的誤區(qū) 誤區(qū)1 調(diào)試和測試是一樣的 誤區(qū)2 軟件測試在軟件開發(fā)過程中并不重要 誤區(qū)3 在軟件開發(fā)結(jié)束之后進(jìn)行測試 誤區(qū)4 過分依賴Beta測試 誤區(qū)5 過分依賴自動化測試 誤區(qū)6 測試是可窮盡的 誤區(qū)7 測試是證明軟件的正確性 誤區(qū)8 可以忽略測試的設(shè)計 1.81.8一個貫穿全文的例子一個貫穿全文的例子 電廠兩票管理系統(tǒng)電廠兩票管理系統(tǒng) 1.8.1 1.8.1系統(tǒng)簡介系統(tǒng)簡介 操作票、工作票（簡稱兩票）是“電業(yè)(電廠)安全工作規(guī)程”中的核心內(nèi)容之一，對保證電業(yè)安全生產(chǎn)具有重要的作用。操作票是保證正確電氣倒閘（熱機）操作的重要環(huán)節(jié)和前提條件，使用操作票的目的是

26、為了保障人身與設(shè)備的安全，確保電氣設(shè)備倒閘操作的正確性，防止電氣誤操作事故發(fā)生。 工作票是保證電氣(電廠設(shè)備)檢修工作安全的重要措施，是檢修人員在運行設(shè)備上或運行區(qū)域內(nèi)進(jìn)行檢修和試驗工作，以及做可能影響設(shè)備的正常運行或備用狀態(tài)的其它工作的重要書面依據(jù)?！皟善薄钡霓k理過程基本上都是開票、各部門負(fù)責(zé)人或三種人審批簽字、工作結(jié)束、部門或廠部檢查審核這樣的一種線性辦理過程。 電力部門分為水電、火電、供電三種類型，各廠、局要處理的兩票類型通常有： 水電廠：電氣一種工作票、電氣二種工作票、水力機械工作票、一級動火工作票、二級動火工作票、電氣倒閘操作票、繼保安措票、腳手架工作單、水力機械操作票、溢洪閘門操作

27、票 火電廠：電氣一種工作票、電氣二種工作票、水力機械工作票、一級動火工作票、二級動火工作票、電氣倒閘操作票、繼保安措票、腳手架工作單、熱力工作票 供電局：電氣一種工作票、電氣二種工作票、水力機械工作票、一級動火工作票、二級動火工作票、電氣倒閘操作票、繼保安措票、腳手架工作單、 一種工作票、線路二種工作票。 為了使讀者更好的了解兩票系統(tǒng)以及后面各章節(jié)的內(nèi)容，在這里對一些電力系統(tǒng)專業(yè)術(shù)語作如下解釋： 一次圖：電氣主接線是由高壓電器通過連接線，按其功能要求組成接受和分配電能的電路，成為傳輸強電流、高電壓的網(wǎng)絡(luò)，故又稱為一次接線。那么用規(guī)定的設(shè)備文字和圖形符號并按工作順序排列，詳細(xì)地表示電氣設(shè)備或成套

28、裝置的全部基本組成和連接關(guān)系的單線接線圖，成為主接線電路圖，這里簡稱為一次圖。 二次圖：在電力系統(tǒng)中，凡監(jiān)視、控制、測量以及起保護(hù)作用的設(shè)備，如機電保護(hù)、控制和信號裝 置等，皆屬于二次設(shè)備。二次接線就是由二次設(shè)備構(gòu)成的回路。這里我們就把二次設(shè)備接線圖簡稱為二次圖。 分廠：發(fā)電廠通常由多個分廠組成，其中電氣分廠、汽機分廠和鍋爐分廠是發(fā)電廠的幾個重要的分廠。 電氣設(shè)備：為滿足生產(chǎn)的需要，發(fā)電廠中安裝有各種設(shè)備。通常把生產(chǎn)和分配電能的設(shè)備稱為一次設(shè)備，具體包括如下幾種：生產(chǎn)和轉(zhuǎn)換電能的設(shè)備；接通或斷開電路的開關(guān)電器；限制故障電流和防御過電壓的電氣；接地裝置；載流導(dǎo)體。此外還有一些對一次設(shè)備進(jìn)行測量、

29、控制、監(jiān)視和保護(hù)用的二次設(shè)備，如：儀用互感器；機電保護(hù)及自動裝置；直流電源設(shè)備等。 在本書中提到的刀閘、開關(guān)等設(shè)備就屬于電氣設(shè)備。 “五妨”規(guī)則：電力系統(tǒng)的倒閘操作具有前后順序和嚴(yán)格的邏輯規(guī)則?！拔宸馈币?guī)則就是根據(jù)電氣運行人員多年的運行經(jīng)驗，總結(jié)出來的倒閘操作規(guī)則，如下： 1、防止誤分合斷路器;防止帶地線合刀閘 2、防止帶負(fù)荷拉合隔離開關(guān); 3、防止帶電掛接地線或接地刀閘; 4、防止帶接地線或合接地刀閘送電; 5、防止誤入帶電間隔 1.8.21.8.2系統(tǒng)運行環(huán)境系統(tǒng)運行環(huán)境 客戶端平臺：windows98/2000、windows NT workstation、Linux等所有具有支持JAV

30、A的瀏覽器系統(tǒng)； 服務(wù)器端平臺：windows2000 server、windows NT Server、Linux、UNIX等所有支持JAVA Bean的系統(tǒng)平臺； 數(shù)據(jù)庫服務(wù)器：Oracle數(shù)據(jù)庫或SQL Server 2000數(shù)據(jù)庫或ACCESS數(shù)據(jù)庫。 Web服務(wù)器：Tomcat 5.0 1.8.31.8.3系統(tǒng)總體結(jié)構(gòu)系統(tǒng)總體結(jié)構(gòu) 兩票系統(tǒng)主要由兩部分構(gòu)成，即：操作票子系統(tǒng)和工作票子系統(tǒng)。整個系統(tǒng)的總體結(jié)構(gòu)如圖1-16所示：1.8.41.8.4系統(tǒng)功能系統(tǒng)功能( (略略) )兩票系統(tǒng)工作票系統(tǒng)功能模塊操作票系統(tǒng)功能模塊操作票檔案管理模塊電氣操作票模塊熱機操作票模塊操作票打印操作票存檔

31、熱力工作票模塊電氣第一種工作票模塊電氣第二種工作票模塊工作票打印工作票回填及存檔圖1-16 兩票系統(tǒng)總體結(jié)構(gòu)圖 本章小結(jié)本章小結(jié) 本章介紹了軟件測試發(fā)展的歷程，以及其在國內(nèi)的發(fā)展?fàn)顩r。隨著軟件開發(fā)過程和開發(fā)技術(shù)的不斷改進(jìn)，軟件測試?yán)碚摵头椒ㄒ苍诓粩嗤晟?，測試工具也在蓬勃發(fā)展。 通過本章的論述，可以了解到軟件測試已經(jīng)不再只是進(jìn)行簡單的程序邏輯檢查，而是一個伴隨著整個軟件開發(fā)過程的活動。 測試對象也不僅僅是程序代碼，而開發(fā)過程中產(chǎn)生的所有軟件產(chǎn)品，甚至是產(chǎn)品使用說明也包括在內(nèi)。 測試過程中為了更好的保證軟件測試的質(zhì)量，首先要遵循一定的測試原則，最為重要的就是應(yīng)該盡早的進(jìn)行測試。 其次，正確處理開發(fā)

32、與測試之間的關(guān)系，更好的把開發(fā)與測試過程集成到一起。從而提高測試效率，節(jié)約測試成本。 本章所介紹的幾種軟件開發(fā)與測試模型，如：V模型、W模型和H模型，三種模型在不同程度上反映了軟件開發(fā)與軟件測試的關(guān)系。 其中，V模型非常明確地標(biāo)明了測試過程中存在的不同級別，并且清楚地描述了測試和開發(fā)過程中各階段的對應(yīng)關(guān)系。而W模型作為V模型的改進(jìn)，更好地體現(xiàn)了軟件開發(fā)與軟件測試工作的同步性，更為明確地指出測試的對象不僅僅是程序本身，而且包括需求分析、概要設(shè)計和詳細(xì)設(shè)計說明書，強調(diào)了軟件測試是軟件開發(fā)過程中的一項重要的工作，貫穿于整個軟件開發(fā)過程。 H模型則從微觀的角度來看待軟件測試過程。 最后一個做好測試工作

33、的關(guān)鍵因素就是精心的組織和安排軟件測試的工作流程，本章把測試工作分為幾個階段，分別闡述了通用的測試工作流程，但要求讀者在工作中，根據(jù)每個項目的具體情況制定可行的測試流程。 各種測試技術(shù)是軟件測試工作的敲門磚，本章從不同的角度介紹了軟件測試技術(shù)的分類。 從是否需要執(zhí)行被測軟件的角度，可分為靜態(tài)測試（Static Testing）和動態(tài)測試（Dynamic Testing）； 從測試用例設(shè)計的角度，可分為黑盒測試和白盒測試；按照軟件測試過程和測試策略，可分為單元測試、集成測試和系統(tǒng)測試。 另外，本章還專門介紹了目前在實際工作中對軟件測試的錯誤認(rèn)識，希望讀者能夠明確軟件測試的目的，正確的認(rèn)識軟件測試

34、工作的必要性和重要性。習(xí)題習(xí)題1. 名詞解釋： 軟件測試 錯誤 缺陷 失效 測試用例 回歸測試 靜態(tài)測試 動態(tài)測試 黑盒測試 白盒測試 單元測試 集成測試 系統(tǒng)測試 2. 簡述軟件測試發(fā)展的過程。從不同角度描述軟件測試的現(xiàn)狀。3. 測試的生命周期可以分為幾個階段？簡單描述各階段需要完成的任務(wù)。4. 什么是V模型？簡述V模型在軟件測試過程中的作用，以及在V模型中各個測試階段和開發(fā)過程的對應(yīng)關(guān)系。5. 請概括一下靜態(tài)測試和動態(tài)測試，以及黑盒測試與白盒測試的不同點。6. 分別描述一下，需求階段、設(shè)計&編碼階段、集成系統(tǒng)驗收測試的軟件測試流程。7. 列舉軟件測試的目的。8. 列舉軟件測試的十項

35、原則。9. 列舉軟件測試的誤區(qū)。第二章第二章 軟件測試基礎(chǔ)軟件測試基礎(chǔ) 本章要點本章要點 軟件測試基礎(chǔ)知識； 白盒測試和黑盒測試的定義； 常見的白盒和黑盒測試設(shè)計技術(shù)； 白盒測試與黑盒測試的區(qū)別； 測試計劃和測試報告的編制； 測試用例的定義和編制方法。 本章目標(biāo)本章目標(biāo) u掌握有關(guān)測試的一些數(shù)學(xué)知識，包括集合、函數(shù)和圖論基礎(chǔ)等；u理解并掌握白盒測試和黑盒測試，以及二者的優(yōu)缺點和各自的應(yīng)用范圍；u能夠熟練使用幾種常見測試用例設(shè)計技術(shù)；u了解測試計劃和測試文檔的作用，以及應(yīng)該包含的內(nèi)容和制定方法；u了解測試報告的基本內(nèi)容，以及測試用例的基本內(nèi)容和編制方法。 2.12.1用于測試的離散數(shù)學(xué)和圖論基礎(chǔ)

36、用于測試的離散數(shù)學(xué)和圖論基礎(chǔ) 一般而言，在功能性測試中，通常要用到離散數(shù)學(xué)知識，而在結(jié)構(gòu)性測試領(lǐng)域中，則要用到一些關(guān)于圖論的知識。 2.1.12.1.1集合論集合論 集合論可分為：自然和不言自明兩種。自然的集合論把集合看作是基本術(shù)語，我們把集合看作一個單位，或一個整體引用多個事物。 集合的表示法有以下兩種： 1、將集合所有元素一一列出的表示法叫做“枚舉法”，但有時也可以只列出一部分元素。 2、用一個集合所具有的共同性質(zhì)來刻畫這個集合。 2.1.22.1.2函數(shù)函數(shù) 簡而言之，函數(shù)是將唯一的輸出值賦予每一輸入的“法則”。 2.1.32.1.3關(guān)系關(guān)系 通俗的講，關(guān)系就是客觀世界一定范圍的對象之間

37、的某種特定聯(lián)系。 集合之間的關(guān)系集合之間的關(guān)系 定義: : 給定兩個集合A和B，關(guān)系R是笛卡兒積A B的一個子集。 如果希望描述整個關(guān)系，則通常只寫RAB。對于特定元素aiA、biB，我們記做aiRbi 。 關(guān)系的表示關(guān)系的表示 關(guān)系關(guān)系表示事物之間的某種聯(lián)系，二元關(guān)系表示兩個事物之間的關(guān)系，如果把這兩個事物分別放在一邊，如果某兩個元素有關(guān)系，那么就在它們之間畫一條有向線，用這種方式表示關(guān)系，稱作關(guān)系圖。 這里我們必須對“勢”進(jìn)行解釋。勢在用于集合時，是指集合中的元素的個數(shù)。 定義定義: : 給定兩個集合A和B，一個關(guān)系RAB，關(guān)系R的勢是： 1）一對一勢 2）多對一勢 3）一對多勢 4）多對

38、多勢 單個集合上的關(guān)系單個集合上的關(guān)系 首先，我們對關(guān)系進(jìn)行定義。設(shè)A是一個集合，RAA是定義在A上的一個關(guān)系，、R。關(guān)系具有四個特殊屬性： 定義定義: : 關(guān)系RAA是： 1）自反的 2）對稱的 3）反對稱的 4）傳遞的 2.1.42.1.4命題邏輯命題邏輯 凡是能分辨其真假的語句都叫做命題。我們通常采用小寫字母p，q和r表示命題。 命題邏輯有著和集合論相似的操作，表達(dá)式和標(biāo)識。命題的真值只有兩種，T代表真，而F代表假。 命題公式的分類：命題公式的分類： 如果命題公式A在任意的真值賦值函數(shù)t : U0, 1下的真值t(A)都為1,則稱命題公式A為永真式(tautology)（或稱重言式）；

39、如果命題A在任意的真值賦值函數(shù)下的真值都為0，則稱A為矛盾式(contradiction)； 如果A不是矛盾式，則稱為可滿足式。 2.1.52.1.5概率論概率論 概率是隨機事件發(fā)生的可能性的數(shù)量指標(biāo)。 在獨立隨機事件中，如果某一事件在全部事件中出現(xiàn)的頻率，在更大的范圍內(nèi)比較明顯的穩(wěn)定在某一固定常數(shù)附近。就可以認(rèn)為這個事件發(fā)生的概率為這個常數(shù)。對于任何事件的概率值一定介于 0和 1之間。 2.1.6 2.1.6用于測試的圖用于測試的圖 測試中使用兩種基本圖：無向圖和有向圖。這里我們給出一些概念。 圖（又叫做線性圖）是一種由兩種集合定義的抽象數(shù)據(jù)結(jié)構(gòu)，即一個節(jié)點集合和一個構(gòu)成節(jié)點之間連接的集合。

40、 圖中節(jié)點的度節(jié)點的度是以該節(jié)點作為端點的邊的條數(shù)。 在本節(jié)中將介紹的三種圖：程序圖、有限狀態(tài)機、狀態(tài)圖。 1、程序圖 經(jīng)過改進(jìn)的程序圖定義：節(jié)點要么是整個語句，要么是語句的一部分，邊表示控制流（從節(jié)點i到節(jié)點j有一條邊，當(dāng)且僅當(dāng)對應(yīng)節(jié)點j的語句或語句的一部分，可以立即在節(jié)點i對應(yīng)的語句或語句的一部分之后執(zhí)行）。 程序的有向圖公式化能夠非常準(zhǔn)確地描述程序的測試方面的問題?；窘Y(jié)構(gòu)化程序設(shè)計的構(gòu)造，例如：串行、選擇和循環(huán)等可以用如圖 2-1所示的有向圖表示。串行If-Then-ElseIf-Then條件前測試環(huán)路后測試環(huán)路圖2-1 結(jié)構(gòu)化程序設(shè)計構(gòu)造的有向圖 2、有限狀態(tài)機 有限狀態(tài)機已經(jīng)成為需

41、求規(guī)格說明的一種相當(dāng)標(biāo)準(zhǔn)的表示方法。有限狀態(tài)機是一種有向圖，其中狀態(tài)是節(jié)點，轉(zhuǎn)移是邊。 圖2-2是一個簡單的自動柜員機(SATM)系統(tǒng)。該圖描述了用于個人標(biāo)識編號PIN嘗試部分的有限狀態(tài)機。這種機器包含5 個狀態(tài)（空閑、等待第一次PIN嘗試等等）和8個用邊表示的轉(zhuǎn)移。轉(zhuǎn)移上的標(biāo)簽所遵循的規(guī)則是，“分子”是引起轉(zhuǎn)移的事件，“分母”是與該轉(zhuǎn)移關(guān)聯(lián)的行為。空閑等待第一次PIN輸入嘗試等待事務(wù)選擇等待第三次PIN輸入嘗試等待第二次PIN輸入嘗試合法卡顯示屏幕S2正確PIN顯示屏幕S5不正確的PIN顯示屏幕S4非法卡顯示屏幕S1;退卡不正確的PIN顯示屏幕S3不正確的PIN顯示屏幕S3正確PIN顯示屏幕

42、S5圖2-2 用于PIN嘗試的有限狀態(tài)機 3、狀態(tài)圖 狀態(tài)圖現(xiàn)在被Rational公司選為統(tǒng)一建模語言，即UML的控制模型。圖2-3 狀態(tài)圖的團(tuán)點 Harel使用與方法無關(guān)的術(shù)語“團(tuán)點”表示狀態(tài)圖的基本構(gòu)建塊。在圖2-3中，團(tuán)點A包含兩個團(tuán)點B和C，通過邊連接。團(tuán)點A通過邊與團(tuán)點D連接。 根據(jù)Harel的意圖，我們可以把團(tuán)點解釋為狀態(tài)，把邊解釋為轉(zhuǎn)移。 在圖2-4中，狀態(tài)A是初始狀態(tài)，當(dāng)進(jìn)入到這個狀態(tài)時，也進(jìn)入低層狀態(tài)B。當(dāng)進(jìn)入某個狀態(tài)時，我們可以認(rèn)為該狀態(tài)是活動的，這可與Petri網(wǎng)中的被標(biāo)記地點類比。狀態(tài)圖工具采用色彩表示哪個狀態(tài)活動的，并等效于Petri網(wǎng)中的標(biāo)記地點。 圖2-4中有一些

43、微妙的地方，從狀態(tài)A轉(zhuǎn)移到狀態(tài)D初看起來是有歧義的，因為它沒有區(qū)分狀態(tài)B和C。約定是，邊必須開始和結(jié)束于狀態(tài)的周圍。如果狀態(tài)包含子狀態(tài)，就像圖中的A一樣，邊會“引用”所有的子狀態(tài)。 因此，從A到D的邊意味著轉(zhuǎn)移可以從狀態(tài)B或從狀態(tài)C發(fā)生。如果有從狀態(tài)D到狀態(tài)A的邊，如圖2-5所示，則用B來表示初始狀態(tài)這個事實，意味著轉(zhuǎn)移實際上是從狀態(tài)D到狀態(tài)B。這種約定可以大大減緩有限狀態(tài)機向“空心代碼”發(fā)展的趨勢。 圖2-4 狀態(tài)圖中的初始狀態(tài) 圖2-5 進(jìn)入自狀態(tài)的默認(rèn)入口 我們最后要討論的一個狀態(tài)圖的特性就是并發(fā)狀態(tài)圖概念。圖2-6中狀態(tài)D的虛線用于表示狀態(tài)D實際上引用兩個并發(fā)狀態(tài)E和F。圖2-6 并發(fā)

44、狀態(tài) 2.2 2.2白盒測試白盒測試 白盒測試是一種可視的測試軟件的方法，即它把測試對象看作一個透明的盒子，測試人員要了解程序結(jié)構(gòu)和處理過程，按照程序內(nèi)部邏輯測試程序，檢查程序中的每條通路是否按照預(yù)定要求正確工作。白盒測試的過程如圖2-7所示： 源程序測試用例被測程序執(zhí)行路徑分析覆蓋情況分析圖2-7 白盒測試過程示意圖 那么，在對被測軟件進(jìn)行白盒測試時，主要對程序進(jìn)行哪些方面的檢查呢？有如下幾點： （）保證一個模塊中的所有獨立執(zhí)行路徑至少測試一次； （）對所有邏輯判定取值“true”和“false”的兩種情況都至少測試一次； （）在循環(huán)邊界和運行界限內(nèi)執(zhí)行循環(huán)體； （）測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性

45、。 在軟件測試領(lǐng)域，有六種基本的測試類型：單元測試，集成測試，功能測試/系統(tǒng)測試，可接受性測試，回歸測試和Beta測試。白盒測試可以用在其中的三種測試類型中： 1、單元測試 2、集成測試 3、回歸測試 2.2.12.2.1白盒測試與調(diào)試的異同白盒測試與調(diào)試的異同 白盒測試和調(diào)試有哪些不同點呢？ 1、從承擔(dān)的任務(wù)來看，白盒測試同其他類型測試一樣，它的任務(wù)是發(fā)現(xiàn)所開發(fā)的項目中的缺陷；但是，調(diào)試不屬于測試，其任務(wù)是糾正軟件中的缺陷。 2、從最終的結(jié)果來看，白盒測試有預(yù)知的結(jié)果，不可預(yù)知的只是程序是否通過測試，并且成功測試的結(jié)果是發(fā)現(xiàn)錯誤的癥狀，從而引起調(diào)試的進(jìn)行；而調(diào)試的結(jié)果是消除項目中的錯誤。 3

46、、從執(zhí)行的過程來看，測試是一個發(fā)現(xiàn)錯誤、改正錯誤、重新測試的過程；而調(diào)試是一個推理過程。 4、從準(zhǔn)備工作來看，測試從已知的條件開始，使用預(yù)先定義的程序；調(diào)試一般是以不可知的內(nèi)部條件開始，做統(tǒng)一性調(diào)試 。 5、從執(zhí)行的計劃性來看，測試是有計劃的并要進(jìn)行測試設(shè)計；而調(diào)試則不受時間約束。 6、從執(zhí)行的人員來看，測試經(jīng)常是由獨立的測試組在不了解軟件設(shè)計的條件下完成的，而調(diào)試必須由程序員來完成。 7、從所使用的工具來看，大多數(shù)白盒測試的執(zhí)行和設(shè)計可有工具支持，而調(diào)試程序員能利用的工具主要是調(diào)試器。 2.2.22.2.2白盒測試的用例設(shè)計白盒測試的用例設(shè)計 白盒測試用例設(shè)計技術(shù)就是研究如何用最少的測試用例

47、最大限度地發(fā)現(xiàn)軟件中的錯誤，目前主要有基本路徑測試、等價類劃分/邊界值分析測試、覆蓋測試、循環(huán)測試、數(shù)據(jù)流測試、程序插樁測試、變異測試等等方法。下面主要對幾種常見的方法加以介紹： 一、基本路徑測試 二、等價類劃分/邊界值分析（Equivalence partitioning/boundary value analysis） 三、控制流/覆蓋測試（Control-flow/Coverage Testing） 方法覆蓋 方法覆蓋可用于衡量測試用例所覆蓋的方法的百分比。 語句覆蓋（Statement Coverage） 語句覆蓋是一種衡量測試所覆蓋的程序語句百分比的措施。通過測試應(yīng)該達(dá)到100%程序

48、語句覆蓋的目標(biāo)，可以標(biāo)識圈數(shù)，然后執(zhí)行最少的一組測試用例就可以達(dá)到語句覆蓋的目標(biāo)。 判斷/分支覆蓋 判斷/分支覆蓋是為了衡量在測試過程中覆蓋了多少個程序中的布爾表達(dá)式。簡單循環(huán)嵌套循環(huán)串接循環(huán)無結(jié)構(gòu)循環(huán)圖2-11 各種循環(huán)圖 四、循環(huán)測試是一種白盒測試技術(shù)，注重于循環(huán)構(gòu)造的有效性。n 循環(huán)結(jié)構(gòu)測試用例的設(shè)計循環(huán)可以劃分為以下幾種模式，如圖2-11： 可以使用如下方法設(shè)計循環(huán)測試用例： 一、簡單循環(huán)： 二、嵌套循環(huán)： 三、串接循環(huán)： 四、無結(jié)構(gòu)循環(huán)： 五、數(shù)據(jù)流測試： 六、程序插裝： 程序插裝（Program Instrumentation）是指在程序中設(shè)置斷點或打印語句，在執(zhí)行過程中了解程序的

49、一些動態(tài)特性。 七、變異測試 變異測試（Mutation Testing）的提出始于70年代末期，是一種錯誤驅(qū)動測試，即針對某類特定程序錯誤而進(jìn)行的測試，也是一種比較成熟的排錯性測試方法（排錯性測試方法的基本思想是通過檢驗測試數(shù)據(jù)集的排錯能力來判斷軟件測試的充分性）。 2.2.32.2.3白盒測試舉例（略）白盒測試舉例（略） 2.32.3黑盒測試黑盒測試 黑盒測試也稱作功能測試和行為測試，主要是根據(jù)功能需求來測試程序是否按照預(yù)期工作。 黑盒測試的目的是盡量發(fā)現(xiàn)代碼所表現(xiàn)的外部行為的錯誤，主要有以下幾類： 功能不正確或不完整； 接口錯誤； 接口所使用的數(shù)據(jù)結(jié)構(gòu)錯誤； 行為或性能錯誤； 初始化和終

50、止錯誤。 黑盒測試的示意圖如圖2-14 所示。從圖2-14中，我們可以看出黑盒測試只考慮程序的輸入和輸出，無須考慮程序的內(nèi)部代碼。 圖2-14 黑盒測試示意圖2.3.12.3.1黑盒測試和白盒測試的異同黑盒測試和白盒測試的異同 本書歸納出以下幾點：1. 執(zhí)行測試人員不同 黑盒測試通常由用戶以及非開發(fā)人員來進(jìn)行；而白盒測試通常要有了解軟件內(nèi)部結(jié)構(gòu)的開發(fā)人員來做。2. 測試覆蓋目標(biāo)不同 如果我們用一個盒子來代替整個軟件系統(tǒng)，那么黑盒測試可以看成是一種系統(tǒng)測試。而對盒子內(nèi)部的多個單元的測試就可以稱作為白盒測試。 另外一種區(qū)別就是，二者的覆蓋目標(biāo)不同。黑盒測試的目標(biāo)是覆蓋所有的用戶需求；而白盒測試的目

51、標(biāo)是覆蓋所有的代碼。3、測試動機不同 有效的安全測試有時也需要詳細(xì)了解代碼以及系統(tǒng)結(jié)構(gòu)，此時把這些技術(shù)稱作白盒測試。 另外一種風(fēng)險測試的目標(biāo)可能就只是測試軟件是否能夠為用戶提供預(yù)期輸出。可用性測試就是如此，所以被稱作黑盒測試。 4、測試方法不同 一個最普通的區(qū)別就是行為測試設(shè)計是基于功能需求來定義測試，而結(jié)構(gòu)測試則是基于代碼本身來定義測試的。這就是兩種設(shè)計測試的方法。因為行為測試是基于外部功能定義的，所以稱作黑盒測試；結(jié)構(gòu)測試則是基于代碼內(nèi)部結(jié)構(gòu)來定義的，所以稱作白盒測試。 5、評估測試方法不同 一些技術(shù)是使用代碼工具來跟蹤軟件內(nèi)部的工作過程，因此稱為白盒測試技術(shù)。與之相比，黑盒測試技術(shù)只是簡

52、單的觀察程序的正常輸出。 2.3.22.3.2黑盒測試的用例設(shè)計黑盒測試的用例設(shè)計 常用的黑盒測試用例設(shè)計方法主要有以下幾種：功能圖分析方法，等價類劃分方法，邊界值分析方法，錯誤推測方法，因果圖方法，判定表驅(qū)動分析方法，正交實驗設(shè)計方法和功能圖分析方法等。 下面對上述方法分別作以簡要介紹。 一、基于用戶需求的測試 黑盒測試用例就是基于用戶需求的，也是從研究客戶需求工作開始的。 二、對等區(qū)間劃分 對等區(qū)間劃分是一種黑盒測試方法，該方法也稱為等價類劃分，是一種設(shè)計測試用例的非常形式化的方法。 三、邊界值分析法 邊界值分析方法是對等價類劃分方法的補充。長期的測試工作經(jīng)驗告訴我們,大量的錯誤是發(fā)生在輸

53、入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內(nèi)部。 四、狀態(tài)轉(zhuǎn)換測試 狀態(tài)轉(zhuǎn)換測試適用于軟件被設(shè)計成一個狀態(tài)機或?qū)崿F(xiàn)了一種被建模成一種狀態(tài)機的情況?？梢栽O(shè)計測試用例測試狀態(tài)間轉(zhuǎn)換，測試用例創(chuàng)建引起轉(zhuǎn)換的事件?？梢栽O(shè)計負(fù)面測試的測試用例用于測試狀態(tài)與事件的非法組合。 五、分支測試 在分支測試中，測試用例用于測試單元的控制流分支或決策點。通常用于實現(xiàn)決策覆蓋（Decision Coverage）的測試目標(biāo)。 六、錯誤推測法 錯誤推測法就是根據(jù)經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤，借助邊界值分析等方法有針對性的設(shè)計測試用例的方法。 七、因果圖方法 因果圖方法適合于檢查程序輸入條件的各種組合

54、情況。使用該方法首先要理解軟件所表示的對象及其關(guān)系，然后，定義一組保證“所有對象與其他對象都具有所期望的關(guān)系”的測試序列。 2.3.32.3.3黑盒測試舉例（略）黑盒測試舉例（略） 2.42.4白盒測試和黑盒測試的比較白盒測試和黑盒測試的比較 1、白盒測試只關(guān)注軟件產(chǎn)品的測試，不能夠確保產(chǎn)品已經(jīng)實現(xiàn)了規(guī)格說明中的所有功能。黑盒測試則只關(guān)注規(guī)格說明中的功能測試，不能夠保證已經(jīng)實現(xiàn)的各個部分都被測試到。 2、與黑盒測試相比，白盒測試的成本要高一些。 3、黑盒測試故意不考慮控制結(jié)構(gòu)，而只注意信息域。白盒測試只考慮測試軟件產(chǎn)品，它不保證完整的需求規(guī)格是否被滿足。黑盒測試是一種確認(rèn)技術(shù)，回答“我們在構(gòu)造

55、一個正確的系統(tǒng)嗎？白盒測試是一種驗證技術(shù)，回答“我們在正確地構(gòu)造一個系統(tǒng)嗎？” 總之，建議測試人員在進(jìn)行測試的過程中，可以考慮先使用黑盒測試，然后統(tǒng)計相應(yīng)的覆蓋率，再設(shè)計適當(dāng)?shù)陌缀袦y試用例作為補充以保證測試的完整性。 2.4.12.4.1白盒測試的優(yōu)缺點白盒測試的優(yōu)缺點 1）優(yōu)點可構(gòu)成測試數(shù)據(jù)對特定程序部分測試，可以檢測代碼中的每條分支和路徑；揭示隱藏在代碼中的錯誤；對代碼的測試比較徹底；有較多工具支持；有一定的充分性度量手段。 2）缺點工作量大, 成本高。通常只用于單元測試，有應(yīng)用局限；無法檢測代碼中遺漏的路徑和數(shù)據(jù)敏感性錯誤；不能驗證規(guī)格說明的正確性；無法對規(guī)格說明中未實現(xiàn)的部分進(jìn)行測試；

56、不易生成測試數(shù)據(jù)(通常)。2.4.22.4.2黑盒測試的優(yōu)缺點黑盒測試的優(yōu)缺點1. 優(yōu)點對于較大的代碼單元來說，效率高；測試人員不需要了解實現(xiàn)的細(xì)節(jié)，包括具體的編程語言；測試員和程序員可以由不同的人員來擔(dān)任；從用戶的角度進(jìn)行測試，容易被理解和接受；有助于暴露任何規(guī)格不一致或有歧義的問題；測試用例的設(shè)計可以在規(guī)格說明完成之后馬上進(jìn)行；容易入手生成測試數(shù)據(jù)；適用于各階段測試。2. 缺點實際上，只有一小部分可能的輸入被測試到，某些代碼得不到測試；如果沒有清晰、簡潔的規(guī)格說明，難以設(shè)計測試用例；如果測試人員不知道開發(fā)人員已經(jīng)執(zhí)行過該測試用例，會存在不必要的重復(fù)測試；會有很多程序路徑?jīng)]有被測試到；不能直

57、接針對可能隱蔽了許多問題的特定程序段進(jìn)行測試，；如果規(guī)格說明有誤，則無法發(fā)現(xiàn)；不易進(jìn)行充分性測試。2.4.32.4.3灰盒測試灰盒測試 灰盒測試介于白盒測試和黑盒測試之間，是現(xiàn)代測試的一種理念。就是指，在白盒測試中交叉使用黑盒測試的方法；在黑盒測試中交叉使用白盒測試的方法。2.52.5測試方法的選擇測試方法的選擇 一、單元測試 測試方法：白盒測試 參考規(guī)范：詳細(xì)設(shè)計說明和代碼結(jié)構(gòu) 二、集成測試 測試方法：黑盒和白盒測試 參考規(guī)范：詳細(xì)設(shè)計說明和概要設(shè)計說明 2.6 2.6測試計劃與測試文檔測試計劃與測試文檔 最常見的測試文檔包括測試計劃，測試規(guī)范，測試用例和測試時發(fā)現(xiàn)缺陷后要寫的缺陷報告等。

58、那么，測試計劃和測試文檔在測試過程中能夠發(fā)揮什么樣的作用呢？ 1、測試文檔有助于測試任務(wù)的完成。 2、使用測試文檔可以更好的協(xié)調(diào)測試任務(wù)與測試過程。 3、測試文檔為測試項目的組織、規(guī)劃與管理提供了一個架構(gòu)。 2.6.1 2.6.1測試計劃的制定測試計劃的制定為了給讀者一個宏觀的認(rèn)識，首先請看測試計劃活動圖，如圖2-20所示。 在制定測試計劃過程中，核心活動就是： 一、確定測試策略 通常，可以采用以下幾個方法來制定測試策略： 1、確定測試的范圍 2、確定測試的方法 3、確定測試標(biāo)準(zhǔn)和質(zhì)量檢查點 4、確定自動化測試策略 二、確定測試系統(tǒng)（硬件和軟件） 1、測試架構(gòu) 測試架構(gòu)指的就是測試用例的組織結(jié)

59、構(gòu)。 取得需求文檔：需求定義文檔需求規(guī)格說明文檔需求追蹤矩陣確定測試策略：測試的范圍測試方法測試入口自動化測試策略確定測試系統(tǒng)：測試架構(gòu)測試環(huán)境測試配置預(yù)估測試工作量：確定任務(wù) 按人天和工作周來預(yù)估工作量 得到時間進(jìn)度計劃和里程碑 評估進(jìn)度風(fēng)險并制定風(fēng)險化解計劃準(zhǔn)備并復(fù)查測試計劃：編寫策略、系統(tǒng)、工作量和時間進(jìn)度文檔與項目團(tuán)隊一起復(fù)查測試計劃圖2-20 測試計劃活動 2、測試工具 3、測試環(huán)境 測試環(huán)境的組成包括物理測試設(shè)施，產(chǎn)品運行的操作系統(tǒng)、產(chǎn)品運行的計算平臺等。 4、測試配置情況 需要排列配置的優(yōu)先級，然后決定哪些配置需要全面測試，哪些可以進(jìn)行部分測試。 三、預(yù)估測試工作量（資源和時間進(jìn)

60、度計劃） 對項目進(jìn)行預(yù)估有5個準(zhǔn)備步驟： 1、確定要完成的任務(wù)。 2、確定每項任務(wù)所需的工作量和整個測試生命周期的工作量。 3、確定完成每項任務(wù)以及整個測試生命周期所需的時間。 4、為測試工作建立詳細(xì)的時間進(jìn)度計劃和里程碑表。 5、評估時間進(jìn)度風(fēng)險并準(zhǔn)備緩解風(fēng)險計劃。 四、準(zhǔn)備并復(fù)查測試計劃文檔。 1、測試計劃格式 2、測試計劃復(fù)查 2.6.22.6.2測試報告測試報告 測試報告是測試階段最后的文檔產(chǎn)出物，優(yōu)秀的測試經(jīng)理應(yīng)該具備良好的文檔編寫能力，一 份詳細(xì)的測試報告包含足夠的信息，包括產(chǎn)品質(zhì)量和測試過程的評價，測試報告基于測試中的數(shù)據(jù)采集以及對最終測試結(jié)果的分析。 2.6.32.6.3測試用例的編制測試用例的編制 本節(jié)我們首先