การทดสอบความเสถียรในการทดสอบซอฟต์แวร์

⚡ สรุปอย่างชาญฉลาด

การทดสอบความเสถียรจะตรวจสอบว่าแอปพลิเคชันยังคงทำงานได้อย่างน่าเชื่อถือหรือไม่เมื่อสภาวะต่างๆ เปลี่ยนแปลงไป ไม่ใช่แค่ภายใต้ภาระคงที่เพียงอย่างเดียว การทดสอบนี้จะเปิดเผยข้อผิดพลาด การใช้ทรัพยากรมากเกินไป และความเสื่อมประสิทธิภาพ ซึ่งการทดสอบการทำงานในระยะเวลาสั้นๆ ไม่เคยพบเห็น

  • 🏗️ วัตถุประสงค์หลัก: ตรวจสอบให้แน่ใจว่าระบบยังคงทำงานได้อย่างน่าเชื่อถือภายใต้ภาระงานที่แตกต่างกันและการใช้งานต่อเนื่องเป็นเวลานาน
  • ⚠️ หลีกเลี่ยงความเสี่ยงได้: ระบบที่ยังไม่ผ่านการทดสอบจะล้มเหลวในการใช้งานจริงภายใต้สภาวะที่ไม่มีใครเคยซ้อมมาก่อน
  • 📊 ประถม Signals: จำนวน CPU, หน่วยความจำ, ดิสก์ และเธรด tracตลอดระยะเวลาทั้งหมด
  • 🔄 ใช้งานไม่ได้: เป็นการวัดพฤติกรรมภายใต้ความเครียดมากกว่าความถูกต้องของลักษณะต่างๆ
  • 🧪 การออกแบบการทดสอบ: กรณีศึกษาเหล่านี้มุ่งเป้าไปที่การใช้งาน CPU อย่างต่อเนื่อง แรงดันหน่วยความจำ และการทำธุรกรรมซ้ำๆ
  • 📈 รายงาน: กราฟแสดงแนวโน้มมีความสำคัญมากกว่าค่าที่วัดได้เพียงค่าเดียว เพราะการเปลี่ยนแปลงอย่างค่อยเป็นค่อยไปถือเป็นข้อบกพร่อง

การทดสอบความเสถียรในการทดสอบซอฟต์แวร์

การทดสอบความเสถียรคืออะไร?

การทดสอบความเสถียร เป็นการทดสอบซอฟต์แวร์ที่ไม่ใช้งานประเภทหนึ่งที่ดำเนินการเพื่อวัดประสิทธิภาพและความสามารถของแอปพลิเคชันซอฟต์แวร์ให้ทำงานอย่างต่อเนื่องเป็นระยะเวลานาน วัตถุประสงค์ของการทดสอบความเสถียรคือการตรวจสอบว่าแอปพลิเคชันซอฟต์แวร์ขัดข้องหรือล้มเหลวจากการใช้งานปกติ ณ จุดใดเวลาหนึ่งหรือไม่ โดยใช้การใช้งานอย่างเต็มรูปแบบ

การทดสอบเสถียรภาพจะทำขึ้นเพื่อตรวจสอบประสิทธิภาพของผลิตภัณฑ์ที่พัฒนาขึ้นเกินขีดความสามารถในการทำงานปกติ ซึ่งมักจะถึงจุดแตกหัก ความสำคัญอยู่ที่การจัดการข้อผิดพลาด ความน่าเชื่อถือของซอฟต์แวร์ ความแข็งแกร่ง และความสามารถในการปรับขนาดของผลิตภัณฑ์ภายใต้ภาระงานหนัก มากกว่าการตรวจสอบพฤติกรรมของระบบภายใต้สถานการณ์ปกติ

การทดสอบความเสถียรเป็นการประเมินปัญหาความเสถียร การทดสอบนี้มีวัตถุประสงค์หลักเพื่อเน้นส่วนประกอบซอฟต์แวร์ให้มากที่สุด เป็นเทคนิคที่ไม่ใช่เชิงฟังก์ชัน

การทดสอบความเสถียร
การทดสอบความเสถียร

การทดสอบความเสถียรเรียกอีกอย่างว่าโหลดหรือ การทดสอบความอดทน.

ความเสี่ยงหากระบบที่อยู่ระหว่างการทดสอบไม่ผ่านการทดสอบความเสถียร

สำหรับแอปพลิเคชันที่อยู่ระหว่างการทดสอบซึ่งมีผู้ใช้จำนวนมากเข้ามาใช้งานและแอปพลิเคชันที่ต้องทำงานเป็นเวลาหลายเดือนโดยไม่ต้องรีสตาร์ท อาจเกิดปัญหาหลายประการ:

ข้อผิดพลาดที่อาจเกิดขึ้นได้

  • ระบบช้าลง
  • ระบบประสบปัญหาการทำงาน
  • ระบบจะแสดงพฤติกรรมแบบมีสาย
  • ระบบล่มไปเลย

ในสาขาวิศวกรรมซอฟต์แวร์ การทดสอบความเสถียร โดยทั่วไปจะเกี่ยวข้องกับการใช้งานระบบกับผู้ใช้จำนวนมาก (เสมือน) และการวัดพารามิเตอร์ประสิทธิภาพเพื่อตรวจสอบว่าระบบสามารถรองรับโหลดที่คาดการณ์ไว้ได้หรือไม่

ทำไมต้องทำการทดสอบความเสถียร

การทดสอบประเภทนี้จะช่วยให้ผู้ใช้เข้าใจถึงวิธีที่ระบบจะทำงานในสถานการณ์จริง

ดังนั้นการทดสอบความเสถียรทำให้คุณสามารถตรวจสอบ

  • ให้ความมั่นใจในความเสถียรของระบบของคุณภายใต้การทดสอบ
  • ตรวจสอบให้แน่ใจว่าระบบของคุณสามารถจัดการกับโปรแกรมขนาดใหญ่ได้
  • ตรวจสอบประสิทธิภาพของระบบของคุณ
  • ทดสอบความเสถียรของระบบภายใต้ความเครียด

มีบทบาทสำคัญในการพัฒนาผลิตภัณฑ์เนื่องจากใช้เพื่อกำหนดข้อจำกัดของผลิตภัณฑ์ซอฟต์แวร์ที่อยู่ระหว่างการทดสอบก่อนวางจำหน่ายหรือพื้นที่ที่ต้องปรับปรุงเพิ่มเติมก่อนที่ผลิตภัณฑ์จะเผยแพร่หรือที่การผลิต

ตัวอย่างเทคนิคการทดสอบความเสถียรที่พบบ่อยมากคือ

OnLine Sกระโดดping Portals: การทดสอบความเสถียรจะตรวจสอบว่าเว็บไซต์จะทำงานอย่างไรเมื่อ –

  • มีการป้อนข้อมูลจำนวนมากในช่วงเวลาเร่งด่วน
  • จำนวนการเข้าชมในช่วงเวลาหนึ่งๆ
  • ปัญหาการโหลดหน้าในเวลาเดียวกัน
  • พฤติกรรมของระบบ
  • การตอบสนองของระบบและอื่นๆ อีกมากมายตามมา การทดสอบความเสถียร

ตัวอย่างอื่น

A ซีพียู การทดสอบเป็นรูปแบบการทดสอบความเสถียรที่เป็นที่นิยมภายใต้ การทดสอบประสิทธิภาพ เทคนิค. การทดสอบนี้จะตรวจสอบความเสถียรของโปรเซสเซอร์และยังติดตามประสิทธิภาพเมื่อเวิร์คโหลดของโปรเซสเซอร์เพิ่มขึ้น

วิธีการทดสอบความเสถียร

  • เพื่อกำหนดขอบเขตและวัตถุประสงค์ของการทดสอบ เราต้องตรวจสอบให้แน่ใจว่าแอปพลิเคชันเซิร์ฟเวอร์ไม่ขัดข้องระหว่างการดำเนินการทดสอบโหลด
  • เพื่อระบุปัญหาทางธุรกิจ ให้ตรวจสอบประสิทธิภาพของระบบและโหลดตามมุมมองของผู้ใช้
  • เพื่อมอบหมายความรับผิดชอบและบทบาทที่แตกต่างกัน เช่น -การสร้างแผนการทดสอบ กรณีทดสอบ การออกแบบ การทบทวนกรณีทดสอบ การดำเนินการทดสอบ ฯลฯ
  • เพื่อให้แน่ใจว่าการทดสอบส่งมอบภายในเวลาที่กำหนด
  • เพื่อความเหมาะสม โหลดการทดสอบ ทีมงานเครื่องมือและประสบการณ์ก็นำเสนอเช่นเดียวกัน
  • เพื่อวัดความเสี่ยงและต้นทุนที่เกี่ยวข้องกับการทดสอบ ซึ่งจะเป็นตัวกำหนดต้นทุนของการดำเนินการแต่ละครั้งในแง่ของการใช้งาน CPU และหน่วยความจำ
  • กำหนด ข้อบกพร่อง tracกษัตริย์และการรายงานและแผนที่ที่ถูกต้องของพวกเขาping พร้อมข้อกำหนด

กรณีทดสอบสำหรับการทดสอบความเสถียรของประสิทธิภาพของ CPU

  • เพื่อตรวจสอบขีดจำกัดบนของระบบ
  • ระบบล่มหรือกู้คืนได้อย่างไร
  • จำนวนธุรกรรมทั้งหมดที่เสร็จสมบูรณ์ต่อคำขอ
  • การตอบสนองต่อธุรกรรมจะคงที่หรือเพิ่มขึ้นเมื่อเวลาผ่านไปหรือไม่
  • ระบบทำงานอย่างไรภายใต้ภาระหนัก
  • การตอบสนองและพฤติกรรมภายใต้ภาระหนัก

รายงานการทดสอบสำหรับการทดสอบความเสถียร

มีการรวบรวมและวัดสถิติต่างๆ ระหว่างการดำเนินการทดสอบ โดยตัวเลขเหล่านี้จะถูกวิเคราะห์เพื่อสร้างรายงานและระบุปัญหาประสิทธิภาพที่อาจเกิดขึ้น

ตัวอย่างสถิติที่รวบรวมภายใต้การทดสอบได้แก่:

  • เวลาตอบสนองธุรกรรม: เวลาเฉลี่ยที่ใช้ในการทำธุรกรรมระหว่างการทดสอบ สถิตินี้จะประเมินว่าประสิทธิภาพของเซิร์ฟเวอร์อยู่ภายในระยะเวลาประสิทธิภาพการทำธุรกรรมขั้นต่ำและสูงสุดที่ยอมรับได้ที่กำหนดไว้สำหรับระบบหรือไม่ ข้อมูลนี้จะประเมินเวลาที่ใช้ในการประมวลผลคำขอโดยเว็บเซิร์ฟเวอร์และส่งไปยังเซิร์ฟเวอร์แอปพลิเคชันซึ่งใน กรณีส่วนใหญ่จะทำการร้องขอไปยังเซิร์ฟเวอร์ฐานข้อมูล
  • จำนวนการเข้าชมต่อวินาที: จำนวนการเข้าชมที่เกิดขึ้นบนเซิร์ฟเวอร์โดยผู้ใช้ สถิติเหล่านี้มีประโยชน์ในการกำหนดจำนวนโหลดที่ผู้ใช้สร้างขึ้น เทียบกับจำนวนการเข้าชม
  • ผ่าน: จำนวนทรูพุตบนเว็บเซิร์ฟเวอร์ระหว่างการทดสอบซึ่งวัดเป็นไบต์ ปริมาณงานหมายถึงจำนวนข้อมูลที่ผู้ใช้ได้รับจากเซิร์ฟเวอร์ในเวลาใดก็ตาม สถิตินี้ช่วยในการประเมินจำนวนโหลดที่ผู้ใช้สร้างขึ้น
  • ธุรกรรมต่อวินาที: นี่คือจำนวนธุรกรรมที่เสร็จสมบูรณ์ทั้งหมด (ทั้งสำเร็จและล้มเหลว) ที่ดำเนินการระหว่างการทดสอบ สถิตินี้ช่วยในการตรวจสอบปริมาณธุรกรรมที่เกิดขึ้นจริงบนระบบ
  • ซีพียู: เปอร์เซ็นต์การใช้งาน CPU ที่ใช้ระหว่างการทดสอบ
  • หน่วยความจำ: การใช้หน่วยความจำระหว่างการทดสอบ
  • ดิสก์: การใช้พื้นที่ดิสก์ที่ใช้ระหว่างการทดสอบ

พื้นฐานการทดสอบความเสถียร

การทดสอบความเสถียร อยู่ภายใต้การทดสอบประสิทธิภาพ ซึ่งเป็นเทคนิคที่ดำเนินการเพื่อตรวจสอบคุณลักษณะด้านคุณภาพบางอย่างของซอฟต์แวร์ เช่น ความเสถียร ความน่าเชื่อถือ และความพร้อมใช้งาน

การทดสอบนี้ใช้เพื่อกำหนดความเร็วของระบบหรือระบบย่อยที่ทำงานภายใต้เวิร์กโหลดเฉพาะ

การทดสอบประสิทธิภาพมีหลายประเภท และการทดสอบความเสถียรก็เป็นหนึ่งในนั้น

  • การทดสอบความเครียด: เป็นแบบทดสอบที่จะตรวจสอบความทนทานของระบบที่เกินความสามารถของระบบ
  • การทดสอบขัดขวาง: ใช้เพื่อตรวจสอบพฤติกรรมของระบบโดยการเพิ่มภาระของระบบทันที วัตถุประสงค์คือเพื่อตรวจสอบว่าระบบจะมีปัญหาด้านประสิทธิภาพ ณ จุดใดหรือจะผ่านไป
  • การทดสอบความสามารถในการปรับขนาด: ใช้เพื่อตรวจสอบความสามารถของระบบ ว่าระบบจะมีประสิทธิภาพแค่ไหนในการรับมือกับความต้องการที่เพิ่มขึ้น การเปลี่ยนแปลงขนาด และการเปลี่ยนแปลงปริมาณ
  • การทดสอบปริมาตร: เป็นเทคนิคการทดสอบที่ไม่สามารถใช้งานได้ซึ่งซอฟต์แวร์ที่อยู่ระหว่างการทดสอบจะต้องได้รับข้อมูลปริมาณมหาศาล และพฤติกรรมของระบบจะได้รับการตรวจสอบและตรวจสอบตามนั้น
  • การทดสอบการรับน้ำหนักหรือความเสถียร: (ได้กล่าวไว้ข้างต้นแล้ว)

เครื่องมือทดสอบความเสถียร

เครื่องมือบางอย่างสำหรับการทดสอบประสิทธิภาพมีดังนี้ -

  • เว็บโหลด
  • โหลดรันเนอร์
  • อาปาเช่ JMeter
  • Neoโหลด
  • คลาวด์เทส
  • โหลดสตอร์ม
  • โหลดUI
  • สวพ
  • โหลดผลกระทบ
  • รถตัก
  • Httperf
  • เปิดSTA

การทดสอบนี้เข้ากับกลุ่มการทดสอบประสิทธิภาพอย่างไร

การทดสอบประสิทธิภาพเป็นคำที่ใช้เรียกโดยรวม รูปแบบต่างๆ ที่กล่าวถึงด้านล่างนี้แตกต่างกันเพียงแค่ลักษณะของแรงที่ใช้และระยะเวลาที่คงแรงไว้ ซึ่งเป็นเหตุผลที่ทำให้มักเกิดความสับสนระหว่างการทดสอบทั้งสามประเภทนี้

ประเภทการทดสอบ รูปแบบการโหลด คำถามมันตอบ
โหลดการทดสอบ คาดการณ์ปริมาณการใช้ไฟฟ้าสูงสุด ระยะเวลาสั้น ระบบสามารถบรรลุเป้าหมายภายใต้ปริมาณการใช้งานสูงสุดปกติได้หรือไม่?
การทดสอบความเครียด เพิ่มขึ้นเกินขีดความสามารถจนกระทั่งเกิดความเสียหาย มันพังตรงไหน และมันพังอย่างราบรื่นหรือไม่?
การทดสอบขัดขวาง พุ่งขึ้นอย่างรุนแรงอย่างฉับพลัน แล้วก็ลดลง รถคันนี้สามารถเอาตัวรอดและฟื้นตัวจากแรงกระแทกจากการจราจรได้หรือไม่?
การทดสอบความทนทาน สามารถรับน้ำหนักปกติได้นานหลายชั่วโมง ประสิทธิภาพจะลดลงเมื่อเวลาผ่านไปหรือไม่?
การทดสอบการแช่ การรับน้ำหนักอย่างต่อเนื่องเป็นระยะเวลานาน มีการรั่วไหลของหน่วยความจำหรือการใช้ทรัพยากรมากเกินไปหรือไม่?
การทดสอบความเสถียร ภาระที่แตกต่างกันไปตามสภาวะต่างๆ ระบบยังคงเชื่อถือได้หรือไม่เมื่อสภาวะเปลี่ยนแปลงไป?
การทดสอบปริมาตร ผู้ใช้งานทั่วไป ปริมาณข้อมูลมหาศาล มันสามารถรองรับการเติบโตของฐานข้อมูลได้หรือไม่?

การทดสอบความทนทานและการทดสอบการแช่น้ำมักถูกมองว่าเป็นคำที่มีความหมายเหมือนกัน โดยทั่วไปแล้ว การทดสอบทั้งสองแบบสามารถรับภาระงานต่อเนื่องได้เป็นเวลานาน หากทีมงานมีการแยกแยะความแตกต่างระหว่างการทดสอบทั้งสอง การทดสอบความทนทานจะเน้นที่การดูว่าเวลาตอบสนองเพิ่มขึ้นหรือไม่ ในขณะที่การทดสอบความทนทานจะเน้นที่การใช้ทรัพยากร เช่น หน่วยความจำ ตัวจัดการไฟล์ และพูลการเชื่อมต่อ การทดสอบแบบใดแบบหนึ่งมักจะให้หลักฐานสำหรับการทดสอบทั้งสองแบบ

ตัวชี้วัดสำคัญที่ต้องบันทึกระหว่างการทดสอบ

การทดสอบประสิทธิภาพจะดีได้ก็ต่อเมื่อคุณบันทึกข้อมูลขณะที่มันทำงาน บันทึกค่าทั้งหกนี้ทั้งฝั่งเซิร์ฟเวอร์และฝั่งไคลเอนต์ จากนั้นเปรียบเทียบกับค่าพื้นฐานแทนที่จะเปรียบเทียบกับความรู้สึกส่วนตัว

เมตริก มันบอกคุณอะไร ป้ายเตือน
เวลาตอบสนองโดยเฉลี่ย ประสบการณ์การใช้งานทั่วไป การเคลื่อนตัวขึ้นด้านบนใดๆ ตลอดแนวการวิ่ง
เวลาตอบสนองเปอร์เซ็นไทล์ที่ 95 ประสบการณ์ของผู้ใช้งานที่ช้าที่สุด สูงกว่าค่าเฉลี่ยมาก ซึ่งหมายถึงความไม่สม่ำเสมอ
ทางเข้า จำนวนคำขอที่ประมวลผลต่อวินาที การตกขณะที่น้ำหนักคงที่
อัตราความผิดพลาด สัดส่วนของคำขอที่ล้มเหลวหรือหมดเวลา การเพิ่มขึ้นใดๆ ที่เกินกว่าเกณฑ์ที่ตกลงกันไว้
การใช้งาน CPU และหน่วยความจำ พื้นที่เหลือเฟือสำหรับทรัพยากรเซิร์ฟเวอร์ ความทรงจำที่ลอยขึ้นไปแล้วไม่เคยหวนกลับมา
การเชื่อมต่อฐานข้อมูลและเธรด ความเหนื่อยล้าจากสระว่ายน้ำ จำนวนที่เพิ่มขึ้นอย่างต่อเนื่องโดยไม่มีการปล่อย

อ่านค่าเฉลี่ยและเปอร์เซ็นไทล์ควบคู่กันไป ค่าเฉลี่ย 800 มิลลิวินาที โดยมีค่าเปอร์เซ็นไทล์ที่ 95 อยู่ที่ 900 มิลลิวินาที แสดงถึงระบบที่มีความสม่ำเสมอ แต่หากค่าเฉลี่ยเดียวกันนี้มีค่าเปอร์เซ็นไทล์ที่ 95 อยู่ที่ 9 วินาที หมายความว่าผู้ใช้ 1 ใน 20 คนกำลังประสบปัญหา และค่าเฉลี่ยที่แสดงนั้นปกปิดปัญหานี้ไว้

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

คำถามที่พบบ่อย

การทดสอบโหลดจะตรวจสอบพฤติกรรมที่จุดสูงสุดที่กำหนดไว้ในช่วงเวลาสั้นๆ ในขณะที่การทดสอบเสถียรภาพจะดำเนินการภายใต้สภาวะที่แตกต่างกันเป็นเวลานานกว่ามาก โดยมุ่งเน้นที่การเสื่อมสภาพมากกว่าการผ่านหรือไม่ผ่านเกณฑ์เป้าหมาย

นานพอที่จะทำให้ปัญหาที่ค่อยๆ สะสมปรากฏขึ้น โดยทั่วไปคือ 8 ถึง 72 ชั่วโมง หากใช้เวลาน้อยกว่าหนึ่งชั่วโมง ปัญหาหน่วยความจำรั่วหรือการเชื่อมต่อที่ค่อยๆ หมดลงมักจะไม่ปรากฏให้เห็น

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

ระบบตรวจจับความผิดปกติที่ใช้ AI สามารถตรวจจับช่วงเวลาที่เส้นกราฟแสดงปริมาณทรัพยากรเปลี่ยนความชัน ซึ่งเร็วกว่าการแจ้งเตือนด้วยเกณฑ์คงที่มาก และเชื่อถือได้มากกว่าการอ่านกราฟด้วยตาเปล่า

ใช่แล้ว โมเดลที่ฝึกฝนจากเหตุการณ์ในอดีตและการเปลี่ยนแปลงของโค้ดจะช่วยเน้นโมดูลที่มีแนวโน้มที่จะรั่วไหลของทรัพยากรมากที่สุด ทำให้ทีมสามารถกำหนดเป้าหมายการทดสอบระยะยาวที่จะให้ผลตอบแทนคุ้มค่าได้

สรุปโพสต์นี้ด้วย: