문서요약 - 효과적인 성능 테스트 보고서 작성법 by Namachivayam

제목: 효과적인 성능 테스트 보고서 작성법(How to write an effective performance test report?)

저자: NaveenKumar Namachivayam

문서유형: 웹문서, 2015년

 

출처: https://qainsights.com/how-to-write-an-effective-performance-test-report/

 

성능 테스트 결과 보고서 작성에 대해 간략하게 설명한 자료

 

---

 

전제 조건

성능 테스트 보고서 작성을 시작하기 전에 아래의 데이터 항목들이 가용하고, 보고서 작성자가 이에 대해 숙지하고 있어야 한다. 

1.     대상자(보고서의 주요 독자)

2.     프로젝트/릴리즈/빌드 세부 정보

3.     테스트 환경 및 버전 정보

4.     테스트 유형(부하/스트레스/내구성/볼륨/스파이크)

5.     워크로드 모델

6.     프로토콜

7.     시간대/타임스탬프

8.     비즈니스 흐름

9.     테스트 데이터

10.   성능 모니터링 도구로부터 나온 입력 데이터

 

HP LoadRunner를 사용하는 경우 기본적으로 모든 세부 정보가 포함된 보고서가 생성되는데, 이걸 그대로 고객과 공유하는 것은 바람직하지 못하다. 중요한 통계 및 측정 항목이 강조되도록 기본(디폴트) 보고서를 커스토마이징하여 사용하는게 좋다

 

 

성능 테스트 보고서 작성 전

성능 테스트 보고서를 작성하기 전에 스프레드시트 프로그램(대개 Microsoft 액셀)에서 사전 작업을 하는 것이 중요하다. 모든 메트릭, 통계, 원시 데이터를 복사하여 붙여 넣고, 이를 분류하고 분석한다.

 

예를 들어, ‘자금 이체(Fund Transfer)’라는 비즈니스 시나리오에 아래와 같은 6가지 주요 비즈니스 트랜잭션이 있다.

1. 은행 웹 사이트 시작(Launch Bank Website)

2. 로그인(Login)

3. 잔액 확인(Check Balance)

4. 자금 이체 제출(Fund Transfer Submit)

5. 잔액 확인(Check Balance)

6. 보안 로그 오프(Secure Logoff)

 

목표 부하(target load)가 시간당 10,000 트랜잭션이고 서비스 수준 합의(Service Level Agreement: SLA)에 따른 95% 응답 시간이 2초라고 가정한다.

 

위의 내용과 별개로 평균값(Mean), 중앙값(Median), 표준 편차(Standard Deviation), CPU/메모리/디스크 사용률을 가정한다.

 

 

성능 테스트 보고서 작성 중

대부분의 조직이 성능 테스트 보고를 위한 템플릿을 제공하고 작성자가 이를 커스토마이징 할 수 있게 하는데, 성능 테스트 보고서에 일반적으로 아래와 같은 사항들을 포함시킨다. 

• 테스트의 목표
• 프로젝트 개요
• 비즈니스 트랜잭션 개요
• 워크로드 모델 분포(Workload model distribution)
• 런타임 설정(Run-time settings)
• 빌드/버전 정보
• 개발 반복(Iteration)
• 테스팅 도구의 결과
• MS Excel 또는 테스트 도구의 그래프
• 서비스 수준 합의(SLA) 위반 세부 정보
• 생산 인프라구조와 비 생산 인프라구조에서의 응답 시간 비교
• 최종 출시 결과와의 비교
• 결론 및 권고사항

 

위에서 마지막 네 가지 항목은 성능 테스트 보고서에 포함시켜야 할 매우 중요한 데이터이다.

 

서비스 수준 합의(SLA) 위반 세부 정보

이 섹션에서는 어떤 트랙잭션이 SLA를 위반했고 그 이유가 뭔지 언급한다. 위 예에서 ‘자금 이체 제출(Fund Transfer Submit)’ 트랜잭션이 응답 시간 2초의 SLA를 위반하는걸로 나타난다. 해당 페이지에서 데이터가 서버로 제출되면, 서버는 코드에 정의된 규칙에 따라 트랜잭션의 유효성을 검사한다. 자금 이체가 은행 내부에서 발생할 수도 있고, 외부 은행과 할 수도 있고, 또는 외국 송금이 될 수도 있다. 자금 이체가 트리거되기 전에 계정에 충분한 잔액이 있는지 여부를 확인하게 되며, 또한 수령자의 세부 사항도 유효성 확인을 한다. 따라서 많은 웹 서비스 호출이 여기저기서 발생하게 되며, 이런 점을 고려하면 확실히 응답 시간이 더 길어지게 된다. 

리퀘스트가 클라이언트와 서버 간에 어떻게 왔다갔다 하는지 이해하려면 트랜잭션을 자세히 분석할 필요가 있으며, 따라서 모든 성능 테스트 엔지니어가 기술 설계 문서를 이해할 수 있어야 한다. 설계를 잘 알고 있다면 할 일의 절반은 이미 한 것이나 마찬가지다.

 

생산 인프라구조와 비 생산 인프라구조 간의 응답 시간 비교

대부분의 성능 테스트 엔지니어가 현재의 비 생산 인프라구조와 생산 인프라구조의 통계치를 비교하는 것을 잊어버리는데, 비 생산 인프라구조가 축소된 환경인 경우 여기에 생산 환경에서와 동일한 부하를 가하는 것은 바람직하지 않다. 

운이 좋은 조직은 생산 환경과 비 생산(생산 전) 환경에서 동일한 인프라구조를 갖을지 몰라도 IT 예산이 부족한 중소 기업에서는 대개 축소된 환경을 갖게 된다. 예를 들어, 생산 환경에 64GB RAM이 있고 비 생산 환경에 6GB RAM이 있다면, 성능 메트릭에 분명히 차이가 발생한다. 이 경우, 비 생산 환경에서의 목표 부하(target load)는 축소된 규모에 따라 비례 배분하는 것이 바람직하다.

 

마지막 출시 결과와의 비교

현재 결과를 이전 반복(previous iteration)과 마지막 릴리즈 결과와 비교하는 것이 바람직한데, 이렇게 하면 코드 튜닝에서 얼마나 많은 향상이 이루어 졌는지 확인할 수 있다. 데이터 열과 행 형식으로 표현하기 보다는 그래프/차트 형태로 원시 데이터 결과를 보여주는 것이 좋다.

 

결론 및 권고사항

결론은 모든 보고서에서 가장 중요한 부분이다. 이전 릴리즈 결과를 참조하기 위해 보고서를 읽는 아키텍트라면 문서의 다른 페이지를 모두 건너 띄고 곧장 결론으로 갈 수도 있다. 따라서 결론과 권고사항을 정확하고 명료하게 표현하는 것이 중요하며, 이 섹션에 여러 데이터 요소를 포함하기 보다는 성능이 어떠했으며 권장사항이 무엇인지를 기술하고 있어야 한다. 필요 시 리스크와 그 영향을 언급 할 수도 있다.

 

 

성능 테스트 보고서 작성 후

성능 테스트 보고서를 작성한 후 최소한 세 번은 검토하는 것이 좋다(작성자 자신의 검토, 동료의 검토, 관리자/팀리더의 검토). 모두가 테스트 보고서에 만족하면, 프로젝트 폴더 또는 콘텐츠/문서 관리 포털에 업로드한다. 날짜 및 시간스탬프를 포함한 문서의 모든 버전 이력을 관리하고, 관련된 모든 참조 이메일, 문서, zip 파일, Excel 파일, 스크린 샷, 기타 문서 등을 첨부한다.

 

적절한 때가 되면 간결한 이메일을 작성하여 성능 보고서를 고객 파트너에게 전달해 공유하고, 모든 팀 구성원과 프로젝트 관리자에게도 참조 이메일을 보낸다.