반응형

제목: 테스트 데이터 관리(Test Data Management)

저자: Purnima Khurana 1, 인도

문서유형: 저널 페이퍼(6페이지), 2014

 

테스트 데이터 관리에 대한 기본적인 이해, 프로세스, 지원 도구들을 기술한 자료



테스트 데이터 관리

  • 테스트 데이터: 테스트케이스를 실행하는 동안 사용되는 정보 또는 테스트케이스 실행의 결과로 나온 정보
  • 테스트 데이터의 품질이 최종 제품의 품질에 직접적으로 연관되므로 테스트 데이터 관리가 중요(테스트케이스의 생성/관리/처분을 다루는 테스트케이스 관리와는 다른 개념)
  • 테스트 데이터 관리가 아래처럼 정의됨:
    1)
    테스트의 계획, 준비, 실행 동안 테스트 데이터를 식별하고, 획득하고, 정제하고, DB에 채워 넣고, 유지보수 하는 통제 프로세스
    2)
    테스트 데이터의 정확성, 완전성, 무결성을 보장하기 위해서 표준, 과업, 소유권, 역할 및 책임을 정의하는 프로세스
  • 테스트 데이터 관리 활동이 모든 테스팅 단계와 타입에서 요구됨(, 단위/시스템/승인 테스팅, 성능 테스팅, 생산 검증, 회귀 테스팅, 테스트 자동화 등)


왜 테스트 데이터를 관리할 필요가 있는가?

    테스터가 애플리케이션을 테스팅하는 것보다 테스트 데이터를 준비하는데 더 많은 시간을 빼앗김

    요구되는 테스트 데이터를 제공하는데 있어 테스터가 비즈니스 분석가(Business Analysts)에게 크게 의존함

    테스트 데이터 리프레시의 지연 때문에 테스팅 마감시간을 지키지 못하는 경우가 빈번

    많은 거짓 결함(false defects)’이 데이터 관련 이슈 때문이다. , 보고된 많은 결함들이 유효하지 않는 데이터가 원인으로 판명되어 기각됨

    테스트 데이터의 재사용이 없음. 새로운 테스트 조건이 새 데이터를 필요로 함에 따라 구 테스트 데이터가 물러날 필요가 있음. 또한 주기적인 리프레시가 수행될 필요가 있음

    테스트 데이터 생성을 위해 업스트림 시스템에 크게 의존함. 다른 시스템이 테스트 데이터를 제공해 주기를 기다리느라 많은 지연이 발생할 수 있음

    중앙 통제되는 마스터 테스트 데이터의 필요성. 다수의 애플리케이션이 동일 테스트 데이터를 동시에 참조할 수 있으므로, 데이터 일관성을 유지하기 위해 동시 접근이 통제될 필요가 있음

    프로젝트 크기가 증가함에 따라 테스트 데이터를 관리하는 것이 더 어려워짐


테스트 데이터를 준비하고 관리하는데 있어서 공통적인 어려움

    현실적인 데이터를 수집하고 분류하기가 어려움: 오늘날 비즈니스 애플리케이션에서 데이터가 통상적으로 다수의 내/외부 DB에 흩어져 있음. 테스트팀이 이런 DB에 접근하여 테스트 데이터를 추출하는데 많은 시간과 노력이 들게 됨. 테스팅 조직은 대개 실제 고객 정보가 있는 생산 시스템(또는 생산 백업 시스템)에 제한된 접근만 허용되며, 다양한 DB와 스키마를 다루는데 있어서도 제한된 스킬을 가짐. , 테스터가 필요한 데이터를 얻기 위해 다른 이해관계자(업무전문가, DBA)에게 의존해야만 한다는 의미. 이 또한 테스팅 프로세스에서 많은 시간을 낭비하게 만드는 요인이 됨

    데이터 휘발성(Data Volatility): 테스트 대상 시스템이 종종 생산 중에 있는 시스템(또는 다른 팀과 공유되는 시스템)과 함께 실행되는데, 이게 데이터를 휘발성(임의적으로 그리고 자주 변경됨)을 가지게 만든다. 이런 휘발성을 가지는 시스템을 기준으로 결과를 확인하기가 어렵거나 불가능

    데이터 민감성(Data Sensitivity): 민감한 정보(, 계좌, 사회보장번호, 신용카드번호)의 식별을 어렵게 만들어야 하는 필요성 때문에 생산 데이터의 사용이 제한됨. 생산 데이터가 테스트를 위해 사용될 때, 민감한 데이터가 부도덕한 사람들의 쉬운 목표물이 됨(특히, 해외 아웃소싱 서비스가 사용되는 경우 규정을 준수하도록 하는게 쉽지 않음)

    생산 시스템에 영향: 일부 테스트 시나리오가 생산 시스템에 있는 데이터에 영향을 주는 트랜잭션을 생성함. 예를 들어, 테스트에서 주문(order)이 생성되면 이것이 추적되고 삭제될 필요가 있음. 이 일에 테스터와 오퍼레이터의 시간과 노력이 들게 되며, 이게 주의 깊게 관리되지 않는 경우 비즈니스 오퍼레이션을 방해할 수도 있음

    저장소 유지 비용 증가: 비즈니스 애플리케이션의 수가 증가하면서 다뤄지는 데이터 양도 폭발적으로 증가. IT 예산에서 저장소 유지 비용의 부담이 높아짐에 따라 QA 팀도 자신들이 저장하고 관리할 데이터 양을 줄일 필요가 생김. 실제로 테스팅을 위해 데이터의 관련 서브셋만 필요할 때 전체 생산 DB를 그대로 복사해 유지하는 것은 비용효과적이지 않음. 하지만 생산 환경으로부터 데이터를 뽑아 낼 때 데이터의 참조 무결성(referential integrity)을 유지하기가 어려움

    데이터가 재사용을 위해 가용하지 않음: 생산 DB로부터 많은 노력과 비용을 들여 추출한 데이터가 종종 단 하나의 테스팅 과업/단계에만 쓰여짐. 만약 이 데이터가 모든 테스팅 도구에 의해 사용될 수 있다면, QA 조직이 데이터를 수집하고 준비하느라 투자한 노력과 비용에서 더 많은걸 얻을 수 있게 됨. 또한 매 테스팅 반복에서 데이터 추출이 요구될 수 있으므로 수동 추출 방법의 사용은 비용을 올리고 일정을 위태롭게 할 수 있음. 대량의 데이터를 구조화된 자동 솔루션 없이 수동으로 다루려 할 때 사람 에러(human errors)가 흔하게 발생

    필요한 데이터 양: 테스팅을 위해 필요한 데이터 양을 결정하는 것 또한 쉽지 않은 일이다. 일부 테스트 시나리오를 위해서는 오로지 작은 양의 데이터만이 목적을 달성할 수 있고, 또 다른 시나리오를 위해서는 아주 많은 양의 데이터가 요구될 수도 있음

    여러 다른 형식으로 가용한 데이터 다루기: 데이터의 가용한 소스가 여러 개이고 또한 다양한 형식으로 가용하면, 이런 데이터를 다루는 것도 쉽지 않음. 테스팅을 위한 관련 데이터가 여러 소스들로부터 수집되어야만 하고 또한 테스팅에 사용될 수 있도록 하나의 형식으로 매핑될 필요가 있다.

    동적 생성 데이터: 때때로 테스팅에 사용되는 데이터가 실행 시에 동적으로 생성되어야만 한다(, 트랜잭션의 결과 데이터, 계산 결과). 이런 데이터를 생성하고 관리하는 것도 큰 도전이다.

    테스트 결과를 테스트케이스 데이터에 덧붙여 저장하기: 테스트 결과와 테스트 데이터 간의 관계 때문에 구 데이터를 저장하는 것이 필수적이 됨. 이게 또한 많은 저장 공간을 소비하므로 과거 데이터(그리고 데이터 간의 관계)를 유지하는 것이 도전적인 업무임


테스트 데이터 관리 생명 주기

테스트 데이터가 아래의 단계들을 거치게 된다.

 

A. 요구사항 수집 및 분석 단계(Requirement Gathering and Analysis)

테스트 요구사항과 관련된 테스트 데이터 요구사항이 수집된다. 아래처럼 다양한 주제로 분류될 수 있음

1)     고통 영역(Pain Areas): 엄격한 테스팅이 수행될 필요가 있는 프로젝트의 중대 모듈을 결정해야 함

2)     데이터 원천지(Data Sources): 테스트 데이터를 준비하기 위해 어떤 데이터 소스가 고려되어야 할지 결정할 필요가 있음

3)     데이터 보안/마스킹(Data Security/Masking): 데이터 마스킹은 완전한 데이터셋에서 민감한 필드들을 가리는 프로세스. 데이터 마스킹의 목적은 민감한 데이터가 비생산 영역(, 테스팅 영역)으로 전혀 유출되지 않도록 보장하는 것

4)     데이터 볼륨 요구사항: 테스팅 용도로 얼마나 많은 데이터가 필요한지 결정되어야 함

5)     데이터 아카이브 요구사항: 데이터 아카이브가 통상적으로 아래로 구성됨
- 크기 관리: DB 크기 관리를 위한 효율적 메커니즘이 있어야 함. 시간이 지나면서 데이터베이스 크기가 증가하게 되고, 적극적으로 이걸 관리할 필요가 생김
- 구 데이터의 아카이브: 오래된 데이터는 좀 낮은 디스크 공간을 차지하는 영역으로 아카이브 되고, 나중에 필요할 때 마다 복원 될 수 있다.

6)     테스트 데이터 리프레시 고려사항: 테스트 데이터 리프레시는 생산 DB(또는 기타 다른 데이터 소스)로부터 나온 최신 데이터로 테스트 DB를 로딩/리프레싱 하는 프로세스이다.

7)     골드 카피 고려사항: 골드 카피는 미래 릴리즈를 위해 사용될 수 있는 데이터의 기준선 버전이다. 예를 들면, 처음으로 테스트 DB를 생산 DB로부터 로드할 때 이 복사본을 하나의 기준선으로 저장할 수 있음(미래 테스트 데이터 리프레시가 이것을 기준으로 수행됨)


B. 계획 및 설계 단계(Planning and Design)

  • 요구사항 분석에 기반하여 테스트 데이터의 여러 고통 영역(pain areas)을 해결하기 위한 적절한 솔루션이 설계됨
  • 문제의 규모와 실현가능한 솔루션을 확인한 후에 적합한 테스트 데이터 프로세스가 제안되며, 사내 솔루션으로 할지 상용 제품으로 할지(또는 이 둘의 혼합을 적용할지)를 선택함
  • 전체 프로젝트를 위한 노력 공수가 추정됨
  • 테스트 데이터 문제를 해결하기 위해 프로젝트가 취할 방향과 접근 방법을 제안하는 테스트 데이터 계획/전략이 개발됨


C. 테스트 데이터 생성 단계(Test Data Creation)

  • 테스트 데이터 전략에 기반하여 솔루션이 개발되고, 프로젝트 테스트 데이터 요구사항에 따라 다양한 기법을 통해 테스트 데이터가 생성됨
  • 수동 기법과 자동 기법의 혼합이 사용될 수도 있고, 자동 기법에 사내 도구 또는 상용 제품이 포함될 수도 있으며, 생산으로부터 리프레시거나 또는 맨 처음부터 생성될 수도 있다(또는 이 둘의 융합이 사용됨).
  • 이 단계 말의 출력물은 프로젝트를 위한 실제 테스트 데이터이다.


D. 테스트 데이터 확인 단계(Test Data Validation)

  • 생성된 테스트 데이터를 비즈니스 요구사항에 비교하여 확인함
  • 이 작업이 비즈니스 분석가에 의해 수행되거나 또는 양이 많은 경우라면 자동 도구를 사용해 수행될 수 있다.


E. 테스트 데이터 유지보수 단계(Test Data Maintenance)

  • 테스트 유지보수 단계와 유사(테스트가 변경됨에 따라 테스트 데이터에도 변경 요청이 생길 수 있음)
  • 테스트 데이터의 유지보수를 위해 전체 생명 주기가 다시 따라 오게 됨. 예를 들면, 향후 사용을 위한 골드 카피 생성, 크기 관리를 위한 아카이브, 골드 카피 업데이트, 테스팅을 위한 구 데이터 복원 등이 뒤 따르게 됨


테스트 데이터 관리 도구

많은 테스트 데이터 관리 도구가 여러 소프트웨어 회사에 의해 개발됨. 일부는 테스트 데이터 관리를 위한 독립형 도구를 개발했고, 일부는 더 큰 테스팅 도구의 한 부분으로 통합되는 모듈을 개발함(테스팅 도구가 테스트 데이터 관리 외에도 훨씬 많은 다른 일을 함). 아래 표는 시중에 나와 있는 일부 테스트 데이터 관리 도구를 나열하고 있음

 

도구 명

벤더

주요 특징

Oracle Test Data Management Pack

ORACLE

- 자동으로 데이터 관계 발견

- 생산 데이터의 서브셋팅(subsetting)을 통해 저장 비용을 크게 줄임

- 민감한 규제 데이터를 보호하면서 DB 크기를 줄임

SOLIX EDMS(Enterprise Data Management Suite)

SOLIX

- 생산 데이터 서브셋의 생성과 관리를 자동화하고 조직이 정의한 비즈니스 규칙에 기반하여 복사본을 생성

- 생성 시간을 수 일에서 단 몇 시간으로 줄이기 위해 테스트 DB가 자동 병렬 복사(parallel copy) 프로세스를 사용해 구축됨

LISA

ITKO

- 메시징 스트림(messaging streams)과 데이터 소스로부터 가상 데이터셋을 캡쳐하고 조작함.

- 모든 애플리케이션 티어와 기술을 가로질러 흘러가는 데이터를 듣고 있다가 캡쳐함

- 테스터가 데이터셋을 수정하고 이걸 함께 엮어서 시나리오로 만드는걸 용이하게 해줌

IBM InfoSphere OPTIM

IBM

- 데이터의 생성, 유지보수, 보호를 총괄하는 종합적인 테스트 데이터 관리 기능을 제공

- 클라우드와 빅 데이터 시스템에서 테스팅을 지원

- Hadoop을 테스트 데이터 착륙 지대로 활용(클라이언트가 더 낮은 비용과 더 빠른 속도로 자신의 테스트 데이터를 관리하는걸 허용)

HP Test Data Management Software

HP

- 모든 데이터 타입에 대해 커스톰 데이터 마스킹 기능 지원

- 공유 데이터 추출 규칙 지원(다른 추출 활동에서 지속적으로 재사용하기 위해 데이터 추출 규칙을 패러미터화 함)

- 공통적으로 사용되는 데이터 타입(, 사회보장번호, 전화번호)을 위해 내장 기능으로 민감한 데이터를 마스크함

TestBench

Original Software

- 테스트 시간과 데이터 풋프린트를 줄이기 위해서 크기가 줄고 대표성을 테스트 데이터 생성을 지원

- 사용자 관리되는 데이터 롤백 기능이 환경 다운타임을 줄임

 


반응형

+ Recent posts