軟件測試打字程序畢業論文畢業設計word格式(文件)

　

【正文】 測試在測試中所占地位 江西信息應用職業技術學院計算機 軟件 專業畢業論文 第 4 頁 共 29 頁 第一章 白盒測試研究 軟件測試概述 軟件測試就是在軟件交付用戶使用或投入運行前，對軟件需求規格說明、設計規格說明和編碼的最終復審，是軟件質量保證的關鍵步驟。在結束這個階段后對軟件系統還要進行各種綜合測試，如集成測試、系統測試、性能測試和配置測試等，這是軟件生命周期的另一個獨立階段，即測試階段。應當避免由程序員檢查自己的程序。不合理的輸入條件是指異常的，臨界的，可 能引起問題的輸入條件 。嚴格執行測試計劃，排除測試的隨意性。 軟件測試的對象：軟件測試并不單純等同于程序測試。 江西信息應用職業技術學院計算機 軟件 專業畢業論文 第 5 頁 共 29 頁 由于邏輯錯誤和不正確假設與一條程序路徑被運行的可能性成反比。白盒測試是一種測試用例設計方法，盒子指的是被測試的軟件，白盒指的是盒子是可視的 ,你清楚盒子內部的東西以及里面是如何運作的。 測試執行階段：輸入測試用例，得到測試結果。靜態分析的關鍵功能是檢查軟件的表示和描述是否一致 ,沒有沖突或者沒有歧義。在動態分析技術中 ,最重要的技術是路徑和分支測試 白盒測試的優缺點 優點：迫使測試人員去仔細思考軟件的實現 。最優化。 總的來說，白盒測試是一種被廣泛使用的邏輯測試方法，是由程序內部邏輯驅動的一種單元測試方法。 那么正確使用白盒測試 ，就要先從代碼分析入手，根據不同的代碼邏輯規則、語句執行情況，選用適合的覆蓋方法。 動態測試 執行代碼動態測試應注意以下方面：測試數據是否具有一定的代表性；測試數據是否包含測試所用的各個等價 類（邊界條件、次邊界條件、空白、無效）；是否可能從客戶那邊得到測試數據；不可從客戶那邊得到測試數據的情況下，所用的測試數據是否具有實際的意義（客戶業務上的）；是否每一組測試數據都得到了執行；每一組測試數據的測試結果是否與預期結果一致；文件的屬性是否正確；打開文件語句是否正確；輸入 /輸出語句是否與格式說明書所記述的一致；緩沖區大小與記錄長度是否匹配；使用文件前是否已打開了文件；文件結束條件是否存在；產生輸入 /輸出錯誤時，系統是否進行檢測并處理；輸出信息中是否存在文字書寫錯誤和語法錯誤；數字輸入框是否接受數字輸 入；數字是否按既定格式顯示；數字輸入框是否拒絕字符串和 “ 非法 ” 數字的輸入；組合框是否的能夠進行下拉選擇；組合框是否能夠進行下拉多項選擇；對于可添加數據組合框，添加數據后數據是否能夠得到正確顯示和進行選擇；列表框是否能夠進行選擇；多項列表框是否能夠進行多數據項選擇；日期輸入框是否 接受正確的日期輸入；日期輸入框是否拒絕錯誤的日期輸入；日期輸入框在日期輸入后是否按既定的日期格式顯示日期；單選組內是否有且只有一個單選鈕可選；如果單選組內無單選鈕可選，這種情況是否允許存在；復選框組內是否允許多個復選框（包括全部可選 ）可選；如果復選框組內無復選框可選，這種情況是否允許存在；文本框及某些江西信息應用職業技術學院計算機 軟件 專業畢業論文 第 7 頁 共 29 頁 控件拒絕輸入和選擇時顯示區域是否變灰或按既定規約處理；文本框中數據格式（大小、對齊方向、顏色、背景）是否符合規范；密碼輸入框是否按掩碼的方式顯示；控件是否存在默認輸入值，若存在，默認值是否得到顯示和提交； Cancel 之類的按鈕按下后，控件中的數據是否清空復原或按既定規約處理； Submit 之類的按鈕按下后，數據是否得到提交或按既定規約處理；異常信息表述是否正確；軟件是否按預期方式處理錯誤；文件或外設不存在的情況下是否存在相應的錯誤處理；軟件 是否嚴格的遵循外設的讀寫格式；產生的文件和數據表的格式是否正確；產生的文件和數據表的計算結果是否正確；打印的報表是否符合既定的格式；錯誤日志的表述是否正確；錯誤日志的格式是否正確。 詳細步驟： （ 1）測試程序要測試的已經具體實現的類。重復這一過程，直至測試程序中沒有已經實現的類的對象。 （ 8）前面的全部過程，直至除了驗證具體實現的特有的方法的測試程序外，所有的測試代碼都已完成。 ②用例設計：（如果此時將 A路徑上的語句 1T 去掉，那么用例如表 ） ③優點：可以很直觀地從源代碼得到測試用例，無須細分每條判定表達式。但是我們不能排除這種以外的分支不會被執行，而往往這種錯誤會經常出現。每個判斷的取真、取假至少執行一次。 （ 3）條件覆蓋 ①主要特點：條件覆蓋要求設計足夠多的測試用例，使得判定中的每個條件獲得各種可能的結果，即每個條件至少有一次為真值，有一次為假值。 （ 4）判定 /條件覆蓋 ①主要特點：設計足夠多的測試用例，使得判定中每個條件的所有可能結果至少出現一次，每個判定本身所有可能結果也至少出現一次。 ②用例設計 (如表 )： ③優點：多重條件覆蓋準則滿足判定覆蓋、條件覆蓋和判定 /條件覆蓋準則。 （ 6）路徑覆蓋 ①主要特點：設計足夠的測試用例，覆蓋程序中所有可能的路徑。這樣不僅降低了測試效率，而且大量的測試結果的累積，也為排錯帶來麻煩。但是在選擇和使用測試工具的時候，我們也應該看到，在測試過程中，并不是所有的測試工具都適合我 們使用，同時，有了測試工具、會使用測試工具并不等于測試工具真正能在測試中發揮作用。 所有字符練習：由系統隨機調用文檔 ，以程序中要求取出字符數輸出到界面，由用戶輸入，程序判斷用戶練習的速度 ,時間 ,正確率等數據。使界江西信息應用職業技術學院計算機 軟件 專業畢業論文 第 14 頁 共 29 頁 面符合設計規范，適用于用戶。 打字程序代碼編寫規范：創建的變量、接口、函數、屬性應與《設計文檔》保持一致；程序的各種命名、注釋、代碼行的格式等應符合《程序開發命名標準》和《編碼規范》；程序模塊能獨立穩定運行。 動態測試 控制流分析； 數據流分析； 信息流分析； 畫出該代碼的控制流程圖； 計算程序的圈復雜度； 做基本路徑覆蓋，設計相應測試 用例； 分析測試結果。 變量在使用之前被再次定義。它將程序中變量的出現分為變量的定義和引用。為描述定義 /使用測試，下面先定義幾個基本術語： 變量 v的定義結點 n記做 DEF(v,n) 變量 v的定義結點 n記做 USE(v,n) 謂詞使用 記做 P— use 定義 /使用路徑 記做 du— path 定義明確路徑 記做 dcpath 表 44 將給出打字程序中變量的定義結點和使用結點。 江西信息應用職業技術學院計算機 軟件 專業畢業論文 第 21 頁 共 29 頁 下面將較詳細的分析一些定義 /使用路徑。在流圖中，每一個圓，稱為流圖的結點，代表一個或多個語句。計算區域時應包括圖外部的范圍。 對應上面圖中的圈復雜度計算如下： 流圖中有５個區域 V(G)=23條邊 19節點 +2=６ V(G)=５判定點 +1=６ 導出測試用例 根據上面 的計算方法，可得出六個獨立的路徑。 設計測試用例 為了確保基 本路徑集中的每一條路徑的執行，根據判斷結點給出的條件，選擇適當的數據以保證某一條路徑可以被測試到，滿足上面例子基本路徑集的測試用例是： （１）路徑１：（ bchhl）的測試用例 輸入數據： speed=49amp。據此，認為軟件測試只是軟件編碼后的一個過程。在軟件項目的每一個階段都要進行不同目的和內容的測試活動，以保證各個階段的正確性。更嚴重的是如果此時發現了軟件需求階段或概要設計階段的錯誤，如果要修復該類錯誤，將會耗費大量的時間和人力。出現軟件錯誤，不能簡單地歸結為某一個人的責任，有些錯誤的產生可能不是技術原因，可能來自于混亂的項目管理。隨之軟件工程學的發展和軟件項目管理經驗的提高，軟件測試已經形成 了一個獨立的技術學科，演變成一個具有巨大市場需求的行業。 (4)軟件測試是測試人員的事情，與程序員無關 開發和測試是相輔相成的過程，需要軟件測試人員、程序員和系統分析師等保持密切的聯系，需要更多的交流和協調，以便提高測試效率。 (5)項目進度吃緊時就少做一些測試，時間富裕時多做測試 這是不重視軟件測試的表現，也是軟件項目過程管理混亂的表現，必然會降低軟件測試的質量。 (6)軟件測試是沒有前途的工作，只有程序員才是軟件高手 由于我國軟件整體開發能力比較低，軟件過程很不規范，很多軟件項目的開發都還停留在 “作坊式 ”和 “壘雞窩 ”階段。在微軟等軟件過程比較規范的大公司，軟件測試人員的數量和待遇與程序員沒有多大差別，優秀測試人員的待遇甚至比程序員還要高。 測試項目中的常見問題及處理方法 （ 1）缺少計劃和評估 有效的測試計劃是一個測試項目中最關鍵，也是最有挑戰性的步驟之一。二義性將是測試設計變的枯燥而乏味。 （ 3）不全面的測試覆蓋 江西信息應用職業技術學院計算機 軟件 專業畢業論文 第 25 頁 共 29 頁 一個優秀的測試應該具有高覆蓋率，數量不足的測試用例是無法測試軟件的全部功能的。低覆蓋率說明測試過程存在問題。 如何處理？ 在一個可控制的環境下進行測試而不是與開發或生產同一環境。開發組提交的產品必須由測試經理或者協調員來管理，并且由其負責設置，版本管理和授權等等。 （ 6）不完善的測試文檔 在分析測試部件的時候，不充分或不準確的測試文檔（測試計劃，測試用例說明書，測試報告等等）將浪費大量的時間，影響產品的質量和交付時間。相對來說，測試工作對技術的要求少一些，但測試工作量是巨大的。是的，測試人員必須往前趕，但是也不要忘記了，測試計劃和測試用例是什么時候寫的，這段時間呢的 Spec做過哪些更新。一個 BUG，開發人員花費時間去檢查代碼，最后卻 發現這是一個假 BUG，自然怒火中燒。測試人員一旦發現問題，心里就興奮起來，這種興奮程度與 BUG的嚴重程度成正比。幾個小時后，測試工作告一段落，我們可以做一 個簡單的休息，放松一下大腦。我們要給自己一個審查自己的機會，避免虛假的 BUG。 窮追不舍。同時要記住說話的態度和方式，不要咄咄逼人。 發現了問題后要重現 一遍，不要急于提交。但即使只出現一次，至少說明有可能有問題，所以，不要輕易放棄，要記錄下來，下次遇到，證據就全了。 不要什么 BUG 附帶的圖片都是全屏的截圖，這樣的文件打開速度慢，而且沒有主次，開發人員不 知道看哪里。軟件測試是軟件質量保證的關鍵環節，直接影響著軟件的質量評估。 通過這次項目的實戰訓練，使我進一步了解了軟件測試的相關知識，增加了項目 經驗，為今后的實際工作中打下了堅實的基礎。這也會在潛移默化之中影響著我今后的學習和工作，會激勵我在未來的工作和生活中不斷拼搏，積極進取。很感謝他對我的指導。他淵博的知識，誠懇的為人，使我受益匪淺。在這難忘的大學學習生涯中，老師給了我精心的指導和細心的幫助。驗收測試作為軟件測試過程的最后一個環節，對軟件質量、軟件的可交付性和軟件項目的實施周期起到 一錘定音 的作用。 江西信息應用職業技術學院計算機 軟件 專業畢業論文 第 27 頁 共 29 頁 總結與展望 軟件測試是為了發現錯誤而執行程序的過程。 BUG描述要清晰，無歧義。有個 BUG有偶然性，你遇上了一次，而想重現的時候卻再也看不到它了。 分析錯誤原因。 重視交流。 （ 3）更好更專業 怎么才能做得更專業？這個問題很難回答，下面的觀點盡供參考： 少提交虛假 BUG。一個一個的重新做一遍，再次發現的問題，就是真正的 BUG。例如很有可能是因為測試人員沒有執行規定的步驟導致預期以外的結果，而測試人員被這個錯誤結果迷惑了，興高采烈地把它當作 BUG上提交上去了。 為什么開發人員不適合做測試呢？那是因為開發人員總是有種心理預期， “ 我的程序沒問題 ” 或 “ 一點點小的問題，沒有什么的，簡直可以忽略不計 ” 。 用例不會是一成不變的，一個用例在運行 5遍以后，你該發現的問題都發現了，如果不 補充更新的用例，怎么去對付被測試的程序呢。在最緊張的時候，有一種疲于奔命的感覺