Як тестувати відеострім

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Привіт! Мене звати Микола Аврамук. Я QA та Streaming Engineer в Switcher.ai. Хочу поділитись своїм досвідом тестування лайв-відеострімінгу, а також отримати поради від ком’юніті. І як сказав мені один із досвідчених QA (це не секрет, це був Саня Романов): «Пиши про те, що хотів би прочитати, коли починав».

Підписуйтесь на мій блог на Substack: avramukk.substack.com

Коли ми читаємо статті про тестування потокового відео, ми часто розглядаємо PSNR, VMAF і SSIM. Найкраще, коли система стабільна і працює так, як очікується, щоб ми могли почати тестування обʼєктивних метрик, таких як VMAF.

Або коли ви вже є Netflixʼом:

Netflix Video Quality at Scale with Cosmos Microservices

Toward a Better Quality Metric for the Video Community

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

Дисклеймер: цей матеріал — поверхневий огляд, без деталей. Глибоке занурення будемо робити в наступних статтях.

Стратегія

Архітектура

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

Чим раніше почати планувати QA, тим краще. Де ще знайти краще використання підходу «shift left»?

Багато стрімінгових сервісів базуються на транскодер-сервері або кластері таких серверів.

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

Зазвичай процес передачі відеопотоку включає такі етапи:

1. Кодування (Encoding). Першим кроком є енкодування аудіо та відео даних у цифровий формат. Енкодер перетворює аналогові сигнали або сигнали з камер в цифровий формат, такий як H.264 або H.265 (також відомий як AVC і HEVC відповідно), який ефективно зберігає відео та аудіодані при відносно низькому обсязі даних.
2. Пакування у контейнер (Containerization). Після енкодування відео та аудіо дані упаковуються в контейнерний формат. MPEG-TS (MPEG Transport Stream) може бути одним з варіантів для контейнера, особливо якщо ви маєте справу з традиційними телекомунікаційними технологіями. Інші популярні контейнери включають MP4, FLV, WebM, а також спеціалізовані контейнери для різних протоколів стрімінгу.
3. Адаптивна або однорівнева передача (Adaptive or Single Bitrate Streaming). Залежно від обраної стратегії передачі, ви можете вибрати адаптивну або однорівневу передачу. В адаптивній стратегії відео дані енкодуються у різні роздільні здатності та бітрейти, і плеєр вибирає найбільш відповідний потік для конкретних умов мережі та відомостей про пристрій. В однорівневій передачі ви передаєте один конкретний потік.
4. Транспортування (Transport). Після енкодування та упакування в контейнер, відеодані готові до передачі мережею. Залежно від обраного протоколу можуть використовуватися різні механізми для транспортування. Протоколи, такі як RTMP, SRT, HLS, MPEG-DASH та WebRTC, надають специфічні механізми для передачі даних.
5. Мережева передача (Network Transmission). Відеодані передаються мережею до серверів, які можуть бути розташовані в різних регіонах або на серверах доставляння контенту (CDN — Content Delivery Network). Це забезпечує оптимальну швидкість та доступність стріму для глядачів з усього світу.
6. Декодування та відтворення (Decoding and Playback). На стороні глядача відеодані декодуються і відтворюються. Плеєр розпізнає формат контейнера та вибирає відповідний декодер для розкодування відео- та аудіоданих.

Готовий декодований потік ми спробуємо прийняти, перевірити його параметри.

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

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

Що перевіряти

Плануючи, що ви будете тестувати, потрібно дослідити вимоги і поставити ключові питання про те, які особливості має система і якої роботи від неї очікують.

Потокове відео передається за допомогою протоколів передачі. Це набір правил, які визначають, як відео і аудіо передаються мережею. Наприклад, ті що частіше зустрічаються — RTMP, SRT, HLS, MPEG-DASH, WebRTC. Кожен з них має свої особливості і перед тестуванням варто розуміти, як вони працюють. Ось тут добре описано основи їх роботи.

Будь-яка передача починається зі встановлення зʼєднання. Тому потрібно протестувати коректне встановлення з’єднань, виходячи з реалізацій різних протоколів. Всі вони використовують зʼєднання типу клієнт-сервер. А webRTC може і client-client.

Обовʼязково потрібно перевірити і негативні сценарії, коли зʼєднання не повинно бути встановлене, та різні випадки, повʼязані з контролем доступу.

Для тестування потоку нам потрібно його прийняти (як клієнт), декодувати і зберегти в контейнер, щоб подивись на дані, які там лежать. Або якщо у вас є інструменти, які можуть показати перевірені параметри сигналу на льоту — це дуже круто, варто ними скористатись.

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

Приймаємо цей стрім доступним вам декодером (як приклад, ffmpeg або vlc) і направляємо вихід у файл (контейнер). Гарний гайд з контейнерів можна почитати тут.

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

Переглянемо ці параметри (на прикладі mpeg ts, який прийнято по SRT).

Відео

• PID: використовується в MPEG-2 транспортному потоці, який зазвичай слугує для передачі відео та аудіо в мережах та системах трансляції для ідентифікації різних типів даних, таких як відео, аудіо, субтитри тощо, і допомагає забезпечити їх коректну передачу та синхронізацію. Я зустрічав системи, які приймали відео та аудіо на конкретних номерах PIDs, тому як мінімум ви маєте перевірити, які номери присвоюються вашим потокам. Перевірити кілька PIDs з різним вмістом.
• Кодек: перевіряємо лише ті, що підтримуються вашим енкодером. Найпопулярніші зараз H.264, H.265, VP9, AV1, MPEG-4. Звертайте увагу на те, що деякі кодеки потребують багато ресурсів. А ще гірше, якщо мультипоточність не підтримується або не налаштована, і все навантаження ляже на одне ядро, і воно буде завантажене більше ніж на 70-80%, то сервер може тротлити, а потік може бути пошкодженим, а тести будуть необʼєктивними.
• Profile: оголошуються за допомогою коду профілю (profile_idc), а іноді набору додаткових обмежень, що застосовуються в кодері. Код профілю та зазначені обмеження дозволяють дешифратору розпізнати вимоги до декодування цього конкретного бітового потоку.
• Level: це певний набір обмежень, які вказують на ступінь необхідної продуктивності декодера для профілю. Наприклад, рівень підтримки в профілі визначає максимальну роздільну здатність зображення, частоту кадрів і швидкість потоку, які може використовувати декодер. Декодер, який відповідає цьому рівню, повинен мати можливість декодувати всі бітові потоки, закодовані для цього рівня, і всі нижчі рівні.
• chroma format: практика кодування зображень шляхом реалізації меншої роздільної здатності для хромаінформації, ніж для інформації Luma, використовуючи переваги нижчої гостроти зорової системи людини для розрізнення кольорів.
• resolution: розміри фреймів у вашому потоці. Один з головних параметрів потоку. Якість вашого відео буде кращою зі збільшенням resolution. Але чим він вищий, тим більший бітрейт потрібен. І не забувайте дивитися на рівень завантаження системи на 2,4,8K.

1. SD (Standard Definition):
   480p: Around 500 Kbps to 1.5 Mbps
2. HD (High Definition):
   720p: Around 1.5 Mbps to 4 Mbps
   1080p: Around 3 Mbps to 6 Mbps
3. Full HD:
   1080p: Around 3 Mbps to 6 Mbps
4. 2K:
   1440p: Around 6 Mbps to 10 Mbps
5. 4K:
   2160p: Around 12 Mbps to 25 Mbps
6. 8K:
   4320p: Can vary significantly, but generally upwards of 30 Mbps

• bitrate: це кількість даних, яка передається за одиницю часу при відтворенні або передачі відео. Він вимірюється в бітах на секунду (bps). Відтворіть отримані відео та оцініть якість кожного варіанту бітрейту. Для цього можна використовувати візуальну оцінку або об’єктивні метри якості, такі як PSNR (Peak Signal-to-Noise Ratio) чи SSIM (Structural Similarity Index).

Він може бути CBR (Constant Bit Rate): CBR означає, що бітрейт залишається постійним протягом всього відео. Незалежно від складності контенту, однаковий обсяг даних використовується на всіх етапах кодування.

VBR (Variable Bit Rate): VBR означає, що бітрейт варіюється в залежності від складності вмісту. Чим складніша сцена, тим більше даних треба передати.

• framerate: частота кадрів, з якою передається відеосигнал. Бувають 24, 25,30,50,60,120. Перевірити частоту кадрів можна такими інструментами як ffprobe, mediainfo або VLC (не рекомендую, бо іноді він обманює). Для перевірки варто використати якісні вхідні дані, щоб бачити номер кожного кадру і переглянувши кожен фрейм, бути впевненим, що втрат кадрів немає.

Частота кадрів, як і бітрейт, може мати або CFR (Constant Frame Rate). У цьому режимі кожен кадр кодується з однаковою швидкістю і весь відеоролик використовує однакову кількість кадрів на секунду (fps). Або VFR (Variable Frame Rate) — у цьому режимі частота кадрів може варіюватися в залежності від складності контенту. Це може бути корисним для ситуацій, коли певні частини відео менш складні та можуть використовувати менше кадрів на секунду для економії обсягу даних, а складніші сцени можуть мати більше кадрів для забезпечення кращої якості.

• GOP: Group of Pictures (Група кадрів). У відеокодуванні GOP — це послідовність відеокадрів, що містить ключовий кадр (I-кадр) та один або декілька передбачуваних кадрів P та B, які використовують інформацію з попередніх або майбутніх кадрів для стиснення даних.

1. I-кадр (ключовий кадр). Це кадр, який не залежить від інших кадрів у GOP. Він містить повну інформацію про відеосцену і може використовуватися для декодування сам по собі. Оскільки I-кадр не залежить від інших кадрів, він зазвичай має більший розмір, ніж інші типи кадрів.
2. P-кадр (передбачуваний кадр). Ці кадри передбачаються на основі I-кадрів та інших P-кадрів в попередніх GOP. Вони містять тільки зміни відносно попередніх кадрів, що дозволяє зберігати їх з меншим об’ємом даних.
3. B-кадр (кадр між I та P). Ці кадри містять інформацію, яка базується на двох інших кадрах — I та P. Вони можуть ще більше зменшити об’єм даних.

Як правило, B frame не використовують в відеотрансляції з низькою затримкою з наступних причин:

• Затримка обчислень. Відеокодеки вимагають більше обчислень для декодування B-кадрів, оскільки їх потрібно побудувати на основі інших кадрів. Це може призвести до збільшення загальної затримки відеостріму.
• Затримка передачі. Використання B-кадрів може збільшити обсяг даних, які потрібно передати для відтворення відео. Це може вплинути на пропускну здатність мережі та збільшити затримку при передачі даних.
• Якість інтерполяції. Використання B-кадрів вимагає інтерполяції між референтними кадрами (I або P) для побудови B-кадрів. Це може призвести до певного рівня додаткової артефактності або зниження якості відтворення.
• Можливий розрив зв’язку. У випадку втрати B-кадра може виникнути проблема з декодуванням наступних кадрів, які можуть бути залежні від нього. Це може призвести до погіршення якості відтворення або затримок у відеострімі.

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

Перевірити структуру GOP в потоці можна спеціальними інструментами.

• key frame interval — показує відстань між ключовими I кадрами. Задається або в кількості кадрів, або в секундах. Можна підготувати різні тестові дані. Починаючи від того, що відео має абсолютно всі ключові кадри і до 10 секунд між ключовими кадрами. Дивимось як поводиться енкодер, який кодує такі відстані, та декодер, який буде це декодовувати. Оцінюємо якість зображення на різних інтервалах ключових кадрів.
• color space — колірний простір описує, як масив значень пікселів повинен відображатися на екрані. Він надає таку інформацію як значення пікселів у файлі, а також діапазон та значення цих значень. Перевіряємо, чи коректно декодер розуміє закодоване відео при різних значеннях, наприклад:
  • [BT.601](en.wikipedia.org/wiki/Rec._601) («Стандартна чіткість» або SD)
  • [BT.709](en.wikipedia.org/wiki/Rec._709) («високої чіткості» або HD)
  • [BT.2020](en.wikipedia.org/wiki/Rec._2020) («Ultra-High-Definition» або UHD)
  • bit depth: бітова глибина в відео належить до кількості бітів, використаних для представлення інформації про кольори кожного пікселя на зображенні або кадрі. Зазвичай в відео використовуються такі бітові глибини як 8 біт, 10 біт та 12 біт. Перевіряємо кожне значення.

• Scan type. Progressive та interlaced — це два різних підходи до відображення зображення на екрані, зокрема у відео.
  • Progressive (прогресивне сканування). У цьому режимі кожен кадр відео відображається повністю і всі рядки зображення обробляються одразу. Всі пікселі на екрані оновлюються одразу ж, що робить зображення чіткішим та плавним. Відео у форматі 720p, 1080p, 4K тощо використовують progressive сканування.
  • Interlaced (черезрядкове сканування). У цьому режимі кадр поділяється на дві половини — парні та непарні рядки. Спочатку відображаються всі парні рядки, а потім — непарні. Це було винайдено для зменшення кількості інформації, яку потрібно передати через обмежені канали зв’язку.

• aspect ratio — співвідношення сторін відеофрейму. Ваша система має коректно розуміти кожен тип і додавати чорні смуги, коли це необхідно, або ж передавати лише корисне навантаження згідно співвідношення сторін. Перевіряємо популярні значення і ті, які задані у вимогах.

• A/V syncronization: синхронізація аудіо та відео. Відома як lipsync. Готуємо відповідний контент, в якому можна легко зрозуміти зсув звуку та зображення.

• NTP sync: якщо ваш сервіс підтримує синхронізацію потоків за таймкодами, то потрібно перевірити, що це працює коректно. NTP працює над синхронізацією ваших потоків через відеокодери. NTP — це абревіатура від протоколу мережевого часу, інтернет-стандарту, який функціонує шляхом синхронізації ваших серверів і пристроїв з всесвітнім координованим часом (UTC). NTP працює шляхом синхронізації ваших пристроїв (у цьому випадку кодерів і декодерів) з NTP-сервером, який, своєю чергою, синхронізується з годинником «grandmaster» (часто одним з атомних годинників або GPS-годинником). NTP має точність до десятків мілісекунд через Інтернет, а за ідеальних обставин може бути точним до субмілісекундних рівнів. І ця точність — від годинника гросмейстера до вашого пристрою. Таким чином, ваші пристрої (які всі повинні бути підключені до одного NTP-сервера) будуть дуже близькі одне до одного з точки зору точності часу.
• PTS/DTS: PTS (Presentation Time Stamp) вказує на час, коли певний кадр або аудіофрагмент повинен бути показаний на екрані або відтворений на аудіовиході. DTS (Decoding Time Stamp) вказує на час, коли певний кадр або аудіофрагмент повинен бути декодований. Тут добре описано, як перевірити правильність цих міток у відеопотоці.
• Latency — це затримка, яка виникає між моментом створення відеосигналу на стороні джерела та моментом відтворення цього відеосигналу на стороні кінцевого користувача.

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

Аудіо

• PID: перевірте, що піди мають очікувані ідентифікаційні номери і що вони коректно декодуються і відтворюються.
• Codec: як і у відео, у аудіо є свої кодеки AAC, MP3, AC3, DTS, а також нестиснений звук PCM, що використовується для точного відтворення аудіосигналу, не застосовуючи стиснення даних.
• Bitrate: 96, 128, 192, 256 — перевіряємо, що енкодер правильно кодує значення і звук проходить без спотворень
• Channel layout: перевіряємо різні схеми каналів звуку, такі як mono, stereo (2.0), 2.1, 5.1, 7.1, 7.1.2, 9.1. Підготуйте багато комбінацій різних тестових даних, щоб перевіряти, чи правильно транскодер їх обробляє.
• Sample rate (частота дискретизації) — це параметр, який визначає, скільки разів за секунду збираються дані з аналогового звуку для перетворення їх в цифровий формат. Це є однією з ключових характеристик цифрового аудіо. Sample rate вимірюється в герцах (Гц) і вказує на кількість аудіосемплів, які записуються за одну секунду. Стандартним sample rate є 44100 Гц або 48000 Гц.
• Bit depth: параметр, який визначає точність зберігання або передачі звукової інформації у цифровому форматі. Вона вимірюється в бітах і показує, скільки різних значень може бути представлено для кожного аудіосемпла. Чим вища бітова глибина, тим більше можливих значень може бути записано для кожного звукового семпла, що спричиняє більшу точність і деталізацію звуку. Перевіряємо поширені значення: 8,16, 24, 32 біт.

Використовуйте тестові дані різного вмісту: людський голос, музика, шум, різні рівні аудіотону. Перевіряйте також пікові та кліпуючі (>0dB) значення.

Метадата

Далі варто перевірити метадані транспортного потоку, а для цього потрібно розуміти, що це.

Program Association Table (PAT). Ця таблиця надає інформацію про доступні програми у потоці MPEG-TS. Вона включає ідентифікатор таблиці відображення програми (PMT) для кожної програми, що дозволяє приймачам знаходити відповідну PMT для додаткової інформації.

Program Map Table (PMT). PMT надає деталі про компоненти конкретної програми, такі як аудіопотоки, відеопотоки, субтитри та інші дані. Кожен компонент ідентифікується ідентифікатором пакета (PID), а PMT допомагає приймачам розуміти, як обробляти та декодувати різні компоненти.

Service Information (SI). Метадані SI містять інформацію про послуги, такі як назви програм, описи та інформацію про постачальників послуг. Ці метадані допомагають користувачам визначити вміст, який вони хочуть переглядати.

Conditional Access Table (CAT). Ця таблиця містить інформацію, пов’язану з системами умовного доступу, які керують шифруванням та розшифруванням вмісту для авторизованих глядачів.

Event Information Table (EIT). Метадані EIT надають деталі про заплановані події, зокрема час початку, тривалість та назви програм. Вони особливо корисні для електронних програмних довідників (EPG), які допомагають користувачам навігувати серед доступного вмісту.

Network Information Table (NIT). Метадані NIT містять інформацію про саму мережу, таку як параметри налаштування, частота та деталі модуляції. Це особливо важливо для приймачів, щоб правильно налаштуватися на бажані канали.

Time and Date Table (TDT). Метадані TDT передають поточну інформацію про час та дату у потоці MPEG-TS. Вони допомагають забезпечити синхронізацію між передавачем та приймачем.

Descriptors. Дескриптори — це невеликі частини метаданих, які надають додаткову інформацію про вміст або компоненти у потоці MPEG-TS. Вони можуть містити деталі, такі як аудіо- та відеоформати кодування, інформацію про мову та інше.

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

Тому дуже важливо перевірити, що туди вкладається.

Статистика потоку в реальному часі

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

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

Test Environment

Internet connection. Перед тестуванням стрімінгу, переконайтеся що у вас стабільний інтернет із високою пропускною здатністю. Краще використовувати Ethernet зʼєднання з 1 Gbps. І тільки для тестування різних варіантів пропускної здатності використовуйте wifi (щоб змоделювати реального звичайного юзера) або інструменти, які допомагають гнучко налаштувати вашу пропускну здатність, latency, delay, lost packets і так далі. Для перевірки вашої мережі можна використати інструмент від Netflix fast.com, або speedtest чи тулу твіча.

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

Test Data

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

Ось деякі лінки на відкриті тестові відео.

streams:

• ottverse.com/free-hls-m3u8-test-urls
• github.com/...​bengarney/list-of-streams

files:

• mango.blender.org/download
• download.tsi.telecom-paristech.fr/gpac/dataset/dash/uhd
• medialab.sjtu.edu.cn/tag/dataset
• ultravideo.fi/#testsequences
• www.murideo.com/...​test-pattern-library.html

Види тестування

Юніт-тести. На першому етапі моліться Богу, щоб розробник написав кілька юніт-тестів і перевірив найдрібніші частини системи.

Component testing. Це перший рівень тестування, де окремі компоненти вашої системи перевіряються на правильну роботу. Саме тут було б круто, щоб ви окремо перевірили, як працюють енкодер, декодер, мультиплексори, фільтри і т. д. Пірнати кудись глибше (якщо ви не лютий С+±розробник, не бачу сенсу), тому просто сподівайтесь, що у розробника в цих компонентах є юніт-тести.

Integration testing:

• Component Integration Testing. Тут можна почати проєктувати кейси, де ваші модулі могли б уже взаємодіяти одне з одним і моделювати кейси, де хтось і них не виконає свої задачі, як очікується.
• System Integration Testing. На цьому рівні ви перевіряєте інтеграцію системи в цілому. Це включає перевірку взаємодії між різними компонентами, серверами, клієнтами та іншими частинами системи.
• Hardware Software Integration Testing. Цей вид тестування орієнтований на перевірку взаємодії між апаратними та програмними компонентами системи.
• Software Integration Testing. Тут ви зосереджуєтеся на інтеграції програмних компонентів, таких як програми, бібліотеки, сервіси та інші програмні модулі, що використовуються для стрімінгу.

System Testing. На цьому етапі ви вже маєте цілу систему, і ви перевіряєте, чи відповідає вона специфікаціям, чи працює коректно та задовольняє вимоги користувачів.

Після цього можна перейти до:

• Stability
• Load
• Stress
• Recovery
• Scalabillity
• Volume
• Reliability
• Failover and Recovery

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

Інструменти

Обов’язково підготуйте інструменти, які будете використовувати для конвертації, передачі, приймання та аналізу потоків. Серед них є open source або trial, якого буде достатньо. Ось ті що використовую я:

— ffmpeg

— ffprobe

— mediainfo

— ffplay

— ffmetrics

— ffbitrate

— Elecard:

— Stream Eye

— Quality Estimator

— Stream Analyzer

— Quality Gates

— HandBrake

— VidCOder

— VQProbe

— NetBalancer

— NetLimiter

— OBS

— vMix

— VLC

— SRTSTressTools

— thumb.co.il

— dvbsnoop.sourceforge.net

— github.com/tsduck/tsduck

— www.digitalekabeltelevisie.nl/dvb_inspector

— VMAF.DEV

Репортінг

Всі баги, що ви знаходите, важливо максимально підкріпити степами, логами, тестовими даними, скріншотами та відео. Тоді розробники будуть щасливі, а вас не будуть спамити проханнями допомогти.

Висновки

1. Щоб доставити до користувача продукт високої якості, потрібно визначитись, що саме ви робите і створювати грамотну стратегію тестування, яка зможе попередити більшість проблем.
2. Починати тестування ще до реалізації функціоналу (shift-left), бо потрібно багато ресурсів (особливо часу) на тестування.
3. Вивчити і розуміти, як працює ваша система, з яких компонентів складається і як вони взаємодіють.
4. Правильно розставити пріоритети в залежності від використання вашого продукту.
5. Бути уважним спостерігачем.

Нагадуємо, що у нас є QA-подкаст. Знаходьте більше цікавих матеріалів на DOU YouTube.