軟件測試基礎

倪鵬:

手機:82821000

辦公室:85118251

郵箱:nipeng@課程安排星期一二三四五1-23-4軟件測試倪鵬20818

軟件測試倪鵬20818

5-67-8軟件測試倪鵬20818課程簡介前導課程：軟件工程后續課程：軟件測試技術考試形式：閉卷學時：48學時軟件測試基礎第一章軟件測試概述本章學習內容軟件測試背景軟件測試定義、目標和原則軟件測試與質量保證傳統軟件測試過程軟件測試的發展歷程及趨勢軟件測試是伴隨著軟件的產生而產生的，有了軟件的生成和運行就必然有軟件測試。例1：1963年,美國,飛往火星的火箭爆炸,損失$10million.

原因：

FORTRAN循環DO5I=1,3

誤寫為DO5I=1.3例2：1994-1995年,迪斯尼的獅子王,第一個面向兒童的多媒體光盤游戲，投訴電話被打爆.

原因：未對市場上的各種PC機型進行正確測試，軟件在大眾使用的常見系統中難以運行例3：1991年,美國愛國者導彈防御系統在幾次對抗導彈戰役中失利，多哈戰誤擊斃28名美軍士兵.

原因：一個很小的系統時鐘錯誤積累，可能拖延14小時并造成跟蹤系統失去準確度，多哈戰中系統拖延了100多個小時早期的軟件開發過程中，測試的含義比較窄，將測試等同于“調試”目的是糾正軟件中已經知道的故障，常常由軟件開發人員自己完成這部分工作對測試的投入極少，測試介入的也晚，常常是等到形成代碼，產品已經基本完成時才進行測試直到1957年，軟件測試才開始與調試區別開來，成為一種發現軟件缺陷的活動。直到20世紀80年代早期，“質量”的號角才開始吹響。軟件測試的定義發生了改變，測試不單純是一個發現錯誤的過程，而且包含軟件質量評價的內容。

20世紀90年代，測試工具終于盛行起來。到了2002年，Rich和Stefan在《系統的軟件測試》一書中對軟件測試做了進一步定義：“測試是為了度量和提高被測軟件的質量，對測試軟件進行工程設計、實施和維護的整個生命周期過程”。近20年來，隨著計算機和軟件技術的飛速發展，軟件測試技術的研究也取得了很大的突破，測試專家總結了很好的測試模型，如著名的V模型，在單元測試、自動化測試等方面涌現了大量優秀的軟件測試工具。雖然軟件測試技術的發展很快，但是其發展速度仍落后于軟件開發技術的發展速度，使得軟件測試在今天面臨著很大的挑戰，主要體現在以下幾個方面。①軟件在國防現代化、社會信息化和國民經濟信息化領域中的作用越來越重要，由此產生的測試任務越來越繁重。②軟件規模越來越大，功能越來越復雜，如何進行充分而有效的測試成為難題。③面向對象的開發技術越來越普及，但是面向對象的測試技術卻剛剛起步。④對分布式系統的整體性能還不能進行很好的測試。⑤對實時系統缺乏有效的測試手段。⑥隨著安全問題的日益突出，對信息系統的安全性如何進行有效的測試與評估，成為世界性難題。根據國內外軟件測試的發展現狀，可以看到軟件測試有以下的發展趨勢。①測試工作將進一步前移。②軟件架構師、開發工程師、QA

（QUALITYASSURANCE

）質量保證人員、測試工程師將進行更好的融合。③測試職業將得到充分的尊重。④設置獨立的軟件測試部門將成為越來越多的軟件公司的共識。軟件測試部門將和開發部、質量保證部一樣作為一個重要的獨立部門存在。⑤測試外包服務將快速增長。和軟件開發外包一樣，軟件測試外包將成為全球化的一種趨勢。可以利用職業測試專家隊伍與機構為自己的產品進行測試，而且可以節省測試費用。軟件測試職業與素質對軟件測試的誤解

如果發布的軟件有質量問題，那是軟件測試人員的錯。

軟件測試技術要求不高，至少比編程容易多了。

軟件測試隨便找一個能力差的人就能做。

有時間就多測試一些，來不及就少測試一些。軟件測試是測試人員的事，與開發人員無關。

設計－實現－測試，軟件測試是開發后期的一個階段。

軟件測試職業和職位

軟件測試員

軟件測試工程師/程序分析員

高級軟件測試工程師/程序分析員

軟件測試組負責人軟件測試/編程負責人

軟件測試/質量保證/項目經理

軟件測試人員應具備下列基本素質：1．具有探索精神2．具有創造性3．堅持不懈的精神4．故障排除專家5．判斷準確6.追求完美7.溝通能力軟件測試員工作目標與必備素質軟件測試人才的現狀

1、軟件測試人員的合理比例

在軟件產業發達的國家：

軟件測試在人員配備和資金投入方面占據相當的比重。

微軟為打造Windows2000，1700多個開發人員，以及3200個測試人員，開發和測試人員之比約為三比五。

HP公司的測試人員和開發人員的比例為一比一，這是很多先進軟件企業通常的人員配比。

在國內：

企業往往忽視軟件測試，很多企業都沒有軟件測試部門，甚至不設置軟件測試的崗位，造成產品質量得不到保證。

測試人員大都不到開發人員的5%，隨著產業和企業的發展，企業必然需要大量的測試人員。

軟件測試人才需求快速增長，體現在：

（1）中國軟件產業正在快速增長，需要大量軟件相關人才；

（2）軟件企業的發展要求測試人才達到一個合適的比例。

近一兩年軟件企業開始認識到軟件測試對于提高軟件質量的重要性，開始重視軟件測試，但由于歷史的原因，找不到合適的軟件測試人員。三個招聘案

慧谷-博為峰軟件測試工作室曾經接受企業委托，招聘二十名軟件測試工程師，結果收到的簡歷不到十份，合格的只有三份，最后錄用的只有一人；而招聘一名程序員就會收到六十多份簡歷。

上海一位軟件企業的副總裁說，他們曾招聘8名基于Unix操作系統的測試工程師，但是半年多招不到合適的人。

微軟亞洲工程院院長張宏江博士最近告訴媒體：“過去兩三個月，我最主要的精力都花在雇人上。遺憾的是，1萬多名應聘者中，居然找不到足夠合適的人。”微軟最緊缺的人才包括軟件測試人員、軟件項目管理員、軟件架構師，1萬多名應聘者中最后合格的只有50多人。測試高手是怎樣煉成的大俠江湖閱歷武術招式內功心法高人指點必勝信念測試高手項目經驗測試技術基礎知識名師指點自信問題什么是軟件？計算機中與硬件相結合的一部分包括程序和文檔什么是Bug？Bug—小蟲子計算機中硬件或軟件的錯誤軟件中（包括程序和文檔）不符合用戶需求的問題判斷軟件問題是否是Bug的唯一標準世界上不存在沒有缺陷的軟件可以通過兩種途徑開發出沒有錯誤的軟件：在一開始就防止引入錯誤識別潛藏在代碼中的錯誤，找到并消滅它們事實由軟件設計故障和計算機硬件設計故障而引發的系統失效的比例大約是：10:1!!!運行軟件的駐留故障密度（每千行代碼的故障數）要求很高的財務或財產軟件為：每千行代碼1-10個故障關鍵的生命軟件為每千行代碼0.01-1個故障1.1軟件錯誤與缺陷軟件與生俱來就有可能存在著缺陷？如何防止和減少這些可能存在的問題？軟件測試！！軟件缺陷與定義軟件缺陷定義軟件未達到產品說明書中已經標明的功能軟件出現了產品說明書中指明不會出現的錯誤軟件未達到產品說明書中雖未指出但應當達到的目標軟件功能超出了產品說明書中指明的范圍軟件測試人員認為軟件難以理解、不易使用或最終用戶認為該軟件使用效果不好軟件缺陷的特征

“看不到”

——軟件的特殊性決定了缺陷不易看到

“看到但是抓不到”

——發現了缺陷，但不易找到問題發生的原因所在

軟件缺陷產生的原因軟件產品說明書（56％）設計方案（27％）編碼（7％）其他（10％）軟件缺陷修復的代價IBM的研究結果表明，缺陷存在放大趨勢由此可見，問題發現越早，解決問題的代價就越小，這是軟件開發過程中的黃金法則。圖測試工作量和軟件缺陷數量之間的關系軟件測試的定義1979年,Glenford

J.Myers:軟件測試是為了發現錯誤而運行程序的過程1983年，IEEE（國際電器電子工程師學會）測試是使用人工或自動的手段來運行或檢測某個系統的過程，其目的在于檢測它是否滿足約定的需求或是比較預期結果與實際結果之間的差別1.2什么是軟件測試軟件測試的特性挑剔性提高軟件質量，盡可能多的發現至今仍未發現的錯誤復雜性需要考慮全面不徹底性輸入量太大輸出結果太多軟件實現途徑太多軟件規格說明沒有客觀標準注：不能證明錯誤不存在經濟性軟件測試的目標和原則測試目標尋找錯誤，并且是最大可能的找出最多的錯誤。證明程序中有故障存在，并力求設計出最能暴露錯誤的測試方案測試不是為了顯示程序是好的，而是應該從軟件中包含有缺陷和故障這個假定出發去測試程序，從中發現盡可能多的軟件故障。在談到軟件測試時，許多人都引用GrenfordJ.Myers的觀點：①軟件測試是為了發現錯誤而執行程序的過程；

②測試是為了證明程序有錯，而不是證明程序無錯誤。

③一個好的測試用例是在于它能發現至今未發現的錯誤；

④一個成功的測試是發現了至今未發現的錯誤的測試。測試原則軟件測試的原則尚沒有標準的說法，大多是經驗之談，一般有下面幾條可作為測試的基本原則。（1）所有的測試都應追溯到用戶需求。（2）盡早的和及時的測試，應作為軟件開發人員的座右銘。（3）設計時應完成測試計劃，詳細的測試用例定義可在設計模型確定后開始，測試可在代碼產生之前進行計劃和設計。（4）測試用例應當由測試數據和與之對應的預期結果組成。（5）在程序提交測試后，應當由專門的測試人員進行測試，避免由程序設計者自行檢查程序。（6）測試用例應包括合理的輸入條件和不合理的輸入條件（7）嚴格執行測試計劃，排除測試的隨意性。（8）充分注意測試當中的群體和集中現象。（9）避免殺蟲劑現象（10）要對每一個測試結果做全面的檢查。（11）完全測試是不可能的，測試需要終止。（12）測試無法顯示潛伏的軟件缺陷（13）程序修改后要回歸測試（14）不是所有軟件缺陷都要修復（15）保存測試計劃、測試用例、出錯統計和最終分析報告，為維護工作提供充分的資料。測試結果分析改正錯誤可靠性分析軟件配置測試配置測試工具測試結果錯誤預期結果修正的軟件預測的可靠性回歸測試圖

測試信息流程測試信息流程測試停止的標準（1）測試時間超過了預定期限，則停止測試。（2）執行了所有的測試用例，但并沒有發現故障，則停止測試。（3）使用特定的測試用例設計方案，作為判斷測試停止的基礎。（4）正面指出了停止測試的具體要求，即停止測試的標準可定義為查出某一預定數目的故障。（5）根據單位時間內查出故障的數量決定是否停止測試。1.3軟件質量保證軟件質量的定義——1983年，IEEE軟件系統或軟件產品滿足規定和隱含的與需求能力有關的全部特征和特性。軟件產品質量滿足用戶要求的程度軟件各種屬性的組合程度用戶對軟件產品的綜合反映程度軟件在使用過程中滿足用戶要求程度①軟件需求是衡量軟件質量的基礎，不符合需求的軟件就不具備質量。設計的軟件應在功能、性能等方面都符合要求，并能可靠地運行。②軟件結構良好，易讀、易于理解，并易于修改、維護。③軟件系統具有友好的用戶界面，便于用戶使用。④軟件生存周期中各階段文檔齊全、規范，便于配置、管理。McCall等人對軟件的質量特性作了如下定義：正確性可靠性易用性效率易維護性可移植性完整性可測試性靈活性復用性互聯性質量管理的發展階段

（1）產品質量檢驗階段

（2）統計質量管理階段

（3）全面質量管理階段1900手工操作者專職檢驗員1920過程統計技術1931全面質量管理19602000以顧客為中心階段時間質量管理的發展階段從質量管理理論的發展歷史可以看出：

——質量管理從單純的對產品質量進行檢驗

發展到對產品形成過程進行控制

——控制方法從靜態發展到動態的、持續的

過程改進

——其核心思想已表現為對過程的策劃、控

制和過程能力的持續改進軟件能力成熟度模型

軟件能力成熟度模型(CMM,CapabilityMaturityModel)：是軟件行業標準模型，用來定義和評價軟件企業開發過程的成熟度，提供如何做才能夠提高軟件質量的指導。

CMM的基本原理：

CMM將軟件組織的過程能力成熟度分為5個級別，每一個級別定義一組過程能力目標，并描述要達到這些目標應該采取的各種實踐活動。CMM的主要作用：

提供了一個軟件過程改進的框架。根據CMM模型，軟件開發者（機構或組織）能夠大幅度的提高按計劃、高效率、低成本的提交有質量保證的軟件產品的能力。1、CMM的基本過程概念

過程：

為達到目的而執行的所有步驟的系列。軟件過程：

開發和維護軟件及其相關產品的一組活動、方法、實踐和改革。軟件過程結構：

對組織標準軟件過程的一種高級別描述，它描述組織標準軟件過程內部的過程元素之間的順序、接口、內部依賴等關系，以及與外部過程之間的接口和依賴關系。

軟件過程元素：

用于描述軟件過程的基本元素，每一個過程元素包含一組定義的、有限的、封閉的相關任務。軟件過程定義：

CMM中過程定義的基本概念是定義組織的標準軟件過程。初始級優化級已管理級已定義級可重復級成熟度風險CMM五個等級

2、CMM的5個分級標準

CMM的分級結構和其主要特征：

初始級：其特點是軟件過程無秩序，有時甚至是混亂的。

可重復級：已建立了基本的項目管理過程，可用于對成本、進度和功能特性進行跟蹤。

已定義級：用于管理的、工程的軟件過程均已實現文檔化、標準化，并形成了整個軟件組織的標準軟件過程。

管理級：軟件過程和產品質量有詳細的度量標準，軟件過程和產品質量得到了定量的認證和控制。

優化級：通過對來自過程、新概念和新技術等方面各種有用信息的定量分析，能夠不斷地、持續性地對過程進行改進。

除第一級外，CMM的每一級是按照完全相同的內部結構構成的。

成熟度等級為頂層，不同的成熟度等級反映了軟件組織的軟件過程能力和該組織可能實現預期的程度。

ISO9000標準簡介ISO9000標準

——是為制造行業制定的質量管理和質量評判的一系列標準

——定義了一套基本達標的做法，有助于企業能夠一致地交付符合客戶質量要求的產品（或服務）ISO9000標準的目標

——在于開發過程，而不是產品

——關心的是進行工作的組織方式，而不是工作成果.

ISO9000只決定過程的要求是什么，而不管如何達到。即：ISO9000指出要做什么，但不指出怎樣做。1、ISO9000標準的構成

ISO9000系列標準主要由下列標準構成：

ISO9000:2000《質量管理體系：基礎和術語》

ISO9000:2000《質量管理體系：要求》

ISO9000:2000《質量管理體系：業績改進指南》

2、ISO9000標準的要求（1）開發詳細的質量計劃和程序，控制配置管理、產品驗證、合法性檢查、不規范行為和修正措施。（2）準備和接受軟件開發計劃證書，包括項目定義、產品驗證、合法性檢查、不規范行為和修正措施。

（3）使用客戶容易理解、測試時容易進行合法性檢查的用語來表達說明書。（4）計劃、開發、編制軟件測試計劃。（5）開發檢測軟件是否滿足客戶要求的方法。（6）實施軟件合法性檢查和驗收測試。（7）維護測試結果的記錄。（8）控制調查研究和解決軟件缺陷的方式。（9）證明產品在發布前就緒。（10）開發控制產品發布過程的程序。

（11）明確指出和規定應該收集的質量信息。（12）應用統計技術的方法分析軟件開發過程。（13）應用統計技術的方法評估產品質量。3、ISO9000質量管理的八項原則（1）以客戶為關注的焦點（2）領導的作用（3）企業全員的參與（4）過程方法（5）管理的系統方法（6）持續的改進（7）基于事實的決策策略（8）與供方互利的關系軟件測試管理軟件測試作用軟件測試管理系統的組成建立軟件測試管理體系的步驟測試計劃單元測試集成測試確認測試系統測試驗收測試測試總結與報告1.4軟件測試過程軟件測試階段組成測試計劃測試設計測試開發測試執行測試評估待測程序單元測試確認測試驗收測試測試計劃項目啟動初期必須規劃計劃是“動態的”什么是單元測試檢查程序的最小單元模塊進行正確性檢驗的測試工作測試模塊在語法、格式和邏輯上的錯誤單元測試目的保證每個模塊單獨運行正確多采用白盒技術檢查模塊控制結構的某些特殊路徑期望覆蓋盡可能多的出錯點單元？人為規定的最小功能模塊單元測試主要任務對各模塊進行測試解決以下5個方面的測試問題模塊接口局部數據結構邊界條件獨立的路徑錯誤處理模塊接口測試模塊接受輸入的實際參數個數與模塊的形式參數個數是否一致。輸入的實際參數與模塊的形式參數的類型是否匹配。輸入的實際參數與模塊的形式參數所使用單位是否一致調用其他模塊時，所傳送的實際參數個數與被調用模塊的形式參數的個數是否相同。調用其他模塊時，所傳送的實際參數與被調用模塊的形式參數的類型是否匹配。調用其他模塊時，所傳送的實際參數與被調用模塊的形式參數的單位一致。調用內部函數時，參數的個數、屬性和次序是否正確在模塊有多個入口的情況下，是否有引用與當前入口無關的參數。是否會修改了只讀型參數。出現全局變量時，這些變量是否在所有引用它們的模塊中都有相同的定義。有沒有把某些約束當做參數來傳送返回局部數據結構測試內部數據能否保持完整性應注意幾類錯誤不正確或不一致的類型說明錯誤的初始化或默認值錯誤的變量名，如拼寫錯誤或縮寫錯誤下溢、上溢或者地址錯誤注意：全程數據對模塊的影響返回模塊邊界條件測試數據邊界處模塊能否正常工作軟件常在邊界處發生錯誤（循環條件）通常為單元測試的最后一步，仔細限制數據處理，設置邊界可能與邊界有關的數據類型數值、字符、數量、尺寸等邊界條件設置注意項首個、最后一個；最大、最小；最長、最短；最高、最矮等特征返回模塊中所有獨立執行路徑測試也稱為覆蓋測試常見錯誤誤用或不正確的算術優先級混合類型的運算初始化的錯誤計算的精確度不夠表達式中的不正確符號表示返回各種錯誤處理測試若模塊在工作中發生錯誤，出錯處理是否有效檢查程序出錯處理時，可能情況對運行發生的錯誤描述難以理解所報告的錯誤與實際遇到的錯誤不一致出錯后，在錯誤處理之前就引起了系統的干預異常情況的處理不正確提供的錯誤定位信息不足，以致無法找到出錯的準確原因返回單元測試的執行過程程序編寫、復查和語法正確性驗證后進行單元測試測試用例設計應與復審工作相結合根據設計信息選取數據，可增大發現上述各類錯誤的可能性需設置若干輔助測試模塊驅動模塊（Driver）模擬被測試模塊的上級模塊用來接收測試數據，啟動被測模塊并輸出結果被調用模擬子模塊/樁模塊（Sub）模擬被測模塊工作過程中所調用的模塊圖2-3顯示了一般的單元測試環境圖

一般單元測試環境

什么時候進行單元測試？由誰來進行單元測試？單元測試的依據是什么？單元測試的通過標準是什么？程序員編碼之后，但要做必要準備工作白盒測試工程師或開發人員源程序（程序和注釋）；項目《詳細設計》文檔不同公司有不同標準例子該程序實現如下功能：在主函數main里面定義了一個含有5個整型元素的數組，用1個循環來實現數組元素的輸入，每次循環都調用1次iszero函數，如果輸入的數組元素不等于0，則打印輸出本身；如果為0，則輸出1。一般步驟編譯運行程序（能否運行）靜態測試（代碼是否符合規范）動態測試（深入檢查代碼正確性、容錯性、邊界值）#include<stdio.h>voidiszero(intm){If(m!=0)printf("%d",m);elseprintf("%d",1);}voidmain(void){inta[5];inti=0;printf("請輸入5個整數\n");for(i=0,i<=4,i++){scanf("%d",&a[i])iszero(a[i]);}}邊界循環次數控制1、編譯運行程序編譯運行程序，輸入輸出2、靜態測試3、動態測試邊界值問題非法數據的容錯性非法數據小數，字符等，Scanf函數錯誤判斷能力不強驅動模塊與樁模塊圖驅動模塊與樁模塊例子：#include<stdio.h>voidmain(void){inta=1;intb=2;intc;c=fun1(a,b);}intfun1(intx,inty){returnx+y;}集成測試概念將通過單元測試的單元模塊組裝成系統或子系統再進行測試集成測試目的驗證組成軟件系統的各模塊的接口和交互作用主要測試軟件結構問題多為黑盒測試適當輔以白盒測試，以便能對主要控制路徑進行測試集成測試主要任務檢查系統是否符合實際軟件結構發現與接口有關的各種錯誤主要解決以下5個方面的測試問題組合后檢查模塊相互調用時，數據經過接口是否丟失檢查能否達到預期要求的各項功能一個模塊的功能是否會對另一個模塊的功能產生不利的影響全局數據結構是否有問題，會不會被異常修改單個模塊的誤差積累起來，是否被放大，從而達到不可接受的程度集成測試方法（分類）非增量式集成增量式集成自頂向下集成（top-downintegration）自底向上集成（bottom-upintegration）非增量式測試一步到位方法來進行測試對所有模塊進行個別的單元測試后，按程序結構圖將各模塊連接起來，把連接后的程序當做一個整體進行測試圖2-5給出該集成測試方法的一個經典例子被測程序結構圖驅動模塊樁模塊驅動模塊樁模塊返回增量式測試逐步實現自頂向下增量式測試逐步集成和逐步測試是按結構圖自上而下進行集成的順序集成主控模塊（主程序）按照軟件控制層次結構向下進行集成自頂向下集成集成測試步驟主控模塊作為測試驅動器，把對主控模塊進行單元測試時引入的被調用