什么是系统测试？
假设您正在显微镜下观察一个软件系统：最初以最高倍率聚焦于单元。这是软件系统的基本构建模块。随后视野逐渐扩大至下一放大级别——由独立单元组成的模块。最终完全缩小视野后，便抵达系统层级。在此放大级别下，您能观察系统内所有内容，以及模块构建的各组件如何协同工作。
从某些方面看，系统测试类似于这种微观观察——但存在关键差异。系统测试属于黑盒测试形式，这意味着测试人员关注的重点并非系统组件的内部结构，而是系统的整体功能。从这种“通过/未通过”的视角出发，系统行为仅在与系统性能相关时才值得关注。（白盒测试则能更清晰地展现系统内部组件的特性。）
系统测试通常涉及对多个独立软件系统的分析，这些系统在特定软件系统中可能协同运行，也可能独立运作。
不妨回想航天发射前的倒计时场景。虽然大家都记得点火升空前的戏剧性十步倒计时，却鲜有人注意到飞行主管对各部门的逐项检查，以及各部门负责人依次回应“就绪”的肯定答复。在典型航天发射中，任务指挥部会逐一征询各部门主管关于计划操作、任务安全、运载系统、预期天气状况等众多事项的意见。每个部门都会接受问询，各部门主管依次作出响应。
类似地，系统测试可视为新软件系统发布前的最终检查清单。此时所有已知软件缺陷的最后一轮清理工作已完成。正如早期航天先驱开创的历史性检查清单，最终取决于系统测试中每个“部门”的确认就绪信号。
每个检查项都围绕系统功能展开：
- 每个组件是否按预期运行？
- 各组件之间是否协调有序？
在讨论系统测试时，我们自然会触及依赖关系这一主题——即测试用例中存在的关联性。此类情况下，某个测试用例的结果可能部分或完全依赖于其他测试用例的结果。依赖关系还可能涉及功能、测试环境或安全策略，甚至可能影响组织实施的整个测试流程。
系统测试方法并不深入探究其内部运作机制（需谨记此为黑盒测试形式），而是用于验证特定应用程序是否正常运行。系统测试的核心目的在于：通过评估软件应用程序的整体功能，帮助定位漏洞、错误或缺失的需求。
系统测试通常在集成测试之后、验收测试之前执行，以此确保所有组件能正确协同工作。正如我们将要看到的，它往往同时涵盖系统的功能性与非功能性维度。基于严格的功能范畴与广泛的非功能领域，系统测试会涉及可用性、安全性和性能等多元层面。
系统测试的主要目的之一是验证软件的编程语言能否被转化为可用的程序。然而系统测试的根本目标在于确保被测试软件能够有效支撑目标用户群体的业务需求。
测试过程需要模拟实际将使用的生产环境，以保证软件在真实多变条件下仍能按需运行。同样，测试数据也需模拟真实场景的数据与情境。测试用例执行后，即可定位并修复软件中的缺陷。
系统测试可分为三大主要类别。第一种是功能测试，它关注系统性能，但仅旨在验证软件是否按承诺运行，不进行更深层次的探究。以下是功能测试的主要类型：
- 验收测试：用户验收测试旨在纳入由代表所开发软件目标用户群体的人员所执行的性能测试。这些用户通过在真实环境条件下测试软件，为测试过程带来了额外的真实性。
- 集成测试：功能测试的一个重要领域是检验不同模块或组件在紧密协同工作时的契合程度。这就是系统集成测试。完全集成的系统使测试人员能够评估关键交互作用。
- 冒烟测试：冒烟测试用于验证开发人员修改代码后整体功能是否保持正常。代码变更完成后，冒烟测试可快速检测此次修改是否引发不良影响。
- 单元测试：在单元测试中，有限代码段会在隔离测试环境中接受检验。若被测单元未通过测试（通过测试数据与功能目标的比对发现），通常需要在系统层面对单个组件或模块进行更多测试。
虽然功能测试能提供关键信息，但这些数据本质上仅能判断系统是否按预期运行。这忽略了大量相关变量——例如系统安全性、用户体验与性能表现等维度。
非功能系统测试则提供了评估系统运行状况的途径。功能测试与非功能测试的本质区别可简化为以下对比：
- 功能测试：系统能否运行？
- 非功能测试：系统运行是否良好？
基于此，以下是非功能系统测试的关键形式：
- 可访问性测试：数字内容是否对所有人（包括各类残障人士）都具有可访问性？可访问性测试专门研究该问题，致力于确保内容能以跨越身心障碍的方式传递给所有潜在用户，并符合《美国残疾人法案》(ADA) 制定的包容性标准。
- 兼容性测试：当考虑到应用程序的广泛分发范围及其需要实现的跨平台运行需求时，就很容易理解兼容性测试的必要性——该测试旨在衡量此类应用程序无论需要跨越多少网络、浏览器、操作系统和硬件配置，都能保持良好运行状态。
- 负载测试：这个分支学科关注负载概念带来的独特物理特性及其对系统处理请求能力的影响，负载测试重点检测系统在实现大规模可扩展性时的表现。我们假定系统处理单个请求毫无压力，但当负载乘以数千次请求——甚至远超于此量级时，系统表现又将如何？
- 本地化测试：当前全球经济体系涵盖的国家与文化比以往任何时候都更加多元。本地化测试旨在根据用户体验的通用规则，确保输出至全球不同地区的软件内容均符合当地特定需求。
- 性能测试：这类非功能性测试特别关注性能表现。例如，系统能否快速流畅地响应请求对保障良好性能至关重要。性能测试中的测试方案会评估用户等待请求处理所需的时间。
- 压力测试：如同医学压力测试旨在检测人体心脏在活动负荷下的工作状态，软件压力测试则是为了验证系统在超出正常负载时，能否保持运行韧性，并准确识别瓶颈与薄弱环节。
- 可用性测试：这类非功能性测试完全关注用户体验 (UX) 的质量。可用性测试属于手动测试过程，最适用于小规模场景。尽管如此，仍应频繁实施该测试——尤其是在执行应用程序本地化等复杂操作时。
尽管其他类型的系统测试不属于功能测试或非功能测试类别，但仍然很有用。以下是这些方法论中最值得关注的几种：
- API 测试：应用程序编程接口 (API) 至关重要，它能通过连接不同应用程序或系统来支撑软件开发。API 测试可确保接口连接点按预期方式运行。同时监控用户权限及通过 API 管理数据的方式。
- 自动化测试：顾名思义， 自动化测试（也称为测试自动化）将自动化技术应用于软件应用测试。它通过创建并执行专为软件应用设计的测试脚本来实现大规模自动化测试，整个过程无需人工干预。有助于自动执行测试流程的结构化指南、工具与实践集合被称为测试框架。
- 手动测试：与自动化测试直接对立，手动测试依赖人工根据各类测试场景与测试脚本来检验受测软件。测试人员需对软件进行全方位实际操作，以识别需要修复的问题。
- 迁移测试：正在进行企业数字文化更新或转型的组织需要迁移测试。当企业从事此类转型工作时，他们需要验证关键数据和软件正在被从原有系统正确迁移至新系统。
- 回归测试：虽然代码变更旨在改进软件或增强功能，但若掺杂人为失误，可能会无意中引发问题。回归测试让测试人员能通过重复执行测试用例，确认系统保持稳定正确的运行状态。
尽管系统测试过程提供了最全面的黑盒性能测试方案，但执行系统测试并非没有潜在问题：
系统测试需满足的需求种类繁多——无论是组织特有的业务需求、软件独有的功能需求，还是可能适用于其运行的特定需求。事实上，操作系统需要吸纳的系统需求似乎永无止境。频繁变更的需求可能导致系统测试受阻，使其仅能完成不完整的测试用例集。
最后期限在商业环境中可能造成严重干扰，这已是共识。当工作进度与时间表预期产生冲突时，期限压力产生的严峻影响众所周知。在软件开发中，期限压力具体表现为：充分适当的系统测试常被压缩，要么以不完整的方式执行，要么被完全忽略。这往往导致在软件开发生命周期后期需要进行返工测试。
系统测试既非在真空中进行，也非无需成本。这需要测试团队的专业技能、辅助劳动的测试工具，以及首要的充足预算支撑。若缺乏这些要素，就容易出现偷工减料的情况，导致测试不完整。若上述任一环节被更改或取消，都可能对该软件应用程序或软件产品的系统测试最终达成的测试覆盖率产生负面影响。
测试过程中能够评估许多潜在漏洞，但软件工程人员必须在其所处测试环境受控且获得支持的前提下才能完成这些评估。当测试人员处于不稳定的工作环境时，更容易遗漏潜在的软件缺陷。即便在不稳定环境中发现需要修复的程序错误，测试人员后续复现这些问题的难度也会显著增加。
当任务涉及软件质量保证时，审查计算机代码行是项艰巨的工作，可能变得冗长耗时。若测试人员、开发人员及其他利益相关者之间出现沟通断层，会使这项工作更加棘手。正如任何商业活动一样，沟通问题会引发误解，形成缺陷难以被发现并在操作系统中扎根的生产环境。
测试技术多种多样，测试结果也形态各异——从易于理解的测试数据，到在测试阶段及后续需要严格管理的庞大复杂数据集。当测试环境无法完全复刻生产环境时，项目复杂程度会进一步加剧。软件开发过程中实施的测试策略需充分考虑如何最优应对这些问题。
完全托管的单租户服务，用于开发和交付 Java 应用程序。
使用开发运维软件和工具，在多种设备和环境中构建、部署和管理云原生应用程序。
云应用程序开发意味着一次构建、快速迭代和随处部署。