Day30-14｜9.5.2 定义软件运行剖面：让可靠性测试接近真实使用

一、教材定位

软件可靠性测试不能脱离软件的实际运行方式。系统每天处理什么业务、各类操作出现的频率是多少、输入数据具有什么分布、用户在什么时间集中访问、外部依赖有多大概率超时，这些信息决定了测试结果是否具有代表性。运行剖面就是对软件实际使用情况的抽象描述，它把“用户如何使用系统”转换为可观察、可统计、可执行的测试模型。

如果没有运行剖面，测试人员往往平均地调用所有接口，或者只选择容易构造的正常数据。这样的测试看起来覆盖了很多功能，却可能严重偏离生产：低频功能被测得过多，高频核心事务被测得过少；测试请求均匀分布，而真实流量有明显高峰；数据规模很小，无法暴露索引、缓存和存储问题；异常场景完全没有进入模型，导致故障恢复能力被高估。因此，定义运行剖面是可靠性测试从“脚本执行”走向“工程测量”的关键一步。

二、运行剖面的基本含义

运行剖面可以理解为一组带有概率、顺序、输入条件和环境条件的运行场景。它至少回答以下问题：谁在使用系统；用户执行哪些操作；不同操作各自出现多少次；操作之间有什么顺序关系；每次操作使用什么数据；系统处于什么负载和配置；异常、重试、取消和恢复的比例是多少。

运行剖面不是单纯的接口清单，也不是一张性能压测参数表。接口清单只说明系统“能做什么”，运行剖面说明系统“通常怎样被使用”；压测参数关注并发和吞吐，运行剖面还要描述业务组成、输入分布、操作顺序、时间变化和故障条件。可靠性测试应使用运行剖面生成具有代表性的业务流量，再结合压力和故障注入检验系统。

三、运行剖面的组成

1. 使用者与使用目标

不同角色的操作路径往往不同。例如电商系统中，普通用户主要浏览和下单，运营人员主要配置商品和促销，仓库人员主要处理出库，客服人员主要查询和售后。若只按照接口总量分配测试比例，可能忽略某个角色的关键流程。定义剖面时，首先要区分用户角色、设备类型、访问渠道和业务目标。

2. 操作或事务集合

把系统操作划分为可观察的事务，例如登录、查询、创建订单、支付回调、库存扣减、报表导出和批处理。事务粒度不能过粗，否则无法定位故障；也不能过细，否则测试模型会复杂到无法维护。对于端到端可靠性测试，应保留关键业务链路，而不是只测单个接口。

3. 操作概率与业务权重

每个事务应有出现概率、调用频率或业务权重。可以根据生产日志、业务统计、用户调研和容量规划得到初始值。若缺少真实数据，可以先由领域专家估计，再通过试运行和监控逐步校正。权重既可以按请求次数计算，也可以按订单金额、用户影响或风险等级修正。

请求数量最多的事务不一定最重要。支付确认可能调用次数不多，但对业务结果影响极大；权限变更可能是低频操作，但错误会引发重大安全和合规风险。因此运行剖面通常要同时保留频率权重和重要性标签，不能只按流量排序。

4. 操作顺序与状态转移

很多业务不是独立调用，而是具有先后关系。用户必须先登录才能下单，订单支付后才能发货，退款只能发生在特定状态。运行剖面应描述事务之间的转移关系、前置条件和状态变化。对状态机复杂的系统，可以把运行剖面表示为状态、事件和转移概率。

5. 输入数据特征

输入数据应覆盖常见值、边界值、异常值和不同规模。数据分布包括字符串长度、金额范围、文件大小、记录数量、热点对象比例、重复键比例和时间跨度。若只使用随机数据，可能无法模拟真实的热点、倾斜和关联关系；若只使用固定数据，又可能掩盖缓存失效、唯一约束和数据增长问题。

6. 时间与负载变化

系统负载通常随时间变化。运行剖面应体现工作日与节假日、白天与夜间、业务高峰与低谷、周期性批任务和突发流量。可以将一天划分为多个时间窗口，为每个窗口定义事务到达率、并发用户数和数据增长量。连续运行测试还要考虑长期趋势，例如每天增加的订单量和持续扩大的日志文件。

7. 依赖和环境条件

外部依赖的响应时间、错误率、可用区分布和网络条件会显著影响可靠性。运行剖面应说明数据库、缓存、消息系统、第三方支付、文件存储和设备接口的状态。对不稳定的依赖，要定义正常、延迟、拒绝、部分成功和完全不可用等条件，以及这些条件出现的概率或测试比例。

四、运行剖面的建立步骤

第一步：明确测试目的和系统边界

先明确本轮测试要回答什么问题，是验证核心业务连续性、评估长期运行稳定性，还是验证故障切换。不同目标需要不同剖面。如果目标是支付链路可靠性，就要包含下单、支付、回调、对账和退款；如果目标是批处理稳定性，就要重点描述批次规模、任务依赖、执行窗口和失败重跑。

系统边界也必须明确。被测系统是否包含客户端、网关、消息平台、数据库和第三方服务？哪些依赖使用真实服务，哪些使用模拟服务？边界不清会导致测试结论被过度外推。

第二步：收集运行数据

优先使用真实生产数据的统计结果，而不是直接复制敏感数据。可以采集访问日志、链路追踪、业务报表、队列长度、数据库审计、告警记录和用户行为统计。收集数据时要注意时间窗口是否足够长，是否覆盖高峰、低谷、节假日和版本变化。

如果系统尚未上线，可使用同类系统经验、业务规划、容量预测和专家访谈建立初始剖面。初始剖面不是永久真相，应在系统试运行后使用实际数据校准。

第三步：抽象事务和场景

将原始日志聚合成业务事务。例如多次页面请求可以聚合为一次商品浏览，多个内部调用可以归并为一次订单创建。抽象时要保留关键参数、状态变化和异常结果，以便测试脚本生成真实业务链路。

通常应建立三层模型：用户行为层描述角色和目标，业务事务层描述操作和顺序，系统调用层描述服务、数据库和消息等技术动作。三层之间要能追踪，避免只剩下无法解释的接口比例。

第四步：确定权重与概率

对每个事务计算相对频率，并结合业务重要性、风险和覆盖目标进行调整。最简单的模型是：某事务权重等于该事务在观察窗口内的次数除以全部事务次数。但若测试目的是覆盖低频高风险路径，就可以增加最低保障比例，并在报告中说明这是测试策略而不是生产流量的真实比例。

概率必须归一化，所有可达路径的概率总和应为 1。对于有条件分支的流程，应分别给出条件概率，例如支付成功、支付失败、支付超时和用户取消的比例。若概率来自估计，应标注不确定性和后续校正方式。

第五步：加入异常与恢复场景

正常运行剖面不能代表完整可靠性测试。应在正常剖面基础上增加网络抖动、依赖超时、节点重启、消息重复、数据校验失败、磁盘空间不足和人工取消等场景。异常场景可以按故障类型、影响范围和注入时机组织，并为每个场景定义预期的降级、重试、切换和补偿结果。

第六步：评审、验证和持续更新

运行剖面需要由架构、开发、测试、运维和业务人员共同评审。业务人员验证流程和权重，技术人员验证依赖与边界，运维人员验证运行环境和故障条件。执行小规模试运行后，将生成的流量与生产统计对比，修正明显偏差。

运行剖面应版本化。业务调整、用户增长、系统重构、渠道变化和新故障出现后，都可能使旧剖面失效。每次更新应记录来源、变化原因、影响范围和生效时间。

五、运行剖面的表示方法

1. 事务概率表

适用于操作相对独立、流程较简单的系统。表中记录事务名称、发生概率、输入规模、平均响应要求、业务重要性和验证结果。例如：查询商品 45%，创建订单 15%，支付确认 10%，库存查询 20%，售后操作 10%。这类表直观易懂，适合综合知识和案例分析。

2. 状态转移模型

适用于订单、工作流、设备控制和审批系统。节点表示业务状态，边表示事件，边上可以标注转移概率。测试生成器按照当前状态选择下一事件，能够避免生成违反业务规则的无效操作。状态模型还可以显式描述超时、取消、回滚和人工干预。

3. 场景树或业务流程图

适用于包含多个角色和分支的端到端业务。树的层次可以表示用户、业务流程和技术调用，分支概率表示不同路径的出现比例。场景树有助于分析关键路径、异常路径和高风险路径，但规模过大时应进行裁剪和分组。

4. 分层运行剖面

大型系统可以按用户层、业务层、服务层和资源层分别建模。用户层描述访问来源和角色，业务层描述事务权重，服务层描述调用链和依赖，资源层描述计算、存储、网络和消息负载。分层模型能够解释“业务流量如何转化为技术压力”，也便于定位可靠性问题。

六、运行剖面与测试充分性的关系

运行剖面不是越复杂越好。过于简单会失真，过于复杂会导致测试成本高、难以复现和难以解释。应根据测试目标选择适当粒度，并保留关键风险的可观测性。

可以从四个方面判断剖面是否充分：第一，是否覆盖核心业务和高影响故障；第二，事务比例是否有数据来源；第三，状态和依赖条件是否符合实际；第四，测试结果能否与生产指标进行比较。覆盖率高不等于剖面真实，随机性强也不等于代表性好。

测试样本量也要与概率对应。低概率场景如果只执行很少次数，不能据此得出“没有问题”的结论。对于低频高风险事务，应通过定向测试提高样本量，并单独报告其结果，不要把它掩盖在总体平均值中。

七、案例分析：物流平台运行剖面设计

某物流平台包含下单、订单查询、运单追踪、网点收件、仓库扫描、配送签收和异常件处理。测试团队原计划平均调用所有接口，运行 24 小时后宣布系统稳定。上线后发现高峰期轨迹查询延迟明显升高，仓库批量扫描时消息积压，异常件人工处理后部分运单状态没有同步。

问题在于原测试没有反映真实业务。首先，轨迹查询是高频操作，应该结合节假日和促销期间的热点运单进行建模；其次，仓库扫描是批量事务，输入不是单条平均请求，而是不同规模的批次和集中到达；再次，异常件处理虽然低频，却会引起人工操作、状态回退、补偿消息和多系统同步，必须作为高风险场景单独测试；最后，测试没有描述不同时间窗口，忽略了白天揽收、夜间分拨和清晨配送的负载差异。

改进后的运行剖面分为客户查询、网点作业、仓库作业、配送作业和异常处理五类。每类记录事务比例、批量规模、状态转移和依赖。正常剖面按生产统计生成，高峰剖面提高查询和批量扫描到达率，异常剖面加入消息延迟、重复投递、网络断开和人工重试。测试结果除记录平均延迟，还要检查轨迹最终一致性、消息积压恢复时间、批量任务成功率和异常件状态对账。

八、综合知识练习

题1

运行剖面与接口清单有什么区别？

参考答案：接口清单只列出系统提供的操作，运行剖面还描述不同角色、事务频率、调用顺序、输入数据、时间变化、依赖状态和异常恢复。接口清单说明系统能做什么，运行剖面说明系统实际上如何被使用。

题2

为什么不能简单地让所有业务事务以相同概率执行？

参考答案：真实业务中事务频率、业务价值和风险不同，平均分配会造成测试流量与生产偏离，可能过测低频操作而漏测高频核心链路。对于低频高风险事务，应在保留生产比例的同时设置专项测试比例，并单独解释测试目的。

题3

定义运行剖面时，为什么要加入异常和恢复场景？

参考答案：可靠性不仅是正常情况下成功，还包括异常发生时的检错、降级、切换、重试、补偿和恢复后数据一致性。只测试正常路径会高估系统可靠性，无法验证架构中的可靠性机制。

九、论文写作素材

论文中可以这样描述运行剖面设计：

“为避免可靠性测试脱离实际使用，我根据生产日志、业务统计和领域专家意见建立分层运行剖面。用户层区分普通用户、运营人员和后台作业，业务层描述查询、创建、支付、取消和对账等事务，技术层进一步映射到服务、数据库、消息和第三方依赖。对每类事务记录发生概率、输入规模、状态转移和高峰时段，并将网络延迟、消息重复、节点重启和依赖不可用作为异常扩展场景。剖面经过业务、架构、测试和运维人员评审，在试运行后依据实际指标持续校准。”

写作时要说明运行剖面如何服务于测试：它决定测试数据和流量组成，支持可靠性指标统计，帮助复现故障，并使测试结论能够与生产运行进行比较。不要只写“根据实际情况设计测试场景”，要写清楚实际情况来自什么数据、如何转化为概率和如何验证代表性。

十、今日复盘

运行剖面是对真实软件使用方式的可执行抽象。
它至少包含角色、事务、概率、顺序、输入、时间、负载和依赖条件。
生产日志是重要来源，但要经过脱敏、聚合和业务解释，不能直接照搬。
低频高风险场景应单独强化测试，并与正常生产比例区分说明。
运行剖面需要版本化、评审、试运行校准和持续更新。
可靠性测试的代表性来自运行剖面，测试结论的可信度也依赖运行剖面。