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