소프트웨어 성능 테스트

윈도우에서 시스템 로그를 남기는 것과 관련하여
소프트웨어 테스트에 대한 좋은 글이 있어 올려둡니다.

출처 : http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=35614

읽을거리 > 디벨로퍼 플러스

시스템 구축·확장계획 위한 출발, 소프트웨어 성능 테스트

프린트  이메일 전송 

소프트웨어 개발은 흔히 소프트웨어의 기능 구현에만 초점을 맞춰 진행되기가 쉽다. 그러나 시스템을 설치하고 운영하는 시점이 되면 소프트웨어 성능 문제로 많은 어려움에 부딪치게 된다. 운영 시점에 발생하는 소프트웨어 성능 문제는 소프트웨어의 큰 틀을 변경할 만큼 많은 영향을 주므로 소프트웨어 성능에 대해 소프트웨어 개발 초기부터 많은 관심을 기울여야 할 것이다.

김성 sung21.kim@samsung.com｜삼성소프트웨어멤버십 회원으로 활동한 바 있고, 현재는 삼성전자에서 근무하고 있다. Enterprise Architecture 개발과 관련된 실무 경험을 갖고 있으며 소프트웨어 공학 분야에 많은 관심을 갖고 있다.

성능 테스트란 무엇인가? 사전적인 의미는 어떤 기계나 시스템을 실제로 사용될 것과 같은 여건에서 성능을 측정하기 위해 실행하는 여러 가지 검사로 통상적으로 1개 또는 여러 개의 대표적인 프로그램을 측정하고자 하는 컴퓨터들에 수행시켜 성능을 측정함으로써 컴퓨터의 속도나 단위 시간당 일 처리량 등을 측정하는 것이다.  

성능 테스트란?
소프트웨어를 개발하다 보면 성능은 비기능적 요구사항이므로 개발 중 일정에 쫓기거나 정확한 성능 목표가 없다면 무시되고 간단히 생각하고 넘어가게 된다. 그 결과 개발 마지막 단계 또는 릴리즈 단계에 문제가 된다면 많은 비용을 지불해가며 테스트하고 소프트웨어를 수정해야 한다. 성능은 요구사항 분석 단계에서부터 릴리즈 단계까지 정확한 성능 목표를 기준으로 테스팅되어야 하고 그 성능 목표를 위해 꾸준히 소프트웨어 튜닝 작업을 수행해야 한다. 성능을 위해 소프트웨어 구조가 바뀔 수도 있으며 구현하는 기능 또한 변경될 수 있기 때문이다. 성능 테스트는 소프트웨어의 병목지점을 파악하고 튜닝해 성능을 향상하는 것이며 소프트웨어의 가용 성능을 측정해 시스템의 용량 산정과 시스템 확장 계획을 수립하는 데 목적이 있다. 

성능 테스트 요소
그럼 성능 테스트에 대한 이해를 위해 몇 가지 알아둬야 할 점에 대해 설명하도록 하겠다.  성능 테스트를 하는 데 있어서 실제로 사용될 환경을 만들기 위해서는 부하가 어떻게 그리고 얼마나 발생하는지를 파악해야 한다. 이는 부하 발생 모델이 될 수 있는데 부하 발생 모델의 발생지는 액터(Actor)가 된다. 액터는 측정하고자 하는 대상시스템과 연관된 다른 시스템이 될 수 있고 사용자가 될 수 있다. 이 모든 액터를 사용자로 규정한다면 시스템을 사용할 전체 사용자 수와 동시에 시스템을 사용하는 동시사용자 수로 정의할 수 있다. <그림 1>과 같이 전체 사용자는 비접속자, 대기자, 사용자 모두를 포함하며 동시사용자는 대기자와 사용자를 포함한다.  

<그림 1> 성능 테스트 요소

부하를 발생시키는 주체는 동시사용자다. 동시사용자에 의해 발생하는 호출관계는 <그림 1>과 같이 Request Time과 Think Time으로 되어 있다. Response Time은 사용자가 요청해서 응답을 받을 때까지의 시간이며 이 시간은 요청이 갔다 오는 시간인 RTT(Round Trip Time)와 Queue에 대기하는 Queuing Time, 요청을 처리하고 응답하는 시간인 Process Time 등의 시간으로 구성된다. 또한 사용자는 다음 요청을 할 때까지 간격이 있는데 이를 Think Time이라고 한다. 이렇게 Response Time과 Think Time이 Request Interval이다. 우리는 이것을 어떻게 활용할 수 있을까? 실제 환경과 유사한 부하를 만들어 내기 위해 활용할 수 있는데 사용자를 조사해 현 시스템의 전체 사용자 수와 그 중 동시사용자 수를 산정한다. 그리고 시스템의 Response Time과 Think Time을 선정한다면 동시에 몇 명의 사용자가 Request를 테스트 대상 시스템으로 보내야 할지 계산해 낼 수 있다.  테스트를 진행하면서 부하를 증가시켜야 한다면 동시사용자 수를 증가시키거나 Think Time을 줄여 부하를 증가시킬 수 있다. 그리고 부하 처리량은 TPS, TPM, TPH로 표시하는데 초당, 분당, 시간당 처리되는 트랜잭션 량을 표시하며 처리하는 TPS가 크면 클수록 성능이 좋은 시스템이다.  

병목 현상
동시사용자 수가 10,000명이며 Response Time은 3초, Think Time은 7초라면 Request Interval은 10초가 된다. 이때 발생시켜야 하는 부하는 몇 TPS일까?  10,000 / 10초 (호출간격) = 1,000TPS의 경우 초당 1,000개의 트랜잭션을 발생시킨다면 예상되는 실제 환경과 유사한 부하를 만들어 낼 수 있다.

그렇다면 부하를 주었을 때 처리량에 따라 시스템의 성능은 어떻게 변화할까? 사용자를 점차 증가시키며 부하를 주었을 때 처리량은 계속 증가하게 되는데 이를 저부하 구간이라고 한다. 사용자를 계속 증가시키면 어느 시점에서 처리량은 증가하지 않는 임계점에 도달하게 된다. 임계점을 기준으로 임계사용자 수가 결정되고 이 구간을 고부하 구간이라고 한다. 고부하 구간에서 계속적으로 사용자 증가로 인해 부하가 늘어나면 서버에는 병목 지점이 발생하고 시스템의 성능은 저하되기 시작한다. 이를 경합구간이라고 하며 시스템 성능 저하로 시스템에 계속적인 병목 지점이 발생하고 결국은 시스템이 다운되는 현상이 발생할 수 있다. 이러한 병목구간은 사용자 증가로 부하가 증가되어 발생할 수 있지만 소프트웨어 소스의 리소스 관리 문제로 인해 조금씩 발생할 수도 있다. 따라서 사용자 증가가 직접적인 영향을 주지 않을 수도 있으므로 시스템 병목현상의 원인을 많은 부하의 원인으로만 한정하지 말아야 한다.

<그림 2> 컴퓨터 시스템의 Throughput 곡선

시스템 확장 계획
테스트를 진행할 때 시스템의 최대 처리량을 산정할 수 있다면 영업 시 효율적인 시스템 선택으로 시스템 리소스의 활용도를 극대화할 수 있을 뿐 아니라 사용자 증가에 따른 시스템 확장 계획도 정확하게 수립될 수 있다. 부하 테스트를 진행하면서 User Count를 증가시켜 부하 발생량을 증가시킨다. 그 결과, 시스템에 점점 많은 부하를 주어 시스템은 임계점에 도달하고 그 시점의 사용자 수를 임계사용자 수로 정한다. 그러면 이 시스템은 몇 명의 동시사용자를 커버할 수 있다는 결과가 나오게 된다.

테스트를 진행하면 부하가 증가함에 따라 응답시간은 선형적으로 증가하게 된다. 그러나 부하가 증가하고 병목구간이 발생하기 시작하면 요청의 대기시간이 길어져 응답시간이 기하급수적으로 증가하게 된다. 임계사용자 수에 도달하면 성능 개선 없이 응답시간만 계속적으로 증가하게 되므로 이 시점의 사용자 수를 최대 허용 동시사용자 수로 정의하기도 한다.  

목표로 하는 최대 허용 동시사용자가 목표치가 정의되어 있다면 이를 수용하는 시스템을 선정하기 위해 시스템을 확장해 테스트해야 한다. 그리고 시스템을 확장한 만큼 시스템의 성능이 개선되지 않으므로 시스템 확장에 따른 성능향상비율을 산정해 추후 시스템 확장에 활용해야 한다. 성능향상 계수는 시스템 확장과 성능과의 관계를 나타내며 성능향상비율/시스템 확장비율로 계산된다.

<그림 3> 응답시간과 처리량의 상관관계

피크치
성능테스트 결과, 시스템의 비즈니스 로직 특성에 따라 변화를 가져온다. 어떠한 Task는 CPU를, 어떠한 Task는 Memory를, 또 어떠한 Task는 IO 리소스를 많이 사용하게 된다.  그러므로 성능테스트 시 체크해야 할 항목도 시스템의 비즈니스 특성에 따라 선정해야 하며 또한 모든 특성이 다 테스트될 수 있도록 테스트케이스를 선정하는 것도 중요하다. 현장에서 시스템의 성능을 모니터링하는 경우도 있으며 현장의 성능 모니터링은 높은 신뢰성을 갖게 된다. 모니터링 결과, 우리는 평균치와 피크치를 얻을 수 있다. 

평균치와 피크치 중 어느 것이 용량 산정의 기준이 될까? 피크치가 기준이 되어야 한다. 피크치까지 올라갈 수 있는 가능성이 있기 때문에 시스템 운영에 많은 영향을 줄 수 있다. 그러나 피크치가 실제적인 부하인지 다른 외부적인 요인에 의한 일시적인 피크치인지 정확하게 확인할 필요가 있다. 단순히 피크치를 확인하고 서버 용량을 산정한다면 불필요한 투자가 될 수도 있다.

“용량 기준은 실제 부하로 인한 피크치다.”

<그림 4> 부하의 피크치

CPU의 경우는 피크치가 최대 80% 이하의 수준을 유지하도록 하고 메모리의 경우는 전체 메모리의 5% 이상 사용 가능한 메모리로 유지하면 된다. 성능 모니터링 결과를 정확하게 분석해 현재 시스템의 진단 및 시스템 사양 조정에 활용한다면 정확한 시스템 확장을 통해 안정적인 서비스 지원 및 축소를 통한 원가 절감이 가능할 것이다.

목적에 따른 성능 테스트
성능 테스트에는 어떤 방법들이 있을까? 성능 테스트 방법은 목적에 따라 크게 세 가지로 나눌 수 있다.

단위 성능 시험 : 각각 업무의 최대 성능을 산출
단위 성능 시험은 각각의 업무 모듈 혹은 프레임워크를 이루는 모듈의 최대 성능을 산출하기 위한 시험이다. 단위 성능 시험을 통해 조기에 단위 모듈의 성능적인 이슈를 찾아 튜닝 해 해결하는 데 그 목적이 있다. 성능 시험은 소스 코드를 보지 않는 블랙박스 형태의 테스트지만 단위 성능 시험은 소프트웨어의 구조적인 문제에 대한 성능 검증도 이뤄지므로 화이트 박스 형태의 테스트를 진행할 수도 있다. 어떠한 메커니즘을 소프트웨어 개발에 도입하고자 할 때 메커니즘을 이해하고 개발된 소스상에서 병목 구간은 발생하지 않는지 테스트하고 튜닝해야 할 것이다. 통합 성능 시험은 실제 시스템이 가동되는 상황을 재현해야 하므로 부하시나리오를 만들고 부하 발생시 업무에 대한 가중치를 적용해 부하를 발생시켜야 할 것이다.

통합 성능 시험 : 업무 가중치와 부하 시나리오를 이용한 시험
통합 성능 시험을 통해 목표 성능만큼의 부하를 처리하는지 검증할 수 있다. 

임계 성능 시험 : 시스템이 발휘할 수 있는 최대 성능 시험
임계 성능 시험은 목표 성능을 넘어 대상시스템이 처리할 수 있는 최대 성능을 측정하는 성능 시험이다. 계속해서 부하를 증가시켜 가면서 대상 시스템의 임계점이 어디이며 임계사용자 수는 얼마인지를 구할 수 있는 테스트다.

방법에 따른 성능 테스트
성능 테스트 방법에 따라 다섯 가지로 나눌 수 있다.

Loop Back 시험 : Loop Back 코드를 추가해 시험
소프트웨어가 여러 모듈 간에 Integration되어 있으므로 테스트 대상 코드에 바로 리턴하는 Look Back 코드를 추가해 테스트하고자 하는 코드에 대한 성능 테스트를 진행해 성능적인 이슈가 없는지 검증하는 테스트다.

Tier 시험 : Tier 간의 통신을 재현해 측정
Tier 시험은 시스템의 구성이 여러 Tier로 구성되어 있을 때 병목이 발생한다면 어느 Tier에 의해 병목이 발생했는지 알 수 없으므로 Tier간 분리를 해 각 Tier에 병목이 없는지를 검증할 수 있도록 테스트 대상 Tier에 직접 부하를 주어 테스트하는 방법이다.

Spike 시험 : 동시사용자가 동시에 트랜잭션을 발생시키는 시험
Spike 시험은 특정 기능이 특정 시점에 동시에 사용되며 그로 인해 시스템의 성능은 피크치에 도달할 수 있다. 이러한 기능에 대해서는 정해진 시간 내에 모두 정상적으로 처리되는지 검증하고 시스템은 정상적인 상태를 유지하는지 체크하는 테스트다.

확장성 시험 : 시스템 증설에 대한 성능 향상 비율 측정
확장성 시험은 시스템 증설에 정확히 비례해 성능이 증가되지 않으므로 시스템 증설에 따른 성능 증가폭을 측정하기 위한 테스트다. 이 결과는 시스템 확장에 활용할 수 있는 중요한 자료가 된다.

가용성 시험 : Long Run 시험
가용성 시험은 자원 불균형 현상으로 시스템의 성능 저하나 다운 등의 현상이 있는지를 검증하기 위해 오랜 시간 동안 진행하는 성능 테스트다. 

소프트웨어 성능은 단위 모듈을 개발하는 개발자에게는 그리 중요하게 여겨지지 않는 요소일 것이다. 그러나 시스템이 통합되고 운영될 때 각 단위 모듈이 가지고 있는 병목은 통합된 시스템과 시스템 전체에 영향을 미치게 되어 사용자가 사용하는 시점에 엄청난 문제로 다가오는 경향이 있다. 모든 프로젝트 참여자는 소프트웨어 기능뿐 아니라 성능의 중요성을 인식하고 성능 향상을 위한 활동을 모든 프로젝트 단계에서 진행해야 할 것이다.

요구분석 단계에서는 성능요소와 목표지수를 정확하게 선정하고 설계 시에는 목표에 도달하기 위한 구조를 설계에 반영해야 한다. 구현 시 코딩하고 단위 성능 테스트를 통해 코드상에 병목은 없는지 테스트하고 병목구간에 대해 튜닝이 이뤄져야 한다. 테스트 단계에서는 통합 테스트를 진행하고 임계 성능 테스트를 통해 시스템 확장 계획을 수립해야 한다. 이와 같이 모든 단계에서 성능을 고려해야 한다. 그러나 많은 성능 요소를 모두 만족시키는 것은 불가능하므로 개발하고자 하는 시스템에 대한 정확한 성능 요소 선정 또한 중요한 작업 중의 하나다.

트랜잭션 모델링
성능 테스트를 정확하게 수행하고 있는지를 묻는 질문에 자신 있게 대답할 수 있는 사람은 그리 많지 않을 것이다. 그렇다면 왜 성능 테스트를 하기 어려운 걸까? 몇 가지 원인을 찾아봤다. 첫 번째는 실제적으로 중요성이 체감되지 않기 때문이다. 개발은 기능 중심으로 이뤄지고 개발 일정도 기능 중심으로 체크된다. 그렇다보니 기능 구현보다는 성능에 대한 중요성을 느끼지 못한다. 두 번째는 성능 문제가 어디에서 발생될지 정확하게 모르는 경우다. 무엇을 해야 할지 감을 잡을 수 없으니 성능 테스트를 하지 못하는 것이다. 세 번째는 실제 운영 환경과 똑같은 환경을 만들 수 없는 제약사항 때문이다. 이러한 이유로 정확한 성능 테스트가 힘든 것이 사실이다. 그러나 성능적인 이유로 발생하는 문제는 단순 기능의 문제를 훨씬 뛰어넘는 더 큰 문제를 야기한다. 전체 시스템이 멈춰 버리는 것과 같은 심각한 상황을 초래하는 것이다.  

성능 테스트를 위해서는 어떠한 트랜잭션이 존재하고 얼마나 많은 양의 트랜잭션이 발생하는지 분석되어야 한다. 그러기 위해 트랜잭션의 패턴을 분석하고 각 패턴에서 실제적으로 발생하는 트랜잭션의 양을 산출해야 한다. 정확한 성능 테스트를 위해서는 실제 환경과 동일한 트랜잭션을 발생시켜 측정하는 것이 무엇보다도 중요하다. 트랜잭션 모델링을 통해 얻은 값의 정확도가 높을수록 성능 테스트에 대한 정확도가 높아진다.

“성능 테스트 결과의 정확도는 모델링의 정확도에 비례한다.”

성능 테스트 툴
성능 테스트를 위해서는 대량의 부하를 발생시켜야 하므로 반드시 툴이 필요하다. 표준화된 프로토콜로 통신할 경우는 성능 테스트를 위해 상용 툴을 구입하기도 하지만 가격이 만만치 않다. 그래서 툴을 직접 개발해 사용하는 경우도 많다. 테스트 툴을 이용해 부하를 발생시키고 시스템 성능을 모니터링하기 위해 로그를 남겨 분석한다. 그런데 테스트 툴에는 입력해야 할 값이 필요하다. 트랜잭션에 대한 정보를 입력하는 것이다. 사용자 수와 반복주기, 동시사용자 수, 네트워크 프로토콜 등 여러 가지 값이 있지만 어떤 값을 입력해야 할지 전혀 알 수 없다. 이미 성능 테스트 툴을 접해 보았을 텐데, 테스트 툴에 대한 설명서는 볼 수 있지만 성능 테스트를 위한 파라미터 값은 도메인마다 다르므로 가이드할 수 없다. 그래서 성능 테스트를 위한 트랜잭션 모델링이 필요한 것이다. 이러한 툴에서 요구되는 파라미터는 트랜잭션 모델링에서 얻어진 값을 사용하면 된다. 트랜잭션을 발생시키기 위해서는 실제 환경과 유사한 트랜잭션 모델이 필요하다. 실제 환경에서 발생하는 트랜잭션에 대한 정확한 분석을 통해 트랜잭션 모델을 만들어 성능 테스트 시 적용해야 한다.

모델링 방법
트랜잭션 모델링에는 예측에 의한 방법과 기존 사이트에 대한 로그 분석 방법이 있다. 예측에 의한 방법은 트랜잭션의 패턴을 예측하는 것으로 정확성이 떨어지지만 실제 운영사이트가 없다면 예측에 의한 방법을 사용할 수 밖에 없다. 그러나 기존 사이트가 존재한다면 현재 운영되고 있는 사이트에 트랜잭션을 로그로 남기고 시스템 성능 로그를 남겨 분석함으로써 트랜잭션의 패턴을 모델링할 수 있다. 이러한 방법은 정확성이 높으나 현장에 로그를 남기고 분석하는 수고가 필요하다. 또한 트랜잭션과 성능 로그를 함께 분석한다면 트랜잭션에 따른 성능에 대한 영향도 예측 가능하게 된다.  

성능 로그를 남기는 방법 성능 로그는 윈도우에서 제공하는 기능을 사용할 수 있다. 제어판 쭭 관리도구 쭭 성능을 선택하면 성능 로그를 남길 수 있는 프로그램이 실행된다. 카운터 로그 메뉴를 통해 원하는 성능 데이터 카운터 로그를 구성할 수 있다. 카운터에는 프로세서, 디스크, 메모리, 네트워크 등 다양한 성능 개체를 선택해 자신이 원하는 로그를 남길 수 있다. 또한 성능 로그의 샘플링 간격을 선택해 자신이 원하는 샘플링 주기를 선택할 수 있다.

트랜잭션의 분류
성능 테스트 시에는 문제가 발생하지 않았는데 실제 서비스 중에 성능 문제가 발생하는 것은 실제 운영되는 환경에서의 트랜잭션과 변수를 정확하게 반영하지 못하고 테스트했기 때문이다. 이러한 테스트는 결국 테스트를 위한 테스트에 불과하다. 트랜잭션의 형태는 다양하며 각 트랜잭션의 형태마다 서로 다른 형태로 발생된다. 트랜잭션의 형태는 외부의 입력으로 인해 발행하는 것과 자체적으로 발생하는 형태로 분류할 수 있다. 외부의 입력에 의해 발생하는 트랜잭션을 External 트랜잭션이라 하고 내부에서 발생한 트랜잭션을 Internal 트랜잭션이라 정의한다.

External 트랜잭션은 사용자 또는 외부 시스템에 의한 트랜잭션 발생이며 Internal 트랜잭션은 내부의 타이머 또는 스케줄러에 의해 발생하는 트랜잭션이다.

<그림 5> 트랜젝션의 정의

모델링
트랜잭션은 분당 처리하는 트랜잭션 수인 TPM(Transaction Per Minute)으로 산출하기 위해 분당 발생되는 트랜잭션 수를 모델링한다. 사용자에 의해 발생하는 트랜잭션의 경우는 응답 결과를 확인하고 다음 트랜잭션을 수행하므로 최대 응답시간에 Think Time을 더할 수 있다. 사용자 수는 비접속자, 대기자, 사용자를 의미하며 동시접속률은 대기자, 사용자를 계산하기 위한 동시접속 확률이다. 동시접속률은 시스템의 특성이나 사용자 특성을 고려해 정의한다. 사용자가 요청하고 응답을 기다릴 때까지 보통은 다른 요청을 하지 않고 기다리므로 트랜잭션 발생시간에 영향을 주는 시간이 최대 응답시간이다. 요청에 대해 응답을 받은 후 다음 트랜잭션을 실행할 때까지의 시간이 Think Time이다.

<표 1> External 트랜젝션 모델링

External 트랜잭션 모델 = (ConnCnt * ConnRate) * (60/(MaxTime[+ThinkTime]))
사용자 수 = 10000, 동시접속률 = 20%, 최대응답시간 = 3초, Think Time = 5초일 때 
(10000*0.2) * (60/ (3+5)) = 15000 TPM
Internal 트랜잭션 모델 = TransactCnt * (60/CycleTime)
트랜잭션의 수 = 500, 발생 주기 = 5초 간격일 때
500 * (60/5) = 6000 TPM

<표 2> Internal 트랜젝션 모델링

External 트랜잭션은 분당 15,000건, Internal 트랜잭션은 분당 6,000건이 발생한다. 모델링의 값은 각 기능별 사용 패턴에 따라 달라질 수 있으며 기능별로 트랜잭션을 구분하고 각 기능별 사용패턴에 맞게 트랜잭션을 모델링해 최종 TPM을 결정하고 이를 테스트에 반영한다.

트랜잭션의 진실
트랜잭션을 분석하다 보면 트랜잭션의 패턴이 계속해서 변화하는 재미있는 사실을 발견하게 된다. 트랜잭션은 왜 바뀌는 것일까? 트랜잭션이 바뀌는 이유를 이해하고 충분히 고려해 트랜잭션을 모델링해야 한다.

● 시간대별 또는 내적, 외적 환경변화에 따라 변화한다. 시간대별로 많이 사용하는 기능과 사용자 수가 달라질 수 있다. 출입시스템의 경우 출근시간이나 퇴근시간에 트랜잭션이 많을 것이고, 사이트를 통해 이벤트를 진행하거나 프로그램 내부적으로 스케줄링 Task(정기점검, 일괄처리)가 있다면 이러한 내적, 외적 영향에 따라 트랜잭션은 증가한다.

● 사용자의 사용 수준에 따라 트랜잭션이 변한다. 사용자는 자신이 아는 만큼 사용한다. 기능이 익숙하지 않으면 사용하는 기능의 수와 사용횟수는 낮아진다. 그러나 익숙해지기 시작하면 사용하는 기능의 수도 많아질 뿐 아니라 사용하는 속도 또한 빨라진다. 이것은 트랜잭션의 증가를 가져온다. 그 결과, 시간이 지날수록 트랜잭션은 증가할 수 있다.

● Unknown 트랜잭션이 영향을 준다. 개발한 소프트웨어 이외에 백신이나 윈도우 업데이트 같은 타 소프트웨어에서 발생하는 트랜잭션이 성능로그에 포함될 수 있다. 테스트 시 Unknown 트랜잭션의 영향을 줄이기 위해 불필요한 서비스를 종료시키고 테스트를 진행해야 한다. 성능 로그의 피크치가 높게 나타났는데 이것이 개발한 소프트웨어의 트랜잭션으로 인한 것인지 타 소프트웨어에 의한 것인지 검토해야 한다. 피크치가 높게 나타난 순간 백신 프로그램의 검사 실행이나 윈도우 업데이트가 실행되었을 가능성도 있기 때문이다.  

모델링 적용
트랜잭션 모델링을 통해 얻은 값은 실제 성능 테스트 툴의 부하 패턴 값으로 적용할 수 있다. 성능 테스트를 위한 다양한 값을 설정할 수 있도록 되어 있고 설정된 값에 따라 툴에서 부하를 발생시키게 된다.

<화면 2> 성능 테스트 툴

트랜잭션 모델링은 시스템이 사용되고 운영되는 실제 환경과 유사하게 트랜잭션을 발생시켜 개발이 끝나고 릴리즈되기 전에 성능적인 문제를 사전에 찾아 해결하고자 하는데 그 목적이 있다. 

참고자료
1. 한빛미디어, 프로젝트 성공을 결정짓는 성능시험 방법론과 실무, 2007
2. Addison-Wesley, xUnit Test Patterns, 2007
3. WILEY, Architecting Enterprise Solutions, 2004