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

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

Ramona Schwering

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

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

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

เทสเคสคืออะไร

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

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

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

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

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

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

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

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

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

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

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

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

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

• รูปแบบ Arrange, act, assert รูปแบบการทดสอบ "จัดเตรียม ดำเนินการ ยืนยัน" (หรือที่เรียกว่า "AAA" หรือ "Triple A") เป็นวิธีจัดระเบียบการทดสอบออกเป็น 3 ขั้นตอนที่ชัดเจน ได้แก่ การจัดเตรียมการทดสอบ การดำเนินการทดสอบ และสุดท้ายคือการสรุปผล
• รูปแบบ Given, when, then รูปแบบนี้คล้ายกับรูปแบบ AAA แต่มีรากฐานมาจากการพัฒนาที่เน้นลักษณะการทำงาน

บทความในอนาคตจะอธิบายรูปแบบเหล่านี้อย่างละเอียดยิ่งขึ้นทันทีที่เราพูดถึงโครงสร้างของแบบทดสอบ หากต้องการเจาะลึกรูปแบบเหล่านี้ในขั้นตอนนี้ โปรดอ่านบทความ 2 บทความต่อไปนี้ Arrange-Act-Assert: A pattern for writing good tests และ Given-When-Then

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

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