• 1.《云设计工具前端性能测试建设及实践》
• 2.《手淘AIOps实战-消息全链路智能监控》
• 3. 《质量-监控体系建设》
• 4. 《质量效能改进三板斧》

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

image

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

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

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

• 具体的建设流程如下：

流程

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

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

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

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

• 主讲人： 王静文 有赞

• 收 获： 对监控的一个整体认识。

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

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

• 主讲人： 贺达 E签宝
• 收 获：

  1. 对电子签名业务以及产业链的了解（借PPT里的一张图），一个极其小众的业务类型，比我现在负责的公交业务类型还小众。
     image
  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的目标，摆脱鄙视链末端。从这个角度来看，我之前的自动化方向一直就是错的。

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

image

image

• 2. PPT里的介绍的开源工具链接,一身技术来源于网络（菜是原罪），还是要归还于网络的。
• 3. 质量红线的设计思路以及实施方案。目前在我的团队里边很难推动这个事情，就先看看了，需要的时候及时借鉴。

• 4. 数据工厂的解决方案，膜拜一下大佬，真的是用了一个很巧的思路并且成本很低来解决数据工厂的难点。

     
     
     image

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

image

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

     
     
     附调试