软件测试课程设计报告

测试用例里有一条永远过不去：登录按钮点击后，软件响应时间从200毫秒飙到3秒。测试我盯着监控曲线看了半小时，课程最后发现是设计隔壁组的接口把线程池占满了。这不是报告功能缺陷，这是软件资源竞争，但用户只会觉得“系统卡死了”。测试课程设计做到第四周，课程我最大的设计收获就是——软件测试不是找茬，是报告找系统在真实环境里的生存缝隙。

我们小组选了校园二手交易平台做被测对象。软件需求文档写得很漂亮，测试页面原型也精致。课程但真正跑起性能测试时，设计问题全冒出来了。报告比如并发抢购功能，文档里写着“支持500人同时操作”，可实际压测到200个虚拟用户时，数据库连接池就报错了。开发说“你们测试环境配置不对”，我们翻出生产环境的配置文件对比，发现连接池上限确实写的是500，但中间件默认超时时间只有3秒——200个请求排队，后面300个全超时。这个bug不是代码逻辑错，是参数配置和文档描述不一致。

后来我们改用真实浏览器录制脚本，而不是纯靠JMeter模拟。录了一个学生发布闲置物品的全流程：上传图片、填描述、选价格区间、提交审核。录制过程中发现，图片上传组件会在前端压缩图片，但压缩算法有问题，超过2MB的图会直接丢失EXIF信息。这个细节需求文档完全没提。我拿着放大镜看测试报告里的截图，发现上传后的图片在详情页显示时，地理位置标签是空的。用户可能根本不会注意这个，但如果是卖数码产品，买家会怀疑照片拍摄时间。

最折腾的是兼容性测试。我们实验室的电脑全是Chrome，但校园网用户里还有不少用IE11的老笔记本。用Selenium跑IE时，页面布局全乱，日期选择器弹不出来。我们试了各种hack，最后发现是前端框架的CSS Grid在IE下不支持。开发改了两行代码，用Flexbox替代，问题解决。这个案例让我意识到，测试不能只看主流环境，要回到真实用户画像里去。

报告写到后半段，我翻出之前所有测试数据，发现一个规律：性能瓶颈往往不在代码逻辑，而在资源调度。比如文件上传并发测试时，Tomcat默认的maxThreads是200，但连接器默认的acceptCount是100，超出的请求直接拒绝。这个参数在官方文档里写得清清楚楚，可没做过压力测试根本不会去查。我把这个发现写进缺陷报告，建议开发把acceptCount调到300，重测后吞吐量提升了40%。

课程设计结束那天，我们提交了47个有效缺陷，其中只有12个是功能错误，其余全是性能、兼容性、配置类问题。我把这些案例按“触发条件-现象-根因-修复建议”整理成表格，发现真正难测的不是步骤，而是那些需要跨模块联调才能暴露的隐患。比如支付回调偶发超时，单测永远测不出来，必须模拟断网、延迟、服务器重启等异常场景。我们写了个故障注入脚本，随机kill掉支付服务的线程，结果真的复现了三次订单状态不一致的问题。

这份报告没有标准答案，每个测试用例背后都是对系统行为的追问。你问测试的意义是什么？我现在的理解是：它让开发团队在发布前多问自己一句——“如果用户真的这么操作，系统会不会崩？”就这一句话，能省下无数个凌晨三点的紧急修复。