原副标题：怎样积极开展USB智能化试验？一般而言组件和数个组件关连又是不是去做试验？
(一)USB智能化怎样积极开展？
0、调研、大前提预备和思索
a)大前提：
1、正式宣布结构设计示例的这时候，紧密结合postman/jmeter这种的辅助工具
2、去结构设计相同的试验数据，发动允诺，查阅积极响应结论与结构设计与否完全一致
3、(要返工纯手工试验的) – 辨认出的bug
b)示例的储存形式:
1、excel表单 – 实用性json方向
2、json文档 – 允诺模块比非常多，写在json文档里
3、yaml文档 – httprunner3.0
4、资料库 – 创建表单
c) 智能化覆盖面积是不是样
覆盖面积：机能上/纯手工示例覆盖面积 – 30% – 90%
1、你做那个工程项目的USB智能化多长时间了？
2、控制系统叶黄杨？与否繁杂？
3、覆盖面积示例啥条？碰到甚么十分困难(及软件控制系统)？
1、需求分析
介绍工程项目的销售业务机能，bug非常多的组件，较为稳定USB有哪些，核心机能有哪些
2、 介绍USB
2.1 抓包看USB
2.2 通过USB文档介绍
3、智能化框架、辅助工具的选择
3.1 工作的可扩展性以及扩展语言 + 选几个繁杂的USB试用
3.2 框架结构的较为
3.3 规范命名
4、写USB示例
4.1 写USB示例脚本
1、核心销售业务的先走 – 用户使用率最高 2、示例优先级 – 常用的机能场景/必填模块 3、模块的格式有效性-后端没有做校验 4、正常示例先结构设计、异常场景(全面)4.2 尽早加入jenkins集成
4.3 定期汇报进度
4.4 试验报告，自动发送报告、分析示例失败原因
4.5 记录USB智能化开始到当前的bug
4.6 异常处理情况
5、持久化层构造
1、资料库直接插入数据
6、维护阶段
1、开发修改USB，试验同步修改USB脚本
2、新增USB，同步新增USB示例
3、脚本、日常框架优化
4、实用性文档持续更新
(二)一般而言组件是不是去做试验的呢？
单组件试验：在试验工作中主要用于检查一般而言销售业务机能的USB实现，或者调试试验数据。
第一步：梳理上下游调用链
1）为甚么要梳理上下游调用链？
目前互联网产品的后端服务，基本上都是分布式部署 的，一个USB可能会调用其他USB，也有可能被其他USB调用，USB与USB之间，具有千丝万缕的依赖关系。
如果只是单独的调调模块，就希望把USB试验做好，显然是不可能的。（开发自己都能调（tiao）USB模块，还要试验做甚么？）
2）是不是梳理上下游调用链？
1、看工程项目wiki、产品文档和开发文档
2、看开发写的代码，阅读代码
3、梳理出上下游调用关系，手绘一份控制系统流程图，如果还有不明确的地方，可以找PM、开发沟通确认
第二步：编写USB试验示例
如果说要做USB智能化，USB试验示例也是很有帮助的。
这里给出一个USB试验示例的案例：
第三步：试验USB文档&调试USB
在工程项目开发之初，前端开发和后端开发会共同去约定一套USB规范，然后由后端开发去编写USB文档，然后前后端就可以按照约定去进行协同开发。
USB文档的管理和编辑有多种形式：
有的团队习惯用wiki或者在线文档去编写USB文档； 有的团队喜欢用专业的USB文档辅助工具，比如：Swagger、Yapi等去生成USB文档。试验USB文档可以参考以下试验点：
确保开发必须提供USB文档。如果开发没有写USB文档的习惯，应push开发去写USB文档。检查USB文档的格式内容等与否完备，包括：URL、允诺方法、Header、入参、返回值、示例Demo等。 检查USB结构设计与否符合公司规范。包括USB命名、USB格式、字段命名、字段类型、积极响应状态码、USB容错、字段与否冗余、USB与否鉴权、与否做版本区分等等。当后端开发完成USB的开发工作时，我们就可以提前开始对USB进行初步试验了。
步骤如下：
把后端代码部署到试验环境上。 通过postman或swagger去对USB文档提到的USB进行试验。第四步：前端USB试验&Mock数据（USB层面的试验）
前面的步骤只是利用试验辅助工具去发动网络允诺，来模拟USB调用。
但在真实的场景下，搜索网关的USB实际上是提供给 APP/WEB/小程序 进行调用的。
我们同样也需要。（需要等待前端开发完毕，才能介入试验）
可以利用Charles来对前端发送的允诺进行抓包，
验证前端调用USB的传参与否正确； 验证后端的USB积极响应与否符合预期； 前端拿到数据之后，交互和UI展示与否正确。当有些数据有多种状态，并且数据较为难以构造时，我们可以通过Mock数据去进行试验。
常见的Mock数据的形式有：
用 Fiddler 或者 Charles 去篡改允诺和积极响应。 如果是PHP或者Python等动态语言，可以直接在后端代码里面去更改条件。 数据库中去修改数据。 用专业的Mock辅助工具去构造数据，如：EasyMock、TestableMock、Mockjs等。较为快速的形式，当然是直接用Charles去模拟。
第五步：后端USB试验&销售业务逻辑覆盖（看日志、看代码）
看日志
有这时候USB积极响应数据是正常的，但是后端日志可能正在报错，
看代码
推荐大家在做USB试验的这时候，一定要去阅读开发的源码。
阅读源码可以对销售业务逻辑实现介绍更加深入。
如果代码量很大是不是办？
告诉大家一个小诀窍：当开发提交代码之后，我们可以在Gitlab上看他的Commit记录，或者将他的开发分支和生产环境的分支做个diff，这种就能知道他改了哪些地方。
第六步：USB性能调优（Arthas）
排查过程 ：
（1）先在APP上尝试复现
（2）通过Arthas的trace逐步去排查USB积极响应慢的原因：
进入Arthas命令行
java -jar arthas-boot.jar
trace USB调用的方法
trace 类名 方法名
第七步：USB版本控制&diffy
一般USB都会区分版本，如果USB不是很规范，或者改了一些通用的逻辑，那个这时候就需要对老版本进行一次回归试验。
最笨的方法就是拿新老版本的两个app对比试验。我们也可以用diffy那个辅助工具来做回归试验。
第八步：开始做USB智能化
USB智能化一般常用于进行线上巡检回归、提测冒烟试验等场景。
实现USB智能化，采用一下形式：
coding：
python+pytest+requests，目前采用这种形式去做。（小而美，方便定制化）
(三)数个组件关连是不是去做试验的呢？
组件关连：是指将两个及以上相关API的出入参以模块化的形式达成动态关连，以实现整个事务的试验覆盖，达到基础的辅助工具USB智能化试验。
第一步：梳理上下游调用链
1）为甚么要梳理上下游调用链？
目前互联网产品的后端服务，基本上都是分布式部署的，一个USB可能会调用其他USB，也有可能被其他USB调用，USB与USB之间，具有千丝万缕的依赖关系。
如果只是单独的调调模块，就希望把USB试验做好，显然是不可能的。（开发自己都能调（tiao）USB模块，还要试验做甚么？）
2）是不是梳理上下游调用链？
1、看工程项目wiki、产品文档和开发文档
2、看开发写的代码，阅读代码
3、梳理出上下游调用关系，手绘一份控制系统流程图，如果还有不明确的地方，可以找PM、开发沟通确认
第二步：编写USB试验示例
如果说要做USB智能化，USB试验示例也是很有帮助的。
这里给出一个USB试验示例的案例：
第三步：试验USB文档&调试USB
在工程项目开发之初，前端开发和后端开发会共同去约定一套USB规范，然后由后端开发去编写USB文档，然后前后端就可以按照约定去进行协同开发。
USB文档的管理和编辑有多种形式：
有的团队习惯用wiki或者在线文档去编写USB文档； 有的团队喜欢用专业的USB文档辅助工具，比如：Swagger、Yapi等去生成USB文档。试验USB文档可以参考以下试验点：
确保开发必须提供USB文档。如果开发没有写USB文档的习惯，应push开发去写USB文档。 检查USB文档的格式内容等与否完备，包括：URL、允诺方法、Header、入参、返回值、示例Demo等。检查USB结构设计与否符合公司规范。包括USB命名、USB格式、字段命名、字段类型、积极响应状态码、USB容错、字段与否冗余、USB与否鉴权、与否做版本区分等等。当后端开发完成USB的开发工作时，我们就可以提前开始对USB进行初步试验了。
步骤如下：
把后端代码部署到试验环境上。 通过postman或swagger去对USB文档提到的USB进行试验。第四步：USB场景化结构设计
背景：现有平台对单服务单USB智能化试验流程相对成熟，而对于繁杂的跨服务的智能化示例实用性的需求反馈日益增多，所以，增加对于繁杂试验场景的支持
甚么样的示例适合场景化
也可称为销售业务流，例如：举个电商类case，下单购买-支付-验证支付状态-查阅权限-退款-验证退款状态
无论与否跨应用，步骤有前后有强依赖关系 核心兜底销售业务场景，比如，下单-支付-履约-退款基于以上背景，此次工程项目对应的机能点如下：
增加【场景集】概念，等同于原有的【工程项目】 增加【试验场景】概念，与原有的【示例集】类似 触发关连的试验场景第五步：前端USB试验&Mock数据（USB层面的试验）
前面的步骤只是利用试验辅助工具去发动网络允诺，来模拟USB调用。
但在真实的场景下，搜索网关的USB实际上是提供给 APP/WEB/小程序 进行调用的。
我们同样也需要。（需要等待前端开发完毕，才能介入试验）
可以利用Charles来对前端发送的允诺进行抓包，
验证前端调用USB的传参与否正确； 验证后端的USB积极响应与否符合预期； 前端拿到数据之后，交互和UI展示与否正确。当有些数据有多种状态，并且数据较为难以构造时，我们可以通过Mock数据去进行试验。
常见的Mock数据的形式有：
用 Fiddler 或者 Charles 去篡改允诺和积极响应。 如果是PHP或者Python等动态语言，可以直接在后端代码里面去更改条件。 资料库中去修改数据。 用专业的Mock辅助工具去构造数据，如：EasyMock、TestableMock、Mockjs等。较为快速的形式，当然是直接用Charles去模拟。
第六步：后端USB试验&销售业务逻辑覆盖（看日志、看代码）
看日志
有这时候USB积极响应数据是正常的，但是后端日志可能正在报错，
看代码
推荐大家在做USB试验的这时候，一定要去阅读开发的源码。
阅读源码可以对销售业务逻辑实现介绍更加深入。
如果代码量很大是不是办？
告诉大家一个小诀窍：当开发提交代码之后，我们可以在Gitlab上看他的Commit记录，或者将他的开发分支和生产环境的分支做个diff，这种就能知道他改了哪些地方。
第七步：USB性能调优（Arthas）
排查过程 ：
（1）先在APP上尝试复现
（2）通过Arthas的trace逐步去排查USB积极响应慢的原因：
进入Arthas命令行
java -jar arthas-boot.jar
trace USB调用的方法
trace 类名 方法名
第八步：USB异常机制（Chaosblade）
因为USB依赖的服务很多，经常需要调用其他USB。假如依赖的服务出现了异常，我们就需要考虑我们的USB是不是做了容错处理，或者是降级处理。
可以用Chaosblade去注入异常。（非必须，但有更好）
第九步：USB版本控制&diffy
一般USB都会区分版本，如果USB不是很规范，或者改了一些通用的逻辑，那个这时候就需要对老版本进行一次回归试验。
最笨的方法就是拿新老版本的两个app对比试验。我们也可以用diffy那个辅助工具来做回归试验。
第十步：开始做USB智能化
USB智能化一般常用于进行线上巡检回归、提测冒烟试验等场景。
实现USB智能化，采用一下形式：
coding：
python+pytest+requests，目前采用这种形式去做。（小而美，方便定制化）
