เมตาปรับปรุงการทดสอบหน่วยอัตโนมัติด้วยโมเดลภาษาใหญ่

 (arxiv.org)
2 คะแนน โดย GN⁺ 2024-02-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

เครื่องมือปรับปรุงการทดสอบหน่วยอัตโนมัติของเมตา: TestGen-LLM

  • TestGen-LLM ที่เมตาพัฒนาขึ้นใช้โมเดลภาษาใหญ่ (LLMs) เพื่อปรับปรุงเทสต์ที่มนุษย์เขียนไว้เดิมอย่างอัตโนมัติ
  • การทดสอบที่สร้างโดย TestGen-LLM ผ่านชุดตัวกรองที่รับประกันการปรับปรุงแบบวัดผลได้เหนือชุดเทสต์ดั้งเดิมได้สำเร็จ และแก้ปัญหา LLM hallucination
  • รายงานการนำ TestGen-LLM ไปใช้ใน test-a-thons สำหรับแพลตฟอร์ม Instagram และ Facebook ของเมตา

ประสิทธิภาพของ TestGen-LLM

  • ในการประเมินบน Instagram Reels และ Stories ของ Instagram, เทสต์เคสของ TestGen-LLM 75% สร้างขึ้นได้สำเร็จ, 57% ผ่านได้อย่างน่าเชื่อถือ, และ 25% ช่วยเพิ่มความครอบคลุม
  • ใน test-a-thons ของ Instagram และ Facebook ของเมตา, TestGen-LLM ปรับปรุง 11.5% ของคลาสที่ใช้ทั้งหมด และวิศวกรซอฟต์แวร์ของเมตายอมรับข้อเสนอแนะ 73% เพื่อนำไปใช้งานจริง
  • นี่คือรายงานครั้งแรกที่มีการนำโค้ดที่สร้างจาก LLM ไปใช้งานในระดับอุตสาหกรรม และได้รับการรับรองการปรับปรุงโค้ดเช่นนี้

ความคิดเห็นของ GN⁺

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-02-19
ความคิดเห็นบน Hacker News
  • ในบริษัทประกันรายใหญ่แห่งหนึ่ง ผู้จัดการตั้งเป้าหมาย coverage ของ codebase ทั้งหมดไว้ที่ 80% ทำให้นักพัฒนาหลายคนเริ่มเขียน unit test แบบง่ายๆ สำหรับ getter และ setter ของ Java DTO เพื่อให้ถึงเป้าหมาย ในฐานะนักพัฒนารุ่นใหม่ ประสบการณ์นี้สอนให้รู้ว่าถ้าสนใจแต่ KPI อย่างเดียวอาจทำให้เกิดพฤติกรรมที่ไม่สอดคล้องกับเป้าหมายที่ตั้งใจไว้ได้ กรณีทดสอบแบบ E2E ที่ออกแบบมาดีไม่กี่กรณีคงมีผลต่อคุณภาพซอฟต์แวร์ได้ดีกว่า
  • ปัญหาของการสร้างเทสต์ด้วย LLM คือมีโอกาสสูงที่มันจะ "อนุมัติ" พฤติกรรมที่มีบั๊ก โดยเฉพาะเมื่อ test coverage ของ codebase ค่อนข้างต่ำ เมื่อเขียนเทสต์ใหม่ด้วยมือ เรามักมีคนที่มองแล้วบอกได้ว่าระบบผิดปกติหรือเทสต์ที่เขียนไปผิดอยู่ และอย่างน้อยที่สุดเทสต์เหล่านี้ควรถูกแยกไว้ในโฟลเดอร์เทสต์เฉพาะเพื่อรับการตรวจสอบด้วยระดับความสงสัยที่เหมาะสม
  • จากการอ่าน PDF ดูแล้ว มันดูเหมือนแค่สร้างเทสต์ที่ผ่านซ้ำๆ แบบคงที่เป็นประจำ จุดประสงค์หลักคือการสร้าง regression test suite ที่ล็อกพฤติกรรมของโค้ดเดิม สิ่งนี้ไม่ใช่การแทนที่เทสต์ที่นักพัฒนาควรเขียนเอง โดยคาดหวังว่านักพัฒนาจะรู้ requirement เชิงฟังก์ชันอยู่แล้ว
  • ราว 20 ปีก่อนที่เคยทำงานอยู่ที่บริษัทหนึ่ง เราเคยลองใช้ AgitarOne ซึ่งสัญญาว่าจะสร้าง test case สำหรับโค้ด Java อัตโนมัติและช่วยสำรวจพฤติกรรม แต่ Agitar ก็สามารถสร้างเทสต์ที่ผ่านอัตโนมัติและนำไปใช้เป็น regression suite ได้เช่นกัน โดยส่วนตัวแล้วผมไม่ชอบแนวนี้เลย ผู้จัดการคิดว่าค่าของ test coverage สูงขึ้นคือคุณภาพดีขึ้นไปอีกเช่นกัน ผมจึงสงสัยว่าแนวทาง LLM จะดีเลิศกว่าที่ Agitar เสนอมากแค่ไหน
  • การเขียนเทสต์เป็นวิธีที่ดีมากในการประเมินคุณภาพโค้ดโดยรวม หากการเขียนเทสต์ซับซ้อนหรือเข้าถึง coverage ยาก เป็นไปได้สูงว่าตัวโค้ดที่ต้องทดสอบนั้นต้องได้รับการปรับปรุง
  • ที่ unlogged.io เคยโฟกัสพยายามสร้าง junit test อัตโนมัตินานาพอสมควร เหตุผลที่แนวทางนี้ไม่ประสบความสำเร็จมีหลายอย่าง: 1) โค้ดเทสต์ที่ถูก generate จำนวนมากและนักพัฒนาไม่อยากดูแลรักษา, 2) เทสต์ที่ถูก generate ไม่ได้จำลองสถานการณ์โลกจริง, 3) test coverage ในฐานะ vanity metric ปัจจุบันเรามุ่งเน้นให้บริการ no-code replay test ที่จำลอง production scenario ที่ไม่ซ้ำใครทั้งหมด โดยนอกเหนือจากนั้นผมเป็นผู้ก่อตั้งของ unlogged.io
  • ในทางกลับกันผมอยากได้วิธีแบบตรงข้าม คือใส่ acceptance criteria แล้วสร้างเทสต์ที่ยืนยันเงื่อนไขนั้น และต่อไปให้สร้างเฉพาะโค้ดที่ทำให้เทสต์ผ่านได้ เมื่อใช้ Copilot บางครั้งก็เข้าได้อย่างจำกัดแนวนี้ แต่ผมสงสัยว่าทำไมไม่ค่อยมีใครโฟกัสเรื่องนี้จริงจัง
  • TestGen-LLM เป็นสิ่งที่แปลกประหลาด ผมคิดว่ามันอาจใช้เป็นขั้นแรกของ refactor หรือ rewrite ได้ แต่การย้ำถึง test coverage ใน paper ดูเป็นแนวคิดที่เสียทีเดียว หากองค์กรใดมี mindset แบบนั้นอยู่แล้วและต้องการ coverage สูง มันอาจจะช่วยได้บ้าง แต่ TestGen-LLM จะไม่ทำให้โค้ดโปรเจกต์ดีขึ้นในทางใด และจะเพิ่ม friction ในการทำงานพัฒนาที่แท้จริงมากกว่า การพึ่งพา compiler errors และเทสต์ที่ล้มเหลวเพื่อตัดข้อมูลรันเดอร์จาก LLM ของ TestGen-LLM นั้น ควรจะมีประโยชน์กว่ามากหากสร้าง edge-case tests ที่ผ่านหรือไม่ผ่านได้ การที่ paper ไม่ได้ให้ตัวอย่างเทสต์ที่เกิดขึ้น ทำให้ผมสงสัยว่ามันน่าจะหื่นระดับ amateur เหมือน LLM-generated code ชิ้นอื่นๆ ที่ผมเคยเห็น
  • ผมอยากรู้ว่าหากดูแล test corpus ที่ generate อัตโนมัติในอนาคตขนาดมหึมาจะมีต้นทุนเท่าไร เราควรมีวิธีการอัตโนมัติในการ update ไม่ใช่แค่ generate case แต่รวมถึงการอัปเดตด้วย
  • ผมยอมรับว่าการที่ทีม Meta เผยแพร่ paper 12 หน้าเพื่อโปรโมต AI สำหรับนักพัฒนาเป็นเรื่องน่าสนใจมาก แม้กระทั่งใช้ Sankey diagram ด้วย ถึงจะอาจจะผิดพลาดบ้าง แต่ถ้าพรีเซนต์แบบนี้ ควรให้ข้อมูลที่ทำซ้ำได้ออกมาชัดเจนกว่านี้ไม่ใช่หรือ? เพราะ Meta ต้องมีข้อมูลที่ใช้เรียนรู้ได้จริง จึงอาจได้เปิดเผยอะไรบางอย่างไว้
  • ในการประเมินผล Reels และ Stories ของ Instagram เทสต์เคสของ TestGen-LLM มีถึง 75% ที่ถูกสร้างอย่างถูกต้อง, 57% ที่ผ่านอย่างเชื่อถือได้ และ 25% ที่เพิ่ม coverage ผมว่ามันไม่ใช่ผลลัพธ์ที่ดีนัก