สํารวจการทดสอบ shift-right

เสร็จสมบูรณ์เมื่อ

ตามที่อธิบายไว้ก่อนหน้านี้ในหลักสูตร การทดสอบในการจัดการวงจรชีวิตของแอปพลิเคชันเป็นสิ่งสําคัญในการเพิ่มคุณภาพโค้ดให้สูงสุดและลดความเสี่ยงในการดําเนินงานที่เกี่ยวข้องกับการปรับใช้และการอัปเดตซอฟต์แวร์ นี่คือเหตุผลสําหรับการใช้ แบบ shift-left ซึ่งแนะนํากิจกรรมการทดสอบโดยเร็วที่สุดในขั้นตอนการพัฒนา อย่างไรก็ตามมีบางแง่มุมของการทดสอบซึ่งไม่มีประสิทธิภาพเมื่อดําเนินการในลักษณะนี้ แทนที่จะทําหน้าที่ตามวัตถุประสงค์ของพวกเขาอย่างเต็มที่ พวกเขาจําเป็นต้องดําเนินการในสภาพแวดล้อมการผลิต ซึ่งเรียกว่าวิธีการ เลื่อนขวาของ องค์กรในสถานการณ์ตัวอย่างของเราจะต้องใช้สิ่งนี้เพื่อประเมินความน่าเชื่อถือของระบบของตนควบคู่ไปกับการฉีดข้อบกพร่อง ในหน่วยนี้ ให้ตรวจสอบเกณฑ์นี้และเกณฑ์อื่น ๆ ที่การทดสอบแบบ shift-right มีความชอบธรรม

อะไรคือเหตุผลของการทดสอบ shift-right

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

การทดสอบในการผลิตมีประโยชน์ดังต่อไปนี้:

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

สถานการณ์การทดสอบ shift-right ทั่วไปคืออะไร

ในขณะที่วิธีการทดสอบแบบ shift-right อาจเป็นเหตุผลในหลายสถานการณ์ แต่มีหลายสถานการณ์ที่เหมาะสม สถานการณ์เหล่านี้รวมถึง:

  • การปรับใช้ Microservices: สถาปัตยกรรมไมโครบริการโดยทั่วไปจะประกอบด้วยส่วนประกอบที่พัฒนาขึ้นเองเป็นจํานวนมาก จํานวนชุดรวมของบริการเหล่านี้อาจจัดเต็มการทดสอบ shift-right เพื่อมุ่งเน้นไปที่สถานการณ์ที่เกี่ยวข้องมากที่สุดในสภาพแวดล้อมการผลิตจริง (ตามการใช้งานในชีวิตจริง)

  • การประเมินผลกระทบของแบนด์วิดท์เครือข่ายและเงื่อนไขเวลาแฝง: สภาพเครือข่ายมีแนวโน้มที่จะท้าทายในการจําลอง ดังนั้นหากประสิทธิภาพของปริมาณงานมีความล่าช้าหรือแบนด์วิดท์ที่สูง การทดสอบ shift-right อาจเป็นตัวเลือกที่เหมาะสมที่สุด

  • การทดสอบการยอมรับของผู้ใช้: คําติชมของผู้ใช้จริงอาจจําเป็นสําหรับการตรวจสอบประสิทธิภาพและการใช้งานของปริมาณงาน

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

    โน้ต

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

    โน้ต

    คุณสามารถใช้ Azure Chaos Studio เพื่อดําเนินการทดลองวิศวกรรมที่โกลาหลที่กําหนดเป้าหมายโซลูชันที่โฮสต์ใน Microsoft Azure ได้ คุณจะผ่านตัวอย่างการทดลองดังกล่าวในแล็บของโมดูลนี้