趁着下班空闲的一会时间回顾了一下 12.19 日参加的杭州第六届测试沙龙的收获，四个议题，收获多多，大概整理了一下，明确一下一些内容的方向。

具体的 PPT 不知道官方允不允许放出来，就先不抛了，后面有回应的再加上分享的 PPT

1.《云设计工具前端性能测试建设及实践》

• 主讲人： 寻迹 酷家乐 质量效能部
• 收 获：从 0 到 1 建设一项测试领域所需要的流程，以及测试落地时候所需要做的事情。

• 详 情：

  1. 要有对测试产品完善的认知，产品解决什么问题？用户场景是什么样子？新增的测试领域能为用户带来什么体验？方便制定测试目标。
  2. 对测试产品的技术架构有清晰的认识，方便测试工作中技术方案的制定以及测试工作中所采用的技术手段。
  3. 参考业界同行在这个领域是怎么做的？移植到自己的产品进行调整优化，完善出属于自己产品的测试方向。
  4. 针对于制定的测试方向和自己业务的难点进行一一对应，然后进行问题细分，制定不同方向的测试指标。

• 具体的建设流程如下：

• 其他： 期间听众提问了三个问题,都是和 UI 自动化相关的内容，大意是遇到一些 UI 界面上锯齿要怎么处理，由此可鉴一部分测试关注点更注重在功能实现的环节上。

2.《手淘 AIOps 实战 - 消息全链路智能监控》

• 主讲人： 阿里巴巴 - 董福铭（吾铭）、黄俊（豆豆）
• 收 获： 自己在下一阶段的规划里也有关于日志监控的内容，相当于帮忙点了一盏明灯，瞻仰一下前沿的同行们对于日志这块是怎么处理的。
• 细 节：
  1. 日志协议统一。我们这里的业务有多种协议，涉及后台服务，前端应用，智能设备，智能硬件。想去查询日志的时候，需要到各个角落里去收集查看，如果有统一的日志协议，的确是可以上送平台，做集中处理。
  2. 高度不同，领悟不到啊，我多加油！！！

3.《质量 - 监控体系建设》

• 主讲人： 王静文 有赞
• 收 获： 对监控的一个整体认识。
• 细 节：
  1. 监控的 4 个黄金指标 1) 延迟：服务处理某个请求所需要的时间。 2) 流量：使用系统中的某个高层次的指标针对系统负载需求所进行的度量。 3) 错误：请求失败的速率。 4) 饱和度：服务容量有多满，比如 CPU，IO，内存等等
  2. 告警信息规范。上面聊到了下一阶段有做日志监控的想法，所以这个规范对我来说还是比较及时的。 1) 告警标题。精简并且有指导性，提升处理效率。 示例：服务名称 - 上送时间 2) 告警级别。设置合理的告警级别 info?warn?critical? 示例：报警等级， 这里有一个要明确的点是：要和后台人员制定好日志打印规则，不然全部是 info 是没有意义的 3) 告警原因。信息明确，告警规则清楚。 示例：规划是报警日志上下 20 条 4) 告警人提醒：开发，运维，测试。 示例：企业微信发送项目群 5) 响应规范。谁在响应？什么问题？影响什么场景？什么用户？处理方式是什么？

4.《质量效能改进三板斧》

• 主讲人： 贺达 E 签宝
• 收 获：
  1. 对电子签名业务以及产业链的了解（借 PPT 里的一张图），一个极其小众的业务类型，比我现在负责的公交业务类型还小众。
  2. 前辈是怎么用两年的时间把一个团队从一穷二白的囧到鸟枪加大炮，一个团队崛起的历程，值得借鉴的地方有很多很多。
  3. 认识到自己对自动化工作方向的错误（最大的收获）。
• 细 节：
  1. 自动化方向的错误。市面上常见的测试框架 1) pytest/unitest（负责用例执行）+SQL/yaml/Excel（用例存储）+Allure(报告展示)+ 钩子（邮件/钉钉/企业微信通知)+Jenkins/Gitlab（CI）+request（模拟 HTTP 请求，其他协议另选模块） 2) Httprunner（负责用例执行）+yaml(用例存储)+ 其他 3) pytest/unitest（负责用例执行）+rebotfarmwark（负责用例编写）+ 其他 4) Testng+httpclient+Allure+SQL/yaml/Excel（用例存储）+ 钩子（邮件/钉钉/企业微信通知)+Jenkins/Gitlab（CI） 5) Testng+restassured（模拟 HTTP 请求）+ExtentTestNGIReport（报告）+ 其他

之前我在选择和练手如上的这些框架的时候，第一反应就是减少使用者的代码量，尽量可以在 SQL，Excel,Yaml 等格式的文档中直接编写用例，为了实现这个效果，尽可能的做出异常判断，但是，远远没有 JMeter 做的完善。

JMeter 是可以实现零代码实现接口自动化，有自定义需求的时候也可以通过 jar 包来实现扩展，那么，自己写自动化脚本的意义在哪？

在看到如下的对比过程中，突然意识到一个事情：

测试是一个技术岗位，日常工作中不应该去减少代码量，甚至应该去增加代码量，只有这样，才能逐渐理解开发所实现的逻辑，也可以摆脱测试只是点点点的岗位，进一步还可以实现 codereview 的目标，摆脱鄙视链末端。从这个角度来看，我之前的自动化方向一直就是错的。

那么自动化的意义在哪？提效，尽可能的提高测试同学来编写自动化脚本的质量与速度，提供排查手段，发现错误迅速定位，提高排查问题的能力（自己踩的坑还要自己填），附带珍藏的自动化测试架构图！

• 2. PPT 里的介绍的开源工具链接,一身技术来源于网络（菜是原罪），还是要归还于网络的。
• 3. 质量红线的设计思路以及实施方案。目前在我的团队里边很难推动这个事情，就先看看了，需要的时候及时借鉴。
• 4. 数据工厂的解决方案，膜拜一下大佬，真的是用了一个很巧的思路并且成本很低来解决数据工厂的难点。

竟然是通过 flask+swagger 的方式来解决，swagger 的 UI 是修改过的，这样才贴合自身的业务，甚至于 swagger 的原始数据也应该是做了修改。但是，这么一种解决方案，极大的降低了测试不用又搞前端，又搞后端的形式，再膜拜一遍，这种方式是真的巧，有空的时候试着实现一下。

• 5. 照着敲了一遍示例代码，发现学了 Java 之后对之前 Python 的一知半解理解的更透彻了一点。之前对于私有变量（private），特殊变量是没什么感受的，知道有这么一回事，但是没用过，抄了一下代码，发现还能这么玩，受教了，截图中有个调试工具，蛮好用的，推荐一下。