논문요약 - 트레이딩 시스템에서의 랜덤 테스트 by HÖJEBERG

제목: 트레이딩 시스템에서의 랜덤 테스트(Random Tests in a Trading System)

저자: NOAH HÖJEBERG, 스웨덴

문서유형: 석사논문(총 47페이지), 2008년

 

이미 테스트가 되었고 사용중인 트레이딩 시스템에 랜덤 테스트 방법을 적용하여 기존에 발견하지 못한 버그를 찾아냄으로써 랜덤 테스트가 버그 식별에 효과적임을 보인 자료

---

트레이딩 시스템

• 거래소 시스템(a market place system) 또는 트레이딩 시스템(a trading system)은 구매자와 판매자가 금융 상품(주식, 옵션, 채권 등)을 거래 할 수 있는 시스템
• 거래에 참여하는 액터(actors)에는 고객(개인 또는 기관 투자자), 브로커(brokers), 전문 투자자(market makers)가 있다.
• 오더(An order)는 상품을 매입 또는 매수 하라는 고객의 지시를 말한다. 거래의 규정에 따라 다양한 형태의 오더(가격 제한 오더, 시간 제한 오더, 묶음 오더 등)가 존재한다.
• 오더 매칭(Order matching)은 한 오더가 또 다른 오더와 매치되어 결과적으로 거래(트랜잭션)가 성사되는 것을 말한다. 오더는 가격과 우선순위에 따라 매칭되며, 매칭 메커니즘은 트레이딩 시스템 마다 다를 수 있다.
• 거래의 핵심적 역할을 하는 오더북(Order books)은 특정 상품에 대한 모든 유형의 오더를 리스트한다.

TRADExpress

• Cinnober Financial Technology가 개발한 트레이딩 시스템
• TRADExpress의 오더 관리 컴포넌트는 모든 입력되는 오더를 인지하고 반응한다. 오더 액션 타입으로는 신규 오더를 삽입하는 ‘Order Insert’, 기존 오더를 수정하는 ‘Update Order’, 기존 오더를 취소하는 ‘Cancel Order’, 특정 액터의 또는 특정 오더북의 모든 오더를 취소하는 ‘Cancel All Orders’, 오더북에서 오더를 제거하지만 시스템에는 남겨두는 ‘Suspend Order’, 중단된 오더를 다시 활성화시키는 ‘Activate Order’ 등이 있다.
• TRADExpress는 아래와 같은 컴포넌트로 구성된다.
  - Matching Engine(ME): 오더북과 액티브 오더를 관리. 거래를 생성하기 위해 오더를 매치시킨다. 여러 트랜잭션이 동시에 동작하는 것을 허용하는 멀티 쓰레드 방식
  - Daemon: TRADExpress를 실행(run)하는 컴퓨터마다 데몬이 존재(해당 컴퓨터의 모든 서버를 핸들링)
  - Vote Server(VS): 어떤 서버가 메인이고 어떤 서버가 대기 서버인지를 결정
  - Trading Application Multiplexer(TAX): 들어오고 나가는 트랙픽의 메시지 라우터 역할. 거래에 참여하는 액터들은 TAX 게이트웨이에 연결
  - Common Data Server(CD): 사용자 정보, 상품 정보, 인증 정보, 트레이딩 스케쥴 등을 데이터베이스에 관리
  - Query Server(QS): 많은 질의로 인한 ME 부하를 덜어주기 위해 액티브 오더북과 오더들의 복사본을 유지 및 관리
  - History Server(HS): 밤 사이 오더 및 거래가 계속되도록 지원하며 과거 정보에 대한 질의에 응답
  - Management Repository(MR): 상태 이벤트와 통계치 같은 시스템 오퍼레이션 데이터를 유지 및 관리

랜덤 테스트(Random Tests)

• 이 논문의 저자는 테스트 타입을 아래 그림처럼 분류하며, 동적 테스트의 통계적 테스트 카테고리에 속하는 랜덤 테스트를 연구 대상으로 한다.
• 통계적 테스팅 또는 몬테카를로 테스팅으로 알려진 랜덤 테스팅은 임의로 생성된 데이터를 테스트 대상 시스템에 보낸다.
• 입력 데이터는 사전 정의된 도메인에서 생성되며, 출력 데이터는 출력이 정확한지 부정확한지 결정하는 오라클(an oracle)에 의해 분석된다.
• 같은 테스트를 반복하는 자동화 테스트의 경우 첫 번째 실행에서 결함을 발견할 가능성이 있어도 그 이후에는 실행을 반복해도 테스트 대상 소프트웨어가 변경되지 않는 한 새로운 결함을 찾아 내지 못한다. 사용하는 테스트 데이터에 임의성(randomness)을 추가한 랜덤 테스트는 같은 테스트를 여러 차례 반복 실행하는 자동 테스트에서 신규 결함 발견 가능성을 높일 수 있다.
• 동등 분할, 경계값 분석 같은 널리 사용되는 테스트 케이스 설계 기법들을 랜덤 테스트에도 적용 가능
• 테스트 입력 데이터를 랜덤하게 생성 시 현실적(정상적) 데이터와 비현실적(비정상적) 데이터 양측 모두 생성하기 위해 여러 분포도(distributions)를 적용하기도 한다. 현실적 테스트 데이터는 시스템 안전성(stability) 정도를 파악할 수 있게 해주며, 비현실적 테스트 데이터는 자주 발생 하지 않는 유형의 버그를 찾을 가능성을 높여준다.
• 임의의 입력 데이터를 생성해내는 입력 도메인(The input domain)은 랜덤 테스트의 중요한 한 측면이다. 복잡한 시스템의 입력 도메인은 실질적으로 무한하기 때문에 제한된 테스트 케이스 수로 광범위한 테스트를 하기 위해서 선택된 여러 서브 도메인으로부터 데이터를 추출해 낸다.

테스트 오라클(Oracles)

• 오라클은 예상 결과, 예상 결과를 생성하는 프로세스 내지는 프로그램, 예상 결과를 생성하기 위해 사용되는 메커니즘 등을 의미한다. 실제 테스트 결과는 그 정확성(correctness)을 확인하기 위해 오라클의 결과와 비교된다.
• 테스트 결과를 오라클과 비교하기 전에 테스트 환경 및 프로그램 상태 같은 조건들이 반드시 고려되어야 한다.
• 복잡한 오라클의 경우 속도가 느리고, 구축 비용이 높고, 그 자체에 에러를 포함할 가능성도 높으며, 유지보수 하기도 어렵다.
• 프로그램 상태 및 환경 조건에 대한 많은 예측을 하는 오라클의 경우 테스트 대상 시스템과 운영 환경의 변화에 민감하다.
• 테스트 대상 시스템과 같은 컴포넌트를 공유하는 오라클의 경우 양쪽이 모두 부정확한 결과값을 출력하여 에러를 발견하지 못하고 놓칠 수도 있다.

다양한 유형의 테스트 오라클이 존재하는데 대표적으로 아래와 같은 것들이 있다.

1) No Oracle

• 결과를 체크하지 않으면서 자동화된 테스트를 실행하므로 시스템 다운 같은 명백하게 드러나는 에러만을 발견할 수 있다는 단점이 있다.
• 장점으로는 비용이 저렴하고, 구현이 쉬우며, 빠르게 실행 가능하다는 점이다.
• 시스템을 완전히 멈추게 만드는 버그를 찾을 때 효과적인 방법

2) True Oracle

• 테스트 대상 시스템과 동일한 결과를 재현하는 오라클
• 동일한 데이터를 오라클과 테스트 대상 시스템에 보내고 그 결과는 별도의 알고리즘, 플랫폼, 프로세스 등을 이용하여 검증한다.
• 오라클과 테스트 대상 시스템이 내적으로 공유하는 컴포넌트가 적을수록 오라클의 신뢰성 높아짐(테스트 대상 시스템이 가진 에러를 오라클이 공유하여 똑같이 부정확한 결과는 출력할 가능성이 낮아지므로). 문제는 구축 비용이 증가된다는 점
• True oracle은 대개 높은 구축 시간과 비용이 요구된다. 

3) Consistent Oracle

• 이전 테스트로부터 나온 테스트 결과를 오라클로 사용
• 테스트 대상 시스템의 과거 버전(다른 플랫폼의 동일 프로그램)이 Consistent oracle이 될 수도 있다.
• 가장 빠르게 사용 가능한 오라클이라는 장점을 가진다.
• 종종 회귀 테스트에 사용되며, 여러 버전간의 변경 내용을 테스트 하는데 적합하다.
• 변경 사항이나 새로운 문제는 찾아낼 수 있지만 변경되기 이전에 이미 존재하던 오래된 문제들은 찾아내지 못한다.

4) Self-Referential Oracle

• 테스트 결과가 입력 데이터 자체에 구축됨. 예) 데이터베이스 엔진 테스트 시 필드간 또는 레코드간 예상되는 데이터 베이스 연관성(the data base linkages)을 데이터 필드에 기술
• 자기 참조(Self-Referential) 전략을 사용 시 테스트는 특정 특징(검증 포인트)을 자체에 포함하여 테스트 데이터를 생성한다.
• 많은 양의 복잡한 데이터를 생성 및 검증할 수 있고 광범위한 테스트 사후 분석(post-test analysis)도 허용한다는 장점이 있다.

5) Heuristic Oracle

• 테스트 결과가 정확한지 아닌지 빠르게 평가하기 위해 휴리스틱(발견적) 접근법을 사용
• 정확한 결과를 체킹하는 대신 휴리스틱에 기반한 단순 알고리즘을 사용하여 결과를 검증. 예) 특정 필드가 스웨덴 우편 번호를 나타낸다면 5자리 숫자인지를 우선 체크
• 구현이 쉽고 빠르게 실행 가능하다는 장점이 있다.

트레이딩 시스템의 랜덤 테스트

• 임의로 생성된 데이터로 트레이딩을 시뮬레이션 하는 방식으로 테스트를 수행한다. 트레이딩 시뮬레이션은 여러 타입의 액터(트레이더, 오퍼레이터 등)가 트레이딩 시스템에서 다양한 트랜잭션을 수행하도록 만든다. 테스트 결과는 오라클을 사용하여 분석한다.
• 적용된 오라클 타입은 특정 요구사항이 충족되었는지 확인하는 휴리스틱 오라클이다. 확인하는 요구사항으로는 ‘음수 값의 가격이 오더로 들어오지는 않았는가’, ‘오더 규모가 0 보다 큰가’와 같은 경계값 테스트와 ‘트레이드가 중단된 오더북에서 거래가 성사되는가’와 같은 불법 오퍼레이션 체크 등이 있다.
• 오라클은 액터와 커뮤니케이션 할 수 있어야 하며, 액터는 오더가 예상한대로 매치되고 거래되는지 오라클이 확인 할 수 있도록 해당 오더를 오라클과 테스트 대상 시스템 양쪽에 보낸다. 

1) 테스트 구현(Implementation)

트레이딩 시스템의 랜덤 테스트 구현은 아래 그림과 같다. 시뮬레이션에서 액터(매수 트레이더, 매입 트레이더, 마켓 오퍼레이터 등)는 트레이딩 및 기타 마켓 액션을 수행하고, 오라클은 뭔가 잘못되지는 않는지 판단하기 위해 액터와 테스트 대상 시스템을 주시한다(시스템 다운 같은 장애도 일종의 오라클로 작용). 시뮬레이션에서 액터가 수행하는 액션은 임의로 결정되며, 각 시뮬레이션에서 여러 액션이 수행된다.

2) 오라클

• 오라클도 하나의 액터로 구현된다.
• 트레이더 액터는 오더를 오라클과 트레이딩 시스템 양쪽으로 보내어 오라클이 트레이더의 오더와 시스템으로부터 받은 오더가 동일한지 비교할 수 있도록 한다.
• 오더 매칭이 성사되면 오라클은 이 매치된 오더를 트레이더로부터 받은 오더와 비교하여 실제로 트레이더가 지시한 오더와 일치하는지 확인한다.
• 오라클은 또한 아래와 같은 필수적인 경계값 테스트(boundary value tests)를 지원한다.
  - Price not negative: 오더의 가격(가치)가 음수값이 아니다.
  - Volume not negative: 오더의 양이 1보다 크거나 같다.
  - Volume correct: 트레이드의 양이 매치가 된 두 오더 각각의 양보다 크지 않다.
  - Price correct: 트레이드의 가격이 매치된 입찰 오더(the matched bid order)의 가격보다 높지 않거나 또는 매치된 요청 오더(the matched ask order) 가격보다 낮다.
• 오라클에 의해 수행되는 또 다른 체크로 아래와 같은 것들이 있다.
  - Traded order exists: 트레이드에서 매치된 오더가 실제로 시스템에 입력되었다. 유일한 오더 식별자(order-id)가 사용된다.
  - Order not canceled: 트레이드에서 매치된 주문들이 취소되지 않았다.
  - Canceled order exists: 취소 액션에 앞서 취소된 오더가 실제 존재했다.
  - Order not duplicate: 시스템에 입력된 주문이 입력 액션 전에 이미 존재하지 않는다.
  - Oracle connected to system: 오라클이 최근 30초 이내에 TAX 박동(시스템이 매 5초마다 보내는 메시지)을 받음
  - User exists: 제거된 사용자가 제거되기 전에 실제 존재했다.
  - Member exists: 제거된 멤버가 제거되기 전에 실제 존재했다.
  - Member not duplicate: 추가된 멤버가 추가 전에 이미 존재하지 않았다.
  - User not duplicate: 추가된 사용자가 추가 전에 이미 존재하지 않았다.
  - Trade-halted order book not traded: 트레이드가 중단된 오더북에서 트레이드가 수행되지 않는다.
• 위에 나열한 요구사항(체크사항)들이 만족되지 않으면 오라클은 에러 메시지를 보내고 해당 에러를 로그에 기록한다. 

3) 커버리지

• 테스트가 커버한 정도를 측정하기 위해 사용된 트랜잭션들을 조사함. 즉, 가용한 전체 트랜잭션 목록 중 테스트에서 수행된 트랜잭션들을 확인
• 대략 19.5%의 트랙잭션이 커버됨. 커버리지 수치가 그다지 높지는 않지만 자주 사용되고 오류 발생 시 큰 문제를 초래할 수 있는 주요 트랙잰셕(예, OrderInsert, OrderUpdate, OrderCancel)은 테스트에서 커버됨

4) 테스트 결과

3개의 버그가 발견됨

• 사용자가 삭제 된 후에도 로그온 상태로 남아 정상적으로 트레이딩이 가능한 버그
• 이미 로그온 된 사용자가 반복해서 로그온을 시도 시 로그온이 실패하면서 TAX Server가 다운되는 버그
• 액터가 이미 존재하는 멤버/사용자를 추가하려 함에 따라 Common Data Server가 다운되는 버그

 

위 버그들은 직접적인 관찰이나 시스템 다운을 통해서 발견되었고, 본 논문에서 설계된 휴리스틱 오라클을 통해 발견된 버그는 없었다. 이 오라클이 이미 테스트된 기능들만을 확인하여서 이런 결과가 나온 것으로 생각되며, 더 정교한 오라클을 적용하면 더 많은 에러를 찾을 수 있을지도 모른다.