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

1、軟件測試的概述及方法Meteor指導(dǎo)教師姓名 _職稱 _專業(yè)名稱_計(jì)算機(jī)網(wǎng)絡(luò)專業(yè) _論文提交日期 _論文答辯日期 _2012年4月30日軟件測試的概述及方法MeteorXX大學(xué),重慶400715摘要：從軟件產(chǎn)業(yè)的發(fā)展初期到目前的大型軟件開發(fā)過程， 軟件測試已成為其中一個不 可分割的部分。隨著軟件規(guī)模的日益增大， 軟件測試問題也日益突出， 現(xiàn)代社會對軟件的依 賴越來越強(qiáng)，高可信軟件測試有著廣泛的需求，基于缺陷模式的軟件測試技術(shù)作為高可信軟 件的重要保證,可以大大降低軟件的缺陷密度，提高軟件的可信性。本文從測試的基本概念入 手,深入剖析軟件測試相關(guān)理論。關(guān)鍵字：軟件測試、白盒測試、黑盒測試、類測試

2、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 He

3、tzel在軟件測試完全指南中指出：測試是以 評價一個程序或者系統(tǒng)屬性為目標(biāo)的任何一種活動，測試是對軟件質(zhì)量的度量。20世紀(jì)90年代，測試工具盛行起來，1996年提出的測試能力成熟度 TCMM(Testi ng Cap ability Maturity Model)、測試支持度 TS( TestabilitySupportModel)、測試成熟度 TMM(Testing Maturity Model )。到了 2002年，Rick 和 Stefan在系統(tǒng)的軟件測試一書中對軟件測試做了進(jìn)一步定義：測試是為了 度量和提高被測軟件的質(zhì)量，對測試軟件進(jìn)行工程設(shè)計(jì)、實(shí)施和維護(hù)的整個生命 過程。2軟件測試的

4、相關(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)境中走上實(shí)際運(yùn)用開 發(fā)的時候，事實(shí)上真的不是那么一回事。軟件無處不在，然而，軟件是人編的一 所以不完美。臭名昭著的軟件測試案例：1、迪士尼的獅子王 （19941995）軟件在少數(shù)系統(tǒng)中能正常工作,但在大 眾使用的常見系統(tǒng)中不行。后來證實(shí)，迪士尼公司沒有對市場上投入實(shí)用的各種 pc機(jī)型進(jìn)行正確的測試。2、英特爾奔騰浮點(diǎn)除法軟件缺陷（19

5、94）英特爾為自己處理軟件缺陷拿出 4億美元支付更換壞芯片的費(fèi)用。導(dǎo)致付出如此昂貴的代價，其主要原因是發(fā)現(xiàn) 了軟件缺陷沒有正確的處理。3、 美國航天局火星極地登陸（1999）該項(xiàng)目使用前有經(jīng)過測試,兩個測試 小組雙方獨(dú)立工作都很好，但從未走在一起。4、 愛國者導(dǎo)彈防御系統(tǒng) （1991） 一枚導(dǎo)彈在多哈擊斃28名美國士兵,癥 結(jié)在于一個軟件缺陷：一個很小的系統(tǒng)時鐘錯誤累積起來就可能拖延14小時， 造成跟蹤系統(tǒng)失去準(zhǔn)確度。在多哈襲擊戰(zhàn)中系統(tǒng)被拖延 100小時。5、 千年蟲（大約1974）估計(jì)世界各地更換或升級該系統(tǒng)程序解決原有2000 年錯誤的費(fèi)用已經(jīng)超過數(shù)億美元。3軟件測試的概述3.1軟件測試的

6、定義軟件測試使用人工或者自動手段來運(yùn)行或測試某個系統(tǒng)的過程，其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別。它是幫助識別開發(fā)完成（中間或最終的版本）的計(jì)算機(jī)軟件（整體或部分）的正確度 （correctness）完全度（completeness）和質(zhì)量（quality） 的軟件過程；是SQA（software quality assura nee）的重要子域。(1)測試并不僅僅是為了找出錯誤，通過分析錯誤產(chǎn)生的原因和錯誤的發(fā)生 趨勢，可以幫助項(xiàng)目管理者發(fā)現(xiàn)當(dāng)前軟件開發(fā)過程中的缺陷，以便及時改進(jìn)；(2)這種分析也能幫助測試人員設(shè)計(jì)出有針對性的測試方法，改善測試的效率和有效性；

7、(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ā)

8、過程很可能是有缺陷的。3.3軟件測試的目的如果測試的目的是為了盡可能多地找出錯誤，那么測試就應(yīng)該直接針對軟件比較復(fù)雜的部分或是以前出錯比較多的位置。如果測試目的是為了給最終用戶提供具有一定可信度的質(zhì)量評價，那么測試就應(yīng)該直接針對在實(shí)際應(yīng)用中會經(jīng)常用 到的商業(yè)假設(shè)。在談到軟件測試時，引用 Grenford J. Myers 在The Art ofSoftware Testi ng一書中的觀點(diǎn)：(1)軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的 過程；(2)測試是為了證明程序有錯，而不是證明程序無錯誤；(3) 個好的測試用例是在于它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤；(4) 一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試

9、。這種觀點(diǎn)可以提醒人們測試要以查找錯誤為中心，而不是為了演示軟件的正確功能。但是僅憑字面意思理解這一觀點(diǎn)可能會產(chǎn)生誤導(dǎo)， 認(rèn)為發(fā)現(xiàn)錯誤是軟件測試的唯一目，查找不出錯誤的測試就是沒有價值的，事實(shí)并非如此。 首先，測試并不僅僅是為了要找出錯誤。 通過分析錯誤產(chǎn)生的原因 和錯誤的分布特征，可以幫助項(xiàng)目管理者發(fā)現(xiàn)當(dāng)前所采用的軟件過程的缺陷，以便改進(jìn)。同時，這種分析也能幫助我們設(shè)計(jì)出有針對性地檢測方法，改善測試的有效性。其次，沒有發(fā)現(xiàn)錯誤的測試也是有價值的， 完整的測試是評定測試質(zhì)量 的一種方法。3.4軟件測試的原則1 應(yīng)當(dāng)把“盡早和不斷的測試”作為開發(fā)者的座右銘。2.程序員應(yīng)該避免檢查自己的程序，測試

10、工作應(yīng)該由獨(dú)立的專業(yè)的軟件測 試機(jī)構(gòu)來完成。3 .設(shè)計(jì)測試用例時應(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)格的測試計(jì)劃，并把測試時間安排的盡量寬松，不要希望在極短 的時間內(nèi)完成一個高水平的測試。7. 回歸測試的關(guān)聯(lián)性一定要引起充分的注意，修改一個錯誤而引起更多的 錯誤出現(xiàn)的現(xiàn)象并不少見。8

11、.妥善保存一切測試過程文檔，意義是不言而喻的，測試的重現(xiàn)性往往要 靠測試文檔4軟件測試的內(nèi)容4.1 驗(yàn)證(verificatio n)驗(yàn)證(verificatio n)是保證軟件正確地實(shí)現(xiàn)了一些特定功能的一系列活動, 即保證軟件做了你所期望的事情。(Do the right thi ng)1.確定軟件生存周期中的一個給定階段的產(chǎn)品是否達(dá)到前階段確立的需求 的過程；2.程序正確性的形式證明，即采用形式理論證明程序符號設(shè)計(jì)規(guī)約規(guī)定的 過程；3.評市、審查、測試、檢查、審計(jì)等各類活動，或?qū)δ承╉?xiàng)處理、服務(wù)或文 件等是否和規(guī)定的需求相一致進(jìn)行判斷和提出報(bào)告。4.2 確認(rèn)(validation)確認(rèn)(v

12、alidation) 是一系列的活動和過程，目的是想證實(shí)在一個給定的外 部環(huán)境中軟件的邏輯正確性。即保證軟件以正確的方式來做了這個事件(Do itright)1.靜態(tài)確認(rèn)，不在計(jì)算機(jī)上實(shí)際執(zhí)行程序，通過人工或程序分析來證明軟 件的正確性；2.動態(tài)確認(rèn)，通過執(zhí)行程序做分析，測試程序的動態(tài)行為，以證實(shí)軟件是 否存在問題。軟件測試的對象不僅僅是程序測試，軟件測試應(yīng)該包括整個軟件開發(fā)期間 各個階段所產(chǎn)生的文檔，如需求規(guī)格說明、概要設(shè)計(jì)文檔、詳細(xì)設(shè)計(jì)文檔，當(dāng)然 軟件測試的主要對象還是源程序。5軟件測試的分類5.1常用分類從是否需要執(zhí)行被測軟件的角度，可分為：靜態(tài)測試和動態(tài)測試從測試是否針對系統(tǒng)的內(nèi)部結(jié)構(gòu)

13、和具體實(shí)現(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和丫及輸

14、出量 乙在字長為32位的計(jì)算機(jī)上運(yùn) 行。若X、丫取整數(shù)，按黑盒方法進(jìn)行窮舉測試：n可能采用的 測試數(shù)據(jù)組： 232 X 232 = 264 n如果測試一組數(shù)據(jù) 需要1毫秒,一年工作365X 24小時,完成所有測試需5億年。5.2.1黑盒測試的測試用例設(shè)計(jì)如手機(jī)的開機(jī)測試案例下表所示開機(jī)(Power UP)測試項(xiàng)目測試ID操作描述預(yù)期結(jié)果實(shí)際結(jié)果(OK/NG/NA)備注1 LED 燈PU-1-1關(guān)機(jī)狀態(tài)下長按掛機(jī)鍵LED燈閃爍， 顏色變換符合 設(shè)計(jì)2開機(jī)動畫PU-2-1關(guān)機(jī)狀態(tài)下長按掛機(jī)鍵開機(jī)動畫演示正常3開機(jī)音樂PU-3-1關(guān)機(jī)狀態(tài)下長按 掛機(jī)鍵開機(jī)音樂播放 正常4開機(jī)歡迎界 面PU-4-1關(guān)

15、機(jī)狀態(tài)下長按掛機(jī)鍵開機(jī)歡迎辭顯示正常5.1 SIM卡損壞或沒有SIM卡插入PU-5.1-1關(guān)機(jī)狀態(tài)下長按掛機(jī)鍵開機(jī)動畫、開 機(jī)音樂之后， 顯示并停留在“請插入SIM 卡”版面PU-5.1-2關(guān)機(jī)狀態(tài)下長按 掛機(jī)鍵,在“請 插入SIM卡”版 面，按SOS軟鍵進(jìn)入“緊急呼 叫”PU-5.2-1關(guān)機(jī)狀態(tài)下長按 掛機(jī)鍵開機(jī)動畫、開 機(jī)音樂后出現(xiàn)“請輸入PIN 碼”版面PU-5.2-2“請輸入PIN 碼”版面，直接按確定軟鍵提示“最小長 度是4”，并 返回“請輸入 PIN碼”版面PU-5.2-3“請輸入PIN 碼”版面，按數(shù) 字鍵可以進(jìn)行輸 入，并顯示*PU-5.2-4“請輸入PIN 碼”版面，輸入 1

16、3位數(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ù)開機(jī)流程PU-5.3-1關(guān)機(jī)狀態(tài)下長按 掛機(jī)鍵開機(jī)動畫、開 機(jī)音樂之后， 提示“PIN1被 鎖住”并最終 顯示在“請輸 入PUK版面PU-5.3-2在“請輸入PUK 版面，直接按確定軟鍵提

17、示“最小長 度是4”，并 返回“請輸入 PUK碼”版面5 SIM 卡 檢 查5.2啟動 了 PIN 檢 驗(yàn)5.3 SIM 卡 PIN1 被鎖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”，并 返回“請

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

19、誤手機(jī)密 碼，按確定軟鍵提示“手機(jī)密 碼錯誤”，并 返回“輸入手 機(jī)密碼”版面PU-6-6在“輸入手機(jī)密 碼”版面，輸入 8位數(shù)字，繼續(xù) 輸入輸入無效6手機(jī)密碼檢 查PU-6-7在“輸入手機(jī)密 碼”版面，輸入手機(jī)解鎖，繼 續(xù)開機(jī)流程4位正確手機(jī)密 碼，按確定軟鍵7搜網(wǎng)PU-7-1關(guān)機(jī)狀態(tài)下長按掛機(jī)鍵開機(jī)動畫、音 樂完畢；PIN 檢驗(yàn)、手機(jī)密 碼檢驗(yàn)完畢， 出現(xiàn)搜網(wǎng)畫面“正在搜網(wǎng)”， 直到找到網(wǎng)絡(luò)注：其它語言下以上各功能運(yùn)行正常測試說明：在測試中，必須對每個界面都要進(jìn)行觸屏的操作，因此測試次數(shù)為 2次，即使用按鍵操作1次，使用觸屏操作1次，檢查功能是否正常.（如有側(cè)翻，合蓋操作界面也做 以上相應(yīng)

20、操作）5.2.2等價劃分法等價類劃分是一種典型的黑盒測試方法，用這一方法設(shè)計(jì)測試用例完全不考 慮程序的內(nèi)部結(jié)構(gòu)，只根據(jù)對程序的要求和說明，即需求規(guī)格說明書。我們必須 仔細(xì)分析和推敲說明書的各項(xiàng)需求，特別是功能需求。把說明書中對輸入的要求 和輸出的要求區(qū)別開來并加以分解。由于窮舉測試工作量太大，以至于無法實(shí)際完成，促使我們在大量的可能數(shù) 據(jù)中選取其中的一部分作為測試用例。例如，在不了解等價分配計(jì)數(shù)的前提下， 我們做計(jì)算器程序的加法測試時，測試了 1+1, 1+2, 1+3和1+4之后，還有必要 測試1+5和1+6嗎，能否放心地認(rèn)為它們是正確的？我們感覺 1+5和1+6,與前 面的1+1，1+2都

21、是很類似的簡單加法。等價類劃分的方法是把程序的輸入域劃分成若干部分，然后從每個部分中選取少數(shù)代表性數(shù)據(jù)作為測試用例。每一類的代表性數(shù)據(jù)在測試中的作用等價于這 一類中的其他值，也就是說，如果某一類中的一個例子發(fā)現(xiàn)了錯誤， 這一等價類 中的其他例子也能發(fā)現(xiàn)同樣的錯誤； 反之，如果某一類中的一個例子沒有發(fā)現(xiàn)錯 誤，則這一類中的其他例子也不會查出錯誤（除非等價類中的某些例子屬于另一 等價類，因?yàn)閹讉€等價類是可能相交的）。使用這一方法設(shè)計(jì)測試用例，首先必 須在分析需求規(guī)格說明的基礎(chǔ)上劃分等價類，列出等價類表。522.1劃分等價類和列出等價類表等價類是指某個輸入域的子集合。在該子集合中，各個輸入數(shù)據(jù)對于發(fā)

22、現(xiàn)程 序中的錯誤都是等效的。并合理地假定：測試某個等價類的代表值就等于對這一 類其他值的測試。因此，可以把全部輸入數(shù)據(jù)合理地劃分為若干等價類，在每一個等價類中取 一個數(shù)據(jù)作為測試輸入條件，就可以用少量代表性的測試數(shù)據(jù)取得較好的測試結(jié) 果。等價類劃分有兩種不同的情況：有效等價類和無效等價類。有效等價類：指對于程序的規(guī)格說明來說是合理的、有意義的輸入數(shù)據(jù)構(gòu)成 的集合。利用有效等價類可以檢驗(yàn)程序是否實(shí)現(xiàn)了規(guī)格說明中所規(guī)定的功能和性 能。無效等價類：與有效等價類的定義相反。設(shè)計(jì)測試用例時，要同時考慮這兩種等價類。因?yàn)檐浖粌H要能接收合理的 數(shù)據(jù)，也要能經(jīng)受意外的考驗(yàn)。這樣的測試才能確保軟件具有更好的可

23、靠性。下面給出6條確定等價類的原則： 在輸入條件規(guī)定了取值范圍或值的個數(shù)的情況下，可以確立一個有效等價 類和兩個無效等價類。 在輸入條件規(guī)定了輸入值的集合或者規(guī)定了 “必須如何”的條件的情況 下，可以確立一個有效等價類和一個無效等價類。 在輸入條件是一個布爾量的情況下，可確定一個有效等價類和一個無效等 價類。 在規(guī)定了輸入數(shù)據(jù)的一組值（假定n個），并且程序要對每一個輸入值分別 處理的情況下，可確立n個有效等價類和一個無效等價類。 在規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則的情況下，可確立一個有效等價類（符合規(guī)則）和若干個無效等價類（從不同角度違反規(guī)則）。在確知已劃分的等價類中，各元素在程序處理中的方式不同

24、的情況下，則 應(yīng)再將該等價類進(jìn)一步劃分為更小的等價類。在確立了等價類之后，建立等價類表，列出所有劃分出的等價類。522.2 確定測試用例根據(jù)已列出的等價類表，按以下步驟確定測試用例： 為每個等價類規(guī)定一個唯一的編號。 設(shè)計(jì)一個新的測試用例，使其盡可能多地覆蓋尚未覆蓋的有效等價類。重 復(fù)這一步，最后使得所有有效等價類均被測試用例所覆蓋。 設(shè)計(jì)一個新的測試用例，使其只覆蓋一個無效等價類。重復(fù)這一步使所有 無效等價類均被覆蓋。在尋找等價區(qū)間時，設(shè)法把軟件的相似輸入、輸出、操作分成組，這些組就 是等價區(qū)間。等價類的重要問題是它們構(gòu)成的集合的劃分，其中，戈扮是指互不相交的一 組子集，這些子集的并是整個集

25、合。這對于測試有兩點(diǎn)非常重要的意義： 表示整 個集合這個事實(shí)提供了一種形式的完備性，而互不相交可保證一種形式的無冗余 性。由于子集是由等價關(guān)系決定的，因此子集的元素都有一些共同點(diǎn)。 等價類測 試的思想是通過每個等價類中的一個元素標(biāo)識測試用例。如果廣泛選擇等價類， 則這樣可以大大減低測試用例之間的冗余。為了便于理解，以下討論涉及有兩個變量 X1和X2的函數(shù)F。如果函數(shù)F實(shí) 現(xiàn)為一個程序，則輸入變量 X1和X2將擁有以下邊界，以及邊界內(nèi)的區(qū)間：aX1d，區(qū)間為a，b），b，c），c，deX2g，區(qū)間為e，f），f，g其中方括號和圓括號分別表示閉區(qū)間和開區(qū)間的端點(diǎn)。X1, X2的無效值是X1d, X

26、2以此作為例子，我們將進(jìn)一步討論等價類劃分法。522.3 弱一般等價類測試采用上面給出的標(biāo)記，弱一般等價類測試通過一個測試用例中的每個等價類（區(qū)間）的一個變量實(shí)現(xiàn)（請注意單邊假設(shè)作用）。對于前面給出的例子，可得到如 下圖所示的弱等價類測試用例。1i ii -1 !t 1卜-1-廠a b由函數(shù)的定義可知，帶陰影的矩形中的任何點(diǎn)都是函數(shù) F的有效輸入。這三 個測試用例使用每個等價類中的一個值。 我們以對稱方式標(biāo)識這些測試用例，于 是得到外在的模式。事實(shí)上，永遠(yuǎn)都有等量的弱等價類測試用例， 因?yàn)閯澐种械?類對應(yīng)最大子集數(shù)。5.2.2.4 強(qiáng)一般等價類測試強(qiáng)一般等價類測試基于多缺陷假設(shè)，因此需要等價類

27、笛卡爾積的每個元素對應(yīng)的測試用例，如下圖所示：X2jI呂一1 1 1 11 ! ! 1f-1 4 - 1-! 1 ! e 11 1 1 1 宀1II11abcd強(qiáng)一股第價類測iA用例請注意，這些測試用例的模式與命題邏輯中的真值表構(gòu)造具有相似性。笛卡 爾積可以保證兩種意義上的“完備性”： 一是覆蓋所有的等價類，二是有可能的 輸入組合中的一個。事實(shí)上，“好的”等價類測試的關(guān)鍵是等價關(guān)系的選擇。注意被“相同處 理”的輸入。在大多數(shù)情況下，等價類測試定義輸入定義域的類。 沒有理由不能 根據(jù)被測程序函數(shù)的輸出值域定義等價關(guān)系，我們可以看到，這對于三角形問題是最簡單的方法。5.2.2.5弱健壯等價類測試這

28、種測試的名稱顯然與直覺矛盾，且自相矛盾。怎么能夠既弱又健壯呢？說 它健壯，是因?yàn)檫@種測試考慮了無效值；說它弱，是因?yàn)橛袉稳毕菁僭O(shè)。1對于有效輸入，使用每個有效類的一個值。（就像我們在所謂弱一般等價 類測試中所做的一樣。請注意，這些測試用例中的所有輸入都是有效的。）2、對于無效輸入，測試用例將擁有一個無效值，并保持其余的值都是等效 的。（因此，“單缺陷”會造成測試用例失敗。）按照這種策略產(chǎn)生的測試用例如下圖所示：1 1 1 1g f11 1 丨-4 -1 1-*1 1 1 丨e 1 1 1 *1 r1111abcd弱贈壯晞價類測逛用例健壯等價類測試有兩個問題。第一個問題是，規(guī)格說明常常并沒有定義

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

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

31、數(shù)，把這3個數(shù)值看作一個三角形的3條邊的長度 值。這個程序要打印信息，說明這個三角形是不等邊的、是等腰的、是等邊的， 或者不能構(gòu)成三角形”。在描述問題時，我們提到有四種可能出現(xiàn)的輸出：非三角形、不等邊三角形、 等腰三角形和等邊三角形?？梢允褂眠@些輸出標(biāo)識如下所示的輸出 （值域）等價 類：R仁:有三條邊a b和c的等邊三角形R2=:有三條邊a b和c的等腰三角形R3=:有三條邊a b和c的不等邊三角形R4=:三條邊a、b和c的不構(gòu)成三角形四個弱一般等價類測試用例是：弱一般等價類測試用例測試用例abc預(yù)期輸出WN1555等邊三角形WN2223等腰三角形WN3345不等邊三角形WN4412非三角形由

32、于a、b和c沒有有效區(qū)間，則強(qiáng)一般等價類測試用例與弱一般等價類測試用 例相同。考慮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)以下是額外強(qiáng)健壯等價類測試用例三維立方的一個“角”：額外強(qiáng)健壯等價類測試用例測試用例abc預(yù)期輸出SR1-155a取值不在所允許的取值值域內(nèi)SR25-15b取值

33、不在所允許的取值值域內(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,

34、 a bD4=: b=c, ab, D5=: ab, ac, bc作為一個單獨(dú)的問題，我們可以通過三角形的性質(zhì)來判斷三條邊是否構(gòu)成一個三 角形。（例如，三元組有一對相等的邊，但是這些邊不構(gòu)成一個三角形。）D6=: ab+c, D7=: ba+c, D8=: ca+b如果我們要徹底一些，可以將“大于或等于”分解為兩種不同的情況，這樣D6就變成D6 =: a=b+c, D6 =: ab+c，同樣對于 D7和 D8也有 類似的情況。列出等價類表，如下所示：等價類表輸入條件有效等價類無效等價類(A0)(1)(A w 0)(7)(B0)(B w 0)(8)是否三角形的3邊(C0)(C w 0)(9)(A

35、+BC)(4)(A+Bw C)(10)(B+CA)(5)(B+Cw A)(11)(A+CB)(6)(A+Cw B)(12)是否等腰三角形(A=B)(13)(AM B) and(B工 C)and (A 工(B=C)(A=C)(14)(15)C)(16)(A=B) and(B=C)and (A=C)(AM B)(18)是否等邊三角形（17）(B 豐 C)(19)(A 豐 C)(20)設(shè)計(jì)測試用例:輸入順序是A, B, C，如卜表所示：設(shè)計(jì)測試用例表序號A , B, C覆蓋等價類輸出13,4,5(1),(2),(3),(4) ,(5),(6)20,1,2(7)31,0,2(8)41,2,0(9)不能

36、構(gòu)成三角形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)

37、,(15),(19)153,3,4(1),(2),(3),(4),(5),(6),(13),(20)等價分配的目標(biāo)是把可能的測試用例組合縮減到仍然足以滿足軟件測試需求為 止。因?yàn)?，了選擇不完全測試，就要冒一定的風(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)程序中的每條通路是否都有能按預(yù)定要求正確工作 ， 而不顧它的功能。 使用被測單元內(nèi)部如何工作的信息，允許測試人員對程序內(nèi) 部邏輯結(jié)

38、構(gòu)及有關(guān)信息來設(shè)計(jì)和選擇測試用例，對程序的邏輯路徑進(jìn)行測試?；?于一個應(yīng)用代碼的內(nèi)部邏輯知識，測試是基于覆蓋全部代碼、分支、路徑、條件。白盒測試的主要方法：?邏輯驅(qū)動測試?基本路徑測試主要用于軟件驗(yàn)證。使用程序設(shè)計(jì)的控制結(jié)構(gòu)導(dǎo)出測試用例。邏輯驅(qū)動測試：主要是測試覆蓋率，以程序內(nèi)在邏輯結(jié)構(gòu)為基礎(chǔ)的測試。包括以下6種類型：?語句覆蓋?判斷覆蓋?條件覆蓋?判定-條件覆蓋?條件組合覆蓋?路徑覆蓋白盒測試的主要目的?保證一個模塊中的所有獨(dú)立路徑至少被執(zhí)行一次；?對所有的邏輯值均需要測試真、假兩個分支；?在上下邊界及可操作范圍內(nèi)運(yùn)行所有循環(huán)；?檢查內(nèi)部數(shù)據(jù)結(jié)構(gòu)以確保其有效性白盒測試的實(shí)施方案在開發(fā)階段要保

39、證產(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)、模型。其好處是保證公司實(shí)踐的均勻性， 產(chǎn)品的可維護(hù)性、可靠性以及可移植性等。在測試階段與軟件產(chǎn)品的開發(fā)過程一樣，測試過程也需要有一定的準(zhǔn)則，來指導(dǎo)、度 量、評價軟件測試過程的質(zhì)量。定義測試準(zhǔn)則為控制測試的有效性以及完成程度，必須定義準(zhǔn)則和策略，以判斷何時結(jié) 束測試階段。準(zhǔn)則必須是客觀的，可量化的元素，而不能是經(jīng)驗(yàn)或感覺。根據(jù)應(yīng)用的準(zhǔn)則和項(xiàng)目相關(guān)的約束，項(xiàng)目領(lǐng)導(dǎo)可以定義使用的度量方法和 需要達(dá)到的覆蓋率，度量測試的有效性、完整

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

41、，使程序中每個判斷的每個條件的所有可能取值至少執(zhí)行一次，并且每個可能的判斷結(jié)果也至少執(zhí)行一次，換句話說，即是要求各個判斷的所有可能的條件取值組合至少執(zhí)行一次；5.條件組合測試：設(shè)計(jì)足夠多的測試用例，運(yùn)行所測程序，使程序中每個判 斷的所有可能的條件取值組合至少執(zhí)行一次；6.路徑測試：設(shè)計(jì)足夠多的測試用例，運(yùn)行所測程序，要覆蓋程序中所有可 能的路徑。5.4靜態(tài)測試是指不實(shí)際運(yùn)行被測軟件，而只是靜態(tài)的檢查程序代碼、界面或文檔中可能 存在的錯誤的過程。其中包括代碼測試、界面測試和文檔測試3個方面。對于代碼測試，主要測 試代碼是否符合相應(yīng)的標(biāo)準(zhǔn)和規(guī)范。對于界面測試，主要測試軟件的實(shí)際界面與 需求中的說明是否相符。對于文檔測試，主要測試用戶手冊和需求說明是否符合 用戶的實(shí)際要求。5.5動態(tài)測試是指實(shí)際運(yùn)行被測程序，輸入相應(yīng)的測試數(shù)據(jù)，檢查實(shí)際輸出結(jié)果和預(yù)期 結(jié)果是否相符的過程。所以，我們判斷一個測試屬于動態(tài)還是靜態(tài)測試，唯一的標(biāo)準(zhǔn)就是看是否運(yùn)行程序。6軟件測試中的類測試面向?qū)ο筌浖暮暧^上來看是各個類之間的相互作用。在面向?qū)ο笙到y(tǒng)中，系統(tǒng)的基本構(gòu)造模塊是封裝了的數(shù)據(jù)和方法的類和對象，而不再是一個個能完成 特定功能的功能模塊。每個對象有自己的生存周期 ，有自己的狀態(tài)。消息是對象 之間相互請求或協(xié)作的途徑，是外界使用對象方法及獲取對象狀態(tài)的唯一方式。 對象