Apakah ada kerangka kerja pengujian untuk pengembangan perangkat lunak numerik

Saya menemukan bahwa banyak pemrograman sains komputasi saya memiliki persyaratan pengujian yang tidak dicakup oleh kerangka uji standar:

1. Pengujian waktu komputasi

   • Untuk memastikan bahwa algoritma tidak menjadi lebih lambat. Saya bisa melakukan sesuatu seperti assureSmallerEqual(RuntimeWrapper(algorithm),53)tetapi saya ingin ambang 53 detik dikurangi terus menerus karena saya bekerja pada algoritma, yaitu sesuatu sepertiassureSmallerEqual(RuntimeWrapper(algorithm),'previousbest+noisetolerance')

2. Pengujian kinerja

   • Untuk memastikan bahwa suatu algoritma yang sebelumnya menemukan perkiraan yang baik untuk solusi analitis masih menemukan solusi yang setidaknya sama baiknya atau lebih baik. Sekali lagi, ini bisa ditiru oleh tes integrasi standar, tetapi saya ingin toleransi menyusut terus-menerus karena algoritme menjadi lebih baik dan lebih baik. Pikirkan untuk mengganti assureAlmostEqual(foo(),1,places=3)denganassureAlmostEqual(foo(),1,places='previousbest')

3. Pengujian persyaratan fisik

   • Untuk memastikan bahwa algoritma tidak tiba-tiba membutuhkan lebih banyak ruang memori / hard disk. Sangat mirip dengan 1.

4. Pengujian persyaratan abstrak

   • Untuk memastikan bahwa suatu algoritma yang melakukan baik dengan perkiraan kuadrat tidak tiba-tiba membutuhkan pendekatan kubik, atau suatu algoritma yang baik-baik saja dengan langkah waktu 0,1 tidak tiba-tiba membutuhkan 0,01 untuk stabilitas. Sekali lagi, ini dapat ditiru oleh tes integrasi standar, tetapi tujuannya adalah untuk mengingat apa parameter persyaratan terkecil yang mencapai tujuan tertentu, sehingga ini akan memerlukan banyak pembaruan manual. Misalnya, jika foo(10)sebelumnya tidak ada pengecualian, saya ingin kerangka memastikan foo(10)masih berfungsi dan juga coba jika foo(9)sekarang bekerja (dalam hal ini semua tes di masa depan akan memastikan foo(9)masih berfungsi).

Orang dapat berargumen bahwa apa yang saya minta tidak menggambarkan pengujian dalam arti pengujian unit / integrasi, karena peningkatan runtimes, misalnya, dapat diterima sebagai imbalan untuk perbaikan lainnya.
Namun dalam praktiknya, saya tahu bahwa saya akan menghemat banyak waktu debug jika saya memiliki fungsionalitas pengujian di atas, karena dalam 95% kasus persyaratan dan kinerja menjadi serba salah karena bug yang saya perkenalkan. Memang, saya tahu fakta bahwa banyak bug yang saya temukan (setelah banyak waktu terbuang untuk memeriksa kode saya sendiri) dengan pustaka perangkat lunak numerik eksternal dapat dihindari secara sepele seandainya tes di atas diterapkan dengan ketat.

PS

Pertanyaan dengan nama yang sama /programming/34982863/framework-for-regress-testing-of-numerical-code bukanlah duplikat karena menjelaskan fungsionalitas yang lebih mudah dicapai dengan kerangka pengujian regresi standar.

Pertanyaan Strategi untuk pengujian unit dan pengembangan berbasis tes meminta strategi yang bertentangan dengan kerangka kerja yang membantu mengimplementasikannya (dan strategi yang diminta / yang disediakan dalam jawaban berbeda dari apa yang saya jelaskan di sini, menurut pendapat saya).

1. Jenis tes ini bagi saya tidak didefinisikan dengan baik karena kondisi pengujiannya terkait dengan mesin tertentu tempat Anda melakukan pengujian dalam pengembangan. Salah satu poin pengujian adalah menjalankan pengujian pada laptop saya memberi tahu saya apakah ada yang salah dengan kode atau lingkungan yang saya atur. 53 detik khusus untuk mesin pengembangan Anda, dan waktu berjalan juga akan meningkat jika mesin pengujian sedang beban dari beban kerja atau pengguna lain. Saya tidak akan mengharapkan kerangka pengujian untuk mengatasi ini: "fungsi berjalan pada input di bawah 53 detik" tidak hanya spec kebenaran yang sangat baik.

2. Saya pikir ini ambigu dan tidak diinginkan dari sudut pandang pengujian perangkat lunak untuk alasan yang sama 1 , Anda kehilangan justifikasi lulus-atau-gagal untuk pengujian perangkat lunak.

3. Ini cukup umum, izinkan saya menjelaskan satu solusi. Ini bukan tugas kerangka pengujian, tetapi Anda dapat menggunakan alat terpisah seperti yang dijelaskan dalam pertanyaan Unix SE Batasi penggunaan memori untuk satu proses Linux . Salah satu alat standar untuk mencoba pertama adalah ulimitperintah di bash, yang memungkinkan Anda menjalankan proses dan memastikan crash jika mencoba, misalnya, mengalokasikan terlalu banyak memori. Jadi, jika Anda menjalankan runtestsskrip dengan batas memori, itu akan macet dan kerangka pengujian harus bisa mengatasinya sebagai kegagalan pengujian biasa.

4. Sebagian besar kerangka kerja pengujian tidak memikirkan unit test dengan cara ini sama sekali . Paket uji dijalankan (misalnya, sebelum melakukan kode untuk dikuasai atau sebelum digunakan), dan hasilnya adalah ya atau tidak yang menunjukkan apakah berfungsi. Kerangka kerja pengujian tidak menganggapnya sebagai bagian dari pekerjaan mereka, misalnya, melacak kemajuan fitur, dan bukan itu yang biasanya dilakukan pengujian. Apa yang akan Anda lakukan di sini adalah Anda akan menulis dua tes expect_succeeds(foo(10)); expect_fails(foo(9)). Setiap kali, kedua tes dijalankan, dan keberhasilan serta kegagalan yang diharapkan akan berlalu. Ketika Anda menerapkan foo(9)dan berhasil, tes mengharapkan-kegagalan sekarang gagal, sehingga Anda akan menulis ulangexpect_succeeds(foo(9)), dan ini adalah fitur yang sangat standar dari semua kerangka kerja. Tetapi Anda harus eksplisit tentang perilaku apa yang Anda harapkan, karena jika tidak, itu akan bertentangan dengan ide dasar pengujian perangkat lunak.

Ada pendekatan alternatif untuk semua ini. Anda mencoba untuk mendapatkan kerangka pengujian untuk melakukan pekerjaan ekstra dalam melacak kemajuan berulang kode Anda, tetapi kerangka kerja pengujian bekerja, dan diharapkan untuk bekerja, pada snapshot kode, memberikan jawaban lulus atau gagal. Mungkin lebih mudah untuk mengambil suatu algoritma , membuat test suite untuk seperti itu, kemudian membuat salinan lengkap dari disebut , harus menjalani tes , dan hanya tetap bekerja pada . Sekarang (a) kerangka pengujian kemudian tidak akan kesulitan membandingkan dan$A$$A$$A$$B$performs_better(foo_A(), foo_B())$B$$A$$B$, dan (b) tidak ada lagi rasa membandingkan kode dengan bagaimana dulu, semua kode dan tes sekarang tidak berubah dan tidak ambigu. Ini serupa dalam semangat dengan bagaimana seseorang dapat menangani penulisan ulang sistem.