소프트웨어 퍼포먼스 테스트

Software performance testing

소프트웨어 품질보증에서 퍼포먼스 테스트는 일반적으로 특정 워크로드에서 응답성과 안정성 측면에서 시스템이 어떻게 성능을 발휘하는지를 판단하기 위해 수행되는 테스트 관행입니다.또한 scalability, 신뢰성, 자원 사용률 등 시스템의 다른 품질 특성을 조사, 측정, 검증 또는 검증할 수도 있습니다.

퍼포먼스 엔지니어링의 서브셋인 퍼포먼스 테스트는 시스템 구현, 설계 및 아키텍처에 퍼포먼스 표준을 구축하기 위해 노력하는 컴퓨터 사이언스 프랙티스입니다.

테스트 유형

부하 테스트

부하 테스트는 가장 간단한 형태의 성능 테스트입니다.일반적으로 부하 테스트는 특정 예상 부하에서의 시스템 동작을 이해하기 위해 수행됩니다.이 로드는 설정된 기간 내에 특정 수의 트랜잭션을 수행하는 응용 프로그램에서 예상되는 동시 사용자 수입니다.이 테스트에서는 모든 중요한 비즈니스 크리티컬 트랜잭션의 응답 시간을 알 수 있습니다.데이터베이스, 어플리케이션서버 등도 테스트 중에 감시되므로 어플리케이션소프트웨어와 소프트웨어가 설치되어 있는 하드웨어의 병목현상을 특정하는 데 도움이 됩니다.

스트레스 테스트

스트레스 테스트는 일반적으로 시스템 내 용량의 상한을 이해하기 위해 사용됩니다.이러한 종류의 테스트는 극한 부하에 관한 시스템의 견고성을 판단하기 위해 수행되며 애플리케이션 관리자는 현재 부하가 예상 최대값을 훨씬 초과할 경우 시스템이 충분한 성능을 발휘할 수 있는지 여부를 판단할 수 있습니다.

흡수 시험

내구성 테스트라고도 하는 소크 테스트는 일반적으로 시스템이 지속적인 예상 부하를 견딜 수 있는지 여부를 결정하기 위해 수행됩니다.소크 테스트 중에 메모리 사용률이 모니터링되어 잠재적인 누출을 탐지합니다.또한 중요하지만 종종 간과되는 것은 성능 저하입니다. 즉, 일정 기간 지속적인 활동 후 스루풋 및/또는 응답 시간이 테스트 시작 시만큼 좋거나 더 낫도록 하는 것입니다.기본적으로 시스템에 상당한 부하를 장기간 가해야 합니다.목표는 시스템이 지속적으로 사용 중일 때 어떻게 동작하는지 알아내는 것입니다.

스파이크 테스트

스파이크 테스트는 다수의 사용자에 의해 발생하는 부하를 갑자기 증가 또는 감소시켜 시스템의 동작을 관찰함으로써 이루어집니다.목표는 성능 저하, 시스템 장애 또는 급격한 부하 변화를 처리할 수 있는지 판단하는 것입니다.

중단점 테스트

브레이크 포인트 테스트는 스트레스 테스트와 비슷합니다.시스템이 미리 정해진 고장 조건을 감시하는 동안 시간에 따라 증분 부하가 인가됩니다.중단점 테스트는 시스템이 필요한 사양 또는 서비스 수준 계약에 따라 수행할 최대 용량을 결정하는 데 사용할 수 있기 때문에 용량 테스트라고도 합니다.고정 환경에 적용된 중단점 분석 결과를 사용하여 클라우드 환경에서 스케일아웃 이벤트를 트리거해야 하는 필수 하드웨어 또는 조건 측면에서 최적의 스케일아웃 전략을 결정할 수 있습니다.

구성 테스트

부하 관점에서 성능을 테스트하는 것이 아니라 시스템 컴포넌트에 대한 구성 변경이 시스템 성능과 동작에 미치는 영향을 판단하기 위해 테스트를 작성합니다.일반적인 예로는 다양한 로드밸런싱 방법을 시험해 보는 것이 있습니다.

절연 테스트

분리 테스트는 성능 테스트에만 해당되지 않지만 시스템 문제를 일으킨 테스트 실행을 반복해야 합니다.이러한 테스트를 통해 장애 도메인을 분리 및 확인할 수 있습니다.

인터넷 테스트

이는 Facebook, Google, Wikipedia 등의 글로벌 애플리케이션을 실제 타깃 대륙에 배치된 부하 생성기에서 성능을 테스트하는 비교적 새로운 형태의 성능 테스트입니다.이러한 테스트는 일반적으로 성공적으로 실행되기 위해 엄청난 준비와 모니터링이 필요합니다.

퍼포먼스 목표 설정

퍼포먼스 테스트의 목적은 다음과 같습니다.

  • 시스템이 성능 기준을 충족함을 증명할 수 있습니다.
  • 두 시스템을 비교하여 어떤 시스템이 더 나은지 확인할 수 있습니다.
  • 시스템 또는 워크로드 중 어떤 부분이 시스템 성능을 저하시키는지를 측정할 수 있습니다.

많은 성능 테스트가 충분히 현실적이고 목표 지향적인 성능 목표를 설정하지 않고 수행됩니다.비즈니스 관점에서 첫 번째 질문은 항상 "퍼포먼스 테스트는 왜 하고 있는가?"입니다.이러한 고려사항은 테스트의 비즈니스 케이스의 일부입니다.퍼포먼스 목표는 시스템의 테크놀로지 및 목적에 따라 다르지만 항상 다음 중 몇 가지를 포함해야 합니다.

동시성과 스루풋

시스템이 로그인 절차를 통해 최종 사용자를 식별할 경우 동시성 목표가 매우 바람직합니다.이는 정의상 시스템이 어느 시점에서나 지원할 것으로 예상되는 최대 동시 시스템 사용자 수입니다.특히 반복 부분에 로그인 및 로그아웃 액티비티가 포함되어 있는 경우 스크립트로 작성된 트랜잭션의 워크플로우에 의해 진정한 동시성이 영향을 받을 수 있습니다.

시스템에 최종 사용자의 개념이 없는 경우 성능 목표는 최대 throughput 또는 트랜잭션 속도를 기반으로 합니다.

서버 응답 시간

이는 어떤 시스템 노드가 다른 시스템노드의 요구에 응답하는 데 걸리는 시간을 나타냅니다.간단한 예로는 브라우저 클라이언트에서 웹 서버로 HTTP 'GET' 요청을 들 수 있습니다.응답 시간 측면에서 이것은 모든 부하 테스트 도구가 실제로 측정하는 것입니다.시스템의 모든 노드 간에 서버 응답 시간 목표를 설정하는 것이 적절할 수 있습니다.

렌더링 응답 시간

부하 테스트 툴은 일반적으로 '회선상에서' 액티비티가 없는 기간을 인식하는 것 이외에는 노드 내에서 일어나는 일에 대한 개념이 없기 때문에 렌더 응답 시간을 측정하는 데 어려움이 있습니다.렌더 응답 시간을 측정하려면 일반적으로 성능 테스트 시나리오의 일부로 기능 테스트 스크립트를 포함해야 합니다.많은 부하 테스트툴은 이 기능을 제공하지 않습니다.

퍼포먼스 사양

퍼포먼스 사양(요건)을 상세하게 기술하여 퍼포먼스 테스트 계획에 문서화하는 것이 중요합니다.이 작업은 시스템 개발 프로젝트의 요건 개발 단계에서 설계 작업 전에 수행하는 것이 이상적입니다.상세한 것에 대하여는, 「퍼포먼스 엔지니어링」을 참조해 주세요.

그러나 성능 테스트는 규격에 대해 수행되지 않는 경우가 많다. 예를 들어, 어느 누구도 주어진 사용자 모집단의 최대 허용 응답 시간을 표현하지 못할 것이다.성능 테스트는 성능 프로파일 조정 프로세스의 일부로 자주 사용됩니다.가장 약한 링크를 특정하는 것이 목적입니다.시스템에는 반드시 더 빨리 응답할 수 있는 부분이 있기 때문에 시스템 전체의 실행 속도가 빨라집니다.시스템의 어느 부분이 이 중요한 경로를 나타내는지 식별하기가 어려울 수 있습니다.테스트 툴 중에는 서버(에이전트)에서 실행되어 트랜잭션 시간, 데이터베이스 액세스 시간, 네트워크 오버헤드 및 기타 서버 모니터를 보고하는 (또는 이를 제공하는 애드온) 계측이 포함되어 있습니다.이러한 계측은 t와 함께 분석할 수 있습니다.퍼포먼스 통계를 작성한다.이러한 인스트루먼트가 없으면 퍼포먼스 테스트에서 발생하는 CPU 부하를 확인하기 위해 서버에 있는 Windows 태스크 매니저 위에 웅크리고 앉아야 할 수도 있습니다(Windows 시스템이 테스트 대상이라고 가정).

퍼포먼스 테스트는 인터넷 자체의 응답 시간이 지역에 따라 다르다는 것이 알려져 있기 때문에 웹을 통해 실시할 수도 있고 심지어 국내의 다른 지역에서도 실시할 수도 있습니다.사내에서도 실행할 수 있습니다만, 일반적으로 퍼블릭네트워크에서 발생하는 지연을 발생시키도록 라우터를 설정할 필요가 있습니다.하중은 현실적 관점에서 시스템에 도입되어야 한다.예를 들어, 시스템 사용자 베이스의 50%가 56K 모뎀 접속을 통해 시스템에 액세스하고 나머지 절반은 T1을 통해 액세스 하는 경우 로드 인젝터(실제 사용자를 시뮬레이트하는 컴퓨터)는 동일한 접속 혼합(이상적)에 부하를 주입하거나 동일한 사용자 프로파일에 따라 이러한 접속의 네트워크 지연을 시뮬레이션해야 합니다.

피크시에 시스템을 사용할 것으로 예상되는 피크 유저의 수를 기술하는 것은, 항상 도움이 됩니다.최대 허용 가능한 95% 응답 시간을 구성하는 문구가 있을 경우 인젝터 구성을 사용하여 제안된 시스템이 해당 사양을 충족하는지 테스트할 수 있습니다.

질문 사항

퍼포먼스 사양에서는 적어도 다음 질문을 해야 합니다.

  • 퍼포먼스 테스트의 범위는 구체적으로 어떻게 됩니까?이 테스트의 범위 내 또는 범위를 벗어나는 서브시스템, 인터페이스, 컴포넌트 등은 무엇입니까?
  • 관련된 사용자 인터페이스(UI)의 경우 각 사용자(피크와 공칭)에 대해 몇 명의 동시 사용자가 예상됩니까?
  • 타겟 시스템(하드웨어)의 외관(모든 서버 및 네트워크 어플라이언스 구성 지정)은 무엇입니까?
  • 각 시스템 컴포넌트의 애플리케이션 워크로드 믹스는 무엇입니까?(예를 들어 로그인 20%, 검색 40%, 항목 선택 30%, 체크아웃 10%)
  • 시스템 워크로드 혼합이란 무엇입니까? [1개의 퍼포먼스 테스트로 여러 워크로드를 시뮬레이션할 수 있습니다](예: 워크로드 A 30%, 워크로드 B 20%, 워크로드 C 50%).
  • 백엔드 배치 프로세스의 모든 시간 요건(피크와 공칭의 지정)은 무엇입니까?

전제 조건

가능한 한 실가동 환경과 유사해야 하는 시스템의 안정적 구축.

일관된 결과를 얻으려면 퍼포먼스 테스트 환경을 사용자 수용 테스트(UAT)나 개발 등 다른 환경으로부터 격리해야 합니다.가능한 한 실전 가동 환경과 유사한 퍼포먼스 테스트 환경을 개별적으로 설치하는 것이 좋습니다.

테스트 조건

성능 테스트에서는 테스트 조건이 예상되는 실제 사용과 유사해야 하는 경우가 많습니다.그러나 실제 운영 시스템은 예측할 수 없는 워크로드에 노출되기 때문에 실제로는 이를 조정하기가 어렵고 완전히 가능한 것은 아닙니다.테스트 워크로드는 가능한 한 실제 가동 환경에서 발생하는 현상을 모방할 수 있지만, 이 워크로드의 가변성을 정확하게 복제할 수 있는 것은 가장 단순한 시스템뿐입니다.

느슨하게 결합된 아키텍처 구현(예: SOA)은 성능 테스트의 복잡성을 가중시켰습니다.프로덕션과 같은 상태를 실제로 복제하려면 공통 인프라 또는 플랫폼을 공유하는 엔터프라이즈 서비스 또는 자산이 모든 소비자가 프로덕션과 같은 트랜잭션 볼륨을 생성하고 공유 인프라 또는 플랫폼에 로드하는 조정된 성능 테스트가 필요합니다.이 액티비티는 매우 복잡하고 비용과 시간이 많이 들기 때문에 일부 조직에서는 현재 퍼포먼스 테스트 환경(PTE)에서 실제 가동 환경(노이즈라고도 함)을 감시 및 시뮬레이션하여 용량과 자원의 요건을 파악하고 품질 속성을 검증/검증하는 도구를 사용하고 있습니다.

타이밍.

새로운 시스템의 비용 퍼포먼스에 있어서 퍼포먼스 테스트 작업은 개발 프로젝트의 시작부터 시작하여 도입까지 확대되는 것이 중요합니다.성능 결함이 늦게 탐지될수록 복구 비용이 높아집니다.이는 기능 테스트의 경우에도 해당되지만 성능 테스트의 경우 범위의 엔드 투 엔드로 인해 더욱 그렇습니다.테스트 환경 및 기타 주요 성능 요건을 취득하고 준비하는 데 시간이 오래 걸리기 때문에 성능 테스트 팀은 가능한 한 빨리 참여하는 것이 중요합니다.

도구들

퍼포먼스 테스트는 크게 두 가지 카테고리로 나뉩니다.

퍼포먼스 스크립팅

퍼포먼스 테스트의 이 부분에서는 주로 특정된 주요 비즈니스 프로세스의 워크플로우 작성/스크립트를 취급합니다.이 작업은 다양한 도구를 사용하여 수행할 수 있습니다.

상기 목록에 기재되어 있는 각 툴은 스크립트 언어(C, Java, JS) 또는 어떤 형식의 시각적 표현(드래그 앤 드롭)을 사용하여 최종 사용자의 워크플로우 작성 및 시뮬레이션을 수행합니다.대부분의 툴에서는 "Record & Replay"라고 불리는 것을 사용할 수 있습니다.여기서 퍼포먼스 테스터는 테스트 툴을 기동하여 브라우저 또는 씩 클라이언트에 접속하여 클라이언트와 서버 간에 발생하는 모든 네트워크 트랜잭션을 캡처합니다.이를 통해 다양한 비즈니스 시나리오를 에뮬레이트하도록 확장/수정할 수 있는 스크립트가 개발됩니다.

퍼포먼스 감시

이는 퍼포먼스 테스트의 다른 면을 형성하고 있습니다.퍼포먼스 모니터링에서는 테스트 대상 어플리케이션의 동작과 응답 특성이 관찰됩니다.다음 파라미터는 보통 퍼포먼스테스트 실행 중에 감시됩니다.

서버 하드웨어 파라미터

  • CPU 사용률
  • 메모리 사용률
  • 디스크 사용률
  • 네트워크 사용률

첫 번째 단계로 이들 4개의 파라미터에 의해 생성된 패턴은 병목현상이 어디에 있는지를 명확하게 나타냅니다.이 문제의 정확한 근본 원인을 파악하기 위해 소프트웨어 엔지니어는 프로파일러 등의 도구를 사용하여 디바이스 또는 소프트웨어의 어떤 부분이 성능 저하의 가장 큰 원인이 되는지 측정하거나 허용 가능한 응답 시간을 유지하기 위한 throughput 수준(및 임계값)을 설정합니다.

테크놀로지

퍼포먼스 테스트 테크놀로지는 1대 이상의 PC 또는 Unix 서버를 사용하여 인젝터로서 동작합니다.각 서버는 사용자 수의 존재를 에뮬레이트하고 퍼포먼스를 테스트하는 호스트와의 인터랙션의 자동 시퀀스(스크립트로 기록되거나 다양한 유형의 사용자 인터랙션을 에뮬레이트하는 일련의 스크립트)를 실행합니다.일반적으로 별도의 PC가 테스트 컨덕터 역할을 하며 각 인젝터의 메트릭을 조정 및 수집하고 성능 데이터를 수집하여 보고합니다.통상적인 순서에서는 부하를 증가시킵니다.즉, 소수의 가상 사용자로부터 시작하여 시간이 지남에 따라 그 수를 사전에 결정된 최대값까지 증가시키는 것입니다.테스트 결과는 사용자 수 대 응답 시간으로 주어진 부하에 따라 성능이 어떻게 변화하는지를 보여줍니다.이러한 테스트를 수행하기 위해 다양한 도구를 사용할 수 있습니다.이 카테고리의 툴은 보통 시스템에 대해 실제 사용자를 에뮬레이트하는 일련의 테스트를 수행합니다.그 결과, 예를 들어 평균 응답 시간은 허용 가능한 수준이지만, 완료하는 데 상당한 시간이 걸리는 몇 가지 주요 트랜잭션의 특이치가 발견될 수 있습니다.이것은 비효율적인 데이터베이스 쿼리나 사진 등으로 인해 발생할 수 있습니다.

성능 테스트는 허용 부하를 초과했을 때 어떤 일이 일어나는지 확인하기 위해 스트레스 테스트와 결합할 수 있습니다.시스템이 크래시합니까?큰 부하를 줄이면 복구에 얼마나 걸립니까?그 고장 때문에 부수적인 피해가 발생합니까?

분석 성능 모델링은 스프레드시트에서 시스템 동작을 모델링하는 방법입니다.이 모델에는 트랜잭션 믹스(시간당 비즈니스 트랜잭션)에 의해 가중치가 부여되는 트랜잭션 리소스 요구량(CPU, Disk I/O, LAN, WAN) 측정값이 제공됩니다.가중 트랜잭션 리소스 요구량을 합산하여 시간당 리소스 요구량을 얻고 시간당 리소스 용량으로 나누어 리소스 로드를 가져옵니다.응답시간 공식(R=S/(1-U), R=응답시간, S=서비스시간, U=로드)을 이용하여 성능시험 결과에 따라 응답시간을 계산하고 교정할 수 있다.분석 성능 모델링을 통해 실제 또는 예상되는 비즈니스 용도에 따라 설계 옵션 및 시스템 크기를 평가할 수 있습니다.따라서 퍼포먼스 테스트보다 훨씬 빠르고 저렴하지만 하드웨어 플랫폼을 충분히 이해해야 합니다.

수행해야 할 태스크

이러한 테스트를 수행하는 작업에는 다음이 포함됩니다.

  • 사내의 전문지식(또는 전문지식 부족)에 따라 내부 자원을 테스트에 사용할지 외부 자원을 사용할지를 결정합니다.
  • 사용자 및/또는 비즈니스 분석가로부터 성능 요구사항(사양)을 수집하거나 도출합니다.
  • 요건, 자원, 스케줄, 마일스톤을 포함한 개략적인 계획(또는 프로젝트 헌장)을 작성합니다.
  • 상세한 퍼포먼스 테스트 계획(상세 시나리오와 테스트 케이스, 워크로드, 환경 정보 등)을 작성합니다.
  • 테스트 도구를 선택합니다.
  • 필요한 테스트 데이터와 전세 작업을 지정합니다(대부분 간과되지만 유효한 성능 테스트를 수행하는 데 필수적입니다).
  • 선택한 테스트 도구와 전략을 사용하여 테스트 대상 애플리케이션/컴포넌트별로 개념 증명 스크립트를 작성합니다.
  • 모든 의존관계 및 관련 일정을 포함한 상세한 성능 테스트 프로젝트 계획을 작성합니다.
  • 인젝터/컨트롤러를 장착 및 구성합니다.
  • 테스트 환경(실가동 플랫폼과 같은 하드웨어가 이상적), 라우터 구성, 저소음 네트워크(다른 사용자가 결과를 왜곡하지 않도록), 서버 계측 도입, 데이터베이스 테스트 세트 개발 등을 구성합니다.
  • 테스트를 모의 실행 - 사전 정의된 사용자와 실제로 로드 테스트를 실행하기 전에 스크립트의 정확성을 확인하기 위해 모의 실행을 수행합니다.
  • 테스트 실행 – (반복적으로) 반복하여 설명되지 않은 요소가 결과에 영향을 미치는지 확인합니다.
  • 결과를 분석합니다(합격/실패, 중요 경로 조사 및 수정 조치 권장).

방법론

퍼포먼스 테스트 웹 어플리케이션

Microsoft Developer Network에 따르면 퍼포먼스 테스트 방법은 다음과 같은 액티비티로 구성됩니다.

  1. 테스트 환경을 식별합니다.물리 테스트 환경과 실가동 환경, 테스트 팀이 이용할 수 있는 툴과 자원을 특정합니다.물리적 환경에는 하드웨어, 소프트웨어 및 네트워크 구성이 포함됩니다.처음에 테스트 환경 전체를 충분히 이해하면 테스트 설계와 계획을 보다 효율적으로 수행할 수 있으며 프로젝트 초기에 테스트 과제를 식별할 수 있습니다.경우에 따라서는 프로젝트의 라이프 사이클 전체에 걸쳐 이 프로세스를 정기적으로 재검토해야 합니다.
  2. 퍼포먼스 수용 기준을 특정합니다.응답 시간, throughput, 자원 사용 목표 및 제약사항을 식별합니다.일반적으로 응답 시간은 사용자의 관심사이며, throughput은 비즈니스 관심사이며, 리소스 사용은 시스템의 관심사입니다.또, 이러한 목표나 제약에 의해서 얻을 수 없는 프로젝트의 성공 기준을 특정합니다.예를 들어 퍼포먼스 테스트를 사용하여 어떤 구성 설정의 조합이 가장 바람직한 퍼포먼스 특성을 얻을 수 있는지를 평가합니다.
  3. 계획 및 설계 테스트주요 시나리오를 특정하고, 대표 사용자 간의 변동성과 그 변동성을 시뮬레이션하고, 테스트 데이터를 정의하고, 수집할 메트릭을 확립하는 방법을 결정합니다.이 정보를 1개 이상의 시스템 사용 모델로 통합하여 구현, 실행 및 분석합니다.
  4. 테스트 환경을 설정합니다.각 전략을 실행하는 데 필요한 테스트 환경, 도구 및 리소스를 테스트에 사용할 수 있도록 준비합니다.테스트 환경이 필요에 따라 리소스 모니터링을 위해 설치되었는지 확인합니다.xsaxasx
  5. 테스트 설계를 구현합니다.테스트 설계에 따라 성능 테스트를 개발합니다.
  6. 테스트를 실행합니다.테스트를 실행하고 모니터링합니다.테스트, 테스트 데이터 및 결과 수집을 검증합니다.테스트 및 테스트 환경을 모니터링하면서 분석을 위해 검증된 테스트를 수행합니다.
  7. 결과 분석, 조정 및 테스트결과 데이터를 분석, 통합 및 공유합니다.튜닝을 변경하고 다시 테스트하십시오.두 테스트의 결과를 비교합니다.각각의 개선은 이전의 개선보다 작은 개선으로 돌아옵니다.언제 멈추나요?CPU 병목현상이 발생하면 코드를 개선하거나 CPU를 추가할 수 있습니다.

「 」를 참조해 주세요.