java測試的類型？
創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于網(wǎng)站制作、成都網(wǎng)站設(shè)計、巧家網(wǎng)絡(luò)推廣、小程序制作、巧家網(wǎng)絡(luò)營銷、巧家企業(yè)策劃、巧家品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)為所有大學(xué)生創(chuàng)業(yè)者提供巧家建站搭建服務(wù)，24小時服務(wù)熱線：18980820575，官方網(wǎng)址：www.cdcxhl.com
黑盒測試？白盒測試？灰盒測試？
白盒測試(White-box Testing，又稱邏輯驅(qū)動測試,結(jié)構(gòu)測試)是把測試對象看作一個打開的盒子。利用白盒測試法進行動態(tài)測試時，需要測試軟件產(chǎn)品的內(nèi)部結(jié)構(gòu)和處理過程，不需測試軟件產(chǎn)品的功能。白盒測試又稱為結(jié)構(gòu)測試和邏輯驅(qū)動測試。
白盒測試法的覆蓋標準有邏輯覆蓋、循環(huán)覆蓋和基本路徑測試。其中邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。
六種覆蓋標準：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋發(fā)現(xiàn)錯誤的能力呈由弱至強的變化。語句覆蓋每條語句至少執(zhí)行一次。判定覆蓋每個判定的每個分支至少執(zhí)行一次。條件覆蓋每個判定的每個條件應(yīng)取到各種可能的值。判定/條件覆蓋同時滿足判定覆蓋條件覆蓋。條件組合覆蓋每個判定中各條件的每一種組合至少出現(xiàn)一次。路徑覆蓋使程序中每一條可能的路徑至少執(zhí)行一次。
白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試，它是知道產(chǎn)品內(nèi)部工作過程，可通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進行，按照程序內(nèi)部的結(jié)構(gòu)測試程序，檢驗程序中的每條通路是否都有能按預(yù)定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅(qū)動、基路測試等，主要用于軟件驗證。
"白盒"法全面了解程序內(nèi)部邏輯結(jié)構(gòu)、對所有邏輯路徑進行測試。"白盒"法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內(nèi)部結(jié)構(gòu)，從檢查程序的邏輯著手，得出測試數(shù)據(jù)。貫穿程序的獨立路徑數(shù)是天文數(shù)字。但即使每條路徑都測試了仍然可能有錯誤。第一，窮舉路徑測試決不能查出程序違反了設(shè)計規(guī)范，即程序本身是個錯誤的程序。第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發(fā)現(xiàn)不了一些與數(shù)據(jù)相關(guān)的錯誤。
白盒測試目前主要用在具有高可靠性要求的軟件領(lǐng)域，例如：軍工軟件、航天航空軟件、工業(yè)控制軟件等等。白盒測試工具在選購時應(yīng)當(dāng)主要是對開發(fā)語言的支持、代碼覆蓋的深度、嵌入式軟件的測試、測試的可視化等。
對開發(fā)語言的支持：白盒測試工具是對源代碼進行的測試，測試的主要內(nèi)容包括詞法分析與語法分析、靜態(tài)錯誤分析、動態(tài)檢測等。但是對于不同的開發(fā)語言，測試工具實現(xiàn)的方式和內(nèi)容差別是較大的。目前測試工具主要支持的開發(fā)語言包括：標準C、C＋＋、Visual C＋＋、Java、Visual J＋+等。
代碼的覆蓋深度：從覆蓋源程序語句的詳盡程度分析，邏輯覆蓋標準包括以下不同的覆蓋標準：語句覆蓋、判定覆蓋、條件覆蓋、條件判定組合覆蓋、多條件覆蓋和修正判定條件覆蓋。
·語句覆蓋 為了暴露程序中的錯誤，程序中的每條語句至少應(yīng)該執(zhí)行一次。因此語句覆蓋（STatement Coverage）的含義是：選擇足夠多的測試數(shù)據(jù)，使被測程序中每條語句至少執(zhí)行一次。語句覆蓋是很弱的邏輯覆蓋。
·判定覆蓋 比語句覆蓋稍強的覆蓋標準是判定覆蓋（DECision Coverage）。判定覆蓋的含義是：設(shè)計足夠的測試用例，使得程序中的每個判定至少都獲得一次“真值”或“假值”，或者說使得程序中的每一個取“真”分支和取“假”分支至少經(jīng)歷一次，因此判定覆蓋又稱為分支覆蓋。
·條件覆蓋 在設(shè)計程序中，一個判定語句是由多個條件組合而成的復(fù)合判定。為了更徹底地實現(xiàn)邏輯覆蓋，可以采用條件覆蓋（ConDItion Coverage）的標準。條件覆蓋的含義是：構(gòu)造一組測試用例，使得每一判定語句中每個邏輯條件的可能值至少滿足一次。
·多條件覆蓋 多條件覆蓋也稱條件組合覆蓋，它的含義是：設(shè)計足夠的測試用例，使得每個判定中條件的各種可能組合都至少出現(xiàn)一次。顯然滿足多條件覆蓋的測試用例是一定滿足判定覆蓋、條件覆蓋和條件判定組合覆蓋的。
·修正條件判定覆蓋 修正條件判定覆蓋是由歐美的航空/航天制造廠商和使用單位聯(lián)合制定的“航空運輸和裝備系統(tǒng)軟件認證標準”，目前在國外的國防、航空航天領(lǐng)域應(yīng)用廣泛。這個覆蓋度量需要足夠的測試用例來確定各個條件能夠影響到包含的判定的結(jié)果。它要求滿足兩個條件：首先，每一個程序模塊的入口和出口點都要考慮至少要被調(diào)用一次，每個程序的判定到所有可能的結(jié)果值要至少轉(zhuǎn)換一次；其次，程序的判定被分解為通過邏輯操作符（and、or）連接的布爾條件，每個條件對于判定的結(jié)果值是獨立的。
黑盒測試
也稱功能測試或數(shù)據(jù)驅(qū)動測試，它是在已知產(chǎn)品所應(yīng)具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測試者在程序接口進行測試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)鋸而產(chǎn)生正確的輸出信息，并且保持外部信息（如數(shù)據(jù)庫或文件）的完整性。黑盒測試方法主要有等價類劃分、邊值分析、因—果圖、錯誤推測等，主要用于軟件確認測試。 “黑盒”法著眼于程序外部結(jié)構(gòu)、不考慮內(nèi)部邏輯結(jié)構(gòu)、針對軟件界面和軟件功能進行測試?！昂诤小狈ㄊ歉F舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。
采用黑盒技術(shù)設(shè)計測試用例的方法有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略。
黑盒測試注重于測試軟件的功能性需求，也即黑盒測試使軟件工程師派生出執(zhí)行程序所有功能需求的輸入條件。黑盒測試并不是白盒測試的替代品，而是用于輔助白盒測試發(fā)現(xiàn)其他類型的錯誤。
黑盒測試試圖發(fā)現(xiàn)以下類型的錯誤：
1）功能錯誤或遺漏；
2）界面錯誤；
3）數(shù)據(jù)結(jié)構(gòu)或外部數(shù)據(jù)庫訪問錯誤；
4）性能錯誤；
5）初始化和終止錯誤。
黑盒測試的優(yōu)點
1. 基本上不用人管著，如果程序停止運行了一般就是被測試程序CRASh了
2. 設(shè)計完測試例之后，下來的工作就是爽了，當(dāng)然更苦悶的是確定crash原因
黑盒測試的缺點
1. 結(jié)果取決于測試例的設(shè)計，測試例的設(shè)計部分來勢來源于經(jīng)驗，OUSPG的東西很值得借鑒
2. 沒有狀態(tài)轉(zhuǎn)換的概念，目前一些成功的例子基本上都是針對PDU來做的，還做不到針對被測試程序的狀態(tài)轉(zhuǎn)換來作
3. 就沒有狀態(tài)概念的測試來說，尋找和確定造成程序crash的測試例是個麻煩事情，必須把周圍可能的測試例單獨確認一遍。而就有狀態(tài)的測試來說，就更麻煩了，尤其不是一個單獨的tEStcase造成的問題。這些在堆的問題中表現(xiàn)的更為突出。
灰盒測試介于白盒測試與黑盒測試之間
單元測試關(guān)注代碼覆蓋率
系統(tǒng)測試、集成測試關(guān)注功能覆蓋率，不能統(tǒng)計代碼覆蓋率了
void DoWork (int x,int y,int z){1 int k=0, j=0;2 if ( (x3)(z10) )3 {4 k=x*y-1;5 j=sqrt(k);6 }7 if((x==4)||(y5))8 j=x*y+10;9 j=j%3;10 }說明：程序段中每行開頭的數(shù)字（1~10）是對每條語句的編號。（1）畫出程序的控制流圖（用題中給出的語句編號表示）。（2）分別以語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、組合覆蓋和路徑覆蓋方法設(shè)計測試用例，并寫出每個測試用例的執(zhí)行路徑（用題中給出的語句編號表示）。題目二、折半查找請按要求對下面的java 代碼進行測試。代碼的功能是：用折半查找法在元素呈升序排列的數(shù)組中查找值為key 的元素。public int binSearch ( int array[], int key ) {int mid, low, high;low = 0;high = array.length-1;while ( low = high ) {mid = (low +high)/2;if ( key = = array [mid] )return mid;else if ( key array [mid] )high = mid -1;elselow = mid + 1}return -1;}（1） 試計算此程序段的McCabe 復(fù)雜性；（2） 用基本路徑覆蓋法給出測試路徑；（3） 為各測試路徑設(shè)計測試用例。
一:創(chuàng)建一個測試類,建議將測試類單獨放在一個包中(在 maven 項目里有測試類專門的存放位置),新建一個Junit Test Case類,下一步?
測試類的命名建議是你將要測試的類名+Test,然后點 Browse, 你可以選擇要進行測試的類(一般選擇 Service, 因為 Service 關(guān)心的是業(yè)務(wù)需求),用這種方式創(chuàng)建可以自動生成要測試類的測試類,你只需要進行測試代碼的書寫.
@Test
public void testqueryById(){
} ? ?@Test
public void testQueryAll(){
} ? ?@Test
public void testReduceNumber(){
}123456789101112
如果里面有自動生成的代碼,刪除或注釋即可…
二:配置 spring 和 junit 整合, junit 啟動時加載 springIOC 容器,這里你需要 Spring-test jar包
@RunWith(SpringJUnit4ClassRunner.class) ? ?//告訴junitspring配置文件
@ContextConfiguration(locations = {"classpath:spring/spring-dao.xml"})123
同樣的,在測試類中我們會調(diào)用 Service 的邏輯,由于我們使用的是 Spring+SpringMVC+ 持久化框架,所以要注入一個 IService 接口(這里我直接對 DAO 進行測試了)
@Autowired
private SeckillDao seckillDao;12
接下來是測試邏輯,在編寫測試代碼之前建議覆蓋實體中的 toString 方法,不然打印會很麻煩.
@Test ? ?public void testqueryById(){ ? ? ? ?long id = 1000;
Seckill seckill = seckillDao.queryById(id);
System.out.println(seckill.getSeckillName());
System.out.println(seckill);
} ? ?//JAVA沒有保存形參的記錄,如果你在 dao 中傳了多個參數(shù),那么需要聲明它的形參對應(yīng)的實參,否則 JVM 會顯示找不到參數(shù).聲明方式稍后奉上
@Test ? ?public void testQueryAll(){
ListSeckill seckills = seckillDao.queryAll(0, 100); ? ? ? ?for(Seckill seckill:seckills){
System.out.println(seckill);
}
}
@Test ? ?public void testReduceNumber(){
Date killTime = new Date(); ? ? ? ?//對增加進行測試的時候,只要數(shù)據(jù)庫增加了一條數(shù)據(jù),我們就默認這個方法執(zhí)行成功了
int updateCount = seckillDao.reduceNumber(1000L, killTime);
System.out.println("updateCount = "+updateCount);
}123456789101112131415161718192021222324
解決JAVA不保存形參的記錄
int reduceNumber(@Param("seckillId")long seckillId,@Param("killTime")Date killTime);
Seckill queryById(long seckillId); ? ?/**
* mysql的分頁查詢
* @param offset 告訴它實際的形參
* @param limit
* @return
*/
ListSeckill queryAll(@Param("offset")int offset,@Param("limit")int limit);1234567891011
接下來我們根據(jù)他返回的結(jié)果和我們想要的結(jié)果對應(yīng)就可以了. 測試類不用部署項目, 測試周期非常短, 而且可以進行專項測試. 測試類代碼邏輯十分簡單, 幾乎不會出錯. 如果結(jié)果不是預(yù)期的, 那么根據(jù)你的需求修改!?
當(dāng)然, 它的局限性也很打. 從單元測試不能看出頁面?zhèn)髦档腻e誤, 許多項目在服務(wù)器中的表現(xiàn)也不能模擬.?
那么我們什么時候用junit呢??
當(dāng)你的數(shù)據(jù)庫操作非常復(fù)雜, 你不確定能輸出你想要的值的時候, 相比用 debug 調(diào)試, 使用 Junit 是更方便的手段.或者新手出錯概率非常大, 也不用在服務(wù)器中專門測試項目的表現(xiàn), Junit 是個必備的工具!而且測試類的測試代碼重用性很高.?
如果你的數(shù)據(jù)和預(yù)期相悖, 那么修改業(yè)務(wù)邏輯; 否則, 查看頁面是否有錯! Junit在一定程度上減輕了我們業(yè)務(wù)代碼調(diào)試的壓力, 讓我們關(guān)注于一點解決錯誤.
重慶分公司
重慶分公司
