《計算機畢業(yè)論文》由會員分享，可在線閱讀，更多相關《計算機畢業(yè)論文（25頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、 軟件測試的概述及方法 Meteor 指導教師姓名 職稱 專 業(yè) 名 稱 計 算 機 網(wǎng) 絡 專 業(yè) 論文提交日期 論文答辯日期 2012年 4月 30 日 軟件測試的概述及方法 Meteor XX大學,重慶 400715 摘要：從軟件產(chǎn)業(yè)的發(fā)展初期到目前的大型軟件開發(fā)過程，軟件測試已成為其中一個不可分割的部分。隨著軟件規(guī)模的日益增大，軟件測試問題也日益突出，現(xiàn)代社會對軟件的依賴越來越強,高可

2、信軟件測試有著廣泛的需求，基于缺陷模式的軟件測試技術作為高可信軟件的重要保證,可以大大降低軟件的缺陷密度,提高軟件的可信性。本文從測試的基本概念入手,深入剖析軟件測試相關理論。 關鍵字：軟件測試、白盒測試、黑盒測試、類測試 1 軟件測試的發(fā)展史 軟件測試的發(fā)展歷史：20世紀60年代（軟件工程建立前），為表明程序正確而進行測試。1972年在北卡羅來納大學舉行了首屆軟件測試正式會議。1975年John Good Enough和Susan Gerhart在IEEE上發(fā)表了《測試數(shù)據(jù)選擇的原理》的文章，軟件測試被確定為一種研究方向。1979年，Glenford Myers的《軟件測試藝術》,

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

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

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

6、個軟件缺陷：一個很小的系統(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)和質量(quality)的軟件過程；是SQA

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

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

9、假設。 在談到軟件測試時，引用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)錯誤是軟件測試的唯一目，查找不出錯誤的測試就是沒有價值的，事實并非如此。 首先，測試并不僅僅是為了要找出錯誤

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

11、試中的錯誤集中發(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) 驗證(verifi

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

13、事件(Do it right) 1.靜態(tài)確認, 不在計算機上實際執(zhí)行程序, 通過人工或程序分析來證明軟件的正確性； 2.動態(tài)確認, 通過執(zhí)行程序做分析, 測試程序的動態(tài)行為, 以證實軟件是否存在問題。 軟件測試的對象不僅僅是程序測試, 軟件測試應該包括整個軟件開發(fā)期間各個階段所產(chǎn)生的文檔, 如需求規(guī)格說明、概要設計文檔、詳細設計文檔, 當然軟件測試的主要對象還是源程序。 5 軟件測試的分類 5.1 常用分類 從是否需要執(zhí)行被測軟件的角度, 可分為： 靜態(tài)測試 和動態(tài)測試 從測試是否針對系統(tǒng)的內(nèi)部結構和具體實現(xiàn)算法的角度來看, 可分為

14、 ： 白盒測試 和黑盒測試 5.2 黑盒測試 黑盒測試 指的是把被測軟件看作是一個黑盒子, 我們不去關心盒子里面的結構是什么樣子, 只關心軟件的輸入數(shù)據(jù)和輸出結果。 黑盒測試方法是在程序接口上進行測試, 主要是為了發(fā)現(xiàn)以下錯誤: ? 是否有不正確或遺漏了的功能? ? 在接口上, 輸入能否正確地接受? 能否輸出正確的結果? ? 是否有數(shù)據(jù)結構錯誤或外部信息(例如數(shù)據(jù)文件)訪問錯誤? ?性能上是否能夠滿足要求? ? 是否有初始化或終止性錯誤?　 用黑盒測試發(fā)現(xiàn)程序中的錯誤, 必須在所有可能的輸入條件和輸出條件中確定測試數(shù)據(jù), 來檢查程序是否都能產(chǎn)生正確的輸出,但這

15、是不可能的。 證明： n假設一個程序P有輸入量X和Y及輸出量Z。在字長為32位的計算機上運行。若X、Y取整數(shù), 按黑盒方法進行窮舉測試： n可能采用的 測試數(shù)據(jù)組： 232232 ＝264 n如果測試一組數(shù)據(jù)需要1毫秒, 一年工作365 24小時, 完成所有測試需5億年。 5.2.1 黑盒測試的測試用例設計 如手機的開機測試案例下表所示 開機（Power UP） 測試項目 測試ID 操作描述 預期結果 實際結果(OK/NG/NA) 備注 1 LED燈 PU-1-1 關機狀態(tài)下長按掛機鍵 LED燈閃爍，顏色變換符合設計 　 　 2 開

16、機動畫 PU-2-1 關機狀態(tài)下長按掛機鍵 開機動畫演示正常 　 　 3 開機音樂 PU-3-1 關機狀態(tài)下長按掛機鍵 開機音樂播放正常 　 　 4 開機歡迎界面 PU-4-1 關機狀態(tài)下長按掛機鍵 開機歡迎辭顯示正常 　 　 5 SIM 卡 檢 查 5.1 SIM卡損壞或沒有SIM卡插入 PU-5.1-1 關機狀態(tài)下長按掛機鍵 開機動畫、開機音樂之后，顯示并停留在“請插入SIM卡”版面 　 　 PU-5.1-2 關機

17、狀態(tài)下長按掛機鍵,在“請插入SIM卡”版面,按SOS軟鍵 進入“緊急呼叫” 　 　 5.2 啟動了PIN檢驗 PU-5.2-1 關機狀態(tài)下長按掛機鍵 開機動畫、開機音樂后出現(xiàn)“請輸入PIN碼”版面 　 　 PU-5.2-2 “請輸入PIN碼”版面，直接按確定軟鍵 提示“最小長度是4”，并返回“請輸入PIN碼”版面 　 　 PU-5.2-3 “請輸入PIN碼”版面，按數(shù)字鍵 可以進行輸入，并顯示* 　 　 PU-5.2-4 “請輸入PIN碼”版面，輸入1~3位數(shù)字，按確定軟鍵 提示“最小長度是4”

18、，并返回“請輸入PIN碼”版面 　 　 PU-5.2-5 “請輸入PIN碼”版面,輸入8位數(shù)字后繼續(xù)輸入 提示“最大長度是8”，并返回“請輸入PIN碼”版面 　 　 PU-5.2-6 “請輸入PIN碼”版面，輸入4~8個數(shù)字的錯誤PIN碼，按確定 提示“錯誤PIN碼”，然后返回“請輸入PIN碼”畫面 　 　 PU-5.2-7 “請輸入PIN碼”版面，輸入正確PIN碼，按確定 繼續(xù)開機流程 　 　 5.3 SIM卡PIN1被鎖 PU-5.3-1 關機狀態(tài)下長按掛機鍵 開機動畫、開機音樂之后，提示“PIN1被鎖住”并最終顯示在“請輸入PUK”版面 　

19、　 PU-5.3-2 在“請輸入PUK”版面，直接按確定軟鍵 提示“最小長度是4”，并返回“請輸入PUK碼”版面 　 　 PU-5.3-3 在“請輸入PUK”版面，按數(shù)字鍵 可以進行輸入，并顯示* 　 　 PU-5.3-4 在“請輸入PUK”版面，輸入1~7位數(shù)字，按確定軟鍵 提示“最小長度是8”，并返回“請輸入PUK碼”版面 　 　 PU-5.3-5 在“請輸入PUK”版面，輸入8位數(shù)字的錯誤PUK碼，按確定軟鍵 要求輸入兩次新PIN碼后，提示“PIN1被鎖住”，并返回“請輸入PUK碼”版面 　 　 PU-5.3-6 在“請輸入PUK”版面，輸入8

20、位數(shù)字，繼續(xù)輸入 提示“最大長度是8”，并返回“請輸入PUK碼”版面 　 　 PU-5.3-7 在“請輸入PUK”版面，輸入8位數(shù)字的正確PUK碼，按確定軟鍵 要求輸入兩次新PIN碼，并成功解鎖，繼續(xù)開機流程 　 　 6 手機密碼檢查 PU-6-1 關機狀態(tài)下長按掛機鍵 開機動畫、開機音樂、PIN檢驗之后，出現(xiàn)“輸入手機密碼”版面 　 　 PU-6-2 “輸入手機密碼”版面，直接按確定軟鍵 提示“最小長度是4”，并返回“輸入手機密碼”版面 　 　 PU-6-3 “輸入手機密碼”版面，按數(shù)字鍵 可以進行輸入，并顯示* 　 　 PU-6-4 在“

21、輸入手機密碼”版面，輸入1~3位數(shù)字，按確定軟鍵 提示“最小長度是4”，并返回“輸入手機密碼”版面 　 　 PU-6-5 在“輸入手機密碼”版面，輸入4位錯誤手機密碼，按確定軟鍵 提示“手機密碼錯誤”，并返回“輸入手機密碼”版面 　 　 PU-6-6 在“輸入手機密碼”版面，輸入8位數(shù)字，繼續(xù)輸入 輸入無效 　 　 PU-6-7 在“輸入手機密碼”版面，輸入4位正確手機密碼，按確定軟鍵 手機解鎖，繼續(xù)開機流程 　 　 7 搜網(wǎng) PU-7-1 關機狀態(tài)下長按掛機鍵 開機動畫、音樂完畢；PIN檢驗、手機密碼檢驗完畢，出現(xiàn)搜網(wǎng)畫面“正在搜網(wǎng)”，直到找到網(wǎng)絡

22、 　 　 注：其它語言下以上各功能運行正常 測試說明：在測試中，必須對每個界面都要進行觸屏的操作，因此測試次數(shù)為2次，即使用按鍵操作1次，使用觸屏操作1次，檢查功能是否正常.(如有側翻，合蓋操作界面也做以上相應操作） 5.2.2 等價劃分法 等價類劃分是一種典型的黑盒測試方法，用這一方法設計測試用例完全不考慮程序的內(nèi)部結構，只根據(jù)對程序的要求和說明，即需求規(guī)格說明書。我們必須仔細分析和推敲說明書的各項需求，特別是功能需求。把說明書中對輸入的要求和輸出的要求區(qū)別開來并加以分解。 由于窮舉測試工作量太大，以至于無法實際完成，促使我們在大量的可能數(shù)據(jù)中選取其中的一部分作為測試用例。

23、例如，在不了解等價分配計數(shù)的前提下，我們做計算器程序的加法測試時，測試了1+1，1+2，1+3和1+4之后，還有必要測試1+5和1+6嗎，能否放心地認為它們是正確的？我們感覺1+5和1+6，與前面的1+1，1+2都是很類似的簡單加法。 等價類劃分的方法是把程序的輸入域劃分成若干部分，然后從每個部分中選取少數(shù)代表性數(shù)據(jù)作為測試用例。每一類的代表性數(shù)據(jù)在測試中的作用等價于這一類中的其他值，也就是說，如果某一類中的一個例子發(fā)現(xiàn)了錯誤，這一等價類中的其他例子也能發(fā)現(xiàn)同樣的錯誤；反之，如果某一類中的一個例子沒有發(fā)現(xiàn)錯誤，則這一類中的其他例子也不會查出錯誤(除非等價類中的某些例子屬于另一等價類，因為幾個

24、等價類是可能相交的)。使用這一方法設計測試用例，首先必須在分析需求規(guī)格說明的基礎上劃分等價類，列出等價類表。 5.2.2.1 劃分等價類和列出等價類表 等價類是指某個輸入域的子集合。在該子集合中，各個輸入數(shù)據(jù)對于發(fā)現(xiàn)程序中的錯誤都是等效的。并合理地假定：測試某個等價類的代表值就等于對這一類其他值的測試。 因此，可以把全部輸入數(shù)據(jù)合理地劃分為若干等價類，在每一個等價類中取一個數(shù)據(jù)作為測試輸入條件，就可以用少量代表性的測試數(shù)據(jù)取得較好的測試結果。等價類劃分有兩種不同的情況：有效等價類和無效等價類。 有效等價類：指對于程序的規(guī)格說明來說是合理的、有意義的輸入數(shù)據(jù)構成的集合。利用有效等價類可以

25、檢驗程序是否實現(xiàn)了規(guī)格說明中所規(guī)定的功能和性能。 無效等價類：與有效等價類的定義相反。 設計測試用例時，要同時考慮這兩種等價類。因為軟件不僅要能接收合理的數(shù)據(jù)，也要能經(jīng)受意外的考驗。這樣的測試才能確保軟件具有更好的可靠性。 下面給出6條確定等價類的原則： ①在輸入條件規(guī)定了取值范圍或值的個數(shù)的情況下，可以確立一個有效等價類和兩個無效等價類。 ②在輸入條件規(guī)定了輸入值的集合或者規(guī)定了“必須如何”的條件的情況下，可以確立一個有效等價類和一個無效等價類。 ③在輸入條件是一個布爾量的情況下，可確定一個有效等價類和一個無效等價類。 ④在規(guī)定了輸入數(shù)據(jù)的一組值(假定n個)，并且程序要對每一個

26、輸入值分別處理的情況下，可確立n個有效等價類和一個無效等價類。 ⑤在規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則的情況下，可確立一個有效等價類(符合規(guī)則)和若干個無效等價類(從不同角度違反規(guī)則)。 ⑥在確知已劃分的等價類中，各元素在程序處理中的方式不同的情況下，則應再將該等價類進一步劃分為更小的等價類。 在確立了等價類之后，建立等價類表，列出所有劃分出的等價類。 5.2.2.2 確定測試用例 根據(jù)已列出的等價類表，按以下步驟確定測試用例： ①為每個等價類規(guī)定一個唯一的編號。 ②設計一個新的測試用例，使其盡可能多地覆蓋尚未覆蓋的有效等價類。重復這一步，最后使得所有有效等價類均被測試用例所覆蓋。

27、③設計一個新的測試用例，使其只覆蓋一個無效等價類。重復這一步使所有無效等價類均被覆蓋。 在尋找等價區(qū)間時，設法把軟件的相似輸入、輸出、操作分成組，這些組就是等價區(qū)間。 等價類的重要問題是它們構成的集合的劃分，其中，劃分是指互不相交的一組子集，這些子集的并是整個集合。這對于測試有兩點非常重要的意義：表示整個集合這個事實提供了一種形式的完備性，而互不相交可保證一種形式的無冗余性。由于子集是由等價關系決定的，因此子集的元素都有一些共同點。等價類測試的思想是通過每個等價類中的一個元素標識測試用例。如果廣泛選擇等價類，則這樣可以大大減低測試用例之間的冗余。 為了便于理解，以下討論涉及有兩個變量X1

28、和X2的函數(shù)F。如果函數(shù)F實現(xiàn)為一個程序，則輸入變量X1和X2將擁有以下邊界，以及邊界內(nèi)的區(qū)間： a≤X1≤d，區(qū)間為[a，b)，[b，c)，[c，d] e≤X2≤g，區(qū)間為[e，f)，[f，g] 其中方括號和圓括號分別表示閉區(qū)間和開區(qū)間的端點。X1，X2的無效值是X1d，X2g。以此作為例子，我們將進一步討論等價類劃分法。 5.2.2.3 弱一般等價類測試 采用上面給出的標記，弱一般等價類測試通過一個測試用例中的每個等價類(區(qū)間)的一個變量實現(xiàn)(請注意單邊假設作用)。對于前面給出的例子，可得到如下圖所示的弱等價類測試用例。 由函數(shù)的定義可知，帶陰影的

29、矩形中的任何點都是函數(shù)F的有效輸入。這三個測試用例使用每個等價類中的一個值。我們以對稱方式標識這些測試用例，于是得到外在的模式。事實上，永遠都有等量的弱等價類測試用例，因為劃分中的類對應最大子集數(shù)。 5.2.2.4 強一般等價類測試 強一般等價類測試基于多缺陷假設，因此需要等價類笛卡爾積的每個元素對應的測試用例，如下圖所示： 請注意，這些測試用例的模式與命題邏輯中的真值表構造具有相似性。笛卡爾積可以保證兩種意義上的“完備性”：一是覆蓋所有的等價類，二是有可能的輸入組合中的一個。 事實上，“好的”等價類測試的關鍵是等價關系的選擇。注意被“相同處理”的輸入。在大多數(shù)情況下，等價類測試定

30、義輸入定義域的類。沒有理由不能根據(jù)被測程序函數(shù)的輸出值域定義等價關系，我們可以看到，這對于三角形問題是最簡單的方法。 5.2.2.5 弱健壯等價類測試 這種測試的名稱顯然與直覺矛盾，且自相矛盾。怎么能夠既弱又健壯呢？說它健壯，是因為這種測試考慮了無效值；說它弱，是因為有單缺陷假設。 1、對于有效輸入，使用每個有效類的一個值。(就像我們在所謂弱一般等價類測試中所做的一樣。請注意，這些測試用例中的所有輸入都是有效的。) 2、對于無效輸入，測試用例將擁有一個無效值，并保持其余的值都是等效的。(因此，“單缺陷”會造成測試用例失敗。) 按照這種策略產(chǎn)生的測試用例如下圖所示： 健壯等價類測

31、試有兩個問題。第一個問題是，規(guī)格說明常常并沒有定義無效測試用例所預期的輸出是什么。(我們可以把這看作是規(guī)格說明的不足，但是這并不能解決問題。)因此，測試人員需要花費大量時間定義這些測試用例的輸出。第二個問題是，強類型語言沒有必要考慮無效輸入。傳統(tǒng)等價類測試是諸如FORTRAN和COBOL這樣的語言占統(tǒng)治地位的年代的產(chǎn)物，因此那時這種錯誤很常見。事實上，正是由于經(jīng)常出現(xiàn)這種錯誤，才促使人們實現(xiàn)強類型語言。 對于第二個問題，應該是指對于純編程語言而言的。在實際的項目中，由于人的因素(人總會犯錯誤，即使編程語言本身再怎么完美，諸如Java、Python、C++這樣的強類型語言，也無法避免)，以及業(yè)

32、務的具體要求，無效輸入往往要考慮業(yè)務因素，所以任何時刻都必須考慮無效輸入。 5.2.2.6 強健壯等價類測試 至少這種測試的名稱既不與直覺矛盾，也不自相矛盾，只是有些冗余。像以前的定義一樣，健壯是指要考慮無效值，強是指多缺陷假設。 我們從所有的等價類笛卡爾積的每個元素中獲得測試用例，如下圖所示： 下面我們將結合三角形問題，來實際應用等價類劃分的方法。三角形問題是這樣的經(jīng)典，以至于雖然大家都知道它是經(jīng)典問題，面試和筆試中還是會遇到。 例題：根據(jù)下面給出的規(guī)格說明，利用等價類劃分的方法，給出足夠的測試用例?！耙粋€程序讀入3個整數(shù)，把這3個數(shù)值看作一個三角形的3條邊的長度值。這個程序要

33、打印信息，說明這個三角形是不等邊的、是等腰的、是等邊的，或者不能構成三角形”。 在描述問題時，我們提到有四種可能出現(xiàn)的輸出：非三角形、不等邊三角形、等腰三角形和等邊三角形?？梢允褂眠@些輸出標識如下所示的輸出(值域)等價類： R1={：有三條邊a、b和c的等邊三角形} R2={：有三條邊a、b和c的等腰三角形} R3={：有三條邊a、b和c的不等邊三角形} R4={：三條邊a、b和c的不構成三角形} 四個弱一般等價類測試用例是： 弱一般等價類測試用例 測試用例 a b c 預期輸出 WN1 5 5 5 等邊

34、三角形 WN2 2 2 3 等腰三角形 WN3 3 4 5 不等邊三角形 WN4 4 1 2 非三角形 由于a、b和c沒有有效區(qū)間，則強一般等價類測試用例與弱一般等價類測試用例相同。 考慮a、b和c的無效值產(chǎn)生的以下額外弱健壯等價類測試用例： 額外弱健壯等價類測試用例 測試用例 a b c 預期輸出 WR1 -1 5 5 a取值不在所允許的取值值域內(nèi) WR2 5 -1 5 b取值不在所允許的取值值域內(nèi) WR3 5 5 -1 c取值不在所允許的取值值域內(nèi) WR4 201 5 5 a取值不在所允許的取值值域內(nèi)

35、 WR5 5 201 5 b取值不在所允許的取值值域內(nèi) WR6 5 5 201 c取值不在所允許的取值值域內(nèi) 以下是額外強健壯等價類測試用例三維立方的一個“角”： 額外強健壯等價類測試用例 測試用例 a b c 預期輸出 SR1 -1 5 5 a取值不在所允許的取值值域內(nèi) SR2 5 -1 5 b取值不在所允許的取值值域內(nèi) SR3 5 5 -1 c取值不在所允許的取值值域內(nèi) SR4 -1 -1 5 a、b取值不在所允許的取值值域內(nèi) SR5 5 -1 -1 b、c取值不在所允許的取值值域內(nèi) SR6 -1 5

36、 -1 a、c取值不在所允許的取值值域內(nèi) SR7 -1 -1 -1 a、b、c取值不在所允許的取值值域內(nèi) 請注意，預期輸出如何完備地描述無效輸入值。 等價類測試顯然對用來定義類的等價關系很敏感。如果在輸入定義域上定義等價類，則可以得到更豐富的測試用例集合。三個整數(shù)a、b和c有些什么可能的取值呢？這些整數(shù)可以相等，有一對整數(shù)相等(有三種相等方式)，或都不相等。 D1={：a=b=c}，D2={：a=b，a≠c}，D3={：a=c，a≠b} D4={：b=c，a≠b}，D5={：a≠b，a≠c，b≠c}

37、 作為一個單獨的問題，我們可以通過三角形的性質來判斷三條邊是否構成一個三角形。(例如，三元組<1，4，1>有一對相等的邊，但是這些邊不構成一個三角形。) D6={：a≥b+c}，D7={：b≥a+c}，D8={：c≥a+b} 如果我們要徹底一些，可以將“大于或等于”分解為兩種不同的情況，這樣D6就變成 D6′={：a=b+c}，D6″={：a>b+c}，同樣對于D7和D8也有類似的情況。 列出等價類表，如下所示： 等價類表 輸入條件 有效等價類 無效等價類 是否三角形的3邊 （A>0） (1)

38、(A≤0) （7） (B>0) (2) (B≤0) (8) (C>0) (3) (C≤0) (9) (A+B>C) (4) (A+B≤C) (10) (B+C>A) (5) (B+C≤A) (11) (A+C>B) (6) (A+C≤B) (12) 是否等腰三角形 （A=B） (13) （A≠B）and(B≠C)and (A≠C) （16） (B=C) (14) (A=C) (15) 是否等邊三角形 （A=B）and(B

39、=C)and (A=C) （17） （A≠B） (18) (B≠C) (19) (A≠C) (20) 設計測試用例：輸入順序是[A，B，C]，如下表所示： 設計測試用例表 序號 [A，B，C] 覆蓋等價類 輸出 1 [3,4,5] (1),(2),(3),(4),(5),(6) 不能構成三角形 2 [0,1,2] (7) 3 [1,0,2] (8) 4 [1,2,0] (9) 5 [1,2,3] (10) 6 [1,3,2] (11) 7 [3,1,2] (12) 8 [3,

40、3,4] (1),(2),(3),(4),(5),(6),(13) 等腰三角形 9 [3,4,4] (1),(2),(3),(4),(5),(6),(14) 10 [3,4,3] (1),(2),(3),(4),(5),(6),(15) 11 [3,4,5] (1),(2),(3),(4),(5),(6),(16) 非等腰三角形 12 [3,3,3] (1),(2),(3),(4),(5),(6),(17) 等邊三角形 13 [3,4,4] (1),(2),(3),(4),(5),(6),(14),(18) 非等邊三角形 14 [3,4,3] (1

41、),(2),(3),(4),(5),(6),(15),(19) 15 [3,3,4] (1),(2),(3),(4),(5),(6),(13),(20) 等價分配的目標是把可能的測試用例組合縮減到仍然足以滿足軟件測試需求為止。因為，了選擇不完全測試，就要冒一定的風險，所以必須仔細選擇分類。 5.3 白盒測試 白盒測試指的是把盒子蓋打開, 去研究里面的源代碼和程序結構。 白盒測試也稱結構測試或邏輯驅動測試, 它是知道產(chǎn)品內(nèi)部工作過程, 可通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進行, 按照程序內(nèi)部的結構測試程序, 檢驗程序中的每條通路是否都有能按預定要求正確工作,

42、 而不顧它的功能。 使用被測單元內(nèi)部如何工作的信息, 允許測試人員對程序內(nèi)部邏輯結構及有關信息來設計和選擇測試用例, 對程序的邏輯路徑進行測試?；谝粋€應用代碼的內(nèi)部邏輯知識, 測試是基于覆蓋全部代碼、分支、路徑、條件。 白盒測試的主要方法： ?邏輯驅動測試 ?基本路徑測試 主要用于軟件驗證。 使用程序設計的控制結構導出測試用例。 邏輯驅動測試： 主要是測試覆蓋率, 以程序內(nèi)在邏輯結構為基礎的測試。包括以下6種類型： ?語句覆蓋 ?判斷覆蓋 ?條件覆蓋 ?判定-條件覆蓋 ?條件組合覆蓋 ?路徑覆蓋 白盒測試的主要目的 ? 保證一個模塊

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

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

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

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

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

48、是整個測試過程的一個重要步驟。 6.1 類測試技術 6.2.1 基于服務的類測試技術 基于服務的類測試主要考察封裝在類中的一個方法對數(shù)據(jù)進行的操作，它可以采用傳統(tǒng)的白盒測試方法。為克服軟件測試的盲目性和局限性,保證測試的質量,提高軟件的可靠性,下面我們是一種類測試模型及相應的測試策略。 BBD通常有兩種獲取途徑。一是采用逆向工程的方法根據(jù)源程序畫出流程圖,然后構造出BBD。但這畢竟是在缺少軟件開發(fā)前期的分析、設計文檔或文檔不齊全的情況下退而求其次的辦法。當源程序不正確時構造出來的BBD就是錯誤的。另一種途徑就是追根溯源,在軟件的分析、設計階段就根據(jù)測試的需要構造出相應的BBD。這樣

49、就能從根本上解決問題,正確地指導類的服務的測試。 6.2.2 基于層次增量的類測試 層次增量測試的基本思想是:首先分別測試父類的各個成員函數(shù),再測試成員函數(shù)間的相互作用,把測試用例和執(zhí)行信息保存在/測試歷史中,在測試子類時,根據(jù)父類的測試歷史修改部分的定義以及實現(xiàn)語言的繼承映射來決定子類中的哪些特征應當重測試以及父類的哪些測試用例可以復用。 這種根據(jù)類間繼承關系的層次特性對類進行增量測試的技術是由M. Harrold等人提出的,其特點是復用父類的測試信息來指導子類的測試。 參考文獻 [1] Ron Patton.《軟件測試》機械工業(yè)出版社 [2] 張克

50、東等.《軟件工程與軟件測試自動化教程》電子工業(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.《面向對象系統(tǒng)測試 模型 視圖與工具（影印版

51、）》 [10] Rakitin,S.K.《軟件驗證與確認的最佳管理辦法》電子工業(yè)出版社 [11] 麥格雷戈.《面向對象的軟件測試》機械工業(yè)出版社 24 致謝 非常感謝老師在我大學的最后學習階段——畢業(yè)設計階段給自己的指導，從最初的定題，到資料收集，到寫作、修改，到論文定稿，你們給了我耐心的指導和無私的幫助。為了指導我們的畢業(yè)論文，放棄了自己的休息時間，這種無私奉獻的敬業(yè)精神令人欽佩，在此我向你們表示我誠摯的謝意。同時，感謝所有任課老師和所有同學在這幾年來給自己的指導和幫助，是他們教會了我專業(yè)知識，教會了我如何學習，教會了我如何做人。正是由于他們，我才能在各方面取得顯著的進步，在此向他們表示我由衷的謝意，并祝所有的老師培養(yǎng)出越來越多的優(yōu)秀人才，桃李滿天下！ 通過這一階段的努力，我的畢業(yè)論文《軟件測試的概述及方法》終于完成了，這意味著大學生活即將結束。在大學階段，我在學習上和思想上都受益非淺，這除了自身的努力外，與各位老師、同學和朋友的關心、支持和鼓勵是分不開的。 寫作畢業(yè)論文是一次再系統(tǒng)學習的過程，畢業(yè)論文的完成，同樣也意味著新的學習生活的開始。 感謝各位專家的批評指導。