【正文】 在此，我向老師表示衷心的感謝 ! 最后向所有曾給予我鼓勵和幫助的而在這里沒有提及的老師、同學(xué)、朋友以及參考文獻的作者們表示最高的敬意 ! 其次深深感謝的是我們的指導(dǎo)老師 —— 賀曉敏 。軟件測試不僅要講究策略，更要講究時效性。不可重現(xiàn)的 BUG也可以提交，只要是注明這個 BUG不容易重現(xiàn)，以面他人誤會，這樣既不浪費開發(fā)人員的時間，也不讓一個 BUG漏掉。在交流時要讓別人聽得進你的 “ 忠言逆耳 ” ，你宙斯好不要作興師問罪狀，前面有一個引子較好，慢慢道來。 在提交 BUG 之前，查詢一下 BUG 庫或者和相關(guān)的同事做一個簡短的交流，盡量不提交重復(fù)的 BUG。興奮起來后，人的理智便下降了，人的所見所聞可能與實際情況有所差異。所以測試管理人員必須經(jīng)常做測試計劃和用例的更新。 如何處理？ 詳細認真的面對測試文檔，在所有測試階段中，測試文檔都是一個非常重要的工作。只有測試組擁有 測試環(huán)境的控制權(quán)，并且未經(jīng)過測試組的允許，任何人都不能改變測試環(huán)境。測試覆蓋率只是衡量測試質(zhì)量的一個方面，如果無法達到高 覆蓋率，那就必須對此進行強化和鞏固。測試計劃和評估表明了測試執(zhí)行的順序和方式以及它們所需要的資源。項目的成功往往靠個別全能程序員決定，他們負責(zé)總體設(shè)計和程序詳細設(shè)計 ，認為軟件開發(fā)就是編寫代碼，給人的印象往往是程序員是真正的牛人，具有很高的地位和待遇。另外，對于單元測試主要應(yīng)該由程序員完成，必要時測試人員可以幫助設(shè)計測試樣例。應(yīng)該分析軟件項目的各個過程，從過程改進方面尋找產(chǎn)生錯誤的原因和改進的措施。軟件測試的對象不僅僅是軟件代碼，還包括軟件需求文檔和設(shè)計文檔。amp。 圖 46 打字程序計算模塊代碼程序控制流程圖 江西信息應(yīng)用職業(yè)技術(shù)學(xué)院計算機 軟件 專業(yè)畢業(yè)論文 第 22 頁 共 29 頁 圈復(fù)雜度是一種為程序邏輯復(fù)雜性提供定量測度的軟件度量，將該度量用于計算程序的基本的獨立路徑數(shù)目，為 確保所有語句至少執(zhí)行一次的測試數(shù)量的上界。 變量 Right_char的定義 /使用路徑 變量 Right_char 有兩個定義結(jié)點 和兩個使用結(jié)點 DEF(Right_char,3) 和DEF(Right_char,31)以及 USE(Right_char,31)和 USE(Right_char,44)，產(chǎn)生了 3條定義 /使用路徑： P1=3,4,5,```````````````,31 P2=31,31 P3=31,44 基本路徑測試 根據(jù)基本路徑測試的方法，我們將先給出打字程序的數(shù)據(jù)控制流程圖。所謂的數(shù)據(jù)流分析是指在不運行被測程序的情況下，對變量的定義、引用進行分析，以檢測數(shù)據(jù)的賦值與引用之間是否出現(xiàn)了不合理的現(xiàn)象，如引用未賦值的變量，對以前未曾使用變量的再次賦值 等數(shù)據(jù)流異常現(xiàn)象。 測試實施 接口測試 江西信息應(yīng)用職業(yè)技術(shù)學(xué)院計算機 軟件 專業(yè)畢業(yè)論文 第 15 頁 共 29 頁 (1) 被測試對象（單元）的介紹 接口 A： 用戶選擇模塊中用戶選擇所要練習(xí)的模塊，由參數(shù)傳至具體模塊 接口 B：用戶選擇退出，由參數(shù)傳至退出模塊 接口 C： 用戶自定義練習(xí)數(shù)據(jù)，數(shù)據(jù)庫內(nèi)容相對更新 (2) 測試范圍與目的 檢查參數(shù)傳送的正確性及函數(shù)的正確性 (3)測試輔助工具的描述 操作系統(tǒng)： Microsoft Windows xp Professional 2021 CHS 運行平臺： Microsoft Visual Studio 2021 (4) 接口測試用例 接口 A：如表 接口 B：如表 接口 C：如表 江西信息應(yīng)用職業(yè)技術(shù)學(xué)院計算機 軟件 專業(yè)畢業(yè)論文 第 16 頁 共 29 頁 江西信息應(yīng)用職業(yè)技術(shù)學(xué)院計算機 軟件 專業(yè)畢業(yè)論文 第 17 頁 共 29 頁 江西信息應(yīng)用職業(yè)技術(shù)學(xué)院計算機 軟件 專業(yè)畢業(yè)論文 第 18 頁 共 29 頁 江西信息應(yīng)用職業(yè)技術(shù)學(xué)院計算機 軟件 專業(yè)畢業(yè)論文 第 19 頁 共 29 頁 數(shù)據(jù)流測試 數(shù)據(jù)流測試是指關(guān)注變量定義點和使用（或引用）點的一種結(jié)構(gòu)測試方式，它和數(shù)據(jù)流圖沒有什么聯(lián)系，實際上，很多數(shù)據(jù)流測試支持者和研究人員將這種測試方法看做是一種路徑測試。 測試項 所要測試的測試項： 打字程序需求報告，需求規(guī)格說明書； 打字程序詳細設(shè)計文檔； 打字程序代碼編寫規(guī)范； 代碼中變量的命名標(biāo)準(zhǔn)； 打字程序界面規(guī)范。 江西信息應(yīng)用職業(yè)技術(shù)學(xué)院計算機 軟件 專業(yè)畢業(yè)論文 第 12 頁 共 29 頁 第二章 項目分析與規(guī)劃測試 項目分析 主要功能模塊 英文練習(xí)模塊：由系統(tǒng)隨機調(diào)用文檔 ，以程序中要求取出字符數(shù)輸出到界面，由用戶輸入，程序判斷用戶練習(xí)的速度 ,時間 ,正確率等數(shù)據(jù)。 ②用例設(shè)計 (如表 )： ③優(yōu)點：這種測試方法可以對程序進行徹底的測試，比前面五種的覆蓋面都廣。 ②用例設(shè)計 (如表 )： ③優(yōu)點：判定 /條件覆蓋滿足判定覆蓋準(zhǔn)則和條件覆蓋準(zhǔn)則，彌補了二者的不足。 ②用例設(shè)計 (如表 )： 江西信息應(yīng)用職業(yè)技術(shù)學(xué)院計算機 軟件 專業(yè)畢業(yè)論文 第 9 頁 共 29 頁 ③優(yōu)點：判定覆蓋比語句覆蓋要多幾乎一倍的測試路徑，當(dāng)然也就具有比語句覆蓋更強的測試能力。 ④缺點：由于這種測試方法僅僅針對程序邏輯中顯式存在的語句，但對于隱藏的條件和可能到達的隱式邏輯分支，是無法測試的。 （ 5）要在測試中調(diào)用的抽象方法。 接口測試 定義通用的命令接口結(jié)構(gòu)，用文本文件記錄接口相關(guān)結(jié)構(gòu)信息，通過對該文本文件進行逐行的語法解析，將文件中的描述轉(zhuǎn)化為統(tǒng)一結(jié)構(gòu)的鏈表，驗證來自外層的數(shù)據(jù)是否正確，以及根據(jù)提示用戶輸入的信息驗證發(fā)送到其它層的數(shù)據(jù)是否正確。只有對程序內(nèi)部十分了解才能進行適度有效的白盒測試。可以檢測代碼中的每條分支和路 徑 。 測試總結(jié)階段：對比測試的結(jié)果和代碼的預(yù)期結(jié)果，分析錯誤原因，找到并解決錯誤。由于我們經(jīng)常相信某邏輯 路徑不可能被執(zhí)行 , 而事實上 ,它可能在正常的情況下被執(zhí)行。測試計劃應(yīng)包括：所測軟件的功能，輸入和輸出，測試內(nèi)容，各項測試的進度安排，資源要求，測試資料，測試工具，測試用例的選擇，測試的控制方法和過程，系統(tǒng)的配置方式，跟蹤規(guī)則，調(diào)試規(guī)則，以及回歸測試的規(guī)定等等以及評價標(biāo)準(zhǔn) 。（指后期系統(tǒng)測試階段，不包括單元測試） 。 軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行 程序的過程。質(zhì)量不佳的軟件產(chǎn)品不僅會使開發(fā)商的維護費用和用戶的使用成本大幅增加，還可能產(chǎn)生其他的責(zé)任風(fēng)險，造成公司信譽下降，繼而沖擊股票市場。這些經(jīng)驗教訓(xùn)迫使軟件開發(fā)者們必須添加一個相應(yīng)的流程，并在此流程中 采取強有力的檢測措施來檢測未發(fā)現(xiàn)的隱藏的軟件缺陷，也就是軟件測試。 第二部分：本文相關(guān)項目的案例分析和測試規(guī)劃，打字練習(xí)程序白盒測試的測試思路和測試方案設(shè)計 第三部分：打字練習(xí)程序白盒測試的具體實現(xiàn)細則 關(guān)鍵字：黑盒測試，白盒測試，測試管理，測試樁，測試點 江西信息應(yīng)用職業(yè)技術(shù)學(xué)院計算機 軟件 專業(yè)畢業(yè)論文 第 3 頁 共 29 頁 引言 信息技術(shù)的飛速發(fā)展，使軟件產(chǎn)品應(yīng)用到社會的各個領(lǐng)域， 軟件產(chǎn)品的質(zhì)量自然成為人們共同關(guān)注的焦點。有錯是軟件的屬性，而且是無法改變的，因為軟件是由人來完成的，所有由人做的工作都不會是完美無缺的?？梢圆捎?Junit 和 Jtest來輔助進行單元測試 。經(jīng)驗表明，測試后程序殘存的錯誤數(shù)目與該程序中已發(fā)現(xiàn)的錯誤數(shù)目或檢錯率成正比。因此需求分析、概要設(shè)計、詳細設(shè)計以及程序編碼等各階段所得到的文檔，包括需求規(guī)格說明、概要設(shè)計規(guī)格說明、詳細設(shè)計規(guī)格說明以及源程序，都應(yīng)該是軟件測試（評審）的對象。 白盒測試的特點：依據(jù)軟件設(shè)計說明書進行測試、對程序內(nèi)部細節(jié)的嚴(yán)密檢驗、針對特定條件設(shè)計測試用例、對軟件的邏輯路徑進行覆蓋測試。動態(tài)分析包含了程序在受控的環(huán)境下使用特定的期望結(jié)果進行正式的運行。無法檢測代碼中遺漏的路徑和數(shù)據(jù)敏感性錯誤 。邏輯測試不是片面的測試正確的結(jié)果或是測試錯誤的結(jié)果，而是盡可能全面地覆蓋每一個邏輯路徑。在具體的測試程序?qū)崿F(xiàn)中繼承這個測試類，并修改相應(yīng)的實現(xiàn)方法。（本文以 1995 年軟件設(shè)計師考試的一道考試題目為例，圖中紅色字母代表程序執(zhí)行路徑）。那么顯然，語句覆蓋對于多分支的邏輯運算是無法全面反映的，它只在乎運行一次，而不考慮其他情況。 ④缺點：要達到條件覆蓋，需要足夠多的測試用例，但條件覆蓋并不能保證判定 覆蓋。并且每個條件都顯示能單獨影響判定結(jié)果。目前用于測試的工具一般可分為白盒測試工具、黑盒測試工具、性能測試工具，另外還有用于測試管理（測試流程管理、缺陷跟蹤管理、測試用例管理）的工具。 第三章 系統(tǒng)白盒測試實例的實現(xiàn) 測試的目的 測試主要為打字系統(tǒng)的白盒測試。 測試步驟 需要列出所測試類的調(diào)用關(guān)系和關(guān)鍵方法的調(diào)用關(guān)系（依據(jù)數(shù)據(jù)流）。由于索引表信息是有編譯器生成的，因此這些異常可以通過所謂景泰分析發(fā)現(xiàn)，即在不執(zhí)行被測程序的情況下發(fā)現(xiàn)源代碼的一些數(shù)據(jù)流異常。如果沿定義 /使用路徑跟蹤程序的執(zhí)行情況，則這些結(jié)點并不很重要。一條邊必須終止于一個結(jié)點，即使該結(jié)點并不代表任何語句 (例如： ifelsethen 結(jié)構(gòu) )。 V(G)值正好等于該程序的獨立路徑的條數(shù)。軟件測試是一個系列過程活動，包括軟件測試 需求分析，測試計劃設(shè)計，測試用例設(shè)計，執(zhí)行測試。軟件中的錯誤可能來自軟件項目中的各個過程，軟件測試只能確認軟件存在錯誤，不能保證軟件沒有錯誤，因為從根本上講，軟件測試不可能 發(fā)現(xiàn)全部的錯誤。所以，具有編程經(jīng)驗的程序員不一定是一名優(yōu)秀的測試工程師。因為縮短測試時間帶來的測試不完整，對項目質(zhì)量的下降引起的潛在風(fēng)險，往往造成更大的浪費。這兩年來國內(nèi)軟件測試人員的需求不斷增大 ,越來越多的 IT企業(yè)認識到了軟件測試的重要性 ,這種可喜的現(xiàn)狀與發(fā)展趨勢讓筆者對我國軟件業(yè)的發(fā)展重新抱有較大的希望。在需求中可能隱藏著數(shù)不清的潛在問題，而這在測試人員瀏覽需求時可能被忽略，因此在測試的起步階段徹底理解需求是十分必要的。在市場上，不少測試工具都可以度量測試覆蓋率。 （ 5）測試放在最后 低估測試和測試所需的資源將導(dǎo)致在開發(fā)周期的末期才開始測試活動，而在那時要發(fā)現(xiàn)關(guān)鍵 Bug也將變的異常困難，并且由于時間的限 制測試文檔的相關(guān)細節(jié)也會有所忽略。在最緊張的時候，有一種疲于奔命的感覺，你沒有辦法停下來，腦子里有一個聲音在說，向前，向前。 為什么開發(fā)人員不適合做測試呢？那是因為開發(fā)人員總是有種心理預(yù)期， “ 我的程序沒問題 ” 或 “ 一點點小的問題，沒有什么的，簡直可以忽略不計 ” 。一個一個的重新做一遍，再次發(fā)現(xiàn)的問題，就是真正的 BUG。 重視交流。有個 BUG有偶然性，你遇上了一次，而想重現(xiàn)的時候卻再也看不到它了。 江西信息應(yīng)用職業(yè)技術(shù)學(xué)院計算機 軟件 專業(yè)畢業(yè)論文 第 27 頁 共 29 頁 總結(jié)與展望 軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。在這難忘的大學(xué)學(xué)習(xí)生涯中，老師給了我精心的指導(dǎo)和細心的幫助。很感謝他對我的指導(dǎo)。 通過這次項目的實戰(zhàn)訓(xùn)練，使我進一步了解了軟件測試的相關(guān)知識，增加了項目 經(jīng)驗，為今后的實際工作中打下了堅實的基礎(chǔ)。 不要什么 BUG 附帶的圖片都是全屏的截圖，這樣的文件打開速度慢，而且沒有主次，開發(fā)人員不 知道看哪里。 發(fā)現(xiàn)了問題后要重現(xiàn) 一遍，不要急于提交。 窮追不舍。幾個小時后，測試工作告一段落，我們可以做一 個簡單的休息，放松一下大腦。一個 BUG，開發(fā)人員花費時間去檢查代碼，最后卻 發(fā)現(xiàn)這是一個假 BUG，自然怒火中燒。相對來說，測試工作對技術(shù)的要求少一些，但測試工作量是巨大的。開發(fā)組提交的產(chǎn)品必須由測試經(jīng)理或者協(xié)調(diào)員來管理，并且由其負責(zé)設(shè)置，版本管理和授權(quán)等等。低覆蓋率說明測試過程存在問題。二義性將是測試設(shè)計變的枯燥而乏味。在微軟等軟件過程比較規(guī)范的大公司，軟件測試人員的數(shù)量和待遇與程序員沒有多大差別，優(yōu)