성능 테스트 Digital.ai Continuous Testing

배경

소프트웨어 테스트 분야에서 성능 테스트는 테스트 대상에 따라 다양한 팀과 개인에게 각기 다른 의미를 가질 수 있습니다. 예를 들어, JMeter나 SoapUI와 같은 도구를 사용하는 부하 테스트 및 스트레스 테스트는 여러 사용자가 애플리케이션과 동시에 상호 작용할 때 애플리케이션의 백엔드 서버를 검증하는 성능 테스트와 더 일반적으로 연관됩니다.

그러나 iOS 또는 Android 모바일 웹과 네이티브 애플리케이션에 대한 성능 테스트는 많은 조직이 탐색하지 않은 분야입니다. 그 이유 중 하나는 모바일 기기에 적합한 성능 테스트 솔루션을 제공하는 시장 도구가 거의 없기 때문입니다.

고객 대면 애플리케이션을 운영하는 기업들은 지난 몇 년 동안 모바일 자동화 테스트를 우선시해 왔습니다. 하지만 애플리케이션이 성장함에 따라 중단 없이 최적으로 작동하는 애플리케이션에 대한 고객의 요구도 커지고 있습니다. 예를 들어, 사용자가 앱스토어에서 애플리케이션을 다운로드했는데 로딩 속도 저하나 충돌과 같은 문제가 발생한다고 가정해 보겠습니다. 이 경우, 사용자는 자신의 요구를 충족하는 다른 애플리케이션으로 전환할 가능성이 높습니다.

기존 자동화 스크립트는 애플리케이션의 기능적 측면에만 집중하는 반면, 애플리케이션 성능의 다른 중요한 요소들은 검증하지 못합니다. 예를 들어, 새 페이지로 이동하여 이동하는 데 걸리는 시간, CPU, 메모리, 배터리 사용량 급증, 사용자 흐름 중 발생하는 불필요한 네트워크 호출 등을 검증하지 않습니다. 이러한 문제들은 사용자가 매일 직면하는 과제이지만, 기업들은 모바일 애플리케이션의 이러한 영역 테스트를 강조하지 않습니다.

어떻게 Digital.ai 접근 방식에 대한 도전?

모바일 성능 테스트의 진정한 가치는 다양한 기기 모델과 OS 버전에서 많은 수의 성능 테스트를 실행할 수 있을 때 측정할 수 있습니다.

단일 기기에 대한 성능 테스트는 사용자가 실제로 겪는 상황을 정확하게 반영하지 못할 수 있지만, 추세를 활용하고 다양한 기기 모델과 OS 버전에서 단일 거래가 어떻게 동작하는지 이해하면 더 나은 그림을 얻을 수 있습니다.

하지만 이러한 데이터를 측정하기 위해 모바일에서 성능 테스트를 어떻게 확장할 수 있을까요?

Digital.ai 기능적 Appium 스크립트 내에서 구현할 수 있는 명령을 소개합니다. 즉, 기능적 자동화 스크립트와 성능 테스트를 결합할 수 있다는 뜻입니다.

애플리케이션의 로그인 기능을 테스트하는 시나리오에 대한 간단한 함수형 Appium 스크립트를 살펴보면 테스트가 간단하다는 것을 알 수 있습니다. 먼저 사용자 이름과 비밀번호 필드를 채우고 로그인 버튼을 클릭하여 다음 페이지로 이동합니다.

이 기능적 Appium 스크립트에 성능 테스트를 구현한다면 다음과 같을 것입니다.

스크립트가 로그인 버튼을 클릭하기 전에 성과 거래를 시작하고, 다음 페이지에 도달하자마자 성과 거래를 종료합니다.

사용자 이름과 비밀번호 필드를 채우기 위해 성과 트랜잭션을 캡처하는 것은 자동화 스크립트에서 텍스트를 입력하는 것이 실제로 사용자가 자격 증명을 입력하는 데 걸리는 시간을 정확하게 나타내지 못할 수 있으므로 그다지 중요하지 않습니다.

로그인 페이지에서 다음 페이지로 이동하는 데 걸리는 시간을 측정할 수 있으며, 로그인 버튼을 클릭했을 때 CPU, 메모리 또는 배터리 소모량이 급증하는 경우도 있습니다.

또한 최종 사용자가 다른 네트워크 조건에 있을 때 애플리케이션을 어떻게 경험하는지 확인하기 위해 다른 네트워크 조건을 시뮬레이션할 수 있으며, 네트워크 프로필은 첫 번째 매개변수로 전달됩니다.

driver.executeScript(“seetest:client.startPerformanceTransaction(\”4G-평균\”)”);

우리가 수집하는 지표의 종류와 이를 통해 성과 거래가 어떻게 진행되었는지 이해하는 데 어떻게 도움이 되는지 살펴보겠습니다.

성과 거래의 일부로 어떤 유형의 지표가 수집됩니까?

각 성과 거래에 대해 다음과 같은 측정 항목을 수집합니다.

• 소요 시간 : 시작부터 끝까지 전체 거래 기간
• 속도 지수: 최종 콘텐츠가 얼마나 빨리 그려졌는지에 대한 전체 점수를 계산했습니다.
• CPU : 거래에 사용된 CPU, 평균 및 최대값을 포함하는 그래프
• 메모리 : 거래에 사용된 메모리, 평균 및 최대값을 포함하는 그래프
• 배터리 : 거래에 대한 소모된 배터리, 평균 및 최대값을 나타내는 그래프
• 네트워크 : 네트워크 프로필 적용을 기준으로 트랜잭션 중 업로드/다운로드된 총 KB
• 네트워크 호출: 거래 중에 이루어진 모든 네트워크 호출

우리가 보고 있는 것은 iPhone 13 Pro에서 실행된 단일 성능 트랜잭션입니다. 성능 트랜잭션의 일부로 촬영된 비디오를 재생하면 해당 비디오와 관련하여 CPU, 메모리, 배터리 사용량을 확인할 수 있습니다.

이 보고서는 추세와 잠재적 병목 현상을 이해하는 데 어떻게 도움이 되나요?

방금 살펴본 보고서는 개별 성과 거래에 초점을 맞춥니다. 하지만 이제 여러 기기 모델과 OS 버전에서 동일한 성과 거래를 대규모로 실행했다고 가정해 보겠습니다. 그러면 기본 제공 보고 기능을 활용하여 추세를 살펴볼 수 있습니다.

다음은 특정 빌드와 특정 거래에서 실행한 모든 거래를 표시하도록 필터링된 보고서 예시입니다(예: 네이티브 애플리케이션의 검색 필드에서 항목을 검색하고 소매 애플리케이션의 컨텍스트에서 다음 페이지를 로드하는 데 걸린 시간을 파악).

이 보고서에 따르면 iOS 버전 13.2의 속도 지수가 다른 iOS 버전에 비해 상당히 높았습니다.

마찬가지로 CPU, 메모리, 배터리 등 다른 지표에 대한 추세도 살펴볼 수 있습니다.

이러한 수준의 정보를 통해 QA 테스터와 개발자는 특정 장치 모델과 OS 버전을 조사하여 잠재적인 병목 현상을 파악하고 테스트 중인 모바일 애플리케이션에서 개선이 필요한 영역을 파악할 수 있습니다.

기기나 네트워크마다 성능 차이가 있을 수 있다는 점에 유의해야 합니다. 기기 간 성능 차이가 최대 30%까지 나타나는 것은 흔한 일이며, 이는 반드시 심각한 성능 문제를 나타내는 것은 아닙니다. 그러나 성능 문제는 기준 측정값의 10배에서 100배까지 차이를 초래할 수 있습니다.

기존의 기능적 자동화 스크립트에 성능 테스트를 구현해야 합니까?

기존 기능 스크립트에 성능 테스트를 구현하는 것이 합리적인지, 아니면 성능 테스트를 위한 새로운 독립형 스크립트를 만드는 것이 합리적인지는 현재 자동화 프레임워크의 유연성과 복잡성에 따라 달라집니다.

앞서 제시한 예시에서는 코드가 지나치게 단순화되어 있습니다. 하지만 기존 자동화 프레임워크의 맥락에서 동일한 접근 방식을 생각해 보겠습니다. 클릭이나 키 전송과 같은 작업을 수행하기 위해 메서드를 호출할 때 훨씬 더 많은 종속성과 계층이 관련될 수 있습니다.

예를 살펴 보겠습니다.

기존 자동화 프레임워크에 더 많은 논리를 추가하면 자동화된 스크립트를 실행하는 데 필요한 전체 시간이 늘어날 수 있으며, 이는 성능 테스트에 부정적인 영향을 미치고 귀중한 측정 항목을 제공하지 못할 수 있습니다.

기존 자동화 프레임워크의 복잡성으로 인해 성능 테스트가 어려운 경우, 성능 지표를 수집하기 위한 별도의 자동화 스크립트를 작성하는 것이 좋습니다.

이를 통해 코드 논리를 어느 정도 단순화하여 성능 테스트에 적합한 지표를 정확하게 파악할 수 있습니다.

수집된 데이터가 측정 가능한지 확인하려면 어떤 유형의 벤치마크 숫자를 설정해야 합니까?

각 조직과 팀이 자체 애플리케이션의 사용자 경험을 정의하기 때문에 성능 측정에 적용할 수 있는 보편적이거나 표준화된 지표는 없습니다. 또한, 애플리케이션의 복잡성에 따라 벤치마크 수치는 페이지 또는 애플리케이션마다 다를 수 있습니다.

사용할 수 있는 지표의 예로는 TTI(상호작용 시간)가 있는데, 이는 사용자가 애플리케이션을 실행한 후 사용 가능해질 때까지 걸리는 시간을 측정합니다.

이에 대한 연구가 진행되었으며, HCI(인간-컴퓨터 상호작용) 연구에 기반한 몇 가지 유용한 경험 법칙은 다음과 같습니다.

• 500ms가 넘는 지연은 "인지적" 이벤트가 되며, 이는 사용자가 시간이 지났음을 안다는 것을 의미합니다.
• 3초가 넘는 지연은 "반성적" 이벤트가 되어, 사용자가 시간이 흘렀다는 사실을 되돌아볼 시간을 갖게 됩니다. 사용자는 주의가 산만해지거나 다른 일을 하기로 선택할 수 있습니다.

하지만 다음과 같은 다른 지표도 주요 성과 지표로 간주됩니다.

• 가장 빠른 응답 시간
• 평균 응답 시간
• 최대 요청 수

서버의 응답 시간이 느리면 사용자 경험이 저하될 수 있습니다. Google PageSpeed ​​Insights에서는 200ms 미만의 서버 응답 시간을 권장합니다. 300~500ms 범위가 표준으로 간주되며, 500ms를 초과하는 응답 시간은 허용 가능한 기준에 미치지 못합니다.

이러한 지표에 대한 만능 답은 없으며, 기준선을 정하는 것은 상황에 따라 다를 수 있다는 점에 유의해야 합니다. 따라서 테스트 중인 애플리케이션의 맥락에서 허용되는 수준을 파악하는 것이 중요합니다. 여기에는 애플리케이션 개발자와 협력하여 특정 사용자 흐름 중 발생하는 네트워크 호출 수, 특정 애플리케이션 구성 요소와 상호 작용할 때 백엔드에서 발생하는 과중한 작업, 기타 관련 요소 등 애플리케이션 백엔드에 대한 통찰력을 얻는 것이 포함될 수 있습니다.

또한, 몇 가지 성능 테스트를 실행하여 기준선으로 사용하는 것도 도움이 될 수 있습니다.

사용 가능한 모든 장치 조합에 대해 성능 테스트를 실행해야 합니까?

성능 테스트를 위해 어떤 기기를 테스트할지 결정할 때는 가장 많은 수익을 창출하는 기기를 고려하는 것이 중요합니다. 이를 위해서는 사용자 기반과 테스트 대상 애플리케이션에 가장 자주 사용되는 기기 유형을 명확하게 이해해야 합니다.

그런 다음, 지속적으로 테스트할 상위 5~10개 기기를 선택하는 것이 좋습니다(정확한 기기 수는 프로젝트 규모와 사용자 기반에 따라 달라질 수 있음). 이러한 접근 방식은 테스트 대상 기기의 기준을 확립하는 데 도움이 되며, 이를 통해 더욱 정확한 성능 측정이 가능합니다.

제품 개요

성능 테스트는 소프트웨어, 애플리케이션 및 시스템이 예상 부하와 트래픽을 처리할 수 있는지 확인하는 데 매우 중요합니다. 배포 전에 성능 병목 현상과 잠재적 장애를 파악하고 해결하여 최종 사용자에게 원활한 경험을 보장합니다.

기존 자동화 스크립트와 달리, 성능 테스트는 사용자가 페이지 간을 탐색하는 데 걸리는 시간을 측정하고, CPU, 메모리, 배터리 소비의 급증을 식별하고, 불필요한 네트워크 호출을 정확히 찾아내는 것을 목표로 합니다.

성능 테스트의 가치는 개발 프로세스 초기에 문제를 식별하여 나중에 문제 해결에 드는 비용을 절감할 수 있다는 것입니다. 또한, 시간 경과에 따라 모니터링하고 비교할 수 있는 성능 지표의 기준을 설정하여 시스템 변경이 성능에 미치는 영향에 대한 통찰력을 제공합니다. 성능 테스트는 개발부터 배포, 그리고 그 이후까지 모든 소프트웨어 개발 주기에 필수적입니다.

 

모바일 성능 테스트를 시작할 준비가 되셨나요? 지금 바로 문의하세요. https://digital.ai/why-digital-ai/contact/