軟件測試的新方法一灰盒測試在測試領域眾所周知存在黑盒測試和白盒測試，黑盒測試更多是在集成測試階段進行只關注應用是否符合需求，而不關心代碼設計的結構，方式，方法。而白盒測試是針對黑盒測試提出的，前提是知道軟件產品內部工作過程。通過測試來檢測軟件產品內部動作是否按照規(guī)格說明書的規(guī)定正常進行，通常是在單元測試階段進行。那么做了這兩種測試是否覆蓋了軟件測試的全部內容，即是否就能保證產品的質量呢。其實是不一定的，或者說如果靠這兩種方法來覆蓋，投入的代價是比較大的。譬如目前很火的OPENAPI的測試，譬如對具備軟件平臺性質產品的測試。因為通過黑盒手工測試是很難完成的，而白盒測試是在單元測試進行的，顯然對產品的測試帶來很大的局限性，它也無法測試到產品在集成過程中帶來的問題。那么灰盒測試就有它出現的必然性，這就是所謂存在就是合理的。灰盒測試的特性：.灰盒測試通常是在集成測試前期進行的。灰盒測試通常在程序員做完白盒測試之后（有些書上認為白盒測試是由測試人員進行的，我覺得純屬理想主義），在功能測試人員進行大規(guī)模集成測試之前進行的。.灰盒測試是需要了解代碼工程的實現的.灰盒測試是通過類似白盒測試的方法進行的，也就是說和白盒測試的方法是相同的，是通過編寫代碼，調用函數或者封裝好的接口進行的。.灰盒測試是由測試人員進行測試的。灰盒測試和白盒測試的區(qū)別.測試的時段不同，白盒測試在單元測試階段進行，灰盒測試在集成測試前期進行.測試的關注對象不同，白盒測試更關注內部實現是否按照規(guī)格說明書進行，灰盒測試除了需要關注白盒測試關注的內容還更多從業(yè)務層面去考慮問題，考慮更多的組合測試業(yè)務場景。.范圍不同，白盒測試更關注單個代碼段，函數的正確性，灰盒測試的對象已經基本能完成一個完整的業(yè)務功能。.灰盒測試的代碼比較獨立，不像白盒測試基本上和程序代碼需要做到一一對應。灰盒測試和白盒測試的相同點.目的相同.方法相同，都是需要通過代碼來實現.對測試人員素質要求相同灰盒測試和黑盒測試的不同點.測試的方法不同。.對測試人員要求不同?；液袦y試要求比較強的編程能力。.測試范圍不同，關注的對象不同，黑盒測試是覆蓋產品范圍最廣的測試，是灰盒測試無法取代的。但是灰盒測試是可以被黑盒替代的，只是代價比較大，需要很多的測試用例。灰盒測試和黑盒測試的相同點.目的相同.測試所處的時間段相近?；液袦y試，確實是介于白盒測試與黑盒測試之間的，可以這樣理解，灰盒測試關注輸出對于輸入的正確性，同時也關注內部表現，但這種關注不象白盒那樣詳細、完整，只是通過一些表征性的現象、事件、標志來判斷內部的運行狀態(tài)，有時候輸出是正確的，但內部其實已經錯誤了，這種情況非常多，如果每次都通過白盒測試來操作，效率會很低，因此需要采取這樣的一種灰盒的方法?；液袦y試結合了白盒測試和黑盒測試的要素.它考慮了用戶端、特定的系統(tǒng)知識和操作環(huán)境。它在系統(tǒng)組件的協同性環(huán)境中評價應用軟件的設計?；液袦y試由方法和工具組成，這些方法和工具取材于應用程序的內部知識和與之交互的環(huán)境，能夠用于黑盒測試以增強測試效率、錯誤發(fā)現和錯誤分析的效率。灰盒測試涉及輸入和輸出，但使用關于代碼和程序操作等通常在測試人員視野之外的信息設計測試。黑盒測試、白盒測試和灰盒測試的基本概念.黑盒測試黑盒測試也稱功能測試或數據驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內部結構和內部特性的情況下，測試者在程序接口進行測試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當地接收輸入數鋸而產生正確的輸出信息，并且保持外部信息（如數據庫或文件）的完整性。黑盒測試方法主要有等價類劃分、邊值分析、因一果圖、錯誤推測等，主要用于軟件確認測試?！ê诤小ǚㄖ塾诔绦蛲獠拷Y構、不考慮內部邏輯結構、針對軟件界面和軟件功能進行測試。〃黑盒〃法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。.白盒測試白盒測試也稱結構測試或邏輯驅動測試，它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規(guī)格說明書的規(guī)定正常進行，按照程序內部的結構測試程序，檢驗程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用于軟件驗證。〃白盒〃法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試?！ò缀小ǚㄊ歉F舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯著手，得出測試數據。貫穿程序的獨立路徑數是天文數字。但即使每條路徑都測試了仍然可能有錯誤。第一，窮舉路徑測試決不能查出程序違反了設計規(guī)范，即程序本身是個錯誤的程序。第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發(fā)現不了一些與數據相關的錯誤。.灰盒測試灰盒測試，確實是介于二者之間的，可以這樣理解，灰盒測試關注輸出對于輸入的正確性，同時也關注內部表現，但這種關注不象白盒那樣詳細、完整，只是通過一些表征性的現象、事件、標志來判斷內部的運行狀態(tài)，有時候輸出是正確的，但內部其實已經錯誤了，這種情況非常多，如果每次都通過白盒測試來操作，效率會很低，因此需要采取這樣的一種灰盒的方法?；液袦y試結合了白盒測試盒黑盒測試的要素.它考慮了用戶端、特定的系統(tǒng)知識和操作環(huán)境。它在系統(tǒng)組件的協同性環(huán)境中評價應用軟件的設計。灰盒測試由方法和工具組成，這些方法和工具取材于應用程序的內部知識盒與之交互的環(huán)境，能夠用于黑盒測試以增強測試效率、錯誤發(fā)現和錯誤分析的效率?；液袦y試涉及輸入和輸出，但使用關于代碼和程序操作等通常在測試人員視野之外的信息設計測試。淺談灰盒測試自動化工具AppSightV2黑白雙煞的困惑大家都知道，在軟件開發(fā)生命周期過程中測試的地位舉足輕重，它要占據這個軟件開發(fā)生命周期中相當多的時間。典型的測試方法即黑盒測試和白盒測試。前者也稱功能測試或數據驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用。在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內部結構和內部特性的情況下，測試者在程序接口進行測試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當地接收輸入數鋸而產生正確的輸出信息，并且保持外部信息（如數據庫或文件）的完整性。后者則是也稱結構測試或邏輯驅動測試，它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規(guī)格說明書的規(guī)定正常進行。按照程序內部的結構測試程序，檢驗程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能。是否有了黑白雙煞兩種手段后就可以保證測試工作高效進行、應用軟件又是否能夠如期交付呢,我們先來看一組統(tǒng)計數據，如圖1所示。iSi+期*礪素綠 ?熨用俄 網Q氈嘮副也 電a圖1測試發(fā)現問題后解決問題占用了更多的時間事實上，軟件測試的根本目的是要提高應用軟件的質量，保證其未來能夠可靠穩(wěn)定運行。圖1的數據也充分說明了，隨著測試的深入，測試發(fā)現問題后的解決問題占用了更多的時間。此時黑盒白盒都顯然有些力不從心了。白盒測試的代碼掃描和應用功能掛不上鉤，而黑盒測試的結果就是測試人員把自動化功能測試發(fā)現的問題通過缺陷跟蹤系統(tǒng)提交給開發(fā)人員處理。盡管好一點的測試人員會提供詳細的測試用例文檔和錯誤截圖，但是開發(fā)人員仍不得不面臨重現問題并不斷的采用Trial&Error的手段來分析并解決問題。很顯然這種問題處理方式是手工方式且非常沒有效率，會延緩問題的處理時間。因此，我們需要另辟新徑?；液芯銈?，只欠工具所謂灰盒測試，是介于黑盒和白盒之間的，既關注輸出對于輸入的正確性，同時也關注內部表現的測試方法。這種關注不像白盒那樣詳細、完整，只是通過一些表征性的現象、事件、標志來判斷內部的運行狀態(tài)。它達到了某種目的，也就是一旦發(fā)現問題，可以迅速定位到黑盒中的某個分支，甚至代碼級別。灰盒測試在系統(tǒng)組件的協同性環(huán)境中評價應用軟件的設計，從而增強了測試效率、錯誤發(fā)現和錯誤分析的效率，可以使得測試達到一個新的境界。但是，灰盒測試對測試人員的要求也比較高，比如灰盒測試要求測試人員具有豐富的開發(fā)知識;需要測試人員更多地從業(yè)務層面去考慮問題，考慮更多的組合測試業(yè)務場景的能力;另外，很多時候問題的解決還需要很多外圍知識，包括數據庫層面上的分析能力、J2EE服務器內部的調用鏈分析等。所以簡單來看，灰盒測試是一個非常好的測試理念，但要真正發(fā)揮其作用，顯然還需要相應的自動化工具這個東風來吹一下。AppSight就是其中一種自動化工具。AppSight概述AppSight由來已久，原來是有Identify開發(fā)的，之后被BMC公司收購但是獨立運營?；液袦y試方法灰盒測試中的精華就是通過灰盒測試能大大縮短解決測試中發(fā)現的問題的時間。問題解決流程實際上包括了主要兩個過程：“根源問題分析”和“問題解決”。而以經驗來看，以前我們的時間主要是耗費在“根源問題分析”上的，一旦問題被定位，解決問題相對是非常容易的。為了進行根源問題分析，通常需要3個典型步驟來進行分析:信息收集、問題重現和問題分析可惜的是，目前來看，大多數開發(fā)人員都是手工來完成這些步驟的，即這個流程是非高效的手工方式，而且易于出錯。而AppSight這個工具的背后實際上是提供了一種問題解決思路的轉變，也就是說需要把重現問題這個環(huán)節(jié)最大程度地消除，同時在發(fā)現問題的時候就盡可能的去收集問題信息和相關環(huán)境信息，并協助定位問題。這于灰盒測試的方法實際上是不謀而合的，如圖2所示。圖2AppSight提供了一種問題解決思路的轉變工作原理BMCAppSight應用解決方案事實上是通過采用類似于飛機上的“黑盒子”專利技術來使得測試后問題解決流程變得更加自動化。這又完全不同于黑盒測試，原因在于飛機的黑盒子最終是可以被解剖的，而黑盒測試永遠是面對一個黑盒子。具體而言，AppSight系統(tǒng)會將問題發(fā)生的相關信息完整錄制下來，包括問題發(fā)生的現場場景、信息及分析等，從而快速切入到問題根源。如圖3所示。圖3AppSight系統(tǒng)會將問題發(fā)生的相關信息完整錄制下來下面是運用AppSight工具的典型測試工作流程。.測試人員通過AppSight提供的錄制器進行測試錄制，由于灰盒測試不同于黑盒測試中主要強調回歸測試的概念，因此錄制不需要添加校驗點和進行參數化，整個過程相當簡單易用。.錄制過程中，錄制器會將所有過程錄制成一個灰盒文件，同時包含了很多環(huán)境信息和錄制中的性能數據信息:如數據庫調用、Web訪問信息、J2EE/.NET調用信息等，這些信息將有助于將來問題的分析。.錄制完成后通過AppSight的集成器將缺陷自動創(chuàng)建到缺陷跟蹤系統(tǒng)中，同時附上灰盒文件，于是開發(fā)人員可以進行問題處理。.開發(fā)人員拿到相關信息后，可以直截了當地看到當時測試用例的全過程，加之灰盒文件提供了有價值的信息，進而可以快速定位到代碼中某一行的位置，這樣開發(fā)人員就只需要直接進行問題處理即可。圖4問題最終被AppSight準確定位到應用代碼相應行和函數小結BMCAppSight通過自動化手段進行灰盒測試的優(yōu)化應用，并提供開發(fā)測試解決方案。它采用的專利問題解決方案技術，從以下幾個方面大大加速了測試過程中問題解決流程:提供了自動化的信息采集、捕獲現場操作并將所有的相關信息統(tǒng)一打包處理;消除了通常情況下需要完整重現問題發(fā)生的過程，避免在重現問題上耗費的時間開銷;大大加速了問題分析的過程，使得開發(fā)人員能夠快速分析問題并隔離根源問題。AppSight應用問題解決方案非常適用于測試人員和開發(fā)人員。對于測試人員事實上，BMC來說，由于自動記錄了測試場景和問題發(fā)生過程，避免了開發(fā)人員和測試人員之間相互推諉，同時開發(fā)人員可以通過“黑盒子”直接從測試人員那里得到更多信息，并幫助直接定位到代碼行。如果說灰盒測試只是萬事俱備只欠東風，那么AppSight就是東風。灰盒測試技術灰盒測試法1999年，美國洛克希德公司發(fā)表了灰盒測試法的論文，提出了灰盒測試法?；液袦y試是一種綜合測試法，它將黑盒測試、白盒測試、回歸測試和變異(Mutation)測試結合在一起，構成一種無縫測試技術。它是一種軟件全壽命周期測試法，用于在功能上檢驗為嵌入式應用研制的Ada、C、FORTRAN和匯編語言軟件。該方法可自動生成所有測試軟件，從而降低了成本，減少了軟件的研制時間。初步研究表明過去要用幾天時間對一套軟件進行徹底測試，現在不到4小時就可完成，軟件測試時間減少75,。灰盒測試定義為將根據需求規(guī)范說明語言(RSL)產生的基于測試用例的要求(RBTC)，用測試單元的接口參數加到受測單元，檢驗軟件在測試執(zhí)行環(huán)境控制下的執(zhí)行情況?；液袦y試法的目的是驗證軟件滿足外部指標要求以及軟件的所有通道都進行了檢驗。通過該程序的所有路徑都進行了檢驗和驗證后，就得到了全面的驗證。完成功能和結構驗證后，就可隨機地一次變化一行來驗證軟件測試用例在軟件遇到違背原先驗證的不利變化時軟件的可靠性。灰盒測試法是在功能上驗證嵌入式系統(tǒng)軟件的一種10步驟法。程序功能正確系指在希望執(zhí)行程序時，程序能夠執(zhí)行。子功能是指從進入到退出經過程序的一個路徑。測試用例是由一組測試輸入和相應的測試輸出構成的測試矢量?；液袦y試法的步驟如表1所示。在目前有許多軟件測試工具可利用的條件下，灰盒測試法的自動化程度可達70,,90,。利用軟件工具可從要求模型或軟件模型中提取所有輸入和輸出變量，產生測試用例輸入文件。利用現行靜態(tài)測試工具可確定入口和出口測試路徑。利用靜態(tài)測試工具可確定所有進出路徑。利用仿真得到的要求，可產生測試軟件需要的實際測試用例部分數據值。表110步灰盒法步驟說明1確定程序的所有輸入和輸出2確定程序所有狀態(tài)3確定程序主路徑4確定程序的功能5產生試驗子功能X的輸入。這里X為許多子功能之一6制定驗證子功能的X的輸出7執(zhí)行測試用例X的軟件8檢驗測試用例X結果的正確性9對其余子功能。重復7和8步10重復4-8步，然后再進行第9步。進行回歸測試.測試用例測試用例可根據系統(tǒng)工程算法、詳細設計、軟件要求或實際代碼生成。這些資源的任何結合都可生成功能上或結構上的測試用例。.產生基于測試用例的要求灰盒測試法利用判定測試法來預置程序測試之前所有要求的條件。保證核心程序正確的一種方法是利用形式證明(formalverification)。當用形式語言說明軟件要求時，就能執(zhí)行該軟件要求，驗證要求的說明的正確性。然后。利用先決條件預測。并執(zhí)行軟件要求，就能產生期望的結果即后續(xù)條件(post-conditiona1)驗證。灰盒測試法就是利用需求規(guī)范說明語言確定的預測和驗證，產生基于測試用例要求的輸入。如果對于每個輸入，程序都能執(zhí)行到頭，并且輸出的判定是正確時，就稱該程序對于該輸入是正確的。如果該要求不是可執(zhí)行的形式，則要求編寫程序可用下述簡單的方法產生預測和驗證。如果輸入沒有唯一有效值，每一個輸入指定一個不為0或l的值。根據要求將輸入轉換成輸出。在完成要求轉換時，輸入就是預測，輸出就是驗證。這一組預測和驗證就成為基于測試用例的要求。在鑒定要求過程中。如果遇到條件語句，就要再執(zhí)行一遍要求，直到所有條件都滿足為止。簡單地說，如果要求不包括條件語句，驗證該要求只需一個測試用力用例就夠了?；液袦y試法是專門為嵌入式軟件研制的。嵌入式軟件的關鍵算法通常是系統(tǒng)工程組制定的。在需求分析階段，分配給軟件的要求和算法，通常作為輸入提供給軟件工程組。系統(tǒng)要求、算法常常是用FORTRAN、C語言作為編碼語言在系統(tǒng)的軟件模擬中制定和檢驗的。得到的軟件要求在多數情況下是算法語句。即fortran、c語言的系統(tǒng)的軟件模擬中制定和檢驗的。總之。不管要求是用可執(zhí)行的需求規(guī)范語言說明還是嵌入在現行系統(tǒng)模擬中，這些需求信息總是可用來產生基于測試用例的要求。.測試執(zhí)行環(huán)境產生基于測試用例的要求后，必須將受測軟件放在模擬受測軟件的環(huán)境中，提取實際的結果?；液袦y試工具具有足夠的智能，生成要求的驅動器和插頭。最后，得到的實際結果要根據基于測試用例產生的要求得到的期望結果進行檢驗。受試軟件必須在不同層次上進行檢驗。第一層是單元級。將受試軟件放在能夠提取模塊規(guī)范并能產生調用受試單元的驅動器的環(huán)境中。被受試模塊(MUT)調用的所有模塊，如果不存在，就會自動地被打樁(stubbed)?；液袦y試法支持樁數據通過MTIF文件返回。灰盒測試法支持所有測試軟件的自動代碼生成(驅動器、樁模塊、結果檢驗)。在軟件集成測試中，再次用灰盒測試工具產生驅動器，測試該模塊與下級模塊的關系。當受試模塊完成一次調用返回時，就根據基于測試用例要求的檢驗數據，對模塊接口上的數據值進行檢驗。對測試用例輸入文件中的每個測試用例都要重復這一檢驗過程?；液袦y試法永遠不進入受試模塊的內部，所有數據都在受試模塊外部檢查。模塊被放進測試環(huán)境中時就受到了探測。這樣就使測試環(huán)境獲得對通道覆蓋信息能見能力。當一個模塊通過了基于測試用例的要求并走遍了所有路徑后，就認為該模塊通過了測試。當測試檢驗得到1分時，模塊從上到下每個路徑就得到1分。一旦分數達?I]i00，就認為該模塊在功能上和結構上通過了測試?；液袦y試法可從上到下進行測試，也可從下到上進行測試?；液袦y試法可用于軟件測試的各個階段。單元級測試與模塊或集成級的測試一樣。不管用戶進行嚴格的單元級測試還是集成測試，灰盒工具都能提供一致的結果。實時灰盒測試法2001年，洛克希德公司在原來的基礎上，提出了實時灰盒測試法。最初的灰盒測試法并不是要解決實時或系統(tǒng)級測試問題，其主要目的是提供一套能夠徹底測試軟件產品的軟件。當計算機處于實時環(huán)境下，新的問題就來了。計算機系統(tǒng)不僅要產生正確的答案，而且還要滿足嚴格的定時限制。實時處理意味著專用計算機常常并行運行多個處理程序。實時灰盒測試法是在灰盒測試法的基礎上，解決了軟件的實時性能測試。實時地使用灰盒法，只需要將時間分量加到期望的輸出數據上。對于在角位移時產生正弦的系統(tǒng)，正常的灰盒測試包括輸入角度和期望的輸出正弦值?！皩τ赬=.30"，Y=sin(X)，試驗結果將為0(5。該試驗的結果中沒有時間分量。因此，每當出現這種響應時，就會與期望的結果0(5比較。這可能是測試開始后的1毫秒，也可能是測試開始后的10秒。在實時系統(tǒng)中，這種試驗是不可接受的。實時試驗將規(guī)定為“y(t)=sin(x，t)”，增加的時間分量“t”就能保證期望值將在對象級時間范疇里進行比較。使用圖1的sinX，主要對象是X。對象X的分量是X.sine。X.sine的對象級時間值是從圖中曲線讀出的。X一軸為對象級時間軸。因此，在X對象產生時，X.sine應該在1(X.olt)處為0。在lOX.olt處，X.sine的值應該是-O(5。在仿真中，一個步驟是檢驗原始數據是否具有確定的趨勢;檢查原始數據的另一步驟是用標圖包來顯示原始數據。這兩個步驟有助于工程師在搜集數據時對數據進行目視查看，以減少實時應用時數據的剔除量。在實時測試期間，要檢查系統(tǒng)的x(olt、x(sine和x(olt的值。記錄時間標記,值，時間標記組，在測試后立即進行處理，以證實在曲線上時標值在開始和結束時標之間。記錄、記數、計時和取樣可通過插入代碼由軟件來做。.黑盒測試黑盒測試也稱功能測試或數據驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內部結構和內部特性的情況下，測試者在程序接口進行測試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當地接收輸入數鋸而產生正確的輸出信息，并且保持外部信息(如數據庫或文件)的完整性。黑盒測試方法主要有等價類劃分、邊值分析、因一果圖、錯誤推測等，主要用于軟件確認測試。“黑盒”法著眼于程序外部結構、不考慮內部邏輯結構、針對軟件界面和軟件功能進行測試。“黑盒”法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。.白盒測試白盒測試也稱結構測試或邏輯驅動測試，它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規(guī)格說明書的規(guī)定正常進行，按照程序內部的結構測試程序，檢驗程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用于軟件驗證。“白盒”法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試?！鞍缀小狈ㄊ歉F舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯著手，得出測試數據。貫穿程序的獨立路徑數是天文數字。但即使每條路徑都測試了仍然可能有錯誤。第一，窮舉路徑測試決不能查出程序違反了設計規(guī)范，即程序本身是個錯誤的程序。第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發(fā)現不了一些與數據相關的錯誤。.灰盒測試灰盒測試，確實是介于二者之間的，可以這樣理解，灰盒測試關注輸出對于輸入的正確性，同時也關注內部表現，但這種關注不象白盒那樣詳細、完整，只是通過一些表征性的現象、事件、標志來判斷內部的運行狀態(tài)，有時候輸出是正確的，但內部其實已經錯誤了，這種情況非常多，如果每次都通過白盒測試來操作，效率會很低，因此需要采取這樣的一種灰盒的方法。灰盒測試結合了白盒測試盒黑盒測試的要素。它考慮了用戶端、特定的系統(tǒng)知識和操作環(huán)境。它在系統(tǒng)組件的協同性環(huán)境中評價應用軟件的設計?；液袦y試由方法和工具組成，這些方法和工具取材于應用程序的內部知識盒與之交互的環(huán)境，能夠用于黑盒測試以增強測試效率、錯誤發(fā)現和錯誤分析的效率。灰盒測試涉及輸入和輸出，但使用關于代碼和程序操作等通常在測試人員視野之外的信息設計測試。.2白盒測試（結構測試）白盒測試（又叫作結構測試）是指測試情境主要是針對邏輯路徑來設計的。測試人員檢查程序或系統(tǒng)的內部結構。測試數據根據對程序或系統(tǒng)的邏輯檢查來確定，而不關心程序或系統(tǒng)的需求。測試人員知道內部的程序結構和處理邏輯，就像汽車維修工知道汽車的內部構造一樣。這一類別中的測試包括基本路徑分析、語句覆蓋、分支覆蓋、條件覆蓋、分支/條件覆蓋。白盒測試的一個優(yōu)點是測試比較徹底，并且側重于已經開發(fā)出來的代碼。因為測試人員知道內部的結構或邏輯，一些致命的錯誤或程序員故意放置一段代碼而搞的惡作劇就會更容易地被檢查出來。白盒測試的一個缺點是不能驗證規(guī)約的正確性，也就是說，白盒測試僅僅側重于測試內部的處理邏輯，而不去驗證邏輯是否滿足需求規(guī)約。白盒測試的另一個缺點是無法檢驗代碼中遺漏的路徑和數據敏感性錯誤。例如，如果程序中的代碼語句應該寫成“if|a-b|<10"，但是結果卻寫成了“if(a-b)<10"，如果沒有詳細的規(guī)約的話，這種錯誤將無法被檢測出來。白盒測試最后的一個缺點是無法窮舉程序中所有可能的邏輯路徑，因為窮舉導致的測試數量將會是一個天文數字。2.1黑盒測試(功能測試)黑盒測試(又叫作功能測試)是指測試條件主要根據程序或系統(tǒng)的功能實現來制定。也就是說，測試人員所要求的信息是輸入的數據和觀察到的輸出結果，但他們不知道程序或系統(tǒng)是怎樣工作的。正如一個人不必知道汽車的內部是如何工作的而只管去開它，同樣也不必知道程序的內部結構而只管去執(zhí)行它。測試人員側重于根據規(guī)約去測試程序的功能。在黑盒測試中，測試人員把程序看作一個黑匣子，對程序或系統(tǒng)的內部結構并不關心。這一類的測試包括決策表、等價類劃分、范圍測試、邊界值測試、數據庫集成測試、因果圖、正交陣列測試、陣列和表測試、異常測試、極限測試、隨機測試。黑盒測試的一個主要的優(yōu)點就是測試活動本身的行為要與程序或系統(tǒng)的設計行為相吻合，是正常的一些操作，并且容易被大家所理解。一些測試技術如結構化走查、審查和聯合應用設計(JAD)可以證實這一點。黑盒測試的一個限制就是測試全部的、無遺漏的輸入流是不太可能的，因為這要求每一個可能的輸入條件或其組合都要被測試到。另外，因為測試人員不知道內部的結構或處理邏輯，在黑盒測試中沒有被測到的部分很可能會有致命的錯誤或程序員故意放置一段代碼而搞的惡作劇。例如，假設一個為公司開發(fā)工資管理程序的程序員在自己開發(fā)的代碼中嵌入一段“保護”自己工作的代碼，他在程序中嵌入如下代碼，如果這位員工被辭退后，他的員工代碼在系統(tǒng)中不再存在，則他預置在程序里的判斷遲早會發(fā)揮作用。ifmy