Essential Linux Commands Every Test Engineer Must Master

Why Linux is a Test Engineer’s Second Workbench

In API testing, automation, performance stress testing, and online troubleshooting, Linux command‑line skills are indispensable for viewing logs, monitoring services, and debugging environments.

1. Basic System Information (Must‑Know)

cat /etc/os-release

– shows the distribution (e.g., CentOS 7). uname -a – displays kernel version, hostname, and architecture.

Test scenario: verify the test environment meets requirements such as “CentOS 7.6+”.

CPU & memory usage: top – interactive real‑time view (press q to quit). htop – enhanced top (requires installation). free -h – shows total, used, and available memory in human‑readable format. cat /proc/cpuinfo – details CPU cores and model.

Interview tip: “During performance testing I monitor CPU usage with top; sustained >80 % indicates a bottleneck.”

Disk space: df -h – displays usage of each partition. du -sh /var/log – shows size of a specific directory.

Test scenario: after a stress test, check whether logs have filled the disk and caused service failures.

2. Process & Service Management (High Frequency)

ps -ef | grep java

– list all processes containing “java”. pgrep -f "app.jar" – directly returns the PID. kill -9 <PID> – forcefully terminate a process (use with caution). pkill -f "app.jar" – kill by process name.

Best practice: first send a graceful SIGTERM (default kill) and only use -9 if the process does not respond. netstat -tunlp | grep 8080 – list listening sockets (older tool). ss -tuln | grep 8080 – modern replacement.

Key flag meanings: -t: TCP -u: UDP -l: listening -n: numeric output (no name resolution) -p: show process PID (requires root)

3. Log Viewing & Analysis (Core Skill)

tail -f app.log

– follow the last 10 lines in real time. tail -n 100 -f app.log – start following from the last 100 lines. grep "ERROR" app.log – simple error search. grep -i "exception" app.log – case‑insensitive search. grep -A 3 -B 3 "Timeout" app.log – show 3 lines before and after each match. grep "ERROR" app.log | wc -l – count occurrences of “ERROR”.

Test scenario: after an automation failure, immediately grep ERROR to pinpoint whether the issue is a network timeout or a business‑logic error.

4. Network Diagnosis (Essential for API Testing)

ping api.test.com

– test ICMP reachability (many production environments block ping). telnet api.test.com 443 – test TCP port connectivity (more reliable).

Golden rule: “Ping failure does not equal service unavailability; a successful telnet confirms the port is reachable.” nslookup api.test.com or dig api.test.com – query DNS resolution.

Tip: if domain ping is slow but IP ping is fast, DNS resolution is the problem. tcpdump -i any -nn port 80 -w capture.pcap – capture HTTP traffic; open the resulting .pcap with Wireshark for analysis.

Use case: when an API returns an error without logs, packet capture can reveal request/response details.

5. File & Permission Operations

find / -name "*.log" 2>/dev/null

– search the entire filesystem for log files, ignoring permission errors. locate "*.log" – fast lookup (requires updated database). tar -czvf archive.tar.gz dir/ – create a compressed archive. tar -xzvf archive.tar.gz – extract an archive. tar -tzvf archive.tar.gz – list contents without extracting.

Test scenario: quickly unzip downloaded test data packages or archive logs. chmod 755 script.sh – owner read/write/execute, group/others read/execute. chmod +x script.sh – add execute permission. chown user:group file – change file owner and group.

Security principle: scripts must have +x to run; sensitive configuration files should be readable only by the owner.

6. Advanced Efficiency Tricks (Combined Commands)

grep "/api/order" nginx.access.log | wc -l

– count how many times a specific API endpoint was called.

grep "slow_query" mysql.log | awk '{print $NF, $0}' | sort -nr | head -10

– extract the ten most time‑consuming SQL statements. sed -i 's/old_token/new_token/g' config.yaml – batch replace text in a file (use a backup first).

Warning: -i modifies files in place; always back up before running.

7. Interview‑Ready Answer Template

When asked “What have you done with Linux?”, avoid vague answers. Example:

“In an API automation project I used tail -f to monitor logs in real time and grep ERROR to quickly locate failures; during performance testing I monitored CPU and disk with top and df -h, discovering a disk‑full issue caused by un‑rotated logs; I also wrote shell scripts to automatically clean test data, boosting team efficiency.”

8. Pitfall Guide – Commands to Use Carefully

Wrong: rm -rf /* – Never run in production; always ls first to confirm.

Wrong: killall java – May kill unintended Java processes; use pkill -f "your_app" instead.

Wrong: cat huge.log – Can freeze the terminal; prefer less or head/tail.

Conclusion

Linux is not just a list of commands; it is a toolbox for solving real problems. For test engineers, mastering these high‑frequency commands enables independent environment setup, rapid root‑cause analysis of automation failures, effective online incident response, and the ability to write robust automation scripts.