กำไร:
- ความสามารถในการออกแบบบทบาทของปัญญาประดิษฐ์และจุดอนุมัติของมนุษย์ในขั้นตอน QA แบบ end-to-end จากแนวคิดไปสู่การเผยแพร่ในบริบทของ CI/CD
- ใน CI/CD ไม่อนุญาตให้ AI 'ผ่าน' การทดสอบโดยอัตโนมัติ แต่ใช้ข้อจำกัดในการปกป้องข้อมูลและคีย์ที่เป็นความลับ
- ความสามารถในการดำเนินการทดสอบความปลอดภัยภายในหน่วยงานและเพื่อวัตถุประสงค์ในการป้องกัน และนำหลักการการเปิดเผยข้อมูลอย่างมีความรับผิดชอบและความโปร่งใสทางจริยธรรมมาใช้
ในสิบหน่วยก่อนหน้านี้ เราใช้ AI ในแต่ละงาน: การสร้างสถานการณ์ โค้ดอัตโนมัติ การรายงานจุดบกพร่อง การวิเคราะห์ความครอบคลุม การทดสอบการกลายพันธุ์ หน่วยสุดท้ายนี้รวมทั้งหมดไว้ในเวิร์กโฟลว์ที่รับผิดชอบเดียว QA ยุคใหม่ไม่ใช่งานที่จบลงที่โต๊ะของบุคคลเพียงคนเดียว เป็นกระบวนการที่อยู่ใน CI/CD (การบูรณาการอย่างต่อเนื่อง / การจัดส่งอย่างต่อเนื่อง — ไปป์ไลน์ที่มีการรวมโค้ดอย่างต่อเนื่อง ทดสอบโดยอัตโนมัติ และเตรียมพร้อมสำหรับการเผยแพร่บ่อยครั้งและปลอดภัย) AI สามารถสัมผัสได้ทุกขั้นตอนของกระบวนการนี้ แต่เมื่อพลังของ AI เติบโตขึ้น ความสำคัญของการใช้ AI อย่างมีความรับผิดชอบก็เพิ่มขึ้นเช่นกัน ไม่ว่าจะเป็นความเป็นส่วนตัว อำนาจในการทดสอบความปลอดภัย จริยธรรม และที่สำคัญที่สุดคือการรักษาการตัดสินใจด้านคุณภาพโดยขึ้นอยู่กับมนุษย์ ในหน่วยนี้ คุณจะได้เรียนรู้การไหลและขอบเขตจากต้นทางถึงปลายทาง
โฟลว์ QA ที่ขับเคลื่อนด้วย AI แบบครบวงจร
บทบาทของ AI ในการเดินทางของฟีเจอร์จากแนวคิดสู่การเผยแพร่:
1. การวิเคราะห์ความต้องการ AI ตั้งค่าสถานะความคลุมเครือในข้อกำหนดและไม่มีเกณฑ์การยอมรับ ("กฎนี้ไม่ได้บอกว่ารหัสผ่านขั้นต่ำมีอักขระกี่ตัว")
2. การออกแบบการทดสอบ สถานการณ์จำลองและแบบร่างกรณีและปัญหา (หน่วยที่ 2) กรณีขอบ (หน่วยที่ 3) อยู่ในเกณฑ์การยอมรับ
3. ระบบอัตโนมัติ ร่างโค้ดทดสอบหน่วย (6), API (5) และ UI (4) แต่ละรายการได้รับการยืนยันโดยการกลายพันธุ์ (10)
4. การรวม CI/ซีดี การทดสอบทำงานโดยอัตโนมัติทุกครั้งที่มีการรวมโค้ด AI ร่างการกำหนดค่าไปป์ไลน์ (YAML) สรุปบันทึกการทดสอบที่ล้มเหลว แนะนำสาเหตุที่เป็นไปได้
5. การตัดสินใจปล่อยตัว ผลลัพธ์การวิเคราะห์ความเสี่ยง (8) และการถดถอย (9) จะถูกรวบรวม — แต่ผู้เชี่ยวชาญจะตัดสินใจว่าจะประสบความสำเร็จหรือไม่
6. การตรวจสอบการผลิตและข้อเสนอแนะ ข้อผิดพลาดในการถ่ายทอดสดกลายเป็นการทดสอบในอนาคต AI เสนอกรณีการถดถอยจากข้อบกพร่องในการผลิต
เคล็ดลับ: ตั้งค่า AI เป็นเลเยอร์ใน CI/CD ที่ “เร่งร่างฉบับร่างที่ตรวจสอบโดยมนุษย์” แทนที่จะ “เขียนการทดสอบและตัดสินใจ” การทดสอบที่สร้างขึ้นโดยอัตโนมัติไม่ควรเข้าสู่ไปป์ไลน์โดยปราศจากการตรวจสอบและอนุมัติจากเจ้าหน้าที่
AI ใน CI/CD: โดยที่ ใช่ และ ไม่ใช่
เวที
เอไอพอดี
มนุษย์เป็นสิ่งจำเป็น
ทดสอบโค้ดร่าง
ใช่
การแก้ไข + การกลายพันธุ์
ไปป์ไลน์ YAML แบบร่าง
ใช่
การรับรองความถูกต้อง + การตรวจสอบรหัสลับ
สรุปบันทึกล้มเหลว
ใช่
การยืนยันสาเหตุที่แท้จริง
การวินิจฉัยการทดสอบที่เปราะบาง
ใช่
การตัดสินใจแก้ไขอย่างถาวร
“มีเวอร์ชั่นมั้ย?”
ไม่
วิจารณญาณและความรับผิดชอบของผู้เชี่ยวชาญ
"ผ่าน" การทดสอบโดยอัตโนมัติ
ไม่เคย
—
ข้อควรระวัง: อย่าให้คำสั่งแก่ AI เช่น "แก้ไขเพื่อให้ผ่านการทดสอบที่ล้มเหลว" ใน CI/CD ซึ่งขัดต่อวัตถุประสงค์ของการทดสอบและปกปิดข้อผิดพลาดโดยอัตโนมัติ AI สามารถอธิบายข้อผิดพลาด แนะนำการแก้ไขได้ แต่การ “ทาสีเขียวทดสอบ” ต้องเป็นการตัดสินใจอย่างมีสติและมีเหตุผล
ความเป็นส่วนตัว ข้อมูล และความปลอดภัย: ขอบเขตที่ไม่เปลี่ยนแปลง
ความเป็นส่วนตัว ในสภาพแวดล้อมการทดสอบ ข้อมูลลูกค้าจริง สำเนาฐานข้อมูลการผลิต คีย์ API และข้อมูลระบบภายในถือเป็นข้อมูลที่ละเอียดอ่อน อย่ามอบสิ่งเหล่านี้ให้กับเครื่องมือ AI สาธารณะ ข้อมูลส่วนบุคคลอยู่ภายใต้ KVKK และกฎระเบียบที่คล้ายกัน บันทึกมาสก์และภาพหน้าจอ ใช้ข้อมูลการทดสอบสังเคราะห์ (สมมติ) เมื่อเป็นไปได้
การทดสอบความปลอดภัย — การป้องกันและได้รับอนุญาต การทดสอบความปลอดภัยที่เรียนรู้ในโมดูลนี้ (การทดสอบการอนุญาต/IDOR ขีดจำกัดการอัปโหลดไฟล์ การตรวจสอบอินพุต) มีไว้สำหรับการทดสอบผลิตภัณฑ์ของคุณเองภายในการอนุญาตเป็นลายลักษณ์อักษรและขอบเขตที่กำหนดไว้เท่านั้น การใช้ AI เพื่อเข้าถึงระบบของผู้อื่นโดยไม่ได้รับอนุญาต สร้างอาวุธให้กับช่องโหว่ที่แท้จริง หรือทำการทดสอบนอกขอบเขต ถือเป็นทั้งผิดหลักจริยธรรมและผิดกฎหมาย เมื่อคุณพบจุดอ่อนด้านความปลอดภัย ให้ปฏิบัติตามหลักการเปิดเผยอย่างมีความรับผิดชอบ โดยเก็บจุดอ่อนไว้เป็นความลับและรายงานไปยังฝ่ายที่เกี่ยวข้องเพื่อให้สามารถแก้ไขได้
จริยธรรมและความโปร่งใส อย่านำเสนอการทดสอบที่ผลิตโดย AI เป็นงานของคุณเอง การระบุว่าคุณกำลังใช้ AI ภายในทีมถือเป็นความโปร่งใส คุณต้องรับผิดชอบต่อความไม่ถูกต้องของเอาต์พุตที่ผลิตโดย AI - “AI เขียนมัน” ไม่ใช่ข้อแก้ตัว
พรอมต์อ่อน / พรอมต์แข็งแกร่ง
จุดอ่อน: "ตั้งค่าไปป์ไลน์ทดสอบสำหรับ CI"
แข็งแกร่ง: "ร่างเวิร์กโฟลว์ CI YAML สำหรับการดำเนินการ GitHub: รันหน่วย + การทดสอบ API ในแต่ละ PR, สร้างรายงานความครอบคลุม, รันการทดสอบการกลายพันธุ์ (Stryker) ทุกสัปดาห์ อย่าฝังความลับในโค้ด ใช้การอ้างอิงความลับเท่านั้น บล็อกการรวมหากการทดสอบเป็นสีแดง นี่คือแบบร่าง ฉันจะตรวจสอบและแก้ไขการจัดการคีย์ลับและขั้นตอนการตรวจสอบความถูกต้อง อย่าเพิ่มขั้นตอน 'แก้ไข' หรือ 'ย้าย' การทดสอบอัตโนมัติ "
พรอมต์อันทรงพลัง; โดยกำหนดข้อจำกัดในการรักษาความลับ การตรวจสอบโดยเจ้าหน้าที่ และ "ไม่มีการทดสอบอัตโนมัติ"
เทมเพลตที่สามารถคัดลอกได้สี่แบบ
1) แผนการทดสอบแบบครบวงจร:
บทบาทของคุณ: ผู้นำอาวุโส QA ร่างแผนการทดสอบตั้งแต่ต้นทางจนถึงปลายทางสำหรับคุณลักษณะต่อไปนี้: [คุณลักษณะ + เกณฑ์การยอมรับ] ขั้นตอน: การวิเคราะห์ข้อกำหนด (ความไม่แน่นอน) การออกแบบการทดสอบ เลเยอร์การทำงานอัตโนมัติ (หน่วย/API/UI) การรวม CI/CD เกณฑ์การตัดสินใจเผยแพร่ การติดตามการผลิต ระบุบทบาทของจุดอนุมัติ AI และ HUMAN ในแต่ละขั้นตอนแยกกัน
2) โครงร่างไปป์ไลน์ CI/CD:
ร่าง CI YAML สำหรับ [GitHub Actions/GitLab CI/Azure Pipelines]:- หน่วย + การทดสอบ API + ขอบเขตใน PR- ป้องกันการผสานในการทดสอบสีแดง- ค่าลับเฉพาะกับความลับเท่านั้น การฝังใน codeThis เป็นแบบร่าง; ฉันจะตรวจสอบขั้นตอนการจัดการและการอนุมัติที่สำคัญ การเพิ่มขั้นตอนการทดสอบการแก้ไขอัตโนมัติ/ผ่าน
3) การวิเคราะห์บันทึกการทดสอบล้มเหลว:
ในการพิมพ์ CI นั้น การทดสอบจะเป็นสีแดง ตรวจสอบบันทึก จัดกลุ่มความล้มเหลว แยกแยะสาเหตุที่เป็นไปได้ และสิ่งที่อาจเป็นความล้มเหลวที่แท้จริง และอาจเป็นปัญหาการทดสอบ/สภาพแวดล้อมที่เปราะบาง หากมีข้อมูลส่วนบุคคลให้ปิดบังไว้ การตัดสินใจและการแก้ไขจะเป็นของฉัน บันทึก: [วาง]
4) การตรวจสอบความปลอดภัย/ความเป็นส่วนตัวล่วงหน้า:
ก่อนที่จะส่งข้อมูล/บันทึกการทดสอบนี้ไปยังเครื่องมือ AI ให้ตรวจสอบว่ามีข้อมูลส่วนบุคคล, คีย์ API, ที่อยู่ระบบภายใน, ข้อมูลการผลิตหรือไม่ ระบุพื้นที่ใด (ถ้ามี) ที่จำเป็นต้องปิดบัง/ลบออก กำลังประมวลผลเหมือนเดิม เนื้อหา: [วาง]
มินิเคสสามอัน
กรณีที่ 1 — ความเร็วของการไหลจากต้นทางถึงปลายทาง ทีมหนึ่งจัดการฟีเจอร์ “การต่ออายุการสมัคร” ใหม่ด้วยโฟลว์แบบ end-to-end ที่ขับเคลื่อนโดย AI: ความไม่แน่นอนของข้อกำหนดถูกตั้งค่าล่วงหน้า การทดสอบสามชั้นที่ร่างไว้ และตรวจสอบความถูกต้องของการกลายพันธุ์ ซึ่งเชื่อมโยงกับ CI คุณลักษณะนี้ลดรอบการทดสอบซึ่งใช้เวลา 5 วันในกระบวนการแบบเดิมเหลือ 2 วัน แต่การอนุมัติจากมนุษย์ยังคงอยู่ทุกขั้นตอน และความไม่แน่นอนของข้อกำหนด (จะเกิดอะไรขึ้นหากการรีเฟรชล้มเหลว) ถูกปิดก่อนการเผยแพร่จริง
กรณีที่ 2 — กลับมาจากการรั่วไหลของกุญแจ นักพัฒนาซอฟต์แวร์ให้ AI สร้าง CI YAML และ AI ได้ฝังคีย์ API ที่ดูสมจริงลงใน YAML เป็นตัวอย่าง ขั้นตอน “การตรวจสอบความปลอดภัย/ความเป็นส่วนตัว” รวบรวมสิ่งนี้ คีย์ถูกแปลงเป็นการอ้างอิงข้อมูลลับ หากไม่มีขั้นตอนการตรวจสอบ คีย์จะรั่วไหลเข้าสู่การควบคุมเวอร์ชัน (ประวัติ git)
กรณีที่ 3 — ขีดจำกัดอำนาจ สมาชิกในทีมต้องการใช้การทดสอบ IDOR ที่เขาเรียนรู้กับระบบสดของพันธมิตรทางธุรกิจจาก "ฉันอยากรู้อยากเห็น" ผู้นำ QA หยุดทำงาน: การทดสอบความปลอดภัยบนระบบอื่นโดยไม่ได้รับอนุญาตเป็นลายลักษณ์อักษรและขอบเขตที่กำหนดไว้ถือเป็นสิ่งผิดกฎหมาย การทดสอบทำได้เฉพาะในสภาพแวดล้อมการทดสอบของผลิตภัณฑ์ของตนเองโดยได้รับอนุญาตเท่านั้น ฝ่ายที่รับผิดชอบแบบเปิดได้รับแจ้งไปยังทีมงานที่เกี่ยวข้อง
ข้อผิดพลาดทั่วไป
- ทำให้ AI ตัดสินใจเผยแพร่ ถามคำถามว่า “ปล่อยได้ไหม?” ให้กับ AI และใส่คำตอบแทนลายเซ็น
- "ผ่าน" การทดสอบอัตโนมัติ ใน CI ให้ AI ทาสีการทดสอบเป็นสีเขียว ปกปิดข้อผิดพลาด
- การให้ข้อมูล/กุญแจที่เป็นความลับแก่ตัวรถ การแชร์ข้อมูลการผลิต ข้อมูลส่วนบุคคล หรือคีย์ API โดยไม่มีการควบคุมดูแล
- การทดสอบความปลอดภัยโดยไม่ได้รับอนุญาต ผู้โจมตีทำการทดสอบบนระบบอื่นโดยไม่มีขอบเขตและการอนุญาต
- การแนะนำการทดสอบเข้าสู่ไปป์ไลน์โดยไม่มีการตรวจสอบ เรียกใช้ภาพร่าง AI โดยอัตโนมัติโดยไม่ต้องได้รับการอนุมัติจากมนุษย์
- โยนความผิดให้กับ AI ปกป้องเอาต์พุตที่ไม่ถูกต้องโดยพูดว่า "AI เขียนมัน"
โดยสรุป
QA แบบครบวงจรเป็นกระบวนการที่ขยายจากข้อกำหนดไปจนถึงการติดตามการผลิตและการใช้ชีวิตภายใน CI/CD ในทุกขั้นตอน AI จะสร้างแบบร่าง สรุปบันทึก และแนะนำสาเหตุที่แท้จริง แต่ขอบเขตนั้นไม่เปลี่ยนแปลง: มนุษย์ทำการตัดสินใจในการทดสอบและอนุมัติการปล่อย AI ไม่เคยได้รับอำนาจให้ "ผ่าน" การทดสอบโดยอัตโนมัติ ข้อมูลและกุญแจที่เป็นความลับจะไม่เข้าไปในรถ การทดสอบความปลอดภัยจะดำเนินการกับผลิตภัณฑ์ของคุณเองเท่านั้น ภายในการอนุญาตเป็นลายลักษณ์อักษรและขอบเขตที่กำหนดไว้ เพื่อวัตถุประสงค์ในการป้องกัน และการค้นพบจะถูกรายงานพร้อมการเปิดเผยอย่างมีความรับผิดชอบ มีความโปร่งใสเมื่อคุณใช้ AI คุณต้องรับผิดชอบต่อความถูกต้องของผลลัพธ์ AI เร่งความเร็ว คุณรับรองคุณภาพและจริยธรรม
งานสมัคร
ร่างแผนจากแนวคิดหนึ่งไปสู่การเผยแพร่ด้วยเทมเพลต “แผนการทดสอบตั้งแต่ต้นจนจบ” สำหรับฟีเจอร์จากโปรเจ็กต์ของคุณเอง ทำเครื่องหมายบทบาทของ AI และจุดอนุมัติของมนุษย์แยกกันในแต่ละขั้นตอน จากนั้นสร้าง YAML ด้วย “โครงร่างไปป์ไลน์ CI/CD” และใช้ “การตรวจสอบความปลอดภัย/ความเป็นส่วนตัวล่วงหน้า” กับ YAML นี้เพื่อตรวจสอบข้อมูลคีย์/ความลับที่ฝังอยู่ สุดท้าย ให้ระบุประเด็น "การตัดสินใจของมนุษย์" ทั้งหมดในแผนของคุณและให้เหตุผลในประโยคเดียวว่าเหตุใดการตัดสินใจเหล่านี้จึงไม่สามารถมอบหมายให้กับ AI ได้
รายการตรวจสอบ
- [ ] ฉันถือว่าการตัดสินใจปล่อยตัวและการทดสอบเป็นไปตามการอนุมัติของมนุษย์ ฉันไม่ได้มอบมันให้กับ AI
- [ ] ใน CI/CD ฉันไม่ได้ให้สิทธิ์ AI ในการ "ผ่าน/แก้ไข" การทดสอบโดยอัตโนมัติ
- [ ] ฉันตรวจสอบและปกปิดข้อมูลที่เป็นความลับ ข้อมูลส่วนบุคคล และกุญแจ ก่อนที่จะส่งไปที่รถ
- [ ] ฉันได้พิจารณาเฉพาะการทดสอบความปลอดภัยในผลิตภัณฑ์ของตัวเอง ภายใต้การอนุญาตและขอบเขตที่เป็นลายลักษณ์อักษร
- [ ] ฉันได้กล่าวถึงช่องโหว่ที่พบในหลักการของการเปิดเผยข้อมูลอย่างมีความรับผิดชอบ
- [ ] ฉันระบุอย่างโปร่งใสว่าฉันใช้ AI และรับผิดชอบต่อความถูกต้องของผลลัพธ์
การสอบโมดูล
1. 'การส่งผ่านเท็จ' มีการกำหนดไว้อย่างแม่นยำที่สุดในบริบท QA อย่างไร
- A) แม้ว่าการทดสอบจะเปลี่ยนเป็นสีเขียว แต่ก็ไม่ได้ยืนยันพฤติกรรมใดๆ จริงๆ ✔ไม่เปลี่ยนเป็นสีแดงแม้ว่ารหัสจะเสียหายก็ตาม
- B) การทดสอบดำเนินไปช้ามากและหมดเวลา
- C) การทดสอบตรวจพบข้อผิดพลาดจริงและเปลี่ยนเป็นสีแดง
- D) การทดสอบจะดำเนินการเฉพาะในสภาพแวดล้อมการผลิตเท่านั้น
คำอธิบาย: การผ่านหลอกคือเมื่อการทดสอบระบุว่า 'ผ่าน' แต่ไม่ได้ยืนยันสิ่งที่มีความหมายจริงๆ การทดสอบเป็นสีเขียว แต่แม้ว่าซอฟต์แวร์จะผิดพลาด แต่ก็ตรวจไม่พบ นี่เป็นความเสี่ยงอันดับหนึ่งของ AI ใน QA เนื่องจาก AI มีแนวโน้มที่จะสร้างการทดสอบที่ดูเรียบร้อยแต่กลวง
2. ตำแหน่งใดของปัญญาประดิษฐ์ที่แม่นยำที่สุดในการทดสอบและกระบวนการประกันคุณภาพ?
- ก) ปัญญาประดิษฐ์สามารถตัดสินใจได้ว่าเวอร์ชันดังกล่าวสามารถเผยแพร่ได้โดยไม่ต้องได้รับการอนุมัติจากมนุษย์หรือไม่
- B) ปัญญาประดิษฐ์เป็นผู้ช่วยที่สร้างแบบร่างและแนวคิด การตัดสินใจและความรับผิดชอบของ 'พร้อมตีพิมพ์หรือไม่' เป็นของผู้เชี่ยวชาญ ✔
- C) ปัญญาประดิษฐ์เขียนเพียงข้อความและไม่สามารถจัดการกับโค้ดทดสอบได้เลย
- ง) ปัญญาประดิษฐ์เขียนการทดสอบได้ถูกต้องกว่ามนุษย์เสมอ ดังนั้นจึงไม่จำเป็นต้องทบทวน
คำอธิบาย: ปัญญาประดิษฐ์เป็นผู้ช่วยทดสอบ ตัวสร้างแบบร่าง และตัวคูณความคิด สร้างสถานการณ์การทดสอบ รหัสอัตโนมัติ และร่างรายงาน อย่างไรก็ตาม ความรับผิดชอบและการอนุมัติขั้นสุดท้ายในการตัดสินใจด้านคุณภาพ เช่น 'ซอฟต์แวร์นี้พร้อมสำหรับการตีพิมพ์หรือไม่' หรือ 'ผ่านการทดสอบนี้แล้ว' เป็นของผู้เชี่ยวชาญที่มีความสามารถ
3. จากข้อเท็จจริงที่ว่าข้อผิดพลาดส่วนใหญ่เกิดขึ้นที่ค่าเกณฑ์ เทคนิคการออกแบบการทดสอบใดคือการทดสอบอายุ 17, 18 และ 19 ปีแยกกันสำหรับขีดจำกัดอายุ 18 ปี
- A) การทดสอบการเปลี่ยนสถานะ
- B) ตารางการตัดสินใจ
- C) การวิเคราะห์มูลค่าขอบเขต ✔
- D) การทดสอบเชิงสำรวจ
คำอธิบาย: การวิเคราะห์ค่าขอบเขตขึ้นอยู่กับการสังเกตว่าข้อผิดพลาดเกิดขึ้นบ่อยที่สุดที่ขอบเขตและทดสอบค่าเกณฑ์ (ต่ำกว่า สูงกว่าเล็กน้อย และสูงกว่าขีดจำกัดเล็กน้อย) แยกกัน เป็นเทคนิคอันทรงพลังที่ช่วยเสริมคลาสที่เท่าเทียมกัน
4. ควรเลือกใช้แนวทางใดในการเลือกองค์ประกอบเพื่อลดความเปราะบางในโค้ดอัตโนมัติการทดสอบ UI ที่สร้างด้วยปัญญาประดิษฐ์
- A) การใช้เส้นทาง XPath ที่ยาวที่สุดเท่าที่จะเป็นไปได้
- B) การเลือกองค์ประกอบตามตำแหน่งพิกเซลบนหน้าจอ
- C) การใช้ตัวเลือกตามชื่อคลาส CSS
- D) เพิ่มการใช้แอตทริบิวต์ที่เสถียร (data-testid) เพื่อการทดสอบ ✔
คำอธิบาย: พาธ XPath แบบยาวและชื่อคลาส CSS ขึ้นอยู่กับโครงสร้างและการออกแบบเพจเป็นอย่างมาก มันพังเมื่อมีการเปลี่ยนแปลงอินเทอร์เฟซเพียงเล็กน้อย คุณลักษณะที่เสถียรที่เพิ่มไว้สำหรับการทดสอบโดยเฉพาะ (เช่น data-testid) จะไม่ได้รับผลกระทบจากการเปลี่ยนแปลงการออกแบบ และทำให้การทดสอบมีประสิทธิภาพ
5. เหตุใดการทดสอบ API จึงไม่เพียงพอสำหรับการตรวจสอบรหัสสถานะ HTTP (เช่น 200)
- A) เนื่องจากข้อมูลร่างกายที่มีรหัสสถานะที่ถูกต้องอาจเสียหายและการตรวจสอบสถานะเพียงอย่างเดียวจะไม่จับสิ่งนี้ (หลอกเชื่อถือ) ✔
- B) เนื่องจากรหัสสถานะไม่น่าเชื่อถือเลยในการทดสอบ API
- C) เนื่องจากการตรวจสอบรหัสสถานะทำให้การทดสอบช้าลงมาก
- D) เนื่องจากรหัสสถานะจะไม่ถูกส่งกลับในการทดสอบ API
คำอธิบาย: แม้ว่าเซิร์ฟเวอร์ส่งคืนรหัสสถานะที่ถูกต้อง แต่อาจส่งคืนข้อมูลที่เสียหายในร่างกาย (ประเภทผิด ฟิลด์หายไป ค่าที่คำนวณไม่ถูกต้อง) การทดสอบที่มองแต่สถานการณ์จะไม่สามารถมองเห็นสิ่งนี้และทำให้เกิดความมั่นใจที่ผิดพลาดได้ ดังนั้นควรเพิ่มการตรวจสอบสคีมา/สัญญาและกฎเกณฑ์ทางธุรกิจด้วย
6. เหตุใดจึงสำคัญที่ต้องบอก AI ให้ 'คำนวณค่าที่คาดหวังด้วยตนเองตามกฎการยอมรับ ไม่ต้องอ้างอิงเอาต์พุตปัจจุบันของฟังก์ชัน' เมื่อทดสอบหน่วยการพิมพ์
- A) เนื่องจากการคำนวณด้วยตนเองทำให้การทดสอบเร็วขึ้น
- B) เพราะไม่เช่นนั้นการทดสอบจะยอมรับพฤติกรรมปัจจุบัน (อาจเป็นข้อผิดพลาด) ของโค้ดว่า 'ถูกต้อง' และยืนยันจุดบกพร่อง ✔
- C) เพราะปัญญาประดิษฐ์ไม่สามารถคำนวณเลขทศนิยมได้เลย
- D) เนื่องจากกฎการยอมรับไม่เคยถูกนำมาใช้ในการทดสอบ
คำอธิบาย: หาก AI ได้รับค่าที่คาดหวังจากเอาต์พุตของฟังก์ชันที่ทดสอบ จะทำให้การทดสอบ 'ผ่าน' แม้ว่าฟังก์ชันจะผิดพลาดก็ตาม นั่นคือไม่ว่าโค้ดจะผลิตอะไรก็ตาม การทดสอบจะนับเป็นจริง การคำนวณค่าที่คาดหวังโดยอิสระจากกฎการยอมรับทำให้แน่ใจได้ว่าการทดสอบเป็นตัวเฝ้าประตูของกฎ ไม่ใช่การจำลองโค้ด
7. ข้อใดต่อไปนี้เป็นคุณลักษณะที่โดดเด่นที่สุดของรายงานข้อบกพร่องที่ดี?
- A) ให้มีความยาวและมีเทคนิคมากที่สุด
- B) เขียนโดยปัญญาประดิษฐ์
- C) มีขั้นตอนการทำซ้ำตามที่กำหนดซึ่งนักพัฒนาสามารถปฏิบัติตามได้อย่างอิสระและก่อให้เกิดข้อผิดพลาด ✔
- D) มันเป็นเพียงภาพหน้าจอ
คำอธิบาย: คุณค่าที่แท้จริงของรายงานข้อบกพร่องคือ นักพัฒนาสามารถสร้างข้อผิดพลาดซ้ำได้โดยไม่ต้องอาศัยความช่วยเหลือจากคุณ ขั้นตอนการผลิตซ้ำที่กำหนดและตรวจสอบย้อนกลับได้ตั้งแต่ต้นทำให้มั่นใจในสิ่งนี้ หากขั้นตอนเหล่านี้หายไป รายงานมักจะปิดลงว่า 'ไม่สามารถผลิตได้'
8. ข้อใดเป็นการแสดงออกถึงความสัมพันธ์ระหว่างความรุนแรงและลำดับความสำคัญในกรณีที่สะกดชื่อบริษัทผิดในหน้าแรกได้ถูกต้องที่สุด
- A) ความเข้มข้นและลำดับความสำคัญควรมีค่าเท่ากันเสมอ
- B) ทั้งความรุนแรงและลำดับความสำคัญของข้อผิดพลาดนี้ต่ำมากอย่างแน่นอน
- C) ระดับความรุนแรงและลำดับความสำคัญเป็นแนวคิดเดียวกัน ป้ายกำกับเดียวก็เพียงพอแล้ว
- D) ความเข้มข้นทางเทคนิคอาจต่ำ แต่ลำดับความสำคัญทางธุรกิจ (ชื่อเสียง) อาจสูง ทั้งสองได้รับการประเมินต่างกัน✔
คำอธิบาย: ระดับความรุนแรงคือผลกระทบทางเทคนิคของข้อผิดพลาด (การพิมพ์ผิดทางเทคนิคต่ำ) ลำดับความสำคัญคือความเร่งด่วนในการแก้ไข (สูงเนื่องจากเป็นองค์ประกอบด้านชื่อเสียงที่ผู้เข้าชมทุกคนเห็น) ทั้งสองไม่ได้ไปในทิศทางเดียวกันเสมอไป ตัวอย่างนี้เป็นสถานการณ์ที่มีลำดับความสำคัญต่ำและมีลำดับความสำคัญสูง
9. ข้อใดคือการตีความชุดทดสอบที่มีความครอบคลุมบรรทัด 90% ที่แม่นยำที่สุด
- A) มันแสดงให้เห็นว่าบรรทัดถูกดำเนินการแต่ไม่ได้พิสูจน์ว่าบรรทัดเหล่านั้นทำงานอย่างถูกต้อง ✔การปกปิดสูงอาจสร้างความมั่นใจที่ผิดพลาดได้
- B) พิสูจน์ได้อย่างชัดเจนว่า 90% ของซอฟต์แวร์ไม่มีข้อบกพร่อง
- C) เป็นการวัดขั้นสุดท้ายของคุณภาพการทดสอบที่ยอดเยี่ยม
- D) บ่งชี้ว่าไม่จำเป็นต้องเขียนการทดสอบเพิ่มเติมอีกต่อไป
คำอธิบาย: ความครอบคลุมของแถวบ่งชี้ว่ามีการดำเนินการเฉพาะแถวเท่านั้น มันไม่ได้พิสูจน์ว่ามันให้ผลลัพธ์ที่ถูกต้อง แม้จะทดสอบแบบไม่มีการยืนยัน แต่ก็สามารถบรรลุความครอบคลุม 90% ได้ ขอบเขตเป็นแผนที่ 'ไม่เคยดูว่าอยู่ที่ไหน' ไม่ใช่การรับประกัน 'ทุกอย่างได้รับการทดสอบ' การป้องกันที่แท้จริงวัดโดยการทดสอบการกลายพันธุ์
10. ในการทดสอบตามความเสี่ยง ความเสี่ยงของคุณสมบัติจะถูกคำนวณเพื่อควบคุมความพยายามในการทดสอบที่จำกัดอย่างไร
- A) ตามจำนวนบรรทัดของโค้ดเท่านั้น
- B) โดยการคูณความน่าจะเป็นของความล้มเหลวและผลกระทบที่จะเกิดขึ้นเมื่อมันพัง✔
- C) เฉพาะตามลำดับที่คุณลักษณะได้รับการพัฒนาเท่านั้น
- D) จัดลำดับความสำคัญเฉพาะคุณลักษณะที่เขียนการทดสอบได้ง่ายที่สุด
คำอธิบาย: ในการทดสอบตามความเสี่ยง ความเสี่ยงจะถูกประเมินเป็นความน่าจะเป็น = ความน่าจะเป็น (โอกาสที่จะพัง) × ผลกระทบ (ความเสียหายหากแตกหัก) โดเมนที่มีความน่าจะเป็นสูงและมีผลกระทบสูง (การชำระเงิน การรับรองความถูกต้อง) สมควรได้รับการทดสอบที่เข้มข้นที่สุด ในขณะที่โดเมนต่ำ×ต่ำจะได้รับการทดสอบเล็กน้อย
11. อะไรคือความเสี่ยงหลักในการเพิ่มการลองซ้ำในการทดสอบที่บางครั้งผ่านและบางครั้งก็ล้มเหลว (เปราะ/ไม่สม่ำเสมอ) แม้ว่าโค้ดจะไม่มีการเปลี่ยนแปลงก็ตาม
- ก) ลดระยะเวลาการทดสอบให้สั้นลง
- B) ลดเปอร์เซ็นต์ความคุ้มครอง
- C) ปกปิดข้อผิดพลาดที่เกิดขึ้นพร้อมกันอย่างแท้จริงหรือสาเหตุที่แท้จริง และระงับอาการ ✔
- D) การเปลี่ยนชื่อการทดสอบ
คำอธิบาย: Retry เป็นเครื่องมือในการวินิจฉัย ไม่ใช่การรักษา ความไม่แน่ใจมักมาจากสภาพการแข่งขันหรือการเสพติดที่แท้จริง การทำให้การทดสอบ 'ผ่าน' โดยการลองอีกครั้งจะปกปิดข้อผิดพลาดที่แท้จริงนี้ และอาจทำให้เกิดปัญหาร้ายแรงในการถ่ายทอดสดได้ จะต้องค้นหาสาเหตุที่แท้จริงก่อน
12. การทดสอบการกลายพันธุ์ซึ่งเป็นวิธีการที่เที่ยงตรงที่สุดในการวัดว่าชุดทดสอบป้องกันได้จริงหรือไม่นั้นทำงานอย่างไร
- ก) โดยการวัดความเร็วในการวิ่งของการทดสอบ
- ข) โดยการนับจำนวนโค้ดที่เขียน
- C) โดยดำเนินการทดสอบในลำดับที่ต่างกัน
- D) โดยเจตนาสร้างการแตกโค้ดเล็กๆ น้อยๆ ในโค้ดและวัดว่าการทดสอบจับได้หรือไม่ ✔
คำอธิบาย: การทดสอบการกลายพันธุ์ทำให้เกิดการบิดเบือนโดยเจตนาเล็กน้อย (การกลายพันธุ์) ในซอร์สโค้ด ชุดทดสอบที่ดีควรตรวจจับความบิดเบี้ยวเหล่านี้และเปลี่ยนเป็นสีแดง การกลายพันธุ์ที่ตรวจไม่พบ (รอด) บ่งชี้ว่าการทดสอบไม่ได้รักษาพฤติกรรมนั้นไว้ คะแนนการกลายพันธุ์เป็นตัววัดคุณภาพที่ตรงไปตรงมามากกว่าเปอร์เซ็นต์ความครอบคลุม
13. ข้อจำกัดหลักที่ต้องปฏิบัติตามเมื่อทำการทดสอบความปลอดภัย (เช่น การทดสอบการอนุญาต/IDOR) คืออะไร?
- A) ควรทำในผลิตภัณฑ์ของตัวเองเท่านั้น โดยได้รับอนุญาตเป็นลายลักษณ์อักษรและขอบเขตที่กำหนดไว้ เพื่อวัตถุประสงค์ในการป้องกัน ✔
- B) สามารถนำไปใช้กับระบบที่สนใจได้อย่างอิสระ
- C) สามารถทดลองได้บนระบบสดของพันธมิตรทางธุรกิจโดยไม่ได้รับอนุญาต
- D) ช่องโหว่ใด ๆ ที่พบควรได้รับการเผยแพร่ต่อสาธารณะทันที
คำอธิบาย: การทดสอบความปลอดภัยที่เรียนรู้ในโมดูลนี้มีไว้เพื่อการทดสอบผลิตภัณฑ์ของคุณเองเพื่อวัตถุประสงค์ในการป้องกัน โดยอยู่ภายใต้การอนุญาตเป็นลายลักษณ์อักษรและขอบเขตที่กำหนดไว้ การเข้าถึงระบบของผู้อื่นโดยไม่ได้รับอนุญาตหรือการทดสอบนอกขอบเขตถือเป็นการกระทำที่ผิดจรรยาบรรณและผิดกฎหมาย ช่องโหว่ใด ๆ ที่พบจะถูกรายงานผ่านการเปิดเผยอย่างรับผิดชอบ
14. อำนาจใดที่ไม่ควรมอบให้แก่ AI ในไปป์ไลน์ CI/CD?
- A) การสรุปบันทึกการทดสอบที่ล้มเหลว
- B) สิทธิ์ในการ 'ผ่าน' การทดสอบที่ล้มเหลว (สีแดง) โดยอัตโนมัติหรือทาเป็นสีเขียว ✔
- C) การแนะนำแบบร่างรหัสทดสอบ
- D) การร่างไฟล์ YAML ไปป์ไลน์
คำอธิบาย: AI สามารถสร้างโครงร่างโค้ดทดสอบ ไปป์ไลน์ YAML และสรุปบันทึกใน CI/CD อย่างไรก็ตาม ไม่ควรให้ความสามารถในการ 'ผ่าน/แก้ไข' การทดสอบที่ล้มเหลวโดยอัตโนมัติ ซึ่งขัดต่อวัตถุประสงค์ของการทดสอบและปกปิดข้อผิดพลาดโดยอัตโนมัติ การทาสีกรีนทดสอบควรเป็นการตัดสินใจอย่างมีสติและมีเหตุผล