Чи гарантує покриття шляху пошук усіх помилок?

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

Якщо ні, то чому б і ні? Як ви могли пройти всі можливі поєднання потоку програми і не знайти проблеми, якщо така існує?

Я вагаюся, припускаючи, що "всі помилки" можна знайти, але, можливо, це тому, що покриття контуру не практичне (як це комбінаторне), тому воно ніколи не виникає?

Примітка. Ця стаття дає короткий підсумок типів покриття, як я думаю про них.

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

Немає

Якщо ні, то чому б і ні? Як ви могли пройти всі можливі поєднання потоку програми і не знайти проблеми, якщо така існує?

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

def Add(x as Int32, y as Int32) as Int32:
   return x + y

Test.Assert(Add(2, 2) == 4) //100% test coverage
Add(MAXINT, 5) //Throws an exception, despite 100% test coverage

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

- EW Dijkstra (Додано наголос. Написано в 1988 р. Зараз це вже значно більше 2 десятиліть.)

Окрім відповіді Мейсона , є ще одна проблема: покриття не говорить вам про те, який код був протестований, він розповідає, який код був виконаний .

Уявіть, у вас є тестовий набір із 100% покриттям шляху. Тепер видаліть всі твердження і запустіть тестовий набір ще раз. Вія, тестовий набір все ще має 100% покриття шляху, але він не тестує абсолютно нічого.

Ось простіший приклад округлення речей. Розглянемо наступний алгоритм сортування (на Java):

int[] sort(int[] x) { return new int[] { x[0] }; }

Тепер перевіримо:

sort(new int[] { 0xCAFEBABE });

Тепер, врахуйте, що (A) цей конкретний виклик sortповертає правильний результат, (B) всі тести коду були охоплені цим тестом.

Але, очевидно, програма насправді не сортує.

Звідси випливає, що покриття всіх кодових шляхів недостатньо для гарантії того, що програма не має помилок.

Розглянемо absфункцію, яка повертає абсолютне значення числа. Ось тест (Python, уявіть собі деякі тестові рамки):

def test_abs_of_neg_number_returns_positive():
    assert abs(-3) == 3

Ця реалізація правильна, але вона отримує лише 60% покриття коду:

def abs(x):
    if x < 0:
        return -x
    else:
        return x

Ця реалізація неправильна, але вона отримує 100% охоплення коду:

def abs(x):
    return -x

Ще одне доповнення до відповіді Мейсона , поведінка програми може залежати від середовища виконання.

Наступний код містить Use-After-Free:

int main(void)
{
    int* a = malloc(sizeof(a));
    int* b = a;
    *a = 0;
    free(a);
    *b = 12; /* UAF */
    return 0;
}

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

З іншого боку, навіть якщо покриття шляху гарантуватиме пошук всіх помилок, навряд чи це може бути досягнуто на практиці в будь-якій програмі. Розглянемо наступне:

int main(int a, int b)
{
    if (a != b) {
        if (cryptohash(a) == cryptohash(b)) {
            return ERROR;
        }
    }
    return 0;
} 

Якщо ваш тестовий набір може створити для цього всі шляхи, то поздоровлення ви криптограф.

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

Інший спосіб відповісти на це питання - це практичний досвід:

У реальному світі, і справді на вашому власному комп’ютері, існує багато програмного забезпечення, розроблених за допомогою набору тестів, які дають 100% охоплення та які все ще мають помилки, включаючи помилки, які краще тестування визначили б.

Таким чином, пов'язане питання:

Який сенс інструментів покриття коду?

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

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

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

При покритті коду може бути заманливо, особливо якщо у вас майже ідеальні 98%, заповнювати справи так, щоб залишилися шляхи.

Це еквівалент правильності за допомогою перевірки орфографії, що це всі слова погода або вузол, що це всі відповідні слова. Результат - каченяний безлад.

Однак якщо врахувати, які тести справді потребують некриті шляхи, інструмент покриття коду зробив свою роботу; не в тому, щоб обіцяти вам правильність, але це вказує на певну роботу, яку потрібно було зробити.

Покриття на шляху не може визначити, чи були реалізовані всі необхідні функції. Покинути функцію - це помилка, але покриття шляху не виявить її.

Частина питання полягає в тому, що 100% покриття гарантує лише те, що код буде функціонувати правильно після одного виконання . Деякі помилки, як-от витоки пам'яті, можуть не виявлятися або спричиняти проблеми після одного виконання, але з часом це призведе до проблем для програми.

Наприклад, скажімо, у вас є програма, яка підключається до бази даних. Можливо, в одному методі програміст забуває закрити з'єднання з базою даних, коли вони виконані зі своїм запитом. Ви можете запустити кілька тестів за допомогою цього методу і не виявити помилок у його функціональності, але ваш сервер баз даних може зіткнутися зі сценарієм, коли він не має доступних з'єднань, оскільки цей конкретний метод не закрив з'єднання, коли це було зроблено, і відкриті з'єднання повинні зараз тайм-аут.

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

Як уже було сказано, відповідь НІ.

Якщо ні, то чому б і ні?

Крім того, про що йдеться, є помилки, що з’являються на різних рівнях, які неможливо перевірити одиничними тестами. Зазначимо лише кілька:

• помилки, виявлені інтеграційними тестами (одиничні тести все-таки не повинні використовувати реальні ресурси)
• помилки в вимогах
• помилки в дизайні та архітектурі

Що означає кожен тестуваний шлях?

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

Розглянемо цей метод:

def add(num1, num2)
  foo = "bar"  # useless statement
  $global += 1 # side effect
  num1 + num2  # actual work
end

Якщо ви пишете тест, який стверджує add(1, 2) == 3, інструмент покриття коду скаже вам, що кожен рядок виконується. Але ви насправді нічого не стверджували про глобальний побічний ефект або марне призначення. Ці рядки виконані, але насправді не перевірені.

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

• Одна мутація може змінити +=на -=. Ця мутація не спричинить збій тесту, тож доведеться, що ваш тест не підтверджує нічого значимого щодо глобального побічного ефекту.
• Інша мутація може видалити перший рядок. Ця мутація не спричинила б тестовий збій, тому вона доведе, що ваш тест не підтверджує нічого важливого щодо завдання.
• Ще одна мутація може видалити третій рядок. Це може спричинити збій тесту, що в цьому випадку показує, що ваш тест щось підтверджує про цю лінію.

По суті, мутаційні тести - це спосіб перевірити свої тести . Але так само, як ви ніколи не перевіряєте фактичну функцію при кожному можливому наборі входів, ви ніколи не запускаєте всі можливі мутації, тому, знову ж таки, це обмежено.

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

Ну ... так, насправді, якщо кожен шлях "через" програма тестується. Але це означає, що кожен можливий шлях через увесь простір усіх можливих станів програми може мати, включаючи всі змінні. Навіть для дуже простої статично складеної програми - скажімо, старого кранчера номера Fortran - це неможливо, хоча це можна принаймні уявити: якщо у вас є лише дві цілі змінні, ви в основному маєте справу з усіма можливими способами підключення точок на двовимірна сітка; це насправді дуже схоже на мандрівного продавця. Для n таких змінних ви маєте справу з n -вимірним простором, тому для будь-якої реальної програми завдання є абсолютно нерозбірливим.

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

Це сказало ... насправді все не так вже й моторошно. Це є можливим proove цілих програм , щоб бути правильними, але вам доведеться відмовитися від кількох ідей.

По-перше: вкрай доцільно перейти до декларативної мови. Імперативні мови чомусь завжди були найпопулярнішими, але спосіб поєднання алгоритмів із взаємодіями в реальному світі вкрай важко навіть сказати, що ви маєте на увазі під «правильним».

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

Тепер, ви кажете, що це все-таки нерозв'язно ... зрештою, простір усіх можливих аргументів взагалі також нескінченно-мірний. Правда - хоча для однієї функції навіть наївне тестування на покриття веде вас далеко далі, ніж ви могли сподіватися в імперативній програмі! Однак є неймовірний потужний інструмент, який змінює гру: універсальне кількісне визначення / параметричний поліморфізм . В основному, це дозволяє записувати функції на дуже загальні типи даних, гарантуючи, що якщо він працює для простого прикладу даних, він буде працювати для будь-якого можливого введення даних взагалі.

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