수치 소프트웨어 개발을위한 테스트 프레임 워크가 있습니까?

많은 계산 과학 프로그래밍에 표준 테스트 프레임 워크에서 다루지 않는 테스트 요구 사항이 있음을 발견했습니다.

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. 추상 요구 사항 테스트

   • 2 차 근사법으로 잘 수행 된 알고리즘에 입방 근사법이 갑자기 필요하지 않거나 시간 단계 0.1로 정교하게 수행 된 알고리즘에 안정성을 위해 0.01이 필요하지 않도록합니다. 다시, 이것들은 표준 통합 테스트에 의해 모방 될 수 있지만, 목표는 특정 목표를 달성 한 가장 작은 요구 사항 매개 변수가 무엇인지 기억하는 것이므로 많은 수동 업데이트가 필요합니다. 예를 들어, foo(10)이전에 예외가 발생하지 않았다면 프레임 워크에서 foo(10)여전히 작동 하는지 확인 하고 foo(9)지금 작동 하는지 확인하십시오 (이 경우 모든 향후 테스트에서 foo(9)여전히 작동 하는지 확인 ).

예를 들어 런타임 향상은 다른 개선 사항에 대한 대가로 수용 가능할 수 있기 때문에 내가 요구하는 것은 단위 / 통합 테스트의 의미에서 테스트를 설명하지 않는다고 주장 할 수 있습니다.
그러나 실제로 위의 테스트 기능이 있다면 많은 디버깅 시간을 절약 할 수 있다는 것을 알고 있습니다. 95 %의 사례에서 내가 소개 한 버그로 인해 요구 사항과 성능이 떨어졌기 때문입니다. 실제로, 외부 수치 소프트웨어 라이브러리에서 발견 한 많은 버그 (내 코드를 확인하는 데 많은 시간이 소요 된 후)가 위의 테스트가 엄격하게 적용되면 사소하게 피할 수 있다는 사실을 알고 있습니다.

추신

비슷한 이름의 질문 /programming/34982863/framework-for-regression-testing-of-numerical-code 는 표준 회귀 테스트 프레임 워크로보다 쉽게 ​​달성 할 수있는 기능을 설명하므로 중복되지 않습니다.

질문의 단위 테스트와 테스트 주도 개발을위한 전략 을 구현하는 데 도움이 프레임 워크 (그리고 답변에서 제공하는 내 의견으로는, 여기에서 설명하는 것보다 다른있다 / 대한이 묻는 전략)에 반대 전략을 요청합니다.

1. 이러한 유형의 테스트는 테스트 조건이 개발중인 테스트를 수행 한 특정 시스템과 연결되어 있기 때문에 제대로 정의되지 않은 것 같습니다. 테스트 포인트 중 하나는 랩톱에서 테스트를 실행하면 코드 또는 환경 설정에 문제가 있는지 알려줍니다. 53 초는 개발 시스템에 따라 다르며 테스트 시스템에 다른 워크로 드나 사용자가로드 한 경우 실행 시간도 늘어납니다. "프레임 워크가 53 초 안에 입력으로 실행된다"는 것은 올바른 정확성 사양이 아닙니다.

2. 나는 같은 이유로 소프트웨어 테스팅의 관점에서이 모호하고 바람직하지 않다고 생각한다. 1 , 당신 은 소프트웨어 테스팅에 대한 합격 또는 불합격을 잃는다.

3. 이것은 매우 일반적입니다. 하나의 솔루션을 설명하겠습니다. 테스트 프레임 워크의 역할은 아니지만 Unix SE 질문 단일 Linux 프로세스의 메모리 사용 제한에 설명 된대로 별도의 도구를 사용할 수 있습니다 . 가장 먼저 시도해야 할 표준 도구 중 하나는 ulimitin 명령 입니다.이 명령 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) 코드를 예전 방식과 비교할 수있는 감각이 없어졌으며, 이제 모든 코드와 테스트는 불변적이고 명확합니다. 이것은 시스템 재 작성을 처리하는 방법과 유사합니다.