...

• RampUp/Down Time을 설정하여 피크타임까지 사용자를 실제 시나리오와 유사하게 늘리고 뺌 - 
• 목표 TPS만큼 테스트가 안되면 테스트 통과 실패 - 
• TPS가 높아도 목표 사용자수가 안되면 테스트 통과 실패 - 
• 목표한 API 허용 에러률(1%)보다 높아도 테스트 통과 실패   (스크립트 오류및 테스트 노드장비 문제일수도 있음) - 
• 로드 테스트를 너무 많이해서 DB FUll이 나서 테스트 통과 실패 - 
• 알수없는 이유로 여러개의 노드중 1개의 노드가 Crash되어도 테스트 통과 실패 ( 에러율이 1%보다 높아짐)  - 
• 에러율이 낮아도 짧은기간에 에러 집중되면 테스트 통과 실패 - 
• 테스트를 모두 통과해도, 평균 허용치 CPU(80%)사용율을 특정시간동안 지속되면 테스트 실패 - 
• 코드수정및 스케일 아웃처리로 모든 로드 테스트를 통과해도, 이미 통과한 QA Sign OFF를 다시 받아야함, 이과정중 Codefix가 발생하면 다시 로드 테스트 수행 -
• 서버가 대용량 처리가 안정화 되어 ,장시간 테스트시 결국 분산 테스트툴보다 더 오래 버팀 (분산 테스트툴을 주기적으로 리셋해야되는 상황발생) -
• 이모든 장벽을 다통과해도 테스트 시나리오때 누락된 테스트항목으로 문제발생 ( 사용자 플래폼 변경에 따른 레거시 → 신규서비스 전환 테스트 미스) - 레거시 테스트 시나리오까지 작성하기 어려움 -이쯤되면 노하우보다 예지력이 생겨서 HotFix  , 신규서비스(html5) 전환 성공 -

위와 같은 수준의 로드(퍼포먼스,스파크,안정성) 테스트  하게되면  노하우보다 예지력이 생길수도있으며
성능테스트는 사실 측정하지 않으면 개선할수 없습니다.  글로벌 특정 카테고리기준 Top트래픽에 속했던 프로덕트의 측정과정의 수치를 공개합니다.

Daily LoadTest

스크립트자체 검증과 서버검증을 통과할떄까지 수행

...