Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

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

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | 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

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Стандарт Wi-Fi для домашнього роутеру та для роутеру в аеропорту нічим не відрізняється, то ж як така різниця може відбитися у вимогах з точки зору бізнесу. Для цього нам допоможуть документи маркетингу. В аеропорту ми гарантуємо, що безліч людей отримує доступ до інтернету. А дома ми гарантуємо, що мама у ванній зможе дивитись улюблений серіал, батько футбол, а дитина мультики. Та ще й одночасно. Бачите тут вимоги? Якщо ми будемо перевіряти доступ для дому, то ми влаштуємо щонайменше 4 стійкі відеопотоки. А для аеропорту ми будемо підключати 50 різних пристроїв одночасно. Бо це різні сегменти ринку та бізнесові задачі

В корне не согласен. High load тестирование помогает выявлять проблемы в софте. Цель тестировщика — не замаскировать проблемы или притворится, что их нет, а выявить их, если они есть.

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

Память течёт не при долгой работе, а при частых вызовах определённого кода — и задача тестера не тестировать долго, а тестировать так, чтобы в единицу времени вызывалось как можно большее количество кода и тогда даже утёчка 4 байт за вызов быстро станет заметной на системном уровне. High load тестирование как раз и позволяет выполнять код чаще.

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

Это какой-то очень специфический локальный опыт, который по ошибке проецируется на все кейсы. Количество и размер «пакетов» обычно ортогональны к загрузке памяти и процессора. У многих роутеров вообще аппаратный проброс пакетов между интерфейсами — ему всё равно что маленькие, что большие пакеты. И опять выходит на сцену high load тестирование и теория массового обслуживания, чтобы загрузить роутер на полную нужно найти сценарий в котором он будет постоянно ждать окончания предыдущей обработки и в это время количество заявок поступающих в систему будет расти. Т.е. загружать быстрее, чем он может обрабатывать.

Ох Майк. Если вы уже пишете «в корне не согласны» То хоть бы написали в чем. То, что вы пишете, что в корне не согласны — это примеры, а не полное раскрытие темы, в которых я на 100% уверена. Примеры != все возможные случаи. А по тексту написаны основные направляющие, про которые много кто забывает. Часто без DoD идет басконечная верификация без валидации. Часто забывают проверки на уровне юнитов. А вы знали Майк, что вот это вот

Память течёт не при долгой работе, а при частых вызовах определённого кода —

очень ошибочное утверждение. Что при нормально написанном коде память как раз не течет при частом вызове определенного участка кода ? А вы знали, что проверить свои функции на очистку буфера и адекватную инициализацию — это ответсвенность разработчика и относится к компонентному тестированию? У меня есть как раз подозрение, что я говорю с разработчиком, а не тестировщиком, который не строил тестирование для разных проектов и еще и плохо проверяет свой код на уровне юнитов, раз у вас память течет при частом обращении к вашему участку кода. И где тут по тексту у меня написано, что

Цель тестировщика — не замаскировать проблемы или притворится, что их нет, а выявить их, если они есть.

? Можете мне показать?

Кстати, дорогие разработчики, которые убеждены, что код ревью и юнит тесты — это не их зона ответственности. Которые писатели своего кода, а не читатели.
Один из рисков, который я забыла написать, но судя по коментам хочу добавить. Важным источником багов и проблем является, плохое ревью кода и отсутствие юнит тестов. А это ваша, дорогие мои, зона ответсвенности. Тестировщики работают на уровне интеграции. А формулировка " плохо протестированный код" в принципе не корректная в сторону тестировщиков. Потому что код — это часть статического тестирования и ответсвенность разработчиков. Я согласна, что можно привести больше примеров. Но memory leak — это говнокод . Который способен найти часто даже статический анализатор. И то, что мы знаем, что такое утечка памяти, то этим не гордятся, а стараются быстро у себя в коде исправить и никому об этом не говорить :)

Ох Майк. Если вы уже пишете «в корне не согласны» То хоть бы написали в чем.

Я же отцитировал то, с чем несогласен. Странный подход в тестировании в зависимости от типичных use case’ов. Которые не являются каким-то стандартом поведения, а просто допущения, которые тестировщик не имеет права делать. Это не его сфера.

Что при нормально написанном коде память как раз не течет при частом вызове определенного участка кода ?

Мы разве это обсуждаем? Мы обсуждаем утёчки памяти и если они есть, то тестировать нужно не долго, а часто.

У меня есть как раз подозрение, что я говорю с разработчиком, а не тестировщиком

И что? Я работаю в embedded компании и наблюдаю все процессы тестирования, имею доступ к отчётам и прочее, потому что это часть моей работы.

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

Сложная embedded система часто использует shared memory, поэтому утечки могут быть не технические, а логические, когда паттерн использования системы допускает, что память не будет освобождаться, когда может быть ещё нужна и что тот момент, когда она не нужна — настал, довольно тяжело определить. Для этого есть тестеры, которые тестируют систему в сборе.

А вы знали, что проверить свои функции на очистку буфера и адекватную инициализацию — это ответсвенность разработчика и относится к компонентному тестированию?

Мы говорим об embedded тестировании, когда тестирование часто возможно только в комплексе.

? Можете мне показать?

Я же отцитировал то место. Вот оно ещё раз:

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

Тестирование с меньшей нагрузкой, а не максимальной и есть маскирование потенциальных проблем.

1.

Я же отцитировал то место. Вот оно ещё раз:

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

Это примеры, которые показывали разность подходов для разных сегментов бизнесса.
Если у нас ограничены ресурсы, то мы не маскируем дефекты, а стараемся покрыть максимальное количество критичных для бизнеса задач в первую очередь. Теория тестирования гласит, что тестирование не может быть исчерпывающим(а именно 7 базовых принцыпов, а именно второй: Exhaustive testing is impossible.). Поэтому важно формирование правильного базиса(Test basis).
Например, не все точки доступа дают 4 устойчивых видеопотока, для этого нужно перепиливать очереди в драйвере. Но если бизнесс акцентирует внимание именно на этом. То данный юзкейс будет иметь более высокий приоритет чем 50 подключений для домашнего устройства. И важно при тестировании изучать маркентиальную документацию, чтобы покрыть в первую очередь критичные для бизнесса аспекты.

Но опять таки. Это примеры. Для других проектов будут другие примеры. Тут важно найти и изучить маркентиальную документацию. Тоесть акцент тут на том, чтобы написать заказчику запрос на предоставление MRD

И важно при тестировании изучать маркентиальную документацию, чтобы покрыть в первую очередь критичные для бизнесса аспекты.

Мы никогда не подходим к тестированию embedded систем подобным образом. Тестирование всегда повёрнуто в сторону системы, а не в сторону бизнес-аспектов. Потому что заказчики имеют свойство тиражировать успешные решения, которые в новых условиях могут быть неработоспособными. Во избежание этого тестирование всегда нацелено внутрь, чтобы оттестировать стабильность всех внутренних подсистем.

Так вы — производитель железа, а они — продавец.
У вас разные типы покупателей.
На стиральной машине из магазина написано, что она не предназначена для прачечных, и если поставишь в прачечную — пропадет гарантия.

Не гоните беса и читайте комментарий выше. И познакомьтесь, наконец, с V-model, которая вам так не нравится

Не гоните беса и читайте комментарий выше.

Ничего не понял.

Простите, если, я не поняла какой комментарий куда относился. Я женщина горячая и у меня «в интернете кто-то не прав». Повторите, пожалуйста, подробнее, что вы имеете ввиду.

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

Написав «пошли лесом» теряешь клиента. И славу.
И надо понимать, что твое железо может, а что — нет.

Я работала и на железе и на bring-up и на интеграции и на софте. И да нужно уточнить вы разрабатываете для прачечных или для дома. И это важно!!!

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

И какой из этого вывод?

Почему я должен делать выводы под Вашей статьей?

Производитель железа обязан протестировать все сценарии, так как не знает, как этим железом будут пользоваться.

Вам обязан :))) закону обязан? :))) по сертификации обязан? :))) в какой стране обязан? :)))

Своим покупателям, иначе испортит репутацию.

Во избежание этого тестирование всегда нацелено внутрь,

Это вы откуда взяли???

Тестирование бывает разных уровней, что собственно прекрасно показано на V-model. Минимально: unit, integration, system, acceptance. Помимо этого есть ещё валидация и верификация. Где верификация — это проверить, что напрограммировали, а валидация — нужно ли это бизнессу. Так вот, я не предлагаю разработке делать валидацию, а прошу максимально тщательно проверить свой юнит уровень, чтобы у нас осталось время на все остальное. Тем не менее, когда я работала на chip-vendor. То сам тимлид по разработке dsp, просил нас по максимуму посмотреть систему на всех уровнях. Потому что он знает, что разработка нового dsp стоит огромное количество денег, включая palladium для моделирования силикона. Этот разработчик знал цену своей ошибки, поэтому просил подключиться бизнесс как можно раньше, чтобы не сделать решение, которое не масштабируется или падает.
Также, если вы погуглите, то сможете найти известную багу на аппаратом уровне в r-car архитектуре, из-за которой остановился Maclaren. О которой знали разработчики и не эскалировали вовремя. Поэтому подобные заявления я считаю не профессионализмом и вредительством

Ох Майк. Если вы уже пишете «в корне не согласны» То хоть бы написали в чем.
Я же отцитировал то, с чем несогласен. Странный подход в тестировании в зависимости от типичных use case’ов. Которые не являются каким-то стандартом поведения, а просто допущения, которые тестировщик не имеет права делать. Это не его сфера.

Это подход, который позволяет увидеть основные самые критичные аспекты и их включить с высоким приоритетом. А дальше, если останутся ресурсы, то можно тестить в свое удовольствие. Основная проблема, которую я замечаю в тестировании на самых разных проектах , что все натестились, а важное не замечают

На всякий случай добавляю 7 базовых принципов тестирования для ознакомления:
The seven principles of testing
Testing shows the presence of defects, not their absence. ...
Exhaustive testing is impossible. ...
Early testing saves time and money. ...
Defects cluster together. ...
Beware of the pesticide paradox. ...
Testing is context dependent. ...
Absence-of-errors is a fallacy.

На всякий случай добавляю 7 базовых принципов тестирования для ознакомления:

Если не сложно, просветите откуда эти 10...простите 7 заповедей взялись?

Они легко гуглятся и великолепно расписаны. Предполагаю, что теория тестирования вам не особо интересна, если такой вопрос возникает. Они входят в сертификационный экзам и в приличное количество книг по тестированию.

То что эти принципы где-то расписаны и куда-то входят не отвечает на вопрос.
А вопрос был откуда эти принципы взялись, то бишь какое у них обоснование ?

Я все еще пытаюсь выяснить контекст. Я их опубликовала в рамках обсуждения, что тестировщики не могут найти все ошибки в коде на том уровне, на котором происходит тестирование и пыталась переложить часть ответсвенности за качество кода на разработку. В статье опубликовала аспекты, которые стоит брать во внимание, чтобы учесть основные риски. Теперь пытаюсь понять ваш вопрос. Вы не согласны с каким-то из принцыпов, хотите разобраться в системном подходе к тестированию или интересуетесь историей тестирования? По вопросу «от куда взялись» и «то бишь какое у них обоснование» я даже теряюсь, что вам ответить.

Вы ссылаетесь на 7 стейтментов, как на некий фундаментальный базис.
Каждый из этих стейтментов может быть либо обоснован, либо нет.
И вопрос был есть ли у этих тезисов логическое обоснование, и если есть то где это можно почитать?
Для контекста, беглый и не очень гугл выдает только формулировки этих тезисов, но не обоснования.(подробно раписаная формулировка это еще не обоснование) Вот и пытаюсь выяснить, есть ли у этих стейтментов логическое обоснование, т.е. доказаны ли они. И если доказаны то где. Потому что если обоснования нет, то это уже не 7 фундаментальных принципов, а теория плоской земли.

Вот вы меня прямо удивили :) Где я написала, что это фундаментальный базис? Я скажу больше, что я считаю, что по тестированию отстуствует фундаменталиный базис. Что с развитием теории тестирования от жесткой аналитики и комбираторики, начали развиваться более исследователские подходы, потому что стало ясно, что ни один подход не может быть исчерпывающим. Эти 7 принцыпов (не стейтментов) сформулировал International Software Testing Qualifications Board. Поэтому, это вы так прочитали про

фундаментальный базис.

 и начали с собой же спорить. А конкретного вопроса я так и не услышала :)

На всякий случай добавляю 7 базовых принципов тестирования для ознакомления

Вот же, базовые принципы...и ссылка на них как на некий фундаментальный базис...
(не популярные, не известные, а именно базовые)

Эти 7 принцыпов (не стейтментов)

Это все-таки не принципы, а утверждения (стейтменты). Потому как приципам следуют, а утверждения (простите за тафтологию) утверждают
И это не одно и то же

А конкретного вопроса я так и не услышала :)

Напишу еще раз. Есть ли у этих стейтментов логическое обоснование, оно же доказательство ? Если есть, то где его можно почитать ?

Обоснование не равно доказательство :) Что мы доказываем? Что следование принцыпам гарантирует качество?

Что мы доказываем? Что следование принцыпам гарантирует качество?

Нет, доказываем что некое утверждение верно или не верно.
Те базовые принципы, если внимательно посмотреть это не приципы, а набор утверждений.
И вопрос был, есть ли доказательство этих утверждений ?
(хотя бы логическое обоснование)

Я не принимаю ничего без личного опыта. Что-то использую что-то нет. Доказательства нужны вам. Я нашла для вас первоисточник www.istqb.org
Им можна написать запрос и потребовать от них доказательства :)

Из оригинала цитаты:
A number of testing principles have been suggested over the past 50 years and offer general guidelines
common for all testing.
Специально для вас нашла в источнике ссылки:See Myers 2011, Kaner 2002, Weinberg 2008, and Beizer 1990 for examples of these and other testing
principles.

Ну я рада, что вы «не такой » и свой код проверяете.

и еще и плохо проверяет свой код на уровне юнитов, раз у вас память течет при частом обращении к вашему участку кода.
Сложная embedded система часто использует shared memory, поэтому утечки могут быть не технические, а логические, когда паттерн использования системы допускает, что память не будет освобождаться, когда может быть ещё нужна и что тот момент, когда она не нужна — настал, довольно тяжело определить. Для этого есть тестеры, которые тестируют систему в сборе.

Да, я думаю, что стоит на каждый упомянутый аспект написать по статье. И по производительности тоже. Тут очень много всего. Failover and recovery. Что система после сбоя выживает. Тут еще не указан volume, на который стоит обратить внимание. MTBF. А также стресс тестирование, когда мы прерываем корректную работу не корректным поведением либо стрессовой нагрузкой. Тут очень много не рассписано. Если будет спрос, то можно будет сделать отдельную статью на нагрузочные тесты.
Поэтому, в такой постановке я с вами вполне согласна. Но ваш комментарий тоже не есть исчерпывающим. Тут целая статья нужна на Performance тестирование под Embedded

и еще и плохо проверяет свой код на уровне юнитов, раз у вас память течет при частом обращении к вашему участку кода.
Сложная embedded система часто использует shared memory, поэтому утечки могут быть не технические, а логические, когда паттерн использования системы допускает, что память не будет освобождаться, когда может быть ещё нужна и что тот момент, когда она не нужна — настал, довольно тяжело определить. Для этого есть тестеры, которые тестируют систему в сборе.

Ничего, это вызывает уважение, что разработчики интересуются качеством тоже. Я просто решила, что важно упомянуть, что код ревью и что юнит тесты тоже важны. Правда ведь?

Я также хочу сказать, что при всем старании тестировщиков в сжатые сроки, мы тоже не все утечки найдем. Что нам важна ваша помощь как программистов тоже, а не перекидывание всей ответственности на команду тестирования

То, что я знаю, что такое shared memory, то это уже из-за довольно большого опыта. Обычно это не является компетенцией тестировщика. Также как и межпроцессный обмен, deadlock. и многое другое, во что приходится иногда вникать почему-то. Поэтому опять таки настою на том, что эту информацию нам нужно передавать, если вы видите риски. Или проверять на уровне команды разработки.

Поэтому опять таки настою на том, что эту информацию нам нужно передавать, если вы видите риски. Или проверять на уровне команды разработки.

Если тестировщики не в состоянии проверить black box, то они не занимаются quality assurance, а только создают иллюзию защищенности.

Какими техниками black — box тестирования вы владеете? И что вы подразумеваете под «иллюзия защищённости»? А так же какие процессы вы внедряли для quality assurance. Мне важно понять ваш контекс, а то я снова предположу, что вы не владеете материалом.

Я утверждаю, что если тестировщики надеются, что программисты им скажут «у нас может течь память при работе VPN», и не в состоянии сами обнаружить такую утечку памяти, то это — плохие тестировщики. Потому что очень много утечек пойдет в релиз.

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

Я осмелюсь утверждать, что самые лучшие тестировщики не смогут найти все утечки памяти.

Хорошие тестировщики — попытаются найти. Плохие — будут тестировать по требованиям и документам от разработчиков, а что не описано в требованиях — уйдет в продакшн неоттестированым.

Это разница в том, нужно ли роутер перезагружать каждый день по расписанию, или можно не перезагружать месяцами.

то это — плохие тестировщики.

То чувство, когда всю жизнь работал только с плохими тестировщиками // Ты требуешь от тестировщика слишком многого. Тестировщику, даже синьеру, очень часто нужно объяснять все как джуну девелоперу

Я говорю о том, что написано в книжках по тестированию.
Тестировщик должен стать заменой продакт овнера — он знает полную функциональность лучше девелоперов, и понимает UX, в отличии от девелоперов.
Если надо объяснять — значит, UX плохой, или нет инструкции по эксплуатации.

Я баг нашел в процессе тестирования статьи. Опечатка в заголовке. Должно быть не «ситему» а «систему» ))) А по сути статьи — интересно, спасибо.

Спасибо, исправил опечатку.

Спасибо, чувствуется, что глаз наметан

Присоединяйтесь к нашему Embedded Community, где Вика — один из ключевых драйверов! www.facebook.com/groups/EmbeddedCommunity

Вика — один из ключевых драйверов

Иван Фёдорович Крузенштерн — человек и пароход, Вика — человек и драйвер.

Майк, шас там в ГЛ потуги набирати гребців, тре піар, бо крокодил не ловіцца, нє ростьот какос:
news.finance.ua/...​bilsh-zatrebuvani-sogodni

У меня подгорело, когда я пришла в универ, а основной спрос среди студентов: быстро научиться делать вэбочку и уехать на Бали. В этом чувствуется определённое вырождение увлечённости. Мы стараемся держать фокус на технологиях в комьюнити, там нет было рекрутинговых активностей. Я верю, что деньги играют роль, но существует интерес к технологиям в природе тоже.

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

Я верю, что деньги играют роль, но существует интерес к технологиям в природе тоже.

хіхі

А можна отримати доступ до public API Віки?

Фу какой неприличный!

Циць, не твій драйвер, от ти і бісишся :-)

Я ж знаю, куди ти потім полізеш вказівником за офсетами

Можливо, вже якийсь master-device захопив цей драйвер, і наші вказівники виявляться повним NULL’Ом

Макс, чтобы дать вам API нужно понять
типы данных и протокол обмена. Я есть во всех сетях. К каким моим public ресурсам Вам нужен доступ?

типы данных и протокол обмена.

Трохи про сам тип з’єднання: симплексний режим, 2-ох бітне кодування, швидкість приблизно 1.5-2 ТБ/сек. Сама структура даних поміщається в багатотисячну кількість сторінок документації, та до кінця не зовсім відома.

К каким моим public ресурсам Вам нужен доступ?

$ ip link show

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

тобто то й же Лінукс, але на Распбері + V модель, це автомотів з Лінуксом, чи як?

Загалом набір тез.
Тема не розкрита.

Не збивайте все у купу. Так, операційна система Лінукс підходить під цю групу. Щодо розкриття, задавайте питання. А V-model не дорівнює автомотив. І не дорівнює важкі документовані процеси. «Важкі документовані процеси для автомотів на базі V-model» — то мабуть ви маєте на увазі A-SPICE?

Я маю на увазі що стаття — набір тез.
Могли би привести один приклад.
Що проектували, як тестували.

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

В середині текстку закралась підорзра що мова про вайфай роутер.

В бонус секції це відчуття посилилось.

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

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

«Важкі документовані процеси для автомотів на базі V-model» — то мабуть ви маєте на увазі A-SPICE?

це не моє

По подходу к разработке и тестированию:
V-модель, здесь описанная, приводит к куче бумаги (как и старый водопад), и она не гибкая — если под конец обнаруживается, что требования недостаточно продуманы, и продукт неудобен в использовании — поздно пить боржоми. Также, совсем непонятно, как развивать продукт (если это не разовый проект сдал-забыл).

Предлагаю опробованный вариант. Я с ним познакомился в Материалайзе лет 15 назад — там делали фотошопо-образные приложения без покрытия автотестами. И они работали. При очень маленьком QA отделе. В эмбедеде тоже работает, так как здесь тоже макро-релизы, а не CI/CD.

Есть общее видение развития продукта.
1) Продакт (овнер) выдает направление развития и основные фичи для следующего релиза.
2) Программисты начинают их имплементить.
3) Как только одна из фич сколько-нибудь готова (даже на уровне PoC), собирается версия и выдается продакту для проверки удобства использования и правильности выполнения, а также — QA, чтобы найти основные проблемы в новой фиче и поломки, которые она вызвала в старых.
4) В результате продакт и QA заводят баги и таски, они идут девелоперам, те их решают и собирают следующую версию для тестирования.
5) Любой отресолвленный баг или таск падает на QA для проверки. Проверяется не только то, что описано в задаче, но и соседняя функциональность, и то, что программисты попросили (где был риск сломать код). При обнаружении проблем — задачи переоткрываются, или заводятся новые баги.
6) Когда фича готова, после проверки продактом она отдается QA на глубокое тестирование. В результате находится больше багов.
7) Когда все фичи, идущие во внешний макро-релиз, готовы — начинается полное тестирование продукта. Программисты в это время чинят найденные баги, а если остается время — работают над следующим макро-релизом (на другом бранче). Каждый день-два выпускаются версии для внутреннего тестирования.
8) По окончанию цикла полного тестирования и закрытия серьезных багов делается релиз кандидат для смок теста. Найденные смок тестом баги фиксятся, кандидат пересобирается.
9) Когда в кандидате не найдено важных багов — отводится релизный бранч, делается внешний релиз, и начинается тестирование следующего макро-релиза (над которым часть программистов уже успела поработать, пока шел багфикс текущего релиза).

Из вашего описания можно добавить больше рисков :). Я даже знаю менеджеров, для которых в таком описании «все понятно» :

глубокое тестирование
больше багов
полное тестирование
выдает направлени
идут девелоперам
важных багов
макро-релиза (над которым часть программистов уже успела поработать, пока шел багфикс текущего релиза).

По статье:
1) Что имеется в виду под Middleware? Этот термин обычно используется для абстракции транспорта в распределенных системах.
2) Среди компонентов не упомянули флеш. В реальности как раз флеш обычно лимитирует возможности встроенных устройств по функциональности, может быстро запортиться или не дать возможности обновить прошивку, если установлено слишком много компонентов.
3) Судя по рискам, у вас есть очень много ресурсов на документацию и тестирование. Что-то посоветуете, когда людей и времени в разы меньше?

1) не только. Есть прослойка через которую происходит обмен данными. На устройстве может быть база банных небольшая, различные структуры данных со своим API. Тот же вэб. Подразумевается еще одна прослойка между пользователем и драйверами
2) Да, флэш перетирается, затирается и выходит из строя. Про нее правда стоит написать. Спасибо большое. Это ценное замечание и я про нее забыла
3) Статья нацелена как раз на проекты, когда с документацией плохо. Я просто посмотрела на систему со всех сторон, чтобы при отсутствии документации не забыть о важных аспектах. На проектах, где с документацией очень хорошо, все это учтено. Например, если говорить про A-SPICE, то там риски максимально покрываются формальными процессами

Підписатись на коментарі