第6 部分- 測試和App Store 核准

散發– 管理布建程式(特別適用于iOS裝置，) 並將軟體版本更新給測試人員。

... 載入時間過長或未在一般使用中回應不足的應用程式將會遭到拒絕。

跳到主要內容 已不再支援此瀏覽器。

請升級至MicrosoftEdge，以利用最新功能、安全性更新和技術支援。

下載MicrosoftEdge 其他資訊 目錄 結束焦點模式 閱讀英文 儲存 目錄 閱讀英文 儲存 Twitter LinkedIn Facebook 電子郵件 目錄 第6部分-測試和AppStore核准 發行項 05/20/2022 7位參與者 本文內容 測試 許多應用程式(甚至Android應用程式，某些商店)必須在發佈前通過核准程式;因此測試是確保您的應用程式達到市場(讓客戶成功)的關鍵。

測試可以採用許多形式，從開發人員層級單元測試到跨各種硬體管理Beta測試。

在所有平臺上進行測試 .NET在Windows手機、平板電腦和桌面裝置上支援的功能稍有差異，以及防止動態程式碼即時產生之iOS的限制。

在開發程式碼時，請規劃在多個平臺上測試程式碼，或在專案結束時排程重構和更新應用程式的模型部分。

使用模擬器/模擬器來測試多個版本的作業系統，以及不同的裝置功能/組態一定是不錯的做法。

您也應該盡可能測試許多不同的實體硬體裝置。

雲端中的裝置 行動電話和平板電腦生態系統一切都持續成長，因此無法在不斷增加的裝置上進行測試。

若要解決此問題，許多服務都能夠從遠端控制許多不同的裝置，讓應用程式可以安裝及測試，而不需要直接投資許多硬體。

AppCenter測試提供簡單的方法，可在數百個不同裝置上測試iOS和Android應用程式。

如需詳細資訊，請參閱準備Xamarin.Android應用程式和準備Xamarin.iOS應用程式。

測試管理 在組織內測試應用程式或與外部使用者管理Beta計畫時，有兩項挑戰： 散發–管理布建程式(特別適用于iOS裝置，)並將軟體版本更新給測試人員。

意見反應–收集應用程式使用方式的相關資訊，以及可能發生之任何錯誤的詳細資訊。

有一些服務可協助解決這些問題，方法是提供應用程式內建的基礎結構來收集和報告使用量和錯誤，並簡化布建程式，以協助註冊和管理測試人員及其裝置。

VisualStudioAppCenter提供這些問題的解決方案，並提供測試版本發佈、損毀報告，以及複雜的應用程式使用資訊。

測試自動化 XamarinUITest可用來建立可在本機執行或上傳至AppCenter測試的自動化使用者介面測試腳本。

單元測試 Touch.Unit Xamarin。

iOS包含名為Touch.Unit的單元測試架構，其遵循JUnit/NUnit樣式撰寫測試。

如需撰寫測試和執行Touch.Unit的詳細資料，請參閱使用Xamarin.iOS的單元測試檔。

Andr.Unit 針對稱為Andr.Unit的Android，具有Touch.Unit的開放原始碼對等專案。

您可以從github下載它，並閱讀@spouliot部落格上的工具。

AppStore核准 Apple和Microsoft在其平臺上操作唯一的商店：分別AppStore和Marketplace。

這兩者都會鎖定其裝置，並實作嚴格的應用程式檢閱程式，以控制可供下載的應用程式品質。

Android的開放本質表示有數個商店選項，範圍從Google的Play廣泛可用，且沒有檢閱程式，到Amazon的Appstore，以進行Android和硬體特定工作，例如SamsungApps，其散發空間有限，並實作核准程式。

等候應用程式檢閱可能會非常壓力-業務壓力通常表示應用程式在「目標」啟動日期之前提交核准，但有非常少的錯誤邊界。

程式本身最多可能需要兩周的時間，而且不一定是透明的：應用程式進度有有限的意見反應，直到最終拒絕或核准為止。

拒絕可能表示缺少商機的行銷視窗，特別是在發生多次時，以及在您原始啟動日期與應用程式最終核准之間的周數。

準備好 第一項建議：事先規劃App的啟動，並針對可能的拒絕和重新提交提供額度。

每個市集都需要您在提交應用程式之前先建立帳戶-請儘快執行此動作。

雖然GooglePlay的註冊只需要幾分鐘的時間，如果您的應用程式是免費的，但如果您要銷售應用程式，且需要提供銀行和稅務資訊，此程式會有更多涉及。

Apple和Microsoft的程式都比Google更涉及，可能需要一周或更多時間才能核准您的帳戶，因此將這次納入您的啟動計畫。

一旦您的帳戶獲得核准，您就可以提交應用程式。

下列檔涵蓋提交應用程式的實際程式： 發佈至Apple的iOSAppStore 準備應用程式以進行GooglePlay Windows開發人員應該造訪Windows開發人員中心，以閱讀提交其應用程式的相關資訊。

本節的其餘部分將討論您應該考慮的事項，以確保您的應用程式經過核准，而不需要任何隱藏。

品質 這聽起來很明顯，但應用程式通常會因為不符合特定品質等級而遭到拒絕：事實上，這是策劃的商店在第一個地方有核准程式的原因！ 當機是拒絕的常見原因。

如果應用程式損毀太容易，則保證會遭到拒絕。

大部分的開發人員都未提交其應用程式，但預期它們會當機，但通常會這麼做。

在提交應用程式之前徹底測試您的應用程式，不僅著重于確定一切運作正常，還能處理常見的行動錯誤案例，例如網路問題和資源限制，例如記憶體或儲存空間。

使用模擬器和實體裝置進行測試-不論程式碼在模擬器中的執行程度為何，只有裝置可以示範應用程式的實際效能。

如果可以的話，請使用許多不同的裝置，並加入Beta測試人員小組，協力廠商服務可協助管理Beta散發和意見反應。

所有行動作業系統都會終止無法快速啟動的應用程式。

允許的時間長度會有所不同，但在一般應用程式中，應該以幾秒鐘的回應性為目標，並使用背景工作來執行需要較長時間的任何工作。

載入時間過長或未在一般使用中回應不足的應用程式將會遭到拒絕。

一律在背景發生某個專案時提供使用者意見反應，或應用程式似乎已當機，並再次遭到拒絕。

檢查您的Edge案例 開發人員的常見陷阱無法解決邊緣案例，特別是需要重新設定模擬器或裝置才能正確測試的案例。

您可以輕鬆地忘記，並非所有客戶都會「允許」您的應用程式存取其位置，因為開發人員接受要求一次之後，永遠不會再次提示他們。

許可權和網路使用量特別著重于核准程式期間，這表示這些領域的小型監督可能會導致拒絕。

下列清單是檢查可能遺漏邊緣案例的良好起點： 客戶可能會「拒絕」對服務的存取權，特別是在iOS中，只有在使用者授與應用程式許可權時，才會提供地理位置資訊等資料的存取權。

應用程式測試人員應該經常以初始狀態重新安裝應用程式，並不允許任何許可權要求，以確保應用程式的行為適當。

開啟和關閉許可權，以在客戶變更心意時驗證正確的行為。

客戶位於任何地方–不假設應用程式只會用於開發所在的城市或國家/地區！使用GPS座標、日期和時間值和貨幣的程式碼，都可能會受到客戶位置和地區設定的影響。

所有平臺都提供模擬器，可讓您指定不同的位置和地區設定--使用它來測試其他地理位置，以及以不同方式格式化日期和貨幣的文化特性。

緯度和經度值可以是正數或負數，小數分隔符號可以是句點或逗號，而且日期可以格式化各種方式-處理！ 網路連線緩慢–應用程式開發人員通常會在快速、一律運作的網路連線能力「理想世界」中運作，這顯然不是真實世界的情況。

使用慢速網路連線(進行測試，例如3G連線不佳)，以及沒有網路存取權，以確保您不會寄送錯誤的應用程式。

核准程式一律會在飛機模式中包含裝置的測試，因此請確定您已自行測試。

硬體不同–請記得在您計畫支援的最舊、最慢硬體上進行測試。

有兩個層面可能會影響您的應用程式：效能、在較舊的裝置上可能無法使用，以及支援相機、麥克風、GPS、陀螺儀或其他選擇性元件等硬體功能。

當元件無法使用時，應用程式應該會正常降級(，且不會損毀)。

指導方針不只是「指南」 Apple對於遵守其人類介面指導方針而言，其名在於其平臺的其中一個重要優點是一致性(，以及認知的可用性增加)。

Microsoft已採用類似的方法來實作FluentDesign系統Windows應用程式。

這兩個平臺的核准程式將牽涉到您的應用程式受到評估，以符合相關的設計原理。

這不表示使用者介面創新不受支援或鼓勵，但有一些您「不應該這麼做」或您的應用程式將會遭到拒絕。

在iOS上，這包括不當使用內建圖示，或以非一致的方式使用其他妥善建立的隱喻;例如，針對建立新內容以外的任何專案使用'compose'圖示。

Windows開發人員應該很小心;根據Microsoft的指導方針，常見的錯誤無法正確支援硬體[上一步]按鈕。

鼓勵您的設計工具閱讀並遵循每個平臺的設計指導方針。

實作Platform-Specific功能 實作平臺特定服務時，專案會比較嚴格，特別是在iOS上。

若要避免Apple自動拒絕，有一些規則可遵循下列iOS功能： 應用程式內購買–應用程式不得針對數位產品實作外部付款機制，包括遊戲內貨幣、應用程式功能、雜誌訂閱等等。

iOS應用程式必須針對這類功能使用Apple的iTunes型服務。

有一個漏洞-KindleReader和一些訂用帳戶型應用程式等應用程式可讓您購買附加至「帳戶」的其他位置的內容，然後您可以透過應用程式存取，不過在此案例中，應用程式不得包含應用程式外購買程式的連結或參考，(或再次拒絕它)。

iCloud備份–隨著iCloud的出現，Apple的檢閱者對於應用程式如何使用儲存體(更嚴格，以確保客戶的遠端備份體驗是)。

浪費備份可用儲存空間的應用程式可能會遭到拒絕，因此請適當地使用快取資料夾，並遵循Apple的其他儲存體相關指導方針。

訂閱–新聞和雜誌應用程式非常適合Apple的聖地，不過，應用程式必須實作至少一個自動續約訂閱和支援背景下載，才能獲得核准。

地圖–在行動地圖中新增重迭和其他功能越來越常見，不過請小心不要遮蔽地圖「點數」資訊，(例如iOS5中的Google標誌)，如此一來，就會導致拒絕。

管理您的中繼資料 除了可能導致應用程式遭到拒絕的明顯技術問題之外，您提交的一些更細微層面也可能會導致拒絕，特別是關於中繼資料(描述、關鍵字和行銷影像，)您提交應用程式以在AppStore或Marketplace內顯示。

影像–遵循應用程式圖示和儲存圖片的平臺指導方針。

請勿使用商標影像，我們發現應用程式因為其圖示精選了iPhone的繪圖而遭到拒絕！ 商標–避免使用您自己的任何商標。

應用程式已拒絕在應用程式描述中提及商標，或甚至是AppleAppStore上的關鍵字。

描述–請勿使用'Beta'這個字，或以任何方式指出應用程式尚未準備好進行入門時間。

即使您的應用程式是跨平臺)，也請勿提及其他行動平臺(。

最重要的是，請確定應用程式確實會執行您說出的功能。

如果您在描述中列出許多功能，最好是清楚如何使用每項功能，或者您會收到「未實作應用程式描述中所提及的功能」拒絕。

投入大量心力處理應用程式的中繼資料，就像是開發和測試一樣。

應用程式在中繼資料中遭到次要違規而遭到拒絕，因此值得花一些時間來正確取得。

AppStore：不適用於所有人 每個平臺上商店的主要焦點是消費者散發，能夠盡可能觸達許多客戶。

不過，並非所有應用程式都是以取用者為目標，因此內部和類似網路的應用程式有快速成長的基礎，這些應用程式需要有限散發給員工、供應商或客戶。

這些應用程式不是「銷售」，而且不需要核准，因為開發人員會控制散發給已關閉的使用者群組。

支援這種類型的部署會因平臺而異。

Android提供最大的彈性：只要裝置的設定允許)，就可以直接從URL或電子郵件附件(安裝應用程式。

這表示建立並散發內部公司應用程式，或將應用程式發佈給特定客戶或供應商是很簡單的。

Apple為iOS開發人員Enterprise計畫註冊的開發人員提供內部部署選項，可略過AppStore核准程式，並允許公司將內部應用程式散發給員工。

不幸的是，此授權無法解決對其他已關閉的客戶或供應商群組進行類似外部網路應用程式散發的需求。

Enterprise(和臨機操作)部署 AppStore摘要 檢閱程式可能很困難，但就像開發生命週期的其餘部分一樣，您可以協助確保一些規劃和注意詳細資料的成功。

這全都屬於幾個簡單的步驟：閱讀並瞭解您必須遵守的使用者介面指導方針、如果您實作平臺特定功能，請遵循規則、徹底測試(然後測試一些更多)，最後確定您的應用程式中繼資料在您提交之前是正確的。

開發人員發佈GooglePlay的最後一個建議：缺乏核准程式看起來可能讓工作更容易，但您的客戶會比檢閱小組更需要要求。

請遵循這些指導方針，就像您的應用程式可能會遭到拒絕一樣，否則會是您的客戶執行拒絕。

本文內容