第一篇：軟件測試畢業(yè)論文解讀

畢業(yè)論文

姓 名：陳鑫 專 業(yè):.Net軟件開發(fā) 年 級：計軟1302 學 號：201317140212指導教師:王梅 1

軟件測試的概述及方法、、完成時間：2012年3月

摘要：從軟件產(chǎn)業(yè)的發(fā)展初期到目前的大型軟件開發(fā)過程，軟件測試已成為其中一個不可分割的部分。隨著軟件規(guī)模的日益增大，軟件測試問題也日益突出，現(xiàn)代社會對軟件的依賴越來越強,高可信軟件測試有著廣泛的需求，基于缺陷模式的軟件測試技術作為高可信軟件的重要保證,可以大大降低軟件的缺陷密度,提高軟件的可信性。本文從測試的基本概念入手,深入剖析軟件測試相關理論 關鍵字：軟件測試、白盒測試、黑盒測試、類測試

目 錄 軟件測試的發(fā)展史.......................................4 2軟件測試的相關背景......................................5 3 軟件測試概述............................................6

3.1軟件測試的定義..............................................................................6

3.2軟件測試的描述.............................................................................6

3.3軟件測試的目的............................................................................7

3.4軟件測試的原則.............................................................................8 4 軟件測試的內(nèi)容....................................................................................9

4.1驗證(verification)...........................................................................9 4.2確認(validation)....................................9 5 軟件測試的分類.........................................10 5.1 常用分類..........................................10錯誤！未定義書簽。

5.2 黑盒測試..........................................10 5.3白盒測試...........................................11

5.4 靜態(tài)測試..........................................14

5.5動態(tài)測試...........................................15 6 軟件測試中的類測試.....................................15 6.1念面向

對

象

軟

件的6.2.類類

測測

試試

概技.....................................................15術.........................................16 7 參考文獻..............................................17 8 致謝...................................................18

1軟件測試的發(fā)展史

軟件測試的發(fā)展歷史：20世紀60年代（軟件工程建立前），為表明程序正確而進行測試。.1972年在北卡羅來納大學舉行了首屆軟件測試正式會議。.1975年John Good Enough和Susan Gerhart在IEEE上發(fā)表了《測試數(shù)據(jù)選擇的原理》的文章，軟件測試被確定為一種研究方向。.1979年，Glenford Myers的《軟件測試藝術》，對測試做了定義：測試是為發(fā)現(xiàn)錯誤而執(zhí)行的一個程序或者系統(tǒng)的過程。.20世紀80年代早期，“質(zhì)量”的號角開始吹響。軟件測試定義發(fā)生了改變，測試不單純是一個發(fā)現(xiàn)錯誤的過程，而且包含軟件質(zhì)量評價的內(nèi)容。制定了各類標準。.1983年，Bill Hetzel在《軟件測試完全指南》中指出：測試是以評價一個程序或者系統(tǒng)屬性為目標的任何一種活動，測試是對軟件質(zhì)量的度量。.20世紀90年代，測試工具盛行起來。.1996年提出的測試能力成熟度TCMM（Testing Capability Maturity Model）、測試支持度TSM（Testability Support Model）、測試成熟度TMM（Testing Maturity Model）。.到了2002年，Rick和Stefan在《系統(tǒng)的軟件測試》一書中對軟件測試做了進一步定義：測試是為了度量和提高被測軟件的質(zhì)量，對測試軟件進行工程設計、實施和維護的整個生命過程。2軟件測試的相關背景

相關背景：前段時間, 就是在我沒有認真了解測試行業(yè)之前, 可能由于測試在中國的重視程度的問題, 我也一直認為測試應該是不重要的, 甚至認為有必要有專門的測試職業(yè)嗎？認為軟件主要是開發(fā)人員的事, 軟件的成果也是由開發(fā)人員決定的, 當我在參加工作后, 真正從學校的學習環(huán)境中走上實際運用開發(fā)的時候, 事實上真的不是那么一回事哦。軟件無處不在, 軟而, 軟件是人編的——所以不完美。臭名昭著的軟件測試案例：

1、迪士尼的獅子王（1994～1995）軟件在少數(shù)系統(tǒng)中能正常工作, 但在大眾使用的常見系統(tǒng)中不行。后來證實, 迪士尼公司沒有對市場上投入實用的各種pc機型進行正確的測試。

2、英特爾奔騰浮點除法軟件缺陷（1994）英特爾為自己處理軟件缺陷拿出4億美元支付更換壞芯片的費用。導致付出如此昂貴的代價, 其主要原因是發(fā)現(xiàn)了軟件缺陷沒有正確的處理。

3、美國航天局火星極地登陸（1999）該項目使用前有經(jīng)過測試, 兩個測試小組雙方獨立工作都很好, 但從未走在一起。

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.1軟件測試的定義

軟件測試使用人工或者自動手段來運行或測試某個系統(tǒng)的過程,其目的在于檢驗它是否滿足規(guī)定的需求或弄清預期結果與實際結果之間的差別。它是幫助識別開發(fā)完成（中間或最終的版本）的計算機軟件（整體或部分）的正確度(correctness)完全度(completeness)和質(zhì)量(quality)的軟件過程；是SQA(software quality assurance)的重要子域。

(1)測試并不僅僅是為了找出錯誤.通過分析錯誤產(chǎn)生的原因和錯誤的發(fā)生趨勢,可以幫助項目管理者發(fā)現(xiàn)當前軟件開發(fā)過程中的缺陷,以便及時改進；

(2)這種分析也能幫助測試人員設計出有針對性的測試方法,改善測試的效率和有效性；

(3)沒有發(fā)現(xiàn)錯誤的測試也是有價值的,完整的測試是評定軟件質(zhì)量的一種方法。

3.2軟件測試的描述

測試是軟件開發(fā)過程的重要組成部分, 是用來確認一個程序的品質(zhì)或性能是否符合開發(fā)之前所提出的一些要求。軟件測試的目的, 第一是確認軟件的質(zhì)量, 其一方面是確認軟件做了你所期望的事情 6（Do the right thing）, 另一方面是確認軟件以正確的方式來做了這個事件（Do it right）；第二是提供信息, 比如提供給開發(fā)人員或程序經(jīng)理的反饋信息, 為風險評估所準備的信息；第三軟件測試不僅是在測試軟件產(chǎn)品的本身, 而且還包括軟件開發(fā)的過程。如果一個軟件產(chǎn)品開發(fā)完成之后發(fā)現(xiàn)了很多問題, 這說明此軟件開發(fā)過程很可能是有缺陷的。

3.3軟件測試的目的

如果測試的目的是為了盡可能多地找出錯誤，那么測試就應該直接針對軟件比較復雜的部分或是以前出錯比較多的位置。如果測試目的是為了給最終用戶提供具有一定可信度的質(zhì)量評價，那么測試就應該直接針對在實際應用中會經(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)錯誤是軟件測試的唯一目，查找不出錯誤的測試就是沒有價值的，事實并非如此。首先，測試并不僅僅是為了要找出錯誤。通過分析錯誤產(chǎn)生的原因和錯誤的分布特征，可以幫助項目管理者發(fā)現(xiàn)當前所采用的軟件過程的缺陷，以便 改進。同時，這種分析也能幫助我們設計出有針對性地檢測方法，改善測試的有效性。其次，沒有發(fā)現(xiàn)錯誤的測試也是有價值的，完整的測試是評定測試質(zhì)量的一種方法。

3.4軟件測試的原則

1．應當把“盡早和不斷的測試”作為開發(fā)者的座右銘。2．程序員應該避免檢查自己的程序, 測試工作應該由獨立的專業(yè)的軟件測試機構來完成。

3．設計測試用例時應該考慮到合法的輸入和不合法的輸入以及各種邊界條件, 特殊情況下要制造極端狀態(tài)和意外狀態(tài), 比如網(wǎng)絡異常中斷、電源斷電等情況。

4．一定要注意測試中的錯誤集中發(fā)生現(xiàn)象, 這和程序員的編程水平和習慣有很大的關系。

5．對測試錯誤結果一定要有一個確認的過程, 一般有A測試出來的錯誤, 一定要有一個B來確認, 嚴重的錯誤可以召開評審會進行討論和分析。

6．制定嚴格的測試計劃, 并把測試時間安排的盡量寬松, 不要希望在極短的時間內(nèi)完成一個高水平的測試。

7．回歸測試的關聯(lián)性一定要引起充分的注意, 修改一個錯誤而引起更多的錯誤出現(xiàn)的現(xiàn)象并不少見。

8．妥善保存一切測試過程文檔, 意義是不言而喻的, 測試的重現(xiàn)性往往要靠測試文檔 4軟件測試的內(nèi)容

4.1驗證(verification)驗證(verification)是保證軟件正確地實現(xiàn)了一些特定功能的一系列活動, 即保證軟件做了你所期望的事情。(Do the right thing)1.確定軟件生存周期中的一個給定階段的產(chǎn)品是否達到前階段確立的需求的過程；

2.程序正確性的形式證明, 即采用形式理論證明程序符號設計規(guī)約規(guī)定的過程；

3.評市、審查、測試、檢查、審計等各類活動, 或?qū)δ承╉椞幚怼⒎栈蛭募仁欠窈鸵?guī)定的需求相一致進行判斷和提出報告。4.2確認(validation)確認(validation)是一系列的活動和過程, 目的是想證實在一個給定的外部環(huán)境中軟件的邏輯正確性。即保證軟件以正確的方式來做了這個事件(Do it right)1.靜態(tài)確認, 不在計算機上實際執(zhí)行程序, 通過人工或程序分析來證明軟件的正確性；

2.動態(tài)確認, 通過執(zhí)行程序做分析, 測試程序的動態(tài)行為, 以證實軟件是否存在問題。

軟件測試的對象不僅僅是程序測試, 軟件測試應該包括整個軟 9 件開發(fā)期問各個階段所產(chǎn)生的文檔, 如需求規(guī)格說明、概要設計文檔、詳細設計文檔, 當然軟件測試的主要對象還是源程序。

5軟件測試的分類

5.1常用分類

從是否需要執(zhí)行被測軟件的角度, 可分為： —靜態(tài)測試 和動態(tài)測試

從測試是否針對系統(tǒng)的內(nèi)部結構和具體實現(xiàn)算法的角度來看, 可分為 ：

－白盒測試 和黑盒測試 5.2黑盒測試

黑盒測試

指的是把被測軟件看作是一個黑盒子, 我們不去關心盒子里面的結構是什么樣子, 只關心軟件的輸入數(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ù)組： 232×232 ＝264 n如果測試一組數(shù)據(jù)需要1毫秒, 一年工作365× 24小時, 完成所有測試需5億年。

黑盒測試的測試用例設計 ?等價劃分法 ?邊界值法 ?錯誤推測法 ?因果圖法

5.3白盒測試

白盒測試指的是把盒子蓋打開, 去研究里面的源代碼和程序結構。

白盒測試也稱結構測試或邏輯驅(qū)動測試, 它是知道產(chǎn)品內(nèi)部工作過程, 可通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進行, 按照程序內(nèi)部的結構測試程序, 檢驗程序中的每條通 路是否都有能按預定要求正確工作, 而不顧它的功能。使用被測單元內(nèi)部如何工作的信息, 允許測試人員對程序內(nèi)部邏輯結構及有關信息來設計和選擇測試用例, 對程序的邏輯路徑進行測試。基于一個應用代碼的內(nèi)部邏輯知識, 測試是基于覆蓋全部代碼、分支、路徑、條件。

白盒測試的主要方法： ?邏輯驅(qū)動測試 ?基本路徑測試

主要用于軟件驗證。

使用程序設計的控制結構導出測試用例。

邏輯驅(qū)動測試：

主要是測試覆蓋率, 以程序內(nèi)在邏輯結構為基礎的測試。包括以下6種類型：

?語句覆蓋 ?判斷覆蓋 ?條件覆蓋 ?判定-條件覆蓋 ?條件組合覆蓋 ?路徑覆蓋 白盒測試的主要目的

? 保證一個模塊中的所有獨立路徑至少被執(zhí)行一次； ?對所有的邏輯值均需要測試真、假兩個分支； ?在上下邊界及可操作范圍內(nèi)運行所有循環(huán)； ?檢查內(nèi)部數(shù)據(jù)結構以確保其有效性

白盒測試的實施方案

在開發(fā)階段

要保證產(chǎn)品的質(zhì)量, 產(chǎn)品的生產(chǎn)過程應該遵循一定的行業(yè)標準。軟件產(chǎn)品也是同樣, 沒有標準可依自然談不上質(zhì)量的好壞。所有關心軟件開發(fā)質(zhì)量的組織、單位, 都要定義或了解軟件的質(zhì)量標準、模型。其好處是保證公司實踐的均勻性, 產(chǎn)品的可維護性、可靠性以及可移植性等。

在測試階段

與軟件產(chǎn)品的開發(fā)過程一樣, 測試過程也需要有一定的準則, 來指導、度量、評價軟件測試過程的質(zhì)量。

定義測試準則

為控制測試的有效性以及完成程度, 必須定義準則和策略, 以判斷何時結束測試階段。準則必須是客觀的, 可量化的元素, 而不能是經(jīng)驗或感覺。

根據(jù)應用的準則和項目相關的約束, 項目領導可以定義使用的度量方法, 和要達到的覆蓋率。度量測試的有效性、完整性

對每個測試的測試覆蓋信息和累計信息, 用圖形方式顯示覆蓋比率, 并根據(jù)測試運行情況實時更新, 隨時顯示新的測試所反映的測試覆蓋情況。

允許所有的測試運行依據(jù)其有效性進行管理, 用戶可以減 少不適用于非回歸測試的測試的過程。

概念：

1.語句覆蓋：語句覆蓋就是設計若干個測試用例, 運行被測試程序, 使得每一條可執(zhí)行語句至少執(zhí)行一次；

2.判定覆蓋（也稱為分支覆蓋）：設計若干個測試用例, 運行所測程序, 使程序中每個判斷的取真分支和取假分支至少執(zhí)行一次；

3.條件覆蓋：設計足夠多的測試用例, 運行所測程序, 使程序中每個判斷的每個條件的每個可能取值至少執(zhí)行一次；

4.判定-條件覆蓋：設計足夠多的測試用例, 運行所測程序, 使程序中每個判斷的每個條件的所有可能取值至少執(zhí)行一次, 并且每個可能的判斷結果也至少執(zhí)行一次, 換句話說, 即是要求各個判斷的所有可能的條件取值組合至少執(zhí)行一次；

5.條件組合測試：設計足夠多的測試用例, 運行所測程序, 使程序中每個判斷的所有可能的條件取值組合至少執(zhí)行一次；

6.路徑測試：設計足夠多的測試用例, 運行所測程序, 要覆蓋程序中所有可能的路徑。

5.4靜態(tài)測試

是指不實際運行被測軟件, 而只是靜態(tài)的檢查程序代碼、界面或文檔中可能存在的錯誤的過程。

其中包括代碼測試、界面測試和文檔測試3個方面。對于代碼測 14 試, 主要測試代碼是否符合相應的標準和規(guī)范。對于界面測試, 主要測試軟件的實際界面與需求中的說明是否相符。對于文檔測試, 主要測試用戶手冊和需求說明是否符合用戶的實際要求。

5.5動態(tài)測試

是指實際運行被測程序, 輸入相應的測試數(shù)據(jù), 檢查實際輸出結果和預期結果是否相符的過程。所以, 我們判斷一個測試屬于動態(tài)還是靜態(tài)測試 , 唯一的標準就是看是否運行程序。

6軟件測試中的類測試

6.1 面向?qū)ο筌浖暮暧^上來看是各個類之間的相互作用。在面向?qū)ο笙到y(tǒng)中,系統(tǒng)的基本構造模塊是封裝了的數(shù)據(jù)和方法的類和對象,而不再是一個個能完成特定功能的功能模塊。每個對象有自己的生存周期,有自己的狀態(tài)。消息是對象之間相互請求或協(xié)作的途徑,是外界使用對象方法及獲取對象狀態(tài)的唯一方式。對象的功能是在消息的觸發(fā)下,由對象所屬類中定義的方法與相關對象的合作共同完成,且在不同狀態(tài)下對消息的響應可能完全不同。對象中的數(shù)據(jù)和方法是一個有機的整體,測試過程中不能僅僅檢查輸入數(shù)據(jù)產(chǎn)生的輸出結果是否與預期的吻合,還要考慮對象的狀態(tài)。模塊測試的概念已不適用于對象的測試“類測試將是整個測試過程的一個重要步驟。

6.2類測試技術

6.2.1基于服務的類測試技術

基于服務的類測試主要考察封裝在類中的一個方法對數(shù)據(jù)進行的操作，它可以采用傳統(tǒng)的白盒測試方法。為克服軟件測試的盲目性和局限性,保證測試的質(zhì)量,提高軟件的可靠性,下面我們介紹一種類的服務的測試模型及相應的測試策略。

BBD通常有兩種獲取途徑。一是采用逆向工程的方法根據(jù)源程序畫出流程圖,然后構造出BBD。但這畢竟是在缺少軟件開發(fā)前期的分析、設計文檔或文檔不齊全的情況下退而求其次的辦法。當源程序不正確時構造出來的BBD就是錯誤的。另一種途徑就是追根溯源,在軟件的分析、設計階段就根據(jù)測試的需要構造出相應的BBD。這樣就能從根本上解決問題,正確地指導類的服務的測試。

6.2.2基于層次增量的類測試

層次增量測試的基本思想是:首先分別測試父類的各個成員函數(shù),再測試成員函數(shù)間的相互作用,把測試用例和執(zhí)行信息保存在/測試歷史中,在測試子類時,根據(jù)父類的測試歷史修改部分的定義以及實現(xiàn)語言的繼承映射來決定子類中的哪些特征應當重測試以及父類的哪些測試用例可以復用。

這種根據(jù)類間繼承關系的層次特性對類進行增量測試的技術是由M.Harrold等人提出的,其特點是復用父類的測試信息來指導子類的測試。

7參考文獻 參考書籍：

1、Ron Patton 《軟件測試》機械工業(yè)出版社

2、張克東等 《軟件工程與軟件測試自動化教程》電子工業(yè)出版社

3、Dustin,E.《軟件自動化測試：引入、管理與實施》電子工業(yè)出版社

4、James A.Whittaker 《實用軟件測試指南》電子工業(yè)出版社

5、Zadrozny 《J2EE性能測試》電子工業(yè)出版社

6、Jones,C.《軟件評估、基準測試與最佳實踐》機械工業(yè)出版社

7、Edward Kit 《軟件測試過程改進》機械工業(yè)出版社

8、Hung Q.Nguyen 《Web應用測試》電子工業(yè)出版社

9、Robert V.Binder《面向?qū)ο笙到y(tǒng)測試 模型 視圖與工具（影印版）》

10、Rakitin,S.K.《軟件驗證與確認的最佳管理辦法》電子工業(yè)出版社

11、麥格雷戈 《面向?qū)ο蟮能浖y試》機械工業(yè)出版社

8致謝 非常感謝陳林華老師在我大學的最后學習階段——畢業(yè)設計階段給自己的指導，從最初的定題，到資料收集，到寫作、修改，到論文定稿，她們給了我耐心的指導和無私的幫助。為了指導我們的畢業(yè)論文，她們放棄了自己的休息時間，她們的這種無私奉獻的敬業(yè)精神令人欽佩，在此我向她們表示我誠摯的謝意。同時，感謝所有任課老師和所有同學在這四年來給自己的指導和幫助，是他們教會了我專業(yè)知識，教會了我如何學習，教會了我如何做人。正是由于他們，我才能在各方面取得顯著的進步，在此向他們表示我由衷的謝意，并祝所有的老師培養(yǎng)出越來越多的優(yōu)秀人才，桃李滿天下！

通過這一階段的努力，我的畢業(yè)論文《 軟件測試的概述及方法 》終于完成了，這意味著大學生活即將結束。在大學階段，我在學習上和思想上都受益非淺，這除了自身的努力外，與各位老師、同學和朋友的關心、支持和鼓勵是分不開的。

寫作畢業(yè)論文是一次再系統(tǒng)學習的過程，畢業(yè)論文的完成，同樣也意味著新的學習生活的開始。

感謝各位專家的批評指導。

讀書的好處

1、行萬里路，讀萬卷書。

2、書山有路勤為徑，學海無涯苦作舟。

3、讀書破萬卷，下筆如有神。

4、我所學到的任何有價值的知識都是由自學中得來的。——達爾文

5、少壯不努力，老大徒悲傷。

6、黑發(fā)不知勤學早，白首方悔讀書遲。——顏真卿

7、寶劍鋒從磨礪出，梅花香自苦寒來。

8、讀書要三到：心到、眼到、口到

9、玉不琢、不成器，人不學、不知義。

10、一日無書，百事荒廢。——陳壽

11、書是人類進步的階梯。

12、一日不讀口生，一日不寫手生。

13、我撲在書上，就像饑餓的人撲在面包上。——高爾基

14、書到用時方恨少、事非經(jīng)過不知難。——陸游

15、讀一本好書，就如同和一個高尚的人在交談——歌德

16、讀一切好書，就是和許多高尚的人談話。——笛卡兒

17、學習永遠不晚。——高爾基

18、少而好學，如日出之陽；壯而好學，如日中之光；志而好學，如炳燭之光。——劉向

19、學而不思則惘，思而不學則殆。——孔子

20、讀書給人以快樂、給人以光彩、給人以才干。——培根

第二篇：軟件測試課題解讀

XX學院

××屆××學院畢業(yè)設計

軟件測試課題

2012-03-13

目 錄

第一章 畢業(yè)設計目的..............................................................................................................3 第二章 畢業(yè)設計安排..............................................................................................................3 第三章 指導老師簡介..............................................................................................................3 第四章 畢業(yè)設計選題..............................................................................................................4

4.1“如何寫一個好的測試計劃？” 或 “XXX項目測試計劃”.....................................4 4.2“如何做好功能測試？” 或 “XXX項目功能測試實踐”.....................................4 4.3“如何做好自動化測試？” 或 “XXX項目自動化測試實踐”.............................5 4.4“如何做好性能測試？” 或 “XXX項目性能測試實踐”.....................................5 4.5如何測試一個電梯/紙杯？..........................................................................................5 4.6怎樣才能做好本地化測試？.......................................................................................5 4.7 學生自己想做的測試相關的其他選題（需要與指導老師確認）..........................6 第五章 總結..............................................................................................................................6

ii

第一章 畢業(yè)設計目的

? 培養(yǎng)學生運用所學基礎理論、基本知識和基本技能進行分析與解決實際問題的能力； ? 培養(yǎng)學生嚴謹認真的態(tài)度、理論聯(lián)系實際的動手能力；

? 通過完成具有一定實際或理論意義的軟件測試項目，使學生受到基本的軟件測試訓練，鞏固與擴展所學的基礎理論和專業(yè)知識，為就業(yè)鋪路搭橋；

? 培養(yǎng)學生分析設計、實際測試和計算機應用的能力，以及進行解決問題和文字表達等基本技能；

? 培養(yǎng)學生的創(chuàng)新意識和創(chuàng)新能力；

? 為學生面試與就業(yè)提供指導，幫助學生盡快就業(yè)，找到如意工作。

第二章 畢業(yè)設計安排

? 開始時間：2012年3月底 ? 結束時間：2012年5月上旬 ? 畢業(yè)論文完成時間：2012年5月上旬

說明：根據(jù)實際情況可能會有所調(diào)整。

第三章 指導老師簡介

XX老師，北航軟件工程碩士，PMP(項目管理專業(yè)認證)，信息系統(tǒng)項目管理師（高級職稱資格認證）。11年IT工作經(jīng)驗，精通軟件測試理論、測試工具、測試流程、測試架構設計及測試管理。軟件測試理論嫻熟，實戰(zhàn)經(jīng)驗豐富，對數(shù)據(jù)庫和UNIX/Linux有 3

致謝

很深的功底，帶過多次畢業(yè)設計。其中參與過黑龍江移動公司《新版BOSS系統(tǒng)》的開發(fā)和測試工作，明天集團的《工商項目檔案管理系統(tǒng)》的開發(fā)和測試工作，網(wǎng)絡版的《電力系統(tǒng)安全性評價專家系統(tǒng)》的開發(fā)和測試工作，中國石油集團下屬《中國石油石化企業(yè)網(wǎng)絡信息庫》、《世界石油大會中國國家委員會網(wǎng)站》、《中油香港網(wǎng)站》、《中國石油商務網(wǎng)》《中國石油集團外部網(wǎng)站》的開發(fā)設計和驗收工作，現(xiàn)在某外企公司任軟件測試項目經(jīng)理，負責軟件測試項目的管理和執(zhí)行，團隊總人數(shù)達20余人。

聯(lián)系方式：

第四章 畢業(yè)設計選題

4.1“如何寫一個好的測試計劃？” 或 “XXX項目測試計劃”

? 測試的發(fā)展及相關理論 ? 項目相關理論 ? 測試管理

? 測試計劃的重要性 ? 測試計劃的基本要素 ? 測試計劃實例

4.2“如何做好功能測試？” 或 “XXX項目功能測試實踐”

? 測試的發(fā)展及相關理論 ? 功能測試理論 ? 項目相關理論 ? 測試需求 ? 測試流程 ? 測試用例 ? 測試工具

4.3“如何做好自動化測試？” 或 “XXX項目自動化測試實踐”

? 測試的發(fā)展及相關理論 ? 自動化測試理論 ? 項目相關理論 ? 測試需求 ? 測試流程 ? 測試用例 ? 測試工具

4.4“如何做好性能測試？” 或? 測試的發(fā)展及相關理論 ? 性能測試理論 ? 項目相關理論 ? 測試需求 ? 測試流程 ? 測試用例 ? 測試工具

4.5如何測試一個電梯/紙杯？

? 測試的發(fā)展及相關理論 ? 項目相關理論 ? 測試用例

4.6怎樣才能做好本地化測試？

? 測試的發(fā)展及相關理論 ? 深入理解本地化測試 ? 如何做好本地化測試

XXX項目性能測試實踐”

“ 致謝

4.7 學生自己想做的測試相關的其他選題（需要與指導老師確認）

第五章 總結

畢業(yè)設計(論文)是學生畢業(yè)前的最后一個重要學習環(huán)節(jié)，是學習深化與升華的重要過程。它既是學生學習、研究與實踐成果的全面總結，又是對學生素質(zhì)與能力的一次全面檢驗，還是對學生的畢業(yè)資格認證的重要依據(jù)。為了保證我院畢業(yè)設計質(zhì)量，讓同學們能夠圓滿完成這次畢業(yè)論文設計，我愿意和同學們一起努力，共同奮斗！

讀書的好處

1、行萬里路，讀萬卷書。

2、書山有路勤為徑，學海無涯苦作舟。

3、讀書破萬卷，下筆如有神。

4、我所學到的任何有價值的知識都是由自學中得來的。——達爾文

5、少壯不努力，老大徒悲傷。

6、黑發(fā)不知勤學早，白首方悔讀書遲。——顏真卿

7、寶劍鋒從磨礪出，梅花香自苦寒來。

8、讀書要三到：心到、眼到、口到

9、玉不琢、不成器，人不學、不知義。

10、一日無書，百事荒廢。——陳壽

11、書是人類進步的階梯。

12、一日不讀口生，一日不寫手生。

13、我撲在書上，就像饑餓的人撲在面包上。——高爾基

14、書到用時方恨少、事非經(jīng)過不知難。——陸游

15、讀一本好書，就如同和一個高尚的人在交談——歌德

16、讀一切好書，就是和許多高尚的人談話。——笛卡兒

17、學習永遠不晚。——高爾基

18、少而好學，如日出之陽；壯而好學，如日中之光；志而好學，如炳燭之光。——劉向

19、學而不思則惘，思而不學則殆。——孔子

20、讀書給人以快樂、給人以光彩、給人以才干。——培根

第三篇：軟件測試筆試題3解讀

一、測試基礎題

1、Linux的超級用戶是root

2、Linux系統(tǒng)中，查看文件的命令是什么？寫出至少三個：cat、less、more

3、Linux系統(tǒng)中，對文件httpd.conf賦予755權限指的是什么意思？如何操作？ 賦予http.conf 文件 擁有者 讀、寫、執(zhí)行；擁有組 讀、執(zhí)行； 其他人 讀；執(zhí)行 chmod 755 http.conf

4、Linux系統(tǒng)中，vi編輯，以下操作的命令是？插入、刪除單個字符、刪除一整行、到文件開頭和結尾、另存為等 插入 i 刪除單個字符 x 刪除一整行

dd 到文件開頭 gg 結尾 G 另存為 :qw

5、數(shù)據(jù)庫題（1）員工信息表

create table employ(employID number primary key--員工ID ,ename varchar2(50)--名稱 ,sex varchar2(50)--性別 ,age number--年齡 ,deptid number--部門ID ,stationid number--崗位ID);(2)員工薪水

create table salary(salaryid number--薪水ID ,employid number--員工ID ,basesalary number--基本薪水 ,bonussalary number--獎金);

1）統(tǒng)計各部門的平均薪水

select max(em.deptid), round(avg(sa.basesalary+sa.bonussalary),1)from employ em ,salary sa where em.employid=sa.employid group by em.deptid

2）查詢所有部門的最高薪水，最低水，平均薪水，顯示部門，最高薪水，最低薪水，平均薪水,并按部門名升序排序;select max(em.deptid)“部門名”, min(sa.basesalary+sa.bonussalary)“最低薪水”, round(avg(sa.basesalary+sa.bonussalary),1)“平均薪水” from employ em ,salary sa where em.employid=sa.employid group by em.deptid order by em.deptid

3）查詢所有姓王的所有員工信息;select em.employID “員工ID”, em.ename “名稱”, em.sex “性別”, em.age “年齡”, em.deptid “部門ID”, em.stationid “崗位ID”, sa.salaryid “薪水ID”, sa.basesalary “基本薪水”, sa.bonussalary “獎金” from employ em ,salary sa where em.employid=sa.employid and ename like '王%'

二、測試理論知識

1、軟件測試的目的是什么？軟件測試有哪幾大特性？

目的：沒發(fā)現(xiàn)軟件缺陷與錯誤，對軟件質(zhì)量進行度量和評估，以提高軟件的 質(zhì)量，節(jié)約成本，滿足客戶需求。

特性：應追溯到用戶需求；盡早地和不斷地進行軟件測試；完全測試是不可能的，測試需要終止；測試無法顯示軟件潛在的缺陷；充分注意測試中的群集現(xiàn)象；開發(fā)人員不能即是運動員又是裁判員；避免測試的隨意性

2、軟件測試有哪幾種類型？它們的關注點分別是什么？ 按階段劃分

對不同的階段用不同的方法進行測試

a單元測試（unit testing），是指對軟件中的最小可測試單元進行檢查和驗證

b集成測試在單元測試的基礎上，將所有模塊按照設計要求（如根據(jù)結構圖〕組裝成為子系統(tǒng)或系統(tǒng)，進行集成測試

c確認測試經(jīng)集成測試后，已經(jīng)按照設計把所有的模塊組裝成一個完整的軟件系統(tǒng)，接口錯誤也已經(jīng)基本排除了，接著就應該進一步驗證軟件的有效性，這就是確認測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。

c系統(tǒng)測試目的是驗證系統(tǒng)是否滿足了需求規(guī)格的定義，找出與需求規(guī)格不符或與之矛盾的地方，從而提出更加完善的方案。系統(tǒng)測試的對象不僅僅包括需測試的軟件，還要包含軟件所依賴的硬件、外設甚至包括某些數(shù)據(jù)、某些支持軟件及其接口等。d驗收測試主要確認軟件是否按合同要求進行工作，既是否滿足軟件需求規(guī)格說明書中的要求。

按是否運行程序劃分

靜態(tài)測試不運行被測試的軟件，而只是靜態(tài)的檢查代碼、界面或者文檔。動態(tài)測試實際運行被測試的軟件，輸入相應的測試數(shù)據(jù)，檢查世界的輸出結果是否和預期結果相一致的過程。按是否查看代碼劃分 黑盒測試

把軟件看成一個黑盒子，不管內(nèi)部邏輯和內(nèi)部特性，只依據(jù)規(guī)格說明書檢查程序的功能是否符合功能說明又稱為功能測試或數(shù)據(jù)驅(qū)動測試 白盒測試

又稱為結構測試或邏輯驅(qū)動測試。著重于程序內(nèi)部結構和算法，不關心功能和性能指標。灰盒測試

介于白盒和黑盒測試之間，基于程序運行時刻的外部表現(xiàn)同時又結合程序內(nèi)部邏輯結構來設計用例，執(zhí)行程序并采集程序路徑執(zhí)行信息和外部用戶接口結果的測試技術。其他劃分 回歸測試

對軟件的新版本測試時，重復執(zhí)行上一個版本測試時使用的測試用例。防止出現(xiàn)“以前應用沒有的問題現(xiàn)在出問題了”。

冒煙測試（BVT測試（Build Verification Test））

冒煙測試的對象是每一個新編譯需要正式測試的版本，目的是確認軟件基本功能正常，可以進行后續(xù)的正式測試工作。隨機測試（又名猴子測試）

測試數(shù)據(jù)是隨機產(chǎn)生的，在測試用例之外。只能作為一個測試的補充。

3、通常來說，一個case需要包含哪幾部分？bug呢？

Case 用例編號 用例名稱 功能接口、預置條件 用例優(yōu)先級 操作步驟 預期結果 Bug bug編號 bug名稱

bug優(yōu)先級

操作環(huán)境 操作步驟

預期步驟 實際結果

三、自動化及項目測試知識

1、在自動化測試中，參數(shù)化的目的是什么？檢查點呢？

2、LR中場景分為哪幾種，分別是什么？性能測試指標包含哪些（盡可能多的列舉）？

四、綜合知識

1、您認為作為一名軟件測試工程師，應該具備哪些素質(zhì)？ 計算機相關知識，能夠熟練使用常用的管理工具 開發(fā)語言：C,C++,Java,JavaScript,VBScript,Shell。數(shù)據(jù)庫：SQL Server,Oracle,MySQL等數(shù)據(jù)庫知識

操作系統(tǒng),如Windows 2003以及2008,UNIX,Linux,MAC,Solaris等 網(wǎng)絡基本知識，能夠獨立完成測試環(huán)境的搭建。

軟件基礎知識：軟件工程,軟件生命周期,測試理論和測試方式有較深的理解。

軟件測試技術,方法,流程,測試文檔編寫,能獨立設計和執(zhí)行測試用例, 提交完整的缺陷報告單, 編寫測試報告。

測試工具，能夠熟練使用至少一種功能/性能自動化測試工具。質(zhì)量管理知識，如CMM,CMMI以及ISO 9001等。

2、就ATM取款機的取款功能，請寫出測試點。

用場景法測試ATM機 基本流 插入銀行卡 驗證銀行卡 輸入密碼 驗證密碼

進入ATM主界面 取款并選擇金額 ATM機驗證

更新賬戶余額出鈔 返回主界面 備選流 銀行卡無效 密碼錯誤

密碼三次錯誤吞卡 賬戶余額不提示退卡

總取款金額超過當日取款限額 ATM機余額不足 場景一 取款成功 預備條件

ATM余額10000 有效銀行卡***8843 密碼213213 卡內(nèi)余額8000 操作步驟

插入銀行卡，輸入正確的密碼213213 進入主頁后選擇取款1000元 預期結果

ATM機輸出1000元，提示用戶取走現(xiàn)金并返回主頁面 ATM機余額9000 用戶賬戶余額7000 場景二 卡無效 預置條件

ATM余額10000 一張無效銀行卡 操作步驟

插入無效銀行卡 預期結果

提示該卡無效并退卡。

場景三 密碼錯誤且輸入三次錯誤密碼，ATM機吞卡 預置條件

ATM余額10000 有效銀行卡***8843 密碼213213 卡內(nèi)余額8000 操作步驟

插入銀行卡，輸入錯誤密碼321321 預期結果

提示密碼錯誤，并清空密碼 再次輸入錯誤密碼321321 預期結果

提示密碼錯誤，并清空密碼 再次輸入錯誤密碼321321 預期結果

提示密碼錯誤，并沒收該卡。場景四賬戶余額不足 ATM余額10000 有效銀行卡***8843 密碼213213 卡內(nèi)余額8000 操作步驟

插入銀行卡，輸入正確的密碼213213 進入主頁后選擇取款9000元 預期結果

提示賬戶余額不足，并退卡 場景五取款金額超過當日限額 預備條件 ATM余額100000（單筆取款最大金額為2000最大取款金額為20000）有效銀行卡***8843 密碼213213 卡內(nèi)余額80000 操作步驟

插入銀行卡，輸入正確的密碼213213 進入主頁后選擇取款2000元 預期結果

ATM機輸出2000元，提示用戶取走現(xiàn)金并返回主頁面 ATM機余額98000 用戶賬戶余額78000 累計取款20000 預期結果

ATM機余額80000 用戶賬戶余額60000 再次取走2000元 預期結果

提示已達當日取款最大限額，并退卡。場景六 ATM余額不足 預備條件 ATM余額800 有效銀行卡***8843 密碼213213 卡內(nèi)余額8000 操作步驟

插入銀行卡，輸入正確的密碼213213 進入主頁后選擇取款1000元 預期結果

提示ATM機余額不足，并退卡。

讀書的好處

1、行萬里路，讀萬卷書。

2、書山有路勤為徑，學海無涯苦作舟。

3、讀書破萬卷，下筆如有神。

4、我所學到的任何有價值的知識都是由自學中得來的。——達爾文

5、少壯不努力，老大徒悲傷。

6、黑發(fā)不知勤學早，白首方悔讀書遲。——顏真卿

7、寶劍鋒從磨礪出，梅花香自苦寒來。

8、讀書要三到：心到、眼到、口到

9、玉不琢、不成器，人不學、不知義。

10、一日無書，百事荒廢。——陳壽

11、書是人類進步的階梯。

12、一日不讀口生，一日不寫手生。

13、我撲在書上，就像饑餓的人撲在面包上。——高爾基

14、書到用時方恨少、事非經(jīng)過不知難。——陸游

15、讀一本好書，就如同和一個高尚的人在交談——歌德

16、讀一切好書，就是和許多高尚的人談話。——笛卡兒

17、學習永遠不晚。——高爾基

18、少而好學，如日出之陽；壯而好學，如日中之光；志而好學，如炳燭之光。——劉向

19、學而不思則惘，思而不學則殆。——孔子

20、讀書給人以快樂、給人以光彩、給人以才干。——培根

第四篇：軟件測試（推薦）

一、簡答5*6’

1.為什么不讓時間有余的人做測試工作

表面上看這體現(xiàn)了管理的效率和靈活性，但實際上也體現(xiàn)了管理者對測試的輕視。測試和測試的人有很大關系。測試工作人員應該是勤奮并富有耐心，善于學習、思考和發(fā)現(xiàn)問題，細心有條理，總結問題，如果具備這樣的優(yōu)點，做其它工作同樣也會很出色，因此這里還有一個要求，就是要喜歡測試這項工作。2.軟件測試風險主要體現(xiàn)在哪里

我們沒有對軟件進行完全測試，實際就是選擇了風險，因為缺陷極有可能存在沒有進行測試的部分。因此，我們要盡可能的選擇最合適的測試量，把風險降低到最小 3.所有軟件測試缺陷都需要修復嗎

從技術上講，所有的軟件缺陷都是能夠修復的，但是沒有必要修復所有的軟件缺陷。測試人員要做的是能夠正確判斷什么時候不能追求軟件的完美。對于整個項目團隊，要做的是對每一個軟件缺陷進行取舍，根據(jù)風險決定那些缺陷要修復。發(fā)生這種現(xiàn)象的主要原因如下：-沒有足夠的時間資源。在任何一個項目中，通常情況下開發(fā)人員和測試人員都是不夠用的，而且在項目中沒有預算足夠的回歸測試時間，修改缺陷可能引入新的缺陷。

-有些缺陷只是特殊情況下出現(xiàn)，這種缺陷處于商業(yè)利益考慮，可以在以后升級中進行修復。-不是缺陷的缺陷。我們經(jīng)常會碰到某些功能方面的問題被當成缺陷來處理，這類問題可以以后有時間時考慮再處理。缺陷是否修改要由軟件測試人員、項目經(jīng)理、程序員共同討論來決定是否修復，不同角色的人員從不同的角度來思考，以做出正確的決定。4.如何減少測試人員跳槽帶來的損失 建議我們從以下兩個方面做起：

-加強部門內(nèi)員工之間的互相學習，互相學習是建立學習型組織的基本要求，是知識互相轉移的過程。在此基礎上，可以把個人擁有的技術以知識的形式沉積下來，也就完成了隱性知識到顯性知識的轉化。

-管理者就應該把員工的個人成長和企業(yè)的發(fā)展聯(lián)系起來，為員工設定合理發(fā)展規(guī)劃并付諸實現(xiàn)。

5.驗收測試的注意點有哪些 測試要注意下面的事項：

（1）用戶現(xiàn)場測試不可能測試全部功能，因此要測試核心功能。這需要提前做好準備，這些核心功能一定要預先經(jīng)過測試，證明沒有問題才可以和用戶共同進行測試。測試核心模塊的目的是建立用戶對軟件的信心。當然如果這些模塊如果問題較多，不應該進行演示。（2）如果某些模塊確實有問題，我們可以演示其它重要的業(yè)務功能模塊，必要時要向用戶做成合理的解釋。爭得時間后，及時修改缺陷來彌補。（3）永遠不能欺騙用戶，蒙混過關。6.完全測試程序是可能的嗎

實際上完全測試是不可能的。主要有以下原因：-完全測試比較耗時，時間上不允許；

-完全測試通常意味著較多資源投入，這在現(xiàn)實中往往是行不通的；-輸入量太大，不能一一進行測試；-輸出結果太多，只能分類進行驗證；-軟件實現(xiàn)途徑太多；

-軟件產(chǎn)品說明書沒有客觀標準，從不同的角度看，軟件缺陷的標準不同；因此測試的程度要根據(jù)實際情況確定 7.是不是發(fā)現(xiàn)的缺陷越多就說明軟件缺陷越多 其中的原因主要如下：

-代碼復用、拷貝代碼導致程序員容易犯相同的錯誤。類的繼承導致所有的子類會包含基類的錯誤，反復拷貝同一代碼意味可能也復制了缺陷。-程序員比較勞累是可以導致某些連續(xù)編寫的功能缺陷較多。

“缺陷一個連著一個”不是一個客觀規(guī)律，只是一個常見的現(xiàn)象。如果軟件編寫的比較好，這種現(xiàn)象就不常見了。測試人員只要嚴肅認真的測試程序就可以了。8.軟件測試就是QA嗎

軟件測試人員的職責是盡可能早的找出軟件缺陷，確保得以修復。而質(zhì)量保證人員（QA）主要職責是創(chuàng)建或者制定標準和方法，提高促進軟件開發(fā)能力和減少軟件缺陷。測試人員的主要工作是測試，質(zhì)量保證人員日常工作重要內(nèi)容是檢查與評審，測試工作也是測試保證人員的工作對象。軟件測試和質(zhì)量是相輔相成的關系，都是為了提高軟件質(zhì)量而工作。9.測試產(chǎn)品和測試項目區(qū)別

習慣上把開發(fā)完成后進行商業(yè)化、幾乎不進行代碼修改就可以售給用戶使用的軟件成為軟件產(chǎn)品，也就是可以買“賣拷貝”的軟件，軟件項目是一種個性化的產(chǎn)品，可以是按照用戶要求全部重新開發(fā)，也可以修改已有的軟件產(chǎn)品來滿足特定的用戶需求。項目和產(chǎn)品的不同特點，決定我們測試產(chǎn)品和測試項目仍然會有很多不同的地方：

-質(zhì)量要求不同。通常產(chǎn)品的質(zhì)量要高一些，修復發(fā)布后產(chǎn)品的缺陷成本較高，甚至會帶來很多負面的影響。而做項目通常面向某一用戶，雖然質(zhì)量越高越好，但是一般只要滿足用戶要求就可以了。測試資源投入多少不同。做軟件產(chǎn)品通常是研發(fā)中心來開發(fā)，進度壓力要小些。同時由于質(zhì)量要求高，因此會投入較多的人力、物力資源。項目最后要和用戶共同驗收測試，這是產(chǎn)品測試不具有的特點。此外，測試產(chǎn)品與測試項目在缺陷管理方面、測試策略制定都會有很大不同，測試管理者應該結合具體的環(huán)境，恰如其分的完成工作 10.如何編寫提交給用戶的測試報告

測試報告一般分為內(nèi)部測試報告和外部測試報告。內(nèi)部報告是我們在測試工作中的項目文檔，反映了測試工作的實施情況,一般外部測試報告要滿足下面幾個要求：

根據(jù)內(nèi)部測試報告進行編寫，一般可以摘錄；不可以向客戶報告嚴重缺陷，即使是已經(jīng)修改的缺陷，開發(fā)中的缺陷也沒有必要讓客戶知道；報告上可以列出一些缺陷，但必須是中級的缺陷，而且這些缺陷必須是修復的；報告上面的內(nèi)容盡量要真實可靠；整個測試報告要仔細審閱，力爭不給項目帶來負面作用，尤其是性能測試報告。總之，外部測試報告要小心謹慎的編寫。

二、論述2*12’

1.請論述為什么要進行軟件測試，并列舉歷史上2~3個著名軟件測試（缺陷）案例，說明測試重要性

軟件測試的目的,第一是確認軟件的質(zhì)量，其一方面是確認軟件做了你所期望做的事情（，另一方面是確認軟件以正確的方式來做了這個事情。第二是提供信息，比如提供給開發(fā)人員或程序經(jīng)理的回饋信息，為風險評估所準備的信息。第三軟件測試不僅是在測試軟件軟件產(chǎn)品本身，而且還包括軟件開發(fā)的過程。如果一個軟件產(chǎn)品開發(fā)完成之后發(fā)現(xiàn)了很多問題，這說明此軟件開發(fā)過程很可能是有缺陷的。因此，軟件測試的第三個目的是保證整個軟件開發(fā)過程是高質(zhì)量的。

愛國者導彈防御系統(tǒng)把“槍口”對準了自己人 美國迪斯尼公司的獅子王游戲軟件的兼容性問題 售票系統(tǒng)性能問題

2.論述軟件測試科學的發(fā)展歷程 1957年之前－調(diào)試為主 20世紀50年代，計算機剛誕生不久，只有科學家級別的人才會去編程，需求和程序本身也遠遠沒有現(xiàn)在這么復雜多變，相當于開發(fā)人員一人承擔需求分析，設計，開發(fā)，測試等所有工作，當然也不會有人去區(qū)分調(diào)試和測試。

1957–1978－證明為主 當時計算機應用的數(shù)量，成本和復雜性都大幅度提升，隨之而來的經(jīng)濟風險也大大增加，測試就顯得很有必要了，這個時期測試的主要目就是確認軟件是滿足需求的，也就是我們常說的“做了該做的事情”。

1979–1982－破壞為主 我們不僅要證明軟件做了該做的事情，也要保證它沒做不該做的事情，這會使測試更加全面，更容易發(fā)現(xiàn)問題。

1983–1987－評估為主 人們提出了在軟件生命周期中使用分析，評審，測試來評估產(chǎn)品的理論。軟件測試工程在這個時期得到了快速的發(fā)展.1988–至今－預防為主 預防為主是當下軟件測試的主流思想之一。測試不是在編碼完成后才開始介入，而是貫穿于整個軟件生命周期。3.論述軟件缺陷的由來

軟件缺陷的產(chǎn)生主要是由軟件產(chǎn)品的特點和開發(fā)過程決定的。

軟件本身：①需求不清晰，導致設計目標偏離客戶的需求，從而引起功能或產(chǎn)品特征上的缺陷。②系統(tǒng)結構非常復雜，而又無法設計成一個很好的層次結構或組件結構，結果導致意想不到的問題或系統(tǒng)維護、擴充上的困難；即使設計成良好的面向?qū)ο蟮南到y(tǒng)，由于對象、類太多，很難完成對各種對象、類相互作用的組合測試，而隱藏著一些參數(shù)傳遞、方法調(diào)用、對象狀態(tài)變化等方面問題。③對程序邏輯路徑或數(shù)據(jù)范圍的邊界考慮不夠周全，漏掉某些邊界條件，造成容量或邊界錯誤。④對一些實時應用，要進行精心設計和技術處理，保證精確的時間同步，否則容易引起時間上不協(xié)調(diào)，不一致性帶來的問題。⑤沒有考慮系統(tǒng)崩潰后的自我恢復或數(shù)據(jù)的異地備份、災難性恢復等問題，從而存在系統(tǒng)安全性、可靠性的隱患。⑥系統(tǒng)運行環(huán)境的復雜，不僅用戶使用的計算機環(huán)境千變?nèi)f化，包括用戶的各種操作方式或各種不同的輸入數(shù)據(jù)，容易引起一些特定用戶環(huán)境下的問題；在系統(tǒng)實際應用中，數(shù)據(jù)量很大。從而會引起強度或負載問題。⑦由于通信端口多、存取和加密手段的矛盾性等，會造成系統(tǒng)的安全性或適用性等問題。⑧新技術的采用，可能涉及技術或系統(tǒng)兼容的問題，事先沒有考慮到。

團隊工作：系統(tǒng)需求分析時對客戶的需求理解不清楚，或者和用戶的溝通存在一些困難。不同階段的開發(fā)人員相互理解不一致。對于設計或編程上的一些假定或依賴性，相關人員沒有充分溝通。項目組成員技術水平參差不齊技術問題。算法錯誤：在給定條件下沒能給出正確或準確的結果。語法錯誤：對于編譯性語言程序，編譯器可以發(fā)現(xiàn)這類問題；但對于解釋性語言程序，只能在測試運行時發(fā)現(xiàn)。計算和精度問題：計算的結果沒有滿足所需要的精度。系統(tǒng)結構不合理、算法選擇不科學，造成系統(tǒng)性能低下。接口參數(shù)傳遞不匹配，導致模塊集成出現(xiàn)問題。

項目管理的問題：缺乏質(zhì)量文化，不重視質(zhì)量計劃，對質(zhì)量、資源、任務、成本等的平衡性把握不好，容易擠掉需求分析、評審、測試、等時間，遺留的缺陷會比較多。系統(tǒng)分析時對客戶的需求不是十分清楚，或者和用戶的溝通存在一些困難。開發(fā)周期短，需求分析、設計、編程、測試等各項工作不能完全按照定義好的流程來進行，工作不夠充分，結果也就不完整、不準確，錯誤較多；周期短，還給各類開發(fā)人員造成太大的壓力，引起一些人為的錯誤。開發(fā)流程不夠完善，存在太多的隨機性和缺乏嚴謹?shù)膬?nèi)審或評審機制，容易產(chǎn)生問題。文檔不完善，風險估計不足等。4.軟件測試V模型

①繪制示意圖

②闡述每個步驟是做什么 需求分析

即首先要明確客戶需要的是什么，需要軟件作成什么樣子，需要有那幾項功能

概要設計

主要是架構的實現(xiàn)，指搭建架構、表述各模塊功能、模塊接口連接和數(shù)據(jù)傳遞的實現(xiàn)等項事務。詳細設計

對概要設計中表述的各模塊進行深入分析，對各模塊組合進行分析等。軟件編碼

按照詳細設計好的模塊功能表，編程人員編寫出實際的代碼。單元測試

按照設定好的最小測試單元進行按單元測試，主要是測試程序代碼，為的是確保各單元模塊被正確的編譯，單元的具體劃分按不同的單位與不同的軟件有不同。集成測試

經(jīng)過了單元測試后，將各單元組合成完整的體系，主要測試各模塊間組合后的功能實現(xiàn)情況，以及模塊接口連接的成功與否，數(shù)據(jù)傳遞的正確性等，其主要目的是檢查軟件單位之間的接口是否正確。根據(jù)集成測試計劃，一邊將模塊或其他軟件單位組合成系統(tǒng)，一邊運行該系統(tǒng)，以分析所組成的系統(tǒng)是否正確，各組成部分是否合拍。系統(tǒng)測試

經(jīng)過了單元測試和集成測試以后，我們要把軟件系統(tǒng)搭建起來，按照軟件規(guī)格說明書中所要求，測試軟件其性能功能等是否和用戶需求相符合，在系統(tǒng)中運行是否存在漏洞，等。驗收測試

主要就是用戶在拿到軟件的時候，在使用現(xiàn)場，會根據(jù)前邊所提到的需求，以及規(guī)格說明書來做相應測試，以確定軟件達到符合效果的。

第五篇：軟件測試復習資料

1． 黑盒測試法是通過分析程序的功能來設計測試用例的方法。

2． 黑盒測試除了測試程序外，它還適用于對需求分析階段的軟件文檔進行測試。3． 白盒測試除了測試程序外，它也適用于對軟件具體設計階段的軟件文檔進行測試。4． 單元測試一般以白盒測試法為主，測試的依據(jù)是模塊功能規(guī)格說明。5． 軟件測試中常用的靜態(tài)分析方法是引用分析和接口分析。

6． 測試人員的基本素質(zhì)為計算機專業(yè)技能、測試專業(yè)技能、行業(yè)知識

7． 軟件危機的體現(xiàn)為：A、開發(fā)成本和進度估計不正確B、用戶對完成的軟件不滿足C、軟件經(jīng)常不可維護；

8． 軟件測試按照開發(fā)階段劃分：A、單元測試

B、集成測試；系統(tǒng)測試C、確認測試；驗收測試

9． 軟件測試按照測試技術劃分：A、性能測試、負載測試、壓力測試B、恢復測試、安全測試、兼容測試

10． 軟件測試項目周期是指：A、需求階段、測試計劃B、階段測試、設計階段測試、執(zhí)行階段 11． 軟件測試原則有：A、制定嚴格的測試計劃 B、保留所有的測試文檔C、功能測試中的缺陷確認 12． 制定測試計劃的步驟：確定測試范圍、確定測試策略、確定測試標準、確定測試構架、確定項目管理機制、預計測試工作量、測試計劃評審 13． 對于軟件的β測試，β測試就是在軟件公司外部展開的測試，由非專業(yè)的測試人員執(zhí)行的測試。14． 正式的技術評審FTR（Formal Technical Review）是軟件質(zhì)量保證活動，其相關的描述為： A.FTR是評審產(chǎn)品而不是評審生產(chǎn)者的能力B.FTR要有嚴格的評審計劃并遵守日程安排C.FTR限制參與者人數(shù)并要求評審會之前做好預備 15． 在進行單元測試時，常用的方法是采用白盒測試，輔之以黑盒測試

16． 側重于觀察資源耗盡情況下的軟件表現(xiàn)的系統(tǒng)測試被稱為壓力測試 17． 必須要求用戶參與的測試階段是驗收測試 18． 系統(tǒng)測試的目的是對最終軟件系統(tǒng)進行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設計。

19． 測試通常可分為白盒測試和黑盒測試。白盒測試是根據(jù)程序的內(nèi)部邏輯來設計測試用例,黑盒測試是根據(jù)軟件的規(guī)格說明來設計測試用例。20． 一個程序中所含有的路徑數(shù)與程序的復雜程度有著直接的關系。

1． 測試階段的根本目標是盡可能多地發(fā)現(xiàn)并排除軟件中潛藏的錯誤，最終把一個高質(zhì)量的軟件系統(tǒng)交給用戶使用。2． 功能測試時系統(tǒng)測試的主要內(nèi)容，檢查系統(tǒng)的功能、性能是否與需求規(guī)格說明相同。3． 軟件測試主要分為單元測試、集成測試、確認測試和系統(tǒng)測試四類測試。4． 漸增方式把模塊結合到程序中去時，有自頂向下和自底向上兩種集成策略。5． 編寫測試用例的依據(jù)是單元測試計劃和詳細設計說明書。6． 系統(tǒng)測試時在集成測試完成后，確認測試之前進行的測試。

7． 設計系統(tǒng)測試計劃需要參考的項目文檔有軟件測試計劃、軟件需求工件、和迭代計劃。

8． 測試設計員的職責有設計測試用例、設計測試過程、腳本。

9． 軟件驗收測試包括正式驗收測試、alpha測試、beta測試三種類型。10． 軟件測試按照開發(fā)階段劃分單元測試、集成測試、系統(tǒng)測試、確認測試、驗收測試。11． 軟件測試按照測試技術劃分性能測試、負載測試、壓力測試、恢復測試、安全測試、兼容測試

12． 靜態(tài)測試基本特征是在對軟件進行分析、檢查和審閱，不實際運行被測試的軟件 13． 軟件測試項目周期是指需求階段、測試計劃、階段測試、設計階段測試、執(zhí)行階段 14． 軟件測試的角色分析人員、設計人員、開發(fā)人員、執(zhí)行人員 15． 軟件測試原則有制定嚴格的測試計劃、、保留所有的測試文檔、功能測試中的缺陷確認

16． 測試工作的文檔主要有：測試計劃、測試模型和用例設計或規(guī)格說明、測試分析報告等

17． 測試計劃的制定必須要注重測試策略、測試范圍、測試方法、測試安排、測試風險、測試治理

18． 缺陷的分類為：需求文檔的缺陷、軟件配置引起的缺陷、分析、設計的缺陷、靜態(tài)文檔的缺陷、軟件開發(fā)引起的缺陷、短視將來的缺陷 19． 測試用例工作主要是如何添加測試用例、如何編寫測試用例、將測試用例和需求關聯(lián)

20． 自動化測試工具有：ratinal Robot、winrunner、quicktest 21． 軟件性能測試工具有： loadRunner、Ratinaol Visual Qantify、PureLoad 22． BUG的種類有：需求階段的BUG、分析設計階段的BUG、實現(xiàn)階段的BUG、配置階段的BUG、靜態(tài)文檔的BUG。23． 測試項目主要包括以下幾個階段：計劃階段、初始階段、執(zhí)行階段、總結評估階段、設計階段。

1． 缺陷報告

是描述軟件缺陷現(xiàn)象和重現(xiàn)步驟地集合。軟件缺陷報告Software Bug Report（SBR）或軟件問題報告Software Problem Report（SPR）

2． 回歸測試

是指重新執(zhí)行已經(jīng)做過的測試的某個子集，以保證修改變化沒有帶來非預期的副作用。

3． 動態(tài)測試 通過運行軟件來檢驗軟件的動態(tài)行為和運行結果的正確性。動態(tài)測試的兩個基本要素： 被測試程序、測試數(shù)據(jù)（測試用例）

4． 白盒測試又稱為結構測試和邏輯驅(qū)動測試，允許測試人員對程序內(nèi)部邏輯結構及有關信息來設計和選擇測試用例，對程序的邏輯路徑進行測試。白盒測試是把測試對象看作一個打開的盒子，測試人員須了解程序的內(nèi)部結構和處理過程，由于白盒測試是一種結構測試，所以被測對象基本上是源程序，以程序的內(nèi)部邏輯和指定的覆蓋標準確定測試數(shù)據(jù)。

5． 黑盒測試又稱為功能測試或數(shù)據(jù)驅(qū)動測試，把系統(tǒng)看成一個黑盒子，不考慮程序的內(nèi)在邏輯，只根據(jù)需求規(guī)格說明書的要求來檢查程序的功能是否符合它的功能說明。

6． 路徑覆蓋的含義是，選取足夠多的測試數(shù)據(jù)，使程序的每條可能路徑都至少執(zhí)行一次(如果程序圖中有環(huán)，則要求每個環(huán)至少經(jīng)過一次)。

7． 軟件測試 ：在軟件投入運行前，對軟件需求分析、設計規(guī)格說明和編碼的最終復審，是軟件質(zhì)量保證的關鍵步驟。8． 單元測試（模塊測試）：針對每個模塊進行的測試，可從程序的內(nèi)部結構出發(fā)設計測試用例，多個模塊可以平行地對立地測試。通常在編碼階段進行，必要的時候要制作驅(qū)動模塊和樁模塊。9． 集成測試：在單元測試的基礎上，將所有模塊按照設計要求組裝成為系統(tǒng)，應提交集成測試計劃、集成測試規(guī)格說明和集成測試分析報告。

10． 確認測試：驗證軟件的功能和性能及其它特性是否與用戶的要求一致。

11． 系統(tǒng)測試：將軟件放在整個計算機環(huán)境下，包括軟硬件平臺、某些支持軟件、數(shù)據(jù)和人員等，在實際運行環(huán)境下進行一系列的測試。

1． 測試過程中會產(chǎn)生哪些基本文檔？

（1）測試計劃（通常包括單元測試和集成測試）：確定測試范圍、方法和需要的資源

（2）測試過程：詳細描述和每個測試方案有關的測試步驟和數(shù)據(jù)（包括測試數(shù)據(jù)及預期的結果）；

（3）測試結果：把每次測試運行的結果歸入文檔，如果運行出錯，則應產(chǎn)生 問題報告，并且必須通過調(diào)試解決所發(fā)現(xiàn)的問題。

（4）

2.大型軟件系統(tǒng)的測試過程基本上由幾個步驟組成? 1）.模塊測試

在設計得好的軟件系統(tǒng)中，每個模塊完成一個清晰定義的子功能，而且這個子功能和同級其他模塊的功能之間沒有相互依賴關系。因此，有可能把每個模塊作為一個單獨的實體來測試，而且通常比較容易設計檢驗模塊正確性的測試方案。模塊測試的目的是保證每個模塊作為一個單元能正確運行，所以模塊測試通常又稱為單元測試。在這個測試步驟中所發(fā)現(xiàn)的往往是編碼和詳細設計的錯誤。2）.子系統(tǒng)測試

子系統(tǒng)測試是把經(jīng)過單元測試的模塊放在一起形成一個子系統(tǒng)來測試。模塊相互間的協(xié)調(diào)和通信是這個測試過程中的主要問題，因此，這個步驟著重測試模塊的接口。3）.系統(tǒng)測試

系統(tǒng)測試是把經(jīng)過測試的子系統(tǒng)裝配成一個完整的系統(tǒng)來測試。在這個過程中不僅應該發(fā)現(xiàn)設計和編碼的錯誤，還應該驗證系統(tǒng)確實能提供需求說明書中指定的功能，而且系統(tǒng)的動態(tài)特性也符合預定要求。在這個測試步驟中發(fā)現(xiàn)的往往是軟件設計中的錯誤，也可能發(fā)現(xiàn)需求說明中的錯誤。不論是子系統(tǒng)測試還是系統(tǒng)測試，都兼有檢測和組裝兩重含義，通常稱為集成測試。4）.驗收測試

驗收測試把軟件系統(tǒng)作為單一的實體進行測試，測試內(nèi)容與系統(tǒng)測試基本類似，但是它是在用戶積極參與下進行的，而且可能主要使用實際數(shù)據(jù)(系統(tǒng)將來要處理的信息)進行測試。驗收測試的目的是驗證系統(tǒng)確實能夠滿足用戶的需要，在這個測試步驟中發(fā)現(xiàn)的往往是系統(tǒng)需求說明書中的錯誤。驗收測試也稱為確認測試。5）.平行運行

關系重大的軟件產(chǎn)品在驗收之后往往并不立即投入生產(chǎn)性運行，而是要再經(jīng)過一段平行運行時間的考驗。所謂平行運行就是同時運行新開發(fā)出來的系統(tǒng)和將被它取代的舊系統(tǒng)，以便比較新舊兩個系統(tǒng)的處理結果。這樣做的具體目的有如下幾點：(1)可以在準生產(chǎn)環(huán)境中運行新系統(tǒng)而又不冒風險；(2)用戶能有一段熟悉新系統(tǒng)的時間；

(3)可以驗證用戶指南和使用手冊之類的文檔；

(4)能夠以準生產(chǎn)模式對新系統(tǒng)進行全負荷測試，可以用測試結果驗證性能指標。3.一套完整的測試應該由哪些階段組成？分別闡述一下各個階段。

計劃階段、設計階段、白盒單元、白盒集成、黑盒單元、黑盒集成、系統(tǒng)測試、回歸測試、驗收測試一套完整的測試應該由五個階段組成：

1）測試計劃首先，根據(jù)用戶需求報告中關于功能要求和性能指標的規(guī)格說明書，定義相應的測試需求報告，即制訂黑盒測試的最高標準。以后所有的測試工作都將圍繞著測試需求來進行，符合測試需求的應用程序即是合格的，反之即是不合格的；同時，還要適當選擇測試內(nèi)容，合理安排測試人員、測試時間及測試資源等。2）測試設計將測試計劃階段制訂的測試需求分解、細化為若干個可執(zhí)行的測試過程，并為每個測試過程選擇適當?shù)臏y試用例（測試用例選擇的好壞將直接影響測試結果的有效性）。

3）測試開發(fā)建立可重復使用的自動測試過程。

4）測試執(zhí)行執(zhí)行測試開發(fā)階段建立的自動測試過程，并對所發(fā)現(xiàn)的缺陷進行跟蹤管理，測試執(zhí)行一般由單元測試、組合測試、集成測試、系統(tǒng)聯(lián)調(diào)及回歸測試等步驟組成，測試人員應本著科學負責的態(tài)度，一步一個腳印地進行測試。

5）測試評估結合量化的測試覆蓋域及缺陷跟蹤報告，對于應用軟件的質(zhì)量和開發(fā)團隊的工作進度及工作效率進行綜合評價。4.軟件測試的流程

制訂測試計劃、設計測試用例、實施測試、提交缺陷報告、編寫測試總結。5.測試計劃的內(nèi)容都包括什么？其中哪些是最重要的？

1)測試計劃的內(nèi)容：測試目的和測試項目簡介、測試參考文檔和測試提交文檔、術語和定義、測試策略、確定測試內(nèi)容、資源、測試進度、測試員的職責與任務分配、項目通過或失敗的標準、暫停和重新啟動測試的標準、風險和問題等。2)最重要的：測試策略、確定測試內(nèi)容、資源、測試進度、測試員的職責與任務分配、項目通過或失敗的標準 6.測試計劃的目的是什么？

測試計劃的目的：編寫軟件測試計劃的目的是指導測試組成員進行工作和讓測試組以外的項目成員了解測試工作的。7.簡述靜態(tài)測試和動態(tài)測試的區(qū)別？

a)靜態(tài)測試： 基本特征是在對軟件進行分析、檢查和審閱，不實際運行被測試的軟件。靜態(tài)測試約可找出30～70%的邏輯設計錯誤。對需求規(guī)格說明書、軟件設計說明書、源程序做檢查和審閱。包括：是否符合標準和規(guī)范；通過結構分析、流圖分析、符號執(zhí)行指出軟件缺陷。b)動態(tài)測試：通過運行軟件來檢驗軟件的動態(tài)行為和運行結果的正確性。動態(tài)測試的兩個基本要素：被測試程序和測試數(shù)據(jù)（測試用例）。動態(tài)測試方法：(1)選取定義域有效值,或定義域外無效值；(2)對已選取值決定預期的結果；(3)用選取值執(zhí)行程序；(4)執(zhí)行結果與預期的結果相比,不吻和程序有錯。8.白盒測試有哪幾種方法？

語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、多重條件覆蓋。9.壓力測試和性能測試的區(qū)別？

1)廣義上說壓力測試是包括在性能測試之中的，是性能測試項內(nèi)的一種。

2)性能測試：顧名思義就是測試軟件的運行性能。驗證SRS中的性能需求，是否實現(xiàn)。

3)壓力測試：測試軟件在超負荷下的工作情況，也是一種軟件的性能。因此是屬于性能測試范圍的。

10.測試結束的標準是什么？

測試計劃中所有規(guī)定的測試內(nèi)容和回歸測試都已經(jīng)運行完成或根據(jù)上級主管對測試結果的意見，就可以結束本次測試。11.黑盒測試的測試用例設計方法包括哪些？：

a)等價類劃分：劃分等價類--確立測試用例--設計用例。b)邊界值分析：通過分析，考慮如何確立邊界情況 c)錯誤推測法：靠經(jīng)驗和直覺來推測程序中可能存在的各種錯誤，從而有針對性地編寫用例。可以列舉出可能的錯誤和可能發(fā)生錯誤的地方，然后選擇用例。d)因果圖：通過畫因果圖，在圖上標明約束和限制，轉換成判定表，然后設計測試用例。這適合于檢查程序輸入條件的各種組合情況。

12.缺陷報告的作用

缺陷報告是軟件測試人員的工作成果之一，體現(xiàn)軟件測試的價值缺陷報告可以把軟件存在的缺陷準確的描述出來，便于開發(fā)人員修正缺陷報告可以反映項目、產(chǎn)品當前的質(zhì)量狀態(tài)，便于項目整體進度和質(zhì)量控制。軟件測試缺陷報告是軟件測試的輸出成果之一，可以衡量測試人員的工作能力。13.等價分類法的基本思想是什么？

根據(jù)程序的輸入特性，將程序的定義域劃分為有限個等價區(qū)段“等價類”，從等價類中選擇出的用例具有“代表性”，即測試某個等價類的代表值就等于對這一類其他值的測試。如果某個等價類的一個輸入數(shù)據(jù)（代表值）測試中查出了錯誤，說明該類中其他測試用例也會有錯誤。14.簡單闡述一下軟件測試的目標

(1)測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程；

(2)好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案；(3)成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。15.軟件測試準則有哪些？

(1)所有測試都應該能追溯到用戶需求。

(2)應當把“盡早地和不斷地進行軟件測試” 作為軟件開發(fā)者的座右銘。(3)pareto原則：測試發(fā)現(xiàn)的錯誤中的80%很可能是由程序中20%的模塊造成的。

（4）應該從“小規(guī)模”測試開始，并逐步進行“大規(guī)模”測試。

（5）測試用例應由輸入數(shù)據(jù)和預期的輸出結果兩部分組成，并兼顧合理的輸入和不合理的輸入數(shù)據(jù)

（6）窮舉測試是不可能的。

（7）為了達到最佳的測試效果，應該由獨立的第三方從事測試工作。

（8）程序修改后要回歸測試。

（9）應長期保留測試用例，直至系統(tǒng)廢棄。16.您認為做好測試用例設計工作的關鍵是什么？

1)白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內(nèi)部程序邏輯結果

2)黑盒測試用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時間內(nèi)發(fā)現(xiàn)最多的問題

1． 根據(jù)下面給出的規(guī)格說明，利用等價類劃分的方法，給出足夠的測試用例。

“一個程序讀入三個整數(shù)。把此三個數(shù)值看成是一個三角形的三個邊。這個程序要打印出信息，說明這個三角形是三邊不等的、是等腰的、還是等邊的。”

2． 某報表處理系統(tǒng)要求用戶輸入處理報表的日期，日期限制在2003年1月至2008年12月，即系統(tǒng)只能對該段期間內(nèi)的報表進行處理，如日期不在此范圍內(nèi)，則顯示輸入錯誤信息。系統(tǒng)日期規(guī)定由年、月的6位數(shù)字字符組成，前四位代表年，后兩位代表月。請用等價類劃分法和邊界值劃分法設計測試用例來測試程序的日期檢查功能。

3． 設要對一個自動飲料售貨機軟件進行黑盒測試。該軟件的規(guī)格說明如下：

“有一個處理單價為1元5角錢的盒裝飲料的自動售貨機軟件。若投入1元5角硬幣，按下“可樂”、“雪碧”或“紅茶”按鈕，相應的飲料就送出來。若投入的是2元硬幣，在送出飲料的同時退還5角硬幣。”

利用等價類劃分的方法，設計測試該軟件的全部測試用例。