QA must learn Linux command practical guide: Log analysis, server debugging, and performance monitoring all at once
A complete tutorial on essential Linux commands for QA engineers, covering actual test scenarios such as log analysis, server debugging, performance monitoring, file operations, etc., with command examples that can be directly applied.
Last Updated:2026-05-24
Table of Contents
1. QA Why should you learn Linux?
Most web and app backends run on Linux servers. When you encounter a 500 error, performance anomaly, or a bug that is difficult to reproduce during testing, if you can SSH into the server to check the log yourself, you don't need to open a ticket or wait for the backend to check it for you. This capability gap is very obvious in daily work.
-
Log Analysis: Check The Error Log Yourself And Locate The Root Cause Of The Bug In 30 Seconds
-
Environment Troubleshooting: Confirm Whether The Services In The Test Environment Are Running Normally And Whether The Settings Are Correct
-
Performance Monitoring: Real-Time Monitoring Of Cpu, Memory, And Disk Usage During Test Execution
-
File Operations: Find, View, And Compare Profiles And Data Files On The Server
-
Deployment Verification: After Deployment, Confirm That The New Version Is Online And The Service Has Been Restarted.
2. Connectivity and basic navigation
First you need to be able to connect to the server and move within it.
-
Ssh Connection: Ssh Username@Server-Ip → Connect To The Test Server. Usually Qa Will Get The Ssh Account Of The Test Environment
-
View Current Location: Pwd → Show Which Directory You Are Currently In
-
List Files: Ls -La → List All Files (Including Hidden Files), Display Permissions, Size, Modification Time
-
Switch Directories: Cd /Var/Log → Move To The Log Directory. Cd .. Go Back To The Previous Level, Cd ~ Go Home Directory
-
Check The Disk Space: Df -H → Confirm Whether The Disk Is Full (Full Disk Is A Common Cause Of Server Abnormalities)
Tip
- Press the Tab key to automatically complete the file name and path, saving a lot of typing time
- Press the up and down arrow keys to view historical instructions without having to re-enter each time.
3. Log analysis: QA’s most frequently used scenarios
Log analysis is what QA does most often using Linux. The following commands are arranged in order of frequency of use.
-
View Log In Real Time: Tail -F /Var/Log/App.Log → Display The Latest Log In Real Time. Open This Window During Testing, And You Can See The Backend Reaction While Operating.
-
Search For Errors: Grep 'Error' /Var/Log/App.Log → Find All Lines Containing Error. Grep -I 'Error' Is Not Case Sensitive
-
Search For A Specific Time: Grep '2026-05-24 14:' /Var/Log/App.Log → Find The Log For A Specific Time Period
-
Search The Context: Grep -B 5 -A 5 'Nullpointerexception' /Var/Log/App.Log → Find The Error And Display 5 Lines Before And After To Help Understand The Error Context
-
Count The Number Of Errors: Grep -C 'Error' /Var/Log/App.Log → Calculate How Many Times Error Occurs
-
Look At The Latest N Lines: Tail -100 /Var/Log/App.Log → Look At The Last 100 Lines Of Log
-
Combination Search: Grep 'Error' /Var/Log/App.Log | Grep 'Payment' → Find Error Related To Payment
Tip
- Before testing, execute tail -f log to enable real-time monitoring. Observe the Log output synchronously during operation to detect problems immediately.
- When reporting bugs, attach relevant Log fragments (after filtering with grep), developers can fix bugs much faster
4. Service status checking and debugging
When the test environment is unstable, first confirm whether the service is running normally.
-
Check The Service Status: Systemctl Status Nginx → Confirm Whether Nginx Is Running. Also Suitable For Other Services Such As Mysql, Redis
-
Check The Running Programs: Ps Aux | Grep Java → Find All Java-Related Programs And Confirm Whether The App Server Is Running
-
Check The Port Using: Netstat -Tlnp Or Ss -Tlnp → Confirm Whether The Port Monitored By The Service Is Correct (For Example, 8080, 3306)
-
Test Connection: Curl -I Http://Localhost:8080/Health → Test Whether The Api Responds Normally From Within The Server
-
Docker Container Status: Docker Ps → List All Running Containers. Docker Logs Container_Name → View Container Log
-
Restart The Service (Requires Permissions): Sudo Systemctl Restart App-Service → If There Is A Problem With The Test Environment, You Can Try To Restart It.
5. Performance monitoring: real-time observation during testing
When performing performance testing or stress testing, you need to monitor the server's resource usage at the same time.
-
Real-Time Resource Monitoring: Top Or Htop → Real-Time Display Of Cpu, Memory Usage And Resource Consumption Of Each Program. Htop Has A Friendlier Interface
-
Memory Usage: Free -H → Check The Total Memory, Used And Available Memory. -H Display In Human Readable Units
-
Cpu Information: Nproc → View The Number Of Cpu Cores. Uptime → View System Load
-
Disk I/O: Iostat → View Disk Read And Write Speed. If Disk I/O Is High, It May Cause The System To Slow Down
-
Network Traffic: Iftop Or Nethogs → Monitor Network Traffic In Real Time. Confirm Whether Bandwidth Is A Bottleneck During Stress Testing
-
View Large Files: Du -Sh /Var/Log/* | Sort -Rh | Head -10 → Find The Largest 10 Log Files, Which May Need To Be Cleaned
Tip
- During the stress test, open three terminal windows: one to run top to see the CPU/memory, one to run tail -f to see the Log, and one to execute the test command.
- If CPU usage exceeds 80% or memory usage exceeds 90% for a long time, flag it in the test report
6. File operations and comparisons
Common commands for finding and comparing files on the server.
-
Find Files: Find /Var/Log -Name '*.Log' -Mtime -1 → Find The Log Files Modified In The Last 1 Day
-
Search File Contents: Grep -R 'Database_Url' /Etc/App/ → Search The Entire Directory For Files Containing Specific Keywords
-
View The Archive: Cat Config.Yml → View The Entire Archive. Less Config.Yml → View Large Files In Pages (Press Q To Exit)
-
Compare Files: Diff Config_Old.Yml Config_New.Yml → Compare The Differences Between The Two Configuration Files To Confirm Whether The Settings Are Updated Correctly After Deployment
-
File Size: Ls -Lh /Var/Log/App.Log → Check The File Size. Wc -L App.Log → Count Lines
-
Compressed Log: Zgrep 'Error' /Var/Log/App.Log.Gz → Search The Compressed Log Directly Without Decompressing It First.
7. QA command combination techniques in daily work
The power of a single command is limited, and combination is the key to efficiency. Here are the most useful combos for QA.
-
Find All Errors Today And Count Them: Grep '2026-05-24' App.Log | Grep 'Error' | Awk '{Print $Nf}' | Sort | Uniq -C | Sort -Rn → Find Today'S Errors And Count Them By Type
-
Monitor Api Response Time: Tail -F Access.Log | Awk '{Print $Nf}' → Instantly Display The Response Time Of Each Request
-
Find The Apis With The Most Errors: Grep 'Http/1.1" 5' Access.Log | Awk '{Print $7}' | Sort | Uniq -C | Sort -Rn | Head -10 → Find The Api Endpoints That Return The Most 5Xx
-
Log Comparison Before And After Deployment: First Save The Number Of Log Lines Before Deployment Wc -L App.Log, And After Deployment Use Tail -N + The Number Of Old Lines App.Log To Only See The New Log
-
Quickly Determine Server Health: Uptime && Free -H && Df -H → Read The Three Major Indicators Of Load, Memory And Disk In One Line Of Command
8. Learning route: Get started in two weeks
Follow the steps below and you'll be comfortable working on a Linux server in two weeks.
-
Day 1-3: Ssh Connection + Cd/Ls/Pwd + Cat/Less/Tail → Able To Connect To The Server And View Files
-
Day 4-7: Grep + Tail -F + Ps + Docker Ps → Can Search Log And Check Service Status
-
Day 8-10: Top/Free/Df + Curl + Netstat → Can Monitor Resources And Test Connections
-
Day 11-14: Pipe (|) Combination + Find + Diff → Enables Advanced Search And Comparison
-
Practice Method: Every Time You Encounter A Scenario Where You Need To Check The Log Or Check The Environment, Force Yourself To Use Linux Commands Instead Of Asking The Backend To Help.
Tip
- Just practice in the Terminal of your local computer (the instructions are the same for Mac and Linux), there is no need to set up a special server
- Create your own "Common Command Notes" and write down the purpose and example of each command. You can check it anytime if you forget it.
Key Takeaways
- 1 QA who knows Linux can look at the Log to find the root cause of the bug by themselves, without waiting for the backend to help check.
- 2 This guide is classified according to actual QA work scenarios, and each instruction has specific usage scenarios.
- 3 From Log search to performance monitoring, covering 30+ Linux commands most commonly used by QA
- 4 Once you master these instructions, you will be significantly more professional in the eyes of your backend and DevOps teams.
Related Links
Related Quick Guides
AI automated testing tools complete comparison 2026: Testim, mabl, Katalon AI and other 6 major tool reviews
An in-depth comparison of the top 6 AI automated testing tools in 2026, covering the functions, prices, and applicable scenarios of Testim, mabl, Katalon AI, Applitools, Codium AI, and Playwright AI.
AI-assisted testing practice: 5 scenarios to double your testing efficiency
From test case generation to visual regression, we will teach you step by step how to introduce AI tools into daily QA work, with practical steps and tool recommendations.
GitHub Copilot practical guide to writing test scripts: QA uses AI to write Playwright and Selenium tests
Teach QA engineers step-by-step how to use GitHub Copilot to write Playwright and Selenium automated test scripts, including Prompt techniques, practical cases, common pitfalls, and best practices.
General Disclaimer
The information provided on this site is for reference only. We do not guarantee its completeness or accuracy. Users should determine the applicability of the information on their own.