軟件測試畢業(yè)論文

1、 畢業(yè)論文畢業(yè)論文 姓姓 名：陳鑫名：陳鑫 專專 業(yè)業(yè):.Net:.Net 軟件開發(fā)軟件開發(fā) 年年 級：計軟級：計軟 13021302 學學 號：號：201317140212201317140212 指導教師指導教師: :王梅王梅 軟件測試的概述及方法 、 、 完成時間：2012 年 3 月摘要：摘要：從軟件產(chǎn)業(yè)的發(fā)展初期到目前的大型軟件開發(fā)過程，軟件測試已成為其中一個不可分割的部分。隨著軟件規(guī)模的日益增大，軟件測試問題也日益突出，現(xiàn)代社會對軟件的依賴越來越強,高可信軟件測試有著廣泛的需求，基于缺陷模式的軟件測試技術作為高可信軟件的重要保證,可以大大降低軟件的缺陷密度,提高軟件的可信性。本文從

2、測試的基本概念入手,深入剖析軟件測試相關理論關鍵字：關鍵字：軟件測試、白盒測試、黑盒測試、類測試 目目 錄錄1 1 軟件測試的發(fā)展史軟件測試的發(fā)展史.4 2 2 軟件測試的相關背景軟件測試的相關背景. .53 3 軟件測試概述軟件測試概述.6 3.1 軟件測試的定義.6 3.2 軟件測試的描述.6 3.3 軟件測試的目的.7 3.4 軟件測試的原則.84 軟件測試的內容軟件測試的內容.9 4.1 驗證(verification).9 4.2 確認(validation).95 5 軟件測試的分類軟件測試的分類.10 5.1 常用分類.10 5.2 黑盒測試.10 5.3 白盒測試.11 5.4

3、 靜態(tài)測試.14 5.5 動態(tài)測試.156 6 軟件測試中的類測試軟件測試中的類測試.15 6.1 面向對象軟件的類測試概念.156.2.類測試技術.167 7 參考文獻參考文獻.17.178 8 致謝致謝.18 1 1 軟件測試的發(fā)展史軟件測試的發(fā)展史軟件測試的發(fā)展歷史：20 世紀 60 年代（軟件工程建立前） ，為表明程序正確而進行測試。. 1972 年在北卡羅來納大學舉行了首屆軟件測試正式會議。. 1975 年 John Good Enough 和 Susan Gerhart 在IEEE 上發(fā)表了測試數(shù)據(jù)選擇的原理的文章，軟件測試被確定為一種研究方向。. 1979 年，Glenford

4、Myers 的軟件測試藝術 ，對測試做了定義：測試是為發(fā)現(xiàn)錯誤而執(zhí)行的一個程序或者系統(tǒng)的過程。. 20 世紀 80 年代早期， “質量”的號角開始吹響。軟件測試定義發(fā)生了改變，測試不單純是一個發(fā)現(xiàn)錯誤的過程，而且包含軟件質量評價的內容。制定了各類標準。. 1983 年，Bill Hetzel 在軟件測試完全指南中指出：測試是以評價一個程序或者系統(tǒng)屬性為目標的任何一種活動，測試是對軟件質量的度量。. 20 世紀 90年代，測試工具盛行起來。. 1996 年提出的測試能力成熟度TCMM（Testing Capability Maturity Model） 、測試支持度TSM（Testability

5、 Support Model） 、測試成熟度 TMM（Testing Maturity Model） 。. 到了 2002 年，Rick 和 Stefan 在系統(tǒng)的軟件測試一書中對軟件測試做了進一步定義：測試是為了度量和提高被測軟件的質量，對測試軟件進行工程設計、實施和維護的整個生命過程。 2 2 軟件測試的相關背景軟件測試的相關背景相關背景：前段時間, 就是在我沒有認真了解測試行業(yè)之前, 可能由于測試在中國的重視程度的問題, 我也一直認為測試應該是不重要的, 甚至認為有必要有專門的測試職業(yè)嗎？認為軟件主要是開發(fā)人員的事, 軟件的成果也是由開發(fā)人員決定的, 當我在參加工作后, 真正從學校的學習

6、環(huán)境中走上實際運用開發(fā)的時候, 事實上真的不是那么一回事哦。軟件無處不在, 軟而, 軟件是人編的所以不完美。臭名昭著的軟件測試案例：1、迪士尼的獅子王 （19941995）軟件在少數(shù)系統(tǒng)中能正常工作, 但在大眾使用的常見系統(tǒng)中不行。后來證實, 迪士尼公司沒有對市場上投入實用的各種 pc 機型進行正確的測試。2、英特爾奔騰浮點除法軟件缺陷（1994）英特爾為自己處理軟件缺陷拿出 4 億美元支付更換壞芯片的費用。導致付出如此昂貴的代價, 其主要原因是發(fā)現(xiàn)了軟件缺陷沒有正確的處理。3、美國航天局火星極地登陸（1999）該項目使用前有經(jīng)過測試, 兩個測試小組雙方獨立工作都很好, 但從未走在一起。4、愛

7、國者導彈防御系統(tǒng) （1991）一枚導彈在多哈擊斃 28 名美國士兵, 癥結在于一個軟件缺陷：一個很小的系統(tǒng)時鐘錯誤累積起來就可能拖延 14 小時, 造成跟蹤系統(tǒng)失去準確度。在多哈襲擊戰(zhàn)中系統(tǒng)被拖延 100 小時。5、千年蟲 （大約 1974）估計世界各地更換或升級該系統(tǒng)程序解決原有 2000 年錯誤的費用已經(jīng)超過數(shù)億美元。 3 3 軟件測試的概述軟件測試的概述3.1 軟件測試的定義軟件測試使用人工或者自動手段來運行或測試某個系統(tǒng)的過程,其目的在于檢驗它是否滿足規(guī)定的需求或弄清預期結果與實際結果之間的差別。它是幫助識別開發(fā)完成（中間或最終的版本）的計算機軟件（整體或部分）的正確度(correct

8、ness) 完全度(completeness)和質量(quality)的軟件過程；是 SQA(software quality assurance)的重要子域。(1)測試并不僅僅是為了找出錯誤.通過分析錯誤產(chǎn)生的原因和錯誤的發(fā)生趨勢,可以幫助項目管理者發(fā)現(xiàn)當前軟件開發(fā)過程中的缺陷,以便及時改進； (2)這種分析也能幫助測試人員設計出有針對性的測試方法,改善測試的效率和有效性； (3)沒有發(fā)現(xiàn)錯誤的測試也是有價值的,完整的測試是評定軟件質量的一種方法。3.2 軟件測試的描述測試是軟件開發(fā)過程的重要組成部分, 是用來確認一個程序的品質或性能是否符合開發(fā)之前所提出的一些要求。軟件測試的目的, 第一是

9、確認軟件的質量, 其一方面是確認軟件做了你所期望的事情（Do the right thing）, 另一方面是確認軟件以正確的方式來做了這個事件（Do it right） ；第二是提供信息, 比如提供給開發(fā)人員或程序經(jīng)理的反饋信息, 為風險評估所準備的信息；第三軟件測試不僅是在測試軟件產(chǎn)品的本身, 而且還包括軟件開發(fā)的過程。如果一個軟件產(chǎn)品開發(fā)完成之后發(fā)現(xiàn)了很多問題, 這說明此軟件開發(fā)過程很可能是有缺陷的。3.3 軟件測試的目的如果測試的目的是為了盡可能多地找出錯誤，那么測試就應該直接針對軟件比較復雜的部分或是以前出錯比較多的位置。如果測試目的是為了給最終用戶提供具有一定可信度的質量評價，那么測

10、試就應該直接針對在實際應用中會經(jīng)常用到的商業(yè)假設。 在談到軟件測試時，引用 Grenford J. Myers 在The Art of Software Testing一書中的觀點: (1)軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程; (2)測試是為了證明程序有錯，而不是證明程序無錯誤; (3)一個好的測試用例是在于它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤; (4)一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。 這種觀點可以提醒人們測試要以查找錯誤為中心，而不是為了演示軟件的正確功能。但是僅憑字面意思理解這一觀點可能會產(chǎn)生誤導，認為發(fā)現(xiàn)錯誤是軟件測試的唯一目，查找不出錯誤的測試就是沒有價值的，事實并非如此。 首先

11、，測試并不僅僅是為了要找出錯誤。通過分析錯誤產(chǎn)生的原因和錯誤的分布特征，可以幫助項目管理者發(fā)現(xiàn)當前所采用的軟件過程的缺陷，以便改進。同時，這種分析也能幫助我們設計出有針對性地檢測方法，改善測試的有效性。其次，沒有發(fā)現(xiàn)錯誤的測試也是有價值的，完整的測試是評定測試質量的一種方法。3.4 軟件測試的原則1應當把盡早和不斷的測試作為開發(fā)者的座右銘。 2程序員應該避免檢查自己的程序, 測試工作應該由獨立的專業(yè)的軟件測試機構來完成。 3設計測試用例時應該考慮到合法的輸入和不合法的輸入以及各種邊界條件, 特殊情況下要制造極端狀態(tài)和意外狀態(tài), 比如網(wǎng)絡異常中斷、電源斷電等情況。 4一定要注意測試中的錯誤集中發(fā)

12、生現(xiàn)象, 這和程序員的編程水平和習慣有很大的關系。 5對測試錯誤結果一定要有一個確認的過程, 一般有 A 測試出來的錯誤, 一定要有一個 B 來確認, 嚴重的錯誤可以召開評審會進行討論和分析。 6制定嚴格的測試計劃, 并把測試時間安排的盡量寬松, 不要希望在極短的時間內完成一個高水平的測試。 7回歸測試的關聯(lián)性一定要引起充分的注意, 修改一個錯誤而引起更多的錯誤出現(xiàn)的現(xiàn)象并不少見。 8妥善保存一切測試過程文檔, 意義是不言而喻的, 測試的重現(xiàn)性往往要靠測試文檔 4 4 軟件測試的內容軟件測試的內容4.1 驗證(verification)驗證(verification)是保證軟件正確地實現(xiàn)了一些

13、特定功能的一系列活動, 即保證軟件做了你所期望的事情。(Do the right thing) 1.確定軟件生存周期中的一個給定階段的產(chǎn)品是否達到前階段確立的需求的過程；2.程序正確性的形式證明, 即采用形式理論證明程序符號設計規(guī)約規(guī)定的過程；3.評市、審查、測試、檢查、審計等各類活動, 或對某些項處理、服務或文件等是否和規(guī)定的需求相一致進行判斷和提出報告。4.2 確認(validation)確認(validation)是一系列的活動和過程, 目的是想證實在一個給定的外部環(huán)境中軟件的邏輯正確性。即保證軟件以正確的方式來做了這個事件(Do it right)1.靜態(tài)確認, 不在計算機上實際執(zhí)行程

14、序, 通過人工或程序分析來證明軟件的正確性；2.動態(tài)確認, 通過執(zhí)行程序做分析, 測試程序的動態(tài)行為, 以證實軟件是否存在問題。軟件測試的對象不僅僅是程序測試, 軟件測試應該包括整個軟件開發(fā)期問各個階段所產(chǎn)生的文檔, 如需求規(guī)格說明、概要設計文檔、詳細設計文檔, 當然軟件測試的主要對象還是源程序。 5 5 軟件測試的分類軟件測試的分類5.1 常用分類從是否需要執(zhí)行被測軟件的角度, 可分為： 靜態(tài)測試 和動態(tài)測試 從測試是否針對系統(tǒng)的內部結構和具體實現(xiàn)算法的角度來看, 可分為 ： 白盒測試 和黑盒測試5.2 黑盒測試黑盒測試指的是把被測軟件看作是一個黑盒子, 我們不去關心盒子里面的結構是什么樣子

15、, 只關心軟件的輸入數(shù)據(jù)和輸出結果。黑盒測試方法是在程序接口上進行測試, 主要是為了發(fā)現(xiàn)以下錯誤: 是否有不正確或遺漏了的功能? 在接口上, 輸入能否正確地接受? 能否輸出正確的結果? 是否有數(shù)據(jù)結構錯誤或外部信息(例如數(shù)據(jù)文件)訪問錯誤? 性能上是否能夠滿足要求? 是否有初始化或終止性錯誤? 用黑盒測試發(fā)現(xiàn)程序中的錯誤, 必須在所有可能的輸入條件和輸出條件中確定測試數(shù)據(jù), 來檢查程序是否都能產(chǎn)生正確的輸出。 但這是不可能的。n 假設一個程序 P 有輸入量 X 和 Y 及輸出量 Z。在字長為 32 位的計算機上運行。若 X、Y 取整數(shù), 按黑盒方法進行窮舉測試：n 可能采用的 測試數(shù)據(jù)組： 2

16、32232 264 n 如果測試一組數(shù)據(jù)需要 1 毫秒, 一年工作 365 24 小時, 完成所有測試需 5 億年。黑盒測試的測試用例設計等價劃分法邊界值法錯誤推測法因果圖法5.3 白盒測試白盒測試指的是把盒子蓋打開, 去研究里面的源代碼和程序結構。白盒測試也稱結構測試或邏輯驅動測試, 它是知道產(chǎn)品內部工作過程, 可通過測試來檢測產(chǎn)品內部動作是否按照規(guī)格說明書的規(guī)定正常進行, 按照程序內部的結構測試程序, 檢驗程序中的每條通路是否都有能按預定要求正確工作, 而不顧它的功能。 使用被測單元內部如何工作的信息, 允許測試人員對程序內部邏輯結構及有關信息來設計和選擇測試用例, 對程序的邏輯路徑進行測

17、試?；谝粋€應用代碼的內部邏輯知識, 測試是基于覆蓋全部代碼、分支、路徑、條件。 白盒測試的主要方法： 邏輯驅動測試 基本路徑測試 主要用于軟件驗證。 使用程序設計的控制結構導出測試用例。 邏輯驅動測試：主要是測試覆蓋率, 以程序內在邏輯結構為基礎的測試。包括以下 6 種類型： 語句覆蓋 判斷覆蓋 條件覆蓋 判定-條件覆蓋 條件組合覆蓋 路徑覆蓋 白盒測試的主要目的 保證一個模塊中的所有獨立路徑至少被執(zhí)行一次； 對所有的邏輯值均需要測試真、假兩個分支； 在上下邊界及可操作范圍內運行所有循環(huán)；檢查內部數(shù)據(jù)結構以確保其有效性 白盒測試的實施方案 在開發(fā)階段要保證產(chǎn)品的質量, 產(chǎn)品的生產(chǎn)過程應該遵循

18、一定的行業(yè)標準。軟件產(chǎn)品也是同樣, 沒有標準可依自然談不上質量的好壞。所有關心軟件開發(fā)質量的組織、單位, 都要定義或了解軟件的質量標準、模型。其好處是保證公司實踐的均勻性, 產(chǎn)品的可維護性、可靠性以及可移植性等。 在測試階段與軟件產(chǎn)品的開發(fā)過程一樣, 測試過程也需要有一定的準則, 來指導、度量、評價軟件測試過程的質量。定義測試準則為控制測試的有效性以及完成程度, 必須定義準則和策略, 以判斷何時結束測試階段。準則必須是客觀的, 可量化的元素, 而不能是經(jīng)驗或感覺。 根據(jù)應用的準則和項目相關的約束, 項目領導可以定義使用的度量方法, 和要達到的覆蓋率。 度量測試的有效性、完整性對每個測試的測試覆

19、蓋信息和累計信息, 用圖形方式顯示覆蓋比率, 并根據(jù)測試運行情況實時更新, 隨時顯示新的測試所反映的測試覆蓋情況。允許所有的測試運行依據(jù)其有效性進行管理, 用戶可以減少不適用于非回歸測試的測試的過程。 概念： 1.語句覆蓋：語句覆蓋就是設計若干個測試用例, 運行被測試程序, 使得每一條可執(zhí)行語句至少執(zhí)行一次； 2.判定覆蓋（也稱為分支覆蓋）：設計若干個測試用例, 運行所測程序, 使程序中每個判斷的取真分支和取假分支至少執(zhí)行一次；3.條件覆蓋：設計足夠多的測試用例, 運行所測程序, 使程序中每個判斷的每個條件的每個可能取值至少執(zhí)行一次； 4.判定-條件覆蓋：設計足夠多的測試用例, 運行所測程序,

20、 使程序中每個判斷的每個條件的所有可能取值至少執(zhí)行一次, 并且每個可能的判斷結果也至少執(zhí)行一次, 換句話說, 即是要求各個判斷的所有可能的條件取值組合至少執(zhí)行一次； 5.條件組合測試：設計足夠多的測試用例, 運行所測程序, 使程序中每個判斷的所有可能的條件取值組合至少執(zhí)行一次； 6.路徑測試：設計足夠多的測試用例, 運行所測程序, 要覆蓋程序中所有可能的路徑。5.4 靜態(tài)測試是指不實際運行被測軟件, 而只是靜態(tài)的檢查程序代碼、界面或文檔中可能存在的錯誤的過程。其中包括代碼測試、界面測試和文檔測試 3 個方面。對于代碼測試, 主要測試代碼是否符合相應的標準和規(guī)范。對于界面測試, 主要測試軟件的實

21、際界面與需求中的說明是否相符。對于文檔測試, 主要測試用戶手冊和需求說明是否符合用戶的實際要求。5.5 動態(tài)測試是指實際運行被測程序, 輸入相應的測試數(shù)據(jù), 檢查實際輸出結果和預期結果是否相符的過程。所以, 我們判斷一個測試屬于動態(tài)還是靜態(tài)測試 , 唯一的標準就是看是否運行程序。 6 6 軟件測試中的類測試軟件測試中的類測試6.1面向對象軟件從宏觀上來看是各個類之間的相互作用。在面向對象系統(tǒng)中,系統(tǒng)的基本構造模塊是封裝了的數(shù)據(jù)和方法的類和對象,而不再是一個個能完成特定功能的功能模塊。每個對象有自己的生存周期,有自己的狀態(tài)。消息是對象之間相互請求或協(xié)作的途徑,是外界使用對象方法及獲取對象狀態(tài)的唯

22、一方式。對象的功能是在消息的觸發(fā)下,由對象所屬類中定義的方法與相關對象的合作共同完成,且在不同狀態(tài)下對消息的響應可能完全不同。對象中的數(shù)據(jù)和方法是一個有機的整體,測試過程中不能僅僅檢查輸入數(shù)據(jù)產(chǎn)生的輸出結果是否與預期的吻合,還要考慮對象的狀態(tài)。模塊測試的概念已不適用于對象的測試“類測試將是整個測試過程的一個重要步驟。6.2 類測試技術 6.2.1 基于服務的類測試技術 基于服務的類測試主要考察封裝在類中的一個方法對數(shù)據(jù)進行的操作，它可以采用傳統(tǒng)的白盒測試方法。為克服軟件測試的盲目性和局限性,保證測試的質量,提高軟件的可靠性,下面我們介紹一種類的服務的測試模型及相應的測試策略。 BBD 通常有兩

23、種獲取途徑。一是采用逆向工程的方法根據(jù)源程序畫出流程圖,然后構造出 BBD。但這畢竟是在缺少軟件開發(fā)前期的分析、設計文檔或文檔不齊全的情況下退而求其次的辦法。當源程序不正確時構造出來的 BBD 就是錯誤的。另一種途徑就是追根溯源,在軟件的分析、設計階段就根據(jù)測試的需要構造出相應的BBD。這樣就能從根本上解決問題,正確地指導類的服務的測試。6.2.2 基于層次增量的類測試 層次增量測試的基本思想是:首先分別測試父類的各個成員函數(shù),再測試成員函數(shù)間的相互作用,把測試用例和執(zhí)行信息保存在/測試歷史中,在測試子類時,根據(jù)父類的測試歷史修改部分的定義以及實現(xiàn)語言的繼承映射來決定子類中的哪些特征應當重測試以及父類的哪些測試用例可以復用。 這種根據(jù)類間繼承關系的層次特性對類進行增量測試的技術是由 M. Harrold 等人提出的,其特點是復用父類的測試信息來指導子類的測試。 7 參考文獻參考文獻參考