引入自动化，确定可以释放工作量么？

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

大部分稳定模块的回归测试工作量通过自动化替代

这一块，怎么让它不会腐烂呢？可能一直跑，都是通过的，但是线上还是会出问题。

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

听起来没问题，走起来问题还很多

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

能详细写下落地这一个么，这个感觉是大多数人遇到的瓶颈

落地这个话题太大了吧

我尝试简单说一下：

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

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

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

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

上次（2019 年）参加广州测试沙龙分享后最大的感触，就是大团队做的事情和我们小团队的很不一样

小团队做得好且愿意出来分享的真的很少。下半年广州计划再来一次沙龙，有兴趣来分享下么？

逐步替代了 80% 以上的手动测试 ---- 我绝对不相信

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

说实话，细节不够，很多地方疑问很大。举个例子，第一点，质量管理流程规范化，这个怎么做到的？仅仅是与领导充分沟通？问个实际一点问题：一个团队就 1 或者 2 个测试，主程来自某大厂（我就不点名黑了）。因为是大厂，说话权很大，但是程序对于质量管理流程不是很感冒，你如何做到推动 “开发代码管理规范”？你是测试还是开发？你如何在开发中有话语权？你进入公司前肯定已经有一套代码管理规范了，你如何推动新的代码管理规范？新旧规范又如何不同，旧规范是如何产生？太多了就不说了。哪天你去分享沙龙，能够不这么宽泛，那一定会给测试界带了不小影响的。

软技能：和开发老大搞好关系就可以推动吧，最理想的是开发团队都关系不错。
硬技能：自己有过硬的技术素质，能让开发信服。
不过具体落地的规则肯定也不只是测试一方的意见，应该是测试开发双方沟通之后形成共识的方案。

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

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

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

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

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

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

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

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

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

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

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

小团队 搞自动化，投入是多大啊

老哥，你这个理解其实不是很准确的。软技能不仅仅指测试和开发关系好，更重要的是产品和开发关系好。有很多时候测试和开发关系不好，是因为产品（策划）和开发有矛盾，战火烧到了测试这边。真正待过小团队的人才深有感悟（鄙人不才，做过大厂外包（偷学技术，偷学流程管理），也待过小团队，真的是从 0 到 1 的那种小团队）。所以光是测试和开发关系好，没什么卵用的。至于硬技能，过硬的技术永远没有上限，开发信服你和你技术过硬没有必然联系，最多就是有那么一丢丢影响。我做外包，有个服务端老哥和我关系特别好，甚至主动开车送我下班（顺路），但那个时候我刚毕业，没有所谓的过硬技术。这种事要看人的，我那个服务端老哥深知，他做的系统质量不止我，还有他都是要负责任的，所以他也很希望我能够测试好；而有些人则是认为，系统质量和开发无关，出事了都是优先丢锅给产品或者测试，这种心态的人永远都教不好的。这种思想才是真正决定开发愿不愿意去相信一个测试，去和测试合作共扶质量。当你真心认为你是团队一员的时候，你就会愿意去相信你的队友，去和他们共同成长。

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

说实话，我苦思冥想破局之法，如今苦战快 2 年，无不以失败告终。如今方明白，人之品德，重如泰山。在现在压力颇大的社会中，很多人的心早已变质了。只是唯恐我，哪一天也变成和他们一样。（我多说一句，我司有一人，上家公司开除过他，原因为嘴臭，此事是项目主管和我亲口所说。此人影响极大，因为该职位只他艺一人，其余众人皆与他矛盾，苦他久矣）

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

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

主程走了，另一个老哥暂时充当。我答应过这个老哥，陪他一起支撑一下团队。

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

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

看这个回归怎么定义，如果仅仅是系统的主流程，80% 还是很容易覆盖的，不管是 UI 的还是接口的，能够称之为核心的会有多少。

还以为是小团队管理经验

小团队，就是自己管自己

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