자동화 된 GUI 테스트 : 중간에 우리를 만나십시오

https://stackoverflow.com/questions/822275

03-07-2019
|

문제

자동화 된 GUI 테스트 시스템을 개발하는 임무를 맡았으며 조언을 사용할 수 있습니다. 운 좋게도, 우리는 GUI의 주요 재 설계의 한가운데에 있으며 작업을 수행하는 개발자는 코드를 자동화에 더 친숙하게 만들 수 있습니다. 내 문제는 무엇을 추가하도록 요청 해야할지 잘 모르겠다는 것입니다. 추가 된 후크가 추가되면 인터페이스의 기능, 모양 또는 보안에 영향을 줄 수 없으며 성능에 눈에 띄는 영향을 미치지 않아야합니다. 그 외에는 하늘이 한계입니다!

문제의 응용 프로그램은 AJAX를 통해 액세스하는 웹 기반 Java 앱입니다. 기존 기능의 대부분은 JSP, JavaScript 및 약간의 플래시 8을 사용하여 코딩됩니다. 다음 기능의 다음 물결은 다음을 사용하여 수행됩니다. Yui JavaScript 라이브러리. 나는 거의 정착했다 셀렌 유연성과 가격표 (무료)로 인해 테스트 도구로. 주요 요점 : 저는 테스트 재사용 성과 유지 보수 용이성을 목표로하고 있습니다. 내가 선호하는 것은 테스트 개발을 위해 레코드 및 플레이 백 시스템을 사용하지 않고 페이지 요소를 감지, 검증 및 연습하는 코드를 작성하는 것입니다.

누구나 테스트 개발을보다 쉽게하고 테스트 자체를보다 강력하게 만들기 위해 코드에 어떤 훅을 배치 할 수 있는지에 대한 지침을 제공 할 수 있습니까?

해결책

기본 지침 원리 : 그들이 당신이 무언가를 테스트하기를 원한다면, 테스터는 해당 상태로 신청서를 가져 오는 방법이 필요하며, 해당 주에서는 상태가 올바른지 확인하는 방법이 필요합니다.

따라서 첫 번째는 자동화가 프로그래밍이고 UI가 API임을 이해하는 것입니다.

UI를 임의로 변경하지 않기위한 동의 - 테스터 Bob이 구성 요소가 버튼에서 링크로 변경된 것을 확인하고 사양과 일치하고 클릭하고 계속됩니다. 자동화의 비교적 쉬운 코드 변경이지만 여러 위치에서 이루어져야 할 수있는 변경 사항입니다. (테스터로서의 직업은 변화가 발생한다는 것을 이해하고 유지 보수 비용을 최소화하는 것입니다. 그들의 임무는 중요한 변화를하고 그 영향을 이해하는 것입니다)
당신이있는 페이지를 결정하는 방법 .... Bob은 로그인과 주문 항목의 차이점을 알 수 있지만 자동화는 어떻게 알 수 있습니까? '사용자 이름'레이블이있는 Enter 필드 인 경우 로그인 페이지입니다. 주문 번호가있는 입력 필드 인 경우 주문 필드.

좋지 않습니다. 더 나은 연습은 페이지 제목, 숨겨진 구성 요소 등 페이지를 식별하는 일관된 UI 요소입니다.

input_42가 아닌 상호 작용 해야하는 모든 요소 (클릭, 입력, 확인 등)를 고유하게 식별하는 방법 ....
개발자에게 테스터가 디버깅 속도 속도를 높이기 위해 어떤 정보를 제공 할 수 있는지, 로그 파일에 넣도록 요청하십시오.
프로그램 상태를 덤프하는 능력
일관된 오류 처리 및보고 (또한 우수한 UI 디자인)

다른 팁

대부분의 질문과 마찬가지로, 그것은 달라집니다. 주로 사이트의 모습과 페이지에 어떤 종류의 컨트롤이 있습니다. 반복되는 요소 등이 많습니까?

나는 Selenium RC와 Selenium IDE를 사용하여 많은 성공을 거두었습니다. 가장 중요한 것은 셀레늄과 그 명령을 사용하는 데 익숙해지는 것입니다. 또한 페이지 (XPaths 및 CSS Selectors, 'Contains'기능)에서 개체를 찾는 데 사용되는 것도 도움이됩니다. 당신이 원하지 않는 것은 동일한 선택 경로를 가진 많은 요소입니다. 아래 테이블과 div가 고유 한 부분이 없으면 테스트에 추가 복잡성을 더할 수 있습니다.

<html>
  <body>
    <table>
      <tr>
        <td>
          <div></div>
          <div></div>
          <div></div>
        </td>
      </tr>
    </table>
    <table>
      <tr>
        <td>
          <div></div>
          <div></div>
          <div></div>
        </td>
      </tr>
    </table>
  </body>
</html>

이미지를 테스트하려면 이미지 파일 이름 이외의 다른 것을 기반으로 존재를 확인할 수 있으므로 이미지가 업데이트 될 때 테스트를 변경할 필요가 없습니다. 플래시 객체를 테스트 해야하는 경우 이 사이트를 확인하십시오.

그 외에도 개발 측면에 통합 될 수있는 것을 알았습니다. 페이지에서 테스트를 설정하고 요소를 찾기 시작하면 개발자가 도움을주기 위해 개발자가해야 할 일을 매우 빨리 알 수 있습니다.

한 가지 조언 : 테스트 코드를 최소 2 층의 추상화 층:

상단 계층: 이것은 특정 응용 프로그램 용어/행동 등을 향한 일종의 외관이어야합니다.이 레이어 하지 않습니다 셀레늄 RC 라이브러리를 직접 사용하십시오. 백그라운드에서 그것은 ...
... 하부 레이어: 일반적인 테스트 패턴이있는 라이브러리 (예 : "라디오 버튼 컨트롤의 x 값이 선택되었다고 주장합니다.셀레늄 RC 라이브러리를 사용하는 ").

이렇게하면 테스트가 테스트되는 내용 측면에서 테스트가 더 깨끗하고 더 이해할 수 있습니다. 우리는 심지어 3 층 접근법을 시도했습니다 XML을 사용하여 지정된 세 번째 (상단) 층. 이는 비 프로그래밍 테스터가 C# 코드를 탐색하지 않고 수락 테스트를 지정할 수있는 것이 었습니다.

McWafflestix 및 S_Hewitt의 의견에 추가하려면 GUI 요소는 GUI 자동화를 통해 성공할 수 있도록 적절하게 태그를 지정하고 독특하며 예측할 수 있어야합니다. 요소 ID를 예측할 수없는 경우 문제가 발생합니다. 예측 가능한 것이 반드시 정적을 의미하는 것은 아닙니다. 사용자 이름 필드 또는 로그인 버튼과 같은 정적 페이지 요소의 경우, 빌드에서 빌드 및 실행까지 정적/ID가 정적/ID가 될 것으로 예상됩니다. 확인란, 라디오 버튼, 동적 컨텐츠의 경우 동적이지만 예측 가능할 것으로 예상됩니다. 예를 들어, 클래스 = "contentDetail"과 id = "12345"가있는 div가있을 수 있습니다. XPath를 만들어 안정적으로 상호 작용하는 데 필요한 개체를 찾을 수있는 한, 당신은 좋을 것입니다.

편집 : DEVS가 테스트 자동화를 지원하는 가장 좋은 방법은 테스트 설정이 있습니다. 응용 프로그램에 따라 자동화 된 테스트 설정 및 분해는 문제가 될 수 있습니다. 예를 들어, 창고 워크 플로우 응용 프로그램에서 워크 플로 시작시 테스트 (창고에 항목을 허용)는 쉽게 설정할 수 있지만 워크 플로 끝의 테스트 (창고에서 고객에게 항목을 배송)는 SO가 있습니다. 대부분의 자동화 코드는 대부분의 자동화 코드가 앱을 탐색하고 입력하여 수행 할 수있는 지점으로 이동하는 데 도움이 될 수 있도록 많은 의존성 (품목이 충분한 수량, 충분한 수량, 올바른 재고 위치 등에 있어야합니다. 시험. 이 경우, 종속성을 주입하거나 데이터베이스를 알려진 상태로 재설정하기 위해 어떤 종류의 외부 유틸리티 (앱 외부, 메인 GUI가 영향을받지 않음)를 갖는 것이 유리할 수 있습니다. 창고 예에서 유틸리티가 API 수준을 통해 시나리오를 설정하여 자동화 된 GUI 테스트가 관련 시점에서 픽업 될 수 있습니다.

개발자가 코드에 추가 할 수있는 것은 거의 없습니다.

문제는 코드 경로의 실행과 해당 코드 경로의 유효성을 테스트하려면 단위 테스트에서 수행해야하며 GUI와 완전히 이혼해야한다는 것입니다. 그러나 실제로 GUI를 테스트하고 싶다면 사용자 입력을 시뮬레이션해야합니다. 이에 도움이 될 수있는 한 가지는 객체와 제어를 올바르게 태그로 만들어 테스트 프레임 워크에 의해 올바르게 감지되고 운동을 할 수 있도록하는 것입니다. 그 외에는 할 수있는 일이 많지 않습니다 (그 자체로는 도움이 될 수 있지만).

나는 (적절한) 단위 테스트에 꽤 녹색이지만 GUI 테스트를 피해야한다는 몇 가지 언급을 통해 달려갔습니다. 그들은 보통 특정 이유를 생략하므로 실제로 백업 할 수는 없습니다.

내가 취하는 접근법 (그리고 "Programming .NET 구성 요소"에서 Juval Lowy가 조언 한 접근 방식은 인터페이스를 통해 GUI의 실제 코드를 시도하고 추상화하는 것입니다. 실제로 GUI 자체를 테스트하지 않고 GUI.

그것은 꽤 잘 작동하며 GUI에서 비즈니스 로직을 크게 분리하여 더 깨끗한 코드를 만들었으며 GUI 수정을 크게 스트레스를 줄였습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow