비즈니스 가치 제공은 Experitest와 모회사의 게임의 이름입니다. Digital.ai. 우리 모두 혁신적인 디지털 경험을 통해 고객 신뢰를 구축하는 데 관심이 있습니다. 전체 조직의 범위는 다음을 기반으로 합니다. 가치 흐름 관리 또는 VSM, 우리가 하는 일 중 하나는 고객들이 완벽한 웹 및 모바일 앱을 제공할 수 있도록 돕는 것입니다. 이를 위해 우리가 하는 일 중 하나는 다음과 같습니다. 성능 시험 제가 이 성능 테스트 체크리스트를 쓴 이유가 바로 이것입니다. 하지만 먼저,

지속적인 테스트 플랫폼 두 가지 주요 목표가 있습니다.

1. 클라우드에서 실제 기기에 대해 수백 개의 수동 또는 자동 테스트를 병렬로 만들고 실행합니다.
2. 자동화 브라우저 간 테스트 1,000개 이상의 브라우저 유형, 버전 및 운영 체제에서 Selenium 테스트를 실행하여

"잠깐만요." 론 포피엘 흉내를 내며 "더 있어요!"라고 소리치는 게 들리는 것 같아요. 네 말이 맞아요. 아무리 테스트를 많이 해도 앱이 기기 메모리나 배터리 전력을 낭비하면 앱 스토어에 등록되는 순간 바로 다운될 테니까요. 그래서 저희가 성능 테스트 체크리스트를 준비했습니다.

성능 테스트란 무엇인가요?

웹 및 모바일 앱 성능 테스트는 주어진 워크로드를 사용하여 앱의 속도, 응답 시간, 신뢰성, 안정성, 그리고 확장성을 테스트하는 과정입니다. 궁극적으로 웹 및 모바일 앱의 성능 병목 현상을 제거하는 것이 목표입니다. 일부에서는 이를 "Perf Testing(성능 테스트)"이라는 속어로 부르는데, 이는 폼 발사체 장난감 총을 테스트하는 것과 혼동해서는 안 됩니다. 이는 Nerf Testing(너프 테스트)이라고 합니다.

성능 테스트는 다음 사항에 중점을 둡니다.

• 속도 – 앱이 얼마나 빨리 반응하는지.
• 안정성 – 앱이 부하 스트레스 하에서 얼마나 안정적인지.
• 확장성 – 문제없이 한 번에 애플리케이션을 로드할 수 있는 최대 사용자 수입니다.

성능이 없다면, 너무 많은 사용자가 접속할 때 웹과 모바일 앱이 느리게 실행되거나, 사용성이 떨어지거나, 여러 OS에서 일관되지 않게 작동하는 등 성능 병목 현상을 제거하기 위한 테스트를 실시하지 못할 것입니다.

다음은 몇 가지 통계입니다. Dun & Bradstreet 성능 테스트의 중요성을 보여주는 사례입니다.

• 포춘 500대 기업들은 매주 약 2시간의 다운타임을 경험합니다. 이는 연간 약 46만 달러에 해당합니다.
• 구글은 2013년에 5분간 서비스가 중단되어 550만 달러의 손실을 입었습니다.
• 최근 AWS 서비스 중단으로 인해 회사들은 초당 최대 1100달러 상당의 매출 손실을 입었습니다.

이 중요한 정보를 바탕으로 성능 테스트 체크리스트를 살펴보겠습니다. 먼저 테스트해야 할 다양한 성능 영역부터 시작하여 각 영역에 대한 예를 살펴보겠습니다.

성능 테스트 유형

부하 테스트 – 비기능적 웹 및 모바일 앱 테스트 앱의 특정 예상 부하 조건에서 성능을 측정하는 테스트입니다. 이러한 유형의 성능 테스트는 여러 사용자가 동시에 웹 또는 모바일 앱에 접속했을 때 앱이 어떻게 동작하는지 파악합니다. 부하 테스트의 목표는 출시 전에 앱 성능 병목 현상을 해소하는 동시에 앱의 안정성과 기능을 향상시키는 것입니다.

• 부하 테스트의 예 – 코로나19 상황으로 인해 수백만 명의 사람들이 항공편을 변경하려고 시도하면서 항공사 앱이 여러 번 다운되는 일이 발생했습니다.

스트레스 테스트 – 부하 테스트의 다음 단계입니다. 예상 부하에서 앱의 성능을 확인하는 대신, 앱의 중단점을 찾을 때까지 부하를 계속 증가시키는 것이 핵심입니다. 앱의 중단점을 찾기 위해 스트레스 테스트를 실시해야 합니다.

• 스트레스 테스트의 예 – 탑승 수용량을 업그레이드하기 위해 노력하는 한 항공사는 앱의 정격 탑승 수용량이 2,000이 아닌 2,500으로 앱을 테스트합니다.

내구성 테스트 – Soak Testing(소크 테스팅)이라고도 하는 내구성 테스트는 웹 또는 모바일 앱이 예상 최대 부하에서 얼마나 오래 작동할 수 있는지 확인합니다. 메모리 누수와 같은 문제를 발견하는 데 도움이 됩니다.

• 내구성 테스트의 예 – 한 회계 회사에 세금 신고를 도와주는 앱이 있습니다. 이 과정에 시간이 많이 걸린다는 것을 알고 있는 회사는 앱이 제대로 작동하는지 확인하기 위해 24~48시간 동안 내구성 테스트를 실시했습니다.

스파이크 테스트 – 급격한 사용자 증가 상황에서 웹 또는 모바일 앱이 어떻게 작동하는지 테스트합니다. 또한, 앱이 이러한 급격한 트래픽 급증에서 어떻게 회복되는지 이해하는 데 도움이 됩니다.

• 스파이크 테스트의 예 – 소셜 미디어 앱은 바이럴 뉴스가 등장하면 엄청난 트래픽 폭발을 경험합니다. 그들은 바이럴 뉴스 경험을 시뮬레이션하기 위해 스파이크 테스트를 사용합니다.

볼륨 테스트 – 이는 웹 또는 모바일 앱 데이터베이스에 대량의 데이터를 추가하여 수행됩니다. 목표는 앱이 다양한 데이터베이스 볼륨에서 어떻게 실행되는지 확인하는 것입니다.

• 볼륨 테스트의 예 – 소매 앱은 새 시즌을 맞아 수백 개의 새 의류 품목을 추가해야 합니다. 모든 정보를 데이터베이스에 입력한 후 성능 테스트를 실행합니다.

성능 테스트로 측정되는 메트릭 유형

이러한 다양한 유형의 성능 테스트를 수행하는 방식은 기기를 모니터링하고 다양한 지표를 측정하여 웹 및 모바일 앱을 개선하는 방법을 보여주는 것입니다. 자세히 살펴보기 전에 간단히 설명해 드리겠습니다.

• 측정 – 앱에서 수집된 모든 데이터.
• 통계 – 측정을 사용하여 결과 품질(평균/전체 응답 시간 등)을 정의합니다.

속도, 안정성, 확장성을 측정하는 방법에 대한 성능 테스트 체크리스트는 다음과 같습니다.

• 평균응답시간 – 요청을 보내고 응답을 받는 데 걸리는 시간.
• 기다리는 시간 – 요청을 보낸 후 바이트 #1을 수신하는 데 걸리는 시간입니다. 평균 지연 시간이라고도 합니다.
• 평균 로드 시간 – 요청을 전달하는 데 걸리는 평균 시간입니다. UX 관점에서 앱 품질을 나타내는 주요 지표입니다.
• 최대 응답 시간 – 요청 처리에 걸리는 최대 시간을 측정합니다. 이 시간이 평균보다 길면 문제가 있을 수 있습니다.
• 오류율 – 오류가 발생한 요청의 비율을 전체 요청 수와 비교하여 이 수치를 계산합니다. 이러한 오류는 일반적으로 부하 용량 초과로 인해 발생합니다.
• 동시 사용자 – 언제든지 활성 사용자의 총 수입니다. 로드 크기라고도 합니다.
• 초당 요청 수 – 처리된 요청 수
• 성공/실패 거래 – 요청이 성공했는지 여부와 관계없이 총 요청 수입니다.
• 맞춤형 설비 – 테스트 중 사용된 대역폭의 양입니다. 초당 KB 단위로 측정됩니다.
• CPU 사용률 – CPU가 요청을 처리하는 데 걸리는 시간.
• 메모리 활용 – 요청을 처리하는 데 필요한 메모리.

웹 및 모바일 앱 성능 테스트 도구

CI 파이프라인의 일부로 성능 테스트를 조기에 지속적으로 구현하는 데 도움이 되는 다양한 도구가 있습니다. 이러한 도구는 탁월한 고객 경험을 제공하는 고품질 소프트웨어를 제공하는 데 도움이 됩니다.

이러한 도구의 수가 늘어나고 각 도구를 구별하는 것이 어려워짐에 따라, 우리는 단순히 도구에만 집중할 것입니다.

SeeTest의 성능 테스트 제공 테스트 자동화 제품군에 모바일 및 웹 성능 테스트를 추가할 수 있습니다. 모바일 및 웹 성능 테스트를 활용하면 성능 문제의 원인을 조기에 파악할 수 있습니다. 이를 통해 사용자가 문제를 발견하기 전에 배포 지연을 방지할 수 있습니다.

당사 도구는 다음을 포함하여 성능 데이터에 대한 심층적인 측정도 제공합니다.

• 거래 기간
• 속도 지수
• CPU 소비
• 메모리 소비
• 배터리 소모
• 네트워크 데이터(업로드 및 다운로드)

이 성능 테스트 체크리스트로 가치를 가져오세요

성능 테스트는 웹 및 모바일 앱이 다양한 상황에서 어떻게 작동하는지 파악하는 데 도움이 됩니다. 물론 100만 명의 사용자가 동시에 실행하더라도 잘 작동할 수 있지만, 10만 명 이상의 사용자가 동시에 실행한다면 어떨까요? 빠르고 안정적이며 확장 가능한 앱 경험을 제공하고자 하는 욕구가 성능 테스트를 주도합니다.

결론적으로, 위에서 앱 성능 테스트가 웹 및 모바일 앱 출시에 어떤 도움을 주는지 살펴보았습니다. 사실 이러한 유형의 테스트는 개발 프로세스 초기에 구현해야 합니다. 버그를 조기에 발견하고, 나아가 시간과 비용을 절약하면서 만족도를 높일 수 있습니다.

조니 슈타이너 - 콘텐츠 관리자