결제 주소 테스트 사례: 자동 완성, 수정 및 배송 재계산

주소 항목에 여러 경로가 있습니다.

키보드 입력, 브라우저 자동 완성, 여러 줄 붙여넣기, 제안 및 저장된 주소를 포함합니다. 모든 경로는 국가 및 단위 세부 정보를 유지하면서 하나의 API 계약을 생성해야 합니다.

제안 시간 초과로 인해 유효한 수동 입력이 차단되어서는 안 됩니다. 쇼핑객이 빈 목록에 가두는 대신 계속 진행할 수 있다고 설명합니다.

구매자가 수정 사항을 통제할 수 있도록 하세요

입력된 주소와 제안된 주소를 나란히 표시하고 변경 사항을 강조 표시하며 원본을 허용합니다. 아파트나 건물 이름을 조용히 삭제하지 마십시오.

수락, 유지, 다시 열기, 시간 초과 및 제안 누락 라인 2를 테스트합니다.

배송비, 세금, 배송 방법을 다시 계산하세요.

국가, 지역 또는 우편번호를 편집하면 방법이 무효화되고 배송, 세금, 한도 및 날짜가 변경될 수 있습니다. 새 견적이 도착할 때까지 최종 제출을 차단합니다.

신속한 편집으로 동시 견적이 생성됩니다. 최신 주소 버전과 일치하는 결과만 적용합니다.

• 국가 변경 후 잘못된 방법 삭제
• 배송비와 세금을 함께 업데이트하세요
• 오래된 인용 응답 무시
• 실패 후에도 장바구니와 주소를 보존합니다.

청구 및 배송에는 독립적인 편집 가능한 사본이 필요합니다.

배송과 동일하게 복사본을 만들 수 있지만 둘은 변경 가능한 개체를 공유해서는 안 됩니다. 선택을 취소한 후 청구서를 편집하면 배송이 변경되어서는 안 됩니다.

지불 주소 확인을 위해 무작위 데이터 대신 지불 공급자 샌드박스와 문서화된 트리거를 사용하십시오.

shippingAddress = structuredClone(selectedAddress);
billingAddress = sameAsShipping
  ? structuredClone(shippingAddress)
  : enteredBillingAddress;

최종 제출을 멱등성으로 만들고 주소 스냅샷을 찍습니다.

두 번 클릭, 시간 초과 재시도 및 모바일 뒤로 탐색을 통해 요청을 반복할 수 있습니다. 반복되는 UI 작업을 비활성화하고 서버 측 멱등성 키를 사용합니다.

편집 가능한 주소록 항목만 참조하는 대신 확인된 주소 스냅샷과 견적 버전을 주문에 저장하세요.

모바일 범위에는 기본 작업을 숨기는 소프트웨어 키보드, 앱을 백그라운드로 전환했다가 복원하는 과정, 외부 결제 승인에서 반환이 포함되어야 합니다. 재개 시 다른 생성 작업을 보내기 전에 기존 주문이나 멱등성 요청을 쿼리하세요.

결제 중에 주소가 두 번 변경된 주문을 감사(audit)합니다. 스냅샷에는 최종 확인된 버전이 포함되어야 하고, 배송 견적은 해당 버전에 속해야 하며, 나중에 구매자 주소록을 편집할 때 주문 이력이 다시 작성되어서는 안 됩니다.

또한 모호한 실패를 테스트하십시오. 제출 후 브라우저가 시간 초과되었지만 서버가 이미 주문을 생성했습니다. 동일한 키를 사용한 재시도는 다시 청구하거나 인벤토리를 두 ​​번 예약하는 대신 원래 결과를 반환해야 합니다. 지원 도구는 일상적인 로그에 전체 주소를 노출하지 않고 요청 키, 주소 버전 및 주문 식별자를 노출해야 합니다. 이를 통해 불필요한 개인 데이터 액세스를 제한하면서 복구를 테스트할 수 있습니다.

• 더블 클릭, 시간 초과 재시도 및 지불 반환 시뮬레이션
• 페이지 복원 후 멱등성 상태 쿼리
• 주문 주소와 견적 버전 일치
• 주소록 편집 후 기록 다시 열기