มีกรอบการทดสอบสำหรับการพัฒนาซอฟต์แวร์เชิงตัวเลขหรือไม่

ฉันพบว่าการเขียนโปรแกรมวิทยาศาสตร์ทางคอมพิวเตอร์ของฉันจำนวนมากมีข้อกำหนดการทดสอบที่ไม่ครอบคลุมโดยกรอบการทดสอบมาตรฐาน:

1. การทดสอบเวลาคำนวณ

   • เพื่อให้แน่ใจว่าอัลกอริทึมจะไม่ช้าลง ฉันสามารถทำสิ่งต่าง ๆ ได้เช่นกัน assureSmallerEqual(RuntimeWrapper(algorithm),53)แต่ฉันต้องการลดขีด จำกัด 53 วินาทีอย่างต่อเนื่องเนื่องจากฉันกำลังทำงานกับอัลกอริทึมassureSmallerEqual(RuntimeWrapper(algorithm),'previousbest+noisetolerance')

2. การทดสอบประสิทธิภาพ

   • เพื่อให้แน่ใจว่าอัลกอริทึมที่ก่อนหน้านี้พบว่าการประมาณค่าที่ดีสำหรับโซลูชันการวิเคราะห์ยังคงหาวิธีการแก้ปัญหาที่อย่างน้อยดีหรือดีกว่า อีกครั้งนี่อาจเป็นแบบจำลองโดยการทดสอบการรวมมาตรฐาน แต่ฉันต้องการความอดทนที่จะลดขนาดลงอย่างต่อเนื่องเนื่องจากอัลกอริทึมดีขึ้นและดีขึ้น คิดว่าการแทนที่assureAlmostEqual(foo(),1,places=3)โดยassureAlmostEqual(foo(),1,places='previousbest')

3. การทดสอบข้อกำหนดทางกายภาพ

   • เพื่อให้แน่ใจว่าอัลกอริธึมไม่ต้องการหน่วยความจำ / พื้นที่ฮาร์ดดิสก์เพิ่มเติม คล้ายกันมากกับ 1

4. การทดสอบความต้องการที่เป็นนามธรรม

   • เพื่อให้แน่ใจว่าอัลกอริทึมที่ทำงานได้ดีกับการประมาณกำลังสองไม่จำเป็นต้องใช้การประมาณแบบลูกบาศก์หรืออัลกอริทึมที่ทำงานได้ดีในขั้นตอนที่ 0.1 ไม่จำเป็นต้องมีเสถียรภาพ 0.01 ในทันที อีกครั้งสิ่งเหล่านี้อาจถูกจำลองโดยการทดสอบการรวมมาตรฐาน แต่เป้าหมายคือการจำว่าพารามิเตอร์ความต้องการที่เล็กที่สุดนั้นบรรลุเป้าหมายที่แน่นอนดังนั้นสิ่งนี้จะต้องมีการอัปเดตด้วยตนเองจำนวนมาก ตัวอย่างเช่นหากfoo(10)ก่อนหน้านี้ไม่มีข้อยกเว้นฉันต้องการให้เฟรมเวิร์กตรวจสอบว่าfoo(10)ยังใช้งานได้และลองfoo(9)ตอนนี้ใช้งานได้ (ในกรณีนี้การทดสอบในอนาคตทั้งหมดจะfoo(9)ยังคงใช้ได้)

หนึ่งอาจโต้แย้งว่าสิ่งที่ฉันขอไม่ได้อธิบายการทดสอบในแง่ของการทดสอบหน่วย / บูรณาการตั้งแต่ runtimes ที่เพิ่มขึ้นเช่นอาจเป็นที่ยอมรับในทางกลับกันสำหรับการปรับปรุงอื่น ๆ
อย่างไรก็ตามในทางปฏิบัติฉันรู้ว่าฉันจะประหยัดเวลาในการดีบักได้มากถ้าฉันมีฟังก์ชั่นการทดสอบด้านบนเพราะใน 95% ของข้อกำหนดกรณีและประสิทธิภาพลดลงเพราะข้อผิดพลาดที่ฉันแนะนำ แน่นอนฉันรู้ว่ามีข้อบกพร่องมากมายที่ฉันพบ (หลังจากเสียเวลามากในการตรวจสอบรหัสของฉัน) ด้วยห้องสมุดซอฟต์แวร์เชิงตัวเลขภายนอกสามารถหลีกเลี่ยงได้เล็กน้อยหากการทดสอบข้างต้นถูกนำไปใช้อย่างจริงจัง

PS

คำถามที่มีชื่อคล้ายกัน/programming/34982863/framework-for-regression-testing-of-numerical-codeไม่ซ้ำกันเนื่องจากอธิบายการทำงานที่ทำได้ง่ายขึ้นด้วยกรอบการทดสอบการถดถอยมาตรฐาน

คำถามกลยุทธ์สำหรับการทดสอบหน่วยและการพัฒนาขับเคลื่อนทดสอบขอกลยุทธ์เมื่อเทียบกับกรอบที่ช่วยในการดำเนินการพวกเขา (และกลยุทธ์ที่ขอ / ที่ให้ไว้ในคำตอบนั้นแตกต่างจากสิ่งที่ฉันอธิบายที่นี่ในความคิดของฉัน)

1.การทดสอบประเภทนี้ดูเหมือนว่าฉันจะถูกกำหนดอย่างไม่ดีเนื่องจากสภาพการทดสอบนั้นเชื่อมโยงกับเครื่องเฉพาะที่คุณทำการทดสอบในการพัฒนา หนึ่งในประเด็นของการทดสอบคือการใช้การทดสอบบนแล็ปท็อปของฉันบอกฉันว่ามีบางอย่างผิดปกติกับรหัสหรือสภาพแวดล้อมที่ฉันตั้งค่า 53 วินาทีนั้นขึ้นอยู่กับเครื่องพัฒนาของคุณและเวลาในการทำงานจะเพิ่มขึ้นหากเครื่องทดสอบนั้นมีภาระงานจากภาระงานหรือผู้ใช้อื่น ฉันไม่คาดหวังว่าจะทำการทดสอบเฟรมเวิร์กเพื่อจัดการกับสิ่งนี้: "ฟังก์ชั่นทำงานกับอินพุตในเวลาไม่เกิน 53 วินาที" เป็นเพียงข้อมูลจำเพาะความถูกต้องที่ไม่ดีมาก

2ฉันคิดว่าสิ่งนี้คลุมเครือและไม่พึงประสงค์จากมุมมองของการทดสอบซอฟต์แวร์ด้วยเหตุผลเดียวกัน1คุณสูญเสียเหตุผลที่ผ่านหรือล้มเหลวสำหรับการทดสอบซอฟต์แวร์

3.นี่เป็นเรื่องธรรมดามากฉันขออธิบายวิธีหนึ่ง ก็ไม่เชิงการทำงานของกรอบการทดสอบ แต่คุณสามารถใช้เครื่องมือแยกต่างหากที่อธิบายไว้ในคำถาม Unix SE ใช้หน่วยความจำ จำกัด สำหรับลินุกซ์เป็นกระบวนการเดียว เครื่องมือมาตรฐานอย่างหนึ่งที่ต้องลองก่อนคือulimitคำสั่งbashซึ่งช่วยให้คุณสามารถเรียกใช้กระบวนการและตรวจสอบให้แน่ใจว่ามันล้มเหลวถ้ามันพยายามเช่นจัดสรรหน่วยความจำมากเกินไป ดังนั้นหากคุณเรียกใช้runtestsสคริปต์โดยมีการ จำกัด หน่วยความจำสคริปต์จะหยุดทำงานและกรอบการทดสอบควรจะสามารถจัดการกับข้อผิดพลาดในการทดสอบปกติได้

4.กรอบการทดสอบส่วนใหญ่ไม่คิดว่าการทดสอบหน่วยด้วยวิธีนี้ในทุก ชุดทดสอบรัน (เช่นก่อนที่จะส่งมอบรหัสให้เป็นมาสเตอร์หรือก่อนที่จะนำไปใช้งาน) และผลลัพธ์คือใช่หรือไม่ระบุว่าจะทำงานหรือไม่ กรอบการทดสอบไม่ได้พิจารณาว่าเป็นส่วนหนึ่งของงานของพวกเขาเช่นติดตามความคืบหน้าของคุณลักษณะและนั่นไม่ใช่สิ่งที่ทดสอบโดยทั่วไป สิ่งที่คุณจะทำที่นี่คือคุณจะต้องทำการทดสอบสองexpect_succeeds(foo(10)); expect_fails(foo(9))ครั้ง แต่ละครั้งมีการทดสอบทั้งสองแบบและความสำเร็จและความล้มเหลวที่คาดว่าจะเกิดขึ้น เมื่อคุณติดตั้งfoo(9)และใช้งานได้สำเร็จการทดสอบที่คาดว่าจะล้มเหลวจะล้มเหลวดังนั้นคุณจึงต้องเขียนใหม่expect_succeeds(foo(9))และนี่เป็นคุณสมบัติมาตรฐานอย่างแน่นอนของทุกเฟรมเวิร์ค แต่คุณต้องมีความชัดเจนเกี่ยวกับพฤติกรรมที่คุณคาดหวังเพราะไม่เช่นนั้นจะขัดกับแนวคิดพื้นฐานของการทดสอบซอฟต์แวร์มากเกินไป

$A$$A$$A$$B$performs_better(foo_A(), foo_B())$B$$A$$B$และ (b) ไม่มีความรู้สึกใด ๆ ของการเปรียบเทียบโค้ดกับวิธีที่เคยเป็นมาอีกต่อไปตอนนี้โค้ดและการทดสอบทั้งหมดไม่เปลี่ยนรูปและไม่คลุมเครือ สิ่งนี้มีความคล้ายคลึงกันกับวิธีที่คน ๆ หนึ่งอาจจัดการกับการเขียนระบบใหม่