개발생명주기단계별/통합_시스템 테스팅

페이퍼요약 - 시나리오를 사용한 소프트웨어 시스템 확인 및 테스팅 by Ryser

grapevine9700 2019. 8. 14. 06:30
반응형

제목: 시나리오를 사용한 소프트웨어 시스템 확인 및 테스팅(A Practical Approach to Validating and Testing Software Systems Using Scenarios)

저자: Johannes Ryser 1, 스위스

문서유형: 페이퍼( 18페이지), 1999

 

시나리오를 이용하여 테스트케이스를 도출하는 방법을 ATM 예를 들어 기술한 자료



시나리오 기반 소프트웨어 테스트 방법

  • 시나리오(또는 유스케이스)는 사용자 중심의 관점에서 시스템의 기능 및 동작을 캡쳐하는 수단으로, 대부분의 객체지향 소프트웨어 개발 방법론에서 사용자 요구사항 도출과 명세를 돕는데 사용된다. 또한 시나리오는 개발 시스템을 위한 일종의 추상적 수준의 테스트 케이스가 되기도 한다.
  • 본 논문은 시스템 테스트를 위한 테스트케이스를 체계적으로 도출하는데 시나리오를 활용하는 방법을 제안함. SCENT(A Method for SCENario-Based Validation and Test of Software)라 불리는 이 방법은 자연어로 작성된 시나리오를 상태차트(statechart)로 정형화하고, 상태차트에 테스트케이스 생성에 유용한 정보를 주석(annotation)으로 달며, 상태차트의 경로를 횡단하면서 구체적인 테스트 케이스를 결정한다.


시나리오 생성(Scenario Creation)

제안된 SCENT 방법에서는 아래 15-단계를 통해 시나리오를 생성함(기본적으로 순차 프로세스이지만 실제 시나리오 생성에서는 단계들이 반복적으로 수행됨)

단계

단계 기술

결과물

1

시스템과 상호작용하는 모든 액터를 찾는다.

액터 목록

2

모든 (관련된 외부) 이벤트를 찾는다.

이벤트(트리거) 목록

3

시스템의 결과와 출력을 결정한다.

시스템 출력

4

시스템 경계(boundaries)를 결정한다.

시스템 경계

5

개괄적인 시나리오를 생성한다(비즈니스 프로세스 레벨이나 태스크 레벨의 인스턴스 시나리오 또는 타입 시나리오).

시나리오 목록

6

중요도에 따라 시나리오에 우선순위를 주고, 시나리오가 모든 시스템 기능을 커버하는지 확인한다.

우선순위화된 시나리오 목록

7

인스턴스 시나리오를 타입 시나리오로 변형한다. 각 시나리오의 단계별(step-by-step) 액션/이벤트를 서술한다.

시나리오에서 개략적인 액션 흐름

8

개괄 다이어그램(an overview diagram)을 생성한다.

개괄 다이어그램

9

사용자가 시나리오와 다이어그램을 검토하고 의견을 낸다.

시나리오에 대한 코멘트와 주석

10

액션의 정상 흐름에 대한 서술에서 각 단계를 단일 원자 액션으로 분할(세분화)하여 시나리오를 정제한다.

정상적인 액션 흐름 서술

11

액션의 대안 흐름을 모델링하고, 예외 및 예외에 대한 대응을 명세한다. 테스트케이스 도출에 대한 힌트(추가 정보)를 포함한다.

액션의 대안 흐름, 시나리오에서 예외 처리

12

추상적 시나리오(하나 이상의 시나리오에서 등장하는 상호작용 시퀀스)를 추려낸다.

추상적 시나리오

13

시나리오에 성능/비기능/품질 요구사항을 포함시킨다.

품질 관련 주석이 달린 시나리오

14

개괄 다이어그램에 변경을 반영한다

갱신된 개괄 다이어그램

15

사용자가 시나리오를 체크하고 검인하도록 한다(공식 검토)

검인된 시나리오

 

본 논문에서 예로 사용되는 자동입출금기(automated teller machine: ATM)의 간단한 명세가 아래와 같다(공간 제약상 실제 ATM 명세의 일부만 주어짐). 

ATM에서 고객이 자신의 계정 잔액을 조회하거나 특정 금액의 현금을 인출할 수 있음. 시스템에 액세스하여 은행 거래를 하기 위해서 고객은 카드와 PIN(a personal identification number)이 필요함. ATM 시스템은 고객 및 계정 정보를 얻고 계정 잔액 조회와 갱신을 하기 위해 중앙 은행 시스템과 상호작용함. 영수증은 발행되지 않음 

[ATM 머신 명세]


아래는 위 ATM 예의 시나리오 생성 프로세스를 단계별로 보여준다.

  • 단계1 액터 식별:고객’, ‘서비스 요원’, ‘오퍼레이터’, ‘은행 시스템 4개 액터를 식별함
  • 단계2 이벤트 식별: 고객의 카드 투입, PIN 코드 입력, 액션 선택, 금액 입력, 카드 돌려 받음, 현금 집어감; 오퍼레이터가 지폐를 채워 넣음; 서비스 요원이 기계를 손 봄
  • 단계3 시스템 입력과 결과/출력 결정: 시스템 입력으로 카드’, ‘PIN’, ‘액션 선택’, ‘금액’, ‘지폐가 있음. 시스템 결과/출력으로 카드’, ‘잔액 정보’, ‘현금/지폐가 있음
  • 단계4 시스템 경계 결정: 해당 환경에 속하는 모든 사람과 은행 시스템. 고객 정보와 계정 정보는 은행 시스템에 보관됨
  • 단계5 개괄적 시나리오 생성: ‘(1)잔액 조회’, ‘(2)현금 인출’, ‘(3)ATM 수리’, ‘(4)지폐 재장전 4개 시나리오를 생성
  • 단계6 시나리오 우선순위화: 1 순위 시나리오는 (1), (2), (4)이고, 2 순위는 (3)이다. 이 시나리오들이 모든 시스템 기능을 커버하는지 확인
  • 단계7 시나리오의 단계별 액션 서술: 아래는 ‘(2)현금 인출시나리오의 서술 예이다.

시나리오 2: 현금 인출

고객이 돈을 인출한다.

액터: 고객

액션 흐름:

1. 고객이 카드를 투입한다.

2. 시스템이 카드의 유효성을 체크한다.

3. 시스템이 “PIN을 입력하세요”라는 대화창을 디스플레이한다.

4. 고객이 자신의 PIN을 입력한다.

5. 시스템이 PIN을 체크한다.

6. 시스템이 메인메뉴를 디스플레이한다.

7. 고객이 메인메뉴의 “현금 인출”을 선택한다.

8. 시스템이 현금 인출 대화창을 디스플레이한다.

9. 고객이 원하는 금액을 입력한다.

10. 시스템이 카드를 반환한다.

11. 시스템이 돈을 내어 준다.

12. 시스템이 웰컴화면을 디스플레이한다.


  • 단계8 개괄 다이어그램 생성: 예를 간단히 하기 위해 개괄 다이어그램(UML 표기법의 표준 유스케이스 다이어그램)은 생략함
  • 단계9 시나리오 검토: 사용자가 생성된 시나리오를 검토하고 코멘트를 함
  • 단계10 시나리오 정제: 개괄적인 시나리오의 단계들이 단일 원자(atomic) 액션으로 정제됨. 현금 인출시나리오에서 첫 단계는 고객에 의한 단일 액션이므로 정제가 불필요. 두 번째와 네 번째 단계는 아래와 같이 정제 될 수 있음

2.1 시스템이 카드 번호를 읽고 유효성 확인을 위해 이것을 은행 시스템으로 보낸다.

2.2 은행 시스템은 카드 번호를 체크하고 확인 코드를 반환한다(Code 1: 유효 카드, Code 0: 무효 카드; 카드를 고객에게 반환, Code –1: 분실 및 도난 카드; 카드 압수)

3. 시스템이 “PIN을 입력하세요”라는 대화창을 디스플레이한다.

4.1 고객이 숫자 키 하나를 누른다.

4.2 시스템이 화면 상의 입력 필드에 보호 글자(에코 키)를 디스플레이한다.

4.3 고객이 숫자 키 하나를 누른다

4.4 …


  • 단계11 대안 흐름 모델링과 예외 명세: SCENT 방법에서는 예외 흐름이 액션의 정상 흐름으로부터 분리됨(이는 시나리오 개발자가 시나리오 매 단계에서 발생할 수 있는 대안/예외에 대하여 지속적으로 생각하게 만들고, 정상 흐름이 여러 대안으로 인해 어수선해지지 않도록 해준다). ‘(2)현금 인출시나리오의 첫 단계인 고객이 카드를 투입한다에서 카드를 투입할 수 없는 예외가 생길 수 있으며(, 투입 구멍이 막힘), 이런 대안 흐름이 아래와 같이 서술된다.

1a. 카드 투입 구멍이 막힘

1a.1 고객이 창구 직원(사람 텔러)에게 알리거나 서비스 부서에 전화하여 알림 

1a.2 사람에게 알린 경우: 텔러가 서비스 부서에 연락한다.

1a.3 서비스 부서가 기계를 수리한다. ‘(4) ATM 수리’ 시나리오로 건너 뛴다.


  • 단계12 추상적 시나리오 추려냄: 시나리오의 특정 시퀀스가 다른 시나리오에서 재사용될 수 있음. 위 예에서는 아래와 같은 인증 절차(authentication procedure)가 추려진다.

1. 고객이 카드를 투입한다.

2. 시스템이 카드의 유효성을 체크한다.

3. 시스템이 “PIN을 입력하세요”라는 대화창을 디스플레이한다.

4. 고객이 자신의 PIN을 입력한다.

5. 시스템이 PIN을 체크한다.

6. 시스템이 메인메뉴를 디스플레이한다.


  • 단계13 시나리오에 비기능/품질 요구사항 포함: ATM에서 투입된 카드의 유효성 체크가 2초 이내에 수행되어야 한다고 가정함. 또한 빨간색은 에러 메시지에만 사용되어야 함. 이를 반영하기 위해 시나리오 서술의 두 번째 단계가 아래와 같이 변경됨

1. 고객이 카드를 투입한다.

2. 시스템이 카드의 유효성을 체크한다. 이 오퍼레이션은 2초 미만이 걸려야 한다.

3. 시스템이 …


빨간색 사용에 대한 요구사항도 아래와 같이 시나리오에 덧붙여진다.

11. …

12. 시스템이 웰컴화면을 디스플레이한다.

비기능 요구사항: 빨간색은 오로지 에러 메시지에만 사용됨



  • 단계14 개괄 다이어그램 교정: 추상적 시나리오, 새롭게 발견된 시나리오, 분할/병합된 시나리오가 개괄 다이어그램에서 갱신되어야만 함. 이 다이어그램과 시나리오 서술이 일관성을 유지해야 한다.
  • 단계15 시나리오 검인: 사용자가 정제된 시나리오를 체크하고 검인한다. 발견된 에러/문제에 따라 시나리오가 변경 및 갱신된다(프로세스의 단계10~15를 반복).


시나리오 정형화(Scenario Formalization)

  • 위에서 생성된 서술식 시나리오를 상태차트로 정형화함으로써 자연어 서술에 존재하는 애매모호함, 모순, 누락, 부정확, 불일치 등을 발견한다.
  • 첫 시나리오가 개발되자마자(시나리오 생성 프로세스에서 단계5와 단계7) 이 시나리오와 매치하는 상태차트를 생성한다. 시나리오 각각에 대해 하나의 상태차트를 생성하고, 주어진 시나리오의 정상 흐름, 모든 예외 흐름, 모든 대안 흐름이 하나의 상태차트에 포함된다(시나리오의 정상 흐름을 먼저 모델링하고 대안 흐름들은 나중에 통합).
  • 시나리오를 상태차트로 매핑하는 것은 창의적인 모델링 작업이기 때문에 동일한 시나리오에 대해서도 개발자에 따라 결과물(상태차트)이 상당히 다를 수 있다.


아래는 위 ATM의 추상적 시나리오인 인증(정상적인 액션 흐름)’을 상태차트로 모델링한 것이다.

[‘인증’ 시나리오를 표현한 상태차트]


상태차트는 시스템의 동작(이벤트나 주어진 조건에 시스템이 어떻게 반응하는지)을 기술하지만 데이터, 성능, 품질 같은 중요 정보를 빠트린다. 따라서 테스팅에 필요한 정보를 제공하고 구체적인 테스트 케이스 도출에 적합한 상태차트를 만들기 위해서 상태차트의 필요한 곳에 사전조건, 사후조건, 입출력 데이터 범위나 데이터 값, 비기능 요구사항(특히 성능 요구사항) 같은 주석을 덧붙인다. 아래는 위 인증상태차트에 대안 흐름과 주석이 추가된 예. 여기에는 무엇이 무효 PIN인지 알 수 있도록 PIN의 형태와 범위를 명세한 데이터 주석이 있고, 또한 두 개의 성능 제약(“카드 유효성 확인에 2초 미만 소요”, “PIN 검증에 0.05초 미만 소요”)이 포함되어 있음

[대안 흐름과 주석을 포함한 ‘인증’ 상태차트]


테스트케이스 도출(Test Case Derivation)

  • 상태차트 상의 경로를 횡단하면서 체계적으로 테스트케이스를 도출함. 먼저 상태차트에 표현된 정상 액션 흐름을 따라가고, 이어서 대안/예외 흐름을 표현한 경로가 횡단된다. 이미 횡단된 경로는 상태차트 상에 표시를 하여 알 수 있게 함
  • 제안된 방법에서는 그래프의 모든 노드(상태)와 모든 링크(전이)가 적어도 하나의 테스트케이스에 의해 커버되도록 테스트케이스가 도출되며, 더 정교한 커버리지(, 스위치 커버리지, n-스위치 커버리지)가 선택될 수도 있다.
  • 아래 표는 위 인증상태차트의 경로를 가로지르는 테스트케이스 몇 개를 보여줌. 첫 번째 테스트케이스는 액션의 정상 흐름을 따라가고(, 카드가 투입되고, 카드와 PIN이 모두 유효), 두 번째는 부정확한 PIN이 입력되는 예외 상황이고, 세 번째는 유효하지 않은 PIN(너무 짧은 PIN)이 입력되는 경우이며, 네 번째는 상태차트에서 세 번째 무효 PIN”이라 명명된 링크를 가로지르기 위해서 세 차례 무효 PIN이 입력된 경우이다.


테스트 준비

ATM 작동 중, 카드와 PIN(1234)가 발행됨, 카드가 투입됨

ID

상태

입력/사용자 액션/조건

예상 출력

1.1

카드가 감지됨

카드를 읽을 수 있고, 카드가 유효하며, 유효 PIN (1234)이 시간 내에 입력됨

메인메뉴 디스플레이

1.2

카드가 감지됨

카드를 읽을 수 있고, 카드가 유효하며, 무효 PIN(1245)이 시간 내에 입력됨(첫 시도)

재시도 메시지 디스플레이

1.3

재시도 메시지

무효 PIN(123)이 시간 내에 입력됨(두 번째 시도)

재시도 메시지 디스플레이

1.4

재시도 메시지

무효 PIN(1234567)이 시간 내에 입력됨(세 번째 시도)

카드 압수, 고객에게 알림

[ATM 예의 테스트케이스]


위 테스트케이스는 요구사항의 상세 사항들을 반영하기 위해 다시 정제될 수 있다. 예를 들면, 위 표의 1.1 테스트케이스가 아래처럼 더 상세한 단일 작업들로 나누어질 수 있다. 테스팅에서 추상화 레벨(, 어떤 상세 정도로 테스트 될지)에 대한 의사결정은 실행할 테스트의 종류(단위, 통합, 또는 시스템 레벨)와 기 수행된 테스팅에 달려 있다.

테스트 준비

ATM 작동 중, 카드와 PIN(1234)가 발행됨, 카드가 투입됨

ID

상태

입력/액션/조건

예상 출력

1.1

카드가 감지됨

카드를 받아 들임

카드가 투입됨, 확인 화면이 디스플레이 됨

1.2

카드가 투입됨

카드를 확인함

카드가 유효함, “PIN을 입력하세요대화창이 디스플레이 됨

1.3

유효 카드

고객이 PIN을 입력함

PIN(1234)이 시간 내에 입력됨, 확인 화면이 디스플레이 됨

1.4

PIN이 입력됨

PIN을 확인함

PIN이 유효함, 메인메뉴가 디스플레이 됨

[ATM 예의 정제된 테스트케이스]


반응형