下面所列对系统测试表述不正确的是

直接说结论：“系统测试必须在所有单元测试通过之后才能开始”——这个表述不正确。它把测试阶段硬生生切成了流水线，所列试表述好像必须等前一工序完全合格，对系下一工序才有资格动工。统测实际项目里，正确系统测试往往和单元测试、下面集成测试并行推进，所列试表述甚至在某些模块还没完全稳定时就已经开始搭建系统测试环境了。对系

我见过一个做智能门锁的统测团队。硬件组还在调试指纹模块的正确识别率，软件组已经用模拟器跑起了整机功能测试。下面他们管这叫“左移+右移混着来”。所列试表述系统测试关心的对系是整锁在真实场景下的响应——比如低温环境里指纹+密码+APP远程开锁会不会冲突，电池续航够不够。统测这些跟某个驱动函数的正确单元测试覆盖率没有先后依赖。硬要等所有单元测试100%通过再启动系统测试，项目周期至少拉长三周。所以那个“必须之后”的说法，从工程实践上看就是错的。

很多人混淆了系统测试和验收测试的边界。另一个常被误判的表述是：“系统测试只需要验证功能，性能和安全由专项测试负责。” 这句话听起来分工明确，实际漏洞很大。系统测试的定义里本来就包含非功能属性——可靠性、可维护性、甚至部分性能指标（比如响应时间是否满足需求规格）。你不可能把整机跑起来只点按钮看功能，却对内存泄漏、并发连接数崩掉视而不见。我参与过一个电商后台的系统测试，功能用例全绿，结果模拟50个用户同时下单时订单状态错乱。这算功能问题还是性能问题？其实都是系统测试该抓的。

❌ 不正确的表述 A：“系统测试的入口准则是所有代码冻结。” 代码冻结是版本管理动作，不是系统测试的前置条件。很多敏捷团队采用持续集成，系统测试每天跑，代码每天合。冻结通常发生在系统测试后期，为了出稳定报告。把冻结当入口，等于让测试等开发停手——那叫瀑布模型晚期，不是系统测试的本质。

❌ 不正确的表述 B：“系统测试只能由独立测试团队执行。” 独立团队能减少偏见，但没规定“只能”。开发人员交叉测试、运维参与稳定性验证、甚至用户代表做探索性系统测试，都是常见做法。我见过一个创业公司，后端开发自己写脚本模拟终端用户全流程，照样发现了关键的状态同步bug。谁执行不重要，覆盖系统级场景才重要。

❌ 不正确的表述 C：“系统测试通过后就不需要再做回归了。” 这简直是灾难。系统测试通过只代表当前版本在特定环境下符合需求。一旦修复缺陷、调整配置、或者打补丁，回归系统测试必须做。去年一个银行APP更新了证书，只跑了接口自动化，没重跑系统测试里的转账流程，结果用户转账时闪退——因为证书校验和UI线程冲突了。系统测试的回归成本高，但省掉它，代价更高。

那正确的系统测试表述该长什么样？它应该承认：系统测试可以尽早介入（比如用桩模块模拟未完成部分），可以和其他测试级别重叠，必须覆盖功能和非功能，必须包含回归，执行者可以多样。最关键的是——它针对的是整个系统与需求规格之间的差距，而不是某个函数或模块的内部逻辑。

如果你在考试或面试里看到“系统测试必须在集成测试之后”、“系统测试不检查代码内部结构所以不需要白盒方法”、“系统测试就是黑盒测试”这类话，留个心眼。黑盒是主要手段，但系统测试里也可以分析日志、监控调用链、甚至做故障注入——这些带着白盒视角。说“就是黑盒”太绝对了。

回到标题那个问题。下面所列对系统测试表述不正确的是——你心里现在应该有数了：凡是把系统测试描述成“必须等待”、“只能由谁做”、“只做功能”、“不用回归”、“纯黑盒”的，基本都不正确。系统测试更像一个持续校准整机行为的活动，而不是一个卡在时间轴末端的固定关卡。