ได้คำถามมาว่า ระบบรองรับ 5,000 users ได้มั้ย
แต่ตอนเทสจริงคือ login 1,000 ครั้งใน 1 ชั่วโมง
.
สัปดาห์นี้พี่กิ่งได้รับคำถามนี้มาจาก CEO ค่ะ
“ระบบเรารองรับ 5,000 users ได้มั้ย”
(product นี้เป็นระบบดูแลสุขภาพจิตให้พนักงานในองค์กร)
ฝั่งคนถามเค้าก็อยากรู้แค่นั้นจริงๆ
ได้ หรือ ไม่ได้
.
ถ้าไม่ได้คิดอะไร ก็คงไปเขียน script ยิงคนเข้าระบบพร้อมกัน 5,000 คน
แล้วดูว่ามันยังรับไหวมั้ย
แต่ถามว่าในการใช้งานจริงมันจะเป็นแบบนี้มั้ย
ก็อาจจะยัง
เพราะคน 5,000 คน คงไม่ได้กดเข้ามาพร้อมกันอยู่แล้วค่ะ
.
พี่กิ่งเลยลองถามกลับไปก่อนว่า
คนจะเข้ามาใช้ตอนไหน แล้วจะเข้ามาทำอะไรบ้าง
จนพอเห็นภาพกันว่า เคสที่จะมีคนเข้ามาเยอะๆ ได้
คงเป็น HR ประกาศให้ทุกคนเข้าไปทำแบบประเมิน
แล้วพนักงานก็จะทยอยกันเข้ามา แล้วก็คงค่อยๆ เพิ่มขึ้น
พอทำเสร็จ ก็คงค่อยๆ ออกไปกัน การใช้งานก็คงค่อยๆ ลดลง
ซึ่งในภาษา performance test มันคือ workload modeling
ที่มีการ ramp up/ramp down ค่ะ
.
คุยกันต่อไปเรื่อยๆ จากเลข 5,000 ตัวเดียว เราก็เริ่มแตกออกมาได้ว่า
👉 Login 1,000 ครั้งใน 1 ชั่วโมง
👉 เช็คอิน 2 แบบ อย่างละ 800 ครั้ง ใน 1 ชั่วโมง
👉 คุยกับ Chatbot 100 คน คนละ 10 ข้อความ ใน 1 ชั่วโมง
👉 ทำแบบประเมิน 200 คน ใน 1 ชั่วโมง
👉 เปิดดู Dashboard สำหรับ HR 5 คน ในชั่วโมงเดียวกัน
.
💡 คำว่า “5,000 users” มันยังมีอีกหลายอย่างซ่อนอยู่
แต่ละฟีเจอร์ถูกใช้ไม่เท่ากัน
บางอัน 1,000 ครั้ง
บางอันแค่ 5 คน
ถ้าไม่ถามกลับ ก็จะไม่ได้เห็นเลขพวกนี้เลยค่ะ
.
💬 สำหรับพี่กิ่ง การทำ performance test ไม่ได้มีแค่การเขียน script และ ยิงโหลด
สิ่งที่สำคัญกว่านั้นคือการเข้าไปดูก่อนว่า business scenario จริงเป็นยังไง
คนจะเข้ามาใช้แบบไหน แบบไหนเรียกว่าผ่าน แบบไหนเรียกว่าไม่ผ่าน มีเงื่อนไขยังไงบ้าง
แล้วค่อยเอาข้อมูลที่ได้มาแปลงเป็นตัวเลขในเชิง technical อีกที
👉 มีคนใช้งานพร้อมกันกี่คน (CCU)
👉 ระบบต้องรองรับงานได้กี่ครั้งต่อวินาที (TPS)
👉 ต้องรองรับการใช้งานต่อเนื่องนานแค่ไหน (duration)
👉 รอได้ไม่เกินกี่วินาที (expected response time)
.
พอได้ผลลัพธ์ออกมา ก็ต้องแปลกลับไปเป็นภาษาที่คนถามเข้าใจด้วย
ไม่ใช่โยนตัวเลขไปให้เค้าแปลเอง
เช่น แทนที่จะบอกว่า p95 = 2 วินาที
เราก็บอกว่า “95 จาก 100 ครั้งที่กด login จะใช้เวลาไม่เกิน 2 วินาที”
.
ถ้าเราข้ามขั้นตอนการทำความเข้าใจตรงนี้
แล้วโดดเข้าไปยิงโหลดที่ตัวเลข 5,000 เลย
สิ่งที่ได้อาจจะกลายเป็น stress test (การเช็คว่าระบบรับได้มากสุดแค่ไหนก่อนจะแตก)
ซึ่งมันไม่ได้ตอบคำถามที่คนถามอยากรู้จริงๆ
และถ้าเป็นแบบนั้น ถึงจะได้ตัวเลขออกมาแล้ว ก็เอาไปใช้ทำอะไรต่อไม่ได้อยู่ดี
.
สุดท้ายมันก็กลับมาที่เรื่องเดิมอีกแล้วค่ะ
ไม่ว่าเราจะเทสแบบไหน ก็ต้องเข้าใจก่อนว่ากำลังจะทำอะไร และ ทำไปเพื่ออะไร
ก่อนจะโดดเข้าไปลงมือทำเลย
ซึ่งการถามแบบนี้ มันเป็นสิ่งที่ QA ทำกับ requirement บ่อยๆ อยู่แล้ว
.
📌 #ลองง่ายๆก่อนไม่ต้องรอพร้อม
ครั้งหน้าที่มีคนถามว่า “ระบบรองรับได้กี่คน” หรือ “โหลดเร็วพอมั้ย”
ยังไม่ต้องรีบเขียน performance test
แต่ให้ลองถาม 3 ข้อนี้กลับก่อนค่ะ
👉 ใครจะเข้ามาใช้ และเข้ามาทำอะไรบ้าง
👉 เข้ามาพร้อมกันทีเดียว หรือทยอยเข้ามา ภายในระยะเวลากี่นาที
👉 “เร็วพอ” คือ รอได้ไม่เกินกี่วินาที
ยังไม่ต้องเปิด tool หรือเขียน script อะไรเลย
แค่ 3 คำถามนี้ ก็ช่วยให้ได้ส่วนสำคัญที่สุดมาแล้วค่ะ
.
การเขียน script ยิงโหลด ใครฝึกก็ทำได้ค่ะ
แต่การรู้ว่าจะยิงไปเพื่อตอบคำถามอะไร
คือสิ่งที่ทำให้ตัวเลขนั้น มีความหมาย
และทำให้งานชิ้นนั้นของเรามีคุณค่าจริงๆ ค่ะ