🐧 Терминал для тестировщика: консольные команды Unix/Linux, которые нужно знать наизусть

Первые шаги: 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.

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

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

Начать можно с простого. Команда 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 - выход

    

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

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

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

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

        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
    

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

        vim <path>/application.properties

    

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

        sudo systemctl restart <serviceName>.service
    

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

        sudo systemctl stаtus <serviceName>.service
    

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

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

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

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