게시 : 1 월 15, 2020
웹 및 모바일 테스트: 요소 찾기 방법
웹 자동화와 관련하여 모바일 테스트 핵심 아이디어는 실제 사용자 행동을 시뮬레이션하여 가능한 모든 사용 사례를 포괄하는 것입니다. 이는 주로 회귀 테스트 목적으로 사용됩니다. 이를 통해 새로운 기능을 도입하거나 버그를 수정하는 과정에 대한 확신을 얻을 수 있습니다. 핵심 목표는 이미 작동하는 기능을 손상시키지 않는 것입니다. 두 번째로 중요한 것은 최종 사용자 경험이 원활하고 문제 없이 유지되도록 하는 것입니다.
업계에서 가장 인기 있는 도구 크로스 브라우저 그리고 크로스 플랫폼 웹 및 모바일 자동화가 가능합니다. 셀레니움 아 피움 상응하게이 문서에서는 애플리케이션 컨트롤(버튼, 링크, 이미지, 텍스트 등)을 찾는 주요 전략을 다루므로, 상호 작용할 요소를 식별하는 올바른 방법을 파악할 수 있습니다.
우선, 요소란 무엇일까요? UI 테스트 자동화 분야에서 요소는 웹 또는 모바일 애플리케이션에서 상호작용(클릭, 호버링, 키보드/마우스/탭 이벤트 수신)이 가능한 가장 작은 단위입니다. 이미지나 텍스트 필드의 경우 요소의 존재 여부를 확인하는 것이 좋습니다. 애플리케이션 레이아웃을 테스트합니다. 따라서 Element는 기본적으로 HTML 또는 XML 요소이며 일반적으로 HTML 또는 XML입니다. 태그.
다음 코드 조각은 다음과 같습니다. <a id =“푸” href =“https://experitest.com”>전문가</a>
- a는 HTML입니다 태그 대표하는 하이퍼 링크
- @ID @href are HTML 속성 그리고 "foo"와 "https://experitest.com”는 각자의 가치입니다
- 전문가는 하이퍼링크 텍스트입니다
이제 이 링크를 "찾아서" 작업할 수 있는 방법(클릭하거나 속성이나 텍스트 값을 확인)을 살펴보겠습니다.
만약 당신이 o를 살펴보면org.openqa.selenium.By 수업 JavaDoc을 살펴보면 테스트 대상 애플리케이션에서 요소를 찾는 데 여러 가지 전략이 있다는 것을 알 수 있습니다. 주요 전략은 다음과 같습니다.
- Id
- CSS 셀렉터
- xpath
나머지 전략은 다음과 같습니다.
- 이름
- 클래스 이름
- 링크텍스트
- 부분 링크 텍스트
- 태그 이름
이는 자명한 사실이므로 추가 설명이 필요하지 않습니다.
그렇다면 ID, CSS, XPath, 이 세 가지 중 어떤 것을 선택해야 할까요? 전략들이 나열된 순서는 의도적으로 다음과 같은 이유로 선택되었습니다.
- ID – 요소를 찾는 가장 빠른 방법이며 리소스 측면에서 차지하는 면적은 최소화됩니다.
- CSS – 요소를 찾는 데 더 느리고 리소스 소모가 많은 옵션이지만 더 많은 유연성을 제공합니다.
- XPath – 가장 느리고 가장 "비싼" 옵션이지만 XPath는 거의 프로그래밍 언어이기 때문에 가장 강력한 옵션입니다.
웹 페이지 또는 모바일 애플리케이션에서 요소 세부 정보 가져오기
페이지 소스를 살펴보니
Selenium과 Appium WebDriver 구현 모두 지원을 도입하세요. getPageSource() 함수 현재 웹 또는 애플리케이션 페이지의 기본 HTML 또는 XML 레이아웃을 반환합니다. 이 함수의 출력을 파일에 저장한 다음 원하는 브라우저에서 파일을 열고 개발자 도구 요소를 검사하고 "흥미로운" 속성을 식별합니다.
웹페이지에서 브라우저 개발자 도구 사용
대부분의 최신 브라우저에는 페이지 소스에 대한 자세한 정보 확인, 특정 요소 검색, 웹 및 모바일 테스트 선택기, 디버깅 스크립트 등에 사용할 수 있는 개발자 도구가 포함되어 있습니다. 일반적으로 개발자 도구는 F12 버튼을 사용하여 열 수 있습니다. 열 수 없는 경우 브라우저 설명서를 참조하세요.
Appium Inspector 세션 사용
Appium Desktop 애플리케이션을 실행하면 페이지 소스와 요소 속성을 볼 수 있는 검사기 세션을 시작할 수 있습니다.
iOS에서는 다음과 같습니다.
안드로이드의 경우는 다음과 같습니다.
ID로 웹 및 모바일 테스트 요소 찾기
작업하려는 요소에 고유 ID 속성이 있으므로, 해당 요소를 찾는 가장 간단한 방법은 이 ID를 사용하는 것입니다. 다음 사항을 확인하세요.
- 이 ID를 가진 다른 요소가 없는 것처럼 Selenium 및/또는 Appium은 처음 찾은 요소와 함께 작동하며 반드시 그 요소가 아닐 수도 있습니다. ID가 사람이 읽기에 다소 쉬워 보이는지 확인해야 합니다. 예를 들어 <입력 id ="암호"/> 변경될 가능성이 없는 식별자인 것 같습니다. <입력 id =“id_j116”/>. 자동으로 생성될 수 있고 다음 애플리케이션 빌드/배포 또는 페이지 다시 로드 시 변경될 수 있으므로 의심스럽습니다.
ID 기반 선택자는 개발하기가 매우 쉽습니다.
- 웹 애플리케이션 – id 관련 HTML 요소의 속성
- 안드로이드 애플리케이션 – a 자원 ID 관련 XML 요소의 속성
- iOS 애플리케이션 - 관련 XML 요소의 명명된 속성
애플리케이션 요소에 ID가 없는 경우, 가장 좋은 방법은 애플리케이션 개발자에게 문의하여 가능한 경우 각 요소에 고유 식별자를 부여해 달라고 요청하는 것입니다. 분석에도 필요할 수 있습니다. 예를 들어 사용자 활동 추적과 같은 경우라면 개발자도 동의할 가능성이 높습니다.
CSS 선택자
요소 ID를 사용할 수 없는 경우에도 다음을 사용하여 요소를 찾을 수 있습니다. CSS 선택기. ID보다 느리고 CPU와 RAM 측면에서 더 많은 리소스를 소모하지만, 원하는 요소에 맞는 옵션이 훨씬 더 많습니다.
예를 들어, 무료 시험판 버튼 https://experitest.com/ 페이지는 다음과 같습니다:
무료 시험판
보시다시피 ID 속성은 없지만 다음을 사용할 수 있습니다. HREF 요소를 찾기 위한 속성 값의 경우 관련 CSS 선택자는 다음과 같습니다.
a[href="/ko/무료 체험판"]
다음과 같이 부분 일치를 수행할 수도 있습니다. a[href*="시험판"] 그리고 여전히 그 요소를 찾을 수 있습니다.
XPath 선택자
고유 ID도 없고 CSS 선택자도 사용할 수 없는 상황에서는 XPath를 고려해야 합니다. XPath는 가장 느리고 리소스를 많이 소모하지만 가장 강력한 옵션입니다. DOM에 대한 전체 접근 권한을 가지고 있어 사용할 수 있습니다. XPath 축 부모, 자식, 형제 등의 요소에 접근하려면 여러 표현식을 결합하고 기존 표현식을 사용합니다. XPath 연산자 및 함수 정확한 일치를 위해 기존 항목을 시나리오에 사용할 수 없는 경우 새 항목을 만들 수도 있습니다.
앞서 언급한 것과 같은 간단한 질의의 경우 무료 시험판 구문은 CSS와 거의 유사하며 동일한 요소 로케이터를 사용하여 일치시킵니다. HREF XPath 언어의 속성은 다음과 같습니다.
//a[@href='/무료 체험판']
동일한 요소와 일치하는 몇 가지 XPath 선택기:
- 링크를 찾으세요 무료 시험판 본문: //a[text()='무료 체험']
- 다음이 포함된 링크를 찾으세요. 무료 본문: //a[contains(text(), '무료')]
- 로 시작하는 링크를 찾으세요 무료 본문: //a[starts-with(text(),'무료')]
- 그리고 보너스. 없다. ~로 끝남() XPath 1.0의 함수이지만 기존 함수를 사용하여 동일한 기능을 구현할 수 있습니다. 다음으로 끝나는 링크를 찾으세요. 재판 본문: //a[substring(text(), string-length(text()) – string-length('TRIAL')+ 1, string-length(text()))= 'TRIAL']
XPath 표현식을 생각해내는 데 어려움이 있다면 다음을 잊지 마세요. 애피움 스튜디오. 장치/에뮬레이터, 프로비저닝 프로필, 녹음을 통한 테스트 코드 생성을 관리하는 간단하고 쉬운 시각적 방법을 제공하며 Object Spy는 다음을 수행할 수 있습니다. 고유한 XPath 생성 페이지의 요소에 대한 표현식을 사용하면 한 번의 클릭으로 로케이터를 만들 수 있습니다.
이제 어떤 요소 선택기를 사용해야 하는지, 각 선택기의 장단점, 기능 및 한계는 무엇인지 명확하게 이해하셨을 것입니다. 이 정보가 여러분의 작업을 더욱 편리하게 하고 웹 및 모바일 테스트를 더욱 강력하고 안정적으로 만들어 줄 수 있기를 바랍니다.
당신은 또한 좋아할 거라
접근성 조사 결과부터 Release 증거: WCAG 검사 결과가 이제 테스트 보고서에 포함되어 있습니다.
자동화된 접근성 테스트는 디지털 접근성 문제의 최대 57%를 식별할 수 있습니다.







