Introduce to Performance test(5/5)

Updated:

안녕하세요!
지난번 포스트에서는 성능테스트 설계 단계에 대해 살펴보았습니다.
전체 포스트는 아래와 같으며 이번 포스트에서는 마지막인 ‘실행 및 보고 단계’에 대해 알아보겠습니다.

  1. 성능테스트 개요
  2. 사전점검 및 계획단계
  3. 분석 단계
  4. 설계 단계
  5. 실행 및 보고 단계

성능테스트 실행 및 보고 단계에서는 계획/분석/설계를 통해 도출된 시나리오 및 케이스 수행을 위해 제반사항을 확인하고 테스트를 수행하여 시스템 병목 등의 문제 해결을 통해 최종 성능 목표 달성 여부를 확인하고 이를 토대로 도출된 결과를 분석하여 결과서를 작성합니다.

1. 테스트 준비

테스트 수행 전 최종 준비사항을 점검합니다.
점검 항목은 일반적으로 다음과 같습니다.

  • 시스템 모니터링 점검
    • POD, DB, Network, vYatta 등 구간별 모니터링 항목 및 담당자를 확인하고 모니터링의 범위, 구간, 모니터링 결과 전달 방법 등을 점검
  • 테스트 관련 엔지니어 참여 확인
    • R&R에서 지정한 엔지니어의 On/Off-line 지원체계를 점검, 시스템 병목구간 발생 시 빠른 식별 및 병목 해소
    • 엔지니어 간 Communication 채널 통합 확인
    • 계획/설계 단계에서 정의한 R&R에 따른 개별 모니터링 구간 재 확인

  • Batch job 중지
    • Batch job으로 인해 서버 자원 사용이 증가하게 되면 결과가 왜곡될 수 있으므로 Batch job은 대상을 식별하여 모두 중지
  • 시스템 로그레벨 확인
    • Application, Middleware에서 개발을 위해 설정된 로그레벨은 반드시 Info 또는 Error로 변경(Debug Level일 경우 LogWrite로 인한 Disk I/O 병목이 발생하여 정상적인 부하가 유입되지 않음)
  • 서버 내 프로세스 확인
    • 특정 Process가 서버의 자원을 점유하고 있을 경우 결과가 왜곡될 수 있으므로 필요없는 Process는 사전에 중단
  • 테스트 시나리오 및 스크립트 확인

2. 모의테스트 수행

본 테스트를 수행하기 전 모의테스트를 수행합니다.
모의테스트의 목적은 최종 테스트 수행 소스에 대한 자동화 스크립트 수행에 문제가 없는지, 기초적인 병목구간은 없는지, 테스트 데이터는 문제가 없는지, 성능테스트 도구 라이선스 문제가 없는지를 확인합니다.
테스트 부하는 본 테스트와 동일한 부하로 테스트를 진행하되, 라이선스 또는 시스템 사용 제약으로 인해 여의치 않을 경우 소량의 부하로 모의테스트를 수행합니다.

3. 테스트 수행

지정된 일자와 시간에 유관 관계자들과 계획된 시나리오/케이스를 수행합니다.
테스트 수행 시 가급적이면 유관 관계자와 같은 회의실에 모여서 수행하는 것이 좋습니다.
테스트 수행 차수 공유 및 문제 발생에 대한 협의가 주된 이유인데, 장소 이동의 귀차니즘 때문에 각자의 자리에서 유선/메신저를 통해 협의하게 되면 대면하여 소통할때와는 달리 의사 전달이 어려워 생각처럼 일이 잘 진행되지 않습니다.
또한, 다음의 항목들을 주의하여 테스트를 수행합니다.

  • Gold Plating 지양
Gold Plating: 고객과 약속하지 않았거나 계약된 범위를 벗어나 활동을 추가 하는 것
  • 각 담당자 모니터링 수행
    • 개발자 : Application 에러 여부 모니터링
    • Architect : H/W,S/W,N/W등 각 요소 담당자 별 모니터링
  • 각 시나리오/케이스 종료 후 결과 분석
    • 각 담당자의 모니터링 결과 공유 및 병목구간 식별
  • 목표 달성 여부 확인
    • 미 달성 시 원인 파악 및 재 수행
    • 테스트 환경에 관련된 경우 부하레벨 조정 후 재 수행
    • Application 및 Architecture와 관련된 경우 튜닝 후 재 수행
  • 로그 기록
    • 시나리오 명, 수행시간, 이슈사항, 조치 및 튜닝사항을 간략하게 작성

4. 테스트 종료

테스트 종료는 정해진 모든 시나리오를 수행 완료하거나 근 시간에 해결이 어려운 장애로 판단될 경우 테스트를 중단합니다. 이 경우 장애 해결 예상 시점에 재 테스틑 일정을 확정하고 종료합니다.
이후 아래와 같은 절차로 테스트 결과를 정리합니다.

  • 테스트 종료 후 요약 정리
    • 테스트 환경
    • 테스트 케이스, 부하 레벨, 대상 업무
    • 목표 달성 여부
    • 처리량(TPS), 응답시간, 자원사용량
    • 결과요약, 시사점 , 이슈사항
    • 향후 일정
  • 테스트 결과를 관련자에게 공유
  • 로그 기록 확인
    • 수행 중 기록한 로그를 바탕으로 결과보고서에 작성 가능한 케이스 도출
    • 미 달성 케이스 및 추가적인 케이스를 도출하여 향후 일정 반영
  • 테스트 자동화 툴에서 수집된 데이터 분석
  • 모니터링 툴 및 각 요소 담당자의 데이터 분석
  • 각 데이터를 취합하여 상관관계를 확인
  • 테스트 수행환경 복구
    • 부하발생기 PC/VM 제거
    • 방화벽 해제 복원
  • 데이터 복구
    • 테스트 수행 시 등록/수정/삭제한 데이터 복구
  • 로그레벨 복구
  • 기타 테스트 환경에 맞춘 설정 복구

5. 테스트 결과 작성

정해진 시나리오가 성능 목표에 도달하여 종료되면 이를 토대로 테스트 결과서를 작성합니다.
결과서는 각 요소 엔지니어의 모니터링 결과를 취합하여 작성하되, 원인과 결과에 대해 가감없이 작성합니다. 이때 주의할 점은 대부분의 보고 받는 대상은 테스팅 관련 전문 지식이 없으므로 최대한 이해하기 쉽도록 내용을 작성하는 것입니다. 결과서에 포함될 주요한 항목은 다음과 같습니다.

  • 테스트 환경 및 Method
  • 결과 요약 및 상세 결과
  • 시스템 자원 사용량(CPU, Memory, Network…)
  • TPS(Transaction Per Second)
  • 응답시간 추이
  • Middleware 모니터링 결과
  • 시스템 튜닝 항목

결과서 공유

결과서가 작성되었으면 내부 리뷰 후 결과서를 공유합니다. 결과서는 가능한 이해당사자가 참여한 상태에서 공유하며 결과가 목표에 미달했을 경우 이를 보완한 재 테스트 일정을 수립할 수 있습니다.

Lessons Learned 정리

테스트 수행에 따른 Lessons Learned를 정리하여 향후 비슷한 환경에서 적용할 기술 자료를 정립합니다.
항목은 다음과 같이 도출하도록 합니다.

  • 부하 모델 적정성
  • 자동화 툴 적용 방법 및 조치 내용
  • 모니터링 툴 적용 방법 및 조치 내용
  • 결함 및 병목에 대한 내용, 원인 및 시정조치 내용
  • 비즈니스 별 성능부하 테스트 방안
  • 기타 테스트 관련 기술 자료

끝마침


Introduce to Performance test의 포스팅은 이번이 마지막으로 총 5회에 걸친 포스팅을 통해 성능테스트 전반에 걸쳐 알아보았습니다.
최근 성능테스트는 Shift-left Testing(전성룡 수석님의 Shift Left Performance Testing 개요 글을 참조하세요)이 트랜드로 떠오르고 있어 애자일한 개발 환경에 성능테스트도 추가하여 조기에 성능 검증을 진행하고 있습니다.
이에 성능테스트의 중요성도 점점 더 커지고 있어 본 포스팅을 통해 성능테스트 전반의 작업들에 대해 많은 분들이 이해하고 테스트를 수행하였으면 합니다.

감사합니다.