测试开发新人手册分为3部分。

1、基础篇 – 如何开始你的第一个测试项目

2、进阶篇 – 做专业的测试

3、思考篇 – 稳定性保障&测试技术创新

2. 进阶篇 – 做专业的测试

2.1 如何做到测试场景不遗漏？

2.1.1 测试分析与设计

测试是一门精细的学科，新人同学很容易有的误区是认为做测试主要就是写测试用例和执行，进阶能力是做自动化或工具。而实际上，测试人员最难修炼的能力是分析设计能力，测试分析能力是衡量一位测试同学是否专业的分水岭。分析除了使用方法，还需要有对业务、经验、质量的深度理解。自动化或工具实际是对分析和设计结果的一种实现，分析和设计的有效会决定实现的效果。

2.1.1.1 分析与设计过程

测试分析要从业务需求最开始就要介入，流程覆盖业务整个生命周期。在做分析的过程会思考清晰整体后续的设计怎么做。

测试分析可总结为四步：

• 建模 - 输出业务/系统流程（分析：业务流程 - 系统流程）
• 设计 - 测试场景（设计：测试场景）
• 细分 - 测试用例/数据（设计：测试用例）
• 扩展 - 多类型测试（性能，安全，经验。。。）（基于经验）

2.1.1.2 测试场景分析实施

测试场景和测试用例区别是什么？为什么先要设计测试场景？

上图也描述了，测试场景对应的是实际的业务场景，业务场景是业务流程中因不同的事件触发后的业务情景。比如银行取款的业务办理流程，会因为用户的身份（VIP与否）、取款金额（大额，小额）、卡内余额（足额取，不足额取）等诸多因素，导致最后取款的结果和过程分支产生不同。测试场景就是对这类事件触发时的业务情景在质量角度的描述。而测试用例是对测试场景在测试范围和测试点的详细覆盖。

第一步:根据业务的目标（价值）、类别、技术等输入，确定业务场景分析的范围。

业务分析就是需求分析的过程。这里不仅仅考虑需求的功能逻辑，还需要结合不同业务类型，根据历史业务经验沉淀和风险沉淀进行综合考虑。可以参考用下图进行前期梳理。

需求类型	资源&方法需求	必须覆盖点
主业务类需求
技改类需求
全链路
外部商家需求
大促&BU核心项目

第二步：业务流程梳理（业务场景）

将需求说明转化为业务流程，完成事件流（基本流+备选流）以及业务分析过程和技术分析过程的梳理。细化出原子级别的场景分支。

事件流：同一事件不同的触发顺序和处理结果形成事件流，事件流分为基本流和备选流

基本流：程序从开始执行直到成功结束所经过的最短路径。

备选流：一个备选流可能从基本流开始，在特定条件下执行，然后重新加入基本流中；也可起源于另一个备选流，执行后加入基本流或终止用例。根结点的备选流要具备原子性。

基本流和备选流：如下图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流2和4）；也可能起源于另一个备选流（如备选流4），或者终止用例而不再重新加入到某个流（如备选流1和3）。

实例：

第三步：场景串联

通过第二步中拆解的场景，根据沉淀后的场景集，用组合，合并等方法梳理出所有的事件流。事件流必须100%覆盖所有的基本流+备选流组合。

例：

2.1.1.3 测试用例设计

测试用例的设计很多时候是测试数据设计的过程，根据事件流（基本流+备选流）和数据，根据不同的角色。进行用例覆盖。需要确保所有场景100%覆盖。

例：

2.1.1.4 非功能性设计扩展

测试用例在设计上除了考虑功能性质量属性，还需要对非功能性进行覆盖，推荐一个四字法进行设计。

• 多：针对测试用例进行大数据量覆盖测试
• 并：针对测试用例进行大数据量同时执行，验证并发下的测试结果
• 复：重复的参数对同一用例进行执行测试。验证幂等结果是否符合预期。
• 异：用非正常输入值进行用例测试。验证结果的正确性。

2.1.2 测试策略

策略其实考虑两个问题，过程和方法：“测什么“，“怎么测“。

• 你的测试对象是什么？
• 本次测试的目标是什么
• 测试中重点、难点、风险是什么
• 测试要覆盖的深度和广度
• 如何安排各种测试计划（先测什么，再测什么，时间资源安排）
• 如何准出（测试结果）

2.1.2.2 测试策略可参考模版&样例

业务整体概述

#业务背景

#产品目标

#架构目标：

#业务目标

项目整体分析

#功能性需求拆解

##核心业务模块介绍，复杂度，测试点分析对应列表（此步骤为关键分析步骤）

测试分析功能点，要从产品质量标准的角度思考。针对质量特性进行功能点覆盖。

名称	说明	使用场景

测试覆盖范围（涉及针对哪些质量要求的测试方式）：

功能性、性能效率、兼容性、易用性、可靠性、安全性、易维护性、可移植性

PRD需求	优先级	质量特性	测试覆盖度评估（深度和广度）	负责测试人员
		功能性
		功能性，性能效率
		安全性，功能性

##测试对设计方案覆盖范围(根据开发设计文档罗列)

序号	接口/设计名称	接口描述	对应产品码/功能描述

#业务流程分析

##被测功能总体概述

##整体业务流程：

##业务模型图：

##风险分析

测试场景覆盖范围

##测试场景

根据上一步的业务/系统流程图，完成测试场景的设计

##测试用例设计（完善测试用例，补充测试数据）

根据测试场景细化测试用例，测试用例必须对测试场景和测试覆盖范围进行100%覆盖。

##测试数据要求

##其他测试补充

测试执行计划

人员组织

测试实施计划

交付计划

2.1.4 测试报告

2.1.4.1 测试报告

测试报告实际就是一个质量评估的过程。内容的关键在于表达清晰两点：报告的对象是谁？报告的内容是什么？测试报告不是一个项目整体结束之后的产物，而是应该在项目整个生命周期随时同步的。

测试报告至少需要包括的信息：

• 项目背景信息
• 项目人员
• 测试覆盖度（需求、功能性、非功能性）
• 测试过程分析（执行情况）
• 缺陷分析
• 质量目标是否达到
• 遗留风险以及应对措施

---

2.2 成为测试多面手

2.2 成为测试多面手

2.2.1 移动应用测试

2.2.1.1 移动应用分类&特点

• Web App

Web App就是用H5开发的应用，在移动端浏览网站应用。优点是开发和发布成本低，直接服务端发布，迭代速度快；缺点是性能和体验比较差，加载速度慢。

• Native App

传统的原生App开发模式，有Android和iOS两大系统，需要基于各自的平台，用特殊的开发语言开发对应的应用。

• Hybrid App

混合模式移动应用，介于Web App、Native App这两者之间的App开发技术，兼具“Native App良好交互体验的优势”和“Web App跨平台开发的优势”。

• H5、WEEX、Native和小程序

WEEX：Weex 致力于使开发者能基于通用跨平台的 Web 开发语言和开发经验，来构建 Android、iOS 和 Web 应用。简单来说，在集成了 WeexSDK 之后，你可以使用 JavaScript 语言和前端开发经验来开发移动应用。

小程序：小程序是一种不需要下载安装即可使用的应用，它实现了应用“触手可及”的梦想，用户扫一扫或者搜一下即可打开应用。也体现了“用完即走”的理念，用户不用关心是否安装太多应用的问题。应用将无处不在，随时可用，但又无需安装卸载。

手淘作为一个航母级App，集成了H5、WEEX、Native和小程序于一身，各司其职。

2.2.1.2 移动应用测试流程

静态测试包括需求分析、需求测试、需求建模；

测试计划包括测试范围、测试策略、执行计划；

测试设计包括功能测试以及其他测试类型的方案设计；

功能测试需要在迭代中改变测试重点和风险分析。

特别强调的是对于集团要求的稳定性压倒一切，务必进行稳定性测试、性能测试、安全测试和适配测试。

2.2.1.3 移动应用测试方法&工具&平台

• 移动应用测试方法

测试方法	方法介绍
真机测试	下载对应的安装包安装，执行对应的测试。
模拟测试	mock测试就是在测试过程中，对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来创建以便测试的测试方法。
流量测试	目前的网络类型包含2G3G4Gwifi，其中还有不同运营商的区分，我们在APP的使用中经常遇到大资源，重复请求，调用响应慢，调用失败等各种情况。在不同的网络类型之下，我们不仅要控制流量使用，还需要加快请求的响应。 流量测试可以给我们带来什么？ 1.可以让我们很清楚的知道用户在某种场景下使用我们的产品需要消耗多少流量。 2.流量数据分析可以指导我们去做优化；比如cgi的调用和参数设置是否合理，有些资源或者配置是否可以本地化？ 3.流量的优化可以带来速度的优化；减少tcp数据包的个数，或者直接减少请求数都可以带来速度的优化。
耗电测试	App使用过程中的电量测试，慎重检查App的电量使用，以免导致用户手机耗电发热，带来不良体验。
中断测试	中断测试指运行中被其他任务或意外事件等情况终止退出，相应的测试即为中断测试。中断测试有人为中断，新任务中断，以及意外中断等几种情况，通过中断测试，确认App的恢复情况。
性能测试	性能测试主要关注：CPU、内存、FPS和响应时间。
兼容性测试	移动端兼容性测试，主要测试App在Android不同的设备OPPO、VIVO、HUAWEI等设备，在Android不同的系统4.X、5.X、6.X、7.X、8.X等系统的兼容性，确认是否有功能、性能和稳定性问题；App在iOS不同的设备iPhone6、iPhone7、iPhoneX等设备，在iOS不同的系统9.X、10.X、11.X、12.X、13.X等系统的兼容性，确认是否有功能、性能和稳定性问题。
弱网络测试	弱网测试主要在宽带、丢包、延时的弱网环境中，验证客户端的展示、以及丢包、延时的处理机制，确认是否有功能、性能和稳定性问题。
压力测试	通过对CPU、内存、存储等加压，确认是否有功能、性能和稳定性问题。

• 移动应用测试工具介绍

工具	工具介绍
ADB	ADB常用指令： 1. 获取序列号： adb get-serialno 2. 查看连接计算机的设备： adb devices 3. 重启机器： adb reboot 4. 重启到bootloader，即刷机模式： adb reboot bootloader 5. 重启到recovery，即恢复模式： adb reboot recovery 6. 查看log： adb logcat 7. 终止adb服务进程： adb kill-server 8. 重启adb服务进程： adb start-server 9. 获取机器MAC地址： adb shell cat /sys/class/net/wlan0/address 10. 获取CPU序列号： adb shell cat /proc/cpuinfo 11. 安装APK： adb install <apkfile> //比如：adb install baidu.apk 其余命令查看文档：https://blog.csdn.net/ekeuy/article/details/43112645
Monkey	Monkey官网
自动化框架	Appium ATX
打包工具	建议使用MTL打包，其他打包方案： 本地无成本打包 gradle打包
设备管理平台	设备使用，可以建立设备实验室来管理
Mock工具	通过Charles进行Mock测试 通过Moke平台进行mock测试

2.2.1.4 经验集 - 工具平台操作实战

本章通过实战案例，对移动应用测试流程、工具、平台进行更为详尽的介绍。

• 如何通过Charles进行Mock测试？

1.、charles的作用

Charles 是在 Mac下常用的网络封包截取工具，在做客户端测试时，我们为了调试与服务器端的网络通讯协议，查看在不同场景下，前端request和后端response是否正确，常常需要截取网络封包来分析。

2、charles的原理

Charles 通过将自己设置成系统的网络访问代理服务器，使得所有的网络访问请求都通过它来完成，从而实现了网络封包的截取和分析。

基于安全性考虑，我们的项目目前也在逐渐从HTTP转向HTTPS，HTTPS协议是在HTTP协议的基础上，添加了SSL/TLS握手以及数据加密传输，那么charles如何做到解密https请求的呢？首先需要了解HTTPS的通信过程：

3、https通信原理：

第一步：client向server发出加密通信的请求，包括支持的协议版本和加密方法等；

第二步：server回应，发出确认协议版本和所使用的加密方法，以及server端证书（带公钥）；

第三步：client进行证书的校验，查看证书是否是信任机构颁发的，证书没有问题，客户端就会从证书中取出服务器的公钥，然后根据携带的随机数生成密码，使用公钥加密；

第四步：client把加密的密码发给server；

第五步：server用自己的私钥对该加密内容进行解密，验证密码的真实性；

第六步：服务器握手结束通知，表示服务器的握手阶段已经结束；

第七步：客户端解密并计算握手消息的HASH值，如果与服务端发来的HASH一致，此时握手过程结束；

第八步：使用公钥，进行加密通信。

4、charles抓取https包

使用charles抓https包时， https 连接旁边都有一个锁的图标，看不到具体的请求和返回，如下图所示。

根据上面所说的https的通信原理，SSL 代理需要安装证书，在客户端和服务端相互信任之后，才能进行加解密的通信，才能捕获信息。那么mac上的charles就相当于服务端，需要有合法的证书，且该证书受客户端信任。下面介绍证书的安装和信任过程。

安装证书过程

第一步：mac上安装 Charles 证书，添加完成以后还要将其设置为「始终信任」

第二步：手机上下载

安装完成以后，iOS 可以在 设置 -> 通用 -> 描述文件与设备管理 里看到 Charles 相关证书，然后信任它。

第三步：开启 SSL 代理，设置域名白名单

只有发到这个域名下的请求，才可以被解析

5、charles的常用功能 - 抓包

第一步：手机连接代理

第二步：mac上点击“allow”，允许连接

第三步：查看抓包

6、mock数据

在测试前端展示的各种场景时，如果后端接口的返回值不满足前端场景要求，则可以使用charles做mock数据，屏蔽掉后端的真正返回值，而使用自己预先准备好的返回值。

7、DNS 欺骗

作用相当于配置hosts文件，把域名解析到指定的 IP。

点击Tools -> DNS Spoofing

8、域名重定向

charles可以重定向域名。

点击Tools -> Map Remote

比如，预发和线上代码是通过域名来区别的，而请求中的cookie等参数难以构造时，可以直接使用线上版本访问，避免自己构造请求参数，然后通过连接charles代理，把正式环境的url转为预发环境的url

2.2.2 服务端测试

服务端测试有两种：一种是直接对WEB或者APP的API接口进行测试；另一种是对更后端的数据库、缓存系统、中间件、文件系统等进行测试，核心就是输入输出是否符合服务设计。必备的测试手段包括接口测试、性能测试、稳定性测试、异常测试。稳定性测试中涉及：异常、超时、重试幂等、性能等

2.2.2.1 基于API的服务端测试

这种服务端就是为WEB／APP端提供一些后台的接口，一般都是用HTTP、HSF、MTOP接口的方式提供。这种后台的测试从流程上来说是跟随着发布节奏来的，根据时间、提测以及持续集成目标，可以采用不同的测试方法：

• 手工接口测试

根据接口设计，测试人员可以借助中间件平台，自有工程，第三方工具进行接口测试了。接口测试过程中，特别需要关注异常场景测试，单接口异常测试主要包括输入异常、操作异常、依赖服务异常，测试验证时关注容错逻辑以及异常返回码是否符合接口约定。

输入异常：包括入参为特殊字段类型、非法长度、边界值等操作异常：例如操作为特殊业务流程、非法修改数据等非正常业务操作依赖服务异常：包括访问超时、服务挂掉、异常返回码等场景

• 手工集成测试

待需求的前端和上下游都交付之后就可以进入集成测试阶段，在这个环节测试人员除了协调各涉及端的测试进度、测试环境和自己域的业务验证之外，同样需要关注异常测试，集成阶段的异常主要包括输入异常、接口异常、操作异常，测试验证时关注异常文案交互是否符合业务预期。

输入异常：包括入参为特殊字段类型、非法长度、边界值等接口异常：例如接口超时、非约定返回码等操作异常：业务流程中高频导致的并发、乱序等非法操作场景

异常测试主要分为功能异常、服务端异常

1）功能异常主要通过各种入参模拟进行验证，接口测试目前可用自建平台、postman以及其他任意接口测试平台

测试常用功能介绍：1）保存参数、导入参数：平台支持保存当前参数模板，方便下次导入调用，但需注意仅支持保存一套参数2）自定义Timeout：可以自定义时间，越过接口原超时限制，mock超时场景下接口返回3）指定Provider调用：指定IP进行调用，便于调试和问题定位4）活用执行结果信息：接口执行失败需要上下游配合排查定位时，traceId、Provider是关键排查参数注意事项：1）特定角色才能在控制台进行hsf接口测试（例如测试负责人）2）入参输入建议切换到Code模式下编辑，以免类型转换错误

2）服务端异常目前主要可通过一些强弱依赖平台进行验证，很多平台支持对线上流量自动进行分析并生成用。

• 持续集成

借助类似Jenkins工具平台完成手工测试的自动化持续集成，实现接口级别的回归和链路级别的回归。

2.2.2.2对更后端的数据库、缓存系统、文件系统等中间件进行测试

对于这类后端服务来说，接口只是暴露给外用的部分，内部逻辑通常是非常复杂的，所以，除了针对接口做测试之外，测试人员还需要细致地了解这些服务端产品的技术框架及技术实现，需要了解到模块的级别，对于系统框架图、时序图等都有很好的理解，针对这些理解去设计用例和执行。下面介绍几种常见中间件的测试思路和方法：

• 模拟消息发送，验证消费消息后的代码逻辑

打开消息控制台，找到对应的topic点击发送，输入body消息后确定发送

• 验证metaq消息是否按照约定发送

打开metaq控制台，点击进入“消息查询”，查看消息体和轨迹，验证是否符合期望

• DTS任务的调试

schedulerx分布式系统调度任务的调试和排查可以使用控制台

编辑：输入job运行参数触发一次：手动触发指定机器：可以勾选指定job运行的服务器

2.2.3 性能测试

2.2.3.1 概念&目的

性能测试是从业务中提取压测模型，然后利用压测工具按照模型制造压测流量，并对目标应用集群进行施压，在施压过程中观察应用集群的性能表现和发掘性能瓶颈的测试行为。

当前性能测试主要分为线上压测和线下压测。线上压测主要通过全链路压测执行，线下压测是单机(或者小集群)压测。

全链路压测请看全链路压测章节，本节主要讨论通用性能测试方案和流程。

2.2.3.2 常用指标

1. 虚拟用户

虚拟用户，模拟真实业务逻辑步骤的虚拟用户，虚拟用户模拟的操作步骤都被记录在压测脚本里。压测脚本用于描述虚拟用户在场景中执行的操作。

2. Transaction压测事务

事务是性能测试脚本的一个重要特性。要度量服务器的性能，需要定义事务，每个事务都包含事务开始和事务结束标记。事务用来衡量脚本中一行代码或多行代码的执行所耗费的时间。可以将事务开始放置在脚本中某行或者多行代码的前面，将事务结束放置在该行或者多行代码的后面，在该脚本的虚拟用户运行时，这个事务将衡量该行或者多行代码的执行花费了多长时间。

3. TPS每秒事务数

TPS(Transaction Per Second)每秒钟系统能够处理的交易或事务的数量，它是衡量系统处理能力的重要指标。

备注：在日常工作中也会用到TPS和QPS，在应用层，所有的请求都可以用QPS或者TPS来表示；但在DB层，TPS和QPS有区别，QPS指的是select的请求量，TPS指的是insert、update和delete的请求量

4. Peak PV 高峰Page View

即PV峰值，指一天中PV数达到的最高峰。

5. Concurrency并发

并发分为狭义和广义两类。

狭义的并发，即所有的用户在同一时刻做同一件事情或操作，这种操作一般针对同一类型的业务，或者所有用户进行完全一样的操作，目的是测试数据库和程序对并发操作的处理。

广义的并发，即多个用户对系统发出了请求或者进行了操作，但是这些请求或操作可以是不同的。对整个系统而言，仍然有很多用户同时进行操作。

狭义并发强调对系统的请求操作是完全相同的，多适用于性能测试、负载测试、压力测试、稳定性测试场景;广义并发不限制对系统的请求操作，多适用于混合场景、稳定性测试场景。

6. 压测场景

为了模拟真实用户的业务处理过程，从被压测业务中抽取出目标压测接口，并封装成压测脚本，该抽出出来的目标压测接口即为一个压测场景。

7. Response Time响应时间（RT）

响应时间是指从客户端发一个请求开始计时，到客户端接收到从服务器端返回的响应结果结束所经历的时间，响应时间由请求发送时间、网络传输时间和服务器处理时间三部分组成。

8. Think Time思考时间

模拟正式用户在实际操作时的停顿间隔时间。从业务的角度来讲，思考时间指的是用户在进行操作时，每个请求之间的间隔时间。在测试脚本中，思考时间体现为脚本中两个请求语句之间的间隔时间。

9. CPU资源

CPU资源是指性能测试场景运行的这个时间段内，应用服务系统的 CPU资源占用率。CPU资源是判断系统处理能力以及应用运行是否稳定的重要参数。应用服务系统可以包括应用服务器、Web服务器、数据库服务器等。

10. Load负载

系统平均负载，被定义为在特定时间间隔内运行队列中的平均进程数。如果一个进程满足以下条件则其就会位于运行队列中:

• 它没有在等待 I/O 操作的结果。
• 它没有主动进入等待状态(也就是没有调用“wait”)。
• 没有被停止(例如:等待终止)。

2.2.3.3 性能测试策略

1. 模拟生产线真实的硬件环境。

架设与生产环境相似的性能测试环境，使用物理机作为服务器。例如，使用4核CPU、8G内存的机器模拟生产环境的应用服务器；使用共用存储的数据库服务器等。

2. 服务器置于同一机房，最大限度避免网络问题。

所有性能测试的服务器都放置在同一个机房，属于同一个网段，服务器与服务器之 间的网络交互通过交换机进行。

3. 以 PV 为切入点，通过模型将其转换成性能测试可量化的 TPS。

互联网的特点，是在线用户不断变化，很难统计到具体某个应用的在线用户数；但是页面是固定的，可以统计的。用户U访问了P页面的行为，是能捕获的。换句话，对于页面 P，不管当前有100个用户，还是1000个用户在使用，页面的Page View都是可以统计到的。

因此，以PV为性能测试切入点，作为性能测试的突破口。通过这种方式，可以将页面流量直接转化成Page View，作为性能测试的预期目标，而削弱在线用户数和并发用户数。得到PV数值之后，再通过PV计算模型、PV->TPS转换模型，将它转化成测试工具可以衡量的指标TPS，从而使复杂的模型变得简单化、可衡量化。

4. 性能测试数据分为基础数据和业务数据两部分。

性能测试数据库和功能测试库相互独立。性能测试数据分为基础数据和业务数据两

部分。基础数据，指为了使表中的数据达到一定的数量级而填充的数据，目的是测试出数据库索引是否足够优化、表空间、索引空间是否足够；业务数据，指为了使被测系统 能够按业务逻辑运行起来的数据，通俗而言，就是功能测试所使用的数据，目的是测试 出SQL语句是否足够优化、代码是否足够优化等。

5. 日志等级设置成 warn，避免大量打印日志对性能测试结果的影响

JAVA 日志，分为 info ,debug ,warn ,error 四个级别。打印日志会消耗服务器的IO，也会消耗硬盘存储空间。在性能测试过程中，如果频繁打日志，会导致IO消耗大，从而消耗服务器的CPU资源；也会导致日志文件过大， 写入困难，程序执行速度变慢等问题。而 info 和 debug 两个级别，都会打印大量日志。因此，性能测试过程中，选择将日志等级设置成warn级别，只打印出warn和 error 的日志，即减少日志输入数量，又能监控到性能测试过程中出现的错误，一举两得。

6. 屏蔽缓存，模拟最坏的情况

缓存，是页面性能优化的手段之一。对于非频繁变化的数据，可以在容器中缓存起来，提高读的性能，同时减轻数据库压力。缓存必须在数据被访问过后才会生效，另外，缓存失效后需要重启缓存，即在系统刚发布、重新缓存过程中，用户访问速度会变慢、数据库压力也会加大。

为了避免类似系统刚上线，数据库就受到Load过高，甚至面临崩溃的灾难。在性 能测试过程中，我们需要模拟没有缓存的场景。

7. 先单场景，后混合场景，确保每个性能瓶颈都得到调优。

性能测试过程中，选择先执行单场景，后执行混合场景的策略。

单场景执行，可以详细测试到某个页面、某个接口等“单点”的性能，这种方式有 利于定位性能瓶颈，优化代码。对于使用 HSF 方式通信的系统来说，这样的针对性测试效果非常显著。

混合场景，在单场景都优化完成后，按照一定的比例对各种场景进行组合，测试整个应用系统的总体性能表现。

其实，单场景和混合场景，两种都不可缺少。

8. 拆分问题，隔离分析，定位性能瓶颈。

性能测试过程中出现的小概率事件，往往隐藏着大的性能瓶颈。为了精确定位到瓶 颈，需要将各个应用，或者一个应用的各个环节进行拆分，逐渐隔离掉没有问题的部分， 然后在可能有问题的部分进行再排查，直到瓶颈定位到为止。

9. 根据业务系统要求，来判断被测性能点通过与否。

结合当前系统复杂度和业务能力要求，来评判当前性能点的性能结果是否满足需求。

10. 性能瓶颈

录入AONE进行跟踪，对于不能在当前项目中解决的性能 bug，邀请专家组进行风险评估。

2.2.3.4 性能测试评估

制定性能测试策略之后，如何开展性能测试工作呢？在实施性能测试之前，需要对被测项目做相应的评估。实施前的评估，主要目的是明确是否需要做性能测试和确立性能点，明确该测什么、期望值是多少。测试期望值也会根据情况评估，要求被测系统能满足将来一定时间段的压力。性能测试评估分为测试前的评估和测试后的评估。这里重点阐述测试前的评估。主要从以下 4 个维度进行测试前的评估:

• 关键业务。
• 日PV量。
• 逻辑复杂度。
• 运营推广计划。

1） 关键业务

首要维度，是确定被测项目是否属于关键业务，有哪些主要的业务逻辑点，特别是跟交易链路息息相关的功能点。例如，购物车系统，用于购物车浏览、购物车添加、购物车删除、购物车凑单等功能。通过评估，从中筛选出购物车浏览和添加这两个主要业务涉及的功能。

如果项目(或功能点)不属于关键业务(或关键业务点)，则可转入第二、三、四个维度进行评估。

2） 日PV量

第二个维度，是界定被测项目各功能点的PV量(或者日请求量)。如果PV量很高，系统压力很大，而且又是关键业务，该项目需要做性能测试；而且其关键业务点，可以被确定为性能点。

如果PV量不高，系统压力不大，但却是关键业务点，则依据第三个或第四个维度来判断。

3） 逻辑复杂度

第三个维度，是判定被测项目各功能点的逻辑复杂度。如果一个主要业务的PV量不高，但是逻辑很复杂，则也需要通过性能测试。原因是，在集团庞大的业务系统调用中，当某一个环节响应较慢，就会影响到其它环节，造成雪崩效应。

4） 运营推广计划

第四个维度，是根据运营的推广计划来判定待测系统未来的压力。未雨绸缪、防患于未然、降低运营风险是性能测试的主要目标。被测系统的性能不仅能满足当前压力，更需要满足未来一定时间段内的压力。因此，事先了解运营推广计划，对性能点的制定有很大的作用。例如，运营计划做活动，要求系统每天能支撑多少PV、多少UV，或者一个季度后，需要能支撑多大的访问量等等数据。

当新项目(或功能点)属于运营重点推广计划范畴之内，则该项目(或功能点)也需要做性能测试。

5） 其它

以上4个评估维护，是相辅相成、环环相扣的，它们合成一个维度集。在实际工作中，应该具体问题具体分析。例如，当一个功能点不满足以上4个维度，但又属于内存高消耗、CPU 高消耗时，也可列入性能测试点行列。

2.2.3.5 性能测试类型

随着单位时间流量的不断增长，被测系统的压力不断增大，服务器资源会不断被消耗，TPS 值会因为这些因素而发生变化，而且符合一定的规律，性能测试压力变化模型如图1所示。

图1 性能测试类型图

图1中:

a 点：性能期望值

b 点：高于期望，系统资源处于临界点

c 点：高于期望，拐点

d 点：超过负载，系统崩溃

由上述压力变化模型，将性能测试分成狭义的4种类型:

a. 性能测试。

b. 负载测试。

c. 压力测试。

d. 稳定性测试。

1. 性能测试

a点到b点之间的系统性能

定义:狭义的性能测试，是指以性能预期目标为前提，对系统不断施加压力，验证系统在资源可接受范围内，是否能达到性能预期。

运用场景：此类型的测试目前最常见。每个项目的性能点，都需要做性能测试。

2. 负载测试

b点的系统性能

定义：狭义的负载测试，是指对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等。

运用场景：此类型的测试目前运用得比较少。一般情况下，是以服务器资源安全临界值为界限的测试。如果要模拟某个应用在指定服务器上最大且安全的负载量，则属于负载测试。

3. 压力测试

b点到d点之间

定义：狭义的压力测试，是指超过安全负载的情况下，对系统不断施加压力，是通过确定一个系统的瓶颈或不能接收用户请求的性能点，来获得系统能提供的最大服务级别的测试。

运用场景：此类型的测试目前运用得比较少。但对于大型的共享中心或者核心的应用，也会用到。

4. 稳定性测试

a点到b点之间

定义：狭义的稳定性测试，是指被测试系统在特定硬件、软件、网络环境条件下，给系统加载一定业务压力，使系统运行一段较长时间，以此检测系统是否稳定，一般稳定性测试时间为n*12小时。

运用场景：此类型的测试目前也最常见，针对需要长时间稳定运行的性能点，需要执行稳定性测试。往往在一个项目的性能测试过程中，会划分出优先级较高的性能点，做稳定性测试。例如:宝贝详情页面等等。

2.2.3.6 性能测试执行方法

性能测试通常采用先单场景，后混合场景的执行方法。

1. 单场景

针对单个性能测试点，构建一个性能测试场景，而进行的性能测试。单场景适用于性能测试、负载测试、压力测试、稳定性测试。

2. 混合场景

为了尽量模拟生产线上运行的业务压力或用户使用场景，测试系统的整体性能是否满足性能需求，把经过一定规则筛选的性能测试点，按照合乎实际逻辑的虚拟用户请求、并发，组合成一个混合场景。

混合场景的特征，通常包含两个或者两个以上的脚本组，执行时间较长。混合场景通常在稳定性测试、负载测试中使用。

2.2.3.7 性能监控

性能监控需要实时观察性能测试过程中各项指标是否正常，包括应用服务器、数据库、中间件、网络等方面，保证测试前提，记录测试数据，输出监控结果。更重要的是，监控的过程是发现系统瓶颈的过程，是性能分析、性能通过与否、性能报告输出等环节的基础和依赖。

监控需要使用不同的工具，结合系统日志、应用和服务器所反映的多项指标，记录监控数据。以下阐述了监控指标、监控工具和监控步骤等三个部分内容。

1. 监控指标

性能测试通常需要监控的指标包括:

a) 服务器

具体包括CPU、Memory、Load、I/O、Disk等。

b) 数据库

具体包括缓存命中、索引、单条SQL性能、数据库线程数、数据池连接数等。

c) 中间件

具体包括线程数、连接数、日志输出等。

d) 网络

具体包括防火墙、网卡、网线、吞吐量、吞吐率等。

e) 应用服务

具体包括JVM内存使用和回收、JAVA内存使用、FullGC频率、JAVA类装入和卸载、日志、线程运行状态(阻塞、等待、正常运行)等。

f) 性能监控指标

具体包括用户执行情况、场景状态、事务响应时间、TPS、Load、CPU分析图表等。

g) 测试机资源

具体包括CPU、Memory、网络、日志输出、磁盘空间、负载生成器评估等。

2. 监控工具

性能测试通常采用下列工具进行监控:

a) JStat

Jstat是JDK自带的一个轻量级小工具。全称“Java Virtual Machine statistics monitoring tool”，它位于java的bin目录下，它主要利用了JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控，包括了对Heapsize和垃圾回收状况的监控。可见，Jstat是轻量级的、专门针对JVM的工具，很实用。

b) JConsole

JConsole是一个用JAVA写的GUI程序，用来监控VM，并可监控远程的VM，易用且功能强大。具体可监控JAVA内存、JAVA CPU使用率、线程执行情况、加载类概况等，JConsole需要在JVM参数中配置端口才能使用。由于是GUI程序，界面可视化，这里就不做详细介绍。

c) JMap

Jmap是一个可以输出所有内存对象的工具，甚至可以将VM中的heap以二进制输出成文本，可以监控JAVA程序是否有内存泄漏。

d) JProfiler

JProfiler分析工具是目前功能相对比较全的JAVA剖析工具(profiler)。它可以详细的剖析CPU、线程和内存的使用信息。JProfiler可提供许多IDE整合和应用服务器整合功能。JProfiler直观式的界面让你可以方便的找到性能瓶颈、抓住内存泄漏(memoryleaks)、并解决多线程的问题。可以对内存的GC的资源回收器做深入的分析，可以轻易找出内存泄漏；JVM内存的快照(snapshot)模式可以让未被引用(reference)的对象、稍微被引用的对象、或在终结(finalization)序列的对象都清晰地呈现出来。

2.2.3.8 性能分析

性能分析从性能测试分析原则、分析信息来源、分析标准。

1. 分析原则

在分布式架构下，性能瓶颈分析也变得相对困难。针对不同的应用系统、不同的测试目标、不同的性能关注点，根据性能指标的表现，采用“拆分问题，隔离分析”的方法进行分析，即逐步定位、从外到内、从表及里、逐层分解、隔离排除。

性能分析，可按以下顺序:

中间件瓶颈(tomcat参数配置、数据库参数配置等)->应用服务日志->本应用的性能瓶颈(代码、SQL语句、索引、业务逻辑、线程池设置、算法)->服务提供者的性能瓶颈->相关联的底层存储应用的性能瓶颈

注:以上是比较通用的分析过程，具体性能测试查找瓶颈过程中，需要具体问题具体分析。

2. 分析信息来源

a) 监控工具所采集的信息。包括压测工具产出的数据以及监控的机器数据。具体为：TPS、响应时间、用户并发数、JVM内存、FullGC频率、CPU利用率、Load等。

b) 应用服务器的日志。包括本应用和远程应用的错误日志、超时日志等。

c) 项目配合人员所提供的信息。包括数据库监控信息、开发人员提供的代码逻辑信息等。

3. 分析标准

通过性能指标的表现形式，分析性能是否稳定。比如:

a) 响应时间是否符合性能预期，表现是否稳定。

b) 应用日志中，超时的概率，是否在可接受的范围之内。

c) TPS维持在多大的范围内，是否有波形出现，标准差有多少，是否符合预期。

d) 服务器CPU、内存、Load是否在合理的范围内，等等。

2.2.3.9 性能测试流程

测试流程中的主要活动描述如下:

1. 评估是否需要进行性能测试：在项目立项前的技术方案阶段，PTM/PM和PDM评估出是否需要做性能测试。

2. 性能测试资源分配：当前主要由各业务线的开发和功能测试同学负责进行性能测试。

3. 制定性能测试计划：根据项目(日常)计划和功能测试计划，制定性能测试计划。

4. 编写性能测试设计方案：在UC评审之后，邀请PM、PDM、测试负责人，一起细化性能测试需求，编写性能测试方案。

5. 评审性能测试设计方案：组织性能测试设计方案评审会议，邀请PM、系统设计人员、测试负责人、DBA等共同参与。评审主要是针对测试目标、测试策略和测试数据进行确认，并提出改进意见，达成一致

6. 提交代码、配合搭建环境、配合数据准备：线下测试，可在aone的项目环境中搭建性能测试环境，同时准备压测数据和压测脚本。

7. 执行性能测试：第一轮功能测试通过之后，执行性能测试，执行脚本需要符合规范。分析性能测试结果，找到性能瓶颈，配合开发人员进行性能调优，每天产出性能测试日报，并判断性能测试结果是否满足期望

8. 性能调优：PM、性能测试工程师、DBA共同参与性能测试调优方案的制定工作。代码的调优工作，由PM或者PM指定开发人员完成。

9. 编写性能测试报告：编写性能测试报告，阐明性能测试目标、性能测试环境、性能测试数据构造规则、性能测试策略、性能测试结果、性能测试调优说明、性能测试过程中遇到的问题和解决办法等。

2.2.4 安全测试

2.2.4.1 概述&目标

• 随着互联网发展，全球网民数量已达到40+亿，中国网民数量已接近8亿，业务场景及用户体验造就了网站的注册功能，用户信息也在这个环节提供了给系统运营方，最近几年不断发生的用户信息泄露事件，使互联网安全得到更多人的关注和学习；一个小小的安全问题可能会被无限放大，如何在系统研发及运营过程中100%保障用户的安全，一直也是业界的一道难题；
• 安全测试是在软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程；通过有效的安全测试手段，在系统功能稳定可用的同时，确保应用安全，不被外部攻击击穿，不发生数据泄露；提升IT产品的安全质量；尽量在发布前找到安全问题予以修补降低成本；有合理客观的安全度量；验证安装在系统内的保护机制能否在实际应用中对系统进行保护，使之不被非法入侵，不受各种因素的干扰；

2.2.4.2 安全问题的危害

• 信息泄露于普通用户而言，可能会个人生活造成巨大影响，比如泄露了电话号码，信息可能会在不同场景下被无数次倒卖，会在不合适的时间接收到来自于各个角色的骚扰电话，还能带来诈骗风险；如果信息涉及到了家庭住址，还可能带来人身安全的隐患；如果信息涉及到了电子邮箱，那么有可能收到N多封毫无价值的邮件；
• 信息泄露于公司而言，可能会引起重大的社会舆论，造成公司的重大公关事件，甚至影响投资人对公司的信心；同时给竞争对手可乘之机，利用安全事件打压对方，提升自己；需要很长事件来修复安全问题带来的负面影响
• 应用系统发生安全为的危害非常之大，历史发生过许多重大的安全问题，比如CSDN600万用户信息泄露、Facebook安全事件、共享单车数据泄露事件；均在不同程度上对客户和公司造成了重大影响和损失；当然，作为全球领先互联网公司，每天受到外界攻击达数亿次，也同样会发生不同程度的数据泄露问题，如何在合适的时间通过合适的手段来确保我们服务好客户一直是涉足安全的同学致力学习和研究的方向；

2.2.4.3 安全红线

标准

• 未经授权入侵或盗用他人账户进入公司计算机、服务器。
• 故意利用或干扰、破坏公司的系统资源
• 严禁私搭私建服务器或应用
• 故意绕过公司安全措施
• 未按要求处理严重高危安全漏洞
• 安全红线规范

2.2.4.4 常见安全漏洞及测试方法&工具

• 重大/高风险项目可申请安全同学介入进行安全评估及验证；
• 垂直权限问题

• 原理
• 垂直权限漏洞是指Web应用没有做权限控制，或仅仅在菜单上做了权限控制，导致恶意用户只要猜到了其他页面的URL，就可以访问或控制其他角色拥有的数据或页面，达到权限提升的目的；
• 用户A和用户B的权限不一样，比如A用户页面有审核菜单，B没有，但是B可以调用审核接口，进行审核操作，此状态表示审核接口有垂直越权问题；
• 测试方法
• 业务测试
• 业务测试过程中，要设计此场景安全测试用例，并切实落地执行；
• 用户A登录后，打开浏览器NetWork，查看所有XHR网络请求；
• 用户B登录后，A的请求，进行重复操作，若可以正当操作，则表示接口存在越权问题；
• CR过程，要针对有update、delete、add接口做着重观察；

• 水平权限问题

• 原理
• 水平权限漏洞是指Web应用程序接收到用户请求时，没有判断数据的所属人，或者在判断数据所属人时是从用户提交的参数中获取了userid，导致攻击者可以自行修改userid修改不属于自己的数据
• UserA和UserB的权限是一样的，但是A可以看到B的数据，就是发生了水平越权问题；
• 容易发生水平越权的地方：除了身份（会话ID）标识外，站点还用其它信息（手机号、员工编码、工号或者使用Hash算法生成的）用来标识用户或用户信息；
• 案例：getAccount.do?accId=12345 ，此类接口就是高危的接口；
• 测试方法
• 通常情况下，我们会用两个测试账号来访问同一个Url，看能否返回相同的数据，如果能够互通，则说明后端接口为对当前用户做数据隔离，存在水平权限问题；
• 业务测试：
• 系统功能测试过程中涉及安全测试用例
• 设计两个测试账号，同时登陆两个测试账号，对比同一个页面的数据是否存在交叉；
• CR过程中，注意针对查询接口看是否都加上了用户属性作为数据隔离条件；
• 自动化测试

• 安全工具可扫描问题

• 命令注入/执行：
• 漏洞原理：用户输入被当做/拼接成服务器命令，交由生产网服务器代为执行，从而导致用户可以对服务器执行任意命令，甚至置入木马，反连，提权等风险操作；
• 测试方法：安全扫描；针对需要执行命令的接口，输入”cat /etc/passwd”或”| cat /etc/passwd”或者其他命令看是否会返回该命令的执行结果，只要有一个命令可以返回执行结果，判定有效；
• 代码注入/执行：
• 漏洞原理：用户输入的代码被服务器直接执行，从而导致用户可以对服务器执行任意命令，甚至置入木马，反连，提权等风险操作；
• 测试方法：安全扫描；针对需要执行代码的接口，根据可以执行的代码不同构造服务器命令调用的代码进行测试，若可以正常执行，则漏洞有效；
• SSRF(服务端请求伪造)
• 漏洞原理：服务端代理用户对用户输入的URL无条件发起请求，并将response返回给用户。用户可以填写内网的任意IP以及端口，用来进行内网嗅探；
• 测试方法：STC安全扫描在某测试服务器上搭建对应测试HTTP服务器；在相关业务接口中填写测试服务器地址提交，查看测试HTTP服务器是否会有访问记录，若有则说明有漏洞；
• XXE(XML实体注入)
• 漏洞原理：用户上传XML文件，服务器在进行解析时没有禁止实体解析，导致schema中的URL被访问，造成类似SSRF的风险；
• 测试方法：安全扫描：在某测试服务器上搭建对应测试HTTP服务器；构造特定XML文件，其中某个schema URL为测试HTTP服务器地址；在XML上传接口出上传该文件，若有看到测试服务器访问记录则有漏洞；Java业务建议使用集团扫描器进行扫描
• 反序列化漏洞
• 漏洞原理：从用户可控的位置(cookie,参数)中读取序列化字符串，在服务端进行反序列化代码执行操作，因为反序列化的内容可以写入任意代码，导致代码注入执行
• 测试方法：安全扫描；构造可执行服务器命令的序列化字符串，填入对应参数/cookie中看是否可以执行成功；
• SQL注入
• 漏洞原理：用户输入的参数会直接拼接进入SQL语句中实现业务逻辑，若参数为精心构造的SQL语句，将会产生本意之外的SQL执行，比如猜解sql的root密码，进一步拖库
• 测试方法：安全扫描；使用sqlmap进行sql注入扫描；
• JSONP劫持
• 漏洞原理：Jsonp跨域提供数据传输时，未对访问来源进行判断，导致可被未授权的他方读取接口中的敏感信息；
• 测试方法：安全扫描；通过burpsuite抓包，若发现有用户个人标识/资源标识出现在参数或者cookie中时，尝试修改并重放请求，若返回正常则存在漏洞
• 任意URL重定向
• 漏洞原理：业务进行跳转的URL的域名可以被用户任意修改(跳转目标url在某个参数/cookie中)，从而跳转至伪造的钓鱼网站，引导用户在网站上进行敏感信息输入，从而
• 测试方法：安全扫描；修改跳转目标URL参数，若能跳转则有漏洞；
• XSS(跨域脚本攻击)
• 漏洞原理：用户输入的内容，不经过处理直接展示在web页面上，若用户输入的是可执行的js脚本将会被直接执行，则可能导致session_id被盗取，csrftoken被盗取，jsonp劫持refer防御失效，同域名下敏感信息页面被盗取等后果
• 测试方法：安全扫描；在输入框输入”< >’ “ &”，当该输入框内容展示在页面上的时候，查看页面源码，若原样输入，则有漏洞，若被转义成”&lt,&gt”等html实体，则说明做了安全防护；
• CSRF(客户端请求伪造)
• 漏洞原理：常规http接口的path,method, 参数等内容完全可以被猜解，有人会伪造某些高危操作接口(比如点赞,收藏,好评),将该接口伪装之后(比如生成短链接，二维码)发送给其他用户点击，此时等于在不知情情况下做了一些对自己有害的操作
• 测试方法：安全扫描；使用burpsuite进行抓包，将参数中的token删除，或者设置为空，重放请求，若正常访问则说明有漏洞；
• 短信/邮件/电话炸弹
• 漏洞原理：短信/电话号码，邮箱地址由用户填写，并且可以无频率次数的给其发送信息，打电话，用以进行骚扰用户；
• 测试方法：安全扫描；使用burpsuite进行信息发送接口抓包，并利用repeater功能进行批量访问，如果每次都成功说明没有做防护；
• 登录口爆破
• 漏洞原理：登录口设计不当，风控策略缺失/不得当，可以进行用户名密码爆破
• 测试方法：安全扫描；使用burpsuite，构造弱口令字典，使用repeater功能访问登录接口；

2.2.5 算法测试

2.2.5.1 引言

算法的概念很大，百度百科对算法的定义是这样的：算法（Algorithm）是指解题方案的准确而完整的描述，是一系列解决问题的清晰指令，算法代表着用系统的方法描述解决问题的策略机制。也就是说，能够对一定规范的输入，在有限时间内获得所要求的输出。

算法本身，它只是一个公式或者是一个解决方案，它只有真正的应用到具体的工业场景中，才真正发挥了它的价值，才能判断它在这个场景的效果的优劣。在互联网领域，算法应用的最好的莫过于推荐的场景，包括商品、图书、音乐、视频、新闻、电影等等。因此，本文会以推荐算法展开介绍。

2.2.5.2 推荐算法的种类

主流的推荐算法主要有以下几种：

• 基于内容的推荐

基于内容的推荐是建立在物品的内容信息上作出推荐的，不需要依据用户对物品的评价意见，更多地需要用机 器学习的方法从关于内容的特征描述的事例中得到用户的兴趣资料。因此，基于内容的推荐常常需要通过自然语言处理NLP技术对用户的行为数据进行分析，从而抽象出内容的共性，然后根据这些共性进行推荐。例如，某用户看了N部电影，我们可以从电影的标题、简介、演员表、评价中抽象出这些电影的共性，然后再给用户推荐相关的电影。

• 协同过滤推荐

协同过滤本质上是利用事务之间的相似性，推荐与主体相似的物品或者推荐相似用户偏好的物品来完成推荐。因此，协同过滤推荐分为三种类型：一种是基于用户的协同过滤推荐，一种是基于物品的协同过滤推荐，一种是基于模型的协同过滤推荐。基于用户的协同过滤主要考虑的是用户和用户之间的相似度，只要找出相似用户喜欢的物品，并预测目标用户对对应物品的评分，就可以找到评分最高的若干个物品推荐给用户。而基于物品的协同过滤和基于用户的协同过滤类似，只不过这时我们转向找到物品和物品之间的相似度，只有找到了目标用户对某些物品的评分，那么我们就可以对相似度高的类似物品进行预测，将评分最高的若干个相似物品推荐给用户。基于模型的协同过滤是最为主流的协同过滤类型，我们可以利用机器学习算法来建模，从而通过稀疏的已有的部分数据来预测那些空白的物品之间的关系，然后找到评分最高的物品推荐给用户。

• 基于关联规则的推荐

基于关联规则的推荐以关联规则为基础，把用户行为的物品作为规则头，规则体为推荐对象。关联规则挖掘可以发现不同商品在销售过程中的相关性，在零售业中已经得到了成功的应用。关联规则就是在一个交易数据库中统计购买了商品集X的交易中有多大比例的交易同时购买了商品集Y，其直观的意义就是用户在购买某些商品的时候有多大倾向去购买另外一些商品。比如购买牛奶的同时很多人会同时购买面包。

• 基于知识推荐

基于知识的推荐在某种程度是可以看成是一种推理技术，它不是建立在用户需要和偏好基础上推荐的。基于知识的方法因它们所用的功能知识不同而有明显区别。效用知识是一种关于一个物品如何满足某一特定用户的知识，因此能解释需要和推荐的关系，所以用户资料可以是任何能支持推理的知识结构，它可以是用户已经规范化的查询，也可以是一个更详细的用户需要的表示。

• 组合推荐

组合推荐也叫混合推荐。顾名思义，组合推荐就是将各种推荐算法进行组合，集各家之长。通过多个推荐算法的集合，弥补各自的缺点，集合各自的优点，往往能得到一个更好的推荐算法，但是也会提高算法的复杂度。在实际应用中，内容推荐和协同过滤推荐的组合最为常用。

2.2.5.3 推荐算法测试方法

测试推荐算法其实并不需要你去搞清楚算法到底是怎么计算的，因为算法通常只有优劣之分而没有对错之分，而对于推荐算法而言，结果是优还是劣，只能交给用户去评判了。那么我们在测试推荐算法的时候能做些什么呢？这就得从一个商品是怎么推荐到用户的整个系统框架说起。

上图是很久远之前的一个实时推荐系统的架构图。从图中可以看到，算法首先会产出一份离线数据，这份数据会计算用户的历史行为，产生一份离线的推荐输出并存储到引擎中。除了离线的数据，系统还会考虑用户的实时行为，对用户的实时行为的数据进行计算并存储到缓存中，推荐系统根据当前用户拿到离线的推荐数据和实时的推荐数据，然后还会将这些数据都丢给一个排序的系统，最后返回一组有序的商品并根据场景的需求截取topN进行推荐。在这样一个推荐系统中，推荐算法会存在于各个环节，而且每个环节使用的底层算法都会不一样，以求达到最好的推荐结果。而作为测试不必要纠结于到底采用了什么算法、算法的计算公式如何以及是否计算的正确，因为你哪怕和算法一样重新用同样的算法计算一遍也达不到你想要的测试目的。

测试在这个过程中，应该着重保障3个环节的产出结果质量，分别是：离线数据的产出、实时数据的时效性、最终推荐结果是否满足业务需求。

• 离线数据质量测试

对于算法产出的数据，需要保障数据的质量和是否满足场景的要求，因此会从数据正确性和业务正确性两方面入手。

数据正确性

数据正确性是为了保证算法数据的正常产出，例如监控数据大小、数据产出时间、数据产出格式、数据依赖是否正确、主键是否唯一、字段值是否为空、字段值是否在一个期望值区间、表数据量的波动是否正常、字段值的平均值、最大最小值等等，都是一些纯数据的测试，以上的指标在目前的数据计算平台DataWorks的摩萨德监控和DQC质量保障都有提供测试手段。更多的数据测试相关知识可以参考2.2.6章节的详细介绍。

业务正确性

一个算法应用于某个场景其产出的数据必须要满足该场景的业务需求。以猜你喜欢的场景为例，类目维度需要过滤敏感类目的商品，需要过滤失效类目的商品，商品维度需要过滤状态不正常的商品、需要过滤商品名称含敏感词的商品，还需要过滤卖家状态不正常的商品等；而如果是同类宝贝推荐则需要验证被推荐商品和推荐商品的类目一致性，同店商品推荐则需要验证被推荐商品和推荐商品的卖家一致性。有些业务场景可能需要推荐的商品在某一个价格区间或者某一个地区范围或者某几个类目范围，又或者有的场景需要推荐4个商品而又的场景需要推荐8个商品，那么推荐的商品个数是否满足需求也是需要验证的。

业务正确性的测试点完全取决于业务的场景需求，以及我们测试站在用户的角度思考出的用户体验性的测试点。例如过滤用户已浏览和已购买的商品，过滤成人类目、丧葬类目的商品等。

实时数据的时效性

一个好的推荐算法必定会考虑用户的实时行为，并通过对用户实时行为分析后给出实时推荐的数据，那么这个过程中，测试最需要保障的是用户的实时行为算法是不是实时采集到并处理了。由上面的实时推荐系统可以看出，用户的实时行为会被采集到实时计算系统Strom中，然后进行用户特征、商品特征等的计算再存储到tair中。那么我们可以通过对TT消息的mock从而可以模拟用户的实时行为数据，然后从tair中拿到算法实时计算的结果，并以一定时间间隔校验tair中结果数据的变化来验证实时数据的时效性。当年实时系统的时效性在分钟级别，而如今实时系统的时效性已经到秒级别了。

• 工程端结果质量

推荐结果的正确性

推荐结果的正确性的指标点，一般会和离线数据业务正确性的测试点相吻合。这个时候有同学会问，那既然离线数据已经保障了，为什么在工程端还要做一次测试呢？那是因为整个推荐系统的环节特别多，上面已经介绍到除了离线数据还有实时数据、还有排序系统、还有推荐系统里的一些处理逻辑，任何一个环节都可能引入问题，因此必须在推荐结果产出的最后一环做出保障。说到这里，有同学可能又会问，那既然在最后一环做了保障，为什么在离线数据环节还要测试呢？那是因为离线数据是推荐结果非常重要的输入，如果在离线数据产出时没有做好各种业务需求的把关，而是直接在最终推荐系统里做各种业务校验的话，很有可能最终满足需求的推荐结果个数不够，或者都被实时行为数据占领又或者被补全的数据占领，这对于推荐效果都是一个很大的损伤。

推荐结果的正确性我们一般都会采用接口测试来保障。严谨的测试我们一般会在日常环境造数据，然后再调用接口进行测试，这是杜绝业务正确性问题最保险的方式。但是在推荐算法领域，算法的更新迭代非常的快，同时算法对应的测试同学会非常的少，特别是在推荐系统演化成TPP平台（淘宝个性化推荐平台）从而服务全集团几十个BU上千个算法同学的时候，这种日常环境造数据测试的方式显然不能满足需求，而且同一个场景算法的迭代需求，往往改动点比较小，对于主逻辑不会有什么改动，最好是有一种机制能让开发无脑完成自测。因此，预发验收测试应运而生。

预发验收的前提条件是这是一个线上已经存在的场景，已经有了线上数据，算法是要迭代上线。将业务的验证点做成一个个可以勾选的测试点，然后利用线上的真是请求数据批量请求推荐系统，最终拿到测试结果，并且这些验证点可以加入回归。算法开发可以轻松的在页面上勾选自己想要的测试点进行测试，其实这些测试点可以像推荐算法的代码扫描一样，做成整个推荐算法上线的流程的一个必经环节，自动验收自动给出结果报告。

推荐系统的性能测试

在保障了算法的各种数据正确性和业务正确性的基础上，还需要保障推荐系统的性能。特别是当推荐算法应用在类似手淘首页这样的场景上，瞬时的QPS会非常高，需要算法能有很强的并发处理能力。因此一个推荐算法上线前，性能测试是必不可少的。

如果是一个新的场景，那么性能测试的数据需要根据场景请求造出来，如果是一个已经在线的场景，算法迭代上线那就会好办很多，直接拿到线上的请求作为性能压测的请求数据就可以。因此，对于已有的场景性能压测是可以做成整个推荐算法上线的流程的一个必经环节，自动压测自动给出压测结果，并根据线上的性能指标自动给出测试通过或不通过的评判结果。

那么除了以上的算法正确性相关的测试，对于算法的效果的优劣有什么测试手段么？答案肯定是有。下面介绍一些算法效果优劣的测试手段。

• 算法效果测试

算法效果测试的手段有ABtest、多样性、更新率、基尼系数，而一般算法都会用到的准确率和召回率以及AUC、DCG、NDCG这样的指标反而不适合作为推荐算法的指标，因为我们无法拿到用户确切的喜欢或者不喜欢的数据，即便花很大的代价用人工评测来完成也会带有很强的主观性。

ABtest

衡量一个推荐算法优劣最好的手段莫过于是ABtest了。ABtest即将A算法和B算法进行线上用户真实行为的对比，对比的指标往往是商业上的一些指标，如：成交UV、成交金额、点击率、购买转化率、千次展示金额等，其中以点击率和千次展示金额为主要对比指标。

ABtest的前提是线上已经有一个稳定运行的算法了，它所作用的流量部分我们称之为基准桶，一般会拿出线上流量的5%-10%进行ABtest，我们称之为测试桶，每个算法作用5%的流量，一般会有一个基准桶和2个测试桶在线上测试。当其中一个测试桶在线上运行一段时间，各项指标都显著优于基准桶的时候会进行算法切花，但是切换的时候也不会一下子全量切换，而是会以一个阶梯递进的方式切换，例如5%-10%-20%-50%-100%。这样做的原因有2个：一个是线上流量分桶策略一般有3种：随机分流、按照userId分流、混合分流，但是无论哪种分流都可能导致样本不均匀，导致小流量的时候效果好，流量切到足够大的时候，效果反而变差了；另一个原因是，虽然算法上线前会要求进行性能测试，但是并不是所有算法都会遵守这一约定，贸然全量切换会引起不可预知的线上性能问题。

虽然ABtest有其显著的优势，真实拿到线上的效果数据评判算法的优劣。但是一旦测试桶要切换基准桶，对于算法的一些诸如多样性、更新率、基尼系数这些指标的测试也非常重要，这直接影响了用户的体验。当然在实际工业中，多样性、更新率和基尼系数往往提供的是算法上线的参考指标，并不作为算法能不能上线的决策指标。

多样性

多样性反映了推荐内容的丰富程度，多样性的好坏影响用户的体验，总体来讲用户更希望看到多样性不错的推荐内容。对于不同的推荐内容，多样性的维度会不一样，总体来说以类目的多样性为主。无论是推荐商品、电影、新闻抑或是音乐，能尽可能的推荐用户喜欢的不同的种类的数据，对算法上线后的商业指标肯定能起到正向的作用。但是多样性也不是越多越好，要考虑用户实际的喜好偏向，对于相同权重的类目可以适当增加多样性，但是不同权重的自然以用户喜爱度为重，这个是算法需要找到的一个平衡。

假设推荐系统的推荐结果是N个，以数据所拥有的某一个属性的个数（比如“类目”、“SPU”或其他自定义属性）为维度，统计各属性个数在全部N条数据中的比例。假设业务要求给被推荐结合O中，每一个元素o推荐的calue集合为V，

表示对于value的某指定属性，V中拥有的不同个数为c个的集合，则多样性公式描述如下：

式中：

表示集合V中包含的指定属性数为c个的集合；

表示

的个数；

则表示

在N中所占的比例。

更新率

用户的行为是不断变化的，一个好的算法的推荐内容必定会根据用户行为的变化而变化。这一指标更多的是应用于离线数据上，对于用户的历史行为会有一定的衰减，并且增加用户近期行为的权重，从而达到推荐结果的不断更新。更新率一定程度上是推荐结果“新颖度”的一种量化。

假设两个推荐集合，其中一个作为参照对象，推荐的总次数（或推荐对象总个数）为

，实验对象于参照对象有不同的次数（或推荐对象个数）累计为VN，则更新率公式描述如下：

基尼系数

基尼系数用来衡量推荐系统的马太效应。假设推荐结果集中物品总个数为n，分n个组，每组物品数占全部的比例为1/n，则简单的基尼系数的公式描述如下：

式中：i表示每个物品累计出现次数依照从小到大排序后的所处的序列位置；Pi表示排序后第i组物品累计出现次数占总物品出现次数的百分比。

2.2.5.4 推荐算法测试流程

推荐算法测试的流程要根据不同的情况采用不同的策略，一般分以下3种情况：

• 全新场景上线

对于一个全新的场景，一个算法要上线，必须要经过严谨的全流程测试，包括离线的数据质量测试（数据正确性、业务正确性）、实时数据时效性测试、工程端结果质量保障（推荐结果的正确性、推荐系统的性能测试）、算法的效果测试（多样性、更新率、基尼系数）。并且和传统的功能测试一样，测试也是在需求阶段就介入、然后经过日常、预发测试，最后再进行线上质量监控，整个测试流程如下：

• 算法迭代ABtest

算法迭代ABtest考虑到一方面算法的改动不会特别大，特别是对于主流程的正确性逻辑不会有什么变动；另一方面考虑到ABtest的线上流量比较小，通常是线上总流量的5%。为了保证算法能快速上线，测试会提供工程端的预发验收测试和性能压测的工具，供开发自测使用，预发验收和性能压测通过之后，算法即可上线ABtest，整个测试流程如下。

• 测试桶切换基准桶

一般算法在ABtest后都会下线，进行新一轮的优化然后再ABtest，周而复始。但是有一些优秀的算法经过优化之后，ABtest的各项商业指标明显优于线上基准桶的算法，就会切换线上基准桶。此时，我们要当做一个全新的场景全新的算法上线来看待，走全新场景上线的测试流程，如下：

• 后记

对于推荐场景来说，一旦哪个场景上线之后，它的需求基本是固定的，剩下的就是算法不断迭代优化的过程。因此，对于测试来说，重点要做的是对于新场景的需求分析，并将测试过程中的测试点沉淀下来，用脚本化、自动化、甚至是平台化的手段去实现。这样，对于已上线的场景，算法开发迭代算法完全可以自助验证，达到效率的指数级提升。

2.2.5.5 其他非推荐算法测试简介

算法的应用除了推荐场景之外，在搜索引擎、图像识别、自然语言处理（NLP）等领域都有广泛的应用。这些场景和推荐场景有很大的不同，结果的优劣是不以使用用户的主观来评判的，它是能被一些确切的指标来衡量的。下面会介绍一些非推荐算法的测试指标。

• 其他算法常用测试指标

DCG

DCG是一个常用来衡量搜索引擎算法的指标，搜索引擎一般采用PI(per item)的方式进行评测，简单地说就是逐条对搜索结果进行分等级的打分，等级越高地排在前面，得到的DCG分数就越高，反之，等级比较高的结果如果排在后面，DCG分数就会有所打折。公式定义为：

其中，rel为这个排序list结果i的一个等级得分，越和主商品相关、质量越好的能排在前面越好，i是指结果i的当前位置序号。

NDCG

NDCG较之DCG，是一个相对比值，可以用来评测不同query之间的排序好坏。在搜索引擎，NDCG是一种对搜索结果排序结果优劣度量的有效性方法。由于搜索结果随着检索词的不同，返回的数量是不一致的，而DCG是一个累加的值，没法针对两个不同的搜索结果进行比较，因此需要归一化处理：

IDCG为理想情况下最大的DCG值：

其中 |REL| 表示，结果按照相关性从大到小的顺序排序，取前p个结果组成的集合。也就是按照最优的方式对结果进行排序。

准确率&召回率&F1

准确率和召回率广泛用户信息检索、分类、识别、翻译等领域，召回率也叫查全率，准确率也叫查准率，概念公式如下：

召回率=系统检索到的相关文件/系统所有相关的文件总数

准确率=系统检索到的相关文件/系统所有检索到的文件总数

假设系统检索出来且是相关的个数为A个，系统检索出来但是不相关的个数为B个，未检索到的但是相关的个数为C个，未检索出并且不相关的个数为D个，那么：

P（准确率）=A/(A+B)

R（召回率）=A/(A+C)

准确率和召回率往往是比较矛盾的，要想准确率高就会牺牲一定的召回率，同理，要想召回率高也需要牺牲一定的准确率。因此，在不同的场合中需要自己判断希望准确率比较高还是召回率比较高。F1的指标就是为了综合考虑准确率和召回率，计算公式如下：

F1=2PR/(P+R)

AUC

AUC是分类、识别领域必测指标，说到AUC首先要先介绍一下ROC曲线。如下是一个ROC曲线：

横轴：负正类率(false postive rate FPR)特异度，划分实例中所有负例占所有负例的比例

纵轴：真正类率(true postive rate TPR)灵敏度，Sensitivity(正类覆盖率)

针对一个二分类问题，将实例分成正类(postive)或者负类(negative)。但是实际中分类时，会出现四种情况： (1)若一个实例是正类并且被预测为正类，即为真正类(True Postive TP)

(2)若一个实例是正类，但是被预测成为负类，即为假负类(False Negative FN)

(3)若一个实例是负类，但是被预测成为正类，即为假正类(False Postive FP)

(4)若一个实例是负类，但是被预测成为负类，即为真负类(True Negative TN)

接下来我们考虑ROC曲线图中的四个点和一条线。第一个点，(0,1)，即FPR=0, TPR=1，这意味着FN（false negative）=0，并且FP（false positive）=0。Wow，这是一个完美的分类器，它将所有的样本都正确分类。第二个点，(1,0)，即FPR=1，TPR=0，类似地分析可以发现这是一个最糟糕的分类器，因为它成功避开了所有的正确答案。第三个点，(0,0)，即FPR=TPR=0，即FP（false positive）=TP（true positive）=0，可以发现该分类器预测所有的样本都为负样本（negative）。类似的，第四个点（1,1），分类器实际上预测所有的样本都为正样本。经过以上的分析，我们可以断言，ROC曲线越接近左上角，该分类器的性能越好。

AUC即计算ROC曲线下的面积，介于0.1和1之间。AUC作为数值可以直观的评价分类器的好坏，值越来越好。那么AUC如何计算呢？这里介绍一个巧妙的计算方式：我们将分类结果按score从大到小排序，然后令最大score对应的sample 的rank为n，第二大score对应sample的rank为n-1，以此类推。然后把所有的正类样本的rank相加，再减去M-1种两个正样本组合的情况。得到的就是所有的样本中有多少对正类样本的score大于负类样本的score。然后再除以M×N。即：

• 人工评测

大家可能已经发现了一个问题：在上述的评测指标中分别出现了理想情况的DCG值、相关的文件、实际为正类，那么如何给出上述的这些评判呢？

在评价信息检索、分类、识别、翻译等算法好坏的方法中，人工评测是一个比较权威的评测手段。由专业的人员对算法的结果进行人工标注，以评价算法的优劣。但是算法产出的结果数据量往往是巨大的，并且算法迭代要求快速，显然每个算法都用人工评测耗费的时间和人力太过巨大。那么在实际工业中，往往会从训练集中拿出一部分进行人工评测，并把评测后的结果中的一部分作为测试集，一部分作为算法训练的样本集，然后用测试集作为上述指标的正确结果进行指标评测。在集团中也涌现了一批优秀的人工标注平台。

对于测试来说，应该将重点放在如何及时合理的更新测试集，建立算法上线的标准化流程上。例如，对于上线的算法沉淀出上述测试指标的基线，新的算法要上线AB则必须各项指标优于指标基线才可以；测试集则需要定期更新，例如一月一次，又或者发现新上的算法的各项指标值都趋近于线上基准算法的值或者持平的时候，说明测试集的数据已经被算法修正，需要及时通过人工评测更换测试集。

2.2.6 数据测试

2.2.6.1 概念&目标

• 名词解释

ODPS: Open Data Processing Service 开放数据处理服务，处理服务；ODPS是分布式的海量数据处理平台，提供了丰富的数据处理功能和灵活的编程框架，是自主研发的海量数据处理平台。主要服务于批量结构化数据的存储和计算，可以提供海量数据仓库的解决方案以及针对大数据的分析建模服务。

ODS: Operational Data Store，操作型数据，指结构与源系统基本保持一致的增量或者全量数据。作为DW数据的一个数据准备区，同时又承担基础数据记录历史变化。

CDM: Common Data Model，通用数据模型（数据中间层），包含DWD和DWS。

DWD：Data Warehouse Detail，数据仓库明细层数据。

DWS：Data Warehouse Summary，数据仓库汇总层数据。

ADS：Application Data Service，面向应用的数据服务层。

• 常见指标定义

PV官网的页面浏览量（page view）

UV按日去重统计用户，若能从日志中提取到uid,则取uid,若没有uid，则取acookieid。

跳出率对于网站级别，为单个pv的session数/session数,即只有一个pv的session占总session的比例.

用户跳出率 注册用户访问的session 中单个pv的session数的比例

停留时间 指用户到达某一页面与从此页面跳出的时间差，如果没有下一步行为则不计算，若时间差超进4分钟时取4分钟。

注册用户停留时间/付费用户停留时间 计算方式同停留时间，只是计算对象限制为注册用户/开通服务用户的访问。

访问深度 没有直接跳出的用户在一个会话中平均打开的页面数，直接跳出的会话不参与计算。

频道/页面退出率 当前是简易算法，频道及页面的打开时间与所在会话的最后一次打开页面时间相同，则算会话在该页面/频道退出。

新访客数 当天第一次到访的uv，若访客为注册用户身份，则查找该用户是否以前日期未来过，若非注册用户，查找该acookie是否第一天来。是否新访客是按首次访问日期判断，若一新访客在首访日期有通过多个渠道进入，则多个渠道都算为网站带来一个新访客。

• 数据测试目标

数据测试涵盖数据质量的正确性、适用性、稳定性和安全性，保障业务数据质量良好可用安全。正确性：用于描述数据遵从预定要求在格式、量、数据值等方面的满足程度，包含完整性、一致性、准确性和时效性，完整性指的是数据量和格式充分；一致性指的是数据在处理和源切换中数据量和值保持一致，准确性指的是数据值符合客观和认知要求，时效性指的是在时间序列处理上满足。适用性：用于描述数据对于业务要求的满足程度，主要包含了业务定制性规则和效果表现。稳定性：用于描述数据可按时按质量要求生产，出现异动恢复策略，包括数据及时性和容错性，及时性指的是数据按照约定时间产出，容错性指数据丢失、缺失或错误后的恢复和兜底备份策略。安全性：用于描述数据具备的隐私保护等安全策略，包含数据私密性，指是在任何策略下，不暴露个人的隐私数据。

在数据业务需求过程中，根据研发事项插拔 阶段与质量维度的重点内容：需求预研阶段中聚焦于外部数据源质量，业务口径定义和上下游的SLA（偏流程规范）；研发阶段覆盖数据正确性与适用性的验证（测试阶段重点）通过dataPro + 夸父 + 自动化的工具支撑测试过程；发布环节和线上应用的阶段，质量保障以内容监控为中心，通过平台联动datapro、摩萨德、DQC等监控工具，对线上业务数据稳定性做常态管控。

2.2.6.2 数据测试技术栈

• 数据源

（1）日志采集

①采集技术 web端：aplus app端：UT

②日志打点统一规范

③日志同步：TT

（2）异构数据同步

①同步中心

②oneclick

（3）外部数据抓取

①Databee

②猎析

• 数据计算

（1）odps

①资产管理平台

②数据地图

③内置函数及UDF

④任务优化

⑤Mosad运维

⑥离线算法开发平台

（2）实时计算

①Blink原理

②贝叶斯平台

③实时算法开发平台

• 展现存储

MySQL、HBase、Opensearch、Tair、Olap：hybridDB&ADS

• 数据访问

tddl、oneService

• 可视化工具
• 数据质量

2.2.6.3 数据测试工作流

类同于业务项目流程，数据业务研发流程如下示意。需要说明的数据质量事项在项目的阶段注意事项:

①项目KO准备阶段，需要业务PD数据需求明确给出来-指标定义、期望的口径、更新的频率等，便于需求指导和上线后透出的解释；

②技术方案和开发阶段：需要对于数据实现有完整的设计梳理，开发调试阶段需要在工具平台上完成自测， 再做提测，（避免select几条看看数据的自测方式）；

③测试阶段：用于对于复杂的业务点做交叉验证，一般是是测试人员或者验收的同学完成

④上线前：对于数据正确性、适用性、安全性和稳定性喝多核查是否完整，项目需要补的周期数据是否已经刷完整（一定要注意补数据需要完成才能正事对外发布）

⑤生产稳定性：周期性的数据监控、业务监控同步配套上线，在监管平台管理。

---

2.3 如何做好跨域项目？

2.3 如何做好跨域项目？

业务的迅猛发展，随之而来一系列跨域、跨BU合作项目，周期短、链路长、依赖多、存量数据迁移是面临的共性问题和挑战，身为PTM如何破局？从项目KO到业务上线，从质量保障角度出发，我们总结出了一套项目PTM实施四部曲：

• 在需求评审阶段制定好计划同时深入业务了解，熟悉产品设计及系统架构、链路等；
• 在技术方案评审及coding阶段，制定好各角色协同规范同时设计完善的测试方案；
• 在测试阶段，做好全链路的协同并对过程问题及时跟进解决；
• 在灰度及发布阶段，跟进每一个线上问题同时根据问题反推是否需要继续加强验证场景。

2.3.1 准备期-深度参与

拒绝仅做项目进度的跟进和统计者，在项目需求评审阶段，就同步产出测试计划，深度参与到项目中去，了解项目相关业务。

2.3.2 热身期-PDCA

制定协同规范，明确分工，确保在项目后期不出现边界不清事情有遗漏的问题。

制定测试方案，通过测试策略创新、测试数据梳理、测试环境使用等完善计划，给项目成员进行整体指导。

2.3.3 实战期-选择相信，不断思考，保持跟进

全链路联调一直都是痛苦的、漫长的，如何才能够保障整体进度顺畅，我们必须学会在繁杂的情况下找准主要矛盾，找准了便抓住并全力去解决，从而实现进度的把控，同时，针对各域问题多做碰撞，打破常规，通过mock、业务工具等方式进行核心测试策略的创新。

2.3.4 灰度期

2.3.5 人员协同-一颗心、一场仗

2.3.6 风险管理-风险的识别和把控

• 什么是风险

与达成目标相关联的不确定性（交付、成本、进度、受益等）

• 风险主要属性

影响：发生时所带来的结果/后果

可能性：风险是否会发生具有不确定性

• 风险管理

是对不确定性作出的准备，实在风险变成现实前所做的工作

• 风险不等同于问题，风险可能变成问题
• 问题是已经明确要解决的

问题是要解决的，项目中的问题可能是产品、技术、可测性等诸多方面

2.3.7 项目总结-遇到更好的自己

做而不思则罔，我们只有经过不断的反思和总结，才能发现自身的不足而不断成长。在每一次项目总结时，围绕项目之初制定的目标去不断的总结和解决。