發行項
12/22/2016

Connect(); 2016

第 31 卷，第 12 期

本文章是由機器翻譯。

Connect(); 行動測試 - 使用 Xamarin Test Cloud 調整您自動化行動裝置 App 測試的規模

由Justin Raczak;2016

近年來，已有大幅的 shift 小組建置和傳遞軟體的方式。一次一般人冗長需求收集處理程序可確保傳遞的完美的第一版產品，它現在是快速學習搭配快速反覆項目是成功的關鍵。如您所考慮的變更，因此，也必須工作流程。開發週期深刻的數個月或年後面冗長瀑布 QA 階段不方便快速學習。必須縮短意見反應迴圈並快速實作的微小變更與發行給使用者。若要立即部署，它必須知道軟體處於良好的狀態在所有的時間。測試自動化做到這一點。

自動化測試，可讓您測試您的應用程式以方式用於需要數天或週數。而不是等到衝刺上百個新的程式碼行的結尾，您可以測試些微變更，加上每個認可。此連續測試介面有缺失，因為它們導入，並減少進行偵錯所需的時間。因為持續地驗證應用程式行為，您有信心，您可以隨時將部署至使用者。自動化測試，您可以在其中發現缺失和出貨的同一天內修正的世界。但行動生態系統的挑戰唯一使用不同的行動裝置和作業系統決策者橫向。

Xamarin 測試定域機組可快速而簡單地調整您自動化測試的最小的變更與現有的工作流程。測試雲端提供超過 400 個唯一的裝置設定，可讓您驗證您的應用程式行為上的裝置型號和對您的使用者不必很重要的作業系統版本或隨附於建置及管理裝置測試環境的管理負擔。在大部分情況下，您便能感受到這個廣大的值，少不變更您的程式碼。

測試定域機組支援撰寫 C# (UITest)、 Ruby (Calabash) 和 Java （Appium 和濃縮咖啡）中的測試。在這篇文章的專案修改部分，我著重於我們最常被要求測試架構。此外，使用 JUnit，Appium，逐步引導您需要在測試定域機組中執行現有的測試對專案進行變更。我也看看 Web 介面，您將檢閱測試結果，疑難排解失敗的測試。所需的特定修改可能會隨著時間變更。您可以找到這些指示的最新版本bit.ly/2dhp2VQ。

在此範例中，我會假設下列先決條件︰

使用中的測試定域機組帳戶 (在註冊bit.ly/2e3YgTy)
已安裝的命令列工具 (的指示，請在bit.ly/2dcrbXS)
原生 Android 應用程式專案
Appium 的現有套件，測試撰寫的 Java 與 JUnit (至少版本 4.9) 符合 Appium 1.5
Maven 建置系統 (至少版本 3.3.9)

建置系統變更

您可以開始使用測試雲端之前，您將需要新增以確保工作準備必要的檔案可用於您的組建相依性。

加入測試定域機組相依性測試定域機組納入您的專案，並確保它的增強型的 Android 和 iOS 驅動程式，可在編譯時期，將下列相依性新增至 pom.xml 檔案︰

<dependency>
  <groupId>com.xamarin.testcloud</groupId>
  <artifactId>appium</artifactId>
  <version>1.0</version>
</dependency>

將上傳設定檔新增新增設定檔從**[圖 1**到您的 pom.xml 內<profiles>標記。</profiles>如果您還沒有<profiles>區段中，建立並新增設定檔。</profiles>此設定檔將組件的測試類別及所有相依性到它們可以測試雲端要上載的目標/上傳資料夾。

[圖 1 測試定域機組上傳設定檔

<profile>
  <id>prepare-for-upload</id>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-dependency-plugin</artifactId>
        <version>2.10</version>
        <executions>
          <execution>
            <id>copy-dependencies</id>
            <phase>package</phase>
            <goals>
              <goal>copy-dependencies</goal>
            </goals>
            <configuration>
              <outputDirectory>${project.build.directory}
                /upload/dependency-jars/</outputDirectory>
              <useRepositoryLayout>true</useRepositoryLayout>
              <copyPom>true</copyPom>
            </configuration>
          </execution>
        </executions>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-resources-plugin</artifactId>
        <executions>
          <execution>
            <id>copy-pom-file</id>
            <phase>package</phase>
            <goals>
              <goal>testResources</goal>
            </goals>
            <configuration>
              <outputDirectory>${project.build.directory}
                /upload/</outputDirectory>
              <resources>
                <resource>
                  <directory>
                    ${project.basedir}
                  </directory>
                  <includes>
                    <include>pom.xml</include>
                  </includes>
                </resource>
              </resources>
            </configuration>
          </execution>
          <execution>
            <id>copy-testclasses</id>
            <phase>package</phase>
            <goals>
              <goal>testResources</goal>
            </goals>
            <configuration>
              <outputDirectory>${project.build.directory}
                /upload/test-classes</outputDirectory>
              <resources>
                <resource>
                  <directory>
                    ${project.build.testOutputDirectory}
                  </directory>
                </resource>
              </resources>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</profile>

變更測試

設定您的組建，您必須修改測試類別，藉此運用測試定域機組 Java 延伸模組。

將匯入加入至測試類別匯入至測試類別的下列封裝︰

import com.xamarin.testcloud.appium.Factory;
import com.xamarin.testcloud.appium.EnhancedAndroidDriver;
import org.junit.rules.TestWatcher;
import org.junit.Rule;

具現化 TestWatcher的其中一個測試類別中插入此具現化︰

@Rule
public TestWatcher watcher = Factory.createWatcher();

更新您的驅動程式宣告取代每個宣告的 AndroidDriver<MobileElement>與 EnhancedAndroidDriver<MobileElement>，就像這樣︰</MobileElement> </MobileElement>

private static EnhancedAndroidDriver<MobileElement> driver;

更新您的驅動程式具現化取代每個執行個體化，驅動程式的這類的程式碼行的形式︰

Driver = new AndroidDriver<MobileElement>(url, capabilities);

變成︰

Driver = new EnhancedAndroidDriver<MobileElement>(url, capabilities);

增強的驅動程式可讓您「標籤」使用 driver.label("myTestStepLabel") 程式測試中的步驟。這個方法會產生的測試步驟的標籤和伴隨螢幕擷取畫面都可在測試定域機組中測試報表中檢視。我建議在 @After 方法中，將擷取其最終狀態中的應用程式的螢幕擷取畫面，測試完成之前呼叫標籤。即使測試失敗，這可能會提供重要的資訊失敗的原因，將會進入螢幕擷取畫面。實際上，這看起來如下︰

@After
  public void tearDown(){
    driver.label("Stopping app");
    driver.quit();
  }

上傳至測試定域機組

現在，您的專案具備所有必要條件，您即可準備檔案，並在測試定域機組中執行測試回合。上傳的步驟之前，最好請嘗試從本機執行，並確定一切如預期運作。如果您需要疑難排解任何您所做的組態變更，則更快速地執行這項操作在本機。

目標/上傳資料夾至包測試類別及所有相依性，執行下列命令︰

mvn –DskipTests -P prepare-for-upload package

您可能想要驗證的目標/上傳目錄存在來確定您已準備好進行上傳您的專案根資料夾中。如果這是新的應用程式測試定域機組中，您必須建立應用程式做為測試回合的一部分。請遵循的流程來建立新的測試回合選取您的裝置，設定喜好設定並產生您要執行的執行命令。針對此練習，我建議從第 1 層類別選取少數的裝置，因此結果快速就是可供檢閱。複製所產生的命令，並在命令列中執行。

一旦檔案上傳已成功交涉驗證，而且將佈建裝置、應用程式將會安裝和執行您的測試。測試雲端操作模型根據裝置的並行存取或實體可以同時使用的裝置數目。例如，具有五個並行的裝置的使用者可以測試 Nexus 5 X Nexus 6 P 上的應用程式 Samsung Galaxy S5、 Samsung Galaxy S6 和 HTC M8 一次。這種效率是其中一個定域機組測試最重要的優點，方便您增加同時新增一些沒有額外的等候時間跨越多個裝置涵蓋範圍。

命令列工具將資料流更新測試回合的狀態中，當執行完成之後提供測試報表的連結。遵循提供的測試報表連結來檢查您的結果。

有三個層級的資料粒度，您可以檢視您的結果︰

概觀報表。
裝置方格。
裝置詳細資料報表。

我會依序討論每個。

概觀報表概觀提供，讓您執行測試，包括成功或失敗的詳細資訊，由作業系統版本、製造商及外型規格的失敗統計資料的摘要資訊，以及有關執行詳細資料，本身包括裝置為目標的組態和執行時間總計 (請參閱**[圖 2**)。

[圖 2 概觀報表

如果您的測試回合會產生失敗，您可能要深入探索根本原因，並收集資料進行偵錯。裝置方格是下一個層級的詳細資料。

裝置方格裝置方格提供高效率的機制，以瀏覽您的測試結果逐步連同每個步驟所擷取的螢幕擷取畫面。測試步驟中明確指出失敗，您可以快速跳至失敗的步驟，並檢查每個裝置上的應用程式的可見狀態。較大的裝置集，您可以篩選只是無法建立簡潔的欄位，來檢查顯示的裝置。如果此層級的詳細資料，失敗的原因不明顯，您可以向下鑽研一個檢視裝置詳細資料的多個層級 (請參閱**[圖 3**)。

[圖 3 裝置方格報表

裝置詳細資料報表裝置詳細資料檢視可讓您測試步驟瀏覽相同的存取和螢幕擷取畫面但有提供特定至所選的裝置，包括 CPU 和記憶體使用量的其他詳細資料。從這個檢視，您也可以存取的裝置記錄檔和堆疊追蹤，很可能是最有用時的成品調查的測試失敗 (請參閱**[圖 4**)。

[圖 4 裝置詳細資料報表

此時我瀏覽過測試定域機組中最常見的工作流程︰

執行測試（手動或透過連續整合或 CI）。
檢閱結果。
擷取偵錯的成品。
修正程式。

接下來，我將討論幾個簡單的方式來思考您以裝置為目標的策略，以及最佳化效能，使您的管線迅速傳送的測試工作流程。

考慮裝置涵蓋範圍

選取的裝置將支援您的組織，並將其最終測試是幾乎與測試本身一樣重要。雖然有許多可引導您在此區域的思考的彙總及一般化的行銷資料的來源，最有影響力的來源是從您自己的使用者基底的使用狀況資料。例外狀況，當然是只發佈至一組已知且受管理裝置的內部應用程式。針對外部消費者應用程式和內部散佈提到-您擁有的裝置 (BYOD) 原則的應用程式，使用資料是您最佳的來源。

市面上的有許多工具可以協助您獲得深入了解您的觀眾使用的裝置。這是資料集，您可以從中推斷支援的裝置清單。您用於判斷哪些裝置支援彙總清單中的正確方法是由您和貴組織。在大部分情況下，這不會造成應該支援從使用資料，每個裝置，這很快會變得不便且昂貴。您可能決定涵蓋組成特定的使用者百分比基底的裝置數目。或者，您可能決定根據使用者的思考和支援保留涵蓋少於 500 個使用者的裝置所需的裝置數目。如果您的電子商務應用程式，您可能想要使用資料與交易資料來交互參照確保代表最高 spend 的裝置，並涵蓋最頻繁的交易。同樣地，特定的方法讓您開發您的裝置支援的清單應該根據需求和您的業務目標。

請記住行動市場快速移動。這表示，為了讓您能夠精確且有意義的支援清單，您必須檢查使用量資料定期。監看的市場，表示可能會建議是檢閱資料，例如新的裝置型號或 OS 的首展的好時機。

最佳化您的測試管線

若要擷取測試自動化的最大價值，最好是及早並經常測試。這可減少的時間和修正 bug 相關聯的成本，並可確保部署管線保持清除。但與小組和作業的縮放、延遲可以建置在管線中，並可能會降低開發人員的生產力。讓我們看看保留清除的管線和高生產力的方式。

所有測試都等於專案會隨著時間成長，當其測試套件要花較長的時間。沒有的轉捩點，此時執行測試套件後，進行簡單的變更就會痛苦且很麻煩，通常會產生不良的習慣，例如完全略過測試。您可以根據早期思考應用程式的重要路徑優先於這 — 也就是什麼流程或您的應用程式的體驗必須絕對運作？使用稍早的電子商務應用程式範例，這可能表示使用者可以瀏覽產品、將產品加入購物車和簽出。它並沒有那麼重要的是，使用者可以設定他們通知的喜好設定。此結構就地變得更實用的每個發送或甚至是每個認可在執行測試。而不是執行完整的測試套件的小型變更，您可以執行的關鍵路徑的一部分。如何在您完成此區別，將取決於您使用的測試架構。

權限時的權限裝置雖然測試每個推播功能分支可能適合從品質的觀點來看，這很快會變得昂貴對於大型的小組，特別是那些支援許多不同的裝置設定。您可以減少額外負荷此處將漸進式策略套用至您的裝置目標，這些測試回合。非生產分支的建置需要您支援每個裝置上進行測試嗎？答案是不可能。相反地，您可以選取合理的裝置數目之間取得平衡測試較短的等候時間很有效率。進入生產階段前從 CI 組建、取樣的最受歡迎的裝置型號和作業系統版本從您的裝置支援清單將提供寶貴的層級的涵蓋範圍，而不會產生您的組建時間超過一小時。個別開發人員從本機工作站中測試，測試針對一或兩個裝置可能已足夠。

這些是幾個範例的方式可以思考設定您的測試工作流程。更廣泛的重點是要最佳化您的管線流程是否投資問題的時間。即使您已回答這個問題之前，為所需的一切這麼做，最好一律定期檢查和調整。

總結

在本文中您已了解如何輕鬆地從數百個裝置設定使用 Xamarin 測試定域機組的力量單一本機裝置或模擬器上執行測試移轉。我也觸及幾個策略來組織您的測試工作流程及擷取測試資源的最大的價值。如果您未使用測試定域機組，您可以註冊免費試用版在bit.ly/2e3YgTy開始立即使用與您的專案。

Justin Raczak是在 Microsoft，導致行動測試自動化服務的資深專案經理。雖然他最近才加入 Microsoft，他著重在自動化測試和它的角色在過去三年來增進連續傳遞。他可以到達justin.raczak@microsoft.com。

感謝下列 Microsoft 技術專家來檢閱這份文件︰ Simon Søndergaard
Simon Søndergaard 是 Microsoft 的軟體工程師。

討論 MSDN Magazine 論壇的文章