DOU Labs: як у Wire витворили власну лабораторію з автоматизованого тестування мобільних платформ

У рубриці DOU Labs ми запрошуємо IT-компанії ділитись досвідом власних цікавих розробок та внутрішніх технологічних ініціатив. Питання і заявки на участь надсилайте на [email protected] .

Доброго дня усім читачам DOU. Сьогодні хотілось би розповісти про структуру нашої тестової лабораторії для автоматизованого тестування Wire на мобільних платформах iOS та Android. Думаю, наш досвід буде корисним стартапам або командам, які хотіли б організувати стабільну роботу автоматизованого тестування свого мобільного продукту в локальному оточненні, не витрачаючи на це захмарні кошти.

До плюсів такого підходу можна віднести:

менша вартість рішення у довготривалій переспективі;
повний контроль над оточенням;
відсутність необхідності ділитися збірками аплікації та автоматизованого фреймворку з третіми сторонами.

Мінуси, відповідно:

необхідність наявності персоналу достатньої кваліфікації для обслуговування інфраструктури;
необхідність проведення регулярного обслуговування.

Мережева архітектура

На даний час лабораторія містить біля двох десятків фізичних машин, кілька десятків віртуальних машин та кільканадцять мобільних пристроїв. Усі клієнти об єднані в окрему мережу класу C, яку контролює роутер Microtik. Наш вибір впав на продукт даної компанії, тому що в даному контексті це було оптимальне відношення ціна/можливості індивідуального налаштування.

Логічна структура мережі виглядає наступним чином:

IP-адреси в діапазоні 192.168.2.1-10 зарезервовані для мережевого обладнання. Діапазон 192.168.2.11-200 зарезервований для статичних IP-адресу, які отримують фізичні та віртуальні клієнти. Все що більше 200 — діапазон динамічних адресу, що автоматично присвоюються мобільним пристроям, які тестуються в лабораторії (роутер також має окрему точку доступу Wi-Fi).

Всі фізичні машини в мережі пронумеровані по порядку і кожна така машина отримує статичну IP-адресою, останній розряд якої завжди кратний 5. Віртуальні машини, розміщені на даній фізичній машині, мають статичні адреси в діапазоні [192.168.2.x+1, 192.168.2.x+4], де x — адреси їхнього фізичного хоста. Тобто, один хост може вміщати не більше чотирьох віртуалок з «реальними» адресами. Дана закономірність також відображається в іменах хостів. Так, якщо фізична машина називається node1, то її віртуалки отримають імена node11, node12, ... Така структура дозволяє спростити задачу по отриманню IP-адресу машин для автоматизовуваних скріптів, що виконуються в мережі. Також сам роутер надає можливість для клієнтів отримувати інформацію про конфігурацію мережі та про клієнтів (IP/MAC-адреси, імена хостів) через власний API.

Hardware-компоненти

Лабораторія включає у собі як Mac, так і PC-сервери. В якості перших були вибрані Mac Mini, а другі — портативні юніти на платформі Intel NUC. Для всіх машин була вибрана конфігурація з 16 і більше GB оперативної пам'яті та процесором Intel Core i5 або i7. Також рекомендується використовувати SSD або хоча б Fusion Drive у випадку з Mac Mini. Інакше будуть сильно відчутні «просідання» в продуктивності віртуалок, особливо якщо їх більше однієї. Дуже важливо наперед продумати правильне підключення машин до електромережі та розрахувати навантаження. Одночасне включення усіх серверів після збою живлення або їхня одночасна робота з повним завантаженням запросто може «відрубати» автомат на електрощитку.

Wire має окремі native-аплікації для Android та iOS. Для автоматизованого тестування на платформі Android ми використовуємо реальні пристрої з множини популярних серед користувачів. Для автоматизовуваних iOS-тестів використовується симулятор, і тільки невелика їх множина виконується на реальних пристроях в силу обмежень властивих для симулятора (наприклад, відсутність камери, фреймворку CallKit і т. д.). Усі мобільні пристрої постійно підключені через USB-конектори до фізичних серверів. Кожен сервер у свою чергу містить статичну таблицю, де вказується, якій віртуальній машині належить тій чі інший підключений пристрій. Тобто кожен віртуальний хост «бачить» не більше одного фізичного пристрою.

Переваги віртуалізації

Образи віртуальних машин абсолютно однакові для кожної окремої платформи, за виключенням мережевих налаштувань та списку довірених пристроїв. Це дозволяє зекономити час на бекапах, оскільки образів для кожної платформи є кілька і всі вони фізично «розкидані» по різних машинах. Тому після «падіння» фізичної машини або пошкодження самого образу можна легко відновити всі з іншого сервера пробачимо копіюванням. Також така стратегія дозволяє розпаралелювати автоматизовані тести за принципом MapReduce, полегшує масштабування, покращує стійкість до випадкових збоїв та спрощує архітектуру фреймворку для автоматизації, оскільки не потрібно задумуватись над паралельним доступом до спільних ресурсів у межах конкретного тесту.

Проблеми та рішення

У процесі роботи лабораторії ми стикнулися з кількома проблемами. Так, основною був перегрів мобільних пристроїв, постійно підключених до джерела живлення. Тепер ми знаємо, чому виробники мобільних телефонів не рекомендують на тривалий час залишати їх у режимі заряджування підключеними до електромережі. У деяких лабораторних пристроях через два-три місяці роботи акумуляторні батареї буквально роздувались до такого розміру, що видавлювали тач-скрін і задню кришку (які були, до речі, приклеєні). Першим рішенням було перемістити все обладнання в серверну кімнату з середньою температурою 19? . А для особливо «гарячих кандидатів» був придбаний просунутий USB хаб Acroname з можливістю програмного управління подачою живлення на кожен з підключених пристроїв через власний API. Далі був написаний скріпт, що автоматично переключає стан лінії живлення на підключених пристроях кожні дві години, що дозволяє уникнути небажаного перегріву. До речі, цікавий факт — хаб має можливість відключити тільки лінію живлення, залишаючи лінію даних включеною, але це все одно призведе до зникнення відповідного пристрою зі списку видимих для ОС.

Друга проблема спостерігалася на підключених пристроях та віртуалізованих ОС внаслідок тривалої роботи в режимі високого навантаження. Особливо діставали проблеми викликані «втіканням» пам'яті та ресурсів (memory and resources leaks). Це призводило до несподіваних «зависань» без видимих на ті причин або неочікуваних помилок в роботі тестів. Допомогло примусове перезавантаження усіх підключених пристроїв та віртуальних машин за розкладом.

Третя проблема — робочі станції з Mac OS автоматично відключають прискорення графіки, якщо до машини не підключено жодного фізичного дисплею. Це створює великі незручності при роботі з віддаленим екраном протокол VNC, а також унеможливлює нормальне функціонування аплікацій, що вимагають OpenGL (в тому числі iOS Simulator). Звичайно, можна було взяти монітор, підключити до нього купу кабелів і створити строкате накопичення, в якому сам дідько ... ногу зламає. А можна придбати заглушку для виходу HDMI або displayport, наприклад, fit-Headless від компанії Compulab, що і було зроблено.

Висновки

Наша тестова лабораторія за два роки свого існування (а починалося все всього з двох Mac Mini) показала хороші можливості по масштабуванню та забезпенню стабільної роботи в цілодобовому режимі. Ми вважаємо, що вона чесно відпрацювала і продовжує відпрацьовувати кожен євроцент вкладений в обладнання для неї (в основному, це вартість самих серверів та ліцензій для програм). Очевидно, що для дуже масштабних проектів з десятками і сотнями пристроїв для проведення автотестів, таке рішення не буде оптимальним, тому ми ще на початку статті окреслили цільову аудиторію. Але якщо хочеться, щоб було дешево і сердито, є бажання та люди, які крім автоматизованого тестування ще й знайомі з послідовністю кольорів у витій парі для обтиснення патч-корду, то чому б і не спробувати?

Опубліковано: 20/07/17 @ 10:24
Розділ Різне

SEO Блог