Performance Testing มีกี่แบบ?
รู้จัก 6 ประเภทที่ใช้จริงในงาน
หลายทีมเรียกทุกอย่างว่า "Performance Test" แต่ทำแค่ Load Test เพียงอย่างเดียว แล้วก็แปลกใจเมื่อระบบล่มตอน Flash Sale หรือ Memory พุ่งขึ้นเรื่อยๆ หลัง Deploy ไปไม่กี่ชั่วโมง บทความนี้อธิบาย 6 ประเภทให้เห็นว่าแต่ละแบบตอบคำถามต่างกันอย่างไร และควรใช้เมื่อไหร่ในวงจรการพัฒนา
ลองจินตนาการว่าระบบ E-commerce ผ่าน QA ครบทุก Test Case ฟีเจอร์ทุกอย่างทำงานถูกต้อง แต่พอ Flash Sale เริ่มต้น มี User เข้ามา 5,000 คนในเวลาไม่กี่นาที — ระบบค้างทันที นี่คือปัญหาที่ Functional Test จับไม่ได้ แต่ Performance Testing ถูกสร้างมาเพื่อป้องกันโดยเฉพาะ
Performance Testing ไม่ได้แค่วัด Response Time แต่ตอบคำถามที่สำคัญกว่านั้น: ระบบรองรับ User กี่คนพร้อมกันได้? มีจุดไหนที่ทำให้ทุกอย่างช้าลง? ถ้าปล่อยให้รันไป 24 ชั่วโมง Memory จะพุ่งไหม? ถ้าเพิ่ม Server เป็น 2 เท่า ความสามารถจะเพิ่มขึ้น 2 เท่าด้วยหรือเปล่า?
ระบบรองรับ User กี่คนพร้อมกัน? ช้าลงเมื่อ Load เพิ่มขึ้นหรือไม่? ล่มเมื่อไหร่?
ปุ่ม Submit ทำงานถูกต้องไหม? Form Validation ผ่านหรือเปล่า? (นั่นคือ Functional Test)
6 ประเภทหลัก แต่ละแบบตอบคำถามคนละข้อ
ทดสอบระบบภายใต้ Workload ที่คาดหวัง (Expected Load) เพื่อตรวจสอบว่าระบบตอบสนองได้ตามมาตรฐานที่กำหนดหรือไม่
Objective: ยืนยันว่าระบบ "ทำงานได้ตามปกติ" ภายใต้ Traffic จริง
ตัวอย่าง: ระบบ E-commerce รองรับ User 1,000 คนพร้อมกัน Response Time < 2s
เพิ่ม Load เกินกว่าที่ระบบออกแบบมารองรับ เพื่อหา Breaking Point และดูพฤติกรรมของระบบเมื่อล้มเหลว
Objective: รู้จุดแตกของระบบ และระบบ Recover ได้ดีแค่ไหน
ตัวอย่าง: เพิ่ม User จาก 1,000 ขึ้นไปเรื่อยๆ จนระบบ Error หรือล่ม
จำลอง Traffic ที่เพิ่มขึ้นอย่างรวดเร็วและฉับพลัน แล้วลดลงทันที เช่น Flash Sale, Breaking News, Viral Event
Objective: ระบบรับมือกับ Sudden Surge ได้หรือไม่ Auto-scaling ทำงานทันไหม
ตัวอย่าง: User เพิ่มจาก 100 เป็น 10,000 ภายใน 2 นาที
รัน Load ต่อเนื่องเป็นเวลานาน (หลายชั่วโมง ถึงหลายวัน) เพื่อหา Memory Leak, Resource Exhaustion และ Degradation ที่ค่อยๆ สะสม
Objective: ระบบยังทำงานได้ดีหลังจาก Production ผ่านไป 24–72 ชั่วโมงหรือไม่
ตัวอย่าง: รัน Load 500 Concurrent Users นาน 8 ชั่วโมง
ทดสอบระบบด้วย ปริมาณข้อมูลขนาดใหญ่ เช่น Database ที่มี Record หลาย 100 ล้านแถว เพื่อดูว่าประสิทธิภาพยังอยู่ในระดับที่ยอมรับได้
Objective: ระบบ Query ได้เร็วพอเมื่อ Database โตขึ้นหลายเท่า
ตัวอย่าง: ทดสอบ Report ที่ต้องประมวลผล Transaction 500 ล้านรายการ
ทดสอบว่าระบบ Scale ได้ดีแค่ไหน ทั้ง Vertical Scaling (เพิ่ม Resource) และ Horizontal Scaling (เพิ่มจำนวน Instance)
Objective: เมื่อเพิ่ม Server 2 เท่า Throughput เพิ่มขึ้น 2 เท่าหรือไม่
ตัวอย่าง: ทดสอบ k8s Horizontal Pod Autoscaling ว่า Scale ได้ทันความต้องการ
เปรียบเทียบ 6 ประเภท
| ประเภท | Load Level | Duration | หา | ความถี่ที่ใช้ |
|---|---|---|---|---|
| ⚖️ Load Test | Expected | 30 min – 2 hr | Performance ปกติ | ทุก Sprint |
| 💥 Stress Test | Beyond Max | 1 – 4 hr | Breaking Point | รายเดือน |
| 📈 Spike Test | Sudden Burst | 15 – 60 min | Recovery Time | ก่อน Event ใหญ่ |
| ⏳ Soak Test | Normal | 8 – 72 hr | Memory Leak | รายไตรมาส |
| 🗄️ Volume Test | High Data | 1 – 8 hr | Data Bottleneck | ก่อน Go-live |
| 📐 Scalability Test | Incremental | 2 – 6 hr | Scale Efficiency | เมื่อเปลี่ยน Arch |
ตัวอย่างโค้ด — k6 Load Test
import http from 'k6/http';
import { check, sleep } from 'k6';
// ── Options: กำหนด Load Profile ──────────────────────────────
export const options = {
stages: [
{ duration: '2m', target: 100 }, // Ramp-up
{ duration: '5m', target: 1000 }, // Peak Load
{ duration: '2m', target: 0 }, // Ramp-down
],
thresholds: {
'http_req_duration': ['p(95)<2000'], // p95 < 2s
'http_req_failed': ['rate<0.01'], // Error rate < 1%
},
};
// ── Virtual User Script ───────────────────────────────────────
export default function main() {
const res = http.get('https://api.example.com/products');
check(res, {
'status is 200': (r) => r.status === 200,
'response time < 2s': (r) => r.timings.duration < 2000,
'body not empty': (r) => r.body.length > 0,
});
sleep(1); // Think time
}Performance Testing สามารถทำบน Environment ขนาดไหนก็ได้ ถ้ารู้ Ratio เช่น Test Env เป็น 1:4 ของ Production หมายความว่า Throughput จริงประมาณ 4× ที่วัดได้ สิ่งที่อันตรายคือ Ratio ไม่สม่ำเสมอ เช่น App Server เล็กกว่า 4 เท่า แต่ DB ขนาดเต็ม แบบนี้จะทำให้ Bottleneck ใน Test ไม่ตรงกับ Production จริง
ทำ Load Test ก่อนเสมอ เพื่อสร้าง Baseline → จากนั้น Stress Test → แล้วจึงทำ Soak Test เมื่อมั่นใจว่าระบบผ่าน Normal Load แล้ว