对，十年前用过的工具了，一下子想不起名字来

你说的这种方式，以前微软的 vs coding 工具就是这么做的，把元素的很多属性都录制下来，然后回放的时候会根据这一组属性去识别元素，稳定性比只靠单个属性去识别要高。

测试必上自动化，我觉得这不是风气，而是每一个项目的管理者都必须会考虑到的必做项。
质量保障体系里面，有很多不同的环节：需求评审，设计评审，开发单元测试，系统集成测试，系统回归测试，用户验收测试，等等。而自动化是系统集成/回归测试阶段很重要的一步。
不做自动化，只用手动测试能做完集成测试和回归测试吗？ 当然可以。但问题是，你怎么保障测试的效率？怎么保证在不断迭代的过程中，测试人员不会疲惫而导致漏测？

什么公司？

只能说楼主说的几点，都是自动化做不好的因素，和自动化本身没什么关系。 如果自动化做得好了，这几点都能在一定程度被解决。

1. 敏捷模式： 难道你们的敏捷模式只跑一个 sprint？ 在后续的 sprint 里面不需要对已经做好的 story 进行回归测试？ 没有足够的自动化测试，怎么应对越来越多的功能和越来越大的回归测试范围？
2. 因为产品变动引起的自动化测试维护问题。 首先确定一个点，你们的产品每一轮都会把所有的功能和页面都改掉吗？ 即使每一个 sprint 里面变动的功能有 20%，那维护的工作量也只是这 20% 的用例，而且如果 page object 的结构做得好的话，页面变动很多时候只是元素定位的变化，用例的本身不需要修改。
3. 精准测试： --1 首先你能保证每次提测的代码都可以识别到 100% 准确的影响范围？ --2 其次，如果识别出来的范围也很大，如果没有自动化测试，纯手工进行测试，工作量会小吗？
   --3 再举个例子，如果开发和你说 JDK 升级了一个版本，或者服务器的操作系统升级了一个版本，你能精确识别出哪些测试范围呢？ 如果用足够的自动化，可能只是跑一次 job 的时间就能做到足够的覆盖，用纯手工的话要点多久？

而你最后的结论，都是基于你自己列举的自动化各种缺点得出来的，足够客观吗？ 能不能把优点也列出来对比呢？ 只看缺点的话，最后只会是一个片面的主观结论。

最后说一点吧，自动化测试都已经被提了几十年，从早期的商业化工具如 QTP，到已经迭代到 4.0 版本的 selenium，再到 appium，ATX， airtest ，cypress 等自动化框架，已经是百花齐放的局面了。如果只是盯着它的缺点或者不足，可能就会一直错过时代的发展。

CA_MD_TOO_WEAK] ca md too weak

我来试着翻译一下这个错误信息：
擦，md ,太弱了

环境不同，理解不一样。
连我自己到了新团队之后看着那惨不忍睹的自动化通过率，也一度怀疑自己以前做的是假自动化

小团队，就是自己管自己

pytest+ selenium 做 UI 自动化，pytest+request 做接口自动化。都是网上很多介绍的框架，不需要花很多时间来搭建。

至于写用例和维护，看你们团队和产品是否合适了，我们当时可能 20% 到 30% 的时间在自动化上。

感觉老哥你对这个团队有点执念啊

如果是我的话，努力也改变不了团队，可能是这个团队不适合你，换一个更好的呗

我觉得你这个也是特例吧，我也在小团队呆了三年多，然而并没有这种复杂的办公室政治关系。

谢谢邀请。不过那是我两年前的团队了，估计现在讲也不合适。

干货满满，谢谢大佬！

同意。 一个处于发展期的团队，特别是早期，其实有非常多环节是会被选择性忽略的，有些团队甚至前期都不会有测试，而是开发自测；但是一旦测试团队接人了，就有责任把这些缺少的环节一一补上：把没有的流程梳理起来，把简单粗暴的开发行为引导，约束起来。

篇幅有限，就不能逐个展开说了。
对于你说的如何推动，我过来的经验，是逐个问题，逐个解决。

比如分支管理：以前的分支设计没有考虑到实际产品中的开发节奏和发布节奏的不同步问题。以前的设计只有主干开发分支和已发布的 tag，非常简单粗暴，每次发布都可能把未完成的代码给带上了；而我们测试就是针对这种设计缺陷提出质疑，并且主导和开发团队讨论之后，梳理了开发分支，测试分支，待上线分支的管理流程，并且趁机制定代码管理规范。

比如质量管理流程，契机也是某次出现了开发的功能与需求不一致，从而引发的风险。我们作为测试，也是拉着开发和需求团队一起，把整个流程中的问题给分析出来，并且主导梳理出一个完整的需求 - 设计 - 开发 - 测试 - 上线，以及缺陷修复的流程，并且监督开发团队去执行。

我知道这些流程其实大家作为质量管理人员都有对应的意识，面试的时候都会作为基本功来考察。但是落地的时候永远有这样那样的困难。

回到我这个团队的例子，能把这些落地离不开以下几个方面：

1. 充分借助合适的契机去向你的开发团队推销这套流程，从测试的专业角度去为团队发现问题，预警风险和改进。不要轻易放过任何一个现有流程上问题，抓住改进的机会。

2. 如何赢取开发团队的信任和配合。针对发现的问题进行改进，而不是针对人；列举风险和合理，可行的改进建议，并且主导落地。

3. 另一个有趣的方面，是我们测试在这个团队的一个优势在于对产品，业务的熟悉程度比开发要强很多，能在需求评审，设计评审阶段提出很多正确的建议，替开发减少很多潜在的风险。当开发面对着一个能帮他兜底的业务专家时，自然也会配合测试做对应的工作。

4. 能为团队效率提升贡献能力。比如把接口测试封装好，让开发可以直接在 Jenkins 触发去做测试；比如写个造数脚本，方便开发进行自测，等等，测试自然会成为团队里有一定话语权的人。

大佬好强！

这个不太严谨，说的是 80% 的手工回归测试。

落地这个话题太大了吧

我尝试简单说一下：

1. 整理有什么影响开发测试流程的问题，包括：需求 - 设计 - 开发 - 测试 - 上线全流程；分支管理；上线规范。

2. 自动化落地：挑选使用最广泛的框架快速落地。我们使用的就是 pytest+request+allure +Jenkins 做接口自动化，pytest+selenium/appium 做 UI 自动化，基本上就可以保证你落地是没大问题的。不要在选择工具上浪费太多时间。

3. 落地的过程不要追求一步到位。我们的过程是小步快跑，慢慢优化。以下是大概的里程碑（UI 和接口自动化都适用）：
   -- 找网上的 demo 搭好本地环境，跑通 hello world。
   -- 用自己的产品界面跑通第一条 case。
   -- 调通第一个 suite，把 setup/teardown 调通。
   -- 配好 Jenkins pipeline，保证每天能跑起来。
   -- 分工，写 case。
   -- 保证每天都能有一个良性循环：早上回来看结果，修复失败用例，写新用例，晚上再跑新的 job。

只有循环开始了，用例数量不断增加和稳定通过，才能节省手工回归测试的工作量，解放人力。

是的，当时也是出了不少问题之后，测试才有了足够的发言权去推到很多流程的改进和得到开发的配合；而且小团队，落实下来也很快。

1. 我们每天都在测试环境跑完整的自动化，在线上环境跑冒烟用例的自动化，并且每天有对失败的用例进行维护，所以可靠性还是有保障的。 2.我们线上有对应的预警系统，捕捉到相关错误的时候会给团队成员发送邮件和短信进行报警。所以对于自动化用例覆盖不到的地方，也能比较及时地处理。

起码把大部分稳定模块的回归测试工作量通过自动化替代了
当然那是两年前小团队的模式，产品和环境依赖没那么大，现在的产品各种依赖太多了，自动化很难稳定下来

你这是屏蔽一个人，我是想屏蔽整个节点

感觉还是若干年前的🍉

getInteger() 和 getInteger() 两个方法都是 com.alibaba.fastjson.JSONObject 中的两个方法

看了半天也没看出这两个方法有什么不一样

先搭一个时光机去明天，拿到数据再回来吧