Как корректно проверить математическую формулу?

Question

[JaneGame]

Добрый день! Может кто сможет подсказать. Есть формула (предположим xyz=c), xyz - это некоторый набор коэффициентов (констант), который зависит от того, какие показания выберет пользователь. Попробовала пайрвайзом - получила 63 комбинации на выходе - без учета негативных проверок. Может с т.з. тестирования это не очень много, но в условиях ограниченных сроков это может быть критичным (учитывая, что тесты ещё надо написать).

Вопрос - достаточно ли будет, если я прогоню каждый коэффициент по 1 разу, чтобы убедиться, что во-первых система принимает эти поля, во-вторых, что коэффициенты соответствуют заданным значениям, в-третьих, что система вообще считает правильно? Например x1y1z1=c1, а x2y2z2=c2.

Answer 1

[hint000]

достаточно ли будет, если я прогоню каждый коэффициент по 1 разу

Тут нет общего ответа. Иногда можно срезать углы, иногда нельзя.

предположим xyz=c

Тогда срезайте, если уверены, что кроме этой формулы больше нигде не используются x,y,z. Тут при вещественных переменных особо важен тест на минимальное положительное значение c (при целых не обязательно), а на максимальное - хоть при вещественных, хоть при целых. На нулевые и на отрицательные значения, если попадают в разрешенный диапазон. И типа всё (срезали лишнее).

А предположим, что 1/(x+y-z+4)=c, а у вас случайно не будет теста x=1, y=1, z=6 (или аналогичного), который обязан зафейлиться (на целых).
"А-а-а? Э-э-э!" (с)

А если у нас задача про землекопов, и в ответе получилось 1.49999 землекопа?
А если в той же задаче получилось 1.99999 землекопа? С точки зрения тестирования это две принципиально разные выявленные ошибки в программе. В первом случае ошибка в формуле, во втором случае потеря точности.

Необходимость тех или иных тестов можно понять только когда известны зависимости, известны диапазоны, известна логика программы (что и для чего мы вычисляем, какой смысл несёт результат работы программы). Если всего этого не знать, то будет по принципу GIGO - garbage in, garbage out - бесполезная работа.

Comments

[JaneGame]

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

[hint000]

JaneGame, да, в первом приближении так. Теоретически, могут встретиться более сложные случаи, когда нужно будет ещё что-то учитывать. Так сразу трудно придумать, что это может быть. Возможно, опытные тестировщики вспомнят что-то из реальной практики.

[JaneGame]

Здорово, спасибо))

Answer 2

[mayton2019]

Например x1y1z1=c1, а x2y2z2=c2

Вы не можете проверить саму формулу. Ее смысл не вытекает ниоткуда. По краейней мере для вас.
Об этом писал Курт Гёдель. Формула корректна потому что она нам дана таковой.

Но вы можете как тестировщик проверить ее реализацию. Обычными тестами или тестами свойств.
Property-Based-Testing (PBT)

Для PBT обычно вы подаете на вход рандомные значения и проверяете что выполняется какой-то
инвариант. Например если формула дает площать фигуры - то площать всегда не отрицательная.
Или Например если это площать круга - то она всегда будет меньше например площади
описанного квадрата. Это грубая проверка но она позволяет по крайней мере очень быстро
доказать что нет грубой ошибки.

Какие конкретно придумать свойства для тестирования - это ваша задача. Спросите бизнес.
Например если вы тестируете банковский кредит то инвариантом должна быть прибыль.
Тоесть при любых допустимых параметрах выгода от кредита должна быть в пользу банка.
Это КМК самый лучший инвариант что можно придумать.

Если типы данных у вас - вещественные то все формулы в тестировании проверяются не на точное
совпадение а с допуском (эпсилон) который вы описываете в asserts:

assert ( x * y * z == c, ε = 0.000001 )

для всей области определения x,y,z

В качестве фреймворков для Java/Scala есть соотвественно jqwik, scalacheck

Comments

[JaneGame]

Я понимаю в чем суть моего рассчёта и продукта — у меня сейчас заминка именно в том как протестировать правильнее с точки зрения тестирования. пользователь выбирает значение поля и в зависимости от его выбора в формулу подставляется то или иное значение коэффициента. И так для каждого. Например, есть набор коэффициентов 1,5,7 для одного поля и 3,9,12 для второго и т.д. Мне нужно убедиться, что подставляются верные коэффициенты, а также заложена верная логика рассчета, округлений и т.д. Изначально я хотела сделать пайрвайз и пересчитать все получившиеся комбинации полей, сейчас думаю, что мб стоит просто по 1 разу сделать? Ну и плюс разные корнеркейсы (например с округлением для нецелочисленных значений в соответствии с бизнес-логикой).

[mayton2019]

PBT - фреймворки сразу посылают на вход корнеркейсы.

Например если у тебя 3 мерная функция - с вещественными аргументами
то первым делом будут протестированы 0, +1, -1.... числа Фибоначии, +MAX_INT, +INFINITY, NaN
а потом уже на вход пойдет шум из рандомных значений.

Я трассировал работу jqwick он так работает.

Кроме того тестовые фреймворки позволяют создать свой генератор значений и там уже
можно учеть какие-то преференции. Например все четные числа.