【正文】 ，你沒有辦法停下來，腦子里有一個聲音在說，向前，向前。 從軟件生命周期的最初階段就開始關(guān)注所有的測試文檔并保持文檔更新。 （ 5）測試放在最后 低估測試和測試所需的資源將導致在開發(fā)周期的末期才開始測試活動，而在那時要發(fā)現(xiàn)關(guān)鍵 Bug也將變的異常困難，并且由于時間的限 制測試文檔的相關(guān)細節(jié)也會有所忽略。 采取措施以建立測試環(huán)境并保障它便于管理。在市場上，不少測試工具都可以度量測試覆蓋率。還有一個因素是不充分的測試數(shù)據(jù)將無法覆蓋所有可能的范圍。在需求中可能隱藏著數(shù)不清的潛在問題，而這在測試人員瀏覽需求時可能被忽略，因此在測試的起步階段徹底理解需求是十分必要的。而一個正確的測試計劃則決定于可靠的評估。這兩年來國內(nèi)軟件測試人員的需求不斷增大 ,越來越多的 IT企業(yè)認識到了軟件測試的重要性 ,這種可喜的現(xiàn)狀與發(fā)展趨勢讓筆者對我國軟件業(yè)的發(fā)展重新抱有較大的希望。因此，在這種環(huán)境下，軟件測試很不受重視，軟件測試人員的地位和待遇自然就很低了，甚至軟件測試變得可有可無。因為縮短測試時間帶來的測試不完整，對項目質(zhì)量的下降引起的潛在風險，往往造成更大的浪費。對于測試中發(fā)現(xiàn)的軟件錯誤，很多需要程序員通過修改編碼才能修復。所以，具有編程經(jīng)驗的程序員不一定是一名優(yōu)秀的測試工程師。 (3)軟件測試要求不高，隨便找個人都行 很多人都認為軟件測試就是安裝和運行程序，點點鼠標，按按鍵盤的工作。軟件中的錯誤可能來自軟件項目中的各個過程，軟件測試只能確認軟件存在錯誤，不能保證軟件沒有錯誤，因為從根本上講，軟件測試不可能 發(fā)現(xiàn)全部的錯誤。軟件開發(fā)與軟件測試應(yīng)該 是交互進行的，例如，單元編碼需要單元測試，模塊組合階段需要集成測試。軟件測試是一個系列過程活動，包括軟件測試 需求分析，測試計劃設(shè)計，測試用例設(shè)計，執(zhí)行測試。系統(tǒng)界面上打印出 “ Try Again[Y/N]____” 期望結(jié)果：屏幕上會打印出 “ Try Again[Y/N]____” （ 2）路徑 2：（ bcdefghkl）的測試用例 輸入數(shù)據(jù)：變量 speed小于或等于 50或者是變量 Right_rate小于或等于 80，變量 ch_2等于 “ n” 或者 “ N ” 期望結(jié)果：跳出此處，返回主界面 （ 3）路徑 3：（ bcdefijkl）的測試用例 輸入數(shù)據(jù)：變量 speed小于或等于 50或者是變量 Right_rate小于或等于 80，變量 ch_2等于 “ y” 或者 “ Y ” 期望結(jié)果：繼續(xù)回到打字練習的界面 （ 4）路徑 4：（ mnttv）的測試用例 輸入數(shù)據(jù)：系統(tǒng)界面上打印出 “ Well Done!! One More Time?[Y/N] ” 期望結(jié)果：屏幕上會出現(xiàn) “ Well Done!! One More Time?[Y/N] ” （ 5）路徑 5：（ mnopqsuv）的測試用例 輸入數(shù)據(jù)：變量 ch_3等于 “ n” 或者 “ N” 期望結(jié)果：跳出此處，返回主界面 江西信息應(yīng)用職業(yè)技術(shù)學院計算機 軟件 專業(yè)畢業(yè)論文 第 23 頁 共 29 頁 （ 6）路徑 6：（ mnoprtuv）的測試用例 輸入數(shù)據(jù)：變量 ch_3等于 “ y” 或者 “ Y” 期望結(jié)果：繼續(xù)回到打字練習的界面 做完以上的工作后，得必須注意的是，一些獨立的路徑，往往還不是完全孤立的，有時它是程序正常的控制流的一部分，這時，這些路徑的測試可以是另一條路徑測試的一部分。 V(G)值正好等于該程序的獨立路徑的條數(shù)。獨立路徑必須包含一條在定義之前不曾用到的邊。一條邊必須終止于一個結(jié)點，即使該結(jié)點并不代表任何語句 (例如： ifelsethen 結(jié)構(gòu) )。 1．畫出打字程序的控制流程圖 流程圖用來描述程序控制結(jié)構(gòu)。如果沿定義 /使用路徑跟蹤程序的執(zhí)行情況，則這些結(jié)點并不很重要。 我們根據(jù)圖 42 給出的一個程序的控制流圖，其中每個語句的定義 /使用變量由表 43給出，下面我們來看看詳細的表 43，并對其結(jié)果做出分析 江西信息應(yīng)用職業(yè)技術(shù)學院計算機 軟件 專業(yè)畢業(yè)論文 第 20 頁 共 29 頁 通過變量的定義 /引用分析，可以發(fā)現(xiàn)該程序中含有幾個數(shù)據(jù)流異常： 語句 1， 2對變量 i的定義未曾被使用過 語句 11使用了變量 Timeyser,但在執(zhí)行時并未對其定義過 語句 14使用了變量 ctime，而在其之前并未對其進行定義（賦值） 經(jīng)過上面的分析，發(fā)現(xiàn)程序中包含有些異常，有些語句執(zhí)行還有錯誤，不過這一情況表明， 也許程序中含有錯誤，也許可 以把程序?qū)懙母菀桌斫?，從而能夠簡化驗證 工作，以及隨后的維護工作（去掉那些多余的語句一般會縮短執(zhí)行時間） 定義 /使用測試 假設(shè) V是程序 P中變量的集合，程序 P的控制流圖用 G(P)表示。由于索引表信息是有編譯器生成的，因此這些異常可以通過所謂景泰分析發(fā)現(xiàn)，即在不執(zhí)行被測程序的情況下發(fā)現(xiàn)源代碼的一些數(shù)據(jù)流異常。早期的數(shù)據(jù)流分析常常集中于現(xiàn)在叫做定義 /引用異常缺陷，如： 變量被定義，但從來沒有被使用（引用）。 測試步驟 需要列出所測試類的調(diào)用關(guān)系和關(guān)鍵方法的調(diào)用關(guān)系（依據(jù)數(shù)據(jù)流）。 通過的準則 測試通過主要依照以下標準： 打 字程序需求報告，需求規(guī)格說明書測試通過的標準：需求報告及需求規(guī)格說明書文檔中描述的正確性，無異性。 第三章 系統(tǒng)白盒測試實例的實現(xiàn) 測試的目的 測試主要為打字系統(tǒng)的白盒測試。 數(shù)字練習模塊：由系統(tǒng)隨機調(diào)用文檔 ，以程序中要求取出字符數(shù)輸出到界面，由用戶輸入，程序判斷用戶練習的速度 ,時間 ,正確率等數(shù)據(jù)。目前用于測試的工具一般可分為白盒測試工具、黑盒測試工具、性能測試工具，另外還有用于測試管理（測試流程管理、缺陷跟蹤管理、測試用例管理）的工具。 ④缺點：由于路徑覆蓋需要對所有可能的路徑進行測試（包括循環(huán)、條件組合、分支選擇等），那么需要設(shè)計大量、復雜的測試用例，使得工作量呈指數(shù)級增長。并且每個條件都顯示能單獨影響判定結(jié)果。 ④缺點：判定 /條件覆蓋準則的缺點是未考慮條件的組合情況。 ④缺點：要達到條件覆蓋，需要足夠多的測試用例，但條件覆蓋并不能保證判定 覆蓋。同樣判定覆蓋也具有和語句覆蓋一樣的簡單性，無須細分每個判定就可以得到測試用例。那么顯然，語句覆蓋對于多分支的邏輯運算是無法全面反映的，它只在乎運行一次，而不考慮其他情況。在本例中去掉了語句 1— 〉 T去掉，那么就少了一條測試路徑。（本文以 1995 年軟件設(shè)計師考試的一道考試題目為例，圖中紅色字母代表程序執(zhí)行路徑）。 （ 6）只涉及接口和一些抽象的測試方法，將測試程序移入抽象的測試類。在具體的測試程序?qū)崿F(xiàn)中繼承這個測試類，并修改相應(yīng)的實現(xiàn)方法。這種通用接口測試方法，解決了接口測試時重復編寫類似功能代碼的問題，提供了一種新的描述不同命令 結(jié)構(gòu)的思路。邏輯測試不是片面的測試正確的結(jié)果或是測試錯誤的結(jié)果，而是盡可能全面地覆蓋每一個邏輯路徑。但是貫穿在程序內(nèi)部的邏輯存在著不確定性和無窮性，尤其對于大規(guī)模復雜軟件。無法檢測代碼中遺漏的路徑和數(shù)據(jù)敏感性錯誤 。揭示隱藏在代碼中的錯誤 。動態(tài)分析包含了程序在受控的環(huán)境下使用特定的期望結(jié)果進行正式的運行。 白盒測試的方法： 總體上分為靜態(tài)方法和動態(tài)方法兩大類。 白盒測試的特點：依據(jù)軟件設(shè)計說明書進行測試、對程序內(nèi)部細節(jié)的嚴密檢驗、針對特定條件設(shè)計測試用例、對軟件的邏輯路徑進行覆蓋測試。由于代碼中的筆誤是隨機且無法杜絕的，因此我們要進行白盒測試。因此需求分析、概要設(shè)計、詳細設(shè)計以及程序編碼等各階段所得到的文檔，包括需求規(guī)格說明、概要設(shè)計規(guī)格說明、詳細設(shè)計規(guī)格說明以及源程序，都應(yīng)該是軟件測試（評審）的對象。應(yīng)當對每一個測試結(jié)果做全面的檢查 。經(jīng)驗表明，測試后程序殘存的錯誤數(shù)目與該程序中已發(fā)現(xiàn)的錯誤數(shù)目或檢錯率成正比。測試用例的設(shè)計要確保能覆蓋所有可能路徑?？梢圆捎?Junit 和 Jtest來輔助進行單元測試 。 軟件測試在軟件生命周期中橫跨兩個階段：通常在編寫出每一個模塊之后就需要對它做必要的測試（稱為單元測試）。有錯是軟件的屬性，而且是無法改變的，因為軟件是由人來完成的，所有由人做的工作都不會是完美無缺的。在一些關(guān)鍵應(yīng)用 (如民航訂票系統(tǒng)、銀行結(jié)算系統(tǒng)、證券交易系統(tǒng)、自動飛行控制軟件、軍事防御和核電站安全控制系統(tǒng)等 ) 中使用質(zhì)量有問題的軟件 ，還可能造成災(zāi)難性的后果。 第二部分：本文相關(guān)項目的案例分析和測試規(guī)劃，打字練習程序白盒測試的測試思路和測試方案設(shè)計 第三部分：打字練習程序白盒測試的具體實現(xiàn)細則 關(guān)鍵字：黑盒測試，白盒測試，測試管理，測試樁，測試點 江西信息應(yīng)用職業(yè)技術(shù)學院計算機 軟件 專業(yè)畢業(yè)論文 第 3 頁 共 29 頁 引言 信息技術(shù)的飛速發(fā)展，使軟件產(chǎn)品應(yīng)用到社會的各個領(lǐng)域， 軟件產(chǎn)品的質(zhì)量自然成為人們共同關(guān)注的焦點。 軟件測試的核心是測試思維，你的思維能深入到什么程度，測試就能做到什么程度，本次課題旨在訓練我們的測試思維，同時通過本次的課題實例掌握測試流程與技巧，為我們成為真正的測試人員打下堅實的基礎(chǔ)。這些經(jīng)驗教訓迫使軟件開發(fā)者們必須添加一個相應(yīng)的流程，并在此流程中 采取強有力的檢測措施來檢測未發(fā)現(xiàn)的隱藏的軟件缺陷，也就是軟件測試。 本文的展開將通過以下三個部分： 第一部分：白盒測試及黑盒測試技術(shù)的相關(guān)介紹，市場上主流測試管理工具的對比分析。質(zhì)量不佳的軟件產(chǎn)品不僅會使開發(fā)商的維護費用和用戶的使用成本大幅增加，還可能產(chǎn)生其他的責任風險，造成公司信譽下降，繼而沖擊股票市場?，F(xiàn)在人們已經(jīng)逐步認識到所謂的軟件危機實際上僅是一種狀況，那就是軟件中有錯誤，正是這些錯誤導致了軟件開發(fā)在成本、進度和質(zhì)量上的失控。 軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行 程序的過程。 軟件測試的目的： 測試的最終目的是為了避免錯誤的發(fā)生，確保應(yīng)用程序能夠正常高效的運行；好的測試用例在于發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤；成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試；好的測試工程師應(yīng)該做到不僅發(fā)現(xiàn)問題， 還能夠幫助開發(fā)人員分析問題； 軟件測試的原則： 應(yīng)把 “ 盡早和不斷地進行軟件測試 ” 作為軟件開發(fā)者的座右銘，實踐證明單元測試能夠盡早發(fā)現(xiàn)問題，減少后期測試的錯誤量。（指后期系統(tǒng)測試階段，不包括單元測試） 。充分注意測試中的群集現(xiàn)象。測試計劃應(yīng)包括：所測軟件的功能，輸入和輸出，測試內(nèi)容，各項測試的進度安排，資源要求，測試資料，測試工具，測試用例的選擇，測試的控制方法和過程，系統(tǒng)的配置方式，跟蹤規(guī)則，調(diào)試規(guī)則，以及回歸測試的規(guī)定等等以及評價標準 。軟件測試應(yīng)該貫穿整個軟件定義與開發(fā)整個期間。由于我們經(jīng)常相信某邏輯 路徑不可能被執(zhí)行 , 而事實上 ,它可能在正常的情況下被執(zhí)行。 白盒的測試用例需要做到： (1)保證一個模塊中的所有獨立路徑至少被使用一次 (2)檢查內(nèi)部數(shù)據(jù)結(jié)構(gòu)以確保其有效性 白盒測試的目的：通過檢查軟件內(nèi)部的邏輯結(jié)構(gòu)，對軟件中的邏輯路徑進行覆蓋測試；在程 序不同地方設(shè)立檢查點，檢查程序的狀態(tài)，以確定實際運行狀態(tài)與預期狀態(tài)是否一致。 測試總結(jié)階段：對比測試的結(jié)果和代碼的預期結(jié)果，分析錯誤原因，找到并解決錯誤。 動態(tài)分析的主要特點是當軟件系統(tǒng)在模擬的或真實的環(huán)境中執(zhí)行之前、之中和之后 , 對軟件系統(tǒng)行為的分析。可以檢測代碼中的每條分支和路 徑 。 缺點：昂貴 。只有對程序內(nèi)部十分了解才能進行適度有效的白盒測試。任何一個高效的測試用例，都是針對具體測試場景的。 接口測試 定義通用的命令接口結(jié)構(gòu)，用文本文件記錄接口相關(guān)結(jié)構(gòu)信息，通過對該文本文件進行逐行的語法解析，將文件中的描述轉(zhuǎn)化為統(tǒng)一結(jié)構(gòu)的鏈表，驗證來自外層的數(shù)據(jù)是否正確，以及根據(jù)提示用戶輸入的信息驗證發(fā)送到其它層的數(shù)據(jù)是否正確。 （ 2）個抽象的測試類，聲明要驗證的功能的測試方法。 （ 5）要在測試中調(diào)用的抽象方法。 白盒測試六種覆蓋方法 首先為了下文的舉例描述方便，這里先給出一張程序流程圖。 ④缺點：由于這種測試方法僅僅針對程序邏輯中顯式存在的語句，但對于隱藏的條件和可能到達的隱式邏輯分支，是無法測試的。再如，在 DoWhil