모바일 애플리케이션의 인터럽트 테스트

⚡ 스마트 요약

인터럽트 테스트는 통화, 알람, 알림 또는 네트워크 끊김과 같은 상황 발생 시 모바일 애플리케이션이 어떻게 동작하는지, 그리고 중단이 종료된 후 애플리케이션이 이전 상태로 정확히 복귀하는지 여부를 확인합니다.

🔘 범위: 이 기법은 모바일 애플리케이션 테스트에 속하지만 웹 및 독립형 소프트웨어에도 적용할 수 있습니다.
☑️ 중단 원인: 수신 전화, 문자 메시지, 알람, 배터리 부족, 충전 이벤트, 앱 업데이트 및 네트워크 변경 사항은 대부분의 실제 시나리오를 포괄합니다.
✅ 예상되는 네 가지 결과: 백그라운드에서 실행, 알림 표시, 행동 유도 메시지 표시 또는 영향 없음 - 어떤 옵션을 적용할지는 각 애플리케이션에 따라 다릅니다.
🧪 테스트 설계: 인터럽트 테스트는 기능 테스트의 하위 범주이므로 동일한 프레임워크, 테스트 케이스 및 실행 프로세스가 적용됩니다.
🛠️ 시뮬레이션: 에뮬레이터의 확장된 제어 기능, 장치 설정 및 실제 장치 클라우드를 통해 필요에 따라 통화, 알림 및 연결 끊김 현상을 재현할 수 있습니다.
📊 복구 테스트가 아닙니다. 복구 테스트는 장애 발생 후 복구를 검증하는 반면, 중단은 단지 일시적인 오류일 뿐입니다.trac결함이 아니라 문제입니다.

인터럽트 테스트란 무엇입니까?

인터럽트 테스트 모바일 애플리케이션 테스트의 한 분야로, 애플리케이션이 외부 요인(운영 체제, 하드웨어 또는 다른 앱)에 의해 중단되었을 때 어떻게 반응하고 이전 상태로 복귀하는지를 검증합니다. 이 테스트는 제어가 복귀될 때 데이터, 화면 상태 또는 진행 중인 트랜잭션이 손실되지 않는지 확인합니다.

인터럽트 테스트는 웹, 모바일, 독립형 애플리케이션 등 모든 유형의 애플리케이션에 적용됩니다. 다양한 장치, 네트워크 및 구성으로 인해 인터럽트 테스트의 중요성이 더욱 커지고 있습니다. 변하기 쉬운 다른 분야보다 활용도가 더 높습니다.

인터럽트 테스트가 필요한 이유는 무엇입니까?

회의 중에 거의 항상 일어나는 한 가지는 무엇일까요? 바로 방해받는 것이죠. 어떤 사람들은 눈 하나 깜빡하지 않고 넘어가지만, 어떤 사람들은 잠시 생각에 잠기기도 하고, 또 어떤 사람들은 아예 말을 끊어버리기도 합니다. 간단히 말해, 인터럽트 테스트는 애플리케이션이 이러한 행동 패턴을 보이는지 파악하는 것입니다.

잠시 모든 표현을 제쳐두고 실제 상황을 생각해 보세요. 예를 들어 손전등을 켰다고 가정해 봅시다. 배터리가 방전되면 손전등의 현재 작동 상태가 중단됩니다. 배터리를 교체하고 다시 작동시키면 손전등은 정상적으로 켜져야 합니다. 이것이 바로 사용 사례입니다. 이러한 상황이 발생하는지 여부에 초점을 맞춘 테스트 분야를 인터럽트 테스트라고 합니다.

비즈니스 사례는 간단합니다. 중단은 최악의 순간, 즉 결제 중, 업로드 중, 양식 작성 중에 발생하며, 작업 내용을 잃어버린 사용자는 다시 시도할 가능성이 거의 없습니다. 재개 시 충돌, 빈 화면, 중복 거래, 양식 입력 손실은 모두 중단 상황에서만 드러나는 결함이므로, 중단이 전혀 발생하지 않는 일반적인 테스트에서는 이러한 결함이 그대로 남아 있는 것입니다.

모바일 애플리케이션의 중단 유형

방해 요소는 아래 그림에 요약된 것처럼 몇 가지 익숙한 유형으로 분류됩니다.

우리는 모두 일상에서 흔히 발생하는 방해 요소들을 잘 알고 있습니다. 몇 가지 예를 들면 다음과 같습니다.

배터리 부족
배터리 완충 - 충전 중
수신 전화
수신 SMS
다른 모바일 애플리케이션에서 수신된 알림
충전을 위해 연결됨
충전 중 플러그가 뽑혔습니다.
장치가 꺼졌습니다
애플리케이션 업데이트 알림
경보
네트워크 연결 끊김
네트워크 연결 복원

이 목록은 모든 경우를 포함하는 것은 아니지만 가장 일반적인 시나리오를 담고 있습니다. 실용적인 분류 방법은 발생 원인별로 나누는 것입니다. 즉, 배터리 및 충전과 같은 기기 관련 이벤트, 통화 수신이나 앱 전환과 같은 사용자 주도 이벤트, 그리고 엘리베이터나 터널에서 신호 끊김과 같은 외부 이벤트로 구분할 수 있습니다.

인터럽트 발생 시 해결 방법

이러한 중단이 발생할 경우 예상되는 동작은 다음 네 가지 중 하나입니다.

백그라운드에서 실행: 방해 요소가 발생하면 애플리케이션이 잠시 제어권을 잃고, 방해 요소가 끝나면 다시 제어권을 되찾습니다. 예를 들어, iBooks(또는 유사한 애플리케이션)에서 디지털 책을 읽는 도중에 전화나 FaceTime 통화를 받는 경우를 생각해 보세요. 사용자가 전화를 받으면 iBooks는 통화가 끝날 때까지 기다렸다가 통화가 종료되면 다시 읽기를 재개합니다.
알림 표시: 알림은 사라지고 사용자는 평소처럼 작업을 계속합니다. 헤더에는 "SMS 수신됨" 메시지가 표시됩니다. 사용자는 이 메시지를 무시하고 평소처럼 애플리케이션을 사용합니다. 페이스북 친구 요청이나 WhatsApp 메시지와 같은 다른 모바일 앱 알림도 이와 같은 범주에 속합니다. 하지만 사용자가 메시지를 읽기로 결정하면 1번 항목에서 설명한 동작이 적용됩니다. 알림을 무시하면 애플리케이션 상태는 변경되지 않습니다.
행동을 요구하다: 알람은 작업을 계속하기 전에 끄거나 다시 울림 기능을 해제해야 합니다. 앱 업데이트 메시지도 마찬가지입니다. 작업을 진행하기 전에 변경 사항을 취소하거나 수락해야 합니다. 또 다른 예로 배터리 부족 알림이 있습니다. 평소처럼 작업을 계속할지, 아니면 기기에서 지원하는 경우 저전력 모드로 전환할지 선택할 수 있습니다.
영향 없음: 예를 들어 네트워크 연결이 가능해지면 기기가 해당 네트워크에 연결됩니다. 또한 기기를 충전기에 연결할 때에도 알림이나 별도의 조치가 필요하지 않습니다. 사용자가 애플리케이션을 계속 사용하는 동안에도 기기가 자동으로 충전을 진행할 것입니다.

따라서 테스트하려는 중단 유형에 따라 동작 방식을 이해하고 애플리케이션이 해당 요구 사항을 충족하는지 확인해야 합니다. 또한 위에서 설명한 동작 방식은 모든 애플리케이션과 기기에서 동일하지 않을 수 있으므로 모바일 앱에 대한 구체적인 세부 정보를 반드시 확인해야 합니다.

인터럽트 테스트 테스트 케이스 및 예상 결과

예상되는 해결 방안이 합의되면, 각 중단 상황은 트리거, 동작 및 검증 가능한 결과를 갖춘 일반적인 테스트 케이스가 됩니다. 아래 표는 위의 네 가지 해결 방안이 구체적인 시나리오로 어떻게 구현되는지 보여줍니다.

중단	테스트 시나리오	예상 결과
수신 전화	양식 작성이 절반 정도 완료된 상태에서 전화를 걸고, 전화를 받은 후 통화를 종료합니다.	애플리케이션이 백그라운드로 전환되었다가 입력된 데이터를 그대로 유지한 채 동일한 화면에서 다시 시작됩니다.
수신 SMS 또는 푸시 알림	동영상 업로드 또는 재생 중에 메시지를 보내고 배너는 무시하세요.	배너가 나타났다가 사라지지만 애플리케이션 상태는 변경되지 않습니다.
경보	활성 세션 중에 예약된 알람이 발생하도록 하고, 발생한 알람은 해제합니다.	알람은 먼저 조치를 취하라는 신호를 보낸 후, 애플리케이션이 중단된 부분부터 다시 시작합니다.
배터리 부족 경고	거래 중에 기기의 배터리 잔량이 경고 임계값까지 떨어지도록 하십시오.	경고 메시지가 표시되지만 거래는 취소되지 않으며, 저전력 모드가 화면을 꺼뜨리지도 않습니다.
네트워크 연결 끊김	요청 도중에 연결을 비활성화한 다음 다시 복원합니다.	명확한 메시지가 표시되고, 충돌이 발생하지 않으며, 복원 시 요청이 안전하게 완료되거나 실패합니다.
충전기가 꽂혀있든 꽂혀있지 않든	사용 중인 기기에 충전기를 연결하거나 분리하세요.	영향 없음 — 애플리케이션은 눈에 띄는 변화 없이 계속 작동합니다.
애플리케이션 업데이트 알림	애플리케이션 사용 중에 업데이트 알림을 표시합니다.	사용자는 취소하거나 수락할 수 있으며, 어떤 선택을 하든 기본 화면은 그대로 유지됩니다.

전체 애플리케이션에 대해 중단 횟수별로 한 행씩 유지하는 대신, 중요한 화면별로 중단 횟수별로 한 행씩 유지하세요. 결제 화면, 로그인 화면, 긴 양식 작성 화면은 각각 다른 방식으로 오류가 발생하는데, 하나의 일반적인 사례로 처리하면 이러한 차이를 숨길 수 있습니다.

이제 인터럽트 테스트가 무엇인지, 이를 수행할 때 무엇을 검증해야 하는지 이해했으므로 이를 수행하는 방법에 대해 이야기할 차례입니다.

인터럽트 테스트를 수행하는 방법

다음 설명을 보십시오. 사용자가 전화를 받을 때 iBooks는 백그라운드에서 실행되어야 합니다.

이것이 iBooks 앱의 기능적 요구 사항이라고 생각하지 않으세요? 저는 그렇게 생각합니다.

따라서 인터럽트 테스트는 다음의 하위 집합입니다. 기능 테스트 모바일 애플리케이션의 경우, 인터럽트 테스트를 수행할 때에도 일반적인 모바일 애플리케이션 테스트 프레임워크와 도구를 그대로 사용합니다. 이러한 시나리오를 구상하는 것은 테스터의 역량에 달려 있습니다. 시나리오 구상이 완료되면 테스트 케이스를 설계하고 다른 테스트와 동일한 방식으로 실행합니다.

실제로 그 과정은 짧고 반복 가능합니다.

로그인, 결제, 업로드, 긴 양식 작성, 미디어 재생 등 핵심 사용자 여정을 나열하세요.
위 목록에 있는 발생 가능한 모든 방해 요소를 각 여정에 반영하십시오.
보편적인 기본값이 없으므로 각 페어링에 대한 예상 해결 방법을 제품 소유자와 합의해야 합니다.
가장 위험한 순간에 중단을 실행하고, 한가한 순간에 실행하지 말고, 그 후에 다시 작업을 재개하십시오.
애플리케이션이 여전히 열려 있는지 여부뿐만 아니라, 재개 후 상태, 데이터, 세션 및 메모리 상태를 확인해야 합니다.

이 분야에 대한 더 자세한 정보는 다음을 참조하십시오. 모바일 테스트 튜토리얼 및 예제 사례 모바일 앱 테스트.

중단 상황을 시뮬레이션하는 도구 및 기술

위의 시나리오들은 기다리는 것이 아니라 필요에 따라 즉시 생성되어야 하며, 각 플랫폼은 이를 위한 방법을 제공합니다.

Android 에뮬레이터 확장 제어: 에뮬레이터 측면 패널은 수신 전화, SMS, 배터리 잔량 및 충전기 상태, 셀룰러 신호 강도를 시뮬레이션하므로 대부분의 알림 목록을 두 번째 휴대폰 없이도 확인할 수 있습니다.
iOS 시뮬레이터 및 Xcode: 시뮬레이터와 장치 설정에서 연결 상태 및 하드웨어 상태를 다양하게 변경할 수 있으며, 실제 장치와의 페어링을 통해 시뮬레이터에서 발생시킬 수 없는 통화 시나리오를 구현할 수 있습니다.
두 번째 물리적 장치: 다른 단말기로 테스트 대상 기기에 전화를 걸거나 문자를 보내는 것이 특히 시간에 민감한 경우 실제 장애를 재현하는 가장 정확한 방법입니다.
기기 설정: 비행기 모드, Wi-Fi 켜기/끄기, 방해 금지 모드, 배터리 절약 모드 및 예약 알람은 실제 하드웨어에서 연결 및 전원 중단 문제를 해결합니다.
자동화 프레임워크: 나머지 기능 제품군에 사용되는 동일한 자동화 스택을 사용하여 중단 전후의 애플리케이션을 구동할 수 있으므로 재개 확인은 육안 검사가 아닌 검증을 통해 이루어집니다.
실제 기기 클라우드: 호스팅된 디바이스 팜은 다양한 제조업체와 OS 버전을 아우르는 폭넓은 지원 범위를 제공하는데, 이는 공급업체별 맞춤 설정이 가장 크게 차이가 나는 영역 중 하나가 장애 처리이기 때문에 중요합니다.

어떤 메커니즘이든 테스트 케이스에서 중단이 발생한 정확한 순간을 기록하십시오. "업로드 중 중단"과 "업로드 후 중단"은 서로 다른 테스트이며, 실패 모드도 다릅니다.

인터럽트 테스트를 위한 최고의 사례

유용한 인터럽트 모음과 형식적인 절차만 거치는 것을 구분 짓는 몇 가지 습관이 있습니다.

가장 부적절한 순간에 방해하다: Target 거래가 확정되거나 파일이 기록되는 순간이 가장 중요한데, 바로 그 순간이 상태 정보가 가장 취약하기 때문입니다.
방해 요소가 아닌 이력서를 테스트하세요. 이 결함은 거의 항상 제어권이 돌아온 후에 나타나므로, 어설션은 복원된 화면에 포함되어야 합니다.
네트워크 변경의 양방향을 모두 다루십시오. 연결이 끊어지는 것과 다시 연결되는 것은 별개의 경우이며, 두 번째 경우는 건너뛰는 경우가 더 많습니다.
지속 시간을 다양하게 해보세요: 2초짜리 알림과 10분짜리 통화는 애플리케이션이 메모리에서 제거되는 것을 포함하여 서로 다른 수명 주기 경로를 거치게 합니다.
다양한 운영체제 버전과 저사양 하드웨어에 걸쳐 분포되어 있습니다. 백그라운드 앱 강제 종료는 성능이 제한된 기기에서 훨씬 더 적극적으로 작동하여 플래그십 스마트폰에는 숨겨져 있던 결함을 드러냅니다.
반복적인 작업은 자동화하세요: 연결 끊김 및 배터리 방전은 자동으로 원활하게 처리되어 통화 및 경보 상황에 필요한 수동 작업을 줄일 수 있습니다.
자원 사용량과 상태를 모두 모니터링하세요: 화면은 정상적으로 보이더라도, 재개 시 메모리 누수나 배터리 소모를 유발하는 중단은 결함이며, 이는 본 연구와 관련이 있습니다. 모바일 앱 성능 테스트.

인터럽트 테스트는 복구 테스트와 동일하지 않습니까?

전혀 그렇지 않다. 복구 테스트 장애 복구의 유효성을 검증합니다. 중단이 반드시 장애를 의미하는 것은 아닙니다. 단지 일시적인 중단일 뿐입니다.trac기.

영어에서 쉼표와 마침표의 차이와 같습니다. 그 차이는 단지 기술적인 차이일 뿐이지만, 그 의미는 명확합니다. 복구 테스트는 애플리케이션에 문제가 발생한 후 정상적으로 작동할 수 있는지 여부를 확인하는 것이고, 중단 테스트는 다른 프로세스가 포그라운드로 전환될 때 애플리케이션에 문제가 발생하지 않는지 여부를 확인하는 것입니다.

이것이 바로 모바일 애플리케이션 테스트의 중요하고 직관적인 분야인 인터럽트 테스트를 시작하는 데 필요한 핵심 사항입니다.

자주 묻는 질문

시나리오는 같지만 결과는 다릅니다. 두 플랫폼은 백그라운드 앱과 메모리 제거를 관리하는 방식이 다르기 때문입니다. Android 제조사별 사용자 인터페이스(UI)는 자체적인 배터리 규칙을 추가하므로, 동일한 테스트라도 기기 제품군에 따라 통과하거나 실패할 수 있습니다.

AI 모델은 사용자 스토리와 크래시 보고서를 분석하여 테스터가 미처 고려하지 않았을 수 있는 중단 상황 조합을 제안합니다. 예를 들어, 토큰 갱신 중에 정확히 통화가 발생하는 경우를 예측할 수 있습니다. 또한 머신 러닝은 실제 운영 환경의 크래시 로그를 클러스터링하여 어떤 중단 상황이 실제 사용자에게 먼저 문제를 일으키는지 보여줍니다.

Copilot은 앱을 백그라운드로 전환하고, 연결을 전환하고, 대기한 다음, 복원된 화면을 확인하는 등의 기본 스크립트를 잘 작성합니다. 하지만 언제 중단해야 하고 어떤 상태를 유지해야 하는지는 테스터의 판단에 달려 있으므로, 생성된 스크립트는 검토를 위한 시작 초안으로 활용하세요.

네. 두 명칭은 동일한 활동을 나타내며 팀과 도구 전반에 걸쳐 혼용되어 사용됩니다. 테스트 계획에는 한 가지 철자만 선택하여 일관되게 사용하세요. 용어가 혼용되면 테스트 스위트를 검색하기 어렵고 중복된 테스트 케이스가 생성될 가능성이 높아집니다.

둘 다 사용하세요. 에뮬레이터는 파이프라인에서 빠르고 반복 가능한 연결 및 배터리 문제를 해결하는 데 이상적입니다. 실제 기기는 실제 통화, 공급업체 배터리 관리 및 메모리 부족 시 연결 해제에 필요하며, 이러한 조건들이 바로 연결 재개 관련 결함을 가장 명확하게 드러내는 환경입니다.

재개 시 충돌, 복귀 후 빈 화면 또는 잘못된 화면 표시, 양식 입력 내용 손실, 재시도 요청으로 인한 중복 결제, 새 로그인이 필요한 세션 끊김, 미디어 재생 중단, 그리고 애플리케이션이 반복적으로 백그라운드에서 실행된 후에만 발생하는 메모리 또는 배터리 누수 문제 등이 있습니다.

둘 다 맞습니다. 네트워크, 배터리 및 앱 전환 중단 스크립트는 안정적으로 작동하며 회귀 테스트 실행에 포함되어야 합니다. 수신 전화, 알람 및 공급업체별 전원 알림은 실제 단말기에서 수동으로 테스트하는 것이 일반적으로 더 빠르므로 대부분의 팀은 수동 테스트 세트를 함께 사용합니다.

핵심 기능 개발이 완료되는 즉시 재개를 시작하세요. 최종 안정화 주간에 시작하는 것보다 훨씬 효율적입니다. 재개 관련 결함은 종종 라이프사이클이나 상태 관리 변경을 필요로 하는데, 릴리스 후보 버전이 확정된 후에는 이러한 변경 사항을 소급 적용하는 데 많은 비용이 소요됩니다.