С тобой сложно, но без тебя невозможно. Посвящается текстовой консоли, работе в командной строке и причинам, по которым эту премудрость стоит освоить начинающему инженеру по Quality Assurance.

Первые шаги: 40 основных команд

Мое знакомство с терминалом началось немного раньше чем путь в тестирование. Скорее всего с установки системы на спор, а потом как-то прижился Linux, и сейчас винда вызывает некоторое подвисание.

Толчок в развитии дала статья «40 основных команд» и книга Скотта Гараннемана «Linux/ Необходимый код и команды. Карманный справочник» (в магазинах доступно ее 2-е издание).

Нагугилшь команду, а перейти в нужную папку забудешь. Или перепутаешь направление dd (команда поблочного переноса данных) и все, здравствуй вечер переустановки системы и потеря данных. Справочники – это хорошо, но основы работы в командной строке Unix/Linux нужно знать наизусть.

У меня получился примерно такой список необходимых внутренних команд оболочки Bourne shell (командные процессоры sh, bash и т.д.) и внешних утилит. Вызываются они одинаково:

• Навигация по каталогам и файлам: cd, ls, pwd.
• Работа с файлами и каталогами: rm, mv, cp, mkdir, cat, more, grep, sort, touch, tail, head, less, find.
• Повышение привилегий: su, sudo.
• Управление правами: chmod, chown, chgrp.
• Текстовые редакторы: vi, vim, nano.
• Архивация и разархивирование: tar, unzip, zip.
• Установка программ: apt, yum.
• Информация о командах: man, опция -h (—help).
• История ранее выполняемых команд: history.
• Работа с сетью: curl, ping, nslookup, netstat, wget, telnet, ifconfig, ip, ss.
• Информация о системе и процессах: top, du, df, ps.
• Управление процессами: kill.

Конечно команд больше, но эти мне пригодились мне в самом начале пути. Расскажу подробнее о самых необходимых.

Совершенствуем чтение логов

Первое, для чего тестировщик откроет терминал и начнет в нем работать – это логи (от англ. logs – файлы журналов, обычно текстовые). Потому что об аргумент «у меня все работает» разбиваются все доводы и с таким трудом найденные шаги воспроизведения. Можно достать файл целиком с помощью WinSCP и приложить его к багу, но не факт, что его откроют (и хорошо еще, если правильно настроено порционирование логов и файл весит не так уж и много).

Начать можно с простого. Команда tail показывает окончание файла (аналогично команда head читает данные с начала), а если добавить ключ -n, то можно увидеть заданное количество строк:

         tail -n 300 console.log     

С ключом -f команда будет показывать дозапись в файл в реальном времени:

         tail -f console.log     

Команда tail помогает, если ошибка произошла только что и ее найти в последних строках, или она воспроизводится прямо сейчас. Если нужно просмотреть весь журнал и найти определенные события (строки по шаблону), можно воспользоваться командой grep:

         grep -i ‘error’ console.log # где i - регистронезависимый поиск      

В данном случае будут найдены все строки в которых есть строка ‘error’ без зависимости от регистра. У команды гораздо больше возможностей, чем я показала. Про grep можно писать отдельную статью. Вот вариант поиска классов, логи которых включены на уровне DEBUG и сортировка их с помощью утилиты sort (один из примеров, который понадобился в реальной работе):

         grep DEBUG console-main.log | grep -oP '[a-z.]+.[A-Z][a-zA-Z0-9]*' | sort | uniq -c     

Третий способ чтения логов – команда less. Работа в ней схожа с работой в редакторе vim, но с возможностью только чтения и поиска по файлу:

         less console.log # откроет файл на просмотр.  # Для навигации можно и нужно пользоваться клавишами: #	Shift+g - для перемещения в конец файла #	Shift+f - для перехода в режим чтения дозаписи файла #	/ + “text” - для поиска значения вниз от курсора #	? + “text” - для поиска значений вверх от курсора #	Q - выход      

Для чтения логов можно пользоваться любым их этих трех способов, но самый удобный – less. Он упрощает работу с большими файлами журналов и отслеживание ошибки, например, по одному треду.

Спасаем показ: подключаемся к базе данных

Рано или поздно в жизни тестировщика наступает сдача проекта. Бессонные ночи, правки на прод за час до релиза, написание ПМИ и постоянный перетест. И вот уже почти конец, остался показ.

В тот раз показ проходил в виде испытаний пользователями. Сами пользователи проходили ПМИ в качестве обучения, параллельно принимая систему. Мы могли только отслеживать и фиксировать ошибки и подсказывать, если выходили сильные заминки.

В системе объект должен был двигаться по определенному жизненному циклу. Пользователь нажал кнопку, и ничего не произошло. Даже в логах не отобразилась никакая информация. Показ встал. Действовать нужно быстро, иначе не засчитывалась защита. Под рукой только терминал. Выход из такой ситуации достаточно прост:

         psql -h localhost -U <user> #	где psql - утилита для работы с бд постгрес #	     h - хост подключения к бд #	     U - пользователь для подключения к бд      

А дальше найти селектом нужный объект и посмотреть, был ли переход объекта. Оказалось, что кнопка не была нажата, и показ продолжился в штатном режиме.

Ошибка не на нашей стороне: связанность, курлы и интеграции

Тестирование интеграций – одна из самых интересных в сфере Quality Assurance. Поиск возможных ошибок всегда усложняется тем, что не понятно, на чьей они стороне, есть ли связанность и на тот ли тестовый стенд настроено каждое приложение.

Прежде чем перейти к собственно тестированию, я провожу проверку связности.

Начнем с проверки сетевой доступности сервиса, с которым вы интегрируетесь (действия производятся с машины, на которой поднят интегрирующийся сервис):

         ping <host>     

Пинг проходит, значит на той стороне как минимум поднят стенд (противоположный результат ни о чем не говорит, поскольку пакеты ICMP может резать сетевой экран – прим. ред.). Теперь нужно проверить, открыты ли нужные порты:

         telnet <ip> <port> # Например: telnet checkip.dyndns.org 80      

Если соединение открыто, остается последний шаг перед началом тестирования интеграции. С помощью утилиты curl проверить возможность представленного в спецификации запроса:

          curl <host>| jq # jq для структурированного просмотра ответа, если используется формат json      

Например:

         curl 'https://proglib.io/api/paging/live'| jq     

Ответ 200, значит можно приступать к тестированию. Минимальные условия для проверки выполнены.

Перезагрузка приложений и изменение настроек

Рано или поздно возникает потребность временно изменить настройки на тестовом стенде, например, изменить максимальный размер загружаемых файлов или подправить ссылку интеграционного стенда. Не всегда есть рядом разработчик или девопс, который может помочь.

В проектах настройки лежат в файлах application.properties (конфигурация приложения может описываться в самых разных файлах и даже с использованием языков разметки – прим.ред.). Чтобы найти их и открыть файл, воспользоваться командой locate:

         locate application.properties     

Команда locate проводит поиск в специальной базе данных (не стоит путать ее с сервером SQL), которая периодически обновляется через планировщик. Для немедленного обновления нужно запустить команду updatedb с администраторскими полномочиями (su, sudo).

После нахождения пути, по которому лежат настройки, их можно открыть в vim или в другом текстовом редакторе:

         vim <path>/application.properties      

После изменения и сохранения :wq настроек, нужно перезагрузить приложение. Рестарт приложения в Linux обычно выполняется командой (если в нем реализована вся необходимая обвязка, иначе придется убивать процессы с помощью kill и запускать программу заново – прим. ред.):

         sudo systemctl restart <serviceName>.service     

После рестарта лучше смотреть логи, поскольку изменение настроек может так критично повлиять на приложение, что оно не запустится. Также нужно посмотреть статус приложения спустя несколько минут после рестарта:

         sudo systemctl stаtus <serviceName>.service     

Прим. ред. Этот метод сработает, если в приложении реализована вся скриптовая обвязка, в противном случае воспользуйтесь командой ps.

Приложение должно быть запущено, иначе лучше вернуть старые настройки и заново его рестартовать.

Нужно ли это тестировщику?

Терминал – инструмент, позволяющий решать множество мелких проблем, не прибегая к помощи других людей и программ. Конечно, есть вероятность сломать с его помощью систему или стереть нужные файлы, можно попасть в глупое положение, можно снести все. Однако сделать это можно и не используя терминал, поэтому почему бы не попробовать?

Удачи в обучении!