Тестуємо вбудовану систему швидко та ефективно

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

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

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

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

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

V модель

На мій погляд, V Model підходить для вбудованих систем найбільше. Ми можемо працювати у будь-якій парадигмі, але завжди необхідно пам’ятати про компоненти системи, їх інтеграцію та як вони будуть використовуватись.

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

Perspective-based та role-based review

Перевірка з точки зору перспективи та ролей повинна відбуватись на рівні вимог. Проте небагато інженерів можуть бути повністю впевненими у вимогах. Задача, що повинна бути виконана на рівні бізнесу та бути вхідними даними, часто виникає вже на рівні тестування. Це моя улюблена тема, тому що детальне її опрацювання допомагає зробити якісний продукт та уникнути багатьох критичних дефектів. Наведу всім доступний приклад — домашній роутер. А тепер скажу таку річ: роутер за 40$ та за 400$ можуть бути однаково якісними у своєму сегменті, але не все так просто. Тож почнемо, наприклад, з трансцендентності тестування. Якість вона як любов на вірність не має ні початку ні кінця. Тому треба бути чіткими у своїх бажаннях, а саме вимогах.

Business view

Стандарт Wi-Fi для домашнього роутеру та для роутеру в аеропорту нічим не відрізняється, то ж як така різниця може відбитися у вимогах з точки зору бізнесу. Для цього нам допоможуть документи маркетингу. В аеропорту ми гарантуємо, що безліч людей отримує доступ до інтернету. А дома ми гарантуємо, що мама у ванній зможе дивитись улюблений серіал, батько футбол, а дитина мультики. Та ще й одночасно. Бачите тут вимоги? Якщо ми будемо перевіряти доступ для дому, то ми влаштуємо щонайменше 4 стійкі відеопотоки. А для аеропорту ми будемо підключати 50 різних пристроїв одночасно. Бо це різні сегменти ринку та бізнесові задачі

Product view

Для того, щоб краще зрозуміти продукт, ми можемо ознайомитися з технічними характеристиками схожих роутерів та перевірити чи закладена у нас перевірка усіх складових. От написали, що ми підтримуємо все види безпеки — запланували перевірку. Написали ми, що у нашого продукту user-friendly інтерфейс — запланували перевірку на usability

Manufacturing та operations view

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

Value-based view

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

Hardware

Вбудовані системи, то є такі системи, що працюють на певному «залізі» та з певними апаратними обмеженнями. Серцем кожного пристрою є RAM та CPU.

Для того, щоб завантажити RAM, необхідно подумати які великі дані будуть потрапляти у систему. Якщо це електронна книжка, то необхідно перевірити завантаження великих файлів. Якщо це мережевий пристрій, то можна навантажити пакетами різних розмірів. А також на вбудованих пристроях є такі дефекти як: Segmentation fault, Kernel panic та memory leak. Такі баги є критичними. Під час таких проблем система просто вмирає. Перевіряються вони, паралельними операціями та навантаженням. А також пам’ять зазвичай «тече» при довготривалій роботі пристрою

Схожі обмеження стосуються і CPU, але проблеми с процесором виникають при інших умовах, тому що стосуються кількості операцій. Наприклад: Якщо ми хочемо навантажити пам’ять, то робимо це великими пакетами, а якщо процесор, то великою кількістю маленьких пакетів.

Також необхідно не забувати про периферію, яка може просто «відпасти» під високим навантаженням

Risks based testing

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

Key stakeholders. Наприклад: ми перевірили все для користувача, але не подумали про команду продавців які будуть їздити з продуктом на конференції. Для цього випадку, я познайомилась з усіма, хто залежить від нашого продукту та майже під кожного створила окремий Acceptance test plan. Навіть якщо це не стандартний підхід, але він дозволив уникнути багатьох критичних ситуацій.

Poor domain knowledge. Вбудовані системи часто існують поряд із прикладними науками. Наприклад Wi-Fi тісно зв’язаний з фізикою хвиль, безпека з математикою, медичні пристрої з хімією та біологією. На ці знання вкрай необхідно створити окремо програми навчання та враховувати при плануванні.

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

Poor requirements. Погано створенні вимоги є причиною найдорожчих дефектів. Протягом всього періоду проєкту необхідно поставити процес узгодження та тестування вимог.

Debugging. Відсутність можливості досліджувати дефекти. Погана система логів або відсутність доступу до компонентів може створити великі проблеми за затримки для релізів.

Equipment. Сюди входять слабкі машини для розробки, а також відсутність, або недостатня кількість DUT(device under test). Сюди можна віднести також відсутність пристроїв для тестування та відладки.

DoD(Definition of Done). На самому старті проєкту необхідно визначити, що ми вважаємо успішно розробленим проєктом. Без чіткого визначення важко розуміти ресурси та пріоритети. А також замовник може нескінченно просити щось ще зробити.

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

Unexpected certification. Сертифікації бувають як продукту, так і процесів. Якщо не знати про них завчасно, то може виникнути необхідність «все перероблювати» перед закінченням проєкту.

Architecture specific. Неправильно спроєктована система може призвести до повного провалу проєкту. Такі випадки трапляються і з апаратними і програмними компонентами. Наприклад апаратно одні компоненти горять, або створюють завади для інших. До програмних проблем можна віднести погану масштабованість.

Bonus

Практична порада для початківців та вже досвідчених інженерів на засвоєння матеріалу. Спробуйте написати вимоги до свого домашнього роутеру та покрити його тестами. Результати можна мені відправити на отримання зворотного зв’язку

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

JavaScript Community
Java Community
Embedded Community