Модульне тестування перевіряє невелику частину коду окремо від решти системи.; # Зберегти документ.; # Тестування міграцій — перевірка змін структури бази даних.; Поширені помилки:
Але ручне тестування не повинно бути єдиним способом контролю якості.; з цієї причини помилка в коді має змогу мати не лише технічні, а й бізнесові наслідки.; Ручне тестування особливо корисне на етапі впровадження або перевірки нестандартної бізнес-логіки.; # Мета перевірки.;== Практичний висновок ==
Тестовий сценарій має описувати, що саме потрібно перевірити.; * правильність запитів;
У K2 ERP потрібно тестувати не тільки окремі функції Python-коду, а всю поведінку системи.; # Документувати нестандартні сценарії.; з цієї причини регресійне тестування є собою одним із найважливіших видів перевірки.; Це особливо корисно для:
Тестування коду в K2 ERP.;== Чому тестування важливе для ERP ==
- стандартні сценарії;
- нестандартні сценарії;
- порожні значення;
- неправильні значення;
- великі обсяги даних;
- різні ролі користувачів;
- різні статуси документів;
- різні періоди;
- різні валюти;
- різні склади;
- різні контрагенти.; інтеграційні функціональні можливості без тестування часто функціонує лише в ідеальних умовах.; * що код запускається;
- що основна логіка функціонує;
- що очевидні помилки виправлені;
- що не зламані пов’язані частини;
- що є собою зрозумілий характеристика змін;
- що зміна готова до перевірки аналітиком або користувачем.; * Інтеграційне тестування — перевірка взаємодії між частинами системи.;== Тестування інтеграцій ==
Якісне тестування надає можливість:
Тестування тільки на одному «ідеальному» прикладі не дає впевненості, що платформа функціонує правильно.;== Тестування оновлень ==
До тестування можуть входити:
У звичайній програмі помилка має змогу означати некрасивий інтерфейс або неправильне повідомлення.; Модульні тести корисні тим, що оперативно показують, де саме виникла помилка.; # Перевірити звіт продажів.; * Модульне тестування — перевірка окремої функції, класу або компонента.;== Пояснення термінів ==
Якщо компонент активно розвивається, автоматизовані тести зменшують ризик того, що нове доопрацювання зламає вже працюючу функціональність.; * неправильні залишки на складі;
- некоректну суму документа;
- помилку у взаєморозрахунках;
- дублювання замовлень;
- втрату даних;
- неправильний звіт для керівника;
- зламану інтеграцію з банком, сайтом або службою доставки;
- порушення прав доступу;
- неможливість провести документи;
- збій у виробничому процесі.; Перед змінами в базі даних потрібно мати резервну копію та зрозумілий план дій.; API потрібно тестувати як окремий програмний продукт.; як ілюстрація, зміна в документі продажу має змогу вплинути на складський облік, фінансовий блок, звіти, друковані форми та API.; Під час тестування звіту варто перевірити:
Потрібно перевірити:
Хороші практики
Програміст K2 ERP не повинен перекладати всю відповідальність за тестування на користувача.; користувач системи має змогу перевірити бізнес-сценарій, але програміст повинен відповідати за технічну якість.; # Повторно тестувати після виправлення помилки.; # Послідовність дій.; * K2 ERP
У K2 ERP тестування розглядається не як формальність і не як «додаткова опція», а як обов’язкова частина відповідальної розробки.; В ERP помилка має змогу означати:
Такі помилки створюють ризик, що проблема проявиться вже після запуску.; # Коментарі або знайдені помилки.; # Тестувати інтеграції на збоях.; Зміни в базі даних потрібно тестувати дуже обережно.; Особливо обережно потрібно впроваджувати зміни, які впливають на фінансовий блок, складський облік, виробництво, зарплату або зовнішні обміни.; Бізнес-логіка повинна тестуватися не лише з технічного, а й з предметного погляду.; * критичних алгоритмів;
- розрахунків;
- API;
- інтеграцій;
- перевірки прав доступу;
- регресійних тестів;
- оновлень;
- складної бізнес-логіки.; актуалізація K2 ERP або окремих модулів потрібно тестувати до встановлення на бойову систему.; * актуалізація модуля;
- зміни бізнес-логіки;
- рефакторингу;
- оптимізації запитів;
- зміни структури бази даних;
- додавання нової інтеграції;
- зміни прав доступу;
- виправлення помилки.; як ілюстрація:
- модулі;
- класи;
- команди;
- документи;
- довідники;
- звіти;
- друковані форми;
- API;
- інтеграції;
- права доступу;
- міграції бази даних;
- актуалізація;
- імпорт і експорт даних;
- фонові задачі;
- обробки;
- бізнес-процеси;
- дії користувача в інтерфейсі.; # Перед оновленням робити резервну копію.; Основні з них:
перевірки того забезпечується через Регресійне тестування потрібне; додатково реалізовано що нові зміни не зламали стару функціональність.; # Провести документ.; Під час тестування документа варто перевірити:
Для якісного тестування бажано мати окреме тестове середовище.; Не варто перевіряти небезпечні зміни одразу на робочій базі.;== Тестування API ==
Автоматизоване тестування надає можливість запускати перевірки багато разів без ручної роботи.; * чи проходить актуалізація без помилок;
- чи зберігаються інформаційні дані;
- чи працюють старі документи;
- чи не зламались звіти;
- чи не змінилася бізнес-логіка випадково;
- чи працюють інтеграції;
- чи коректно застосовані міграції;
- чи можна відкотитися в разі проблеми.; Потрібно перевіряти:
- створення запису;
- редагування;
- пошук;
- фільтрацію;
- унікальність;
- обов’язкові поля;
- ієрархію;
- зв’язки з документами;
- імпорт;
- експорт;
- права доступу;
- архівацію або деактивацію.; Це дія, яка має змогу змінювати стан бізнесу.;== Типові помилки при тестуванні ==
Це надає можливість відстежити, після якої зміни з’явилася проблема, і швидше знайти причину.; Потрібно перевіряти:
Документ у ERP — це не без ускладнень форма.;== Тестування перед впровадженням ==
Тестування бази даних
- створити замовлення клієнта;
- провести видаткову накладну;
- сформувати рахунок;
- перевірити зміну залишків;
- створити оплату;
- сформувати звіт;
- перевірити друковану форму;
- виконати обмін із зовнішнім сервісом;
- перевірити права різних користувачів.; це бізнес-процес перевірки програмної логіки.; Людина має змогу пропустити помилку, забути сценарій або перевірити не всі варіанти.; * що зміна не зламала існуючу функціональність;
- що новий компонент функціонує відповідно до вимог;
- що документи створюються і проводяться правильно;
- що звіти показують коректні інформаційні дані;
- що API повертає очікуваний результат;
- що інтеграції обробляють помилки;
- що права доступу не порушені;
- що актуалізація не пошкоджує інформаційні дані;
- що бізнес-процес після зміни залишається керованим.; # Перевірити друковану форму.; Саме з цієї причини тестування коду в ERP є собою критичною частиною розробки.; як ілюстрація, якщо замовлення не можна відвантажити без оплати, тест має перевірити не тільки стандартний сценарій, а й спробу обійти це правило через API, зміну статусу або іншу дію.; * Git — платформа контролю версій.; # Очікуваний результат.;== Роль користувача у тестуванні ==
- що користувач системи бачить лише дозволені інформаційні дані;
- що користувач системи не має змогу виконати заборонену дію;
- що API додатково дотримується прав доступу;
- що звіти не показують зайву інформацію;
- що кнопки, команди й обробки доступні лише потрібним ролям;
- що адміністраторські функції не відкриті звичайним користувачам.;== Тестове середовище ==
Тестування ERP має поєднувати технічну перевірку і бізнес-перевірку.; * Коміт — зафіксована зміна в Git.; У реальному бізнесі ідеальні умови трапляються не завжди.; Приклад структури сценарію:
У K2 ERP це має змогу бути взаємодія:
Ручне тестування потрібне там, де істотно перевірити реальний бізнес-сценарій.; # Інтеграційне тестування — перевірка взаємодії між модулями або зовнішніми системами.; Звіти потрібно перевіряти не тільки на відкриття, а й на правильність даних.; Тестування — це спосіб не вгадувати, а перевіряти.; # Використовувати тестове середовище.; Автоматизовані тести допомагають швидше знаходити помилки після змін у коді.; * Тестове середовище — окрема копія системи для безпечної перевірки змін.; ERP без тестування — це ризик.; * чи правильно платформа виконує бізнес-правила;
- чи не надає можливість заборонені дії;
- чи правильно реагує на виняткові ситуації;
- чи відповідає логіка реальному процесу підприємства;
- чи коректно працюють статуси документів;
- чи правильно обробляються різні ролі користувачів;
- чи не виникають приховані обхідні шляхи.; Документи в K2 ERP потрібно перевіряти особливо уважно.; Інтеграції потрібно тестувати з урахуванням реальних збоїв.; Права доступу є собою критичною частиною тестування.; # Додати товар.; * функція розрахунку суми;
- перевірка знижки;
- алгоритм формування номера документа;
- правило округлення;
- обробка статусу;
- перевірка дати;
- фільтрація списку;
- конвертація даних;
- підготовка відповіді API.; * успішний обмін;
- повторну відправку;
- часткову помилку;
- недоступність зовнішнього сервісу;
- неправильний формат відповіді;
- дублювання даних;
- затримку відповіді;
- зміну статусів;
- журнал обміну;
- ручне повторення операції;
- повідомлення адміністратору;
- відкат або компенсацію дій.; Тестування має бути пов’язане з контролем версій.; # Тестувати не тільки код, а й бізнес-сценарій.;== Автоматизоване тестування ==
Саме користувач системи має змогу сказати:
Тестові інформаційні дані
Головна ідея
- чи відповідає функціональність бізнес-вимогам;
- чи зручна форма;
- чи правильний звіт;
- чи не порушена логіка роботи;
- чи враховані винятки;
- чи можна використовувати зміну в реальній роботі.; # Перевіряти як успішні, так і помилкові ситуації.; # Тестування продуктивності — перевірка швидкості роботи запитів, звітів, API та обробок.; Перед впровадженням змін на бойову систему потрібно перевірити:
Потрібно перевіряти:
Тестування коду в K2 ERP — це захист бізнесу від помилок, хаосу та непередбачуваних наслідків.;== Тестування і Git ==
Інтеграційне тестування перевіряє, як різні частини системи працюють разом.; ERP-тестування завжди ширше, ніж проста перевірка: «чи не впав код».; * джерело даних;
- період;
- фільтри;
- групування;
- сортування;
- підсумки;
- деталізацію;
- права доступу;
- експорт;
- швидкість формування;
- відповідність очікуваному бізнес-результату.;== Тестування звітів ==
ERP-система функціонує з реальними бізнес-даними: документами, залишками, фінансами, взаєморозрахунками, замовленнями, складами, виробництвом, клієнтами та звітністю.; # Початкові умови.; Чим раніше знайдено помилку, тим дешевше її виправити.; # Фіксувати результати тестування.; Вони мають покривати:
Тестове середовище надає можливість:
- які зміни були зроблені;
- які тести запускалися;
- які помилки виправлені;
- яка реліз потрапила на тестування;
- яка реліз потрапила на бойову систему.; як ілюстрація:
Інтеграційні помилки часто складніші за звичайні.; Розробник має самостійно перевірити:
- код;
- міграції;
- документи;
- звіти;
- права доступу;
- інтеграції;
- API;
- продуктивність;
- резервне копіювання;
- можливість відкату;
- інструкції для користувачів.; # Фактичний результат.; # Перевіряти права доступу.; * Міграція — зміна структури бази даних або перетворення даних.; * Тестові інформаційні дані — спеціально підготовлені інформаційні дані для перевірки сценаріїв.; # Перевірити залишки.; Для тестування потрібні якісні тестові інформаційні дані.; як ілюстрація, якщо змінено правило розрахунку знижки, тест має змогу одразу показати, що для певного типу клієнта результат став неправильним.;== Помилки, які має знаходити тестування ==
- Ручне тестування — перевірка сценаріїв користувачем, програмістом або аналітиком.;== Регресійне тестування ==
Ручне тестування
- перевіряти зміни без ризику для бойових даних;
- моделювати бізнес-сценарії;
- тестувати актуалізація;
- перевіряти інтеграції;
- навчати користувачів;
- відтворювати помилки;
- експериментувати з новими модулями.;== Джерела ==
Що потрібно тестувати
Потрібно перевіряти:
Особливо істотно перевіряти звіти, на основі яких приймаються управлінські або фінансові рішення для бізнесу.;== Роль програміста у тестуванні ==
У K2 ERP можуть застосовуватися різні види тестування.; # Пов’язувати зміни з Git-комітами.;== Типовий тестовий сценарій ==
Це особливо істотно після:
Тестування документів
Тестування потрібне для того, щоб переконатися:
- Назва сценарію.; У Git бажано фіксувати:
Погано протестований довідник має змогу створювати проблеми в документах, звітах та інтеграціях.; * документа і регістру;
- модуля продажів і складу;
- CRM і замовлень;
- ERP і сайту;
- ERP і банку;
- ERP і служби доставки;
- API і зовнішнього клієнта;
- звіту і бази даних;
- бізнес-процесу і прав доступу.;== Інтеграційне тестування ==
користувач системи або бізнес-аналітик важливий для перевірки реального процесу.; Для API істотно перевірити:
Це має змогу бути:
Дивіться додатково
- Тестування коду — перевірка програмної логіки на правильність роботи.; # Модульне тестування — перевірка окремих функцій, класів або компонентів.; # Автоматизоване тестування — запуск тестів, які перевіряють код автономно.;== Тестування бізнес-логіки ==
Модульне тестування
Під час тестування коду в K2 ERP варто дотримуватися таких правил:
- тестування тільки одного сценарію;
- тестування тільки успішного випадку;
- відсутність перевірки прав доступу;
- відсутність тестового середовища;
- перевірка одразу на бойовій базі;
- відсутність фіксації результатів;
- ігнорування інтеграцій;
- відсутність регресійного тестування;
- тестування без реальних даних;
- відсутність резервної копії;
- виправлення без повторної перевірки.; * зменшити кількість помилок;
- безпечніше впроваджувати зміни;
- швидше знаходити причини збоїв;
- підтримувати стабільність ERP;
- контролювати бізнес-логіку;
- підвищувати довіру користувачів;
- зменшувати технічний борг;
- спокійніше оновлювати систему.; Особливо істотно тестувати ситуації, коли користувач системи намагається обійти інтерфейс і звернутися до функціональності напряму.; # Не забувати про регресійні тести.; * Python Documentation — unittest
- pytest Documentation
- Git Book
- Martin Fowler — The Practical Test Pyramid
- MediaWiki — Help:Formatting
- MediaWiki — Help:Links
