第 6 部分 - 測試和 App Store 核准
測試
許多應用程式（即使是Android應用程式，在某些商店）都必須通過核准程式，才能發佈;因此，測試對於確保您的應用程式到達市場至關重要（更不用說與您的客戶成功）。 測試可以採用許多形式，從開發人員層級單元測試到跨各種硬體管理 Beta 測試。
在所有平台上進行測試
Windows 手機、平板電腦和桌面裝置上的 .NET 支援專案，以及 iOS 上防止動態程式代碼即時產生的限制稍有差異。 您可以在開發程式代碼時規劃在多個平台上測試程式代碼，或在項目結束時排程重構和更新應用程式的模型部分。
最好使用模擬器/模擬器來測試多個操作系統版本，以及不同的裝置功能/組態。
您也應該儘可能測試許多不同的實體硬體裝置。
雲端中的裝置
手機和平板電腦生態系統一直都在增長，使得無法測試不斷增加的可用裝置數量。 為了解決這個問題，一些服務提供遠端控制許多不同裝置的能力，以便安裝及測試應用程式，而不需要直接投資許多硬體。
App Center 測試提供在數百部不同裝置上測試 iOS 和 Android 應用程式的簡單方式。 如需詳細資訊，請參閱準備 Xamarin.Android 應用程式和準備 Xamarin.iOS 應用程式。
測試管理
在組織內測試應用程式或與外部使用者管理 Beta 計劃時，有兩項挑戰：
- 散發 – 管理佈建程式（特別是針對 iOS 裝置），以及將軟體更新版本傳送給測試人員。
- 意見反應 – 收集應用程式使用方式的相關信息，以及可能發生之任何錯誤的詳細資訊。
提供內建的基礎結構來收集和報告使用量和錯誤，以及簡化布建程式，協助註冊及管理測試人員及其裝置，藉此協助解決這些問題。
Visual Studio App Center 提供這些問題的解決方案，提供測試版本發佈、當機報告，以及複雜的應用程式使用資訊。
測試自動化
Xamarin UITest 可用來建立可在本機執行或上傳至 App Center 測試的自動化使用者介面測試腳本。
單元測試
Touch.Unit
Xamarin.iOS 包含名為 Touch.Unit 的單元測試架構，其遵循 JUnit/NUnit 樣式撰寫測試。
如需撰寫測試和執行 Touch.Unit 的詳細資訊，請參閱使用 Xamarin.iOS 進行單元測試的檔。
Andr.Unit
適用於 Android 的 Touch.Unit 具有稱為 Andr.Unit 的開放原始碼對等專案。 您可以從 github 下載，並閱讀@spouliot部落格上的工具。
App Store 核准
Apple 和 Microsoft 在其平臺上操作唯一的商店：App Store 和 Marketplace。 兩者都會鎖定其裝置，並實作嚴格的應用程式檢閱程式，以控制可供下載的應用程序品質。 Android 的開放性質意味著有一些商店選項，從谷歌的 Play，這是廣泛可用的，沒有審查程式，亞馬遜的 Appstore 的 Android 和硬體特定工作，如三星應用程式，具有更有限的發佈和實作核准程式。
等待應用程式檢閱可能會非常緊張 - 商業壓力通常表示應用程式提交核准，在「目標」啟動日期之前，錯誤幅度很小。 此程式本身最多可能需要兩周的時間，而且不一定是透明的：在應用程式最終遭到拒絕或核准之前，對應用程式的進度有有限的意見反應。 拒絕可能意味著遺漏商機的營銷視窗，特別是如果它發生多次，以及您原始啟動日期與最終核准應用程式之間的周時間。
準備好
第一項建議：提前規劃app的推出，並針對可能的拒絕和重新提交提供津貼。 每個市集都需要您在提交應用程式之前先建立帳戶-請儘早執行此動作。 雖然 Google Play 的註冊只需要幾分鐘的時間，如果您的應用程式是免費的，如果您出售這些應用程式，而且需要提供銀行和稅務資訊，這個過程會更加相關。 蘋果和微軟的程式都比谷歌更涉及，可能需要一周或更多時間才能批准您的帳戶，所以這次考慮您的推出計劃。
一旦您的帳戶獲得核准，您就可以提交應用程式。 提交應用程式的實際程式涵蓋在下列檔案中：
- 發佈至 Apple 的 iOS App Store
- 準備Google Play的應用程式
- Windows 開發人員應該造訪 Windows 開發人員中心，以閱讀提交其應用程式的相關信息。
本節的其餘部分將討論您應該考慮的事項，以確保您的應用程式未經任何擷取即可核准。
品質
這聽起來很明顯，但應用程式通常會被拒絕，因為他們不符合一定的品質等級：畢竟，這就是為什麼策劃的商店有一個核准程式在一開始的原因！
當機是拒絕的常見原因。 如果讓應用程式當機太容易，則保證會遭到拒絕。 大部分的開發人員不會提交他們的應用程式，因為他們期望它們會當機，但他們經常會這麼做。 在提交應用程式之前徹底測試您的應用程式，不僅著重於確保一切運作，還能處理常見的行動錯誤案例，例如網路問題和資源限制，例如記憶體或儲存空間。 使用模擬器和實體裝置來測試 - 不論程式代碼在模擬器中執行得有多好，只有裝置可以示範應用程式的實際效能。 如果可以的話，請盡可能使用許多不同的裝置，並加入 Beta 測試人員小組 -- 第三方服務可協助管理 Beta 散發和意見反應。
所有行動作業系統都會終止無法快速啟動的應用程式。 允許的時間長度會有所不同，但在一般應用程式中，應該會在幾秒鐘內回應，並使用背景工作來執行任何需要較長時間的工作。 應用程式需要太多時間才能載入，或在一般使用中回應不夠快的應用程式將會遭到拒絕。 在背景發生某個情況時，請一律提供使用者意見反應，或應用程式似乎已當機，並再次遭到拒絕。
檢查您的Edge案例
開發人員的常見陷阱無法解決邊緣案例，尤其是需要重新設定模擬器或裝置才能正確測試的陷阱。 很容易忘記，並不是每位客戶都會「允許」您的應用程式存取其位置，因為在開發人員接受要求一次之後，他們永遠不會再次收到提示。 許可權和網路使用方式特別著重於核准程序期間，這表示這些領域的小型監督可能會導致拒絕。
下列清單是檢查可能遺漏邊緣案例的良好起點：
- 客戶可能會「拒絕」存取服務 ，特別是在iOS中，只有在使用者授與應用程式許可權時，才會提供地理位置資訊等數據的存取權。 應用程式測試人員應該經常以初始狀態重新安裝應用程式，並不允許任何許可權要求，以確保應用程式的行為適當。 切換開啟和關閉許可權，以在客戶改變想法時驗證正確的行為。
- 客戶無處不在 – 不要假設應用程式只會用於開發所在的城市或國家/地區！ 使用 GPS 座標、日期和時間值和貨幣的程式代碼都可能會受到客戶位置和地區設定的影響。 所有平臺都提供模擬器，可讓您指定不同的位置和地區設定-使用它來測試其他半球的位置，以及以不同方式格式化日期和貨幣的文化特性。 緯度和經度值可以是正數或負數，小數分隔符可以是句點或逗號，而且日期可以格式化無數的方式 - 處理它！
- 網路連線 變慢 – 應用程式開發人員通常會在快速且一律運作的網路連線的「理想世界」中運作，這顯然在真實世界中並不常見。 測試網路連線速度緩慢（例如 3G 連線不佳），且沒有網路存取對於確保您不會寄送錯誤應用程式至關重要。 核准程式一律會在飛機模式中包含裝置的測試，因此請確定您已自行測試該測試。
- 硬體會有所不同 – 請記得在您計劃支援的最舊、最慢的硬體上進行測試。 有兩個方面可能會影響您的應用程式：效能、在較舊的裝置上可能無法使用，以及相機、麥克風、GPS、陀螺儀或其他選用元件等硬體功能的支援。 當元件無法使用時，應用程式應該會正常降級（且不會當機）。
指導方針不僅僅是一個「指南」
蘋果以嚴格遵守其人介面指導方針而聞名，因為他們的平臺的主要優勢之一是一致性（以及感知的可用性增加）。 Microsoft 對實作 Fluent Design 系統 的 Windows 應用程式採取了類似的方法。 這兩個平臺的核准程式將涉及評估您的應用程式是否符合相關的設計理念。
這並不是說使用者介面創新不受支持或鼓勵，但您「不應該這麼做」或您的應用程式將會遭到拒絕。
在 iOS 上，這包括濫用內建圖示，或以不一致的方式使用其他已建立的隱喻;例如，針對建立新內容以外的任何專案使用 『compose』 圖示。
Windows 開發人員應該同樣小心;根據 Microsoft 的指導方針，常見的錯誤無法正確支持硬體 [上一頁] 按鈕。
鼓勵您的設計工具閱讀並遵循每個平臺的設計指導方針。
實作平臺特定功能
實作平臺特定服務，特別是在iOS上時，情況會更加嚴格。 若要避免Apple自動拒絕，有一些規則要遵循下列iOS功能：
- 應用程式內購買 – 應用程式不得為數位產品實作外部付款機制，包括遊戲內貨幣、應用程式功能、雜誌訂閱等等。 iOS 應用程式必須針對這類功能使用 Apple 的 iTunes 型服務。 有一個漏洞 - 像 Kindle Reader 和一些以訂用帳戶為基礎的應用程式等應用程式可讓您購買附加至「帳戶」的內容，然後您可以透過應用程式存取，但在此情況下，應用程式不得包含應用程式外購買程式的連結或參考（或再次拒絕）。
- iCloud 備份 – 隨著 iCloud 的出現，Apple 的檢閱者對於應用程式使用記憶體的方式更為嚴格（以確保客戶的遠端備份體驗愉快）。 浪費備份儲存空間的應用程式可能會遭到拒絕，因此請適當地使用快取資料夾，並遵循 Apple 的其他記憶體相關指導方針。
- 美因 – 報紙和雜誌應用程式非常適合 Apple 的美感，不過應用程式必須至少實作一個自動更新訂閱和支援背景下載才能獲得核准。
- 地圖 – 將重疊和其他功能新增至行動地圖越來越常見，但請小心不要遮蔽地圖的「點數」資訊（例如 iOS5 中的 Google 標誌），因為這樣做會導致拒絕。
管理您的元數據
除了可能導致應用程式遭到拒絕的明顯技術問題之外，您提交的一些更微妙層面可能會導致拒絕，特別是在您隨應用程式一起提交的元數據（描述、關鍵詞和行銷影像）周圍，以在 App Store 或 Marketplace 內顯示。
- 影像 – 遵循平台的應用程式圖示和儲存圖片指導方針。 請勿使用商標影像，我們看到應用程式遭到拒絕，因為它們的圖示精選了 i 電話！
- 商標 – 避免使用您自己以外的任何商標。 應用程式因在應用程式描述中提及商標，或甚至在Apple App Store的關鍵詞中提及商標而遭到拒絕。
- 描述 – 請勿使用 'beta' 一詞，或以任何方式指出應用程式尚未準備好進行黃金時段。 別提其他行動平臺（即使您的應用程式是跨平臺也一樣）。 最重要的是，請確定應用程式確實會執行您所說的內容。 如果您在描述中列出一堆功能，最好是清楚如何使用每項功能，否則您會收到「未實作應用程式描述中提及的功能」拒絕。
將投入到應用程式元數據中，如同開發和測試一樣努力。 應用程式 DO 因元數據中的輕微侵權而遭到拒絕，因此值得花時間進行正確處理。
App Store：不適合所有人
每個平臺上商店的主要焦點是消費者分佈，能夠盡可能接觸盡可能多的客戶。 然而，並非所有應用程式都以消費者為目標，因此內部和外部網路應用程式的基礎快速增長，需要有限的員工、供應商或客戶分配。 這些應用程式不是「銷售」，而且不需要核准，因為開發人員會控制散發給關閉的使用者群組。 這種類型的部署支援會因平臺而異。
Android 在這方面提供最大的彈性：應用程式可以直接從 URL 或電子郵件附件安裝（只要裝置的設定允許）。 這表示建立併發佈內部公司應用程式，或將應用程式發佈給特定客戶或供應商是微不足道的。
Apple 提供內部部署選項給 iOS Developer Enterprise Program 中註冊的開發人員，其會略過 App Store 核准程式，並允許公司將內部應用程式散發給員工。 不幸的是，此授權無法解決外部網路型應用程式散發給其他已關閉的客戶或供應商群組的需求。 企業 （和臨機操作） 部署
App Store 摘要
檢閱程式可能令人生畏，但就像開發生命週期的其餘部分一樣，您可以協助確保一些規劃和關注細節的成功。 這一切都歸結為幾個簡單的步驟：閱讀並瞭解您必須遵守的使用者介面指導方針，如果您實作平臺特定功能，請遵循規則，徹底測試（然後測試更多），最後確定應用程式元數據正確，再提交。
對於在Google Play上發佈開發人員的最後一句話建議：缺乏核准程式似乎會使您的工作變得更容易，但您的客戶會比審查小組更苛刻。 請遵循這些指導方針，就像您的應用程式可能會遭到拒絕一樣，否則會是進行拒絕的客戶。