페이퍼요약- 자연어 요구사항 기반 테스팅 by Sneed

제목: 자연어 요구사항 기반 테스팅(Testing against natural language Requirements)

저자: Harry M. Sneed, 오스트리아

문서유형: 컨퍼런스 페이퍼(총 8페이지), 2007년

 

텍스트 분석기를 사용해 요구사항 문서로부터 테스트 케이스를 추출하는 방법을 제안한 자료

---

 

요구사항 기반 테스팅(Requirements-based testing)

• 최종 시스템 테스트(a final system test)와 인수 테스트(an acceptance test)의 가장 일반적인 접근 방법이 자연어로 작성된 요구사항에 기반한 테스팅이다. 즉, 공식 요구사항 문서에 정의된 기능적 요구사항과 비기능적 요구사항을 분석하여 테스트 케이스를 도출하고 테스트를 수행
• 요구사항 기반 테스트가 수행될 쯤에는 코드 기반 단위 테스팅이나 설계 기반 통합 테스팅 같은 다른 종류의 테스팅이 이미 수행되어서 소프트웨어가 실행가능하고 꽤 안정적인 것으로 가정되며, 요구사항 기반 테스트의 임무는 시스템이 사용자 조직과 개발 조직 간의 공식 합의에 따른 해야 할 일을 하는지를 증명하는 것이다.
• 편견을 배제하기 위해 종종 독립적인 테스트 조직에 의해 이 테스트가 수행됨. 즉, 테스터는 단지 테스트 수행뿐만 아니라 자연어로 작성된 모호할 수도 있는(다양한 해석이 가능) 요구사항의 의미를 해석할 필요가 있다.
• 요구사항 텍스트를 분해하고 여러 다른 타입의 요구사항 진술(requirement statements)을 구별하는 것이 자동화된 요구사항 기반 테스팅으로의 첫 걸음이며, 본 논문에서는 텍스트 분석기(Text Analyzer)가 이런 역할을 하는 도구임

 

자연어로 작성된 요구사항(natural language requirements)의 성격

• 일부 애플리케이션 영역에서는 요구사항이 형식 언어(예, VDM, SET, Z, OCL)로 작성되지만, 이것이 IT 분야에서 널리 받아들여지지는 않았으며 대부분의 요구사항이 여전히 산문체(prose text)로 작성된다.
• 오늘날 요구사항 문서의 작성 방식을 비구조적(unstructured text), 구조적(structured text), 반정형적(semi-formal text)으로 구분할 수 있음
• 구조적 문서에서는 요구사항이 특정 의미를 가진 사전정의된 장(chapters)과 구역(sections)으로 나뉨. 예를 들어, ‘ANSI/IEEE-830 요구사항 명세 지침’에서는 기능적 요구사항이 목적, 시퀀스, 사전조건, 사후조건, 입력, 출력으로써 정의되며, 비기능 요구사항은 통과/실패 기준(3초 미만 응답시간 같은 측정가능한 목표를 설정)으로써 정의된다. 제품의 기능 및 비기능 요구사항에 더불어 ANSI/IEEE 표준은 또한 제약, 리스크, 프로젝트의 기타 속성들을 규정하며, 최종 결과물은 7개의 구역으로 나뉘어진 고도로 구조화된 문서이다.
• 구조적 문서에서 표준 제목/번호가 사용된 경우 텍스트 분석 도구가 무엇이 기술되었는지를 쉽게 인지할 수 있으며(기술된 내용 자체는 해석가능하지 않더라도), 따라서 테스터가 테스트 케이스를 추출하는 일이 쉬워진다. 또한 이런 구조적 요구사항에 인수 기준(acceptance criteria)이 첨부되어 있는 경우 이것이 사후조건 어써션(a postcondition assertion)과 동등하므로 테스트 케이스 정의에 사용될 수 있다.
• 반정형 요구사항은 한 단계 더 나가서 텍스트 내용이 특정 형식으로 작성됨. 예를 들어, 유스케이스는 요구사항 작성자가 반드시 기입해야 하는 표준화된 애트리뷰트(트리거, 규칙, 사전조건, 사후조건, 경로, 스텝, 타 유스케이스와의 관계)를 가진다. 텍스트에서 이 애트리뷰트들이 항상 같은 이름을 가지므로 분석 도구가 이들을 쉽게 인지할 수 있음

 

시스템 테스팅 프로세스(system testing process)

기능 및 비기능 요구사항으로부터 테스트 케이스를 도출하는 것이 시스템 테스터의 일이며, 이를 시작점으로 해서 아래와 같은 7개의 단계를 수행한다.

①    테스트 케이스 식별(Identifying the test cases): 오브젝트를 분석하고 잠재적 테스트 케이스를 식별함. 이를 위해 요구사항 문서를 스캔하고 확인할 필요가 있는 타겟 시스템의 동작에 대한 모든 진술(statements)을 선택한다. 진술은 액션이나 상태를 나타내거나 또는 어떤 액션이 일어나기 위해서(또는 어떤 상태가 되기 위해서) 충족되어야만 하는 조건(규칙)을 정의한다. 이 액션, 상태, 조건이 테스트 케이스의 후보

②    테스트 설계 창출(Creating a test design): 일단 테스트 케이스가 정의되면 시간과 장소에 의해 그 순서가 정해지고(test case ordering) 또한 테스트 세션 별로 그룹 지어진다. 하나의 세션에서 여러 요구사항과 여러 관련 유스케이스가 실행되며, 테스트 케이스들이 순차적으로 또는 병렬로 실행될 수 있다.

③    테스트 케이스 명세(Specifying the test cases): 테스트 케이스의 애트리뷰트들이 입력 및 출력 데이터 범위 수준까지 상세하게 채워진다. 선행 테스트 케이스 설계, 테스트 될 물리적 인터페이스 또는 데이터베이스 설계, 데이터 값 할당 등이 이루어짐

④    테스트 데이터 생성(Generating the test data): 테스트 데이터 정의가 형식적 신택스(a formal syntax)로 된 경우 테스트 데이터 자체를 자동 생성할 수 있음. 테스트 데이터 생성의 기초는 HTML 폼, XML 스키마, WSDL 명세, SQL 데이터베이스 스키마 같은 인터페이스 서술(interface descriptions)이다. 테스트 케이스 명세로부터 추출된 값들이 데이터 정의 형식이 제공하는 구조적 정보와 연합하여 테스트 오브젝트(예, GUI 인스턴스, 맵, 레코드, 데이터베이스 테이블, 기타 다른 테스트 데이터 형식)를 생성한다.

⑤    테스트 환경 셋업(Setting up the test environment): 테스트 환경이 준비됨. 테스트 데이터베이스가 할당되고 생성된 데이터로 채워지며, 테스트 워크스테이션에 클라이언트 소프트웨어와 입력 테스트 오브젝트가 로드되고, 네트워크가 활성화되고, 서버 소프트웨어가 초기화되고, 실행 및 테스트 커버리지 추적을 위해 소스 코드가 인스트루멘테이션된다.

⑥    테스트 실행(Executing the test): 실제 테스트가 시작됨(테스트 대상 시스템에 따라 한번에 하나의 세션씩 또는 여러 세션이 병렬로 진행됨). 시스템 테스터가 입력 데이터를 수동으로 조달하거나 또는 도구를 통해 자동으로 제공함. 테스트가 실행되는 동안 실행 경로가 모니터되고 코드의 테스트 커버리지가 측정된다.

 

⑦    테스트 평가(Evaluating the test): 각 테스트 세션(또는 테스트 런) 후에 테스터가 테스트 결과를 분석한다. 테스트 세션 동안 발생된 사건(incidents)을 보고하고, 기능적 테스트 커버리지를 기록 및 문서화하고, 데이터 결과(사후조건)의 정확성을 확인한다. 즉, 실제 결과와 테스트 케이스에 명세된 예상 결과를 비교하여 차이가 있으면 보고함. 또한 테스터가 여러 테스트 메트릭(예, 실행된 테스트 케이스 수, 테스트된 요구사항 수, 검증된 데이터 수, 기록된 에러 수, 달성된 테스트 커버리지 정도)을 기록한다.

 

텍스트 분석기를 활용한 자동화된 요구사항 분석

 

본 논문은 자체 개발한 텍스트 분석기(text analyzer)를 사용하여 요구사항 문서로부터 테스트 케이스를 자동으로 식별 및 추출한다.

 

1) 필수 오브젝트 인식 및 선정(Recognizing and selecting essential objects)

• 키워드와 문장 구조에 기반하여 텍스트로부터 정보를 추출하는 자연어 처리기(a natural language processor)를 가지는 것이 요구사항 분석의 열쇠(이는 인터넷 검색 엔진에 의해 사용되는 기법인 ‘텍스트 마이닝’이라고 일컬어짐). 텍스트 마이닝(text mining)의 원래 목적은 분류(classification) 및 검색(retrieval)를 위해 자동으로 문서를 인덱싱 하는 것이지만, 여기서의 목적은 자연어 텍스트로부터 테스트 케이스를 추출하는 것이다.
• 테스트 케이스는 시스템의 오브젝트(어떤 액션이 취해지거나 또는 그 상태가 체크되는 대상)와 관련되므로 텍스트 분석의 첫 단계는 오브젝트를 식별하는 것임. 이를 위해 모든 명사(nouns)가 식별되어야 하는데, 영어에서는 종종 동사(verbs)나 복합어(compound words)가 명사가 될 수 있기 때문에 쉬운 작업이 아님. 이런 면에서는(즉, 텍스트로부터 오브젝트 식별) 독일어나 헝가리어 같은 언어가 더 정확하다.
• 사전 스캐너(A pre scanner)가 텍스트에 있는 모든 명사를 식별하고 기록할 수 있지만, 오로지 사람 분석자만이 사용된 문맥(context)에 기반하여 어떤 명사가 잠재적 오브젝트인지 결정할 수 있다. 스캐너가 모든 명사를 체크박스에 디스플레이하면 사용자가 무관한 명사들을 언체크하며, 그 결과 관련된 명사들의 목록을 얻는다(이것들이 필수 오브젝트로 기록됨).

 

2) 문맥에서의 키워드 정의(Defining key words in context)

 

텍스트 분석을 계속하기 위해 사용자가 요구사항 텍스트에서 사용된 키워드를 식별해야 함. 어떤 문자 스트링이든 키워드가 될 수 있지만 사전정의된 의미가 할당되어야 한다. 아래는 텍스트의 키워드로 할당될 수 있는 약 20개의 사전정의된 개념을 보여준다. 이 키워드를 통해 텍스트 분석기가 산문체 텍스트에 포함된 특정 요구사항 요소(requirement elements)를 인식할 수 있다.

 

SKIP = 이 단어로 시작되는 줄(lines)을 무시한다. REQU = 이 단어는 요구사항(a requirement)을 가리킨다. MASK = 이 단어는 사용자 인터페이스(a user interface)를 가리킨다. INFA = 이 단어는 시스템 인터페이스(a system interface)를 가리킨다. REPO = 이 단어는 보고서(a report)를 가리킨다. INPT = 이 단어는 시스템 입력(a system input)을 가리킨다. OUTP = 이 단어는 시스템 출력(a system output)을 가리킨다. SERV = 이 단어는 웹 서비스(a web service)를 가리킨다. DATA = 이 단어는 데이터 저장(a data store)을 가리킨다. ACT = 이 단어는 시스템 액터(a system actor)를 가리킨다 TRIG = 이 단어는 트리거(a trigger)를 가리킨다. PRE = 이 단어는 사전조건(a precondition)을 가리킨다. POST = 이 단어는 사후조건(a post condition)을 가리킨다. PATH = 이 단어는 논리적 경로(a logical path) 또는 스텝 시퀀스(a sequence of steps)를 가리킨다. EXCP = 이 단어는 예외 조건(an exception condition)을 가리킨다. ATTR = 이 단어는 사용자 할당 텍스트 애트리뷰트(a user assigned text attribute)를 가리킨다. RULE = 이 단어는 비즈니스 규칙(a business rule)을 가리킨다. PROC = 이 단어는 비즈니스 프로세스(a business process)를 가리킨다. GOAL = 이 단어는 비즈니스 목표(a business goal)를 가리킨다. OBJT = 이 단어는 오브젝트명(the name of an object)이다.

[키워드 테이블]

 

3) 잠재적 테스트 케이스 인식 및 추출(Recognizing and extracting potential test cases)

• 텍스트 분석기가 요구사항 문서를 두 번째로 스캔함. 이 때 필수 오브젝트가 등장하는 문장만 고려하고 그 외는 건너 띄며, 선택된 각 문장이 액션(action)인지, 상태(state) 질의인지, 아니면 조건(condition) 인지를 검토한다.
• 오브젝트가 동사의 타겟이면 문장이 액션이다. 예를 들면, “고객 계정이 매일 갱신된다(The customer account is updated daily)”와 “시스템이 고객 계정을 갱신한다(The system updates the customer account)”에서 “account”가 오브젝트이고, “updates”가 액션. 테스트 케이스는 시스템이 정말로 계정을 갱신하는지 테스트 한다.
• 문장 “잔액이 신용 한계를 넘어서면 초과인출 계정이 된다(The account is overdrawn when the balance exceeds the credit limit)”는 테스트 될 필요가 있는 상태이다.
• 문장 “초과인출이면 돈이 들어올 때까지 계정이 동결되어야 한다(If an account is overdrawn, it should be frozen until a payment comes in)”은 오브젝트 상태를 오브젝트 액션과 결합한 조건이다. “account”가 오브젝트, ”overdrawn”이 상태, “should be frozen”이 액션. 실제 여기서 두 개 테스트가 나오는데, 하나는 계정이 초과인출 될 수 있는지 확인하는 것이고, 다른 하나는 초과인출 시 계정이 동결되는지 확인하는 것이다.

 

기능적 테스트 케이스 샘플

• 생성된 테스트 케이스는 식별자, 목적, 트리거, 사전조건, 사후조건을 가진다. 예를 들어, 문장 “고객의 신용 등급이 적절하다면 고객이 수표책을 주문할 수 있다(if the customer’s credit rating is adequate, he can order a book)”는 아래와 같은 2개의 사전조건과 2개의 사후조건을 가진다.
• 이는 모든 조건 절(conditional clauses)에 대해 두 개의 테스트 케이스(하나는 조건을 충족시키는 것 다른 하나는 조건을 충족시키지 않는 것)가 있음을 보이며, 이 두 테스트 케이스 모두 동일한 트리거(즉, 고객이 수표책을 주문한다)를 가진다.

 

사전조건	사후조건
1. 고객의 신용 등급이 적절하다. 2. 고객의 신용 등급이 적절하지 않다.	1. 고객이 수표책을 주문했다. 2. 고객이 수표책을 주문하지 않았다.

 

 

비기능적 테스트 케이스 샘플

• 비기능적 테스트 케이스는 모두 상태이거나 또는 조건이다. 예를 들어, 문장 “시스템이 시간당 적어도 2000건의 트랜잭션을 처리할 수 있어야 한다(The system should be able to process at least 2000 transactions per hour)“는 동사 “should be”가 가리키는 상태이다.
• 또 다른 문장 “시스템 크래시가 일어나면 2분내에 시스템이 재시작되어야 한다(In case of a system crash, the system has to be restarted within 2 minutes)”는 술어 “In case of”에 의해 결정되고 뒤이어 액션 “restarted”가 따라오는 조건이다.
• 위 두 요구사항 모두 반드시 테스트 되어야 한다.

 

4) 잠재적 테스트 케이스 저장(Storing the potential test cases)

 

텍스트 분석의 결과로 잠재적 시스템 테스트 케이스들을 얻게됨. 만일 요구사항 문서가 구조적이면(즉, 개별 요구사항이 인식 가능함) 테스트 케이스가 요구사항에 의해 순서 지어진다. 만일 유스케이스가 정의되었다면, 특정 유스케이스로부터 추출된 테스트 케이스가 해당 유스케이스와 연관 지어진다. 앞의 두 경우가 아니면 테스트 케이스가 소제목(subtitles)에 의해 그룹 지어진다.

 

모든 테스트 케이스는(기능적이든 비기능적이든) 적어도 다음과 같은 애트리뷰트를 가진다.

• 테스트 케이스 ID
• 테스트 케이스 목적 = 해당 테스트 케이스가 추출되어진 문장
• 테스트 케이스 타입 = {action | state | condition}
• 사전조건
• 사후조건
• 트리거
• 관련된 오브젝트로의 참조(a reference)
• 테스트되는 요구사항으로의 참조
• 테스트되는 유스케이스로의 참조

 

[텍스트 분석기를 활용한 자동화된 요구사항 분석]