การกำหนดกรอบการทดสอบและลำดับความสำคัญ

กำหนดว่าจะทดสอบอะไร ระบุกรณีทดสอบ และจัดลำดับความสำคัญ

Ramona Schwering

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

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

ส่วนที่เหลือของบทความนี้จะอธิบายเกณฑ์เหล่านี้และวิธีนำไปใช้เมื่อคุณระบุกรอบการทดสอบ

กรอบการทดสอบคืออะไร

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

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

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

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

เส้นทางการทดสอบ: ประเภทกรอบการทดสอบทั่วไป

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

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

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

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

การจัดหมวดหมู่เส้นทางเหล่านั้นมีอยู่หลายวิธี วิธีที่ใช้กันทั่วไปมี 2 วิธี ได้แก่

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

แนวทางปฏิบัติแนะนำ: การเขียนกรอบการทดสอบ

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

• รูปแบบจัดเรียง ดำเนินการ ยืนยัน รูปแบบการทดสอบ "จัดเรียง ดำเนินการ ยืนยัน" (หรือที่เรียกว่า "AAA" หรือ "ทริปเปิล A") เป็นวิธีแบ่งการทดสอบออกเป็น 3 ขั้นตอน ได้แก่ จัดเตรียมการทดสอบ ดำเนินการทดสอบ และสรุปสุดท้ายแต่ไม่ท้ายสุด
• ระบุเมื่อใดและเมื่อใด รูปแบบนี้คล้ายกับรูปแบบ AAA แต่มีพื้นฐานมาจากการพัฒนาที่ขับเคลื่อนด้วยพฤติกรรม

บทความในอนาคตจะลงรายละเอียดเพิ่มเติมเกี่ยวกับรูปแบบเหล่านี้ทันทีที่เราพูดถึงโครงสร้างของการทดสอบเอง หากคุณต้องการเจาะลึกลงไปเกี่ยวกับรูปแบบเหล่านี้ในขั้นตอนนี้ ให้ดูที่บทความ 2 เรื่องนี้ ได้แก่ Aกำหนดเวลา-Act-Assert: รูปแบบการเขียนการทดสอบที่ดี และการให้แล้วเมื่อนั้น

จากข้อมูลทั้งหมดที่ได้เรียนรู้จากบทความนี้ ตารางต่อไปนี้สรุปตัวอย่างแบบคลาสสิก

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