Сценарне тестування допомога програміста 1С

Тема сценарного тестування вже давно розкрита, а усвідомлення необхідності використання TDD і BDD тією чи іншою мірою є майже в кожній компанії. Винятком не стала і наша невелика група розробників на 1С. Однак, від моменту розуміння необхідності, до реального використання технології, проходить час, і на цьому шляху незміцнілі уми, як, наприклад, автор цієї статті, починають замислюватися про ефективність всієї цієї затії. Якщо вам цікаво як групка тямущих хлопців запровадила у своїй роботі щось схоже на сценарне тестування – ласкаво просимо.

Передісторія
На ринку існують дуже потужні та розвинуті засоби тестування користувальницького інтерфейсу. Є спеціальні мови опису сценаріїв, маса документації та методологій. Іншими словами, «Є проблема? Є рішення!».

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

Отже, дано: територіально розподілена група розробників 1С до 10 осіб, в середньому, до 5 активних проектів, в основному розробка кастомних рішень без використання типових продуктів 1С.

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

Після дослідження ряду інструментальних систем західних вендорів, а також, сценарного тестування від 1С версії 3.0, і xUnitFor1C, складалося враження, що ми ментально поки не доросли до впровадження цих технологій. Час ішов, а ми все ніяк не можемо дорости. При цьому, нутро все вимагало і вимагало хоч якогось рішення.

Піднявши старі записи, був в черговий раз складено список вимог до потенційного програмного продукту:

  • Рішення повинно бути хмарним
  • База тестів для всіх розробок повинна бути єдиною
  • Повинен бути контроль доступу до додатків (у кожного програміста свій пул розробок)
  • Розробка тестів та їх виконання має бути в одній IDE
  • Сценарії повинні програмуватися, а не записуватися діями користувача
  • Бажано, щоб мова програмування тестів був схожий на мову 1С
  • Запуск тестів повинен проводитися по одній кнопці, без попередніх маніпуляцій, компіляцій, збірок, выгрузок, завантажень та іншого
  • У процесі написання тесту повинна бути можливість аналізу структури вікон та реквізитів досліджуваного програми в термінах моделі керованого інтерфейсу 1С, і це має бути в тій програмі, де розробляється і сам тест. Повинна бути можливість отримання властивостей полів досліджуваного додатка, при проході по дереву контролів в базі тестування — досліджуване додаток повинен відгукуватися і показувати де цей контрол.
  • Для тестування бізнес-логіки не повинна використовуватися еталонна база
  • Для відпрацювання тесту, не повинна бути заготовлена спеціально база, всі тести повинні вміти працювати і створювати все що потрібно самі
Звичайно, список далеко не повний, і в тій чи іншій мірі присутній в інших програмних продуктах. Може здатися юнацьким максималізмом, але тільки при виконанні всіх цих умов в одному продукті ми бачили можливим впровадження сценарного тестування в нашій ситуації. Колеги можуть зі мною не погодитися, але я дотримуюся думки, що однією з ключових проблем якості і кількості тестів як таких є те, як швидко і зручно ці тести можна робити в безперервному режимі розробки програми.

Минуло, мабуть, ще півроку, і нарешті я прийняв рішення розпочати мляво-факультативному режимі розробку чергового велосипеда-тестувальника (далі — тестер), і ось, що з цього вийшло.

Як це виглядає
В результаті народилося додаток на базі 1С, в якому пишуться і виконуються сценарні тести для рішень на базі 1С. Щоденне використання приблизно таке: тестер відкритий у програміста на другому моніторі весь робочий день. В базі обліку проектів менеджер вказує обов'язковий набір тестів, якими повинен бути покритий проект.

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

Коли пишуться тести
На практиці написання тестів в половині випадків відбувається у процесі розробки (дуже зручно для автоматизації рутини, коли потрібно в кожному перезапуску повторювати одні і ті ж дії). В іншій половині – після. Як напевно помітив досвідчений читач, таку ситуацію складно назвати класичним BDD.

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

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

image
image

Зверху – розробляється додаток, знизу – тестер, в режимі тонкого клієнта, база тестів в хмарі. Код, який ви бачите, написаний на мові 1С. Код сценарію взаємодіє з запущеним клієнтським додатком через обгортки методів досліджуваного програми 1С, наприклад, ось як виглядає метод Choose (...);

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

Перейду до більш цікавим сценаріями.

Взаємозв'язок тестів
Для того, щоб розробити сценарій створення і проведення документа Assembling, як у попередньому прикладі, ми повинні мати масу додаткових даних: необхідний склад довідників, залишки матеріалів на складі, що як мінімум означає наявність якогось приходу на склад. Як я говорив раніше, ми для себе вирішили, що тести повинні виконуватися в умовах, коли еталонної бази не існує, існує тільки початковий образ додатки, де є як мінімум один користувач з правами, заповнені класифікатори, та значення за замовчуванням для комфортної роботи початкової користувача.

Однак, писати кожен раз повний сценарій, який буде створювати всі необхідні «по дорозі» дані буде неефективно. Хотілося б розробити параметризований тест, який не тільки вміє щось робити, але і приймати параметри. Наприклад, для того, щоб в базі створити надходження, для цього повинен бути тест, який його створить. І нічого нам не заважає зробити цей тест параметризированным, і передати в нього всі необхідні дані, наприклад, якою датою зробити прихід, на який склад і які матеріали/послуги прибуткувати. У свою чергу, тест по створенню парафії, буде використовувати тести по створенню складу, матеріалів, які будуть очікувати в параметрах вид упаковки, тип, коефіцієнти перерахунку та інше.

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

Ось приклад як тест створення Assembling готується до вступу:

image
(ціни, суми і кол-ва задаються у вигляді рядків, щоб уникнути проблем помилкового спрацьовування перевірки тесту у випадку його запуску в інший локаль, де роздільник тріад і дробової частини, наприклад, можуть відрізнятися)

У процесі виконання цього тесту, буде виконано ряд інших тестів, які створять все необхідне для можливості протестувати Assembling як такої. Ось приблизно, що вийде в результаті в базі:

image
image
Тестування бізнес логіки
Крім того, що всі кнопки «прокликались» та поля «повыбрались», захід з тестуванням залишило б глибокий рубець на серці, якби я не протестував результати роботи механізмів проведення документа, і не оцінив ситуацію обліковий ситуацію в базі.

Я зізнатися довго ламав голову, як це краще реалізувати так, щоб і без еталонної бази, і щоб легко і просто. Нічого кращого я не придумав, як просто виконувати перевірку рухів документа в зв'язці з тестуванням звітності.

Ось приклад звіту по руху документа в тестованому додатку:

image

Ось як ці руху буде перевіряти тестер:

image

Червоні області є значущими для перевірки. Крім областей, в тестері можна задати перевірку полів за шаблоном.

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

Контроль помилок
Є як мінімум три види помилок, які хотілося б контролювати. Перший вид – це помилки кодування, такі як ділення на нуль, звернення до неіснуючого властивості або методу. Другий вид помилок – помилки в логіці, наприклад, при натисканні на кнопку форма повинна закритися, але цього не відбувається, або при установці галочки, частина форми повинна стати недоступною або невидимою. І третій вид помилок, помилки бізнес логіки, наприклад, при списанні матеріалів зі складу, не вдалося визначити його наявність по базі. Всі три типи помилок можуть в тестері бути відпрацьовані. При спрацьовуванні, тестер реєструє виняток, записує його в лог і може показати стек викликів, наприклад, так:

image

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

Ось приклад реалізації такої перевірки в одному з тестів:

image
image

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

image

Висновок
В цілому, вийшов невеликий велосипедик в допомогу програміста 1С. В якості позитивних якостей програми, можна відзначити наступне:

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

  • Немає розкладу запуску тестів
  • Немає просунутої системи аналізу, графіків і звітів за результатом тестування
  • Не реалізовані ніякі автоматично розсилки повідомлення про те, що зламалося, хто і чому зламав
  • Немає зв'язку з репозиторіями, і версійності тестів
Тестер відкритий і безкоштовний, запускати бажано починаючи 8.3.8, але і на 8.3.7 теж буде працювати, якщо включити режим сумісності. Всередині є невелика довідка (підкачується з інету), обгортки методів є і російською мовою, dt-шник можна скачати звідси. Там є кілька прикладів для бухгалтерії корп 3.0.

Вдалих вам тестів друзі і спасибі за увагу!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.