책 발췌 – 네트워크 테스팅에서 애플리케이션 부하 모델 유형 by Buchanan

출처: 책 The Art of Testing Network Systems, R. W. Buchanan, 1996년, 359~364 페이지

 

애플리케이션 계층 네트워크 테스팅에서 부하 모델 및 테스트 스크립트를 설계하는 데 도움이 되는 가이드라인

 

---

 

부하 모델 개발하기(DEVELOPING THE LOAD MODEL)

애플리케이션/프레젠테이션 계층 테스트에서 요구되는 기본 부하 모델로 아래 세 가지 형식이 있다.

• 애플리케이션 테스트는 애플리케이션 프로그램이나 GUI에 대한 입력을 나타내는 커맨드 시퀀스 또는 마우스 포인트-앤드-클릭 시퀀스를 ​​필요로 한다.
• 데이터베이스 서버 테스트는 트랜잭션 스트림(transaction streams)을 필요로 한다.
• 네트워크 플랫폼 테스트는 일련의 파일 I/O 리퀘스트를 필요로 한다.

 

테스트 프로젝트에서는 실제 부하에 대해 알기 전에, 심지어 애플리케이션이 개발되기 전에, 부하 모델을 개발해야 하는 경우가 빈번하다. 베이스라인 설정을 위한 시스템이 가용하지 않을 때 테스터가 트래픽 패턴(traffic patterns)과 부하 분포(load distributions)를 추정해야만 한다. 다음은 애플리케이션 부하 모델 개발을 위한 추정(estimating), 에이징(aging), 배이스라인 설정(baselining)에 접근하는 방법이다.

 

1. 경험, 직감 또는 입력으로 사용할 수 있는 기타 모든 것을 기반으로 하여 가장 잘 추정한 트래픽 패턴을 시작으로 한다. 가능한 경우 기존 네트워크 및 사용자에 대한 베이스라인 정보를 수집한다.

2. 1단계에서 도출한 부하들에 최소 2개의 상향 트래픽 패턴과 1개의 하향 트래픽 패턴을 덧붙여 일괄한다. 이 5개의 부하 포인트를 모두 테스트함으로써 부하 변화에 따른 시스템 성능(performance), 성능 저하(degradation), 신뢰성(reliability)에 대한 사실적인 정보를 얻을 수 있다. 이는 부하 변화에 대한 네트워크의 민감도(sensitivity)에 대한 구체적 수치와 관점을 제공한다.

3. 네트워크 노후화(aging)에 대해 추정 또는 예측한다. 1년 간 성장치 그리고 3년 간의 성장치를조사한다. 더 나쁜 경우 시나리오(worse case scenarios)를 사용하여 2단계에서 도출한 부하를 증가시키고 테스트를 다시 실행한다. 이는 네트워크가 성장을 지탱할 수 있는지 여부를 측정하며, 만약 지탱할 수 없는 경우 용량(capacity) 확장에 드는 비용에 대한 추정치를 제공한다.

4. 네트워크 및 애플리케이션의 일부가 설치되자마자 시스템 베이스라인(기준선) 설정을 시작하고, 이 베이스라인 수치를 1단계와 3단계의 가정치와 비교한다. 베이스라인 이력이 축적됨에 따라 이것을 사용된 부하 모델과 비교하고 적절하게 조정한다.

5. 테스팅을 계속하고 테스팅 결과를 사용하여 설치된 네트워크/업그레이드/확장을 적절하게 조정한다.

 

애플리케이션 부하 모델링: 커맨드 시퀀스 및 트랜잭션 스트림

애플리케이션 테스팅을 위한 부하 모델(load models)은 일반적으로 다음 6가지 형식 중 하나를 취한다.

 

• 네트워크 중심(Network centric) 스크립트: 이 부하 스크립트는 GUI 프런트 엔드 또는 프로그램 생성 트랜잭션 스트림을 기반으로 최대 네트워크 액티비티를 생성하는 데 중점을 둔다. 이러한 스크립트는 최소한의 워크스테이션으로 파일 서버와 데이터베이스 서버에 스트레스를 주고자 한다. 트랜잭션 생성기는 GUI 프런트 엔드 오버헤드를 제거하고 더 적은 테스트 하드웨어로 더 높은 트랜잭션 흐름을 가능하게 하며, 또한 GUI와 백엔드 서버 간의 병목(bottlenecks)을 격리하는 데 도움이 된다. 네트워크 중심 스크립트는 응답 시간(response time), 신뢰성(reliability), 처리량(throughput), 구성(configuration), 수용력(capacity), 그리고 회귀 테스팅에 사용된다.
• 현실(Real-world) 스크립트: 현실 스크립트는 실제 사용자 인터액션을 흉내내고자 한다. 이 스크립트는 광범위한 애플리케이션 커맨드, 생각 시간(think time)을 위한 일시 중지, 응답 확인(verification of responses), 유도된 에러 조건(induced error conditions) 등을 포함한다. 이러한 스크립트는 회귀 테스트나 Novell의 Super Lab 같이 대규모 네트워크 구성을 테스팅에 사용할 수 있는 경우에 자주 쓰인다. 높은 네트워크 부하를 생성하려면 네트워크 중심 스크립트보다 훨씬 더 많은 워크스테이션을 필요로 한다.
• 주요 피쳐(Key features) 스크립트: 이 스크립트는 애플리케이션 피쳐 중 가장 널리 사용되고 중요한 5~10개의 피쳐로 제한한다. 이 스크립트가 높은 부하를 생성하고 중요한 애플리케이션 피쳐를 확인하기 때문에 승인 테스트에 자주 사용된다.
• 주요 기능(Key functions) 스크립트: 이 스크립트는 데이터베이스 서버 및 분산 네트워크 서비스와 연관된 부하에 민감한 오퍼레이션(예, 이름 디렉토리, 그룹웨어, 메일)으로 제한한다. 데이터베이스 서버의 경우 이 스크립트가 트랜잭션 로깅, 트랜잭션 롤백, 데이터 동기화, 백업 같은 백그라운드 오퍼레이션을 포함한다.
• 워크스테이션/GUI 중심(Workstation/GUI centric) 스크립트: 워크스테이션 GUI와 데스크탑은 전체 시스템 및 애플리케이션 성능에 상당한 영향을 미칠 수 있다. 이 스크립트는 GUI 소프트웨어에서 또는 데스크탑 오버레이 간 스위칭에서 응답 지연(response delays)을 측정하고자 한다. 이러한 스크립트는 오버레이 다운로드, 임시 파일 저장, 워크스테이션과 파일 또는 데이터베이스 서버 간의 스왑 파일 액티비티를 기반으로 네트워크 오버헤드를 생성한다. 일반적으로 이러한 스크립트는 다른 스크립트(종종 네트워크 중심 스크립트)와 함께 실행된다.
• QA 테스트 스크립트: 좋은 QA 테스트는 사용자가 실제로 애플리케이션에 액세스하는 방식과 유사하게 모든 애플리케이션 피쳐와 커맨드를 확인한다. 이러한 스크립트는 여러 대의 워크스테이션이 동원되는 네트워크 피쳐 테스트(network feature testing)에서 사용되며, 대부분의 네트워크 테스트에서 요구되는 것보다 스크립트가 더 복잡하다.

 

스크립트 생성의 핵심은 보다 복잡한 스크립트로 결합되거나 새 스크립트 작성을 위해 수정될 수 있는 개별 모듈로 구성된 스크립트 라이브러리를 작성하는 것이다. 예를 들어, 네트워크 중심 스크립트, 현실 스크립트, 주요 피쳐 스크립트는 50%가 동일한 커맨드일 수 있다. 주요 피쳐 스크립트에 일시 중지(pauses)를 추가하면 현실 스크립트가 생성된다. QA 스크립트를 잘라내어 네트워크 중심 스크립트나 주요 피쳐 스크립트의 초안을 만드는 것도 좋은 시작이다. 요점은 한덩어리로 뭉친 거대한 스크립트(monolithic script)를 만들지 말고, 그보다는 계속해서 재사용하고 수정할 수 있는 작고 집중된 스크립트를 만들라는 것이다. 스크립트 준비에는 시간이 걸리며 이런 방식은 시간과 노력을 절약할 수 있다.

 

 

스크립트 내용 정의하기(Defining Script Contents)

이미 전개된 시스템의 경우 스크립트 작성을 위한 가장 좋은 입력 소스는 사용자 및 소프트웨어 모니터링이다. 신규 개발의 경우 가장 좋은 방법은 요구사항 명세(requirements specification)를 기반으로 스크립트를 작성하고, 소프트웨어를 실제로 테스트하여 이를 조정하는 것이다.

 

현실 스크립트, 주요 피쳐 스크립트, 주요 기능 스크립트, 워크스테이션/GUI 중심 스크립트, QA 스크립트는 애플리케이션 커맨드 또는 리퀘스트를 기반으로 개발된다. 그러나 네트워크 중심 스크립트는 커맨드보다 트랜잭션을 필요로 한다(때때로 주요 기능 스크립트도 여기에 해당). 특정 애플리케이션 커맨드나 리퀘스트를 동일한 역할을 하는 트랜잭션 시퀀스로 대체하는 것이 종종 어려운 데, 특히 "수다스러운(네트워크 상에 오고 가는 게 많은)" 프로그램에서 그러하다. 예를 들어, 예제 1.1에서 다룬 레코드 액세스를 하는 간단한 데이터베이스 리퀘스트는 120개의 네트워크 트랜잭션을 생성하였다. 클라이언트-서버 애플리케이션 테스트를 수행하는 여러 회사에 따르면 새 버전의 CoroNet CMS 제품이 애플리케이션 트랜잭션 흐름을 모니터링하는 데 매우 유용하다고 한다.

 

애플리케이션의 베이스라인을 설정하고 데이터베이스 서버를 로드하기 위한 이벤트 순서가 다음과 같다.

1. 레코드 액세스, 정렬, 레코드 업데이트 같은 데이터베이스 리퀘스트를 식별한다.
2. 리퀘스트를 실행하고 CMS를 사용하여 애플리케이션 액티비티를 모니터링한다.
3. CMS 데이터를 기반으로 리퀘스트에 상응하는 트랜잭션 시퀀스를 생성한다.
4. Mercury Interactive의 LoadRunner를 사용하여 데이터베이스 서버에 대한 트랜잭션 스트림을 생성한다.

 

애플리케이션 부하 스크립트는 우리가 테스트하는 애플리케이션만큼이나 다양할 것이므로 이 책에서 스크립트 형식과 내용을 구체적으로 정의할 수는 없지만, 다음은 좋은 스크립트를 개발하는 데 도움이 되는 지침이다.

 

1. 네트워크 지향 스크립트는 QA 테스트 스크립트와 다르다. 네트워크 스크립트는 모든 애플리케이션 기능을 실행하려고 해서는 안 된다. 네트워크 트래픽을 생성하는 몇 가지 잘 선택된 기능이 여러 다양한 기능보다 더 나은 스크립트를 만든다. 예를 들어, 클라이언트-서버 애플리케이션 스크립트가 임의의 레코드에 액세스하기, 레코드 키를 변경하기, 레코드를 새 엔트리로 다시 쓰기, 이 프로세스를 1,000번 반복하기 등을 포함한다. 편집, 정렬, 인쇄 같은 커맨드는 자주 사용되는 기능이지만 워크스테이션에서 서버로의 의미 있는 액티비티을 생성하지는 않는다. 이러한 기능은 워크스테이션 또는 데이터베이스 서버에 부하를 가하며 GUI/워크스테이션 테스팅과 서버 CPU 테스팅에서 사용된다.

2. 응답 시간(response time)을 측정할 때는 시간 지정된 커맨드 루프에서 스타트업 및 셧다운 액티비티를 항상 제외해야 한다. 포함되는 경우 이러한 액티비티가 테스트 결과를 왜곡할 수 있다. 스타트업 및 셧다운 타이밍이 중요하다면 이를 별도의 테스트에서 측정한다.

3. 데이터베이스 서버를 테스트하는 스크립트는 GUI를 우회하고 서버에 대해 트랜잭션 스트림을 생성하는 경우 더 효과적이다.

4. 응답 시간 테스트의 경우 키 입력(keystrokes)을 통해 커맨드를 호출하고 서버 응답의 콘텐츠를 확인하지 않는다(이는 일반적으로 워크스테이션 상의 부하를 줄이고 워크스테이션당 더 많은 트랜잭션이 생성되도록 허용함).

5. 마우스 오퍼레이션 및 서버 응답을 확인하는 것은 네트워크 테스트 스크립트가 아니라 QA 기능-지향 테스트 스크립트에서 수행한다.

6. 현실 스크립트나 주요 피쳐(key feature) 스크립트의 경우 사용자가 가장 많이 쓰는 인터페이스를 사용한다. 대부분의 GUI 환경에서는 이것이 마우스 포인트-앤-클릭 오퍼레이션이다.

7. 신뢰성 테스트(Reliability tests)는 애플리케이션의 올바른 작동을 보장하기 위해 때때로 응답을 확인한다(특히 어떤 문제가 의심되는 경우).

8. 스크립트가 단일 워크스테이션에서 올바르게 실행되는지 먼저 확인한 다음 이를 두 개 또는 세 개의 워크스테이션에서 동시에 시도한다. 이는 여러 사용자가 동일 레코드에 액세스하는 데 있어서의 어떤 충돌을 대규모 다중 사용자 테스트를 실행하기 전에 미리 식별한다.