Генерація автоматичних тестів: Excel, XML, XSLT, далі — скрізь

Проблема

Є певна функціональна область додатка: якась експертна система, що аналізує стан даних, та видає результат — безліч рекомендацій на базі набору правил. Компоненти системи покриті певним набором юніт-тестів, але основна «магія» полягає у виконанні правил. Набір правил визначено замовником на стадії проекту, конфігурація виконана.
Більше того, оскільки після першого приймання (це було довго і складно — тому, що “вручну") правила експертної системи регулярно вносяться зміни на вимогу замовника. При цьому, очевидно, непогано — б проводити регрессионное тестування системи, щоб переконатися, що інші правила все ще працюють коректно і ніяких побічних ефектів останні зміни не внесли.

Основна складність полягає навіть не в підготовці сценаріїв — вони є, а в їх виконанні. При виконанні сценаріїв “вручну", приблизно 99% часу і зусиль йде на підготовку тестових даних у додатку. Час виконання правил експертною системою і подальшого аналізу видається результату — незначно в порівнянні з підготовчою частиною. Складність виконання тестів, як відомо, серйозний негативний фактор, який породжує недовіру з боку замовника, і що впливає на розвиток системи («Зміниш щось, а потім тестувати ще прийдеться… Ну його...»).

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

Під катом буде розказано про одному підході, що реалізує цю ідею — з використанням MS Excel, XML і XSLT-перетворень.

Тест — це насамперед дані

А де найпростіше готувати дані, особливо непідготовленому користувачеві? В таблицях. Значить, перш за все — в MS Excel.

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

Отже, постановка завдання

  • забезпечити підготовку даних в MS Excel. Формат повинен бути розумним з точки зору зручності підготовки даних, простим для подальшої обробки, доступним для передачі бізнес користувачам (останнє — це факультативно, для початку зробимо інструмент для себе);
  • прийняти підготовлені дані і перетворити їх в код тесту.

Рішення

Пара додаткових вступних:
  • Конкретний формат подання даних в Excel поки не ясний і, мабуть, буде трохи змінюватися в пошуках оптимального подання;
  • Код тестового сценарію може з часом змінюватися (налагодження, виправлення дефектів, оптимізація).
Обидва пункти приводять до думки, що вихідні дані для тесту необхідно гранично оделить і від формату, в якому буде здійснюватися введення, і від процесу обробки та перетворення в код автотеста, оскільки обидві сторони будуть змінюватися.

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

Отже, архітектура рішення:
  1. Перетворити дані з Excel в XML формату
  2. Перетворити XML за допомогою XSLT у фінальний код тестового скрипта на довільній мові програмування
Конкретна реалізація на обох етапах може бути специфічна задачі. Але деякі загальні принципи, які, як мені здається, будуть корисні в будь-якому разі, наведені нижче:

Етап 1. Ведення даних в Excel

Тут, чесно кажучи, я обмежився веденням даних у вигляді табличних блоків. Фрагмент файла — на картинці.

image
  1. Блок починається з рядка, який містить назву блоку (осередок “A5"). Воно буде використано в якості імені xml-елемента, так що зміст повинен відповідати вимогам. У тій же устрій може бути необов'язковий «тип» (осередок «B5") — він буде використано в якості значення атрибута, так що теж має обмеження.
  2. Кожна колонка таблиці містить крім „офіційної“ назви, що представляє бізнес-терміни (рядок 8), ще два поля для „типу“ (рядок 6) та „технічного назви“ (рядок 7). У процесі підготовки даних технічні поля можна приховувати, але під час генерації коду використовуватися будуть саме вони.
  3. Колонок в таблиці може бути скільки завгодно. Скрипт завершує обробку колонок як тільки зустріне колонку з порожнім значенням „тип“ (колонка D).
  4. Колонки з „типом“, починаючи з нижнього підкреслення — пропускаються.
  5. Таблиця обробляється до тих пір, поки не зустрітися рядок з порожнім значенням у першій колонці (осередок „A11“)
  6. Скрипт зупиняється після 3 порожніх рядків.

Етап 2. Excel -> XML

Перетворення даних з аркуша Excel в XML — нескладне завдання. Перетворення здійснюється за допомогою коду VBA. Тут можуть бути варіанти, але мені так здалося простіше і швидше всього.
Нижче наведу лише кілька міркувань — як зробити фінальний інструмент зручніше в підтримці і використанні.
  1. Код представлений у вигляді Excel add-in.xlam) — для спрощення підтримки коду, коли кількість файлів з тестовими даними понад 1 і ці файли створюються/підтримуються більш ніж однією людиною. Крім того — це відповідає підходу поділу коду і даних;
  2. XSLT шаблони розміщуються в одному каталозі з файлом add-in — для спрощення підтримки;
  3. Генеруються файли: проміжний XML і результуючий файл з кодом, — бажано поміщати в той же каталог, що і файл Excel з вихідними даними. Людям створює тестові скрипти буде зручніше і швидше працювати з результатами;
  4. Excel файл може містити декілька листів з даними для тестів — вони використовуються для організації варіативності даних для тесту (наприклад, якщо тестується процес, в якому необхідно перевірити реакцію системи на кожному кроці): откопировал лист, поміняв частину вхідних даних і очікуваних результатів — готово. Все в одному файлі;
  5. Оскільки всі аркуші книги Excel повинні мати унікальне ім'я — цю унікальність можна використовувати в якості частини імені тестового сценарію. Такий підхід дає гарантовану унікальність імен різних подсценариев в рамках сценарію. А якщо включати в ім'я тестового скрипта назву файлу, то досягти унікальності назв скриптів стає ще простіше — що особливо важливо у випадку якщо тестові дані готують кілька людей незалежно. Крім того, стандартний підхід до імен допоможе надалі при аналізі результатів тесту — від результатів виконання до вихідними даними буде дістатися дуже просто;
  6. Дані з усіх аркушів книги зберігаються в один XML файл. Для нас це здалося доцільним у випадку генерації тестової документації, та деяких випадках генерації тестових сценаріїв;
  7. створення файла з даними для тіста зручно виявилося мати можливість не включати в генерацію окремі аркуші з вихідними даними (з різних причин; наприклад, дані для одного з п'яти сценаріїв ще не готові — а тести проганяти пора). Для цього ми використовуємо угоду: аркуші, на яких назва починається з символу нижнього підкреслення — виключаються з генерації;
  8. У файлі зручно тримати лист з деталями сценарію, за яким створюються тестові дані («Documentation») — туди можна копіювати інформацію від замовника, вносити коментарі, тримати базові дані та константи, на які посилаються інші листи з даними, і так далі. Зрозуміло, що даний лист в генерації не бере;
  9. Щоб мати можливість впливати на деякі аспекти генерації фінального коду тестових скриптів, виявилося зручним включати у фінальний XML додаткову інформацію опції генерації», які не є тестовими даними, але можуть використовуватися шаблоном для включення або виключення ділянок коду (за аналогією з pragma, define, ітп.) Для цього ми використовуємо іменовані комірки, розміщені на негенерируемом аркуші «Options»;
  10. Кожна рядок тестових даних повинна мати унікальний ідентифікатор на рівні XML — це здорово допоможе при генерації коду і при обробці крос-посилань між рядками тестових даних, які при цьому необхідно формулювати в термінах саме цих унікальних ідентифікаторів.
Фрагмент XML який виходить з даних в Excel з картинки вище
<MasterRecord type="Type1">
<columns>
<column>
<type>Field</type>
<name>TechName1</name>
<caption>Business Name 1</caption>
</column>
<column>
<type>Field</type>
<name>TechName2</name>
<caption>Business Name 2</caption>
</column>
<column>
<type>Field</type>
<name>TechName3</name>
<caption>Business Name 3</caption>
</column>
</columns>
<row id="Type1_1">
<Field name="TechName1">A</Field>
<Field name="TechName2">123</Field>
<Field name="TechName3">2016-01-01</Field>
</row>
<row id="Type1_2">
<Field name="TechName1">B</Field>
<Field name="TechName2">456</Field>
<Field name="TechName3">2016-01-01</Field>
</row>
</MasterRecord>


Етап 3. XML -> Code

Ця частина гранично специфічна завдань що вирішуються, тому обмежуся загальними зауваженнями.
  1. Початкова ітерація починається з елементів, що становлять листи (різні тестові сценарії). Тут можна розміщувати блоки setup / teardown, утиліт;
  2. Ітерація по елементам даних усередині елемента сценарію повинна починатися з елементів очікуваних результатів. Так можна логічно організувати згенеровані тести за принципом «один тест — одна перевірка»;
  3. Бажано явно розділити на рівні шаблонів області, де генеруються дані, виконується перевіряється дію, і контролюється отриманий результат. Це можливо шляхом використання шаблонів з режимами (mode). Така структура шаблону дозволить в подальшому робити інші варіанти генерації — просто імпортуючи цей шаблон і перекриваючи у новому шаблоні необхідну область;
  4. Поряд з кодом, у той же файл буде зручно включити довідку по запуску тестів;
  5. Дуже зручним є виділення коду генерації даних в окремо викликається блок (процедуру) — так щоб його можна було використовувати як в рамках тесту, так і незалежно, для налагодження або просто створення набору тестових даних.

Фінальний коментар

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

Висновок

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

У нашому проекті вдалося досить швидко створити набір тестових сценаріїв для інтеграційного тестування складної функціональної області — всього на даний момент близько 60 файлів, що генеруються приблизно в 180 тестових класів tSQLt (фреймворк для тестування логіки на стороні MS SQL Server). У планах — використовувати підхід для розширення тестування цієї та інших функціональних областей проекту.

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

Код VBA для перетворення Excel файлів XML і запуску перетворення (разом з прикладом Excel і XML) можна взяти на GitHub github.com/serhit/TestDataGenerator.
Перетворення XSLT не включено в репозиторій, оскільки воно генерує код для конкретної задачі — у вас все одно буде свій. Буду радий коментарям та pull request'ам.

Happy testing!
Джерело: Хабрахабр

0 коментарів

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