Как тестировать встроенные системы?

Question

[andrey_pavlovich]

Привет ребята,

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

Проблема заключается в том что по отдельности все настройки работают, а вот когда начинаются какие-то непредсказуемые настройки, появляются ошибки, скажите как это все выявить? Это все должно было заложиться на уровне проэктирования? Как организовать тестирование такого монстра, вручную перебирать все возможные варианты или программно в коде запрещать все ?? Или сделать список обязательных тестов перед каждым релизом? А то после каждого релиза firmware появляются баги там где их раньше не было.

С уважением, Андрей

Answer 1

[rustler2000]

• Написать (минимальный) симулятор, чтобы компилировать для хоста
  
• (Опционально) прикрутить статический анализатор
  
• Использовать assert везде где только можно
  
• Писать тесты и гонять их на хосте под valgrind
  
• Если чтото симулировать сложно, делать стенд для железки и писать под стенд тесты (матричное тестирование много чем поддерживается, да и если что сгенерировать не сложно)
  
• Поднимать CI и автоматом пускть тесты на билдхосте и стенде
  
• Поднимать sonarqube и фиксить _все_ замечания
  
• (Опционально)Найти управляемый heat chamber и конять тесты в нем
  

Answer 2

[Alexej Simakov]

Как я упомянал в другом ответе https://toster.ru/answer?answer_id=1040391
у нас в системе есть конфигурационные файлы, с флагами, эти флаги определяют при запуске системы какие части системы запускаются а какие нет. Т.е ПО в принципе поддерживает максимальную конфигурацию но путем флагов ее можно вариировать. Значение этих флагов можно опрашивать. Если знать как должна быть настроена система в идеале, то можно написать тесты проверяющие значение этих флагов.
В принципе при тестировании настроек мы берем эталонные зачения и сравниваем с действительными, все довольно просто, но нужно написать файл с эталонными значениями. Это может быть дофига работы на несколько недель, но это окупится сторицей.
И конечно тесты эти гонять перед релизом, т.е после сборки. Не до сборки, а после. Так вы сможете выявить проблемы в всей цепочке,чтобы не было такого что у разработчика на машине тесты зеленые, а сборка (внезапно) корявая.

Answer 3

[Николай]

При большом количестве входных параметров можно попробовать использовать Pairwise технику для тест-дизайна. Позволяет существенно снизить количество кейсов и в последствии их автоматизировать.

Создавать кейсы вручную этой техникой долго и относительно сложно. Есть специализированные тулзы для этого.