1. Testing 시나리오 작성

1. 요구사항

• API V1.1의 경우 Transaction을 적용해도 데이터 정합성이 지켜지지 않는 문제점 확인되었으며, API V1.2로 진행 → Code Logic에 문제점을 확인하였으며, 수정 후 Test 진행
• 데이터 정합성이 지켜지는지 확인
• Isolate Level과 Lock 종류에 따른 데이터 정합성 결과 확인
• User수는 10으로 진행하며, 정합성이 지켜진다면 점진적으로 100, 1000으로 증가시키기.

<aside> 💡 Test시 가장 중요한 점 예매 수(Count)의 최대 한도가 BookingLimit와 일치해야 한다. (데이터 정합성)

</aside>

2. Test 절차

1. Test Source Code

• 공연 예매 신청 Logic
  1. TypeORM queryRunner를 사용하여 Transaction 진행
  2. goods Entity의 BookingCount, BookingLimit를 확인 → 이때, Lock 수준을 변경하며 Test 진행
  3. Count 수가 BookingLimit보다 많은 경우 → Error 처리 (’남는 좌석이 없습니다’)
  4. Count 수가 BookingLimit보다 적은 경우 → bookingCount =+ 1을 진행
  5. Goods Entity의 BookingCount update 진행
  6. Booking에 예매 정보 insert
  7. 완료가 된 경우 Transaction Commit 진행
  8. 성공한 경우 성공 메세지 return
• Source Code

1. Server, SQL 환경

• Server : Local 환경 진행 (Code 문제점을 보기 위한 Test)
• SQL : Local 환경 PostgreSQL 진행