테스트 자동화 프레임워크: Archi구조와 유형

⚡ 스마트 요약

테스트 자동화 프레임워크 아키텍처는 자동화 스크립트가 따라야 하는 코딩 표준, 테스트 데이터 처리 및 객체 저장소 규칙을 정의합니다. 기존에는 다섯 가지 유형이 있었으며, 각 유형은 설정 노력과 재사용성, 유지 관리 비용 및 장기적인 확장성 간의 균형을 고려했습니다.

  • 📐 핵심 정의: 프레임워크는 규칙이 아니라 재사용성, 이식성 및 유지 관리 비용 절감을 가능하게 하는 일련의 지침입니다.
  • ⏺️ 선형 스크립팅: 녹음 및 재생 기능은 구축 속도는 가장 빠르지만 유지 관리가 가장 어렵습니다. 데이터가 하드코딩된 상태로 유지되기 때문입니다.
  • 🧱 테스트 라이브러리 Archi강의: 공통적인 단계는 드라이버 스크립트에서 호출되는 재사용 가능한 함수가 되어 계획 시간을 희생하더라도 재사용성을 높입니다.
  • 📊 데이터 기반: 테스트 로직은 스크립트에 유지되는 반면 데이터는 Excel, CSV 또는 데이터베이스로 이동되므로 스크립트당 다양한 시나리오를 실행할 수 있습니다.
  • 🔑 키워드 기반: 동작은 테이블에 키워드로 저장되므로 테스트는 도구나 애플리케이션에 관계없이 독립적으로 수행됩니다.
  • 🔀 하이브리드 모델: 대부분의 성숙한 도구 모음은 노력과 적용 범위의 균형을 맞추기 위해 키워드 테이블과 기능 분해를 결합합니다.

테스트 자동화 프레임워크 Archi구조와 유형

자동화 테스트의 프레임워크란 무엇입니까?

A 테스트 자동화 프레임워크 코딩 표준, 테스트 데이터 처리, 객체 저장소 처리 등과 같은 가이드라인 세트입니다. 자동화 스크립팅 중에 따르면 코드 재사용 증가, 더 높은 이식성, 스크립트 유지 관리 비용 감소 등과 같은 유익한 결과가 발생합니다. 이는 단지 가이드라인일 뿐 규칙이 아닙니다. 필수가 아니며 가이드라인을 따르지 않고도 스크립팅할 수 있습니다. 하지만 프레임워크를 갖는 이점을 놓치게 됩니다.

왜 프레임워크가 필요한가요?

프레임워크가 필요한 이유를 이해하기 위해 예를 살펴보겠습니다.

귀하는 참가자들에게 다음 지침을 준수하도록 요청한 세미나/강의/컨퍼런스에 참석했을 것입니다.

  • 참가자들은 강의 시작 5분 전까지 자리에 착석해 주시기 바랍니다.
  • 메모를 위해 노트와 펜을 가져오세요.
  • 복근을 읽어보세요trac그러니까 발표 내용이 무엇일지 대략적인 감을 잡으실 수 있을 거예요.
  • 휴대폰은 무음으로 설정해야 합니다.
  • 강의 도중에 나가야 하는 경우에는 발표자의 반대편 끝에 있는 출구를 이용하세요.
  • 세션이 끝나면 질문을 받습니다.

세미나를 열 수 있다고 생각하시나요? 없이 이 지침을 준수하고 있습니까?

답은 크다 예! 물론, 위의 지침이 없어도 세미나/강의/컨퍼런스/시연을 진행할 수 있습니다. 사실 우리 중 일부는 지침이 제시되어 있어도 따르지 않을 것입니다!

하지만 지침을 준수하면 시청자 이탈 감소와 같은 긍정적인 결과를 얻을 수 있을 것입니다.trac강의 중 참여도 향상, 참가자 유지율 증가, 주제 이해도 향상.

위의 내용을 바탕으로, 프레임워크는 준수할 때 유익한 결과를 생성하는 일련의 지침으로 정의할 수 있습니다.

테스트 자동화 프레임워크 Archi구조: 주요 구성 요소

각 프레임워크의 유형을 비교하기 전에, 각 프레임워크가 무엇을 포함하고 있는지 살펴보는 것이 도움이 됩니다. Archi구조는 이러한 부분들이 어떻게 겹겹이 쌓여 있는지, 즉 한 층의 변화가 다른 층에 영향을 미치지 않도록 하는 방식을 설명합니다.

  • 테스트 스크립트 레이어: 테스트 케이스를 저장합니다. 스크립트는 탐색 단계를 반복하는 대신 재사용 가능한 함수를 호출하기 때문에 간결하게 유지됩니다.
  • 함수 라이브러리: 로그인, 검색, 로그아웃과 같은 공유 작업을 저장하므로 워크플로 변경은 한 번만 수행하면 됩니다.
  • 객체 저장소: GUI 요소 위치 지정자에 친숙한 이름을 매핑합니다. 인터페이스가 변경될 때 이 레이어만 편집됩니다.
  • 테스트 데이터 레이어: 입력값과 예상값을 코드 내부가 아닌 Excel, CSV 또는 데이터베이스 소스에 저장합니다.
  • 구성 계층: 환경을 포함합니다 URL브라우저 선택, 시간 초과 및 자격 증명.
  • 보고 계층: 실행 보고서, 오류 스크린샷 및 진단 로그를 생성합니다.
  • 실행 계층: 빌드 서버에서 트리거 스위트를 실행하여 자동화를 연결합니다. 지속적인 통합.

아래 프레임워크 유형들은 주로 이러한 계층들을 얼마나 엄격하게 분리하는지에 따라 차이가 납니다.

테스트 자동화 프레임워크 유형

다음은 다양한 유형의 자동 테스트 프레임워크입니다.

  1. 선형 스크립팅
  2. 테스트 라이브러리 Archi강의 프레임워크.
  3. 데이터 중심 지원 뼈대.
  4. 키워드 기반 또는 테이블 기반 테스트 프레임워크.
  5. 하이브리드 테스트 자동화 프레임워크.

자세히 살펴보겠습니다 –

1) 선형 스크립팅 – 기록 및 재생

모든 테스트 자동화 프레임워크 중 가장 간단하며 “녹화 및 재생”. 이번에 자동화 테스트 Framework, Tester는 첫 번째 라운드에서 각 단계(탐색 및 사용자 입력)를 수동으로 기록하고 체크포인트(검증 단계)를 삽입합니다. 그런 다음 그는 다음 라운드에서 기록된 스크립트를 재생합니다.

예: 로그인을 고려해보세요 항공편 예약 신청 성공적인 로그온 시 애플리케이션이 로드되었는지 확인합니다. 여기서 테스터는 단순히 단계를 기록하고 검증 단계를 추가합니다.

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
Dialog("Login").WinEdit("Password:").Set "Mercury"
Dialog("Login").WinButton("OK").Click
'Check Flight Reservation Window has loaded after successful log-on
Window("Flight Reservation").Check CheckPoint("Flight Reservation")

장점

  • 스크립트를 생성하는 가장 빠른 방법
  • 자동화 전문 지식이 필요하지 않음
  • 테스트 도구의 기능을 배우는 가장 쉬운 방법

단점

  • 스크립트 재사용이 거의 없음
  • 테스트 데이터는 스크립트에 하드코딩됩니다.
  • 유지보수의 악몽

2) 테스트 라이브러리 Archi강의 프레임워크

그것은 또한 다음과 같이 알려져 있습니다. “구조화된 스크립팅” or “기능적 분해”.

이 자동화 테스트 프레임워크에서 테스트 스크립트는 처음에 "기록 및 재생”방법. Later, 스크립트 내부의 일반적인 작업이 식별되어 기능으로 그룹화됩니다. 이러한 함수는 다음과 같은 기본 테스트 스크립트에 의해 호출됩니다. 운전기사 테스트 케이스를 만드는 방법은 다양합니다.

예: 위와 동일한 예를 사용하면 Flight Reservation에 로그인하는 기능은 다음과 같습니다.

Function Login()
  SystemUtil.Run "flight4a.exe","","","open"
  Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
  Dialog("Login").WinEdit("Password:").Set "Mercury"
  Dialog("Login").WinButton("OK").Click
End Function

이제 다음과 같이 기본 스크립트에서 이 함수를 호출합니다.

Call Login()
---------------------------
'Other Function calls / Test Steps.
---------------------------

장점

  • "기록 및 재생"에 비해 구조적 스크립팅에서 더 높은 수준의 코드 재사용이 달성됩니다.
  • 자동화 스크립트는 코드 재사용률이 높기 때문에 개발 비용이 저렴합니다.
  • 더욱 쉬워진 스크립트 유지 관리

단점

  • Test Library Framework를 사용하여 스크립트를 작성하려면 기술적 전문성이 필요합니다.
  • 테스트 스크립트를 계획하고 준비하는 데 더 많은 시간이 필요합니다.
  • 테스트 데이터는 스크립트 내에 하드 코딩되어 있습니다.

3) 데이터 기반 테스트 프레임워크

이 프레임워크에서는 테스트 케이스 테스트 로직은 테스트 스크립트에 구현되고, 테스트 데이터는 분리되어 테스트 스크립트 외부에 저장됩니다. 테스트 데이터는 외부 파일(Excel 파일, 텍스트 파일, CSV 파일, ODBC 소스, DAO 객체, ADO 객체)에서 읽어와 테스트 스크립트 내부의 변수에 로드됩니다. 변수는 입력값과 검증값 모두에 사용됩니다. 테스트 스크립트는 선형 스크립팅 또는 테스트 라이브러리 프레임워크를 사용하여 작성됩니다. 이 기법에 대한 자세한 설명은 다음에서 확인할 수 있습니다. 데이터 기반 테스트 튜토리얼.

예: 개발ping 이 방법을 사용하는 항공편 예약 로그인 스크립트는 두 단계로 구성됩니다.

단계 1) Excel, CSV 또는 기타 데이터베이스 소스가 될 수 있는 테스트 – 데이터 파일을 만듭니다.

에이전트 이름 비밀번호
조립식 쇠지레 Mercury
티나 수은
Bill 수은

단계 2) 테스트 스크립트를 개발하고 테스트 데이터 소스에 대한 참조를 만듭니다.

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set DataTable("AgentName", dtGlobalSheet)
Dialog("Login").WinEdit("Password:").Set DataTable("Password", dtGlobalSheet)
Dialog("Login").WinButton("OK").Click
'Check Flight Reservation Window has loaded
Window("Flight Reservation").Check CheckPoint("Flight Reservation")
'Note "dtGlobalSheet" is the default excel sheet provided by QTP.

장점

  • 테스트 스크립트에 대한 변경 사항은 테스트 데이터에 영향을 미치지 않습니다.
  • 여러 데이터 세트로 테스트 케이스를 실행할 수 있습니다.
  • 외부 데이터 파일의 테스트 데이터만 변경하면 다양한 테스트 시나리오 실행 가능

단점

  • 테스트 스크립트와 테스트 데이터를 모두 계획하고 준비하는 데 더 많은 시간이 필요합니다.

4) 키워드 중심 또는 테이블 중심 테스트 프레임워크

The 키워드 기반 테이블 기반 자동화 프레임워크 개발에는 데이터 테이블과 키워드가 필요합니다. 독립적 테스트 자동화 도구 그것들을 실행하는 데 사용됩니다. 테스트는 애플리케이션을 사용하거나 사용하지 않고 설계할 수 있습니다. 키워드 기반 테스트에서는 테스트 중인 응용 프로그램의 기능이 표와 각 테스트에 대한 단계별 지침으로 문서화됩니다.

키워드 기반 프레임워크에는 키워드, 애플리케이션 맵, 구성 요소 기능 등 3가지 기본 구성 요소가 있습니다.

키워드는 GUI 구성 요소에서 수행할 수 있는 작업입니다. 예: GUI 구성 요소 텍스트 상자의 경우 일부 키워드(작업)는 InputText, VerifyValue, VerifyProperty 등입니다.

애플리케이션 맵이란 무엇입니까?

응용 프로그램 맵은 GUI 구성 요소에 대한 명명된 참조를 제공합니다. 애플리케이션 맵은 “개체 저장소"

구성 요소 기능이란 무엇입니까?

구성 요소 기능은 GUI 구성 요소를 적극적으로 조작하거나 조사하는 기능입니다. 기능의 예로는 모든 오류 처리가 포함된 웹 버튼 클릭, 모든 오류 처리가 포함된 웹 편집에 데이터 입력 등이 있습니다. 구성요소 기능은 애플리케이션에 따라 다를 수도 있고 독립적일 수도 있습니다.

예시: 키워드 보기를 이해하기 위해 동일한 예를 들어보겠습니다. 2단계로 구성됩니다.

1단계: 데이터 테이블 생성(Data Driven Framework에서 생성된 테스트 데이터 테이블과 다름) 이 데이터 테이블에는 GUI 개체에 대해 수행되는 작업과 해당 인수가 포함되어 있습니다. 각 행은 하나의 테스트 단계를 나타냅니다.

목적 동작
(응용프로그램 MAP) (키워드) 논의
WinEdit(에이전트 이름) 세트 Guru99
WinEdit(비밀번호) 세트 Mercury
Win버튼(확인)
창구(항공편 예약) 확인 존재

2단계: 글쓰기 Code 컴포넌트 함수 형태로 제공됩니다.

데이터 테이블을 생성한 후에는 각 단계를 읽고, 작업 필드에 포함된 키워드를 기반으로 단계를 실행하고, 오류 검사를 수행하고, 관련 정보를 기록하는 프로그램이나 스크립트 세트를 작성하기만 하면 됩니다. 이 프로그램 또는 스크립트 세트는 아래 의사 코드와 유사합니다.

Function main()
{
  Call ConnectTable(Name of the Table) { //Calling Function for connecting to the table.
  while (Call TableParser() != -1) //Calling function for Parsing and extracting values from the table.
  {
    Pass values to appropriate COMPONENT functions. Like Set(Object Name, Argument) ex. Set(Agent Name, Guru99).
  }
}
  Call CloseConnection() //Function for Closing connection after all the operation has been performed.
} //End of main

이것이 키워드 기반 프레임워크의 전부입니다.

키워드 기반 프레임워크의 장점은 키워드를 재사용할 수 있다는 것입니다. 이를 이해하려면 YAHOO MAIL과 같은 웹사이트에 대한 로그인 작업을 확인하고 싶다고 가정해 보겠습니다. 표는 다음과 같습니다.

목적 동작
(응용프로그램 맵) (예어) 논의
웹편집(사용자 이름) 세트 abc@yahoo.com
웹편집(비밀번호) 세트 XXXXX
웹버튼(확인)
윈도우(야후 Mail) 확인 잔뜩

이 경우 키워드 설정, 클릭, 확인은 이미 개발된 해당 구성 요소 기능과 동일하게 유지됩니다. 따라서 애플리케이션 맵만 변경하면 됩니다.ping (객체 저장소) 이전 항공편 예약부터 Yahoo까지 Mail , 인수 값이 변경되면 동일한 스크립트가 작동합니다!

장점

  • 높은 코드 재사용성을 제공합니다.
  • 테스트 도구 독립적
  • 테스트 중인 응용 프로그램과 별도로 동일한 스크립트가 AUT에 대해 작동합니다(몇 가지 제한 사항 있음)
  • AUT를 포함하거나 포함하지 않고 테스트를 설계할 수 있습니다.

단점

  • 초기 투자 비용이 상당히 높기 때문에 애플리케이션의 규모가 상당히 크고 테스트 스크립트를 몇 년 동안 유지 관리해야 하는 경우에만 이점을 실현할 수 있습니다.
  • 키워드 기반 프레임워크를 생성하려면 고도의 자동화 전문 지식이 필요합니다.

노트 : ... 비록 ... 할지라도 OpenText UFT 원(구 마이크로 포커스) UFT이 프레임워크는 키워드 기반 프레임워크라고 광고하지만, 이를 사용해서는 완벽한 테스트 도구 및 애플리케이션 독립성을 달성할 수 없습니다.

5) 하이브리드 테스트 자동화 프레임워크

이름에서 알 수 있듯이 이 프레임워크는 위에서 설명한 하나 이상의 자동화 프레임워크의 조합으로, 장점을 활용하고 단점을 완화하려고 노력합니다. 하이브리드 테스트 QA 자동화 프레임워크는 대부분의 테스트 자동화 프레임워크가 시간이 지남에 따라 여러 프로젝트로 발전하는 것입니다. 맥시멈산업에서는 기능분해 방식을 조합하여 키워드 프레임워크를 사용하고 있습니다.

추신: 언급할 만한 다른 자동화 프레임워크는 다음과 같습니다.

테스트 모듈성 프레임워크

이 프레임워크에서는 테스트 스크립트의 공통 작업이 모듈로 그룹화됩니다.

예시: 액션을 사용하는 방법 QTP 사용자는 모듈형 스크립트를 생성할 수 있습니다.

로그인용 샘플 스크립트

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
Dialog("Login").WinEdit("Password:").Set "Mercury"
Dialog("Login").WinButton("OK").Click
'End of Script

이제 다음과 같이 기본 스크립트에서 이 작업을 호출할 수 있습니다.

RunAction ("Login[Argument]", oneIteration)

비즈니스 프로세스 테스트(BPT)

이러한 자동화 프레임워크는 대규모 비즈니스 프로세스를 동일하거나 다른 테스트 스크립트에서 여러 번 재사용할 수 있는 구성 요소로 나눕니다. 예를 들어 항공편 예약의 비즈니스 프로세스는 동일한 비즈니스 프로세스 또는 다른 프로세스에서 재사용할 수 있는 로그인, 항공편 찾기, 예약, 결제 및 로그아웃과 같은 구성 요소로 분할됩니다. 또한 BPT는 SME와 자동화 엔지니어 간의 긴밀한 조정을 촉진합니다.

적합한 테스트 자동화 프레임워크를 선택하는 방법

어떤 한 가지 유형이 항상 최고는 아닙니다. 올바른 선택은 팀의 역량, 애플리케이션 규모, 그리고 제품군이 얼마나 오랫동안 유지되어야 하는지에 따라 달라집니다. 아래 표는 결과에 영향을 미치는 요소들을 기준으로 다섯 가지 유형을 비교합니다.

프레임워크 유형 설정 노력 Code 재사용 유지 보수 비용 최고의 적합 대상
선형 스크립팅 매우 낮은 매우 낮은 매우 높은 시연 및 일회성 연기 점검
테스트 라이브러리 Archi강의 중급 중급 중급 반복적인 워크플로우를 지원하는 안정적인 애플리케이션
데이터 중심 중급 중급 높음 여러 입력 세트가 필요한 양식 및 계산
키워드 기반 높음 매우 높은 높음 다양한 기술팀이 관리하는 대규모 스위트룸
잡종 높음 매우 높은 높음 장기 운영 기업 프로그램

결정하기 전에 다음 질문들을 꼼꼼히 살펴보세요:

  1. 이 스위트룸은 얼마나 오래 사용할 수 있을까요? 키워드 기반 또는 하이브리드 디자인의 높은 초기 투자 비용은 수년간의 유지 관리를 통해 정당화될 수 있지만, 단기 프로젝트로는 충분하지 않습니다.
  2. 시험 문제는 누가 출제하나요? 수동 테스터가 테스트 케이스를 제공하는 경우, 키워드 테이블을 통해 스크립팅 언어를 배우지 않고도 작업할 수 있습니다.
  3. 인터페이스는 얼마나 불안정한가요? 잦은 화면 전환으로 인해 별도의 객체 저장소가 필수적이며, 그렇지 않으면 모든 스크립트를 수정해야 합니다.
  4. 어느 정도의 데이터 다양성이 필요할까요? 많은 입력 조합이 데이터 기반 설계를 직접적으로 가리킵니다.
  5. 이미 사용 중인 도구는 무엇입니까? 프레임워크는 선택된 것에 적합해야 합니다. 자동화 도구 그리고 팀이 알고 있는 언어, 예를 들면 다음과 같습니다. Selenium 과 Java or Cucumber.

대부분의 팀은 라이브러리 또는 데이터 기반 접근 방식으로 시작하여 점차 하이브리드 모델로 발전해 나갑니다. 되돌아옴 스위트룸이 확장됩니다.

테스트 자동화 프레임워크의 이점 Archi강의

테스트 자동화 프레임워크 아키텍처의 이점은 다음과 같습니다.

  • 테스트 자동화 프레임워크는 위험 및 비용 비용을 줄이는 데 도움이 됩니다.
  • 테스트의 효율성을 향상시킵니다.
  • 유지관리비 절감에 도움이 됩니다
  • 코드 재사용을 허용합니다.
  • 최대 테스트 범위를 달성할 수 있습니다.
  • 애플리케이션 기능을 극대화합니다.
  • 테스트 케이스 중복을 줄이는 데 도움이 됩니다.
  • 테스트 자동화로 테스트 효율성 및 성능 향상에 도움이 됩니다.

자주 묻는 질문

툴은 애플리케이션에 대해 명령을 실행합니다. 프레임워크는 이러한 명령을 작성, 구성 및 유지 관리하는 방법을 결정하는 규칙, 폴더 구조 및 재사용 가능한 라이브러리의 집합입니다.

아니요. 페이지 객체 모델(Page Object Model)은 객체 저장소 계층을 위한 디자인 패턴입니다. 일반적으로 라이브러리 기반, 데이터 기반 및 하이브리드 프레임워크 내에서 사용되며, 기존 프레임워크를 대체하는 것은 아닙니다.

AI는 객체 저장소 계층에 자체 복구 로케이터와 시각적 비교 기능을 추가합니다. 계층형 아키텍처는 그대로 유지되지만, 사용자 인터페이스가 약간 변경될 때 스크립트 오류가 발생하는 빈도가 줄어듭니다.

예. AI 비서는 작성된 단계를 객체, 동작 및 인자 행으로 변환합니다. 검토자는 객체 이름이 저장소와 일치하는지 확인해야 하며, 그렇지 않으면 생성된 행이 런타임 오류를 발생시킵니다.

Trac릴리스당 스크립트 유지 관리 시간, 불안정한 오류 비율, 빌드부터 결과 도출까지의 시간 등을 측정합니다. 정상적인 프레임워크는 자동화된 코드 커버리지가 계속 증가하는 동안 유지 관리 노력이 감소하는 모습을 보입니다.

이 게시물을 요약하면 다음과 같습니다.