สิ่งที่เราทดสอบ
คำถามด้านประสิทธิภาพที่ต่างกัน ต้องออกแบบการทดสอบต่างกัน งานหนึ่งมักผสมหลายแบบต่อไปนี้ เลือกตามเป้าหมายของคุณตอนวางแผน
Load Testing
วัดว่าระบบทำงานยังไงภายใต้สภาพปกติและ peak ที่คาดไว้ เราจำลอง concurrent users จำนวนมากตลอดช่วงเวลาที่กำหนด เดินตามสถานการณ์สมจริงที่ครอบคลุมหลาย endpoint แล้วบันทึก response time, throughput และ error rate ขณะระบบรับ load ต่อเนื่อง ตรงนี้ก็บอกได้ว่าระบบทำได้ตามเป้าประสิทธิภาพที่ระดับ traffic ที่คุณคาดว่าจะเจอจริงหรือเปล่า
Stress Testing
เพิ่ม load ทีละขั้นจนเกิน peak ที่คาดไว้ ไปจนระบบล้มหรือเริ่มไม่เสถียร เป้าหมายคือหา breaking point ว่าระบบรับได้สูงสุดแค่ไหน component ใดถึงขีดจำกัดก่อน และเกิดปัญหาในรูปแบบไหน เช่น ประสิทธิภาพค่อย ๆ ลดลง error ลามเป็นลูกโซ่ หรือระบบ crash
Endurance / Soak Testing
คง load ระดับปกติไว้ยาว ๆ อย่างน้อย 8 ชั่วโมง เพื่อหาปัญหาที่จะปรากฏเมื่อระบบทำงานไปนาน ๆ เช่น memory leak, connection pool ที่ค่อย ๆ หมด และ log ที่เขียนจนดิสก์เต็ม ปัญหาเหล่านี้อาจไม่ปรากฏในการทดสอบสั้น ๆ แต่ soak test ช่วยให้พบก่อนที่จะทำให้ production ล่ม
Spike Testing
ประเมินว่าระบบรับมือการพุ่งขึ้นของผู้ใช้แบบฉับพลันยังไง ทั้งจังหวะ flash sale, โพสต์ที่กลายเป็นไวรัล, การแจ้งเตือนที่ยิงหาลูกค้าทุกคนพร้อมกัน และที่สำคัญไม่แพ้กัน คือมันทำตัวยังไงตอนคลื่นนั้นซาลง ระบบที่รอด spike มาได้แต่ไม่เคยกลับสู่ปกติ ถือว่ายังไม่ผ่านเกณฑ์
แอปพลิเคชันที่รับมือผู้ใช้สิบคนได้สบาย อาจล้มทั้งระบบตอนเจอผู้ใช้หนึ่งหมื่นคนพร้อมกัน โดยที่โค้ดไม่ต้องมีอะไรผิดเลย connection pool ที่ตั้งขนาดไว้เท่ากับ traffic ตอน develop, query ที่เคยเร็วตอนตารางยังเล็ก หรือ cache ที่ไม่เคยต้อง evict ข้อมูล ปัญหาเหล่านี้อาจไม่ปรากฏในการทดสอบ functional และการใช้งานประจำวัน จนถึงวันเปิดตัว แคมเปญการตลาด หรือเช้าวันจันทร์ที่มีผู้ใช้จำนวนมากเข้ามาพร้อมกัน ผลคือธุรกรรมที่ทำไม่สำเร็จ session ที่ถูกทิ้งกลางคัน และผู้ใช้ที่ไม่กลับมาอีก response time ที่ช้าก็สร้างความเสียหายค่อยเป็นค่อยไป แม้ระบบยังทำงานอยู่ แต่ทุกครั้งที่ผู้ใช้ต้องรอ ความเชื่อมั่นก็ลดลง
วิธีการทำงานของเรา
load testing กับ stress testing ตอบคำถามที่การทดสอบ functional ตอบไม่ได้ ระบบนี้รองรับ concurrent users ได้จริงกี่คน ประสิทธิภาพเริ่มตกที่ตรงไหน อะไรพังก่อนเมื่อความต้องการเกินกำลัง และระบบกลับมาทำงานตามปกติได้หรือไม่หลังจากนั้น เราจำลองพฤติกรรมผู้ใช้จริงในสเกลใหญ่ วัดว่าระบบตอบสนองยังไง แล้วสรุปเป็น finding ที่ทีมวิศวกรนำไปแก้ได้ โดยระบุ bottleneck และคำแนะนำให้ชัดเจน ทุกงานเดินผ่านเฟสเดียวกันเสมอ
วางแผน
เรากำหนดเป้าหมายร่วมกับคุณ ว่าจะทดสอบแบบไหน เกณฑ์ที่ถือว่าผ่านคืออะไร (response time เป้าหมาย, error rate ที่ยอมรับได้, จำนวน concurrent users ที่ต้องรองรับ) และ user journey ไหนสำคัญที่สุด
จากนั้นก็สร้างสถานการณ์และโปรไฟล์ load ที่สะท้อนพฤติกรรมผู้ใช้จริง ทั้งสัดส่วนการเลือกดู ค้นหา และทำธุรกรรม
ดำเนินการ
เรารันการทดสอบที่ตกลงกันด้วยเครื่องมือ load testing มาตรฐานอุตสาหกรรม สร้าง load ใส่ environment เป้าหมาย พร้อมเฝ้าดูพฤติกรรมระบบตลอดทาง
ตารางเวลาและการประสานงานทำร่วมกับทีมคุณ เพื่อไม่ให้ stress test ที่ตั้งใจทำ ถูกเข้าใจผิดว่าเป็น incident จริง
วิเคราะห์
เราแปลง metric ดิบเป็น finding โดยดูว่า bottleneck อยู่ตรงไหน response time เปลี่ยนอย่างไรเมื่อ load เพิ่มขึ้น ทรัพยากรใด (CPU, memory, database connection, network) ถึงขีดจำกัดก่อน และระบบเริ่มทำไม่ได้ตามเป้าที่ load ระดับใด
ทุก finding มาพร้อมคำแนะนำ
Retest
หลังทีมคุณแก้เสร็จ เรารันการทดสอบที่เกี่ยวข้องซ้ำภายใต้เงื่อนไขเดิม เพื่อยืนยันว่าการปรับปรุงเกิดผลจริงและวัดได้
สิ่งที่คุณจะได้รับ
รายงานทุกฉบับมีอย่างน้อยสิ่งเหล่านี้
Executive summary
ภาพ capacity และความเสี่ยงในภาษาธุรกิจ เหมาะให้ผู้บริหารอ่าน ระบบรับได้แค่ไหนวันนี้ และเพดานอยู่ตรงไหน
รายงานประสิทธิภาพแบบละเอียด
throughput, response time ที่แต่ละระดับ load, error rate และ resource utilisation ตลอดรอบการทดสอบ พร้อมบันทึกการออกแบบการทดสอบไว้ให้ผลลัพธ์ทำซ้ำได้
Bottleneck และ breaking point
ชิ้นส่วนที่จำกัดประสิทธิภาพจริง ๆ ระดับ load ที่ทำให้ระบบเริ่มไม่เสถียร และลักษณะอาการเมื่อระบบล้ม
คำแนะนำการ optimise
แนวทางปรับปรุงที่ทำได้จริงทั้งฝั่ง hardware, software และ configuration จุดไหนควร scale out จุดไหน tune แล้วคุ้มกว่า และแก้ตรงไหนได้ capacity มากที่สุดด้วยแรงน้อยที่สุด
การออกแบบการทดสอบ การดำเนินการ การวิเคราะห์ประสิทธิภาพ และคำแนะนำการ optimise รวมอยู่ในงานทั้งหมด
ความเชี่ยวชาญของทีม
งานทดสอบประสิทธิภาพที่ Incognito Lab รันโดยทีมสายวิศวกรรมชุดเดียวกับที่ทำงานประเมินความปลอดภัยของเรา ใช้วิธีการที่ทำซ้ำได้ ให้ผลลัพธ์ที่ตรวจสอบได้ และ finding ที่วิศวกรของคุณเอาไปลงมือต่อได้ ดูใบรับรองที่ทีมถือ
เมื่อไหร่ควรทำ
มีสามสถานการณ์ที่คุ้มจะทดสอบประสิทธิภาพเสมอ
ก่อนเปิดตัวหรือแคมเปญใหญ่
ตอนที่คุณรู้ว่า traffic กำลังมา และอยากมั่นใจว่าระบบจะรับไหว โดยยังมีเวลาเหลือพอจะแก้สิ่งที่ไม่ไหว
หลังเปลี่ยนสถาปัตยกรรมครั้งใหญ่
ย้ายระบบ เปลี่ยน database ใหม่ หรือ re-platform บริการ ผลทดสอบเก่าใช้ไม่ได้แล้ว และสมมติฐานที่ยกมาจากสถาปัตยกรรมเดิมต้องตรวจสอบใหม่
เพื่อวาง baseline ของ capacity
พอรู้เพดานปัจจุบัน การตัดสินใจเรื่อง scaling และงบ infrastructure ก็กลายเป็นทางเลือกที่มีข้อมูล และได้จุดอ้างอิงไว้วัดทุกการเปลี่ยนแปลงในอนาคต
ตรวจทานล่าสุด: 14 Oct 2026
LOAD TEST / STRESS TEST
เรากำหนดเป้าหมายร่วมกับคุณ ทดสอบแบบไหนบ้าง คำว่า "ดี" หน้าตาเป็นยังไง และ user journey ไหนสำคัญที่สุด
คำถามที่พบบ่อย
Load Test ต่างจาก Stress Test อย่างไร?
Load Test วัดการทำงานภายใต้จำนวนผู้ใช้ที่คาดว่าจะเกิดขึ้น ส่วน Stress Test เพิ่มภาระเกินระดับนั้นเพื่อหาจุดที่ประสิทธิภาพตกหรือระบบเริ่มไม่เสถียร
ต้องเตรียมอะไรบ้างก่อนทดสอบ?
เตรียม user journey ที่สำคัญ จำนวนผู้ใช้เป้าหมาย environment ที่อนุญาตให้ทดสอบ เป้าหมายด้าน response time และผู้ประสานงานด้านระบบ
จะได้รับผลลัพธ์อะไร?
รายงาน throughput, response time, error rate, bottleneck และคำแนะนำเรื่อง capacity ตามขอบเขตและสถานการณ์ทดสอบที่ตกลงกัน
บทความจากทีมของเรา
บอกเราว่าระบบต้องรับมือกับอะไร
การพูดคุยวางแผนใช้เวลาไม่นาน บอกเราว่าระบบทำอะไร และคุณคาดหวังให้มันทนอะไรได้บ้าง แล้วเราจะออกแบบการทดสอบรอบตัวมันให้
