문서요약 - 5가지 테스트 자동화 프레임워크 유형에 따른 테스트 스크립트 작성 방법 by STH

제목: 5가지 테스트 자동화 프레임워크 유형에 따른 테스트 스크립트 작성 방법(How to Develop Test Scripts Using Top 5 Most Popular Test Automation Frameworks)

저자: Vijay, STH(Software Testing Help) 블로그

유형: 웹 문서(http://www.softwaretestinghelp.com/automation-testing-tutorial-5/), 2016년

 

 

테스트 자동화 프레임워크가 무엇인지에 대해 간단한 예를 들어 설명한 자료

---

 

스크립팅(Scripting)

테스트 자동화에서는 스크립트를 작성하게 되는데, 이 스크립팅이 아래 세 개 측면으로 구성된다.

 

1. 어레인지먼트(ARRANGEMENT) 또는 오브젝트 식별(Object Identification)

오브젝트(예, 버튼, 드랍다운 등)를 그 id, 이름, 또는 윈도우 타이틀을 통해 식별함

웹 애플리케이션의 경우 id, Xpath, CSS, 또는 클래스명(Class Name) 등을 통해 식별. 만일 이 중 어느 것도 안 먹히면 마우스 좌표를 사용하여 오브젝트를 식별(하지만 이게 오브젝트 식별의 신뢰할 만한 방법은 아님)

식별 후에는 이 오브젝트들을 스크립트에서 재사용하기 위해서 UIMaps 또는 Object Repository에 배치(arrange)/저장한다.

 

 

아래는 Selenium WebDriver(C#)에서 id를 사용해 오브젝트를 식별한 예(웹 애플리케이션).

 

아래는 MS 코드 UI의 오브젝트 식별 예(데스크탑 애플리케이션).

 

2. 식별된 오브젝트 상의 액션(ACTION)

오브젝트가 식별되면 마우스 또는 키보드를 사용해 어떤 액션을 수행한다.

예를 들어, 해당 오브젝트를 클릭하거나, 더블클릭하거나, 위로 마우스를 가져다 대거나, 또는 끌어놓기(drag drop)한다. 때때로 텍스트 박스에 뭔가를 쓰기도 한다. 즉, 해당 오브젝트 상에 수행하는 모든 종류의 액션이 이 두 번째 스텝에서 커버된다.

 

 

예) Selenium WebDriver(C#)

 

예) MS Coded UI(C#)

 

3. 어써션(ASSERTION)

어쎠션은 기본적으로 어떤 예상 결과(expected result)를 가지고 오브젝트를 확인하는 것이다. 예를 들어, 계산기 상에 2+3을 누르면 화면이 5를 보여주는데, 이 경우 예상 결과가 5이다.

 

 

아래는 어써션의 예이다.

 

 

완전한 스크립트 예

 

테스트 자동화에서 작성된 거의 모든 스크립트가 이 세 가지(어레인지먼트, 액션, 어써션)를 포함한다. 아래는 이 모든 스텝들을 포함하는 완전한 스크립트 예이다(계산기를 열고, 1 + 6을 누르고, 화면에 7이 나오는지 아닌지 확인하는 스크립트).

 

Example A:

 

위 테스트 스크립트의 문제점

위 스크립트는 이해하기는 쉽지만 유지보수가 용이하지 않은 단점이 있다. 만약 계산기의 각 기능에 대한 테스트케이스를 작성해야만 한다면, 많은 수의 테스트케이스가 나오게 될 것이다. 예를 들어, 10개의 테스트케이스가 있다면 이 각각에서 동일한 오브젝트를 정의해야 하며, 오브젝트의 이름 또는 id에 어떤 변경이 발생하면 10개의 테스트케이스에 있는 오브젝트 식별 부분을 모두 변경해야만 한다.

 

 

예를 들어, 스크립트에서 Add 버튼에 대한 아래의 코드 라인이 10개 테스트케이스에서 사용된다고 가정해보자.

 

계산기의 다음 버전에서 개발자가 버튼명을 “Add”에서 “Plus”로 변경한 경우, 테스트케이스들을 실행시키면 모두 실패하게 됨. 즉, 10개 테스트케이스에 있는 위 라인 부분을 아래처럼 일일이 변경해야만 한다.

 

개선된 스크립트

따라서 위 테스트케이스의 개선이 필요하다. 같은 코드가 반복되는 것을 피하도록 오브젝트 식별 부분이 작성되어야 함. 즉, 오브젝트가 단 한 장소에서만 식별되고, 그 외 다른 곳에서는 호출을 통해 사용되도록 만든다.

 

 

Example B:

 

위 예에서 calWindow와 txtResult 오브젝트를 분리해 상단으로 이동시키고, 이게 여러 다른 테스트 메쏘드에서 사용될 수 있도록 함(즉, 이 오브젝트들을 단 한번만 정의하고, 이게 원하는 만큼 많은 테스트케이스에서 사용될 수 있도록 만듬). 또한 두 개의 함수도 생성함. ClickButton()은 버튼명을 받아들여 여기에 클릭 액션을 수행하고, AddTwoNumbers()는 두 개의 수를 받아들이고 내부의 ClickButton 함수를 이용해 이를 더한다.

 

à 이렇게 코드를 개선하기 시작해 그것을 재사용 가능하고 유지보수 용이하게 만드는 것이 바로 자동화 프레임워크를 활용하기 시작하는 것을 의미한다.

 

 

 

테스트 자동화 프레임워크(test automation frameworks)

 

테스트 자동화 프레임워크는 유지보수가 용이한 방식으로 스크립트를 작성하도록 도와주는 “규칙들의 집합(set of rules)”이다. 아래는 테스트 자동화 프레임워크의 대표적인 5가지 유형이다.

 

1. 선형 프레임워크(Linear Framework)

• 스크립트와 관련된 모든 것이 이 스크립트 내부에 정의되어 있다.
• 추상화(abstraction)와 코드 중복(code duplication)에 대해 신경 안 쓴다.
• 레코드와 플레이백이 대개 선형 코드를 생성한다.
• 처음 시작하기가 쉽다.
• 유지보수가 악몽이다.

 

 

위의 Example A가 여기 해당됨. 이 프레임워크는 UI 화면이 많지 않은 소규모 프로젝트에서 사용될 수 있다. 또한 자동화 도구를 처음 사용하게 되었을 때, 대개 선형의 코드를 생성한다(자동화 도구가 특정 액션에 대해 어떤 코드를 생성하는지 배울 수 있음). 이런 이유 말고는 스크립팅에 있어서 이 프레임워크의 사용을 피해야 한다.

 

2. 모듈식 프레임워크(Modularity Framework)

• 오브젝트가 단 한 번만 정의되고, 이게 모든 테스트 메쏘드에서 재사용된다.
• 개별 기능을 위한 작고 간단명료한 메쏘드가 생성된다.
• 테스트케이스가 이 작은 메쏘드들과 재사용가능한 오브젝트들의 집합이다.
• 유지보수가 용이한 코드 작성을 허용한다.

 

위의 Example B가 여기 해당됨. calWindow를 상부로 옮기고 속성 내부에 정의하여 다른 장소에서 사용될 수 있도록 함으로써 추상화를 생성하였고, ClickButton()과 AddTwoNumbers()라 불리는 두 개의 작고 독립적인 함수(메쏘드)를 생성함. 이 두 함수를 결합하여 계산기의 “Add” 기능을 테스트 하는 최종 스크립트를 생성

 

이 프레임워크는 유지보수가 더 용이한 스크립트 작성을 허용하며, 따라서 자동화에 많이 사용된다. Selenium에서 사용되는 Page Object 프레임워크도 이 모듈식 프레임워크의 한 종류이다. 이 프레임워크의 약점으로는 좋은 객체 지향 개념과 강력한 개발 기술이 요구된다는 것이다.

 

 

3. 데이터 주도 프레임워크(Data Driven Framework)

• 테스트 데이터(입력값과 출력값)가 스크립트로부터 분리되어 외부 파일(예, .CSV 파일, 액셀 스프레드시트, 데이터베이스)에 저장된다.
• 스크립트가 실행될 때 이 값들이 외부 파일로부터 선택되어 변수에 저장되고, 하드 코드된 값들이 있는 경우 이것들을 대체한다.
• 동일한 테스트케이스가 여러 다른 입력값을 가지고 실행되어야만 하는 경우 아주 유용하다.

 

Example C:

3개의 다른 입력 값으로 Add 테스트케이스를 실행하고자 함. 데이터가 아래와 같다.

 

7 + 2 = 9

5 + 2 = 7

3 + 2 = 5

 

 

이 데이터(입력과 출력 둘 다)를 외부 CSV 파일에 저장한다.

 

 

위 스크립트에서 데이터 소스(.CSV 파일)를 스크립트의 상단에 정의함. 이 .CSV 파일의 경로를 주고, 스크립트가 이것을 “순차적(Sequentially)”으로 파싱하도록 함. 즉, 스크립트가 CSV 파일에 있는 줄(rows)의 수만큼 실행된다(이 예의 경우는 스크립트가 3번 실행됨). 각 실행에서 스크립트가 첫 두 개 열에 정의된 두 숫자를 더하고, 이 두 수의 합이 세 번째 열에 있는 숫자와 일치하는지 확인한다.

 

 

이 프레임워크의 장점은 모든 값들이 스크립트 외부에 저장되므로 다음 빌드에서 어떤 변경이 발생되면 외부 파일에 있는 데이터만 변경시키면 되고 스크립트는 건드릴 필요가 없다는 것이다. 두 번째 장점은 동일한 스크립트가 여러 다른 입력에 대해 실행될 수 있다는 점이다. 예를 들어, ERP에서 100명의 직원 등록을 테스트해야 할 필요가 있다면, 하나의 스크립트를 작성하고 직원들의 이름과 기타 관련 데이터는 외부 파일에 저장한다. 이 하나의 스크립트를 매번 다른 직원 데이터를 가지고 100번 실행시키면 어떤 데이터에서 스크립트가 직원 등록에 실패하는지 쉽게 발견할 수 있다.

 

4. 키워드 주도 프레임워크(Keyword-Driven Framework)

• 데이터와 액션 둘 다 스크립트 외부에 정의된다.
• 여러 다른 종류의 액션을 위한 키워드 개발을 요구한다.
• 개발된 키워드와 테스트 데이터를 사용해 테스트 할 기능을 표 형태로 단계적으로 작성한다. 이 표를 데이터 주도 프레임워크에서처럼 외부 파일로 저장한다.
• 스크립트가 이 테이블을 파싱하고, 상응하는 액션을 수행한다.
• 코딩을 할 줄 모르는 수동 테스터가 자동화에 어느 정도 참여할 수 있도록 허용한다.

 

Example D:

 

데이터(예, 1 + 3 = 4)와 액션(예, 클릭, 클리어 등)을 액셀 파일에 표 형식으로 정의한다.

 

스크립트가 대충 아래와 같은 모습이 된다(아래 코드는 단순히 이해 목적으로 작성됨)

 

위 스크립트는 단순히 액셀 파일의 파서이다(액셀 파일을 한 라인 씩 파싱하고, 각각의 액션을 수행하기 위해 키워드를 찾음). 스크립트가 키워드 “Click”을 찾으면 정의된 오브젝트 상에서 클릭을 하고, “Verify Result”를 찾으면 어써션을 수행한다.

 

키워드 주도 프레임워크는 테스트케이스의 변경 가능성이 매우 높은 시나리오에 도움이 된다. 테스트케이스에서 어떤 스텝이 변경되어도 코드를 손 댈 필요가 없으며, 액셀 파일만 업데이트 하면 스크립트가 업데이트 된다. 이런 방식은 수동 테스터가 테스트 자동화의 부분이 될 수 있도록 허용한다(즉, 수동 테스터가 코딩을 전혀 할 필요가 없으며, 필요 시 액셀 파일을 업데이트하기만 하면 스크립트가 자동으로 업데이트 됨). 또 다른 장점은 스크립트가 도구에 독립적이 된다는 점이다. 스크립트를 액셀 파일에서 유지보수 할 수 있고, 언젠가 자동화 도구를 바꿀 필요가 있다면 다른 도구로 액셀 파서를 작성함으로써 쉽게 변경할 수 있다.

 

이 프레임워크의 단점은 다양한 타입의 액션을 위한 키워드를 고안할 필요가 있다는 점이다. 대규모 프로젝트에서는 기억해야 할 키워드가 아주 많아질 수 있으며, 이게 어떤 지점에 도달하면 다루기 힘든 일이 되어버린다. 또한 오브젝트가 쉽게 식별될 수 없는, 그래서 마우스 좌표나 다른 기법을 사용할 필요가 있는, 일부 복잡한 시나리오에서는 이 프레임워크가 그다지 도움이 되지 않는다.

 

 

하지만 이게 여전히 많은 자동화 테스터가 선호하는 프레임워크이다. Google의 Robot 프레임워크도 잘 알려진 키워드 주도 프레임워크이며, 왕성한 활동을 하는 커뮤니티의 지원을 받고 있다.

 

5. 혼합 프레임워크(Hybrid Test Automation Framework)

• 위에 언급된 기법들이 두 개 또는 그 이상이 조합된 것(각자의 장점은 살리고 약점은 최소화하기 위해)
• 이 프레임워크가 데이터 주도 프레임워크 또는 키워드 주도 프레임워크와 더불어 모듈식 접근방법을 사용할 수 있다.
• 순수한 키워드 주도 접근법에서는 구현하기 어려울 수도 있는 일부 작업을 수행하기 위해 이 프레임워크가 스크립트를 사용할 수 있다.

 

 

결론

• 프레임워크는 테스터의 업무를 돕기 위한 용도이다. 즉, 테스터가 유지보수 용이하고 신뢰할 만한 스크립트를 작성하도록 도와준다.
• 프레임워크 사용 없이는 애플리케이션의 작은 변경에도 매번 수 백 군데에서 코드를 변경해야만 하므로 테스트 자동화 분야가 악몽이 된다.
• 따라서 프레임워크를 이해하는 것은 테스트 자동화를 경험하고자 하는 모든 테스터가 반드시 해야만 하는 일이다.