Журнал QA Studio
Полезное

Linux для QA инженера: шпаргалка по командам

Этот путеводитель создан специально для тех, кто только начинает свой путь в
тестировании и впервые заглядывает в загадочный, но очень полезный мир командной
строки Linux. Не переживайте, если что-то кажется сложным — каждый из нас когда-то
стоял перед чёрным экраном и думал: «А что теперь делать?». Здесь мы разберём самые
нужные команды простыми словами, чтобы вы не просто запомнили их, а поняли, зачем
они нужны и как помогают в повседневной работе QA. Всё получится!

  1. Навигация и файлы

Большую часть времени вы будете просто перемещаться по папкам сервера, искать
конфигурационные файлы и смотреть, что где лежит. Это совсем не страшно, и скоро
станет привычным делом.
ls — что тут у нас есть?
Что делает: показывает список файлов и папок в текущей директории.
Зачем это QA: это первая команда, которую вы вводите, зайдя в незнакомую папку.
Помогает сориентироваться.
# Просто список файлов и папок
ls

# Подробный список: размер, дата изменения, права доступа
ls -l

# Показать и скрытые файлы (их имена начинаются с точки)
ls -a

# Отсортировать по размеру (самые большие файлы будут в конце)
ls -lS

# Отсортировать по времени изменения (свежие — сверху)
ls -lt

# Размер файлов показывать в читаемом виде (1K, 234M, 3G)
ls -lh
Пример:
# Хотим быстро посмотреть, какие логи менялись сегодня
ls -lt /var/log/myapp/
cd — переходим из папки в папку
Что делает: меняет текущую рабочую директорию.
Зачем это QA: основа навигации. Без неё никуда.
# Перейти в конкретную папку
cd /var/log

# Подняться на один уровень вверх
cd ..

# Вернуться в домашнюю папку
cd ~
# или просто
cd
pwd — где я сейчас нахожусь?
Что делает: выводит полный путь к текущей директории.
Зачем это QA: иногда в терминале видно только последнюю часть пути, и легко забыть,
где именно вы находитесь. pwd мгновенно напомнит.
pwd
# Вывод: /home/user/myproject/logs
find — поиск файлов и папок
Что делает: ищет файлы по имени, размеру, дате изменения и другим параметрам.
Зачем это QA: часто нужно найти, куда разработчики положили конфиг или
определённый лог. find — ваш универсальный поисковик.
# Ищем файл с точным именем "app.log"
find /home -name "app.log"

# Ищем все файлы с расширением .log
find /var/log -name "*.log"

# Ищем только обычные файлы (не папки) с именем *.conf
find . -type f -name "*.conf"

# Ищем папки, имя которых начинается на "config"
find . -type d -name "config*"

# Ищем файлы размером больше 100 мегабайт
find /var/log -size +100M

# Ищем файлы, изменённые за последние сутки
find . -mtime -1
Практичные примеры:
# Находим все конфиги приложения, в которых упоминается слово "database"
find /etc -name "*.conf" | xargs grep -l "database"

# Ищем логи, изменённые за последний час
find /var/log -mmin -60 -name "*.log"
file — что это за файл?
Что делает: определяет тип файла (текст, картинка, архив, исполняемый бинарник и т.д.).
Зачем это QA: иногда файлы приходят без расширения или с неожиданным
содержимым. file быстро подскажет, с чем мы имеем дело.
file screenshot.png
# Вывод: PNG image data, 1920 x 1080

file app.log.gz
# Вывод: gzip compressed data

file dump.sql
# Вывод: UTF-8 Unicode text

2. Работа с логами

Представь что логи являются дневником приложения. Когда пользователь говорит «у
меня что-то сломалось», первым делом мы заглядываем именно в него. Не бойтесь
больших файлов — у нас появились удобные инструменты в виде команд, чтобы быстро
найти нужную строчку.

tail — заглядываем в конец файла
Что делает: показывает несколько последних строк файла. По умолчанию — 10, но
можно попросить больше.
Зачем это QA: когда приложение только что упало или зависло, самые свежие записи в
логе обычно и содержат подсказку о причине. Вместо того чтобы открывать гигантский
файл целиком, мы смотрим только «хвостик».
# Показываем последние 10 строк
tail /var/log/app.log

# Хотим увидеть побольше — например, 50 последних строк
tail -n 50 /var/log/app.log

# А это волшебный режим: лог будет обновляться на глазах в реальном времени
tail -f /var/log/app.log
Пример из жизни QA:
# Слушаем лог в реальном времени и показываем только строки с ошибками
tail -f /var/log/app.log | grep -i "error\|exception\|failed"
Так вы сможете в реальном времени наблюдать, что происходит в системе, когда
воспроизводите баг. Удобно и наглядно!
grep — ищем иголку в стоге сена
Что делает: ищет в тексте строки, содержащие нужное слово или фразу, и показывает их.
Зачем это QA: в логах могут быть сотни тысяч строк, и искать вручную — занятие
неблагодарное. grep — ваш верный помощник, который мгновенно найдёт все
упоминания ошибки, конкретного пользователя или важного события.
# Ищем слово "ERROR" (регистр не важен)
grep -i "error" /var/log/app.log

# Ищем только целое слово "ERROR", чтобы не цеплять "ERROR_MESSAGE"
grep -w "ERROR" /var/log/app.log

# Показываем 3 строки после найденной — чтобы понять контекст
grep -A 3 "ERROR" /var/log/app.log

# А что было ДО ошибки? Покажем 2 строки перед ней
grep -B 2 "ERROR" /var/log/app.log

# Или всё вместе: 5 строк до и после
grep -C 5 "ERROR" /var/log/app.log

# Ищем сразу несколько ключевых слов (error, warning, fatal)
grep -E "error|warning|fatal" /var/log/app.log
Пример из практики:
# Находим все ошибки типа NullPointerException и видим, что происходило
перед ними
grep -B 5 -A 2 "NullPointerException" /var/log/app.log

# Ищем действия конкретного пользователя по его ID
grep "userId.*12345" /var/log/app.log

# Считаем, сколько раз произошла ошибка "Connection refused"
grep -c "Connection refused" /var/log/app.log
less — листаем большие файлы без стресса
Что делает: открывает файл в удобном режиме просмотра, где можно спокойно листать,
искать и не загружать всю память компьютера.
Зачем это QA: некоторые лог-файлы весят гигабайты. Открывать их в обычном
редакторе — верный способ «подвесить» систему. less загружает только ту часть,
которую вы сейчас видите, и работает очень быстро.
# Открываем файл для просмотра
less /var/log/app.log

# Внутри less работают простые клавиши:
# стрелка вниз / j — на строку вниз
# стрелка вверх / k — на строку вверх
# пробел / Page Down — страница вниз
# b / Page Up — страница вверх
# g — в самое начало файла
# G — в самый конец
# /error — начать поиск слова "error" (n — следующее совпадение)
# q — выйти
Полезный приём:
# Открываем большой лог и сразу начинаем искать слово "ERROR"
less -p "ERROR" /var/log/app.log
wc — быстрый подсчёт строк
Что делает: считает количество строк, слов или символов в файле.
Зачем это QA: чтобы быстро оценить объём лога или понять, сколько раз произошло
какое-то событие.
# Сколько всего строк в логе?
wc -l /var/log/app.log

# А сколько раз встретилась ошибка?
grep "ERROR" /var/log/app.log | wc -l
Пример из жизни:
# Сколько запросов сделал пользователь за одну сессию?
grep "sessionId.*abc123" /var/log/app.log | wc -l

# Хотим отправить лог разработчику, но сначала узнаем его размер в строках
wc -l /var/log/app.log
# Вывод: 284739 app.log — почти 285 тысяч строк, прилично!
awk — работаем с колонками как с таблицей
Что делает: воспринимает текст как таблицу с колонками (обычно разделёнными
пробелами) и позволяет легко вытаскивать нужные столбцы, фильтровать или считать.
Зачем это QA: многие логи имеют чёткую структуру, например: дата, время, уровень
ошибки, сообщение. awk помогает обрабатывать их почти как Excel.
# Представим, что лог выглядит так:
# 2024-01-15 10:23:45 ERROR UserService Failed to login
user=test@example.com
# Вытаскиваем первый и третий столбец (дату и уровень)
awk '{print $1, $3}' /var/log/app.log

# Показываем только строки, где упоминается email
awk '/user=.*@/ {print $0}' /var/log/app.log
Пример из практики:
# Лог запросов к API: timestamp, endpoint, status_code, duration_ms
# Показываем только медленные запросы (дольше 1000 мс)
awk '$4 > 1000 {print $0}' /var/log/api.log

# Считаем количество ошибок по каждому коду ответа (например, 404, 500)
awk '$3 >= 400 {print $3}' /var/log/api.log | sort | uniq -c
sed — быстрые замены и чистка текста
Что делает: умеет заменять один текст на другой, удалять строки или вставлять новые —
и всё это без необходимости открывать файл в редакторе.
Зачем это QA: например, чтобы перед отправкой лога разработчику скрыть из него
чувствительные данные (email, пароли) или убрать лишние отладочные строки.
# Заменяем все "old" на "new" и выводим результат на экран
sed 's/old/new/g' app.log

# Удаляем из вывода все строки, где есть слово "DEBUG"
sed '/DEBUG/d' app.log

# Внимание! Эта команда меняет сам файл (осторожно, без отмены)
sed -i 's/old/new/g' app.log
Безопасный пример:
# Перед отправкой лога маскируем все email-адреса
sed 's/[a-z]*@[a-z]*\.com/HIDDEN_EMAIL/g' app.log > cleaned.log

# Убираем отладочные строки и сохраняем в новый файл
sed '/DEBUG/d' /var/log/app.log > errors_only.log

3. Процессы и система

Когда приложение «тормозит» или потребляет слишком много ресурсов, следующие
команды помогут понять, что происходит под капотом. Не волнуйтесь — это просто взгляд на «жизнь» системы.

ps — какие процессы запущены?
Что делает: показывает список работающих процессов.
Зачем это QA: чтобы убедиться, что нужный сервис запущен, узнать его идентификатор
(PID) или проверить, не запущено ли что-то лишнее.
# Показываем все процессы в подробном формате
ps aux

# Ищем процессы конкретного пользователя
ps aux | grep postgres

# Ищем процесс по части имени (например, java-приложение)
ps aux | grep -i "java"

# Выводим только PID и имя команды (минимально)
ps -eo pid,comm
Пример:
# Узнаём, сколько памяти потребляет наше Java-приложение
ps aux | grep java
# В выводе увидим столбцы %CPU и %MEM — это загрузка процессора и памяти.
top и htop — мониторинг в реальном времени
Что делает: показывает обновляющийся список процессов, сортированный по
использованию ресурсов. htop — более красочная и удобная версия (если установлена).
Зачем это QA: быстро оценить, не упирается ли система в лимит памяти или
процессора, когда приложение ведёт себя странно.
# Запускаем мониторинг
top

# Выход — клавиша q
# Внутри top можно нажимать:
# M — сортировка по использованию памяти
# P — сортировка по загрузке процессора
kill — аккуратно завершаем процесс
Что делает: отправляет сигнал процессу, обычно с просьбой завершиться.
Зачем это QA: иногда приложение зависает намертво, и единственный способ его
перезапустить — сначала остановить процесс. Делаем это вежливо или, в крайнем
случае, настойчиво.
# Мягкая остановка (процессу даётся шанс сохранить данные)
kill 12345

# Если процесс не реагирует — принудительная остановка (сигнал -9)
kill -9 12345

# Попросить процесс перечитать конфигурацию (работает не для всех)
kill -HUP 12345
Безопасная последовательность перезапуска:
# Находим PID процесса
ps aux | grep java
# Допустим, PID = 12345

# Мягко завершаем
kill 12345
# Ждём пару секунд
sleep 2
# Проверяем, что процесс действительно исчез
ps aux | grep java

# Запускаем заново (как именно — зависит от приложения)
cd /opt/myapp && ./start.sh
free — сколько свободной памяти?
Что делает: показывает использование оперативной памяти и файла подкачки.
Зачем это QA: если приложение падает с ошибкой OutOfMemory, стоит проверить,
достаточно ли памяти в системе в принципе.
# Показываем в мегабайтах (удобно для восприятия)
free -m
df — сколько места на дисках?
Что делает: показывает, сколько свободного места осталось на подключенных дисках.
Зачем это QA: иногда логи разрастаются до невероятных размеров и забивают весь
диск, из-за чего приложение перестаёт работать. df быстро выявит проблему.
df -h
# Ключ -h делает размеры человекочитаемыми (G, M)

4. Сеть

Многие баги связаны с тем, что приложения не могут «договориться» по сети. Эти
команды помогут проверить, кто кого не слышит.

curl — ваш карманный HTTP-клиент
Что делает: отправляет HTTP-запросы и показывает ответ. Идеально для ручной
проверки API.
Зачем это QA: быстро проверить, отвечает ли сервер, какой статус код возвращает,
корректен ли JSON в ответе.
# Простой GET-запрос
curl https://api.example.com/health

# GET с красивым отображением JSON (если установлена утилита jq)
curl -s https://api.example.com/users/123 | jq .

# Отправляем POST-запрос с телом в формате JSON
curl -X POST -H "Content-Type: application/json" \
-d '{"name":"test","email":"test@example.com"}' \
https://api.example.com/users

# Обновляем данные через PUT
curl -X PUT -H "Content-Type: application/json" \
-d '{"status":"active"}' \
https://api.example.com/users/123

# Удаляем запись через DELETE
curl -X DELETE https://api.example.com/users/123

# Добавляем заголовки авторизации
curl -H "Authorization: Bearer token123" \
-H "Accept: application/json" \
https://api.example.com/profile
Практичные приёмы:
# Только HTTP-код ответа (200, 404, 500 и т.д.)
curl -s -o /dev/null -w "%{http_code}" https://api.example.com/users/123

# Измеряем время ответа
curl -s -o /dev/null -w "Time: %{time_total}s\n"
https://api.example.com/health
netstat и ss — кто слушает порт?
Что делает: показывает открытые сетевые соединения и порты, которые «слушают»
входящие подключения.
Зачем это QA: проверить, что приложение действительно запущено и ожидает запросы
на нужном порту (например, 8080 для веб-сервера).
# Показываем все слушающие порты с информацией о процессе
ss -tulpn

# Ищем конкретный порт (например, 8080)
ss -tulpn | grep 8080
ping — проверка связи до сервера
Что делает: отправляет специальные пакеты и ждёт ответа, измеряя время.
Зачем это QA: самый простой способ понять, доступен ли удалённый сервер вообще.
# Пингуем, пока не прервём (Ctrl+C)
ping example.com

# Отправим ровно 4 пакета и остановимся
ping -c 4 example.com
telnet и nc — проверка TCP-порта
Что делает: пытается установить соединение с конкретным портом на сервере.
Зачем это QA: иногда ping проходит (сервер жив), но само приложение на порту 8080 не
отвечает. Эти команды проверяют доступность именно нужного порта.
# Простая проверка через netcat (nc)
nc -zv example.com 8080
# Вывод: Connection to example.com 8080 port [tcp/http] succeeded!

# Проверить несколько портов сразу
nc -zv example.com 80 443 8080 9090
wget — скачиваем файлы
Что делает: загружает файлы по HTTP/HTTPS/FTP.
Зачем это QA: скачать сборку приложения с сервера, загрузить архив с логами для
локального анализа.
# Скачать файл
wget https://example.com/file.zip

# Скачать с указанием логина и пароля
wget --user=admin --password=secret https://example.com/secure-file.zip

5. Архивы и сжатие

Логи часто хранятся в сжатом виде, чтобы экономить место. Умение работать с архивами
напрямую экономит время.

tar — собираем и распаковываем архивы
Что делает: объединяет файлы в один архив, может также сжимать их.
Зачем это QA: распаковать старые логи, которые прислал администратор, или
запаковать свои логи для отправки разработчику.
# Создать простой архив (без сжатия)
tar -cf logs.tar /var/log/myapp/*.log

# Создать архив и сжать его gzip (расширение .tar.gz)
tar -czf logs.tar.gz /var/log/myapp/*.log

# Распаковать архив
tar -xzf logs.tar.gz

# Распаковать в конкретную папку
tar -xzf logs.tar.gz -C /tmp/extracted/

# Посмотреть содержимое архива, не распаковывая
tar -tzf logs.tar.gz
zgrep и zcat — работаем со сжатыми файлами без распаковки
Что делает: zcat показывает содержимое сжатого файла, zgrep ищет текст внутри него.
Зачем это QA: старые логи часто лежат в файлах с расширением .gz. Распаковывать их целиком ради одного поиска — долго. Эти команды делают всё на лету.
# Ищем ошибку в сжатом логе
zgrep "ERROR" /var/log/archive/app.log.gz

# Просматриваем содержимое сжатого файла постранично
zcat /var/log/archive/app.log.gz | less

6. Текстовая обработка

Иногда нужно быстро обработать данные из лога, посчитать что-то или
переформатировать. Вот несколько простых, но мощных инструментов.

cat — вывести содержимое файла
Что делает: показывает файл целиком в терминале.
Зачем это QA: подходит для маленьких файлов. Для больших лучше использовать less
или tail.
cat config.yml

# Объединить несколько файлов в один
cat part1.log part2.log > combined.log
sort — наводим порядок в строках
Что делает: сортирует строки по алфавиту или по числам.
Зачем это QA: чтобы подготовить данные для подсчёта уникальных значений или просто
упорядочить вывод.
# Сортируем по алфавиту
sort file.log

# Сортируем числа по убыванию
sort -nr file.log
uniq — убираем повторы
Что делает: удаляет повторяющиеся строки, которые идут подряд. Обычно используется
вместе с sort.
Зачем это QA: чтобы посчитать, сколько раз встречается каждое уникальное значение
(например, коды ошибок).
# Показываем только уникальные строки
sort file.log | uniq

# Сразу считаем количество вхождений каждого значения
sort file.log | uniq -c | sort -nr
Практичный пример:
# Топ-10 самых частых ошибок в логе
grep "ERROR" app.log | awk '{print $NF}' | sort | uniq -c | sort -nr | head
-10
head и tail — начало и конец файла
Мы уже знакомы с tail. Его «брат» head показывает первые строки файла. Полезно
для быстрого взгляда на формат лога.
# Первые 20 строк
head -n 20 app.log

# Последние 20 строк
tail -n 20 app.log

7. Права и пользователи

В Linux у каждого файла есть владелец и права доступа. Иногда из-за них возникает
ошибка «Permission denied». Не пугайтесь — это поправимо.

chmod — меняем права доступа
Что делает: устанавливает, кто может читать, записывать или исполнять файл.
Зачем это QA: скрипт не запускается? Скорее всего, у него нет прав на исполнение.
Исправим одной командой.
# Даём право на выполнение для всех (+x)
chmod +x script.sh

# Устанавливаем права: владелец может всё, остальные только читать и
выполнять
chmod 755 script.sh
chown — меняем владельца файла
Что делает: передаёт права владения файлом другому пользователю или группе.
Зачем это QA: если файл создан от имени root, а приложение работает от
пользователя app, оно может не иметь доступа.
# Меняем владельца и группу
chown user:group file.log

# Рекурсивно меняем для всей папки
chown -R user:group /var/log/myapp/
sudo — выполняем команду от имени суперпользователя
Что делает: даёт временные права администратора для выполнения одной команды.
Зачем это QA: многие системные операции (перезапуск сервисов, просмотр защищённых
логов) требуют привилегий.
# Перезапустить сервис
sudo systemctl restart myapp

# Прочитать защищённый лог
sudo tail /var/log/secure

8. Полезные приёмы и маленькие хитрости

Конвейеры (пайпы)
Символ | позволяет передать результат одной команды на вход другой. Это как
конвейер на фабрике: данные переходят от одного рабочего к другому.
# Смотрим лог, фильтруем ошибки, берём третий столбец, сортируем, считаем
уникальные
cat app.log | grep "ERROR" | awk '{print $3}' | sort | uniq -c | sort -nr
history — вспоминаем, что делали
Бывает, набрали сложную команду полчаса назад, а сейчас она снова нужна. history
покажет список последних команд.
history
# Ищем команду с curl
history | grep curl
# Повторяем команду под номером 42
!42
Горячие клавиши в терминале
Ctrl + C — прервать текущую команду (если она зависла).

Ctrl + L — очистить экран.

Стрелки вверх/вниз — листать историю команд.

Tab — автодополнение (начинаете печатать имя файла, жмёте Tab, и оно
дописывается).

nohup — запуск в фоне, который переживёт закрытие окна

Если нужно запустить долгий процесс и отключиться от сервера, используйте nohup .
nohup ./long_script.sh &

9. Что делать, если что-то пошло не так?

Проблема
Возможная причина
Что попробовать
permission denied
Нет прав на файл или папку
Проверить права ls -la, использовать sudo
command not found
Команда не установлена или опечатка
Проверить написание, возможно, нужно установить пакет
No such file or directory
Неверный путь или файл отсутствует
Проверить текущую папку pwd, посмотреть содержимое ls
Connection refused
На сервере никто не слушает этот порт
Проверить, запущен ли сервис, с помощью ss -tulpn
Connection timed out
Сетевой экран или проблемы с сетью
Проверить доступность ping, порт nc - zv
Диск заполнен
Логи или другие файлы заняли всё место
df -h покажет, какой раздел полон; du-sh * в папке покажет, что занимает больше всего

10. Примеры из реальной работы QA

Разбираемся с ошибкой входа пользователя
# 1. Ищем ошибки в логе за последний час
grep "2024-01-15 1[0-9]:.*ERROR" /var/log/app.log

# 2. Нашли ошибку — смотрим, что было до и после неё
grep -B 10 -A 5 "Login failed.*user=test@example.com" /var/log/app.log

# 3. Проверяем, доходил ли запрос до базы данных
grep "database.*test@example.com" /var/log/db.log

# 4. Считаем, сколько всего было неудачных попыток входа
grep -c "Login failed" /var/log/app.log
Анализируем медленный API-эндпоинт
# 1. Находим все запросы, которые выполнялись дольше 2 секунд
awk '$NF > 2000 {print $0}' /var/log/api.log

# 2. Увидели проблемный URL — смотрим детали только по нему
grep "GET /api/users" /var/log/api.log | awk '$NF > 1000'
Готовим логи для разработчика (чисто и аккуратно)
# 1. Находим логи за нужный период (сравниваем с меткой времени)
find /var/log -name "*.log" -newer /tmp/start_marker

# 2. Запаковываем с понятным именем
tar -czf debug_logs_$(date +%Y%m%d_%H%M%S).tar.gz /var/log/myapp/

# 3. Убираем из логов чувствительные данные перед отправкой
sed 's/userId=[0-9]*/userId=HIDDEN/g' debug_logs.tar.gz >
debug_logs_clean.tar.gz
Не переживайте, если не всё запомнили с первого раза. Самые важные команды
запоминаются практикой. Каждый раз, когда вы используете tail -f или grep "ERROR",
вы становитесь на шаг ближе к уверенной работе в Linux. Удачи в охоте за багами!
Над статьёй работал:
Александр Галкин, QA Lead, ex ВТБ, Т1, МТC
@qa_lead_automation
Телеграм-канал: @it_for_qa
Полезные ссылки: