测试分析文档

 

1   产品概述

1.1 产品背景

本项为必填项。必须包含内容：需求PRD&系分等相关文档链接

 

业务背景：

描述产品的业务背景，便于测试小组成员了解业务背景，划分测试场景，并站在用户的立场上测试；

 

开发背景：

描述该项目采用的技术背景。全新产品与升级改造类项目。对于不同类型需要考虑不同内容等。

 

1.2 产品目标

本项为必填项。产品目标来自需求PRD

描述产品的预期指标.，对于测试分析而言，需要对此分析，目前的架构设计是否能够支持该目标的实现，由此提取出性能，可扩展性及可维护性的测试需求；

举例:

产品预期目标

1.产品上线后支持10家以上信用卡种；

2.目前确认本次项目上线银行为工行、兴业、广发；

2.1.2 产品价值评价指标

1. 产品上线后6个月还款笔数达到25万笔/月以上；
2. 产品上线后6个月交易量5亿/月以上；
   2.1.3 用户页面交互评价指标
   TBD

 

2.  项目整体分析

2.1 功能性需求测试分析

2.1.1 术语表

本项为选填项。根据实际情况填写，术语来自产品PRD

对于PRD中的术语，在这里再列出，并给出定义，避免由于对术语理解不一致而导致漏测，或错误的提单；

名称 说明

2.1.2 PRD需求清单与测试功能对应列表

本项目为必填项

• 测试分析功能点必须和PRD需求内容对应，或者是一对一，或者是一对多，或者是多对多
• 测试分析功能点如果不是PRD引发出来的，需要在备注中说明具体原因
• 技术改造类项目也需要遵循此部分内容
• 此处可以使用脑图，不局限于此表格。只要表达清楚需求与功能点的对应即可

优先级	PRD需求	测试分析功能点	备注
P1	P1-用户还款流程	用户还款流程	基本功能
P2	P2-后台信息增删改	信息新增	信息修改
P1	P1-bizfund系统LDC改造		系统级技改

 

2.2 系统架构分析

需求在实现时，通常需要分解分配到已有的系统架构中的各个子系统，通过各个功能模块分别实现，这里衍生出新的需求，一类是业务实现需求（PRD），一类是系统架构为保证实现业务需求实现而设计的架构，实体，数据，通信机制是否有效，是否可靠；架构分析的目的正在于此 ；

 

2.2.1 被测系统总体架构

本项为选填项，参考系分

系统静态架构图可以在系分文档提供的基础上通过评审获得，确保完备性，一致性.

用于分析确定被测系统边界，被测系统上下文，确定测试范围；

注意：

这里要给出与被测产品功能实现所有相关系统的图形描述；

举例:

 

 

以及系统依赖关系:

 

 

2.2.2 被测系统总体接口

本项为必填项。需要体现所有需测试的接口

接口是对系统静态架构的进一步描述，系统间的依赖关系通过接口来实现，因此该图中要体现所有与被测产品功能实现有关的所有接口；

系分或详细设计中应该出各个接口的接口名，参数，以及简要的说明，便于在日志中对比验证；

举例:

 

 

3 功能性需求测试分析

3.1 Xxx功能测试分析

可以按功能模块划分，也可以按子系统划分；无论采用何种方式，都要保证对需求及系统实现的覆盖

3.1.1 需求说明

本项为必填项

这里描述测试理解以后的PRD需求，并根据需求详细拆分成功能列表。

 

3.1.2 业务流程分析

本项为选填项，参考系分

• 表现形式: 业务流程图
• 需要考虑正常流程
• 需要考虑异常流程（业务异常、系统异常），如：
  λ 超时，
  λ 异常时是否支持重试，重试中是否有幂等检查
  λ 明确成功、失败、未知返回码定义，返回码变更必须走返回码管理流程，需要关注返回的失败后对方是否还有继续处理成功的可能（比如超时返回到客户端后，服务端可能还在处理落地中，但客户端处理结束后服务端会继续处理最终且还能成功）
• 如果没有流程图需要在此说明原因

 

 

3.1.3 状态机分析

本项为选填项，根据实际需求填写

• 表现形式: 状态图
• 正常：正向 & 逆向
• 异常，如：拿不到确切结果的场景，如轮询不到支付结果，如unknow，不要把unknow当成确切的失败。
• 不管正常还是异常，都能走到终态
• 举例:

 

 

3.1.4 交互时序图

本项必填项，参考系分文档

• 形式：交互时序图
• 使用条件: 当两个及以上系统交互时, 需要画出交互时序图
• 画图过程中考虑系统交互中调用超时、消息延迟、乱序等异常处理
  举例:

 

 

3.1.5 资金流分析

本大项是选填项，如果是测试owner，本项是必填项

3.1.5.1

• 形式：资金流图
• 使用条件: 当两个及以上资金实体时, 需要画出资金在实体间流转图
• 考虑正向、逆向：
  λ 付款方与单据的金额一致
  λ 是否存在多次退款，因为四舍五入等计算方法导致1分钱问题
• 考虑过渡户、公用资金池等：
  λ 付款方与单据的金额一致，
  λ 是否有透支隐患等
• 资金平衡：
  λ 金额及币种：明确金额单位、精度，部分业务场景金额不一定是“1.23“元 格式，比如日元没有分，比如部分场景金额小数点需要2位以上精度。金额关注尾差问题，防止由于四舍五入引发的资损；
  λ 汇率的计算等（包括汇率的查询结果是否存在不一致情况，是否存在损益情况）
• 支付工具：
  λ 支付渠道（是否有禁用渠道，渠道收费如何定义的）
  λ 营销优惠工具（不同的优惠工具叠加，优惠溢价等现象）
• 资金三要素: 账户(首付款方)，金额，状态
  举例:

 

 

3.1.5.2 收费

• 形式：资金流图或其它（如在整体的资金流图中体现的话，在此可以不用画图）
• 收费消息：收费方式、收费方（比如要求从卖家收费）是否符合预期
• 渠道收费：不同的渠道，签有不同的收费方案
• 是否支持退费，以及是否允许多次退款退费
• 销售订单有效性：下单与收费的期间订单失效导致无法收费，退款与支付的期间订单失效导致无法退款，等
• 收费回查是否配置
  λ 收费回查的实现(处理器)是否有
  λ 业务系统向消息中心发送消息时异常，收费回查的验证
  λ 消息中心向charge发送消息异常，收费回查的验证

 

 

3.1.5.3 额度

• 额度是否配置
• 正向记账
• 如果是cid维度的记账，要考虑关联认证等场景下的额度的合并问题
• 逆向销账
• 限额

 

3.1.6 权限

本项是选填项

• 商户鉴权：如签约：
  λ 考虑签约查询时返回多条查询结果
  λ 签约信息缓存（比如10mins有效期）与DB不一致
• 用户鉴权：
  λ 用户状态及生命周期（冻结、抢夺、销户）
  λ 比如签约业务是否在销户前要检查，跟身份有关的业务在身份释放时是否新增业务风险，需要监听消息处理
• 授权

 

 

3.1.7 定时任务

本项是必填项，如果不涉及定时任务，请说明

• 配置（如机房部署，是否会导致并发等）
• 频率（考虑本层及上下游的处理能力）

3.2 迁移测试

本项是选填项

迁移测试主要考虑内容如下：

• 迁移方案

• 兼容性测试

• 数据库层面的分析测试：配置、性能

• 是否支持比对模式

 

3.3 链路测试

本项是选填项

链路测试主要考虑内容如下：

• 上下游变更带来的影响

• 本身变更影响了上下游：分析对外暴露的业务模型，如FundTransDTO属性值变更，或新增修改删除属性时，是否会对外围依赖系统产生影响，如prodtrans，giftprod，zdatabus，consumecenter，mcenter等，需要分析出来并通知外围

• 上下游重要参数传递：如卡号长度，避免参数字段的分段截取、截长后存储操作

• 上下游的错误码理解是否有误（如在3.1.2业务流程分析中有涉及，在此可不再赘述）

• ZB & ZC 变更分析：收单域

• 上下游出现异步调用，需考虑是否有请求或单据存在悬挂或不一致的情况

 

3.4 配置测试

本项是选填项

配置测试主要考虑内容如下：

• 发布系统配置内容测试（可在功能测试中分析）

• 数据库变更测试：如脚本测试，是否兼容老业务

• 中间件变更测试

 

4 非功能性需求测试分析

4.1 资金安全测试分析

4.1.1 核对，数据一致性校验

本项是必填项：需包含开发实现的echeck和测试同学反馈的echeck，需标注需求提出人。如本次无新增echeck，需要说明原因

写核对脚本的攻略：http://atit.alipay.net/index.php?r=blog/detail&qid=4791

一、故障场景概述

1. 场景说明：用户正常下单、购买超会并支付，然后取消，程序bug导致退款金额与订单金额不符，导致资损。
2. 风险控制措施：使用测试账户，在PPE环境注入
3. 通知方：NOC、瀚辰

 

二、故障场景详情

1. 操作步骤

 

a. 用户正常下单、购买超会并支付，然后取消

b. 使用核对助手drc

VIRTUAL_REFUND_SUCCESS

{"id": "17389386", "order_id": "2000000032181891510", "process_group": "0", "operator_id": "235441538", "refund_amount": "10", "operator_reason": "\u8ba2\u5355\u88ab\u65e0\u6548", "created_at": "2020-03-11 00:00:21", "updated_at": "2020-03-11 00:00:21", "drc_check_time": "2020-03-11 00:00:21.328000"}

，预期会存在告警VIRTUAL_REFUND_SUCCESS

 

2. 故障场景配置

使用演练平台进行故障注入的，需要填写故障场景地址，以便review配置的正确性。

核对助手

 

3. 蓝军恢复手段

核对助手为一次性动作，且为无损注入，自动结束。

 

4.1.2 时效性

本项是必填项。本项主要针对主从延迟。需包含本次改动是否有引入主从延迟，如有需要说明：主从延迟适用场景及不适用场景，不适用场景解决方案

• 业务处理需要注意实效性， 避免由于业务处理延迟，对用户造成额外的影响， 比如未及时还信用卡产生而外滞纳金、影响个人信用、错过交易截止时间导致收益受损、错过优惠时段；
• 有时效性承诺的产品，如何保证时效性，比如余额宝15：00之前必须收益发放完毕、2小时提现到账；
• 有时效性的业务单据，确保过期的业务单据不会被推进成功，比如线下收单场景不需要系统重试支付；
• 注意时间边界，比如9点前发送完成，会出现08:59:59发送， 09:00:01接受处理；
• 数据库主从延迟问题，在项目架构设计/评审的时候，就明确评估好“是否是数据延迟敏感型”业务，如果是，在代码逻辑里面就把对mysql数据库的请求都走主库，如果都走主库会导致TPS/QPS太够，就继续评审是否改造sharding分库分表，如果存在读写分离方式（写完立即读取），看一下业务降级预案、DB的压力是否允许紧急绑定读写到master主库、是否需要代码逻辑改造

 

4.2 并发测试分析

本项为必填项目，涉及资损业务必须进行此项测试，如本次无需并发测试，请说明原因

*业务状态更新操作的单笔或批量SQL，是否遵循了：

λ 单笔操作时：一锁，二判，三更新的规范

λ 批量更新流水时，是否在SQL的where条件中增加了原有流水的状态，且检查了update方法返回的记录条数是否满足预期。

• 缓存（本地、分布式、线程变量）信息的更新，是否遵循了：

λ 确保不出现脏数据，引起资金操作异常；

λ 确保关联缓存的更新，设计了合理更新顺序、遵守数据一致性原则；

λ 缓存有效期

λ 缓存大小

λ 缓存读写频率

• 资金操作的状态机设计，状态迁移需要确保能达到终态、异常处理重点关注；

• 重复提交

• 定时任务，有并发风险，需要考虑极端 并发时的处理情况

• 是否存在热点问题（如Tair热点，如账务热点，目前账务会自动配置缓冲记账）

 

4.3 幂等测试分析

本项为必填项，根据接口定义确定是否幂等，如无需幂等，请说明原因（参考系分）

 

• 数据、消息、事务，都要具备幂等检查：
• 幂等参数必须明确由哪个或者哪些参数组成（如外部交易号、批次号、文件名等），且明确幂等的返回结果定义
• 幂等参数不可以为时间参数，防止被更新导致幂等击穿；
• 幂等参数不可以用自身产生的数值;
• 重试时需考虑幂等；
• 资金安全风险高的，有addp缓存做幂等检查时，必须有兜底措施；
• 若批量业务，需要考虑数据重复递交、重复生成文件流水、处理超时等场景处理机制（如活动多次审核等）；
• 考虑切库（如FO库，历史库）时的幂等检查；
• 考虑历史迁移数据。

 

4.4 消息传递测试分析

本项为选填项，根据实际需求填写

• 通讯方式：同步 or 异步
• 发送和接受机制
• 分析本次项目是否对消息的订阅关系发生变更，以及是否做到了新老消息兼容逻辑
• 消息乱序

 

4.5 通知

本项为选填项，根据实际需求填写

 

需要分析：

• 外部商户通知

• 沟通平台配置（关注如：单个用户发送量，防止打扰用户）

• Push通知（关注push的模板，可能与短信模板不一致）

• 短信等

• 确保发送成功

 

4.6 安全性测试分析

本项为选填项，根据实际需求填写

• 安全测试分析的来源主要是PRD、系统设计、安全工程师安全建议。
• 采用的测试策略:工具扫描,手工测试.
• 安全开发参考://asoc.alipay.com/home/docs/

4.6.1 越权测试

场景例如:
λ 查看其他用户的订单，金额，用户信息
λ 越权创建活动

 

4.6.2 数据安全

• 数据权限：
  λ 考虑访问控制：水平权限、垂直权限，尤其在外部商户接口中，防止用户撞库来获取数据；
  λ 小二用户的关键操作需要控制后台权限，最好有操作日志记录；
• 业务信息数据安全：用户数据在输入、传输、存储、页面展示、日志中，是否有脱敏处理：
  λ 高敏感度要求的卡号、身份证号、密码、短信校验码、动态口令、密保问题答案、加密密钥禁止在任何途径明文展示（包括页面、页面源代码、日志等）；
  λ 对外敏感信息输出遵循数据安全输出规范，对输出对象(即合作伙伴)有同样的约束要求；
  λ 外部接口对外信息输出，能够支持信息敏感度级别定制化输出策略，如合作伙伴满足什么样的资质或者签署怎样的协议才能输出敏感度更高的信息（卡号、身份证号、真实姓名等）；
  λ 对于高敏感度的信息输出，应用层需要考虑支持加密传输（如身份证号加密对外输出）；

 

 

4.7 容量及性能测试分析

本项为必填项，本次需求上线是否压测，必须体现在本测分中体现。如无需要压测，说明即可。

 

性能测试分析来源主要是PRD、系统设计。对于PRD中有明确业务性能要求的，要根据PRD中的数据要求，然后再通过数据仓库抽取线上监控数据、线上应用系统有多少台部署、数据库的访问次数等信息做分析。对于PRD没有明确业务需求，但是项目中有新建的系统、服务访问方式改变、服务处理方式改变等也是要做性能测试的分析。

主要指标：

访问量

峰值处理能力

上下游处理能力

 

4.7.1 容量与性能分析

新增系统或新增服务的访问量与峰值处理能力

（1） 新增或改造系统及服务的访问量和对应的流量模型而产出的稳定平均事务处理（TPS）的能力；极限（TPS）的处理能力；

（2） 提供与交易创建或交易付款的比例关系；

（3） 根据当前部署架构中的集群大小，评估峰值访问量与集群峰值处理能力；

（4） 对于一级服务，峰值访问量/峰值处理能力应小于50%;

（5） 对于二、三级服务，峰值访问量/峰值处理能力应小于75%;

（6） 如果针对某一业务压测，需要考虑峰值叠加的影响

（7） 需考虑数据库访问频率及次数

提供内部依赖系统的服务访问量

通过上一节得到的服务访问量，根据应用依赖关系，计算出该服务对每一个内部依赖服务的访问量。比如，服务(页面)访问量是100TPS，在一次服务执行中，调用了某个内部依赖服务3次，则对该内部依赖服务的访问量是300TPS。

 

需要确保每一个内部依赖服务的总访问量不超过该内部依赖服务集群的处理能力（一级服务应小于50%，二、三级服务应小于75%,对于新增或改造项目峰值访问量/峰值处理能力不得小于 10%）。

外部依赖服务的访问量

对外部依赖服务的服务访问量计算方法与内部依赖服务相同。如果得到外部依赖服务确定的SLA，可以根据SLA要求来评估外部依赖服务的容量是否满足要求；否则必须与外部依赖服务的提供商进行沟通，明确提出容量要求，并在必要时进行扩容。

对关键业务及链路的系统影响评估

判断新增系统或服务对其他相互被依赖系统的影响.也就是要关注上下游的依赖关系.比如收银台页面加载中增加了对CIF的调用次数.那么对CIF的容量,性能的影响必须和CIF系统owner沟通,并做适当压测.在比如securitycore改变了加解密的算法,在支付是收银台在请求securitycore是请求和返回都受到影响.因为DES和RSA两个加解密方法在时间上就差50毫秒.对上下游依赖性能影响,除了在项目中进行压测,必须提前通知性能实验室,在代码合并后关注性能实验室的关键业务路径的测试结果.

 

4.7.2 测试范围、方法及工具

根据不同的项目选择不同的性能测试方法.

标准项目

标准项目的性能测试一般采用下列几个测试方法，这些方法视项目开发中对容量和性能的评估做取舍。 但a,b,e是必选：

a) 通过负载压力测试找出系统的稳定性事务处理能力。 极限处理能力；

b) 通过24 小时 x N 天的稳定性测试，保证系统的稳定性。 防止内存溢出，缓慢泄露，连接池，session， 资源获取时的偶然竞争造成，死锁，排队等现象；稳定性压测的时间长度,可根据具体情况适当减少.比如按照JVM FullGC发生次数决定稳定性压测时间,等.

c) 架构设计前期的POC测试；

d) 调优测试；

e) 代码合并后的性能基线回归测试;

敏捷开发项目

敏捷开发项目采用的测试方法和标准项目有所不同。其原则：

a) 容量和性能验证需要拆分为以迭代为阶段性性能测试, 建立阶段性能基线和目标；

b) 迭代回归测试；

c) 系统集成容量及性能验证测试；

d) 稳定性测试；

e) 代码合并后的性能基线回归测试；

 

4.8 数据库

本项为选填项，根据实际需求填写

 

分数据库配置及表配置：

• 数据库连接数配置

• 数据库读写频率、次数（如在4.8容量及性能分析中涉及，在此可无需赘述）：

• Zdal配置（区分主库、FO库里面分段分库分表路由配置）

• 数据表结构、数据表字段含义变更，如：下游消费者，商户账单

• PK\UK键及索引

• 订单号：

λ 订单号系统内部确保不会产生重复，符合相关规范（比如长度、分段标准、分表规则等规范），重点评估对分表、历史库、弹性、FailOver等数据方案的影响；

λ 数据库自增值不建议使用，建议使用zdal的sequence组件获取；

λ 订单号容量是否满足业务目标，评估sequence的步长、缓存量、起始值、最大值、重复周期是否设置合理；

 

4.9 兼容性

本项为选填项，根据实际需求填写，涉及到数据库表字段结构或者语义变更的，本项为必填项

4.9.1 数据兼容性

• 老的数据结构是否可以运行在新代码之上，避免发布期间，出现线上问题。
• 新的数据结构是否可以运行在老代码之上，避免预发布时，出现线上问题。
• 代码结构的变更，是否能兼容处理历史数据。（如05年注册的数据中，部分register_from字段是空的）
• 数据查询

4.9.2 浏览器兼容性

• 如果本次项目内容涉及页面开发或前端代码变更，须进行浏览器兼容性测试分析，分析结果须与前端开发工程师确认，并在此说明是否进行浏览器兼容测试，以及原因分析；
• 如需进行浏览器兼容性测试，需将测试范围在此说明。参照最新版本 《浏览器兼容性测试指南》 制定兼容性测试策略、组织设计对应测试用例，并经过前端开发工程师参与测分评审确认。

4.9.3 客户端兼容性

4.10 稳定性

4.10.1 监控

本项为必填项，需包含本需求中新增的监控。如本次无新增监控，必须说明原因

• 业务趋势
• 异常报警
• 错误码大盘
• echeck告警（数据一致性，数据正确性）
• eplan预案，数据修复（数据一致性，数据正确性）

4.10.2 灰度

本项为必填项，需包含本需求灰度方案。无灰度不上线；灰度方案几种场景：

1、功能接口迁移：必须有流量对比方案

2、新增功能：必须满足对单一店铺或单一用户等最少颗粒度的灰度方案；百分比的灰度方案

3、无需发布重启应用，即可调整的灰度方案

4、灰度策略，必须保证对原有逻辑代码改动为0的原则

 

• 支持百分比灰度切流
• 支持白名单、黑名单（如果有需要）

4.10.3 可回滚

本项为必填项，无回滚方案不上线；回滚方案必须含有非版本回切的实现方案，

如果回滚对脏数据/出错的数据的处理需要体现

• 业务代码
• 数据
• 版本回切

4.10.4 可降级

本项为必填项，需包含本系统改造内容对上游是否是强依赖，不可降级；如不可降级，原因需要说明，如何满足1/5的手段需要说明。本系统如可降级，填写降级方案；本次改动依赖下游哪些可降级，哪些不可降级，可降级，降级方案说明，不可降级说明原因

（要求开发系分中也包含此项内容）

• 具备降级、熔断止血应急能力
• 降级后的功能分析

4.10.5 业务报表

本项为必填项，需包含本次改动是否需新增离线报表。如无新增，请说明原因。新增报表在上线后，1-2个工作日完成

4.10.6 预案

本项为必填项，需包含本次改动新增预案。如无新增，请说明原因。

5 测试计划

本项为必填项

时间	内容	负责人
	测分
	测试用例
	交付测试
	测试执行（第一轮）
	测试执行（第二轮）
	SIT
	预发布
	发布

 

6 困难及风险

基于以上的分析，这里给出项目内存在的风险和困难，并对这些风险和困难进行跟踪，

如：质量方面、稳定性相关、以及上下游等外围系统带来的：

风险描述	提出人	建议规避措施	备注

 

7 附录：