01 / 10 Performance Test Plan

Chic Car Rent
Performance Test

แผนและชุดทดสอบสมรรถนะระบบ อิงตาม Non-Functional Requirements (BRD §5) — ทดสอบว่าระบบรองรับผู้ใช้พร้อมกันได้ตามเป้าและเร็วพอ

Zeabix × Prime Car Rent · นำเสนอทีมพัฒนา

02 / 10 เป้าหมาย · อิงตามเอกสาร BRD

วัดอะไร และผ่านที่เท่าไร

10,000

บัญชีลูกค้าที่ต้องรองรับ

100 → 200

ผู้ใช้พร้อมกัน Normal → Peak

< 1%

Error rate (ทั้งสองโหมด)

โหมด	Concurrent Users	Page Load (p95)
Normal Traffic	100 users	≤ 3.0 วินาที
Peak Traffic	200 users	≤ 5.0 วินาที

ตัวเลขทั้งหมดอ้างอิงจาก เอกสาร BRD — Non-Functional Requirements

03 / 10 วิธีการ

เครื่องมือ & เส้นทางที่เทส

🛠 เครื่องมือ

k6 — script เป็น JS, รันใน CI/Docker ได้, มี HTML report
โครงสร้าง แยกไฟล์ต่อ flow — มี HTML report แยกต่อ API
สลับ normal / peak ด้วย env เดียว ไม่ต้องแก้โค้ด

🎯 เน้น Critical Path

เทสเส้นทางที่ลูกค้าใช้จริง & โดน traffic หนักสุด

ค้นหาCatalog

→

จองBooking

→

จ่ายเงินPayment

โหลดแต่ละรอบ: ramp-up 2 นาที → คงโหลด 10 นาที → ramp-down 1 นาที (จำลองผู้ใช้ค้างต่อเนื่อง ไม่ใช่ยิงรัวครั้งเดียว)

04 / 10 Microservices ที่ทดสอบ

ยิงโหลดไปที่ service ไหนบ้าง

เลือกเฉพาะ service บนเส้นทางจอง (in-scope) — ทุกตัวเรียกผ่าน gateway เดียว /api/proxy/{service}/...

Service	หน้าที่ในเส้นทาง	Endpoint ที่เทส	น้ำหนักโหลด
catalog-service	ค้นหารถ + คำนวณราคา	`POST /public/search`	หนักสุด
booking-service	สร้างการจอง (guest)	`POST /public/booking`	ปานกลาง
payment-service	เริ่มชำระเงิน	`POST /public/payments/initiate`	ปานกลาง

user-service และ service อื่น — ไม่อยู่ใน scope รอบนี้ (ไม่ใช่เส้นทางจองหลัก) เพิ่มได้ภายหลังถ้าต้องการ
ทุก service แชร์ App Service Plan B3 ตัวเดียว → ตอนยิง 200 VU จะเห็นว่า CPU เป็นคอขวดร่วมหรือไม่

05 / 10 โครงสร้างโค้ด

โค้ดทำงานยังไง

📁 โครงไฟล์

ccr-perf-test/k6/
  lib/
    options.js   # สลับโหมด+เกณฑ์
    tokens.js    # จัดการ auth
  scenarios/
    search.js    # ค้นหา
    booking.js   # จอง
    payment.js   # จ่าย
  results/       # HTML report

⚙️ 3 กลไกหลัก

options.js — ตัวเดียวคุมทุก scenario: env MODE → กำหนด VU (100/200) + threshold (p95 3s/5s) ตาม NFR
tokens.js — รวมจุดจัดการ Turnstile + booking-token ไว้ที่เดียว
handleSummary — ทุก scenario ออก HTML report อัตโนมัติเทียบเกณฑ์ผ่าน/ไม่ผ่าน

// search.js — หัวใจของทุก scenario เหมือนกัน
export const options = buildOptions('Search');           // ← VU+threshold ตาม MODE
const res = http.post(`${BASE_GATEWAY}/catalog-service/public/search`, body,
                      { tags: { API: 'Search' } });       // ← tag แยกวัดต่อ API
check(res, { 'status is 200': (r) => r.status === 200 }); // ← นับ pass/fail
sleep(3~5);                                               // ← think time จำลองคนจริง

06 / 10 สิ่งที่ต้องช่วยกันปลดล็อก

3 ตัวบล็อก (ยืนยันจากการยิงจริงบน DEV)

ฝั่งสคริปต์เทสพร้อมแล้ว — ที่เหลือต้องอาศัยทีมพัฒนา/ระบบ

● BACKEND

1 · Search คืน 500

/public/search คืน HTTP 500 ทุก request (ผ่าน validation แล้ว แต่ logic ฝั่ง server พัง) → ต้องแก้ก่อน

● ENV

2 · Turnstile บน Booking

Cloudflare bot protection (x-turnstile-token) — บอทยิงเองไม่ได้ → ปิด/ออก bypass token บน env เทส

● INFRA

3 · ยังไม่มี UAT URL

มีแค่ DEV ซึ่ง spec ≠ prod → NFR วัดบน DEV ใช้อ้างไม่ได้ ต้องได้ origin ของ UAT (spec=prod)

เพิ่มเติม: payment ต้องชี้ sandbox/mock · seed 10,000 บัญชี ก่อนวัด · เช็ค APIM rate limit

07 / 10 สถานะความพร้อม

สคริปต์พร้อมแค่ไหน

Scenario	สถานะ	เหลืออะไร
Search	✓ payload ถูกต้อง	รันได้ทันทีเมื่อ endpoint ถูกแก้ (branch code จริง + date format ผ่าน validation แล้ว)
Booking	โครงพร้อม	เติม car/price/addon จาก search response + ปลด Turnstile
Payment	โครงพร้อม	เติม fields ของ initiate + ชี้ sandbox (chain จาก booking-token แล้ว)
Harness k6+report+threshold	✓ ทดสอบแล้วใช้ได้	พิสูจน์กับ `branches/list` = ผ่าน 100%

08 / 10 ผลลัพธ์ที่ส่งมอบ

หน้าตา HTML Report ที่ได้

ทุกรอบที่ยิง ออกเป็นไฟล์ HTML เปิดในเบราว์เซอร์ — เห็นทันทีว่าผ่าน/ไม่ผ่านเกณฑ์ NFR (ตัวอย่างด้านล่างเป็นตัวอย่างค่าจำลอง)

results/search-peak.html

k6 Test Report — search · peak

✓ THRESHOLDS PASSED

200

Max VUs

48,210

Requests

0.42%

Failed (เกณฑ์ <1%)

Metric	ค่า	เกณฑ์ NFR	ผล
`http_req_duration p(95)`	4,210 ms	< 5,000 ms	✓ ผ่าน
`http_req_failed`	0.42%	< 1%	✓ ผ่าน
`checks succeeded`	99.6%	—	✓ 24,100/24,200

09 / 10 เริ่มใช้งาน

ติดตั้ง & รันยังไง

1 · ติดตั้ง k6

# macOS
brew install k6

# Windows
choco install k6

ติดตั้งครั้งเดียว ไม่ต้องลง dependency อื่น

2 · รันตามโหมด

# เช็ค script ก่อน (1 VU)
k6 run -e MODE=smoke \
  -e BASE_ORIGIN=https://<env> \
  scenarios/search.js

# วัดจริง: normal=100 / peak=200
k6 run -e MODE=peak ... search.js

สลับ MODE = smoke / normal / peak — VU + เกณฑ์เปลี่ยนตาม NFR อัตโนมัติ ไม่ต้องแก้โค้ด
ผลลัพธ์ออกเป็น HTML report ที่โฟลเดอร์ results/ (หน้าตาตามสไลด์ก่อนหน้า)

10 / 10 ขั้นต่อไป

พอปลดล็อก ก็ยิงได้เลย

ทีม Dev / Infra ช่วย

แก้ search 500 บน env เทส
ปิด/bypass Turnstile
ส่ง UAT origin URL (spec=prod)
seed 10,000 บัญชี + ชี้ payment ไป sandbox

จากนั้น (ฝั่งเทส) — เปลี่ยนแค่ env

k6 run -e MODE=peak \
  -e BASE_ORIGIN=https://<uat> \
  scenarios/search.js

ไม่ต้องแก้โค้ด → ได้ HTML report เทียบเกณฑ์ NFR ทันที

ทุกไฟล์อยู่ใต้ ccr-perf-test/ · แผนเต็ม: PERFORMANCE_TEST_PLAN.md

Chic Car RentPerformance Test