Các trường hợp kiểm thử trình biên dịch hoặc cách kiểm thử trình biên dịch

Question

Các trình biên dịch giống như tất cả phần mềm, cũng dễ bị lỗi, lỗi logic.

Làm cách nào để xác thực đầu ra được tạo bởi trình biên dịch. Thông thường, câu hỏi của tôi là (là)

• Làm cách nào để xác thực rằng mã máy được tạo là chính xác?

• Cách đảm bảo rằng mã máy được tạo theo đặc tả ngôn ngữ.

• Có ý nghĩa khi chỉ cần chọn một dự án nguồn mở (trong C nếu một người viết một trình biên dịch trong C) để biên dịch nó thông qua "trình biên dịch". Trong trường hợp đó, làm thế nào để đánh giá rằng trình biên dịch hoạt động như mong đợi.

• Có bất kỳ trường hợp kiểm tra chính thức nào (văn học) do ủy ban tiêu chuẩn ngôn ngữ cung cấp mà trình biên dịch "tuân thủ ngôn ngữ" phải thỏa mãn không?

• Điều gì là chắc chắn "cung cấp cho aways" rằng vấn đề trong một chương trình được biên soạn bởi một biên dịch là lỗi trình biên dịch chứ không phải lỗi chương trình.

  - Bất kỳ ví dụ nào trong đó trình biên dịch chính thống bị nhầm lẫn và biên dịch mã sai?

Liên kết tới bất kỳ tài liệu nào sẽ được đánh giá cao.

Answer 1

Có một số bộ thử nghiệm trình biên dịch ở ngoài đó. Chúng tôi đã có một số may mắn bằng cách sử dụng bộ kiểm tra Plum Hall cho trình biên dịch C. Nó bao gồm một bộ mã C lớn được viết riêng để kiểm tra theo tiêu chuẩn ngôn ngữ. Nó xác minh rằng trình biên dịch có thể xử lý cú pháp và ngữ nghĩa ngôn ngữ.

Answer 2

Thực hành chung là tạo một tập hợp lớn các chương trình nhỏ mà mỗi chương trình trình bày một khía cạnh của trình biên dịch. Chúng sẽ bao gồm cả hai chương trình biên dịch và những chương trình không nên. Nói chung ASM sắp ra phía sau không được kiểm tra mà là chương trình được chạy và kiểm tra đầu ra của nó. Đối với làm thế nào để đảm bảo không có lỗi trong các trường hợp thử nghiệm: làm cho chúng nhỏ, như trong 5-10 dòng mỗi.

Các bộ kiểm tra này có thể rất lớn như trong hàng trăm đến hàng nghìn phép thử (ví dụ: an out of date test suite for the D programming language) và thường bao gồm một hoặc nhiều trường hợp kiểm tra cho mọi lỗi được báo cáo.

Answer 3

Có một số earlier question related to this for C, nhưng nó đi kèm với bộ kiểm tra trình biên dịch được viết cẩn thận.

Khi các trình biên dịch nhận được mã sai, tôi đã nhấn thường đủ trong sự nghiệp chuyên nghiệp của tôi, cảm ơn. Nó xảy ra ít hơn và ít hơn theo thời gian, nhưng I found a bug in MS C++ compilers targeting CLI tuần này.

Answer 4

Trình biên dịch Eiffel là mã nguồn mở và có một thư viện mở rộng các trường hợp thử nghiệm và các hợp đồng thiết kế nội bộ.

http://dev.eiffel.com

Answer 5

dãy phòng thử nghiệm tốt cho các ngôn ngữ thực sự là tốn kém để tạo ra và duy trì. Có một lý do mà the Plum Hall test suite, là tiêu chuẩn công nghiệp cho ANSI   C, quá đắt đỏ.

George Necula's translation validation là một ý tưởng tuyệt vời nhưng cũng khá tốn kém để triển khai.

Điều duy nhất rẻ và dễ dàng là: duy trì bộ kiểm tra hồi quy và mỗi lần bạn sửa lỗi trong trình biên dịch, đặt một thử nghiệm phù hợp vào bộ hồi quy. Với các trình biên dịch, không thể tin được làm thế nào để giữ lại cùng một lỗi một cách dễ dàng. Việc bổ sung kỷ luật vào bộ hồi quy của bạn sẽ ngăn chặn điều đó và chúng không tốn nhiều tiền.

Answer 6

Để có ý tưởng biên soạn một dự án mã nguồn mở lớn:

Bạn có thể tự mình thực hiện một dự án có bộ thử nghiệm. Sau đó, bạn biên dịch dự án và bộ kiểm thử của nó và xem thử nghiệm có vượt qua hay không. Để xác nhận các kết quả này, bạn biên dịch dự án và bộ kiểm thử bằng một trình biên dịch khác và chạy lại các kiểm thử.

Answer 7

GCC có bộ thử nghiệm khá lớn (https://gcc.gnu.org/onlinedocs/gccint/Testsuites.html#Testsuites). Nó có sẵn trên SCM: https://github.com/gcc-mirror/gcc/tree/master/gcc/testsuite