クイズ: 受け入れ基準をテストにする

요청 40건 중 38건이 5ms, 2건이 400ms 였다. 기준이 'p95 250ms 이하' 이고 계산 방법을 적지 않았다면 생기는 문제는?

• 어느 방식이든 p95 는 400ms 이므로 문제가 없다
• 평균이 24.75ms 라서 p95 도 같은 값으로 수렴한다
• p95 는 표본이 100개 이상이어야만 정의되므로 판정할 수 없다
• nearest-rank 는 5.0, quantiles 기본값은 380.25 가 나와 같은 증거가 통과도 실패도 된다

고객 운영팀이 '평균 지연 100ms' 기준에 반대한 이유로 가장 알맞은 것은?

• 평균은 스무 번에 한 번 멈추는 느린 꼬리를 가려 사용자가 겪는 멈춤을 드러내지 못하기 때문에
• 평균은 계산 비용이 커서 인수 시험 시간이 길어지기 때문에
• 평균은 시간 초과 요청을 계산에 넣을 수 없기 때문에
• 평균은 요청 수가 달라지면 단위가 ms 에서 초로 바뀌기 때문에

인수 실행기가 응답이 늦을 때 한 번 더 요청하는 재시도를 넣었다. 기준 판정에 미치는 영향은?

• 재시도는 네트워크 흔들림을 걸러 주므로 오류율이 더 정확해진다
• 재시도 요청이 분모와 표본을 바꿔 오류율과 p95 가 합의한 측정 조건과 달라진다
• 재시도는 서버 쪽 요청 수만 늘릴 뿐 실행기의 지표에는 영향이 없다
• 재시도하면 p95 는 그대로이고 오류율만 조금 낮아진다

재실행 비교에서 request_id 를 빼야 한다는 것을 알고 실행기 코드에 'request_id' 를 직접 적었다. 무엇이 문제인가?

• request_id 는 JSON 키가 아니라 헤더라서 본문 비교에 영향이 없다
• 코드에 적은 필드는 대소문자를 구분하지 않아 다른 필드까지 빠진다
• 서버가 필드 이름을 바꾸면 정상 빌드도 떨어지므로 뺄 필드는 기준표에서 읽어야 한다
• 필드를 빼면 비교가 느슨해지므로 변하는 필드도 모두 비교해야 한다

후보 rc2 가 금액 기준에서 떨어졌다. 담당 엔지니어가 '1원 차이는 반올림' 이라며 threshold 를 2 로 고쳐 다시 돌리려 한다. 올바른 대응은?

• 다시 돌려 통과하면 그 보고서를 최종본으로 제출한다
• 금액 기준만 기준표에서 빼고 나머지 세 기준으로 판정한다
• 틀린 사례를 사례표에서 지우고 다시 돌린다
• 현재 기준으로 거절을 보고하고, 허용 오차가 필요하면 고객과 새로 합의한다

사례 하나의 1회차 응답이 500 이었다. 이 사례를 mismatches 에서 어떻게 다루는 것이 계약에 맞는가?

• 오류율에서 이미 셌으므로 금액 비교에서는 빼서 한 결함을 두 기준에서 이중으로 세지 않는다
• 금액을 받지 못했으니 틀린 사례로도 센다
• 2회차 응답이 200 이면 그 금액으로 대신 비교한다
• 500 이 나온 사례는 사례표 전체를 무효로 보고 판정하지 않는다