Тестування (детерміновані) алгоритми з декількома або важко довести правильні відповіді

Я хотів би передумови, що це питання схоже, але моє запитання не передбачає випадковості, просто вибагливий детермінізм, тому відповідь "використовувати відоме насіння" насправді не застосовується. Так само це питання схоже, але знову ж таки, я не сподіваюсь, що алгоритм колись вийде з ладу - я просто не знаю, яким чином це буде правильним.

Це питання виникло під час тестування алгоритмів графіків. але жодним чином не обмежується ними. Деякі алгоритми, такі як A *, можуть мати кілька правильних відповідей. Залежно від вашої точної реалізації, ви можете отримати будь-який з декількох відповідей, кожен з яких однаково правильний. Це може ускладнити їх тестування, тому що ви не знаєте, який саме буде виплюнути достроково, і дуже багато часу потрібно обчислити відповіді вручну.

У моєму конкретному випадку я обійшов це, змінивши Флойда-Варшалла, щоб виплюнути всі можливі найкоротші шляхи, і витратив час на тестування цього. Користь була хорошою рисою сама по собі. Тоді я міг би перевірити інші функції з точки зору відомих правильних шляхів від FW (якщо повернутий шлях - це будь-який із шляхів, повернутих FW для цієї пари початку / кінця, це правильно). Звичайно, це працює лише для щільних графіків завдяки тому, як працює FW, але це все одно приємно.

Однак це не завжди може бути життєздатним для всіх алгоритмів з цією характеристикою. Поки найкраща відповідь, яку я придумав, - це перевірити на характеристики правильної відповіді, а не на саму правильну відповідь. Щоб повернутися до алгоритмів найкоротшого шляху, ви можете перевірити вартість повернутого шляху відповідно до відомої правильної вартості та переконатися, що шлях дійсний.

Це працює, але може виникнути ризик не перевірити все правильно, тим більше критеріїв правильності є, особливо якщо верифікація сама по собі є складною (наприклад, поки існують правильні алгоритми , перевірка мінімального розміру дерева є відомою важкою проблемою; напевно, важче, ніж побудова самого MST), і в цьому випадку вам доведеться провести тестування коду тестування. Гірше: імовірно, вам доведеться побудувати MST для тестування алгоритму перевірки MST, тому у вас є чудовий сценарій, коли ваш тест MST спирається на роботу вашого алгоритму перевірки MST, а ваш тест алгоритму перевірки MST спирається на ваш код генерації MST.

Нарешті, є "дешевий спосіб", який передбачає спостереження за результатами, перевірку його вручну, а потім жорстке кодування тесту, щоб перевірити вихід, який ви тільки що перевірили, але це не чудова ідея, оскільки вам, можливо, доведеться переглядати тест кожен раз, коли ви трохи змінити реалізацію (чого слід уникати автоматизованого тестування).

Очевидно, що відповідь залежить від точного алгоритму, який ви перевіряєте до певної міри, але мені було цікаво, чи існували "найкращі практики" для перевірки алгоритмів, які мають декілька певних, детермінованих "правильних" результатів, але ці точні правильні результати важко знати заздалегідь, і, можливо, важко навіть перевірити факт.

Я не впевнений, що ви намагаєтеся перевірити правильність властивості, і це викликає вашу неоднозначність.

Алгоритми графіків спрямовані не на пошук деякого найкоротшого шляху (це побічний ефект), а на мінімізацію або максимізацію деякої функції витрат, визначеної на наборі ребер та вершин. Таким чином, ви можете перевірити правильність рішення, перевіривши остаточне значення цього функціоналу і стверджуючи, що перший і останній вузли - це фактично необхідні.

Якщо ви можете заздалегідь обчислити значення функції кінцевої вартості для кожного можливого шляху (як правило, це нереально), тоді вам слід просто перевірити, що вартість рішення, що надається тестовою реалізацією, дорівнює мінімальній вартості серед цього набору (абсолютне порівняння ). Якщо у вас "просто" є золотий стандартний алгоритм та / або реалізація, то вам слід порівняти вартість його виходу з вартістю алгоритму, що перевіряється (порівняльне порівняння)

Наприклад, наївним тестом буде:

1. Обчисліть усі можливі шляхи між Va і Vb у тестовому графіку за допомогою жадібного алгоритму.
2. Обчисліть функцію витрат (наприклад, довжину, якщо всі ваги вашої межі рівні 1) для кожного з цих шляхів і знайдіть мінімальне значення.
3. Застосуйте тестований алгоритм.
4. У вашому тесті висловіть твердження, що вартість вартості тестованого алгоритму дорівнює мінімуму жадібних рішень.

Якщо ви хочете дізнатися більше про оптимізацію на основі графіків, ви можете ознайомитись з публікаціями Юрія Бойкова тут , хоча в іншому контексті (проблеми з комп’ютерним баченням).

Я думаю, що прямою відповіддю на ваше запитання є вибір кращих тестових випадків. Цікаво про тестові випадки, які ви використовуєте. Графіки, які ви використовуєте, можуть бути КАНАНОВАНИМ графіками, де людині порівняно легко визначити очікувану відповідь. Спробуйте розібрати "крайові" випадки, за якими ви хочете бути впевненими, що ваш алгоритм обробляє, і створіть консервований графік для кожного конкретного реберного випадку, який людині легко обчислити. Наприклад, у випадку алгоритму Djikstra ви, ймовірно, можете створити деякі графіки розміром 5x5 або 7x7, які охоплюють усі ваші крайові регістри, хоча ваша реальна система може бути 500x500.

Тоді в якості остаточної перевірки на обгрунтованість можна створити більш реалістичний тестовий випадок з графіком або два. Але в будь-якому випадку, я думаю, що в sansuiso є місце, де зазначено, що вам потрібно бути впевненим, що ви перевіряєте правильність власності.