軟件測試第1章

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

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

3、市場宣傳力度很大，前期銷售情況很好度很大，前期銷售情況很好 出現(xiàn)的問題：該游戲在一些出現(xiàn)的問題：該游戲在一些PCPC機上無法玩機上無法玩 原因：迪斯尼公司沒有對市場上已經(jīng)投入運行的原因：迪斯尼公司沒有對市場上已經(jīng)投入運行的PCPC機型機型進行調研，并且進行測試，導至該游戲只在程序員開發(fā)進行調研，并且進行測試，導至該游戲只在程序員開發(fā)游戲的系統(tǒng)上可以運行，但在大眾使用的常見系統(tǒng)中無游戲的系統(tǒng)上可以運行，但在大眾使用的常見系統(tǒng)中無法運行法運行 結果：迪斯尼公司不得不承擔客戶的投訴、產(chǎn)品退貨、結果：迪斯尼公司不得不承擔客戶的投訴、產(chǎn)品退貨、更換光盤、以及又一輪的調試、修改和測試的所有費用更換光盤、以

4、及又一輪的調試、修改和測試的所有費用。軟件錯誤的案例(2) Intel奔騰浮點除法軟件缺陷 時間：時間：19941994 背景：背景：IntelIntel發(fā)布的一款新處理器發(fā)布的一款新處理器 問題：在裝有這款處理器計算機的計算器中執(zhí)行算式問題：在裝有這款處理器計算機的計算器中執(zhí)行算式“(4195835/3145727)(4195835/3145727)3145727-41958353145727-4195835”不等于不等于0 0 原因：老式奔騰原因：老式奔騰CPUCPU的浮點除法軟件有缺陷的浮點除法軟件有缺陷 結果：結果：IntelIntel事實上在芯片發(fā)布之前，已經(jīng)發(fā)現(xiàn)了這個事實上在芯片發(fā)

5、布之前，已經(jīng)發(fā)現(xiàn)了這個缺陷，但認為不嚴重，沒有修正。被外界發(fā)現(xiàn)后，試缺陷，但認為不嚴重，沒有修正。被外界發(fā)現(xiàn)后，試圖掩飾。最終，迫于輿論壓力公開道歉，花費圖掩飾。最終，迫于輿論壓力公開道歉，花費4 4億美元億美元更換老芯片。更換老芯片。軟件錯誤的案例(3) 美國航天局火星極地登陸 時間：時間：19991999年年1212月月3 3日日 背景：火星極地登陸飛船在試圖登陸火星表面時背景：火星極地登陸飛船在試圖登陸火星表面時失蹤。失蹤。 問題：某一個數(shù)據(jù)位被意外復位問題：某一個數(shù)據(jù)位被意外復位. . 原因：測試過程分兩組：一組是測試飛船腳的落原因：測試過程分兩組：一組是測試飛船腳的落地打開過程；另一

6、組是測試飛船打開后的著陸過地打開過程；另一組是測試飛船打開后的著陸過程；前一組沒有注意數(shù)據(jù)位是否被置位，因為這程；前一組沒有注意數(shù)據(jù)位是否被置位，因為這不是他們負責的范圍。而后一個組在每次測試之不是他們負責的范圍。而后一個組在每次測試之前又重置計算機，清除所有的數(shù)據(jù)位。雙方獨立前又重置計算機，清除所有的數(shù)據(jù)位。雙方獨立工作都很正常，但兩個組沒有進行集成測試。工作都很正常，但兩個組沒有進行集成測試。 結果：飛船墜毀結果：飛船墜毀軟件錯誤的案例(4) 千年蟲 時間：時間：2020世紀世紀9090年代年代 背景：隨著背景：隨著2121世紀的到來，很多的計算機系統(tǒng)都面臨世紀的到來，很多的計算機系統(tǒng)都面

7、臨著著“千年蟲千年蟲”的危害的危害 問題：這樣就導致問題：這樣就導致20002000年以后的年份的記錄出現(xiàn)問題，年以后的年份的記錄出現(xiàn)問題，如如0000年是指年是指19001900還是還是20002000？ 原因：原因：2020世紀世紀7070年代時，由于計算機存儲空間很小，年代時，由于計算機存儲空間很小，并且十分昂貴，所以在計算機中記錄時間采用了并且十分昂貴，所以在計算機中記錄時間采用了“偷偷懶懶”的方式，例如將的方式，例如將19731973縮減為縮減為7373 結果：世界各地為了更換和升級系統(tǒng)，花費了上百億結果：世界各地為了更換和升級系統(tǒng)，花費了上百億的美元的美元軟件錯誤的案例(5) 愛國

8、者導彈防御系統(tǒng)炸死自家人 背景：海灣戰(zhàn)爭時導彈防御系統(tǒng)背景：海灣戰(zhàn)爭時導彈防御系統(tǒng) 問題：軟件系統(tǒng)缺陷問題：軟件系統(tǒng)缺陷 原因：系統(tǒng)時間的累計錯誤，延時原因：系統(tǒng)時間的累計錯誤，延時1414個小時，造成跟個小時，造成跟蹤系統(tǒng)失去了準確度。蹤系統(tǒng)失去了準確度。 結果：愛國者導彈炸死結果：愛國者導彈炸死2828名美軍士兵。名美軍士兵。軟件測試工程師，需要具備哪些軟件測試工程師，需要具備哪些能力？能力？ 通用技能上：1.基本計算機知識（操作系統(tǒng)，數(shù)據(jù)庫，通訊協(xié)議原理，熟悉至少一門編程語言）2.基本軟件測試知識（各種測試理論，測試方法論，測試用例編寫，缺陷界定標準，軟件質量評估）3.簡單項目管理知識軟

9、件測試工程師，需要具備哪些軟件測試工程師，需要具備哪些能力？能力？ 性格上：有牛皮糖屬性的為佳，越“不要臉”越好測試工程師提交的BUG越多，意味著研發(fā)工程師工作質量越差，需要返工的工作量也越大，甚至會影響績效，所以測試工程師有時候很容易得罪研發(fā)部門。一個可以相對堅持原則（比如3級BUG以上一定要改），又能拉下臉和不愉快的研發(fā)工程師保持較好關系的測試工程師，會對項目質量起到很關鍵作用。軟件測試工程師，需要具備哪些軟件測試工程師，需要具備哪些能力？能力？ 你不是產(chǎn)品，但你知道產(chǎn)品是怎么工作的； 你不是運營，但你知道用戶關心什么； 你不是開發(fā)，但你知道開發(fā)同事怎么工作； 你不是設計，但你有你對交互邏

10、輯的理解； 你不是銷售和編輯，但你熟悉產(chǎn)品業(yè)務。第一章 概述 本章要點本章要點 l 軟件測試的發(fā)展歷史；l 軟件測試技術的分類方法；l 軟件測試原則；l 軟件測試的定義；l 軟件測試同軟件開發(fā)之間的關系；l 軟件測試與開發(fā)模型；l 軟件測試工作流程。 本章目標本章目標 u 了解軟件測試的發(fā)展歷程和行業(yè)現(xiàn)狀；u 掌握軟件測試技術的分類；u 理解軟件測試的目的和軟件測試原則，以及了解人們對軟件測試行業(yè)的錯誤認識；u 掌握軟件測試中的基本定義、基本知識;u 理解軟件開發(fā)與軟件測試的關系。 1.1軟件測試的發(fā)展歷程及現(xiàn)狀軟件測試的發(fā)展歷程及現(xiàn)狀 1.1.1軟件測試的發(fā)展歷程軟件測試的發(fā)展歷程 20世紀

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

12、距主要在測試意識，測試理論的研究，測試工具軟件的開發(fā)以及從業(yè)人員的數(shù)量等方面。1.1軟件測試的發(fā)展歷程及現(xiàn)狀軟件測試的發(fā)展歷程及現(xiàn)狀 近年來，隨著軟件外包行業(yè)的興起，國近年來，隨著軟件外包行業(yè)的興起，國內(nèi)軟件質量保證的意識也在加強。占整體內(nèi)軟件質量保證的意識也在加強。占整體外包業(yè)務外包業(yè)務85%85%的對日軟件外包中主要的工作的對日軟件外包中主要的工作就是軟件測試。就是軟件測試。 IBMIBM，百度，華為，惠普，盛大，百度，華為，惠普，盛大，聯(lián)想等大型聯(lián)想等大型ITIT企業(yè)均表示出對成熟軟件測企業(yè)均表示出對成熟軟件測試人員的期盼。試人員的期盼。 1.2 1.2 什么是軟件測試什么是軟件測試（s

13、oftware testingsoftware testing） 1.2.11.2.1軟件測試的定義軟件測試的定義 根據(jù)側重點的不同，主要有以下三種觀點： 1）“使用人工或自動手段運行或測定某個系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的需求或是弄清預期結果與實際結果之間的差別”，該定義明確地提出了軟件測試以檢驗是否滿足需求為目標。 2）“軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程”，明確提出了“尋找錯誤”是測試目的。 3）從軟件質量保證的角度看：是一種重要的軟件質量保證活動，其動機是通過一些經(jīng)濟、高效的方法，捕捉軟件中的錯誤，從而達到保證軟件內(nèi)在質量的目的。 最終目的是驗證軟件是否按著預期運行。

14、測試過程中的活動包括“分析”軟件（靜態(tài)測試）和“運行”軟件（動態(tài)測試）。 也有人認為軟件測試（software testing）就是在軟件投入運行前，對軟件需求分析、設計規(guī)格說明和編碼的最終復審，是軟件質量保證的關鍵步驟。 軟件測試有兩個基本職責：確認：保證開發(fā)過程中軟件符合產(chǎn)品說明書的過程驗證：保證最終產(chǎn)品滿足用戶要求的過程 經(jīng)常會確認了但沒有驗證，例如1990年哈勃天文望遠鏡事件。 注意：區(qū)分軟件測試和軟件調試。 1，調試分析和定位BUG，不能完全代替測試。 2，調試是為了使軟件正確運行，測試是找錯誤。 3，調試對象是源代碼，測試的對象是開發(fā)過程各個階段的所有產(chǎn)品。 1.2.21.2.2軟

15、件測試生命周期軟件測試生命周期 測試的生命周期（software testing life cycle）分為幾個階段（如圖1-1所示 ）。 前三個階段就是引入程序錯誤階段； 后三個階段就是清除程序錯誤的階段。 需求規(guī)格說明設計編碼測試缺陷分類缺陷分離缺陷排除修復錯誤錯誤錯誤錯誤錯誤錯誤錯誤錯誤3(失效)圖1-1 測試生命周期 1.2.3 1.2.3軟件開發(fā)與測試模型軟件開發(fā)與測試模型 下面我們將介紹幾種典型的軟件開發(fā)與測試模型。 一、軟件開發(fā)模型一、軟件開發(fā)模型1 1、大爆炸模型、大爆炸模型 一大堆能量（這里指開發(fā)軟件所需的人力和物力）放在一起，巨大的能量進行釋放，通常的結果可能是產(chǎn)生了優(yōu)秀的

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

17、模型 一、軟件開發(fā)模型一、軟件開發(fā)模型瀑布模型瀑布模型瀑布模型是將軟件生命周期的各項活動，規(guī)定為按照固定順序相連的若干個階段性工作，形如瀑布流水，最終得到軟件產(chǎn)品。 問題定義分析研究需求分析軟件設計編碼測試維護定義階段開發(fā)階段維護階段瀑布開發(fā)模型瀑布開發(fā)模型 1.2.3 1.2.3軟件開發(fā)與測試模型軟件開發(fā)與測試模型一、軟件開發(fā)模型一、軟件開發(fā)模型瀑布法瀑布法 優(yōu)點：易于理解；調研開發(fā)的階段性；強調早期計劃及需求調查；能夠確定何時能夠交付產(chǎn)品及何時進行評審與測試。 缺點：需求調查分析只進行一次，不能適應需求變化；順序的開發(fā)流程，使得開發(fā)中的經(jīng)驗教訓不能反饋到該項目的開發(fā)中去；不能反映出軟件開發(fā)

18、過程的反復與迭代性；沒有包含任何類型的風險評估；開發(fā)中出現(xiàn)的問題直到開發(fā)后期才能夠顯露，因此失去及早糾正的機會。邊寫邊改法 采用邊寫邊改法的軟件開發(fā)通常只是有了比較粗略的想法就開始進行簡單的設計、然后進行較長的反復編寫、測試與修復，是一個循環(huán)的過程。在認為無法更精細的描述軟件產(chǎn)品要求時，就發(fā)布產(chǎn)品。 優(yōu)點：能夠較為迅速的展現(xiàn)成果，適合需要快速制作而且用完就扔的小項目，如示范程序、演示程序等。缺點：其編碼和測試可能將是長期的循環(huán)往復的過程。 產(chǎn)品說明書代碼編制、測試、修復代碼編制、測試、修復 最終產(chǎn)品快速原型模型快速原型模型 快速原型模型的第一步是建造一個快速原型，實現(xiàn)客快速原型模型的第一步是建

19、造一個快速原型，實現(xiàn)客戶或未來的用戶與系統(tǒng)的交互，用戶或客戶對原型進行評戶或未來的用戶與系統(tǒng)的交互，用戶或客戶對原型進行評價，進一步細化待開發(fā)軟件的需求。價，進一步細化待開發(fā)軟件的需求。 通過逐步調整原型使通過逐步調整原型使其滿足客戶的要求，開發(fā)人員可以確定客戶的真正需求是其滿足客戶的要求，開發(fā)人員可以確定客戶的真正需求是什么；第二步則在第一步的基礎上開發(fā)客戶滿意的軟件產(chǎn)什么；第二步則在第一步的基礎上開發(fā)客戶滿意的軟件產(chǎn)品。品。 需求分析需求分析原型開發(fā)原型開發(fā)原型評價原型評價最終設計最終設計系統(tǒng)實現(xiàn)系統(tǒng)實現(xiàn)用戶反饋用戶反饋螺旋模式法螺旋模式法 螺旋模式是瀑布模式與邊寫邊改演化模式相結合，并加

20、入風險評估所建立的軟件開發(fā)模式。 每一個螺旋周期，為開發(fā)的一次迭代在每次迭代中，沒有固定定義的軟件活動，而是根據(jù)需要選擇。將開發(fā)活動與風險分析相結合，用于降低和控制風險。軟件開發(fā)與軟件測試的關系測試與開發(fā)各階段的關系測試與開發(fā)各階段的關系軟件測試與軟件開發(fā)過程的關系需求分析說明書詳細設計說明書源程序代碼單元測試集成測試系統(tǒng)測試概要設計說明書 1.2.3 1.2.3軟件開發(fā)與測試模型軟件開發(fā)與測試模型 一、軟件開發(fā)與測試一、軟件開發(fā)與測試V V模型模型 在傳統(tǒng)開發(fā)過程中測試不受重視，僅把它作為在需求分析、概要設計、詳細設計及編碼之后的一個階段。尤其在瀑布模型中。 V模型，描述了一些不同的測試級別

21、， 級別對應的生命周期中不同的階段， 這些測試階段和開發(fā)過程期間存在對應關系。 用戶需求獲取需求定義需求分析需求分析書概要設計概要設計書詳細設計詳細設計書編碼程序軟件產(chǎn)品可交付軟件系統(tǒng)測試已確認軟件確認測試已集成軟件集成測試已測試模塊單元測試需求分析評審評審評審評審評審評審評審評審 V模型示意圖 二、軟件開發(fā)與測試二、軟件開發(fā)與測試WW模型模型 開發(fā)的每一個環(huán)節(jié)都可能產(chǎn)生錯誤，如果堅持各個階段的技術評審,就能夠盡早發(fā)現(xiàn)和預防錯誤。 W 模型，形象地說明了軟件測試與開發(fā)的這種同步性。 W模型的優(yōu)點在于，每個軟件開發(fā)活動結束后就可以執(zhí)行相應的測試，如：在需求分析結束后，就可以進行需求分析測試。 需

22、求測試需求分析功能測試概要設計設計測試詳細設計單元測試編碼系統(tǒng)測試驗收確認測試確認集成測試集成圖1-3 W模型示意圖 三、軟件開發(fā)與測試三、軟件開發(fā)與測試HH模型模型 與前兩種模型相比，H模型充分地體現(xiàn)了測試過程。 1、 軟件測試不僅僅指測試的執(zhí)行, 還包括很多其他的活動。 2、軟件測試是一個獨立的流程, 貫穿產(chǎn)品的整個開發(fā)周期, 與其它流程并發(fā)進行。 3、軟件測試要盡早準備, 盡早執(zhí)行。 測試準備測試執(zhí)行測試流程其他流程測試就緒點圖1-4 H模型示意圖 4、軟件測試根據(jù)被測物的不同是分層次的. 不同層次的測試活動可以是按照某個次序先后進行的, 但也可能是反復的。 1.2.4 1.2.4與軟件

23、測試相關的術語與軟件測試相關的術語 1.錯誤（Error） 程序員在編寫代碼時會出錯，我們把這種錯誤稱之為bug。隨著開發(fā)過程的進行，錯誤會不斷的放大。 2.缺陷(Default) 缺陷是錯誤的結果，更精確的說是錯誤的表現(xiàn)。 包括過錯缺陷和遺漏缺陷。 過錯缺陷：信息輸入到了不正確的表現(xiàn)形式中 遺漏缺陷：沒有輸入信息 3.失效（Failure） 在缺陷運行時，常常會發(fā)生失效的情況。一種是過錯缺陷對應的失效；一種是遺漏缺陷對應的失效。 4.測試（Test） 測試是一項采用測試用例執(zhí)行軟件的活動，在這項活動中某個系統(tǒng)或組成的部分將在特定的條件下運行，然后要觀察并記錄結果，以便對系統(tǒng)或組成部分進行評價

24、。 5.測試用例(Test Case) 測試用例是為特定的目的而設計的一組測試輸入、執(zhí)行條件和預期的結果。 6.回歸測試（Regression testing） 回歸測試的目的是為了測試由于修正缺陷而更新的應用程序，以確保徹底修正了上一個版本的缺陷，并且沒有引入新的軟件缺陷。 回歸測試可分為：回歸測試可分為： 完全回歸測試完全回歸測試 嚴重性高嚴重性高 部分回歸測試部分回歸測試 時間緊張，測試內(nèi)容過多時間緊張，測試內(nèi)容過多 1.31.3軟件測試技術分類軟件測試技術分類 從不同的角度，可以把軟件測試技術分成不同種類， 一 、從是否需要執(zhí)行被測軟件的角度，可分為靜態(tài)測試和動態(tài)測試。 比如檢查二手車

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

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

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

28、 1.51.5軟件測試的原則軟件測試的原則 1.5.1 1.5.1盡早地和不斷地進行軟件測試盡早地和不斷地進行軟件測試 缺陷存在放大趨勢。需求階段缺陷概要設計階段缺陷詳細設計階段缺陷代碼階段缺陷放大n1倍放大n2倍放大n3倍圖1-5 缺陷放大模型 問題發(fā)現(xiàn)越早，解決問題的代價就越小，這是軟件開發(fā)過程中的黃金法則。 1.5.21.5.2不可能完全的測試不可能完全的測試 對一個程序進行完全測試就是意味著在測試結束之后，再也不會發(fā)現(xiàn)其它的軟件錯誤了。這是不可能的。主要原因有以下幾點： 一、不可能測試程序對所有可能輸入的響應。 1，對所有有效輸入 2，對所有無效輸入 3，對所有編輯過的輸入（如Back

29、space反復編輯） 4，對所有輸入時機的變化 （輸入的隨機中斷） 無法進行完全測試的例子程序PXYZ若X、Y為所有可能的整數(shù) 在字長32位機上測試X1、Y1 Z1 Xn、Yn Znn = 232232 = 264 1.84 1019 1.5.21.5.2不可能完全的測試不可能完全的測試 二、不可能測試到程序每一條可能的執(zhí)行路徑 M1D1D2D3D4M2M3M4M5M6M7D5=20次循環(huán)次數(shù)01220獨立路徑數(shù)51+52+53+5211014(1百萬億)每個測試用例（考慮、執(zhí)行、驗證結果）5分鐘共需測試時間10億年 1.5.21.5.2不可能完全的測試不可能完全的測試 三、無法找出所有的設計

30、錯誤 四、不能采用邏輯來證明程序的正確性 1.5.3 1.5.3增量測試，由小到大增量測試，由小到大 測 試 時 間測 試 范 圍可 用 資 源系 統(tǒng) 測 試集 成 測 試單 元 測 試單 元 測 試測試資源關系圖 1.5.4 1.5.4避免測試自己的程序避免測試自己的程序 避免程序員測試自己的代碼的主要原因： 1.程序員輕易不會承認自己寫的程序有錯誤。 2.程序員的測試思路有局限性，在做測試時很容易受到編程思路的影響。 3.多數(shù)程序員沒有嚴格正規(guī)的職業(yè)訓練，缺乏專業(yè)測試人員的意識。 4.程序員沒有養(yǎng)成錯誤跟蹤和回歸測試的習慣. 1.5.5 1.5.5設計周密的測試用例設計周密的測試用例 軟件

31、測試的本質就是針對要測試的內(nèi)容確定一組測試用例。測試用例至少應該包括如下幾個基本信息： 1、在執(zhí)行測試用例之前，應滿足的前提條件。 2、輸入（合理的、不合理的）。 3、預期輸出（包括后果和實際輸出）。 圖1-8顯示了一個典型的測試用例所應該具有的基本信息。測試用例ID：目的：前提：輸入：預期輸出：后果：執(zhí)行歷史：日期： 結果： 版本： 執(zhí)行人：測試用例是測試工作的核心，應該盡量設計的周密細致，這樣才能更好的保證測試工作的質量。 以一個實現(xiàn)登錄功能的小程序為例，它允許用戶選擇城市和地區(qū)，輸入自己的賬號和密碼。 通過Alt-F4組合鍵和“退出”按鈕來終止程序，Tab鍵在區(qū)域中間移動。 操操 作作

32、員員 登登 錄錄 選 擇 城 市 選 擇 地 區(qū) 城 市地 區(qū)操 作 員密 碼提 交退 出圖1-9 登錄窗口根據(jù)組成頁面的具體元素，分別從幾個方面做了一些比較全面的測試用例：操作員登錄操作員登錄選擇城市選擇地區(qū)城市地區(qū)操作員密碼提交退出1. 下拉框和輸入框測試用例 表1-1 下拉框和輸入框測試用例測試內(nèi)容測試內(nèi)容輸入操作輸入操作預期輸出預期輸出實際結果實際結果下拉框下拉框未和后臺數(shù)據(jù)庫綁定未和后臺數(shù)據(jù)庫綁定（顯示列表元素固定）（顯示列表元素固定）不允許列表中出不允許列表中出現(xiàn)現(xiàn)NULLNULL現(xiàn)象，現(xiàn)象，固定固定“請選擇請選擇-”-”已和后臺數(shù)據(jù)庫綁定已和后臺數(shù)據(jù)庫綁定（顯示列表元素活動）（顯

33、示列表元素活動）不允許列表中出不允許列表中出現(xiàn)現(xiàn)NULLNULL現(xiàn)象，現(xiàn)象，固定固定“請選擇請選擇-”-”輸輸入入框框限定字符型限定字符型輸入輸入1212、6 6無無# #，* *等等錯誤提示錯誤提示限定型數(shù)字限定型數(shù)字輸入輸入測試數(shù)據(jù)測試數(shù)據(jù)無無1212月、月、7 7* *、0 0錯誤提示錯誤提示2、功能測試 （表1-2 功能測試用例）用 例應產(chǎn)生行為結果失敗原因1.基本功能測試1.1在輸入框內(nèi)輸入資料并且執(zhí)行存儲程序必須能夠接受使用者的輸入并且將輸入值存在登錄文件內(nèi)1.2在輸入框內(nèi)不輸入資料但執(zhí)行儲存程序必須能夠檢查使用者輸入是否為空白，同時必須能夠告知使用者原因1.3檢查city字段儲存

34、結果City字段輸入 后存入cookies1.4檢查area字段儲存結果Area字段輸入 后存入cookies儲存結果1.5檢查ID 字段儲存結果ID字段輸入 后存入cookies2.使用接口功能測試2.1檢查輸入字段的輸入值必須組織使用者輸入空白，同時部分字段只能輸入數(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)容輸入操作輸入操作預選測預選測試數(shù)據(jù)試數(shù)據(jù)預期輸出預期輸出

35、實際結果實際結果點擊登錄點擊登錄按鈕按鈕不完整的數(shù)據(jù)不完整的數(shù)據(jù) CityCity，areaarea，I ID D，pswdpswd略略提示錯誤對話提示錯誤對話框框不正確的數(shù)據(jù)不正確的數(shù)據(jù) CityCity，areaarea，I ID D，pswdpswd略略提示錯誤對話提示錯誤對話框框回車操作回車操作不完整的數(shù)據(jù)不完整的數(shù)據(jù) CityCity，areaarea，I ID D，pswdpswd略略提示錯誤對話提示錯誤對話框框點擊點擊“退退出出”按鈕按鈕無無無無無無關閉當前應用關閉當前應用系統(tǒng)系統(tǒng)4、特殊測試 表1-4 特殊測試用例測試內(nèi)容測試內(nèi)容輸入操作輸入操作預選測試數(shù)預選測試數(shù)據(jù)據(jù)預期輸出

36、預期輸出操作焦點逃操作焦點逃逸逸連續(xù)連續(xù)TabTab切換，察看異常切換，察看異常無無焦點可準確回歸焦點可準確回歸當前操作窗口當前操作窗口分配內(nèi)存不分配內(nèi)存不足足啟動多個應用程序或模擬啟動多個應用程序或模擬多個程序運行多個程序運行無無是否可以正常運是否可以正常運行行網(wǎng)絡斷線網(wǎng)絡斷線切斷網(wǎng)絡連接切斷網(wǎng)絡連接無無是否可正常拋出是否可正常拋出異常異常 1.5.6 1.5.6注意錯誤集中的現(xiàn)象注意錯誤集中的現(xiàn)象 軟件缺陷的“扎堆”現(xiàn)象的常見形式： 1、對話框的某個控件功能不起作用，可能其他控件的功能也不起作用。 2、某個文本框不能正確顯示雙字節(jié)字符，則其他文本框也可能不支持雙字節(jié)字符。 3、聯(lián)機幫助某段

37、文字的翻譯包含了很多錯誤，與其相鄰的上下段的文字可能也包含很多的語言質量問題。 4、安裝文件某個對話框的“上一步”或“下一步”按鈕被截斷，則這兩個按鈕在其他對話框中也可能被截斷。 1.5.7 1.5.7確認確認BUGBUG的有效性的有效性 有時候測試人員提交的BUG并不是真正的BUG。一般由A測試人員發(fā)現(xiàn)的BUG，一定要由另外一個B測試人員來進行確認，如果發(fā)現(xiàn)嚴重的BUG可以召開評審會進行討論和分析。 1.5.7 1.5.7確認確認BUGBUG的有效性的有效性 有時候測試人員提交的BUG并不是真正的BUG。無效BUG來源構成圖 1.5.8 1.5.8合理安排測試計劃合理安排測試計劃 合理的測試

38、計劃有助于測試工作順利有序地進行，要求: 結合多種針對性強的測試方法、 列出所有可使用資源， 建立一個正確的測試目標； 要本著嚴謹、準確的原則，周到細致地做好測試前期的準備工作，避免測試的隨意性。尤其是要盡量科學合理地安排測試時間。 1.5.91.5.9回歸測試回歸測試 程序員修正BUG時，完全有可能會引入一處或多處錯誤。當需求變更時，對現(xiàn)有系統(tǒng)也會產(chǎn)生類似的波及效應，導致錯誤產(chǎn)生，這是因為錯誤具有關聯(lián)現(xiàn)象。 因此，當程序改動時，需要進行多次回歸測試以保證錯誤被正確關閉。 ABABCABCDEF基本結構（a）（b）（c）單純依賴多重依賴復合依賴錯誤依賴關系1.5.91.5.9回歸測試回歸測試錯

39、誤具有關聯(lián)現(xiàn)象（a）圖中的A、B 關系表達為：A錯誤依賴于B錯誤的關閉而關閉。（b）圖，A錯誤依賴于B錯誤和C錯誤的同時關閉而關閉。（c）圖是（a）和（b）的復合方式，因程序中的錯誤存在著一對多，多對多的復雜關系而變得難以處理，并且有些錯誤關聯(lián)和依賴關系處于隱性狀態(tài)。 1.5.10 1.5.10測試結果的統(tǒng)計和分析測試結果的統(tǒng)計和分析 得出的測試結果中存在大量的正確的以及錯誤的輸出信息，只有對這些輸出信息進行深入地統(tǒng)計、分析和比較，才能夠正確的鑒別測試后輸出的數(shù)據(jù)，給出清晰的錯誤原因分析報告。當輸出的信息很龐大時，我們可以借助專業(yè)的測試工具。 1.5.11 1.5.11及時更新測試及時更新測試

40、 設計用例后未及時測試，會造成文檔過時現(xiàn)象。 有可能導致測試失敗的原因還有很多，可大致歸納為如下幾點： 1、測試團隊管理者失職； 2、測試團隊中溝通不好； 3、測試團隊和項目團隊溝通不良； 4、測試過程中，執(zhí)行角色無準確定義； 5、測試團隊缺乏良好的培訓。 1.6 1.6軟件測試工作流程軟件測試工作流程 一般的軟件測試總體工作流程如圖1-12所示： 立項階段需求階段設計階段編碼單元測試階段集成測試階段系統(tǒng)測試階段驗收測試階段結項總結階段圖1-12 軟件測試工作總體流程圖 1、需求階段 需求階段是軟件測試活動的前提。需求階段測試工作流程如圖1-13所示： 需 求 工 作 培 訓編 寫 需 求業(yè)

41、務 、 用 戶 、 功 能需 求 評 審需 求 規(guī) 格 說 明 書需 求 變 更需 求 變 更 記 錄需 求 報 警總 體 測 試 計 劃系 統(tǒng) 測 試 方 案需 求 報 警 信 號需 求 跟 蹤 矩 陣進 入 下 一 階 段需需求求階階段段測測試試工工作作流流程程圖1-13 需求階段測試活動流程圖2、設計&編碼階段測試工作流程 圖1-14 設計&編碼階段測試流程圖上一階段需求相關文擋概要設計評審詳細設計單元測試方案編碼單元測試測試抽檢單元測試總結報告進入下一階段集成測試方案自動測試方案抽象出驗證標準設設計計& &編編碼碼階階段段測測試試工工作作流流程程以模塊為

42、單位，不斷循環(huán) 這一環(huán)節(jié)以模塊為單位循環(huán)：單元測試方案制定編碼單元測試是否通過測試抽檢是否通過，重新編寫沒有通過單元測試和測試抽檢的代碼。最終形成一份單元測試總結報告。 3、集成測試、系統(tǒng)測試和驗收測試階段 該測試階段流程如圖1-15所示： 上一階段集成測試方案集成測試系統(tǒng)測試申請測試部評估自動測試方案系統(tǒng)測試方案系統(tǒng)測試系統(tǒng)測試綜合報告驗收測試質量合格證書產(chǎn)品化工作產(chǎn)品工作報告測試工作總結集集成成、系系統(tǒng)統(tǒng)、驗驗收收測測試試階階段段圖1-15 集成測試、系統(tǒng)測試和驗收測試階段流程圖 1.7 1.7軟件測試中的誤區(qū)軟件測試中的誤區(qū) 誤區(qū)1 調試和測試是一樣的 1,軟件測試是找出軟件已經(jīng)存在的錯

43、誤,而調試是定位錯誤,修改程序以修正錯誤. 2,軟件測試從一個已知的條件開始,有預知的結局 而調試從未知的條件開始,其結局不可預知 3,軟件測試可以計劃,可以預先制定測試用例和過程,工作進度可以度量.而調試不能計劃,進度不可度量. 4,測試的對像可以是文檔和代碼 而調試的對像只能是代碼 . 1.7 1.7軟件測試中的誤區(qū)軟件測試中的誤區(qū) 誤區(qū)2 軟件測試在軟件開發(fā)過程中并不重要 誤區(qū)3 在軟件開發(fā)結束之后進行測試 誤區(qū)4 過分依賴Beta測試 誤區(qū)5 過分依賴自動化測試 誤區(qū)6 測試是可窮盡的 誤區(qū)7 測試是證明軟件的正確性 誤區(qū)8 可以忽略測試的設計 1.8 軟件測試過程1.8.1 制定測試

44、計劃1.8.2 測試執(zhí)行過程1.8.1 制定測試計劃1 1、制定計劃、制定計劃本階段的主要工作內(nèi)容 對需求規(guī)格說明書的仔細研究 將要測試的產(chǎn)品分解成可獨立測試的單元 為每個測試單元確定采用的測試技術 為測試的下一個階段及其活動制定計劃制定計劃包括： （1）概要測試計劃 （2）詳細測試計劃1.8.2 測試執(zhí)行過程 1 1、測試執(zhí)行過程的三個階段、測試執(zhí)行過程的三個階段（1）初測期 測試主要功能和關鍵的執(zhí)行路徑，排除主要障礙。（2）細測期 依據(jù)測試計劃和測試大綱、測試用例，逐一測試大大小小的功能、方方面面的特性、性能、用戶界面、兼容性、可用性等等；預期可發(fā)現(xiàn)大量不同性質、不同嚴重程度的錯誤和問題。

45、（3）回歸測試期 系統(tǒng)已達到穩(wěn)定，在一輪測試中發(fā)現(xiàn)的錯誤已十分有限；復查已知錯誤的糾正情況，確認未引發(fā)任何新的錯誤時，終結回歸測試。測試執(zhí)行過程（續(xù)）初測期初測期功能凍結功能凍結代碼凍結代碼凍結回歸測試期回歸測試期細測期細測期0 020204040606080801001001201201401401601601 12 23 34 45 56 67 78 89 9 1010 1111 1212 1313 1414 1515 1616 1717 1818 1919出錯數(shù)出錯數(shù)時間時間三個測試期階段圖示2 2、集成測試過程中的兩個重要里程碑、集成測試過程中的兩個重要里程碑 在集成測試過程中的兩個重

46、要的里程碑是功能凍結和代碼凍結的確定。這兩個里程碑界定出回歸測試期的起止界限。 功能凍結(Function/Feature Freeze) 經(jīng)過測試，符合設計要求，確認系統(tǒng)功能和其他特性均不再做任何改變。 代碼凍結(Code Freeze) 理論上，在無錯誤時凍結程序代碼，但實際上，代碼凍結只標志系統(tǒng)的當前版本的質量已達到預期的要求，凍結程序的源代碼，不再對其做任何修改。這個里程碑是設置在軟件通過最終回歸測試之后。測試執(zhí)行過程（續(xù)）1.9 軟件質量保證1.9.1 軟件錯誤與質量保證1.9.2 軟件質量管理1.9.3 軟件能力成熟度模型1.9.4 ISO9000標準簡介1.9.1 軟件錯誤與質量

47、保證1.9.1.1 程序正確性情況1.9.1.2 軟件錯誤類型1.9.1.3 程序中隱藏錯誤的估計1.9.1.1 程序正確性情況 程序編寫無語法錯誤。 這是程序運行的最起碼條件，否則無法通過編譯程序的檢查 程序執(zhí)行中未發(fā)現(xiàn)明顯的運行錯誤。 這是指程序運行時，沒有因為產(chǎn)生過大或過小的數(shù)據(jù)、由于溢出而無法執(zhí)行；也沒有遇到死循環(huán)等情況 程序中無不適當語句。 程序盡管符合語法規(guī)則，也未出現(xiàn)運行錯誤，但有些語句不適當。例如，有的變量經(jīng)過說明，但未曾引用。或有的變量未置初始值而被有引用，有的變量經(jīng)過多次賦值，但未引用等程序正確性情況(續(xù))程序運行時能通過典型的有效測試數(shù)據(jù)，得到正確的預期結果。 這說明程序

48、能夠接受規(guī)格說明所規(guī)定的正常條件下的合理數(shù)據(jù)，并給出正確結果程序運行時能通過典型的無效測試數(shù)據(jù)，得到正確的結果。 程序能夠接受規(guī)格說明中多規(guī)定的異常條件下的不合理數(shù)據(jù)，并給出正確結果程序運行時能通過任何可能給出的數(shù)據(jù)，給出正確的結果。1.9.1.2 軟件錯誤類型和嚴重程度 根據(jù)錯誤的性質，我們可以將軟件錯誤分為以下幾種類型：軟件需求錯誤軟件需求制定的不合理或不正確，需求不完全，其中含有邏輯錯誤，需求分析的文檔有誤等。功能和性能錯誤功能或性能規(guī)定的有錯誤，或是遺漏了某些功能，或是規(guī)定了某些冗余的功能；為用戶提供的信息有錯，或者信息不正確；對意外的異常情況處理有誤等。軟件錯誤類型和嚴重程度(續(xù))軟

49、件結構錯誤程序控制流或控制順序有誤；處理過程有誤等。數(shù)據(jù)錯誤數(shù)據(jù)定義或數(shù)據(jù)結構有誤；數(shù)據(jù)存取或數(shù)據(jù)操作有誤等。例如動態(tài)數(shù)據(jù)與靜態(tài)數(shù)據(jù)混淆，參數(shù)與控制數(shù)據(jù)混淆等。軟件實現(xiàn)和編碼錯誤編碼錯，或按鍵錯；違背編碼風格要求或是編碼標準的問題。包括語法錯、數(shù)據(jù)名錯、局部變量與全局變量混淆，或是程序邏輯有誤等。軟件錯誤類型和嚴重程度(續(xù))軟件集成錯誤軟件的內(nèi)部接口、外部接口有誤；軟件各相關部分在時間配合，數(shù)據(jù)吞吐量等方面不協(xié)調軟件系統(tǒng)結構錯誤操作系統(tǒng)調用錯或使用錯、恢復錯誤、診斷錯誤、分割及覆蓋錯誤，以及引用環(huán)境的錯誤等。測試定義與測試執(zhí)行錯誤測試的錯誤往往被人們所忽略，它可能包括測試方設計與測試實施的錯誤

50、、測試文檔的問題、測試用例不夠充分等。軟件錯誤類型和嚴重程度(續(xù))錯誤分類錯誤數(shù)百分比需求錯誤13178.1%功能和性能錯誤262416.2%結構錯誤408225.2%數(shù)據(jù)錯誤363822.4%實現(xiàn)與編碼錯誤16019.9%軟件集成錯誤14559.0%系統(tǒng)結構錯誤2821.7%測試定義與測試執(zhí)行錯誤4472.8%其他類型錯誤7634.7%軟件錯誤分類統(tǒng)計軟件錯誤分類統(tǒng)計軟件錯誤類型和嚴重程度(續(xù)) 按錯誤發(fā)生的影響和后果，錯誤的嚴重程度可以分為如下幾類：較小錯誤：這類錯誤只是對系統(tǒng)的輸出結果有一些非實質性的影響，如輸出的數(shù)據(jù)格式不符合要求中等錯誤：對系統(tǒng)的運行有局部影響。如輸出的某一部分數(shù)據(jù)有

51、錯誤或出現(xiàn)冗余較嚴重錯誤：系統(tǒng)的行為由于錯誤的干擾而出現(xiàn)明顯不合情理的現(xiàn)象。如開出0.00元的支票。系統(tǒng)的輸出結果完全不可信賴。嚴重錯誤：系統(tǒng)運行不可跟蹤，一時不能掌握其規(guī)律，時好時壞。非常嚴重的錯誤：系統(tǒng)運行中突然停機，其原因不明，且無法軟啟動。最嚴重錯誤：運行被測的軟件導致環(huán)境遭到破壞，或者造成事故，引起生命、財產(chǎn)的損失。1.9.1.3 程序中隱藏錯誤-數(shù)量的估計 Seeding Model假設魚塘中只有一個品種的魚，目標是估計它的數(shù)目N方法：向魚塘中釋放Nt條帶標記的魚，使其與其他未作標記的魚充分混合。幾天后，再從池塘中取一些樣本，并根據(jù)標記進行區(qū)別，得到帶標記的魚nt條，沒有標記的n條

52、。如果這一取樣是隨機進行的，那么可以得到如下的關系ttttnnnNNNttNnnN 程序中隱藏錯誤數(shù)量的估計(續(xù)) Hyman的改進的方法（Hyman分別測試法） 兩個（或多個）程序員一開始針對同一個程序分別獨立的進行排錯工作。假設這個工作大約需要4個月完成。在開始的幾周內(nèi)，由一位分析員來評價他們的工作，可以利用公式來估算錯誤的數(shù)量，這樣的估算每隔幾周就進行一次，直到得到滿意的N為止。在過一個月或兩個月后，讓第二個人去做其他的工作，將工作移交給第一個人。這樣在該承襲的排錯工作完成1/4或1/2之后，就可以得到該程序錯誤數(shù)的合理估計值。程序中隱藏錯誤數(shù)量的估計(續(xù)) 由兩個測試員同時互相獨立地測

53、試同一程序的兩個副本，用t表示測試時間（月），記t = 0時，程序中原有故障總數(shù)是B0；t = t1時，測試員甲發(fā)現(xiàn)的故障總數(shù)是B1；測試員乙發(fā)現(xiàn)的故障總數(shù)是B2；其中兩人發(fā)現(xiàn)的相同故障數(shù)目是bc；兩人發(fā)現(xiàn)的不同故障數(shù)目是bi。 在大程序測試時，頭幾個月所發(fā)現(xiàn)的錯誤在總的錯誤中具有代表性，兩個測試員測試的結果應當比較接近，bi不是很大。這時有 程序中隱藏錯誤數(shù)量的估計(續(xù)) 如果bi比較顯著，應當每隔一段時間，由兩個測試員再進行分別測試，分析測試結果，估算B0。如果bi減小，或幾次估算值的結果相差不多，則可用B0作為程序中原有錯誤總數(shù)的估值。 2 2個小組獨立地測試同一個程序，第一組發(fā)現(xiàn)個小組

54、獨立地測試同一個程序，第一組發(fā)現(xiàn)2525個錯誤個錯誤，第二組發(fā)現(xiàn)了，第二組發(fā)現(xiàn)了3030個錯誤，在個錯誤，在2 2個小組發(fā)現(xiàn)的錯誤中有個小組發(fā)現(xiàn)的錯誤中有1515個是共同的，那么可以估計程序中的錯誤總數(shù)是多個是共同的，那么可以估計程序中的錯誤總數(shù)是多少個？少個？程序中隱藏錯誤數(shù)量的估計(續(xù)) 如果bi比較顯著，應當每隔一段時間，由兩個測試員再進行分別測試，分析測試結果，估算B0。如果bi減小，或幾次估算值的結果相差不多，則可用B0作為程序中原有錯誤總數(shù)的估值。 2 2個小組獨立地測試同一個程序，第一組發(fā)現(xiàn)個小組獨立地測試同一個程序，第一組發(fā)現(xiàn)2525個錯誤個錯誤，第二組發(fā)現(xiàn)了，第二組發(fā)現(xiàn)了30

55、30個錯誤，在個錯誤，在2 2個小組發(fā)現(xiàn)的錯誤中有個小組發(fā)現(xiàn)的錯誤中有1515個是共同的，那么可以估計程序中的錯誤總數(shù)是多個是共同的，那么可以估計程序中的錯誤總數(shù)是多少個？少個？答案：答案：2525* *30/15=5030/15=50 1.101.10一個貫穿全文的例子一個貫穿全文的例子 電廠兩票管理系統(tǒng)電廠兩票管理系統(tǒng)1.10.11.10.1系統(tǒng)簡介系統(tǒng)簡介 操作票、工作票（簡稱兩票）是“電業(yè)(電廠)安全工作規(guī)程”中的核心內(nèi)容之一，對保證電業(yè)安全生產(chǎn)具有重要的作用。操作票是保證正確電氣倒閘（熱機）操作的重要環(huán)節(jié)和前提條件，使用操作票的目的是為了保障人身與設備的安全，確保電氣設備倒閘操作的正

56、確性，防止電氣誤操作事故發(fā)生。 工作票是保證電氣(電廠設備)檢修工作安全的重要措施，是檢修人員在運行設備上或運行區(qū)域內(nèi)進行檢修和試驗工作，以及做可能影響設備的正常運行或備用狀態(tài)的其它工作的重要書面依據(jù)?！皟善薄钡霓k理過程基本上都是開票、各部門負責人或三種人審批簽字、工作結束、部門或廠部檢查審核這樣的一種線性辦理過程。 電力部門分為水電、火電、供電三種類型，各廠、局要處理的兩票類型通常有： 水電廠：電氣一種工作票、電氣二種工作票、水力機械工作票、一級動火工作票、二級動火工作票、電氣倒閘操作票、繼保安措票、腳手架工作單、水力機械操作票、溢洪閘門操作票 火電廠：電氣一種工作票、電氣二種工作票、水力機械工作票、一級動火工作票、二級動火工作票、電氣倒閘操作票、繼保安措票、腳手架工作單、熱力工作票 供電局：電氣一種工作票、電氣二種工作票、水力機械工作票、一級動火工作票、二級動火工作票、電氣倒閘操作票、繼保安措票、腳手架工作單、 一種工作票、線路二種工作票。 為了使讀者更好的了解兩票系統(tǒng)以及后面各章節(jié)的內(nèi)容，在這里對一些電力系統(tǒng)專業(yè)術語作如下解釋： 一次圖：電氣主接線是由高壓電器通過連接線，按其功能要求組成接受和分配電能的電路，成為傳輸強