Approach to load testing iOS app (stackoverflow 질문글 한국어 해석)

https://stackoverflow.com/questions/34934322/approach-to-load-testing-ios-app

Approach to load testing iOS app

 

원문은 위에서 볼 수 있습니다. (문제시 삭제)

 

Question

"나는 이에 대해 검색을 해봤지만 일치하는 것을 찾지 못했습니다. 아마도 '로드 테스팅'이라는 문구의 여러 의미 때문일 것입니다... 우리가 하고자 하는 것은 우리의 앱(시기적절하게 업데이트된 데이터를 MUST 표시해야 하는 의료 기기)이 아이폰이 바쁠 때에도 요구되는 처리량으로 데이터를 처리할 수 있는지 확인하는 것입니다 - 예를 들어, CPU 주의가 필요한 여러 앱들이 열려 있는 상황에서 말입니다. 우리가 생각해낸 최선의 테스트 접근법은 기본적으로 이렇습니다... 여러 앱을 열고, 아마도 대용량 첨부 파일이 있는 이메일을 여러 개 보내 CPU에 부하를 걸어보는 것입니다. 하지만 분명히 이는 위험에 대한 단순한 추측일 뿐입니다. 더 나은 기술이나 도구가 있을까요? 도움에 감사드립니다.

• 1 음, 그건 다소 무서운 질문이네요. 여기서 여러분이 실시간이 아닌 범용 운영 체제에서 앱을 개발하고 있다는 점에서 "MUST"라는 단어를 매우 관대하게 정의하고 있기를 바랍니다. 운영 체제는 CPU 시간과 다른 자원을 제공하기 위해 최선을 다할 수 있지만, 보장은 없으며 자원 경합이나 스레드 기아 위험은 항상 존재합니다. 데이터 획득이나 렌더링의 지연이 누군가의 건강에 실제 위험을 초래할 것이라면 멈추고 접근 방식을 재고하시기 바랍니다. - Jonah, 2016년 1월 21일 오후 9시 25분 코멘트
• 아이폰으로 구동되는 의료용 온도계에서 일한 경험이 있습니다. FDA 승인을 받기 위해 따라야 할 가이드라인과 테스트 계획이 있습니다. 전화, 운영 체제, 그리고 장치의 조합이 의료 기기로 간주되었습니다. 정말 무섭고도 흥미로웠습니다. - Jess, 2016년 1월 21일 오후 9시 44분 코멘트
• 1 그렇습니다. "MUST"는 소프트웨어 개발에서 매우 무서운 단어입니다. 특히 데이터 전송이나 앱 안정성에 대해 이야기할 때 그렇습니다. 규제 품질 관리를 담당하는 사람에게 품질 관리 계획과 테스트 케이스를 실행해볼 것을 제안합니다. 전통적인 의료 기기처럼 언제든 앱이 종료될 수 있다는 것을 이해해야 합니다. 비정상적인 이유로 폭발할 수도 있죠. 최악의 시나리오에 대한 지식을 준비하세요. (모든 것이 잘 되면 제 답변을 테스트 계획 접근 방식을 안내하는 데 자유롭게 사용하세요) - Jess, 2016년 1월 21일 오후 9시 49분 코멘트
• "MUST" = 시기적절하거나 또는 대기 시간을 스스로 진단하고, 사용자에게 문제가 있음을 알리는 메시지를 제시해야 합니다. 우리는 애플리케이션 수준의 타임스탬프와 타임스탬프 검사를 사용하여 이를 처리합니다. iOS(또는 체인의 다른 링크)의 어떤 바쁜 상태든 플래그가 지정되며 사용자는 아날로그 시스템으로 대체됩니다. 이는 모두 FDA 규정과 IEC-62304에 따라 철저히 위험 분석되었습니다. - Chris, 2016년 1월 24일 오후 6시 15분 코멘트
• 지금 우리가 하고 있는 것은 이러한 자가 진단 기능을 가능한 한 현실적으로 테스트하는 것입니다. iPad에 바쁨을 만들어 해당 기능을 작동시킬 수 있는지 확인하려고 합니다. 제 질문은 어떻게 iOS에 바쁨을 만들 수 있는지에 대한 것입니다. - Chris, 2016년 1월 24일 오후 6시 19분 코멘트"

 

Answer

앱 개발 관점에서, 여러분은 다음 사항들을 해결하는 데 집중해야 합니다:

* "*데이터가 전송되지 않으면 어떻게 되나요?*"
* "*iOS가 어떤 이유로든 앱을 종료하면 어떻게 되나요?*"

나쁜 상황을 유발할 시나리오를 만드는 방법은 수없이 많습니다. 일반적인 실패에 대비되어 있다는 것을 아는 것이 가장 안전한 의존점입니다.

기존 앱의 검증 관점에서:

과거에 앱 개발을 통제할 수 없었던 시나리오에서, 저는 물리적 기기로 수동 탐색 테스트를 통해 이러한 시나리오들을 테스트했습니다.
요즘에는 **아이폰 시뮬레이터가 많은 유틸리티를 제공하므로 모든 것을 수동으로 할 필요가 없을 수 있습니다.** 답변을 보려면 아래로 스크롤하세요.

 

기기가 데이터를 안정적으로 전송하지 못할 때 테스트하기

* **비기술적인 방법:** 3G와 비행기 모드를 사용하고 앱을 사용하는 동안 연결성을 자주 전환합니다.
* **좀 더 기술적인 방법:** 컴퓨터를 통해 프록시하도록 전화기를 설정합니다. 연결 속도를 제한합니다. Charles가 이를 수행합니다.

연결 속도를 제한하는 동안 백엔드와 통신하는 모든 트랜잭션에 앱을 사용합니다.
Wi-Fi나 더 안정적인 무선 연결로 다시 연결했을 때 올바르게 전송되나요?

CPU가 과부하될 때 테스트하기

* 가장 높은 대상 OS를 지원하는 가장 오래된 전화기를 가져옵니다 (예: iOS 9의 iPhone 4S).
* 백그라운드에서 몇 개의 게임을 엽니다.
* 약 30분 동안 적극적으로 앱을 사용합니다.
   * 적극적으로란, 모든 버튼에 5번 탭하고 화면의 다른 곳에도 탭하여 느려지기 시작할 때까지 인내심 없는 사용자인 척 합니다.
* 느려지는 영역을 악용합니다.
주요 포인트는: 애니메이션, 동영상, 백엔드로 데이터를 보내는 작업, 테이블 뷰, 컬렉션 뷰 등입니다.
* 앱이 충돌할 때 무슨 일이 일어나는지 확인합니다.
   * 로그아웃되었나요?
   * 중요한 데이터가 잘못되거나 손실되었나요?

시뮬레이터 사용에 관하여

시뮬레이터 사용에 대한 참고사항입니다.
시뮬레이터는 메모리 경고를 시뮬레이션하고 Charles로 연결을 제한하거나 강제로 재부팅할 수 있는 편리한 방법입니다. 하지만 물리적 기기에서 테스트한 것만큼 CPU를 제한할 수는 없습니다.

 

 

느낀점

꽤 오래전 글인데도 생각할 부분이 많았습니다. 단순하게 loadTesting에 관한 정보를 갖기 위해서 구글링을 했지만, 테스트가 갖는 본질의 목적에 대해서 생각할 수 있게 되었습니다. 특히 어플리케이션이 동작이 메디컬 이슈에 영향을 미친다면, 다른 방법을 고안하라는 것에 대해서 충격받았습니다. 이는 맹신하는 어플리케이션에 종속된 프레임워크나 라이브러리에 해당할 수 있습니다. 어쩌면 어플리케이션도 문제 해결의 근원이 아닐 수 있다는 생각이 들었습니다. 

 

부하테스트에 관해서 실기기로 테스트하는것이 중요하다고 느꼈습니다. Simulator 보다 실기기로 비슷한 상황을 재현하면서 문제 상황에 좀 더 가까워질 필요를 느꼈습니다.