Прибуток:
- Розуміти мету регресійного тестування та вміти вибирати тести та створювати випадки регресії відповідно до змін за допомогою штучного інтелекту
- Здатність діагностувати основні причини крихких тестів (час, залежність порядку, спільний стан, зовнішня залежність) і застосовувати постійні рішення без придушення симптому
- Можливість підтримувати дисципліну виконання попередньої версії повного пакета, зберігаючи швидкий, незалежний і надійний набір регресій за рахунок усунення повторного тестування
Програмне забезпечення постійно змінюється; Кожна нова функція, кожне виправлення може порушити роботу того, що працювало раніше. Подальше порушення раніше працюючої функції називається регресією. Регресійне тестування – це повторне тестування існуючих функцій із кожною зміною, щоб виявити ці погіршення. З часом ці набори тестів стають все більшими — тисячі тестів — і виникають дві великі проблеми: набір уповільнюється, а нестабільні тести — ненадійні тести, які іноді проходять, а іноді не в одному коді — руйнують впевненість команди в результатах тестування. Штучний інтелект (ШІ) є потужним допоміжним засобом у підтримці набору регресії в належному стані, швидкості та надійності. Але головне застереження залишається: хоча штучний інтелект може запропонувати «пройти» крихкий тест, він часто може створити патч, який прикриває справжню помилку. Ваше завдання — знайти першопричину нестабільності, а не пригнічувати симптом.
Основні причини крихких тестів
Крихке тестування є найпідступнішою проблемою тестування: воно ненадійне незалежно від того, пройде воно чи не пройде, що штовхає команду на звичку «мабуть, знову застрягло, запустіть знову» — і ця звичка одного разу проігнорує справжню помилку як «нестабільну». Основні першопричини:
- Умови хронометражу/гонки: тест перевіряє результат, не чекаючи завершення операції. Найчастіша причина.
- Залежність порядку: тести залежать від даних, залишених один одним; Він ламається, коли змінюється порядок.
- Спільний випадок: кілька тестів використовують ті самі тестові дані/користувача, конфліктуючи.
- Зовнішня залежність: реальна мережа, сторонній сервіс, системний час, випадкове значення.
- Відмінність середовища: перемикається на локальне, залишається в CI (середовище безперервної інтеграції).
Застереження: проходження крихкого тесту шляхом «повторної спроби кілька разів» часто маскує справжню помилку паралелізму. Повторна спроба – це діагностичний інструмент, а не лікування. Спочатку знайдіть першопричину; Використовуйте повторну спробу лише в крайньому випадку для задокументованої справді зовнішньої нестабільності.
Тестове технічне обслуговування: збереження упаковки в належному стані
Регресійний номер схожий на сад; Якщо не доглядати, бур’яни захоплюються. AI допомагає виконувати три завдання з обслуговування:
1. Повторне/непотрібне тестове очищення. З часом накопичується велика кількість випадків тестування одного і того ж. AI пропонує групувати та об’єднувати схожі тести.
2. Крихкий тестовий діагноз. Ви надаєте AI тестовий код і шаблон нестабільності; пропонує можливі основні причини та постійне вирішення.
3. Вибір/пріоритезація тестів. Дорого запускати весь пакет із кожною зміною. Завдяки аналізу впливу тестів (вибір лише релевантних тестів на основі зміненого коду) AI рекомендує, які тести слід запускати першими. Однак повний пакет попередньої версії є обов’язковим.
Карантин: правильне керування крихким тестуванням
Ви виявили, що тест крихкий, але у вас немає часу негайно усунути першопричину. що робити Є два неправильні способи: повністю видалити тест (ця поведінка більше не зберігається взагалі) або заглушити його повторною спробою (приховуючи справжню помилку). Правильний спосіб – карантин (тимчасове відділення крихкого тесту від основної упаковки та відстеження в окремому списку). Тестування на карантині не перешкоджає об’єднанню версій, але залишається видимою заборгованістю, і до неї регулярно звертаються. Головне: карантин – це кімната очікування, а не смітник. Якщо карантинний список збільшується, це сигнал про те, що тестовий стан здоров'я команди погіршується. ШІ може періодично переглядати ваш карантинний список і групувати його за основними причинами; Це дає можливість колективних рішень, виявляючи загальні причини, наприклад «усі 6 тестів підключено до одного спільного користувача тесту».
Порада. Додайте «власник» і «дату останнього перегляду» до кожного запису карантину. Занедбаний карантин стає постійним звалищем; Крихкі тести живуть там вічно, тому що нікого не хвилює.
Таблиця стратегії регресії
Статус
Стратегія
Роль ШІ
незначне виправлення
Уражена ділянка + димовий тест
Виберіть відповідні тести
нова функція
Пов'язаний модуль + інтеграція
Запропонуйте новий випадок регресії
великий рефактор
Повний пакет регресії
Аналіз прогалин у охопленні
попередній випуск
Повний пакет + дослідження
Оцінка пріоритетності та тривалості
Терміновий живий ремонт
Цілеспрямований + критичний шлях
Мінімальний безпечний набір тестів
Слабка підказка / Сильна підказка
Слабкий: «Цей тест інколи провалюється, виправте».
Сильний: "Цей тест не проходить 3 із 10 запусків, код без змін. Діагностуйте основну причину нестабільності: це може бути час/гонка, залежність порядку, спільний стан, зовнішня залежність або різниця в середовищі. Покажіть, який рядок у тесті вказує на кожну можливу причину. Запропонуйте постійне рішення; НЕ пропонуйте рішення для придушення симптомів, наприклад "додати повторну спробу" — якщо це неминуче, чітко напишіть причину. Тест: [код]. Слід помилок: [журнал]."
Потужна підказка; спрямовує діагностику до першопричини та чітко забороняє пригнічувати симптоми.
Чотири шаблони, які можна копіювати
1) Крихкий тестовий діагноз:
Цей тестовий код іноді проходить, а іноді не вдається без змін. Перелічіть першопричину-кандидатів (раса, залежність від порядку, спільний стан, зовнішня залежність, годинник/випадковість, різниця в середовищі) і покажіть рядок доказів у тесті для кожного. Запропонуйте постійне рішення; позначте пригнічувальні рішення, такі як повторна спроба, як останній засіб і з обґрунтуванням. Тест: [код] / шаблон нестабільності: [скільки разів за скільки запусків]
2) Proposing a regression case:
Було внесено таку зміну: [підсумок змін/PR]. Перелічіть ПОТОЧНІ поведінки, які ця зміна може порушити, і запропонуйте регресійний тест для кожного. Особливо виділіть області побічних ефектів і спільних залежностей.
3) Очищення дублікатів тесту:
Перегляньте набір тестів нижче. Групуйте повторювані або збігаються випадки, які перевіряють однакову поведінку; Запропонуйте, які з них залишити, а які об’єднати для кожної групи. Попередити, якщо є ризик втрати покриття. Тести: [список/код]
4) Вибір тестового ефекту:
Змінено такі файли/функції: [список]. З існуючого набору тестів виберіть і обґрунтуйте тести, які мені потрібно виконати в першу чергу (ті, які прямо/опосередковано пов’язані зі зміненим кодом). Примітка: нагадайте мені, що я все одно запускатиму повний пакет попередніх версій.
три міні-чохла
Випадок 1 — справжня помилка, прикрита повторною спробою. Одна команда додала 3 повторні спроби до випадкового тесту виплат, що залишився; Тест тепер завжди був «прохідним». Застосування «крихкої тестової діагностики» виявило, що нестабільність походить від реальних умов перегонів: під час високого навантаження підтвердження платежу іноді оброблялося двічі. Протягом кількох місяців Retry приховувала помилку, яка могла призвести до фактичної втрати грошей у прямому ефірі. Основну причину виправлено, повторіть спробу.
Випадок 2 — пакунок зменшився, швидкість зросла. Регресійний набір із 1400 тестів зайняв 55 хвилин. При «чистці дублікатів тестів» 380 тестів виявилися дублікатами або покритими; об'єднані. Пакет скорочено до 900 тестів, час скорочено до 34 хвилин, охоплення вимірно не зменшено. Швидший зворотній зв’язок спонукав команду тестувати частіше.
Випадок 3 — Залежність замовлення. Тест завжди проходитиме локально, але випадково зазнає невдачі в CI. Діагностика штучного інтелекту показала, що тест залежить від користувача, створеного іншим тестом, у CI він зламався, оскільки тести запускалися паралельно/в іншому порядку. Кожен тест проводився для встановлення власних даних; Нерішучість закінчилася.
Поширені помилки
- Вимкнення крихкого тесту за допомогою повторної спроби. Повторна спроба без пошуку першопричини; приховуючи справжню помилку.
- Культура «знову застрягла». Регулярне ігнорування червоних результатів; Одного разу, пропускаючи справжню помилку.
- Не обрізаючи пакет взагалі. Дозволяє накопичувати дублікати тестів і сповільнювати пакет.
- Залежність між тестами. Тести базуються на загальній умові/послідовності; джерело невизначеності.
- Тестування лише зміненої частини та пропуск повного пакета. Ярлик попередньої версії; Втеча від прихованих побічних ефектів.
- Покладаючись на зовнішню залежність. Тести на основі фактичної мережі/годинника/випадкового значення; природно нестабільний.
Підсумовуючи
Регресійне тестування виявляє зміни, що порушують раніше працючі функції; Але в міру того, як пакети зростають, повільність і крихке тестування підривають довіру. Основними причинами крихкого тестування зазвичай є час, залежність порядку, спільний стан і зовнішні залежності. AI є потужним помічником у діагностиці, очищенні та виборі тестів; Але придушення нерішучості повторними спробами приховує справжні помилки. Знайдіть першопричину, зробіть тести незалежними та детермінованими, регулярно обрізайте пакет, запускайте повний пакет перед випуском.
Аплікаційне завдання
Виберіть тест зі свого власного проекту, який, як ви знаєте, є крихким (або здається нестабільним). Виділіть першопричину-кандидатів і перевірте рядки доказів у тесті за допомогою шаблону «крихкої діагностики тесту». Визначте першопричину та застосуйте постійне рішення без повторних спроб. Потім виберіть 10 тестів зі свого пакету та знайдіть ті, які можна поєднати з «очищенням дублікатів тестів». Повідомте, скільки тестових нестабільностей ви усунули від їх першопричини та скільки непотрібних випадків ви видалили з набору.
контрольний список
- [ ] Я діагностував першопричину крихкого тесту; Я не стала придушувати симптом.
- [ ] Я вважав повторну спробу виправданим останнім засобом, а не лікуванням.
- [ ] Я зробив тести незалежними та детермінованими (ізольованими від зовнішніх залежностей).
- [ ] Я видалив повторювані/непотрібні тести з набору регресії.
- [ ] Я вирішив провести тестування на основі змін, але запустив попередню версію повного пакета.
- [ ] Я серйозно ставився до кожного червоного, проти культури «знову застряг, пройшов».