STLC - การดำเนินการทดสอบ

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

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

ต้องพิจารณาประเด็นต่อไปนี้สำหรับการดำเนินการทดสอบ

  • ในขั้นตอนนี้ทีม QA จะทำการตรวจสอบความถูกต้องของ AUT ตามกรณีการทดสอบที่เตรียมไว้และเปรียบเทียบผลลัพธ์แบบทีละขั้นกับผลลัพธ์ที่คาดไว้

  • เกณฑ์การเข้าสู่ระยะนี้คือการเสร็จสิ้นของแผนการทดสอบและขั้นตอนการพัฒนากรณีทดสอบข้อมูลการทดสอบควรพร้อมด้วย

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

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

กิจกรรมสำหรับการดำเนินการทดสอบ

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

การทดสอบการรวมระบบ

การตรวจสอบความถูกต้องของผลิตภัณฑ์ / AUT เริ่มต้นที่นี่ System Integration Testing (SIT) เป็นเทคนิคการทดสอบกล่องดำที่ประเมินความสอดคล้องของระบบกับข้อกำหนดที่ระบุ / กรณีทดสอบที่เตรียมไว้

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

  • สถานะข้อมูลภายในเลเยอร์การรวม
  • สถานะข้อมูลภายในชั้นฐานข้อมูล
  • สถานะข้อมูลภายในเลเยอร์แอปพลิเคชัน

Note- ในการทดสอบ SIT ทีม QA พยายามค้นหาข้อบกพร่องให้ได้มากที่สุดเพื่อให้มั่นใจในคุณภาพ วัตถุประสงค์หลักคือการค้นหาจุดบกพร่องให้ได้มากที่สุด

การรายงานข้อบกพร่อง

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

ในขณะที่ทำการทดสอบ SIT ทีม QA พบข้อบกพร่องประเภทนี้และจำเป็นต้องรายงานให้สมาชิกในทีมที่เกี่ยวข้องทราบ สมาชิกดำเนินการเพิ่มเติมและแก้ไขข้อบกพร่อง ข้อดีอีกประการหนึ่งของการรายงานคือช่วยลดการติดตามสถานะของข้อบกพร่อง มีเครื่องมือยอดนิยมมากมายเช่น ALM, QC, JIRA, Version One, Bugzilla ที่รองรับการรายงานและการติดตามข้อบกพร่อง

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

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

การทำแผนที่ข้อบกพร่อง

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

การทดสอบซ้ำ

การทดสอบซ้ำกำลังดำเนินการทดสอบที่ล้มเหลวก่อนหน้านี้กับ AUT เพื่อตรวจสอบว่าปัญหาได้รับการแก้ไขหรือไม่ หลังจากแก้ไขข้อบกพร่องแล้วให้ทำการทดสอบซ้ำเพื่อตรวจสอบสถานการณ์ภายใต้สภาวะแวดล้อมเดียวกัน

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

การทดสอบการถดถอย

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

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

ประเภทของการทดสอบการถดถอย

  • Final Regression Tests- มีการดำเนินการ "การทดสอบการถดถอยขั้นสุดท้าย" เพื่อตรวจสอบความถูกต้องของโครงสร้างที่ไม่ผ่านการเปลี่ยนแปลงในช่วงเวลาหนึ่ง โครงสร้างนี้ถูกปรับใช้หรือจัดส่งให้กับลูกค้า

  • Regression Tests - การทดสอบการถดถอยตามปกติจะดำเนินการเพื่อตรวจสอบว่าบิวด์ไม่ได้ทำลายส่วนอื่น ๆ ของแอปพลิเคชันหรือไม่โดยการเปลี่ยนแปลงโค้ดล่าสุดสำหรับการแก้ไขข้อบกพร่องหรือเพื่อการปรับปรุง

แผนภาพบล็อกกิจกรรม

แผนภาพบล็อกต่อไปนี้แสดงกิจกรรมสำคัญที่ดำเนินการในระยะนี้ นอกจากนี้ยังแสดงการพึ่งพาจากขั้นตอนก่อนหน้า -