Термінал і Linux для QA

Навіщо QA взагалі термінал, якщо є браузер, Postman і графічні клієнти?

Бо три речі, критичні для розслідування, живуть поза браузером. Логи застосунку лежать файлом на віддаленому сервері, куди мишкою не дотягнешся. CI-агент, на якому впав автотест, — це машина без екрана, і єдиний спосіб дізнатися, що там сталося, — прочитати її текстовий вивід. Керування процесами на стенді (перезапустити службу, звільнити зайнятий порт, перевірити, чи вона взагалі жива) теж робиться командами. Щойно робота торкається автоматизації чи CI, половина відповідей на питання «чому впало» дістається саме через CLI, тож базова термінальна грамотність стає робочим інструментом, а не факультативом.

Чим абсолютний шлях відрізняється від відносного і чому це породжує «локально працює, у пайплайні ні»?

Абсолютний шлях відлічується від кореня файлової системи (/var/log/app.log) і вказує на той самий файл звідки завгодно. Відносний (./app.log, ../fixtures) відлічується від поточної робочої директорії, тож те, на що він указує, залежить від того, звідки команду запустили. У цьому й пастка: на своїй машині ви стартуєте тест із кореня проєкту, і відносний шлях до фікстури збігається, а CI-джоб запускає команду з іншого каталогу — той самий шлях указує в порожнечу, звідси «файл не знайдено». Правило безпеки: у скриптах і конфігах, що поїдуть у CI, або спирайтеся на абсолютні шляхи, або явно фіксуйте робочу директорію, а не сподівайтеся на «звідки прийшло».

Як прочитати рядок прав у виводі ls -l, наприклад -rwxr-xr-x?

Перший символ — тип обʼєкта: - звичайний файл, d директорія, l символьне посилання. Далі йдуть три трійки по три біти — права для власника, для групи й для всіх решти. У кожній трійці r дозволяє читати, w писати, x виконувати (для директорії x означає право зайти всередину). У прикладі власник має повний набір rwx, а група й решта — r-x, тобто можуть читати й виконувати, але не змінювати. Для QA це не теорія: коли скрипт «не запускається» або тест «не бачить файл» на стенді, перший стовпчик ls -l часто показує причину швидше, ніж читання коду.

Що робить chmod 755 і навіщо це знати тестувальнику?

chmod змінює права доступу, а число 755 — компактний вісімковий запис: кожна цифра задає набір для однієї трійки (власник, група, решта), де читання важить 4, запис 2, виконання 1. Отже 7 (4+2+1) — повний набір власнику, а 5 (4+1) — читання й виконання групі та решті; 644 дає власнику читання-запис, іншим лише читання. Практична причина знати це: коли CI падає з Permission denied на скрипті, майже завжди бракує біта виконання, і chmod +x (чи 755) лікує це за секунду. Так само доступ до тестового файлу на стенді впирається в права й власника, а не в логіку тесту.

Як подивитися логи застосунку на віддаленому сервері?

Спершу зайти на сервер по SSH (ssh qa@staging...), а далі працювати з логом трьома командами залежно від задачі. tail -f app.log стежить за файлом наживо — нові рядки зʼявляються самі, ідеально під час відтворення бага. less app.log відкриває навіть гігантський файл миттєво, бо не тримає його весь у памʼяті, і дає пошук усередині. grep фільтрує потрібне за шаблоном чи ідентифікатором запиту. Сильна відповідь додає, що лог не завжди простий файл: під systemd його читають командою journalctl -u служба -f, а лог контейнера — docker logs -f, але граматика та сама — хвіст, стеження наживо, фільтр.

Чим tail -f цінний саме під час відтворення бага?

tail -f (follow) не просто показує кінець файлу, а лишається відкритим і домальовує кожен новий рядок, щойно застосунок його записав. Це дає точну звʼязку «дія в застосунку → реакція сервера»: ви запускаєте стеження за логом, робите крок у продукті й одразу бачите, що бекенд написав саме в цю мить. Без цього довелося б раз по раз перевідкривати файл і губити контекст. Вихід зі стеження — Ctrl+C. На проді той самий прийом працює через journalctl -f чи docker logs -f.

Навіщо grep прапорці -i, -n, -v та -C?

Це чотири щоденні модифікатори пошуку в логах. -i робить пошук нечутливим до регістру, тож error, Error і ERROR ловляться разом. -n додає до кожного збігу номер рядка — зручно, щоб потім стрибнути туди в редакторі чи less. -v інвертує умову й показує все, КРІМ збігів, — так відсіюють шум на кшталт рядків healthcheck. -C 3 друкує сам збіг плюс по три рядки контексту навколо, і це часто важливіше за саму помилку: стек виклику, вхідні дані й наступна дія розкривають причину краще, ніж один рядок винятку.

Що таке пайп (|) і чим він відрізняється від перенаправлення у файл?

Пайп зʼєднує дві команди: бере стандартний вивід (stdout) лівої й подає його на стандартний вхід (stdin) правої, тож ланцюжок з grep і wc -l рахує рядки з помилками, не створюючи проміжного файлу. Перенаправлення (>, >>) натомість спрямовує потік не в іншу команду, а у файл: > out.txt перезаписує, >> out.txt дописує в кінець. Різниця по суті: пайп передає дані між процесами в памʼяті, перенаправлення зберігає їх на диск. Комбінуючи їх, з простих утиліт складають точковий інструмент — наприклад, витягти всі події одного запиту за наскрізним ідентифікатором з мільйона рядків.

Що означає 2>&1 і чому цей запис постійно трапляється в CI-скриптах?

Кожна програма має два вихідні потоки: stdout (номер 1) для звичайного виводу й stderr (номер 2) для помилок. Запис 2>&1 означає «спрямуй потік 2 туди ж, куди зараз іде потік 1», тобто злий помилки з основним виводом в одне місце. Це потрібно, бо за замовчуванням вони окремі, і якщо лог збирає лише stdout, повідомлення про помилку зі stderr просто зникне з журналу. У CI це рятує від загадки «в логах чисто, а щось явно пішло не так»: зібравши обидва потоки в один файл, ви бачите повну картину. Важливий нюанс — перенаправлення читаються зліва направо, тому 2>&1 ставлять після того, як уже задали, куди йде потік 1.

Джоб у CI «зелений», але в логах видно помилку. Як таке можливо?

Бо пайплайн судить про успіх не за текстом логів, а за кодом виходу останньої команди: 0 — успіх, будь-що інше — провал. Програма могла написати повідомлення про помилку в stderr й усе одно завершитися з кодом 0 — тоді джоб бачить нуль і фарбує крок зеленим, хоча всередині щось зламалося. Друга частина тієї ж пастки — потоки: помилка пішла в stderr, а збирали лише stdout, тож у збереженому лозі її взагалі немає. Лікування подвійне: перевіряти реальний код виходу ($?) і зводити обидва потоки разом через 2>&1, а не довіряти самому зеленому кружечку.

Чим kill відрізняється від kill -9?

kill за замовчуванням не «вбиває», а надсилає процесу сигнал SIGTERM (номер 15) — ввічливе прохання завершитися, яке програма може перехопити, щоб коректно закритися: дописати файли, звільнити ресурси, закрити зʼєднання. kill -9 шле SIGKILL, який виконує вже сама операційна система: процес не має шансу ні перехопити його, ні прибрати за собою, тому дані можуть лишитися недописаними. Правильний порядок — спершу мʼяко SIGTERM, і лише якщо процес не реагує, застосовувати жорсткий SIGKILL. Звичка одразу бити все kill -9 небезпечна тим, що маскує реальну проблему: якщо застосунок не вимикається чисто по SIGTERM, це часто справжній баг, який варто завести, а не глушити.

Як знайти й прибрати завислий процес, що тримає порт?

Симптом упізнаваний: новий інстанс сервера не піднімається, бо порт зайнятий, — його не звільнив попередній прогін. Спершу треба знайти винуватця: ps aux із фільтром за назвою покаже процеси і їхні номери (PID), а точніше «хто сидить на порту» дадуть lsof -i :3000 або ss -ltnp. Знайшовши PID, звільняють порт командою kill PID, і лише якщо процес не реагує — kill -9. Для QA це типова причина флаку в локальних і CI-прогонах: тест стартує сервер, падає, не прибирає за собою, і наступний запуск валиться вже на піднятті. Надійне прибирання (teardown), що гарантовано гасить процес, лікує це в корені.

Як швидко перевірити, що API живий, без Postman?

Через curl — це «браузер без браузера», який робить HTTP-запит і показує відповідь прямо в терміналі. Базовий curl https://api.../health віддасть тіло; -i додасть до виводу заголовки й статус-рядок; -I попросить лише заголовки (метод HEAD); -v покаже весь діалог — і запит, і відповідь — що безцінно, коли треба зрозуміти, які саме заголовки полетіли. Для запису й авторизації додають метод і дані: -X POST разом із -H для заголовка типу вмісту й -d для тіла. А для смоук-перевірки в CI ідеальна звʼязка -o /dev/null -s -w '%{http_code}' — вона викидає тіло, глушить прогрес і лишає рівно один рядок із кодом статусу: чи відповідає стенд узагалі.

Автотест на API впав. Як через термінал зрозуміти, тест винен чи бекенд?

Найшвидший спосіб — повторити той самий запит руками через curl і подивитися сиру відповідь, поки тестовий фреймворк ще не додав своєї інтерпретації. Якщо валідний запит curl-ом відтворює ту саму помилку — підозра на бекенд, і це вже доказ, а не здогад. Якщо ж curl повертає нормальну відповідь, а падає лише тест, зміщуємося на тест: не підставилася змінна середовища, протух токен, крива фікстура або не те середовище. Другий крок — заглянути в лог сервера через SSH і grep за ідентифікатором того запиту: помилка 5xx майже завжди лишає стектрейс, який прямо показує, де впало. Дисципліна тут головніша за команди: не називати причину, поки під нею немає відтворення чи стектрейсу.

Що таке SSH і навіщо пара ключів замість пароля?

SSH (Secure Shell) — це зашифрований канал до віддаленої машини, який дає термінал на ній так, ніби ви фізично за нею сидите; типовий сценарій QA — зайти на стенд, знайти лог служби й стежити за ним, поки відтворюєш баг. Автентифікуватися можна паролем, але на практиці використовують пару ключів: приватний ключ лежить лише у вас (~/.ssh/id_ed25519), публічний — на сервері. Сервер криптографічно перевіряє, що ви володієте приватним ключем, і пускає без пароля — це і зручніше, і безпечніше, бо пароль не літає мережею й не витікає. Приватний ключ — секрет рівня пароля: його не комітять у репозиторій і не пересилають месенджером. Ті самі ключі й механізми копіювання артефактів працюють і всередині CI, коли пайплайн деплоїть код чи забирає результати прогону.

Як забрати лог або артефакт зі стенду до себе на машину?

Командою scp (secure copy) — вона копіює файли тим самим захищеним SSH-каналом, в обидва боки. Щоб забрати файл із сервера, джерелом указують віддалений шлях, а призначенням локальний: scp qa@staging:/var/log/app.log ./. Щоб залити на стенд — навпаки: scp report.zip qa@staging:/tmp/. Прапорець -r копіює цілу директорію рекурсивно (наприклад, теку фікстур). Це щоденна операція AQA — стягнути лог чи артефакт зі стенду, щоб спокійно розібрати локально, а не длубатися в ньому через вузький канал термінала на самому сервері.

Що таке PATH і чому виникає command not found, хоча програма встановлена?

PATH — це змінна середовища зі списком директорій через двокрапку, у яких оболонка шукає виконуваний файл, коли ви вводите node, git чи npx. Оболонка перебирає ці директорії зліва направо й запускає перший знайдений збіг, а якщо каталогу програми в списку немає — відповідає command not found, навіть коли файл фізично лежить на диску. Тобто помилка частіше означає не «програми немає», а «оболонка не знає, де її шукати». Розкрити правду за секунду допомагають which node (покаже, який саме файл запуститься й звідки) та echo $PATH (весь список пошуку). Це цілий клас помилок CI: інструмент установлено в нестандартне місце, а його директорію забули додати в PATH.

Навіщо змінні середовища в автотестах?

Щоб конфігурувати тести під різні середовища, не вшиваючи значень у код: базовий URL стенду, токени доступу, рівень логування задаються ззовні й читаються з process.env. Саме так один і той самий набір тестів переїжджає між локаллю, staging і CI — змінюється лише BASE_URL, а код лишається тим самим. Постійні змінні прописують у ~/.bashrc чи ~/.zshrc, а секрети проєкту зазвичай кладуть у файл .env і підвантажують бібліотекою dotenv — сам .env при цьому не комітять. Сильна відповідь підкреслює саме гігієну секретів: токени не в коді й не в репозиторії, а в змінних оточення й секрет-сторі CI.

Чому змінна, задана всередині запущеної програми, «не протікає» назад у вашу оболонку?

Через однобічне успадкування: оболонка передає свої експортовані змінні всім процесам, які запускає (дочірнім), але зворотного каналу немає — дочірній процес не може змінити оточення батьківського. Тому export BASE_URL=... у скрипті бачать команди всередині цього скрипта, а от змінна, яку встановила вже запущена програма, залишиться в її власному процесі й зникне разом із ним. Звідси дві типові пастки: без export змінну не побачать навіть дочірні процеси (вона лишиться локальною для оболонки), а в новій сесії термінала тимчасово задані змінні просто відсутні. Практичний наслідок — «скрипт не бачить токен» часто означає не баг, а те, що значення задали в одній оболонці, а команда виконується в іншому процесі, куди воно не долетіло.

CI падає з Permission denied на скрипті. Де шукати причину?

Не в коді скрипта, а в його правах і власнику — це класичний випадок «виглядає як баг, а насправді метадані файлу». Найчастіша причина — забутий біт виконання: файл скопіювали чи згенерували без права x, і оболонка відмовляється його запускати; лікує chmod +x скрипт (чи 755). Друга причина — файл належить іншому користувачеві або групі, ніж той, під яким працює джоб, і в поточного просто немає доступу; тут дивляться колонки власника та групи у ls -l. Тобто діагностика починається з ls -l, а не з читання логіки: перший стовпчик прав і колонки власника/групи зазвичай показують проблему одразу.

Три кейси, де термінал вирішує, знайдете ви причину за пʼять хвилин чи полюватимете на примару півдня: наскрізне розслідування нічного падіння API-тесту (SSH на стенд, стеження за логом, повтор запиту curl-ом), розбір «джоб зелений, а фіча зламана» через потоки й код виходу, і конфігурація Playwright через змінні середовища з типовою пасткою command not found у CI.

Кейс 1. Розслідування «нічний API-тест впав» через термінал

Уранці в CI червоний один тест на створення замовлення: expected 201, got 500. Локально він зелений. Питання не «де в коді баг», а «на чиєму боці проблема» — і весь маршрут проходиться в терміналі, не відкриваючи застосунок.

Крок 1 — зайти на стенд і почати стежити за логом служби ще до відтворення:

ssh qa@staging.example.com
tail -f /var/log/orders/app.log

Крок 2 — у сусідньому терміналі повторити рівно той запит, що робить тест, і подивитися сиру відповідь:

curl -i -X POST https://staging.example.com/api/orders \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"productId":42,"qty":1}'

Якщо curl валідним запитом теж повертає 500 — це вже не здогад, а відтворення на боці бекенда. Крок 3 — витягти саме цей інцидент із логу за наскрізним ідентифікатором, який сервер повернув у заголовку відповіді, разом із контекстом навколо помилки:

grep -C 5 "correlation-id: 7f3a9c" /var/log/orders/app.log

Стектрейс у цих рядках прямо показує рядок коду, що впав, — наприклад, звернення до неіснуючого поля в тілі. Це і є доказ замість «здається, баг бекенда».

Куди веде кожен результат:

Дисципліна кейсу: не називати винного, поки під висновком немає відтворення curl-ом або стектрейсу з логу. «Схоже на бекенд, стектрейс указує на контролер замовлень» коштує рівно стільки, скільки під ним доказів.

Кейс 2. «Джоб зелений, а фіча зламана»: потоки й код виходу

Крок збірки в CI позначено зеленим, але користувачі скаржаться, що дані не мігрували. У логах джоба — жодної помилки. Розгадка в тому, що пайплайн судить про успіх за кодом виходу, а помилка пішла в інший потік і не потрапила ні в лог, ні в код.

Спрощений скрипт кроку виглядав так:

node migrate.js > migration.log
echo "Done"

migrate.js написав помилку у stderr, а > migration.log перехопив лише stdout, тож у файлі порожньо. Гірше — код виходу кроку визначає остання команда echo, яка завжди успішна, тому джоб бачить 0 і фарбує крок зеленим. Перевірити реальний код виходу можна одразу після команди:

node migrate.js > migration.log
echo "exit code = $?"   # надрукує ненульовий код, якщо міграція впала

Правильна версія збирає обидва потоки в один файл і не ковтає код виходу проміжним echo:

set -e                              # обірвати крок на першій же помилці
node migrate.js > migration.log 2>&1  # stdout і stderr в один лог

Що дивитися і чому:

• 2>&1 без нього помилки невидимі. stdout і stderr — різні потоки; зібравши лише stdout, ви втрачаєте саме те, заради чого читаєте лог.
• Код виходу — джерело правди про успіх, не текст логу. $? після команди чи set -e у скрипті не дають «зеленому» брехати; фінальний echo/|| true мовчки ховає провал.
• /dev/null глушить свідомо, а не випадково. Викидати вивід у «нікуди» доречно для шуму, але якщо туди ж полетіла помилка — джоб знову збреше про успіх.

Кейс 3. Playwright: конфіг через змінні середовища і command not found у CI

Автотести мають ганятися по локалі, staging і CI без правок коду — це роблять змінними середовища, які тест читає з process.env. Значення за замовчуванням страхує локальний запуск:

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  use: {
    baseURL: process.env.BASE_URL ?? 'http://localhost:3000',
  },
});

Локально URL задають на сесію (значення видно командам, які ця оболонка запускає далі), а секрети тримають у .env, який не комітять:

export BASE_URL=https://staging.example.com
npx playwright test

Типова пастка №1 — «скрипт не бачить змінну». Якщо BASE_URL задали без export або в іншому вікні термінала, дочірній процес тесту її не успадкує, і конфіг тихо візьме локальний дефолт замість стенду. Швидка перевірка, що змінна реально в оточенні:

printenv BASE_URL   # порожньо = змінну не експортовано або сесія інша

Типова пастка №2 — npx: command not found у CI, хоча локально все працює. Причина майже завжди не у відсутності Node, а в PATH: директорії з npx немає у списку пошуку оболонки того джоба. Діагностика — два рядки:

which npx      # порожньо = виконуваного файлу немає в PATH
echo $PATH     # подивитися, які директорії оболонка взагалі переглядає

Що дивитися і чому:

• process.env + дефолт — контракт переносимості тесту. Один код, різні середовища; забутий дефолт валить локальний прогін, а не тільки CI.
• export і сесія вирішують видимість змінної. Змінна успадковується вниз, у дочірні процеси, але не назад; задане в одному вікні не існує в іншому.
• command not found — це PATH, а не «немає програми». which і echo $PATH за секунду відрізняють «не встановлено» від «встановлено, але оболонка не знаходить».

Bash: навігація, файли, права

• Знаю різницю між абсолютним (/var/log/app.log) і відносним (./app.log) шляхом і чому відносний ламає CI-джоби, коли команду запустили з іншого каталогу.
• Памʼятаю, що rm видаляє без кошика й без відкату, тож rm -rf на спільному стенді небезпечний так само, як DELETE без WHERE.
• Читаю перший стовпчик ls -l: тип (- файл, d директорія, l посилання) плюс три трійки rwx для власника, групи й решти.
• Розумію вісімкову нотацію (r=4, w=2, x=1: 755=rwx r-x r-x, 644=rw- r-- r--) і що Permission denied у CI майже завжди — забутий біт x (chmod +x) чи чужий власник, а не баг коду.

Процеси і сигнали

• Розумію, що kill не «вбиває», а шле сигнал: SIGTERM (15) ввічливо просить завершитися, SIGKILL (9, kill -9) вбиває примусово й без прибирання; порядок — спершу TERM, і лише якщо процес не реагує — KILL.
• Можу знайти й прибити завислий процес, що тримає порт: PID через ps aux (чи lsof -i :порт) і звільнити порт командою kill.
• Памʼятаю, що Ctrl+C — це сигнал SIGINT (перервати чисто), а Ctrl+Z — призупинення, а не завершення.

Потоки, пайпи, перенаправлення

• Розрізняю три стандартні потоки — stdin, stdout (1) і stderr (2) — і можу пояснити 2>&1 («злий stderr туди ж, куди stdout») та чому без цього повідомлення про помилку зникає зі зібраного логу.
• Знаю різницю > (перезаписати файл) vs >> (дописати в кінець) і що /dev/null — це «чорна діра», куди викидають зайвий вивід.
• Розумію, чому джоб буває «зелений» з помилкою всередині: код виходу 0 плюс помилка, що пішла в stderr, а не в код виходу.

Логи: tail, grep, less

• Знаю, коли що: tail -f для стеження наживо, less для гігантських файлів, grep для фільтра за шаблоном.
• Володію грепом (-i, -n, -v, -C, -r) і можу витягти всі події одного запиту, грепнувши лог за наскрізним ідентифікатором (correlation id).
• Розумію, що логи можуть бути не файлом: journalctl -u служба -f під systemd, docker logs -f у контейнері — граматика та сама.

curl

• Можу за секунди перевірити ендпоінт: curl -i (заголовки з тілом), -I (лише заголовки, HEAD), -v (весь діалог); POST — метод -X, заголовок -H, тіло -d.
• Памʼятаю смоук-звʼязку для CI: -o /dev/null -s -w '%{http_code}' віддає рівно код статусу стенду.
• Розумію, що curl без -L не піде за редіректом (на відміну від браузера), і що повторити запит curl-ом — найшвидший спосіб відділити баг тесту від бага бекенда.

ssh і scp

• Розумію, що SSH дає термінал на віддаленій машині, а пара ключів (приватний у себе, публічний на сервері) безпечніша й зручніша за пароль; приватний ключ — секрет рівня пароля, його не комітять і не пересилають.
• Можу копіювати файли обома напрямками через scp (на стенд і зі стенду), а цілу директорію — через scp -r.

Змінні середовища і PATH

• Розумію, що змінні успадковуються дочірніми процесами, але не течуть назад у батьківську оболонку (тому без export чи в новій сесії змінної «немає»), а тести читають конфіг із process.env; секрети кладуть у .env, який не комітять.
• Можу пояснити, що таке PATH і чому буває command not found при встановленій програмі; перевіряю через which і echo $PATH.