【正文】 同的變量；賦值的目的變量是否小于賦值表達式的值；數(shù)值計算是否會出現(xiàn)溢出（向上）的情況；數(shù)值計算是否會出現(xiàn)溢出（向下）的情況；除數(shù)是否可能為零；某些計算是否會丟失計算精度；變量的值是否超過有意義的值；計算式的求值的順序是否容易讓人感到混亂；比較是否正確；是否存在分數(shù)和浮點數(shù)的比較；精度問題是否會影響比較；每一個邏輯表達式是否都得到了正確表達；邏輯表達式的操作數(shù)是否均為邏 輯值；程序中的 Begin? End和 Do? While等語句中， End是否對應；程序、模塊、子程序和循環(huán)是否能夠終止；是否存在永不執(zhí)行的循環(huán)；是否存在多循環(huán)一次或少循環(huán)一次的情況；循環(huán)變量是否在循環(huán)內被錯誤地修改；多分支選擇中，索引變量是否能超過可能的分支數(shù)； 該情況是否能夠得到正確處理；全局變量定義和用法在各個模塊中是否一致；是否修改了只作為輸入用的參數(shù)；常量是否被作為形式參數(shù)進行傳遞。 江西信息應用職業(yè)技術學院計算機 軟件 專業(yè)畢業(yè)論文 第 8 頁 共 29 頁 （ 1）語句覆蓋 ①主要特點：語句覆蓋是最起碼的結構覆蓋要求，語句覆蓋要求設計足夠多的測試用例，使得程序中每條語句至少被執(zhí)行一次。條件覆蓋只能保證每個條件至少有一次為真，而不考慮所有的判定結果。 總的來說，測試工具的應用可以提高測試的質量、測試的效率。 靜態(tài)測試 變量命名及代碼書寫規(guī)范檢查； 變量定義、函數(shù)、方法、數(shù)組、變量的使用檢查； 檢查是否有定義未使用的變量； 檢查全局變量的使用情況； 檢查程序代碼循環(huán)情況； 檢查是否為引用的指針分配內存； 檢查數(shù)組運算情況。但是如果出現(xiàn)了問題，包含這些結點有助于發(fā)現(xiàn)問題，則可視情況做出選擇。 ) 路徑 1： bchhl 路徑 2： bcdefghkl 路徑 3： bcdefijkl 路徑 4: mnttv 路徑５： mnopqsuv 路徑６： mnoprtuv 根據(jù)上面的獨立路徑，去設計輸入數(shù)據(jù)，使程序分別執(zhí)行到上面六條路徑。從軟件開發(fā)的角度看，軟件的高質量不是軟件測試人員測出來的，是靠軟件生命周期的各個過程中設計出來的?？朔@種現(xiàn)象的最好辦法是加強軟件過程的計劃和控制，包括軟件測試計劃、測試設計、測試執(zhí)行、測試度量和測試控制。 如何處理？ 測試人員可以以一份問題清單的方式參與需求審核，使?jié)撛趩栴}能夠在準備測試用例之前浮出水面以提高軟件產品的質量，或者測試人員也可以以報告的形式來指出需求的不足之處。 如何處理？ 采用開發(fā)與測試并行的方式，當需求確定時就開始撰寫測試計劃。而在測試人員總是懷疑有 BUG的心 理傾向下，我們也要預防一種錯誤：報告虛假的 BUG。與 PM和 Dev多做交流，這樣的測試人員才不會孤陋寡聞。它不僅是軟件開發(fā)階段的有機組成部分，而且在整個軟件工程 (即軟件定義、設計和開發(fā)過程 )中占據(jù)相當大的比重。在寫作過程中，悉心指導，給了我們很大的幫助。 圖片要經過裁剪。 少提交重復的 BUG。 （ 2）在報告一個 BUG之前，需要重現(xiàn)一遍 江西信息應用職業(yè)技術學院計算機 軟件 專業(yè)畢業(yè)論文 第 26 頁 共 29 頁 開發(fā)人員和測試人員在工作上有些爭論是很正常的，而有些事情卻容易加深誤解，虛假的 BUG就是其中之一。舉例來說，測試環(huán)境的配置應該和使用環(huán)境相似或相同。 （ 2）模棱兩可的需求 如果缺乏足夠的文檔，測試過程將持續(xù)更長的時間，并且軟件在推出發(fā)布版時也將面臨更多的錯誤。程序員可以通過有目的的分析軟件錯誤的類型、數(shù)量，找出產生錯誤的位置和原因，以便在今后的編程中避免同樣的錯江西信息應用職業(yè)技術學院計算機 軟件 專業(yè)畢業(yè)論文 第 24 頁 共 29 頁 誤， 積累編程經驗，提高編程能力。如果等到軟件編碼結束后才進行測試，那么，測試的時間將會很短，測試的覆蓋面將很不全面，測試的效果也將大打折扣。 有以下三種方法計算圈復雜度： 流圖中區(qū)域的數(shù)量對應于環(huán)型的復雜性； 給定流圖 G的圈復雜度 V(G)，定義為 V(G)=EN+2， E是流圖中邊的數(shù)量， N是流圖中結點的數(shù)量； 給定流圖 G的圈復雜度 V(G)，定義為 V(G)=P+1， P是流圖 G中判定結點的數(shù)量。 G(P)有一個單入口和一個單出口結點，并且不允許有某個結點到其自身的身邊。 打字程序詳細設計文檔測試通過的標準：文檔中描述的正確性，無異性。而在有些情況下，一些執(zhí)行路徑是不可能被執(zhí)行的，如： If （ !A） B++； ~ Fc3Q~~0If （ !A） D； 這兩個語句實際只包括了 2條執(zhí)行路徑，即 A為真或假時候對 B和 D 的處理，真或 假不可能都存在，而路徑覆蓋測試則認為是包含了真與假的 4條執(zhí)行路徑。 ④缺點：往往大部分的判定語句是由多個邏輯條件組合而成（如，判定語句中包含 AND、 OR、 CASE），若僅僅判斷其整個最終結果，而忽略每個條件的取值情況，必然會遺漏部分測試路徑。 （ 7）這一過程直至所有的測試都移入抽象的測試類。因此我們不能窮舉所有的邏輯路徑，即使窮舉也未必會帶來好運（窮舉不能查出程序邏輯規(guī)則錯誤，不能查出數(shù)據(jù)相關錯誤，不能查出程序遺漏的路徑）。 靜態(tài)分析是一種不通過執(zhí)行程序而進行測試的技術。妥善保存測試計劃，測試用例，出錯統(tǒng)計和最終分析報告，為維護提供方便。編碼和單元測試屬于軟件生命周期中的同一個階段。 隨著計算機軟件的規(guī)模越來越大，軟件測試成為了軟件質量保障的關鍵環(huán)節(jié)，軟件測試自動化也成為了軟件測試領域所無法逾越的發(fā)展階段。為了解決這場危機，軟件從業(yè)人員、專家和學者做出了大量的努力。不合理的輸入條件是指異常的，臨界的，可 能引起問題的輸入條件 。白盒測試是一種測試用例設計方法，盒子指的是被測試的軟件，白盒指的是盒子是可視的 ,你清楚盒子內部的東西以及里面是如何運作的。最優(yōu)化。 詳細步驟： （ 1）測試程序要測試的已經具體實現(xiàn)的類。但是我們不能排除這種以外的分支不會被執(zhí)行，而往往這種錯誤會經常出現(xiàn)。 ②用例設計 (如表 )： ③優(yōu)點：多重條件覆蓋準則滿足判定覆蓋、條件覆蓋和判定 /條件覆蓋準則。 所有字符練習：由系統(tǒng)隨機調用文檔 ，以程序中要求取出字符數(shù)輸出到界面，由用戶輸入，程序判斷用戶練習的速度 ,時間 ,正確率等數(shù)據(jù)。 變量在使用之前被再次定義。在流圖中，每一個圓，稱為流圖的結點，代表一個或多個語句。據(jù)此，認為軟件測試只是軟件編碼后的一個過程。隨之軟件工程學的發(fā)展和軟件項目管理經驗的提高，軟件測試已經形成 了一個獨立的技術學科，演變成一個具有巨大市場需求的行業(yè)。在微軟等軟件過程比較規(guī)范的大公司，軟件測試人員的數(shù)量和待遇與程序員沒有多大差別，優(yōu)秀測試人員的待遇甚至比程序員還要高。低覆蓋率說明測試過程存在問題。相對來說，測試工作對技術的要求少一些，但測試工作量是巨大的。幾個小時后，測試工作告一段落，我們可以做一 個簡單的休息，放松一下大腦。 發(fā)現(xiàn)了問題后要重現(xiàn) 一遍，不要急于提交。 通過這次項目的實戰(zhàn)訓練，使我進一步了解了軟件測試的相關知識，增加了項目 經驗，為今后的實際工作中打下了堅實的基礎。在這難忘的大學學習生涯中，老師給了我精心的指導和細心的幫助。有個 BUG有偶然性，你遇上了一次，而想重現(xiàn)的時候卻再也看不到它了。一個一個的重新做一遍，再次發(fā)現(xiàn)的問題，就是真正的 BUG。在最緊張的時候，有一種疲于奔命的感覺，你沒有辦法停下來，腦子里有一個聲音在說，向前，向前。在市場上，不少測試工具都可以度量測試覆蓋率。這兩年來國內軟件測試人員的需求不斷增大 ,越來越多的 IT企業(yè)認識到了軟件測試的重要性 ,這種可喜的現(xiàn)狀與發(fā)展趨勢讓筆者對我國軟件業(yè)的發(fā)展重新抱有較大的希望。所以，具有編程經驗的程序員不一定是一名優(yōu)秀的測試工程師。軟件測試是一個系列過程活動，包括軟件測試 需求分析，測試計劃設計，測試用例設計，執(zhí)行測試。一條邊必須終止于一個結點，即使該結點并不代表任何語句 (例如： ifelsethen 結構 )。由于索引表信息是有編譯器生成的，因此這些異常可以通過所謂景泰分析發(fā)現(xiàn)，即在不執(zhí)行被測程序的情況下發(fā)現(xiàn)源代碼的一些數(shù)據(jù)流異常。 第三章 系統(tǒng)白盒測試實例的實現(xiàn) 測試的目的 測試主要為打字系統(tǒng)的白盒測試。并且每個條件都顯示能單獨影響判定結果。那么顯然，語句覆蓋對于多分支的邏輯運算是無法全面反映的，它只在乎運行一次，而不考慮其他情況。在具體的測試程序實現(xiàn)中繼承這個測試類，并修改相應的實現(xiàn)方法。無法檢測代碼中遺漏的路徑和數(shù)據(jù)敏感性錯誤 。 白盒測試的特點：依據(jù)軟件設計說明書進行測試、對程序內部細節(jié)的嚴密檢驗、針對特定條件設計測試用例、對軟件的邏輯路徑進行覆蓋測試。經驗表明，測試后程序殘存的錯誤數(shù)目與該程序中已發(fā)現(xiàn)的錯誤數(shù)目或檢錯率成正比。有錯是軟件的屬性，而且是無法改變的，因為軟件是由人來完成的，所有由人做的工作都不會是完美無缺的。這些經驗教訓迫使軟件開發(fā)者們必須添加一個相應的流程，并在此流程中 采取強有力的檢測措施來檢測未發(fā)現(xiàn)的隱藏的軟件缺陷，也就是軟件測試。 軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行 程序的過程。測試計劃應包括：所測軟件的功能，輸入和輸出，測試內容，各項測試的進度安排，資源要求，測試資料，測試工具，測試用例的選擇，測試的控制方法和過程，系統(tǒng)的配置方式，跟蹤規(guī)則，調試規(guī)則，以及回歸測試的規(guī)定等等以及評價標準 。 測試總結階段：對比測試的結果和代碼的預期結果，分析錯誤原因，找到并解決錯誤。只有對程序內部十分了解才能進行適度有效的白盒測試。 （ 5）要在測試中調用的抽象方法。 ②用例設計 (如表 )： 江西信息應用職業(yè)技術學院計算機 軟件 專業(yè)畢業(yè)論文 第 9 頁 共 29 頁 ③優(yōu)點：判定覆蓋比語句覆蓋要多幾乎一倍的測試路徑，當然也就具有比語句覆蓋更強的測試能力。 ②用例設計 (如表 )： ③優(yōu)點：這種測試方法可以對程序進行徹底的測試，比前面五種的覆蓋面都廣。 測試項 所要測試的測試項： 打字程序需求報告，需求規(guī)格說明書； 打字程序詳細設計文檔； 打字程序代碼編寫規(guī)范； 代碼中變量的命名標準； 打字程序界面規(guī)范。所謂的數(shù)據(jù)流分析是指在不運行被測程序的情況下，對變量的定義、引用進行分析，以檢測數(shù)據(jù)的賦值與引用之間是否出現(xiàn)了不合理的現(xiàn)象，如引用未賦值的變量，對以前未曾使用變量的再次賦值 等數(shù)據(jù)流異常現(xiàn)象。 圖 46 打字程序計算模塊代碼程序控制流程圖 江西信息應用職業(yè)技術學院計算機 軟件 專業(yè)畢業(yè)論文 第 22 頁 共 29 頁 圈復雜度是一種為程序邏輯復雜性提供定量測度的軟件度量，將該度量用于計算程序的基本的獨立路徑數(shù)目，為 確保所有語句至少執(zhí)行一次的測試數(shù)量的上界。軟件測試的對象不僅僅是軟件代碼，還包括軟件需求文檔和設計文檔。另外，對于單元測試主要應該由程序員完成，必要時測試人員可以幫助設計測試樣例。測試計劃和評估表明了測試執(zhí)行的順序和方式以及它們所需要的資源。只有測試組擁有 測試環(huán)境的控制權，并且未經過測試組的允許，任何人都不能改變測試環(huán)境。所以測試管理人員必須經常做測試計劃和用例的更新。 在提交 BUG 之前，查詢一下 BUG 庫或者和相關的同事做一個簡短的交流，盡量不提交重復的 BUG。不可重現(xiàn)的 BUG也可以提交，只要是注明這個 BUG不容易重現(xiàn)，以面他人誤會，這樣既不浪費開發(fā)人員的時間，也不讓一個 BUG漏掉。在此，我向老師表示衷心的感謝 ! 最后向所有曾給予我鼓勵和幫助的而在這里沒有提及的老師、同學、朋友以及參考文獻的作者們表示最高的敬意 ! 其次深深感謝的是我們的指導老師 —— 賀曉敏 。軟件測試不僅要講究策略，更要講究時效性。在交流時要讓別人聽得進你的 “ 忠言逆耳 ” ，你宙斯好不要作興師問罪狀，前面有一個引子較好，慢慢道來。興奮起來后，人的理智便下降了，人的所見所聞可能與實際情況有所差異。 如何處理？ 詳細認真的面對測試文檔，在所有測試階段中，測試文檔都是一個非常重要的工作。測試覆蓋率只是衡量測試質量的一個方面，如果無法達到高 覆蓋率，那就必須對此進行強化和鞏固。項目的成功往往靠個別全能程序員決定，他們負責總體設計和程序詳細設計 ，認為軟件開發(fā)就是編寫代碼，給人的印象往往是程序員是真正的牛人，具有很高的地位