趁着下班空闲的一会时间回顾了一下 12.19 日参加的杭州第六届测试沙龙的收获，四个议题，收获多多，大概整理了一下，明确一下一些内容的方向。
具体的 PPT 不知道官方允不允许放出来，就先不抛了，后面有回应的再加上分享的 PPT
1.《云设计工具前端性能测试建设及实践》
- 主讲人： 寻迹 酷家乐 质量效能部
- 收 获：从 0 到 1 建设一项测试领域所需要的流程，以及测试落地时候所需要做的事情。
-
详 情：
- 要有对测试产品完善的认知，产品解决什么问题？用户场景是什么样子？新增的测试领域能为用户带来什么体验？方便制定测试目标。
- 对测试产品的技术架构有清晰的认识，方便测试工作中技术方案的制定以及测试工作中所采用的技术手段。
- 参考业界同行在这个领域是怎么做的？移植到自己的产品进行调整优化，完善出属于自己产品的测试方向。
- 针对于制定的测试方向和自己业务的难点进行一一对应，然后进行问题细分，制定不同方向的测试指标。
具体的建设流程如下：
- 其他： 期间听众提问了三个问题,都是和 UI 自动化相关的内容，大意是遇到一些 UI 界面上锯齿要怎么处理，由此可鉴一部分测试关注点更注重在功能实现的环节上。
2.《手淘 AIOps 实战 - 消息全链路智能监控》
- 主讲人： 阿里巴巴 - 董福铭（吾铭）、黄俊（豆豆）
- 收 获： 自己在下一阶段的规划里也有关于日志监控的内容，相当于帮忙点了一盏明灯，瞻仰一下前沿的同行们对于日志这块是怎么处理的。
- 细 节：
- 日志协议统一。我们这里的业务有多种协议，涉及后台服务，前端应用，智能设备，智能硬件。想去查询日志的时候，需要到各个角落里去收集查看，如果有统一的日志协议，的确是可以上送平台，做集中处理。
- 高度不同，领悟不到啊，我多加油！！！
3.《质量 - 监控体系建设》
- 主讲人： 王静文 有赞
- 收 获： 对监控的一个整体认识。
- 细 节：
- 监控的 4 个黄金指标 1) 延迟：服务处理某个请求所需要的时间。 2) 流量：使用系统中的某个高层次的指标针对系统负载需求所进行的度量。 3) 错误：请求失败的速率。 4) 饱和度：服务容量有多满，比如 CPU，IO，内存等等
- 告警信息规范。上面聊到了下一阶段有做日志监控的想法，所以这个规范对我来说还是比较及时的。 1) 告警标题。精简并且有指导性，提升处理效率。 示例：服务名称 - 上送时间 2) 告警级别。设置合理的告警级别 info?warn?critical? 示例：报警等级， 这里有一个要明确的点是：要和后台人员制定好日志打印规则，不然全部是 info 是没有意义的 3) 告警原因。信息明确，告警规则清楚。 示例：规划是报警日志上下 20 条 4) 告警人提醒：开发，运维，测试。 示例：企业微信发送项目群 5) 响应规范。谁在响应？什么问题？影响什么场景？什么用户？处理方式是什么？
4.《质量效能改进三板斧》
- 主讲人： 贺达 E 签宝
- 收 获：
- 对电子签名业务以及产业链的了解（借 PPT 里的一张图），一个极其小众的业务类型，比我现在负责的公交业务类型还小众。
- 前辈是怎么用两年的时间把一个团队从一穷二白的囧到鸟枪加大炮，一个团队崛起的历程，值得借鉴的地方有很多很多。
- 认识到自己对自动化工作方向的错误（最大的收获）。
- 对电子签名业务以及产业链的了解（借 PPT 里的一张图），一个极其小众的业务类型，比我现在负责的公交业务类型还小众。
- 细 节：
- 自动化方向的错误。市面上常见的测试框架 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），特殊变量是没什么感受的，知道有这么一回事，但是没用过，抄了一下代码，发现还能这么玩，受教了，截图中有个调试工具，蛮好用的，推荐一下。
伍个一
回复
测试最大的问题其实在于 没有创造价值 只是减少损失 但是 bug 不可能消失的 损失是不可避免的 按照中国国情 测试处于最后一个把关人 不论你测试技术多强 体系建设的多少 减少了多么多可能存在的损失 老板看到的永远是现在这个 bug 给我造成了损失 而不是关注你规避了多少损失 规避的损失在老板眼里这些是天经地义的 没出现的损失老板是不会在意的
图加载不出来呢
自动化那块不是很赞同,自动化平台傻瓜性操作效率绝对远大于直接编写代码 ,灵活性扩展性 可以依赖在线代码编译成动态字节码 而且自动化平台在可视化方面也比较好 只是现在市场上相对好点的自动化平台还没有 没有多少能支持灵活扩展 操作简单的而已 很多人写自动化平台只是为了 kpi 或者提高自己的代码能力 没有从一个产品的角度去考虑这个自动化平台
陈建富
回复
我还是认同 e 签宝的测试负责人贺达的，我非常的反对做傻瓜式的自动化平台，可能会带来更多的问题，可能每个人所处的环境和个人经历不一样导致的。贺达当时面临的团队都是纯功能测试，没有懂代码的可以深入业务和架构的。所以说可能你看到的是一些效率，我更关注的是团队能力。效率其实还有更多的手段。当然如果是 BAT 就好一点，因为他们在人才筛选上具备更大的优势，而中小型公司在技术人才培养上是需要时间的
jmeter 最大的 2 个缺陷是 1 保存脚本的逻辑零散 不好沉淀各流程脚本 每次打开繁琐 可视化方面缺陷 2 编写用例的时候繁琐 要配置一大堆东西 没有约定即默认配置的思想 自动化平台实现 jmeter 的 web 化 在针对 jmeter 的缺陷做修补 约定即配置 操作更傻瓜性 这个就是自动化平台比 jmeter 的优势和意义 只不过市场上还没出现这种企业级的接口自动化产品
写代码的劣势 先不说测试个人代码水平可能会有 bug case 多的时候 可视化低 维护成本随着 case 增加项目文件增加会越来越高
陈建富
回复
平台呢？好是当然好，但是我觉得平台的方案会弱化使用者的代码能力，使用者傻瓜式的操作就行了，对于整个测试团队来说，不是一个好的方案。
更倾向于团队里自己用代码写 case（在线编译的方案可以有），加深对于代码，数据结构的理解，在测试工作中定位缺陷的时候也更容易一点。
也可以摆脱测试地位低的帽子（自认为测试地位低是因为在一个技术团队里，测试是偏技术薄弱的一方，如果技术好，还地位低？）
面对疾风吧
回复
遇到问题，解决问题。我认为我的自动化方向错误是因为这个
平台是好，但是对于团队来说，整体的综合能力更重要！！！
据我了解，大厂的外包同学对于自己使用的平台没有多少参与度，工具是会用的，但是综合能力呢？代码编写，BUG 定位这些呢？
我没有参与过大型的测试团队，所以，我的理解可能有点偏差
陈建富
回复
JMeter 的缺陷问题，有舍有得，根据实际情况衡量吧
- 保存脚本的逻辑零散；借鉴包命名的思路，针对于自己的用例结构进行拆分。 2.编写用例的时候繁琐 要配置一大堆东西，没有约定即默认配置的思想;使用前培训，进行约定，规则说明 3.可视化低；这个没有好的解决方案，maven 集中管理和命名空间来解决吧
，经常来社区逛逛吧伍个一
回复
从整个测试行业角度上来讲 肯定是写代码比较好的 可以提高测试的技术水准 相当于提高门槛 压低纯功能测试的生存空间 从而提高测试整体人员的技术水准 但是这是要一个过程的 不是那么容易带动整体行业的发展 我觉得现在就挺好的 有薪资追求的 研究代码 错测试开发等 没薪资追求的 做做纯功能测试 养家糊口 等大家整个行业真的 都会代码了 到时候真不一定会是个好事情 更大的可能是 企业只愿意花 8k 招个 代码能力弱点的测试做功能 不是所有企业都吃的消测试的薪资上浮 现在还有很多公司花 6 7k 找几个测试
伍个一
回复
测试最大的问题其实在于 没有创造价值 只是减少损失 但是 bug 不可能消失的 损失是不可避免的 按照中国国情 测试处于最后一个把关人 不论你测试技术多强 体系建设的多少 减少了多么多可能存在的损失 老板看到的永远是现在这个 bug 给我造成了损失 而不是关注你规避了多少损失 规避的损失在老板眼里这些是天经地义的 没出现的损失老板是不会在意的
陈建富
回复
老板只会关注 当前这个 bug 给我造成多少多少的损失 这个测试怎么这个没发现 是不是测试技术不行 老板自己认知不了 bug 和产品和用户肯定会一直相生相随的 用户越多 bug 就会越多
其实现在 metersphere 的平台就做得不错，它是类似 postman 的界面，你把 postman 的内容导进去，再加上断言就是借口自动化用例了，也支持整合到 jenkins，比 jmeter 要强。
陈建富
回复
我觉得核心是不是测试总监和他的上级是如何思考的，这个问题决定了测试团队的倾向吧，我觉得我们公司还好，我们的 CTO 作为创始人，相对而言也没有那么短时，我们的故障 review 也很少把板子打在测试上， 所以我考虑的是更长远的事情，故障之类的和开发绑定，团队的整体能力是我重点思考的。
jmeter 能够 web 化，结合各公司实际情况，再稍微研究一下 jmeter 的 API，通过 java 代码生成 jmeter 脚本的 HashTree 很简单的
数据工厂也能执行动态代码（用户 web 页面粘贴 java 代码，平台动态编译执行，也可以是 python 代码，平台调用执行）
业务逻辑和平台功能分离
陈恒捷
回复
有时候问题是 他们都知道测试是必须要有的 测试是重要的 但是每次线上出 bug 的时候 下意识的第一个想法 都是 这个测试是不是不靠谱啊 这个 bug 都没发现 第一印象很重要的 所以就造成现在这种现象 测试的这个过程是重要的 但是测试人员的地位是无足轻重的 因为线上经常会出问题 久而久之 就会下意识的觉得 公司的这个测试能力是不是不行 换一个测试 是不是好点的想法 然而不论公司怎么换人 都是解决不了这个问题的 这个是程序自身的局限性决定的 其实如果线上经常出奇怪的 bug 换开发比换测试更有效 但是公司只会换测试而不会去换开发 这种情况无论换几个测试 遇上不靠谱的开发还是没辙 不能从根源上杜绝 bug code review 机制不是那么好推广落地的 除非能力极强的测试 不然所有测试遇到这种情况都半斤八两 开发技术越弱的团队测试地位越低
陈建富
回复
这种观点未免太悲观了点，诚然测试是容易背锅的岗位，但是有些开发造成的问题，是可以通过努力让团队和 leader 认识到的，并不会最终把责任定给测试。无法改变人的第一印象，那么就需要前期做好记录，遇到线上事故能拿出可以解释的证据，如果总是发现是开发导致的，难道还会认为是测试不靠谱么？
测试开发体系
回复
个体改变不了整体的 在整个软件行业 线上出问题 70% 以上都是测试自身的问题吧 . 出问题 原因无非是什么项目时间紧 没有全面回归 漏测 等等诸如此类的 整个大环境如此 就算你自己的团队测试强无敌 没有任何测试引起的 bug 但是改变不了整个软件行业测试的地位 所以我说了 测试只能去开发技术强,团队管理强的团队才能实现地位的提高 但是二八原则 整个软件行业 80% 都是技术不怎么强 团队不规范的企业 所以不论你个体怎么努力 大环境是不可能改变的 岗位性质和大环境决定了 80% 的测试地位只能偏低 但是你可以通过自己的努力进入那 20% 大环境无法改变 努力去那些优秀的团队实现自己的价值
测试开发体系
回复
还有一个 很多三四年的功能测试 就是为了安逸的拿一份普通的 6 7 8k 薪资养家糊口的 这种测试你指望他们提高自身的测试水平不现实 这种测试人员的基数很庞大 testhome 的各位才是整个测试行业里的少数人而已
陈建富
回复
但是每次线上出 bug 的时候 下意识的第一个想法 都是 这个测试是不是不靠谱啊
这种情况，就得在线上出问题后复盘时，测试一起参与甚至主导了。先得要明确，线下的测试无法发现线上所有缺陷，有的缺陷确实是测试环境无法复现，或者测试成本极高的（比如必须要用线上的数据才能出现）。另外，要引导说明，预防这个问题再次出现，测试、开发甚至产品需要做什么。让老板知道，解决问题不只是测试要干活，开发、产品都要干，意味着他们都有责任。
不过有一个基础要做好，不要出现那种很简单就能发现而且是 P0、P1 级别功能的 bug，并且造成不小的损失。出现这类问题，不管怎么说测试都有责任的。
但是公司只会换测试而不会去换开发
那可以预见换多少个测试都没用，因为 bug 都是开发写的。。。
开发技术越弱的团队测试地位越低
不一定呀，只要测试指出了这个点，并且去各种推动开发提升自己技术和质量，那测试地位就不比开发低。如果说测试只会在出问题后后知后觉，那地位肯定高不到哪里去。
最后多少几句，如果说老板本身的态度就是 “测试是为了保障系统不出问题的，出问题都是测试没做好”，那就要明确，要做到确实没问题可以，成本增加 2 倍甚至 3 倍。就像同一个代工厂，可以生产高质量的 iphone，也可以生产低质量的山寨机，只取决于你的质量标准多高，愿意付出多少成本去覆盖不良品和检测成本。老板们都不笨，所有缺陷和故障背后都有 roi 的，比如一个服务器机房造成的故障，作为公司要彻底解决那可能得多地灾备或者搬另一个机房，但如果这个缺陷其实造成的损失不大而且出现频率不高，最后其实还是会保持现状的。
另外，感觉你有点悲观，观点里有许多 “不现实” ，“不可能” 。积极点看，应该是 “很难” “几乎不可能”，但概率绝不是 0。确实个体力量很难扭转大局，但从自己做起，由己及人，积沙成塔，也是能产生不小的影响的。莫以事小而不为，只要觉得正确，就去干吧。
PPT 现在有开放么？对贺达的议题《质量效能改进三板斧》很感兴趣