กำไร:
- ความสามารถในการแปลงเกณฑ์ความต้องการและการยอมรับให้เป็นกรณีทดสอบที่ครอบคลุมด้วยเทคนิค เช่น คลาสที่เท่าเทียมกัน การวิเคราะห์ค่าขอบเขต และตารางการตัดสินใจ ด้วยการสนับสนุนของปัญญาประดิษฐ์
- ความสามารถในการสร้างสถานการณ์เชิงบวก ลบ และ Edge Case แยกจากกัน และดำเนินการ Edge Case ที่พลาดไปโดยปัญญาประดิษฐ์ด้วยข้อมูลผลิตภัณฑ์
- ความสามารถในการสร้างความสามารถในการตรวจสอบย้อนกลับและขจัดช่องว่างความครอบคลุมและการขยายตัวที่ไม่จำเป็นโดยการเชื่อมโยงกรณีทดสอบเข้ากับเกณฑ์การยอมรับ
งานของผู้ทดสอบมักจะเริ่มต้นด้วยกระดานชนวนที่ว่างเปล่า: เขามีข้อกำหนด ("ผู้ใช้จะต้องสามารถรีเซ็ตรหัสผ่านของเขาได้") และเขาจำเป็นต้องเปลี่ยนประโยคเดียวนี้เป็นการตรวจสอบที่เป็นรูปธรรมหลายสิบครั้งที่จะพิสูจน์ว่าซอฟต์แวร์ทำงานได้อย่างถูกต้องจริง การเปลี่ยนแปลงนี้เรียกว่าการออกแบบการทดสอบ การทราบความแตกต่างระหว่างสถานการณ์การทดสอบ — วัตถุประสงค์ระดับสูงที่อธิบายสิ่งที่ต้องทดสอบ เช่น "รหัสผ่านที่ไม่ถูกต้องควรถูกปฏิเสธ" — และกรณีทดสอบ — หน่วยปฏิบัติการที่ให้รายละเอียดสถานการณ์นั้นด้วยขั้นตอนที่เป็นรูปธรรม ข้อมูลนำเข้า และผลลัพธ์ที่คาดหวังเป็นสิ่งสำคัญ ปัญญาประดิษฐ์ (AI) เร่งช่วงเวลาของหน้าว่างนี้อย่างรวดเร็ว: เปลี่ยนข้อกำหนดหนึ่งข้อให้กลายเป็นสถานการณ์ร่างหลายสิบรายการในไม่กี่วินาที แต่อย่าลืมว่า AI จำลองสถานการณ์ที่คุณนึกถึงได้ คุณเลือกด้วยความรู้เกี่ยวกับผลิตภัณฑ์ว่าสถานการณ์ใดมีความสำคัญจริงๆ
ในหน่วยการเรียนรู้นี้ คุณจะได้เรียนรู้ทีละขั้นตอนถึงวิธีเปลี่ยนข้อกำหนดให้เป็นชุดการทดสอบที่ครอบคลุมแต่ไม่เกะกะพร้อมการสนับสนุน AI
ทีละขั้นตอน: จากข้อกำหนดไปจนถึงชุดทดสอบ
ขั้นตอนที่ 1 — ชี้แจงข้อกำหนด รวบรวมเกณฑ์การยอมรับ (เงื่อนไขที่งานต้องเข้าจึงจะถือว่า “เสร็จสิ้น”) ก่อนที่จะให้ข้อกำหนดดิบแก่ AI "รหัสผ่านต้องรีเซ็ตได้" ยังไม่เพียงพอ กฎเช่น "ลิงก์รีเซ็ตใช้ได้ 30 นาที", "รหัสผ่านเดียวกันไม่สามารถใช้ซ้ำได้" เป็นที่มาของการทดสอบจริง
ขั้นตอนที่ 2 — นำเทคนิคการทดสอบไปใช้ อย่าเพิ่งพูดว่า "เขียนสคริปต์" เกี่ยวกับ AI; ขอชื่อเทคนิคการออกแบบการทดสอบแบบคลาสสิก:
- คลาสที่เท่าเทียมกัน (การแบ่งพาร์ติชันที่เท่ากัน): การแบ่งอินพุตออกเป็นกลุ่มที่คาดว่าจะสร้างพฤติกรรมเดียวกัน ตัวอย่างเช่น สำหรับฟิลด์อายุ "ช่วงที่ถูกต้อง" "เล็กเกินไป" และ "ใหญ่เกินไป" ถือเป็นคลาส การทดสอบหนึ่งตัวอย่างจากแต่ละชั้นเรียนก็เพียงพอแล้ว
- การวิเคราะห์ค่าขอบเขต: การทดสอบค่าเกณฑ์โดยพิจารณาจากข้อเท็จจริงที่ว่าข้อผิดพลาดเกิดขึ้นมากที่สุดที่ขอบเขต มันเหมือนกับการทดสอบ 17, 18, 19 แยกกันสำหรับขีดจำกัดอายุ 18 ปี
- ตารางการตัดสินใจ: การจัดตารางชุดค่าผสมของหลายเงื่อนไขและผลลัพธ์ที่คาดหวังของแต่ละชุด
- การเปลี่ยนสถานะ: การทดสอบการเปลี่ยนผ่านของระบบจากสถานะหนึ่งไปอีกสถานะหนึ่ง (เช่น คำสั่งซื้อ: สร้างแล้ว → ชำระเงิน → จัดส่งแล้ว) และการเปลี่ยนที่ไม่ถูกต้อง
ขั้นตอนที่ 3 — แยกสถานะบวก ลบ และเอดจ์ ขอการทดสอบเชิงบวก (ผลลัพธ์ที่คาดหวังด้วยอินพุตที่ถูกต้อง) การทดสอบเชิงลบ (ข้อผิดพลาดที่เหมาะสมพร้อมอินพุตที่ไม่ถูกต้อง) และกรณี Edge — เส้นเขตแดนหรือกรณีที่ผิดปกติ โดยทั่วไปแล้ว AI จะเน้นไปที่แง่บวก กรณีเชิงลบและกรณีขอบจะไม่สมบูรณ์เว้นแต่คุณจะร้องขออย่างชัดเจน
ขั้นตอนที่ 4 — จัดลำดับความสำคัญและตัดแต่ง AI สามารถสร้างสถานการณ์ได้ 60 สถานการณ์ พวกเขาไม่ได้มีมูลค่าเท่ากันทั้งหมด จัดลำดับความสำคัญของสิ่งที่มีความเสี่ยงสูง (เงิน ความปลอดภัย ข้อมูลสูญหาย) และรวมสิ่งที่ซ้ำกันเข้าด้วยกัน
เคล็ดลับ: ส่งคำขอแยกต่างหากไปยัง AI โดยระบุว่า "สร้าง 5 กรณี Edge ที่คิดไม่ถึงจากข้อกำหนดนี้" การสนับสนุนที่มีค่าที่สุดของ AI คือการที่ AI มักจะเตือนคุณถึงสถานการณ์พิเศษที่คุณมองข้ามไป
พรอมต์อ่อน / พรอมต์แข็งแกร่ง
จุดอ่อน: "เขียนกรณีทดสอบสำหรับการรีเซ็ตรหัสผ่าน"
แข็งแกร่ง: "สร้างกรณีทดสอบสำหรับคุณสมบัติ 'รีเซ็ตรหัสผ่าน' ด้วยเกณฑ์การยอมรับต่อไปนี้: ลิงก์ใช้ได้ 30 นาที ใช้ครั้งเดียว รหัสผ่าน 3 รายการสุดท้ายไม่สามารถนำมาใช้ซ้ำได้ บัญชีถูกล็อคเป็นเวลา 15 นาทีหลังจากพยายามไม่ถูกต้อง 5 ครั้ง ใช้คลาสที่เทียบเท่าและการวิเคราะห์ค่าขอบเขต ระบุกรณีบวก ลบ และขอบในหัวข้อแยกกัน สำหรับแต่ละกรณี: ID ข้อกำหนดเบื้องต้น ขั้นตอน ข้อมูลการทดสอบ ผลลัพธ์ที่คาดหวัง เกณฑ์การยอมรับที่เกี่ยวข้อง เน้นการใช้สถานการณ์การรักษาความปลอดภัย/การล็อค มัน”
พรอมต์อันทรงพลัง; โดยให้กฎ เทคนิค รูปแบบเอาต์พุต และลำดับความสำคัญ ดังนั้น AI จึงสร้างกรณีทดสอบที่ปฏิบัติการได้และตรวจสอบย้อนกลับได้ ไม่ใช่กรณีตกแต่ง
รูปแบบเอาต์พุตกรณีทดสอบ
ขอรูปแบบที่มีโครงสร้างซึ่งสามารถนำเข้าโดยตรงไปยังเครื่องมือการจัดการการทดสอบของทีมของคุณ (เช่น TestRail, Zephyr, Xray) ตารางต่อไปนี้แสดงส่วนประกอบของกรณีทดสอบที่ดี:
พื้นที่
คำอธิบาย
ตัวอย่าง
บัตรประจำตัวประชาชน
รหัสที่ไม่ซ้ำ
TC-PWD-014
ชื่อเรื่อง
วัตถุประสงค์โดยย่อ
ลิงก์ที่หมดอายุจะถูกปฏิเสธ
ข้อกำหนดเบื้องต้น
เงื่อนไขที่จำเป็นก่อนการทดสอบ
ลิงค์รีเซ็ตถูกสร้างขึ้นเมื่อ 31 นาทีที่แล้ว
ขั้นตอน
การดำเนินการตามลำดับ
1. คลิกที่ลิงค์ 2. ใส่รหัสผ่านใหม่
ข้อมูลทดสอบ
ค่าคอนกรีตที่ใช้
ลิงค์เก่า รหัสผ่านใหม่ "Abc!2345"
ผลลัพธ์ที่คาดหวัง
พฤติกรรมที่ต้องตรวจสอบ
เกิดข้อผิดพลาด "ลิงก์หมดอายุ" รหัสผ่านไม่เปลี่ยนแปลง
เกณฑ์การยอมรับ
ลิงค์ตรวจสอบย้อนกลับ
AK-3: ลิงก์ใช้ได้ 30 นาที
ลำดับความสำคัญ
ระดับความเสี่ยง
สูง
เทมเพลตที่สามารถคัดลอกได้สี่แบบ
1) การผลิตสถานการณ์ตามเทคนิค:
บทบาทของคุณ: ผู้ออกแบบการทดสอบอาวุโส สร้างกรณีการทดสอบสำหรับคุณลักษณะ: [คุณลักษณะและเกณฑ์การยอมรับ] นำไปใช้: คลาสที่เทียบเท่า การวิเคราะห์เบรกพอยต์ ตารางการตัดสินใจ ให้ผลลัพธ์เป็น 3 กลุ่ม: กรณีบวก / ลบ / Edge แต่ละกรณี: ID, เงื่อนไขเบื้องต้น, ขั้นตอน, ข้อมูลการทดสอบ, ผลลัพธ์ที่คาดหวัง, เกณฑ์การยอมรับที่เกี่ยวข้อง, ลำดับความสำคัญ (สูง/ปานกลาง/ต่ำ)
2) นักล่ากรณีขอบ:
รายชื่อเคส Edge ที่ปกติมักถูกมองข้าม 10 รายการสำหรับฟีเจอร์ต่อไปนี้: [ฟีเจอร์] เขียนในหนึ่งประโยคว่าเหตุใดจึงมีความเสี่ยงสำหรับแต่ละคน ลองคิดถึงแกนต่างๆ เช่น ว่างเปล่า/ว่าง อินพุตยาวเกินไป เกิดพร้อมกัน หมดเวลา ข้อผิดพลาดของรูปแบบ ยูนิโค้ด/อีโมจิ ลบ/ศูนย์ เครือข่ายขัดข้อง
3) การผลิตตารางการตัดสินใจ:
สร้างตารางการตัดสินใจสำหรับกฎทางธุรกิจต่อไปนี้: [กฎ].คอลัมน์: การรวมเงื่อนไข; แถว: แต่ละเงื่อนไขและการดำเนินการที่คาดหวัง ตั้งค่าสถานะชุดค่าผสมที่ไม่สามารถบรรลุผลสำเร็จหรือขัดแย้งกัน จากนั้นเสนอกรณีทดสอบสำหรับแต่ละชุดค่าผสม
4) การควบคุมการตรวจสอบย้อนกลับ:
ตามรายการเกณฑ์การยอมรับต่อไปนี้และกรณีทดสอบต่อไปนี้:[เกณฑ์] / [กรณี] แสดงในรูปแบบตารางว่ากรณีใดไม่ตรงตามเกณฑ์การยอมรับ (กรณีทดสอบซ้ำ) และกรณีใดไม่ตรงตามเกณฑ์ (กรณีซ้ำซ้อน)
มินิเคสสามอัน
กรณีที่ 1 — ค่าของสถานะขอบ ผู้เชี่ยวชาญจากทีมฟินเทคได้เขียนสคริปต์ 18 รายการสำหรับฟีเจอร์การโอนเงิน เขาใช้เทมเพลต “Edge Case Hunter” กับ AI; AI เตือนสถานการณ์ "ถ่ายโอนยอดคงเหลือเดียวกันจากอุปกรณ์สองเครื่องพร้อมกัน" (พร้อมกัน) เมื่อมีการทดสอบสถานการณ์นี้ พบช่องโหว่การใช้จ่ายสองเท่าและปิดก่อนที่จะใช้งานจริง สถานการณ์ขอบเดียวช่วยป้องกันการสูญเสียตัวเลขหกหลักได้
กรณีที่ 2 — ตัดส่วนนูนออก ทีมงานให้ AI สร้างสคริปต์แบบฟอร์มสมัครสมาชิก และผ่านไป 74 เคส การเรียกใช้เทมเพลตการตรวจสอบย้อนกลับพบว่ามี 74 กรณีที่มีคุณสมบัติตรงตามเกณฑ์การยอมรับเพียง 9 ข้อ โดยหลายกรณีมีการทดสอบซ้ำในระดับความเท่าเทียมกันเดียวกัน ชุดดังกล่าวลดลงจาก 74 เหลือ 23 คดีสำคัญ ระยะเวลาดำเนินการลดลง 68% ความครอบคลุมไม่ลดลง
กรณีที่ 3 — สมมติฐานที่ผิด AI แนะนำการทดสอบวันที่ไม่ถูกต้อง เช่น “31 กุมภาพันธ์” สำหรับช่องวันที่ แต่ไม่ทราบว่าองค์ประกอบปฏิทินที่ทีมใช้บล็อกสิ่งนี้ไว้แล้ว ผู้เชี่ยวชาญได้กำจัดสถานการณ์วันที่ 4 จาก 6 สถานการณ์ที่ AI สร้างขึ้นโดยไม่จำเป็นในบริบทของผลิตภัณฑ์ AI สร้างความเป็นไปได้ ได้ทำการเลือกข้อมูลผลิตภัณฑ์
ข้อผิดพลาดทั่วไป
- การขอสคริปต์โดยไม่ระบุเกณฑ์การยอมรับ โดยไม่รู้ว่าอะไรคือความจริง AI จะสร้างสถานการณ์ผิวเผินที่มักจะพลาดความเสี่ยงที่แท้จริง
- แค่ตกลงใจสำหรับการทดสอบเชิงบวก เห็นได้ชัดว่าไม่ต้องการกรณีเชิงลบและขอบ นี่คือจุดที่ข้อผิดพลาดมักเกิดขึ้น
- ยอมรับสิ่งที่ผลิตตามที่เป็นอยู่ โดยลืมไปว่า AI ไม่ทราบบริบทของผลิตภัณฑ์และทิ้งสถานการณ์ที่ไม่จำเป็นหรือเป็นไปไม่ได้ไว้ในฉาก
- ข้ามการตรวจสอบย้อนกลับ ไม่เชื่อมโยงกรณีต่างๆ กับเกณฑ์การยอมรับ จึงไม่เห็นว่าเกณฑ์ใดที่ไม่ได้รับการทดสอบ (coverage gap)
- การเข้าใจผิดเกี่ยวกับปริมาณ ดีใจเพราะ "60 สคริปต์ออกแล้ว" ค่าไม่ได้อยู่ที่ตัวเลขแต่อยู่ในขอบเขตที่ครอบคลุมความเสี่ยง
โดยสรุป
การออกแบบการทดสอบเป็นเรื่องเกี่ยวกับการแปลข้อกำหนดหนึ่งประโยคให้เป็นกรณีที่เป็นรูปธรรมและปฏิบัติการได้ ซึ่งพิสูจน์ความถูกต้องของซอฟต์แวร์ AI ช่วยเร่งการเปลี่ยนแปลงนี้อย่างมาก โดยจะสร้างพิมพ์เขียวที่ครอบคลุมเมื่อคุณให้เกณฑ์การยอมรับ เทคนิคการทดสอบแบบคลาสสิก (คลาสที่เทียบเท่า เบรกพอยต์ ตารางการตัดสินใจ การเปลี่ยนสถานะ) และรูปแบบผลลัพธ์ที่ชัดเจน แต่ AI มีอคติไปในทางบวก ไม่ทราบบริบทของผลิตภัณฑ์ และอาจทำให้เกิดการขยายตัวโดยไม่จำเป็นได้ งานของคุณคือการร้องขอกรณีเชิงลบและกรณีขอบอย่างชัดเจน สร้างการตรวจสอบย้อนกลับ จัดลำดับความสำคัญตามความเสี่ยง และตัดทิ้ง
งานสมัคร
เลือกคุณลักษณะจากโครงการของคุณเองและจดเกณฑ์การยอมรับ ให้ AI สร้างกรณีทดสอบด้วยเทมเพลต “การสร้างสถานการณ์ตามเทคนิค” จากนั้นใช้เทมเพลต “Edge Case Hunter” และ “การตรวจสอบย้อนกลับ” ผลลัพธ์ที่ได้คือ (1) เพิ่ม Edge Case อย่างน้อย 3 เคสที่ AI ข้ามไป (2) ตัดเคสที่ไม่เชื่อมโยงกับเกณฑ์การยอมรับใดๆ (3) เขียนเคสใหม่หากมีเกณฑ์การยอมรับที่ยังไม่ได้ทดสอบ เทชุดสุดท้ายลงในสเปรดชีต
รายการตรวจสอบ
- [ ] ก่อนที่จะขอสคริปต์ ฉันได้ชี้แจงเกณฑ์การยอมรับแล้ว
- [ ] ฉันถาม YZ เกี่ยวกับคลาสความเท่าเทียมกันและการวิเคราะห์ค่าขอบเขตตามชื่อ
- [ ] ฉันสร้างสถานะเชิงบวก ลบ และ Edge แยกกัน
- [ ] ฉันเชื่อมโยงแต่ละกรณีทดสอบกับเกณฑ์การยอมรับ (ตรวจสอบย้อนกลับ)
- [ ] ฉันตรวจสอบช่องว่างขอบเขตและกรณีที่ไม่จำเป็นกับตาราง
- [ ] ฉันจัดลำดับความสำคัญตามความเสี่ยงและตัดฉากที่บวมออก