블로그

테스트 도구 프로필: Threat Stack이 ThoughtWorks Gauge를 사용하는 이유

F5 썸네일
F5
2022년 3월 16일 업데이트

Threat Stack은 이제 F5 Distributed Cloud App Infrastructure Protection (AIP)입니다. 오늘부터 팀과 함께 분산 클라우드 AIP를 사용해 보세요.

Threat Stack에서는 매일 수많은 테스트를 실행하여 Threat Stack Cloud Security Platform®에서 모든 것이 예상대로 작동하는지 확인합니다. 소프트웨어 엔지니어의 단위 및 통합 테스트를 보완하기 위해 당사 테스트 엔지니어링 팀은 자동화된 회귀 테스트 모음의 일부로 다음을 생성했습니다.

  • Capybara로 작성된 브라우저 기반 테스트는 유효한 사용자만 대시보드에 로그인하고, 사이트를 탐색하고, AWS 플릿에서 생성된 이벤트 추적을 보고, 보안 팀이 분류할 수 있는 경고를 생성하는 이러한 이벤트에 따라 규칙을 만들고 업데이트할 수 있는지 확인하는 모든 작업을 웹 기반 사용자 인터페이스를 통해 수행합니다. 150개 이상의 테스트.
  • API 테스트는 Net/HTTP Ruby gem을 사용하여 Threat Stack API 와 상호 작용하여 지난 30일간의 감사 로그를 검색하고 심각도 및 유형별로 개별 및 알림 그룹을 나열하고 Threat Stack에서 모니터링하고 조사한 모든 가상 환경을 나열하고 HIPAA, ISO 27001, MPAA, PCI, SOC 2에 대한 기본 규정 준수 규칙 세트를 볼 수 있는지 확인합니다. 테스트에서는 이러한 사전 구성 및 사용자 지정 규칙에 의해 생성된 경고를 Threat Stack API를 통해 모두 볼 수 있고, 억제하거나, 해제할 수 있는지도 확인합니다. 130개 이상의 테스트.

거의 300개의 수용 테스트를 어떻게 추적할 수 있을까요? Threat Stack의 테스트 엔지니어는 무료이고 가벼운 크로스 플랫폼 테스트 자동화 프레임워크인 ThoughtWorks Gauge를 사용하여 테스트를 설정했습니다. 

게이지 테스트에는 두 가지 주요 부분이 있습니다.

  • 평범한 언어로 작성된 테스트 사양은 테스트를 수행하는 방법에 대한 단계별 지침을 요점별로 나열한 것입니다. 사양은 수동 테스트 계획처럼 읽혀야 하며, 다른 사람들이 따라갈 수 있을 만큼 명확하고 간결한 설명이 있어야 합니다.
  • step_implementation 폴더에는 테스트를 실행하는 코드가 포함되어 있으며, 각 단계를 사양에서 언제 어디서나 호출되어 재사용 가능한 코드 블록으로 래핑합니다. 

Gauge가 테스트를 실행하는 코드에서 테스트 계획을 분리함으로써 테스트의 가독성과 유지 관리가 더 높아지고, 여러 테스트 사이에서 테스트 단계를 공유할 수 있습니다.

이 게시물의 나머지 부분에서는 Gauge에 대해 우리가 좋아하는 주요 기능 중 10가지에 대해 중점적으로 살펴보겠습니다. 

스냅 사진:

  • 웹사이트: Gauge.org , Github.com/getgauge
  • 출시일: 2018년 7월
  • 지원 언어: 자바, C#, 루비, 자바스크립트, 고, 파이썬
  • 지원되는 운영 체제: 리눅스, 맥OS, 윈도우
  • IDE 플러그: 비주얼 스튜디오, 비주얼 스튜디오 코드, 인텔리J

1. 설치의 용이성

게이지는 설치하기 매우 쉽습니다. Gauge 설치 페이지 로 가서 운영 체제, 프로그래밍 언어, IDE를 선택하면 모든 항목을 설치하는 방법에 대한 맞춤 지침이 표시됩니다. MacOS 설치는 HomeBrew를 사용하여, Linux 설치는 APT_GET을 사용하여, Windows 설치 는 소스 코드에서 설치 하고 싶지 않으면 Windows Installer를 사용하여 수행할 수 있습니다. 

모든 것을 다운로드한 후 명령줄에 gauge install ruby를 입력하여 Ruby와 같은 프로그래밍 언어용 언어 실행기를 설치할 수 있습니다.

2. 샘플 프로젝트 포함

새로운 테스트 자동화 프레임워크를 사용하면 어떤 파일을 어떤 폴더에 넣어야 하는지, 테스트를 어떻게 설정하고 시작해야 하는지 판단하기 어려울 수 있습니다. 

게이지는 몇 가지 테스트를 포함한 샘플 프로젝트를 포함시켜서 이런 혼란을 피하고, 프레임워크를 처음 사용하는 사용자도 쉽게 조작할 수 있도록 했습니다. 예를 들어 "게이지", "밍글", "스냅"과 같은 특정 단어가 있다고 가정해 보겠습니다. 단어의 모음 개수를 세는 테스트를 설계할 때, 예상 개수와 실제 개수가 일치한다고 단언하려면 어떻게 해야 할까요? 

예시 테스트는 데이터 중심이며, 입력은 '단어'와 예상 '모음 수'의 두 열이 있는 데이터 테이블에 수집됩니다.

샘플 프로젝트는 설치 후 바로 명령줄에서 gauge run spec 명령을 사용하여 실행할 수 있습니다.

샘플 출력, 명령줄: 

3. 테스트와 테스트 구현 방법의 분리

자동화된 테스트 모음 내에서 실제로 무엇이 테스트되고 있는지 알아내려고 하면 좌절스러울 수 있습니다. 특히 테스트의 목적, 테스트가 수행하는 단계 또는 각 테스트 단계를 실행하는 코드를 파악하기 전에 수많은 코드 블록을 조사해야 하는 경우 더욱 그렇습니다. 

게이지는 테스트 계획과 테스트 계획의 실행 방법을 분리함으로써 이런 혼란을 피합니다. 게이지는 조쉬 그루버와 에런 슈워츠가 2004년에 만든 텍스트 서식 언어인 마크다운 파일에 단계를 구성합니다. 테스트 단계는 사양 파일에 요점으로 저장되며, 이후 step_implementations 에서 실행할 수 있습니다. 

명세서: 사양은 단순히 제품 기능에 대한 사양을 나열하는 것이 아닙니다. 이는 테스트 코드를 구성하고 HTML 또는 XML 보고서를 설정하는 방법입니다. *.spec 파일의 각 요소는 Markdown의 요소에 해당합니다. 사양은 "비즈니스 계층 테스트 사례"이며 기능 문서 역할도 할 수 있습니다. 이러한 내용은 비즈니스 언어로 작성되었습니다. Gauge 공식 문서에 따르면 , 일반적으로 사양이나 사양서는 테스트 중인 애플리케이션의 특정 기능을 설명합니다. 

각 사양에는 다양한 테스트 시나리오를 설명하는 헤더가 있으며, 관련 테스트 시나리오는 하위 헤더로 설명됩니다. 이러한 헤더와 하위 헤더는 로그를 볼 때 포함되어 무엇이 통과되었고 무엇이 실패했는지 확인할 수 있으며 HTML 보고서에도 포함됩니다. 

단계 정의: 사양에 나열된 각 단계는 사양의 일반 언어와 실행되는 Java, C#, Javascript, Python 또는 Ruby 코드를 페어링하는 개념 또는 재사용 가능한 단계 정의에 해당합니다. 

테스트를 실행하는 코드에서 테스트를 분리함으로써 다른 테스터, 비즈니스 분석가 및 제품 소유자가 코드를 깊이 파고들지 않고도 사양 파일을 보고 테스트가 어떻게 구성되었는지 명확하게 알 수 있습니다.

4. 사양은 가독성을 위해 포맷되었습니다.

사양은 매우 읽기 쉽게 설정되어 있습니다. 

  • 헤더에는 작성자가 시나리오의 내용을 설명할 수 있는 해시태그(#)가 접두사로 붙습니다.
  • 개별 테스트 시나리오는 이중 해시태그("##")로 표시된 하위 헤더로 나열됩니다. 
  • 테스트 시나리오를 수행하는 테스트 단계는 별표("*")로 시작합니다. 

사양 파일의 예가 필요하신가요? 다음은 새로운 Gauge 프로젝트를 초기화할 때 Gauge가 설치하는 데모 프로젝트의 사양입니다.

# 사양 제목
이것은 실행 가능한 사양 파일입니다. 이 파일은 마크다운 구문을 따릅니다. 이 파일의 모든 제목은 시나리오를 나타냅니다. 모든 요점은 단계를 나타냅니다.
* 영어의 모음은 "aeiou"입니다.
## 단일 단어의 모음 수
* "gauge"라는 단어에는 "3"개의 모음이 있습니다.
## 여러 단어의 모음 수
이것은 이 사양의 두 번째 시나리오입니다. 다음은 표를 사용하는 단계입니다.
* 거의 모든 단어에는 모음이 있습니다.
|단어 |모음 수|
|------|-----------|
|게이지 |3 |
|밍글|2 |
|스냅 |1 |
|GoCD |1 |

이 사양의 각 항목은 step_implementations 폴더에 나열된 테스트 단계에 해당합니다. 

또 다른 예가 필요하신가요? 예를 들어, specs 폴더에 사이트에 로그인하는 login.spec 이라는 테스트가 있다고 가정해 보겠습니다.

# 로그인 테스트
## 유효한 사용자가 사이트에 로그인할 수 있는지 확인
* 로그인: 사용자 이름 입력: “info@threatstack.com”
* 로그인: 비밀번호를 입력하세요: “1234”
* 로그인: [로그인]을 선택하세요.

step_implementations 폴더에 배치된 각 단계는 테스트에서 자동으로 찾아 실행할 수 있습니다.

login_spec.rb 단계 '로그인: 사용자 이름을 입력하세요: ' do | username | fill_in(EMAIL_TEXTBOX, with: username) end

동일한 일련의 단계를 계속해서 반복하고 있다고 생각하시나요? 이 세 가지 로그인 단계를 Login.cpt 아래의 컨셉 파일 에 넣을 수 있습니다. 

login.cpt # *로 로그인 LOGIN: 사용자 이름을 입력하세요: * 로그인: 비밀번호를 입력하세요: * 로그인: [로그인]을 선택하세요

다른 테스트에 로그인 구성 요소가 있는 경우 세 단계를 모두 복사하여 붙여 넣는 대신 테스트에 한 줄만 삽입할 수 있습니다. “info@threatstack.com”과 “1234”로 로그인하세요

5. 좋은 문서 및 지원

새로운 자동화 프레임워크를 배우는 것은 혼란스러울 수 있습니다. 때로는 설명서를 읽는 것만으로는 충분하지 않습니다. Gauge.org의 자세한 문서 를 읽어도 답할 수 없는 질문이 있나요? 개발자들은 StackOverflow , Google 그룹 , Gitter Chat 에서 매우 적극적으로 대응합니다.

6. 테스트 사양에 따라 생성된 HTML 보고서

앞서 살펴본 것처럼 테스트 사양은 Markdown 으로 작성됩니다. 사양에 나열된 이러한 테스트는 테스트 중인 소프트웨어 제품이 어떻게 작동하는지에 대한 실제 문서로 활용될 수 있습니다. 마크다운 형식으로 나열되어 있으므로 해당 사양을 활용하여 읽기 쉬운 HTML 보고서를 만들 수 있습니다.

데모 프로젝트의 HTML 보고서를 살펴보고 단어의 모음 수를 세어 보겠습니다.

HTML 보고서에는 다음이 포함되어 있는 것을 볼 수 있습니다.

  • 테스트가 실행된 시간과 날짜, 그리고 실행하는 데 걸린 시간
  • 얼마나 많은 사양과 시나리오가 실행되었는가
  • 얼마나 많은 사양과 시나리오가 통과되었고 실패했는가
  • 통과한 단계는 녹색, 실패한 단계는 빨간색으로 표시하여 어떤 단계가 실행되었는지 보여줍니다. 오류 메시지는 보고서에 포함됩니다. 

7. 게이지 공급 실행 후크

모든 우수한 자동화 프레임워크에는 테스트에 대한 전제 조건을 설정하는 방법과 테스트가 완료된 후 실행되는 종료 방법이 포함되어 있습니다. 

한 가지 예로는 브라우저 테스트에 초점을 맞춘 자동화 제품군이 있는데, 이 제품군에는 테스트 제품군이 시작될 때 브라우저를 초기화하는 설정 메서드와 테스트가 완료되면 브라우저를 닫는 해제 메서드가 있습니다. 

Gauge는 자동화 테스트 모음의 각 Suite, Spec, Scenario 또는 Step 전, 후에 실행할 수 있는 실행 후크를 제공합니다.

Gauge는 실행 코드를 사용하여 모든 제품군, 사양, 시나리오 또는 단계 전에 실행해야 하는 코드의 중복을 제거합니다. 

8. 명령줄 기능

Gauge는 IDE와 명령줄 모두에서 "일류 리팩토링 지원"을 제공합니다. 예를 들어, 테스트의 실제 목적이 무엇인지 점점 더 명확하게 하기 위해 테스트의 문구를 지속적으로 조정하고 싶은 경우 명령줄에 다음을 입력하세요. 

$ gauge --refactor "이전 단계 이름" "새로운 단계 이름"

Gauge의 명령줄 도구에 대한 자세한 내용은 manpage.gauge.org를 참조하세요. 

9. 테스트는 데이터 중심일 수 있습니다

테스트는 데이터 기반으로 초안을 작성하도록 설정할 수 있으므로 단순히 특정 주제에 대한 변형인 테스트에 사용할 테스트 매개변수 표를 입력할 수 있습니다. 

테스트가 필요한 일련의 웹 서비스가 있고 API 엔드포인트에 도달했다고 가정해 보겠습니다. 웹 서비스 이름, 스키마, 포트가 주어지면 HTTP 응답이 200 OK 인지 확인해야 합니다. 

각 테스트가 서로 유사하므로 데이터를 읽기 쉬운 표 형식으로 정리할 수 있습니다.

웹서비스_테스트.spec

모든 정보 행은 테스트 단계에 입력되고 해당 단계 구현에 의해 실행되므로 작성자는 작업을 중복할 필요가 없습니다. 

10. 데이터는 즉시 저장될 수 있습니다

때로는 테스트 단계 간에 데이터를 공유하고 나중을 위해 저장해야 합니다. 위의 API 테스트에서처럼 엔드포인트에 도달하여 응답을 받으면 올바른 JSON 스키마를 사용하여 유효한 형식인지 확인하는 테스트 단계가 필요하거나, 부정적인 테스트를 실행할 때 적절한 오류 메시지가 나열되는지 확인할 수 있습니다. 

Gauge는 세 가지 유형의 DataStore를 사용합니다. ScenarioStore, SpecStore 및 SuiteStore는 시나리오, 사양 또는 전체 테스트 모음의 수명 주기에 대한 키/값 쌍으로 데이터를 저장합니다. 

예: 단계 구현 섹션에서 다음과 같이 요소 ID를 추가할 수 있습니다.

// 값 추가
scenario_store = DataStoreFactory.scenario_datastore;
scenario_store.put("element-id", "455678");
// 값 가져오기
element_id = scenario_store.get("element-id");

마무리하며...

서두에서 언급했듯이 Threat Stack에서 매일 많은 테스트를 실행한다면 견고하고 민첩한 크로스 플랫폼 테스트 자동화 프레임워크가 필요합니다. 또한 특정 테스트 요구 사항을 처리할 수 있는 기능과 역량을 갖추고 있으면서도 상당한 사용 편의성과 자동화를 제공하여 테스터의 적절한 노력과 입력으로 합리적인 시간 내에 철저히 테스트할 수 있어야 합니다.

계속 지켜봐주세요: 향후 게시물에서는 Capybara를 포함하여 Threat Stack에서 사용하는 다른 테스트 도구 중 일부를 살펴보겠습니다.

Threat Stack은 이제 F5 Distributed Cloud App Infrastructure Protection (AIP)입니다. 오늘부터 팀과 함께 분산 클라우드 AIP를 사용해 보세요.