Test Results Summary

LoadTest의 고뇌 ( 한번도 못할수도 있지만 한번하면 한번만 하고 싶은 로드 테스트 과정 )

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

Daily  Daily 로드 테스트(스크립트자체 검증과 서버검증을 통과할떄까지 수행)

...