홍성진

홍성진

I am Ironman

Introduce to Performance test(2/5)

Updated:

안녕하세요!
지난번 포스트에서는 성능테스트의 개요에 대해 살펴보았습니다.
전체 포스트는 아래와 같으며 이번 포스트에서는 두번째인 ‘사전점검 및 계획단계’ 에 대해 알아보겠습니다.

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

사전점검

1. 사전 검토 및 자동화 툴 검증

성능테스트를 수행하기 전 성능테스트 담당자는 해당 프로젝트를 사전에 파악하여 성능테스트가 필요한 프로젝트인지, 준비사항이 어떤것이 있는지를 미리 파악 할 필요가 있습니다.

지피지기 백전불태 (知彼知己 百戰不殆)
테스트 준비도 한걸음 부터

1-1. 사전미팅

테스트 수행을 위해 프로젝트 관계자와 회의를 통해 아래의 항목을 미리 점검해야 합니다.

  • 프로젝트 주요 프로필
  • 대상 업무 및 시스템의 종류와 유형
  • 성능 관련 비기능 요구사항(RFP 또는 고객 요청사항 참조)
  • 테스트 환경, 이슈 및 리스크 검토
  • 부하발생기 설치위치 및 구성
  • 시스템 모니터링 자동화 툴 종류 및 구성

1-2. 자동화 툴 검증

사전미팅 또는 투입 전 테스트 대상 App의 자동화 툴 적용 여부를 검토합니다. 일반적인 WEB 환경이라면 큰 무리없이 진행 가능하나 자동화 툴로 구현이 어려운 환경일 경우 자동화 툴 적용 여부를 검토할 필요가 있습니다.

자동화 툴로 구현 가능한 환경

  • WEB 기반 환경(80포트 통신)
  • TCP/IP 전문 통신환경(TCP/IP 규격)
  • SAP ERP …

자동화 툴로 구현이 어려운 환경

  • 규격외 TCP/IP 전문
  • CCTV 화면송출
  • Realtime data …

자동화 툴로 구현이 가능하다고 해도 License 정책에 따라 수행이 불가능할 수 있습니다.(실제로 Loadrunner 경우 Protocol이 제품군에 따라 나뉘기 때문에 이로 인한 제약도 고려해야 합니다) 또한, 구현은 가능하나 암호화 통신, 보안등의 제약을 우회하기 위한 시간적 제약도 고려해야 합니다. 일례로, 지금은 많이 사라졌지만 ActiveX을 사용한 페이지를 테스트할 경우 개발사로 부터 ocx파일을 성능테스트 용도(암호화 및 전문 처리를 위한 별도의 파일)로 변형하여 전달받아 이에 맞는 양식으로 OCX를 로드하여 사용하기도 합니다. 이를 위해 개발사와 별도로 회의를 하고, 개발된 파일을 받고, 이를 툴에 적용하기까지의 시간이 상당히 소요됩니다.

암호화 모듈 사용을 위해 직접 코드를 개발해야 할 수도 있다
{
// P값을 Xecure.dll을 통해 암호화 문자열을 추출해 가져옴. 결과는 Param_Q에 저장
strcpy(xaddr_enc, "maker.test.go.kr:443:8088"); 
strcpy(path, “/jsp/mp/mpMemberLoginCheck.jsp");
strcpy(plain, "j_nextpage=/Index.jsp&");
strcpy(method, "post");

BlockEnc(xaddr_enc, path, plain, method, &result_msg);
lr_output_message("result_msg = %s",   result_msg);  
sprintf(s, "%s", result_msg );
strcpy(strEscapeUrl ,escape_url(s));
lr_save_string(s, "Param_P");
lr_log_message("Param_P=>%s\n", lr_eval_string("{Param_P}"));

lr_start_transaction("01_로그인");
	web_submit_data("apMemberLoginCheck.jsp", 
	"Action=http://test.go.kr/jsp/apk.jsp?q={Param_Q}&charset=utf-8", 
		"Method=POST", 
		"TargetFrame=", 
		"RecContentType=text/html", 
		"Referer=http://biz.test.go.kr/", 
		"Snapshot=t2.inf", 
		"Mode=HTML", 
		ITEMDATA, 
		"Name=p", "Value={Param_P}", ENDITEM, 
		EXTRARES, LAST);
}

1-3. 준비사항 검토 및 가이드

사전점검 단계는 대면을 통한 준비단계라고 한다면 준비사항 검토 및 가이드는 대면 이후 서면등을 통해 준비하는 단계입니다. 대부분 사전점검 단계에서 항목들이 식별되었으나 이를 준비하는 프로젝트 입장에서는 조금 더 세분화된 항목들의 가이드를 통해 테스트 준비를 공고히 할 수 있습니다.

Workload Modeling을 위한 준비사항

  • 동시유저, Peak 시점, AS-IS Access Log 등

성능목표 협의

  • 응답시간, 목표 TPS

테스트 대상업무 선정

  • 발생빈도, 집중사용시기, 사용자수, 아키텍처 및 기간을 고려하여 선정
  • MSA(MicroService Architecture)일 경우 MSA별 서버를 최대한 커버할 수 있는 업무로 선정
  • 동일 아키텍처 중복 배제, 테스트 데이터 반복사용을 고려

테스트 수행환경

  • 테스트 수행환경 세팅(운영환경을 원칙으로 하되 여의치 않을 경우 운영Spec에 준하는 환경으로 구축)
  • 소스 Freezing(스크립팅 이후 대상 업무에 대한 수정 시 재 작업이 필요하므로 Minor patch는 테스트 이후 적용)
  • 서버 모니터링 도구 결정(ex. Grafana, Sitescope)
  • 부하발생기 설치(VM 또는 노트북)
  • 방화벽 해제

Database

  • Open후 운영시점 수준의 데이터 적재
  • 소진성 데이터(ex. 결재)의 경우 테스트 횟수만큼 준비

테스트 수행 관련

  • 테스트 관련자 참석 요청 및 일정 공유

테스트 계획

2. 성능테스트 계획수립

앞 단계에서 협의한 사항을 토대로 성능부하 테스트 계획서 템플릿을 이용하여 테스트 계획서를 작성합니다. 전체 시스템 중 테스트 대상 시스템의 규모와 개략적인 대상 업무 파트, 일정등을 도출하여 테스트 전반의 계획을 세우고 이를 토대로 관련 엔지니어와 공유하여 협업을 준비합니다.


[완벽한 준비로 성공적 테스트 수행을! / 기생충 포스터 중]


2-1. 프로젝트 팀 사전 준비 항목 완료 여부 파악

계획수립 단계는 사전점검 이후 프로젝트에 투입되어 테스트를 준비하는 단계입니다. 사전점검 및 준비사항 가이드의 항목이 어느정도 준비되었는지 점검하여 미흡한 항목을 준비합니다. 사전점검 단계에서 가이드한 항목은 사실 대부분의 프로젝트에서 절반도 준비하지 못하는 경우가 많습니다. 보통 성능테스트 수행이 통합테스트 단계에 포함되어 수행하여 무지하게 바쁜 시기이기 때문이죠.(성능테스트가 Agile Sprint 단계에 포함되어야 하는 이유기도 합니다)

2-2. 업무 개요 및 테스트 범위 정의

테스트 대상 시스템의 개요 및 테스트 범위를 정의합니다. 시스템의 규모가 커서 단위 시스템이 여러개로 나뉘어진 프로젝트의 경우 단위 시스템별 / 부하가 중첩되지 않는 시스템별 / 중요 시스템별 테스트를 수행하는 등 전략적으로 테스트 범위를 정합니다.

2-3. 테스트 목적, 영역, 수행 절차 정의

테스트의 목적에 따라 테스트 방법이 달라질 수 있습니다. 시스템의 병목구간을 확인하기 위함인지, 시스템 구성의 적정성을 검증할 것인지, 부하 분산 방식을 확인할 것인지, 네트워크 병복구간을 확인할 것인지, AS-IS vs TO-BE 비교를 할 것인지를 명확히 하여 자칫 테스트가 산으로 가지 않도록 해야 합니다.


[목적이 없으면 결국 산으로 간다 / 출처: 네이버지도]


또한 테스트 영역이 명확하지 않으면 개발 범위 이외의 구간까지 테스트해야 할 상황이 올 수 있습니다. 테스트 수행 절차 정의 역시 중요한데요, 테스트 목적에 맞게 단계별 Task, input/output, 지침, 담당자를 지정하여 짜임새 있는 준비를 할 필요가 있습니다.

2-4. 테스트 조직 및 역할 정의

테스트 조직과 역할은 테스트 수행 절차에 따른 실제 담당자들을 Listup하여 담당자들의 역할과 활동사항을 정의합니다. 성능테스트가 수행되면 많은 이해관계자가 주간 또는 야간에 모여 테스트를 수행하게 됩니다. 앞선 계획 단계에서 테스트 영역과 구간을 명확히 하여 모니터링 할 구간 별 담당자가 정확히 정의되지 않는다면 많은 인원이 모인것이 허사가 되고 재 테스트를 하는 상황까지 올 수 있죠.

모 사이트 성능테스트 중 시스템에 목표한 부하가 제대로 유입되지 않는 현상이 발생하였습니다. 자정이 넘어서까지 문제점을 찾아보니 서버 앞단 WAF 방화벽으로 인한 문제였습니다. 결국 테스트는 중단되었고 다음날 WAF 엔지니어를 데리고 다시 테스트를 수행하였습니다.

2-5. 테스트 일정 및 자원 정의

테스트 전체 일정에 대한 계획을 세웁니다. 일자별 Task를 정의하고 Task별 담당자를 지정하여 일정표 대로 테스트가 준비될 수 있도록 합니다.
테스트 수행 일자는 재 테스트와 결과서 작성 시간을 고려하여 너무 늦지 않은 일정에 수행될 수 있도록 선정하여야 합니다. 물론 해당 테스트 일자에 시스템 유지보수 일정 등 다른 작업이 있는지도 고려해야겠죠.

2-6. 성능부하 테스트 계획서 공유

작성된 테스트 계획서는 테스트 조직 및 역할에 정의한 담당 엔지니어, 고객, 이해관계자와 공유하여 해당 일정의 테스트 계획을 공유하여 담당자별 역할과 일정을 미리 주지시키도록 합니다.

끝마침

이로써 Introduce to Performance test의 두 번째 포스팅을 마쳤습니다. 시작이 반이라고 계획 단계에서 빠짐없는 준비를 해야 성공적인 테스트를 마칠 수 있습니다.
다음 포스팅은 시스템 분석 단계에 대한 포스팅을 기술할 예정이므로 많은 관심 부탁드립니다.

감사합니다.

You May Also Enjoy