RBT - test design/implementation and test environment

테스트 설계 / 구현 및 테스트 환경
(Test design/implementation and test environment)

위험기반 테스트에서 테스트 설계, 구현 및 테스트 환경 구축 활동은 테스트의 효율성과 신뢰성을 높이는 데 중요한 역할을 합니다. 이를 위한 전략은 위험 수준에 따라 차별화되며, 각 단계에서 구체적인 방법이 적용됩니다.

---

피처 구체화 및 테스트 전략 수립

테스트 설계 단계에서는 피처를 세부 피처로 구체화하여 각각의 특성을 명확히 정의합니다. 특히, 위험 수준이 높은 피처는 더 세밀하게 분석되고, 보다 정교한 테스트 케이스가 설계됩니다. 예를 들어, 경곗값 분석 기법을 사용할 때, 위험 수준이 높은 피처에는 일반적인 2-value 경곗값 분석 대신 3-value 경곗값 분석을 적용하여 더욱 철저한 검증이 이루어집니다. 이를 통해 테스트 설계는 위험도를 고려한 깊이 있는 접근 방식을 따르게 됩니다.

3-Value 경곗값 분석 (Three-Value Boundary Testing)

3-value 경곗값 분석은 각 경계에서 3개의 값을 선택하여 테스트하는 방법입니다. 즉, 경계 직전의 값, 경계 값 및 경계를 막 넘은 값을 사용합니다.

예시:

어떤 입력 값이 10에서 100 사이의 값을 가져야 하는 경우를 가정하면:

• 최소 경계: 10
• 최대 경계: 100

테스트할 값은:

1. 최소 경계 바로 아래 값 (9)
2. 최소 경계 값 (10)
3. 최소 경계 바로 위 값 (11)
4. 최대 경계 바로 아래 값 (99)
5. 최대 경계 값 (100)
6. 최대 경계를 넘는 값 (101)

이 방식은 경계값 주변의 오류 가능성을 최대한 포착할 수 있도록 도와줍니다.

2-Value 경곗값 분석 (Two-Value Boundary Testing)

2-value 경곗값 분석은 각 경계에서 2개의 값을 선택하여 테스트하는 방법입니다. 즉, 경계 값과 경계를 막 넘은 값을 사용합니다.

예시:

입력 값이 10에서 100 사이여야 한다고 가정하면:

• 최소 경계: 10
• 최대 경계: 100

테스트할 값은:

1. 최소 경계 값 (10)
2. 최소 경계를 넘는 값 (11)
3. 최대 경계 값 (100)
4. 최대 경계를 넘는 값 (101)

이 방법은 테스트할 값이 줄어들기 때문에 더 간단하지만, 특정 오류를 놓칠 가능성이 3-value 방식보다 높을 수 있습니다.

피처 구체화

피처 구체화는 전체 시스템에서 정의된 각 피처를 더 작은 단위로 분해하여 명확하고 구체적인 형태로 표현하는 과정입니다. 이를 통해 각 피처의 특성, 동작, 경계 및 예외 사항을 명확하게 정의할 수 있습니다. 피처 구체화는 테스트 설계에 중요한 영향을 미치며, 주로 다음 단계를 거칩니다:

• 피처 분해
  시스템의 주요 피처를 여러 하위 피처로 분해합니다. 예를 들어, 로그인 기능은 사용자 입력, 인증 과정, 오류 처리, 보안 정책 등으로 세분화될 수 있습니다.
• 요구사항 매핑
  각 세부 피처를 해당 요구사항에 매핑합니다. 이를 통해 해당 피처가 어느 요구사항을 충족하는지 명확히 이해할 수 있습니다.
• 테스트 가능한 단위로 구체화
  각 피처가 테스트 가능한 단위로 구체화되도록 피처의 조건과 시나리오를 정의합니다. 예를 들어, "사용자가 잘못된 비밀번호를 세 번 입력하면 계정이 잠긴다"는 명확한 조건을 포함한 테스트 케이스로 구체화될 수 있습니다.

 이 과정에서 위험 수준이 높은 피처는 더 세밀하게 분석되어야 합니다. 예를 들어, 금융 시스템에서 결제 관련 기능은 그 자체로 위험이 높으므로 오류가 발생할 가능성이 큰 부분이나 안전에 민감한 부분을 더욱 세부적으로 나누고, 그에 맞는 테스트 케이스를 준비해야 합니다.

테스트 전략 수립

테스트 전략 수립은 각 피처에 맞는 테스트 방식을 선택하고, 위험 수준에 따라 적절한 테스트 기법과 리소스를 할당하는 과정입니다. 이 과정에서는 다음 사항을 고려합니다

• 테스트 기법 선택
  피처의 특성 및 위험도에 맞는 테스트 기법을 선택합니다. 예를 들어, 단순한 계산 피처의 경우 경곗값 분석 또는 동등 분할 기법이 적합할 수 있지만, 복잡한 데이터 처리 피처의 경우 상태 전이 테스트나 오류 예측 기법이 더 적절할 수 있습니다.
  • 위험도가 높은 피처는 경곗값 분석 시 3-value 경곗값 분석처럼 더욱 철저한 기법을 적용할 수 있습니다. 이 기법은 최소값, 최대값 외에도 경계 내의 중간값을 추가로 테스트하여, 극단값뿐 아니라 중간값에서도 시스템의 동작을 확인할 수 있게 합니다.
• 테스트 강도 결정
  위험 수준이 높은 피처는 더 많은 테스트 케이스를 설계하고, 테스트 강도를 높여야 합니다. 예를 들어, 인증 시스템처럼 보안이 중요한 피처는 다양한 입력 조합을 통해 모든 가능한 시나리오를 테스트해야 할 수 있습니다.
  • 낮은 위험도의 피처는 일반적인 테스트 강도로 충분할 수 있지만, 높은 위험도를 가진 피처는 경계 사례, 극단적인 입력값, 비정상적인 입력값 등 다양한 상황을 고려한 테스트가 필요합니다.
• 테스트 우선순위 설정
  위험 수준을 기준으로 테스트 우선순위를 설정합니다. 예를 들어, 중요한 금융 거래 기능이나 사용자 개인정보 처리 기능 등은 위험도가 높기 때문에 우선적으로 테스트되어야 합니다. 이때, 위험도가 높은 피처는 단순 기능 테스트뿐만 아니라 성능 테스트, 보안 테스트 등 다양한 종류의 테스트가 병행되어야 합니다.
• 테스트 커버리지 확보
  피처가 제대로 작동하는지 확인하기 위해 테스트 커버리지를 확장합니다. 위험도가 높은 피처는 더욱 다양한 시나리오와 엣지 케이스를 포함한 테스트가 필요하며, 이를 통해 테스트 설계의 신뢰성을 높입니다.

결론

피처 구체화 및 테스트 전략 수립은 위험기반 테스트에서 중요한 부분입니다. 피처를 구체화하고, 각 피처에 맞는 테스트 전략을 수립함으로써, 위험 수준이 높은 영역에 대해 더욱 철저한 테스트를 수행할 수 있습니다. 이는 결국 테스트 효율성과 신뢰도를 높이며, 중요한 오류나 리스크를 조기에 발견하여 제품의 품질을 보장할 수 있도록 합니다.

---

우선순위 결정

위험 수준은 테스트의 우선순위를 결정하는 중요한 기준입니다. 위험이 높은 피처를 포함한 피처 집합은 테스트 수행에 있어 높은 우선순위를 부여받으며, 이에 따라 해당 피처들의 테스트 케이스 및 절차도 우선적으로 실행됩니다. 이로 인해 테스트 리소스가 제한된 상황에서도 가장 중요한 영역부터 테스트가 이루어져, 위험 완화에 집중할 수 있습니다.

prioritization

---

테스트 환경 요건 및 구축

테스트 환경 요건 및 구축은 소프트웨어 테스트 과정에서 중요한 부분입니다. 적절한 테스트 환경을 구축함으로써 실제 사용 환경과 유사한 조건에서 소프트웨어의 성능과 기능을 검증할 수 있습니다. 테스트 환경이 제대로 준비되지 않으면 테스트의 신뢰성이 떨어지고 결함을 발견하지 못하거나 잘못된 결과를 얻을 수 있습니다.

테스트 환경 요건

테스트 환경 요건은 테스트하려는 소프트웨어의 성격, 프로젝트 목표 및 사용자 요구사항에 따라 달라집니다. 기본적으로 고려해야 할 요건은 다음과 같습니다.

1. 하드웨어 요건
   • 서버
     테스트가 서버 기반일 경우, 실제 운영 환경과 유사한 서버가 필요합니다. 성능 테스트 시에는 테스트 규모에 맞는 서버 리소스가 준비되어야 합니다.
   • 네트워크
     실제 사용 환경과 유사한 네트워크 환경(대역폭, 지연 시간 등)을 제공하여 네트워크 관련 성능 문제를 테스트할 수 있어야 합니다.
   • 스토리지
     데이터의 읽기/쓰기 성능이 중요하다면 테스트 중 사용할 충분한 스토리지 용량과 성능을 제공해야 합니다.
   • 클라이언트 장비
     데스크톱, 모바일 기기 등 소프트웨어가 실행될 클라이언트 하드웨어의 종류와 사양을 정의합니다.
2.  소프트웨어 요건
   • 운영 체제
     소프트웨어가 지원하는 운영 체제(OS) 버전 및 종류에 대한 요구 사항을 충족해야 합니다.
     (예: Windows, Linux, iOS, Android 등)
   • 서버 및 데이터베이스
     애플리케이션이 사용하는 서버와 데이터베이스(예: Apache, Nginx, MySQL, Oracle 등)를 실제 환경과 동일하게 설정해야 합니다.
   • 미들웨어
     필요한 경우 미들웨어 소프트웨어(Java, Python, .NET, Node.js 등)가 설치되어 있어야 합니다.
   • API 및 외부 통합 시스템
     소프트웨어가 다른 시스템과 통합되는 경우 해당 API 및 외부 시스템의 에뮬레이터 또는 실제 시스템 접근 권한이 필요합니다.
3. 테스트 도구
   • 자동화 테스트 도구
     Selenium, Appium, JUnit 등 소프트웨어의 기능, 성능, 보안을 테스트하기 위한 자동화 도구가 필요합니다.
   • 모니터링 도구
     테스트 중에 성능, 리소스 사용률, 로그 등을 모니터링할 수 있는 도구가 필요합니다. 예로는 Grafana, Kibana, New Relic 등이 있습니다.
   • 버전 관리 시스템
     소프트웨어 및 테스트 스크립트의 버전을 관리하기 위한 Git, SVN 등의 도구가 필요할 수 있습니다.
4. 테스트 데이터
   • 샘플 데이터
     터테스트 환경에서 사용할 샘플 데이터를 준비해야 합니다. 실제 데이터와 유사한 형식과 구조를 가지되, 개인 정보는 보호되도록 익명화되어야 합니다.
   • 데이터베이스 스냅샷
     일정 시점의 데이터베이스 상태를 캡처한 스냅샷이 있으면, 동일한 조건에서 반복적으로 테스트를 수행할 수 있습니다.
5. 보안 요건
   • 인증 및 권한 관리
     사용자 인증(예: OAuth, JWT 등) 및 권한 관리가 실제 환경과 동일하게 설정되어야 합니다.
   • 보안 구성
     방화벽, SSL 인증서, 네트워크 보안 규칙 등 실제 환경에서의 보안 요구사항이 테스트 환경에도 적용되어야 합니다.
   • 테스트 데이터 보호
     테스트 중 민감한 정보가 노출되지 않도록 해야 합니다. 테스트 환경에서 가짜 데이터를 사용하는 것이 권장됩니다.
6.  테스트 환경의 접근성
   • 물리적 또는 가상 환경
     테스트는 로컬 환경, 물리적 서버 또는 클라우드 기반 가상 환경에서 수행될 수 있습니다. CI/CD(Continuous Integration/Continuous Deployment) 파이프라인에서 자동화된 테스트 환경이 요구될 수 있습니다.
   • 동시 접속 및 다중 사용자
     다수의 사용자가 동시에 테스트 환경에 접속할 수 있는지 확인하고, 복수의 팀이 서로 간섭하지 않도록 테스트 환경이 격리되어야 합니다.

테스트 환경 구축

테스트 환경 구축은 소프트웨어가 배포될 실제 환경과 유사한 환경을 구성하는 과정입니다. 적절하게 구축된 환경은 테스트가 예측 가능하고 신뢰성 있게 수행되도록 지원합니다.

1. 요건 분석
   • 소프트웨어의 특성과 테스트 목표를 이해하고, 이를 기반으로 테스트 환경의 하드웨어, 소프트웨어, 네트워크, 데이터 요건을 정의합니다. 또한 테스트의 범위와 종류(기능 테스트, 성능 테스트, 보안 테스트 등)에 따라 필요 자원을 분석합니다.
2. 물리적/가상화 환경 구성
   • 물리적 서버 또는 클라우드 서비스를 사용하여 테스트 환경을 구성합니다. 가상 머신(VM) 또는 컨테이너(Docker, Kubernetes)를 사용하여 환경을 보다 유연하게 설정할 수 있습니다. 가상화 기술을 통해 테스트 환경의 확장성 및 복제성을 확보할 수 있습니다.
3. 설정 및 설치
   • 운영 체제, 웹 서버, 데이터베이스 서버 및 필요한 미들웨어를 설치합니다. 이는 실제 운영 환경에서 사용될 버전과 동일하게 맞춰야 하며, 운영 체제의 패치 및 보안 업데이트도 적용해야 합니다.
4. 테스트 데이터 준비
   • 실제 환경을 반영한 테스트 데이터를 준비합니다. 데이터가 현실적이어야 테스트가 의미 있으며, 특히 성능 테스트의 경우 데이터의 양과 복잡성이 실제 상황과 유사해야 합니다.
5.  네트워크 설정
   • 네트워크 관련 테스트가 필요한 경우(예: 대규모 트래픽 시뮬레이션) 네트워크 대역폭, 라우팅 설정 등을 적용합니다. 실제 환경과 유사한 네트워크 조건을 시뮬레이션하는 것이 중요합니다.
6.  자동화 및 스크립팅
   • 환경 구축 및 재설치를 자동화하기 위해 스크립트를 작성합니다. 이를 통해 일관된 테스트 환경을 신속하게 구축할 수 있습니다. 예를 들어, Ansible, Chef, Puppet 등의 인프라 자동화 도구를 사용할 수 있습니다.
7.  테스트 환경 검증
   • 구축된 환경이 적절히 동작하는지 검증합니다. 즉, 각 구성 요소가 의도한 대로 상호작용하는지 확인하며, 필요 시 시스템 성능을 모니터링하는 도구를 설치하여 성능 문제가 없는지 확인합니다.
8.  테스트 환경 유지보수
   • 테스트 환경은 지속적으로 유지보수해야 합니다. 특히 소프트웨어의 업데이트 또는 테스트 시나리오의 변경에 따라 테스트 환경도 주기적으로 업데이트해야 하며, 필요에 따라 백업 및 복구 전략을 수립합니다.

테스트 환경 요건 및 구축은 소프트웨어 품질을 보장하는 데 필수적인 작업입니다. 실제 운영 환경과 유사한 테스트 환경을 구축함으로써 더 신뢰성 높은 테스트 결과를 얻을 수 있습니다. 잘 정의된 요건 분석과 구축 프로세스를 통해 테스트 과정에서 발생할 수 있는 문제를 사전에 예방하고, 제품의 품질을 보장할 수 있습니다.

---

테스트 데이터 요건 및 준비

테스트 데이터 요건 및 준비는 소프트웨어 테스트의 핵심 단계 중 하나로, 적절한 데이터를 사용하여 시스템을 검증하는 것이 중요합니다. 테스트 데이터가 정확하지 않거나 충분하지 않으면, 테스트 결과가 왜곡되거나 결함을 놓칠 수 있습니다. 따라서 테스트 데이터의 요건을 이해하고 이를 적절히 준비하는 것이 필수적입니다.

테스트 데이터 요건

테스트 데이터 요건은 주로 시스템의 기능, 사용자 요구사항, 그리고 테스트 범위에 따라 달라집니다. 주요 요건은 다음과 같습니다.

1. 현실성과 신뢰성
   • 테스트 데이터는 실제 운영 환경에서 발생할 수 있는 상황을 최대한 현실적으로 반영해야 합니다. 이를 통해 소프트웨어가 실제 데이터로도 정상적으로 작동하는지 검증할 수 있습니다.
   • 데이터는 다양한 형태로 준비되어야 합니다. 예를 들어, 사용자의 다양한 입력 유형(정상 값, 비정상 값, 경계 값 등)을 포함해야 하며, 각 상황에 맞는 데이터를 포함해야 합니다.
2. 충분한 커버리지
   • 모든 테스트 케이스가 충분히 커버되도록 테스트 데이터가 준비되어야 합니다. 시스템의 다양한 기능을 검증할 수 있는 데이터 세트가 필요하며, 각 기능이 다양한 상황에서 어떻게 동작하는지 확인할 수 있어야 합니다.
   • 입력 값의 종류에 따른 경곗값, 예외 처리, 오류 상황 등을 고려하여 데이터가 준비되어야 합니다.
3. 다양성
   • 데이터는 다양한 시나리오를 포함해야 합니다. 정형 데이터(숫자, 문자 등)와 비정형 데이터(이미지, 동영상 등), 대용량 데이터와 소용량 데이터 등 여러 유형의 데이터를 활용하여 시스템이 다양한 상황에서 어떻게 반응하는지 테스트할 수 있어야 합니다.
   • 예를 들어, 금융 시스템을 테스트할 때는 정상적인 거래뿐만 아니라 비정상 거래, 경곗값 거래, 대규모 트랜잭션 등 다양한 데이터를 포함해야 합니다.
4. 데이터 민감성 및 보안
   • 테스트 데이터에는 개인정보나 민감한 정보가 포함되지 않도록 주의해야 합니다. 실제 데이터를 사용할 경우, GDPR 등 개인정보 보호법을 준수하여 개인정보가 포함된 데이터를 사용할 때는 이를 익명화하거나 가명화해야 합니다.
   • 테스트 환경에서도 보안적인 측면을 고려하여 데이터의 안전성을 유지해야 합니다. 예를 들어, 금융 정보, 의료 정보 등 민감한 데이터는 필요 시 암호화하여 테스트 환경에서 노출되지 않도록 해야 합니다.
5. 일관성 및 무결성
   
   • 데이터의 일관성은 시스템의 복잡성에 따라 매우 중요할 수 있습니다. 특히 데이터베이스 연동 테스트 시 데이터의 무결성이 유지되어야 하며, 데이터가 잘못 연결되거나 누락되지 않도록 관리해야 합니다.
   • 다중 모듈이나 시스템 간 연동 테스트에서는 각 시스템 간의 데이터가 정확하게 일치하는지 확인해야 합니다.
6. 데이터의 대량성
   
   • 대용량 데이터를 처리하는 시스템일 경우, 실제 사용 환경에서 예상되는 데이터 양을 충분히 반영해야 합니다. 대용량 데이터가 제대로 처리되고 성능에 영향을 미치지 않는지 확인하기 위해 충분한 양의 데이터를 준비해야 합니다.
   • 성능 테스트, 부하 테스트에서는 트래픽 및 데이터 처리량이 실제 환경과 유사하거나 그 이상의 수준이 되도록 데이터를 준비해야 합니다.
7. 재사용성
   • 테스트 데이터는 여러 번 반복적으로 사용될 수 있어야 합니다. 특히 회귀 테스트에서 동일한 데이터 세트를 사용하여 이전에 발견된 결함이 수정되었는지 확인하는 것이 중요합니다.
   • 데이터가 쉽게 복원되고 재사용될 수 있도록 데이터베이스 스냅샷이나 자동화된 데이터 생성 스크립트를 사용하는 것도 유용합니다.

테스트 데이터 준비 과정

테스트 데이터를 준비하는 과정은 아래와 같은 단계를 거칩니다.

1. 테스트 요건 분석
   • 먼저, 소프트웨어의 테스트 요구사항을 분석합니다. 이를 통해 각 테스트 케이스에 필요한 데이터의 유형, 형식, 양 등을 결정합니다. 예를 들어, 기능 테스트인지 성능 테스트인지, 혹은 보안 테스트인지에 따라 필요한 데이터의 형태가 달라질 수 있습니다.
2. 실제 데이터 수집
   • 실제 운영 환경에서 사용할 데이터를 기반으로 테스트 데이터를 수집할 수 있습니다. 하지만 민감한 정보를 포함하지 않도록 익명화 작업이 필요하며, 데이터의 무결성도 보장해야 합니다.
   • 실제 데이터가 매우 민감할 경우, 대체 데이터를 생성하거나 테스트를 위한 특수 데이터를 사용할 수 있습니다.
3. 가상 데이터 생성
   • 경우에 따라서는 실제 데이터를 사용할 수 없는 상황이 있을 수 있습니다. 이 경우, 가상 데이터를 생성하여 테스트를 진행합니다. 가상 데이터는 예측 가능한 패턴과 다양한 변형을 포함할 수 있어야 합니다.
   • 가상 데이터를 자동으로 생성하는 도구들이 많이 존재합니다. 예를 들어, 데이터 생성기(Data Generator)를 사용하여 대량의 데이터베이스 레코드, 다양한 입력 값 등을 빠르게 생성할 수 있습니다.
4. 데이터 익명화 및 가명화
   
   • 실제 데이터를 사용할 경우, 개인정보 및 민감 정보를 보호하기 위해 데이터를 익명화하거나 가명화해야 합니다. 이는 특히 법적 요구사항을 준수하기 위해 중요합니다.
   • 익명화는 데이터 자체를 추적할 수 없도록 변경하는 것이며, 가명화는 추적 가능한 방식으로 변경된 데이터를 의미합니다. 예를 들어, 이름을 암호화하거나 주민등록번호를 대체 값으로 바꾸는 방식이 있습니다.
5. 데이터베이스 스냅샷 또는 백업
   • 데이터베이스가 필요한 테스트의 경우, 특정 시점의 데이터베이스 상태를 캡처한 스냅샷을 이용하면 테스트 환경을 반복적으로 재구성할 수 있습니다. 이를 통해 동일한 데이터 상태에서 일관된 테스트 결과를 도출할 수 있습니다.
   • 스냅샷이나 백업을 활용하여 테스트가 끝난 후에도 데이터베이스를 원래 상태로 복원할 수 있도록 준비하는 것이 중요합니다.
6. 데이터 검증
   • 준비된 테스트 데이터가 예상대로 동작하는지 사전에 검증해야 합니다. 즉, 테스트 데이터가 시스템의 요구사항을 만족시키고, 각 테스트 시나리오에 적합한지 확인해야 합니다.
   • 데이터의 정합성, 무결성 및 다양성을 보장하기 위해 사전에 검증 단계를 거치면 불필요한 오류를 줄일 수 있습니다.
7. 자동화된 데이터 관리
   • 테스트 데이터가 계속해서 필요할 경우, 자동화된 방식으로 데이터를 생성하고 관리하는 것이 효율적입니다. 이를 위해 테스트 데이터를 자동으로 생성하고 복원하는 스크립트를 작성하거나, 데이터베이스 관리 도구를 사용할 수 있습니다.

테스트 데이터는 소프트웨어 테스트의 정확성과 신뢰성을 높이는 중요한 요소입니다. 현실적이고 다양한 데이터를 준비하는 것이 중요하며, 특히 데이터 보안, 일관성, 재사용성 등을 고려하여 준비해야 합니다. 데이터 준비 과정은 사전 계획과 자동화를 통해 효율적으로 관리될 수 있으며, 이를 통해 고품질의 테스트를 수행할 수 있습니다.

반응형