JavaScript를 사용하여 Appium 모바일 자동화를 설정하기 위한 단일 가이드

바로 이 가이드입니다. 강력한 WebdriverIO 프레임워크를 활용하여 JavaScript로 Appium 모바일 자동화 테스트를 설정하는 방법에 대한 완벽한 가이드입니다. 이 접근 방식은 모바일 테스트 자동화를 위한 효율적이고 확장 가능한 솔루션을 보장합니다. 이 가이드를 통해 모바일 앱 배포를 가속화하는 일관되고 안정적인 테스트 스크립트를 구축하는 데 도움이 되기를 바랍니다.

Appium 설치를 위한 전제 조건 

JavaScript를 사용하여 Appium 자동화를 시작하려면 다음과 같은 필수 소프트웨어가 설치되어 있는지 확인하세요. 호환성과 최신 기능 활용을 위해 특정 버전을 권장합니다.

• Node.js(버전 18.x 이상 권장): 이 JavaScript 런타임은 브라우저 외부에서 JavaScript를 실행하고 프로젝트 종속성을 관리하는 데 필수적입니다.
• 다운로드 및 설치 : 를 방문 공식 Node.js 웹사이트 LTS 버전을 다운로드하세요. 설치 프로그램의 안내를 따르세요.
• 확인 : 터미널이나 명령 프롬프트를 열고 다음을 실행하세요.  

강타
노드 -v
npm -v

설치된 Node.js와 npm 버전이 표시됩니다. 

• 안드로이드 스튜디오: Android 기기 또는 에뮬레이터에서 테스트하기 위해 Android SDK를 제공합니다. ADB 장치 인식을 위한 유틸리티.
• 다운로드 및 설치 : 공식 개발자 웹사이트에서 Android Studio를 다운로드하세요마법사를 따르세요.
• Android SDK 구성: Android Studio에서 SDK 관리자를 통해 필요한 Android SDK 플랫폼과 빌드 도구가 설치되어 있는지 확인하세요. 에뮬레이터용 Android 가상 기기(AVD)를 설정하세요.
• 환경 변수 : 귀하의 안드로이드 홈 환경 변수가 Android SDK 디렉토리로 설정되어 있고 플랫폼 도구 (포함하는 ADB)가 시스템에 추가되었습니다. PATH.
• 비주얼 스튜디오 코드: JavaScript 개발을 위한 무료, 가볍고 강력한 코드 편집기입니다.
• 다운로드 및 설치 : 공식 방문 Visual Studio Code 웹사이트 설치 지침을 따르십시오.

Appium 설치 

사전 요구 사항을 충족하면 명령줄 인터페이스(CLI)를 사용하여 Appium을 설치할 수 있습니다. 최신 환경에서 널리 사용되는 Appium CLI는 자동화 워크플로우 측면에서 Appium Desktop보다 더 뛰어난 유연성을 제공합니다. 

1. Appium CLI를 전역적으로 설치합니다. 터미널을 통해 Appium 서버를 전역적으로 설치하세요. 

강타 
npm 설치 -g appium@next 

@다음 개선된 아키텍처와 드라이버/플러그인 관리 기능을 갖춘 현재의 주요 버전인 Appium 2.x를 설치합니다. 

2. Appium 드라이버 설치: Appium 2.x는 "플러그인으로서의 드라이버" 모델을 사용하므로 특정 플랫폼 드라이버를 설치해야 합니다. 

• Android의 경우 :  

강타 
appium 드라이버 설치 uiautomator2 

• iOS의 경우(해당되는 경우):  

강타
appium 드라이버 설치 xcuitest 

• 확인 : 다음을 사용하여 설치된 드라이버를 확인하세요.  

강타
Appium 드라이버 목록 

3. Appium 서버 시작: 활성 테스트를 실행하려면 Appium 서버가 필요합니다. 다음 명령어를 실행하여 Appium 서버를 시작하세요. 

강타
아피움 

이렇게 하면 기본 포트에서 Appium 서버가 시작됩니다. 4723. 

필요한 JavaScript 라이브러리 설치 

우리는 WebdriverIO를 기본 테스트 자동화 프레임워크로 사용하여 대체하고 있습니다. 셀레늄 웹 드라이버WebdriverIO는 설정을 위한 강력한 CLI, 내장 테스트 러너, 다양한 어설션 라이브러리 및 리포터에 대한 지원을 갖춘 완벽한 솔루션입니다. 

1. 프로젝트 디렉토리를 만듭니다. 터미널에서 원하는 위치로 이동하여 새 디렉토리를 만듭니다. 

강타
mkdir my-appium-project
cd my-appium-project

2. WebdriverIO 프로젝트 초기화: WebdriverIO CLI를 사용하여 프로젝트를 설정하세요. 이 명령은 다음과 같은 구성 관련 질문을 안내합니다. 

강타
npx wdio 설정 

구성하는 동안 다음을 선택합니다. 프레임워크로 "로컬 머신", "Mocha" 또는 "Jest"를 선택합니다. 컴파일러로 "아니요"를 선택합니다. 기본 테스트 파일 위치(./test/specs/**/*.js), "dot" 및 "spec" 리포터, "appium" 서비스를 선택합니다. 

이렇게 하면 wdio.conf.js 파일이 생성되고 WebdriverIO 및 @wdio/appium-service와 같은 필수 종속성이 설치됩니다. 

3. package.json을 검토하세요. 실행 후 npx wdio 설정당신의 package.json 필수 종속성이 있는 파일 업데이트(버전에 따라 다를 수 있음): 

JSON 

{ 
  "이름": "my-appium-project",
  "버전": "1.0.0",
  "기술": "WebdriverIO를 사용한 첫 번째 Appium 프로젝트"
  "기본": "index.js",
  "스크립트"{
    "와디오": "wdio 실행 ./wdio.conf.js"
  },
  "키워드": [],
  "작가": "",
  "특허": "ISC",
  "devDependencies"{
    "@wdio/appium-service": "^8.xx",
    "@wdio/cli": "^8.xx",
    "@wdio/mocha-프레임워크": "^8.xx",
    "@wdio/spec-reporter": "^8.xx",
    "웹드라이버리오": "^8.xx"
  } 
} 

참고 셀레늄 웹 드라이버 더 이상 직접적인 종속성이 아닙니다. WebdriverIO가 Appium과의 기본 통신을 처리합니다.

Appium 아키텍처 이해 

Appium의 강력한 클라이언트-서버 아키텍처는 크로스 플랫폼 모바일 테스트 자동화를 지원합니다. 구성 요소의 상호 작용 방식을 이해하는 것은 자동화 작업을 효율적으로 설계하고 문제 해결을 위해 매우 중요합니다.

Appium 서버 

Appium은 Node.js 기반으로 구축된 HTTP 서버입니다. Appium 2의 간소화된 핵심 모듈은 플랫폼에 구애받지 않는 기능을 제공하며, 특정 자동화 기능은 별도의 드라이버 모듈에 포함되어 있습니다. 이러한 설계 덕분에 앱을 수정하거나 특수 에이전트를 추가할 필요가 없어 테스트된 애플리케이션이 프로덕션 상태와 거의 동일한 상태를 유지합니다.

Appium 클라이언트 

Appium 클라이언트는 HTTP 요청 전송 시 W3C WebDriver 프로토콜 준수를 간소화하는 라이브러리로, 원하는 언어로 자동화 스크립트를 작성할 수 있도록 합니다. JavaScript의 경우, WebdriverIO는 모바일 자동화를 위한 풍부한 API와 프레임워크를 제공합니다. Java, Python, Ruby, C#용으로 제공되는 더 많은 클라이언트 라이브러리가 있으며, 모두 서버 통신을 위한 W3C WebDriver 사양을 준수합니다.

지원되는 플랫폼 

Appium의 크로스 플랫폼 기능은 운영 체제 전반에서 다양한 애플리케이션 유형을 자동화하기 위한 통합 API를 제공합니다. 

Appium은 주로 다음을 지원합니다. 

모바일 운영 체제:  

• 안드로이드 :
  • 기본 앱: Android SDK(Java/Kotlin)로 구축되었습니다. Appium은 UI Automator 2(uiautomator2 드라이버) 또는 에스프레소(에스 프레소 운전사).
  • 모바일 웹 앱: Chrome 등 모바일 브라우저를 통해 접속하는 웹사이트.
  • 하이브리드 앱: 기본 UI와 내장된 웹 뷰를 결합한 애플리케이션입니다. 

• iOS
  • 기본 앱: iOS SDK(Swift/Objective-C)로 구축되었습니다. Appium은 Apple의 XCUITest 프레임워크를 사용합니다(엑스큐이테스트 Xcode에서 드라이버)를 다운로드합니다.
  • 모바일 웹 앱: iOS에서 Safari를 통해 접속하는 웹사이트.
  • 하이브리드 앱: Android와 비슷하게 네이티브와 웹 구성 요소를 결합했습니다.

JavaScript로 첫 번째 Appium 테스트 작성하기 

WebdriverIO와 Mocha 프레임워크를 사용하여 첫 번째 Appium 테스트 스크립트를 만들고, 실행하고, 분석해 보겠습니다.

테스트 스크립트 만들기 

WebdriverIO 초기화 후, wdio.conf.js 테스트 파일이 있는 동안 글로벌 구성을 관리합니다. 테스트/사양 (또는 유사한). 우리는 만들 것입니다 테스트/사양/로그인.spec.js 가상의 로그인 애플리케이션의 경우. 

1. wdio.conf.js를 엽니다. 

먼저, wdio.conf.js 기능을 구성하여 Appium에 테스트를 위한 장치와 애플리케이션에 대한 정보를 제공합니다. 

JavaScript 

// wdio.conf.js
const를 내보내다 구성={
    // ... 다른 구성 ...
    기능: [{
        플랫폼 이름: '안드로이드',
        'appium:deviceName': '에뮬레이터-5554', // 장치 이름이나 에뮬레이터 ID로 바꾸세요
        'appium:플랫폼 버전': '11', // Android 버전으로 변경하세요
        'appium:app': '/path/to/your/eribank.apk', // 중요: .apk 파일의 절대 경로를 제공하세요
        'appium:appPackage': 'com.experitest.ExperiBank', // 앱 패키지로 교체하세요
        'appium:appActivity': '.로그인활동', // 앱의 기본 활동으로 대체합니다.
        'appium:automationName': 'UiAutomator2',
        // 'appium:noReset': true, // 선택 사항: 세션 간에 앱이 재설정되는 것을 방지하려면 true로 설정하세요.
        // 'appium:newCommandTimeout': 60000 // 선택 사항: Appium 명령에 대한 시간 초과
    }],
    // ... 나머지 구성 ...
};

기능에 대한 설명: 

• 플랫폼 이름: 모바일 기기의 운영 체제(예: '안드로이드', 'iOS').
• appium:장치 이름: 장치 식별자(예: 에뮬레이터-5554, Pixel_3a_API_30 에뮬레이터용; ADB 장치 (실제 장치의 경우)
• appium:플랫폼버전: 기기/에뮬레이터의 Android 또는 iOS 버전.
• 앱피움:앱: 응용 프로그램의 절대 경로 의 .apk (Android) 또는 .ipa (iOS) 파일은 Appium에서 앱을 설치하고 실행하는 데 필요합니다.
• appium:앱패키지 (안드로이드) / appium:bundleId (iOS): 애플리케이션의 고유 식별자.
• appium:appActivity (Android): Android 애플리케이션의 주요 활동을 시작합니다.
• appium:자동화이름: Appium 자동화 백엔드(UiAutomator2 Android의 경우 XCUITest iOS의 경우). 

참고 : iOS의 경우 구성 platformName: 'iOS', appium:deviceName, appium:platformVersion, appium:bundleId, appium:automationName: 'XCUITest', 그리고 포인트 앱피움:앱 너의 ~에게 .ipa 파일. 

2. login.spec.js를 만듭니다. 

다음으로, 다음 내용으로 test/specs/login.spec.js를 만듭니다.

JavaScript 

// 테스트/사양/로그인.spec.js
import { 예상하다 } 에 '@wdio/globals'; // WebdriverIO의 내장 어설션 라이브러리

설명하다('에리뱅크 로그인 테스트', () => {
    // 이 'before' 후크는 이 describe 블록의 모든 테스트 전에 한 번 실행됩니다.
    전에(비동기 () => {
        // "확인" 버튼과 같은 초기 팝업이 나타나면 이를 확인하고 처리합니다.
        // 이것은 초기 앱 출시의 일반적인 패턴입니다.
        const를 ok버튼셀렉터 = '//*[@text="확인"]';
        const를 확인요소 = 기다리다 $$(ok버튼셀렉터); // 여러 요소를 찾는 데 사용되는 $$
        if (okElements.길이 > 0) {
            콘솔.통나무('확인 버튼을 찾았어요, 클릭해보니...');
            기다리다 okElements[0].딸깍 하는 소리(); // 발견된 첫 번째 "확인" 버튼을 클릭합니다.
            기다리다 드라이버.일시 중지(1000); // UI가 안정될 수 있도록 잠시 멈춤
        }
    });

    그것('유효한 자격 증명으로 성공적으로 로그인해야 합니다', 비동기 () => {
        // 텍스트 속성(XPath)을 사용하여 사용자 이름 입력 필드를 찾습니다.
        const를 사용자 이름 필드 = 기다리다 $('//*[@text="사용자 이름"]');
        기다리다 사용자 이름 필드.setValue('회사'); // 사용자 이름 입력

        // 비밀번호 입력 필드 찾기
        const를 비밀번호필드 = 기다리다 $('//*[@text="비밀번호"]');
        기다리다 passwordField.setValue('회사'); // 비밀번호를 입력하세요 

        // 로그인 버튼을 찾아 클릭하세요
        const를 로그인 버튼 = 기다리다 $('//*[@text="로그인"]');
        기다리다 로그인버튼.클릭();

        // Assertion: 로그인이 성공했는지 확인합니다.
        // 이 예제에서는 로그인이 성공하면 "잔액" 텍스트가 나타난다고 가정합니다.
        const를 잔액텍스트 = 기다리다 $('//*[@text="잔액"]');
        기다리다 예상(잔액텍스트).존재할것(); // "Balance" 요소가 존재하는지 확인합니다. 

        콘솔.통나무('로그인 성공! '잔액' 텍스트를 찾았습니다!');
    }); 

    // 여기에 더 많은 테스트 케이스를 추가합니다(예: 잘못된 로그인, 로그아웃)
    // afterEach(async() => {
    // // 선택 사항: 각 테스트 후 탐색이나 데이터 지우기와 같은 해체 작업
    // // await driver.reset(); // 앱 상태를 재설정합니다.
    // }); 

    후에(비동기 () => {
        // 선택 사항: 이 제품군의 모든 테스트를 완료한 후 수행할 작업
        // 예를 들어, 브라우저를 열었다면 여기서 닫을 수 있습니다.
        // WebdriverIO를 사용하면 드라이버가 wdio.conf.js 설정에 따라 세션 수명 주기를 관리합니다.
        // 서비스에서 `cleanup`이 구성된 경우 여기서 `driver.quit()`는 필요하지 않습니다.
    });
}); 

테스트 실행 

테스트 스크립트가 준비되면 실행하기 전에 Appium 서버가 실행 중인지, 장치/에뮬레이터가 연결되어 있는지 확인하세요.

1. Appium 서버 시작: 

아직 실행 중이 아니라면 터미널에서 Appium 서버를 시작하세요. 

강타
아피움 

서버는 다음을 수신합니다. http://localhost:4723. 

2. 장치/에뮬레이터가 실행 중인지 확인하세요. 

• 에뮬레이터 : Android Studio의 AVD 관리자를 통해 Android 에뮬레이터를 시작합니다.
• 실제 장치: USB를 통해 Android 기기를 연결하고 USB 디버깅을 활성화한 후 인식을 확인하세요. ADB 장치.

3. WebdriverIO 테스트를 실행합니다. 

Appium 서버와 별도의 새 터미널에서 프로젝트 루트에서 다음을 실행합니다. 

강타
npm에서 wdio 실행 

이 명령은 와이파이 스크립트 in package.json. WebdriverIO 읽기 wdio.conf.jsAppium에 연결하고, 지정된 기기에서 앱을 실행하고, 테스트를 실행합니다. 터미널 출력에 테스트 진행 상황이 표시되며, 앱이 실행되어 작업을 수행하고 성공을 보고합니다.

테스트 결과 분석 

WebdriverIO는 즉각적인 테스트 피드백을 위한 기본 제공 보고 기능을 제공합니다. 기본값은 투기 기자는 간결한 콘솔 요약을 제공합니다. 

• 콘솔 출력(Spec Reporter): 

실행 중에 사양 보고자는 다음을 포함하여 실시간 터미널 피드백을 제공합니다. 

• 녹색 체크 표시(✓) 시험에 합격하기 위해.
• 실패한 테스트에는 빨간색 X 표시, 오류 메시지 및 스택 추적이 표시됩니다.
• 합격/불합격 횟수를 보여주는 최종 요약입니다.
• HTML 보고서(상세한 분석에 권장): 

자세하고 공유 가능하며 CI/CD 친화적인 보고서를 원하시면 wdio-json-html-reporter나 @wdio/allure-reporter와 같은 HTML 리포터를 추가하세요. 

추가하려면 wdio-json-html-리포터: 

리포터를 설치하세요: 

강타
npm 설치 --save-dev wdio-json-html-reporter 

wdio.conf.js를 업데이트하세요: 

reporters 배열에 reporter를 추가하고 onComplete 후크를 포함하여 HTML 보고서를 생성합니다. 

JavaScript 

// wdio.conf.js
import { JSONReporter, HTMLReportGenerator } 에 'wdio-json-html-리포터'; // 이 가져오기를 추가합니다 

const를 내보내다 구성={
    // ... 다른 구성 ...
    기자[
        '투기', // 즉각적인 피드백을 위해 콘솔 리포터를 유지하세요
        [JSONReporter, { // JSON 리포터를 추가하여 데이터를 수집합니다.
            결과물 파일: './reports/test-results.json',
            스크린샷 옵션: '실패 시' // 테스트 실패 시 스크린샷 캡처
        }]
    ],
    // ...

    // 모든 테스트가 완료되면 실행할 함수입니다.
    // 수집된 JSON 데이터로부터 HTML 보고서를 생성하는 곳입니다.
    완료 시: 비동기 함수() {
        const를 출력파일경로 = './reports/test-report.html'; // HTML 보고서의 경로
        const를 json폴더 = './보고서'; // JSON 보고서가 저장되는 디렉토리

        const를 보고서 생성기 =   HTMLReportGenerator(출력파일경로);
        기다리다 reportGenerator.convertJSONFolderToHTML(json폴더);
        콘솔.통나무(`\nHTML 보고서가 ${outputFilePath}에서 생성되었습니다.`);
    },
    // ... 나머지 구성 ...
};

테스트를 다시 실행하세요.

npm run wdio를 다시 실행하면 보고서 폴더가 생성됩니다. 열기 테스트 보고서.html 테스트 세부 정보, 실행 시간, 실패 스크린샷이 포함된 포괄적이고 대화형 보고서를 브라우저에서 확인하세요.

고급 Appium JavaScript 기능 

Appium과 WebdriverIO는 복잡한 모바일 시나리오를 처리하는 강력한 기능을 제공합니다. 

원하는 기능 사용 

기능(이전 Appium 2.x 및 W3C WebDriver 프로토콜의 "원하는 기능")은 Appium 자동화 세션의 테스트 환경과 원하는 동작을 정의하는 키-값 쌍입니다. Appium 서버에 장치, 애플리케이션 및 자동화 설정을 포함한 세션 설정에 대한 지침을 제공하는 데 필수적입니다.  

이 섹션에서는 고급 옵션을 살펴봅니다.

공급업체 접두사 이해(아피움:) 

Appium 2.x와 W3C WebDriver 프로토콜은 비표준 기능에 대한 공급업체 접두사를 요구합니다. Appium의 접두사는 다음과 같습니다. 아피움:표준 W3C 또는 다른 공급업체 기능과의 충돌을 방지합니다. 

Android의 일반 및 고급 기능(uiautomator2 운전사): 

JavaScript 

// wdio.conf.js의 Android 기능 예시 

기능: [{
    플랫폼 이름: '기계적 인조 인간',
    'appium:장치이름': '픽셀_3a_API_30', // 또는 `adb devices`에서 가져온 실제 장치 ID
    'appium:플랫폼버전': '11',
    '앱피움:앱': '/path/to/your/app.apk',
    'appium:앱패키지': 'com.yourcompany.yourapp',
    'appium:appActivity': '.MainActivity',
    'appium:자동화이름': 'UiAutomator2',
    'appium:noReset': 참된, // 테스트 사이에 앱 상태 유지
    'appium:fullReset': 그릇된, // 세션마다 앱을 다시 설치하지 마세요
    'appium:newCommandTimeout': 120000, // 느린 명령에 대한 시간 초과를 늘립니다.
    'appium:enableMultiWindows': 참된, // 여러 창/활동을 활용하는 앱의 경우
    'appium:systemPort': 8201, // 병렬 실행을 위한 시스템 포트 지정
    'appium:자동 허가': 참된, // 앱 권한을 자동으로 수락합니다
    'appium:chrome옵션'{ 인수['--웹뷰-GPU 비활성화'] }, // 하이브리드 앱 웹뷰 디버깅을 위해
    'appium:avd': '픽셀_3a_API_30', // 아직 실행 중이 아니면 이름으로 특정 AVD를 실행합니다.
    'appium:avdLaunchTimeout': 300000, // AVD 실행 시간 초과
    // 'appium:chromedriverExecutable': '/path/to/custom/chromedriver', // 특정 Chrome/WebView 버전용
}],

iOS(XCUITest 드라이버)의 일반 및 고급 기능:

JavaScript 

// wdio.conf.js의 iOS 기능 예시 

기능: [{
    플랫폼 이름: '아이오에스',
    'appium:장치이름': '아이폰 15 프로', // 또는 특정 시뮬레이터/장치 이름
    'appium:플랫폼버전': '17.0',
    '앱피움:앱': '/경로/앱/앱', // .app 파일(시뮬레이터의 경우) 또는 .ipa(실제 장치의 경우) 경로
    'appium:bundleId': 'com.yourcompany.yourapp',
    'appium:자동화이름': 'XCUITest',
    'appium:udid': '당신의_기기_UDID', // 실제 장치에 필요함
    'appium:noReset': 참된,
    'appium:fullReset': 그릇된,
    'appium:newCommandTimeout': 120000,
    'appium:xcodeOrgId': '팀 ID', // 실제 장치에 필요함
    'appium:xcodeSigningId': '애플 개발자', // 실제 장치에 필요함
    'appium:updatedWDABundleId': 'com.yourcompany.WebDriverAgentRunner', // WDA용 사용자 정의 번들 ID
    'appium:autoAcceptAlerts': 참된, // 시스템 알림(예: 위치, 푸시 알림)을 자동으로 수락합니다.
    'appium:usePrebuiltWDA': 참된, // 더 빠른 시작을 위해 미리 빌드된 WebDriverAgent를 사용합니다.
    'appium:webkitDebugProxyPort': 27753, // 하이브리드 앱 웹뷰 디버깅을 위해
}], 

역량에 대한 주요 정보: 

• 문서화가 핵심입니다: 최신 기능에 대한 자세한 내용은 항상 공식 Appium 문서를 참조하세요.
• 플랫폼 특성: 많은 기능은 Android 또는 iOS 및 해당 드라이버에만 고유합니다.UiAutomator2, XCUITest).
• 성능 및 안정성: 다음과 같은 기능 재설정 안 함, 전체 재설정및 새로운 명령 시간 초과 테스트 실행 속도와 안정성에 상당한 영향을 미칩니다.
• 디버깅 : 크롬옵션 or 웹킷디버그프록시포트 하이브리드 앱 웹 뷰를 디버깅하는 데 필수적입니다.
• 병렬 실행 : 병렬 테스트를 위해, 시스템포트 (안드로이드) 또는 고유성을 보장 우디드 (iOS)가 중요합니다.

모바일 제스처 처리 

모바일 애플리케이션은 스와이프, 스크롤, 길게 누르기, 핀치 투 줌과 같은 제스처를 많이 사용합니다. Appium과 함께 WebdriverIO는 이러한 상호작용을 위한 강력한 API를 제공하며, 특히 W3C Actions API(동작 유연성과 표준 준수를 위해 명령)을 사용합니다. Appium은 또한 특수화된 변하기 쉬운: 일반적인 제스처에 대한 명령. 

1. 탭하고 길게 누르기: 기본적인 상호작용은 종종 요소에서 직접 처리됩니다. 

JavaScript 

// 테스트/사양/제스처.spec.js

설명하다('모바일 제스처', () => {
    그것('요소를 길게 눌러야 합니다', 비동기 () => {
        // 길게 누르면 반응하는 요소가 있다고 가정합니다.
        const를 longPressElement = 기다리다 $('~길게 눌러주세요'); // 접근성 ID를 사용한 예

        // WebdriverIO의 긴 누르기 편의 메서드 사용
        기다리다 longPressElement.longPress();
        콘솔.통나무('요소를 길게 누르기 수행');

        // 일부 결과 확인(예: 컨텍스트 메뉴가 나타남)
        const를 컨텍스트메뉴 = 기다리다 $('//*[@text="컨텍스트 메뉴 항목"]');
        기다리다 기대(contextMenu).toBeExisting();
    });

    그것('좌표를 탭해야 합니다', 비동기 () => {
        // 때로는 특정 화면 좌표를 탭해야 합니다.
        // 예: 입력 필드 밖을 탭하여 키보드를 닫습니다.
        // 필요한 경우 화면 크기를 가져옵니다. await driver.getWindowRect();
        const를 화면 너비 = (기다리다 드라이버.getWindowRect()).너비;
        const를 화면 높이 = (기다리다 드라이버.getWindowRect()).높이;

        // 화면 중앙 근처를 탭하세요
        기다리다 드라이버.touchPerform([
            { 동작: '수도꼭지', 옵션{ x: 화면 너비 / 2, y: 화면 높이 / 2 }}
        ]);
        콘솔.통나무('화면 좌표를 탭했습니다.');
    });
});

2. 스와이프 및 스크롤: 스와이프는 손가락을 드래그하는 반면, 스크롤은 뷰 내에서 콘텐츠를 이동합니다. 

사용 브라우저.스와이프() (WebdriverIO 편의 메서드): 

JavaScript 

그것('스와이프 제스처를 수행해야 합니다', 비동기 () => {
    // 스크롤 가능한 요소 내에서 아래로 스크롤
    // 이것은 간단한 방향 스크롤에 좋습니다.
    const를 스크롤 가능한 요소 = 기다리다 $('안드로이드 위젯.스크롤뷰'); // 또는 iOS 동등 버전

    기다리다 스크롤 가능한 요소.스와이프({ 방향: '위로', 퍼센트: 0.8, 지속: 1000 }); // 1초 동안 요소 높이의 80%만큼 위로 스와이프합니다.
    콘솔.통나무('스크롤 가능한 영역 내에서 위로 스와이프합니다.');

    // 또는 전체 화면 스와이프
    // 브라우저를 기다립니다.swipe({ 방향: '왼쪽', 지속시간: 500 });
}); 


Appium의 모바일 사용: 스크롤 또는 모바일: 스와이프 명령 실행:
이러한 기능은 특히 특정 요소나 방향이 있는 복잡한 스크롤/스와이프 시나리오에서 더욱 강력합니다.

JavaScript 

그것('mobile:scroll'을 사용하여 요소로 스크롤해야 합니다., 비동기 () => {
    // '대상 요소'가 표시될 때까지 아래로 스크롤하려는 경우
    const를 대상요소선택자 = '//*[@text="대상 요소"]';

    기다리다 드라이버.실행('모바일: 스크롤 제스처', {
        요소 ID: (기다리다 $('안드로이드 위젯.스크롤뷰')).요소ID, // 스크롤할 요소
        방향: '아래에',
        퍼센트: 1.0, // 전체 보기로 스크롤
        속도: 5000 // 초당 픽셀 속도
    });

    const를 대상요소 = 기다리다 $(대상요소선택자);
    기다리다 expect(대상요소).toBeExisting();
    콘솔.통나무('대상 요소로 스크롤되었습니다.');
});

그것('캐러셀에서 가로로 스와이프해야 합니다', 비동기 () => {
    // 특정 제어된 스와이프(예: 회전형 슬라이드)의 경우
    const를 회전목마요소 = 기다리다 $('~이미지 회전목마'); // 접근성 ID 예시

    기다리다 드라이버.실행('모바일: 스와이프 제스처', {
        요소 ID: 캐러셀요소.요소ID,
        방향: '왼쪽', // 오른쪽에서 왼쪽으로 스와이프
        퍼센트: 0.75, // 요소를 75% 스와이프합니다.
        속도: 5000
    });
    콘솔.통나무('캐러셀을 왼쪽으로 넘겼습니다.');
});

3. 핀치 및 확대/축소(멀티터치 제스처): 핀치와 확대/축소는 두 손가락을 가까이 또는 멀리 움직이는 것을 의미하며, 일반적으로 포인터 유형과 함께 W3C Actions API를 사용합니다. 

JavaScript 

그것('핀치 줌 제스처를 수행해야 합니다', 비동기 () => {
    const를 대상이미지 = 기다리다 $('~확대 가능한 이미지'); // 핀치/줌할 요소 

    // 요소의 중심 좌표를 가져옵니다
    const를 요소위치 = 기다리다 targetImage.getLocation();
    const를 요소 크기 = 기다리다 targetImage.getSize();
    const를 centerX = elementLocation.x + elementSize.width / 2;
    const를 centerY = elementLocation.y + elementSize.height / 2;

    // W3C Actions API를 사용하여 핀치 제스처를 정의합니다.
    기다리다 드라이버.수행작업([
        {
            유형: '바늘',
            id: '손가락1',
            매개 변수{ 포인터 유형: '만지다' },
            행위[
                { 유형: '포인터다운', x: 센터X - 50, y: 중심Y }, // 손가락 1은 중앙 왼쪽에서 시작합니다.
                { 유형: '정지시키다', 지속: 100 },
                { 유형: '포인터 이동', 지속: 500, x: 센터X - 10, y: 중심Y } // 손가락 1이 약간 오른쪽으로 움직입니다.
            ]
        },
        {
            유형: '바늘',
            id: '손가락2',
            매개 변수{ 포인터 유형: '만지다' },
            행위[
                { 유형: '포인터다운', x: 센터X + 50, y: 중심Y }, // 손가락 2는 중앙 오른쪽에서 시작합니다.
                { 유형: '정지시키다', 지속: 100 },
                { 유형: '포인터 이동', 지속: 500, x: 센터X + 10, y: 중심Y } // 손가락 2가 약간 왼쪽으로 움직입니다.
            ]
        }
    ]);
    기다리다 드라이버.일시 중지(1000); // 애니메이션 시간 허용
    기다리다 드라이버.릴리스작업(); // Release 포인터

    콘솔.통나무('핀치 줌 제스처를 수행했습니다.');
    // 이미지가 예상대로 확대/축소되었는지 확인합니다(예: 크기 확인)
});

제스처에 대한 중요 참고 사항: 

• W3C 액션 API(드라이버.수행 작업): 순차적인 포인터 동작을 사용하여 복잡한 멀티터치 및 싱글터치 제스처를 정의하는 가장 유연하고 표준화된 방법입니다.
• 변하기 쉬운: 명령 : Appium은 특정 기능을 제공합니다 변하기 쉬운: 명령(예: 모바일: 스크롤 제스처, 모바일: 스와이프 제스처) 기본 드라이버에 기본으로 적용되고 일반적인 제스처에 더 간단하며 다음을 통해 실행됩니다. driver.execute('mobile:commandName', { /* 매개변수 */ }).
• 플랫폼 차이점: 기본 네이티브 자동화 프레임워크(UI Automator 2, XCUITest)는 다르게 동작합니다. Android와 iOS 모두에서 제스처를 철저히 테스트하세요.
• 좌표계: 좌표가 절대 화면 좌표인지 아니면 요소에 상대적인 좌표인지 주의하세요.

실제 장치와 에뮬레이터 작업 

실제 장치와 에뮬레이터/시뮬레이터 중에서 선택하는 것은 테스트 정확도, 속도, 비용 및 적용 범위에 영향을 미치므로 매우 중요합니다.

	에뮬레이터(Android) / 시뮬레이터(iOS)	실제 장치
장점	비용 효율성: 무료이며 물리적 하드웨어가 필요하지 않습니다. 확장성: 여러 인스턴스를 쉽게 시작할 수 있습니다. 제어된 환경: 간단한 설정, 쉬운 재설정, 네트워크/배터리 시뮬레이션. 빠른 피드백: UI 테스트를 위한 더 빠른 시작 및 실행. 디버깅: 개발 환경과의 통합이 우수합니다. 다양한 구성: 다양한 화면 크기, 해상도, OS 버전을 시뮬레이션합니다.	정확도: 앱 성능, UI, UX에 대한 가장 정확한 결과를 제공합니다. 하드웨어 기능 테스트: 실제 하드웨어에 의존하는 기능에 필수적입니다. 실제 시나리오: 실제 네트워크 조건과 중단 상황에서 테스트합니다. 진정한 UX: 터치 반응성과 애니메이션에 대한 실제적인 피드백. 제조업체별 문제: 기기 모델이나 OS 사용자 정의에 따른 버그를 찾아냅니다.
단점	제한된 하드웨어 시뮬레이션: 카메라, GPS, 생체 인식 등을 복제할 수 없습니다. 성능 차이: 특히 리소스를 많이 사용하는 앱의 경우 실제 성능을 반영하지 않을 수 있습니다. 실제 상황: 통화, SMS 또는 다양한 셀룰러 신호를 시뮬레이션하기 어렵습니다. 터치 반응성: 실제 기기의 동작을 완벽하게 모방하지 못할 수 있습니다. OS 특이점: 제조업체의 사용자 정의나 미묘한 OS 동작을 복제하지 못할 수 있습니다.	비용: 다양한 장치를 구매하고 유지 관리하는 데 비용이 많이 듭니다. 설정 및 유지관리: 설정, 관리, 요금 청구, 업데이트가 더 복잡합니다. 확장성 과제: 병렬 테스트를 위해 확장하는 것이 어렵고 비용이 많이 듭니다. 가용성: 다른 사람이 기기를 사용 중일 수 있어 지연이 발생할 수 있습니다. 디버깅의 복잡성: 더 어렵고, 종종 직접 연결이나 클라우드 도구가 필요합니다. 불안정성: 실제 변수로 인해 테스트가 불안정해질 수 있습니다.

많은 조직이 하이브리드 전략을 채택하고 있습니다. 에뮬레이터/시뮬레이터를 사용하여 신속한 일일 테스트를 진행하고, 실제 기기(사내 또는 클라우드)는 출시 시점에 가까워질수록 중요하고 엔드투엔드이며 성능에 민감한 테스트를 위해 남겨두는 것입니다. 이를 통해 속도, 비용, 그리고 정확성의 균형을 맞출 수 있습니다. 

Appium 테스트 디버깅 및 문제 해결 

이 섹션에서는 일반적인 Appium 테스트 문제, Appium Inspector를 사용하여 요소 식별, 문제를 분리하기 위한 로깅 및 보고 모범 사례에 대해 설명합니다. 

일반적인 문제 및 솔루션 

Appium에서 자주 발생하는 문제와 일반적인 해결 방법은 다음과 같습니다. 

1. Appium 서버가 실행되지 않거나 잘못 구성됨:

• 발행물: 거부됨 또는 "Appium 서버에 연결하지 못했습니다" 오류가 발생합니다.
• 해결 방법 : 확인 아피움 별도의 터미널에서 실행 중입니다. 확인하세요 wdio.conf.js 올바른 Appium 서버 주소 및 포트를 가리킵니다(기본값: http://localhost:4723). Appium 2.x의 기본 경로는 다음과 같습니다. / (아니신가요 /wd/허브).

2. 장치/에뮬레이터가 연결되지 않았거나 인식되지 않음:

• 발행물: "장치를 찾을 수 없습니다", "연결된 Android 장치를 찾을 수 없습니다" 또는 "사용 가능한 장치가 없습니다" 오류.
• 솔루션(Android): 장치 연결 및 디버깅 확인(ADB 장치). 보장하다 안드로이드 홈 및 플랫폼 도구 환경 변수에 있습니다 PATH에뮬레이터의 경우 테스트 전에 실행 중인지 확인하세요.
• 솔루션(iOS): 시뮬레이터가 실행되었는지 확인하세요. 실제 기기의 경우 연결, 신뢰 및 개발자 모드(iOS 16 이상)를 확인하세요. WebDriverAgent에 대한 Xcode 서명을 확인하세요.

3. 요소를 찾을 수 없음 (NoSuchElementError):

• 발행물: 잘못된 로케이터, 타이밍 또는 요소 부재로 인해 테스트에서 요소를 찾지 못했습니다.
• 해결 방법 :
  • 위치 확인: Appium Inspector를 사용하면 취약한 XPath에서 안정적인 로케이터(예: 접근성 ID, 고유 ID)를 정확하게 식별할 수 있습니다.
  • 대기 전략: 다음을 사용하여 명시적 대기를 구현합니다. 브라우저.waitUntil(), 요소.waitForExist()및 요소.표시 대기() 요소의 존재와 상호작용을 보장합니다.

JavaScript 

기다리다 브라우저.waitUntil(비동기 () => {
    return (기다리다 $('//*[@text="로그인 버튼"]').표시됨());
}, { 시간 제한: 10000, 시간 초과 메시지: '10초 후에 로그인 버튼이 표시될 것으로 예상됩니다.' });
기다리다 $('//*[@text="로그인 버튼"]').딸깍 하는 소리();

• • 응용 프로그램 상태: 앱이 요소가 존재할 것으로 예상되는 상태(예: 탐색 완료, 방해가 되는 팝업 없음)에 있는지 확인하세요. 

4. 세션이 생성되지 않았습니다(세션이 생성되지 않음 예외): 

• 발행물: Appium은 새로운 자동화 세션을 시작하지 못하는 경우가 많은데, 이는 종종 잘못된 기능이나 충돌하는 기능으로 인해 발생합니다.
• 해결 방법 : 
  • 검토 기능: 주의 깊게 확인하세요 wdio.conf.js 기능: 잘못된 절대 앱 경로; 일치하지 않음 장치 이름 or 플랫폼 버전; 잘못된 앱 패키지/번들 ID or 앱 활동; 누락/잘못됨 자동화 이름.
  • Appium 서버 로그 확인: Appium 서버 콘솔은 세션 생성 실패에 대한 자세한 이유를 제공합니다.
  • 앱 권한 : appium:autoGrantPermissions: true (Android) 또는 appium:autoAcceptAlerts: 참 (iOS) 앱 실행 시 권한이 필요한 경우. 

5. 불안정한 테스트(간헐적 실패): 

• 발행물: 코드를 변경하지 않아도 테스트가 간헐적으로 통과하거나 실패합니다.
• 해결 방법 :
  • 강력한 대기: 정적을 대체하다 드라이버.일시 중지() 명시적이고 조건부 대기.
  • 동기화: 상호작용을 시작하기 전에 UI 안정성을 확보합니다(예: 로딩 스피너가 사라질 때까지 기다리는 경우).
  • 네트워크 대기 시간: 네트워크에 의존하는 앱의 경우 더 긴 시간 제한을 고려하세요.
  • 테스트 격리: 테스트가 독립적인지 확인하세요. noReset: 거짓, fullReset: 참및 드라이버.리셋()/드라이버.terminateApp()/드라이버.launchApp() 테스트 사이.
  • 안정적인 위치: 동적으로 변경되는 로케이터를 다시 평가합니다. 

6. iOS 실제 기기의 WebDriverAgent(WDA) 문제: 

• 발행물: WDA가 장치에서 빌드, 설치 또는 실행되지 않습니다.
• 해결 방법 : 
  • Xcode 서명: 정확한지 확인하세요 xcodeOrgId 및 xcodeSigningId Xcode에서 Apple Developer 계정을 올바르게 구성하고 기능을 활용하세요. 
  • 수동 WDA 빌드: Xcode에서 WebDriverAgentRunner 앱을 수동으로 빌드합니다(~/.appium/node_modules/appium-xcuitest-driver/node_modules/appium-webdriveragent/WebDriverAgent.xcodeproj). 
  • 신뢰 개발자: iOS 기기에서 다음으로 이동하세요. 설정 > 일반 > VPN 및 기기 관리 개발자 앱을 신뢰하세요. 

Appium Inspector 사용하기 

Appium Inspector는 장치/에뮬레이터에서 앱 UI를 검사할 수 있는 그래픽 인터페이스를 제공하여 요소를 식별하고, 속성을 탐색하고, 견고한 테스트에 필수적인 정확한 로케이터를 생성하는 데 도움이 됩니다. 

Appium 2.x에서 Appium Inspector를 사용하는 방법: 

1. Appium Inspector 다운로드: Appium Inspector GitHub 릴리스 페이지에서 독립 실행형 애플리케이션을 받으세요. 

2. Appium 서버 시작: 터미널에서 Appium 서버가 실행 중인지 확인하세요.  

강타
아피움 

3. Appium Inspector를 실행합니다. 다운로드한 애플리케이션을 엽니다. 

4. 연결 및 기능 구성:  

• 원격 호스트: 127.0.0.1 (로컬호스트).
• 원격 포트: 4723 (기본).
• 통로: 비워두거나 설정하세요 / (Appium 2.x 기본값).
• 원하는 기능 추가: 동일한 기능을 붙여넣습니다. wdio.conf.js (절대 앱 경로를 확인하세요). 예시(Android):  

JSON 

{
  "플랫폼 이름": "기계적 인조 인간",
  "appium:장치이름": "에뮬레이터-5554",
  "appium:플랫폼버전": "11",
  "appium:앱": "/path/to/your/eribank.apk",
  "appium:앱패키지": "com.experitest.ExperiBank",
  "appium:appActivity": ".로그인활동",
  "appium:자동화이름": "UiAutomator2"
} 

• 저장 기능(선택 사항): 나중에 빠르게 로딩할 수 있도록 기능 세트를 저장합니다. 

5. 세션 시작: "세션 시작"을 클릭하세요. Appium Inspector가 Appium 서버에 연결하여 기기/에뮬레이터에서 앱을 실행합니다. 

6. 요소 검사:  

• 앱의 스크린샷이 왼쪽에 나타납니다.
• 요소 위에 마우스를 올리면 오른쪽 창에 세부 정보(로케이터, 텍스트, 크기, 위치)가 표시됩니다.
• 클릭하여 요소 세부 정보를 강조 표시합니다.
• "검색" 상자를 사용하여 로케이터로 요소를 찾으세요.
• 행위: UI에서 직접 기본 작업(탭, 키 보내기, 지우기, 스와이프, 스크롤, 클릭)을 수행하여 유효성 검사를 수행합니다. 

7. 위치 찾기: 검사관의 주요 용도는 신뢰할 수 있는 위치 지정자를 확보하는 것입니다.  

• 우선 순위 : 접근성 ID > ID > 클래스 이름 > XPath. XPath는 최후의 수단으로 사용하고, 상대 및 특정 XPath를 선호합니다.
• 선택한 로케이터를 WebdriverIO 테스트 스크립트에 직접 복사합니다.

로깅 및 보고 

실패한 테스트를 디버깅하고, 테스트 모음 상태를 모니터링하고, 결과를 전달하려면 포괄적인 로깅과 효과적인 보고가 필수적입니다. 

1. Appium 서버 로그 

Appium 서버는 서버 측, 드라이버 또는 통신 문제를 디버깅하는 데 매우 귀중한 자세한 로그를 생성합니다. 

• 로그 접근: 터미널에 직접 인쇄됨 아피움 발사되었다.
• 다변: 로그 수준을 제어합니다. –로그 수준 (예 : appium –log-level 디버그).
• 타임 스탬프 : 추가 –로그-타임스탬프 더 쉽게 이벤트를 추적할 수 있습니다.
• 로그 필터링(Appium 2.x): 지원 –로그 필터 또는 민감한 정보를 삭제하기 위한 구성입니다. 

2. WebdriverIO 테스트 러너 로그 

WebdriverIO의 테스트 러너는 특히 사양 리포터를 사용하여 테스트 실행에 대한 세부 정보를 제공하는 콘솔 출력을 제공합니다. 

• console.log (): 테스트 스크립트 내에서 변수 값, 요소 상태 또는 디버그 메시지를 인쇄하는 데 사용됩니다. 이는 실행 중인 터미널에 나타납니다. npm에서 wdio 실행.
• WebdriverIO 로그 수준: 구성 wdio.conf.js 를 통해 로그레벨 속성(예: '정보', '디버그') 내부 작업 세부 사항을 제어합니다. 

3. 테스트 보고 

콘솔 로그 외에도 구조화된 테스트 보고서는 결과와 CI/CD 통합을 이해하는 데 필수적입니다. 

• HTML 리포터(예: wdio-json-html-리포터): 테스트 단계, 통과/실패 상태, 기간, 선택적 실패 스크린샷을 포함하여 사람이 읽을 수 있는 보고서를 생성합니다. 
• 얼루어 리포터(@wdio/얼루어-리포터): 다음을 포함하여 대화형 HTML 보고서를 생성하는 인기 있고 강력한 리포터:
  • 테스트 단계 및 상태
  • 테스트 데이터
  • 스크린샷(특히 실패 시)
  • 첨부 파일(예: 페이지 소스, 네트워크 로그)
  • 역사적 경향
  • 결함에 대한 범주.
  • 설정(예):
    • 설치 :  

강타 
npm install --save-dev @wdio/allure-reporter allure-commandline 

• • • 구성 wdio.conf.js:  

JavaScript 

// wdio.conf.js
const를 내보내다 구성={
    // ...
    기자[
        '투기', // 콘솔 출력 유지
        ['매력', {
            출력 디렉터리: './allure-results', // Allure XML 데이터 디렉토리
            disableWebdriverStepsReporting: 참된, // 선택 사항: 단계 중복을 방지하세요
            disableWebdriver 스크린샷 보고: 그릇된, // 스크린샷 캡처
        }],
    ],
    // ...
    // Allure에서 실패 시 스크린샷을 캡처하기 위해 `afterTest` 후크를 추가합니다.
    테스트 후: 비동기 함수(테스트, 컨텍스트, { 오류, 결과, 기간, 통과, 재시도 }) {
        if (!통과) {
            기다리다 브라우저.스크린샷 찍기(); // WebdriverIO가 Allure에 자동으로 연결됩니다.
        }
    },
    // ...
}; 

• • • HTML 보고서 생성(테스트 실행 후):  

강타 

npx allure allure-results --clean -o allure-report를 생성합니다.
npx allure 오픈 allure-report 

이렇게 하면 HTML 보고서가 생성되어 브라우저에서 열립니다. 

• • CI/CD 통합: CI/CD 파이프라인(Jenkins, GitLab CI, GitHub Actions, Azure)에 테스트 보고서 통합 DevOps) 플러그인이나 내장 기능을 사용하여 JUnit XML이나 Allure 보고서를 구문 분석하고, 추세를 표시하고, 실패 시 알림을 보냅니다. 

이러한 디버깅 도구를 체계적으로 사용하고, 일반적인 함정을 이해하고, 포괄적인 로깅 및 보고를 활용하면 Appium 자동화 제품군의 안정성과 유지 관리성이 크게 향상됩니다.

Appium JavaScript를 다른 도구와 통합 

Appium JavaScript 테스트를 CI 도구, 고급 보고 및 클라우드 테스트 플랫폼과 통합하면 실행, 피드백 및 확장성이 향상됩니다. 

지속적인 통합 도구 

지속적 통합(CI)은 중앙 저장소에 코드를 자주 병합하고, 자동화된 테스트를 실행하여 통합 문제를 조기에 감지하는 것을 의미합니다. Appium 테스트를 CI 파이프라인에 통합하면 지속적인 모바일 애플리케이션 검증과 신속한 회귀 감지가 보장됩니다. 

CI 서버의 일반적인 프로세스는 다음과 같습니다. 

1. 풀 코드: 버전 제어에서 테스트 자동화 코드를 가져옵니다.
2. 설치 종속성: Node.js, Appium 및 프로젝트 npm 종속성을 설치합니다.
3. Appium 서버 시작: Appium을 로컬에서 실행하거나 원격/클라우드 서버에 연결합니다.
4. 장치/에뮬레이터 준비: CI 에이전트를 구성하여 Android AVD, iOS 시뮬레이터를 실행하거나 클라우드 플랫폼에서 실제 장치를 프로비저닝합니다.
5. 테스트 실행: WebdriverIO 테스트를 실행하려면 다음을 사용하세요. npm에서 wdio 실행.
6. 보고서 생성: 실행 후 테스트 보고서(예: Allure, JUnit XML)를 게시합니다. 

CI 도구 통합의 예: 

• 젠킨스:
  • 플러그인 : Node.js, Allure 보고서 게시, Android 에뮬레이터 관리(종종 셸 스크립트를 통해)를 위해 플러그인을 사용합니다.
  • 파이프라인 스크립트(선언적):  

그루비 

파이프라인 {
    에이전트
    단계 {
        단계('점검') {
            단계 {
                자식 'https://github.com/your-repo/your-appium-project.git'
            }
        }
        단계('종속성 설치') {
            단계 {
                sh 'npm 설치'
            }
        }
        단계('Appium 및 에뮬레이터 시작(Android 예제)') {
            // 이것은 종종 백그라운드 프로세스나 전용 에이전트에서 실행됩니다.
            // 단순화를 위해 기본 셸 명령을 표시합니다.
            // 실제로는 별도의 전담 에이전트나 클라우드 공급자를 사용할 수도 있습니다.
            단계 {
                // Android 에뮬레이터 실행(에이전트에 Android SDK 필요)
                // 예: 백그라운드에서 AVD 시작
                sh '에뮬레이터 -avd -no-audio -no-window &> /dev/null &'
                sh 'adb 장치 대기'
                sh '아피움 &' // Appium 서버를 백그라운드에서 시작합니다.
                sh '10시간 자다' // Appium이 시작할 시간을 줍니다.
            }
        }
        단계('Appium 테스트 실행') {
            단계 {
                sh 'npm에서 wdio 실행'
            }
        }
        단계('보고서 생성 및 게시') {
            단계 {
                sh 'npx allure allure-results --clean -o allure-report'
                매력([
                    속성 포함: 그릇된,
                    JDK: '',
                    속성: [],
                    보고서빌드토큰: [],
                    보고자: '얼루어 리포트'
                ])
            }
        }
    }
    우편 {
        언제나 {
            // 정리(에뮬레이터, Appium 서버 종료)
            sh 'adb emu kill || true'
            sh '킬올 노드 || 참' // 주의: 모든 노드 프로세스를 종료합니다.
        }
    }
}

• GitLab CI/CD:
  • 용도 .gitlab-ci.yml 파일 및 Docker 이미지 활용(예: 마디: -황소의 눈 또는 Appium/Android SDK를 사용한 사용자 정의 이미지).
  • 예시 .gitlab-ci.yml 단편:  

얌 

영상: 노드:18-불스아이 # 또는 Android SDK 및 Appium을 사용한 사용자 정의 이미지

변수:
  안드로이드 SDK 루트: "/opt/android-sdk" # Docker 컨테이너 내부 경로 

스크립트 이전:
  - apt-get update && apt-get install -y --no-install-recommends openjdk-11-jre-headless 압축 해제 curl
  # Android SDK 다운로드 및 설정
  - if [ !-d "$ANDROID_SDK_ROOT" ]; 그런 다음 mkdir -p $ANDROID_SDK_ROOT && curl -o $ANDROID_SDK_ROOT/cmdline-tools.zip https://dl.google.com/android/repository/commandlinetools-linux-858302-latest.zip && $ANDROID_SDK_ROOT/cmdline-tools.zip 압축 해제 -d $ANDROID_SDK_ROOT/cmdline-tools; fi
  - PATH=$PATH:$ANDROID_SDK_ROOT/cmdline-tools/최신/bin:$ANDROID_SDK_ROOT/cmdline-tools/최신/lib:$ANDROID_SDK_ROOT/플랫폼-도구를 내보냅니다. 
  - 예 | sdkmanager --라이선스
  - sdkmanager "플랫폼;안드로이드-30" "플랫폼-도구" "빌드-도구;30.0.3" "에뮬레이터" "시스템-이미지;안드로이드-30;구글_API;x86"
  - 에코 아니 | avdmanager avd -n test_avd -k "시스템 이미지; android-30; google_apis; x86"을 생성합니다.
  - npm 설치 -g appium@next # Appium CLI 설치
  - appium 드라이버 설치 uiautomator2 # 안드로이드 드라이버 설치
  - npm 설치 # 프로젝트 종속성 설치

테스트:appium:
  단계: test
  스크립트:
    - 에뮬레이터 -avd test_avd -no-window -no-audio -gpu 끄기 &
    - adb 장치 대기
    - adb 쉘 입력 키 이벤트 82 # 화면 잠금 해제
    - 아피움 &
    - 잠 10 # Appium이 시작할 시간을 주세요
    - npm에서 wdio 실행
  아티팩트:
    경로 :
      - 매력-결과/ # Allure 보고서의 경우
      - 스크린샷/    # 스크린샷을 저장하면
    만료일: 1 주
  스크립트 이후:
    - npx allure allure-results --clean -o allure-report를 생성합니다.
    - $(jobs -p)를 죽입니다. 참된 # 백그라운드 프로세스 종료 

다른 CI 도구(GitHub Actions, Azure)와의 통합 DevOps, CircleCI)는 각자의 특정 구성 구문을 사용하여 유사한 패턴을 따릅니다.

테스트 보고 도구 

WebdriverIO의 리포터는 기본적인 인사이트를 제공하는 반면, 전문 도구는 더욱 풍부하고 상호 작용적이며 공유 가능한 대시보드를 제공합니다. 이러한 대시보드는 데이터를 집계하고, 과거 추세를 보여주고, 실패를 분류하고, 자세한 아티팩트를 포함합니다. 

• 얼루어 리포트: (디버깅 및 문제 해결에서 다루어짐)
  • 이유 : 협업과 커뮤니케이션에 매우 적합한 단계, 첨부 파일, 추세 및 분류된 결함을 포함한 높은 상호 작용성의 HTML 보고서입니다.
  • 완성: 사용 @wdio/얼루어-리포터 및 allure-명령줄 XML 데이터로부터 보고서를 생성합니다.
• 보고서 포털:
  • 이유 : AI 기반 분석을 통해 신속한 실패 분석, 유사한 결함에 대한 자동 분석, 실시간 대시보드를 제공합니다.
  • 완성: 사용 @reportportal/agent-webdriverio 서버 URL과 API 키로 구성된 WebdriverIO 리포터로서.
• 맞춤형 HTML/대시보드 솔루션: 고유한 요구 사항에 따라 WebdriverIO에서 JUnit XML 또는 JSON 출력을 처리하여 사용자 정의 보고서를 생성하거나 데이터를 내부 대시보드로 푸시합니다. 

효과적인 테스트 보고는 다음과 같은 경우에 중요합니다. 

• 더 빠른 디버깅: 풍부한 맥락을 바탕으로 실패 원인을 빠르게 파악합니다.
• 유행 분석: 시간 경과에 따른 테스트 모음의 안정성과 성능을 모니터링합니다.
• 이해관계자 커뮤니케이션: 명확하고 이해하기 쉬운 보고서를 제공합니다.
• 품질 게이트: CI/CD 파이프라인에 대한 메트릭 정의.

클라우드 테스팅 플랫폼 

클라우드 플랫폼에서 모바일 자동화 테스트를 실행하는 것은 광범위한 기기 커버리지, 확장 가능한 병렬 실행, 그리고 사내 기기 랩 오버헤드 감소를 위한 표준입니다. 이러한 플랫폼은 다양한 실제 기기와 에뮬레이터/시뮬레이터를 제공합니다. 

작동 방식 : WebdriverIO 테스트는 클라우드 플랫폼에서 호스팅되는 원격 Appium 서버에 연결되며, wdio.conf.js에 공급자의 허브 URL과 특정 기능(API 키/사용자 이름 포함)을 사용하여 장치를 선택하고 클라우드 Appium 세션을 트리거합니다. 

Digital.ai Appium JavaScript를 위한 클라우드 테스트 플랫폼 테스트: 

• 특징: 실제 장치 클라우드, 에뮬레이터, 엔터프라이즈 통합을 포함한 모바일 앱 테스트를 위한 강력한 플랫폼으로, 기능, 성능, 접근성에 중점을 둡니다.
• 완성: 고유한 액세스 키를 사용하여 특정 URL을 통해 클라우드 그리드에 연결하고 장치와 환경을 정의합니다. 

Benefits of Digital.ai 테스트 : 

• Deployment 옵션: 온프레미스 장치, 전용 프라이빗 클라우드 장치 또는 하이브리드 옵션을 통해 비교할 수 없는 보안과 안정성을 확보하세요.
• 확장성: 다양한 장치에서 병렬로 테스트를 실행하여 실행 시간을 대폭 줄입니다.
• 장치 적용 범위: 물리적인 소유 없이 다양한 기기와 OS 버전에 액세스하세요. 공유 기기를 통해 필요에 따라 빠르게 확장할 수 있습니다.
• 유지관리 및 업데이트: Digital.ai 테스트는 장치 유지 관리, OS 업데이트, Appium 서버 관리를 처리합니다.
• 글로벌 액세스: 인터넷에 연결된 곳이라면 어디서든 테스트해 보세요.
• 고급 분석 : 성능 지표와 클라우드 리소스 사용량을 위한 통합 대시보드.

Appium JavaScript 모범 사례 

효과적인 Appium 자동화를 개발하려면 구조화, 성능 최적화 및 모범 사례를 따라야 합니다. safe내구성, 유지관리성, 신뢰성을 보장하기 위해 불안정성을 방지합니다.

테스트 모음 구성 

잘 구성된 테스트 스위트는 이해, 유지 관리 및 확장이 더 쉽습니다. 주요 패턴과 원칙은 다음과 같습니다. 

1. 페이지 객체 모델(POM): 

• 개념: UI 요소(로케이터)와 상호작용(메서드)을 테스트 로직에서 분리합니다. 각 앱 페이지/구성요소는 자체 JavaScript 클래스를 갖습니다.
• 이점:
  • 유지보수성: 한 곳에서 로케이터를 업데이트하세요.
  • 가독성 : 높은 수준의 명확한 테스트 단계.
  • 재사용 성: 페이지 객체 메서드는 재사용 가능합니다.
• 구현 예:  

JavaScript 

// 페이지/LoginPage.js
수업 로그인 페이지 {
    얻을 사용자 이름 입력() {
        return $('~사용자 이름 입력 필드'); // 접근성 ID 또는 기타 안정적인 로케이터
    }

    얻을 비밀번호 입력() {
        return $('~비밀번호 입력 필드');
    }

    얻을 로그인 버튼() {
        return $('~로그인 버튼');
    }

    비동기 열 수() {
        // 필요한 경우 로그인 화면으로 이동하거나 초기 앱 상태를 처리합니다.
        기다리다 브라우저.url('/'); // 웹 컨텍스트에 대한 예, 모바일 앱 흐름에 맞게 조정
    }

    비동기 로그인(사용자 이름, 비밀번호) {
        기다리다 이.usernameInput.setValue(사용자 이름);
        기다리다 이.passwordInput.setValue(비밀번호);
        기다리다 이.로그인버튼.클릭();
    } 

    비동기 로그인 버튼이 표시됨() {
        return 이.loginButton.isDisplayed();
    }
}
기본값으로 내보내기 로그인페이지(); // 인스턴스 내보내기

// 테스트/사양/login.e2e.js
import 로그인 페이지 에 '../페이지/로그인페이지';
import 홈페이지 에 '../페이지/홈페이지'; // HomePage 객체가 있다고 가정합니다.

설명하다('로그인 기능', () => {
    beforeEach(비동기 () => {
        기다리다 로그인페이지.open(); // 각 테스트 전에 로그인 페이지에 있는지 확인하세요.
    });

    그것('사용자가 유효한 자격 증명으로 로그인할 수 있도록 허용해야 합니다', 비동기 () => {
        기다리다 로그인페이지.로그인('표준_사용자', '비밀_소스');
        기다리다 expect(홈페이지.제품헤더).toBeExisting(); // 로그인 성공 확인
    });

    그것('잘못된 자격 증명에 대한 오류를 표시해야 함', 비동기 () => {
        기다리다 로그인페이지.로그인('잘못된 사용자', '잘못된 비밀번호');
        const를 오류 메시지 = 기다리다 $('~오류 메시지 텍스트'); // 오류 메시지 예시
        기다리다 expect(errorMessage).toBeExisting();
        기다리다 expect(오류 메시지).toHaveText('잘못된 자격 증명');
    });
}); 

2. 모듈형 테스트 파일: 테스트를 더 작고 집중적인 파일로 분할합니다(예: 로그인.spec.js, 제품.spec.js)을 사용하면 관리가 더 쉬워집니다. 

3. 도우미/유틸리티 기능: 데이터 생성과 같이 페이지에 국한되지 않은 일반적인 재사용 가능한 기능에 대해 별도의 파일을 만듭니다.utils/dataGenerator.js), 대기 도우미 (utils/waitHelpers.js), 또는 보고 도우미(utils/reportingHelpers.js). 

4. 구성 관리: 구성(기능, URL, 자격 증명, 시간 초과)을 중앙 파일(예:)로 외부화합니다. wdio.conf.js, .env 파일 또는 JSON 구성). 민감하거나 동적 데이터에는 환경 변수를 사용하세요.

성능 최적화하기 

느린 테스트는 자동화 이점을 저해합니다. Appium 테스트 성능을 최적화하는 것이 중요합니다. 

• 스마트한 대기 전략:
  • 피하 드라이버.일시 중지() / 절전(): 하드코딩된 대기로 인해 테스트가 느리고 불안정해집니다.
  • 명시적 대기 사용: WebdriverIO가 제공합니다 요소.waitForExist(), 요소.표시 대기(), 요소.waitForEnabled()및 브라우저.waitUntil() 신뢰할 수 있는 조건 기반 대기를 위해. 

 

JavaScript 

// 대신: 기다리다 드라이버.일시 중지(5000);
기다리다 $('~로그인 버튼').표시 대기({ 시간 제한: 10000, 시간 초과 메시지: '10초 후 로그인 버튼이 표시되지 않습니다' });
기다리다 $('~로그인 버튼').딸깍 하는 소리(); 

• 최적의 위치 전략:
  • 안정적인 로케이터를 우선시하세요: 접근성 ID를 먼저 사용하고, 그다음 ID를 사용하세요. 클래스 이름은 빠르지만 고유하지 않은 경우가 많습니다. XPath는 가장 느리고 취약합니다. 상대 XPath를 사용하는 것이 좋으며, 최후의 수단으로만 사용하세요.
• Appium 명령 줄이기:
  • 각 명령은 오버헤드를 발생시킵니다. 요소 참조를 재사용하여 중복 쿼리를 최소화하세요.
  • 반복적인 조회를 줄이려면 일괄 작업이나 페이지 객체를 디자인하세요.
• 앱 상태 관리(기능):
  • 재설정 안 함 및 전체 재설정: noReset: 참 세션 간에 앱 상태가 재설정되는 것을 방지하여 깨끗한 시작이 필요하지 않은 테스트 속도를 높입니다. fullReset: 참 새로 시작할 때 데이터를 다시 설치하거나 지우지만 속도가 느립니다.
  • 전략적 활용 드라이버.launchApp(), 드라이버.앱 닫기(), 드라이버.리셋(): 효율성을 위해 테스트 내에서 앱 수명 주기를 제어합니다.
• 병렬 실행 : WebdriverIO를 통해 여러 장치/에뮬레이터/시뮬레이터에서 동시에 테스트를 실행합니다. 기능 배열 및 –최대 인스턴스총 실행 시간이 대폭 단축되었습니다.
• 불필요한 스크린샷/로깅을 피하세요: 과도한 캡처/로그는 오버헤드를 증가시킵니다. 실패 시에만 캡처하도록 리포터를 구성하세요.
• 애니메이션 비활성화(가능한 경우): Android에서 개발자 옵션 애니메이션을 비활성화하면 UI 전환 속도가 빨라지고, 불안정성과 테스트 시간이 줄어듭니다. 

테스트 신뢰성 보장 

불안정한 테스트(간헐적인 실패)는 생산성을 크게 저하시킵니다. 따라서 신뢰성 확보가 무엇보다 중요합니다. 

• 강력한 명시적 대기(재검토): 항상 액션을 취하기 전에 요소가 상호작용할 때까지 기다리세요. 의미 있는 정보를 제공하세요. 시간 초과 메시지 디버깅을 위해.
• 안정적인 위치 지정자(재검토): 동적 ID나 손상되기 쉬운 중첩된 XPath는 피하세요. 접근성 ID나 고유 리소스 ID를 우선시하세요.
• 동적 요소 처리: 브라우저.기다릴 때까지 나타나거나 사라지거나, 텍스트가 변경되거나, 순서가 변경되는 요소에 대한 사용자 지정 조건을 제공합니다. 목록의 요소를 반복합니다.
• 오류 처리 및 재시도:
  • Try-Catch 블록: 정상적으로 실패할 수 있는 중요한 작업(예: 예상치 못한 팝업)을 구현합니다.
  • 테스트 재시도: WebdriverIO를 사용하면 재시도를 구성할 수 있습니다. wdio.conf.js 불안정한 테스트의 경우, 임시방편으로 재시도가 활성화되어 있더라도 근본 원인을 조사하고 해결하세요. 

 

JavaScript 

// wdio.conf.js
const를 내보내다 구성={
    // ...
    명세서[
        './test/specs/**/*.js'
    ],
    최대 인스턴스: 10,
    // ...
    // 테스트가 실패할 경우 재시도되는 횟수
    // 재시도: 1, // 예: 실패한 테스트를 한 번 재시도합니다.
    // ...
}; 

• 분리 검사: 테스트는 독립적이어야 합니다. 각각 전에 깨끗한 상태 설정을 위한 후크 및 각각 이후 청소를 위해.
• 자주 그리고 의미 있게 주장하세요: 모든 중요한 작업 후에 예상되는 상태를 단언하세요. 명확한 단언 메시지(예: expect(element).toHaveText('대시보드에 오신 것을 환영합니다')).
• 일관된 테스트 데이터: 안정적이고 알려진 테스트 데이터를 사용하세요. 설정을 위해 데이터 생성기나 API 호출, 또는 모의 데이터를 고려하세요.
• 정기 유지 보수 : 테스트 스위트는 지속적인 유지 관리가 필요합니다. 로케이터를 정기적으로 업데이트하고, 이전 테스트를 리팩토링하고, 오래된 테스트를 제거하세요.
• CI/CD 실행 모니터링: CI/CD 파이프라인을 면밀히 관찰하고, 지속적으로 발생하는 실패를 즉시 해결하고, 회귀나 성능 병목 현상에 대한 추세를 분석합니다. 

맺음말 

축하합니다! 이제 JavaScript와 최신 WebdriverIO 프레임워크를 사용하여 강력한 Appium 모바일 자동화 테스트를 설정하고 실행할 준비가 되었습니다. Appium의 아키텍처, 고급 기능, 효율적인 테스트 구조화 및 성능 최적화를 이해하면 흔히 발생하는 문제를 해결하여 안정성을 확보할 수 있습니다. 이제 CI/CD 파이프라인에 완벽하게 통합된 확장 가능한 모바일 테스트 자동화 제품군을 구축, 디버깅 및 유지 관리하여 지속적인 품질 보증을 실현할 준비가 되었습니다.