Có khung kiểm tra để phát triển phần mềm số không

Tôi thấy rằng rất nhiều chương trình khoa học tính toán của tôi có các yêu cầu kiểm tra không được bao gồm trong các khung kiểm tra tiêu chuẩn:

1. Kiểm tra thời gian tính toán

   • Để đảm bảo rằng các thuật toán không bị chậm hơn. Tôi có thể làm một cái gì đó tương tự assureSmallerEqual(RuntimeWrapper(algorithm),53)nhưng tôi muốn giảm ngưỡng 53 giây liên tục khi tôi đang làm việc với thuật toán, tức là một cái gì đó nhưassureSmallerEqual(RuntimeWrapper(algorithm),'previousbest+noisetolerance')

2. Kiểm tra năng suất

   • Để chắc chắn rằng một thuật toán trước đây tìm thấy một xấp xỉ tốt cho một giải pháp phân tích vẫn tìm thấy một giải pháp ít nhất là tốt hoặc tốt hơn. Một lần nữa, đây có thể là một mô phỏng của một bài kiểm tra tích hợp tiêu chuẩn, nhưng tôi muốn dung sai thu nhỏ liên tục vì thuật toán ngày càng tốt hơn. Hãy nghĩ đến việc thay thế assureAlmostEqual(foo(),1,places=3)bằngassureAlmostEqual(foo(),1,places='previousbest')

3. Kiểm tra yêu cầu vật lý

   • Để đảm bảo rằng các thuật toán đột nhiên không cần thêm bộ nhớ / dung lượng đĩa cứng. Rất giống với 1.

4. Kiểm tra yêu cầu trừu tượng

   • Để chắc chắn rằng một thuật toán hoạt động tốt với các xấp xỉ bậc hai không đột nhiên cần xấp xỉ bậc ba hoặc thuật toán hoạt động tốt với thời gian bước 0,1 không đột nhiên cần 0,01 cho sự ổn định. Một lần nữa, chúng có thể được mô phỏng bằng các thử nghiệm tích hợp tiêu chuẩn, nhưng mục tiêu là ghi nhớ tham số yêu cầu nhỏ nhất đã đạt được một mục tiêu nhất định, vì vậy điều này sẽ đòi hỏi rất nhiều cập nhật thủ công. Ví dụ: nếu foo(10)trước đây không có ngoại lệ, tôi muốn khung để đảm bảo foo(10)vẫn hoạt động và cũng thử nếu foo(9)bây giờ hoạt động (trong trường hợp đó tất cả các thử nghiệm trong tương lai sẽ đảm bảo foo(9)vẫn hoạt động).

Người ta có thể lập luận rằng những gì tôi yêu cầu không mô tả các thử nghiệm theo nghĩa của thử nghiệm đơn vị / tích hợp, ví dụ như thời gian chạy tăng, có thể được chấp nhận để đổi lấy các cải tiến khác.
Tuy nhiên, trong thực tế, tôi biết rằng tôi sẽ tiết kiệm được rất nhiều thời gian gỡ lỗi nếu tôi có chức năng kiểm tra ở trên, bởi vì trong 95% các trường hợp yêu cầu và hiệu suất bị lỗi do lỗi tôi đã giới thiệu. Thật vậy, tôi biết một thực tế là rất nhiều lỗi mà tôi đã tìm thấy (sau nhiều thời gian lãng phí khi kiểm tra mã của riêng tôi) với các thư viện phần mềm số bên ngoài có thể tránh được các thử nghiệm ở trên được áp dụng một cách nghiêm ngặt.

PS

Câu hỏi có tên tương tự /programming/34982863/framework-for-regression-testing-of-numerical-code không phải là một bản sao vì nó mô tả chức năng dễ dàng đạt được hơn với các khung kiểm tra hồi quy tiêu chuẩn.

Câu hỏi Chiến lược để thử nghiệm đơn vị và phát triển dựa trên thử nghiệm yêu cầu các chiến lược trái ngược với khung giúp triển khai chúng (và các chiến lược mà nó yêu cầu / được cung cấp trong các câu trả lời khác với những gì tôi mô tả ở đây, theo ý kiến ​​của tôi).

1. Loại thử nghiệm này đối với tôi được xác định kém vì điều kiện thử nghiệm của nó được gắn với máy cụ thể mà bạn đã thử nghiệm trong quá trình phát triển. Một trong những điểm kiểm tra là việc chạy thử nghiệm trên máy tính xách tay của tôi cho tôi biết liệu có lỗi gì với mã hoặc môi trường tôi đã thiết lập hay không. Thời gian 53 giây dành riêng cho máy phát triển của bạn và thời gian chạy cũng sẽ tăng nếu máy kiểm tra chịu tải từ các khối lượng công việc hoặc người dùng khác. Tôi không mong đợi các khung kiểm tra sẽ giải quyết vấn đề này: "chức năng chạy trên đầu vào dưới 53 giây" không phải là một thông số chính xác rất tốt.

2. Tôi nghĩ rằng điều này mơ hồ và không mong muốn từ quan điểm kiểm thử phần mềm vì những lý do tương tự 1 , bạn mất đi sự biện minh vượt qua hoặc thất bại cho kiểm thử phần mềm.

3. Điều này khá phổ biến, hãy để tôi mô tả một giải pháp. Đây không phải là công việc của khung kiểm tra, nhưng bạn có thể sử dụng một công cụ riêng như được mô tả trong câu hỏi Unix SE Giới hạn sử dụng bộ nhớ cho một quy trình Linux . Một công cụ tiêu chuẩn để thử đầu tiên là ulimitlệnh in bash, cho phép bạn chạy một quy trình và đảm bảo rằng nó gặp sự cố nếu nó cố gắng, ví dụ, phân bổ quá nhiều bộ nhớ. Vì vậy, nếu bạn chạy runteststập lệnh với giới hạn bộ nhớ, nó sẽ bị sập và khung kiểm tra có thể xử lý như một lỗi kiểm tra thông thường.

4. Hầu hết các khuôn khổ thử nghiệm không nghĩ về đơn vị kiểm tra theo cách này ở tất cả . Bộ kiểm thử được chạy (ví dụ: trước khi cam kết mã thành chủ hoặc trước khi triển khai) và kết quả là có hoặc không cho biết liệu nó có hoạt động hay không. Các khung kiểm tra không coi đó là một phần công việc của họ, ví dụ, theo dõi tiến trình tính năng và đó không phải là kiểm thử thường là gì. Những gì bạn làm ở đây là bạn viết hai bài kiểm tra expect_succeeds(foo(10)); expect_fails(foo(9)). Mỗi lần, cả hai bài kiểm tra đều được thực hiện, và những thành công và thất bại dự kiến ​​sẽ qua. Khi bạn thực hiện foo(9)và nó thành công, thử nghiệm thất bại bây giờ thất bại, vì vậy bạn viết lạiexpect_succeeds(foo(9))và đây là một tính năng hoàn toàn tiêu chuẩn của tất cả các khung. Nhưng bạn phải rõ ràng về những hành vi mà bạn mong đợi, bởi vì nếu không thì nó chỉ đi ngược lại quá nhiều so với những ý tưởng cơ bản của kiểm thử phần mềm.

$A$$A$$A$$B$performs_better(foo_A(), foo_B())$B$$A$$B$và (b) không còn ý nghĩa so sánh mã với cách sử dụng trước đây, tất cả các mã và kiểm tra hiện không thay đổi và không rõ ràng. Điều này tương tự về tinh thần với cách người ta có thể xử lý việc viết lại hệ thống.