mobile app testing tutorials
심층 자습서를 통해 모바일 애플리케이션을 테스트하기위한 완전한 가이드 :
모바일 기술과 스마트 기기는 현재 트렌드이며 우리가 알고있는 세상의 미래를 바꿀 것입니다. 우리 모두는 그렇지 않나요? 이제 우리가 이러한 모바일 장치를 사용하는 용도를 나열하면 아마추어가 될 것입니다. 여러분 모두 알고 있습니다 – 아마도 우리보다 더 좋을 것입니다.
이 튜토리얼의 내용을 곧바로 살펴 보겠습니다.
30 개 이상의 모바일 테스트 자습서 전체 목록 :
모바일 테스트 소개 :
튜토리얼 # 1 : 모바일 테스트 소개
튜토리얼 # 2 : iOS 앱 테스트
튜토리얼 # 3 : Android 앱 테스트
튜토리얼 # 4 : 모바일 테스트 과제 및 솔루션
튜토리얼 # 5 : 모바일 테스트가 힘든 이유는 무엇입니까?
모바일 장치 테스트 :
튜토리얼 # 6 : 출시 된 Android 버전 테스트
튜토리얼 # 7 : 저가형 장치에서 모바일 앱을 테스트하는 방법
튜토리얼 # 8 : 모바일 애플리케이션을위한 현장 테스트
튜토리얼 # 9 : 전화 모델 대 OS 버전 : 먼저 테스트해야하는 것은 무엇입니까?
모바일 UI 테스트 :
튜토리얼 # 10 : 모바일 앱의 UI 테스트
튜토리얼 # 11 : 모바일 반응 형 테스트
모바일 테스트 서비스 :
튜토리얼 # 12 : 클라우드 기반 모바일 애플리케이션 테스트
튜토리얼 # 13 : 모바일 테스트 서비스
튜토리얼 # 14 : 모바일 앱 베타 테스트 서비스
튜토리얼 # 15 : 모바일 앱 개발 회사
튜토리얼 # 16 : 클라우드 기반 모바일 앱 테스트 서비스 제공 업체
모바일 앱 성능 및 보안 테스트 :
튜토리얼 # 17 : BlazeMeter를 사용한 모바일 애플리케이션 성능 테스트
튜토리얼 # 18 : 모바일 앱 보안 테스트 지침
모바일 테스트 도구 :
튜토리얼 # 19 : Android 앱 테스트 도구
튜토리얼 # 20 : 최고의 모바일 앱 보안 테스트 도구
튜토리얼 # 21 : 58 최고의 모바일 테스트 도구
모바일 자동화 테스트 :
튜토리얼 # 22 : Appium Mobile Automation Tool 튜토리얼
튜토리얼 # 23 : Appium Studio 튜토리얼
튜토리얼 # 24 : TestComplete 도구를 사용하여 Android 애플리케이션 자동화
튜토리얼 # 25 : Robotium 튜토리얼 – Android 앱 UI 테스트 도구
튜토리얼 # 26 : Selendroid 튜토리얼 : 모바일 자동화 프레임 워크
튜토리얼 # 27 : pCloudy 자습서 : 실제 장치에서 모바일 앱 테스트
튜토리얼 # 28 : Katalon Studio 및 Kobiton의 클라우드 기반 Device Farm 자습서
모바일 테스트 경력 :
튜토리얼 # 29 : 모바일 테스트 작업을 빠르게하는 방법
튜토리얼 # 30 : 모바일 테스트 인터뷰 질문 및 이력서
튜토리얼 # 31 : 모바일 테스트 인터뷰 질문 2 부
************************************************* * **********
시리즈의 첫 번째 자습서부터 시작하겠습니다.
학습 내용 :
- 튜토리얼 # 1 : 모바일 애플리케이션 테스트 소개
튜토리얼 # 1 : 모바일 애플리케이션 테스트 소개
전화가 구석에 앉아 우리의주의를 끌기 위해 울려 야하는 기기 였거나 컴퓨터가 단지 소수의 사람들 만 사용했던 기계였던 시절은 지나갔습니다. 이제는 우리 존재의 연장입니다. 말대로하는 세계와 가상의 하인.
컴퓨터는 분노했고 우리 인간이 생각하고, 행동하고, 배우고, 존재하는 방식을 바 꾸었습니다.
요즘 모빌리티 솔루션이 시장을 장악했습니다. 사람들은 모든 작업을 위해 노트북 / PC를 켜고 싶어하지 않고 휴대형 장치가 모든 작업을 빠르게 수행하기를 원합니다.
따라서 우리가 고객에게 제공하는 모바일 솔루션은 매우 잘 테스트되어야합니다. 이 튜토리얼은 이미 모바일 테스트 중이거나 최근에 전환 한 사용자를 대상으로합니다. 모바일 테스트 관련 용어의 정의에 대한 많은 자습서가 이미 있으므로이 자습서의 범위를 직접 다룰 것입니다.
이 튜토리얼은 모바일 테스트에 대한 소개이자 가이드입니다. 그래서 읽어보세요!
모바일 테스트 유형
모바일 장치에서 수행되는 테스트에는 크게 두 가지 종류가 있습니다.
#1. 하드웨어 테스트 :
내부 프로세서, 내부 하드웨어, 화면 크기, 해상도, 공간 또는 메모리, 카메라, 라디오, Bluetooth, WIFI 등을 포함하는 장치입니다.이를 단순 '이라고도합니다.모바일 테스트”.
# 2. 소프트웨어 또는 애플리케이션 테스트 :
모바일 장치에서 작동하는 응용 프로그램과 해당 기능이 테스트됩니다. 그것은 '모바일 애플리케이션 테스트”를 사용하여 이전 방법과 구별합니다. 모바일 애플리케이션에서도 이해하는 데 중요한 몇 가지 기본적인 차이점이 있습니다.
a) 기본 앱 : 모바일 및 태블릿과 같은 플랫폼에서 사용하기 위해 기본 애플리케이션이 생성됩니다.
b) 모바일 웹 앱 모바일 네트워크 또는 WIFI와 같은 무선 네트워크에 연결하여 Chrome, Firefox와 같은 다른 브라우저를 사용하여 모바일에서 웹 사이트에 액세스하는 서버 측 앱입니다.
c) 하이브리드 앱 기본 앱과 웹 앱의 조합입니다. 장치 또는 오프라인에서 실행되며 HTML5 및 CSS와 같은 웹 기술을 사용하여 작성됩니다.
다음과 같은 몇 가지 기본적인 차이점이 있습니다.
- 네이티브 앱에는 단일 플랫폼 선호도가있는 반면 모바일 웹 앱에는 교차 플랫폼 선호도가 있습니다.
- 네이티브 앱은 SDK와 같은 플랫폼에서 작성되는 반면 모바일 웹 앱은 HTML, CSS, asp.net, Java, PHP와 같은 웹 기술로 작성됩니다.
- 기본 앱의 경우 설치가 필요하지만 모바일 웹 앱의 경우 설치가 필요하지 않습니다.
- 기본 앱은 Play 스토어 또는 앱 스토어에서 업데이트 할 수 있으며 모바일 웹 앱은 중앙 집중식 업데이트입니다.
- 많은 기본 앱에는 인터넷 연결이 필요하지 않지만 모바일 웹 앱의 경우 필수입니다.
- 기본 앱은 모바일 웹 앱에 비해 더 빠르게 작동합니다.
- 네이티브 앱은 다음과 같은 앱 스토어에서 설치됩니다. 구글 플레이 스토어 또는 앱 스토어 모바일 웹은 웹 사이트이며 인터넷을 통해서만 액세스 할 수 있습니다.
나머지 기사는 모바일 애플리케이션 테스트에 관한 것입니다.
모바일 애플리케이션 테스트의 중요성
모바일 장치에서 응용 프로그램을 테스트하는 것은 데스크톱에서 웹 응용 프로그램을 테스트하는 것보다 더 어렵습니다.
- 다양한 범위의 모바일 장치 하드 키패드, 가상 키패드 (터치 스크린) 및 트랙볼 등과 같은 다양한 화면 크기 및 하드웨어 구성
- 다양한 모바일 장치 HTC, Samsung, Apple 및 Nokia처럼.
- 다양한 모바일 운영 체제 Android, Symbian, Windows, Blackberry 및 IOS와 같은
- 다양한 버전의 운영 체제 iOS 5.x, iOS 6.x, BB5.x, BB6.x 등
- 다양한 모바일 네트워크 사업자 GSM 및 CDMA와 같습니다.
- 빈번한 업데이트 (예 : Android- 4.2, 4.3, 4.4, iOS-5.x, 6.x)는 업데이트 할 때마다 새로운 테스트주기를 통해 애플리케이션 기능에 영향을주지 않는지 확인하는 것이 좋습니다.
다른 응용 프로그램과 마찬가지로 모바일 응용 프로그램 테스트도 매우 중요합니다. 특정 제품에 대해 고객이 일반적으로 수백만 명에 달하기 때문에 버그가있는 제품은 결코 평가되지 않습니다. 종종 금전적 손실, 법적 문제 및 돌이킬 수없는 브랜드 이미지 손상을 초래합니다.
모바일 및 데스크톱 애플리케이션 테스트의 기본 차이점 :
데스크톱 테스트와 차별화되는 모바일 앱 테스트를 설정하는 몇 가지 명백한 측면
- 데스크톱에서 응용 프로그램은 중앙 처리 장치에서 테스트됩니다. 모바일 장치에서 응용 프로그램은 Samsung, Nokia, Apple 및 HTC와 같은 핸드셋에서 테스트됩니다.
- 모바일 장치 화면 크기는 데스크톱보다 작습니다.
- 모바일 장치는 데스크톱보다 메모리가 적습니다.
- 모바일은 데스크탑이 광대역 또는 전화 접속 연결을 사용하는 2G, 3G, 4G 또는 WIFI와 같은 네트워크 연결을 사용합니다.
- 데스크톱 애플리케이션 테스트에 사용되는 자동화 도구는 모바일 애플리케이션에서 작동하지 않을 수 있습니다.
모바일 앱 테스트 유형 :
위의 모든 기술적 측면을 해결하기 위해 모바일 애플리케이션에서 다음 유형의 테스트가 수행됩니다.
- 사용성 테스트 – 모바일 앱이 사용하기 쉽고 고객에게 만족스러운 사용자 경험을 제공하기 위해
- 호환성 테스트 – 요구 사항에 따라 다양한 모바일 장치, 브라우저, 화면 크기 및 OS 버전에서 애플리케이션 테스트.
- 인터페이스 테스트 – 응용 프로그램의 메뉴 옵션, 버튼, 북마크, 기록, 설정 및 탐색 흐름 테스트.
- 서비스 테스트 – 응용 프로그램의 서비스를 온라인 및 오프라인으로 테스트합니다.
- 낮은 수준의 리소스 테스트 : 메모리 사용량 테스트, 임시 파일 자동 삭제, 하위 수준 리소스 테스트로 알려진 로컬 데이터베이스 증가 문제.
- 성능 시험 – 2G, 3G에서 WIFI로 연결 변경, 문서 공유, 배터리 소모 등을 통해 애플리케이션 성능 테스트
- 운영 테스트 – 배터리가 다운되거나 저장소에서 애플리케이션을 업그레이드하는 동안 데이터 손실시 백업 및 복구 계획 테스트.
- 설치 테스트 - 장치에 설치 / 제거하여 응용 프로그램의 유효성을 검사합니다.
- 보안 테스트 – 정보 시스템이 데이터를 보호하는지 여부를 검증하기 위해 애플리케이션 테스트.
모바일 애플리케이션 테스트 전략
테스트 전략은 모든 품질 및 성능 지침을 충족하는지 확인해야합니다. 이 영역에 대한 몇 가지 지침 :
1) 장치 선택 - 시장을 분석하고 널리 사용되는 장치를 선택하십시오. (이 결정은 대부분 클라이언트에 달려 있습니다. 클라이언트 또는 앱 빌더는 테스트에 사용할 핸드셋을 결정하기 위해 애플리케이션에 대한 마케팅 요구뿐만 아니라 특정 장치의 인기 요인을 고려합니다.)
2) 에뮬레이터 – 이들의 사용은 앱을 빠르고 효율적으로 확인할 수 있으므로 개발 초기 단계. 에뮬레이터는 소프트웨어 자체를 변경하지 않고 한 환경에서 다른 환경으로 소프트웨어를 실행하는 시스템입니다. 기능을 복제하고 실제 시스템에서 작동합니다.
모바일 에뮬레이터의 유형
- 장치 에뮬레이터-장치 제조업체에서 제공
- 브라우저 에뮬레이터-모바일 브라우저 환경을 시뮬레이션합니다.
- 운영 체제 에뮬레이터-Apple은 iPhone 용, Windows 용 Microsoft 및 Google Android 용 에뮬레이터를 제공합니다.
권장 도구
# 1) Kobiton
Kobiton은 실제 장치를 사용하여 Android와 iOS 모두에서 네이티브, 웹 및 하이브리드 앱의 테스트 및 제공을 가속화하는 저렴하고 매우 유연한 클라우드 기반 모바일 경험 플랫폼입니다. 새로운 스크립트없는 테스트 자동화는 코딩 전문 지식이없는 팀이 개방형 표준 Appium 스크립트를 쉽게 생성 할 수 있도록 도와줍니다.
클래스 d의 기본 서브넷 마스크
무료이며 사용하기 쉬운 모바일 장치 에뮬레이터 목록
나는. 휴대폰 에뮬레이터 – iPhone, Blackberry, HTC, Samsung 등과 같은 핸드셋 테스트에 사용됩니다.
ii. MobiReady –이를 통해 웹 앱을 테스트 할 수있을뿐만 아니라 코드도 확인할 수 있습니다.
iii. 반응 형 px – 웹 페이지의 응답, 웹 사이트의 모양 및 기능을 확인합니다.
iv. Screenfly – 사용자 정의 가능한 도구이며 다양한 카테고리에서 웹 사이트를 테스트하는 데 사용됩니다.
삼) 모바일 앱에 대한 만족스러운 수준의 개발이 완료되면 테스트로 이동할 수 있습니다. 물리적 장치 실제 시나리오 기반 테스트를 위해.
4) 클라우드 컴퓨팅 기반 테스트 고려 : 클라우드 컴퓨팅 기본적으로 애플리케이션을 테스트, 업데이트 및 관리 할 수있는 인터넷을 통해 여러 시스템 또는 네트워크에서 장치를 실행합니다. 테스트 목적으로 시뮬레이터에 웹 기반 모바일 환경을 만들어 모바일 앱에 액세스합니다.
장점 :
- 백업 및 복구-클라우드 컴퓨팅은 원격 위치에서 데이터를 자동으로 백업하므로 데이터를 쉽게 복구하고 복원 할 수 있습니다. 또한 저장 용량은 무제한입니다.
- 클라우드는 다양한 장치에서 어디서나 액세스 할 수 있습니다.
- 클라우드 컴퓨팅은 비용 효율적이고 사용, 유지 관리 및 업데이트가 쉽습니다.
- 빠르고 빠른 배포.
- 웹 기반 인터페이스.
- 여러 장치에서 동일한 스크립트를 병렬로 실행할 수 있습니다.
단점
- 덜 제어 – 애플리케이션이 원격 또는 타사 환경에서 실행되기 때문에 사용자는 기능에 대한 제어 및 액세스가 제한됩니다.
- 인터넷 연결 문제 – 설정이 인터넷에 있습니다. 네트워크 문제는 가용성 및 기능에 영향을 미칩니다.
- 보안 및 개인 정보 문제 – 클라우드 컴퓨팅은 인터넷 컴퓨팅이며 인터넷상의 어떤 것도 안전하게 완료되지 않으므로 데이터 해킹 가능성이 더 높습니다.
5) 자동화 대 수동 테스트
- 응용 프로그램에 새 기능이 포함 된 경우 수동으로 테스트하십시오.
- 응용 프로그램에 한두 번 테스트가 필요한 경우 수동으로 수행하십시오.
- 회귀 테스트 사례에 대한 스크립트를 자동화합니다. 회귀 테스트가 반복되는 경우 자동화 된 테스트가 적합합니다.
- 수동으로 실행하면 시간이 많이 걸리는 복잡한 시나리오의 스크립트를 자동화합니다.
모바일 앱을 테스트하기 위해 두 가지 종류의 자동화 도구를 사용할 수 있습니다.
개체 기반 모바일 테스트 도구 – 장치 화면의 요소를 개체에 매핑하여 자동화. 이 접근 방식은 화면 크기와 무관하며 주로 Android 기기에 사용됩니다.
- 예 :-Ranorex, jamo 솔루션
이미지 기반 모바일 테스트 도구 – 요소의 화면 좌표를 기반으로 자동화 스크립트를 생성합니다.
- 예 :-Sikuli, Egg Plant, RoutineBot
6) 네트워크 구성 모바일 테스트의 필수 부분이기도합니다. 2G, 3G, 4G 또는 WIFI와 같은 다양한 네트워크에서 애플리케이션을 검증하는 것이 중요합니다.
모바일 앱 테스트를위한 테스트 사례
기능 기반 테스트 케이스 외에도 모바일 애플리케이션 테스트에는 다음 시나리오를 다루어야하는 특수 테스트 케이스가 필요합니다.
- 배터리 사용량 – 모바일 장치에서 응용 프로그램을 실행하는 동안 배터리 소모량을 추적하는 것이 중요합니다.
- 응용 프로그램의 속도 다른 장치, 다른 메모리 매개 변수, 다른 네트워크 유형 등의 응답 시간
- 데이터 요구 사항 – 설치 및 제한된 데이터 요금제를 가진 사용자가 다운로드 할 수 있는지 확인하기 위해.
- 메모리 요구 사항 – 다시 다운로드, 설치 및 실행
- 응용 프로그램의 기능 – 응용 프로그램이 네트워크 장애 또는 다른 이유로 인해 충돌하지 않는지 확인하십시오.
다운로드모바일 애플리케이션 테스트를위한 몇 가지 샘플 테스트 사례 :
=> 모바일 앱 샘플 테스트 케이스 다운로드
모바일 애플리케이션 테스트의 일반적인 활동 및 절차
테스트의 범위는 확인해야 할 여러 요구 사항 또는 앱 변경 범위에 따라 다릅니다. 변경 사항이 적 으면 라운드 제정신 테스트 할 것입니다. 주요 및 / 또는 복잡한 변경의 경우 완전 회귀 권장됩니다.
예제 애플리케이션 테스트 프로젝트 : ILL (International Learn Lab)은 관리자와 게시자가 공동으로 웹 사이트를 만들 수 있도록 설계된 응용 프로그램입니다. 강사는 웹 브라우저를 사용하여 일련의 기능 중에서 선택하여 요구 사항을 충족하는 수업을 만듭니다.
모바일 테스트 프로세스 :
1 단계. 식별 테스트 유형 : ILL 애플리케이션은 브라우저에 적용 할 수 있으므로 다른 휴대 기기를 사용하는 지원되는 모든 브라우저에서이 애플리케이션을 테스트해야합니다. 우리는해야합니다 유용성, 기능성 과 적합성 다른 브라우저에서 테스트 조합 의 안내서 과 오토메이션 테스트 케이스.
2 단계. 수동 및 자동 테스트 : 이 프로젝트를 위해 따르는 방법론은 2 주 반복되는 Agile입니다. 2 주마다 dev. 팀은 테스트 팀을위한 새 빌드를 출시하고 테스트 팀은 QA 환경에서 테스트 케이스를 실행합니다. 자동화 팀은 기본 기능 세트에 대한 스크립트를 만들고 새 빌드가 테스트하기에 충분히 안정적인지 확인하는 데 도움이되는 스크립트를 실행합니다. 수동 테스트 팀은 새로운 기능을 테스트합니다.
지라 승인 기준 작성에 사용됩니다. 테스트 케이스 유지 및 결함 로깅 / 재 검증 반복이 끝나면 되풀이 계획 dev. 팀, 제품 소유자, 비즈니스 분석가 및 QA 팀이 논의합니다. 잘 된 것 과 개선해야 할 사항 .
3 단계. 베타 테스트 : QA 팀이 회귀 테스트를 완료하면 빌드가 UAT로 이동합니다. 사용자 수락 테스트는 클라이언트가 수행합니다. 그들은 모든 버그를 재 검증하여 모든 버그가 수정되었고 승인 된 모든 브라우저에서 애플리케이션이 예상대로 작동하는지 확인합니다.
4 단계. 성능 테스트: 성능 테스트 팀은 JMeter 스크립트를 사용하고 애플리케이션에 대한 부하를 다르게하여 웹 앱의 성능을 테스트합니다.
Windows 7에서 빈 파일을 여는 방법
5 단계. 브라우저 테스트 : 웹 앱은 다양한 시뮬레이션 도구를 사용하거나 실제 모바일 장치를 사용하여 여러 브라우저에서 테스트됩니다.
6 단계. 출시 계획 : 4 주마다 테스트는 스테이징 단계로 이동하여 이러한 장치에 대한 최종 테스트를 수행하여 제품이 생산 준비가되었는지 확인합니다. 그리고 Live!
******************************************
Android 및 iOS 플랫폼 모두에서 모바일 애플리케이션을 테스트하는 방법
iOS와 Android 플랫폼 모두에서 앱을 테스트하는 테스터가 둘의 차이점을 아는 것은 매우 중요합니다. iOS와 Android는 룩앤필, 앱보기, 인코딩 표준, 성능 등과 관련하여 많은 차이가 있습니다.
Android와 iOS 테스트의 기본 차이점
모든 튜토리얼을 살펴 보았을 수도 있고, 여기에 몇 가지 주요 차이점을 입력하여 테스트의 일부로 도움이 될 것입니다.
#1) 우리는 시장에 많은 Android 장치를 사용할 수 있고 모두 화면 해상도와 크기가 다르기 때문에 이것이 주요 차이점 중 하나입니다.
예를 들어 , Nexus 6에 비해 삼성 S2 크기가 너무 작습니다. 기기 중 하나에서 앱 레이아웃과 디자인이 왜곡 될 가능성이 높습니다. iOS에서는 시장에서 구할 수있는 기기 만 있고 그 중에서도 비슷한 해상도를 가지고 있기 때문에 확률이 낮습니다.
예를 들어, iPhone 6 이상이 등장하기 전에는 모든 이전 버전의 크기가 비슷했습니다.
#두) 위의 요점을 주장하는 예는 Android에서 개발자는 모든 장치의 이미지 해상도를 지원하기 위해 1x, 2x, 3x, 4x 및 5x 이미지를 사용해야하는 반면 iOS는 1x, 2x 및 3x 만 사용한다는 것입니다. 그러나 이미지 및 기타 UI 요소가 모든 기기에서 올바르게 표시되는지 확인하는 것은 테스터의 책임이됩니다.
이미지 해상도의 개념을 이해하려면 아래 다이어그램을 참조하십시오.
#삼) 시장이 안드로이드 기기로 넘쳐나므로 코드는 성능이 안정적으로 유지되는 방식으로 작성되어야합니다. 따라서 앱이 저사양 기기에서 느리게 작동 할 가능성이 매우 높습니다.
# 4) Android의 또 다른 문제는 모든 장치에서 소프트웨어 업그레이드를 한 번에 사용할 수 없다는 것입니다. 장치 제조업체는 장치 업그레이드시기를 결정합니다. 새 OS와 이전 OS로 모든 것을 테스트하는 것은 매우 어려운 작업이됩니다.
또한 개발자가 두 버전을 모두 지원하도록 코드를 수정하는 것은 번거로운 작업이됩니다.
예를 들어 , Android 6.0이 출시되었을 때이 OS가 앱 수준 권한을 지원하기 시작하면서 큰 변화가있었습니다. 더 명확히하기 위해 사용자는 앱 수준에서도 권한 (위치, 연락처)을 변경합니다.
이제 테스트 팀은 Android 6.0 이상에서 앱 실행시 권한 화면을 표시하고 하위 버전에서는 권한 화면을 표시하지 않도록 할 책임이 있습니다.
# 5) 테스트 관점에서 프리 프로덕션 빌드 (예 : 베타 버전) 테스트는 두 플랫폼에서 다릅니다. Android에서 사용자가 베타 사용자 목록에 추가되면 베타 사용자로 추가 된 동일한 이메일 ID로 Play 스토어에 로그인 한 경우에만 Play 스토어에서 업데이트 된 베타 빌드를 볼 수 있습니다.
모바일 테스트의 핵심 요소
저는 지난 2 년 동안 iOS 및 Android 플랫폼에서 모바일 테스트 작업을 해왔으며이 튜토리얼에서 아래에 언급 된 모든 핵심 사항은 제 개인적인 경험에서 비롯되었으며 일부는 프로젝트에서 발생한 문제에서 파생되었습니다.
자신 만의 테스트 범위 정의
누구나 자신 만의 테스트 스타일이 있습니다. 일부 테스터는 눈에서 보는 것에 초점을 맞추고 나머지는 모든 모바일 애플리케이션의 뒤에서 작동하는 모든 것에 열정적입니다.
당신이 iOS / 안드로이드 테스터라면, 나는 항상 우리의 테스트 스타일에 가치를 더하기 때문에 적어도 안드로이드 또는 iOS의 몇 가지 일반적인 제한 / 기본 기능에 익숙해 지길 권합니다. 예를 들지 않고는 이해하기 어렵다는 것을 알고 있습니다.
다음은 몇 가지 예입니다.
- 6.0.1 버전 미만의 Android 기기에서는 앱 수준에서 카메라, 저장소 등의 권한을 변경할 수 없습니다.
- iOS 10.0 이하 버전의 경우 통화 키트가 없었습니다. 간단히 말해, 통화 키트는 통화 앱에서 사용되며 사용자가 WhatsApp, Skype 등과 같은 통화 앱에서 전화를받을 때 전체 화면보기를 표시합니다. 반면 iOS 버전이 10.0 이하인 경우 이러한 통화가 표시됩니다. 알림 배너로.
- 지갑에 돈을 추가하려는 경우 앱이 은행 결제 페이지로 리디렉션되지 않는 Paytm에서 많은 문제가 발생했을 수 있습니다. 위의 문제는 은행 또는 Paytm 서버의 문제라고 생각하지만 AndroidSystemWebView가 업데이트되지 않았기 때문입니다. 프로그래밍에 대한 지식이 거의 없어도 항상 도움이되고 팀과 공유 할 수 있습니다.
- 간단히 말해, 앱이 웹 페이지를 열 때마다 AndroidSystemWebView를 업데이트해야합니다.
테스트를 제한하지 마십시오
테스트는 모바일 앱 탐색 및 버그 로깅에만 국한되어서는 안됩니다. 우리는 QA로서 우리가 서버에 도달 한 모든 요청과 서버에서 나오는 응답을 알고 있어야합니다.
프로젝트에서 사용중인 항목에 따라 로그를 보거나 로그에 대한 스모 로직을 확인하도록 Putty를 구성합니다. 애플리케이션의 엔드-투-엔드 흐름을 아는 데 도움이 될뿐만 아니라 더 많은 아이디어와 시나리오를 지금 얻을 수 있으므로 더 나은 테스터가됩니다.
이유: 이유없이이 세상에는 아무것도 오지 않습니다. 모든 진술에는 타당한 이유가 있어야합니다. 로그를 분석하는 이유는 로그에서 많은 예외가 관찰되었지만 UI에 영향을 미치지 않아서인지하지 못하기 때문입니다.
그래서 우리는 그것을 무시해야합니까?
아니, 우리는 안됩니다. UI에는 영향을주지 않지만 미래의 우려가 될 수 있습니다. 이러한 종류의 예외가 계속 발생하면 앱이 중단되는 것을 볼 수 있습니다. 마지막 문장에서 App Crash에 대해 언급했듯이 QA는 프로젝트의 crashlytics에 액세스 할 수 있습니다.
Crashlytics는 시간 및 기기 모델과 함께 비정상 종료가 기록되는 도구입니다.
이제 여기에있는 질문은 테스터가 앱 충돌을 본 적이 있다면 왜 crashlytics에 대해 신경을 써야할까요?
이에 대한 대답은 매우 흥미 롭습니다. UI에 표시되지 않을 수 있지만 crashlytics에 기록되는 일부 비정상 종료가 있습니다. 나중에 성능에 영향을 줄 수있는 메모리 부족 충돌 또는 치명적인 예외 일 수 있습니다.
교차 플랫폼 테스트
교차 플랫폼 상호 작용 테스트는 매우 중요합니다.
간단한 인용 예 , 이미지 및 비디오 전송을 지원하는 WhatsApp과 같은 채팅 응용 프로그램에서 작업 중이고 응용 프로그램이 iOS 및 Android 플랫폼 모두에 구축되어 있다고 가정합니다 (개발이 동기화 될 수도 있고 아닐 수도 있음).
Android와 iOS의 통신을 테스트해야합니다. 그 이유는 iOS가 'Objective C'를 사용하는 반면 Android 프로그래밍은 Java 기반이며 두 가지 모두 서로 다른 플랫폼에서 빌드되기 때문에 앱에서 추가 수정이 필요한 경우가 있습니다. 다른 언어 플랫폼에서 오는 문자열을 인식합니다.
모바일 앱의 크기를 주시하십시오
모바일 테스터를위한 또 다른 중요한 조언입니다. 앱 크기 각 릴리스 후.
앱의 크기가 최종 사용자 인 우리조차도이 앱의 크기가 크기 때문에 다운로드를 원하지 않는 지점에 도달하지 않도록해야합니다.
앱 업그레이드 시나리오 테스트
모바일 테스터의 경우 앱 업그레이드 테스트 매우 중요합니다. 개발팀에서 버전 번호가 일치하지 않았을 수 있으므로 업그레이드시 앱이 다운되지 않는지 확인하세요.
데이터 보존은 사용자가 이전 버전에서 저장 한 기본 설정이 앱을 업그레이드 할 때 보존되어야하는 것과 마찬가지로 중요합니다.
예를 들어 , 사용자가 PayTm 등과 같은 앱에 은행 카드 정보를 저장했을 수 있습니다.
기기 OS가 앱을 지원하지 않을 수 있음
흥미로운가요?
예, 많은 기기에서 앱을 지원하지 않을 수 있습니다. 많은 사람들이 공급 업체가 미국 상단에 자체 래퍼를 작성한다는 사실을 알고 있어야하며 앱의 SQL 쿼리가 기기와 호환되지 않을 수 있으므로 예외가 발생하고 실행되지 않을 수도 있습니다. 그 전화의 앱.
여기서 요점은 – 사무실에서 사용하는 장치를 제외하고 자신의 장치에서 앱을 사용하십시오. 앱에 몇 가지 문제가있을 수 있습니다.
앱 권한 테스트
다음 목록은 모바일 앱의 권한 테스트 . 거의 매초마다 사용자에게 휴대 전화의 연락처, 카메라, 갤러리, 위치 등에 대한 액세스 권한을 요청합니다. 이러한 권한의 적절한 조합을 테스트하지 않아 실수를 저지른 테스터는 거의 없습니다.
실시간으로 기억할 수 있습니다 예 이미지와 오디오 파일을 공유하는 모든 기능이있는 채팅 앱을 테스트 할 때 스토리지 권한이 NO로 설정되었습니다.
이제 사용자가 카메라 옵션을 클릭하면 저장 권한이 YES로 설정 될 때까지 열리지 않습니다. Android Marshmallow에는 저장소 권한이 NO로 설정된 경우 해당 앱에 카메라를 사용할 수없는이 기능이 있으므로 시나리오는 무시되었습니다.
범위는 위 단락에서 논의한 것보다 더 확장됩니다. 앱이 사용되지 않는 권한을 요청하지 않는지 확인해야합니다.
소프트웨어 업계에 익숙한 최종 사용자는 너무 많은 권한이 필요한 앱을 다운로드하지 못할 수 있습니다. 앱에서 기능을 제거한 경우 동일한 권한 화면을 제거해야합니다.
기능 테스트 및 비 기능 테스트
마켓에서 유사하고 인기있는 앱과 비교
이야기의 교훈 – 의심 스러우면 스스로 결론을 내리지 마십시오. 동일한 플랫폼에있는 다른 유사한 앱과 비교하면 테스트중인 기능이 작동할지 여부에 대한 주장을 강화할 수 있습니다.
Apple의 빌드 거부 기준에 대한 개요보기
마지막으로, 대부분의 사용자는 빌드가 Apple에서 거부 된 상황을 접했을 수 있습니다. 나는이 주제가 독자들의 많은 관심을 끌지 않을 것이라는 것을 알고 있지만 Apple의 거부 정책을 아는 것은 항상 좋은 일입니다.
테스터로서 우리는 기술적 측면을 충족시키기가 어려워 지지만 테스터가 처리 할 수있는 몇 가지 거부 기준이 있습니다.
이에 대한 자세한 내용을 보려면 여기.
항상 앞발에 있어야합니다.
테스터이기 때문에 개발자 팀 / 관리자가 법정으로 넘어 가지 않도록하십시오. 테스트에 열정이 있다면 '항상 앞발에 있으십시오' . 코드가 테스트를 위해 버킷에 오기 훨씬 전에 발생하는 활동에 참여하십시오.
가장 중요한 것은 고객과 비즈니스 분석가의 티켓에 대한 모든 최신 업데이트를 위해 JIRA, QC, MTM 또는 프로젝트에서 사용되는 항목을 계속 살펴 보는 것입니다. 또한 수정이 필요한 경우 뷰를 공유 할 준비를하십시오. 이는 다양한 도메인과 플랫폼에서 작업하는 모든 테스터에게 적용됩니다.
제품이 우리 제품이라고 생각하지 않는 한, 기존 기능에 대한 새로운 개선이나 변경 사항을 제안해서는 안됩니다.
오랫동안 앱을 백그라운드에 유지 (12-24 시간)
이상하게 들리는 건 알지만 장면 뒤에는 우리 모두가 이해하지 못하는 논리가 많이 있습니다.
나는 앱을 시작한 후, 예를 들어 백그라운드 상태에서 약 14 시간 후에 충돌하는 것을 보았 기 때문에 이것을 공유하고 있습니다. 그 이유는 개발자가 어떻게 코딩했는지에 따라 무엇이든 될 수 있습니다.
실시간 예를 공유하겠습니다.
제 경우에는 토큰 만료가 원인이었습니다. 채팅 앱 중 하나의 경우 12 ~ 14 시간 후에 시작되면 연결 배너에 멈춰 죽고 다시 시작될 때까지 연결되지 않습니다. 이러한 종류의 문제는 파악하기가 매우 어렵고 어떤면에서는 모바일 테스트를 더욱 어렵고 창의적으로 만듭니다.
앱 성능 테스트
모바일 세계에서 앱의 성능은 애플리케이션이 전 세계적으로 인식되는 정도에 영향을 미칩니다. 테스트 팀으로서 앱 응답을 확인하는 것이 너무 중요 해지고 많은 사용자가 모두 함께 사용할 때 작동 방식이 더 중요해집니다.
예:
PayTm에 대해 이야기합시다.
PayTm 앱에서 ADD MONEY 옵션을 클릭하면 지갑에있는 잔액이 표시됩니다. 이면에서 무슨 일이 일어나고 있는지 고려하면 PayTm 사용자 ID로 서버로 진행되는 요청이며 서버는 계정의 잔액과 함께 응답을 다시 보냅니다.
위의 경우는 한 사용자가 서버에 접속 한 경우에만 해당됩니다. 1000 명의 사용자가 서버에 접속하더라도 최종 사용자의 유용성이 우리의 주된 목표이기 때문에 그들이 제 시간에 응답을 잘받을 수 있도록해야합니다.
결론
처음에는 모바일 테스트가 매우 쉬운 것처럼 보이지만 계속해서 살펴보면 개발 된 모든 것이 전 세계 수천 대의 장치에서 원활하게 실행되는지 확인하는 것이 쉽지 않다는 것을 이해하게 될 것입니다. .
대부분의 경우 최신 및 최근 몇 가지 OS 버전에서만 지원되는 앱이 표시됩니다. 그러나 시나리오를 놓치지 않는 것이 테스터의 의무가됩니다. 고려해야 할 다른 많은 사항이 있지만 다른 튜토리얼에서 이미 반복 한 사항은 언급하지 않았습니다.
배터리 소모, 인터럽트 테스트, 다른 네트워크 (3G, Wi-Fi)에서 테스트, 네트워크 전환 중 테스트, 모바일 앱의 원숭이 테스트 등과 같은 시나리오는 모두 모바일 테스트에 유용합니다.
테스터의 태도는 실제 테스트 환경에서 매우 중요합니다. 당신이 당신의 직업을 좋아하지 않는 이상 당신은 튜토리얼에 언급 된 일을하지 않을 것입니다.
저는이 분야에서 약 6 년 동안 일해 왔으며 작업이 때때로 단조롭다는 것을 잘 알고 있지만 이러한 단조로운 작업을 다소 흥미롭게 만들기 위해 우리 스스로 할 수있는 다른 많은 일들이 있습니다.
올바른 테스트 전략을 설계하고 올바른 모바일 시뮬레이터, 장치 및 모바일 테스트 도구를 선택하면 100 % 테스트 범위를 확보하고 보안, 사용성, 성능, 기능 및 호환성 기반 테스트를 테스트 스위트에 포함시킬 수 있습니다.
글쎄, 이것은 모바일 애플리케이션 테스트 가이드에서 독자의 여러 요청을 충족시키기위한 우리의 노력이었습니다.
저자 :이 시리즈를 컴파일하는 데 도움을 주신 Swapna, Hasnet 및 기타 모바일 테스트 전문가에게 감사드립니다!
다음 기사에서는 iOS 앱 테스트 .