軟件測試畢業(yè)論文(下載)[19頁]_第1頁
軟件測試畢業(yè)論文(下載)[19頁]_第2頁
軟件測試畢業(yè)論文(下載)[19頁]_第3頁
軟件測試畢業(yè)論文(下載)[19頁]_第4頁
軟件測試畢業(yè)論文(下載)[19頁]_第5頁
已閱讀5頁,還剩14頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

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

2、關鍵字:軟件測試、白盒測試、黑盒測試、類測試 3 目目 錄錄 1 1 軟件測試的發(fā)展史軟件測試的發(fā)展史.4 2 2 軟件測試的相關背景軟件測試的相關背景. .5 3 3 軟件測試概述軟件測試概述.6 3.1 軟件測試的定義. .6 3.2 軟件測試的描述. .6 3.3 軟件測試的目的.7 3.4 軟件測試的原則. .8 4 軟件測試的內容軟件測試的內容.9 4.1 驗證(verification).9 4.2 確認(validation). .9 5 5 軟件測試的分類軟件測試的分類.10 5.1 常用分類.10 5.2 黑盒測試.10 5.3 白盒測試. .11 5.4 靜態(tài)測試.14 5

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

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

5、TSM(Testability 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)了軟件缺陷沒有正確的處理。 6 3、美國航天局火星極地登陸(1999)該項目使用前有經(jīng)

7、過測試, 兩個測試小組雙方獨立工作都很好, 但從未走在一起。 4、愛國者導彈防御系統(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ī)定的需求或弄清預期結果與實際結果 之間的差別。它是

8、幫助識別開發(fā)完成(中間或最終的版本)的計算 機軟件(整體或部分)的正確度(correctness) 完全度 (completeness)和質量(quality)的軟件過程;是 SQA(software quality assurance)的重要子域。 (1)測試并不僅僅是為了找出錯誤.通過分析錯誤產(chǎn)生的原因和 錯誤的發(fā)生趨勢,可以幫助項目管理者發(fā)現(xiàn)當前軟件開發(fā)過程中的缺 陷,以便及時改進; (2)這種分析也能幫助測試人員設計出有針對性的測試方法,改 7 善測試的效率和有效性; (3)沒有發(fā)現(xiàn)錯誤的測試也是有價值的,完整的測試是評定軟件 質量的一種方法。 3.2 軟件測試的描述 測試是軟件開發(fā)過

9、程的重要組成部分, 是用來確認一個程序的 品質或性能是否符合開發(fā)之前所提出的一些要求。軟件測試的目的, 第一是確認軟件的質量, 其一方面是確認軟件做了你所期望的事情 (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í)行程 8 序的過程; (2)測試是為了證明程序有錯,而不是證明程序無錯誤; (3)一個好的測試用例是在于它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤; (4)一 個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。 這種觀點可以 提醒人們測試要以查找錯誤為中心,而不是為了演示軟

11、件的正確功 能。但是僅憑字面意思理解這一觀點可能會產(chǎn)生誤導,認為發(fā)現(xiàn)錯 誤是軟件測試的唯一目,查找不出錯誤的測試就是沒有價值的,事 實并非如此。 首先,測試并不僅僅是為了要找出錯誤。通過分析 錯誤產(chǎn)生的原因和錯誤的分布特征,可以幫助項目管理者發(fā)現(xiàn)當前 所采用的軟件過程的缺陷,以便改進。同時,這種分析也能幫助我 們設計出有針對性地檢測方法,改善測試的有效性。其次,沒有發(fā) 現(xiàn)錯誤的測試也是有價值的,完整的測試是評定測試質量的一種方 法。 3.4 軟件測試的原則 1應當把盡早和不斷的測試作為開發(fā)者的座右銘。 2程序員應該避免檢查自己的程序, 測試工作應該由獨立的專 業(yè)的軟件測試機構來完成。 3設計測

12、試用例時應該考慮到合法的輸入和不合法的輸入以及 各種邊界條件, 特殊情況下要制造極端狀態(tài)和意外狀態(tài), 比如網(wǎng)絡 異常中斷、電源斷電等情況。 4一定要注意測試中的錯誤集中發(fā)生現(xiàn)象, 這和程序員的編程 水平和習慣有很大的關系。 5對測試錯誤結果一定要有一個確認的過程, 一般有 A 測試出 9 來的錯誤, 一定要有一個 B 來確認, 嚴重的錯誤可以召開評審會進 行討論和分析。 6制定嚴格的測試計劃, 并把測試時間安排的盡量寬松, 不要 希望在極短的時間內完成一個高水平的測試。 7回歸測試的關聯(lián)性一定要引起充分的注意, 修改一個錯誤而 引起更多的錯誤出現(xiàn)的現(xiàn)象并不少見。 8妥善保存一切測試過程文檔,

13、意義是不言而喻的, 測試的重 現(xiàn)性往往要靠測試文檔 4 4 軟件測試的內容軟件測試的內容 4.1 驗證(verification) 驗證(verification)是保證軟件正確地實現(xiàn)了一些特定功能的 一系列活動, 即保證軟件做了你所期望的事情。(Do the right thing) 1.確定軟件生存周期中的一個給定階段的產(chǎn)品是否達到前階段 確立的需求的過程; 2.程序正確性的形式證明, 即采用形式理論證明程序符號設計 規(guī)約規(guī)定的過程; 3.評市、審查、測試、檢查、審計等各類活動, 或對某些項處 理、服務或文件等是否和規(guī)定的需求相一致進行判斷和提出報告。 10 4.2 確認(validati

14、on) 確認(validation)是一系列的活動和過程, 目的是想證實在一 個給定的外部環(huán)境中軟件的邏輯正確性。即保證軟件以正確的方式 來做了這個事件(Do it right) 1.靜態(tài)確認, 不在計算機上實際執(zhí)行程序, 通過人工或程序分 析來證明軟件的正確性; 2.動態(tài)確認, 通過執(zhí)行程序做分析, 測試程序的動態(tài)行為, 以 證實軟件是否存在問題。 軟件測試的對象不僅僅是程序測試, 軟件測試應該包括整個軟 件開發(fā)期問各個階段所產(chǎn)生的文檔, 如需求規(guī)格說明、概要設計文 檔、詳細設計文檔, 當然軟件測試的主要對象還是源程序。 5 5 軟件測試的分類軟件測試的分類 5.1 常用分類 從是否需要執(zhí)行

15、被測軟件的角度, 可分為: 靜態(tài)測試 和動態(tài)測試 從測試是否針對系統(tǒng)的內部結構和具體實現(xiàn)算法的角度來看, 可分為 : 白盒測試 和黑盒測試 11 5.2 黑盒測試 黑盒測試 指的是把被測軟件看作是一個黑盒子, 我們不去關心盒子里面 的結構是什么樣子, 只關心軟件的輸入數(shù)據(jù)和輸出結果。 黑盒測試方法是在程序接口上進行測試, 主要是為了發(fā)現(xiàn)以下 錯誤: 是否有不正確或遺漏了的功能? 在接口上, 輸入能否正確地接受? 能否輸出正確的結果? 是否有數(shù)據(jù)結構錯誤或外部信息(例如數(shù)據(jù)文件)訪問錯誤? 性能上是否能夠滿足要求? 是否有初始化或終止性錯誤? 用黑盒測試發(fā)現(xiàn)程序中的錯誤, 必須在所有可能的輸入條

16、件和 輸出條件中確定測試數(shù)據(jù), 來檢查程序是否都能產(chǎn)生正確的輸出。 但這是不可能的。 n 假設一個程序 P 有輸入量 X 和 Y 及輸出量 Z。在字長為 32 位 的計算機上運行。若 X、Y 取整數(shù), 按黑盒方法進行窮舉測試: n 可能采用的 測試數(shù)據(jù)組: 232232 264 n 如果 測試一組數(shù)據(jù)需要 1 毫秒, 一年工作 365 24 小時, 完成所有測試 需 5 億年。 黑盒測試的測試用例設計 等價劃分法 邊界值法 12 錯誤推測法 因果圖法 5.3 白盒測試 白盒測試指的是把盒子蓋打開, 去研究里面的源代碼和程序結 構。 白盒測試也稱結構測試或邏輯驅動測試, 它是知道產(chǎn)品內部工 作過

17、程, 可通過測試來檢測產(chǎn)品內部動作是否按照規(guī)格說明書的規(guī) 定正常進行, 按照程序內部的結構測試程序, 檢驗程序中的每條通 路是否都有能按預定要求正確工作, 而不顧它的功能。 使用被測單 元內部如何工作的信息, 允許測試人員對程序內部邏輯結構及有關 信息來設計和選擇測試用例, 對程序的邏輯路徑進行測試?;谝?個應用代碼的內部邏輯知識, 測試是基于覆蓋全部代碼、分支、路 徑、條件。 白盒測試的主要方法: 邏輯驅動測試 基本路徑測試 主要用于軟件驗證。 使用程序設計的控制結構導出測試用例。 邏輯驅動測試: 主要是測試覆蓋率, 以程序內在邏輯結構為基礎的測試。包括 以下 6 種類型: 13 語句覆蓋

18、 判斷覆蓋 條件覆蓋 判定-條件覆蓋 條件組合覆蓋 路徑覆蓋 白盒測試的主要目的 保證一個模塊中的所有獨立路徑至少被執(zhí)行一次; 對所有的邏輯值均需要測試真、假兩個分支; 在上下邊界及可操作范圍內運行所有循環(huán); 檢查內部數(shù)據(jù)結構以確保其有效性 白盒測試的實施方案 在開發(fā)階段 要保證產(chǎn)品的質量, 產(chǎn)品的生產(chǎn)過程應該遵循一定的行業(yè)標準。 軟件產(chǎn)品也是同樣, 沒有標準可依自然談不上質量的好壞。所有關 心軟件開發(fā)質量的組織、單位, 都要定義或了解軟件的質量標準、 模型。其好處是保證公司實踐的均勻性, 產(chǎn)品的可維護性、可靠性 以及可移植性等。 在測試階段 與軟件產(chǎn)品的開發(fā)過程一樣, 測試過程也需要有一定的

19、準則, 來指導、度量、評價軟件測試過程的質量。 定義測試準則 14 為控制測試的有效性以及完成程度, 必須定義準則和策略, 以 判斷何時結束測試階段。準則必須是客觀的, 可量化的元素, 而不 能是經(jīng)驗或感覺。 根據(jù)應用的準則和項目相關的約束, 項目領導可以定義使用的 度量方法, 和要達到的覆蓋率。 度量測試的有效性、完整性 對每個測試的測試覆蓋信息和累計信息, 用圖形方式顯示 覆蓋比率, 并根據(jù)測試運行情況實時更新, 隨時顯示新的測試所反 映的測試覆蓋情況。 允許所有的測試運行依據(jù)其有效性進行管理, 用戶可以減 少不適用于非回歸測試的測試的過程。 概念: 1.語句覆蓋:語句覆蓋就是設計若干個測

20、試用例, 運行被測試 程序, 使得每一條可執(zhí)行語句至少執(zhí)行一次; 2.判定覆蓋(也稱為分支覆蓋):設計若干個測試用例, 運行 所測程序, 使程序中每個判斷的取真分支和取假分支至少執(zhí)行一次; 3.條件覆蓋:設計足夠多的測試用例, 運行所測程序, 使程序 中每個判斷的每個條件的每個可能取值至少執(zhí)行一次; 4.判定-條件覆蓋:設計足夠多的測試用例, 運行所測程序, 使 程序中每個判斷的每個條件的所有可能取值至少執(zhí)行一次, 并且每 個可能的判斷結果也至少執(zhí)行一次, 換句話說, 即是要求各個判斷 的所有可能的條件取值組合至少執(zhí)行一次; 15 5.條件組合測試:設計足夠多的測試用例, 運行所測程序, 使

21、程序中每個判斷的所有可能的條件取值組合至少執(zhí)行一次; 6.路徑測試:設計足夠多的測試用例, 運行所測程序, 要覆蓋 程序中所有可能的路徑。 5.4 靜態(tài)測試 是指不實際運行被測軟件, 而只是靜態(tài)的檢查程序代碼、界面 或文檔中可能存在的錯誤的過程。 其中包括代碼測試、界面測試和文檔測試 3 個方面。對于代碼 測試, 主要測試代碼是否符合相應的標準和規(guī)范。對于界面測試, 主要測試軟件的實際界面與需求中的說明是否相符。對于文檔測試, 主要測試用戶手冊和需求說明是否符合用戶的實際要求。 5.5 動態(tài)測試 是指實際運行被測程序, 輸入相應的測試數(shù)據(jù), 檢查實際輸出 結果和預期結果是否相符的過程。所以,

22、我們判斷一個測試屬于動 態(tài)還是靜態(tài)測試 , 唯一的標準就是看是否運行程序。 6 6 軟件測試中的類測試軟件測試中的類測試 6.1面向對象軟件從宏觀上來看是各個類之間的相互作用。在 16 面向對象系統(tǒng)中,系統(tǒng)的基本構造模塊是封裝了的數(shù)據(jù)和方法的類和 對象,而不再是一個個能完成特定功能的功能模塊。每個對象有自己 的生存周期,有自己的狀態(tài)。消息是對象之間相互請求或協(xié)作的途徑, 是外界使用對象方法及獲取對象狀態(tài)的唯一方式。對象的功能是在 消息的觸發(fā)下,由對象所屬類中定義的方法與相關對象的合作共同完 成,且在不同狀態(tài)下對消息的響應可能完全不同。對象中的數(shù)據(jù)和方 法是一個有機的整體,測試過程中不能僅僅檢查

23、輸入數(shù)據(jù)產(chǎn)生的輸出 結果是否與預期的吻合,還要考慮對象的狀態(tài)。模塊測試的概念已不 適用于對象的測試“類測試將是整個測試過程的一個重要步驟。 6.2 類測試技術 6.2.1 基于服務的類測試技術 基于服務的類測試主要考察封裝在類中的一個方法對數(shù)據(jù)進行 的操作,它可以采用傳統(tǒng)的白盒測試方法。為克服軟件測試的盲目 性和局限性,保證測試的質量,提高軟件的可靠性,下面我們介紹一種 類的服務的測試模型及相應的測試策略。 BBD 通常有兩種獲取途徑。一是采用逆向工程的方法根 據(jù)源程序畫出流程圖,然后構造出 BBD。但這畢竟是在缺少軟件開發(fā) 前期的分析、設計文檔或文檔不齊全的情況下退而求其次的辦法。 當源程序

24、不正確時構造出來的 BBD 就是錯誤的。另一種途徑就是追 根溯源,在軟件的分析、設計階段就根據(jù)測試的需要構造出相應的 BBD。這樣就能從根本上解決問題,正確地指導類的服務的測試。 17 6.2.2 基于層次增量的類測試 層次增量測試的基本思想是:首先分別測試父類的各個成員函 數(shù),再測試成員函數(shù)間的相互作用,把測試用例和執(zhí)行信息保存在/測 試歷史中,在測試子類時,根據(jù)父類的測試歷史修改部分的定義以及實 現(xiàn)語言的繼承映射來決定子類中的哪些特征應當重測試以及父類的 哪些測試用例可以復用。 這種根據(jù)類間繼承關系的層次特性對類進行增量測試的技術是 由 M. Harrold 等人提出的,其特點是復用父類的測試信息來指導子類 的測試。 7 參考文獻參考文獻

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論