Я бы подошел к этому с помощью внешнего скрипта бегуна, использующего два потока.Пример алгоритма без реализации:
Запустить счетчик времени (только текущее время эпохи);Первый (основной) поток является управляющим.Он спит в течение 1 с, а при проверках выполнения и ответвлениях:
счетчик не достиг порогового значения (например, текущая эпоха - начало <предел) - проверка, работает ли другой поток (не имеетзаконченное выполнение): <br>- да: pass
- нет: этот «другой» поток - это выполнение наборов роботов.Он не запущен - создайте поток, который будет запускать пакеты;перед этим - скопируйте журналы из предыдущего выполнения - если вы заботитесь о них (в общем, я полагаю, вы бы проанализировали результат прогона; кроме случаев, когда вы выполняете тест на долговечность и хотите контролировать только SUT).Таким образом, вы перезапустите наборы после того, как они закончатся.
Счетчик превысил порог - остановите запуск в другом потоке.Для этого сигнал INT или TERM - это позволит каркасу создавать файлы журнала.Если вы используете KILL, это внезапно завершит текущее выполнение - если вам не нужны журналы, это вариант.Но вы рискуете оставить свое SUT в загрязненном состоянии - запущенный случай, возможно, изменил свою конфигурацию, и у него не будет возможности очиститься после него.
Я бы посоветовал начатьвыполнение, чтобы указать , а не создать журнал и сообщить html-файлы из промежуточных прогонов (опции --log none --report none
CLI) - их генерация займет время выполнения, в течение которого ваши дела не будут "вращаться".После выполнения вы можете сгенерировать их из промежуточных файлов output.xml, которые вы скопировали ранее.
Если вы заинтересованы в этом подходе и хотите использовать python для управляющего скрипта / системы, я 'Я бы посоветовал взглянуть на источник pabot
- это то, что (управление потоком и запускается, но без привязки ко времени, ваш запрос) на стероидах.