系统测试到底在测什么
很多人以为系统测试就是点点页面，看看有没有报错。其实远不止这样。系统测试的核心任务，是验证整个软件系统是否符合需求，能不能在真实环境中稳定运行。它关注的是“整体”，而不是某个功能模块。
功能验证：确保系统按预期工作
最基础的一环是检查所有功能是否正常。比如你开发了一个电商系统，用户从浏览商品、加入购物车、下单支付，到查看订单状态，这一整条流程都得走通。测试人员会模拟真实用户的操作路径，确认每个环节没有逻辑错误或数据丢失。
举个例子，用户提交订单后，库存应该自动减一。如果没减，或者减错了，这就是功能问题。这类测试通常基于需求文档一条条核对，不能遗漏。
集成测试：看各个部分能不能协同
系统往往由多个模块组成，比如前端、后端、数据库、第三方支付接口。单独看每个部分都没问题，但拼在一起就可能出岔子。系统测试要发现的就是这种“组合故障”。
比如调用支付宝支付成功后，系统要更新订单状态并发送通知。如果通知没发出去，可能是接口回调处理有问题，也可能是消息队列没接上。这时候就得排查整个链路。
性能测试：高负载下还能不能扛住
一个系统平时用着没问题，但到了促销活动，几百人同时下单就卡死，这显然不行。性能测试就是要模拟大并发场景，观察系统的响应时间、吞吐量和资源占用情况。
常见的做法是用工具模拟大量用户请求，比如模拟1000人同时登录。如果响应时间超过3秒，或者服务器CPU飙到90%以上，就需要优化。
安全性检查：别让漏洞开门迎贼
系统上线前必须检查常见安全风险。比如用户能不能通过修改URL参数越权访问他人数据？表单提交有没有做过滤，防止SQL注入或XSS攻击？密码是不是加密存储？这些都得一项项验证。
有时候测试人员会尝试用一些已知的攻击手法去“试探”系统，就像体检时医生故意给你打一针看免疫反应。
兼容性测试：在不同环境下都能跑
用户的设备五花八门，有人用Chrome最新版，有人还在用IE11；有人用安卓手机，有人用苹果平板。系统测试要覆盖主流浏览器、操作系统和屏幕尺寸，确保界面不乱、功能不崩。
比如某个按钮在Mac的Safari里点不动，在Windows的Edge里却正常，这就是典型的兼容性问题，必须修复。
回归测试：改完bug别引发新问题
开发修了一个bug，结果把另一个功能搞坏了，这种情况太常见了。每次代码有变动，都要重新跑一遍关键路径的测试用例，确保原有功能没被影响。这部分工作量不小，但必不可少。
有些团队会用自动化脚本做回归测试，比如每天晚上自动执行一轮核心流程检测，第二天早上看报告就行。
环境部署验证：别在上线时掉链子
测试不仅要关心“功能对不对”，还得关心“能不能装上去”。系统测试阶段也会验证部署脚本、配置文件、数据库迁移脚本是否能在目标环境顺利执行。
比如预发布环境装完系统后，服务起不来，查了半天发现是配置文件少写了一行端口号。这种低级错误最容易在上线前最后一刻暴露。