基于黑盒測試的軟件測試策略研究與實踐
2009-01-01 00:00:00李寧李戰懷
計算機應用研究 2009年3期
（西北工業大學 計算機學院， 西安 710072）
摘 要：在軟件測試的系統測試、驗收測試等測試階段中，傳統的黑盒測試基本方法主要應用在細節測試方法中，但它不能給面向宏觀的測試策略的設計提供有效的指導作用。為了彌補這方面的不足，從測試用例分布、測試角度確定和測試人力資源分布三個方面提出了幾個有效的軟件測試方法策略，并結合具體的軟件測試項目驗證了這些方法策略的應用效果。實踐表明好的宏觀軟件測試策略將有效地改善測試的效果。
關鍵詞：軟件測試； 矩陣法； 場景法； 關聯關系法
中圖分類號：TP311 文獻標志碼：A
文章編號：10013695(2009)03092304
Research and practice of software test policies based on black box testing
LI Ning， LI Zhanhuai
(College of Computer， Northwestern Polytechnical University， Xi’an 710072， China)
Abstract:In system testing and acceptance testing of software test， applied the method of black box testing to the detail of test methods. But it could not provide the effective guidance to the strategic policy design. To fill up a deficiency， presented several strategic software test policies，which included test case，test viewpoint and tester arrangement. Besides，described how applied the policies successfully into an software project. It shows that good test policies can effectively improve the test result.
Key words：software testing; matrix method; scenario method; association method
隨著計算機與人們日常生活關系日益緊密，各種類型的軟件被廣泛應用于各行各業之中。人們對軟件的依賴性越大，就會對軟件的品質要求越來越高。在這樣的背景下，近年來在國內，軟件測試越來越受到軟件領域的關注。
軟件測試是軟件生命周期中的一個重要階段，它是軟件品質得以保證的重要過程。軟件開發中所有的測試時間之和幾乎占到軟件開發周期的一半，因此如何制訂有效的測試策略，如何有效地組織人員實施測試就成為一個至關重要的問題。
本文主要是圍繞在某些大型軟件的基于黑盒的軟件測試實踐中逐步探索出的一些行之有效的測試策略和方法進行討論和分析，并對今后的探索方向進行展望。
1 傳統軟件測試方法的不足
在系統測試、驗收測試的測試活動中，主要測試對象都是功能已經完成，即將要交付或者發布的軟件，所以大多是通過黑盒法來進行功能、性能等各種測試。黑盒法中的一些典型方法，如等價分類法、邊界值分析法、錯誤推測法、因果圖以及狀態轉換圖等方法在某些具體細節的測試用例的設計中起到非常好的作用。但是在細節的測試用例設計之前，規劃宏觀測試策略，提出有效測試觀點時，黑盒測試的方法就不能很好地發揮作用了。
如果沒有有效的測試策略來指導具體測試用例的編寫生成，測試往往就會陷入細節之中，最終測試分布不均，導致遺漏很多重要的內容。
在工程化的軟件測試中，目前有很多的測試模型，如V模型、W模型等，但是不論哪一種模型，最終實施都要通過具體的測試用例來進行。下文主要針對指導測試用例的宏觀設計以及測試用例的實施方法等方面給出了一些有效可行的測試策略。
2 幾種有效的軟件測試策略
從廣義上來說，軟件測試策略包括很多方面的內容，如：測試觀點、測試方法、測試用例和測試工具；測試相關的評判標準；測試資源(包括人和物)的分配；影響測試資源或者測試進度的風險管理等。本文主要從測試用例分布和測試角度確定、測試人力資源分布三個方面提出了幾個有效改善測試效果的軟件測試策略。主要解決以下幾個問題：a）如何對測試用例進行合理的預期分布，提高測試的效果和效率；b）如何從不同的角度設計測試用例，提高bug發現率；c）如何通過測試人員的合理分布，提高測試效果。
2.1 測試用例的分布策略
一般而言，針對一個軟件的測試用例集是不可能窮盡的，只能根據各種原則選擇部分典型的用例進行測試。特別是對于一些大型軟件，最終可能需要數以萬計的測試用例來對其進行測試，在測試用例設計之前大量的測試用例該如何進行分布才能達到相對更好的測試效果呢？
1）基于矩陣的首次分布策略
理論上程序規模與測試用例的數量并非線性關系，因為程序規模越大，復雜度就越高，關聯因素也越多，所以對軟件來說并不是單純行數的增長。但是在工程中，為了便于實際操作，大多會簡單將它們假設為線性關系。
為了把握好測試用例數目的合理分布，采用矩陣式首次分布預測法進行分布。以軟件子功能作為矩陣的行，以功能測試的基礎測試觀點作為矩陣的列，如表1所示(表中的行列元素僅僅是舉例說明)。
表1 矩陣法示意表
大功能中功能程序規模用例密度用例總數特殊字符并發操作邊界操作…
大功能1中功能1
中功能2
中功能3
大功能2中功能1
中功能2
統計
根據表1建立如下的測試用例數量預測模型：
a）模型假設前提
忽略軟件復雜度等因素，僅考慮軟件規模。假設規模與測試用例的數量呈線性增長。
b）模型定義
（a）QA=∑Si×Ri(i=1，…，n，表示軟件進行功能劃分后功能模塊個數)。其中：QA表示該系統所需的所有測試用例的總數量；Si表示第i個功能模塊規模(代碼行數，單位：L)；Ri表示第i個功能模塊的測試用例密度(每一千行代碼的平均測試用例個數，單位：個/kL)。測試用例密度一般根據投入測試的人員、時間、規模等不同而有所變化。如果僅考慮測試充分性的情況下，基礎經驗值為200個/kL，根據不同的語言、系統平臺、功能復雜度、難易度等進行適當調整。
（b）QCij=Si×Ri×Wij。其中：QCij表示矩陣的第i行、第j列的單元格預測的測試用例數目；Si和Ri的含義與模型定義(a)中說明相同；Wij表示對該矩陣的第i行來說，矩陣的列元素中第j個基礎測試觀點所占權重值，每行的所有基礎測試觀點的權重值和為100%。各個基礎測試觀點在各行所占的權重值可以不同。
b）分布方法
根據模型定義的(a)利用每個子功能的規模Si和設定好的密度Ri，計算出每個子功能需要設計的測試用例總數目；然后根據模型定義的(b) 利用每個基礎測試觀點權重率Wij計算出每個QCij的值。該值即為編寫測試用例的定量目標。與此同時，矩陣法合理地分布了測試用例，有針對性地提高了測試密度。
大型軟件的測試中最常犯的錯誤之一就是看似都是測試過的功能點，也均是測試過的觀點，但最終還是發生了測試遺漏。通過矩陣法就可以有效保證在矩陣的每個有交叉可能的觀點和功能的交叉點上都實施了測試，所以最大限度地避免了這種類型的測試遺漏。
2)基于分析結果的再次分布策略
如果是按照上述基于矩陣的首次分布策略單純地實施完最初設計的測試用例就認為測試結束，那么測試不能稱之為完整的測試。必須依據第一輪測試發現的bug的分布特征、bug的收斂趨勢等分析結果，判斷是否需要繼續測試。當需要繼續增加測試的情況下，可以采用基于分析結果的再次分布策略來確定增加部分測試用例的分布。
具體實施方法如下：根據功能點和基礎測試觀點進行bug的分布規律分析，將測試發現的bug數都正確地填寫在表1的矩陣中，然后根據數字明確哪些子功能是薄弱點，哪些基礎測試觀點是bug最多的觀點，根據軟件測試中的8020規則(80%的bug集中在20%的程序代碼內)，對于這些交叉點提高測試用例密度，進行增加部分的測試用例再次分布。
2.2 不同角度的測試策略
對同一個事物從不同的角度來看，往往會有不同的觀點。同樣，對于同一個軟件，如果從不同的角度入手進行測試，也會提出各種不同的觀點，有些可能是重疊的，有些則是獨有的。所以從不同角度入手測試，可以更多地覆蓋到軟件的各個方面。
1）基于場景的測試
場景測試指假定自己是被測軟件系統的使用者，在實際使用中，會以什么樣的操作順序如何去使用該軟件，將這樣的可能性都一一列出來形成測試觀點。這種測試策略在思想上與面向對象軟件測試中的基于序列的測試是相同的。該測試與普通的功能測試是不同的，它的側重點在于連續使用整個軟件的各個功能；而功能測試則是針對每個功能點進行全面細致的測試，所以基于場景的測試往往會發現一些普通功能測試不能發現的bug。
2)基于關聯關系的測試
對于一個軟件來說，關聯關系可以分為兩類。一類為橫向的關聯關系，如同一種類型的問題如果在某個功能中發生了，那么在其他功能中是否正確呢？這樣的展開測試稱為橫向展開測試。另一類為縱向的關聯關系，如一個大型軟件有多個功能，它們之間有各種聯系，那么一個功能中有些值/設定/操作改變的情況下另一個關聯的功能處理是否正確呢？這樣的展開測試稱為縱向展開測試。
在已經測試出部分bug之后，針對每個bug實施橫向和縱向兩類的關聯關系測試效果將是非常顯著的。
3)基于接口的測試
接口處往往是最薄弱之處。例如，在一個系統中，有大功能A、B、C，每個大功能下的各種子功能經過單獨測試都是正常的，但是從大功能A中可以調用C，這種調用情況下大功能C的有些功能就不正確了。所以在測試中，列出系統中各種不同類型/級別的功能之間的接口，然后針對接口專門設計測試用例進行測試。
2.3 測試人員的分布策略
根據有效的測試策略方法設計好測試用例之后，就需要測試人員的具體實施。雖然一個好的測試用例不論任何人來測試結果都應該是相同的，但是因為個體差異和知識結構的不同，在實施測試用例的過程中激發的一些思維是各不相同的，所以在實際測試中常常會有一定比率的bug都通過自由測試發現并非測試用例發現的。測試人員如果能合理分布，對于提高測試的質量效率也是很有幫助的。
在測試的人員管理方面，多數情況下，都會是采用某個人負責固定部分的測試到結束為止。這種方法的優點在于一個人一直負責一些固定的內容，操作非常熟練，可能會測試出一些有深度的問題。但是因為長期測試固定內容，往往會形成一些思維定勢，也會造成思維松懈，還缺乏與相關功能的對比聯系，所以測試效果不能達到最佳。為了提高測試的質量，經過實踐總結出結對測試和交叉測試是兩種比較有效的人員分布方法。
1)結對測試
專業的測試團隊往往需要將測試出的問題提交給開發團隊或者測試委托方，為了使開發團隊或者測試委托方能夠清楚地看懂所提交的問題，從而進行有效快速的溝通，在測試團隊內部可以通過結對測試方法確保測試問題的質量。
結對測試是指每兩個人為一個小組，嚴格按照彼此提交的問題重現步驟，互相重現判斷該問題。一方面確保了測試團隊提出的問題是有效的問題；另一方面確保了測試者以外的人可以順利重現該問題，為問題的解決提供方便。
2)人員交叉測試
大型軟件測試中，測試的周期比較長，長期測試相同功能，測試人員容易產生浮躁的心情，為了有效改善這種狀況，可以采用人員交叉的測試方法。該方法主要是交換原定的各個功能的測試者來實施測試用例。注意在該方法開始實施之前，一定要進行一個交流會，每個功能的原計劃測試者需要將自己已知的一些基本內容和想法向大家進行說明，以避免由于人員更換帶來的知識損失。
人員交叉方法的優點如下：a)因為接觸新事物會消除了以前的厭倦感；b)一個大型軟件的各個功能之間大多有一定的聯系，可以通過這些聯系，對以前認識到的內容有進一步的認識進而產生新的測試火花，發現更多的問題。
3 各種軟件測試策略的應用實例
通過很多大型軟件項目的第三方測試實踐，上述的策略均取得了較好的效果，有效地提高了測試質量和測試效率。下面的實例以一個大型軟件測試項目為例展開說明：該軟件總規模為1 500 kL(千行)，測試任務是需要對其中客戶經常使用而且比較重要的400 kL規模的功能進行強化測試。該軟件在市場銷售時間已經長達5年以上，因此客戶經常使用的功能中最普通的bug已經是比較少的，潛在bug都是比較難以發現的，測試工作本身難度較高。該項目的測試工作持續了一年，最多時有15個人同時參與測試。為了達到預定的目標，試用了上述的各種測試策略，最終取得了非常好的效果，得到了客戶委托方的高度好評。
3.1 測試用例分布策略的實例
根據該項目的測試要求和特點，決定采用基于矩陣的首次分布策略進行測試用例的分布預測，測試出實際bug分析，以及基于分析結果的再次分布策略調整增加測試用例的分布。通過該策略的實施，該項目的測試中每個階段目標都很明確，操作性很強，而且將分析結果反饋之后的再測試常常會發現更多的問題。整個策略的實踐過程如下：
a)確定矩陣行和列的具體內容
矩陣列的基礎測試觀點內容包括郵件、WF、Status WF、自增編號、Import/Export、自定義類型、分頁控制、檢索排序、要件、邊界值、特殊字符、大量數據、刪除關系、權限、同時訪問、幫助文檔、數字計算、數據格式、消息正確性、各種日志、TabOrder、打印、組合。矩陣的行即為該軟件的各個功能模塊，一共分為大功能和中功能兩個階層。其中大功能共計9個，中功能共計20個。
b)向測試用例分布矩陣中填入內容
(a)確定矩陣每行(每個中功能)的代碼規模數和每列(基礎測試觀點)權重值。
(b)確定平均測試用例密度TC(單位：用例數/kL)：
TC=P×H×E/S
其中：P為測試人數(單位：人)；H為測試時間(單位：d)；E為測試效率，即人均每天做成實施測試用例數，按照經驗值40計算；S為軟件規模(單位：L)。
(c)根據各個子功能的重要度，復雜度在平均密度上進行微調。
(d)根據各子功能模塊的規模和密度計算相應的該模塊應該實施的測試用例總數。
(e)根據每個基礎測試觀點的權重值計算每個子功能在每個觀點下預期實施的測試用例個數。
c)運用bug分布矩陣進行bug分析
實施測試，然后將各個交叉點測試出的bug填入bug分布矩陣(該矩陣結構與測試用例分布矩陣相同)中。分別以矩陣的行和列為基點，得出如圖1、2所示的分析結果。
根據分析可以知道，發生bug較多的基礎測試觀點主要有組合、特殊字符刪除關系、邊界值大量數據等。發生bug較多的功能點主要是品質管理、進度管理和任務管理等。
d）基于分析結果的測試用例再次分布
根據上述分析，對于比較薄弱的觀點和功能，再次增加測試，在測試用例分布矩陣中，這些交叉點再次分配新的測試用例數目，強化測試的力度。
e）最終效果確定
通過以上的四步測試，在最初投入12人為期43 d的測試中發現bug共計207個，效果非常顯著。
3.2 不同角度測試策略的實例
針對2.2節中描述了幾種不同角度的測試，這里僅以基于關聯關系的測試為例進行詳細說明。在該項目的第一階段測試中期，發現bug總計19個。此時采用了橫向展開測試，通過bug的測試者對每個bug進行說明和演示，使得其他測試人員了解這些bug的現象，然后在自己負責測試的功能模塊中確認是否有同樣或者類似的問題。在第一階段測試結束時，又發現bug總計28個，其中有15個都是通過橫向展開測試發現的，占其中的54%。
隨著測試工作的深入，測試人員對該大型軟件也越來越熟悉。但是因為該軟件功能強大，各個功能之間都有一定的聯系，所以常常因為不知道這些聯系而遺漏了一些測試。這種情況下縱向展開測試可以發揮比較好的效果。本次縱向展開測試具體實施是通過大家共同完成該系統的各功能模塊的關聯關系圖的方式進行的。每個人貢獻自己知道的一部分，合起來便完成了整個系統各功能模塊的關聯關系圖。與此同時，各位測試人員對各種縱向關聯關系也就清楚了。在接下來對第一階段測試發現的bug進行確認測試過程中，通過這種縱向展開測試，又新發現了14個bug。
通過實踐基于關聯關系的測試策略，充分驗證了軟件測試中的8020原則。所以對于已經發現的bug進行充分的周邊展開測試是非常有效的。
3.3 測試人員分布策略的實例
該項目的測試中，在第一階段結束以后，測試人員大多都認為自己負責的部分該測的都已經測過了，應該不會再有問題了，因此出現了思想懈怠，同時因為長期面對一件事情，心理上也出現了反感的情緒。為了提高測試的質量，采用了人員交叉的分布策略，即交換每個人負責測試的功能模塊，這個策略使得測試取得了出其不意的效果。例如，對于該軟件的品質管理功能，在采用人員交叉策略之后，經過交叉人員的共同努力，第二階段發現的bug達到了第一階段的兩倍。
通過這個策略的實施，每個人不僅接觸了新的內容，更重要的是通過新舊結合產生了更多的組合觀點，這個調整也進一步推動了縱向關聯關系策略更加深入地進行。
另外，關于結對測試的策略，在該項目的測試中擴展為分組測試，即2、3人為一個組，組內確認bug無誤后再向委托方提交。經過這個策略的運用，提交給委托方的軟件問題，他們需要再次與測試人員進行確認的比率由最初的60%下降到后來的15%，這樣為雙方的工作節約了大量的時間，很好地提高了工作效率。
4 結束語
為了提高軟件測試的質量和效率，本文從三個不同方面提出了幾個關于軟件測試的策略。這些策略與具體的黑盒測試的各種方法相結合，使得軟件測試更加系統化、靈活化，測試的效率和質量都會得到明顯提升。目前自動化測試是軟件測試領域蓬勃發展的一個分支。自動化測試帶來的便利之處有目共睹，但是自動化測試也并非所有的測試都適用，所以對于如何有效地進行自動化測試將是需要繼續研究的一個問題。
參考文獻：
［1］PATTON R. 軟件測試[M]. 北京：機械工業出版社，2004.
[2]張海番. 軟件工程導論[M]. 3版. 北京：清華大學出版社，1998.
[3]董曉霞. 相鄰因素組合測試用例集的最優生成方法[J]. 計算機學報， 2007，30(2)：200210.
[4]楊玲萍，韓陽. 基于功能點分析測試設計充分性模糊評判建模[J]. 計算機工程與應用，2007，43(3)：106111.
[5]張永強，陳永革，姚立新. 軍用軟件的測試與實踐方法[J]. 火力與指揮控制，2006，31(9)：9193.
[6]朱海燕. 關于兩兩測試的研究[J]. 計算機工程與設計， 2006，27(15)：28022804.
[7]董曉霞. 軟件測試工程化的研究和實踐[J]. 計算機工程與設計， 2006，27(11)：20082011.
