디버깅 프록시로 실패 사례 설계하기
프록시 기반 테스트가 점검해야 할 클라이언트 동작에 맞춰 HTTP 편집, 지연, 중단된 교환을 선택합니다.
디버깅 프록시는 일반 서버가 좀처럼 만들지 않는 응답을 클라이언트가 마주해야 할 때 유용합니다. 먼저 클라이언트 동작을 정의하고, 그다음 그 조건을 만드는 개입을 선택하십시오.
“요청이 실패했다”는 너무 넓은 테스트 사례입니다. 유효한 HTTP 오류 응답, 끝내 도착하지 않는 응답, 다운로드 도중 끊긴 연결은 애플리케이션에 서로 다른 것을 요구합니다.
| 사례 | 점검할 동작 |
|---|---|
| 완전한 HTTP 오류 응답 | 클라이언트가 상태를 읽고 의도한 오류 정책을 적용하는지 |
| 지연된 응답 | 사용자가 취소할 수 있는지, 의도한 단계에서 타임아웃이 적용되는지 |
| 예상치 못한 헤더나 본문 필드 | 파싱과 검증이 명확히 실패하는지 |
| 중단된 교환 | 불완전한 데이터가 완료된 결과와 구분되는지 |
올바른 계층에서 개입하기
Charles는 요청이나 응답을 전달하기 전에 멈추는 브레이크포인트를 제공합니다. 가로챈 메시지는 검사하고 편집할 수 있으며, 통과시키거나 중단할 수 있습니다. Rewrite 도구는 일치하는 헤더, URL, 본문에 반복 가능한 변경을 적용합니다. 대역폭 제한은 대역폭과 추가 지연을 제어합니다.
이 제어는 HTTP 클라이언트의 동작을 시험할 수 있지만, 대역폭 한도는 무작위 IP 패킷 손실의 정확한 모델이 아닙니다. 프록시는 데이터를 버퍼링하고 연결을 재사용하며 별도의 업스트림 연결을 열 수 있습니다. 필요한 조건이 분명히 HTTP 아래 계층이라면 네트워크 열화 도구를 선택하십시오.
각 사례를 해석 가능하게 유지하기
의도한 호스트와 경로를 좁게 일치시키십시오. 정상적인 교환으로 시작해 변경 하나만 켜고 무엇이 바뀌었는지 기록하십시오. 재시도가 두 번째 엔드포인트에 도달하면 같은 규칙이 그 시도에도 적용되어야 하는지 결정하십시오. 그렇지 않으면 무조건적인 재작성이 모든 복구 경로를 원래의 실패로 바꿔 놓을 수 있습니다.
업로드나 결제와 유사한 작업에서 응답이 유실되었다고 해서 서버가 요청을 거부했다는 증거는 아닙니다. 모든 전송 실패를 반복해도 안전하다고 단정하지 말고 그 모호함을 재시도 사례에 포함하십시오.
HTTPS 내용을 검사하거나 편집하려면 클라이언트가 디버깅 프록시의 TLS 검사 설정에 참여해야 합니다. CONNECT만 전달하는 프록시는 암호화된 애플리케이션 바이트를 봅니다. 분리된 테스트 구성을 사용하고 이후에 라우팅과 신뢰 설정을 복원해 이후 관찰이 정상 클라이언트를 설명하도록 하십시오.