เปลี่ยนเป้าหมายคุณภาพที่คลุมเครือเป็นสถานการณ์ที่มีการตอบสนองให้สังเกตได้และกฎการวัด คำว่า “พอร์ทัลต้องเร็ว” ไม่เพียงพอสำหรับเลือกการออกแบบหรือพิจารณาว่า release ตรงตามข้อกำหนดหรือไม่
ระบุแหล่งสิ่งกระตุ้น สิ่งกระตุ้น ระบบที่ได้รับผล เงื่อนไขการทำงาน การตอบสนองที่คาดหวัง และตัววัดการตอบสนอง องค์ประกอบเหล่านี้ทำให้สมมติฐานชัดเจน เพื่อให้ต่างทีมทดสอบคำกล่าวอ้างเดียวกันได้
สำหรับพอร์ทัลคืนสินค้าตัวอย่าง ให้ตกลงสถานการณ์ต่อไปนี้กับเจ้าของธุรกิจ:
ตัวเลขเหล่านี้เป็นเป้าหมายตัวอย่าง ไม่ใช่ค่าเริ่มต้นของอุตสาหกรรม รายงานความล้มเหลวแยกต่างหาก เพื่อไม่ให้การปฏิเสธที่รวดเร็วทำให้ latency ดูดี การยืนยันรับคำขอแตกต่างจากคลังสินค้าดำเนินการเสร็จ ซึ่งต้องมีเกณฑ์เวลาทางธุรกิจของตัวเอง
การออกแบบอาจรับคำขออย่างถาวรก่อน แล้วประมวลผลงานคลังสินค้าแบบ asynchronous ทดสอบเส้นทางนั้นจริง รวมถึงเงื่อนไขเครือข่ายที่สมจริง เขียนสถานการณ์แยกสำหรับระบบที่พึ่งพาไม่พร้อมใช้งานและการกู้คืน การทดสอบโหลดขณะระบบปกติพิสูจน์ทั้งสองเรื่องนี้ไม่ได้
latency เฉลี่ยซ่อนผู้ใช้ที่ได้รับการตอบสนองช้า ชุดข้อมูลที่ไม่กำหนดชัดทำให้ทำซ้ำผลได้ยาก “พร้อมใช้งานเสมอ” ไม่ระบุขอบเขตความล้มเหลวหรือช่วงวัด คำตอบที่ดีระบุว่าจะวัดอะไร จากที่ใด ภายใต้เงื่อนไขใด และใครยอมรับว่าเป้าหมายเพียงพอ
อ้างอิง: SEI: การกำหนดข้อกำหนดคุณลักษณะคุณภาพ.
คลังคำถามสัมภาษณ์งาน IT พร้อมคำตอบโดยละเอียด — ตั้งแต่ระดับ Junior ถึง Senior
บริจาค