黑盒測試與白盒測試區(qū)別

黑盒測試與白盒測試區(qū)別

黑盒測試

　　黑盒測試也稱功能測試或數(shù)據(jù)驅(qū)動(dòng)測試，它是在已知產(chǎn)品所應(yīng)具有的功能，通過測試來檢測每個(gè)功能是否都能正常使用，在測試時(shí)，把程序看作一個(gè)不能打開的黑盆子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測試者在程序接口進(jìn)行測試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)鋸而產(chǎn)生正確的輸出信息，并且保持外部信息（如數(shù)據(jù)庫或文件）的完整性。黑盒測試方法主要有等價(jià)類劃分、邊值分析、因—果圖、錯(cuò)誤推測等，主要用于軟件確認(rèn)測試。 “黑盒”法著眼于程序外部結(jié)構(gòu)、不考慮內(nèi)部邏輯結(jié)構(gòu)、針對(duì)軟件界面和軟件功能進(jìn)行測試?！昂诤小狈ㄊ歉F舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯(cuò)誤。實(shí)際上測試情況有無窮多個(gè)，人們不僅要測試所有合法的輸入，而且還要對(duì)那些不合法但是可能的輸入進(jìn)行測試。
白盒測試

　　白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動(dòng)測試，它是知道產(chǎn)品內(nèi)部工作過程，可通過測試來檢測產(chǎn)品內(nèi)部動(dòng)作是否按照規(guī)格說明書的規(guī)定正常進(jìn)行，按照程序內(nèi)部的結(jié)構(gòu)測試程序，檢驗(yàn)程序中的每條通路是否都有能按預(yù)定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅(qū)動(dòng)、基路測試等，主要用于軟件驗(yàn)證。

　　“白盒”法全面了解程序內(nèi)部邏輯結(jié)構(gòu)、對(duì)所有邏輯路徑進(jìn)行測試?！鞍缀小狈ㄊ歉F舉路徑測試。在使用這一方案時(shí)，測試者必須檢查程序的內(nèi)部結(jié)構(gòu)，從檢查程序的邏輯著手，得出測試數(shù)據(jù)。貫穿程序的獨(dú)立路徑數(shù)是天文數(shù)字。但即使每條路徑都測試了仍然可能有錯(cuò)誤。第一，窮舉路徑測試決不能查出程序違反了設(shè)計(jì)規(guī)范，即程序本身是個(gè)錯(cuò)誤的程序。第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯(cuò)。第三，窮舉路徑測試可能發(fā)現(xiàn)不了一些與數(shù)據(jù)相關(guān)的錯(cuò)誤。

軟件人員使用白盒測試方法，主要想對(duì)程序模塊進(jìn)行如下的檢查：
– 對(duì)程序模塊的所有獨(dú)立的執(zhí)行路徑至少測試一次；
– 對(duì)所有的邏輯判定，取 “ 真 ” 與取 “ 假 ” 的兩種情況都至少測試一次；
– 在循環(huán)的邊界和運(yùn)行界限內(nèi)執(zhí)行循環(huán)體；
– 測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性，等。
具體包含的邏輯覆蓋有： – 語句覆蓋 – 判定覆蓋 – 條件覆蓋 – 判定－條件覆蓋 – 條件組合覆蓋 – 路徑覆蓋。

白盒測試技術(shù)(White Box Testing) ： 深入到代碼一級(jí)的測試，使用這種技術(shù)發(fā)現(xiàn)問題最早，效果也是最好的。該技術(shù)主要的特征是測試對(duì)象進(jìn)入了代碼內(nèi)部，根據(jù)開發(fā)人員對(duì)代碼和對(duì)程序的熟悉程度，對(duì)有需要的部分進(jìn)行在軟件編碼階段，開發(fā)人員根據(jù)自己對(duì)代碼的理解和接觸所進(jìn)行的軟件測試叫做白盒測試。這一階段測試以軟件開發(fā)人員為主，在 JAVA 平臺(tái)使用 Xunit 系列工具進(jìn)行測試， Xunit 測試工具是類一級(jí)的測試工具對(duì)每一個(gè)類和該類的方法進(jìn)行測試。

黑盒測試技術(shù)（ Black Box Testing ）：黑盒測試的內(nèi)容主要有以下幾個(gè)方面，但是主要還是功能部分。主要是覆蓋全部的功能，可以結(jié)合兼容，性能測試等方面進(jìn)行，根據(jù)軟件需求，設(shè)計(jì)文檔，模擬客戶場景隨系統(tǒng)進(jìn)行實(shí)際的測試，這種測試技術(shù)是使用最多的測試技術(shù)涵蓋了測試的方方面面，可以考慮以下方面

c正確性 (Correctness) ：計(jì)算結(jié)果，命名等方面。

d可用性 (Usability) ：是否可以滿足軟件的需求說明。

e邊界條件 (Boundary Condition) ：輸入部分的邊界值，就是使用一般書中說的等價(jià)類劃分，試試最大最小和非法數(shù)據(jù)等等。

f性能 (Performance) ： 正常使用的時(shí)間內(nèi)系統(tǒng)完成一個(gè)任務(wù)需要的時(shí)間，多人同時(shí)使用的時(shí)候響應(yīng)時(shí)間在可以接受范圍內(nèi)。 J2EE 技術(shù)實(shí)現(xiàn)的系統(tǒng)在性能方面更是需要照顧的，一般原則是 3 秒以下接受， 3-5 秒可以接受， 5 秒以上就影響易用性了。如果在測試過程中發(fā)現(xiàn)性能問題，修復(fù)起來是非常艱難的，因?yàn)檫@常常意味著程序的算法不好，結(jié)構(gòu)不好，或者設(shè)計(jì)有問題。因此在產(chǎn)品開發(fā)的開始階段，就要考慮到軟件的性能問題

g壓力測試 (Stress) ： 多用戶情況可以考慮使用壓力測試工具，建議將壓力和性能測試結(jié)合起來進(jìn)行。如果有負(fù)載平衡的話還要在服務(wù)器端打開監(jiān)測工具 , 查看服務(wù)器 CPU 使用率，內(nèi)存占用情況，如果有必要可以模擬大量數(shù)據(jù)輸入，對(duì)硬盤的影響等等信息。如果有必要的話必須進(jìn)行性能優(yōu)化 ( 軟硬件都可以 ) 。這里的壓力測試針對(duì)的是某幾項(xiàng)功能。

h錯(cuò)誤恢復(fù) (Error Recovery) ：錯(cuò)誤處理，頁面數(shù)據(jù)驗(yàn)證，包括突然間斷電，輸入臟數(shù)據(jù)等。

i安全性測試 (Security) ：這個(gè)領(lǐng)域正在研究中，防火墻、補(bǔ)丁包、殺毒軟件等的就不必說了，不過可以考慮。破壞性測試時(shí)任意看了一些資料后得知 , 這里面設(shè)計(jì)到的知識(shí) 內(nèi)容可以寫本書了 , 不是一兩句可以說清的，特別是一些商務(wù)網(wǎng)站，或者跟錢有關(guān)，或者和公司秘密有關(guān)的 web 更是需要這方面的測試，在外國有一種專門干這一行的人叫安全顧問，可以審核代碼，提出安全建議，出現(xiàn)緊急事件時(shí)的處理辦法等，在國內(nèi)沒有聽說哪里有專門搞安全技術(shù)測試的內(nèi)容。

j 兼容性 (Compatibility) ：不同瀏覽器，不同應(yīng)用程序版本在實(shí)現(xiàn)功能時(shí)的表現(xiàn)不同的上網(wǎng)方式，如果你測試的是一個(gè)公共網(wǎng)站的話。