부하테스트 합격 기준 잡기 - TPS 응답시간 측정 구간 프로파일 조서 연결

평균 응답시간만 넘기면 왜 검수가 흔들릴까?

평균은 느린 꼬리를 가립니다. 합격 문장은 백분위와 허용 초를 같이 적어야 현업 체감과 리포트가 같은 분모를 씁니다.

1초짜리 두 건과 7초짜리 한 건을 더해 나누면 평균은 3초입니다. 리포트는 3초를 초록으로 찍고, 현업은 7초를 느리다로 기억하죠.

같은 시험인데 분모가 다릅니다. 부하 시험 실무에서도 SLA를 평균으로 두지 말고, 예를 들어 요청의 99%가 1초 안에 끝나게 문장을 쓰라고 말합니다.

국제 소프트웨어 품질 모델은 시간 특성을 응답시간과 처리량으로 나눠 보는데, 그 시간도 평균 한 칸이 아니라 요구로 적힌 숫자여야 합니다. 검증(Validation)이 받는 것은 합의된 초이지, 도구가 고른 대표값이 아닙니다.

착수 기준선에 거래별로 95% 또는 99%와 허용 초를 적어두세요. 평균만 있으면 검수 주는 체감 싸움이 되고, 체감 싸움은 재시험 한 주가 아니라 오픈 연기로 갑니다.

TPS와 동시사용자 수는 같은 숫자일까?

TPS는 초당 처리 건수이고, 동시사용자는 붙어 있는 세션 수입니다. 한 칸에 섞으면 대기 줄이 긴 화면이 초록 TPS 뒤로 숨죠.

동시 200명이 붙어 있어도, 조회가 12초면 초당 처리는 한참 낮죠. 반대로 TPS 40이 나와도 대상이 로그인 한 종류면 월말 정산은 한 번도 안 탄 숫자죠.

그래서 합격 칸을 둘로 나눕니다. 대상 거래의 초당 건수, 그리고 그 거래를 붙인 세션 수.

품질 모델이 용량을 따로 보는 이유도 여기 있죠. 최댓값이 세션인지 건수인지가 비면, 수행사는 쉬운 쪽으로 부하를 태웁니다.

QA vs QC 주간 첫 장에 TPS만 크게 박히면 회의는 그 숫자에 쓰이고, 오류율과 타임아웃은 첨부로 내려갑니다. 오류 1%를 허용할지, 치명 거래는 0으로 볼지를 거래 칸에 같이 적어야 초록 TPS가 실패를 가리지 않습니다.

한 줄로 40 TPS 달성이라고 쓰면, 그 40의 분모는 수행사가 고른 거래가 됩니다.

측정 구간을 화면부터 잡을까, 서버부터 잡을까?

구간이 서버 로그만이면 브라우저 렌더와 망 지연이 빠집니다. 현업이 느낀 초와 도구 초가 갈리는 지점이 여기입니다.

서버 처리 0.4초에 화면이 그려지기까지 2초가 붙으면, 현업은 2.4초를 기다린 겁니다. 도구가 API 구간만 재면 0.4가 합격이고, 조회 화면 앞의 사람은 느리다를 검수 항목으로 올리죠.

구간을 세 칸으로 적어 보세요. 화면 클릭부터 응답 표시, 게이트웨이에서 애플리케이션, 데이터베이스만.

세 칸의 초가 같으면 그 숫자는 아직 구간이 없는 셈입니다. 목록 조회와 단건 저장, 파일 다운로드는 허용 초가 달라야 하고, 월말 배치는 초가 아니라 창의 분으로 적죠.

현업 싸인이 필요한 칸은 화면부터의 초입니다. 서버만의 초는 엔지니어 검토용으로 아래에 두세요.

구간을 비운 채 3초 이내라고만 쓰면, 재시험마다 도구 설정이 바뀌고 같은 3초가 다른 거리가 됩니다.

부하 프로파일이 없으면 왜 다음 주에 숫자가 달라질까?

램프업, 유지, 하강 분이 없으면 같은 TPS라도 충격 부하와 완만 부하가 섞입니다. 재시험은 다른 시계를 탄 시험이 됩니다.

오픈 직전 한 번에 200을 붙이면 큐가 터지고, 10분에 걸쳐 올리면 같은 200이 버팁니다. 둘 다 동시 200인데 결과는 다릅니다.

프로파일은 거창한 문서가 아닙니다. 시작 인원, 몇 분에 걸쳐 올리는지, 정점을 몇 분 유지하는지, 내릴 때 몇 분인지.

네 숫자가 조서 첨부에 없으면 다음 주 재시험은 다른 부하입니다. 실제 업무 시계도 넣으세요.

점심 직후 조회 몰림, 마감일 17시 저장, 심야 배치와 온라인이 겹치는 30분. 이 세 장면이 프로파일에 없으면 평일 오전 부하만 통과한 시스템이 됩니다.

WBS 시험 단계에 데이터 규모를 맞춘 줄을 따로 두세요. 개발 DB 1만 건으로 돌린 초는 운영 300만 건의 초가 아닙니다.

규모를 안 맞춘 합격은 오픈 다음 날 장애 목록으로 돌아옵니다.

조서에는 어떤 합격 칸을 남겨야 할까?

거래별 백분위, 오류율, 프로파일과 구간이 본문입니다. 평균 한 줄 만족은 첨부 제목에 가깝습니다.

소프트웨어사업 관리 지침은 납품물이 계약 요구를 충족했는지 시험과 검사로 확인한 뒤 인수하라고 합니다. 요구에 초와 분모가 없으면 그 확인은 만족 문장만 남죠.

조서 본문에 거래명, 백분위와 허용 초, 오류율, 측정 구간, 프로파일 첨부를 한 표로 두세요. 평균 PDF는 첨부 3입니다.

첨부를 본문으로 올리면 읽는 순서가 도구가 됩니다. 요구 관리 쪽 공개 자료도, 기능은 다 됐는데 성능 같은 품질 요구가 빠지면 그 사업을 실패로 본다고 적어 두었죠.

조서에 기능 시나리오만 합격이고 부하 칸이 비면, 검증(Validation)은 동작을 받은 기록이지 시간 특성을 받은 기록이 아닙니다. 조건부 합격이면 기한과 재시험 범위를 한 줄로 남기세요.

기한 없는 조건부는 다음 주에도 같은 평균 리포트가 다시 옵니다.

성능 시험을 WBS 어디에 넣어야 할까?

오픈 직전 한 칸이면 실패해도 고칠 주가 없습니다. 데이터 규모를 맞춘 성능 줄을 시험 단계 안에 따로 두고, 치명 실패 시 오픈을 막는 칸을 옆에 둡니다.

성능 시험을 오픈 전 3일로 한 줄 그리면, 실패는 일정 연기가 아니라 무시로 처리되기 쉽습니다. 여유일이 없는 줄에 실패를 넣으면 회의는 일단 오픈하고 안정화에서 보자는 쪽으로 기울죠.

시험 단계에 칸을 둘로 나누세요. 중간 규모로 프로파일을 고정하는 줄, 운영 규모에 가깝게 한 번 더 도는 줄.

두 줄의 선행이 데이터 이행 리허설이면, 규모 없는 초를 합격으로 부르지 못합니다. 치명 거래의 백분위가 기준을 넘기면 오픈 불가라고 옆 칸에 적어 두세요.

불가 칸이 없으면 그 줄은 참고 시험입니다. 참고 시험의 리포트는 주간보고를 채우지만 검수를 막지 못합니다.

막는 숫자가 표에 있어야 부하테스트가 검수이고, 없으면 도구 시연입니다.