«В начале была командная строка.» Neal Stephenson
В этом уроке мы с вами тестировать не будем.
Хотя "в жизни" тестирование консольных приложений вам может пригодиться. Но не часто. Я бы сказал в двух случаях:
Первый случай - при устройстве на работу в тестовых заданиях может попасться задача протестировать (или протестировать в воображении) какое-либо консольное приложение.
И второй случай - если вы устроитесь в компанию которая пишет эти самые консольные приложения. Тогда да, это прям будет ваша работа. Но компаний таких не много настолько, что такой вероятностью можно пренебречь.
Так зачем же нужен терминал?
Терминал — это окно, где ты общаешься с компьютером текстовыми командами (без кнопок и меню).
Исторически терминал был буквально устройством: клавиатура + экран, через которые человек общался с большим компьютером (мейнфреймом). Никаких мышек и красивых интерфейсов тогда не было — управление шло командами.
Позже “терминал” стал программой на компьютере, которая делает то же самое: даёт тебе доступ к командной строке (shell).
Shell — это “оболочка”, то есть программа‑посредник между тобой и операционной системой. Ты пишешь команду — оболочка запускает нужную программу, показывает результат, пишет ошибки.
Важно различать два понятия, которые часто путают:
Терминал (terminal) — это окно/приложение, где ты вводишь команды.
Командная оболочка (shell) — это то, что эти команды понимает.
Примеры:
— Windows Terminal — это терминал (окно), а PowerShell — командная оболочка (то, что выполняет команды).
— Terminal/iTerm2 на macOS — терминалы, а оболочка обычно zsh (иногда bash).
— В Linux терминалов много (GNOME Terminal, Konsole и т.п.), оболочка чаще bash, но нередко используют zsh или fish.
Почему терминал до сих пор жив, хотя есть GUI?
Потому что текстовые команды:
— точнее (меньше двусмысленности)
— быстрее для повторяющихся действий
— отлично автоматизируются (скрипты)
— удобны для работы с серверами, где “кнопок” нет
Многие команды терминала — это обычные маленькие программы
Например, grep, curl, git — это не “функции терминала”, а отдельные утилиты. Терминал — просто место, где ты их запускаешь. Это хорошо: ты можешь комбинировать утилиты и получать удобные цепочки действий.
Терминал полезен тем, что позволяет быстро и точно проверить, что происходит "под капотом":
— какой ответ вернул сервер (API), даже если приложение показывает “что-то пошло не так”
— что система записала в журнал событий (логи), когда что-то сломалось
— есть ли связь с нужным адресом и портом, и на каком шаге она пропадает (интернет/DNS/маршрут)
— какие программы сейчас запущены и не заняли ли они нужный порт
— какие изменения в коде ты проверяешь прямо сейчас (ветка, коммит, список изменений в Git)
и многое другое..
На самом деле в тестировании мы достаточно много работаем с терминалом, хотя для некоторых видов тестирования (или например пока вы стажер) он не необходим. Но для некоторых видов тестирования (например тестирования безопасности) - это практически единственный интерфейс (способ) взаимодействовать с тестируемым объектом.
В этом уроке разберем полезный “скелет” команд:
1) базовая навигация и файлы
2) просмотр/поиск логов
3) сеть и API через curl
4) быстрый дебаг (процессы/порты)
5) Git минимум для QA
Договоримся:
— для Windows мы будем разбирать команды для PowerShell (это стандарт). На самом деле это не единственный терминал доступный в Windows - есть еще cmd и git bash. Но cmd значительно реже используется, а git bash (на базовом уровне) практически аналогичен терминалу из линукс (хотя и сильно урезан в командах).
— для macOS/Linux — bash/zsh (по сути одинаково на базовом уровне).
0) Два правила безопасности (серьёзно)
Терминал это способ взаимодействовать с компьютером для "профессионалов", то есть тут чаще всего вас не спросят действительно ли вы хотите удалить все безвозвратно или куда-либо перенести. Или даже если спросят - есть вероятность что в потоке текста вы этого не поймете. В терминале часто вам видны "скрытые" для вашей же безопасности системные файлы и вы легко можете их повредить/затереть - поэтому 2 правила:
Правило №1. Не запускай команды, смысл которых не понимаешь, особенно если там есть:
sudo, rm, del, format, diskpart, wipe, truncate.
Суть этого правила - вы должны точно понимать что будет делать эта команда перед тем как ее запустить.
Правило №2. Перед любой командой, которая что-то удаляет/перемещает — проверь, в какой ты папке.
Мини-команда “я не потеряюсь”:
— Windows / macOS / Linux: pwd (покажет текущую папку)
1) Открыть терминал и понять “где я”
Windows:
— Windows Terminal → PowerShell
macOS:
— Terminal или iTerm2
Linux:
— любой Terminal (GNOME Terminal / Konsole и т.п.)
Команды:
Текущая папка (где я сейчас)
— Windows (PowerShell): pwd (это алиас команды Get-Location)
— macOS/Linux: pwd
Список файлов
— Windows (PowerShell): ls или dir (это алиасы Get-ChildItem)
— macOS/Linux: ls или ls -la (подробно + скрытые файлы)
Подсказка: если команда не понятна — у неё почти всегда есть помощь
— macOS/Linux: man ls
— PowerShell: Get-Help ls (или Get-Help Get-ChildItem)
Примечание: в PowerShell многие привычные “unix-команды” (ls/cd/pwd) — алиасы. Это нормально, просто полезно знать “официальные” имена команд.
============================================================
2) Навигация по папкам (cd)
Перейти в папку
— Windows: cd C:\work\project
— macOS/Linux: cd /Users/alex/work/project
На уровень выше
— Windows/macOS/Linux: cd ..
В домашнюю папку
— Windows: cd $HOME
— macOS/Linux: cd ~
Вернуться в предыдущую папку
— macOS/Linux: cd -
— PowerShell: тоже может работать, но чаще используют историю команд (стрелка вверх)
Важно про пути с пробелами - если в названии или пути файла есть пробелы - используй кавычки:
— Windows/macOS/Linux: cd "C:\Program Files" (или любой путь в кавычках)
============================================================
3) Файлы и папки: создать/скопировать/переместить/удалить
Создать папку
— Windows: mkdir logs
— macOS/Linux: mkdir logs
Создать пустой файл
— macOS/Linux: touch app.log
— Windows (PowerShell): New-Item app.log
Копировать файл
— macOS/Linux: cp a.txt b.txt
— Windows: Copy-Item a.txt b.txt
Примечание: a.txt и b.txt - названия ваших файлов (с расширением)
Переместить / переименовать
— macOS/Linux: mv a.txt old.txt или mv a.txt ./logs/
— Windows: Move-Item a.txt old.txt или Move-Item a.txt .\logs\
Удалить файл
— macOS/Linux: rm app.log
— Windows: Remove-Item app.log
Удалить папку рекурсивно (использовать осторожно)
— macOS/Linux: rm -r logs
— Windows: Remove-Item .\logs -Recurse
============================================================
4) Логи: быстро посмотреть файл и “подсмотреть, что было”
Три базовые операции по логам:
1) быстро глянуть начало/конец
2) найти нужные строки
3) “следить” за логом в реальном времени
Показать весь файл (только если он небольшой)
— macOS/Linux: cat app.log
— Windows: Get-Content app.log
Посмотреть постранично (лучший вариант для больших файлов)
— macOS/Linux: less app.log (выход: q)
— Windows: Get-Content app.log | more
Первые N строк
— macOS/Linux: head -n 50 app.log
— Windows: Get-Content app.log -TotalCount 50
Последние N строк (самое частое)
— macOS/Linux: tail -n 50 app.log
— Windows: Get-Content app.log -Tail 50
Следить за логом в реальном времени (как tail -f)
— macOS/Linux: tail -f app.log
— Windows: Get-Content app.log -Wait
QA-лайфхак: если “упало” — начинай с последних 200 строк и поиска по ключам:
ERROR, Exception, stacktrace, timeout, traceId, requestId
============================================================
5) Поиск по логам: grep (Unix) и Select-String (PowerShell)
macOS/Linux (grep)
Найти строки с ERROR
grep "ERROR" app.log
С номерами строк
grep -n "ERROR" app.log
Рекурсивно по папке (когда логов много)
grep -R "Exception" ./logs
Windows PowerShell (Select-String)
Поиск по файлу
Select-String -Path .\app.log -Pattern "ERROR"
Поиск по нескольким файлам
Select-String -Path .\logs*.log -Pattern "Exception"
Сохранить найденное в файл
Select-String -Path .\app.log -Pattern "ERROR" | Out-File .\errors.txt
============================================================
6) Сеть для QA: “почему не открывается / не ходит”
Проверить доступность хоста
— Windows/macOS/Linux: ping example.com
Проверить DNS (очень частая причина проблем)
— Windows: nslookup example.com
— macOS/Linux: nslookup example.com (или dig example.com, если есть)
Проверить маршрут (где “умирает”)
— Windows: tracert example.com
— macOS/Linux: traceroute example.com
Проверить доступность порта
— Windows (PowerShell): Test-NetConnection example.com -Port 443
— macOS/Linux (часто): nc -vz example.com 443
(если nc нет — это ок, просто используй другие инструменты/подходы, например:
telnet example.com 443)
============================================================
7) API из терминала: curl (must-have)
curl — это “пощупать backend руками”. Без UI. Без дополнительных программ типа Postman (он последнее время почему то у меня лично очень тормозит).
ВАЖНО для Windows/PowerShell:
в зависимости от версии PowerShell команда curl может быть алиасом Invoke-WebRequest.
Самый безопасный вариант — явно вызывать curl как curl.exe.
GET запрос
— macOS/Linux: curl https://api.example.com/health
— Windows (PowerShell): curl.exe https://api.example.com/health
Заголовки + статус
— macOS/Linux: curl -i https://api.example.com/health
— Windows (PowerShell): curl.exe -i https://api.example.com/health
Красиво смотреть JSON (если есть jq)
— macOS/Linux: curl -s https://api.example.com/data | jq
— Windows (PowerShell):
curl.exe -s https://api.example.com/data | ConvertFrom-Json
(работает не всегда идеально, jq чаще удобнее)
POST запрос с JSON (универсальный пример)
— macOS/Linux:
curl -X POST https://api.example.com/login -H "Content-Type: application/json" -d "{\"login\":\"user\",\"password\":\"pass\"}"
— Windows (PowerShell) (надёжнее тоже через curl.exe):
curl.exe -X POST https://api.example.com/login -H "Content-Type: application/json" -d "{\"login\":\"user\",\"password\":\"pass\"}"
Таймауты (важно в дебаге)
curl --connect-timeout 5 --max-time 15 https://api.example.com/data
Сохранить ответ
curl https://api.example.com/data -o response.json
Почему это важно для QA:
в баг можно приложить curl-команду — это почти идеальные “шаги воспроизведения”, которые разработчик сможет повторить.
============================================================
8) Быстрый дебаг: процессы и порты
Классическая QA-ситуация: “локально не стартует”, “порт занят”, “что-то висит”.
Посмотреть процессы
— macOS/Linux:
ps aux
top (выход: q)
— Windows PowerShell:
Get-Process
Топ по CPU: Get-Process | Sort-Object CPU -Descending | Select-Object -First 10
Кто занял порт 8080
— macOS/Linux:
lsof -i :8080
— Windows:
netstat -ano | findstr :8080
(увидишь PID, дальше можно понять, что это за процесс)
Остановить процесс (использовать осторожно)
— macOS/Linux: kill <PID>
— Windows: Stop-Process -Id <PID>
============================================================
9) Git минимум для QA (чтобы уверенно жить в задачах)
Git (или альтернатива SVN (но чаще все же GIT))- система управления версиями проекта - используется абсолютно во всех командах разработки / компаниях. Пользоваться базовыми командами и понимать принцип работы тестировщику ОБЯЗАТЕЛЬНО. У нас будет отдельный урок по GIT, здесь же рассмотрим самые частые команды.
База команд:
1) git status
Что делает: показывает текущее состояние твоей рабочей папки и индекса (staging area).
Ты увидишь:
— на какой ты ветке
— какие файлы изменены, но НЕ добавлены
— какие файлы уже “подготовлены” к коммиту (staged)
— есть ли неотправленные коммиты и т.п.
Разбор слов:
— git — запускаем Git
— status — “статус”
2) git add
Что делает: добавляет изменения в staging area (то есть “подготовить к коммиту”).
Примеры:
— git add file.txt (добавить конкретный файл)
— git add . (добавить все изменения в текущей папке и подпапках)
Разбор слов:
— add — “добавить (в индекс/стейджинг)”
Важно: git add НЕ отправляет изменения никуда и НЕ делает коммит. Это просто шаг “я выбираю, что войдёт в следующий коммит”.
3) git commit -m "сообщение"
Что делает: создаёт коммит — фиксирует подготовленные (staged) изменения в историю репозитория.
Разбор слов:
— commit — “зафиксировать изменения в историю”
— -m — message (сообщение коммита)
— "..." — текст сообщения (коротко: что сделано)
Пример:
git commit -m "Update checklist for release 1.2"
4) git pull origin <branch>
(ты написал “git pull origin”, но корректнее почти всегда указывать ветку)
Что делает: подтягивает изменения с удалённого репозитория и пытается сразу применить их к твоей текущей ветке (обычно это fetch + merge, иногда fetch + rebase — зависит от настроек).
Разбор слов:
— pull — “забрать и применить”
— origin — имя удалённого репозитория (remote), чаще всего это “основной” сервер (GitLab/GitHub)
— <branch> — имя ветки на сервере (например main, develop, feature/abc)
Пример:
git pull origin main
Замечание: если выполнить просто git pull origin без ветки — Git может ругнуться или повести себя не так, как ты ожидаешь (зависит от конфигурации). Для учебного текста лучше писать с веткой.
5) git push origin <branch>
Что делает: отправляет твои локальные коммиты в удалённый репозиторий (на сервер).
Разбор слов:
— push — “отправить”
— origin — имя удалённого репозитория
— <branch> — ветка, которую отправляем
Пример:
git push origin feature/abc
Если ты в нужной ветке, часто достаточно:
git push
Но в учебном материале безопаснее показывать явный вариант с origin и веткой.
Дополнительные команды, которые QA реально используют
Какая ветка / список веток
git branch
(покажет ветки, текущая ветка отмечена звёздочкой)
Переключиться на ветку
git switch feature/abc
или старый вариант:
git checkout feature/abc
Скачать обновления с сервера (без изменения твоей рабочей папки)
git fetch origin
(полезно, когда хочешь “просто обновить информацию”, не мерджить)
Посмотреть историю (коротко)
git log --oneline --decorate -n 20
Посмотреть, что поменялось в конкретном коммите
git show <hash>
Посмотреть изменения (diff)
git diff
или между ветками:
git diff main..feature/abc
Найти строку в репозитории (очень полезно)
git grep "some_text"
5 типовых ошибок новичка в терминале (и как их не ловить)
1) Путают, где они находятся
Очень частая ситуация: ты думаешь, что работаешь в папке проекта, а на самом деле ты в другой директории — и “файла нет”, “команда не работает”, “ничего не находится”.
Что делать: перед любыми действиями проверяй pwd, а потом ls/dir.
2) Проблемы с путями и пробелами
Путь с пробелами без кавычек почти гарантированно сломает команду.
Правило: если в пути есть пробелы — бери путь в кавычки:
cd "C:\Program Files"
(на macOS/Linux ровно то же самое).
3) Команды выглядят одинаково, но работают по-разному (особенно на Windows)
В PowerShell многие привычные команды типа ls, pwd — это алиасы, а curl иногда вообще оказывается алиасом Invoke-WebRequest. В итоге ты копируешь команду из гайда и получаешь “странный” результат.
Что делать:
— для curl в Windows чаще всего надёжнее писать curl.exe ...
— если сомневаешься, что за команда: Get-Command curl или Get-Command ls
4) Нет прав доступа (Permission denied)
На macOS/Linux это типично при работе с системными папками или файлами, на Windows — при доступе в защищённые директории.
Что делать: не пытайся сразу “лечить” это sudo/админом. Сначала убедись, что ты работаешь в своей папке (домашней/проектной), а не лезешь в системные каталоги.
5) Ожидают, что терминал “сам догадается”
Терминал очень буквальный: лишний символ, неправильные кавычки, другой слэш в пути — и команда уже другая.
Что делать: используй автодополнение (Tab), копируй пути аккуратно, и не стесняйся делать команды маленькими шагами: сначала pwd, потом ls, потом уже “сложная” команда.
Домашнее задание (лучше сделать, чем прочитать)
1) С помощью терминала создай папку “qa_terminal”, зайди в неё, создай файл log.txt и добавь туда 20 строк (вручную можно).
2) Найди в этом файле строку по слову “ERROR” (добавь 2–3 строки с ERROR специально).
3) Научись:
— показать последние 5 строк файла
— “следить” за файлом (tail -f / Get-Content -Wait)
4) Дерни любой публичный API через curl (например, /health любого сервиса) и посмотри статус-код.
Следите за новым разделом — уроки по тестированию. Он подойдёт тем, кто учится на QA с нуля, и тем, кто уже работает, но хочет систематизировать знания: тест-дизайн, API, автотесты, SQL/данные, CI/CD и практики командной разработки.
Подписывайтесь, добавляйте в закладки в браузере, чтобы ничего не пропустить: QA Helper - справочник тестировщика
