การสร้างการทดสอบด้วยปัญญาประดิษฐ์: การทดสอบหน่วย อินเทอร์เฟซ และระบบอัตโนมัติ

กำไร:

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

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

การทดสอบปิรามิด: จะทดสอบอะไรและเท่าไหร่

กลยุทธ์การทดสอบที่ดีนั้นมีลักษณะคล้ายกับปิรามิด ฐานประกอบด้วยการทดสอบหน่วยจำนวนมาก (การทดสอบด่วนที่ทดสอบฟังก์ชันเดียวหรือคลาสแยกกัน) รวดเร็วและราคาถูก ตรงกลางคือการทดสอบการบูรณาการน้อยกว่า (ทดสอบว่าหลายส่วนทำงานร่วมกันอย่างไร) ที่ด้านบนมีการทดสอบ UI/end-to-end ขั้นต่ำ (การทดสอบทำได้โดยการคลิกบนหน้าจอเหมือนกับที่ผู้ใช้ทำ) พวกมันสมจริงแต่ช้าและเปราะบาง AI ช่วยในทุกชั้น แต่คุณค่าสูงสุดอยู่ที่ฐาน นั่นคือสร้างการทดสอบหน่วยของตรรกะทางธุรกิจอย่างรวดเร็ว

ประเภทการทดสอบ

ขอบเขต

ความเร็ว

ประสิทธิภาพของเอไอ

การทดสอบหน่วย

ฟังก์ชั่นเดียว/คลาส

เร็วมาก

สูงมาก

บูรณาการ

อินเตอร์เลเยอร์

ปานกลาง

สูง

UI / จากต้นทางถึงปลายทาง

สตรีมหน้าจอทั้งหมด

ช้า

ปานกลาง (เปราะบาง)

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

ขั้นตอนการเขียนข้อสอบด้วย AI

1. กำหนดพฤติกรรมที่จะทดสอบ "ฟังก์ชันนี้ควรให้เอาต์พุตนี้แก่อินพุตนี้"
2. ระบุกรอบการทำงาน JUnit + MockK บน Android, XCTest บน iOS, Espresso (Android) หรือ XCUITest (iOS) สำหรับ UI
3. สอบถามสถานะขีดจำกัด สถานการณ์สมหวัง + ข้อผิดพลาด + จุดพัก
4. จัดการวัตถุจำลอง การพึ่งพาภายนอก เช่น เครือข่ายและฐานข้อมูลได้รับการจำลองเพื่อการทดสอบ (การจำลอง - การจำลองแบบควบคุม แทนที่จะเป็นบริการจริง)
5. เรียกใช้การทดสอบและตรวจสอบ การทดสอบผ่านการทดสอบ มันยืนยันสิ่งที่มีความหมายอย่างแท้จริงหรือไม่?

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

ข้อควรระวัง: เพียงเพราะ AI สามารถผลิตได้ไม่ได้หมายความว่าการทดสอบถูกต้อง บางครั้ง AI ยอมรับพฤติกรรมปัจจุบัน (อาจผิดพลาด) ของโค้ดว่า "ถูกต้อง" และเขียนการทดสอบตามนั้น การทดสอบดังกล่าวจะแก้ไขจุดบกพร่องแทนที่จะจับมัน คุณเป็นผู้กำหนดว่าการทดสอบคาดหวังอะไร บอก AI ว่าควรทำอะไร ไม่ใช่ว่าโค้ดทำอะไร

การทดสอบความครอบคลุมและความเข้าใจผิด

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

มินิเคสสามอัน

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

กรณีที่ 2 — การทดสอบปลอม ทีมหนึ่งรู้สึกโล่งใจที่จะเพิ่มความครอบคลุมเป็น 85% ด้วยการทดสอบ 40 หน่วยที่ผลิตโดย AI ในระหว่างการตรวจสอบ พบว่าการทดสอบส่วนใหญ่ไม่ได้ตรวจสอบเอาต์พุตใดๆ เลย พวกเขาเพียงแค่เรียกใช้ฟังก์ชันและเขียน assertTrue(true) ความครอบคลุมสูงแต่การป้องกันเป็นศูนย์ การทดสอบได้รับการแก้ไขและเขียนใหม่ด้วยการตรวจสอบความถูกต้องจริง บทเรียน: ตัวเลขความคุ้มครองสามารถโกหกได้

กรณีที่ 3 — การทดสอบ UI เร่งขึ้น ทีมอีคอมเมิร์ซเขียนสคริปต์ XCUITest ของขั้นตอนการเพิ่มสินค้าลงตะกร้าด้วย AI ภายใน 20 นาที หากเขียนด้วยมือจะใช้เวลาครึ่งวัน AI เดาตัวระบุองค์ประกอบหน้าจอ ทีมงานจับคู่พวกเขากับโค้ดจริงและแก้ไขพวกเขา ความเร็วร่างเป็นเรื่องจริง แต่การตรวจสอบตัวระบุเป็นงานของมนุษย์

พรอมต์อ่อน / พรอมต์แข็งแกร่ง

ข้อความแจ้งที่อ่อนแอ: "เขียนการทดสอบสำหรับฟังก์ชันนี้"

พร้อมท์ที่มีประสิทธิภาพ: "สร้างการทดสอบหน่วยสำหรับฟังก์ชัน Kotlin นี้ด้วย JUnit5 + MockK ฟังก์ชัน: การโอนเงิน (จำนวนเงิน แหล่งที่มา เป้าหมาย) พฤติกรรมที่จะทดสอบ (สิ่งที่โค้ดควรทำ): - การโอนที่ถูกต้องจะต้องสำเร็จ - จำนวนที่เป็นลบหรือเป็นศูนย์จะต้องถูกปฏิเสธ - จำนวนเงินที่มากกว่ายอดคงเหลือจะต้องถูกปฏิเสธ - ข้อผิดพลาดของเครือข่ายจะต้องส่งข้อยกเว้นที่เหมาะสม การทดสอบแต่ละครั้งควรตรวจสอบเพียงสิ่งเดียว ชื่อควรเป็นคำอธิบาย เยาะเย้ยบริการภายนอก อย่าเขียนการยืนยันที่ว่างเปล่า "

เทมเพลตที่คัดลอกได้

เทมเพลตการทดสอบหน่วย: "สร้างการทดสอบหน่วย [JUnit/XCTest] สำหรับฟังก์ชันนี้สำหรับ [ภาษา] พฤติกรรมที่คาดหวัง: [สิ่งที่ต้องทำ] รวม: สถานการณ์ที่มีความสุข การป้อนข้อมูลเป็นโมฆะ จุดพัก กรณีข้อผิดพลาด ปล่อยให้การทดสอบแต่ละครั้งตรวจสอบพฤติกรรมเดียว ใช้การยืนยันที่มีความหมาย เยาะเย้ย [รหัส]"

เทมเพลตการทดสอบ UI: "เขียนการทดสอบ UI ของโฟลว์ต่อไปนี้ด้วย [Espresso/XCUITest]: [โฟลว์ผู้ใช้ทีละขั้นตอน] เลือกองค์ประกอบหน้าจอที่มีรหัสการเข้าถึง ใช้รหัสแทนข้อความ เพิ่มกลยุทธ์การรอ เตือนฉันให้จับคู่รหัสองค์ประกอบกับรหัสจริง"

เทมเพลตการตรวจสอบการทดสอบ:"ตรวจสอบการทดสอบเหล่านี้:1) พวกเขาตรวจสอบผลลัพธ์/พฤติกรรมจริงหรือไม่ หรือเป็นโมฆะหรือไม่?2) ครอบคลุมกรณีจำกัดหรือไม่3) พวกเขาแก้ไขข้อผิดพลาดโค้ดหรือคาดหวังพฤติกรรมที่ถูกต้องหรือไม่ ตั้งค่าสถานะและเสริมความแข็งแกร่งให้กับการทดสอบที่อ่อนแอ [ทดสอบ]"

เทมเพลตการเพิ่มประสิทธิภาพความครอบคลุม: "ระบุส่วนที่ยังไม่ทดสอบของคลาสนี้และแนะนำการทดสอบที่มีความหมาย จัดลำดับความสำคัญเส้นทางที่มีความเสี่ยงที่แท้จริง ไม่ใช่แค่จำนวนการครอบคลุม [รหัส]"

ข้อผิดพลาดทั่วไป

• แค่ทดสอบสถานการณ์แห่งความสุข ข้อผิดพลาดจะถูกเก็บไว้ในสถานะจำกัด ถามพวกเขาอย่างเปิดเผย
• ยอมรับการทดสอบที่ว่างเปล่า/ไร้ประโยชน์ การทดสอบประเภท assertTrue(true) จะทำให้ขอบเขตกว้างขึ้นและไม่มีการป้องกัน
• ให้ AI ตรวจสอบสิ่งที่โค้ดกำลังทำอยู่ การทดสอบควรคาดหวังว่าโค้ดควรทำเช่นไร มิฉะนั้นจะแก้ไขข้อบกพร่อง
• การใส่หมายเลขขอบเขตผิดไปเพื่อจุดประสงค์ ความครอบคลุม 90% ไม่ได้หมายถึงความแม่นยำ 90%
• การลิงก์ไปยังข้อความในการทดสอบ UI การทดสอบล้มเหลวเมื่อข้อความเปลี่ยนแปลง ใช้ตัวระบุที่เสถียร (id)
• ตั้งค่าการเยาะเย้ยไม่ถูกต้อง "การทดสอบหน่วย" ที่เรียกใช้บริการจริงจะช้าและเปราะบาง

โดยสรุป

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

งานสมัคร

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

รายการตรวจสอบ

• [ ] ฉันเลือกเลเยอร์ที่เหมาะสมสำหรับปิรามิดทดสอบ (หน่วยลำดับความสำคัญ)
• [ ] ฉันต้องการกรณีขีดจำกัดและข้อผิดพลาดนอกเหนือจากสถานการณ์ที่มีความสุข
• [ ] ฉันตรวจสอบแล้วว่าการทดสอบแต่ละครั้งมีข้อยืนยันที่มีความหมาย
• [ ] ฉันบอก AI ว่าโค้ดควรทำอย่างไร ไม่ใช่สิ่งที่ควรทำ
• [ ] ฉันมุ่งเน้นไปที่เส้นทางความเสี่ยงที่แท้จริง ไม่ใช่จำนวนความคุ้มครอง
• [ ] ฉันใช้ตัวระบุที่เสถียรในการทดสอบ UI ฉันไม่ได้ผูกกับข้อความ