Сообщений в теме: 17

[sdcalifornia]

Всем привет.

 

 

Вот что имеем:

 

5 видов серверов (это же видео плеер для проигрывания видео на ТВ), для которых существует единое ПО.

 

Задача после каждого нового билда загружать софт на каждый сервер и после этого запускать тестирование уже на реальном железе.

 

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

 

Ну и потом хорошо бы получать результаты в удобном виде.

 

 

 

Сейчас существует такая идея. Берем каждый вид сервера-плеера (железа) и все устанавливаем в одном месте. Подключаем к единому ПК. Для серверов устанавливаем настройку загружать новый софт по мере его поступления. Создаем скрипт, который переодически проверяет изменилась ли версия софта. Если да, то запускаем тесты. После этого Запускается скрипт, который меняет конфигурацию и опять запускает тест ыи тд. Результаты куда-то складываем и, возможно, подключаем что-то типа Splunk для сигнализации результатов (к примеру, критических ошибках).

 

По тестам пока есть тестирование API и возможно каких-то юайных добавим. Основной язык софта NodeJS.

 

 

Буду очень признателен за совет как все же сделать это максимально граммотно.

[Spock]

а без железа нельзя обойтись?

[sdcalifornia]

Хотим максимально приближенно к реальной ситуации, чтобы учесть особенности железа тоже.

А как вы бы сделали?

[Spock]

 

Хотим максимально приближенно к реальной ситуации, чтобы учесть особенности железа тоже.

А как вы бы сделали?

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

 

ну а может это все не надо если у вас и так все в порядке, в вашем описании у вас как бы и проблем нет

[sdcalifornia]

Железо у нас сделано под нас же (Linux OS).

Проблема есть. Хотим автоматизировать часть тестов, но пока нет полного понимания какие инструменты использовать и как все построить.

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

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

[Spock]

 

 

Важней будет то, что все на реальном железе гоняется.

ну а насколько важно что именно каждый билд именно на всех железках гонялся?

 

а вообще можно чтобы ЦИ сервер типа Дженкинса раскручивал Докер контейнеры с серверами с разными настройками, и параллельно на них пускал тесты

[sdcalifornia]

 

 

ну а насколько важно что именно каждый билд именно на всех железках гонялся?

 

Видимо важно, т.к. менеджер попросил именно так.

[Spock]

с юнит-тестами уже все в порядке?

[sdcalifornia]

с юнит-тестами уже все в порядке?

 

Я не занимаюсь юнит тестами. Не думаю, что там все в порядке))

Роман, возможно с вами можно было бы как-то поговорить, к примеру, в скайпе или другом мессенджере?

[BadMF]

а какую проблему решить хотите? у вас при тестировании на виртуальном окружении пропускаются ошибки конкретного железа?

[Little_CJIOH]

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

[Spock]

 

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

конечно тестировать надо на железе. Вопрос в том, только ли на железе надо ранить тесты?

 

конечно хорошо когда энвайронмент ближе всего к продукции - но такой будет всегда дорогой и хрупкий, и с кучей своих проблем

[Little_CJIOH]

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

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

Именно так. Расписание использования железок. Ночные смены.
Можно всего этого избежать. Но взамен обнаружить что этот проект на этом железе запустить невозможно в принципе. В тот момент, когда уже N тысяч этих железок лежат у вас на складе. Не всегда все так драматично. Но это всегда потери.
Да, тесты на виртуальных девайсах возможны, но отношение к ним как к юнит-тестам - зеленые юнит-тесты работоспособность чего-либо не гарантируют.
Опять-же под ембеддед городить виртуальный девайс придется, скорее всего, самому.

[Spock]

по аналогии с например Андроид: основная масса тестов это юнит тесты, далее интеграционные тесты например на РЕСТ АПИ которых меньше, далее ещё меньше тестов которые ранятся на эмуляторах, и только потом уже установка на реальные девайсы

 

если тестировать только на девайсах, то далеко не уедешь

[Little_CJIOH]

Андроид + rest api - плохая аналогия. rest api живет в типовой, повторяемой среде исполнения. И тесты выполняются в той-же среде что и код в проде. Андроид разнообразен, но пока вы держитесь верхнеуровневых API все достаточно ровно и предсказуемо. Опять-же, есть виртуальные машины отрабатывающие все типовые ньюансы. Баги все равно просачиваются, но они задевают доли процента аудитории.
В ембеддед обычно работаете с некоей платформой, которая декларирует наличие некоей функциональности.
Возможно с этой платформой работают еще N компаний, которые в половине случаев ваши прямые конкуренты и не горят желанием делится кодом и опытом, как и компания разработчик платформы не горит желанием делиться контактами заказчиков.
К моменту окончания вашей разработки с вероятностью далекой от нуля платформа будет снята с поддержки как устаревшая и на любое предложение пофиксить "внезапный" креш будет предложено перейти на новую платформу или купить поддержку старой.

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

[Spock]

 

 

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

ну а когда например разработчик запушил код, и надо бы запустить тесты и достаточно быстро дать фидбек обратно, надо ли что-то чинить

ведь часто баг может быть очень простым, и достаточно виртуального окружения чтобы его найти

 

а если тесты на железе, то это вряд ли получится - ранится тесты будут долго, где-то что-то может сломаться, плюс availability у такого окружения достаточно низкий - даже не всегда работать будет

[Little_CJIOH]

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

ну а когда например разработчик запушил код, и надо бы запустить тесты и достаточно быстро дать фидбек обратно, надо ли что-то чинить
ведь часто баг может быть очень простым, и достаточно виртуального окружения чтобы его найти

Не были вы в эмбеддед разработке. Ни один разработчик не сядет писать код, пока у него на столе не стоит железка со всем необходимым добром, и эта железка - первое место, куда будет попадать его код и первый фидбек он будет получать с нее сам, не важно, вручную или скриптами. А виртуальное окружение, во первых собрать надо, а во вторых, тест прошедший в виртуальном окружении нужно повторять на реальном. Это, конечно, можно отдать на откуп тестировщикам, но А) долгий цикл обратной связи, Б) А есть ли у нас вообще тестировщики способные развернуть и обслуживать тестовую лабу?

а если тесты на железе, то это вряд ли получится - ранится тесты будут долго, где-то что-то может сломаться, плюс availability у такого окружения достаточно низкий - даже не всегда работать будет

А почему на железке тесты будут идти дольше, чем, например, в докере?
"где-то что-то может сломаться" - весомый аргумент, а главное универсальный. Давайте не будем делать кроссбраузерное тестирование, а то "где-то верстка может поехать". И нагрузку, а то "отвалится что-то, когда до таймаутов дойдет".
Работоспособность железного окружения зависит от культуры работы. Тема хорошо освещена в докладах про тестирование на реальных мобилках.

[chicago]

Сейчас существует такая идея. Берем каждый вид сервера-плеера (железа) и все устанавливаем в одном месте. Подключаем к единому ПК. Для серверов устанавливаем настройку загружать новый софт по мере его поступления. Создаем скрипт, который переодически проверяет изменилась ли версия софта. Если да, то запускаем тесты. После этого Запускается скрипт, который меняет конфигурацию и опять запускает тест ыи тд. Результаты куда-то складываем и, возможно, подключаем что-то типа Splunk для сигнализации результатов (к примеру, критических ошибках).

 

По тестам пока есть тестирование API и возможно каких-то юайных добавим. Основной язык софта NodeJS.

 

Буду очень признателен за совет как все же сделать это максимально граммотно.

 

 

Создаем тестовый управляющий сервер (то, что ты назвал "единый ПК"). Можно сделать его физикой, можно виртуалкой, зависит от требований. На нем ставится Дженкинс. На дженкинсе создается джоба, что мониторит выход нового билда. Эта джоба потом запускает другую джобу, которая загружает новый билд на тестовую железку и конфигурирует её (по ssh). После этого эта же джоба либо сама, либо вызывает другую, что запускает тест, контролирует исполнение и забирает результаты. Ну и, соответственно, всё это параллельно запускается на 5ти тестовых серверах. Дженкинс используем в качестве шедулера, который через свои джобы запускает скрипты, что лежат локально на той же машине.