문서요약 - 성능 테스팅 방법론 by du Plessis

제목: 성능 테스팅 방법론(Performance Testing Methodology)

저자: Johann du Plessis, 남아프리카

문서유형: 화이트페이퍼(총 13페이지), 2008년

 

성능 테스트 프로젝트를 수행하기 위한 방법론을 제안한 자료

---

본 자료에서 제안된 성능 테스트 방법론은 아래의 6개 단계와 산출물을 가진다.

단계(Phase)	산출물(Deliverable)
1 - 프로젝트 평가(Project assessment)	평가 보고서(Assessment report)
2 - 계획(Planning)	테스트 계획서(Test plan)
3 – 스크립팅(Scripting)	테스트 스크립트
4 - 테스트 실행(Test execution)	테스트 시나리오, 테스트 결과
5 - 결과 분석(Results analysis)	결과 요약서(Results summary)
6 - 보고(Reporting)	성능 테스트 보고 및 발표

Phase 1: 프로젝트 평가(Project assessment)

• 정보를 수집하는 프로세스. 요구사항을 분석하고, 특정 환경의 가용 자원으로 이 요구사항을 충족시킬 수 있는지 판단하기 위해 시스템과 아키텍쳐를 조사함
• 테스팅을 수행하기 위한 테스터의 요구사항(예, 유용한 결과를 얻는데 까지 필요한 시간)을 관계자들에게 알림. 성능 테스트에 대한 관계자들의 기대치도 관리해야 함
• 성능 테스팅을 위한 요구사항은 대개 매우 구체적임. 이런 요구사항이 식별이 안되어 있다면 이를 알아내는 것도 평가 프로세스의 한 부분
• 아래 표는 평가 단계가 커버해야 할 몇몇 주요 영역을 나타냄

무엇이 반드시 달성되어야 하는가? (해결해야 할 비지니스 문제)	Ø 사용자 수(Number of users) Ø 용인되는 응답 시간(Acceptable response times) Ø 테스트 할 비니지스 프로세스 Ø 베이스라인 Ø 데이터 볼륨
아키텍쳐/플랫폼	Ø  해당 아키텍쳐에 익숙한가? Ø  해당 아키텍쳐에 대한 경험을 가지고 있는가? Ø  시스템 컴포넌트(하드웨어 & 소프트웨어)
테스트 환경	Ø 성능 테스팅에 적합한가? Ø 하드웨어 Ø 소프트웨어
어떤 도구가 사용될 것인가?	Ø  해당 도구에 익숙한가? Ø  해당 도구가 해당 아키텍쳐와 호환되는가(compatible)? Ø  도구 설치 및 사용을 위한 하드웨어 요구사항과 소프트웨어 요구사항
모니터링	Ø 무엇이(예, 요구사항) 반드시 모니터 되어야 하는가? Ø 무엇이 모니터 될 수 있는가? Ø 모니터링을 시행하기 위한 요구사항
가용한 시간	Ø 가용한 시간 vs. 요구되는 시간 Ø 테스팅을 위한 충분한 시간을 확보하라(충분한 시간 = 의미 있는 결과)
테스팅 수행을 위한 요구사항	Ø 주요 관계자들에게 접근/접촉 Ø 하드웨어 요구사항 Ø 소프트웨어 요구사항 Ø 데이터 요구사항
고객 기대	Ø 모든 것에 “예”라고 하지 않는다. Ø 테스트 수행자(성능 테스트 서비스 제공자) 측면에서의 제한을 밝힌다. Ø 가능한 위험(risks)을 강조한다. Ø 테스팅에서 제외되는 부분이 있으면 이를 강조하고 이유를 설명한다.
평가 보고서	Ø  이 성능 테스팅이 수행 가능한가? Ø  이 성능 테스팅을 어떻게 수행할 것인가? Ø  누가 수행할 것인가? Ø  요구되는 시간과 노력 공수 Ø  제외(Exclusions) Ø  작업 결과로 나오는 산출물

• 평가 단계 마지막에는 모든 발견사항을 전달하기 위한 보고서가 작성됨(성능 테스트 프로젝트를 어떻게 진행할 것인지 그리고 테스팅을 완료하는데 필요한 추정 시간에 대한 의사결정이 보고서에 포함됨). 아래는 전형적인 평가 보고서의 목차 예이다.

Phase 2: 계획(Planning)

• ‘프로젝트 평가’ 단계 동안 수집된 정보가 성능 테스팅을 계획하고 이 테스트 계획을 시작하는데 사용됨
• 성능 테스트 계획은 반드시 모든 상세 사항을 포함해야 하며, 테스트 실행을 위한 체크리스트와 참고 자료의 역할을 한다.
• 아래는 전형적인 성능 테스트 계획서의 목차 예

Phase 3: 스크립팅(Scripting)

• 일차 테스팅 동안 문제가 발견되면 테스트 도구와 스크립트가 항상 먼저 비난을 받으므로 스크립트가 시스템 상에서 문제/에러를 야기하지 않음을 100% 확실히 하는 것이 필수적임. 즉, 도구를 이해하고 이 도구가 어떻게 시스템과 상호작용하는지 이해하여 성능 테스터가 도구와 자신의 스크립트를 완전히 신뢰할 수 있는 위치에 있어야 함
• 성능 테스터가 겪는 어려움 중 하나가 테스팅 외부의 사람들(개발자, 시스템 아키텍트, 데이터베이스 관리자, 네트워크 관리자)의 신뢰를 얻는 일. 성능 테스트 결과에 영향을 받는 이들을 자신의 편으로 만들면 성공적인 성능 테스트 프로젝트를 기대할 수 있음
• 스크립팅은 테스팅이 시작되는 지점임. 스크립트를 짜기 위해 시스템과 프로세스를 알아가면서 응답 시간과 느린/매우 분주한 프로세스를 기록해 둠(잠재 병목 구간의 후보). 스크립트 실행이 시작되면 이 식별된 프로세스를 주의 깊게 모니터 함(공식적인 성능/부하 테스트가 수행되기 전에 여기서 첫 문제를 식별하게 될 수도 있음)

Phase 4: 테스트 실행(Test execution)

성능 테스팅에 대한 여러 다른 관점과 용어가 존재하며 이에 대해 절대적으로 맞다 틀리다 따질 수는 없음(대부분 사람들이 부하 테스팅과 스트레스 테스팅을 언급). 본 자료는 성능 테스팅을 아래 5가지 테스팅을 포함하는 전체적인 개념으로 간주

1 베이스라인 테스트(Baseline tests): 성능 베이스라인을 확립

• 베이스라인 테스트가 종종 무시되지만 약간의 노력을 더하고 상세사항을 검토하는데 시간을 들이면 최대 85%의 성능 문제가 이 테스트 런에서 식별되고 해결될 수 있음
• 베이스라인 테스트는 각 스크립트를 개별적으로 수행함. 통상적으로 각 스크립트를 1, 2, 5, 10, 20명의 사용자로 실행시킴. 최대 사용자 수는 프로젝트 마다 다르며, 또한 스크립트화된 트랜잭션/비즈니스 프로세스의 타입에 따라 달라짐
• 베이스라인 테스팅 동안에 완전 모니터링이 수행되어야 하며 모든 결과가 저장되고 분석되어야 한다. 여기서 장점은 모든 측정치가 단일 프로세스/트랜잭션에 특정되므로 문제/에러를 야기하는 프로세스를 격리시키는(isolating) 수고를 따로 할 필요 없이 문제가 식별될 수 있다는 점이다.

아래 그림은 어떤 단일 스크립트의 반응 시간을 3차례 측정한 결과를 보여줌

아래 그림은 20명의 사용자로 단일 스크립트를 실행시킨 테스트 결과로 매우 높은 CPU 사용(utilization)을 보임. 즉, 이 문제가 베이스라인 테스팅 동안 식별되었고 하나의 스크립트로 특정됨에 따라 완전 부하 테스트를 셋업/준비하는 시간 그리고 다수 스크립트를 가진 부하 테스트 결과 그래프로부터 높은 CPU의 원인을 격리하는 노력에 드는 시간을 낭비하지 않게 됨

2 부하 테스트(Load tests): 시스템 상의 운영 로드(production load)를 흉내 냄

• 이 테스트의 단점은 첫 테스트 결과가 장시간의 준비 후에야 비로소 가용하다는 점이다(그마저도 종종 의미 없거나 해독하기 어려운 결과). 또한 이 테스트에 의해 문제가 식별되었다 하더라고 그 원인을 찾기가 어렵고 시간도 많이 걸림
• 제안된 방법론에서는 대부분의 문제가 첫 부하 테스트 런 전에 식별되고 해결되도록 함

3 스트레스 테스트(Stress test): 중지점까지 시스템을 적재함

• 스트레스 테스트는 시스템의 중지점(breakpoint)을 판단하기 위해 실행된다. 이 테스트는 성능 테스팅으로부터 생겨난 모든 문제가 해결되면 수행됨
• 스트레스 테스트의 결과는 규모 계획(capacity planning)을 위해 사용될 수 있으며, 관리자에게 시스템이 어떻게 중단되고 복구되는지에 대한 뷰를 제공한다.
• 프로젝트 말 쯤에 적어도 하나의 스트레스 테스트를 포함하도록 계획한다.

4 소크 테스트(Soak test): 장기간에 거쳐 시스템을 테스트

• 소크 테스트는 장기간의 시간을 거쳐 실행되는 부하 테스트이다. 이 테스트는 가능한 길게 또는 모니터를 통해 특정 추세가 식별될 때까지 실행되어야 함
• 소크 테스트 동안 찾고자 하는 아마도 가장 공통적인 문제가 메모리 누수이지만, 커넥션 타임아웃(connection timeouts)도 종종 발견되고 데이터베이스 증가(database growth)도 모니터 될 수 있음
• 소크 테스트 계획 시 모든 관련된 사람들을 포함시키고 그들 각자의 특정 영역을 위해 무엇을 모니터하기 원하는지 질문한다.

5 볼륨 테스트(Volume test): 높은 데이터 볼륨과 처리량

• 볼륨 테스팅은 데이터베이스 크기와 파일 크기에 대한 것. 이 테스트가 항상 요구되는 것은 아니지만 테스트 되는 애플리케이션 타입에 따라 중요할 수도 있음
• 데이터베이스 크기가 성능에 크게 영향을 줄 수 있으므로, 만일 성능 테스팅이 운영에서의 실제 크기에 비해 작은 데이터베이스에서 수행되었다면 이를 리스크로 밝혀야 함
• 볼륨 테스팅에서는 높은 사용자 수 형태의 부하나 테스트를 어떻게 실행할지에 대한 신중한 계획이 필요하지 않을 수도 있다.

Phase 5: 결과 분석(Results analysis)

• 결과 분석은 테스트 런 종료 시 테스터가 결과를 볼 때 올바른 그림(picture)을 주는 시나리오와 테스트의 설계로 시작함. 항상 의미 있는 결과가 얻어지는 것은 아님
• 성공적인 결과 분석을 보장하기 위해서 아래 2가지 규칙을 준수해야 함:
  1) 모든 것을 저장한다: 수행하는 매 테스트 런의 결과에 이름을 주고 저장한다. 나중에 참조하기가 쉽도록 적절하고 의미 있는 명명 규칙을 사용
  2) 모든 것을 추적한다: 왜 테스트가 실패하는지, 왜 성능이 좋은지/나쁜지(또는 이전과 다른지) 메모한다. 매 런 후에는 변경(무엇이 변했는지)과 이 변경이 시스템 성능에 주는 영향을 결과 요약서에 추가한다. 

결과 요약서(the results summary)는 아래 사항들을 포함한다.

• 테스트 개요(Overview of test)
• 시나리오 요약(Scenario summary)
• 사용자 수(Number of users)
• 최대 사용자 수(Maximum users)
• 기간(Duration)
• 총 처리량(Total throughput - Bytes)
• 총 히트 수(Total hits)
• 초당 평균 히트 수(Average hits per second)
• 그래프: 응답 시간 그래프(Response time graphs), 시스템 자원 그래프(System resource graphs), 비교 그래프(Comparison graphs)
• 후속으로 어떤 테스트를 수행해야 할지 추천(Recommendations for next test)

 

Phase 6: 보고(Reporting)

• 방법론의 마지막 단계에서는 전체 프로젝트의 발견사항과 진척을 보고함. 완전한 성능 테스트 보고서가 발표와 함께 관련자들에게 전달된다.
• 보고서 자체만으로는 그다지 효과적이지 않으므로(많은 이들이 아예 읽지도 않음) 발표를 통해 비기술자들도 이해할 수 있도록 최종 보고서 내용을 설명하고 질문에 답한다.
• 최종 보고서는 하나의 특정한 테스트의 결과를 다루기 보다는 테스트 프로세스의 전체적인 발견사항을 커버한다. 그래프는 프로젝트를 통한 성능 개선을 강조하면서 주로 비교 목적으로 포함되며, 상세한 결과는 포함되지 않는다(대신 특정 이슈가 언급되는 곳에서 관련 결과 요약서로의 참조 정보가 주어짐)