實(shí)際開發(fā)過程中尖淘，軟件工程師有責(zé)任去編寫一些測試用例颈将，保證我們程序的健壯性驹针。這里殖告，探討一下在ios和安卓不同的測試用例的區(qū)別和用法阿蝶。

iOS篇

• 以下是幾種比較靠譜的測試框架

• 1.NSAssert (斷言，和普通代碼在一起書寫)
• 2.WIKI,是從行為的角度思考問題黄绩。測試用例都遵循三段式Given-When-Then的描述羡洁，清晰地表達(dá)測試用例是測試什么樣的對象或數(shù)據(jù)結(jié)構(gòu)，在基于什么上下文或情景爽丹，然后做出什么響應(yīng)筑煮。
• 3.XCTest（Unit Test）（又稱為模塊測試, Unit Testing）單元測試非常適合用來做 app 的邏輯以及網(wǎng)絡(luò)接口方面的測試,Xcode提供單元測試的是從測試的角度思考問題
• 4.比如專注于提供 Mock 和 Stub 的 OCMock(建議使用GHUnit + OCMock組合進(jìn)行單元測試)
• 5.UITest

具體的使用方法和介紹

1.NSAssert（斷言）

什么是斷言？
程序運(yùn)行時防止某些數(shù)據(jù)不符合預(yù)期粤蝎，直接在使用數(shù)據(jù)的時候咆瘟，對他用斷言判斷一下，保證數(shù)據(jù)的正確性

使用場景
在程序的任何位置诽里，只要是對任何數(shù)據(jù)或者對象的懷疑袒餐，就可以對他們進(jìn)行斷言判斷（只在debug模式開啟，release默認(rèn)關(guān)閉）

優(yōu)點(diǎn)
和程序同步，當(dāng)開發(fā)和測試人員使用app的時候灸眼，走到程序的任何位置卧檐，都時刻有斷言給你保證你所使用的數(shù)據(jù)是符合你預(yù)期的，如有違背焰宣，直接就崩潰提醒霉囚，簡單粗暴

當(dāng)你要去使用一個變量的時候，你害怕他不對或者為空匕积，通常你會判斷一下

    GEUser * user =[GEUserTool userInfo];
    if (user.Token.length) {
        NSLog(@"用戶的token不為空");
    }

這是我們正常的使用過程盈罐，沒問題。如果測試測完了闪唆，說對盅粪，這很好，當(dāng)下一個版本的時候悄蕾，我們突然改動了些東西票顾，這個位置的token為空了，測試又走到這里帆调，沒注意到無打印奠骄，那么這個隱藏的bug就這樣放著，一直不會發(fā)現(xiàn)番刊。我舉得例子是比較小的含鳞，如果是個大的bug珍策，測試忘了回歸測試姑隅，責(zé)任是很大的圆裕，所以胳蛮，為了保險起見烫堤，我們可以使用斷言躯砰，哪怕測試沒有發(fā)現(xiàn)活箕，我們可以自定義的對錯誤做一個處理（自定義直接崩潰或者打印輸出）魂仍！

    GEUser * user =[GEUserTool userInfo];
    NSAssert(user.Token.length != 0, @"用戶的token不能是空的");
    if (user.Token.length) {
        NSLog(@"用戶的token不為空");
    }

如果是這個樣子沃但，及時測試人員沒有測試出來磁滚，系統(tǒng)會自動奔潰，打印出出錯的斷言的位置宵晚，方便我們調(diào)試垂攘，給開發(fā)人員和測試人員提供了諸多便利，具體內(nèi)容請到我的另一篇文章看看詳情.

2.UintTest（單元測試淤刃，屬于TDD）

什么是單元測試晒他？

蘋果親兒子，直接在app的UITestCase類中測試業(yè)務(wù)邏輯逸贾，集中化管理測試用例陨仅，將測試的對象設(shè)置成最小的單元津滞，方便開發(fā)人員測試

使用場景
測試一些純業(yè)務(wù)邏輯的東西，還有就是網(wǎng)絡(luò)接口返回的數(shù)據(jù)是否符合預(yù)期的判斷

優(yōu)點(diǎn)

統(tǒng)一化管理灼伤，書寫代碼触徐，可以多次的進(jìn)行回歸測試，方便修改狐赡，節(jié)約成本和時間撞鹉，一勞永逸

缺點(diǎn)
缺點(diǎn)是不能和UI交互，屬于TDD類型颖侄，報錯的描述在后面鸟雏，不是特別容易理解，如果是項(xiàng)目轉(zhuǎn)交給新的工程師览祖，可能會費(fèi)比較長的時間去理解測試用例

在TestCase中我們可以寫很多的測試用例孝鹊，可以一次性跑所有的，也可以一個一個來穴墅，可以試想一下惶室，如果有50個網(wǎng)絡(luò)接口温自，或者一些測試的判斷玄货，那么一口氣跑下來，卻都是對的悼泌，那多么的爽歪歪松捉。
具體的內(nèi)容可以參考我的另一篇文章 UITestCase 測試單元的使用

PS:感覺** NSAssert和XCTAssert好像啊，語法基本一致馆里，確實(shí)如此隘世，只是他們的使用場景不同，一個是和普通代碼在一起雜糅的寫鸠踪，時時刻刻判斷數(shù)據(jù)丙者，另一個是專門在TestCase類**中去判斷數(shù)據(jù)或者對象是否符合自己的預(yù)期。

3.WIKI（屬于BDD）

什么是WIKI营密？
WIKI是ios測試的開源庫械媒，測試用例都遵循三段式Given-When-Then的描述，清晰地表達(dá)測試用例是測試什么樣的對象或數(shù)據(jù)結(jié)構(gòu)评汰，在基于什么上下文或情景纷捞，然后做出什么響應(yīng)，報錯的描述在前邊被去，然后才是具體的邏輯判斷主儡，寫完之后，就像是讀一個句子一樣惨缆，非常的方便糜值，即使項(xiàng)目交給新的工程師丰捷，他們也會非常快速的接手測試

使用場景
應(yīng)該是測試Case中

優(yōu)點(diǎn)
統(tǒng)一化管理臀玄，書寫代碼瓢阴，可以多次的進(jìn)行回歸測試，方便修改健无，節(jié)約成本和時間荣恐，而且寫完之后，堆起來行云流水累贤，轉(zhuǎn)交給新的測試人員叠穆，也可以很快的入手，方便后期的維護(hù)測試臼膏。2.語法簡單硼被，功能強(qiáng)大，

缺點(diǎn)
語法全面渗磅，但是問題是語句太多了嚷硫，造成寫的東西比較多

describe(@"Team", ^{
    context(@"when newly created", ^{
        it(@"should have a name", ^{
            id team = [Team team];
            [[team.name should] equal:@"Black Hawks"];
        });

        it(@"should have 11 players", ^{
            id team = [Team team];
            [[[team should] have:11] players];
        });
    });
});

3.WIKI（屬于BDD）

什么是WIKI？
WIKI是ios測試的開源庫始鱼，測試用例都遵循三段式Given-When-Then的描述仔掸，清晰地表達(dá)測試用例是測試什么樣的對象或數(shù)據(jù)結(jié)構(gòu)，在基于什么上下文或情景医清，然后做出什么響應(yīng)起暮，報錯的描述在前邊，然后才是具體的邏輯判斷会烙，寫完之后负懦，就像是讀一個句子一樣，非常的方便柏腻，即使項(xiàng)目交給新的工程師纸厉，他們也會非常快速的接手測試

使用場景
應(yīng)該是測試Case中

優(yōu)點(diǎn)
統(tǒng)一化管理五嫂，書寫代碼颗品，可以多次的進(jìn)行回歸測試，方便修改贫导，節(jié)約成本和時間抛猫，而且寫完之后，堆起來行云流水孩灯，轉(zhuǎn)交給新的測試人員闺金，也可以很快的入手，方便后期的維護(hù)測試峰档。2.語法簡單败匹，功能強(qiáng)大寨昙，

缺點(diǎn)
語法全面，但是問題是語句太多了掀亩，造成寫的東西比較多

4.GH+Unit

GH+Unit
一套可視化測試框架舔哪，可以在手機(jī)，或者電腦的控制臺看到打印槽棍，更加人性化的服務(wù)

使用場景
應(yīng)該是測試Case中

優(yōu)點(diǎn)
GUI開發(fā)捉蚤，可以一目了然看到項(xiàng)目中測試了什么項(xiàng)目，那些項(xiàng)目測試了炼七，那些項(xiàng)目還沒有測試缆巧！

缺點(diǎn)
沒有過，我哪知道

Android篇*

以下是幾種比較靠譜的測試框架

• 1.NSAssert (斷言豌拙，和普通代碼在一起書寫)
• 2.WIKI,是從行為的角度思考問題陕悬。測試用例都遵循三段式Given-When-Then的描述，清晰地表達(dá)測試用例是測試什么樣的對象或數(shù)據(jù)結(jié)構(gòu)按傅，在基于什么上下文或情景捉超，然后做出什么響應(yīng)。
• 3.XCTest（Unit Test）（又稱為模塊測試, Unit Testing）單元測試非常適合用來做 app 的邏輯以及網(wǎng)絡(luò)接口方面的測試,Xcode提供單元測試的是從測試的角度思考問題
• 4.比如專注于提供 Mock 和 Stub 的 OCMock(建議使用GHUnit + OCMock組合進(jìn)行單元測試)
• 5.UITest

具體的使用方法和介紹

1.NSAssert（斷言）

什么是斷言唯绍？
程序運(yùn)行時防止某些數(shù)據(jù)不符合預(yù)期拼岳，直接在使用數(shù)據(jù)的時候，對他用斷言判斷一下推捐，保證數(shù)據(jù)的正確性

使用場景
在程序的任何位置裂问，只要是對任何數(shù)據(jù)或者對象的懷疑侧啼，就可以對他們進(jìn)行斷言判斷（只在debug模式開啟牛柒，release默認(rèn)關(guān)閉）

優(yōu)點(diǎn)
和程序同步，當(dāng)開發(fā)和測試人員使用app的時候痊乾，走到程序的任何位置皮壁，都時刻有斷言給你保證你所使用的數(shù)據(jù)是符合你預(yù)期的，如有違背哪审，直接就崩潰提醒蛾魄，簡單粗暴

當(dāng)你要去使用一個變量的時候，你害怕他不對或者為空湿滓，通常你會判斷一下

    GEUser * user =[GEUserTool userInfo];
    if (user.Token.length) {
        NSLog(@"用戶的token不為空");
    }

這是我們正常的使用過程滴须，沒問題。如果測試測完了叽奥，說對扔水，這很好，當(dāng)下一個版本的時候朝氓，我們突然改動了些東西魔市，這個位置的token為空了主届，測試又走到這里，沒注意到無打印待德，那么這個隱藏的bug就這樣放著君丁，一直不會發(fā)現(xiàn)。我舉得例子是比較小的将宪，如果是個大的bug绘闷，測試忘了回歸測試，責(zé)任是很大的较坛，所以簸喂，為了保險起見，我們可以使用斷言燎潮，哪怕測試沒有發(fā)現(xiàn)喻鳄，我們可以自定義的對錯誤做一個處理（自定義直接崩潰或者打印輸出）！

    GEUser * user =[GEUserTool userInfo];
    NSAssert(user.Token.length != 0, @"用戶的token不能是空的");
    if (user.Token.length) {
        NSLog(@"用戶的token不為空");
    }

如果是這個樣子确封，及時測試人員沒有測試出來除呵，系統(tǒng)會自動奔潰，打印出出錯的斷言的位置爪喘，方便我們調(diào)試颜曾，給開發(fā)人員和測試人員提供了諸多便利，具體內(nèi)容請到我的另一篇文章看看詳情.

2.UintTest（單元測試秉剑，屬于TDD）

什么是單元測試泛豪？
蘋果親兒子，直接在app的UITestCase類中測試業(yè)務(wù)邏輯侦鹏，集中化管理測試用例诡曙，將測試的對象設(shè)置成最小的單元，方便開發(fā)人員測試

使用場景
測試一些純業(yè)務(wù)邏輯的東西略水，還有就是網(wǎng)絡(luò)接口返回的數(shù)據(jù)是否符合預(yù)期的判斷

優(yōu)點(diǎn)

統(tǒng)一化管理价卤，書寫代碼，可以多次的進(jìn)行回歸測試渊涝，方便修改慎璧，節(jié)約成本和時間，一勞永逸

缺點(diǎn)
缺點(diǎn)是不能和UI交互跨释，屬于TDD類型胸私，報錯的描述在后面，不是特別容易理解鳖谈，如果是項(xiàng)目轉(zhuǎn)交給新的工程師岁疼，可能會費(fèi)比較長的時間去理解測試用例

在TestCase中我們可以寫很多的測試用例，可以一次性跑所有的蚯姆，也可以一個一個來五续，可以試想一下洒敏，如果有50個網(wǎng)絡(luò)接口，或者一些測試的判斷疙驾，那么一口氣跑下來凶伙，卻都是對的，那多么的爽歪歪它碎。
具體的內(nèi)容可以參考我的另一篇文章 UITestCase 測試單元的使用

PS:感覺** NSAssert和XCTAssert好像啊函荣，語法基本一致，確實(shí)如此扳肛，只是他們的使用場景不同傻挂，一個是和普通代碼在一起雜糅的寫，時時刻刻判斷數(shù)據(jù)挖息，另一個是專門在TestCase類**中去判斷數(shù)據(jù)或者對象是否符合自己的預(yù)期金拒。

3.WIKI（屬于BDD）

什么是WIKI？
WIKI是ios測試的開源庫套腹，測試用例都遵循三段式Given-When-Then的描述绪抛，清晰地表達(dá)測試用例是測試什么樣的對象或數(shù)據(jù)結(jié)構(gòu)，在基于什么上下文或情景电禀，然后做出什么響應(yīng)幢码，報錯的描述在前邊，然后才是具體的邏輯判斷尖飞，寫完之后症副，就像是讀一個句子一樣，非常的方便政基，即使項(xiàng)目交給新的工程師贞铣，他們也會非常快速的接手測試

使用場景
應(yīng)該是測試Case中

優(yōu)點(diǎn)
統(tǒng)一化管理腋么，書寫代碼咕娄，可以多次的進(jìn)行回歸測試亥揖，方便修改珊擂，節(jié)約成本和時間，而且寫完之后费变，堆起來行云流水摧扇，轉(zhuǎn)交給新的測試人員，也可以很快的入手挚歧，方便后期的維護(hù)測試扛稽。2.語法簡單，功能強(qiáng)大滑负，

缺點(diǎn)
語法全面在张，但是問題是語句太多了用含，造成寫的東西比較多

describe(@"Team", ^{
    context(@"when newly created", ^{
        it(@"should have a name", ^{
            id team = [Team team];
            [[team.name should] equal:@"Black Hawks"];
        });

        it(@"should have 11 players", ^{
            id team = [Team team];
            [[[team should] have:11] players];
        });
    });
});

3.WIKI（屬于BDD）

什么是WIKI？
WIKI是ios測試的開源庫帮匾，測試用例都遵循三段式Given-When-Then的描述啄骇，清晰地表達(dá)測試用例是測試什么樣的對象或數(shù)據(jù)結(jié)構(gòu)，在基于什么上下文或情景瘟斜，然后做出什么響應(yīng)缸夹，報錯的描述在前邊，然后才是具體的邏輯判斷螺句，寫完之后虽惭，就像是讀一個句子一樣，非常的方便蛇尚，即使項(xiàng)目交給新的工程師芽唇，他們也會非常快速的接手測試

使用場景
應(yīng)該是測試Case中

優(yōu)點(diǎn)
統(tǒng)一化管理取劫，書寫代碼披摄，可以多次的進(jìn)行回歸測試，方便修改勇凭，節(jié)約成本和時間疚膊，而且寫完之后，堆起來行云流水虾标，轉(zhuǎn)交給新的測試人員寓盗，也可以很快的入手，方便后期的維護(hù)測試璧函。2.語法簡單傀蚌，功能強(qiáng)大，

缺點(diǎn)
語法全面蘸吓，但是問題是語句太多了善炫，造成寫的東西比較多

4.GH+Unit

GH+Unit
一套可視化測試框架，可以在手機(jī)库继，或者電腦的控制臺看到打印箩艺，更加人性化的服務(wù)

使用場景
應(yīng)該是測試Case中

優(yōu)點(diǎn)
GUI開發(fā)，可以一目了然看到項(xiàng)目中測試了什么項(xiàng)目宪萄，那些項(xiàng)目測試了艺谆，那些項(xiàng)目還沒有測試！

缺點(diǎn)
沒有過拜英，我哪知道

網(wǎng)球家客戶端要解決的問題

1.如何確定后臺幾十個接口返回數(shù)據(jù)是否符合我們的預(yù)期?
推薦使用 XCTest,(有異步處理的方法)静汤，或者使用WIKI

2.如何在項(xiàng)目中可以一直監(jiān)視著系統(tǒng)的各種數(shù)據(jù)的正確性？
推薦使用NSAssert，在項(xiàng)目中的任何位置都可以隨時監(jiān)聽數(shù)據(jù)的正確性虫给，一旦和預(yù)期數(shù)據(jù)不同藤抡，我們可以打印，或者直接使項(xiàng)目崩潰

3.如何對UI界面用戶操作做回歸測試抹估？
在iOS的框架中杰捂，UITest專門做UI層面的測試，可以多次回歸棋蚌，但是目前這種技術(shù)并不是特別的靠譜

寫在最后
最后那嫁佳，推薦一下onevcat(VVDocument的作者)關(guān)于測試的兩篇文章，寫的非常棒谷暮！
1.TDD的iOS開發(fā)初步以及Kiwi使用入門
2.Kiwi 使用進(jìn)階 Mock, Stub, 參數(shù)捕獲和異步測試