软测-测开面试题集合（二、实战场景与思维拓展篇）
1. 电商支付场景的测试用例设计支付功能是电商平台的核心模块之一涉及用户资金安全测试时需要从多个维度进行全面覆盖。下面以支付宝扫码支付为例详细拆解测试点1.1 功能测试基础支付流程验证正常扫码支付流程生成二维码→用户扫码→输入金额→确认支付→返回结果支付金额边界值0.01元最小单位、单笔限额如5万元、单日累计限额支付结果同步支付成功后订单状态、账户余额、交易记录的实时更新异常场景覆盖# 模拟支付失败场景的测试代码示例 def test_payment_failure(): # 余额不足 simulate_balance_insufficient() assert payment_result 支付失败余额不足 # 重复支付 duplicate_payment() assert payment_result 该订单已支付 # 网络中断 simulate_network_disconnect() assert payment_result 网络异常请重试支付方式组合余额支付优惠券组合使用信用卡分期支付3/6/12期跨币种支付时的汇率计算1.2 安全测试风险操作防护连续5次输错支付密码触发账户锁定大额支付强制短信验证更换设备登录时的二次验证数据加密验证支付请求是否使用HTTPS传输敏感字段如卡号、CVV是否前端加密日志中不应记录完整银行卡信息1.3 性能测试压力测试指标场景预期指标实际结果100并发支付成功率99.9%99.95%500并发查询平均RT200ms150ms持续1小时稳定性测试无内存泄漏通过峰值处理能力模拟双11零点流量突增10倍支付系统自动扩容机制验证2. 社交平台消息推送的测试策略微信朋友圈点赞功能看似简单实则涉及复杂的系统交互测试时需要重点关注2.1 客户端测试UI交互验证点赞图标点击后的状态变化颜色/动画长按点赞的快捷表情选择功能点赞列表的展示规则最多显示10个头像数据一致性// Android端数据同步测试示例 Test public void testLikeSync() { // 设备A点赞 deviceA.likePost(postId); // 设备B验证 assertTrue(deviceB.checkLikeStatus(postId)); // 撤回验证 deviceA.unlikePost(postId); assertFalse(deviceB.checkLikeStatus(postId)); }2.2 服务端测试推送逻辑测试共同好友可见性规则验证深夜时段是否触发免打扰模式拉黑用户后的点赞屏蔽压力测试场景明星发帖后的万级点赞并发点赞数据分库分表策略验证缓存击穿防护机制如Bloom Filter3. 自动化测试框架技术选型3.1 Web自动化方案对比工具语言支持执行速度移动端支持学习曲线Selenium多语言中等需Appium平缓PlaywrightJS/Java/Python快原生支持较陡CypressJavaScript快有限低选型建议老项目维护Selenium POM模式新项目快速迭代Playwright纯前端团队Cypress3.2 接口自动化实践# 使用pytestrequests的接口测试示例 pytest.mark.parametrize(test_input,expected, [ (正常token, 200), (过期token, 401), (错误token, 403) ]) def test_auth_api(test_input, expected): headers {Authorization: fBearer {test_input}} response requests.get(API_ENDPOINT, headersheaders) assert response.status_code expected关键优化点使用pytest-xdist实现并行测试通过allure生成可视化报告接口契约测试OpenAPI Schema验证4. 性能测试的实战技巧4.1 电商秒杀场景测试测试策略基准测试单用户正常流程响应时间负载测试逐步增加用户至系统瓶颈压力测试超出设计容量20%的流量冲击典型问题排查商品超卖问题通过JMeter模拟并发下单缓存雪崩随机过期时间多级缓存支付卡单异步队列补偿机制4.2 性能监控体系搭建必备监控项系统层CPU/Memory/Disk IO中间件Redis命中率、MySQL慢查询应用层JVM GC次数、线程池状态报警阈值设置# Prometheus报警规则示例 ALERT HighErrorRate IF rate(http_requests_total{status~5..}[5m]) 0.1 FOR 10m LABELS { severitycritical }在实际项目中性能测试不是一次性工作需要建立持续的性能基准Performance Benchmark每次代码变更后自动运行对比。我曾遇到一个案例某次看似无害的日志级别调整导致系统吞吐量下降30%正是通过自动化性能回归发现的。
