Я спершу хочу сказати, що все, що я роблю, - це SQL Server, тому це приклади. Однак загалом це стосується будь-якої форми коду незалежно від системи.
Почнемо, трохи розбивши це.
Модернізації
У вас є система, яка збирається оновити деякі або всі її. Наприклад, оновлення екземпляра з SQL Server 2012 до 2014 року. На даний момент тестування є важливим. На жаль, протестувати кожну частину навіть невеликого додатка, мабуть, не вдасться. У той момент я зробив би те, що я назвав би "робочим" тестом. Чи працює основна система. Виконайте свої звичайні завдання, почніть закінчувати. Не перевіряйте кожен варіант, а лише основний шлях.
Під час оновлення SQL Server також потрібне читання . По суті, ви хочете прочитати Backward Compatibilityзапис для нової версії ( ось 2014 року ) і переконатися, що у вас немає нічого в жодному зі списків (порушення змін, зміни поведінки тощо).
Код програми
Тут ми розглядаємо новий / змінений код програми (адже, звичайно, все існуюче вже перевірено, правда?). У цьому випадку все слід перевірити. Вам слід встановити тестові випадки, встановлені достроково, і пройти через щонайменше більшість порушених функцій. Переважно на цьому етапі ви також повинні мати когось іншого, щоб зробити подібну перевірку. Цей код буде існувати, мабуть, досить тривалий час, і його використовуватиме велика кількість людей. Ви хочете переконатися, що вона працює і працює добре.
Однією з речей, яка може реально допомогти в цьому, є створення набору, unit testsякий легко повторюється. Стів Джонс рекомендує використовувати tSQLt для тестування вашого TSQL-коду (боюсь тільки SQL Server). Але зробивши це, ви можете швидко пройти фіксований набір тестів, і це дійсно допоможе в регресійному тестуванні (протестуйте все, скажімо, перед тим, як зробити оновлення).
Особливості / конфігурації
Навіть більше, ніж зміни коду програми, ви хочете ретельно перевірити нові функції та зміни конфігурації. Наприклад, ви вирішили почати працювати з індексами стовпціввперше вам потрібно буде протестувати кожен фрагмент коду, який торкається зачіпаних таблиць. Використовуйте створені вами одиничні тести для тестування програми. Ці функції, ймовірно, нові для вас (і, можливо, нові в платформі), і, ймовірно, матимуть деякі проблеми, яких ви не очікували. Щодо змін конфігурації, ви говорите про щось, що може вплинути на всю вашу систему, можливо, істотно. Головне правило - тестувати та ретельно перевіряти. Є деякі зміни, які ви насправді не побачите, поки не потрапите в активну систему (можливо, лише вашу виробничу систему), але це не привід не спробувати їх спочатку в тестовому середовищі.
Спеціальні запити, на які посилаються / впливають дані користувачів
Якщо у вас є код , який впливає на ваші призначені для користувача дані зазвичай потрібно , щоб перевірити це, навіть, і , можливо , особливо, тому що це Ad Hoc. Тепер, коли говорять, якщо ви використовуєте один і той же фрагмент коду знову і знову, лише з різними параметрами, то вам, ймовірно, не потрібно турбуватися про тестування кожного разу.
Наприклад, вам потрібно видаляти одну чи кілька оголошень із таблиці AdList щокварталу.
DELETE FROM AdList WHERE AdName IN ('January 2015 Ads','February 2015 Ads','March 2015 Ads')
На той момент ви вже протестували код (ви просто змінюєте фіксовані рядки) і, ймовірно, досить безпечні, просто запускаєте код (якщо припустити, що у вас є гарні резервні копії на всякий випадок).
Один простий спосіб перевірити DELETE, UPDATEчи INSERT, щоб змінити їх до SELECT , і запустити їх, а потім підтвердити , що кількість і тип рядків ви очікуєте повертаються.
Ви можете подумати, що вам не потрібно тестувати SELECTs, оскільки вони насправді не змінюють жодних даних. Однак ви запускаєте код так, чи не так? Скажімо, ви робите дослідження для свого менеджера, який в свою чергу передасть ці дані своєму менеджеру тощо. Ви перевіряєте, чи не отримуєте помилкових даних (або не дозволяєте іншим збирати їх дані).
Спеціальні запити, що посилаються / впливають на системні дані
Можливо, це єдиний виняток із правила "перевірити все". Ви виконуєте інформаційні запити щодо системних даних. Тут важливо повернути очікувані дані. Якщо запит - це щось просте (запит на системний вигляд), то, ймовірно, ви добре, поки ви перевірили, що насправді означають перегляд / стовпці. Якщо запит складний (скажімо, натискання 3 або 4 системних представлень із розрахунками на повернені стовпці), можливо, ви захочете виконати кілька тестів просто для того, щоб переконатися, що ви отримаєте назад очікувані вами дані.
Підсумок
Підсумовуючи, так, ви хочете перевірити все. Якщо вам достатньо важливо написати його і запустити, то для вас це досить важливо для тестування. Це не означає, що вам доведеться витратити величезну кількість часу на тестування кожної гілки кожного рядка коду. Але деякий рівень тестування потрібно зробити.
Тут знайомий ваш автоматизований тестовий пристрій. З появою DevOpsі Continuous Integrationви побачите все більше додатків і методів швидкого і легкого тестування вашого коду. Звичайно, для цього потрібно мати гарне тестове середовище та дані, але це зовсім інша дискусія.