 你在日常的工作中沒有遇到問題嗎？如果有，你也可以提交案例�！�我要提交案例】 |
| 案例分析 |
| |
|
本期案例 |
題目：白盒測試的困惑：究竟多少人在做？適用范圍？
所屬主題：測試技術
作者：Alan |
案例內容：
一般軟件工程書籍在介紹白盒測試時，通常包括了“流圖符號”、“環形復雜性估算”、“圖矩陣”、“條件測試”、“數據流測試”、“循環測試”等方法。這些方法比較復雜，對于非關鍵性應用（即除了航空航天，原子能反應堆控制等領域），從經濟角度來看進行白盒測試似乎不大合理。
XP的測試驅動開發中強調的單元測試，從網絡上現有的介紹資料（主要是JUnit和NUnit的有關文檔）來看，似乎僅限于程序特性的驗證而已，和測試理論書籍中的白盒測試、黑盒測試還是有很大不同。
像Parasoft公司的JTest、C++Test等工具，其中的文檔好像說要進行一般測試理論意義上的那種單元測試，就必須采用Design by Contract的方法。也就是說，必須提供嚴格的程序規格說明。
那么，一般的應用開發，特別是企業應用開發，考慮到經濟合理的目標，應該如何進行測試呢？
誠心請教各位，你們真正做過那種測試理論書上的白盒測試嗎？這種白盒測試適用范圍何在？特別希望在航空航天、國防軍工領域，或者嵌入式開發、電信開發領域有測試經驗的網友給予指點！不勝感激！
而且，另外一個感覺是所有的書都在互相抄襲，不知道誰是原創。關于白盒測試，幾乎所有書的案例都是同一個！哪位有經驗的網友能夠給出一個不同于測試理論書中的實際案例？謝謝！
另外，那本《Software Testing - A Craftsman Approach》（網上有英文電子版，中文版由機械工業出版），作者的開發領域是電話交換系統。那么，除了這種領域的開發，比如ERP開發，就不需要這種嚴格的形式化的以數學理論為基礎的測試嗎？ERP測試有什么方法呢？哪位網友能談談呢？ |
相關分析 |
|
|
分析一：
分析內容：
白盒測試實際上是一種測試方法，測試的一種思維方式.按照解釋來看，就是基于被測對象的結構來設計測試套件。有些人習慣的將白盒測試和單元測試混淆在一起。實際上集成,系統測試都可以使用白盒測試的方法。
即使在ERP類型的軟件測試中，也是有需要單元測試的地方。系統中關鍵的組件、類、服務端組件都是需要經過嚴格的各個級別的測試。
有的公司可能會有詳細的函數規格說明書，在這樣的情況下，采用白盒測試技術的單元測試是必須要做的。 |
分析二：
作者：newbie
分析內容：
基于功能規格說明書的測試，應該是黑盒測試吧？
我理解白盒測試應該是基于程序源代碼或者控制流程圖之類能夠揭示程序內部結構的制品（artifact）的測試。
我希望了解的是，如何采用白盒測試技術進行單元測試？特別是ERP領域。希望能夠提供實例。先謝謝了！
白盒測試，就是在已經了解軟件的內部結構的基礎上，有針對性地設計更有可能暴露和揭示程序錯誤和缺陷的測試用例的測試方法。
在單元測試階段，白盒測試需要程序源代碼或控制流程圖；而黑盒測試需要程序功能規格說明書。
在集成測試階段，白盒測試需要交互圖（序列圖和協作圖）；而黑盒測試需要集成模塊的規格說明書。
依次類推。 |
分析三：
作者：cocoying
分析內容：
個人認為黑盒測試、白盒測試都是相對的！
對于一個模塊進行黑盒測試，他對于整個系統就是白盒測試！
而對于一個類進行黑盒測試，他對于所屬模塊就是白盒測試！
對于一個方法乃至算法進行黑盒測試，他對于所屬類就是白盒測試！ |
分析四：
作者：hunle
分析內容：
贊同cocoying
個人認為：最好不要用黑盒、白盒來區分測試（尤其是對于測試工作人員）。 應該針對不同的測試對象選用不同的測試方法， 以期達到不同的測試標準。 |
分析五：
作者：Alan
分析內容：
white box ，black box 測試只是一種測試方法。和測試的類型沒有必然的聯系。即使是系統級別的測試，也可以使用white box 。同樣你對一個單元測試的時候，比方一個函數，也是可以采用black box 來測試函數的外部特性。 |
分析六：
作者：取自深圳測試論壇深圳測試論壇流程版
分析內容：
第四環節單元測試
這一個環節是單元測試。在測試過程中，這一塊是比較神秘的地方。因為國內的測試人員，有很多人都是看過理論知道而 沒有真實的去做過。單元測試對測試人員設計能力要求比較高。
單元測試也要有測試計劃、測試用例等相關文檔。當然，如果不做單元測試的話也就不會有這些文檔了。單元測試的技術
從整體上可分為白盒測試和黑盒測試其實就是對程序的邏輯結構和數據流的檢查。
白盒測試也就是我們通常是的程序員代碼互查。通常使用的技術是獨立路徑測試。主要是要檢查獨立的執行路徑，程序是否有邏輯錯誤，對循環的檢查，還有內部數據的有效性檢查等等。
黑盒測試注重于測試軟件的功能性需求，通常黑盒測試試圖發現以下類型的錯誤：功能不正確或遺漏，接口錯誤，性能錯誤等等。黑盒測試技術通常分為等價劃分、邊界值分析、因果圖等。做黑盒測試要設計驅動模塊和樁模塊，也就是要測試人員寫代碼了。
單元測試更多的也還是借助于測試工具，但是有相當一部分的單元測試工具是要和源代碼結合起來的。所以要做好單元測試就要有比較好的編碼功底了。
由于開發方式的不同，單元的劃分存在一些差異，一般的單元劃分方法如下：
面向對象的軟件開發：以Class(類)作為測試的最小單元。以方法的內部結構作為測試的重點。
結構化的軟件開發： 以模塊（函數、過程）作為測試的最小單元。
在這里我不試圖對單元測試做更多的講解，所以這一環節的內容很少。 |
分析七：
作者：ahhuang
分析內容：
測試的類型分單元、集成、系統、接受性測試。測試的技術則有白、灰、黑盒。
呵呵，不想在浪費時間紙上談兵。但清晰的概念有利于討論。
將單元測試類型同白盒測試技術混淆是非常正常的，但也沒什么大不了的（畢竟我們不是理論家，而是實干者）。
關鍵是如果你為每個“單元”都編寫驅動和樁模塊，來跑遍所有測試路徑，那你就達到了兩者的和諧統一。但這通常是不可能的（sorry，是對于我們開發非高危性系統來說），除非你時間盒資源大大的多。
實際上更可行的做法是單元集測試（編寫少量的驅動和樁模塊，對幾個有調用關系的單元聯測）運用上灰盒測試（接口級別的測試），以期望少投入，快產出，當然，這是以質量為代價的（進度要求同質量總是成反比的） |
分析八：
作者：yanyubaobao
分析內容：
之前一直做功能性驗證測試，熟悉了自動測試軟件，最近看到一份程序員提供的部分軟件函數說明，在分析這些函數功能和參數以及各自關系的過程中發現很多在集成測試中不好發現的問題在這里可以找到很好的依據，在某種程度上可以加強測試的深度
不過我們在用戶方面使用深度的探索上有待提高，什么是用戶常用的，我們需要尋找。 |
分析九：
作者：關河
分析內容：
首先，白盒測試 不等于 單元測試
白盒測試是一種測試方法，而單元測試是測試過程。
在單元測試過程中，一般采用白盒測試的方法，但由于要實現完整意義上的路徑覆蓋測試開銷實在太大，一般的公司很少會把路徑覆蓋作為單元測試的退出準則，我所見到的一般要求語句覆蓋不小于90％（甚至更高）。
除單元測試意外的測試階段（集成測試、系統測試）也可以采用白盒測試方法，此時的白盒測試方法體現在利用對代碼的認識設計相應的測試用例，這部分就是非常依賴經驗和開發基礎的了，如yanyubaobao所說：“在分析這些函數功能和參數以及各自關系的過程中發現很多在集成測試中不好發現的問題在這里可以找到很好的依據”，通過這種方式可以將測試進行到更深入的程度。 |
分析十：
作者：戴金龍
分析內容：
白盒和黑盒是針對同一事物采用不同的觀察角度而產生出的方法差異。白盒注重事物內部的組織、結構與邏輯；黑盒注重事物整體的一致、協作與效用。二者是相輔相成的，統一于高品質的軟件測試過程之中。
有時候，事物本身是如此復雜，以致單使用白盒和黑盒方法還不足以描述清楚其局部與整體、內部與外部之間錯綜復雜的關系，于是，人們又提出灰盒的概念， 灰盒是聯系白盒方法與黑盒方法的一個中間地帶。視所分析的對象本質及環境不同，灰盒的“寬度”有所差異。
打個比方，研究一棵樹木，如果去一一察看它的葉子、樹冠、樹干和根系，這時使用的就是白盒方法；如果要綜合起來判斷樹木的種屬、生長狀態及使用價值，這時使用的就是黑盒測試的方法；而如何從葉子、樹冠、樹干及根系推斷出種屬、生長狀態及使用價值，就得灰盒測試的方法。
白盒與黑盒是相對的。例如，研究一棵樹木的種屬、生長狀態及使用價值在上面的例子中屬于黑盒部分，但如果研究對象是整片的樹林，自然，上述部分又成了白盒方法應該關心的內容了。
白盒與黑盒乃至灰盒在測試流程中具體如何使用，使用到什么程度，部分是工程問題，部分是藝術問題。工程問題，可以借鑒以往的技術文檔照貓畫虎，藝術問題則要靠管理者個人的技能、對團隊成員的領悟以及對工程環境的把握來統籌完成。 |
測試時代工作室分析 |
|
|
從產品來講：商業級應用軟件中要求最高的就是金融類了，這就決定了軟件的側重點－即數據安全及正確。其次才是流程的正確和軟件的易用。
從軟件內部實現來看：80%以上的代碼是用來實現框架、應用及流程的，只有不到20%的代碼用于完成數據校驗和計算。
由此可見，商業軟件的測試中，關鍵的測試所占比例不高。
從測試技術上講：商業軟件所使用到的技術主要是黑盒測試技術，這是其特點所決定的。還有少量的白盒技術，但在實際中很少有公司愿意投入人力來作。
白盒測試做法
第一步：確定軟件中的數據計算及校驗模塊
第二步：使用基本路徑法計算模塊中所有可能的路徑
第三步：設計用例，覆蓋所有路徑
商業應用級軟件的白盒測試只需使用基本路徑法遍歷路徑即可�；韭窂椒ǹ稍谌我庖槐窘榻B測試技術的書籍中找到。
目的：驗證設計實現即可。（無需做到軍用或航天產品的質量級）
好處：降低測試的難度以壓縮測試周期和投入。
使用范圍：測試的各階段均可進行白盒測試。
使用對象：數據安全和數據計算。（如利息或稅費計算）
說明：
1.基本路徑法比較嚴謹，符合使用對象對測試的要求。
2.由于使用方法單一，從而在不降低測試效果的前提下降低的技術復雜性和實現難度。
3.由于只針對不到20%的代碼進行白盒測試，所以比較經濟。
|
| 關注案例 |
|
|
焦點5：在軟件項目規劃和開發階段，如何考慮與測試配合？
焦點6：覆蓋率如何計算？
焦點7：如何進行滾動測試？
焦點8：嵌入式軟件的測試設計應該如何做？
焦點9：怎么搭建測試環境。  |
|
|
| 你在日常的工作中沒有遇到問題嗎？如果有，你也可以提交案例�！�我要提交案例】 |
|
案例分析
