單元測試 軟件測試
一、單元測試的方法
單元測試也稱為模塊測試，在模塊編寫完成且無編譯錯誤后就可以進行。如果選用機器測試，一般用白盒測試法；多個模塊可以同時進行。
單元測試主要從模塊的以下5個特征著手進行檢查。
(1)模塊接口。模塊的接口保證了測試模塊的數據流可以正確地流人、流出。在測試中應檢查以下要點：
．測試模塊的輸入參數和形式參數在個數、屬性、單位上是否一致。
·調用其他模塊時所給出的實際參數和被調用模塊的形式參數在個數、屬性、單位上是否一致。
·調用標準函數時所用的參數在屬性、數目和順序上是否正確。
·全局變量在各模塊中的定義和用法是否一致。
．輸入是否僅改變了形式參數。
·開／關的語句是否正確。
·規定的I／O格式是否與輸入輸出語句一致。
。在使用文件之前是否已經打開文件或是使用文件之后是否已經關閉文件。
(2)局部數據結構。在單元測試中，局部數據結構出錯是比較常見的錯誤，在測試剛應重點考慮以下因素：
·變量的說明是否合適。
·是否使用了尚未賦值或尚未初始化的變量。
·變量的初始值或默認值是否正確。
·變量名是否有錯(例如拼寫錯)。
(3)重要的執行路徑。在單元測試中，．對路徑的測試是最基本的任務。由于不能進行窮舉測試，需要精心設計測試用例來發現是否有計算、比較或控制流等方面的錯誤。
·計算方面的錯誤：算術運算的優先次序不正確或理解錯誤；精度不夠；運算對象的類型不匹配；算法錯；表達式的符號表示不正確等。
·比較和控制流的錯誤：本應相等的量由于精度造成不相等；不同類型進行比較邏輯運算符不正確或優先次序錯誤；循環終止不正確(如多循環一次或少循環一次)、死循環；不恰當地修改循環變量；當遇到分支循環時，出口錯誤等。
(4)出錯處理。好的設計應該能預測到出錯的條件并且有出錯處理的途徑。雖然計算機機可以顯示出錯信息的內容，但仍需要程序員對出錯進行處理，保證其邏輯的正確性以便于用戶維護。
(5)邊界條件。邊界條件的測試是單元測試的最后工作，也是非常重要的工作。毫件容易在邊界出現錯誤。塊進行測試時，需要開發兩種模塊：
·驅動模塊，相當于一個主程序，接收測試用例的數據，將這些數據送到測試槨
輸出測試結果。
·樁模塊，也稱為存根模塊。樁模塊用來代替測試模塊中所調用的子模塊，其進行少量的數據處理，目的是為了檢驗人口，輸出調用和返回的信息。 提高模塊的內聚度可以簡化單元測試。如果每個模塊只完成一種功能，對于具一塊來講，所需的測試方案數據就會顯著減少，而且更容易發現和預測模塊中的錯誤。
2)組裝測試 ． [Page]
組裝測試也稱為集成測試，就是把模塊按系統設計說明書的要求組合起來進行即使所有模塊都通過了測試，但在組裝之后，仍可能會出現下列問題：
·穿過模塊的數據丟失；
·一個模塊的功能對其他模塊造成有害的影響；
·各個模塊組裝起來沒有達到預期的功能；
·全局數據結構出現問題； ．
·單個模塊的誤差可以接受，但模塊組合后，可能會出現誤差累積，最后到不能壬的程度，所以需要組裝測試 。
通常組裝測試有兩種方法：一種是分別測試各個模塊，再把這些模塊組合起來主整體測試，即非增量式集成。另一種是把下一個要測試的模塊組合到已測試好的模塊測試完后再將下一個需要測試的模塊組合起來，進行測試，逐步把所有模塊組合在一并完成測試，即增量式集成。非增量式集成可以對模塊進行并行測試，能充分利用人并加快測試進度。但這種方法容易造成混亂，出現錯誤不容易查找和定位。增量的范圍一步步擴大，錯誤容易定位，而且已測試的模塊可在新的條件下再測試，測由徹底。
3)確認測試
經過組裝測試之后，軟件就被集成起來，接口方面的問題已經解決，將進人軟件的最后一個環節一確認測試。確認測試的任務就是進一步檢查軟件的功能和性能是軍用戶要求的一樣。系統方案說明書描述了用戶對軟件的要求，所以是軟件有效性驗證標準，也是確認測試的基礎。
確認測試，首先要進行有效性測試以及軟件配置審查，然后進行驗收測試和安裝試，經過管理部門的認可和專家的鑒定后，軟件即可以交給用戶使用。
·有效性測試，就是在模擬環境下，通過黑盒測試檢驗所開發的軟件是否與需習格說明書一致。在設計測試用例時，除了檢測軟件的功能和性能之外，還需要 成，但最好是沒有參加該項目的有經驗的軟件設計人員。在所有測試用例完成二后，若發現測試結果與預期的不符，這時要列出缺陷清單。在這個階段才發現白嚴重錯誤，一般很難在預定的時間內糾正，需要與用戶協商，尋找妥善解決問題的辦法。
·軟件配置審查，主要是檢查軟件(源程序、目標程序)和文檔(包括面向開發人員習用戶的文檔)是否齊全以及分類是否有序。確保文檔、資料的正確和完善，以便護階段使用。
·驗收測試，是以用戶為主的測試。軟件開發人員和質量保證人員也應該參加。驗收測試之前，需要對用戶進行培訓，以便熟悉該系統。驗收測試的測試用例用戶參與設計，主要驗證軟件的功能、性能、可移植性、兼容性、容錯性等，測試掃描一般采用實際數據。
二、單元測試方法之黑盒測試與白盒測試
單元測試的測試數據可以用兩個基本的方法系統地構建。第一個是規格說明測試，這個技術也稱為黑盒測試，行為測試，數據驅動測試，功能測試以及輸入/輸出驅動測試。在這個方法中，不考慮代碼本身，在擬制測試用例中使用的僅有的信息是規格說明文檔。另一個極端是代碼測試，它在選擇測試用例時不理會規格說明文檔。這個技術也稱為玻璃盒測試，白盒測試，結構測試，邏輯驅動測試以及面向路徑測試。
規格說明測試的可行性：
考慮下面的例子。假定某個數據處理產品的規格說明指出，必須包含5類傭金和7類折扣。僅測試傭金和折扣的每個可能的組合就需要35個測試用例，說傭金和折扣是在兩個完全獨立的模塊中，因而可以獨立測試是沒有用的，因為在黑盒測試中將產品當作黑盒對待，它的內部結構因此是完全無關的。因此，徹底的規格說明測試在實際中是不可能的，因為它的組合方式會爆炸式的增長。
代碼測試的可行性：
代碼測試最常見的形式要求對模塊通過的每條路徑最少執行一次。試驗產品中全部路徑是不可靠的，因為存在這樣的產品，某些數據試驗一個給定路徑將檢測到錯誤，而不同的數據試驗同一個路徑將不會檢出錯誤。然而，面向路徑的測試是有效的，因為它沒有固有地將可能揭示錯誤的測試數據的選擇排除在外。
因為組合爆炸，徹底的規格說明測試或徹底的代碼測試都是不可行的。為此，在使用將盡可能多揭示錯誤的技術的同時，也承認沒有方法保證已經檢測出全部錯誤，一個繼續下去的合理的辦法是首先使用黑盒測試用例，然后使用玻璃盒測試開發額外的測試用例。
黑盒單元測試技術：
徹底的黑盒測試通常要求成百上千億的測試用例，因此測試的技巧是設計一個較小，可管理的測試用例集，是檢測出一個錯誤的機會最大，同時通過讓相同的錯誤由多個測試用例檢出從而使浪費一個測試用例的機會最小。一個這樣的黑盒技術是結合了邊界值分析的等價測試。
1. 等價測試和邊界值測試
假定一個數據庫產品的規格說明指出，該產品必須能夠處理任何從1到16383個記錄，如果該產品能夠處理34個記錄和14870個記錄，那么它在比如說 8252個記錄時工作良好的可能性很大。因此，該產品能夠處理的記錄數的規定范圍可以定義三個等價類：比1個記錄小，從1到16383個記錄和多于 16383個記錄。
一個成功的測試用例能檢測出先前未檢測到的錯誤，為了使發現這一的錯誤的機會最大，一個高效的技術是邊界值分析。
綜上，因此，測試這個數據庫產品的時候，應選擇7個測試用例：
1> 0個記錄：等價類1的成員，臨近邊界值。
2> 1個記錄：邊界值。
3> 2個記錄：臨近邊界值。
4> 723個記錄：等價類2的成員。
5> 16382個記錄：臨近邊界值。
6> 16383個記錄：邊界值。
7> 16384個記錄：等價類3的成員，臨近邊界值。
等價測試的過程概括如下：
對于輸入和輸出規格說明
對于每個范圍（L，U）：
選擇5個測試用例：小于L，等于L，比L大但比U小，等于U以及大于U。
對于每個集合S：
選擇2個測試用例：一個S的元素和一個非S的元素。 [Page]
對于每個精確值P：
選擇2個測試用例：P和其他任何值。
2. 功能測試
一個可選的黑盒測試形式是根據模塊的功能選擇測試數據。在功能測試中，要區別每個功能項或在模塊中實現的功能。
玻璃盒單元測試技術：
在玻璃盒測試技術中，基于代碼的檢查，而不是規格說明的檢查來選擇測試用例。有一些不同形式的玻璃盒測試，包括語句，分支以及路徑覆蓋。
1. 結構測試：語句，分支和路徑覆蓋
最簡單形式的玻璃盒測試是語句覆蓋，即運行一系列測試用例，在運行期間每個語句最少執行一次。這個方法的缺點是不能保證對分支的所有輸出都充分地測試。
語句覆蓋的一個改進是分支覆蓋，即運行一系列，確保所有的分支最少測試一次。
像語句或分支覆蓋的技術成為結構測試。
功能最強大的結構測試的形式是路徑覆蓋，即測試所有的路徑。
2. 復雜性度量
質量保證觀點提供另一個玻璃盒單元測試的方法。假定一個管理者被告知代碼模塊m1比代碼模塊m2更復雜，且不管術語復雜是如何準確定義的，管理者直覺上相信m1可能比m2有更多的錯誤。沿著這條思路，計算機科學家已經開發出一些軟件復雜性度量，以幫助確定哪個代碼模塊更可能有錯誤。如果發現一個代碼模塊的復雜度不合理的高，管理者可能直接要求對它重新設計和重新實現，與試圖調試一個有錯的代碼模塊相比，可能從頭開始的代價更小，速度更快。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
