페이퍼요약 - 실무에서 테스트 데이터 관리 by Haller

제목: 실무에서 테스트 데이터 관리(Test Data Management in Practice)

저자: Klaus Haller, 스위스

문서유형: 컨퍼런스 저널 페이퍼(총 11페이지), 2013년

 

스위스 통신사업자인 Swisscom의 IT 서비스 분야에서 적용하는 테스트 데이터 관리 사례(개념, 프로세스, 도구)를 설명한 자료

---

테스트 데이터 관리의 필요성

• 오늘날 IT 시스템의 복잡도가 크게 증가하면서 테스팅도 복잡해짐. 예를 들면, 샘플 모바일 앱이 은행 고객들이 주식 트레이드를 할 수 있게 해주며 다양한 스마트폰 상에서 실행됨. 이 앱이 고객의 트레이드를 은행의 코어 뱅킹 시스템으로 전송하면, 코어 시스템은 해당 트레이드를 거래소로 전달
• 이런 아키텍쳐의 단-대-단 테스트(end-to-end tests)가 쉽지 않음. 먼저 테스팅이 다양한 모바일 플랫폼과 스마트폰 타입을 고려해야만 하며, 둘째로 많은 인터페이스가 테스트되어야 하고, 셋째로 (종종 간과되는 점인데) 테스터가 스마트폰, 코어 뱅킹 시스템, 트레이딩 서버 상에서 일관성 있는 테스트 데이터를 필요로 한다.
• 이런 테스트 데이터를 어떻게 효율적으로 관리할 것인가가 이 논문의 초점

테스트 데이터 관리

• 테스트 데이터 관리는 테스트 대상 시스템의 데이터베이스에 있는 데이터가 테스트케이스의 사전조건(preconditions)을 충족시키는걸 보장하기 위한 모든 개념과 도구를 다룬다.
• 코어 뱅킹 시스템에 테스트 사용자가 있는가? 테스터가 특정 금융 상품을 트레이드 하는 것이 허용되는가? 테스터의 계정에 잔고가 충분한가? 등등 테스트케이스를 위한 사전조건을 올바르게 갖추는 것이 그것의 실행보다 더 어려울 수도 있다.

테스트 데이터 관리 프로젝트의 목적

1. 데이터 프라이버시 향상

• 관련 규제를 준수하고, 대외적인 평판을 유지하고, 비즈니스 비밀을 보호하기 위한 목적으로 회사가 테스트 데이터 관리에 투자하고 데이터 프라이버시를 향상시킴
• 오늘날 IT 부서가 생산 DB에 민감한 데이터가 저장되는걸 잘 인지하고 있으며, 따라서 접근 제어 메커니즘을 적용함(비즈니스 사용자가 업무에 필요한 데이터에만 접근 가능). 반면 테스트 서버의 리스크는 종종 무시됨. 즉, 많은 개발자와 테스터가 테스트 서버 상의 생산 데이터에 접근 할 수 있고, 심지어 대규모 데이터 집합을 추출하기 위한 접근 권한과 도구를 가지고 있을 수도 있음
• 여기에 데이터 유출의 높은 리스크가 존재하며 이런 리스크를 완화하는 것이 테스트 데이터 관리 프로젝트의 목적이 될 수 있다.

2. 테스팅 최적화(테스팅을 더 효율적으로 만듬)

적절한 테스트 실행, 반복가능한 테스트, 효율적인 테스트 데이터 공급을 보장하는 것이 테스트 데이터 관리 프로젝트의 두 번째 목적이 된다.

• 적절성(Relevance): 테스트 실행이 테스트케이스의 목적을 반영하는걸 의미. 예를 들어, 싱가포르에 사는 미국 시민이 런던 증권거래소에서 채권을 사는 테스트케이스가 있을 때, 이 테스트케이스를 미국에 사는 미국 시민 데이터로 실행해서는 안됨. 잘못된 데이터를 가지고 테스트를 실행하는 것이 쓸모 없고 시간과 돈 낭비이다.
• 반복성(Repeatability): 테스팅과 버그 수정이 활동 사슬로 연결됨(테스터가 버그를 발견하면 개발자에게 보고 à 개발자는 이 버그를 수정 à 버그 수정으로 버그가 실제 해결되었는지 확인을 위해 테스터가 재테스트). 버그 수정 후 재테스트가 해당 버그가 발생했을 때 처리된 것과 의미상 동일한 데이터/DB를 가지고 수행되어야 함
• 효율적인 테스트 데이터 공급(efficient test data provisioning): 테스트 데이터 생성과 소비 간의 “논리적 거리(logical distance)”가 어려움이 되기도 함. 예를 들어, 시스템 통합 테스트에서는 테스터가 자신이 알지 못하는 애플리케이션/모듈/배치잡에 의해 생성된 데이터를 필요로 하는 것이 흔한 일. 테스터가 어떻게 “논리적으로 멀리 떨어진” 애플리케이션으로부터 데이터를 얻을지를 테스트 데이터 관리 프로젝트가 최적화할 수 있음

테스트 데이터 관리의 접근방법

테스트 데이터 관리 프로젝트의 두 가지 주요 목적(데이터 프라이버시와 테스팅 최적화)을 달성할 수 있는 4가지 주요 접근방법이 존재한다.

• 익명화(Anonymization): 생산 데이터를 입력으로 취하고, 이 데이터를 가리거나 조각 내거나 또는 값을 교환하여 “청소된(sanitized)” 데이터를 생성한다.
• 인조 테스트 데이터(Synthetic test data): 생산 데이터로부터 파생된 것이 아니라 구체적인 테스트케이스를 위해 정의되고 손으로 만들어진 데이터
• 데이터베이스 애플리케이션에 특정한 테스트 도구: 테스트케이스 관리 도구가 데이터베이스 애플리케이션과 IT 배경을 테스팅 하는데 있어 세부 사항을 반영해야만 하며, 이것이 신규 도구(또는 이미 사용중인 도구의 커스토마이징)를 요구할 수도 있다.
• 프로세스와 조직(Processes & 0rganization): 데이터베이스 애플리케이션에 특정한 도구와 익명화 도구는 일상 업무(즉, 테스팅 프로세스와 조직)로 녹아들 때에만 조직에 이익을 가져올 수 있다.

테스트 데이터 관리 개념

성공적인 테스트 데이터 관리 프로젝트가 세 가지 개념(데이터베이스-애플리케이션-인지 테스트케이스, 테스트 오브젝트 타입, 테스트 데이터 카달로그)을 구현함

 

1. 데이터베이스-애플리케이션-인지 테스트케이스(Database-Application-aware Test Cases)

• 데이터베이스 애플리케이션은 하나 또는 다수의 데이터베이스를 포함하며, 데이터베이스의 상태가 테스트 결과에 영향을 줌. 따라서 테스트케이스가 기존에 정의되는 속성(테스트 단계, GUI 입력, 예상 GUI 출력)에 더하여 데이터베이스 상태를 정밀하게 명세해야 함. 이런 테스트케이스를 ‘데이터베이스-애플리케이션-인지 테스트케이스’라고 명명함
• 데이터베이스-애플리케이션-인지 테스트케이스가 테스트 오브젝트 타입과 데이터베이스 시스템 상태를 테스트케이스에 명세할 것을 요구하며, 이게 테스트케이스 실행의 반복성을 보장한다.

[데이터베이스-애플리케이션-인지 테스트케이스]

2. 테스트 오브젝트 타입(Test Object Types)

테스트케이스가 어떤 종류의 오브젝트를 가지고 실행되는지를 유지보수가 용이한 방식으로 명세한 것이며, 테스트 오브젝트 타입은 수 년간 안정적이지만 반면 DB의 오브젝트는 자주 변경된다는 것이 요점. 데이터베이스 테스트 오브젝트가 종종 복잡하고 많은 속성(attributes)을 가지는데, ‘테스트 오브젝트 타입’은 어떤 속성이 정말로 중요한지를 분명히 한다. 타입 정의가 아래로 구성됨

• 이름과 서술(Name and Description): 테스터가 타입을 사용하고 유지보수 하는걸 용이하게 함
• 의미상 필수 속성(Semantically mandatory attributes): 이 타입의 데이터베이스 테스트 오브젝트가 생성될 때, 모든 의미상 필수 속성들은 반드시 데이터베이스 오브젝트 타입 정의에 명세되어 있는 대로의 값들을 가져야 함
• 일관성 필수 속성(Consistency mandatory attributes): GUI 또는 데이터베이스가 종종 테스트케이스와 관련 없는 속성들이 채워질 것을 요구함. 예를 들어, 테스트케이스는 단지 국가명만 필요하다 할지라도 주소에서 도시명과 우편번호도 같이 요구될 수 있음. 일관성 필수 속성은 테스트 데이터 생성을 순조롭게 하기 위해 적절한 값(또는 값 조합)을 기록하는 방법이다.
• 무관한 속성(Irrelevant attributes): 테스트케이스와 관련 없고 시스템에 의해 요구되지 않는 것들로, 이게 임의 값을 가지거나 또는 공란/NULL로 남을 수 있다.
• 재사용 신호기(Reusability flag): 이 타입의 오브젝트가 어떻게 사용될 수 있는지를 정의함. 플래그가 “재사용가능(reusable)”으로 설정된 경우라면 테스트케이스가 ‘의미상 필수 속성’들의 값을 수정해서는 안 됨

 

테스트 센터 또는 프로젝트가 반드시 자신들의 테스트 오브젝트 타입을 관리해야 하는데, 간단한 방법은 아래처럼 엑셀 시트를 사용하는 것이다. 아래 엑셀 시트가 특정 속성 값들을 가진 5개 타입을 나열하고 있음. 테스터가 작성하는 어떤 샘플 테스트케이스에서 주재국(Country of residence)이 “CH”인 고객이 필요하며 테스트 실행 동안 주재국이 “AU”로 변경됨. 이 테스트케이스를 위한 적합한 테스트 오브젝트 타입은 의미상 필수 속성인 주재국 값이 “CH”이어야 함. 엑셀 시트에서 여기 부합하는 테스트 오브젝트 타입이 세 개 존재(“Credit Rating Tests 5”, “Credit Rating Tests 6”, “Swiss Wealth Management”). 실행 중에 이 테스트케이스가 의미상 필수 속성인 ‘주재국’을 변경시키므로 플래그가 “reusable” 이여서는 안되며, 결국 “Swiss Wealth Management”가 적합한 테스트 오브젝트 타입으로 좁혀짐. 따라서 이 샘플 테스트케이스 실행 전에 “Swiss Wealth Management” 타입의 오브젝트가 반드시 생성되거나 또는 기존 데이터에 존재해야 함. ‘주재국(Country of residence)’과 ‘고객 타입(Customer type)’은 고정되며(“CH”/“Wealth Management”), 그 외 다른 속성들은 어떤 값이든 가질 수 있다. 이 정의에서는 국적(Nationality)으로 “CH”를 사용할 것을 제안함

[고객을 위한 테스트 오브젝트 타입 (회색 셀: 의미상 필수, 흰색 셀: 일관성 필수, 공란 셀: 관련 없음)]

3. 테스트 데이터 카달로그(Test Data Catalogue)

테스트 데이터 카달로그가 테스트 오브젝트 타입을 구현하는 구체적인 오브젝트를 가리킴. 테스터가 테스트케이스를 실행하도록 요청 받았을 때, 1) 먼저 (Jira 또는 HP Quality Center에 있는) 테스트케이스 정의를 열고, 2) 실행해야 하는 테스트 단계(test steps)를 확인하고, 3) 데이터베이스 테스트 시스템 상태와 데이터베이스 테스트 오브젝트 타입을 확인하고, 4) 해당 데이터베이스 오브젝트 타입에 들어 맞는 DB 상의 구체적인 오브젝트를 찾는다. 테스터가 이걸 찾기 위해 DB와 그 테이블들을 쿼리 하는데, 모든 테스터가 SQL 레벨 상의 DB에 접근할 수 있고 쿼리가 너무 복잡하지 않으면 괜찮은 방법. 하지만 이런 기준이 충족되는 경우는 드물며, 따라서 데이터베이스 테스트 오브젝트 카달로그가 각 데이터베이스 테스트 오브젝트 타입을 위한 적절한 오브젝트들의 목록을 제공하고 테스터를 위해 데이터베이스 테스트 오브젝트를 예약하는걸 허용함으로써 도움을 준다. 아래는 엑셀 시트에 구현된 테스트 데이터 카달로그 샘플

[엑셀 기반 테스트 데이터 카달로그]

테스트 데이트 관리를 위한 UML 클래스 모델

테스트 데이터 관리를 위한 세 가지 개념(데이터베이스-애플리케이션-인지 테스트케이스, 테스트 오브젝트 타입, 테스트 데이터 카달로그)을 통합한 UML 클래스 다이어그램이 세 개 영역으로 구분됨

[오브젝트 모델 – 테스트 데이터 관리]

1) 최상위 영역은 테스트 관리 도구의 통상적인 기능을 나타냄

• 테스트케이스 정의(Test Case Definition): 테스트케이스 정의를 나타냄
• 테스트케이스 실행(Test Case Execution): 테스트케이스 실행의 결과를 나타냄. 테스트 실행 시 사용되는 데이터베이스 오브젝트를 참조

 

2) 최하단 영역은 테스트 대상 시스템의 데이터베이스를 나타냄

• 데이터베이스 오브젝트(Database Object): 테스트 대상 시스템의 DB에 있는 데이터 항목(또는 데이터 항목의 조합)을 나타냄

 

3) 중간 영역은 테스트 데이터 관리에 특정한 모든 클래스를 포함(오늘날의 테스트 관리 시스템이 대개 이 기능을 제공 안 함)

• 데이터베이스 테스트 시스템 상태(Database Test System State): 상태를 데이터베이스 export로써 모델링(예, 오라클 데이터베이스 export 파일). export 파일의 이름과 위치, 해당 export의 원천지인 DB로의 링크를 저장함
• 테스트 상태 저장소(Test States Repository): 다양한 애플리케이션의 데이터베이스 테스트 시스템 상태를 관리하는 책임을 가짐
• 테스트 데이터 카달로그(Test Data Catalogue): 엔트리 목록을 관리하고, 엔트리를 업데이트 하는 Update() 메쏘드를 제공함
• 엔트리(Entry): DB의 실제 오브젝트와 관련되고, 어떤 데이터베이스 테스트 오브젝트 타입을 위해 이것이 사용될 수 있는지 진술함. DB 오브젝트가 한 테스터의 전용을 위해 잠길 수 있으며, 이게 여러 사람이 동일 오브젝트를 사용하고 간섭하는걸 막아준다.
• 데이터베이스 테스트 오브젝트 타입(Database test object type): 테스트케이스가 하나의 데이터베이스 테스트 오브젝트 타입을 가질 수 있음. 추상 클래스(abstract class)이며, 두 개의 서브클래스를 가짐
  - 정적 DB 테스트 오브젝트 타입: 적절한 데이터베이스 오브젝트로 관련되는 사용자 정의 목록(a user-defined list)
  - 동적 DB 테스트 오브젝트 타입: 이 클래스가 두 개의 속성(데이터베이스 커넥션 스트링과 SQL 쿼리)을 가짐. SQL 쿼리는 DB를 쿼리하고 그 엔트리를 업데이트 하기 위해 Test Data Catalogue 클래스의 Update() 메쏘드에 의해 사용됨. 커넥션 스트링은 데이터를 뽑아내는 소스가 되는 구체적인 DB를 식별함

데이터 프라이버시 인지 테스트 환경(Data-privacy Aware Test Environments)

데이터 프라이버시 이슈가 테스트 데이터 관리의 이유일 때 “테스트 환경이 생산 데이터를 가지고 있나?”라는 질문을 하게 됨. 테스팅을 위한 생산 데이터 또는 인조 데이터 사용에 있어서 아래 그림처럼 여러 다른 패턴이 존재하며, 프라이버시 인지 테스트 환경이 테스터나 개발자에게로의 생산 데이터 노출을 줄이거나 제거한다. 

• 고전 패턴(classic pattern): 생산의 모든 데이터를 테스트 환경으로 복사. 테스터와 개발자가 생산 데이터를 보는걸 막기 위한 제한이 없음
• 온탑 패턴(on-top pattern): 생산 데이터를 어느 정도 보호함. 생산 환경을 복사한 테스트 환경에 인조 테스트 데이터(synthetic data)가 더해짐. 예를 들어, 애플리케이션의 일부가 인조 데이터로 작동되면, 테스터가 인조 데이터를 가지고 해당 부분을 테스트하고 생산 데이터에는 접근하지 않는다.
• 제거 및 삽입 패턴(castrate & inject pattern): 중요 데이터를 지우거나(“-“) 또는 가려서/익명화해서(“*M*”) DB를 청소한다. 이게 테이블, 컬럼, 또는 row 레벨에서 수행될 수 있음. 만일 테스터가 완전 제거된 어떤 데이터를 필요로 하면, 해당 테이블로 인조 데이터가 삽입된다.
• 외딴 탑 패턴(Isolated towers pattern): 최고의 데이터 보호를 제공함. 생산 환경과 테스트 환경은 어떤 데이터도 교환하지 않으며, 테스트 환경이 오로지 인조 데이터만 포함한다. 이 패턴이 후반 테스팅 단계(시스템 통합 테스트 환경, 복잡한 애플리케이션의 시스템 테스트 환경)에서 쓰기에는 비용이 비싸지만, 고객이 DB 복사본 제공을 꺼리거나 규제 이슈 등의 이유로 인해 이게 벤더의 유일한 옵션이 될 수도 있다.

[테스트 환경에서의 생산 및 인조 테스트 데이터 - 4가지 패턴(눈 모양은 테스터가 볼 수 있는 데이터를 상징)]

Swisscom Test Data Organizer

앞에 설명된 테스트 데이터 관리를 위한 기능들을 구현한 도구로, 조직에서 기 사용 중인 테스트 관리 도구인 HP Quality Center 위에 통합 구현됨. 자세한 내용 요약은 생략