Використання продуктів Acronis в автоматизації тестування

    Всім привіт! У цій статті я розповім вам про те, як можна використовувати наші продукти для підготовки оточення для тестування ваших програм. У більшості сценаріїв тестування ПО для досягнення повторюваності результатів необхідно, щоб оточення, на якому воно проводиться, було ідентичним. Підготовку цього оточення перед тестом будемо називати деплойментом ("deployment").
 
 
Весь комплекс автоматизованого тестування виглядає наступним чином: стартовою точкою є сервер з встановленим на ньому «Jenkins »; через нього ми задаємо параметри автоматичного прогону тесту:
 
 - На якому сервері чи машині ми будемо запускати наш тест;
 - Як конфігурувати на ньому рейд контролер; як, в якій послідовності і з якими параметрами розбити диски;
 - Яку операційну систему поставити
 - Які продукти необхідно встановити на цей сервер для прогону тестового сценарію.
 
Дженкінс через SSH підключається до іншого сервера, на якому лежать всі необхідні скрипти для деплоймента, і виконує ці скрипти з переданими в нього параметрами. Сервер, який безпосередньо виконує всі дії, готує конфігурацію для завантаження вибраного комп'ютера через PXE .
 
В якості того, що буде вантажити PXE, ми вибрали нашу Acronis Bootable Media, т. к. з її допомогою можна виконати все, що нам потрібно. Acronis Bootable Media — це урізана версія Linux'a (BusyBox) з виконуваними файлами нашого продукту, упакована в ramdisk . Рамдіск нашої медії можна отримати, встановивши з дистрибутива Acronis Backup компонент Agent For Windows. Рамдіск буде знаходитися в папці з встановленим продуктом:
 
 
C:\Program Files (x86)\Common Files\Acronis\BackupAndRecoveryAgent\

 
і називатиметься
agent_ramdisk.dat
для 32х бітної медії і
agent_ramdisk64.dat
— для 64х бітної.
 
 image
 Зовнішній вигляд завантаженої з рамдіска медії
  
У завантаженої медії ми виконаємо всі скрипти з підготовки рейд-контролера, і через неї відновимо образ тієї чи іншої операційної системи — поверх щойно налаштованого заліза. Перший крок — настройка рейд-контролера. Для конфігурації дисків ми використовуємо утиліту storcli , яку попередньо запаковуємо в ramdisk.
 
Ось приклад shell'овского скрипта, який запаковує потрібні нам файли в ramdisk:
 
 
# Распаковка ramdisk.
extract_ramdisk() {
            rm -rf .ramdisk
            mkdir .ramdisk
            pushd .ramdisk
            gzip -dc < $1 | cpio -i -d --no-absolute-filenames
            popd
}
# Подкладывание нужных файлов в Acronis Media. 
copy_extra_files() {
            mkdir -p .ramdisk/tmp/root/.ssh
            cp -f files/id_rsa .ramdisk/tmp/root/.ssh
            cp -f files/autostart.sh .ramdisk/bin/autostart_dbg
            cp -f files/libstorelibir-2.so.14.07-0 .ramdisk/bin
            cp -f files/storcli64 .ramdisk/bin
}
# Запаковка ramdisk’a.
pack_ramdisk() {
            mkdir -p out
            pushd .ramdisk
            /cygdrive/c/cygwin/bin/find . | cpio -H newc -o > ../out/agent_ramdisk_echo.dat.initrd
            popd
            gzip -c9 out/agent_ramdisk_echo.dat.initrd > out/ramdisk.dat
            rm -f out/agent_ramdisk_echo.dat.initrd
            rm -rf .ramdisk
}
# Вызов методов.
echo Extracting ramdisk...
extract_ramdisk $1
echo Copying extra files...
copy_extra_files
echo Packing ramdisk...
pack_ramdisk

Після того, як ми запакували утиліту в ramdisk, її можна використовувати в завантаженою Acronis медії. Для завантаження через кастомний ramdisk-під PXE, потрібно створити коректний конфігураційний файл для завантажування машини. В якості PXE-сервера ми використовуємо ту ж саму машину, якої Jenkins передає управління. На ній же у нас коштує DHCP сервер. Всі тестові машини тримаємо у своїй власній віртуальної мережі, щоб не заважати іншим працівникам компанії.
 
Процес деплоймента починається з підготовки конфігураційного файлу для PXE: який генерується по імені машини. Оскільки цей же сервер також виконує функцію DHCP, імені нам достатньо, щоб дізнатися її mac-адресу, створити правильний файл конфігурації і покласти його в / var / lib / tftpboot. Приклад файлу конфігурації завантаження наведено нижче. Після цього ми перезавантажуємо машину через IPMI (якщо у машини він є).
 
Після того як машина завантажиться з ramdisk, в медії почне виконуватися скрипт autostart.sh. Спочатку ми прописуємо в ньому, як через storcli конфігурувати диски, а потім задаємо параметри відновлення того чи іншого образу операційної системи на машину через наш продукт. Ці образи зроблені нашим же продуктом Acronis
 
Backup являють собою *. Tib файли і лежать на кулі в цій же мережі.
 
Ось приклад скрипта autostart.sh:
 
 
configureRaidDisk() {
    conf_id=$(cat /proc/cmdline | grep -o 'raid_configuration_number=[^ ]*' | sed 's/\(^raid_configuration_number=\)\(.*\)/\2/')
    echo Raid configuration: $conf_id
    # Default value not to reconfigure raid controller disk state.
    if [ "$conf_id" == "0" ]; then
        return
    elif [ "$conf_id" == "1" ]; then
        (/bin/storcli64 /c1/vall delete force && echo Delete all virtual drives.) || exit 1
        (/bin/storcli64 /c1 add vd type=raid0 drives=252:3 wt nora direct strip=64 && echo Create system partition.) || exit 1
        (/bin/storcli64 /c1 add vd type=raid0 drives=252:0,252:1,252:2 wt nora direct strip=64 && echo Create first virtual drive.)  || exit 1
        (/bin/storcli64 /c1 add vd type=raid0 drives=252:4,252:5,252:6 wt nora direct strip=64 && echo Create second virtual drive.)  || exit 1
        (/bin/storcli64 /c1 add vd type=raid0 drives=252:7 wt nora direct strip=64 && echo Create third virtual drive.)  || exit 1
        (/bin/storcli64 /c1/v0 set bootdrive=on && echo Set system disk as bootable.)  || exit 1
    fi
}

execCmd() {
        tmp=$(cat /proc/cmdline | grep -oe acrocmd.*\) )
        cmd=${tmp%%\)} 
        echo Recovering OS image...
        ($cmd >> /dev/null && echo Done.) || exit 1
}

configureRaidDisk
startProduct
execCmd
reboot now

Параметри для цього скрипта ми передаємо через / proc / cmdline, який беремо конфігураційного файлу з PXE. Ми переглядаємо, яку конфігурацію рейду нам взяти, і кличемо вже безпосередньо storcli з потрібними нам параметрами. Зараз у нас все налаштовано під певні залізяки, надалі є бажання зробити ці операції більш розумними.
 
Після конфігурації рейду ми запускаємо операцію відновлення операційної системи. Для цього знову вичленяємо з переданого нам в / proc / cmdline команду для відновлення і виконуємо її.
 
Ось приклад конфігураційного файлу, згенерованого для завантаження машини через PXE:
 
 
timeout=1
default=media

image=kernel64.dat
        label=media
        initrd=ramdisk64.dat
        append="ramdisk_size=100000 quiet vga=791 recover=(acrocmd recover disk --loc=smb://10.250.114.44/raid/images --credentials=image,qweqweqwe --arc=win7_64srv --disk=1 --target_disk=1) bootfile=root@10.250.114.101:/tmp/uefi/0AFA7218.conf#end raid_configuration_number=1"

З нього ми і задаємо, який архів відновлювати — якраз те, що в параметрі append потрапить потім у proc / cmdline всередині медії.
 
Рамдіск повинен лежати в / var / lib / tftpboot / на PXE-сервері. У нашому випадку він називається ramdisk64.dat. Після того, як наша медія відпрацювала, і система відновлена, ми можемо зіткнутися з проблемою: після налаштування рейду за допомогою storcli, томи на віртуальних дисках рейду не створюються. Тому в скрипті найвищого рівня, який готує конфігурацію для завантаження PXE, перезавантажує машину і чекає завантаження відновленої системи, ми додали виконання наступного скрипта:
 
 
echo list disk > list.txt
for /f "usebackq tokens=1,2" %%a in (`diskpart /s list.txt ^| findstr /r /c:"Disk [1-99]"`) do (
            echo sel %%a %%b>script.txt
            echo clean>>script.txt
            echo create part primary>>script.txt
            echo format FS=NTFS quick>>script.txt
            echo assign>>script.txt
            echo rescan>>script.txt
            diskpart /s script.txt
)
del list.txt, del script.txt

Він створює NTFS-томи на кожному знайденому диску (крім першого). Так як diskpart не може приймати на вхід параметри, а може тільки використовувати скрипт, ми генеруємо файл з командою для лістингу дисків на льоту і після форматуємо файлову систему, використовуючи диски з лістингу.
 
Після відновлення ОС можна приступати до установки продуктів. Запуск скриптів і інших дій на тестовій машині проводиться з керуючого сервера через SSH-з'єднання. Для цього на тестовій машині коштує SSH-сервер, який уже встановлений в образі, так що після відновлення машини, ми просто підключаємося до неї по SSH. Установку продукту реалізуємо копіюванням на машину потрібних нам msi-файлів нашого продукту, які просто ставимо через msiexec. Тепер можна приступати до самого тестування.
 
Тести представляють собою «обгортки» на Пітоні, що виконують ті чи інші операції через командний рядок утиліти Acrocmd. Acrocmd дозволяє нам виконувати всі ті ж операції, що і через GUI основного продукту.
 
Запуском цих файлів (реалізованих на Python'e) на тестованої машині займається спеціальна система, встановлена ​​на інший керуючий сервер. Керуючий сервер по SSH-з'єднанню заливає всі скрипти на машину і запускає їх, збирає їх висновок і об'єднує результати всіх тестів в один підсумковий звіт. Надалі по ньому можна побудувати гарний звіт про прогін тестового сценарію. Для цього ми використовуємо нескладний веб-сервер, написаний на Python'e, який перетворює результати в красиві html-сторінки.
 
 image
 
Ось приклад звіту, який ми виходить в кінцевому результаті. Порівняння швидкості бекапу в трьох різних версіях продукту. Вісь абсцис — це номер ітерації в прогоні, а вісь ординат — це швидкість бекапу.
  
Задачу автоматизації деплоймента, кожен вирішує по-своєму. Ми вибрали шлях із застосуванням власних же продуктів, так як за своїми можливостями вони повністю підходять до наших цілей.
 
А як ви автоматизуєте тестування і підготовку оточення для нього?
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.