1、主講：于海洋,高等院校計算機系列課程,軟件測試,教材,軟件測試技術(shù)，21世紀(jì)高等院校計算機系列教材 作者：曲朝陽等編著，出版社：中國水利水電出版社，2006-8-1，ISBN：7508439295,參考教材,軟件測試教程 重點大學(xué)計算機教材 作者：宮云戰(zhàn) 主編 ，出版社：機械工業(yè)出版社 ，2008-9-1，ISBN：711124897,參考教材,軟件測試 作者：美Paul .Jorgensen 譯者：韓柯 杜旭濤 出版社：機械工業(yè)出版社 原出版社： CRC,參考教材,計算機 軟件測試技術(shù) 鄭人杰 清華大學(xué)出版社，1990。,參考教材,軟件測試教程 作者: 賀平出版社: 電子工業(yè)出版社頁數(shù): 3

2、19定價: 29.0出版時間: 2005-06-01,教學(xué)目標(biāo),了解軟件測試的基本原理和基本概念 掌握基本的軟件測試方法和技術(shù) 提高軟件質(zhì)量控制的意識和素質(zhì) 培養(yǎng)工程實踐及團隊合作精神,評分標(biāo)準(zhǔn),上機實踐：熟練運用軟件測試的方法和技術(shù)，在對實際程序進行測試，同時遵照軟件文檔規(guī)范提交設(shè)計文檔、源程序和測試報告 (20%) 平時出勤及課堂練習(xí)(10%) 期末考試-閉卷考試(70%),軟件錯誤無處不在,只要是人編寫的軟件，就不能避免軟件錯誤的發(fā)生。,軟件錯誤的案例(1),迪斯尼的獅子王游戲 時間：19941995 背景：迪斯尼公司首次進軍兒童游戲市場，市場宣傳力度很大，前期銷售情況很好 出現(xiàn)的問題：

3、該游戲在一些PC機上無法玩 原因：迪斯尼公司沒有對市場上已經(jīng)投入運行的PC機型進行調(diào)研，并且進行測試，導(dǎo)至該游戲只在程序員開發(fā)游戲的系統(tǒng)上可以運行，但在大眾使用的常見系統(tǒng)中無法運行 結(jié)果：迪斯尼公司不得不承擔(dān)客戶的投訴、產(chǎn)品退貨、更換光盤、以及又一輪的調(diào)試、修改和測試的所有費用。,軟件錯誤的案例(2),Intel奔騰浮點除法軟件缺陷 時間：1994 背景：Intel發(fā)布的一款新處理器 問題：在裝有這款處理器計算機的計算器中執(zhí)行算式“(4195835/3145727)3145727-4195835”不等于0 原因：老式奔騰CPU的浮點除法軟件有缺陷 結(jié)果：Intel事實上在芯片發(fā)布之前，已經(jīng)發(fā)現(xiàn)

4、了這個缺陷，但認(rèn)為不嚴(yán)重，沒有修正。被外界發(fā)現(xiàn)后，試圖掩飾。最終，迫于輿論壓力公開道歉，花費4億美元更換老芯片。,軟件錯誤的案例(3),美國航天局火星極地登陸 時間：1999年12月3日 背景：火星極地登陸飛船在試圖登陸火星表面時失蹤。 問題：某一個數(shù)據(jù)位被意外復(fù)位. 原因：測試過程分兩組：一組是測試飛船腳的落地打開過程；另一組是測試飛船打開后的著陸過程；前一組沒有注意數(shù)據(jù)位是否被置位，因為這不是他們負(fù)責(zé)的范圍。而后一個組在每次測試之前又重置計算機，清除所有的數(shù)據(jù)位。雙方獨立工作都很正常，但兩個組沒有進行集成測試。 結(jié)果：飛船墜毀,軟件錯誤的案例(4),千年蟲 時間：20世紀(jì)90年代 背景：隨

5、著21世紀(jì)的到來，很多的計算機系統(tǒng)都面臨著“千年蟲”的危害 問題：這樣就導(dǎo)致2000年以后的年份的記錄出現(xiàn)問題，如00年是指1900還是2000？ 原因：20世紀(jì)70年代時，由于計算機存儲空間很小，并且十分昂貴，所以在計算機中記錄時間采用了“偷懶”的方式，例如將1973縮減為73 結(jié)果：世界各地為了更換和升級系統(tǒng)，花費了上百億的美元,軟件錯誤的案例(5),愛國者導(dǎo)彈防御系統(tǒng)炸死自家人 背景：海灣戰(zhàn)爭時導(dǎo)彈防御系統(tǒng) 問題：軟件系統(tǒng)缺陷 原因：系統(tǒng)時間的累計錯誤，延時14個小時，造成跟蹤系統(tǒng)失去了準(zhǔn)確度。 結(jié)果：愛國者導(dǎo)彈炸死28名美軍士兵。,軟件測試工程師，需要具備哪些能力？,通用技能上：1.基

6、本計算機知識（操作系統(tǒng)，數(shù)據(jù)庫，通訊協(xié)議原理，熟悉至少一門編程語言） 2.基本軟件測試知識（各種測試?yán)碚?，測試方法論，測試用例編寫，缺陷界定標(biāo)準(zhǔn)，軟件質(zhì)量評估） 3.簡單項目管理知識,軟件測試工程師，需要具備哪些能力？,性格上：有牛皮糖屬性的為佳，越“不要臉”越好測試工程師提交的BUG越多，意味著研發(fā)工程師工作質(zhì)量越差，需要返工的工作量也越大，甚至?xí)绊懣冃?，所以測試工程師有時候很容易得罪研發(fā)部門。一個可以相對堅持原則（比如3級BUG以上一定要改），又能拉下臉和不愉快的研發(fā)工程師保持較好關(guān)系的測試工程師，會對項目質(zhì)量起到很關(guān)鍵作用。,軟件測試工程師，需要具備哪些能力？,你不是產(chǎn)品，但你知道產(chǎn)品

7、是怎么工作的； 你不是運營，但你知道用戶關(guān)心什么； 你不是開發(fā)，但你知道開發(fā)同事怎么工作； 你不是設(shè)計，但你有你對交互邏輯的理解； 你不是銷售和編輯，但你熟悉產(chǎn)品業(yè)務(wù)。,第一章 概述, 本章要點 軟件測試的發(fā)展歷史； 軟件測試技術(shù)的分類方法； 軟件測試原則； 軟件測試的定義； 軟件測試同軟件開發(fā)之間的關(guān)系； 軟件測試與開發(fā)模型； 軟件測試工作流程。, 本章目標(biāo) 了解軟件測試的發(fā)展歷程和行業(yè)現(xiàn)狀； 掌握軟件測試技術(shù)的分類； 理解軟件測試的目的和軟件測試原則，以及了解人們對軟件測試行業(yè)的錯誤認(rèn)識； 掌握軟件測試中的基本定義、基本知識; 理解軟件開發(fā)與軟件測試的關(guān)系。,1.1軟件測試的發(fā)展歷程及現(xiàn)狀

8、 1.1.1軟件測試的發(fā)展歷程 20世紀(jì)50-60年代，軟件仍然處于次要位置,測試?yán)碚摵头椒ǖ陌l(fā)展比較緩慢。 70年代以后，軟件技術(shù)的成熟和完善使得軟件測試的規(guī)模和復(fù)雜度加大，軟件測試也逐漸形成了一套完整的體系，逐漸走向規(guī)范化。 如今對軟件質(zhì)量的要求越來越高，質(zhì)量的控制已經(jīng)不僅僅是傳統(tǒng)意義上的基于代碼運行上的測試。軟件測試已經(jīng)是一個基于整個軟件生命周期的質(zhì)量控制活動。,1.1軟件測試的發(fā)展歷程及現(xiàn)狀 1.1.2軟件測試的現(xiàn)狀 與一些發(fā)達(dá)國家相比，國內(nèi)測試工作還存在一定的差距。國內(nèi)測試人員所占比例小。 微軟的開發(fā)工程師與測試工程師的比例是1 : 2,國內(nèi)一般公司是6 ：1. 與發(fā)達(dá)國家相比，我們

9、的差距主要在測試意識，測試?yán)碚摰难芯浚瑴y試工具軟件的開發(fā)以及從業(yè)人員的數(shù)量等方面。,1.1軟件測試的發(fā)展歷程及現(xiàn)狀 近年來，隨著軟件外包行業(yè)的興起，國內(nèi)軟件質(zhì)量保證的意識也在加強。占整體外包業(yè)務(wù)85%的對日軟件外包中主要的工作就是軟件測試。 IBM，百度，華為，惠普，盛大，聯(lián)想等大型IT企業(yè)均表示出對成熟軟件測試人員的期盼。,1.2 什么是軟件測試（software testing） 1.2.1軟件測試的定義 根據(jù)側(cè)重點的不同，主要有以下三種觀點： 1）“使用人工或自動手段運行或測定某個系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的需求或是弄清預(yù)期結(jié)果與實際結(jié)果之間的差別”，該定義明確地提出了軟件

10、測試以檢驗是否滿足需求為目標(biāo)。 2）“軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程”，明確提出了“尋找錯誤”是測試目的。,3）從軟件質(zhì)量保證的角度看：是一種重要的軟件質(zhì)量保證活動，其動機是通過一些經(jīng)濟、高效的方法，捕捉軟件中的錯誤，從而達(dá)到保證軟件內(nèi)在質(zhì)量的目的。 最終目的是驗證軟件是否按著預(yù)期運行。 測試過程中的活動包括“分析”軟件（靜態(tài)測試）和“運行”軟件（動態(tài)測試）。 也有人認(rèn)為軟件測試（software testing）就是在軟件投入運行前，對軟件需求分析、設(shè)計規(guī)格說明和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵步驟。,軟件測試有兩個基本職責(zé)： 確認(rèn)：保證開發(fā)過程中軟件符合產(chǎn)品說明書的過程 驗證：

11、保證最終產(chǎn)品滿足用戶要求的過程 經(jīng)常會確認(rèn)了但沒有驗證，例如1990年哈勃天文望遠(yuǎn)鏡事件。 注意：區(qū)分軟件測試和軟件調(diào)試。 1，調(diào)試分析和定位BUG，不能完全代替測試。 2，調(diào)試是為了使軟件正確運行，測試是找錯誤。 3，調(diào)試對象是源代碼，測試的對象是開發(fā)過程各個階段的所有產(chǎn)品。,1.2.2軟件測試生命周期 測試的生命周期（software testing life cycle）分為幾個階段（如圖1-1所示 ）。 前三個階段就是引入程序錯誤階段； 后三個階段就是清除程序錯誤的階段。,圖1-1 測試生命周期,1.2.3軟件開發(fā)與測試模型 下面我們將介紹幾種典型的軟件開發(fā)與測試模型。 一、軟件開發(fā)模

12、型 1、大爆炸模型 一大堆能量（這里指開發(fā)軟件所需的人力和物力）放在一起，巨大的能量進行釋放，通常的結(jié)果可能是產(chǎn)生了優(yōu)秀的軟件產(chǎn)品或成為一堆“廢品”（不成功的軟件）。 優(yōu)點：思路簡單，計劃、進度和正規(guī)開發(fā)過程幾乎沒有，所有的精力集中在開發(fā)軟件和編寫代碼上,通?？赡苁情_發(fā)者的“突發(fā)奇想” 缺點：開發(fā)過程是非工程化的，隨意性大。由于軟件已經(jīng)完成，不可能回頭修復(fù)已經(jīng)無法挽回的問題，軟件測試的工作其實只是向用戶報告發(fā)現(xiàn)的問題。 關(guān)于測試：有的較簡單，有的則非常困難。測試工作妨礙軟件的交付，測試越深入，就會發(fā)現(xiàn)越來越多的缺陷，實際中測試幾乎不作。,1.2.3軟件開發(fā)與測試模型 一、軟件開發(fā)模型 1、大爆

13、炸模型,？,1.2.3軟件開發(fā)與測試模型 一、軟件開發(fā)模型 瀑布模型 瀑布模型是將軟件生命周期的各項活動，規(guī)定為按照固定順序相連的若干個階段性工作，形如瀑布流水，最終得到軟件產(chǎn)品。,1.2.3軟件開發(fā)與測試模型 一、軟件開發(fā)模型 瀑布法 優(yōu)點：易于理解；調(diào)研開發(fā)的階段性；強調(diào)早期計劃及需求調(diào)查；能夠確定何時能夠交付產(chǎn)品及何時進行評審與測試。 缺點：需求調(diào)查分析只進行一次，不能適應(yīng)需求變化；順序的開發(fā)流程，使得開發(fā)中的經(jīng)驗教訓(xùn)不能反饋到該項目的開發(fā)中去；不能反映出軟件開發(fā)過程的反復(fù)與迭代性；沒有包含任何類型的風(fēng)險評估；開發(fā)中出現(xiàn)的問題直到開發(fā)后期才能夠顯露，因此失去及早糾正的機會。,邊寫邊改法

14、采用邊寫邊改法的軟件開發(fā)通常只是有了比較粗略的想法就開始進行簡單的設(shè)計、然后進行較長的反復(fù)編寫、測試與修復(fù)，是一個循環(huán)的過程。在認(rèn)為無法更精細(xì)的描述軟件產(chǎn)品要求時，就發(fā)布產(chǎn)品。 優(yōu)點：能夠較為迅速的展現(xiàn)成果，適合需要快速制作而且用完就扔的小項目，如示范程序、演示程序等。 缺點：其編碼和測試可能將是長期的循環(huán)往復(fù)的過程。,快速原型模型 快速原型模型的第一步是建造一個快速原型，實現(xiàn)客戶或未來的用戶與系統(tǒng)的交互，用戶或客戶對原型進行評價，進一步細(xì)化待開發(fā)軟件的需求。 通過逐步調(diào)整原型使其滿足客戶的要求，開發(fā)人員可以確定客戶的真正需求是什么；第二步則在第一步的基礎(chǔ)上開發(fā)客戶滿意的軟件產(chǎn)品。,螺旋模式法

15、 螺旋模式是瀑布模式與邊寫邊改演化模式相結(jié)合，并加入風(fēng)險評估所建立的軟件開發(fā)模式。 每一個螺旋周期，為開發(fā)的一次迭代 在每次迭代中，沒有固定定義的軟件活動，而是根據(jù)需要選擇。 將開發(fā)活動與風(fēng)險分析相結(jié)合，用于降低和控制風(fēng)險。,軟件開發(fā)與軟件測試的關(guān)系,測試與開發(fā)各階段的關(guān)系,軟件測試與軟件開發(fā)過程的關(guān)系,1.2.3軟件開發(fā)與測試模型 一、軟件開發(fā)與測試V模型 在傳統(tǒng)開發(fā)過程中測試不受重視，僅把它作為在需求分析、概要設(shè)計、詳細(xì)設(shè)計及編碼之后的一個階段。尤其在瀑布模型中。 V模型，描述了一些不同的測試級別， 級別對應(yīng)的生命周期中不同的階段， 這些測試階段和開發(fā)過程期間存在對應(yīng)關(guān)系。,V模型示意圖,

16、二、軟件開發(fā)與測試W模型 開發(fā)的每一個環(huán)節(jié)都可能產(chǎn)生錯誤，如果堅持各個階段的技術(shù)評審,就能夠盡早發(fā)現(xiàn)和預(yù)防錯誤。 W 模型，形象地說明了軟件測試與開發(fā)的這種同步性。 W模型的優(yōu)點在于，每個軟件開發(fā)活動結(jié)束后就可以執(zhí)行相應(yīng)的測試，如：在需求分析結(jié)束后，就可以進行需求分析測試。,圖1-3 W模型示意圖,三、軟件開發(fā)與測試H模型 與前兩種模型相比，H模型充分地體現(xiàn)了測試過程。 1、 軟件測試不僅僅指測試的執(zhí)行, 還包括很多其他的活動。 2、軟件測試是一個獨立的流程, 貫穿產(chǎn)品的整個開發(fā)周期, 與其它流程并發(fā)進行。 3、軟件測試要盡早準(zhǔn)備, 盡早執(zhí)行。,圖1-4 H模型示意圖,4、軟件測試根據(jù)被測物的

17、不同是分層次的. 不同層次的測試活動可以是按照某個次序先后進行的, 但也可能是反復(fù)的。,1.2.4與軟件測試相關(guān)的術(shù)語 1.錯誤（Error） 程序員在編寫代碼時會出錯，我們把這種錯誤稱之為bug。隨著開發(fā)過程的進行，錯誤會不斷的放大。 2.缺陷(Default) 缺陷是錯誤的結(jié)果，更精確的說是錯誤的表現(xiàn)。 包括過錯缺陷和遺漏缺陷。 過錯缺陷：信息輸入到了不正確的表現(xiàn)形式中 遺漏缺陷：沒有輸入信息,3.失效（Failure） 在缺陷運行時，常常會發(fā)生失效的情況。一種是過錯缺陷對應(yīng)的失效；一種是遺漏缺陷對應(yīng)的失效。 4.測試（Test） 測試是一項采用測試用例執(zhí)行軟件的活動，在這項活動中某個系統(tǒng)

18、或組成的部分將在特定的條件下運行，然后要觀察并記錄結(jié)果，以便對系統(tǒng)或組成部分進行評價。,5.測試用例(Test Case) 測試用例是為特定的目的而設(shè)計的一組測試輸入、執(zhí)行條件和預(yù)期的結(jié)果。 6.回歸測試（Regression testing） 回歸測試的目的是為了測試由于修正缺陷而更新的應(yīng)用程序，以確保徹底修正了上一個版本的缺陷，并且沒有引入新的軟件缺陷。 回歸測試可分為： 完全回歸測試 嚴(yán)重性高 部分回歸測試 時間緊張，測試內(nèi)容過多,1.3軟件測試技術(shù)分類 從不同的角度，可以把軟件測試技術(shù)分成不同種類， 一 、從是否需要執(zhí)行被測軟件的角度，可分為靜態(tài)測試和動態(tài)測試。 比如檢查二手車，看車漆

19、屬于靜態(tài)測試，發(fā)動聽音則屬于動態(tài)測試。,靜態(tài)測試 那些不利用計算運行被測程序，而是通過其他手段達(dá)到測試目的的方法稱作靜態(tài)測試。 幾種靜態(tài)測試 代碼檢查：以小組為單位閱讀代碼 代碼走查：在檢查的基礎(chǔ)上，還要執(zhí)行邏輯運行 桌面檢查：由一個人進行的代碼檢查與走查 同行評分：不為發(fā)現(xiàn)錯誤，對代碼自己質(zhì)量進行評價,動態(tài)測試 動態(tài)測試的對象：必須是能夠運行的程序。 通過輸入測試用例，并對實際輸出結(jié)果和預(yù)期輸出結(jié)果進行比較分析，從而發(fā)現(xiàn)錯誤的測試屬于動態(tài)測試。 黑盒測試和白盒測試就屬于動態(tài)測試。,二、從軟件測試用例設(shè)計方法的角度，可分為黑盒測試（Black-Box Testing）和白盒測試（White-B

20、ox Testing）。 黑盒測試：又叫功能性測試，測試人員只需知道軟件要做什么？無法看到軟件如何運行。目的是檢查程序各個功能是否實現(xiàn)。 白盒測試：測試人員可以訪問代碼，并通過檢查代碼線索來協(xié)助測試。目的是檢查內(nèi)部操作是否按規(guī)定執(zhí)行，功能是否得到充分使用。,三、按照軟件測試的策略和過程分類，軟件測試可分為 單元測試(Unit Testing)：針對每個單元的測試，是測試的最小單位。 集成測試(Integration Testing)：主要檢查與軟件設(shè)計相關(guān)的程序結(jié)構(gòu)問題。 確認(rèn)測試(Validation Testing)：測試程序能否滿足所有功能和性能的需求。 系統(tǒng)測試(System Test

21、ing)：測試軟件與系統(tǒng)的其他部分的協(xié)調(diào)性。 驗收測試(Verification Testing)：從用戶角度進行測試。,1.4軟件測試的目的 測試真正的目的是使我們通過對軟件錯誤的原因和分布進行歸納，來發(fā)現(xiàn)并排除當(dāng)前軟件產(chǎn)品的缺陷，對在需求和設(shè)計過程中存在的問題查缺補漏，從而確保軟件產(chǎn)品的質(zhì)量。,測試的目標(biāo)： 1)軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。 2)測試是為了證明程序有錯，而不是證明程序無錯。 3)一個好的測試用例在于他能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤。 4)一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。 軟件測試不只是軟件測試人員的工作，也是軟件開發(fā)人員和軟件使用者的工作。,1.5軟件測試

22、的原則 1.5.1盡早地和不斷地進行軟件測試 缺陷存在放大趨勢。,圖1-5 缺陷放大模型,問題發(fā)現(xiàn)越早，解決問題的代價就越小，這是軟件開發(fā)過程中的黃金法則。,1.5.2不可能完全的測試 對一個程序進行完全測試就是意味著在測試結(jié)束之后，再也不會發(fā)現(xiàn)其它的軟件錯誤了。這是不可能的。 主要原因有以下幾點： 一、不可能測試程序?qū)λ锌赡茌斎氲捻憫?yīng)。 1，對所有有效輸入 2，對所有無效輸入 3，對所有編輯過的輸入（如Backspace反復(fù)編輯） 4，對所有輸入時機的變化 （輸入的隨機中斷）,無法進行完全測試的例子,程序P,X,Y,Z,若X、Y為所有可能的整數(shù) 在字長32位機上 測試X1、Y1 Z1 Xn

23、、Yn Zn n = 232232 = 264 1.84 1019,1.5.2不可能完全的測試 二、不可能測試到程序每一條可能的執(zhí)行路徑,1.5.2不可能完全的測試 三、無法找出所有的設(shè)計錯誤 四、不能采用邏輯來證明程序的正確性,1.5.3增量測試，由小到大,測試資源關(guān)系圖,1.5.4避免測試自己的程序 避免程序員測試自己的代碼的主要原因： 1.程序員輕易不會承認(rèn)自己寫的程序有錯誤。 2.程序員的測試思路有局限性，在做測試時很容易受到編程思路的影響。 3.多數(shù)程序員沒有嚴(yán)格正規(guī)的職業(yè)訓(xùn)練，缺乏專業(yè)測試人員的意識。 4.程序員沒有養(yǎng)成錯誤跟蹤和回歸測試的習(xí)慣.,1.5.5設(shè)計周密的測試用例 軟件

24、測試的本質(zhì)就是針對要測試的內(nèi)容確定一組測試用例。測試用例至少應(yīng)該包括如下幾個基本信息： 1、在執(zhí)行測試用例之前，應(yīng)滿足的前提條件。 2、輸入（合理的、不合理的）。 3、預(yù)期輸出（包括后果和實際輸出）。,圖1-8顯示了一個典型的測試用例所應(yīng)該具有的基本信息。,測試用例是測試工作的核心，應(yīng)該盡量設(shè)計的周密細(xì)致，這樣才能更好的保證測試工作的質(zhì)量。,以一個實現(xiàn)登錄功能的小程序為例，它允許用戶選擇城市和地區(qū)，輸入自己的賬號和密碼。 通過Alt-F4組合鍵和“退出”按鈕來終止程序，Tab鍵在區(qū)域中間移動。,圖1-9 登錄窗口,根據(jù)組成頁面的具體元素，分別從幾個方面做了一些比較全面的測試用例：,1. 下拉框

25、和輸入框測試用例 表1-1 下拉框和輸入框測試用例,2、功能測試 （表1-2 功能測試用例）,3、各種錯誤數(shù)據(jù)的測試 表1-3 錯誤數(shù)據(jù)的測試用例,4、特殊測試 表1-4 特殊測試用例,1.5.6注意錯誤集中的現(xiàn)象 軟件缺陷的“扎堆”現(xiàn)象的常見形式： 1、對話框的某個控件功能不起作用，可能其他控件的功能也不起作用。 2、某個文本框不能正確顯示雙字節(jié)字符，則其他文本框也可能不支持雙字節(jié)字符。 3、聯(lián)機幫助某段文字的翻譯包含了很多錯誤，與其相鄰的上下段的文字可能也包含很多的語言質(zhì)量問題。 4、安裝文件某個對話框的“上一步”或“下一步”按鈕被截斷，則這兩個按鈕在其他對話框中也可能被截斷。,1.5.7

26、確認(rèn)BUG的有效性 有時候測試人員提交的BUG并不是真正的BUG。一般由A測試人員發(fā)現(xiàn)的BUG，一定要由另外一個B測試人員來進行確認(rèn)，如果發(fā)現(xiàn)嚴(yán)重的BUG可以召開評審會進行討論和分析。,1.5.7確認(rèn)BUG的有效性 有時候測試人員提交的BUG并不是真正的BUG。,無效BUG來源構(gòu)成圖,1.5.8合理安排測試計劃 合理的測試計劃有助于測試工作順利有序地進行，要求: 結(jié)合多種針對性強的測試方法、 列出所有可使用資源， 建立一個正確的測試目標(biāo)； 要本著嚴(yán)謹(jǐn)、準(zhǔn)確的原則，周到細(xì)致地做好測試前期的準(zhǔn)備工作，避免測試的隨意性。尤其是要盡量科學(xué)合理地安排測試時間。,1.5.9回歸測試,程序員修正BUG時，完

27、全有可能會引入一處或多處錯誤。當(dāng)需求變更時，對現(xiàn)有系統(tǒng)也會產(chǎn)生類似的波及效應(yīng)，導(dǎo)致錯誤產(chǎn)生，這是因為錯誤具有關(guān)聯(lián)現(xiàn)象。 因此，當(dāng)程序改動時，需要進行多次回歸測試以保證錯誤被正確關(guān)閉。,錯誤依賴關(guān)系,1.5.9回歸測試 錯誤具有關(guān)聯(lián)現(xiàn)象,（a）圖中的A、B 關(guān)系表達(dá)為：A錯誤依賴于B錯誤的關(guān)閉而關(guān)閉。（b）圖，A錯誤依賴于B錯誤和C錯誤的同時關(guān)閉而關(guān)閉。（c）圖是（a）和（b）的復(fù)合方式，因程序中的錯誤存在著一對多，多對多的復(fù)雜關(guān)系而變得難以處理，并且有些錯誤關(guān)聯(lián)和依賴關(guān)系處于隱性狀態(tài)。,1.5.10測試結(jié)果的統(tǒng)計和分析 得出的測試結(jié)果中存在大量的正確的以及錯誤的輸出信息，只有對這些輸出信息進行

28、深入地統(tǒng)計、分析和比較，才能夠正確的鑒別測試后輸出的數(shù)據(jù)，給出清晰的錯誤原因分析報告。當(dāng)輸出的信息很龐大時，我們可以借助專業(yè)的測試工具。,1.5.11及時更新測試 設(shè)計用例后未及時測試，會造成文檔過時現(xiàn)象。 有可能導(dǎo)致測試失敗的原因還有很多，可大致歸納為如下幾點： 1、測試團隊管理者失職； 2、測試團隊中溝通不好； 3、測試團隊和項目團隊溝通不良； 4、測試過程中，執(zhí)行角色無準(zhǔn)確定義； 5、測試團隊缺乏良好的培訓(xùn)。,1.6軟件測試工作流程 一般的軟件測試總體工作流程如圖1-12所示：,圖1-12 軟件測試工作總體流程圖,1、需求階段 需求階段是軟件測試活動的前提。需求階段測試工作流程如圖1-1

29、3所示：,圖1-13 需求階段測試活動流程圖,2、設(shè)計防止帶地線合刀閘 2、防止帶負(fù)荷拉合隔離開關(guān); 3、防止帶電掛接地線或接地刀閘; 4、防止帶接地線或合接地刀閘送電; 5、防止誤入帶電間隔,1.10.2系統(tǒng)運行環(huán)境 客戶端平臺：windows98/2000、windows NT workstation、Linux等所有具有支持JAVA的瀏覽器系統(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