系统测试和验收测试是软件测试中两个重点且易被混淆的阶段。区别是测试立场和根本目标的不同：系统测试是开发者视角的证实过程，保证产品被正确创建；验收测试是用户视角的确定过程，保证创建了正确的产品。

证实和确定

系统测试 的重要是证实。追问：“我们是不是严格按照规格说明书（设计文档）正确地实现了所有功能？” 这是一个技术正确性的检查过程，不同于软件内部的正确性、完整性和质量属性。

验收测试 的重要是确定。追问：“我们创建的软件是不是真正解决了用户的业务问题，满足了他们在真实情形中的需求和期望？” 这是一个业务有效性的检验过程。

比喻建造一座桥梁。

系统测试 就像工程师团队对照设计蓝图，检查每一个焊接点是不是牢固、每一根钢筋的型号和位置是不是符合标准、材料的抗压强度是不是达标。关心的是“桥是不是被正确地建出来”。

验收测试 则就像市政府验收小组，组织各种车辆实际通行，考虑桥面是不是平整、车流承载能力是不是满足城市需求、紧急通道是不是可用。关心的是“这座桥是不是解决了交通问题，即这是不是是一座正确的桥”。

详细对比

系统测试：一般由组织内独立的测试团队或质量保证团队执行。他们代表开发组织的利益，以技术专家的身份，力求在软件交付给用户前发现所有缺陷。

验收测试：一般由最后用户、客户代表、业务分析师或产品经理来主导执行。在第三方测试情形中（如之前讨论的卓码软件测评），独立的第三方机构代表用户方的利益，提供客观公正的考虑。

范围和测试重点

系统测试：范围极其广泛和深入。是一个综合性的质量考虑，不仅包括功能性测试，更不同于非功能性需求：

性能测试：压力、负载、稳定性。

安全性测试：渗透、漏洞扫描。

兼容性测试：跨平台、跨浏览器、跨设备。

可靠性测试：长时间运行、容错和恢复。

安装/卸载测试。

验收测试：范围相对聚焦于业务作用。它主要证实软件是不是满足合同中规定的业务需求和用户情形，重点包括：

业务流程的端到端证实。

用户界面和易用性是不是符合业务操作习惯。

重点业务规则的准确性。

数据迁移的正确性（如果适用）。

标准

系统测试：主要根据系统/子系统设计规格说明书、软件需求规格说明书以及各类技术标准。测试用例的设计源于技术文档。

验收测试：主要根据用户需求说明书、业务合同、招标文件、以及法律/行业法规。

测试环境

系统测试：在高度仿真的测试环境中进行，该环境应尽可能模拟生产环境的架构，但允许使用测试数据、进行破坏性测试和性能压测。

验收测试：理想情况下应在准生产环境或实际的生产环境中进行，使用真实的或高度仿真的业务数据，以模拟用户真实操作。

测试类型和方法

系统测试：大量采用白盒和黑盒结合的方法。会使用自动化工具进行回归测试、性能压测、安全扫描等，追求测试的深度和自动化。

验收测试：主要采用黑盒测试，一般以用户验收测试（UAT）的形式，由真实用户执行手工的情形化测试，证实业务流的顺畅性。

时间迭代

系统测试：是开发过程的一部分，一般在集成测试之后、验收测试之前进行。在敏捷开发中，每个迭代都可能进行系统级回归测试。

验收测试：是项目交付前的最后一道正式测试步骤，一般在系统测试通过、软件功能已稳定的基础上进行。。

输出结果和目标

系统测试：输出详细的缺陷报告、性能测试报告、测试包括率分析等。目标是发现并修复缺陷，将软件提升到一个可交付的质量水平。

验收测试：输出最后的验收测试报告（如我们之前详细讨论的结构），并给出 “通过/不通过” 的结果。

缺陷方面

系统测试：发现的缺陷多为技术性缺陷，如功能错误、性能短板、安全漏洞、界面兼容性问题等。

验收测试：发现的缺陷多为业务性缺陷，如流程不符合实际工作、操作繁琐、计算结果和业务预期不符、报表格式不满足管理要求等。

实际项目中的注意事项

重叠和反馈：在正式验收测试中发现的重大业务缺陷，可能仍需退回开发团队进行修复，并触发新一轮的系统回归测试。

根据项目规模调整：在小型或敏捷项目中，两者的界限可能变得模糊，但仍应保持证实和确定的重要思想。

第三方测试的桥梁作用：专业的第三方检测机构（如有CMA/CNAS资质的实验室）所提供的验收测试服务，实质上是将严格的系统测试方法（尤其是非功能测试）和用户验收的视角相结合，出具具有法律和技术公信力的报告。

系统测试是面向开发过程的质量保证测试；验收测试是面向最后用户的质量决定测试。