การทดสอบแบบ Soak Test ในซอฟต์แวร์: ความหมายและตัวอย่าง
โธมัส แฮมิลตัน
⚡ สรุปอย่างชาญฉลาด
การทดสอบแบบ Soak Testing คือการใช้ภาระการทำงานที่สมจริงและต่อเนื่องกับแอปพลิเคชันเป็นระยะเวลานาน เพื่อเปิดเผยปัญหาที่เกิดขึ้นเมื่อเวลาผ่านไป ปัญหาที่การทดสอบนี้ออกแบบมาเพื่อตรวจจับ ได้แก่ การรั่วไหลของหน่วยความจำ การเสื่อมสภาพของการเชื่อมต่อ และการลดลงของประสิทธิภาพอย่างช้าๆ
Soak Testing คืออะไร?
การทดสอบการแช่ เป็นการทดสอบที่ไม่ใช้งานประเภทหนึ่งซึ่งใช้ในการวัดประสิทธิภาพของแอปพลิเคชันซอฟต์แวร์ภายใต้โหลดปริมาณมากเป็นระยะเวลานาน เป้าหมายของการทดสอบ Soak คือเพื่อให้แน่ใจว่าแอปพลิเคชันซอฟต์แวร์รองรับการใช้งานในปริมาณมากหรือไม่ และเพื่อตรวจสอบว่าจะเกิดอะไรขึ้นนอกเหนือความคาดหมายของการออกแบบ
ภาพด้านล่างแสดงรอบการทดสอบที่แสดงการทดสอบการแช่ในขั้นตอนใด (ประเภทของการทดสอบประสิทธิภาพ) ดำเนินการบนแอปพลิเคชัน
ในการทดสอบประเภทนี้ สิ่งที่ได้รับการตรวจสอบโดยทั่วไปคือการใช้หน่วยความจำโดยแอปพลิเคชันในระบบ กำลังทดสอบในระดับระบบ เพื่อค้นหาว่าระบบจะทนทานต่อการใช้งานในปริมาณที่สูงมากหรือไม่ และเพื่อดูว่าจะเกิดอะไรขึ้นนอกเหนือความคาดหมายในการออกแบบ
ทำไมต้อง Soak Test?
ระบบอาจทำงานได้ตามปกติเมื่อใช้เป็นเวลา 2 ชั่วโมง แต่เมื่อใช้งานระบบเดียวกันอย่างต่อเนื่องเป็นเวลา 10 ชั่วโมงหรือมากกว่านั้น ระบบอาจล้มเหลวหรือทำงานผิดปกติ/สุ่ม/อาจหยุดทำงาน การทดสอบ Soak Testing จะดำเนินการเพื่อคาดการณ์ความล้มเหลวดังกล่าว
ควรทำ Soak Test เมื่อใด?
การทดสอบแบบแช่ควรดำเนินการในสถานการณ์ต่อไปนี้: –
- ก่อนที่จะนำบิลด์ไปใช้งานกับไคลเอนต์ กล่าวคือ ก่อนที่จะเผยแพร่แอปพลิเคชันใดๆ บนแพลตฟอร์มเฉพาะ จะต้องผ่านการทดสอบโหลดชุดหนึ่งที่ประสบความสำเร็จในระดับปริมาณการรับส่งข้อมูลที่สูงหรือเทียบเท่า หลังจากนั้น ทำการทดสอบการแช่- ช่วยให้เรากำหนดวิธีเรียกใช้แอปพลิเคชันใด ๆ เป็นระยะเวลานาน หากพบปัญหาเช่นหน่วยความจำรั่ว/หน่วยความจำเสียหายในช่วงเวลาดังกล่าว เช่น เมื่อเปิด Soak ก็ควรรายงานทันที
- เวลาที่ดีที่สุดในการทดสอบการแช่คือช่วงสุดสัปดาห์ เนื่องจากแอปพลิเคชันจะต้องอยู่ในสถานะทำงานเป็นเวลามากกว่าหนึ่งวันหรือกลางคืน ขึ้นอยู่กับข้อจำกัดของสถานการณ์การทดสอบโดยสิ้นเชิง การทดสอบการแช่เป็นหนึ่งในข้อกำหนดการปฏิบัติตามข้อกำหนดที่สำคัญที่สุดซึ่งทุกบริษัทจำเป็นต้องปฏิบัติตามอย่างเคร่งครัด
กลยุทธ์การทดสอบการแช่
Long Session Soak Testing เป็นกลยุทธ์ที่ระบบอยู่ภายใต้โหลดเป็นเวลานาน
ตัวอย่างง่ายๆ คือ เมื่อผู้ใช้ล็อกอินเข้าสู่ระบบหลายชั่วโมงเพื่อดำเนินการธุรกรรมทางธุรกิจต่างๆ ด้วยวิธีนี้ ข้อมูลจำนวนมากจึงถูกสร้างขึ้น อาจมีภาระงานจำนวนมากบนเซิร์ฟเวอร์ระบบ/ฐานข้อมูล ซึ่งอาจส่งผลให้เซิร์ฟเวอร์ระบบ/ฐานข้อมูลหยุดชะงักหรือล่มได้
ภายใต้การทดสอบแช่เซสชันระยะยาว กิจกรรมหลายวัน (เช่น 30 วัน) จะดำเนินการในกรอบเวลาที่จำกัด (เช่น 2 วัน) จำนวนธุรกรรมในกรอบเวลาที่จำกัดนี้ควรตรงกันหรือเกินกว่ามูลค่าธุรกรรมหลายวัน ควรเน้นที่จำนวนธุรกรรมที่ประมวลผล ส่วนที่สำคัญที่สุดของ Soak Testing คือการตรวจสอบหน่วยความจำที่มีอยู่ใน CPU และจำนวนหน่วยความจำที่จะใช้งาน เราจำเป็นต้องบันทึกการใช้หน่วยความจำเมื่อเริ่มต้นและสิ้นสุดการทดสอบการแช่ หากจำเป็นให้ใช้หน่วยความจำของสิ่งอำนวยความสะดวกต่างๆ เช่น Java Virtual Machines ก็มีความสำคัญและจำเป็นต้องได้รับการตรวจสอบเช่นกัน
ด้านล่างนี้คือการตรวจสอบเพิ่มเติมบางประการที่ผู้ใช้/ผู้ทดสอบจำเป็นต้องทำก่อนที่จะเริ่มการทดสอบ Soak:
ก) ตรวจสอบการใช้ทรัพยากรฐานข้อมูล
b) ตรวจสอบการใช้ทรัพยากรเซิร์ฟเวอร์ (ยกเว้นการใช้งาน CPU)
c) การทดสอบ Soak ควรรันโดยผู้ใช้เห็นพ้องต้องกันตามความเป็นจริง
ลักษณะของการทดสอบการแช่
วิธีทดสอบแบบแช่มาตรฐานควรมีลักษณะดังต่อไปนี้: –
- ระยะเวลาของ Soak Test ส่วนใหญ่มักจะถูกกำหนดตามเวลาที่มีอยู่
- แอปพลิเคชันใด ๆ จะต้องทำงานโดยไม่มีการหยุดชะงักหากต้องใช้เวลาขยายออกไป
- ควรครอบคลุมสถานการณ์ทั้งหมดที่ผู้มีส่วนได้ส่วนเสียตกลงกัน
- โดยส่วนใหญ่ ทุกระบบจะมีช่วงเวลาในการบำรุงรักษาอย่างสม่ำเสมอ และเวลาระหว่างช่วงดังกล่าวจะเป็นตัวขับเคลื่อนสำคัญในการกำหนดขอบเขตของ Soak Test
ตัวอย่างการทดสอบการแช่
- ในกรณีโดเมนธนาคารเมื่อมีข้อมูลจากผู้ขายจำนวนมาก ผู้ทดสอบจะทำให้ระบบโหลดอย่างต่อเนื่องเป็นเวลา 70 ชั่วโมงถึง 150 ชั่วโมง เพื่อตรวจสอบว่าแอปพลิเคชันทำงานอย่างไรในช่วงโหลดนี้
- สมมติว่ามีการเข้าสู่ระบบ 33,000 ครั้ง ซึ่งหมายถึงกิจกรรมที่กินเวลาเจ็ดวันครึ่ง ในกรณีนี้ การทดสอบ Soak Test เป็นเวลา 60-70 ชั่วโมงสามารถเริ่มได้ภายในเย็นวันศุกร์ เวลาประมาณ 6 น. ซึ่งสามารถทำได้เสร็จสิ้นภายใน Monday เช้าเวลา 6 น. เฉพาะการทดสอบดังกล่าวเท่านั้นจึงจะสามารถสังเกตการเสื่อมประสิทธิภาพภายใต้สภาวะควบคุมได้
- ในกรณีของวิดีโอเกม โทรศัพท์มือถือ แอปพลิเคชัน ฯลฯ เกี่ยวข้องกับการออกจากเกมหรือแอปพลิเคชันในสถานะการทำงานเป็นเวลานาน ในโหมดการทำงานต่างๆ เช่น การทำงานเฉยๆ หยุดชั่วคราวที่หน้าจอชื่อเรื่อง และอื่นๆ เพื่อดูว่าแอปพลิเคชันนั้นสามารถรองรับโหลดที่คาดว่าจะเกิดขึ้นต่อเนื่องกันได้หรือไม่
ปัญหาทั่วไปที่พบในระหว่างการทดสอบ Soak
- การจัดสรรหน่วยความจำ (หน่วยความจำรั่วไหลซึ่งท้ายที่สุดจะส่งผลให้เกิดวิกฤตหน่วยความจำหรือข้อผิดพลาดในการปัดเศษที่ปรากฏเมื่อเวลาผ่านไปเท่านั้น)
- การใช้ทรัพยากรฐานข้อมูล (ความล้มเหลวในการปิดเคอร์เซอร์ฐานข้อมูลภายใต้เงื่อนไขบางประการ ซึ่งจะส่งผลให้ระบบทั้งหมดหยุดทำงานในที่สุด)
- นอกจากนี้ยังสามารถนำไปสู่การลดประสิทธิภาพได้ กล่าวคือ เพื่อให้แน่ใจว่าเวลาตอบสนองหลังจากกิจกรรมต่อเนื่องเป็นเวลานานจะดีเท่ากับตอนเริ่มต้นการทดสอบ
- ความล้มเหลวในการปิดการเชื่อมต่อระหว่างชั้นของระบบหลายชั้นภายใต้สถานการณ์บางอย่าง ซึ่งอาจทำให้โมดูลบางส่วนหรือทั้งหมดของระบบหยุดชะงัก
- การลดลงอย่างค่อยเป็นค่อยไปของเวลาตอบสนองของฟังก์ชันบางอย่างเนื่องจากโครงสร้างข้อมูลภายในมีประสิทธิภาพน้อยลงในระหว่างการทดสอบที่ยาวนาน
การทดสอบนี้เข้ากับกลุ่มการทดสอบประสิทธิภาพอย่างไร
การทดสอบประสิทธิภาพเป็นคำที่ใช้เรียกโดยรวม รูปแบบต่างๆ ที่กล่าวถึงด้านล่างนี้แตกต่างกันเพียงแค่ลักษณะของแรงที่ใช้และระยะเวลาที่คงแรงไว้ ซึ่งเป็นเหตุผลที่ทำให้มักเกิดความสับสนระหว่างการทดสอบทั้งสามประเภทนี้
| ประเภทการทดสอบ | รูปแบบการโหลด | คำถามมันตอบ |
|---|---|---|
| โหลดการทดสอบ | คาดการณ์ปริมาณการใช้ไฟฟ้าสูงสุด ระยะเวลาสั้น | ระบบสามารถบรรลุเป้าหมายภายใต้ปริมาณการใช้งานสูงสุดปกติได้หรือไม่? |
| การทดสอบความเครียด | เพิ่มขึ้นเกินขีดความสามารถจนกระทั่งเกิดความเสียหาย | มันพังตรงไหน และมันพังอย่างราบรื่นหรือไม่? |
| การทดสอบขัดขวาง | พุ่งขึ้นอย่างรุนแรงอย่างฉับพลัน แล้วก็ลดลง | รถคันนี้สามารถเอาตัวรอดและฟื้นตัวจากแรงกระแทกจากการจราจรได้หรือไม่? |
| การทดสอบความทนทาน | สามารถรับน้ำหนักปกติได้นานหลายชั่วโมง | ประสิทธิภาพจะลดลงเมื่อเวลาผ่านไปหรือไม่? |
| การทดสอบการแช่ | การรับน้ำหนักอย่างต่อเนื่องเป็นระยะเวลานาน | มีการรั่วไหลของหน่วยความจำหรือการใช้ทรัพยากรมากเกินไปหรือไม่? |
| การทดสอบความเสถียร | ภาระที่แตกต่างกันไปตามสภาวะต่างๆ | ระบบยังคงเชื่อถือได้หรือไม่เมื่อสภาวะเปลี่ยนแปลงไป? |
| การทดสอบปริมาตร | ผู้ใช้งานทั่วไป ปริมาณข้อมูลมหาศาล | มันสามารถรองรับการเติบโตของฐานข้อมูลได้หรือไม่? |
การทดสอบความทนทานและการทดสอบการแช่น้ำมักถูกมองว่าเป็นคำที่มีความหมายเหมือนกัน โดยทั่วไปแล้ว การทดสอบทั้งสองแบบสามารถรับภาระงานต่อเนื่องได้เป็นเวลานาน หากทีมงานมีการแยกแยะความแตกต่างระหว่างการทดสอบทั้งสอง การทดสอบความทนทานจะเน้นที่การดูว่าเวลาตอบสนองเพิ่มขึ้นหรือไม่ ในขณะที่การทดสอบความทนทานจะเน้นที่การใช้ทรัพยากร เช่น หน่วยความจำ ตัวจัดการไฟล์ และพูลการเชื่อมต่อ การทดสอบแบบใดแบบหนึ่งมักจะให้หลักฐานสำหรับการทดสอบทั้งสองแบบ
ตัวชี้วัดสำคัญที่ต้องบันทึกระหว่างการทดสอบ
การทดสอบประสิทธิภาพจะดีได้ก็ต่อเมื่อคุณบันทึกข้อมูลขณะที่มันทำงาน บันทึกค่าทั้งหกนี้ทั้งฝั่งเซิร์ฟเวอร์และฝั่งไคลเอนต์ จากนั้นเปรียบเทียบกับค่าพื้นฐานแทนที่จะเปรียบเทียบกับความรู้สึกส่วนตัว
| เมตริก | มันบอกคุณอะไร | ป้ายเตือน |
|---|---|---|
| เวลาตอบสนองโดยเฉลี่ย | ประสบการณ์การใช้งานทั่วไป | การเคลื่อนตัวขึ้นด้านบนใดๆ ตลอดแนวการวิ่ง |
| เวลาตอบสนองเปอร์เซ็นไทล์ที่ 95 | ประสบการณ์ของผู้ใช้งานที่ช้าที่สุด | สูงกว่าค่าเฉลี่ยมาก ซึ่งหมายถึงความไม่สม่ำเสมอ |
| ทางเข้า | จำนวนคำขอที่ประมวลผลต่อวินาที | การตกขณะที่น้ำหนักคงที่ |
| อัตราความผิดพลาด | สัดส่วนของคำขอที่ล้มเหลวหรือหมดเวลา | การเพิ่มขึ้นใดๆ ที่เกินกว่าเกณฑ์ที่ตกลงกันไว้ |
| การใช้งาน CPU และหน่วยความจำ | พื้นที่เหลือเฟือสำหรับทรัพยากรเซิร์ฟเวอร์ | ความทรงจำที่ลอยขึ้นไปแล้วไม่เคยหวนกลับมา |
| การเชื่อมต่อฐานข้อมูลและเธรด | ความเหนื่อยล้าจากสระว่ายน้ำ | จำนวนที่เพิ่มขึ้นอย่างต่อเนื่องโดยไม่มีการปล่อย |
อ่านค่าเฉลี่ยและเปอร์เซ็นไทล์ควบคู่กันไป ค่าเฉลี่ย 800 มิลลิวินาที โดยมีค่าเปอร์เซ็นไทล์ที่ 95 อยู่ที่ 900 มิลลิวินาที แสดงถึงระบบที่มีความสม่ำเสมอ แต่หากค่าเฉลี่ยเดียวกันนี้มีค่าเปอร์เซ็นไทล์ที่ 95 อยู่ที่ 9 วินาที หมายความว่าผู้ใช้ 1 ใน 20 คนกำลังประสบปัญหา และค่าเฉลี่ยที่แสดงนั้นปกปิดปัญหานี้ไว้
ให้ดูที่รูปทรง ไม่ใช่แค่ค่าของตัวเลข ในการทดสอบระยะยาวใดๆ หากเส้นกราฟทรัพยากรคงที่ แสดงว่าผ่านการทดสอบ และหากเส้นกราฟเพิ่มขึ้น แสดงว่ามีการรั่วไหล แม้ว่าตัวเลขสัมบูรณ์จะยังอยู่ในขีดจำกัดที่กำหนดไว้ ณ เวลาที่การทดสอบสิ้นสุดลงก็ตาม
