페이퍼요약 - 단 대 단 통합 테스팅 설계 by Tsai

제목: 단 대 단 통합 테스팅 설계(End-To-End Integration Testing Design)

저자: W. T. Tsai 외 4인, 미국

문서유형: 학계 페이퍼(총 6페이지), 2001년

 

‘씬쓰레드(Thin thread)’라는 개념을 기반으로 체계적으로 통합 테스트케이스를 생성하는 E2E 테스팅 설계 방법을 소개한 자료

---

단 대 단 통합 테스팅(End-to-End integration testing)

• E2E 테스팅은 초점이 단일 모듈 상에 있는 모듈 테스팅과 다르다.
• E2E 테스팅은 통합 테스팅과 비슷하지만 통합 테스팅이 서브시스템의 어떤 서브 집합에든 중점을 둘 수 있는 반면 E2E 테스팅은 오로지 최종 사용자의 관점에만 초점을 맞춘다.
• E2E 테스팅은 이미 모듈 테스팅과 (여러 레벨의) 통합 테스팅이 수행되었고 승인되었다고 가정한다.

미국방성의 E2E 테스팅 프로젝트

• 미국방성(Department of Defense: DoD)이 E2E 통합 테스팅에 대한 프로젝트를 착수함
• 이 프로젝트는 테스트 계획(test planning), 테스트 설계(test design), 테스트 실행(test execution), 테스트 결과분석(test result analysis), 회귀 테스팅(regression testing), 리스크 분석 및 할당(risk analysis and assignment), 파급 효과 분석(ripple effect analysis)을 포함한 E2E 테스팅의 여러 측면을 커버함
• 이 논문은 E2E 프로젝트의 기본 토대가 되는 테스트 설계에 대해서만 소개 

E2E 테스트 설계

• E2E 테스트 설계는 테스트 대상 시스템의 E2E 테스트 요구사항을 명세하고, 이 명세에 기반하여 테스트시나리오(test scenarios)와 테스트케이스(Test cases)를 생성한다.
• E2E 테스팅은 사용자 관점에서의 기본적인 시스템 기능(a basic system function)을 나타내는 ‘씬쓰레드(thin threads)’를 사용하여 테스트 설계를 명세 한다.
• 테스트케이스는 테스트시나리오(즉, 씬쓰레드)로부터 생성되며 이 때 다양한 기법(예, 동등 클래스 테스팅, 경계값 테스팅, 랜덤 테스팅, 스트레스 테스팅)이 활용된다.

씬스레드(Thin Threads)

DOD Management Plan에 따르면 씬쓰레드는 아래와 같이 정의된다.

 

“데이터/메시지의 완전한 흔적(E2E). 대표적인 최소한의 외적 입력 데이터 샘플이, 상호연결된 시스템(아키텍쳐)의 집합을 통해 변형되어, 대표적인 최소한의 외적 출력 데이터 샘플로 생성됨. 씬스레드의 실행은 명세된 해당 기능을 수행하기 위한 방법을 시연해 보임”
“A complete trace (E2E) of data/messages using a minimally representative sample of external input data transformed through an interconnected set of systems (architecture) to produce a minimally representative sample of external output data. The execution of a thin thread demonstrates a method to perform a specified function.”

 

• 씬쓰레드는 통합된 시스템의 최소한의 사용 시나리오(a minimum usage scenario)이다.
• 씬쓰레드는 최종 사용자의 관점에서 완전한 시나리오이다. 즉, 시스템이 입력 데이터를 받아들이고, 어떤 계산(전산작업)을 수행하고, 결과적인 출력을 생성한다.
• 씬쓰레드는 전체 시나리오를 기술하고 단지 하나의 기능(function)만을 기술한다. 은행 애플리케이션을 예로 들자면 “지역 은행으로부터의 성공적인 인출 거래” 또는 “불충분한 자금으로 인해 원거리 은행으로부터의 실패한 인출 거래”가 씬쓰레드이다.

씬쓰레드 그룹(Thin-thread group)

• 어떤 공통성(commonalities)을 공유하는 여러 씬쓰레드들이 하나의 씬쓰레드 그룹으로 함께 묶여질 수 있다.
• 또한 그룹화(grouping)가 순환적(recursive)일 수 있다. 즉, 특정 공통성을 공유하는 하위-레벨 씬쓰레드 그룹들이 다시 하나의 상위-레벨 씬쓰레드 그룹으로 묶일 수 있다. 예, 씬쓰레드 그룹 “지역 은행으로부터의 인출 거래”와 또 다른 그룹 “원거리 은행으로부터의 인출 거래”가 상위 그룹인 “인출 거래”로 함께 묶임

씬쓰레드 트리(thin-thread tree)

• 순환적 그룹화를 통해 모든 씬쓰레드와 씬쓰레드 그룹이 하나의 트리로 계층 형태로 배열될 수 있다.
• 씬쓰레드와 유스케이스(use case)는 비슷한 기능을 제공한다(즉, 시스템 시나리오를 기술하는 일). 하지만 씬쓰레드가 유스케이스보다 더 많은 정보를 포함하며, 트리 형태로 구성된 씬쓰레드는 의존성 분석(dependency analysis), 리스크 분석(risk analysis), 추적성 분석(traceability analysis), 커버리지 분석(coverage analysis), 완전성 및 일관성 체킹, 테스트케이스/시나리오 생성 같은 다양한 분석에 적합하다.
• 테스트 엔지니어가 체계적으로 테스트케이스를 생성하는데 뿐만 아니라 다른 관련 작업(예, 리스크 분석 및 할당, 회귀 테스팅, 파급 효과 분석)을 수행하는데도 씬쓰레드 트리를 사용 할 수 있다.

씬쓰레드 식별하기(Identify Thin Threads)

• 씬쓰레드 식별은 시스템 기능성(functionality)과 아키텍쳐를 포함한 테스트 대상 시스템에 대한 철저한 이해를 요구한다.
• 시스템 기능성으로부터 식별된 씬스레드는 시스템의 외적 관점으로부터 식별되었으므로 ‘블랙박스 씬쓰레드’라 하고, 시스템 구조로부터 식별된 것들은 내적 관점이 고려되었으므로 ‘화이트박스 씬쓰레드’라고 지칭

 

은행을 예로 들자면 씬쓰레드 식별하기가 아래와 같이 이루어진다.

• 주요 비즈니스 기능을 분석하여 씬쓰레드 그룹을 식별한다. 즉, 블랙박스 씬쓰레드가 먼저 식별된다. 뱅킹 시스템에서 시스템의 주요 기능으로 인출(withdraw), 예금(deposit), 잔고 확인(check-balance)이 식별됨
• 그 입력을 분석하여 씬쓰레드 그룹을 분해한다. 예, 씬쓰레드 그룹 “잔고 확인 거래”를 “유효 입력”과 “유효하지 않은 입력”의 두 개 서브그룹으로 나눌 수 있음
• 그 출력을 분석하여 씬쓰레드 그룹을 분해한다. 예, 씬쓰레드 그룹 “인출 거래”는 성공적으로 인출하기나 불충분한 자금에 대한 에러 메시지 발생 같은 여러 다른 출력을 가질 수 있음. 즉, 이 씬쓰레드 그룹이 두 개의 서브그룹 “성공적인 인출 거래”와 “불충분한 자금으로 인한 실패한 인출 거래”로 분해될 수 있다.
• 그 가능한 실행 경로를 분석하여 씬쓰레드 그룹을 분해한다. 예, 씬쓰레드 그룹 “인출 거래”는 로컬 인출 거래와 리모트 인출 거래 두 개의 가능한 실행 경로를 가진다. 따라서 이 그룹이 “지역 은행으로부터 인출 거래”와 “원거리 은행으로부터 인출 거래”의 두 개 서브그룹으로 분해될 수 있다.

씬쓰레드 간의 관계(Relationships Among Thin Threads)

씬쓰레드들은 그 실행 경로와 관련하여 서로 연관이 있으며, 아래와 같은 관계(relationship)를 보인다.

• 포함(Contained in): 한 씬쓰레드의 실행 경로가 또 다른 씬쓰레드의 경로의 일부분
• 동일(Identical): 두 개의 씬쓰레드가 동일한 실행 경로를 가짐(이 경우 이들이 컨디션 같은 특정 애트리뷰트들의 집합을 공유할 수도 있음)
• 독립(Independent): 씬쓰레드들이 완전히 다른 실행 경로를 가짐

 

씬쓰레드 간의 이런 관계는 테스트 케이스 실행을 스케쥴링 하는데 유용함. 예를 들어, 어떤 씬쓰레드가 시스템의 핵심 경로(a critical path) 상에 있다면 해당 씬쓰레드를 철저하게 그리고 최대한 일찍 테스트 해야 함. 만일 테스팅을 위해 한 무리의 씬쓰레드들을 선정할 필요가 있다면 독립적인 실행 경로를 가진 씬쓰레드들을 선택하는 것이 커버리지 측면에서 바람직함

씬쓰레드 트리 구축하기(Construct Thin-Thread Trees)

• 씬쓰레드 트리의 뿌리(root)는 통합된 테스트 대상 시스템 전체를 나타내고, 브랜치 노드는 관련된 씬쓰레드(또는 씬쓰레드 그룹)들의 모음이며, 최하단 노드(a leaf)는 구체적인 하나의 씬쓰레드를 나타낸다.
• 대개의 경우 하나의 씬쓰레드 그룹 내에 있는 씬쓰레드들은 공통의 기능성으로 묶여있다. 따라서 씬쓰레드 트리는 테스트 대상 시스템의 기능적 분해도(a functional decomposition)로 볼 수도 있다.

 

씬쓰레드 트리는 아래와 같이 여러 방식으로 구축될 수 있다.

• 하향식(Top-down): 주요 씬쓰레드 그룹을 식별하고, 씬쓰레드 그룹들을 한 레벨씩 분해하여 트리를 구축한다.
• 상향식(Bottom-up): 더 쪼개질 수 없는 원자의 사용 시나리오(atomic usage scenarios)를 식별하고, 씬쓰레드(또는 씬쓰레드 그룹)를 한 레벨씩 조합하여 트리를 구축한다.
• 혼합식(Combined): 프로세스 동안에 하향식과 상향식 방법을 함께 사용한다.

[뱅킹 애플리케이션의 씬쓰레드 트리 예]

씬쓰레드로 데이터 첨부하기(Attach Data to Thin Thread)

• 각 씬쓰레드(씬쓰레드 그룹)를 위해 입력 데이터, 출력 데이터, 조작되는 데이터를 식별하는 것이 필수적임
• 예를 들어, 뱅킹 시스템에서 “인출 거래”와 관련된 데이터로 a) 은행 ID, b) 계정 정보, c) 계정 비밀번호, d) 거래 정보 등이 있을 수 있다.
• 이 데이터들이 관계된 씬쓰레드로 첨부되고 테스트 데이터베이스에 저장되어야 한다(이런 데이터는 테스트케이스 생성에 유용함).

컨디션(Conditions)

‘컨디션’은 씬쓰레드의 실행에 영향을 미치는 술부(predicates)이다. 각 씬쓰레드는 자신의 ‘triggering 이벤트’를 명세하는 컨디션(또는 predicates)의 집합과 관련되어 있으며, 자신의 모든 컨디션들이 충족될 때에만 활성화(activated)된다. 컨디션에는 아래와 같은 것들이 포함된다.

• 통신 컨디션(Communication conditions): 타임아웃 메커니즘, 복구 메카니즘, 보안 메카니즘, 프로토콜에서의 통신 지연
• 시퀀싱과 타이밍 컨디션(Sequencing and timing conditions): 주문(요청) 순서, 최소 지연, 최대 허용 가능한 지연, 일/월/분기 업데이트, 협업 당사자들 간의 협조
• 데이터 컨디션(Data conditions): 데이터 항목(data items) 관련 조건들. 예, 뱅킹 애플리케이션의 모든 거래(transaction)에서 사용자 계정 번호가 요구되며 유효한 번호 없이는 거래가 실패하게 됨
• 환경적 컨디션(Environmental conditions): 외적 환경이 씬쓰레드가 다르게 동작하도록 영향을 미칠 수 있음. 예, 뱅킹 시스템에서 한 은행의 과다 부하(heavy load)는 거래 데이터가 모두 유효하다 할지라도 해당 거래가 거부되게 만들 수 있음

컨디션 식별하기(Identify Conditions)

씬쓰레드와 마찬가지로 컨디션도 시스템 기능성(functionality)과 구조(structure)로부터 식별될 수 있으며, 컨디션의 긍정적 측면과 부정적 측면 둘 다를 식별하는 것이 중요하다. 아래는 컨디션 식별의 몇몇 방법을 보여준다.

a.     씬쓰레드의 입력과 출력으로부터 데이터 컨디션을 식별한다. 예를 들어, 씬쓰레드 “성공적인 인출 거래”는 입력 데이터로 계정 번호, 비밀번호, 인출액, 계정 잔고를 가질 수 있다. 따라서 이 씬쓰레드를 위한 컨디션들은 아래를 포함한다:
1) 유효한 계정 번호(Valid account number)
2) 유효하고 매칭되는 비밀번호(Valid and matching password)
3) 유효한 인출 금액(Valid withdraw amount)
4) 충분한 계정 잔고(Sufficient account balance)

b.     외적 사용자 인터페이스로부터 데이터 컨디션을 식별한다. 예를 들어, ATM 사용자 인터페이스가 “계정 ID”, “비밀번호”, “거래 유형” 같은 데이터 항목을 가질 수 있다. 따라서 유효한 계정 ID와 비밀번호, 유효하지 않은 계정 ID와 비밀번호 같은 컨디션이 도출될 수 있다.

c.      소프트웨어 컴포넌트들 간에 교환되는 데이터로부터 데이터 컨디션을 식별한다. 예를 들어, ATM 기계는 거래를 은행으로 전송하기 전에 이를 암호화 한다. 따라서 성공적인 거래를 위한 컨디션에 “유효한 거래 메시지”와 “성공적인 암호화”가 포함된다.

d.     컴포넌트들 간의 논리적 및 물리적 커넥션으로부터 통신 컨디션을 식별한다. 예를 들어, “정확한 통신 프로토콜”은 ATM 머신과 뱅킹 시스템 간의 통신으로부터 식별된 컨디션이다.

e.     분산된 서브시스템들 간의 물리적 커넥션으로부터 네트워크 컨디션을 식별한다. 예를 들어, ATM 머신과 뱅킹 시스템 간의 커넥션으로부터 식별된 컨디션에 “점대점 커넥션(point-to-point connection)”과 “1초의 최대 지연”이 포함될 수 있다.

컨디션들 간의 관계(Relationships Among Conditions)

컨디션들의 모든 조합(combinations)을 완전하게 테스트 하는 것은 실현 가능하지 않음. 따라서 컨디션들 간의 관계를 분석하는 것이 중요(테스터가 애플리케이션을 테스트 하기에 적합한 테스트 컨디션들의 집합을 구축할 수 있도록 해줌). 컨디션들간의 전형적인 관계는 아래와 같다.

• 독립(Independent): 두 개 컨디션이 하나가 다른 하나에 상관없이 발생할 수 있으면 서로 독립적이다
• 유발(Trigger/trigger-by): 한 컨디션이 다른 컨디션을 활성화되게 만들 수 있다.
• 상호 배타(Mutually exclusive): 두 개 컨디션이 동시에 존재할 수 없으면 상호배타적이다. 예를 들어, 컨디션 “유효한 은행 계정”은 또 다른 컨디션 “유효하지 않은 은행 계정”과 상호 배타적이다.
• 관련(Related): 두 개 컨디션이 동일한 쓰레드에서 사용되면 서로 관련되어 있다.

컨디션 트리 구축(Construct Condition Trees)

• 컨디션들도 재사용과 관리를 용이하게 하기 위해 그룹화되고 트리 구조로 조직될 수 있다.
• 씬쓰레드 트리와 마찬가지로 컨디션 트리의 뿌리는 테스트 대상 시스템을 나타내며, 브랜치 노드는 서로 관련된 컨디션들의 모음이고, 말단 노드는 구체적인 컨디션을 나타낸다.

씬쓰레드 트리와 컨디션 트리 간의 관계

• 컨디션 트리의 구축과 씬쓰레드 트리의 구축은 서로 영향을 준다.
• 먼저 씬쓰레드 트리 분석이 컨디션의 식별로 이어질 수 있다. 예를 들면, 몇몇 씬쓰레드가 동일한 컨디션을 공유할 수 있음(“성공적 지역 인출 거래”와 “성공적 원거리 인출 거래”가 같은 입력 데이터 컨디션을 공유함). 일부 씬쓰레드들은 배타적인 컨디션을 가질 수도 있음(예, “성공적 지역 인출 거래”와 “무효한 사용자 비밀번호로 인한 실패한 지역 인출 거래”)
• 역으로 컨디션을 분석하는 것이 신규 쓰레드의 식별로 이어질 수도 있다. 일단 씬쓰레드(또는 씬쓰레드 그룹)의 컨디션들이 식별되었다면, 관련된 컨디션들의 조합(combination)을 통해 신규 쓰레드가 발견될 수도 있음
• 따라서 씬쓰레드 트리와 컨디션 트리의 구축은 반복적인 프로세스이며, 테스터는 양 트리에 빠진 항목들을 식별하기 위해 두 개 트리를 교차 검토(cross-examine) 할 수 있다.

테스트 시나리오 생성(Test Scenario Generation)

하나의 씬쓰레드가 테스트 대상 시스템의 단일 E2E 기능을 나타내지만 실무에서는 사용자가 단일 세션에서 다수의 기능을 수행할 수 있다. 따라서 테스팅도 원자 기능(atomic function)의 실행에만 제한되지는 않으며 원자 기능의 시퀀스(a sequence)나 조합(a combination) 일 수 있다. 이런 합성 씬쓰레드(composite thin threads)를 명세하기 위해 복합 테스트시나리오(complex test scenario)가 사용되며 아래 오퍼레이터를 이용하여 구성된다.

• 시퀀싱(Sequencing): 하나의 씬쓰레드 다음에 또 다른 씬쓰레드가 바로 이어짐
• 루핑(Looping): 하나의 씬쓰레드가 여러 번 반복됨
• 조건부 실행(Conditioned execution): 복합 테스트 시나리오에 컨트롤 결정(control decision)이 더해짐. 예, if-then-else

 

아래 그림은 위 오퍼레이터들의 조합을 통해 하나의 복합 시나리오가 형성되는 것을 보여준다. 복합 시나리오는 씬쓰레드로부터 뿐만 아니라 씬쓰레드 그룹과 타 복합 시나리오들로부터도 형성될 수 있다.

[복합 테스트시나리오 예 – 씬쓰레드(TT)들이 시퀀싱, 루핑, 조건부 실행으로 조합됨]

E2E 테스트케이스 생성(Test Case Generation)

• 테스트케이스는 씬쓰레드(또는 복합 시나리오)로부터 아래와 같은 방법으로 생성될 수 있다.
  1) 기존의 여러 테스팅 기법에 기반하여 쓰레드와 연관된 컨디션을 충족하는 입력 데이터를 식별한다(즉, 컨디션 변수에 실제 값을 할당)
  2) 쓰레드 명세(thread description)로부터 예상 결과를 결정한다.
• 테스트 입력을 선정하는 방법에는 컨디션의 경계에 가까이 있는 점들을 선택하거나(즉, boundary 테스팅), 무작위로 선정하거나(즉, random 테스팅), 입력을 동등 클래스로 분류하고 각 카테고리에서 전형적인 데이터를 선정하거나(즉, partition 테스팅), 용법에 기반하여 테스트 케이스를 생성할 수도 있다(즉, 클린룸 방법에서의 usage-기반 테스팅).
• 종종 씬쓰레드(테스트시나리오)가 여러 컨디션에 의해 영향을 받고, 각 컨디션을 충족시키는데 다수의 데이터가 요구될 수 있음. 이 경우 의사결정 테이블(a decision table)이 여러 다른 컨디션 조합으로부터 테스트 입력을 생성하는데 도움이 된다.

도구 지원(Tool Support)

• E2E 테스팅이 복잡하므로 이를 지원하기 위해 웹 기반 프로토타입 도구가 개발됨. 이 도구는 3-티어 아키텍쳐를 가지며, Enterprise JavaBean(EJB)을 사용하여 J2EE 플랫폼 상의 분산 환경에서 동작한다.
• 백엔드에 파일/데이터베이스 서버와 테스트 데이터 저장소가 있고, 미들 층이 E2E 테스팅의 핵심 기능(core functions)을 수행하며, 프론트 티어는 프리젠테이션 층이다(즉, 사용자에게 테스트 데이터와 분석 결과의 다양한 그래픽 뷰를 제공).
• 이 도구는 대화식(interactive)으로 데이터의 수집, 구성, 분석을 용이하게 하며, 또한 소프트웨어 개발자, 테스터, 프로젝트 관리자, 프로그램 관리자, 감독 조직 간의 협업을 향상시킨다.

[E2E 테스트 관리 도구의 아키텍쳐]