Один день з життя тестувальника системи локального позиціонування

Всім привіт!
Мене звуть Денис Койвистойнен nimpos та я є тестувальником в компанії RTL-Service.
Це мій перший топік на Хабре і в ньому я хочу поділитися трудовими буднями відділу тестування і розповісти, як у нас побудований процес тестування обладнання та програмного забезпечення.


Поїхали

9:00
Початок нашого трудового дня. Насамперед дивимося які листи прийшли по електронній пошті і перелік поточних справ на сьогодні. Зазвичай список завдань у відділі тестування великий, у кожної із завдань різні пріоритети — в першу чергу звертаємо нашу увагу на завдання зі статусом «Терміново» і «Негайно», які ставлять розробники і менеджери проектів.

9:10
Відповідаємо на отримані електронні листи. Деякі клієнти нашої компанії працюють в інших часових поясах, і, чим раніше вони отримають відповіді на запитання по роботі нашого обладнання, тим краще буде всім. Приміром, є клієнти нашої компанії, з якими у нас різниця у часі п'ять-шість годин, внаслідок цього – коли у нас робочий день починається, у них він вже підходить до кінця. В результаті чого проблема може залишитися невирішеною до наступного робочого дня.

9:25
Переглядаємо і аналізуємо логи від пристроїв, залишених на ніч на тестування. Для цього використовуємо стандартні команди linux для фільтрації даних (grep, cat, tail, more) і написаними співробітниками нашого відділу скриптами на Python і Bash.

Рис.№ 1 — Аналіз отриманих логів

10:30
Приступаємо до виконання поставлених на сьогодні завдань: одне з пріоритетних завдань, що мають статус «Терміново» — протестувати нову версію прошивки для точки доступу (access point), в якій раніше було виправлено баг (довільна зміна режиму роботи пристрою зі шлюзу на ретранслятор). Завантажуємо нову версію прошивки в пристрій, перевіряємо, що вона коректно завантажилася. У терміналі налаштовуємо фільтрацію за заданим режимом роботи (використовуємо grep), вихідні дані результатів вказуємо файл для того, щоб в кінці експерименту можна було перевірити його на наявність помилок, якщо вони виникнуть у режимі. Для збору даних буде потрібно від декількох годин до декількох діб, так що можна перейти до наступної задачі.

11:30
Далі у нас на черзі по термінових завдань — перевірка голосової сесії через ланцюжки ретрансляторів. Як шлюзів і ретрансляторів будемо використовувати обладнання нашого виробництва — RealTracTM Access Point Indoor (точка доступу в офісному виконанні, в завдання якої входить формування зони радіопокриття і здійснення передачі даних від\до мобільних пристроїв з метою забезпечення локального позиціонування і передачі голосу (Рис.№ 2)).

Рис.№ 2 — RealTracTM Access Point Indoo

Для цього прошиваємо наш шлюз (шлюз-точка доступу, ШТД), через який будуть прийматися пакети з ретрансляторів (ретранслятор-точка доступу, РТД), всі наші ретранслятори і комунікатор (переносна радіопристрій з функцією голосового зв'язку, що забезпечує передачу даних від\до стаціонарних радиоустройствам в межах зон радіопокриття (Рис.№ 3) на прошивку однієї версії.

Рис.№ 3 — Комунікатор

Розставляємо нашу ланцюжок в послідовності ШТД — РТД — РТД — РТД (Рис.№ 4). Одне з важливих умов для коректної передачі даних – це те, що пристрій повинен бути в зоні прямої видимості наступного пристрою в ланцюжку.

Рис.№ 4 — Схема розташування обладнання

12:00
Всі пристрої, які будуть використовуватися в тестуванні, розставлені, можна приступати до нашого тесту (Рис.№5).

Рис.№ 5 — Схема розташування обладнання

І тут, на нашому шляху, виникла проблема – майданчик для проведення тесту – невелика, а стіни недостатньо щільні і не екранують сигнали. У результаті сигнал від ретрансляторів проходить крізь стіни. Це створює такий ефект, що кілька ретрансляторів будуть чути комунікатор, а це неприпустимо, так як ми перевіряємо коректність передачі сигналу по ланцюжку РТД. Для вирішення виниклої проблеми ми зменшуємо потужність ретрансляторів і комунікатора. Для зменшення потужності передачі сигналу пристроєм ми використовуємо розроблену нашою компанією утиліту setparam.

12:15
Потужності на пристроях зменшені. Тепер треба переконатися, що кілька РТД не будуть чути комунікатор. Для перевірки чутності точок доступу з конкретного місця скористаємося аналізатором (переносна пристрій, розроблене нашою компанією спеціально для виміру по радіоканалу різних параметрів пристроїв, у тому числі RSSI, відстані до всіх знаходяться в зоні чутності пристроїв та інше (Рис.№6)).

Рис.№ 6 — Аналізатор

Підходимо до кожного з ланок у ланцюжку і перевіряємо за допомогою Аналізатора, чути сусідні ретранслятори і не чути інші пристрої в ланцюжку.

12:30
Після деяких перестановок ретрансляторів по території вдалося добитися необхідного ефекту. Тепер справа за малим — один співробітник виконує роль диспетчера і дзвонить на комунікатор іншого, який стоїть у кінці ланцюжка. Якщо виклик на комунікатор пройшов, значить, ланцюжок з ретрансляторів працює справно. Тепер перевіряємо ланцюжок, викликаючи диспетчера з комунікатора. При виклику з комунікатора у диспетчера з'являється повідомлення про вхідний виклик.

Тепер спробуємо розірвати ланцюжок шляхом відключення одного з ретрансляторів в ланцюжку, щоб перевірити, що передача голосової сесії не піде далі по ланцюжку після відключеного ретранслятора.
Ретранслятор в центрі ланцюжка відключений, співробітник з комунікатора стоїть біля останнього ретранслятора в ланцюжку, диспетчер дзвонить на комутатор — і виклик не проходить до комунікатора. Пробуємо зробити виклик у зворотний бік — викликаємо з комутатора нашого диспетчера — у відповідь – тиша, це якраз те, що нам і потрібно.

Тест підійшов до кінця, залишилося перевірити логи сервера на наявність помилок. Для цього переходимо в наш каталог з балками і виконуємо команду для парсингу файлів на наявність рядків "ERROR", "WARNING", "EXCEPTION".

Виявлене повідомлення ERROR

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

13:03
Обідній час. На час обіду запустимо авто-тести веб-клієнта (про використання даного способу прискорення автоматизації тестування веб-інтерфейсу за рахунок застосування Python і Selenide є стаття в нашому хабі) (https://habrahabr.ru/company/rtl-service/blog/300860/), щоб система даремно не простоювала.

14:00
З усіх авто-тестів, запущених на обіді, з помилкою завершився лише один. Коли буде вільний час, треба буде подивитися, у чому проблема. Для цього збережемо лог виконання завдання в окремий файл для його подальшого вивчення.


Помилки при виконанні автотестів

Перевіряємо логи, відфільтровані по помилок в нашому експерименті з дзвінками на комунікатор. Критичних помилок не виявлено. Йдемо далі.

14:30
Надійшла завдання з пріоритетом «Негайно» на виконання, це означає, що всі завдання на поточний момент припиняються. Суть поставленого завдання в тому, що при обертанні підкладки нанесеної на карту у веб-клієнті, завантаження оперативної пам'яті і центрального процесора зростала до 80-90 % і не высвобождалась по закінченню обертання. Було озвучено припущення, що таке навантаження на систему викликає процес Java, вражається нашою системою. Для виконання мого завдання потрібно спробувати відтворити цю помилку.
Для цього були обрані підкладки декількох розмірів (1000 x 1000, 3508 x 2480). Розгортаємо нашу систему, встановлюємо нашу першу підкладку з обраних (1000 x 1000) і починаємо обертати, спостерігаючи, як зростає навантаження на центральний процесор і оперативну пам'ять в окремій консолі (використовуємо консольні команди top і htop). При підкладці такого розміру не вдалося навантажити систему до необхідних більше 80%. Тепер беремо основу більш великого розміру. Повторюємо наші минулі дії вже з новою підкладкою — обертаємо її, одночасно спостерігаємо параметри завантаження в консолі — тут результат вже є, при обертанні підкладки близько хвилини нам вже вдалося створити навантаження на 84 %, цього вже достатньо для відтворення поставленої задачі. Чекаємо 10 — 15 хвилин, щоб перевірити, чи знижуватися навантаження на процесор і оперативну пам'ять.


Висновок команди top

15:20
За минулий час, а було виділено навіть більше, ніж плановані 10-15 хвилин, навантаження з процесора спала до 5-7 %, а навантаження на оперативну пам'ять так і залишилася в районі 80%.
На підставі цього, можна припустити, що на поточний момент обертання підкладки великого розміру викликає навантаження на оперативну пам'ять, і надалі вона не буде звільнено, що вплине на працездатність системи. У той же час використання підкладки не такого великого розміру забиває пам'ять незначно і будь-які дії з нею не зможуть некоректно вплинути на працездатність системи. Але для чесності експерименту потрібно перевірити це ще пару разів.

15:50
Повторний експеримент показав аналогічний результат. Оформляємо отримані результати про виявлену проблему в поставленого завдання.

16:20
Переглянемо, не змінився режим роботи пристрою, яке ми прошили вранці. Для цього дивимося, що лог, фільтруючий значення зміни режимів пристроїв порожній. Отже, будуємо припущення, що за 5 годин роботи зміна режиму не спостерігалося. Але для перевірки залишимо тест на добу і завтра перевіримо результат по збереженим логів.

16:40
Обговорюємо зафіксовані баги з колегами, оформляємо дані, отримані в результаті сьогоднішніх експериментів, для кожного бага заводимо тікет в Redmine.

17:30
Перевіряємо, чи немає нових листів, які завдання поставлені на завтра, їх пріоритети і терміни виконання. Також пам'ятаємо, що ми збираємо логи зі шлюзу, прошитого вранці. У зв'язку з чим, перед відходом з роботи треба не забути, що не варто відключати живлення від пристрою, а то завтра будемо неприємно здивовані відсутністю логів. Буває, звичайно, що відключається живлення у всьому будинку, але тут вже ми нічого вдіяти не можемо, крім як повторити.

18:00
Перевіряємо, що логи пишуться в файл, пристрій увімкнено в мережу. Можна вирушати додому. А завтра знову, назустріч новим невиявленим багам, цікавих завдань і труднощів, які зустрічаються на нелегкому шляху тестувальника.

Що в підсумку


Підводячи підсумки минулого дня, можна зробити висновок, що для коректного проведення тестів і отримання достовірних результатів необхідно особливу увагу приділити етапу попереднього планування тесту. Слід заздалегідь передбачити всі труднощі і можливі проблеми, з якими можна зіткнутися під час проведення тесту, це дозволить мінімізувати час на усунення (рішення) проблем.

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

Також ще до початку розміщення обладнання та проведення тестів слід кілька разів переконатися, що параметри, виставлені на використовуваному устаткуванні, відповідає необхідним значенням. Перевірити, що обладнання визначається в системі, світлова та звукова індикація, де вона є, справна і коректно функціонує. Це дозволить заощадити час на заміну несправного пристрою і повторення тесту (внаслідок невірно виставленого значення параметра).

Спасибі за увагу, готовий відповісти на питання в коментарях.
Джерело: Хабрахабр

0 коментарів

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