計算機畢業(yè)論文 (2).doc

軟件測試的概述及方法meteor指導(dǎo)教師姓名 職稱 專 業(yè) 名 稱 計 算 機 網(wǎng) 絡(luò) 專 業(yè) 論文提交日期 論文答辯日期 2012年 4月 30 日軟件測試的概述及方法meteorxx大學(xué),重慶 400715摘要：從軟件產(chǎn)業(yè)的發(fā)展初期到目前的大型軟件開發(fā)過程，軟件測試已成為其中一個不可分割的部分。隨著軟件規(guī)模的日益增大，軟件測試問題也日益突出，現(xiàn)代社會對軟件的依賴越來越強,高可信軟件測試有著廣泛的需求，基于缺陷模式的軟件測試技術(shù)作為高可信軟件的重要保證,可以大大降低軟件的缺陷密度,提高軟件的可信性。本文從測試的基本概念入手,深入剖析軟件測試相關(guān)理論。關(guān)鍵字：軟件測試、白盒測試、黑盒測試、類測試1 軟件測試的發(fā)展史軟件測試的發(fā)展歷史：20世紀(jì)60年代（軟件工程建立前），為表明程序正確而進(jìn)行測試。1972年在北卡羅來納大學(xué)舉行了首屆軟件測試正式會議。1975年john good enough和susan gerhart在ieee上發(fā)表了測試數(shù)據(jù)選擇的原理的文章，軟件測試被確定為一種研究方向。1979年，glenford myers的軟件測試藝術(shù),對測試做了定義：測試是為發(fā)現(xiàn)錯誤而執(zhí)行的一個程序或者系統(tǒng)的過程 。20世紀(jì)80年代早期，“質(zhì)量”的號角開始吹響。軟件測試定義發(fā)生了改變，測試不單純是一個發(fā)現(xiàn)錯誤的過程，而且包含軟件質(zhì)量評價的內(nèi)容。制定了各類標(biāo)準(zhǔn)。1983年，bill hetzel在軟件測試完全指南中指出：測試是以評價一個程序或者系統(tǒng)屬性為目標(biāo)的任何一種活動，測試是對軟件質(zhì)量的度量。 20世紀(jì)90年代，測試工具盛行起來, 1996年提出的測試能力成熟度tcmm（testing capability maturity model）、測試支持度tsm（testability support model）、測試成熟度tmm（testing maturity model）。 到了2002年，rick和stefan在系統(tǒng)的軟件測試一書中對軟件測試做了進(jìn)一步定義：測試是為了度量和提高被測軟件的質(zhì)量，對測試軟件進(jìn)行工程設(shè)計、實施和維護的整個生命過程。2 軟件測試的相關(guān)背景相關(guān)背景：前段時間, 就是在我沒有認(rèn)真了解測試行業(yè)之前, 可能由于測試在中國的重視程度的問題, 我也一直認(rèn)為測試應(yīng)該是不重要的, 甚至認(rèn)為有必要有專門的測試職業(yè)嗎？認(rèn)為軟件主要是開發(fā)人員的事, 軟件的成果也是由開發(fā)人員決定的, 當(dāng)我在參加工作后, 真正從學(xué)校的學(xué)習(xí)環(huán)境中走上實際運用開發(fā)的時候, 事實上真的不是那么一回事。軟件無處不在, 然而, 軟件是人編的所以不完美。臭名昭著的軟件測試案例：1、迪士尼的獅子王 （19941995）軟件在少數(shù)系統(tǒng)中能正常工作, 但在大眾使用的常見系統(tǒng)中不行。后來證實,迪士尼公司沒有對市場上投入實用的各種pc機型進(jìn)行正確的測試。2、英特爾奔騰浮點除法軟件缺陷（1994）英特爾為自己處理軟件缺陷拿出4億美元支付更換壞芯片的費用。導(dǎo)致付出如此昂貴的代價, 其主要原因是發(fā)現(xiàn)了軟件缺陷沒有正確的處理。3、美國航天局火星極地登陸（1999）該項目使用前有經(jīng)過測試, 兩個測試小組雙方獨立工作都很好, 但從未走在一起。4、愛國者導(dǎo)彈防御系統(tǒng) （1991）一枚導(dǎo)彈在多哈擊斃28名美國士兵, 癥結(jié)在于一個軟件缺陷：一個很小的系統(tǒng)時鐘錯誤累積起來就可能拖延14小時, 造成跟蹤系統(tǒng)失去準(zhǔn)確度。在多哈襲擊戰(zhàn)中系統(tǒng)被拖延100小時。5、千年蟲 （大約1974）估計世界各地更換或升級該系統(tǒng)程序解決原有2000年錯誤的費用已經(jīng)超過數(shù)億美元。3 軟件測試的概述3.1 軟件測試的定義軟件測試使用人工或者自動手段來運行或測試某個系統(tǒng)的過程,其目的在于檢驗它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實際結(jié)果之間的差別。它是幫助識別開發(fā)完成（中間或最終的版本）的計算機軟件（整體或部分）的正確度(correctness) 完全度(completeness)和質(zhì)量(quality)的軟件過程；是sqa(software quality assurance)的重要子域。(1)測試并不僅僅是為了找出錯誤,通過分析錯誤產(chǎn)生的原因和錯誤的發(fā)生趨勢,可以幫助項目管理者發(fā)現(xiàn)當(dāng)前軟件開發(fā)過程中的缺陷,以便及時改進(jìn)； (2)這種分析也能幫助測試人員設(shè)計出有針對性的測試方法,改善測試的效率和有效性； (3)沒有發(fā)現(xiàn)錯誤的測試也是有價值的,完整的測試是評定軟件質(zhì)量的一種方法。3.2 軟件測試的描述測試是軟件開發(fā)過程的重要組成部分, 是用來確認(rèn)一個程序的品質(zhì)或性能是否符合開發(fā)之前所提出的一些要求。軟件測試的目的, 第一是確認(rèn)軟件的質(zhì)量, 其一方面是確認(rèn)軟件做了你所期望的事情（do the right thing）, 另一方面是確認(rèn)軟件以正確的方式來做了這個事件（do it right）；第二是提供信息, 比如提供給開發(fā)人員或程序經(jīng)理的反饋信息, 為風(fēng)險評估所準(zhǔn)備的信息；第三軟件測試不僅是在測試軟件產(chǎn)品的本身, 而且還包括軟件開發(fā)的過程。如果一個軟件產(chǎn)品開發(fā)完成之后發(fā)現(xiàn)了很多問題, 這說明此軟件開發(fā)過程很可能是有缺陷的。3.3 軟件測試的目的如果測試的目的是為了盡可能多地找出錯誤，那么測試就應(yīng)該直接針對軟件比較復(fù)雜的部分或是以前出錯比較多的位置。如果測試目的是為了給最終用戶提供具有一定可信度的質(zhì)量評價，那么測試就應(yīng)該直接針對在實際應(yīng)用中會經(jīng)常用到的商業(yè)假設(shè)。 在談到軟件測試時，引用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)生誤導(dǎo)，認(rèn)為發(fā)現(xiàn)錯誤是軟件測試的唯一目，查找不出錯誤的測試就是沒有價值的，事實并非如此。 首先，測試并不僅僅是為了要找出錯誤。通過分析錯誤產(chǎn)生的原因和錯誤的分布特征，可以幫助項目管理者發(fā)現(xiàn)當(dāng)前所采用的軟件過程的缺陷，以便改進(jìn)。同時，這種分析也能幫助我們設(shè)計出有針對性地檢測方法，改善測試的有效性。其次，沒有發(fā)現(xiàn)錯誤的測試也是有價值的，完整的測試是評定測試質(zhì)量的一種方法。3.4 軟件測試的原則1應(yīng)當(dāng)把 “盡早和不斷的測試”作為開發(fā)者的座右銘。 2程序員應(yīng)該避免檢查自己的程序, 測試工作應(yīng)該由獨立的專業(yè)的軟件測試機構(gòu)來完成。 3設(shè)計測試用例時應(yīng)該考慮到合法的輸入和不合法的輸入以及各種邊界條件, 特殊情況下要制造極端狀態(tài)和意外狀態(tài), 比如網(wǎng)絡(luò)異常中斷、電源斷電等情況。 4一定要注意測試中的錯誤集中發(fā)生現(xiàn)象, 這和程序員的編程水平和習(xí)慣有很大的關(guān)系。 5對測試錯誤結(jié)果一定要有一個確認(rèn)的過程, 一般有a測試出來的錯誤, 一定要有一個b來確認(rèn), 嚴(yán)重的錯誤可以召開評審會進(jìn)行討論和分析。 6制定嚴(yán)格的測試計劃, 并把測試時間安排的盡量寬松, 不要希望在極短的時間內(nèi)完成一個高水平的測試。 7回歸測試的關(guān)聯(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)品是否達(dá)到前階段確立的需求的過程；2.程序正確性的形式證明, 即采用形式理論證明程序符號設(shè)計規(guī)約規(guī)定的過程；3.評市、審查、測試、檢查、審計等各類活動, 或?qū)δ承╉椞幚?、服?wù)或文件等是否和規(guī)定的需求相一致進(jìn)行判斷和提出報告。4.2 確認(rèn)(validation)確認(rèn)(validation)是一系列的活動和過程, 目的是想證實在一個給定的外部環(huán)境中軟件的邏輯正確性。即保證軟件以正確的方式來做了這個事件(do it right)1.靜態(tài)確認(rèn), 不在計算機上實際執(zhí)行程序, 通過人工或程序分析來證明軟件的正確性；2.動態(tài)確認(rèn), 通過執(zhí)行程序做分析, 測試程序的動態(tài)行為, 以證實軟件是否存在問題。軟件測試的對象不僅僅是程序測試, 軟件測試應(yīng)該包括整個軟件開發(fā)期間各個階段所產(chǎn)生的文檔, 如需求規(guī)格說明、概要設(shè)計文檔、詳細(xì)設(shè)計文檔, 當(dāng)然軟件測試的主要對象還是源程序。5 軟件測試的分類5.1 常用分類從是否需要執(zhí)行被測軟件的角度, 可分為： 靜態(tài)測試 和動態(tài)測試 從測試是否針對系統(tǒng)的內(nèi)部結(jié)構(gòu)和具體實現(xiàn)算法的角度來看, 可分為 ： 白盒測試 和黑盒測試5.2 黑盒測試黑盒測試指的是把被測軟件看作是一個黑盒子, 我們不去關(guān)心盒子里面的結(jié)構(gòu)是什么樣子, 只關(guān)心軟件的輸入數(shù)據(jù)和輸出結(jié)果。黑盒測試方法是在程序接口上進(jìn)行測試, 主要是為了發(fā)現(xiàn)以下錯誤: 是否有不正確或遺漏了的功能? 在接口上, 輸入能否正確地接受? 能否輸出正確的結(jié)果? 是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息(例如數(shù)據(jù)文件)訪問錯誤? 性能上是否能夠滿足要求? 是否有初始化或終止性錯誤? 用黑盒測試發(fā)現(xiàn)程序中的錯誤, 必須在所有可能的輸入條件和輸出條件中確定測試數(shù)據(jù), 來檢查程序是否都能產(chǎn)生正確的輸出,但這是不可能的。證明：n假設(shè)一個程序p有輸入量x和y及輸出量z。在字長為32位的計算機上運行。若x、y取整數(shù), 按黑盒方法進(jìn)行窮舉測試：n可能采用的 測試數(shù)據(jù)組： 232232 264 n如果測試一組數(shù)據(jù)需要1毫秒, 一年工作365 24小時, 完成所有測試需5億年。5.2.1 黑盒測試的測試用例設(shè)計如手機的開機測試案例下表所示開機（power up）測試項目測試id操作描述預(yù)期結(jié)果實際結(jié)果(ok/ng/na)備注1 led燈pu-1-1關(guān)機狀態(tài)下長按掛機鍵led燈閃爍，顏色變換符合設(shè)計2 開機動畫pu-2-1關(guān)機狀態(tài)下長按掛機鍵開機動畫演示正常3 開機音樂pu-3-1關(guān)機狀態(tài)下長按掛機鍵開機音樂播放正常4 開機歡迎界面pu-4-1關(guān)機狀態(tài)下長按掛機鍵開機歡迎辭顯示正常5 sim卡檢查5.1 sim卡損壞或沒有sim卡插入pu-5.1-1關(guān)機狀態(tài)下長按掛機鍵開機動畫、開機音樂之后，顯示并停留在“請插入sim卡”版面pu-5.1-2關(guān)機狀態(tài)下長按掛機鍵,在“請插入sim卡”版面,按sos軟鍵進(jìn)入“緊急呼叫”5.2 啟動了pin檢驗pu-5.2-1關(guān)機狀態(tài)下長按掛機鍵開機動畫、開機音樂后出現(xiàn)“請輸入pin碼”版面pu-5.2-2“請輸入pin碼”版面，直接按確定軟鍵提示“最小長度是4”，并返回“請輸入pin碼”版面pu-5.2-3“請輸入pin碼”版面，按數(shù)字鍵可以進(jìn)行輸入，并顯示*pu-5.2-4“請輸入pin碼”版面，輸入13位數(shù)字，按確定軟鍵提示“最小長度是4”，并返回“請輸入pin碼”版面pu-5.2-5“請輸入pin碼”版面,輸入8位數(shù)字后繼續(xù)輸入提示“最大長度是8”，并返回“請輸入pin碼”版面pu-5.2-6“請輸入pin碼”版面，輸入48個數(shù)字的錯誤pin碼，按確定提示“錯誤pin碼”，然后返回“請輸入pin碼”畫面pu-5.2-7“請輸入pin碼”版面，輸入正確pin碼，按確定繼續(xù)開機流程5.3 sim卡pin1被鎖pu-5.3-1關(guān)機狀態(tài)下長按掛機鍵開機動畫、開機音樂之后，提示“pin1被鎖住”并最終顯示在“請輸入puk”版面pu-5.3-2在“請輸入puk”版面，直接按確定軟鍵提示“最小長度是4”，并返回“請輸入puk碼”版面pu-5.3-3在“請輸入puk”版面，按數(shù)字鍵可以進(jìn)行輸入，并顯示*pu-5.3-4在“請輸入puk”版面，輸入17位數(shù)字，按確定軟鍵提示“最小長度是8”，并返回“請輸入puk碼”版面pu-5.3-5在“請輸入puk”版面，輸入8位數(shù)字的錯誤puk碼，按確定軟鍵要求輸入兩次新pin碼后，提示“pin1被鎖住”，并返回“請輸入puk碼”版面pu-5.3-6在“請輸入puk”版面，輸入8位數(shù)字，繼續(xù)輸入提示“最大長度是8”，并返回“請輸入puk碼”版面pu-5.3-7在“請輸入puk”版面，輸入8位數(shù)字的正確puk碼，按確定軟鍵要求輸入兩次新pin碼，并成功解鎖，繼續(xù)開機流程6 手機密碼檢查pu-6-1關(guān)機狀態(tài)下長按掛機鍵開機動畫、開機音樂、pin檢驗之后，出現(xiàn)“輸入手機密碼”版面pu-6-2“輸入手機密碼”版面，直接按確定軟鍵提示“最小長度是4”，并返回“輸入手機密碼”版面pu-6-3“輸入手機密碼”版面，按數(shù)字鍵可以進(jìn)行輸入，并顯示*pu-6-4在“輸入手機密碼”版面，輸入13位數(shù)字，按確定軟鍵提示“最小長度是4”，并返回“輸入手機密碼”版面pu-6-5在“輸入手機密碼”版面，輸入4位錯誤手機密碼，按確定軟鍵提示“手機密碼錯誤”，并返回“輸入手機密碼”版面pu-6-6在“輸入手機密碼”版面，輸入8位數(shù)字，繼續(xù)輸入輸入無效pu-6-7在“輸入手機密碼”版面，輸入4位正確手機密碼，按確定軟鍵手機解鎖，繼續(xù)開機流程7 搜網(wǎng)pu-7-1關(guān)機狀態(tài)下長按掛機鍵開機動畫、音樂完畢；pin檢驗、手機密碼檢驗完畢，出現(xiàn)搜網(wǎng)畫面“正在搜網(wǎng)”，直到找到網(wǎng)絡(luò)注：其它語言下以上各功能運行正常測試說明：在測試中，必須對每個界面都要進(jìn)行觸屏的操作，因此測試次數(shù)為2次，即使用按鍵操作1次，使用觸屏操作1次，檢查功能是否正常.(如有側(cè)翻，合蓋操作界面也做以上相應(yīng)操作）5.2.2 等價劃分法等價類劃分是一種典型的黑盒測試方法，用這一方法設(shè)計測試用例完全不考慮程序的內(nèi)部結(jié)構(gòu)，只根據(jù)對程序的要求和說明，即需求規(guī)格說明書。我們必須仔細(xì)分析和推敲說明書的各項需求，特別是功能需求。把說明書中對輸入的要求和輸出的要求區(qū)別開來并加以分解。由于窮舉測試工作量太大，以至于無法實際完成，促使我們在大量的可能數(shù)據(jù)中選取其中的一部分作為測試用例。例如，在不了解等價分配計數(shù)的前提下，我們做計算器程序的加法測試時，測試了1+1，1+2，1+3和1+4之后，還有必要測試1+5和1+6嗎，能否放心地認(rèn)為它們是正確的？我們感覺1+5和1+6，與前面的1+1，1+2都是很類似的簡單加法。等價類劃分的方法是把程序的輸入域劃分成若干部分，然后從每個部分中選取少數(shù)代表性數(shù)據(jù)作為測試用例。每一類的代表性數(shù)據(jù)在測試中的作用等價于這一類中的其他值，也就是說，如果某一類中的一個例子發(fā)現(xiàn)了錯誤，這一等價類中的其他例子也能發(fā)現(xiàn)同樣的錯誤；反之，如果某一類中的一個例子沒有發(fā)現(xiàn)錯誤，則這一類中的其他例子也不會查出錯誤(除非等價類中的某些例子屬于另一等價類，因為幾個等價類是可能相交的)。使用這一方法設(shè)計測試用例，首先必須在分析需求規(guī)格說明的基礎(chǔ)上劃分等價類，列出等價類表。5.2.2.1 劃分等價類和列出等價類表等價類是指某個輸入域的子集合。在該子集合中，各個輸入數(shù)據(jù)對于發(fā)現(xiàn)程序中的錯誤都是等效的。并合理地假定：測試某個等價類的代表值就等于對這一類其他值的測試。因此，可以把全部輸入數(shù)據(jù)合理地劃分為若干等價類，在每一個等價類中取一個數(shù)據(jù)作為測試輸入條件，就可以用少量代表性的測試數(shù)據(jù)取得較好的測試結(jié)果。等價類劃分有兩種不同的情況：有效等價類和無效等價類。有效等價類：指對于程序的規(guī)格說明來說是合理的、有意義的輸入數(shù)據(jù)構(gòu)成的集合。利用有效等價類可以檢驗程序是否實現(xiàn)了規(guī)格說明中所規(guī)定的功能和性能。無效等價類：與有效等價類的定義相反。設(shè)計測試用例時，要同時考慮這兩種等價類。因為軟件不僅要能接收合理的數(shù)據(jù)，也要能經(jīng)受意外的考驗。這樣的測試才能確保軟件具有更好的可靠性。下面給出6條確定等價類的原則：在輸入條件規(guī)定了取值范圍或值的個數(shù)的情況下，可以確立一個有效等價類和兩個無效等價類。在輸入條件規(guī)定了輸入值的集合或者規(guī)定了“必須如何”的條件的情況下，可以確立一個有效等價類和一個無效等價類。在輸入條件是一個布爾量的情況下，可確定一個有效等價類和一個無效等價類。在規(guī)定了輸入數(shù)據(jù)的一組值(假定n個)，并且程序要對每一個輸入值分別處理的情況下，可確立n個有效等價類和一個無效等價類。在規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則的情況下，可確立一個有效等價類(符合規(guī)則)和若干個無效等價類(從不同角度違反規(guī)則)。在確知已劃分的等價類中，各元素在程序處理中的方式不同的情況下，則應(yīng)再將該等價類進(jìn)一步劃分為更小的等價類。在確立了等價類之后，建立等價類表，列出所有劃分出的等價類。5.2.2.2 確定測試用例根據(jù)已列出的等價類表，按以下步驟確定測試用例：為每個等價類規(guī)定一個唯一的編號。設(shè)計一個新的測試用例，使其盡可能多地覆蓋尚未覆蓋的有效等價類。重復(fù)這一步，最后使得所有有效等價類均被測試用例所覆蓋。設(shè)計一個新的測試用例，使其只覆蓋一個無效等價類。重復(fù)這一步使所有無效等價類均被覆蓋。在尋找等價區(qū)間時，設(shè)法把軟件的相似輸入、輸出、操作分成組，這些組就是等價區(qū)間。等價類的重要問題是它們構(gòu)成的集合的劃分，其中，劃分是指互不相交的一組子集，這些子集的并是整個集合。這對于測試有兩點非常重要的意義：表示整個集合這個事實提供了一種形式的完備性，而互不相交可保證一種形式的無冗余性。由于子集是由等價關(guān)系決定的，因此子集的元素都有一些共同點。等價類測試的思想是通過每個等價類中的一個元素標(biāo)識測試用例。如果廣泛選擇等價類，則這樣可以大大減低測試用例之間的冗余。為了便于理解，以下討論涉及有兩個變量x1和x2的函數(shù)f。如果函數(shù)f實現(xiàn)為一個程序，則輸入變量x1和x2將擁有以下邊界，以及邊界內(nèi)的區(qū)間：ax1d，區(qū)間為a，b)，b，c)，c，d ex2g，區(qū)間為e，f)，f，g其中方括號和圓括號分別表示閉區(qū)間和開區(qū)間的端點。x1，x2的無效值是x1d，x2g。以此作為例子，我們將進(jìn)一步討論等價類劃分法。5.2.2.3 弱一般等價類測試采用上面給出的標(biāo)記，弱一般等價類測試通過一個測試用例中的每個等價類(區(qū)間)的一個變量實現(xiàn)(請注意單邊假設(shè)作用)。對于前面給出的例子，可得到如下圖所示的弱等價類測試用例。由函數(shù)的定義可知，帶陰影的矩形中的任何點都是函數(shù)f的有效輸入。這三個測試用例使用每個等價類中的一個值。我們以對稱方式標(biāo)識這些測試用例，于是得到外在的模式。事實上，永遠(yuǎn)都有等量的弱等價類測試用例，因為劃分中的類對應(yīng)最大子集數(shù)。5.2.2.4 強一般等價類測試強一般等價類測試基于多缺陷假設(shè)，因此需要等價類笛卡爾積的每個元素對應(yīng)的測試用例，如下圖所示：請注意，這些測試用例的模式與命題邏輯中的真值表構(gòu)造具有相似性。笛卡爾積可以保證兩種意義上的“完備性”：一是覆蓋所有的等價類，二是有可能的輸入組合中的一個。事實上，“好的”等價類測試的關(guān)鍵是等價關(guān)系的選擇。注意被“相同處理”的輸入。在大多數(shù)情況下，等價類測試定義輸入定義域的類。沒有理由不能根據(jù)被測程序函數(shù)的輸出值域定義等價關(guān)系，我們可以看到，這對于三角形問題是最簡單的方法。5.2.2.5 弱健壯等價類測試這種測試的名稱顯然與直覺矛盾，且自相矛盾。怎么能夠既弱又健壯呢？說它健壯，是因為這種測試考慮了無效值；說它弱，是因為有單缺陷假設(shè)。1、對于有效輸入，使用每個有效類的一個值。(就像我們在所謂弱一般等價類測試中所做的一樣。請注意，這些測試用例中的所有輸入都是有效的。)2、對于無效輸入，測試用例將擁有一個無效值，并保持其余的值都是等效的。(因此，“單缺陷”會造成測試用例失敗。)按照這種策略產(chǎn)生的測試用例如下圖所示：健壯等價類測試有兩個問題。第一個問題是，規(guī)格說明常常并沒有定義無效測試用例所預(yù)期的輸出是什么。(我們可以把這看作是規(guī)格說明的不足，但是這并不能解決問題。)因此，測試人員需要花費大量時間定義這些測試用例的輸出。第二個問題是，強類型語言沒有必要考慮無效輸入。傳統(tǒng)等價類測試是諸如fortran和cobol這樣的語言占統(tǒng)治地位的年代的產(chǎn)物，因此那時這種錯誤很常見。事實上，正是由于經(jīng)常出現(xiàn)這種錯誤，才促使人們實現(xiàn)強類型語言。對于第二個問題，應(yīng)該是指對于純編程語言而言的。在實際的項目中，由于人的因素(人總會犯錯誤，即使編程語言本身再怎么完美，諸如java、python、c+這樣的強類型語言，也無法避免)，以及業(yè)務(wù)的具體要求，無效輸入往往要考慮業(yè)務(wù)因素，所以任何時刻都必須考慮無效輸入。5.2.2.6 強健壯等價類測試至少這種測試的名稱既不與直覺矛盾，也不自相矛盾，只是有些冗余。像以前的定義一樣，健壯是指要考慮無效值，強是指多缺陷假設(shè)。我們從所有的等價類笛卡爾積的每個元素中獲得測試用例，如下圖所示：下面我們將結(jié)合三角形問題，來實際應(yīng)用等價類劃分的方法。三角形問題是這樣的經(jīng)典，以至于雖然大家都知道它是經(jīng)典問題，面試和筆試中還是會遇到。例題：根據(jù)下面給出的規(guī)格說明，利用等價類劃分的方法，給出足夠的測試用例?！耙粋€程序讀入3個整數(shù)，把這3個數(shù)值看作一個三角形的3條邊的長度值。這個程序要打印信息，說明這個三角形是不等邊的、是等腰的、是等邊的，或者不能構(gòu)成三角形”。在描述問題時，我們提到有四種可能出現(xiàn)的輸出：非三角形、不等邊三角形、等腰三角形和等邊三角形?？梢允褂眠@些輸出標(biāo)識如下所示的輸出(值域)等價類：r1=：有三條邊a、b和c的等邊三角形r2=：有三條邊a、b和c的等腰三角形r3=：有三條邊a、b和c的不等邊三角形r4=：三條邊a、b和c的不構(gòu)成三角形四個弱一般等價類測試用例是：弱一般等價類測試用例測試用例abc預(yù)期輸出wn1555等邊三角形wn2223等腰三角形wn3345不等邊三角形wn4412非三角形由于a、b和c沒有有效區(qū)間，則強一般等價類測試用例與弱一般等價類測試用例相同?？紤]a、b和c的無效值產(chǎn)生的以下額外弱健壯等價類測試用例：額外弱健壯等價類測試用例測試用例abc預(yù)期輸出wr1-155a取值不在所允許的取值值域內(nèi)wr25-15b取值不在所允許的取值值域內(nèi)wr355-1c取值不在所允許的取值值域內(nèi)wr420155a取值不在所允許的取值值域內(nèi)wr552015b取值不在所允許的取值值域內(nèi)wr655201c取值不在所允許的取值值域內(nèi)以下是額外強健壯等價類測試用例三維立方的一個“角”：額外強健壯等價類測試用例測試用例abc預(yù)期輸出sr1-155a取值不在所允許的取值值域內(nèi)sr25-15b取值不在所允許的取值值域內(nèi)sr355-1c取值不在所允許的取值值域內(nèi)sr4-1-15a、b取值不在所允許的取值值域內(nèi)sr55-1-1b、c取值不在所允許的取值值域內(nèi)sr6-15-1a、c取值不在所允許的取值值域內(nèi)sr7-1-1-1a、b、c取值不在所允許的取值值域內(nèi)請注意，預(yù)期輸出如何完備地描述無效輸入值。等價類測試顯然對用來定義類的等價關(guān)系很敏感。如果在輸入定義域上定義等價類，則可以得到更豐富的測試用例集合。三個整數(shù)a、b和c有些什么可能的取值呢？這些整數(shù)可以相等，有一對整數(shù)相等(有三種相等方式)，或都不相等。d1=：a=b=c，d2=：a=b，ac，d3=：a=c，abd4=：b=c，ab，d5=：ab，ac，bc作為一個單獨的問題，我們可以通過三角形的性質(zhì)來判斷三條邊是否構(gòu)成一個三角形。(例如，三元組有一對相等的邊，但是這些邊不構(gòu)成一個三角形。)d6=：ab+c，d7=：ba+c，d8=：ca+b如果我們要徹底一些，可以將“大于或等于”分解為兩種不同的情況，這樣d6就變成d6=：a=b+c，d6=：ab+c，同樣對于d7和d8也有類似的情況。列出等價類表，如下所示：等價類表輸入條件有效等價類無效等價類是否三角形的3邊（a0） (1)(a0) （7）(b0) (2)(b0) (8)(c0) (3)(c0) (9)(a+bc) (4)(a+bc) (10)(b+ca) (5)(b+ca) (11)(a+cb) (6)(a+cb) (12)是否等腰三角形（a=b） (13)（ab）and(bc)and (ac) （16）(b=c) (14)(a=c) (15)是否等邊三角形（a=b）and(b=c)and (a=c) （17）（ab） (18)(bc) (19)(ac) (20)設(shè)計測試用例：輸入順序是a，b，c，如下表所示：設(shè)計測試用例表序號a，b，c覆蓋等價類輸出13,4,5(1),(2),(3),(4),(5),(6)不能構(gòu)成三角形20,1,2(7)31,0,2(8)41,2,0(9)51,2,3(10)61,3,2(11)73,1,2(12)83,3,4(1),(2),(3),(4),(5),(6),(13)等腰三角形93,4,4(1),(2),(3),(4),(5),(6),(14)103,4,3(1),(2),(3),(4),(5),(6),(15)113,4,5(1),(2),(3),(4),(5),(6),(16)非等腰三角形123,3,3(1),(2),(3),(4),(5),(6),(17)等邊三角形133,4,4(1),(2),(3),(4),(5),(6),(14),(18)非等邊三角形143,4,3(1),(2),(3),(4),(5),(6),(15),(19)153,3,4(1),(2),(3),(4),(5),(6),(13),(20)等價分配的目標(biāo)是把可能的測試用例組合縮減到仍然足以滿足軟件測試需求為止。因為，了選擇不完全測試，就要冒一定的風(fēng)險，所以必須仔細(xì)選擇分類。5.3 白盒測試白盒測試指的是把盒子蓋打開, 去研究里面的源代碼和程序結(jié)構(gòu)。白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試, 它是知道產(chǎn)品內(nèi)部工作過程, 可通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進(jìn)行, 按照程序內(nèi)部的結(jié)構(gòu)測試程序, 檢驗程序中的每條通路是否都有能按預(yù)定要求正確工作, 而不顧它的功能。 使用被測單元內(nèi)部如何工作的信息, 允許測試人員對程序內(nèi)部邏輯結(jié)構(gòu)及有關(guān)信息來設(shè)計和選擇測試用例, 對程序的邏輯路徑進(jìn)行測試?；谝粋€應(yīng)用代碼的內(nèi)部邏輯知識, 測試是基于覆蓋全部代碼、分支、路徑、條件。 白盒測試的主要方法： 邏輯驅(qū)動測試 基本路徑測試 主要用于軟件驗證。 使用程序設(shè)計的控制結(jié)構(gòu)導(dǎo)出測試用例。 邏輯驅(qū)動測試：主要是測試覆蓋率, 以程序內(nèi)在邏輯結(jié)構(gòu)為基礎(chǔ)的測試。包括以下6種類型： 語句覆蓋 判斷覆蓋 條件覆蓋 判定-條件覆蓋 條件組合覆蓋 路徑覆蓋 白盒測試的主要目的 保證一個模塊中的所有獨立路徑至少被執(zhí)行一次； 對所有的邏輯值均需要測試真、假兩個分支； 在上下邊界及可操作范圍內(nèi)運行所有循環(huán)；檢查內(nèi)部數(shù)據(jù)結(jié)構(gòu)以確保其有效性 白盒測試的實施方案 在開發(fā)階段要保證產(chǎn)品的質(zhì)量, 產(chǎn)品的生產(chǎn)過程應(yīng)該遵循一定的行業(yè)標(biāo)準(zhǔn)。軟件產(chǎn)品也是同樣, 沒有標(biāo)準(zhǔn)可依自然談不上質(zhì)量的好壞。所有關(guān)心軟件開發(fā)質(zhì)量的組織、單位, 都要定義或了解軟件的質(zhì)量標(biāo)準(zhǔn)、模型。其好處是保證公司實踐的均勻性, 產(chǎn)品的可維護性、可靠性以及可移植性等。 在測試階段與軟件產(chǎn)品的開發(fā)過程一樣, 測試過程也需要有一定的準(zhǔn)則, 來指導(dǎo)、度量、評價軟件測試過程的質(zhì)量。定義測試準(zhǔn)則為控制測試的有效性以及完成程度, 必須定義準(zhǔn)則和策略, 以判斷何時結(jié)束測試階段。準(zhǔn)則必須是客觀的, 可量化的元素, 而不能是經(jīng)驗或感覺。 根據(jù)應(yīng)用的準(zhǔn)則和項目相關(guān)的約束, 項目領(lǐng)導(dǎo)可以定義使用的度量方法和需要達(dá)到的覆蓋率, 度量測試的有效性、完整性對每個測試的測試覆蓋信息和累計信息, 用圖形方式顯示覆蓋比率, 并根據(jù)測試運行情況實時更新, 隨時顯示新的測試所反映的測試覆蓋情況。允許所有的測試運行依據(jù)其有效性進(jìn)行管理, 用戶可以減少不適用于非回歸測試的測試的過程。 概念：1.語句覆蓋：語句覆蓋就是設(shè)計若干個測試用例, 運行被測試程序, 使得每一條可執(zhí)行語句至少執(zhí)行一次； 2.判定覆蓋（也稱為分支覆蓋）：設(shè)計若干個測試用例, 運行所測程序, 使程序中每個判斷的取真分支和取假分支至少執(zhí)行一次；3.條件覆蓋：設(shè)計足夠多的測試用例, 運行所測程序, 使程序中每個判斷的每個條件的每個可能取值至少執(zhí)行一次； 4.判定-條件覆蓋：設(shè)計足夠多的測試用例, 運行所測程序, 使程序中每個判斷的每個條件的所有可能取值至少執(zhí)行一次, 并且每個可能的判斷結(jié)果也至少執(zhí)行一次, 換句話說, 即是要求各個判斷的所有可能的條件取值組合至少執(zhí)行一次； 5.條件組合測試：設(shè)計足夠多的測試用例, 運行所測程序, 使程序中每個判斷的所有可能的條件取值組合至少執(zhí)行一次； 6.路徑測試：設(shè)計足夠多的測試用例, 運行所測程序, 要覆蓋程序中所有可能的路徑。5.4 靜態(tài)測試是指不實際運行被測軟件, 而只是靜態(tài)的檢查程序代碼、界面或文檔中可能存在的錯誤的過程。其中包括代碼測試、界面測試和文檔測試3個方面。對于代碼測試, 主要測試代碼是否符合相應(yīng)的標(biāo)準(zhǔn)和規(guī)范。對于界面測試, 主要測試軟件的實際界面與需求中的說明是否相符。對于文檔測試, 主要測試用戶手冊和需求說明是否符合用戶的實際要求。5.5 動態(tài)測試是指實際運行被測程序, 輸入相應(yīng)的測試數(shù)據(jù), 檢查實際輸出結(jié)果和預(yù)期結(jié)果是否相符的過程。所以, 我們判斷一個測試屬于動態(tài)還是靜態(tài)測試 , 唯一的標(biāo)準(zhǔn)就是看是否運行程序。6 軟件測試中的類測試面向?qū)ο筌浖暮暧^上來看是各個類之間的相互作用。在面向?qū)ο笙到y(tǒng)中,系統(tǒng)的基本構(gòu)造模塊是封裝了的數(shù)據(jù)和方法的類和對象,而不再是一個個能完成特定功能的功能模塊。每個對象有自己的生存周期,有自己的狀態(tài)。消息是對象之間相互請求或協(xié)作的途徑,是外界使用對象方法及獲取對象狀態(tài)的唯一方式。對象的功能是在消息的觸發(fā)下,由對象所屬類中定義的方法與相關(guān)對象的合作共同完成,且在不同狀態(tài)下對消息的響應(yīng)可能完全不同。對象中的數(shù)據(jù)和