AIEPCO · LLM Agent FDE☎ 18923740759
Aiepco AI Công nghiệp

Khi công cụ kiểm tra im lặng báo “đạt”

Công cụ phân tích tĩnh của chúng tôi đã báo “không phát hiện vấn đề” trên mã PLC trong nhiều tháng. Cho đến khi chúng tôi tạo một mẫu thử đầy lỗi cố ý — và phát hiện hai quy tắc chưa từng khớp với một dòng mã nào. Đây là bản mổ xẻ, kèm 8 điểm kiểm tra cho công cụ của bạn.

Kết luận ngắn

Một công cụ kiểm tra thất bại trong im lặng còn nguy hiểm hơn việc không có công cụ nào — nó cho bạn cảm giác an toàn giả. Quy tắc được viết trong tệp không đồng nghĩa với quy tắc thực sự chạy; giữa hai điều đó chỉ có một bước: kiểm chứng nó bằng một mẫu cố ý có lỗi.

Kết quả chạy bình thường trông như thế này

[motor_control_ref.scl]
  LOC=86 SLOC=61 comment_rate=27% McCabe~9 nesting=3 magic_numbers=0
  POU: FUNCTION_BLOCK FB200_MotorControl (line 11)
  Không phát hiện vấn đề tĩnh

Chúng tôi phát hiện như thế nào

Lúc đó chúng tôi đang viết một mẫu thử — tệp mã chứa đầy lỗi cố ý — để kiểm tra xem các quy tắc có thực sự hoạt động không. Kết quả khiến chúng tôi nhìn màn hình một lúc lâu: mẫu thử có #m_rB được dùng làm số chia, và truy cập mảng không kiểm tra biên như #m_Buffer[#i_Index]. Nhưng hai quy tắc “nguy cơ chia cho 0” và “nguy cơ truy cập mảng ngoài biên” không báo gì cả. Đọc mã mới thấy nguyên nhân: mẫu tìm “tên biến sau dấu gạch chéo” không tính đến việc biến cục bộ trong SCL có tiền tố #. Mã thực tế là #m_rA / #m_rB — sau dấu gạch chéo là khoảng trắng, rồi #, rồi mới đến tên biến, và # đã cắt mất phần khớp.

Hai quy tắc đó chưa từng khớp với bất kỳ dòng mã nào, kể từ ngày chúng được viết ra. Còn báo cáo thì vẫn luôn ghi “không phát hiện vấn đề tĩnh”.

Các trường hợp cùng loại: năm dạng thất bại

Không bao giờ kích hoạt
Hai quy tắc có mẫu khớp sai nên không khớp với mã nào — báo cáo trông không có gì bất thường
Quá rộng (báo sai)
VAR CONSTANT bị coi là biến tĩnh: cả 6 hằng số bị đánh dấu “tiền tố đặt tên không đúng chuẩn”
Nhiễu lấn át
Một khối chức năng báo 17 cảnh báo cùng loại; vấn đề thật bị chôn trong nhiễu
Phân tích sai
Đồ thị gọi hàm đọc ELSIF (...) như một lời gọi khối chức năng, làm sai phân tích độ sâu gọi
Tài liệu rời khỏi thực tế
Các script được tài liệu khung viện dẫn, ở thời điểm đó chưa cái nào tồn tại

Điểm chung của cả năm dạng: không dạng nào báo lỗi. Công cụ không sập, không ném ngoại lệ, không cảnh báo. Nó chỉ âm thầm đưa ra một kết luận sai.

Phát hiện thứ tư: có loại lỗi mà tầng tĩnh không thể thấy về mặt nguyên lý

6 / 6
Đột biến cú pháp / cấu trúc

Thiếu END_IF, thiếu dấu chấm phẩy, ngoặc không khớp, đặt tên sai quy ước, số ma thuật, xóa chú thích — đều bị phát hiện

0 / 6
Đột biến ngữ nghĩa (công bố chủ động)

Đổi AND thành OR, xóa NOT, đảo phép so sánh, sửa giá trị khởi tạo, xóa liên động — không phát hiện được cái nào

0.9981
Độ tương đồng văn bản sau khi làm sai

Đổi AND trong điều kiện khởi động thành OR (logic đảo hoàn toàn) vẫn đạt BLEU-4 gần như tuyệt đối

Đột biến ngữ nghĩa thậm chí có thể khiến mã trông “giống” bản tham chiếu hơn. Không công cụ dựa trên văn bản hay cấu trúc nào có thể nhìn thấy nó — nên chúng tôi ghi hạn chế đó vào báo cáo thay vì tô đẹp con số.

Kiểm tra tĩnh đạt ≠ biên dịch đạt ≠ logic đúng. Đó là ba câu phải nói tách ra, và tính đúng đắn ngữ nghĩa thuộc về kiểm chứng động (mô phỏng, đối chiếu quỹ đạo trên máy thật) cùng con người.

Ba nguyên tắc chúng tôi đặt ra

  • Mỗi quy tắc phải có mẫu “phải kích hoạt”: viết xong quy tắc thì tạo ngay mẫu chứa lỗi đó, khẳng định nó được báo ra, rồi cố định thành kiểm thử hồi quy
  • Mỗi quy tắc cũng phải có đối chứng “không được kích hoạt”: chạy trên mã đúng chuẩn và khẳng định không có cảnh báo — thiếu bước này, cả nhóm sẽ học cách bỏ qua mọi cảnh báo, tức là tương đương không kiểm tra
  • Công cụ phải tự chứng minh trước: 45 khẳng định tự kiểm, chạy vài giây; nếu tự kiểm không xanh toàn bộ thì không được dùng công cụ để đánh giá mã

Tự kiểm của công cụ trông như thế này

$ selftest_tools.py
khẳng định 45, thất bại 0
kết luận: ĐẠT — công cụ hoạt động đúng như công bố

8 điểm kiểm tra cho công cụ của bạn

  • Mỗi quy tắc có mẫu “phải kích hoạt” chưa? (Chưa → bạn không biết nó có chạy hay không)
  • Mỗi quy tắc có đối chứng “không được kích hoạt” chưa? (Chưa → nó có thể đang giết mã đúng)
  • Số lượng cảnh báo có hợp lý không? (17 cảnh báo cùng loại trong một tệp nghĩa là nhiễu, cả nhóm sẽ bỏ qua)
  • Khi công cụ thất bại, nó báo lỗi hay im lặng? Thất bại im lặng là loại nguy hiểm nhất
  • Có kiểm thử siêu cấp nào bảo vệ chính công cụ không? (Sửa A làm hỏng B là bình thường, không phải ngoại lệ)
  • Đã ghi rõ những việc công cụ “cố ý không làm” chưa? (Ranh giới không nói ra sẽ bị hiểu là làm được mọi thứ)
  • Mọi tệp được tài liệu dẫn chiếu có thực sự tồn tại không?
  • Trước chữ “đạt”, có một dòng nói rõ nó đạt ở tầng nào chưa?

Vì sao chúng tôi công bố điều này

Bài viết không có biểu đồ tăng trưởng, không có đường ROI — nó ghi lại việc công cụ của chính chúng tôi thất bại và được sửa. Chúng tôi công bố vì một niềm tin rất giản dị: nếu một nhà cung cấp còn không nói được công cụ kiểm tra của họ đã được kiểm chứng hay chưa, thì bạn càng không nên tin thứ họ bàn giao. Nói ba câu tách ra — kiểm tra tĩnh đạt, có biên dịch được hay không, logic có đúng hay không — hữu ích cho người trả tiền hơn một câu mơ hồ “chất lượng được bảo đảm”.

Giao chương trình nhà máy cho một quy trình có thể kiểm chứng