Как протестировать научное программное обеспечение?

Question

Я убежден, что тестирование программного обеспечения действительно очень важно, особенно в науке. Однако за последние 6 лет я никогда не сталкивался с каким-либо научным программным проектом, который проводился регулярно (большинство из них даже не контролировалось версией).

Теперь мне интересно, как вы справляетесь с тестированием программного обеспечения для научных кодов (числовые вычисления).

С моей точки зрения, стандартные модульные тесты часто пропускают точку, поскольку нет точного результата, поэтому использование assert(a == b) может оказаться немного сложным из-за «нормальных» числовых ошибок.

Так что я с нетерпением жду ваших размышлений об этом.

Answer 1

Я также в научных кругах, и я написал квантовые программы механического моделирования, которые должны выполняться на нашем кластере. Я сделал то же самое наблюдение относительно тестирования или даже контроля версий. Я был еще хуже: в моем случае я использую C++-библиотеку для своих симуляций, а код, который я получил от других, - это чистый код спагетти, отсутствие наследования, даже функции.

Я переписал его, и я также внедрил некоторые модульные тесты. Вы правы, что вам приходится иметь дело с числовой точностью, которая может отличаться в зависимости от архитектуры, в которой вы работаете. Тем не менее, единичное тестирование возможно, если вы учитываете ошибки численного округления. Ваш результат не должен зависеть от округления числовых значений, иначе у вас будет другая проблема с надежностью вашего алгоритма.

Итак, в заключение я использую модульное тестирование для своих научных программ, и это действительно делает более уверенным в результатах, особенно в отношении публикации данных в конце.

Answer 2

Пожалуйста, обратите внимание на ответы на так вопрос How to use TDD correctly to implement a numerical method?

Answer 3

Я также использую cpptest для своего TEST_ASSERT_DELTA. Я пишу высокопроизводительные численные программы в вычислительной электромагнетике, и я с удовольствием использовал его в своих программах на C++.

Я обычно идти о тестировании научного кода точно так же, как и я с любым другим видом кода, только несколько ретушей, а именно:

• Я всегда проверить свои цифровые коды для случаев, которые делают не физический смысл и убедитесь, что вычисление фактически прекратилось до получения результата. Я усвоил это с трудом: у меня была функция, которая вычисляла некоторые частотные ответы, а затем снабжала матрицу, построенную с ними, другой функцией в качестве аргументов, которые в конечном итоге дали свой ответ одному вектору. Матрица могла быть любого размера в зависимости от того, сколько терминалов было применено к сигналу, но моя функция не проверяла, соответствовал ли размер матрицы количеству терминалов (2 терминала должны были означать матрицу 2 x 2 x n); однако сам код был обернут, чтобы не зависеть от этого, ему не важно, какой размер матрицы был, так как ему просто нужно было выполнить некоторые основные операции с матрицами. В конце концов, результаты были совершенно правдоподобными, хорошо в пределах ожидаемого диапазона и, по сути, частично правильные - только половина вектора решения исказилась. Мне потребовалось некоторое время, чтобы понять. Если ваши данные выглядят корректно, они собраны в правильной структуре данных, а числовые значения хороши (например, нет NaN или отрицательного числа частиц), но это не имеет физического смысла, функция должна изящно терпеть неудачу.

• Я всегда проверяю процедуры ввода-вывода, даже если они просто читают кучу номеров, разделенных запятыми, из тестового файла.Когда вы пишете код, который выполняет скрученную математику, всегда возникает соблазн перейти к отладке части кода, который настолько тяжеловесен, что вам нужен толчок кофеина, чтобы понять символы. Через несколько дней вы понимаете, что вы также добавляете значение ASCII от \n к вашему списку пунктов.

• При тестировании математического отношения я всегда проверяю его «по книге», и я также изучил это на примере. Я видел код, который должен был сравнивать два вектора, но проверял только на равенство элементов и не проверял равенство длины.

Answer 4

Просто посмотрел на аналогичную проблему (google: «тестирование научного программного обеспечения») и придумал несколько статей, которые могут представлять интерес. Они охватывают как ошибки мирские кодирования и большие проблемы познания, если результат даже прямо

http://http.icsi.berkeley.edu/ftp/pub/speech/papers/wikipapers/cox_harris_testing_numerical_software.pdf

http://www.cs.ua.edu/~SECSE09/Presentations/09_Hook.pdf (неработающую ссылку, новая ссылка http://www.se4science.org/workshops/secse09/Presentations/09_Hook.pdf) (глубина мантии Земли?)

http://www.associationforsoftwaretesting.org/?dl_name=DianeKellyRebeccaSanders_TheChallengeOfTestingScientificSoftware_paper.pdf

Я думал, что идея тестирования мутаций, описанная в 09_Hook.pdf (см. Также matmute.sourceforge.net), особенно интересна, поскольку она имитирует простые ошибки, которые мы все делаем. Самая сложная часть - научиться использовать статистический анализ для уровней доверия, а не обзоры кода одного прохода (человек или машина).

Проблема не новая. Уверен, у меня есть оригинальная копия «Насколько точна научная программа?». Хаттон и др., октябрь 1994 г., что даже тогда показали, как различные реализации тех же теорий (как алгоритмы) расходились довольно быстро (это также ссылка 8 в Kelly & Sanders paper)