摘要：在世界級(jí)的安卓測(cè)試開(kāi)發(fā)流第一部分，作者開(kāi)始了安卓測(cè)試開(kāi)發(fā)流的討論。這個(gè)測(cè)試用例的測(cè)試對(duì)象是，部分指令集僅涉及執(zhí)行的指令和。測(cè)試的粒度則應(yīng)當(dāng)和測(cè)試范圍相當(dāng)。一旦我們能夠測(cè)試產(chǎn)品需求是否正確實(shí)現(xiàn)，我們必須繼續(xù)測(cè)試開(kāi)發(fā)流。

在「世界級(jí)的安卓測(cè)試開(kāi)發(fā)流?—?第一部分」，作者開(kāi)始了安卓測(cè)試開(kāi)發(fā)流的討論。我們探討了一個(gè)軟件工程師開(kāi)始編寫(xiě)測(cè)試，到發(fā)現(xiàn)測(cè)試開(kāi)發(fā)中的相關(guān)問(wèn)題的不斷變化。 最后，得到了以下結(jié)論：

測(cè)試自動(dòng)化對(duì)于軟件開(kāi)發(fā)的成功是至關(guān)重要的

可測(cè)試性代碼對(duì)編寫(xiě)某些特定類(lèi)型的測(cè)試是必須的

有些開(kāi)發(fā)者在不確定測(cè)試內(nèi)容和測(cè)試方法的情況下，就開(kāi)始編寫(xiě)測(cè)試

測(cè)試的質(zhì)量和可靠度通常達(dá)不到我們的期望

一個(gè)測(cè)試開(kāi)發(fā)流對(duì)于定義測(cè)試內(nèi)容和方法是必要的

因此，任何應(yīng)用程序中測(cè)試的關(guān)鍵部分是：

業(yè)務(wù)邏輯的測(cè)試要獨(dú)立于框架或庫(kù)

測(cè)試服務(wù)器端的API集成

從用戶的角度，使用黑盒測(cè)試驗(yàn)收標(biāo)準(zhǔn)

在本文中，我們將探討涉及這幾個(gè)部分的幾種測(cè)試方案，以確保一個(gè)穩(wěn)固的測(cè)試開(kāi)發(fā)流。

首先，檢查業(yè)務(wù)邏輯是不是真的實(shí)現(xiàn)預(yù)定的產(chǎn)品需求，是必不可少的。我們需要將想要測(cè)試的代碼隔離出來(lái)，然后模擬出不同的初始場(chǎng)景，以配置某些組件在運(yùn)行時(shí)的行為。然后，我們選擇想要執(zhí)行的代碼部分進(jìn)行測(cè)試。之后，我們需要在執(zhí)行完測(cè)試對(duì)象后檢查軟件的狀態(tài)是否正確。

這個(gè)測(cè)試方案的關(guān)鍵在于依賴(lài)反轉(zhuǎn)原則。通過(guò)編寫(xiě)只依賴(lài)于抽象的代碼，我們就可以把軟件分離成不同的層級(jí)。為了獲得依賴(lài)的實(shí)例，我們只需要向某個(gè)對(duì)象發(fā)出請(qǐng)求。 或者，一旦實(shí)例生成，我們也能獲得之。 我們的軟件有很多部分需要?jiǎng)?chuàng)建代碼來(lái)獲得合作者的實(shí)例。這時(shí)，我們會(huì)使用測(cè)試替身來(lái)模擬初始場(chǎng)景，或編寫(xiě)不同的行為程序來(lái)設(shè)計(jì)我們的測(cè)試。通過(guò)使用測(cè)試替身，我們能同時(shí)模擬產(chǎn)品代碼的行為和狀態(tài)。 同時(shí)，它幫助我們選擇測(cè)試的范圍，也即需要測(cè)試的代碼量。沒(méi)有依賴(lài)反轉(zhuǎn)，所有的類(lèi)需要獨(dú)自獲取自己的依賴(lài)。結(jié)果會(huì)導(dǎo)致類(lèi)實(shí)現(xiàn)和依賴(lài)實(shí)現(xiàn)相耦合，這樣就沒(méi)有辦法借用測(cè)試替身來(lái)切割產(chǎn)品代碼的執(zhí)行流程。

通常，在構(gòu)造時(shí)傳遞類(lèi)依賴(lài)是使用依賴(lài)反轉(zhuǎn)的最有效機(jī)制。這個(gè)機(jī)制對(duì)采用測(cè)試替身已經(jīng)足夠。在構(gòu)造時(shí)傳遞類(lèi)依賴(lài)將幫助我們創(chuàng)建相應(yīng)的測(cè)試替身來(lái)替換依賴(lài)的實(shí)例。要謹(jǐn)記，使用服務(wù)定位器或依賴(lài)反轉(zhuǎn)框架將有助于減少在應(yīng)用依賴(lài)反轉(zhuǎn)時(shí)所需要的樣板， 雖然這并不是強(qiáng)制的。

我們將用一個(gè)具體例子（該測(cè)試和筆者幾個(gè)月前開(kāi)始開(kāi)發(fā)的 Android GameBoy 模擬器有關(guān)）來(lái)演示如何測(cè)試我們的業(yè)務(wù)需求。

以下測(cè)試是關(guān)于 GameBoy 內(nèi)存管理單元（MMU）和 GameBoy BIOS 執(zhí)行單元的。 我們將檢查產(chǎn)品需求（硬件模擬）是否正確實(shí)現(xiàn)。

public class MMUTest {  
  private static final int MMU_SIZE = 65536;
  private static final int ANY_ADDRESS = 11;
  private static final byte ANY_BYTE_VALUE = 0x11;

  @Test public void shouldInitializeMMUFullOfZeros() {
    MMU mmu = givenAMMU();

    assertMMUIsFullOfZeros(mmu);
  }

  @Test public void shouldFillMMUWithZerosOnReset() {
    MMU mmu = givenAMMU();

    mmu.writeByte(ANY_ADDRESS, ANY_BYTE_VALUE);
    mmu.reset();

    assertMMUIsFullOfZeros(mmu);   
  }

  @Test public void shouldWriteBigBytesValuesAndRecoverThemAsOneWord() {
    MMU mmu = givenAMMU();

    mmu.writeByte(ANY_ADDRESS, (byte) 0xFA);
    mmu.writeByte(ANY_ADDRESS +1, (byte) 0xFB);

    assertEquals(0xFBFA, mmu.readWord(ANY_ADDRESS));
  }
}

前三個(gè)測(cè)試是檢查 GameBoy 的 MMU 實(shí)現(xiàn)是否正確。 成功的關(guān)鍵是總在測(cè)試執(zhí)行完成后，檢查 MMU 的狀態(tài)是否正確。 所有測(cè)試都會(huì)檢查 MMU 是否正確初始化。如果重置后MMU 是整潔的，寫(xiě)入2個(gè)字節(jié)后讀出的是一個(gè)字符，那么最終讀取就是正確的。為了測(cè)試模擬器軟件的這個(gè)部分，我們將測(cè)試范圍縮小為一個(gè)類(lèi)。

public class GameBoyBIOSExecutionTest {

  @Test 
  public void shouldIndicateTheBIOSHasBeenLoadedUnlockingTheRomMapping() {
    GameBoy gameBoy = givenAGameBoy();

    tickUntilBIOSLoaded(gameBoy);

    assertEquals(1, mmu.readByte(UNLOCK_ROM_ADDRESS) & 0xFF);
  }

  @Test
  public void shouldPutTheNintendoLogoIntoMemoryDuringTheBIOSThirdStage() {
    GameBoy gameBoy = givenAGameBoy();

    tickUntilThirdStageFinished(gameBoy);

    assertNintendoLogoIsInVRAM();
  }

  private GameBoy givenAGameBoy() {
    z80 = new GBZ80();
    mmu = new MMU();
    gpu = new GPU(mmu);
    GameLoader gameLoader = new GameLoader(new FakeGameReader());
    GameBoy gameBoy = new Gameboy(z80, mmu, gpu, gameLoader);
    return gameboy;
  }
  
}

在這兩個(gè)測(cè)試中，我們檢查 BIOS 是否在不同階段都正確執(zhí)行。BIOS執(zhí)行結(jié)束后，在具體內(nèi)存位置的一個(gè)字節(jié)必須被初始化為一個(gè)具體的值。然后，在第三階段的最后，任天堂的logo必須已經(jīng)加載到 VRAM。由于全套的BIOS執(zhí)行是任何模擬器開(kāi)發(fā)的關(guān)鍵部分，我們決定采用更大的測(cè)試范圍。這個(gè)測(cè)試用例的測(cè)試對(duì)象是 CPU，部分 CPU 指令集(僅涉及 BIOS執(zhí)行的指令)和 MMU。 要檢查執(zhí)行的狀態(tài)是否正確，我們必須對(duì) MMU的狀態(tài)使用斷言（assert）。要想顯著的提升測(cè)試質(zhì)量，一個(gè)關(guān)鍵就是檢查軟件執(zhí)行后的最終狀態(tài)，同時(shí)避免驗(yàn)證和其他組件之間的交互。因?yàn)榧词购推渌M件之間的交互都是正確的，最終狀態(tài)依然可能是錯(cuò)的。還要明確，這些測(cè)試的某些部分同樣可以獨(dú)立進(jìn)行，如 CPU指令。

這些測(cè)試的另一個(gè)主要亮點(diǎn)是使用測(cè)試替身來(lái)模擬和 Android SDK 相關(guān)的部分代碼。在執(zhí)行 BIOS 前，GameBoy 游戲必須加載進(jìn) GameBoy 的 MMU。然而，在測(cè)試期間，沒(méi)有 Android SDK 可用，因而就不得不將其替換，轉(zhuǎn)而從測(cè)試環(huán)境中加載 GameBoy的 rom。我們使用依賴(lài)反轉(zhuǎn)原則不僅用于隱藏實(shí)現(xiàn)細(xì)節(jié)，或者定義邊界，還用測(cè)試替身 FakeGameReader 來(lái)替代 AndroidGameReader 的產(chǎn)品代碼，這意味著完全不依賴(lài)框架和庫(kù)進(jìn)行代碼測(cè)試。通過(guò)這樣做，我們創(chuàng)建了隔離的測(cè)試環(huán)境，同時(shí)調(diào)整了測(cè)試范圍。

調(diào)整測(cè)試的范圍是非常重要的。 開(kāi)始編寫(xiě)測(cè)試前，我們應(yīng)當(dāng)牢記測(cè)試范圍可以幫助識(shí)別代碼錯(cuò)誤(取決于測(cè)試的規(guī)模)。縮小測(cè)試規(guī)模能帶給我們更豐富的錯(cuò)誤反饋，而放大規(guī)模的測(cè)試則不能提供錯(cuò)誤位置的精確信息。測(cè)試的粒度則應(yīng)當(dāng)和測(cè)試范圍相當(dāng)。

編寫(xiě)這些測(cè)試的基礎(chǔ)設(shè)施相當(dāng)明了。 我們必須在依賴(lài)反轉(zhuǎn)原則下編寫(xiě)可測(cè)試代碼，并結(jié)合使用一個(gè)測(cè)試框架和一個(gè)模擬庫(kù)。 模擬庫(kù)用來(lái)生成模擬場(chǎng)景中需要的測(cè)試替身，或者用于替代部分產(chǎn)品代碼的測(cè)試替身。請(qǐng)注意，這些框架和庫(kù)不是強(qiáng)制使用的，但是非常推薦。

這個(gè)方案的結(jié)果很有趣。 當(dāng)遵循依賴(lài)反轉(zhuǎn)原則時(shí)，我們能獨(dú)立于框架和庫(kù)測(cè)試我們產(chǎn)品代碼中的業(yè)務(wù)邏輯。通過(guò)可重復(fù)的，易于編寫(xiě)和設(shè)計(jì)的測(cè)試，我們可以創(chuàng)建隔離的測(cè)試環(huán)境。此外，我們能夠方便選擇要測(cè)試的產(chǎn)品代碼數(shù)量，并使用測(cè)試替身代替這部分代碼，來(lái)模擬行為和不同的場(chǎng)景。

一旦我們能夠測(cè)試產(chǎn)品需求是否正確實(shí)現(xiàn)，我們必須繼續(xù)測(cè)試開(kāi)發(fā)流。接下來(lái)要測(cè)試的，就是在前一階段使用測(cè)試替身替換的外部組件集成后是否執(zhí)行正確。我們將在下一篇博文中討論，敬請(qǐng)期待！

原文地址：http://blog.karumi.com/world-class-testing-development-pipeline-for-android-part-2/

OneAPM Mobile Insight ，監(jiān)控網(wǎng)絡(luò)請(qǐng)求及網(wǎng)絡(luò)錯(cuò)誤，提升用戶留存。訪問(wèn) OneAPM 官方網(wǎng)站感受更多應(yīng)用性能優(yōu)化體驗(yàn)，想閱讀更多技術(shù)文章，請(qǐng)?jiān)L問(wèn) OneAPM 官方技術(shù)博客。
本文轉(zhuǎn)自 OneAPM 官方博客