Автоматизація тестування: «безпілотник» Acronis Kernel


http://bp-la.ru/bespilotnyj-apparat-danem)
Білд => Тест => Не пройдено => і кілометри логів, розкиданих по різних системах, і десятки хвилин зведення кінців з кінцями у пошуках причини збою. Знайоме?
А якщо інакше?
Білд => Тест => Не пройдено => Тікет в JIRA — і розробник бере баг в роботу, тому як вся інформація у нього вже є.
Працюючи в команді Acronis Kernel, я задався метою створити саме такий автотест.
Під катом — моя історія.
Введення
Тестування програмного забезпечення — це дослідження з метою забезпечити зацікавлені сторони (Stakeholders, далі-Замовники) інформацією про якість продукту або послуги (з Вікіпедії).
Замовники сприймають результати тестування по-різному:
  • Продукт менеджер дивиться, які фічі продукту готові до релізу, а які доведеться спростити \ відкласти \ викинути.
  • Тест менеджера цікавлять деталі дослідження: типи виконаних тестів, покриття коду \ вимог, витрачений час, детальні результати, а також будь-які збої \ помилки \ складності, які можуть негативно позначитися на об'єктивності результату тестів.
  • Розробнику потрібні дефекти: зрозуміло описані, відтворювані, що включають всю необхідну для фікса інформацію.
  • Тестувальник отримує завдання, виконує тест, який аналізує результат, репортит баги. По можливості, розширює тестове покриття шляхом додавання нових тестів або тестових оточень (середовищ).
Дані повинні бути доступні як можна швидше, в ідеалі — в реальному часі, відразу по появі нової збірки продукту.
Тепер уявімо робочий процес, достатній для виконання зазначених вимог:
  1. Тести стартують відразу з появи нової збірки продукту;
  2. Час виконання тестів визначається прийнятим в компанії процесом розробки, але не повинно перевищувати середнього часу між появами нової збірки;
  3. Виявлені помилки автоматично аналізуються, вже відомі помилки приписуються до існуючих дефектів, решта реєструються у вигляді нових дефектів — протягом лічених хвилин після виявлення;
  4. Результати тестів відзначаються на "Карті якості продукту".
Тут, у команді Acronis Kernel, ми побудували такий процес — не відразу, звичайно.
Спершу розповім, з чого ми починали.
Prehistoric

http://spongebob.wikia.com/wiki/Primitive_Sponge)

Машинерія

  • [велосипед] Control Center (СС) — написаний на пітоні планувальник завдань, також зберігає тест плани і малює звіти
  • [велосипед] AutoTest Management System (ATMS) — java-based менеджер віртуальних і фізичних ресурсів
  • [велосипед] Кастомный DSL для налаштування тестового оточення
  • [велосипед] Кастомный Python unittest-based фреймворк для написання власне тестів, з XML конфіг. Подекуди в конфіги була вбудована логіка тесту
  • [велосипед] Кастомний версія TestLink — тут, по ідеї, повинні жити докладні описи тест кейсів і результати їх виконання. За фактом, використовувався в основному для отримання унікального ID сценарію (групи тестів)
  • Віртуальні машини на ESX-i

Працювало це все приблизно так

  1. З'явилася нова збірка.
  2. CC відзначав появу збірки, і, відповідно до що зберігається в ньому ж плану тестування, створював нові завдання в Testlink.
  3. ATMS знаходив завдання в TestLink і просив для них ресурси у гіпервізора. Черг завдань не було: хто встиг захопити ресурс, той і прав.
  4. Отримавши необхідний набір VM, ATMS налаштовував в них Guest OS. Рецепт налаштування задавався у вигляді кастомного DSL.
  5. Далі управління передавалося Python бібліотеці, яка завершувала конфігурування оточення, деплоила білд і запускала тести.
  6. Після завершення тестів, АТМС збирав логи і результати тесту, оновлював статус завдання в TestLink.
  7. CC бачив завершення завдання в TestLink, забирав результати, оновлював свою базу статистики і відправляв листом звіт про результати тестування. Пізніше Control Center взяв на себе функції TestLink, і завдання стали створюватися в його внутрішній базі, эмулирующей Testlink для клієнта — ATMS.
Тести йшли кілька годин, часто даючи випадковий (невоспроизводимый) результат. Для аналізу фейлов проходили цілий квест з відвідуванням ATMS, CC, кулі з логами, детальним розбором логів і пошуком аналогічних багів в Jira — все врукопашну.
Зареєстровані збої іноді відтворювалися, частіше — ні. З більшості порушених багів розробники просили уточнити кроки, надати віртуальну машину або докласти забуті логи.
Приблизно раз в тиждень ATMS падав. Якщо тест завис, або з іншої причини ресурси не звільнилися, доводилося вручну видаляти віртуальні машини, знімати завдання АТМС і обнулити лічильник зайнятості хоста.
Порівняти результати тестів на різних збірках можна було по статичним email-репортам з графіком Тип результату / Номер збірки, або перебираючи результати вручну в СС. Щоб порівняти результати одного і того ж тесту на різних операційних системах, доводилося вручну переглядати логи тестів з кожної ОС.
В результаті, девелопери не довіряли автотестам, більше покладаючись на ручний запуск власних тестів на своєму оточенні. Подібна "механізація" мене ніяк не влаштовувала, ситуацію треба було виправляти.
Brave New World

http://dkrack.wikispaces.com/Brave+New+World)

В основу архітектури нової системи автотестів лягли:

  • Jenkins — планувальник завдань, менеджер ресурсів, хранитель історії тестів і детальних результатів
  • Віртуальні машини на ESX-i
  • Python, Pytest — пошук тестів по тегам, параметризований запуск, контроль виконання і вивід результату у форматі junit.xml (стандартний формат для Jenkins)
  • JIRA — результати тесту у вигляді багів, показники успішності проекту
0 (нуль) велосипедів.

Шлях завдання

  1. При успішному складанні билдсервер (теж Jenkins) стартує проект на тестовому Jenkins, ставлячи тест в чергу.
  2. Тестовий Jenkins резервує ресурси (VM linked clone), викачує свіжий код тестів з SVN, запускає CMD скрипт для налаштування оточення і кличе pytest.
  3. Pytest з допомогою вбудованої функції test discovery підбирає кейси і стартує тест. Код фреймворку виконується на Gate VM — контрольної машині, а System Under Test (в нашому випадку kernel driver) розгортається на Test VM, щоб у разі BSOD не втратити результати.
    • Стандартна python logging бібліотека пише info лог і debug log в двох різних файлів:
      a) Info лог містить кроки тіста і відповідає двом вимогам: 1) human readable формат, 2) інформації достатньо для відтворення збою.
      b) Debug лог включає таймштамп, адреса \ номер рядка виконуваного коду і розгорнуте повідомлення. Лог дозволяє відстежити детальну історію подій, прямо не відносяться до суті тесту, але впливають на результат: чи вдалося встановити з'єднання, скільки часу виконувався ребут, etc.
    • Тест зупиняється при виявленні першого ж збою (результат assert = False). Pytest записує результат + трейс в junit xml.

  4. Jenkins (JUnit Plugin) публікує звіт і стартує python скрипт за репорту багів.
  5. Скрипт шукає вже відомі відкриті баги в Jira, якщо знаходить — залишає коментар "Відтворено там-то", якщо немає — реєструє новий баг. Повідомлення про помилку (pytest assert) йде в заголовок, кроки Info лода — опис, самі логи тіста і драйверів аттачатся до багу.
Наведу схему для наочності:

© Acronis)
Ім'я бага додається суфіксом імені VM, так що девелопери легко можуть знайти машину при необхідності. Машинка, на якій пісня закінчилась вже відомий баг, буде автоматично видалена через три дні. Машинка з новим багом буде автоматично видалений після того, як розробник переведе її в статус Resolved, а відповідний тест пройде без помилок.

Приклад автоматично заведеного бага


© Acronis)
Раніше автоматизатор змушений був 80-90% часу витрачати на ручний розбір результатів тестів. Тепер досить подивитися на список багів в Jira. Баг продукту йде розробникам, збій тестів автоматизатор забирає собі. Якщо якоїсь інформації в баг репорте не вистачає, не потрібно вчити людей заводити баги інакше — достатньо змінити код.

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


© Acronis)
Підтримка тестів звелася до обробки в коді ще неврахованих видів збоїв. Corner cases будуть завжди, це треба розуміти, і не варто ставити метою позбавлення від 100% збоїв автотеста\тестовій інфраструктури. Достатньо перетворити ці збої в конкретні action items — баги в Jira, в нашому випадку, і виправляти їх один за іншим.

Карта якості продукту

Загальний огляд стану тестованих компонент тепер можна отримати, поглянувши на Jenkins dashboard:

© Acronis)
Дашборд реалізований з допомогою плагіна https://wiki.jenkins-ci.org/display/JENKINS/Dashboard+View.
Можливо, не всі читачі знайомі з Jenkins, так що поясню значення колонок:
  • S (Status) — результат останньої збірки (в нашому випадку тесту);
  • Name — назва тесту;
  • W (Weather) — іконографіка, що показує історію якості збірки, на 5 збірок тому. Сонечко означає, що усі 5 збірок успішні, грозова хмара — усі 5 збірок погані;
  • Build Parameters — в нашому випадку вказаний шлях, відповідний гілці коду і містить номер складання;
  • Last Duration — час виконання останньої збірки, починаючи з моменту постановки замовлення в чергу, і до моменту завершення збору логів з останнього оточення і відправки звіту про результати тесту;
  • Build Description — опис збірки автотест додає номери багів, автоматично заведених в Jira, із зазначенням, новий це баг (new), або вже відомий (upd);
  • Last Success, Last Failure — як давно була зроблена остання успішна / неуспішна складання.
Результати
Систему, яку я описав вище, ми побудували і налагодили до кінця осені минулого року, і потім активно додавали нові сценарії для тестування. З лютого 2016 року я перейшов full time на інший проект.
За час моєї відсутності (півроку):
  • Знайдено і заведено автоматично 129 коректних багів — приблизно по одному новому багу кожен робочий день.
  • З інших джерел заведено 48 багів.
Проект півроку жив і розвивався зусиллями тільки розробників, без єдиного тестувальника. Розробники самостійно додали новий компонент, створивши Jenkins проекти і Pyhton код за аналогією з існуючими.
Некоректних багів за цей час теж заведено досить багато, в основному дублікатів, народжених некоректним сетапом нового тесту або відмовами тестового сервера. Однак це вже тема для окремої статті.
Джерело: Хабрахабр

0 коментарів

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