บทความ 05

Performance Testing: จากคำถามธุรกิจถึงผลที่ใช้ตัดสินใจได้

วางเป้าหมาย workload, scenario, test data, environment, threshold และ observability ให้ผลทดสอบบอกได้ว่าควรแก้อะไรก่อน

16 นาที Tech Lead, Developer, QA และ Platform Team 2026-07-17

Infographic ภาพรวม

Threshold

Load

250 RPS

p95

780 ms

Errors

0.6%

สถานการณ์ตัวอย่าง

ลองเริ่มจากเหตุการณ์ที่คนทำงานพบจริง

ทดสอบได้ 1,000 users แต่ตอบไม่ได้ว่าระบบพร้อมหรือยัง

ตัวเลขผู้ใช้สูงไม่ได้มีความหมาย หาก test ไม่เหมือนพฤติกรรมจริง ไม่มี pass/fail criteria และไม่ได้เก็บ metric ของ API, database และ infrastructure ผลที่ดีต้องตอบคำถามธุรกิจ เช่น flow จองยังทำงานทันหรือไม่ในช่วงเปิดจอง

ถ้าคุณไม่ได้ทำงานสายเทคนิค ให้เริ่มจากส่วนนี้

Performance Testing: จากคำถามธุรกิจถึงผลที่ใช้ตัดสินใจได้

เริ่มจากเหตุผลที่ทดสอบ: ยืนยัน traffic ปกติ หา limit หรือเตรียม campaign

กำหนด threshold ก่อนรัน ไม่เลือกเกณฑ์หลังเห็นผล

เก็บ application และ infrastructure metric ใน timeline เดียวกับผล load

ภาพขยายความแบบเคลื่อนไหว

ดูความสัมพันธ์ของแต่ละขั้น ก่อนลงรายละเอียด

เลือกแต่ละขั้นเพื่อดูว่าเกิดอะไรขึ้น ต้องตรวจข้อมูลใด และผลจากขั้นหนึ่งส่งต่อไปยังขั้นถัดไปอย่างไร

ขั้น 01 / 04

01 / ตั้งคำถาม

Test type ต้องตามสิ่งที่ต้องการเรียนรู้

Smoke test ตรวจ script, average-load test ยืนยันการใช้งานปกติ, stress test ดูช่วงเกินปกติ, spike test ดูการเพิ่มฉับพลัน, soak test หาปัญหาที่สะสม และ breakpoint test หาเพดาน ไม่ควรใช้ผลจาก test ชนิดหนึ่งตอบทุกคำถาม

ประเด็นที่ต้องตรวจให้เห็นหลักฐาน

Flow ใดห้ามล้ม
Traffic ปกติและ peak เท่าไร
ต้องการยืนยันหรือค้นหา limit
ข้อมูลทดสอบกระทบ production หรือไม่

รายละเอียดเชิงลึก

ค่อย ๆ ดูทีละส่วนว่าเกิดอะไรขึ้น และควรเตรียมอย่างไร

เราเริ่มจากผลที่คนใช้งานหรือธุรกิจจะพบ แล้วจึงอธิบายว่าทีมเทคนิคต้องตรวจอะไร มีตัวอย่างแบบไหน และจุดใดไม่ควรปล่อยให้เดาเอง

01 / ตั้งคำถาม

Test type ต้องตามสิ่งที่ต้องการเรียนรู้

Flow ใดห้ามล้ม
Traffic ปกติและ peak เท่าไร
ต้องการยืนยันหรือค้นหา limit
ข้อมูลทดสอบกระทบ production หรือไม่

02 / สร้าง Scenario

จำลองสัดส่วนพฤติกรรม ไม่ใช่ยิง endpoint เดียว

ระบบจริงมีทั้ง login, browse, search, save, report และ background API ควรสร้าง scenario ตามสัดส่วนที่พบจริง พร้อม think time และ test data ที่ไม่ทำให้ cache หรือ database มีพฤติกรรมผิดจาก production

ถ้าคุณเป็นคนออกแบบหรือดูแลระบบ

แยก tag ตาม flow และ endpoint เพื่ออ่าน p95/error rate รายกลุ่ม ไม่ใช้ค่าเฉลี่ยรวมกลบ transaction ที่สำคัญ

03 / Pass หรือ Fail

Threshold ต้องผูกกับประสบการณ์และความเสี่ยง

กำหนด response time percentile, error rate และ transaction success ของ flow สำคัญก่อนเริ่ม test ค่า p95 ช่วยให้เห็นประสบการณ์ของผู้ใช้ส่วนใหญ่โดยไม่ถูก request ที่เร็วมากกลบ แต่ target ต้องมาจากบริบทธุรกิจ ไม่ควรคัดลอกตัวเลขตัวอย่างไปใช้ทุกระบบ

ตัวอย่าง Threshold

ใช้เป็นรูปแบบ ไม่ใช่ค่ามาตรฐานสากล

Flow ค้นหา: p95 ต่ำกว่า 800ms, error ต่ำกว่า 1%; Flow ยืนยันคำสั่งซื้อ: success มากกว่า 99.5% และห้ามเกิดข้อมูลซ้ำ

04 / อ่านผล

กราฟ Load ต้องวางข้าง Metric ของทุกชั้น

เมื่อ latency เพิ่ม ให้เทียบเวลานั้นกับ CPU, memory, event loop, connection pool, slow query, lock, cache hit, queue depth และ external API หากมีเพียงผลจากเครื่องยิง load จะรู้ว่าช้า แต่ไม่รู้ว่าต้องแก้ตรงไหน

ก่อนนำไปใช้ ลองตรวจทีละข้อนี้

กำหนดเหตุผลที่ทดสอบ

สร้าง workload จากข้อมูล

เตรียม test data

ตั้ง threshold ล่วงหน้า

เก็บ metric ทุกชั้น

เขียนข้อสรุปพร้อมข้อจำกัด

แหล่งอ้างอิง

Grafana k6: API Load Testing Grafana k6: Thresholds

ตัวอย่างในบทความช่วยให้เริ่มคุยกันได้ แต่ระบบแต่ละแห่งมีจำนวนผู้ใช้ ข้อมูล และข้อจำกัดไม่เหมือนกัน จึงควรตรวจจากระบบจริงอีกครั้งก่อนตัดสินใจ

ผู้ตรวจทาน: SIS Engineering
ตรวจทานล่าสุด: 2026-07-17

อ่านแล้วอยากรู้ว่าระบบของคุณควรเริ่มตรวจตรงไหน?

ลองใช้เครื่องมือประเมินเบื้องต้น หรือเล่าให้ทีม SIS ฟังว่าระบบทำอะไร ใครใช้งาน และตอนนี้กังวลเรื่องใด เราจะช่วยเรียงสิ่งที่ควรตรวจให้เป็นลำดับ

ทดลองประเมินด้วยเครื่องมือ คุยกับทีม SIS

กลับไป Knowledge Base