Как выстроить процесс автоматизации в следующей ситуации?
#1
Отправлено 12 октября 2018 - 02:33
#2
Отправлено 12 октября 2018 - 06:29
а без железа нельзя обойтись?
#3
Отправлено 12 октября 2018 - 15:21
Хотим максимально приближенно к реальной ситуации, чтобы учесть особенности железа тоже.
А как вы бы сделали?
#4
Отправлено 12 октября 2018 - 16:36
Хотим максимально приближенно к реальной ситуации, чтобы учесть особенности железа тоже.
А как вы бы сделали?
железо для всех билдов это будет медленно. Вот например если вы пишете приложение для Андроида. конечно можно тестировать "только на железе" чтобы "максимально приблизить к реальной ситуации", но намного быстрее можно будет тестировать все билды на Андроид студио и эмуляторах, и только некоторые билды можно деплоить на реальное железо
ну а может это все не надо если у вас и так все в порядке, в вашем описании у вас как бы и проблем нет
#5
Отправлено 12 октября 2018 - 17:53
Железо у нас сделано под нас же (Linux OS).
Проблема есть. Хотим автоматизировать часть тестов, но пока нет полного понимания какие инструменты использовать и как все построить.
Так как опыта у меня мало в автоматизации, боюсь начать строить что-то свое и не эффективное.
Вы говорите, что будет медленно. Думаю, ото сейчас можем принять. Важней будет то, что все на реальном железе гоняется.
#6
Отправлено 12 октября 2018 - 18:31
Важней будет то, что все на реальном железе гоняется.
ну а насколько важно что именно каждый билд именно на всех железках гонялся?
а вообще можно чтобы ЦИ сервер типа Дженкинса раскручивал Докер контейнеры с серверами с разными настройками, и параллельно на них пускал тесты
#7
Отправлено 12 октября 2018 - 19:24
ну а насколько важно что именно каждый билд именно на всех железках гонялся?
Видимо важно, т.к. менеджер попросил именно так.
#8
Отправлено 12 октября 2018 - 20:03
с юнит-тестами уже все в порядке?
#9
Отправлено 12 октября 2018 - 20:29
с юнит-тестами уже все в порядке?
Я не занимаюсь юнит тестами. Не думаю, что там все в порядке))
Роман, возможно с вами можно было бы как-то поговорить, к примеру, в скайпе или другом мессенджере?
#10
Отправлено 15 октября 2018 - 11:49
а какую проблему решить хотите? у вас при тестировании на виртуальном окружении пропускаются ошибки конкретного железа?
#11
Отправлено 16 октября 2018 - 10:53
#12
Отправлено 16 октября 2018 - 11:21
Ребята, это явно embedded. Его тестировать не на железе - это как тестировать на убунте с продом на центосе. Там другая архитектура, специфические версии библиотек со своими специфическими багами, баги в железе, ядре, драйверах. Цум байшпиль, при дисковых операциях отстают часы. Реальный баг, который я отловил в процессорном модуле.
конечно тестировать надо на железе. Вопрос в том, только ли на железе надо ранить тесты?
конечно хорошо когда энвайронмент ближе всего к продукции - но такой будет всегда дорогой и хрупкий, и с кучей своих проблем
#13
Отправлено 16 октября 2018 - 13:56
Именно так. Расписание использования железок. Ночные смены.конечно тестировать надо на железе. Вопрос в том, только ли на железе надо ранить тесты?Ребята, это явно embedded. Его тестировать не на железе - это как тестировать на убунте с продом на центосе. Там другая архитектура, специфические версии библиотек со своими специфическими багами, баги в железе, ядре, драйверах. Цум байшпиль, при дисковых операциях отстают часы. Реальный баг, который я отловил в процессорном модуле.
конечно хорошо когда энвайронмент ближе всего к продукции - но такой будет всегда дорогой и хрупкий, и с кучей своих проблем
Можно всего этого избежать. Но взамен обнаружить что этот проект на этом железе запустить невозможно в принципе. В тот момент, когда уже N тысяч этих железок лежат у вас на складе. Не всегда все так драматично. Но это всегда потери.
Да, тесты на виртуальных девайсах возможны, но отношение к ним как к юнит-тестам - зеленые юнит-тесты работоспособность чего-либо не гарантируют.
Опять-же под ембеддед городить виртуальный девайс придется, скорее всего, самому.
#14
Отправлено 16 октября 2018 - 14:57
по аналогии с например Андроид: основная масса тестов это юнит тесты, далее интеграционные тесты например на РЕСТ АПИ которых меньше, далее ещё меньше тестов которые ранятся на эмуляторах, и только потом уже установка на реальные девайсы
если тестировать только на девайсах, то далеко не уедешь
#15
Отправлено 17 октября 2018 - 13:54
В ембеддед обычно работаете с некоей платформой, которая декларирует наличие некоей функциональности.
Возможно с этой платформой работают еще N компаний, которые в половине случаев ваши прямые конкуренты и не горят желанием делится кодом и опытом, как и компания разработчик платформы не горит желанием делиться контактами заказчиков.
К моменту окончания вашей разработки с вероятностью далекой от нуля платформа будет снята с поддержки как устаревшая и на любое предложение пофиксить "внезапный" креш будет предложено перейти на новую платформу или купить поддержку старой.
Да, можно собрать специфичные виртуалки и тестировать на них. Это вам даст косяки специфических библиотек. Но не покажет вам проблем с железом, с производительностью, с драйверами, с совместным использованием ресурсов. А они как раз самые дорогие, их бы найти на стадии прототипа.
#16
Отправлено 17 октября 2018 - 15:20
Да, можно собрать специфичные виртуалки и тестировать на них. Это вам даст косяки специфических библиотек. Но не покажет вам проблем с железом, с производительностью, с драйверами, с совместным использованием ресурсов. А они как раз самые дорогие, их бы найти на стадии прототипа.
ну а когда например разработчик запушил код, и надо бы запустить тесты и достаточно быстро дать фидбек обратно, надо ли что-то чинить
ведь часто баг может быть очень простым, и достаточно виртуального окружения чтобы его найти
а если тесты на железе, то это вряд ли получится - ранится тесты будут долго, где-то что-то может сломаться, плюс availability у такого окружения достаточно низкий - даже не всегда работать будет
#17
Отправлено 17 октября 2018 - 19:14
Не были вы в эмбеддед разработке. Ни один разработчик не сядет писать код, пока у него на столе не стоит железка со всем необходимым добром, и эта железка - первое место, куда будет попадать его код и первый фидбек он будет получать с нее сам, не важно, вручную или скриптами. А виртуальное окружение, во первых собрать надо, а во вторых, тест прошедший в виртуальном окружении нужно повторять на реальном. Это, конечно, можно отдать на откуп тестировщикам, но А) долгий цикл обратной связи, Б) А есть ли у нас вообще тестировщики способные развернуть и обслуживать тестовую лабу?ну а когда например разработчик запушил код, и надо бы запустить тесты и достаточно быстро дать фидбек обратно, надо ли что-то чинитьДа, можно собрать специфичные виртуалки и тестировать на них. Это вам даст косяки специфических библиотек. Но не покажет вам проблем с железом, с производительностью, с драйверами, с совместным использованием ресурсов. А они как раз самые дорогие, их бы найти на стадии прототипа.
ведь часто баг может быть очень простым, и достаточно виртуального окружения чтобы его найти
А почему на железке тесты будут идти дольше, чем, например, в докере?а если тесты на железе, то это вряд ли получится - ранится тесты будут долго, где-то что-то может сломаться, плюс availability у такого окружения достаточно низкий - даже не всегда работать будет
"где-то что-то может сломаться" - весомый аргумент, а главное универсальный. Давайте не будем делать кроссбраузерное тестирование, а то "где-то верстка может поехать". И нагрузку, а то "отвалится что-то, когда до таймаутов дойдет".
Работоспособность железного окружения зависит от культуры работы. Тема хорошо освещена в докладах про тестирование на реальных мобилках.
#18
Отправлено 18 октября 2018 - 15:07
Сейчас существует такая идея. Берем каждый вид сервера-плеера (железа) и все устанавливаем в одном месте. Подключаем к единому ПК. Для серверов устанавливаем настройку загружать новый софт по мере его поступления. Создаем скрипт, который переодически проверяет изменилась ли версия софта. Если да, то запускаем тесты. После этого Запускается скрипт, который меняет конфигурацию и опять запускает тест ыи тд. Результаты куда-то складываем и, возможно, подключаем что-то типа Splunk для сигнализации результатов (к примеру, критических ошибках).По тестам пока есть тестирование API и возможно каких-то юайных добавим. Основной язык софта NodeJS.Буду очень признателен за совет как все же сделать это максимально граммотно.
Создаем тестовый управляющий сервер (то, что ты назвал "единый ПК"). Можно сделать его физикой, можно виртуалкой, зависит от требований. На нем ставится Дженкинс. На дженкинсе создается джоба, что мониторит выход нового билда. Эта джоба потом запускает другую джобу, которая загружает новый билд на тестовую железку и конфигурирует её (по ssh). После этого эта же джоба либо сама, либо вызывает другую, что запускает тест, контролирует исполнение и забирает результаты. Ну и, соответственно, всё это параллельно запускается на 5ти тестовых серверах. Дженкинс используем в качестве шедулера, который через свои джобы запускает скрипты, что лежат локально на той же машине.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных