匿名职言 为什么一聊测试技术就条件反射的各种框架、工具、平台？
昨天看到美团技术博客的一篇关于测试用例设计的文章，觉得特别好。
纵观团队内部，或者一些外面的聊天群组，但凡讨论测试技术，总数离不开某某框架，某某平台，某某开发语言等等，然而大家在回顾一下自己手上的事情，是不是这些东西真的帮助业务解决了绝大部分问题？其实我也时常困惑不已，为什么团队只有靠这些研发技术才能获取 KPI？为什么领导需要开发出 ** 平台，自动化覆盖率才能喜笑颜开？如何能让测试的抵达率、测试用例的覆盖率更全面更有效？如何发现更深层次的问题？有没有更换的测试手段？
这里倒不是吐槽，至少对于行业现象的一种困惑。欢迎讨论拍砖
额。。其实这个我个人觉得咩有太多讨论的必要。其实你看到的是对的，困惑也是对的。我可以说的是，其实就是现状，当然也不是所有的测试，所有的 leader 都这样。大多数
我也反感动不动就搞平台. 除非他们的确有能力把平台开源开放出来. 不然就会成了 KPI 项目. 然后年久失修慢慢死掉.
工具尽量使用开源的方案, 实在没有再自己封装.
对于企业内部, 我也建议做的事情敢于开源, 不然自己也会慢慢失去动力去维护的.
还有一个问题是很多公司自己搞的平台, 都不支持持续集成....
#2 楼 @seveniruby KPI 的问题，不是大家想，大多数无奈
政治任务是一方面，另一方面是引起团队内部很多人不想做业务，只想做平台的不好风气，擅长做业务的担心没有办法出绩效。管理者可能也有难言之隐吧
黑盒测试搞好了也很 NB 啊，能写出全面的测试案例也很 NB 啊，但是这个能写进 KPI。。。就是这样。。。
我个人觉得是框架、工具、平台的东西可适用的范围更大。
而测试用例设计什么的，其实还是要看具体业务的。并不像上述的那样能够直接套过来用。
目前搞平台这种现象我也不支持。能用开源尽量用开源。
但前提是你已经具备开发框架、工具、平台的能力。
有了这些技能，你才具备高效的测试抵达率、测试用例的覆盖率、发现更深层次的问题。
一个群里那么多人 大家干啥的都有 聊天不聊这些框架啊工具啊平台啊怎么彰显自己的身份地位呢？聊业务？其一是大家各行各业的都有，驴唇不对马嘴，聊不了两句就没人接话了。再者说业务聊着聊着泄密了怎么办？
学习了
测试行业基础不好的人很多，但是不敢承认，所以只能用什么平台啊，架构啊一些看似高大上的东西来宣示自己已经脱离了基础基础级别，借以掩饰自己的基础不好，然后到头来一般是什么平台架构都没搞出来，原因还是因为基础不好。
这个就和比较音响有些类似，你说这个音响怎么好怎么好应用了什么技术，听起来感觉如何如何，都是比较软性的，不懂行的人也听不懂。直接说音响 A 卖 1000 块，音响 B 卖 2000 块，啊！果然 B 比 A 好。不懂行的没法判断，缺乏安全感（对判断不懂的事物），想依赖那些能看得见的东西（2000 块>1000 块）。
因为在别人眼里，测试就是 low, 所以要说写别人不懂，或者看似高大上的东西。
真正会学习的人或者技术好的人，是不屑于加群的
工程师的想法和 leader 站角度不同
—— 来自 TesterHome 官方 安卓客户端
#2 楼 @seveniruby 我离开上个东家就因为这个原因。所有人为 kpi 工作。搞了一年自动化。生产各种框架平台。结果连个持续集成都没有。测试环境里没有一条能重复执行的脚本
#2 楼 @seveniruby 额，原来我刚才是匿名说的
诚然。很多人为了 kpi 而活，所以必然满嘴的框架，平台。到处吹嘘自己有多么高大上技术。否则如何能忽悠住老板？但持续集成里到底有几条有效的脚本明眼人心里都有数。我特烦动不动就接口测试平台的，我就没见过什么接口测试平台支持持续集成的。全是一次性产品，基本靠手工驱动。可能我呆的公司都比较 low 吧。没去过 BAT 那么牛逼的地方。
但也不可否认测试需要好的框架。现在都是用开源的然后二次开发。也算是做了个框架吧。虽然我觉得其实没太多代码量。一个人没多久就能搞出来。我倒是觉得更重要的是开发技术。所谓的测试技术，其实就是开发技术的一个分支。一个人开发技术不咋地。测试技术必然也不咋地。所以测试人员需要搞代码。需要搞框架。开发牛逼的人测试也必然差不了
我认为把 “测试任务” 和 “测试技术” 分开理解讨论就好了，本身测试技术就是要讨论解决测试效率和持续有效运作的流程和框架。
每个测试团队扛的是 “测试任务”：测试验证覆盖率，bug 产出，用户反馈 bug 回溯跟踪。
而服务于测试效率的是 “测试技术”：自动化 UI 功能验证相关框架，专项压力脚本方案，手工辅助性测试工具，服务测试流程的框架模板等。
统筹人员和任务流程的是 “测试管理”：协调各测试任务的人员配比，对接配合部门接口需求，控制用例覆盖程度，管理追述 bug 状态，推进集成 “测试技术” 提高效率，推进人员培训提高测试人员能力等。
我认为综合在一起才是 “测试团队”。每个部分都可以单独提出来讨论，如” 测试技术 “。至于是否适用就得放到 “测试团队” 中去考量。
。。。没必要匿名，再发一遍
我认为把 “测试任务” 和 “测试技术” 分开理解讨论就好了，本身测试技术就是要讨论解决测试效率和持续有效运作的流程和框架。
每个测试团队扛的是 “测试任务”：测试验证覆盖率，bug 产出，用户反馈 bug 回溯跟踪。
而服务于测试效率的是 “测试技术”：自动化 UI 功能验证相关框架，专项压力脚本方案，手工辅助性测试工具，服务测试流程的框架模板等。
统筹人员和任务流程的是 “测试管理”：协调各测试任务的人员配比，对接配合部门接口需求，控制用例覆盖程度，管理追述 bug 状态，推进集成 “测试技术” 提高效率，推进人员培训提高测试人员能力等。
我认为综合在一起才是 “测试团队”。每个部分都可以单独提出来讨论，如” 测试技术 “。至于是否适用就得放到 “测试团队” 中去考量。
为了平台而平台就是耍流氓
—— 来自 TesterHome 官方 安卓客户端
有些工具和框架本身作用就是为了检查测试用例不足，从而补充测试用例，比如覆盖率就是。
测试交付，交付效能提升，交付减少往返开销是不一样的啊。。