Функціональне тестування 1C-Бітрікс: де ламається сайт
Функціональне тестування 1C-Бітрікс починається не з перевірки верстки, а з бізнес-сценаріїв, де помилка коштує найдорожче: оформлення замовлення, обмін з 1С, розмежування прав, зовнішні інтеграції.
Ці місця ламаються тихо — сторінка відкривається, кнопки натискаються, а на стороні замовника вже губляться замовлення та розходяться залишки.
Кошик — класична точка відмови. Товар додається, але при перерахунку знижки або зміні способу доставки сума перераховується неправильно; промокод застосовується до однієї позиції замість усього кошика; при паралельних замовленнях списується зайвий залишок. Клієнт бачить помилку на сайті в момент оплати — і йде, а не повідомляє про неї.
Обмін з 1С рветься непомітно для вітрини: ціни та залишки перестають оновлюватися, замовлення не вивантажуються в облікову систему, розходяться номенклатура та склади. Помилка накопичується добами, поки менеджер не звірить дані вручну.
Права доступу — третя зона ризику: гість бачить ціни для оптовиків, менеджер регіону отримує доступ до чужої бази, а розділ для авторизованих відкритий за прямим посиланням.
Інтеграції з платежами, службами доставки та зовнішніми сервісами додають свої збої: платіж проходить, але статус замовлення не змінюється; розрахунок доставки повертає порожню відповідь на нестандартну адресу.
Кожен такий розрив — це ручна робота підтримки, повернення та втрачена довіра. Розбираємо, як виявляти ці точки відмови до того, як їх знайдуть клієнти.
Що дає перевірка: вимірюваний ефект для бізнесу
Функціональне тестування 1C-Бітрікс відповідає на одне питання: що саме ламається у користувача після чергової зміни. Регресійний набір проганяється на кожному релізі й закриває типові сценарії — оформлення замовлення, оплату, реєстрацію, вивантаження каталогу, обмін з 1C.
Помилки, які раніше спливали в проді через день-два після викладки, відловлюються до публікації, тому потік звернень до підтримки падає передбачувано: тікетів стає менше в рази, а не на відсотки.
Швидкість випуску змін зростає не за рахунок «швидше пишемо код», а за рахунок знятого страху викатки.
Коли є автоматичні перевірки на ключових шляхах і зрозумілий протокол відкату, релізи виходять частіше й дрібніше — правки в шаблонах, компонентах, правилах обміну з 1C перестають бути подією на весь день.
Команда не витрачає час на ручне переклацування одних і тих самих сценаріїв, а підтримка займається розвитком, а не розбором однотипних інцидентів.
Окремий ефект — зникнення цілих класів відмов. Перевірки на цілісність даних при обміні з 1C прибирають розсинхрон залишків і цін; тести кошика й оплати — завислі замовлення та втрачені платежі; контроль прав доступу — витоки через відкриті розділи.
Це не «стало трохи надійніше», а інший профіль експлуатації: стабільність сайту перестає залежати від того, хто саме виклав реліз і в яку зміну.
На практиці це видно за метриками: частка інцидентів, знайдених користувачами, знижується, середній час між релізами скорочується, а час на розбір одного звернення падає, бо причина вже локалізована тестом. Розбираємо, як такий контур перевірок вибудовується під конкретний сайт і його інтеграції з 1C.
Режими перевірки: ручний прогін, автотести, регрес
Три режими не замінюють, а доповнюють один одного: ручне тестування ловить те, що не опишеш формальним сценарієм, автотести тримають стабільність на довгій дистанції, регресійне тестування захищає вже працюючі сценарії від нових правок. Вибір залежить від того, що змінюється в релізі та якою є ціна помилки на конкретній ділянці.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Ручне тестування | Нові сценарії, верстка, форми, оплата, інтеграції з 1С | Дорого повторювати, залежить від уваги перевіряючого |
| Автотести | Стабільні сценарії: авторизація, кошик, оформлення замовлення, обмін даними | Потребують підтримки при зміні верстки та логіки |
| Регресійне тестування | Перед кожним релізом і після правок ядра | Повний прогін займає час, потрібен відбір пріоритетів |
| Димові перевірки | Після деплою та оновлень | Покривають лише критичний шлях, не замінюють повний прогін |
Як обираємо режим під задачу
Якщо реліз торкається бізнес-логіки — оплати, особистого кабінету, обміну з 1С — спочатку ручний прогін нових сценаріїв, потім закріплення їх автотестами. Так перевірка не втрачається з наступною правкою: сценарій один раз описаний і далі виконується без людини.
Для регулярних оновлень ядра та модулів достатньо регресу за пріоритетними шляхами та димових перевірок після викочування. Повний прогін усіх сценаріїв на кожному релізі невиправданий — відбираємо ті, що зачіпають змінений код.
Що дає поєднання режимів
Ручне тестування виявляє дефекти, які автотести пропускають: невірні тексти, зміщену верстку, нелогічні переходи. Автотести фіксують результат і прибирають людський фактор на повторюваних кроках.
Регресійне тестування закриває головний ризик — «поправили одне, зламали інше». Димові перевірки дають швидку впевненість, що сайт живий після деплою, і дозволяють відкотити реліз до того, як проблему побачить клієнт.
Як відбувається перевірка: етапи інженерної роботи
Перевірка починається не із запуску тестів, а з інвентаризації: які компоненти та модулі задіяні, де кешування, які інтеграції з 1С і зовнішніми сервісами, які сценарії критичні для бізнесу.
Без цього схема перевірок виходить формальною — покриває те, що легко перевірити, а не те, що ламається в проді. Тому перший етап завжди дає карту системи та список ризиків, а не звіт про кількість прогонів.
Далі вибудовуємо послідовність так, щоб кожен етап спирався на результат попереднього.
- Аудит сайту — розбираємо структуру, версії ядра та модулів, історію правок, поточні помилки в логах. Фіксуємо, що вже працює нестабільно: це майбутні точки відмови.
- Схема перевірок — описуємо, які шляхи покриваємо, які сценарії вважаємо критичними, що перевіряємо вручну, а що автоматизуємо. Узгоджуємо пріоритети: спочатку те, що безпосередньо впливає на замовлення та дані.
- Налаштування середовища — піднімаємо копію, максимально наближену до бойової: ті самі версії, ті самі налаштування кешу та черг, та сама база 1С. Перевірка на «чистій» збірці ловить неіснуючі проблеми та пропускає реальні.
- Прогін тестів — функціональне тестування 1C-Бітрікс іде за узгодженими сценаріями: оформлення замовлення, обмін з 1С, права доступу, форми, інтеграції. Кожне падіння фіксуємо з кроками відтворення, а не просто «не працює».
- Розбір і пріоритизація — ділимо знайдене на блокери, критичні та косметичні. Блокери лагодимо одразу, решту — з оцінкою та черговістю.
- Повторний прогін — підтверджуємо, що правки не зламали сусідні сценарії. Регрес тут дешевший, ніж відкат на проді.
- Передача результатів — звіт з відтворюваними кроками, список виправленого, залишкові ризики та рекомендації щодо моніторингу.
Така послідовність дає передбачуваний результат: на момент викладки в команди є не «наче все перевірили», а список покритих шляхів і явно названі зони, які залишилися поза перевіркою. Опишіть ваше завдання — повернемося з оцінкою та планом перевірки під ваш контур.
Що залишається на руках: артефакти та регламенти
Перевірка не закінчується вердиктом «працює». Її результат — набір артефактів, за якими команда замовника далі випускає релізи та приймає зміни без нас. Кожен документ закриває свій клас помилок, тому перелік фіксований.
- Тест-кейси за критичними сценаріями: оформлення замовлення, оплата, реєстрація, інтеграція з 1С, вивантаження каталогу. Кожен крок з очікуваним результатом і позначкою, чи відтворюється дефект повторно.
- Звіт про перевірку: що тестували, на якому середовищі, які дефекти знайшли, що виправлено, що залишилося з позначкою пріоритету. Без «все добре» — з прив'язкою до конкретних сторінок і сценаріїв.
- Карта ризиків: вузькі місця, які не ламаються зараз, але дадуть збій при зростанні навантаження або оновленні ядра — важкі запити до каталогу, синхронізація з 1С за розкладом, кеш компонентів.
- Регламент релізу: порядок викладки, обов'язкові перевірки перед публікацією, точки відкату, хто підтверджує випуск. Правило «спочатку на тестовий контур, потім на бойовий» перестає триматися на пам'яті одного інженера.
- Чек-лист приймання: короткий список із 10-15 пунктів, який проходить керівник або менеджер перед здачею задачі — форми надсилаються, листи доходять, оплата проходить, стара версія сторінки відкривається.
- Налаштований моніторинг: оповіщення про падіння сайту, помилки в логах, недоступність обміну з 1С. Інцидент ловиться до дзвінка клієнта, а не після.
- Резервні копії та перевірка відновлення: розклад, термін зберігання, де лежать копії та як розгорнути їх на чистому середовищі. Копія, яку жодного разу не відновлювали, копією не вважається.
- Доступи та документація: облікові записи з ролями, схема середовищ, інструкція за типовими операціями — оновлення контенту, додавання розділу, правка цін.
Комплект залишається у замовника і не прив'язаний до нас: новий підрядник або штатний розробник входить у проєкт за цими документами, а не відновлює логіку за кодом.
Регламент релізу та чек-лист приймання зазвичай переживають кілька змін команди — саме вони утримують якість, коли перевірка давно позаду.
Кейс: як перевірка усунула збої обміну з 1С
Клієнт — оптова компанія з інтернет-магазином на 1С-Бітрікс і синхронізацією каталогу, цін і залишків з обліковою системою. Обмін запускався за розкладом, але регулярно падав: частина товарів не оновлювалася, ціни розходилися з фактичними, менеджери правили позиції вручну.
Помилки синхронізації спливали вже в покупців — у вигляді відмов на оформленні та питань у підтримку.
Що було до перевірки
Ми почали з функціонального тестування обміну: прогнали повний цикл синхронізації на тестовому контурі, розібрали журнали та відтворили сценарії, які в звичайній роботі проходили «на удачу».
Виявили накопичені збої — від дублів позицій до обривів на середині пакета, коли частина даних записувалася, а частина ні. Окремо перевірили поведінку при повторному запуску: без коректної обробки повтор обміну множив помилки замість того, щоб їх виправляти.
Що змінили
Переписали логіку обміну з ідемпотентною обробкою — повторний запуск тепер безпечний і не створює дублів. Додали перевірку цілісності пакета до запису та зрозумілі повідомлення при розходженні, щоб збій було видно одразу, а не через добу.
Налаштували автоматичний перезапуск завдань, що впали, і розмежували права на запис, щоб ручні правки не конфліктували з обміном.
Що стало
Кількість звернень у підтримку щодо розходжень цін і залишків скоротилася приблизно в п'ять разів. Час простою обміну при збої зменшився з кількох годин до хвилин — завдання піднімається саме, без участі інженера.
Частка успішних циклів синхронізації зросла до стабільних значень, а ручні правки каталогу практично зникли з щоденної роботи менеджерів.
Чим відрізняється перевірка перед релізом від регулярного регресу?
Перевірка перед релізом відповідає на одне питання: чи можна викочувати цю збірку сьогодні. Інженери проганяють критичні сценарії — оформлення замовлення, оплату, авторизацію, вивантаження каталогу, обмін з 1С — на тому самому наборі даних, що й продакшн.
Завдання — зловити регрес, який вніс конкретний зміна, і не пропустити його до клієнтів. Такий прогін разовий: він прив'язаний до дати викочування і закривається разом із релізом.
Регрес — це не разова акція, а постійний контур якості. Він живе незалежно від релізів: набір перевірок зафіксований, виконується за розкладом і після кожної зміни в коді, конфігурації або на стороні 1С.
Сенс у тому, що система змінюється не лише коли ви її торкаєтеся: оновлюється ядро платформи, надходять нові версії модулів, постачальник змінює вивантаження, оновлюється сама 1С. Будь-яка з цих подій може зламати сценарій, який учора працював.
Різниця проявляється в частоті та охопленні. Перед релізом перевіряють те, що зачеплено правкою, — швидко й точково. Регрес проганяє весь критичний шлях повністю, включно з інтеграціями та фоновими завданнями, і робить це регулярно, а не від випадку до випадку.
Саме тому регрес ловить деградацію, яку разова перевірка фізично не побачить: розходження залишків після обміну, таймаути на вивантаженні, помилки в листах і повідомленнях.
Практичний висновок простий: разова перевірка знижує ризик конкретного релізу, а постійний контур якості знижує ризик усієї системи. Перше без другого залишає сліпі зони між викочуваннями — і саме там зазвичай і спливають проблеми, про які клієнт дізнається раніше, ніж команда.
Часті технічні сумніви замовників
Перед стартом робіт майже завжди виринають одні й ті самі питання — про навантаження, доступи, інтеграції та сумісність з тим, що вже працює. Нижче — відповіді так, як ми їх даємо на технічних зустрічах.
Чи витримає сайт пікове навантаження після доопрацювань?
Ми не гадаємо: перед релізом проганяємо навантажувальне тестування на сценаріях, що повторюють реальний трафік — з урахуванням кешу, сесій і звернень до бази. Дивимося не середній час відповіді, а поведінку на піку та точку, де система починає деградувати. Якщо запас менший за потрібний, оптимізуємо запити й кешування до викладки, а не після інциденту.
Які доступи вам потрібні й наскільки це безпечно?
Потрібен доступ до середовища розробки та тестового контуру, а до продактиву — лише на час викладки. Працюємо через окремі облікові записи з обмеженими правами, без спільного пароля адміністратора.
Усі дії фіксуються в журналах, доступ відкликається після завершення етапу — ви будь-якої миті бачите, хто і що робив.
Чи не зламаються поточні інтеграції?
Спочатку інвентаризуємо все, що обмінюється даними із сайтом: склад, оплата, доставка, CRM, зовнішні сервіси. Для кожної інтеграції перевіряємо формат обміну, обробку помилок і поведінку за недоступності зовнішньої сторони. Зміни викочуємо так, щоб старі й нові виклики працювали паралельно, — тоді відкат не рве зв'язки.
Чи сумісно це з нашою інфраструктурою та версією платформи?
Перед оцінкою звіряємо вимоги з вашим оточенням: версія ядра, конфігурація сервера, оточення бази даних, встановлені модулі. Якщо оновлення обов'язкове, плануємо його окремим етапом із перевіркою на копії бойового контуру. Так ви бачите реальні обмеження до початку робіт, а не в момент викладки.
Що якщо після релізу щось піде не так?
Тримаємо точку відкату: резервна копія бази та файлів перед викладкою, версіонування змін. Якщо після релізу з'являється відхилення, повертаємося до попереднього стану за хвилини, а причину розбираємо на копії. Це стандартна частина регламенту, а не окрема послуга.
Опишіть вашу задачу та поточний контур — повернемося з оцінкою, планом перевірок і списком необхідних доступів.
Обговоримо задачу: повернемося з оцінкою та планом
Перевірка починається з розбору поточного стану: які модулі та компоненти задіяні, як влаштовані шаблони, де зберігаються дані, які інтеграції з 1С вже працюють.
Без цього плану не буде — функціональне тестування 1C-Бітрікс будується навколо конкретної конфігурації проєкту, а не за загальним чек-лістом. Опишіть задачу у вільній формі: що турбує зараз, що змінювалося останнім часом, які сценарії клієнтів ламаються найчастіше. Цього достатньо, щоб повернутися з оцінкою та планом перевірки.
Далі ми фіксуємо обсяг робіт і терміни, узгоджуємо пріоритети і лише після цього виходимо на тестування. До плану входить:
- інвентаризація компонентів, модулів і кастомних доопрацювань з оцінкою ризику;
- перевірка користувацьких сценаріїв: замовлення, оплата, реєстрація, особистий кабінет, форми;
- тестування обміну з 1С — вивантаження, синхронізація номенклатури, цін, залишків, замовлень;
- перевірка прав доступу та ролей: що бачить гість, менеджер, адміністратор;
- прогін по браузерах і пристроях, включно з мобільними сценаріями;
- навантажувальна перевірка ключових сторінок і точок входу;
- звіт з переліком дефектів, їхніми пріоритетами та рекомендаціями щодо усунення.
За підсумками ви отримуєте не абстрактне «все працює», а список конкретних місць, де поведінка системи розходиться з очікуваною, із зазначенням кроків відтворення. Це дозволяє планувати доопрацювання за фактом, а не за здогадками.
Розкажіть, що відбувається із сайтом зараз і який результат потрібен — повернемося з оцінкою, планом перевірки та термінами.