Все, що вам потрібно знати про формати звітів у тестуванні З

Щоразу, коли я зустрічаюся з проектом, в якому без причини винайшли свій новий формат звітів мені хочеться зробити щось ще для популяризації існуючих форматів. Останнім часом таких випадків було декілька. У перший раз я додав підтримку підсвічування синтаксису TAP в бібліотеку highlight.js потім додав підтримку синтаксису формату SubUnit. Ну і в останній раз після зустрічі з одним із таких проектів я зібрав воєдино всю інформацію з цих форматів в одному місці і вийшла невелика книжка. Таким чином, цей текст — мій хрестовий похід проти разножопицы з тестовими результатами в розробці :)

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

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

Навіщо взагалі потрібні звіти?

У яких випадках вам може знадобитися зберігання звіту про виконане тестування:

оцінка поточного якості проекту на основі покриття тестами і отримання відповідей на питання: Закінчено тестування? Готовий продукт до релізу? З якою швидкістю розробка сходиться до релізу?
отримання статистики про частоту відтворення дефекту;
оцінка ефективності тестів (наскільки корисний тест і знаходить дефекти?);
обмін даними між командами, якщо ролі в команді розділені (наприклад, розробники і тестувальники);
стабільність тестів і функціональності в продукті (PASS/FAIL rate) з плином часу.

До того ж дані про тестування можна використовувати для постійного поліпшення самого тестування.

Огляд існуючих форматів

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

Завдяки винахідливості інженерів у світі розробки існує безліч форматів звітів. Але одні набули більшого поширення, ніж інші. Всі формати можна поділити на дві категорії:

закриті формати, винайдені компаніями для своїх комерційних продуктів;
відкриті формати.

Це може здатися дивним, але відкритість посприяла поширенню форматів з другої категорії. Як це вийшло з'ясувати? Я проаналізував півсотні найбільш поширених відкритих проектів і отримав наступні дані: 24 проекту зберігають тестові результати і ці дані доступні публічно, половина проектів якщо і використовує якийсь формат для тестових звітів, то це один з трьох форматів: TAP , JUnit і SubUnit.

Формат	Кількість проектів
TAP	19
JUnit	8
SubUnit	3
Власний	29

А що з популярністю цих форматів в комерційних проектах? опитування про використання форматів тестових даних у розробці комерційного ПЗ (36 голосів):

TAP — 3%;
JUnit — 58%;
SubUnit — 3%;
Інший формат — 36%.

Взагалі в природі крім форматів TAP, JUnit, SubUnit існують і інші формати, але я їх не буду тут розглядати і наведу список тільки в якості інформаційної довідки: DejaGnu , Selenium, TAPOUT , Microsoft Test, HP QuickTest Professional, IBM Rational Functional Tester, Gallio Test Report, Parasoft C/C++test, Ranorex, TestRail .

Тепер докладніше про кожен з трьох форматів.

Test Anything Protocol (TAP)

Самий старий формат для представлення результатів тестування. По суті lingua franca для тестування. Формат був створений для тестування першої версії інтерпретатора Perl в 1987 році. Пізніше Tim Bunce і Andreas K?nig написали модуль Test::Harness , що дозволило використовувати формат для тестування модулів Perl. Зараз формат має підтримку не тільки в Perl, але і в інших мовах програмування і фреймворках для тестування . У 2008 році на конференції YAPC::Europe була зроблена спроба розробити IETF стандарт для TAP, але ця спроба не увінчалася успіхом. Але є текстовий опис формату на сайті testanything.org , а модулі TAP::Spec::Parser і TAP::Parser::Grammar вважаються референсною реалізацією TAP.

Приклад виведення результатів тесту у форматі TAP:

# Hardware architecture: x86_64
# Timestamp: 2016-06-16 06:23 (GMT+1)
# 
TAP version 13
1..258
ok 1 - zdtm/static/conntracks # SKIP manual only run
ok 2 - zdtm/static/maps03 # SKIP manual only run
ok 3 - zdtm/static/mlock_setuid
ok 4 - zdtm/static/groups
ok 5 - zdtm/static/maps05
ok 6 - zdtm/static/pdeath_sig
ok 7 - zdtm/static/xids00
ok 8 - zdtm/static/proc-self
ok 9 - zdtm/static/file_fown
ok 10 - zdtm/static/eventfs00
ok 11 - zdtm/static/uptime_grow # SKIP manual only run
ok 12 - zdtm/static/signalfd00
ok 13 - zdtm/static/inotify_irmap
ok 14 - zdtm/static/fanotify00
ok 15 - zdtm/static/session00
ok 16 - zdtm/static/rlimits00
ok 17 - zdtm/static/maps04
ok 18 - zdtm/static/pty03
ok 19 - zdtm/static/pty02
...

Приклад звіту з додатковими полями:

1..1
 not ok 1 Wrong length 
---
 wanted: 5
 found: 4
 time: 2011-02-01 00:09:01-07
 extensions: 
 files: 
1.txt:
 name: 1.txt 
 file-type: text/plain 
 file-size: 43 
 content: c2FtcGxl ...

SubUnit

SubUnit є потоковим форматом. Спочатку був розроблений в 2005 році Робертом Коллинсом для юніт-тестування. Для SubUnit доступні утиліти для аналізу результатів (subunit-stats, subunit-ls і т. д. ) та бібліотеки для Python, C, C++ і Shell. Формат активно використовується в тестуванні компонентів проекту OpenStack, Linux дистрибутива Ubuntu і Samba. Є дві версії формату: перша версія зберігає результати в текстовому поданні, друга — в двійковому. Для обох версій доступна детальна специфікація формату .

Приклад виведення результатів тесту у форматі SubUnit:

 time: 2011-05-23 22:49:38.856075 Z
 test: mytest.SampleTestCase.runTest 
 failure: mytest.SampleTestCase.runTest 
 [ 
 Traceback (most recent call last): File "/media/windows/dev/java/qaworkspace/pythonnosetests/src/mytest.py", line
 11, in runTest self.assertEqual(len(s), 4, 'Wrong length') AssertionError: Wrong length 
 ] 
 time: 2011-05-2322:49:38.858163 Z

JUnit

xUnit — це збірна назва сімейства фреймворків для модульного тестування, структура і функціональність яких заснована на SUnit, що призначався для мови програмування Smalltalk. SUnit , розроблений Кентом Беком в 1998 році, отримав широку популярність і був адаптований для безлічі інших мов. Назви фреймворків цього сімейства утворені аналогічно «SUnit», зазвичай замінюється буква «S» на першу букву (або) у назві передбачуваного мови («JUnit» для Java, «NUnit» для програмної платформи .NET і т. д.). Незважаючи на спільні корені, формати для всіх фреймворків засновані на XML, але структура може відрізнятися (див. xunit-plugin ).

Приклад виведення результатів тесту у форматі JUnit:

<testsuites>
 <testsuite time="0.239100933074951"
failures="10"
name="access_t"
tests="14"
errors="1">
 <testcase name="(init)" time="0.180249929428101" />
 <testcase time="0.00193119049072266" name="1 - inet allow all">
 <failure type="TestFailed"
 message="not ok 1 - inet allow all"><![CDATA[not ok 1 - inet allow all]]></failure>
</testcase>
 <testcase name="2 - inet allow unix" time="0.00225496292114258">
 <failure type="TestFailed"
 message="not ok 2 - inet allow unix"><![CDATA[not ok 2 - inet allow unix]]></failure>
</testcase>
 <testcase time="0.00211286544799805" name="3 - inet deny all"></testcase>
 <testcase name="4 - inet deny unix" time="0.00119209289550781">
 <failure type="TestFailed"
 message="not ok 4 - inet deny unix"><![CDATA[not ok 4 - inet deny unix]]></failure>
</testcase>

Плюси і мінуси різних форматів

Незважаючи на те, що всі три формату створювалися для однієї мети — юніт-тестування, вони мають відмінності. У таблиці нижче проводиться порівняння цих форматів.

Параметр	TAP	SubUnit	JUnit
Человекочитаемый формат	Так	v1 — так, v2 — немає	Так?
Незалежність від мови програмування	Так	Так	Ні (незважаючи на те, що формати тестових звітів усіх фреймворків JUnit схожі один на одного, ці формати мають відмінності)
Підтримувані мови програмування	Perl, Python, PHP, Java, C, C++, C#, Lua, Shell, Ruby, Javascript, Pascal, PostgreSQL, Haskell, Lisp, Forth та інші	Python, C/C++, Shell	Java, .NET, C/C++, Fortran, Haskell, Perl, PHP, Python, Ruby
Початок використання	1988	2006	1994 ?
Можливість групування тестів за категоріями або тегами	Немає (в стані обговорення)	Так	Так
Можливість розширення	Так, є можливість додати YAML в звіт	Ні?	Ні?
Документація	Специфікація 13-ї версії	Кілька прикладів використання	Немає
Опис специфікації	Є референсна реалізація формату в Perl модулі Test::Harness , також була спроба розробити IETF стандарт для формату TAP	Опис обох версій формату є в Python Package Index	Офіційного опису стандарту не існує, але є XML схема для JUnit
Поле з часом виконання тесту	Так, у YAML	Так	Так
Підтримка розширених статусів тестів	Немає	Немає	Ні?
Можливість прикріплення файлів до тестових звітів	Так, файли закодовані в Base64, можна додавати в YAML	Так, можна додавати файли, закодовані в Base64	Так?

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

Інструменти для зберігання та аналізу результатів у тестуванні З

Найчастіше тестування вбудовують в процес розробки за допомогою інструментів безперервної інтеграції (Jenkins CI, BuildBot, Travis CI, Teamcity і т. д.) і їх використовують для аналізу результатів. Мій досвід показує, що окремі сервіси зберігання та аналізу результатів з можливістю інтеграції з системами CI зручніше, ніж плагін в одній з них. Інші досвідчені тестувальники . Хоча я розумію, що ці два випадки не показові :)

У таблиці перераховані системи для аналізу звітів про тестування в одному з трьох стандартних форматів.

Інструмент	Користувачі	Коментар
Subunit2SQL	OpenStack	Формат: SubUnit. Відео , слайди , Using SubUnit2SQL with the gate
Badger	2ГІС	Формати: JUnit. Відео: CodeFest , SQAdays
Allure	Яндекс та інші	Формати: JUnit. Розширення для Jenkins CI.
Tapper	Амазон	Формат: TAP (Test Anything Protocol). Розробка припинена.
Jenkins: Test Results Analyzer Plugin	?	Формати: JUnit, TAP (Test Anything Protocol). Розширення для Jenkins CI.
testrepository	?	Формати: SubUnit.

Корисні посилання

Список бібліотек та інструментів з підсвічуванням синтаксису стандартних тестових форматів:

highlight.js : SubUnit , TAP і JUnit (XML);
Pygments (Python syntax highlighter): TAP;
Rouge (Ruby syntax highlighter): TAP , JUnit ;
Vim : SubUnit і JUnit (XML);
Emacs : TAP .

Опубліковано: 19/06/17 @ 10:02
Розділ Блоги

SEO Блог