作者
Phill Powell
Staff Writer
IBM Think
Ian Smalley
Staff Editor
IBM Think
功能测试定义
功能测试是一种软件测试方法，用于验证应用程序特性是否根据规定需求按预期运行。
在软件开发中过程中存在多种软件测试类型。每种测试方法都从略有差异的角度出发。功能测试最贴近用户体验概念，其核心关注点是：软件特性是否按预期且符合规定需求正常运行？
作为软件开发生命周期的一部分，软件质量通常需要从多维度进行评估。在功能测试方面，测试人员需要验证基础功能，并确认软件功能是否有效支撑业务需求。涉及的测试执行过程让开发运维团队能够将实际测试结果与预期结果进行比对。
测试是开发过程的重要组成部分，而功能测试让质量保证团队能够在事实发生前进行质量验证，为其清晰展示工作流在真实启动时的可能运行状态。
行业时事通讯
辅以专家洞察分析的最新科技新闻
通过 Think 时事通讯，了解有关 AI、自动化、数据等方面最重要且最有趣的行业趋势。请参阅 IBM 隐私声明。
谢谢！您已订阅。
您的订阅将以英语提供。每份时事通讯都包含取消订阅链接。您可以在此管理您的订阅或取消订阅。更多相关信息，请参阅我们的 IBM 隐私声明。
功能测试如何运作？
根据整体测试战略中采用的软件测试类型，会重点关注不同的运营要素。功能测试评估不同软件模块之间的整体兼容性，这会直接影响其他相关方面，例如预期的用户交互和用户界面的可用性。
功能测试提供的测试环境被视为黑盒测试的范例——测试人员无法洞察系统内部运作机制（如白盒测试那样），而是会获得关于系统及其流水线是否按预期运行的“通过/未通过”报告。
功能测试的六个步骤
功能测试通常遵循包含六个步骤的测试流程：
确定软件需要执行的各项功能。根据功能需求创建输入数据。根据功能规格确定预期输出。执行测试用例。评估实际输出与预期输出的吻合程度。判定软件应用程序是否按预期要求正常运行。
应用程序开发
开启旅程：云端企业应用程序开发
在本视频中，Peter Haumer 博士通过演示不同的组件和实践（包括 IBM Z Open Editor、IBM Wazi 和 Zowe），探讨了混合云环境中现代企业应用程序的开发现状。
深入了解云应用程序开发
功能测试类型
正如存在多种软件测试模型一样，功能测试也存在不同类别。其种类繁多，此处仅列举部分类型。功能测试类型涵盖广泛细分领域，以下按字母顺序排列。
随机测试
在软件测试中，测试人员常在正式测试流程后进行随机测试。这种非正式的探索性测试完全由测试人员的技能与直觉引导。它没有既定结构，而是依靠测试者的本能驱动所采用的测试技术。
示例：“伙伴测试”——开发人员与测试者协同合作改进某个模块或应用程序。在此类随机测试中，通常由测试者发现程序缺陷等待修复项，而开发者专注实施修复。
API 测试
应用程序编程接口 (API) 支撑软件开发，并实现不同应用或系统的连接。API 测试确保接口连接点按需运行，同时监控用户权限及通过 API 管理数据的方式。
例如：“无界面测试”适用于缺乏用户界面或 UI 数据输入字段的场景。此类情况下，通过与接口服务或应用程序共享输入数据的方式，往往能通过 API 测试实现最佳检测效果。
复杂测试场景
许多组织希望其测试过程能真实反映实际用户的体验。对这些企业而言，复杂测试场景能提供所需的精确度，但需指出的是，更高的复杂性需要前期投入更多工作量来执行。
例如：在线订单处理看似是无缝操作，其背后却涉及大量待测试流程——例如商品能否轻松加入购物车、折扣应用等功能能否快速整合、以及交易流程是否顺畅无阻。
集成测试
集成测试常与单元测试同步执行，这能带来早期问题发现和更广测试覆盖率等优势。除了确保数据格式匹配外，集成测试还能深入揭示微服务的运行机制与性能表现。
例如：假设订单管理系统与某类支付处理模块进行集成，集成测试能预示两个实体间可能发生的故障点，并为开发人员提供早期低成本修复集成问题的解决方案蓝图。
回归测试
在理想情况下，一旦功能测试通过，就应始终保持通过状态。但这与现实并不相符——软件开发中，开发者新的代码变更可能会在无意中引发错误。回归测试能确保系统维持稳定的基准状态。
例如：任何代码变更发生时，总会有某种形式的回归测试被启用。这包括所有相关更新，例如缺陷修复后的调整、新功能的引入或软件升级后的验证。
健全测试
健全测试是一种快速敏捷的检测方式，用于验证现有功能是否未受相对较小的变更或缺陷修复的影响。健全测试常作为快速确认手段，确保新功能不会影响系统其他功能的正常运行。
例如：与回归测试类似，健全测试允许您将系统“回滚”至先前状态，以验证性能改进、确认基础操作并确保系统按预期运行。任何代码变更发生时，总会启用某种形式的回归测试。这包括所有相关更新，例如缺陷修复后的调整、新功能的引入或软件升级后的验证。
冒烟测试
俗话说：“有烟的地方就有火”。这条谚语似乎启发了“冒烟测试”的命名。冒烟测试在开发早期执行，用于评估端到端功能的完整性。若功能测试失败，质量保证团队会立即进行必要修正。
例如：冒烟测试可用于验证持续集成与持续交付流水线，作为新软件构建版本（或重大代码变更）部署前的最终检测环节。
系统测试
系统测试（有时称为端到端测试）旨在评估整个软件系统中各组件协同工作的状况。系统测试通常涉及对多个独立软件系统的分析，这些系统在特定软件系统中可能协同运行，也可能独立运作。
例如：端到端场景使测试人员能够评估完整工作流程。对于在线零售业务而言，这意味着覆盖消费者从初始采购订单到完整履约流程的全程消费体验。
单元测试
单元测试是一种微观层面的测试形式。此类测试不针对完整系统，仅针对有限代码段进行验证。代码片段在隔离测试环境中接受评估，若单元测试失败（通过测试数据与功能目标的比对判定），则可在系统层面展开更全面的测试。
例如：基础计算元素非常适合通过单元测试进行验证。以摄氏温度转华氏温度的简单函数为例：测试环境包含待测代码及相应测试用例。
用户验收测试
用户验收测试作为软件测试的后期阶段，旨在通过目标用户群体进行的性能测试来获取反馈并优化产品。这些最终用户为测试过程注入了更强的真实感。
例如：当软件方案用户升级至更高服务层级时，理应解锁全新功能。用户验收测试可验证用户能否按预期获得相应增强的功能访问权限。
功能测试与非功能测试
顾名思义，非功能测试评估的是那些通常不直接影响功能运行的应用行为。然而，提供组织有序且愉悦的用户体验现已被视为软件开发的重要组成部分。非功能测试能够揭示潜在系统问题，尤其在软件需要展现更高可扩展性时尤为关键。
负载测试
负载测试是非功能测试的关键形式之一。理论上，系统处理数千个系统请求时应与处理单个请求保持同样的响应效率。但现实经验往往与此相悖。负载测试旨在验证系统能否承受峰值负载乃至极端工作负荷的激增。
性能测试
另一类非功能测试则特别关注性能表现。系统能否流畅迅速地响应请求，对保障良好性能至关重要。性能测试中的测试方案会评估用户等待请求处理所需的时间。经过周密设计的性能测试有助于在早期最大限度减少延迟。
安全测试
鉴于数据安全的重要性，出现专门针对这一现代需求的测试类型也就不足为奇。动态应用程序安全测试 (DAST) 和静态应用程序安全测试 (SAST) 等安全测试方法能帮助测试人员检测安全漏洞。企业会根据潜在威胁来选择相应的安全测试方法。
可用性测试
有一种非功能测试类型完全关注用户体验的质量。可用性测试属于手动测试过程，最适用于小规模测试。但应尽可能实施该测试——特别是在执行应用程序本地化等操作时，因此类操作引入的复杂性可能触发人为错误，存在较大风险。
功能测试工具
要准确掌握各类功能测试工具需要投入大量精力，因为大多数工具支持不同平台和应用程序类型。虽然无法完全跟上这个蓬勃发展的市场（预估市面存在的功能测试工具数量轻松突破数百甚至上千款），但以下列举的工具因其广受认可的热度与实用价值而脱颖而出。
Appium：功能测试市场拥有众多开源工具，其中 Appium 高居榜首。Appium 支持多种编程语言。此外，Appium 支持在 iOS 和 Android 平台上实现原生应用程序、移动网页应用程序及混合应用程序的测试自动化。
Katalon Studio：测试自动化平台 Katalon Studio 提供了建立与评估回归测试及端到端测试结果的解决方案。其具备录制回放功能并支持跨平台协同操作。
Micro Focus Unified Functional Testing (UFT)：Micro Focus 推出的 UFT 是另一款商业测试工具，为测试人员提供清晰的多平台视角，可同时监测 Web 服务、应用程序编程接口 (API) 及图形用户界面 (GUI) 的运行状态。
Playwright：Microsoft 开发的商业框架，专注于实现 Web 浏览器自动化。该工具以强化可靠性著称。虽然 Playwright 确实支持现代网页特性，但在编程语言处理方面提供的选项相对有限。
Selenium：作为最受欢迎的测试自动化工具之一，Selenium 是一款开源框架。这款基于浏览器的工具允许测试人员使用多种主流编程语言（包括 JavaScriptTM、NodeJS 和 Python）编写并评估测试脚本。
Share
复制链接