Master Performance Testing: Key Interview Questions & 12306 Crash Lessons

This article compiles essential performance testing interview questions, outlines a complete testing process with metrics and types, analyzes the 12306 ticketing system crash causes—including overload, bugs, security and network issues—and offers practical mitigation strategies for engineers.

FunTester
FunTester
FunTester
Master Performance Testing: Key Interview Questions & 12306 Crash Lessons

Performance Testing Interview Questions

During the peak hiring season, many companies ask candidates about performance testing. The core questions are collected and can be answered with a unified approach, covering test content, types, metrics, and expected results.

Complete Performance Testing Process

1. Test Content

The test should address six aspects:

Subsystems involved

Main functional modules

High‑traffic features

Complex business logic

Data‑intensive functions

Special scenarios

2. Test Types

Two major categories are used:

Backend server testing (JMeter) : includes concurrency tests (benchmark, load, stress, stability) and data‑processing capacity tests.

Client‑side testing (adb, solopi, monkey) : focuses on mobile performance.

3. Test Metrics and Expected Results

Backend metrics :

Concurrency: project‑specific target, no universal standard.

Response time: follow 1‑3‑5 s or 2‑5‑8 s rule.

Throughput: apply the 80/20 principle.

Transaction success rate: generally >95 % (payment >99 %).

Resource monitoring: CPU, memory, network < 80 %; disk < 90 %.

Client metrics :

Cold/hot start time: 2‑3‑5 s.

FPS: ~60 fps, each frame < 16 ms.

GPU: limit over‑draw to 2×, red‑area ≤ ¼ screen.

Package size: ~36 MB.

CPU usage: idle 0 %, normal use ≤ 30 %, high load ≤ 75 %.

Power consumption: ≤ 10 MB/h.

Network traffic: ≤ 10 MB.

Page transition: 3‑5‑8 s rule.

Stability: monkey + solopi within expectations.

These metrics are industry‑wide guidelines and can be adjusted per project.

12306 System Crash Analysis

The 12306 ticketing platform crashed during the National Day ticket sale due to sudden massive traffic and third‑party scripts.

1. Server Overload

High concurrent requests overwhelmed the backend; solutions include distributed architecture, load balancing, rate limiting, and caching to improve scalability and response time.

2. Code Bugs

Logical errors, unhandled exceptions, and memory leaks can also cause crashes.

3. Security Issues

Unauthorized scripts exploit the system; mitigation involves captchas, IP restrictions, and blocking malicious scripts.

4. Network Problems

Network congestion during peak traffic leads to access failures; remedies include load balancers, WAN optimization, SD‑WAN, and virtual port channels.

Key Takeaways

Performance testing must simulate real‑world scenarios, such as third‑party script traffic, to expose hidden issues before release. Test engineers should continuously learn new tools, understand user behavior, and design realistic load, stress, and stability tests to ensure software reliability.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

software reliabilityPerformance TestingLoad TestingSecuritynetwork optimizationinterview-questions12306 crash
FunTester
Written by

FunTester

10k followers, 1k articles | completely useless

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.