Всем привет!
Меня зовут Денис 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
Проверяем, что логи пишутся в файл, устройство включено в сеть. Можно отправляться домой. А завтра вновь, навстречу новым невыявленным багам, интересным задачам и трудностям, которые всегда встречаются на нелёгком пути тестировщика.
Что в итоге
Подводя итоги прошедшего дня, можно сделать вывод, что для корректного проведения тестов и получения достоверных результатов требуется особое внимание уделить этапу предварительного планирования теста. Следует заранее предусмотреть все трудности и возможные проблемы, с которыми можно столкнуться во время проведения теста, это позволит минимизировать время на устранение (решение) проблем.
К примеру, эксперимент по передаче голоса по цепочке ретрансляторов занял бы гораздо меньше времени, если бы мы заранее (ещё на этапе планирования эксперимента) учли, что ретрансляторы будут слышать друг друга через стены, и уменьшили бы мощность ретрансляторов. А во время проведения эксперимента не отвлекались бы на эту проблему.
Также ещё до начала расстановки оборудования и проведения тестов следует несколько раз удостовериться, что параметры, выставленные на используемом оборудовании, соответствует требуемым значениям. Проверить, что оборудование определяется в системе, световая и звуковая индикация, где она есть, исправна и корректно функционирует. Это позволит сэкономить время на замену неисправного устройства и повторения теста (вследствие неверно выставленного значения параметра).
Спасибо за внимание, готов ответить на вопросы в комментариях.
Автор: RTL-Service
