软件测试——功能、接口、性能、自动化阅读提示：全文1.6w字，码字不易，建议大家收藏。在当今数字化浪潮中，软件如丝线般

阅读提示：全文1.6w字，码字不易，建议大家收藏。

在当今数字化浪潮中，软件如丝线般编织进生活各个角落，从日常社交娱乐到关键业务运营，软件质量举足轻重，而软件测试恰似把关卫士，确保交付产品稳定可靠。以下深入探究软件测试几大关键领域：功能测试、接口测试、性能测试与自动化测试。

一、功能测试：基石之检

功能测试聚焦软件能否契合既定业务需求与功能规格说明，模拟用户实际操作流程，遍历各功能模块。以电商 APP 为例，用户注册、登录、商品搜索、下单支付、物流跟踪等功能均是测试要点。测试人员会精心设计用例，考量正常与异常输入情形。像注册环节，验证常规手机号、密码格式能否顺利注册同时，故意输入不合法手机号（位数不对、含非法字符）、弱密码（过于简单、纯数字），观察系统提示与限制是否合理，恰似模拟现实中用户犯错场景，确保系统容错且引导正确。

这种测试按业务流程分层级、分模块细致进行，从界面交互元素显示正确与否，到复杂业务逻辑（如电商满减、优惠券叠加规则）运算精准度，逐点击破，保障软件 “能用”，是软件立足市场基本前提，任何功能瑕疵都可能致用户流失、口碑受损。

黑盒测试常见测试用例编写方法

①等价类划分法

定义：
等价类划分是把程序的输入域划分成若干个部分，然后从每个部分中选取少数具有代表性的数据作为测试用例。这些部分被分为有效等价类和无效等价类。有效等价类是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合，能让程序正常运行并得到预期结果；无效等价类则是不符合规格说明、不合理的输入数据构成的集合，程序对其进行处理时应该给出相应的错误提示或异常处理。

举例：
假设要测试一个用户名注册功能，要求用户名长度为 6 到 12 位，只能包含字母和数字。

- 有效等价类：长度在 6 到 12 位之间，且仅由字母和数字组成的字符串，比如 “abc123456”“testuser789” 等，这些代表了符合规则的正常输入情况，通过对这类等价类的测试可以验证功能在正常输入时能否正确处理。
- 无效等价类：可以进一步细分，比如长度小于 6 位的字符串（如 “abc12”），长度大于 12 位的字符串（如 “abcdefghijklmn”），包含除字母和数字之外其他特殊字符的字符串（如 “abc@1234”）等。针对这些无效等价类进行测试，能够查看程序是否对不合理输入做出了正确的错误提示或异常拦截，防止程序出现意外行为。

优点：该方法能够用较少的测试用例覆盖大量可能的输入情况，提高测试效率，同时确保对合理和不合理输入情况都能进行有效验证。

②边界值分析法

定义：
边界值分析法是对等价类划分法的一种补充，它着重关注输入或输出的边界情况。因为大量的错误往往出现在输入或输出范围的边界上，而不是在其内部。通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试用例。

举例：
还是以用户名注册功能为例（用户名长度要求 6 到 12 位，只能包含字母和数字）。

- 边界值选取：最小边界值，即长度为 6 位的合法用户名，像 “abc123”；最大边界值，长度为 12 位的合法用户名，例如 “abcdef123456”。同时还要考虑刚刚小于最小边界值（长度为 5 位的用户名 “abc12”）和刚刚大于最大边界值（长度为 13 位的用户名 “abcdef1234567”）的情况。对于输出边界，如果注册成功有相应提示信息，也要关注提示信息在不同边界条件下的显示是否正确等。
- 实际应用场景：比如软件中某个功能接受用户输入年龄，范围是 18 到 60 岁，那么 18 岁、60 岁就是边界值，测试用例就需要包含输入正好是 18 岁、60 岁的情况，以及 17 岁、61 岁这样接近边界的无效情况，以此来验证程序在边界处的处理是否准确。

优点：通过聚焦边界情况，可以有效发现因边界处理不当而导致的错误，很多程序在边界条件下容易出现越界、溢出等问题，这种方法能够精准地排查此类隐患。

③决策表法

定义：
决策表是一种分析和表达多逻辑条件下执行不同操作情况的工具。它将条件桩（列出所有可能的条件）、动作桩（列出所有可能的操作）、条件项（针对各个条件的取值情况）以及动作项（不同条件组合下对应的具体操作）组合在一起，用于梳理复杂的业务逻辑和条件判断流程，进而据此编写测试用例。

举例：
考虑一个电商系统的折扣规则。条件为：用户是否是会员（是 / 否）、购物金额是否达到 500 元（是 / 否）；动作有：打 8 折、打 9 折、不打折。

构建决策表：
条件桩条件项 1（会员）条件项 2（购物金额≥500 元）动作桩动作项 1（打 8 折）动作项 2（打 9 折）动作项 3（不打折）
是是 √
是否 √
否是 √
否否 √
- 编写测试用例：根据决策表中的每一种条件组合编写对应的测试用例，比如对于 “是会员且购物金额达到 500 元” 的情况，在测试用例中模拟会员用户购买超过 500 元商品的场景，验证是否按规定打 8 折；对于 “是会员但购物金额未达到 500 元” 的情况，测试是否打 9 折等。

优点：适合处理复杂的逻辑关系，能够条理清晰地呈现出各种条件组合对应的操作，避免遗漏重要的测试场景，保证对复杂业务规则的全面测试。

④因果图法

定义：
因果图法是一种用于描述输入条件（因）与输出结果（果）之间的因果关系以及约束关系的图形化工具。它通过分析软件规格说明中的各种因果关系，绘制因果图，然后基于因果图转换生成判定表，最后根据判定表编写测试用例。因果图中用一些特定的符号来表示因果关系，比如用 “→” 表示因果关系（原因导致结果），“∧” 表示与关系（多个原因同时满足才导致结果），“∨” 表示或关系（多个原因中只要有一个满足就导致结果）等。

举例：
假设有一个文件上传功能，要求文件大小不能超过 10MB，文件格式必须是.docx 或.pdf。

- 分析因果关系并绘制因果图：
  原因有：C1（文件大小不超过 10MB）、C2（文件格式是.docx）、C3（文件格式是.pdf）；结果有：R1（文件上传成功）、R2（显示文件大小超出限制提示）、R3（显示文件格式不支持提示）。
  其因果关系为：（C1 ∧ （C2 ∨ C3））→ R1；¬C1 → R2；（¬C2 ∧ ¬C3）→ R3 （“¬” 表示否定）。根据这些关系绘制出相应的因果图，图中用节点表示原因和结果，用相应符号表示它们之间的逻辑连接。
- 转换为判定表并编写测试用例：基于因果图转换出判定表，列出不同原因取值组合对应的结果，然后按照判定表编写测试用例，例如对于文件大小在 10MB 以内且格式为.docx 的情况，验证是否能上传成功；对于文件大小超过 10MB 的情况，验证是否显示文件大小超出限制提示等。

优点：能够深入挖掘输入条件和输出结果之间的复杂逻辑关系，尤其是在存在多个条件相互制约、相互影响的情况下，通过图形化的方式清晰呈现，确保测试用例能够覆盖所有可能的逻辑情况，避免测试遗漏。

⑤场景法

定义：
场景法是基于用户实际使用软件的场景来编写测试用例的方法。它把软件系统的操作流程看作是由一系列场景构成的，通过梳理出不同的业务场景，模拟用户在这些场景下的操作路径，从而设计出有针对性的测试用例。通常会先构建出基本流（正常的、符合业务逻辑的操作流程），再分析出各种备选流（因用户操作失误、系统异常等导致偏离基本流的情况）。

举例：
以在线购物流程为例，基本流可以是：用户登录账号→搜索商品→选择商品加入购物车→结算购物车商品→选择支付方式→支付成功。

- 分析备选流：
- - 在 “搜索商品” 环节，可能出现搜索无结果的情况（输入不存在的商品名称），这就是一种备选流。
  - 在 “结算购物车商品” 环节，可能出现库存不足的情况，导致无法正常结算，这也是一个备选流。
- 编写测试用例：针对基本流编写一个完整的测试用例，确保在正常操作情况下系统功能正常；然后针对每一种备选流分别编写测试用例，比如针对 “搜索无结果” 的备选流，模拟用户输入不存在商品名称进行搜索，验证系统是否给出相应提示等，以此来全面覆盖用户在购物过程中可能遇到的各种情况。

优点：贴近用户实际使用情况，从用户视角出发，能够有效发现因实际操作中各种意外情况而导致的软件功能问题，提高软件在真实使用场景下的可靠性和稳定性。

⑥正交实验法

定义
正交实验法是一种利用正交表来合理安排多因素、多水平实验，以较少的实验次数获取较为全面且有代表性的实验结果，进而分析各因素对实验指标影响程度的科学实验设计方法。在软件测试中，特别是当需要测试多个输入条件（因素）且每个条件有不同取值（水平）时，它可以高效地帮助我们设计测试用例，从众多可能的组合中挑选出具有代表性的组合进行测试，减少测试工作量的同时保证测试的有效性。

基本原理与要素
正交实验法涉及几个关键要素，即因素、水平和正交表。

- 因素：指的是影响实验结果（在软件测试中可理解为影响软件功能表现等）的各种输入条件或变量。例如，在测试一个电商 APP 的商品搜索功能时，因素可能包括搜索关键词长度、搜索类别（按商品名称、按品牌等）、是否启用模糊搜索等。
- 水平：是每个因素所取的不同状态或取值。比如上述电商 APP 商品搜索功能中，搜索关键词长度这个因素，其水平可以设定为短（3 - 5 个字符）、中（6 - 10 个字符）、长（11 - 15 个字符）；搜索类别因素的水平可以是按商品名称、按品牌、按功能这几种。
- 正交表：是一种经过精心设计的表格，它规定了如何从众多因素与水平的组合中挑选出有代表性的实验组合。正交表具有均衡分散性（各因素的不同水平在实验中均匀分布）和整齐可比性（对于每个因素，不同水平对实验结果的影响能进行比较）的特点。常见的正交表有、、等，其中字母 “L” 表示正交表，下标数字表示实验的总次数，括号内数字的底数表示因素的水平数，指数表示因素的个数。

应用步骤

1. 确定因素和水平：分析软件功能及测试需求，梳理出有影响的因素，并为每个因素确定合适的水平取值。例如在测试一款图像处理软件的图像缩放功能时，因素可能有缩放比例（设为 50%、100%、150% 三个水平）、图像格式（JPEG、PNG、BMP 三个水平）、是否保持纵横比（是、否两个水平）等。
2. 选择合适的正交表：根据确定的因素个数和水平数，挑选与之匹配的正交表。比如有 3 个因素，每个因素有 3 个水平，那就可以选择正交表（虽然因素个数不完全对应，但可以将多余的列舍去不用）。
3. 将因素和水平代入正交表，生成测试用例组合：把具体的因素及其水平值按照正交表的行列对应关系填入，从而得到具体的测试用例组合。以选择正交表测试上述图像处理软件图像缩放功能为例，按照正交表的安排，可能会生成这样的测试用例：第一组是缩放比例为 50%、图像格式为 JPEG、保持纵横比为 “是”；第二组是缩放比例为 50%、图像格式为 PNG、保持纵横比为 “否” 等等，依次根据正交表填满所有组合情况，每一组就构成了一个测试用例。
4. 执行测试并分析结果：依据生成的测试用例对软件进行测试，记录测试结果，然后通过数据分析等手段，判断各个因素对软件功能（如图像缩放后的质量、显示效果等）的影响程度，找出可能存在的问题或优化点。

优点

- 高效性：能在大量可能的因素与水平组合中，挑选出少量有代表性的组合进行测试，避免了全面测试所有组合带来的巨大工作量，大大提高了测试效率。
- 科学性：基于正交表的均衡分散和整齐可比性特点，保证所选取的测试用例组合可以较为全面地反映各因素及其交互作用对测试结果的影响，使测试结果具有较强的说服力，减少遗漏重要问题的可能性。

缺点

- 对复杂交互作用分析有限：当因素之间存在复杂的、高度非线性的交互作用时，正交实验法可能无法完全精准地剖析这些交互关系对结果的影响，有可能遗漏一些因特殊交互情况导致的问题。
- 正交表选择与应用有一定难度：对于初学者来说，理解正交表的原理以及根据实际情况准确选择合适的正交表，并正确将因素和水平代入其中生成测试用例，需要一定的学习成本，操作不当可能导致测试用例设计不合理。

⑦错误推断法

概述
错误推断法是一种凭借测试人员的经验、直觉以及对软件常见错误类型的了解，推测软件可能存在错误的地方，进而针对性地设计测试用例的方法。它基于过往大量的测试实践以及对软件失效模式的总结归纳，不依赖于系统的规格说明书等常规依据，重点关注那些容易出现问题的 “高危” 区域来挖掘软件潜在的缺陷。

应用依据

- 经验积累：测试人员在长期的软件测试工作中，会遇到各种各样的软件错误，例如内存泄漏问题在频繁进行资源分配和释放的功能模块中较易出现；数据输入验证不严格时，容易出现非法输入导致程序崩溃等情况。这些积累下来的经验能让测试人员在面对新的软件测试项目时，快速识别出可能出现类似错误的地方。
- 常见错误模式：不同类型的软件通常有一些共性的容易出错的地方。比如在 Web 应用中，表单提交功能如果没有对用户输入进行充分的防 SQL 注入处理，就很容易遭受攻击，导致数据泄露等严重后果；在多线程并发的软件中，线程同步问题常常会引发数据不一致、死锁等错误。了解这些常见的错误模式后，测试人员可以根据软件的具体特点，推断其是否存在类似的隐患，并设计测试用例进行排查。

应用步骤

1. 分析软件特点与功能：熟悉待测试软件的功能架构、所采用的技术、应用场景等信息，确定其大致的风险区域。例如，一款在线教育直播软件，涉及大量实时音视频数据传输以及用户互动功能，那么网络通信、并发处理以及实时数据处理相关的模块就是可能出现错误的重点关注区域。
2. 依据经验和常见错误模式进行错误推断：根据对软件的分析，结合过往经验以及已知的常见错误类型，推测软件可能存在的错误情况。对于上述在线教育直播软件，测试人员可以推断在网络不稳定时，音视频播放可能出现卡顿、中断情况；当多个用户同时发送互动消息时，可能存在消息丢失、显示混乱等问题；在切换不同课程直播间时，可能出现资源未及时释放导致内存占用过高的问题等等。
3. 设计针对性测试用例：针对推断出的每一种可能的错误情况，设计具体的测试用例来验证是否确实存在这些问题。比如为了验证网络不稳定时音视频播放卡顿问题，测试用例可以通过网络模拟工具制造弱网环境（如设置高延迟、丢包率等），然后观察音视频播放的流畅度以及是否会出现中断后自动重连等情况；对于消息丢失问题，可以安排多个测试账号同时发送大量互动消息，查看后台记录以及前端显示情况，确认是否有消息丢失。

优点

- 针对性强：能够直接聚焦于软件最有可能出现问题的地方，有的放矢地进行测试，对于快速发现隐藏较深、基于常规测试方法容易遗漏的缺陷很有帮助，尤其适用于挖掘那些因开发人员疏忽或者对特定技术细节处理不当而产生的错误。
- 灵活性高：不受限于软件规格说明书等固定文档，可以充分发挥测试人员的主观能动性和专业经验，根据软件实际的复杂情况随时调整推断方向和测试重点，适应不同类型、不同特点软件的测试需求。

缺点

- 主观性强：严重依赖测试人员的个人经验和知识储备，不同经验水平的测试人员可能推断出的错误情况差异较大，容易出现因个人判断局限而遗漏一些重要错误的情况，缺乏像其他一些基于规范方法设计测试用例的全面性和系统性。
- 难以覆盖全面：由于是基于推测来设计测试用例，很难保证能够涵盖软件所有可能出现错误的情况，对于一些不常见、超出测试人员经验范围的错误，可能就无法通过这种方法检测出来，所以通常需要与其他测试用例设计方法结合使用，以提高测试的完整性。

二、软件测试接口测试

1、什么是接口测试

接口测试，聚焦于软件系统不同组件、模块、子系统或者不同应用程序之间交互接口的功能性、可靠性、安全性以及性能的验证过程。这些接口依据通信协议、调用方式差异，可大致归为几类常见形式：

HTTP/HTTPS 接口：广泛应用于 Web 应用、移动端与后端服务交互场景，基于超文本传输协议，通过 GET（用于获取资源）、POST（提交数据创建新资源）、PUT（更新已有资源）、DELETE（删除资源）等请求方法，传递 JSON、XML、表单数据等格式内容，以实现信息交互。例如，电商 APP 下单操作，前端向服务器后端发送包含商品详情、用户收货地址等数据的 POST 请求，遵循 HTTP 协议规范完成交易创建流程。
Web Service 接口：常依托 SOAP（简单对象访问协议），以 XML 作为数据交换格式，在分布式异构系统间架起通信桥梁，因其具备严格契约定义（WSDL 文档描述接口、方法、参数类型等），多用于企业级复杂系统集成，金融机构间资金转账、跨企业供应链管理系统对接等场景多有涉及。
RPC（远程过程调用）接口：旨在让本地程序像调用本地函数那般便捷调用远程服务器程序，有基于不同技术框架的实现，像 Java 的 RMI（远程方法调用）、Dubbo 框架；Python 的 gRPC 等，隐藏底层网络通信细节，高效实现跨进程、跨机器功能调用，在微服务架构内部服务间通信场景大放异彩。

接口测试工作核心在于深度剖析接口输入（请求参数、请求头、请求方式）与输出（响应状态码、响应数据、响应头），模拟多类真实场景下调用情况，检验数据传输全流程完整性、准确性、合法性，确保接口按设计预期稳健工作。

2、为什么要做接口测试

尽早发现问题，降低修复成本：软件开发生命周期里，接口开发常先于前端界面。在底层接口联调阶段开展测试，能前置揪出数据交互错误、逻辑漏洞，相较等到系统集成后、界面测试阶段才暴露问题，修复成本呈指数级降低，避免牵一发而动全身的大规模返工。
保障系统集成稳定性：复杂系统集成时，各模块协同工作，一个接口故障犹如交通枢纽堵塞，会牵累整个业务流程瘫痪。例如在线旅游预订平台，航班查询、酒店预订、支付等多个子系统接口交互，任何接口数据传输偏差（如酒店库存数据同步出错致超售）、调用失败，都让用户预订受阻，影响业务运营。
提升测试覆盖，增强安全性：相较于仅依赖前端功能测试，接口测试可突破界面限制，深入测试系统 “幕后” 数据交互逻辑，挖掘隐藏在后端服务的安全隐患，防范 SQL 注入（通过接口参数恶意构造 SQL 语句窃取数据）、越权访问（篡改接口请求身份标识非法获取敏感信息）等攻击，拓宽测试覆盖率广度与深度，筑牢安全防线。

3、如何做接口测试

测试环境搭建：依据目标软件架构，搭建配套测试环境，涵盖服务器端模拟环境（若测试内部接口，部署对应服务版本）、网络配置（模拟不同网络带宽、延迟场景，利用工具如 Charles、Fiddler 代理网络抓包兼模拟网络环境），安装必要测试工具（Postman 方便手工接口调用测试、JMeter 应对复杂性能负载测试、SoapUI 专长于 Web Service 接口测试等）。
接口文档剖析与用例设计：熟读接口文档（OpenAPI 规范、Swagger 生成文档或企业内部接口手册），明晰接口地址、请求方式、参数规则（必选 / 可选、数据类型、取值范围）、响应格式及状态码含义。基于此设计用例，覆盖正常业务流（如按规则输入有效用户登录信息，验证能否成功登录并返回正确用户权限数据）、异常场景（输入不存在用户账号、密码错误格式，校验响应提示准确性）、边界值（查询订单列表，输入最大 / 最小页码值测试接口数据获取完整性）、安全校验（尝试 SQL 注入语句于参数位，看接口防护机制是否拦截）。
测试执行与结果验证：借助测试工具，依用例依次发起接口请求，细致比对实际响应与预期结果。检查响应状态码是否匹配（200 代表成功、400 系列标识客户端错误、500 系列暗示服务器端故障），解析响应数据结构、内容准确性（JSON 数据字段值、XML 标签对应内容），记录测试全程日志，对不符预期情况截图、详细描述问题便于回溯排查。
持续集成与自动化拓展：将接口测试融入持续集成（CI）流程，像 Jenkins、GitLab CI 等平台配置任务，代码提交或更新触发接口测试套件自动执行，搭配自动化测试框架（如 Python 的 unittest、Pytest 结合 Requests 库编写 HTTP 接口自动化脚本；Java 的 TestNG、JUnit 搭配 RestAssured 操作接口自动化），利用数据驱动（参数化用多组数据驱动相同测试步骤）、关键字驱动等技术，提升测试效率、反复回归验证，确保接口质量随软件迭代稳固可靠。

三、软件测试性能测试

1、什么是性能测试

性能测试是一种通过模拟真实使用场景或特定的负载条件，对软件系统的各项性能指标进行评估和分析的测试活动。其目的在于验证软件系统是否能够满足用户在不同工作负载下的性能需求，以及在长时间运行、高并发等复杂情况下能否稳定可靠地运行，确保软件交付后能提供良好的用户体验。

软件系统的性能指标通常包含多个维度，常见的如下：

响应时间：指从用户发起请求（比如点击网页上的某个按钮、发送一个操作指令等）到系统返回响应结果所花费的时间。例如，在电商平台上，用户点击搜索商品按钮后，页面完全显示出搜索结果所耗费的时长就是响应时间。一般来说，响应时间越短，用户体验越好，不同类型的应用有不同的响应时间合理范围，如普通网页应用，理想响应时间多在几秒内，而对于实时性要求极高的金融交易系统，响应时间往往要求在几百毫秒甚至更短。
吞吐量：表示单位时间内系统能够处理的请求数量或传输的数据量。比如，一个文件下载服务器，每分钟能够成功传输给用户的文件大小总和就是其吞吐量的一种体现。对于 Web 应用，通常以每秒处理的 HTTP 请求数来衡量吞吐量，它反映了系统的处理能力，吞吐量越高，说明系统在单位时间内能够应对更多的业务操作。
并发用户数：指在同一时刻与系统进行交互的用户数量。可以分为实际并发用户数（真实同时操作的用户数量）和虚拟并发用户数（通过工具模拟出来的同时操作情况）。例如，在电商大促活动时，有成千上万个用户同时在平台上浏览商品、下单付款，这就是高并发场景，系统需要在这样大量用户同时访问的情况下保持稳定运行，不出现卡顿、崩溃等情况。
资源利用率：主要考查软件系统运行过程中对各类硬件资源（如 CPU、内存、磁盘 I/O、网络带宽等）的使用情况。例如，长时间运行的数据库服务器，查看其 CPU 使用率是否长时间处于高位（可能意味着存在性能瓶颈，如查询语句优化不足等），内存是否存在泄漏（随着时间推移内存占用不断不合理增加），磁盘 I/O 读写速度是否满足数据存储和读取的需求，网络带宽是否在高并发数据传输时成为限制系统性能的因素等，合理的资源利用率能保障系统健康稳定运行。

性能测试可以帮助发现软件系统潜在的性能瓶颈，以便开发团队提前优化，避免在实际使用中出现响应迟缓、系统瘫痪等影响用户体验和业务运营的问题。

2、如何做性能测试

①明确性能测试目标和需求

- 与相关方沟通：和项目的业务部门、开发团队等进行深入交流，了解软件系统的业务功能、预期使用场景（如日常使用量、高峰时段使用情况等）以及关键性能指标的要求。例如，对于一个即将上线的在线办公软件，业务部门可能期望在日常办公时段（上午 9 点到下午 6 点），能支持至少 5000 个并发用户流畅使用文档编辑、文件共享等功能，且响应时间平均不超过 3 秒，吞吐量要满足每小时处理一定数量的文件操作请求，这些要求就是性能测试要围绕的目标。
- 梳理关键业务流程：确定软件系统中哪些业务操作是核心且高频的，重点对这些流程进行性能测试。比如电商平台的登录、搜索商品、下单支付等操作；社交软件的消息发送、朋友圈加载等功能，因为这些关键业务如果出现性能问题，会严重影响用户体验和软件的实用性。

②制定性能测试计划

- 确定测试范围和策略：明确要测试的功能模块、涉及的技术架构层面（如前端界面、后端服务器、数据库等）以及采用的测试策略（是进行负载测试、压力测试、容量测试还是几种结合等，后面会详细介绍不同测试类型）。例如，对于一个包含 Web 前端和后端微服务架构的应用，测试范围可能涵盖前端页面的加载性能以及各个微服务之间接口的响应性能，测试策略可以先进行负载测试确定基本性能表现，再通过压力测试排查极限情况下的稳定性。
- 规划测试环境：搭建与生产环境相似的测试环境，包括服务器配置、网络环境、数据库环境等，确保测试结果能真实反映软件在实际使用场景下的性能表现。若生产环境使用高性能服务器，测试环境也应尽量采用相近配置，或者按照一定比例进行等比例缩放配置，但要保证关键的性能影响因素能如实体现。同时，要考虑测试环境的独立性和可重复性，方便多次测试对比。
- 安排测试资源和时间进度：确定需要的测试工具（如 JMeter 用于模拟并发请求、LoadRunner 功能更全面可进行复杂性能测试等）、参与测试的人员及其职责，制定详细的时间计划，明确各个测试阶段（如测试环境搭建、脚本编写、测试执行、结果分析等）的起止时间节点，确保性能测试有序推进。

③准备性能测试环境和工具

- 搭建测试环境：按照规划好的测试环境要求，部署软件系统及其依赖的中间件、数据库等，进行必要的配置调整（如服务器参数优化、数据库连接池设置等），使环境处于一个相对稳定且可用于测试的状态。同时，要确保测试环境的网络连接正常，能够模拟出不同的网络场景（如模拟高延迟、丢包等弱网环境，以及高速稳定的正常网络环境）。
- 选择合适的测试工具：根据软件系统的特点（如基于 Web 的、移动端的、采用的技术框架等）以及性能测试的具体需求，选择合适的测试工具。常见的性能测试工具除了前面提到的 JMeter 和 LoadRunner 外，还有 Gatling（适用于对响应时间要求高精度分析的场景，常用于 Web 应用测试）、WebLOAD（侧重于 Web 性能测试，有强大的脚本编辑和分析功能）等。在选择工具时，要考虑其是否能准确模拟所需的负载情况、对目标软件技术的兼容性以及能否方便地收集和分析性能数据等因素。

④设计性能测试用例

- 分析业务场景和负载模型：依据前期确定的关键业务流程和预期使用场景，构建不同的负载模型。例如，对于一个旅游预订网站，负载模型可以分为日常浏览（低并发、少量请求）、假期预订高峰（高并发、大量查询和下单请求）等不同情况。针对每种负载模型，设计相应的测试用例，模拟不同数量的并发用户、不同的请求频率等条件来操作核心业务功能（如查询旅游线路、预订酒店、购买机票等）。
- 确定测试数据：准备好测试用例中需要用到的数据，包括用户账号数据（用于模拟不同用户登录）、业务操作数据（如商品信息数据用于电商平台的商品搜索测试等）等，确保测试数据的合理性和多样性，同时要注意数据量的大小对测试结果的影响，必要时进行数据量的控制和调整，以符合不同性能测试场景的要求。

⑤编写性能测试脚本

- 使用测试工具编写脚本：依据设计好的测试用例，利用选定的测试工具来编写性能测试脚本。以 JMeter 为例，如果要测试电商平台的下单支付功能，需要在脚本中设置好模拟用户登录、添加商品到购物车、发起下单支付请求等操作步骤，配置好相应的请求参数（如 URL、请求方法、请求头、请求体等），并通过工具的相关功能设置模拟的并发用户数量、请求的发送频率等参数，使脚本能够准确地模拟出真实的业务操作场景和负载情况。
- 脚本调试与优化：在编写完脚本后，要进行反复调试，检查脚本是否能正常运行，是否准确模拟了预期的业务操作，有没有出现请求错误、数据传输异常等问题。同时，对脚本进行优化，提高脚本运行的效率，避免因脚本自身问题影响性能测试结果的准确性，例如去除不必要的等待时间、优化请求的顺序和逻辑等。

⑥执行性能测试

- 按照计划逐步执行测试：依据性能测试计划和安排好的测试用例顺序，依次启动性能测试脚本，模拟相应的负载条件对软件系统进行测试。在测试过程中，密切关注测试工具反馈的各项性能指标数据（如实时的响应时间、吞吐量、服务器资源利用率等），确保测试过程正常进行，及时发现并记录可能出现的异常情况（如系统报错、性能指标突然恶化等）。
- 记录测试数据和环境信息：全面记录性能测试过程中的各项数据，包括不同负载条件下每个测试用例对应的性能指标具体数值、测试执行的时间、测试环境的相关参数（如服务器的 CPU 型号、内存大小、网络带宽等），这些详细的数据和信息将用于后续的分析和对比，以便准确评估软件系统的性能状况。

⑦分析性能测试结果

- 整理和汇总数据：将测试过程中记录的分散的数据进行整理汇总，按照不同的测试用例、负载条件等维度进行分类，制作成清晰的表格、图表（如柱状图对比不同并发用户数下的响应时间，折线图展示随着测试时间推移吞吐量的变化情况等），以便直观地查看和分析性能指标的变化趋势和相互关系。
- 性能瓶颈分析：通过对整理后的性能数据进行深入分析，查找是否存在性能瓶颈。例如，如果发现随着并发用户数增加，响应时间急剧上升，同时服务器的 CPU 利用率接近 100%，则可能意味着 CPU 处理能力是当前的性能瓶颈所在，需要进一步排查是代码逻辑导致 CPU 运算量过大，还是服务器配置不够等原因；又如，若在高并发情况下数据库查询操作响应很慢，可能是数据库的索引设置不合理、查询语句优化不足等问题导致的，要针对这些可能的瓶颈点进行详细的分析和定位。
- 与性能目标对比评估：将分析得出的性能结果与最初设定的性能测试目标（如响应时间要求、吞吐量要求、并发用户数支持情况等）进行对比，判断软件系统是否满足业务需求。如果未达到目标，要明确差距有多大，为后续的优化工作提供具体的依据，同时向相关团队（如开发团队、运维团队）反馈性能测试结果和分析建议，共同商讨优化改进方案。

⑧性能优化与回归测试

- 提出优化建议并实施：根据性能瓶颈分析的结果，协同开发团队、运维团队等提出针对性的性能优化建议，如优化代码算法以降低 CPU 占用、增加服务器内存或升级硬件配置、优化数据库查询语句和索引等。实施这些优化措施后，对软件系统进行相应的调整和改进，使其性能得到提升。
- 回归测试验证：在完成性能优化后，需要再次进行性能测试（即回归测试），按照之前的测试用例和流程，重新模拟负载条件对软件系统进行测试，验证性能优化措施是否有效，各项性能指标是否达到预期目标，确保软件系统的性能在优化后确实得到了改善且不会引入新的性能问题。

四、软件测试自动化测试

1、什么是自动化测试

自动化测试是借助特定的测试工具、脚本以及编程框架，通过编写代码来模拟用户操作行为或者验证软件系统功能、性能等各方面特性，让测试过程能够自动执行而无需人工手动逐个操作的一种测试方式。它旨在替代部分或全部重复、繁琐的手工测试工作，以提高测试效率、保证测试的准确性和一致性，并能够更频繁地执行测试，快速反馈软件质量相关信息。

例如，在对一个电商 APP 进行功能测试时，如果采用手工测试，测试人员需要一遍又一遍地手动点击登录、搜索商品、加入购物车、下单支付等各个操作按钮，然后查看结果是否符合预期，过程十分耗时且容易出现人为疏忽导致的漏测情况。而通过自动化测试，利用诸如 Selenium（用于 Web 应用和部分移动端应用自动化测试的工具）这样的工具，编写相应的脚本，就可以让程序自动模拟这些操作流程，像用户真实操作一样去反复验证软件功能，并且每次执行的操作和验证标准都是统一的，极大地提升了测试的可靠性和效率。

自动化测试可以覆盖软件测试的多个层面，包括功能自动化测试（验证软件功能是否正常运作）、性能自动化测试（模拟高并发等场景自动检测软件性能指标）、接口自动化测试（自动调用接口并验证接口数据交互是否正确等），几乎贯穿整个软件开发生命周期，从单元测试阶段到集成测试、系统测试阶段都能发挥作用。

2、为什么要做自动化测试

提高测试效率：随着软件功能日益复杂、迭代速度加快，手工测试要花费大量时间去重复执行相同的测试用例，比如回归测试时，每次软件更新后都需要重新验证原有功能是否受到影响，手工操作极为繁琐。而自动化测试脚本一旦编写完成，就可以快速、自动地多次执行这些测试，大大缩短了测试周期，能让测试人员在相同时间内完成更多的测试任务，更快地获取软件质量反馈。
保证测试准确性和一致性：人工进行测试时，由于人的状态、注意力等因素，可能会出现操作失误、遗漏测试步骤或者判断结果不一致等情况。自动化测试按照预先设定好的脚本和规则来执行，每次操作的顺序、输入的数据以及验证的标准都是固定的，不会受到主观因素影响，从而确保了测试结果的准确性和重复性，只要软件本身没有变化，每次执行自动化测试得到的结果都应该是相同的（在相同测试环境下）。
增强测试覆盖度：有些复杂的测试场景，比如模拟大量并发用户访问系统进行性能测试，或者对系统进行长时间的稳定性测试，依靠手工很难实现或者成本极高。通过自动化测试工具可以方便地模拟各种复杂的负载、环境条件，对软件进行全方位、深层次的测试，挖掘出一些手工测试难以发现的潜在问题，拓宽了测试的覆盖范围。
便于持续集成和持续交付（CI/CD） ：在现代软件开发流程中，CI/CD 是非常重要的环节，要求代码能够频繁地集成、测试并快速部署到生产环境。自动化测试可以无缝嵌入到 CI/CD 管道中，当开发人员提交代码后，自动化测试能够立即自动启动，快速判断代码变更是否引入了新的缺陷，及时反馈给开发团队进行修复，保障整个软件开发和部署流程的高效、顺畅进行，有助于实现快速迭代和高质量交付。

3、如何做自动化测试

①确定自动化测试目标和范围：

- 与团队沟通：和项目的开发团队、业务部门等相关人员交流，明确软件项目的关键功能、性能要求以及业务优先级等信息，进而确定哪些部分适合开展自动化测试，比如核心业务流程（如电商平台的下单支付流程）、频繁变动且需要反复验证的功能模块等通常是优先考虑自动化的对象。
- 评估可行性：分析软件的技术架构、系统复杂度等因素，判断是否具备实施自动化测试的条件。例如，如果软件界面频繁变动且没有相对稳定的元素定位方式，可能会对自动化测试的实施带来较大挑战，需要先考虑如何解决界面元素定位的稳定性问题，或者是否调整自动化测试的范围。

②选择合适的自动化测试工具和框架：

- 根据软件类型和测试需求选择：不同类型的软件适用不同的测试工具，比如对于 Web 应用，Selenium 是常用的选择，它支持多种浏览器（Chrome、Firefox 等），可以方便地模拟用户在浏览器上的操作；对于移动端应用，Appium 可用于跨平台（iOS 和 Android）的自动化测试，通过它能实现点击、滑动、输入文本等各种手机端操作的自动化模拟。如果是进行性能自动化测试，JMeter、LoadRunner 等工具则更为合适，它们可以模拟大量并发用户对系统性能进行检测。
- 考虑编程语言和框架兼容性：许多自动化测试工具需要结合编程语言来编写脚本，如 Python、Java 等。选择工具时要考虑团队成员对编程语言的掌握程度以及与软件项目所采用的技术框架是否兼容。例如，Python 语言简洁易懂、生态丰富，配合 Selenium 使用编写自动化测试脚本会很方便；如果项目本身是基于 Java 开发的，使用 JUnit、TestNG 等 Java 测试框架结合相关自动化工具来开展测试工作可能更契合团队的技术能力和项目特点。

③设计自动化测试用例：

- 复用手工测试用例：可以从已有的手工测试用例中筛选出适合自动化执行的部分，将其转化为自动化测试用例。例如，那些重复性高、逻辑清晰、输入输出明确的手工用例，像登录功能用例（输入不同的用户名和密码组合，验证登录结果）就很容易改写成自动化测试用例。
- 基于业务流程和功能模块设计：按照软件的实际业务流程和功能划分，系统地设计自动化测试用例。以电商 APP 为例，围绕用户从打开 APP、浏览商品、加入购物车、结算、支付到查看订单等完整购物流程设计一系列用例，确保各个环节的功能都能通过自动化测试进行验证；同时针对商品搜索、分类筛选等独立功能模块也单独设计用例，保证功能的全面覆盖。
- 考虑异常情况和边界值：自动化测试用例不仅要关注正常的业务操作，还要涵盖各种异常情况和边界值情况的测试。比如在输入框中输入超出规定长度的字符、输入非法字符等异常输入场景，以及数值型输入的最大最小值等边界情况，都要在自动化测试用例中有所体现，这样才能更全面地检测软件的健壮性。

④编写自动化测试脚本：

- 学习工具和编程语言相关知识：根据选择的自动化测试工具和编程语言，深入学习其语法、函数、操作方法等基础知识，比如使用 Python 和 Selenium 时，要掌握如何通过 Python 代码操作 Selenium 来定位页面元素（通过 ID、类名、XPath 等方式）、模拟鼠标点击和键盘输入等操作，以及如何设置等待时间以确保页面加载完成后再进行下一步操作等细节内容。
- 按照用例编写脚本逻辑：依据设计好的自动化测试用例，逐步编写脚本的逻辑代码。以登录功能自动化测试脚本为例，首先要打开登录页面（通过调用工具相关函数打开对应的 URL），然后定位用户名输入框并输入指定的用户名（使用元素定位方法找到输入框元素并执行输入操作），接着定位密码输入框输入密码，再点击登录按钮，最后通过判断页面是否跳转到预期的登录成功页面或者是否出现相应的提示信息来验证登录结果是否正确，整个过程要确保代码逻辑严谨、条理清晰，能够准确模拟用户的真实操作和验证流程。
- 脚本优化和调试：编写完脚本后，要进行反复的优化和调试工作。优化方面，去除脚本中不必要的冗余代码，提高脚本运行效率，比如避免过多的重复定位元素操作，可以将常用元素的定位提取出来复用；调试时，要检查脚本在执行过程中是否会出现元素定位失败、操作无响应、验证结果不准确等各类问题，通过打印日志、设置断点等方式排查并解决这些问题，保证脚本能够稳定、准确地执行测试任务。

⑤执行自动化测试并分析结果：

- 选择合适的执行环境：根据软件的部署环境和测试需求，确定自动化测试的执行环境，比如是在本地开发环境、测试服务器环境还是模拟的生产环境等进行测试执行。确保环境配置准确无误，并且具备执行自动化测试所需的各种条件（如安装了相应的测试工具、依赖库等）。
- 定期或按需执行测试：可以按照既定的计划定期执行自动化测试，比如每天下班前启动一轮完整的自动化测试，对当天开发的代码进行质量检测；也可以根据项目的特定需求，在代码有重大变更、新功能上线等关键节点按需执行自动化测试，及时获取软件质量反馈。
- 分析测试结果：自动化测试执行完成后，仔细分析测试结果报告，查看是否有测试用例失败的情况。对于失败的用例，要深入分析是由于软件本身的缺陷导致的（如功能出现错误、性能不达标等），还是因为测试环境问题、脚本自身的漏洞（如元素定位方式因页面改版失效等）引起的，根据不同原因采取相应的解决措施，如将软件缺陷反馈给开发团队修复，对测试脚本进行更新调整等，确保自动化测试能够持续有效地为软件质量保驾护航。

⑥持续维护和改进自动化测试：

- 应对软件变更：随着软件的不断迭代更新，功能会发生变化，界面元素可能会调整，这就要求自动化测试脚本要及时跟上软件的变化进行相应的修改和维护。例如，当电商 APP 的界面布局进行改版，原来用于定位商品搜索按钮的元素定位方式可能不再适用，就需要重新分析新界面并更新脚本中的元素定位代码，保证自动化测试能够继续准确执行。
- 优化测试流程和脚本：定期回顾自动化测试的整个流程和已有的脚本，寻找可以优化的环节，比如是否可以通过引入新的测试框架或技术来提高测试效率、增强测试覆盖度，或者对现有的脚本进行重构，使其更简洁、更易于维护等，通过持续的优化改进，让自动化测试始终保持良好的适应性和有效性。

往期推荐：

条件项 1（会员）	条件项 2（购物金额≥500 元）	动作项 1（打 8 折）	动作项 2（打 9 折）	动作项 3（不打折）
是	是	√
是	否		√
否	是			√
否	否			√