Share via

6부 - 테스트 및 App Store 승인

  • 아티클

테스팅

많은 앱(일부 스토어의 Android 앱)은 게시되기 전에 승인 프로세스를 통과해야 합니다. 따라서 테스트는 앱이 시장에 도달하는 데 중요합니다(고객과 함께 성공하는 것은 물론). 테스트는 개발자 수준 단위 테스트부터 다양한 하드웨어에서 베타 테스트 관리에 이르기까지 다양한 형태를 취할 수 있습니다.

모든 플랫폼에서 테스트

Windows 휴대폰, 태블릿 및 데스크톱 디바이스에서 .NET이 지원하는 것과 동적 코드가 즉시 생성되지 않도록 하는 iOS의 제한 사항 간에는 약간의 차이가 있습니다. 개발하는 동안 여러 플랫폼에서 코드를 테스트하거나 프로젝트 끝에 애플리케이션의 모델 부분을 리팩터링하고 업데이트하는 시간을 예약합니다.

시뮬레이터/에뮬레이터를 사용하여 여러 버전의 운영 체제와 다양한 디바이스 기능/구성을 테스트하는 것이 좋습니다.

또한 가능한 한 많은 물리적 하드웨어 디바이스를 테스트해야 합니다.

클라우드의 디바이스

휴대폰 및 태블릿 에코시스템은 항상 증가하고 있어 점점 더 많은 디바이스를 사용할 수 있는 디바이스를 테스트하는 것은 불가능합니다. 이 문제를 해결하기 위해 많은 서비스가 많은 하드웨어에 직접 투자하지 않고도 애플리케이션을 설치하고 테스트할 수 있도록 다양한 디바이스를 원격으로 제어할 수 있는 기능을 제공합니다.

App Center 테스트는 수백 개의 다른 디바이스에서 iOS 및 Android 애플리케이션을 쉽게 테스트할 수 있는 방법을 제공합니다. 자세한 내용은 Xamarin.Android 앱 준비 및 Xamarin.iOS 앱 준비를 참조하세요.

Test Management

조직 내에서 애플리케이션을 테스트하거나 외부 사용자로 베타 프로그램을 관리하는 경우 다음 두 가지 문제가 있습니다.

  • 배포 – 프로비전 프로세스 관리(특히 iOS 디바이스의 경우) 테스터에게 업데이트된 버전의 소프트웨어를 가져옵니다.
  • 피드백 – 애플리케이션 사용량에 대한 정보 및 발생할 수 있는 오류에 대한 자세한 정보 수집

애플리케이션에 기본 제공되는 인프라를 제공하여 사용량 및 오류를 수집하고 보고하고 테스터와 해당 디바이스를 등록하고 관리하는 데 도움이 되는 프로비전 프로세스를 간소화하여 이러한 문제를 해결하는 데 도움이 되는 여러 가지 서비스가 있습니다.

Visual Studio App Center 는 이러한 문제에 대한 솔루션을 제공하여 테스트 버전 배포, 크래시 보고 및 정교한 애플리케이션 사용 정보를 제공합니다.

검사 자동화

Xamarin UITest를 사용하여 로컬로 실행하거나 App Center 테스트에 업로드할 수 있는 자동화된 사용자 인터페이스 테스트 스크립트를 만들 수 있습니다.

단위 테스트

Touch.Unit

Xamarin.iOS에는 JUnit/NUnit 스타일 쓰기 테스트를 따르는 Touch.Unit이라는 단위 테스트 프레임워크가 포함되어 있습니다.

테스트 작성 및 Touch.Unit 실행에 대한 자세한 내용은 Xamarin.iOS를 사용한 유닛 테스트 설명서를 참조하세요.

Andr.Unit

Andr.Unit이라는 Android용 Touch.Unit에 해당하는 오픈 소스가 있습니다. github에서 다운로드하고 @spouliot 블로그의 도구에 대해 읽을 수 있습니다.

App Store 승인

Apple과 Microsoft는 각각 앱 스토어와 마켓플레이스의 플랫폼에서 유일한 스토어를 운영합니다. 둘 다 디바이스를 잠그고 엄격한 앱 검토 프로세스를 구현하여 다운로드할 수 있는 애플리케이션의 품질을 제어합니다. 안드로이드의 개방적 성격은 널리 사용할 수 있고 검토 프로세스가 없는 Google의 Play에서부터 Android용 Amazon의 앱 스토어 및 더 제한된 배포가 있고 승인 프로세스를 구현하는 삼성 앱과 같은 하드웨어 관련 노력에 이르기까지 다양한 스토어 옵션이 있음을 의미합니다.

앱이 검토되기를 기다리는 것은 매우 스트레스가 될 수 있습니다. 비즈니스 압력은 종종 애플리케이션이 "대상" 출시 날짜 이전에 오류에 대한 여백이 거의 없는 승인을 위해 제출됨을 의미합니다. 프로세스 자체는 최대 2주가 걸릴 수 있으며 반드시 투명하지는 않습니다. 최종적으로 거부되거나 승인될 때까지 애플리케이션 진행 상황에 대한 피드백이 제한됩니다. 거부는 특히 두 번 이상 발생하는 경우, 원래 시작 날짜와 앱이 마지막으로 승인된 시점 사이에 몇 주가 경과하는 경우 영업 기회의 마케팅 기간을 누락하는 것을 의미할 수 있습니다.

준비

조언의 첫 번째 조각 : 사전에 잘 응용 프로그램의 출시를 계획하고 가능한 거부 및 재 제출에 대한 수당을합니다. 각 저장소는 앱을 제출하기 전에 계정을 만들어야 합니다. 가능한 한 빨리 이 작업을 수행합니다. Google Play의 등록은 앱이 무료인 경우 몇 분밖에 걸리지 않지만, 앱이 판매되고 은행 및 세금 정보를 제공해야 하는 경우 프로세스가 훨씬 더 복잡해집니다. 애플과 마이크로 소프트의 프로세스는 모두 구글보다 훨씬 더 관여, 그것은 당신의 계정이 승인을 얻기 위해 일주일 이상 걸릴 수 있습니다 그래서 당신의 출시 계획에이 시간을 요인.

계정이 승인되면 앱을 제출할 준비가 된 것입니다. 앱을 제출하는 실제 프로세스는 다음 설명서에서 다룹니다.

이 섹션의 re기본der에서는 딸 틈 없이 앱이 승인되었는지 확인하기 위해 고려해야 할 사항에 대해 설명합니다.

품질

그것은 분명 소리,하지만 응용 프로그램은 종종 품질의 특정 수준을 충족하지 않기 때문에 거부됩니다 : 결국, 이것은 큐레이팅 매장이 처음에 승인 프로세스가 이유입니다!

크래시는 거부의 일반적인 이유입니다. 앱 충돌을 만들기가 너무 쉽으면 거부됩니다. 대부분의 개발자는 충돌할 것이라는 기대로 앱을 제출하지 않지만 종종 그렇게 합니다. 제출하기 전에 앱을 철저히 테스트하여 모든 것이 작동하는지 확인하는 것뿐만 아니라 네트워크 문제 및 메모리 또는 스토리지 공간과 같은 리소스 제약 조건과 같은 일반적인 모바일 오류 시나리오를 처리하는 데 집중합니다. 시뮬레이터와 물리적 디바이스를 모두 사용하여 테스트합니다. 시뮬레이터에서 코드가 얼마나 잘 실행되는지에 관계없이 디바이스만 앱의 실제 성능을 보여줄 수 있습니다. 찾을 수 있는 만큼 다양한 디바이스를 사용하고 가능한 경우 베타 테스터 팀에 참여합니다. 타사 서비스는 베타 배포 및 피드백을 관리하는 데 도움이 될 수 있습니다.

모든 모바일 운영 체제는 충분히 빠르게 시작되지 않는 애플리케이션을 종료합니다. 허용되는 시간은 다양하지만, 일반적으로 앱은 몇 초 안에 응답하고 백그라운드 작업을 사용하여 더 오래 걸리는 작업을 수행하는 것을 목표로 해야 합니다. 로드하는 데 시간이 너무 오래 걸리거나 정기적으로 충분히 응답하지 않는 앱은 거부됩니다. 백그라운드에서 문제가 발생하는 경우 항상 사용자 피드백을 제공하거나 앱이 충돌한 것으로 표시되고 다시 한 번 거부됩니다.

Edge 사례 확인

개발자를 위한 일반적인 트랩은 에지 케이스, 특히 제대로 테스트하기 위해 시뮬레이터 또는 디바이스를 다시 구성해야 하는 사례를 해결하지 못하고 있습니다. 개발자가 요청을 한 번 수락한 후에는 다시는 메시지가 표시되지 않기 때문에 모든 고객이 앱이 자신의 위치에 액세스하도록 "허용"하는 것은 아님을 잊기 쉽습니다. 권한 및 네트워크 사용은 특히 승인 프로세스 중에 집중되므로 이러한 영역에서 작은 감독으로 인해 거부될 수 있습니다.

다음 목록은 누락되었을 수 있는 에지 사례를 검사 위한 좋은 시작점입니다.

  • 고객은 서비스에 대한 액세스를 '거부'할 수 있습니다. 특히 iOS에서 지리적 위치 정보와 같은 데이터에 대한 액세스는 사용자가 애플리케이션에 권한을 부여하는 경우에만 제공됩니다. 애플리케이션 테스터는 초기 상태에서 애플리케이션을 자주 다시 설치하고 애플리케이션이 적절하게 동작하도록 권한 요청을 허용하지 않아야 합니다. 고객이 마음을 바꿀 때 올바른 동작을 확인하기 위해 사용 권한을 설정/해제합니다.
  • 고객은 어디에나 있습니다. 앱이 개발된 도시 또는 국가에서만 사용된다고 가정하지 마세요! GPS 좌표, 날짜 및 시간 값 및 통화와 함께 작동하는 코드는 모두 고객의 위치 및 로캘 설정의 영향을 받을 수 있습니다. 모든 플랫폼은 다른 위치와 로캘을 지정할 수 있는 시뮬레이터를 제공합니다. 이를 사용하여 다른 반구의 위치와 날짜 및 통화 형식을 다르게 지정하는 문화권에서 테스트합니다. 위도 및 경도 값은 양수 또는 음수일 수 있고, 소수 구분 기호는 마침표 또는 쉼표일 수 있으며, 날짜는 무수한 방법으로 서식을 지정할 수 있습니다.
  • 느린 네트워크 연결 – 앱 개발자는 종종 빠르고 항상 작동하는 네트워크 연결의 '이상적인 세계'에서 작업하는데, 이는 실제 환경에서는 그렇지 않습니다. 느린 네트워크 연결(예: 3G 연결 불량)과 네트워크 액세스 없이 테스트하는 것은 버그가 있는 앱을 제공하지 않도록 하는 데 중요합니다. 승인 프로세스에는 항상 비행기 모드에서 디바이스를 사용한 테스트가 포함되므로 직접 테스트했는지 확인합니다.
  • 하드웨어는 다양합니다. 지원하려는 가장 오래되고 가장 느린 하드웨어를 테스트해야 합니다. 앱에 영향을 줄 수 있는 두 가지 측면은 이전 장치에서 사용할 수 없는 성능과 카메라, 마이크, GPS, 자이로스코프 또는 기타 선택적 구성 요소와 같은 하드웨어 기능에 대한 지원입니다. 구성 요소를 사용할 수 없는 경우 애플리케이션은 정상적으로 성능이 저하되고 충돌하지 않아야 합니다.

지침은 단순한 '가이드' 이상입니다.

Apple은 플랫폼의 주요 강점 중 하나는 일관성(및 사용 가능성의 인식된 증가)으로 인간 인터페이스 지침을 준수하는 것에 대해 엄격한 것으로 유명합니다. Microsoft는 Fluent Design 시스템 구현하는 Windows 애플리케이션과 비슷한 접근 방식을 취했습니다. 두 플랫폼에 대한 승인 프로세스에는 관련 디자인 철학을 준수하는지 평가되는 앱이 포함됩니다.

즉, 사용자 인터페이스 혁신이 지원되거나 권장되지 않는다는 것을 말하는 것이 아니라 "그냥 하지 말아야 할" 특정 사항이 있거나 앱이 거부됩니다.

iOS에서는 기본 제공 아이콘을 오용하거나 일관되지 않은 방식으로 잘 설정된 다른 은유를 사용하는 것이 포함됩니다. 예를 들어 새 콘텐츠를 만드는 것 이외의 다른 항목에 대해 '작성' 아이콘을 사용하는 경우를 예로 들어 보겠습니다.

Windows 개발자도 마찬가지로 주의해야 합니다. 일반적인 실수는 Microsoft의 지침에 따라 하드웨어 뒤로 단추를 제대로 지원하지 못하는 것입니다.

디자이너가 각 플랫폼에 대한 디자인 지침을 읽고 따르도록 권장합니다.

플랫폼별 기능 구현

특히 iOS에서 플랫폼별 서비스를 구현할 때는 좀 더 엄격합니다. Apple에서 자동 거부를 방지하려면 다음 iOS 기능을 따라야 하는 몇 가지 규칙이 있습니다.

  • 앱 내 구매 – 애플리케이션은 게임 내 통화, 애플리케이션 기능, 잡지 구독 등을 비롯한 디지털 제품에 대한 외부 결제 메커니즘을 구현해서는 안 됩니다. iOS 앱은 이러한 종류의 기능에 Apple의 iTunes 기반 서비스를 사용해야 합니다. Kindle Reader 및 일부 구독 기반 앱과 같은 앱은 앱을 통해 액세스할 수 있는 "계정"에 연결된 다른 곳에서 콘텐츠를 구매할 수 있지만, 이 경우 앱에 앱 외부 구매 프로세스에 대한 링크 또는 참조를 포함해서는 안 됩니다(또는 다시 한 번 거부됨).
  • iCloud 백업 – iCloud의 출현과 함께 Apple의 검토자는 앱이 스토리지를 사용하는 방법에 대해 훨씬 더 엄격합니다(고객의 원격 백업 환경이 쾌적하도록 보장). 백업 가능 스토리지 공간을 낭비하는 앱은 거부될 수 있으므로 캐시 폴더를 적절하게 사용하고 Apple의 다른 스토리지 관련 지침을 따릅니다.
  • 뉴스 스탠드 – 신문 및 잡지 애플 리 케이 션은 애플의 뉴스 스탠드에 대 한 좋은 적합, 그러나 애플 리 케이 션 하나 이상의 자동 갱신 구독을 구현 하 고 승인 될 백그라운드 다운로드를 지원 해야 합니다.
  • 지도 – 모바일 맵에 오버레이 및 기타 기능을 추가하는 것이 점점 더 일반적이지만, 맵 '크레딧' 정보(예: iOS5의 Google 로고)를 가리지 않도록 주의해야 합니다.

메타데이터 관리

애플리케이션이 거부될 수 있는 명백한 기술 문제 외에도, 특히 앱 스토어 또는 Marketplace 내에 표시하기 위해 애플리케이션과 함께 제출하는 메타데이터(설명, 키워드(keyword) 및 마케팅 이미지)와 관련하여 거부될 수 있는 제출의 미묘한 측면이 있습니다.

  • 이미지 – 애플리케이션 아이콘에 대한 플랫폼의 지침을 따르고 그림을 저장합니다. 상표 이미지를 사용하지 마세요. 아이콘에 i전화 그림이 표시되어 앱이 거부되는 것을 보았습니다.
  • 상표 – 본인 의 상표가 아닌 다른 상표는 사용하지 않도록 합니다. 앱 설명 또는 Apple App Store의 키워드(keyword) 상표를 멘션 것에 대해 앱이 거부되었습니다.
  • 설명 – 'beta'라는 단어를 사용하지 않거나 앱이 황금 시간대에 사용할 준비가 되지 않았음을 나타냅니다. 앱이 플랫폼 간인 경우에도 다른 모바일 플랫폼을 멘션 마세요. 가장 중요한 것은 앱이 사용자가 말하는 것과 정확히 일치하는지 확인합니다. 설명에 여러 기능을 나열하는 경우 이러한 각 기능을 사용하는 방법을 더 잘 알 수 있거나 "애플리케이션 설명에 멘션 기능이 구현되지 않음" 거부가 표시됩니다.

개발 및 테스트와 마찬가지로 애플리케이션의 메타데이터에 많은 노력을 기울입니다. 애플리케이션은 메타데이터의 사소한 침해에 대해 거부되므로 올바르게 가져오는 데 시간을 할애하는 것이 좋습니다.

앱 스토어: 모든 사용자를 위한 것은 아닙니다.

각 플랫폼에 대한 매장의 주요 초점은 소비자 배포입니다. 가능한 한 많은 고객에게 도달할 수 있는 기능입니다. 그러나 모든 애플리케이션이 소비자를 대상으로 하는 것은 아니지만 직원, 공급업체 또는 고객에게 제한된 배포가 필요한 사내 및 엑스트라넷과 같은 애플리케이션의 기반이 빠르게 증가하고 있습니다. 개발자가 닫힌 사용자 그룹에 배포를 제어하므로 이러한 앱은 "판매용"이 아니며 승인이 필요하지 않습니다. 이러한 유형의 배포에 대한 지원은 플랫폼에 따라 다릅니다.

Android는 다음과 같이 가장 유연하게 사용할 수 있습니다. 애플리케이션은 URL 또는 전자 메일 첨부 파일에서 직접 설치할 수 있습니다(디바이스 구성에서 허용하는 한). 즉, 사내 회사 애플리케이션을 만들고 배포하거나 특정 고객 또는 공급업체에 애플리케이션을 게시하는 것은 간단합니다.

Apple은 iOS 개발자 엔터프라이즈 프로그램에 등록된 개발자에게 사내 배포 옵션을 제공하여 App Store 승인 프로세스를 우회하고 회사에서 사내 앱을 직원에게 배포할 수 있도록 합니다. 아쉽게도 이 라이선스는 다른 폐쇄된 고객 또는 공급업체 그룹에 엑스트라넷과 유사한 앱 배포의 필요성을 해결하지 않습니다. 엔터프라이즈(및 임시) 배포

앱 스토어 요약

검토 프로세스는 어려울 수 있지만 나머지 개발 수명 주기와 마찬가지로 세부 사항에 대한 계획 및 주의로 성공을 보장하는 데 도움이 될 수 있습니다. 이 모든 단계는 준수해야 하는 사용자 인터페이스 지침을 읽고 이해하고, 플랫폼별 기능을 구현하는 경우 규칙을 따르고, 철저히 테스트하고(그런 다음, 좀 더 테스트) 마지막으로 제출하기 전에 애플리케이션 메타데이터가 올바른지 확인하는 몇 가지 간단한 단계로 이루어집니다.

Google Play에 게시하는 개발자에게 조언의 마지막 단어: 승인 프로세스의 부족은 작업을 더 쉽게 만드는 것처럼 보일 수 있지만 고객은 검토 팀보다 훨씬 더 까다로울 것입니다. 앱이 거부될 수 있는 것처럼 다음 지침을 따르세요. 그렇지 않으면 고객이 거부를 수행하는 것입니다.