1.需求分析

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

A. 一对一
B. 一对多
C. 多对多

1.2 系统架构分析

A. 业务实现需求
B. 系统架构为保证实现业务需求而设计的架构

B.1 业务逻辑是否有效、可靠
B.2 数据通信机制是否有效、可靠
B.3 被测系统边界是否规范、可靠
B.4 各个接口是否完整，可测接口名、参数、以及简要说明
B.5 日志系统是否完备，具有可参考性

2.功能性测试分析

2.1 子系统需求功能映射

A. 确保测试到需求及开发的覆盖

a. 流程梳理

a.1 跨流程职能图梳理业务
a.2 业务流转图```

B. 按子系统、功能模块划分

b.1 交互时序图（两个及以上系统交互必须有此图形）

Alt text

2.2 外部接口测试分析

A. 重点接口描述
B. 重点接口幂等性分析重复处理一次请求、生成脏数据、重复扣款、打款等严重缺陷

b.1 重复请求测试
b.2 并发测试

2.3 数据迁移测试

A. 数据初始化测试
B. 数据迁移方案测试
C. 数据读取兼容测试
D. 数据性能测试

3. 非功能性测试分析

3.1 性能测试分析

3.1.1 数据来源

A. 系统设计中明确业务性能要求的
B. 通过数据仓库抽取线上监控数据、线上应用系统有多少台部署、数据库的访问次数等信息
C. 项目新建系统、服务访问方式变更、服务处理方式变更等信息

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

A. 新增或改造系统及服务的访问量和对应的流量模型而产出的稳定平均事 务处理(TPS)的能力;极限(TPS)的处理能力
B. 提供与交易创建或交易付款的比例关系
C. 根据当前部署架构中的集群大小，评估峰值访问量与集群峰值处理能力
D. 对于一级服务，峰值访问量/峰值处理能力应小于 50%
E. 对于二、三级服务，峰值访问量/峰值处理能力应小于 75%

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

A. 得到服务访问量，根据应用依赖关系，计算出该服务对每一个内部依赖服务的访问量
B. 需要确保每一个内部依赖服务的总访问量不超过该内部依赖服务集群的处理能力

一级服务应小于 50%，二、三级服务应小于 75%,对于新增或改造项目峰值访问 量/峰值处理能力不得小于 10%)

3.1.4 外部依赖服务的访问量

A. 根据SLA要求评估外部依赖服务的容量是否满足要求
B. 与外部依赖服务的提供商进行沟通，明确提出要求，并在必要时进行扩容

3.1.5 对关键业务及联络的系统影响评估

A. 判断新增系统或服务对其他相互被依赖系统的影响，关注上下游的依赖关系
B. 改变实现方式，必须合并代码在项目中进行性能测试来对关键业务进行评估

3.2 测试方法

3.2.1 标准项目

A. 通过负载压力测试找出系统的稳定性事务处理能力。 极限处理能力
B. 通过 24 小时 x N 天的稳定性测试，保证系统的稳定性

连接池，session， 资源获取时的偶然竞争造成死锁、排队等现象
稳定性压测的时间长度,可根据具体情况适当减少，比如按照 JVM FullGC 发生次数决定稳定性压测时间等```

C. 架构设计前期的 POC 测试
D. 调优测试
E. 代码合并后的性能基线回归测试

3.2.1 敏捷开发项目

A. 容量和性能验证需要拆分为以迭代为阶段性性能测试, 建立阶段性能基线和目标
B. 迭代回归测试
C. 系统集成容量及性能验证测试
D. 稳定性测试
E. 代码合并后的性能基线回归测试

3.3 风险评估

3.3.1 资损风险

Alt text

3.3.2 安全性

A. 数据来源：PRD、系统设计、安全工程师建议
B. 测试策略：工具扫描、手工测试
C. 输入输出安全

c.1 用户输入信息校验
c.2 页面展示信息过滤

D. CTU相关

(./1511575946451.png)

E. 认证与授权

e.1 注册：恶意用户注册
e.2 授权：一些重要信息或系统访问控制

F. 会话管理：会话安全
G. 加密机制和密钥管理
H. 第三方安全
I. 敏感数据：输入、传输、存储、展现

3.4 并发测试

凡涉及到不同系统间交互，有可能能导致错误数据的并发操作才需要做并发测试
包括但不限于：不同用户数据的并发、相同用户数据的并发

3.5 消息传递

httpclient、XFire 同步传递
TBNotify、ESB 异步传递

3.6 分布式事务

分布式事务可能会引起异常回滚失败等异常
分析思路：项目中是否有用到分布式事务
测试准备：需要至少两台测试目标机器, 以及一个分流工具

3.7 健壮性

如何对异常的数据进行测试

3.8 可维护性

各种项目中需要配置的内容，是否都使用灵活的配置方式，便于后续的维护，包含：数据库配置、XML 配置文件等

3.9 兼容性

3.9.1 数据兼容性

A. 老的数据结构是否可以运行在新代码之上，避免发布期间，出现线上问题
B. 新的数据结构是否可以运行在老代码之上，避免预发布时，出现线上问题
C. 代码结构的变更，是否能兼容处理历史数据
D. 数据查询

3.9.2 浏览器兼容性

3.10 系统日志

A. 否将敏感数据(短信校验码，身份证号码，银行卡等)打印到日志中
B. 输出的日志级别是否合适?比如提醒类的日志是否打成了 error 级别
C. 需求中是否有对日志存储方式，时间上的要求
D. 测试过程中对 Log4j.properties 配置的日志存储时间等信息进行 check

3.11 LDC

A. 如果是新建系统，考虑是否应放入 RZone(目前 RZone 中主要是关键业务路径或关键业务)
B. 如果系统已在 RZone，或者准备放入 Rzone 中

b.1 在本项目中是否新增了对 GZone 中系统提供服务的依赖，如果新增了依赖则需要 确保正确配置了相应 VIP 地址，并确保当前的 sofa 版本支持 VIP 地址设置(Sofa 版本>=2.1.5)
b.2 页面级系统根据业务的实际情况分析是否需要进行跨 zone 的调用
b.3 接口级系统(目前只涉有 TBAPI)关注特殊的接口新增或变更。如:涉及文件上传/下载等、UTF-8，带中文、post 请求、session 设值如付款、参数超长等
b.4 如果该系统根据 uid 进行再次路由和转发，需要定制不同的路由规则，请分析整个业务链接到数据落地，均在同一 RZone 内完成

C. 如果系统只在 Gzone 中，不需要分析 LDC 影响。