Тестування вбудованого ПО: особливості, складнощі, рішення

11.09.2016

Тестування вбудованого ПО: особливості, складнощі, рішення

Створення ефективної тестової платформи – інфраструктура, віртуальна лабораторія і процес тестування.

Особливості тестування програмно-апаратних засобів

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

M2M замість UI

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

Залежність від обладнання

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

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

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

У порівнянні зі стандартною розробкою, такі речі, як «стан гонки» (далі використовується оригінальна назва – «race conditions»), найчастіше викликаються не взаємодією внутрішніх компонентів самого програмного забезпечення, а взаємодією програмного забезпечення з середовищем. Таким чином, кількість факторів і параметрів, що впливають на роботу вбудованого ПО набагато вище. Відтворення дефектів тому також набагато складніше.

Складнощі оновлення вбудованого ПЗ

Процедури підтримки, такі як розгортання і оновлення програмного забезпечення, отримання налагоджувальної інформації, також відрізняються від того, що використовується для традиційного прикладного програмного забезпечення, де можна покладатися на plug-and-play, автоматичну конфігурацію, майстри установки, наявність зручного відладчика в IDE, або, щонайменше, можна скинути лог-файл на диск.

У світі вбудованого ПО оновлення потребують перекладу програмного забезпечення в спеціальний режим, видалення EEPROM-захисту від запису, підключення до сервера роздачі файлів (наприклад, TFTP), кількох перезавантажень і тому подібних речей. Таким чином, весь цей процес дуже тривалий і незручний. Крім того, може виявитися, що пристрій зберігання файлів підтримує тільки обмежена кількість циклів перезапису.

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

Необхідність проміжних інструментів тестування

Тестувати M2M-інтерфейси вручну неможливо. Тому перед початком тестування вбудованого ПО нам необхідно розробити спеціальні додатки агенти тестування, які дозволяють створювати вхідний сигнал і отримувати відповідь системи через доступні інтерфейси. Часто також потрібно емулювати специфічні патерни електричних сигналів на різних лініях передачі даних, щоб протестувати поведінку вбудованого ПО в різних ситуаціях. Для цього може використовуватися спеціальний апаратно-програмний комплекс.

Обмежена доступність обладнання

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

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

Проблеми з визначенням джерела дефектів

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

Висока цінність кожного виявленого дефекту

Ми вже писали вище про те, що у випадку з вбудованим ПО дефекти відтворити складніше. Саме тому кожен такий дефект цінний сам по собі, і обов’язок тестувальника – зібрати максимум інформації про нього в момент виявлення, так як другий раз відтворити його, можливо, вдасться не скоро. У поєднанні з дуже обмеженими можливостями з налагодження програмно-апаратних засобів це ставить перед інженерами додаткові непрості завдання.

Обмеження, пов’язані з оновленнями програмного забезпечення, вимагають наполегливості і завзятості в процесі тестування, виявлення максимальної кількості дефектів для кожної версії програмного забезпечення, надають особливу важливість процесів збирання і розгортання.

Високі вимоги до автономності системи

Необхідність стійкості системи до введення некоректних даних і її автономності вимагає дуже ретельного стресового тестування. Як наслідок – потрібно емулювати послідовність швидко змінюваних подій, щоб перевірити код на всі можливі race conditions.

Основи підходу і платформи тестування

Автоматизоване тестування

Очевидно, що використання ручного тестування в якості основного методу для вбудованого ПО практично не реалізовується. Необхідність проведення рутинного, тривалого, повторюваного стресового тестування; робота з M2M-інтерфейсами; висока потреба в виявленні race conditions для часто-змінюваних подій ,, а також ряд інших факторів підводять нас до висновку, що поле бою залишається за автоматизованим тестуванням.

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

Проектування тестів і відстеження вимог

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

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

Валідація інфраструктури для підтримки тестування

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

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

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

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

Відстеження і аналіз дефектів

Крім, власне, самих процесів верифікації та валідації, необхідність проведення валідації інфраструктури підтримки тестування впливає на життєвий цикл дефектів і настройку сховища відстеження дефектів. Для програмно-апаратних засобів необхідно враховувати кілька можливих варіантів походження дефектів: кінцеве ПО, апаратне забезпечення або інфраструктура підтримки тестування. На практиці це вимагає вказівки для кожного виявленого дефекту ідентифікаторів цільового ПО, апаратного забезпечення та інструменту тестування. Крім того, рекомендується включити представника команди розробки допоміжної інфраструктури тестування в робочу групу по приоритизации завдань при усуненні дефектів (далі використовується в оригінальному значенні – triage committee).

Для пошуку дефектів, викликаних апаратним забезпеченням, команда тестування повинна включати в себе фахівця з хорошими знаннями в області апаратного забезпечення і досвідом роботи з різними інструментмі з налагодження апаратного забезпечення, згаданих вище. Цей фахівець також повинен входити в triage committee. У його завдання входить аналіз кожного дефекту на предмет його виникнення внаслідок проблем з апаратним забезпеченням, збір і аналіз додаткових даних при виникненні припущень в апаратній походження дефекту, а також консультування команди тестування в разі будь-якого сумнівного поведінки апаратного забезпечення.

Матриця покриття апаратного забезпечення

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

У будь-якому випадку матриця покриття апаратного забезпечення необхідна. У ній повинні міститися всі комбінації «тестовий сценарій – модуль апаратного забезпечення», які заплановані до верифікації. З цілком зрозумілих причин, середа автоматизованого тестування повинна дозволяти подальші специфікацію і зміна матриці, які не повинні позначатися при цьому на тестових сценаріїв.

Відстеження збірок програмного забезпечення

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

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

Інший метод використовується для smoke-тестів для стабільних версій ПЗ. На практиці інфраструктура підтримки тестування містить в собі всі необхідні інструменти для створення збірки, призначення їй унікального номера, маркування її в дереві вихідного коду, архівації бінарних файлів, передачі їх на сервер розгортання (TFTP-сервер) і потім на цільову плату, а також поновлення ПО на платі. Всі ці операції можуть бути виконані перед початком нічного smoke-тесту для стабільної збірки ПЗ. Для проектів, які не мають обмежень за кількістю оновлень ПО для цільового апаратного модуля, ці операції можуть бути виконані повністю (збірка і розгортання на платі) або частково (тільки розгортання) перед кожною збіркою, гарантуючи тестування правильної версії ПЗ.

Підтримка налагодження

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

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

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

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

Прогони тестів

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

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

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

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

Віртуальна лабораторія

Методологічні підходи, описані в попередніх розділах, дозволяють побудувати ефективний процес тестування програмно-апаратних засобів. Проте є і ще одна важлива частина цього процесу – програмно-апаратний комплекс «Віртуальна лабораторія» (Virtual Laboratory або VL). Даний комплекс надає кошти для вирішення деяких технічно складних завдань, з якими можна зіткнутися під час тестування.

По-перше, він включає в себе базу даних існуючих апаратних модулів, кожному з яких присвоєно простий строковий ідентифікатор. Для кожного модуля можна вказати кілька ознак, таких як версія апаратного забезпечення, ідентифікатори каналу зв’язку: IP-адреса, MAC-адресу, логін і пароль до системи і т.д. Для тестового сценарію це означає, що, знаючи ідентифікатор модуля, він може відновити всі інші ознаки, необхідні для комунікації з даною платою і надати повноцінний звіт про дефекти.

По-друге, VL підтримує роботу з послідовними консолями, стійками харчування (пристрої, що дозволяють включати і вимикати харчування на цільових апаратних модулях), реле з сухими контактами. Відповідні консолі / реле / ​​стійки вказані для конкретних модулів в базі даних, що дозволяє тестовим сценаріями виконувати будь-які операції з конкретним модулем, знаючи тільки його ім’я.

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

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

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

10 головних проблем автоматизації, які необхідно вирішити при тестуванні вбудованого ПО

1. Фізичний доступ до вбудованої системи для проведення тестування або отримання результатів. Для датчиків і деяких інших апаратних інтерфейсів, можливо, будуть потрібні особливі умови доступу.

2. Можливості підтримки автоматизації тестування в самому продукті. Перехоплювачі, пастки для підключення тестових засобів або викликані API-інтерфейси повинні бути додані в код продукту спочатку.

3. Верифікація поведінки. Рекомпіляції вбудованого коду на ПК часто впливає на час прогону.

4. Доступність обладнання. Проводьте верифікаційні тести на оригінальному обладнанні. Автоматизація на симуляторі не замінює тестування безпосередньо на пристрої.

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

6. Питання тимчасових характеристик. В деякі пристрої вбудовано ПО, залежне від контролерів часу.

7. Експерти в команді. Команді потрібні люди, підковані як в технології, так і в тестуванні.

8. Автоматизація мультимедійних компонентів. Неважливо, що це – відтворення звуків або миготіння світлодіодів, – все повинно бути протестовано.

9. Обмеження пам’яті. Бувають ситуації, коли оперативної пам’яті занадто мало, що викликає збій системи.

10. Недетермінізм тестованої системи. Завдяки цілому ряду причин (race conditions, генератори випадкових чисел, стан системи) тестована система може вести себе по-різному в різні прогони тестів, що істотно ускладнює тестове покриття і проходження критеріїв Pass / Fail.

 

Андрій Пронін, В’ячеслав Ванюлін, Ігор Починок, Auriga, Inc., НИВЦ МГУ

Джерела: RTSoft і LogiGear

 

При використанні матеріалів сайту vkt.ua активне посилання на джерело обов’язкове

Статьи

30.04.2018

Ринок індустрії 4.0, Internet of Things (IoT) і Industrial Internet of Things (IIoT) буде продовжувати розвиватися в 2018 році, як прогнозують аналітики ринку галузевої (читать далее)

27.04.2018

Всесвітня торгова ярмарка Embedded World відбулася в 15-й раз з 27 лютого по 1 березня 2018 року в Нюрнберзі. Як завжди, не обійшлося без (читать далее)