0

저는 개발중인 자동화 스크립트 중 하나에 Ruby Selenium-Webdriver를 사용하고 있었고 페이지 객체를 사용하라는 요청을 받았지만 페이지 객체를 많이 사용합니다. application 나는 CSV 파일을 대신 사용하고 있는데, CSV 파일의 응용 프로그램에서 사용하고있는 모든 xpath를 정의했고 그 객체를 참조하기 위해 내 CSV 파일을 구문 분석하고 있습니다. 알고 싶습니다. 페이지 객체 정의를위한 클래스 사용이나 성능 문제를 제외하고 CSV 파일 사용의 차이점은 무엇입니까? 나는 CSV 파일을 사용하는 것이 구성의 관점에서 우리를위한 애드온이 될 것이며, 이것을 유지하는 것이 훨씬 쉽다고 주장한다.Page Object 대 Selenium의 설정 파일

편집 - 우리는 실제로 클라우드 기반 도구를 기반으로 구축 된 응용 프로그램을 자동화하고 있습니다. 따라서 기본적으로 모든 응용 프로그램은 HTML 관점에서 동일한 디자인 구조를 공유하므로 CSV에서 xpath 패턴을 정의한 다음 특정 매개 변수를 CSV를 사용하여 자동으로 xpath를 생성하기 위해 개발 한 일부 사용자 정의 메서드는 모든 응용 프로그램이 모든 요소에 대해 유사한 xpath 패턴을 공유한다는 것을 이미 알고 있기 때문에이를 수동으로 오버 헤드로 찾는 대신 CSV를 사용합니다.

감사합니다.

답변

0

완전히 실행할 수있는 응용 프로그램과 테스트 유형에 따라 다릅니다.

자동화 된 테스트 스크립트이기 때문에 스크립트 성능에 대해 실제로 걱정할 필요가 없습니다 (구문 분석하는 데 몇 밀리 초가 걸릴 수 있습니다.)

CSV 파일의 모든 요소 식별 속성 & 해당 작업을 유지하면 유지 관리가 쉬워지고 프레임 워크 응용 프로그램이 독립적으로 작동합니다. 그러나 프레임 워크를 유지 관리하는 것은 조금 더 어렵습니다. 두 접근법 모두 장단점이 있습니다.

게시물 아래를 참조하십시오 [예 자바에있는 -하지만 당신은 아이디어를 얻을 것] :

  1. Keyword driven framework
  2. Advanced Page Objects

업데이트 :

당신이 모두를 좋아하는 경우에, 당신은 쉽게 구현할 수있는 구현을 할 수 있습니다.

@ObjectRepository(src="/login.csv") 
public class LoginPage{ 

    private Map<String, WebElement> elements; 

    public void login(){ 
     elements.get("username").sendKeys(''); 
     elements.get("password").sendKeys(''); 
     elements.get("signin").click(); 
    } 
} 

즉, 페이지의 객체가 페이지 요소의 클래스를 참조하자 CSV/JSON 등과 같은 설정 파일의 모든 요소를 ​​정의합니다. 모든 메소드는 페이지 클래스의 일부가됩니다.

+0

이 글에 나는 당신이 동의한다. 내가이 글에서 편집 한 것을 보았을 때 당신의 조언은 무엇인가? 개요를 제공하기 위해 클라우드 기반 도구를 기반으로하는 응용 프로그램을 자동화하므로 모든 응용 프로그램이 HTML 관점에서 동일한 기본 구조를 공유하므로 CSV로 일반 xpath 패턴을 정의한 다음 사용자 정의 메서드를 사용하여 해당 CSV에 레이블을 전달합니다. 우리가 모든 애플리케이션에 대한 페이지 객체를 정의한다면 우리는 그 객체의 실제 xpath를 생성한다. 우리는 수동으로 그 객체들을 찾아야 만한다. – utkarshs

+0

@utkarshs, this를 주로 사용하고 앞으로 이것을 유지한다면, 그것이 당신의 안락 수준에있게하십시오. 내 업데이트 답변을 참조하십시오. – vins

3

제 생각에는 POM이 CSV 방식보다 낫습니다. POM에서는 페이지 요소를 별도의 클래스 파일에 넣습니다. 따라서 어떤 변경이 이루어지면 변경/유지할 위치를 찾는 것이 더 쉽습니다. 더욱이, CSV 파일처럼 너무 지저분 해지지 않으며, 구문 분석을 위해 추가 유틸리티 함수를 사용할 필요가 없습니다.

+0

실제로 우리의 유즈 케이스는 일반 웹 애플리케이션 자동화와 조금 다르다. ID의 클래스와 요소의 클래스에 의존하지 않는다. 새로 고침 할 때마다 변경되기 때문에 xpath의 유일한 옵션은 여기에 또 다른 캐치가있다. 우리가 다른 환경으로 응용 프로그램을 이동하자마자 해당 요소의 클래스도 바뀌므로 레이블을 사용하여 요소로 이동합니다. – utkarshs

2

webdriver/watir 이상의 라이브러리 세트를 제공하는 pageobjects gem이있어 코드를 단순화합니다.

왜 xpaths입니까? 요소를 식별하는 마지막 권장 방법 중 하나입니다.

프레임 워크 측면에서 csv는 PageObjects보다 유지 관리 문제가 더 중요합니다. 텍스트와 코드의 기본적인 차이점.PageObjects에서 요소에 대한 객체 지향 접근법을 적용하지만 csv에서는 불가능합니다.

최상의 시나리오에서는 xpath 요소가 속한 페이지를 정의하는 열/별도 시트를 작성했습니다. 오버 헤드처럼 들리네. 애플리케이션/제품군이 커짐에 따라 수천 가지 요소가있을 수 있습니다. 그런 종류의 데이터로 CSV를 파싱/수동으로 업데이트한다고 상상해보십시오.

PageObjects 대신 요소가 페이지로 제한됩니다. 앱을 변경하면 영향을받을 수있는 요소도 지정됩니다. 이제는 css가 아닌 PageObject에서 객체로 요소를 정의 할 때 csv를 읽고 명시 적으로 요소를 만들 필요가 없습니다.

+0

xpath로 이동하는 이유는 우리의 응용 프로그램이 동적 인 이유입니다. 페이지를 새로 고침 할 때마다 각 요소의 ID를 변경한다는 의미이며, 클라우드 기반 기술에서 DEV를 UART로 PROD로 마이그레이션하면 부서 클래스도 변경됩니다. – utkarshs

+0

We 're we 're 실제로 클라우드 툴을 기반으로 구축 된 애플리케이션을 자동화하여 모든 애플리케이션이 HTML과 관련하여 동일한 기본 구조를 공유하도록합니다. 우리는 페이지를 기반으로 요소를 찾을 필요가 없습니다. 왜냐하면 구조가 항상 환경에있는 어떤 응용 프로그램이라도 항상 동일 할 것이고 이것이 스크립트 개발을 가속화 할 이유입니다. CSV에서 xpath 패턴을 정의한 다음 실제 요소의 xpath를 즉석에서 생성합니다 CSV 파일을 사용하여 사용자 지정 메서드에 매개 변수 일부를 전달합니다. – utkarshs

관련 문제