Meta cải thiện kiểm thử đơn vị tự động bằng mô hình ngôn ngữ lớn

Công cụ cải thiện kiểm thử đơn vị tự động của Meta: TestGen-LLM

• Công cụ TestGen-LLM do Meta phát triển sử dụng các mô hình ngôn ngữ lớn (LLMs) để tự động cải tiến các kiểm thử trước đó do con người viết.
• Các lớp kiểm thử do TestGen-LLM tạo ra đã vượt qua thành công một loạt bộ lọc nhằm đảm bảo có sự cải tiến có thể đo lường được so với test suite gốc, nhờ đó giải quyết được vấn đề ảo giác của LLM.
• Bài viết mô tả việc triển khai TestGen-LLM trong các test-a-thons cho nền tảng Instagram và Facebook của Meta.

Đánh giá hiệu suất của TestGen-LLM

• Trong các bài đánh giá cho sản phẩm Reels và Stories của Instagram, 75% test case do TestGen-LLM tạo đã build thành công, 57% chạy thành công đáng tin cậy và 25% làm tăng độ phủ.
• Trong các test-a-thons của Instagram và Facebook tại Meta, TestGen-LLM cải thiện 11.5% tất cả các lớp được áp dụng, và kỹ sư phần mềm của Meta chấp nhận 73% đề xuất để triển khai.
• Đây là báo cáo đầu tiên về việc triển khai quy mô công nghiệp mã do LLM tạo ra và có lời cam kết cải thiện mã như vậy.

Ý kiến GN+

• TestGen-LLM là công cụ có thể mang lại thay đổi đột phá cho việc tự động hóa và nâng cao chất lượng kiểm thử phần mềm, thành công trong việc sử dụng LLM để cải tiến các kiểm thử hiện có.
• Công cụ này đóng góp quan trọng cho cộng đồng kỹ thuật phần mềm bằng cách tăng độ phủ kiểm thử trong môi trường doanh nghiệp thực tế và tạo ra các test case đáng tin cậy.
• Việc ứng dụng thành công trong các test-a-thons của Meta cho thấy TestGen-LLM có thể được tích hợp vào quá trình phát triển sản phẩm thực tế, mở ra tiến bộ quan trọng giúp nâng cao hiệu quả và độ ổn định trong phát triển phần mềm.

[GN⁺]

Ý kiến Hacker News

• Ở một công ty bảo hiểm lớn, ban quản lý đã đặt mục tiêu đạt 80% độ phủ kiểm thử cho toàn bộ codebase. Vì vậy các nhà phát triển bắt đầu viết các unit test đơn giản cho getter và setter của Java DTO để đạt mục tiêu đó. Với tư cách là một nhà phát triển trẻ, kinh nghiệm này khiến tôi nhận ra rằng nếu chỉ tập trung vào KPI thì có thể kích thích các hành vi không phù hợp với mục tiêu ban đầu. Một vài kịch bản kiểm thử E2E được thiết kế tốt có lẽ sẽ tác động tích cực hơn đến chất lượng phần mềm.
• Vấn đề của test do LLM tạo là chúng rất dễ "chấp nhận" hành vi có bug. Điều này đặc biệt có thể xảy ra khi độ phủ kiểm thử của codebase thấp. Khi viết test mới thủ công, vẫn có người để phán đoán xem hệ thống đang nguệch ngoạc hay test mới bị viết sai. Ít nhất, những test như vậy nên được tách vào một thư mục test riêng và được xử lý với mức độ hoài nghi hợp lý.
• Khi đọc bản PDF, tôi thấy đây dường như chỉ là việc tạo các test có tính chất lặp lại và luôn pass, tức là tương đối không thay đổi. Mục tiêu chính là tạo bộ regression test suite để cố định hành vi của mã hiện có. Nó không thay thế test do developer viết, bởi test viết bởi developer được kỳ vọng là nắm được yêu cầu chức năng.
• Khoảng 20 năm trước tại một công ty tôi từng làm, tôi đã thử AgitarOne. Nó hứa hẹn sẽ tạo test case tự động cho mã Java để giúp khám phá hành vi của mã đó. Nhưng Agitar cũng có thể tạo ra test tự động pass và dùng chúng như regression suite. Cá nhân tôi không thích chuyện đó. Ban lãnh đạo nghĩ rằng chất lượng tốt hơn chỉ vì coverage tăng. Tôi tò mò cách tiếp cận LLM tốt hơn Agitar tới mức nào.
• Viết test thường là cách rất hay để đánh giá chất lượng mã. Nếu test quá phức tạp hoặc khó đạt được coverage, có thể mã được kiểm thử cần phải được cải thiện.
• unlogged.io đã từng tập trung một thời gian vào việc tạo test JUnit tự động. Một số lý do khiến cách tiếp cận này không thành công: 1) quá nhiều mã test được sinh ra mà các developer không muốn duy trì, 2) test sinh ra không mô phỏng các kịch bản thế giới thực, 3) coverage code như một chỉ số phô trương. Hiện tại chúng tôi tập trung cung cấp no-code replay test để mô phỏng tất cả các kịch bản production duy nhất. Lưu ý, tôi là người sáng lập của unlogged.io.
• Tôi muốn tiếp cận ngược lại: nhập tiêu chí chấp nhận, sinh test để kiểm tra tiêu chí đó, rồi chỉ sinh ra code khi code đó pass test. Copilot đôi khi có thể tiếp cận gần như vậy theo một cách giới hạn; nhưng tôi băn khoăn vì sao không có người nào tập trung vào hướng này.
• TestGen-LLM là một sinh vật kỳ lạ. Tôi nghĩ nó có thể dùng như bước đầu tiên cho refactor hoặc rewrite, nhưng việc nhấn mạnh code coverage trong bài báo giống như một suy nghĩ bị lỗi hoàn toàn. Nếu một tổ chức đã đủ điên để đã yêu cầu coverage cao rồi thì có thể ổn, nhưng TestGen-LLM sẽ không cải thiện code của dự án theo bất kỳ cách nào và sẽ làm tăng ma sát liên quan khi triển khai cải tiến thực sự. Việc TestGen-LLM dựa vào lỗi compiler và test fail để lọc rác LLM thì hữu ích hơn nhiều nếu tạo ra các test case biên có thể pass hoặc fail. Vì bài báo không có ví dụ test sinh ra, tôi nghi ngờ chúng cũng giống như phần lớn mã do LLM sinh ra mà tôi đã thấy là amatuer.
• Tôi tò mò chi phí duy trì một corpus test khổng lồ được tạo tự động trong tương lai sẽ như thế nào. Cần có cách tự động để cập nhật, không chỉ tạo ra case.
• Nhận thấy thú vị là nhân viên Meta đã công bố một bài báo 12 trang để quảng bá AI cho developer. Họ thậm chí còn dùng cả sơ đồ Sankey. Có thể tôi sai, nhưng khi công bố theo cách này thì nên cung cấp thông tin có thể tái lập. Meta cần dữ liệu để học, nên có thể họ đã công khai một số thứ gì đó.
• Trong đánh giá sản phẩm Reels và Stories của Instagram, 75% test case của TestGen-LLM được xây dựng đúng, 57% pass một cách tin cậy, và 25% tăng coverage. Kết quả đó dường như không thật sự tốt, đúng không?