最近用 yaml+pytest+allure 封装了一个框架，个人和领导看起来不错。之前公司测试部在推 RF 二次封装做自动化，可能效果一般吧。所以领导想向整个测试部推广，得到其他自动化测试和手工测试的支持。想求教各位大佬应该从哪些方面来论述呢，有经验吗。感觉就几个方面吧，一是 yaml+pytest+allure 对比之前 RF 框架的优势在哪里。不足在哪里，如何弥补。二是手工如何参与进来，比如协助编写测试用例，而不是增加工作量。三是测试框架能覆盖多少级别的用例，怎样减少手工回归测试的辛苦（公司项目比较稳定，变化不大，但是业务很复杂，适合自动化）。各位来讨论一下，或者有没有资料对比 RF 和 pytest 的优点缺点，感激不尽
红客联盟
回复
如果是设计时就不想有太大偏差，建议是开发之前，就需要进入项目或者和项目人员深度交流，了解大家最需要什么，项目特点是什么。比如项目如果是流程较长，链路较长型的，单个接口如果没有准备好数据很难测试，那就需要能比较简单就可以把多个用例组装起来，达到可以符合流程自动化执行的目标，方便快速把数据造起来。
然后框架有个雏形后，就轮岗进入项目中，自己加上少数项目中对这个有兴趣的同学一起作为先锋把最需要自动化的几个用例用自己的框架实现并在项目中跑起来，然后再推广。这个时候你可以针对项目说出很多接地气的例子，大家也就更容易接受，不会自嗨。
你的想法也不错，写完一个模块就和手工联调，及时修正。如果可以，建议问下有没有一些手工对这个有兴趣，抽出 30%-50% 的时间陪你一起做，这样沟通更多，修正也更快。
陈恒捷
回复
嗯嗯，其实想继续问下如何做出一个让大家都觉得效果不错的框架呢，在开发之初就应该考虑的东西？而不是做完了发现很难用，而且准确率不高，效果差。目前想到的是写完一个模块要和手工联调，问问他们的意见
孙高飞
回复
主要是想请教如何将情怀落地，也就是真正做出有效果的工具让大家使用。而不是自嗨。最后做出的东西没有用，这个过程需要注意哪些地方，比如开发某个模块和经验丰富的手工多交流？每做一点有个评审？你们是怎么处理的呢·
如果大家对 RF 并不是特别熟悉，我觉得 RF 的对比不大需要太突出。一个新框架本来就有学习成本，还多加一个对比，成本更高了。
建议突出自动化的好处（手工一起参与编写，写完后不用乏味地重复劳动），以及你的框架如何简单易用（如 xx 步写好一个自动化测试用例，套路一定要简单，容易听懂），让大家产生试用的冲动就达到目的了。
起步阶段，很多 pytest 的特性其实不大需要介绍，否则会让大家觉得复杂兴趣消退。只需要介绍起步阶段最常用的几个就好了。
另外：强烈建议先找个合适的团队（感兴趣、有技术底子）试点，丰富你的实际使用案例，再全面铺开，会顺利不少。
孙高飞
回复
第一点 RF 也只是试点，而且做出来问题很多，可以说基本没用，老大也说只是个人做着玩玩，没有实际用在工程项目上
第二点推 RF 的人在一个部门，不过不在一个组，其他几个自动化测试都是新来的，他们明确支持我使用的框架，因为可定制度高
第三点老大和部门经理都比较支持我，推广出去的意思是让手工来一起联调，提意见，帮助转化自动化测试用例，毕竟贴近业务才是有用的。要让手工模块负责人放心这部分模块可以交给代码去做。
第四点我这个框架本来就是要做在与之前 RF 不同的全新的业务线上，而且协调其他自动化测试在这个业务线上统一用这个框架，老大说过的
这个主要看你现在所处的情况。我假设你现在的框架是比 RF 好很多的。那么你主要需要面对以下 4 点。
- 第一看你们已有的根据 RF 做的自动化已经积累了多大的规模了， 如果规模小，迁移成本小，那就还好说。 如果规模大就很难推，除非新的框架比旧的框架有很明显的颠覆式的优势，但即便这样也是要给他们专门排期去迁移，所以就很麻烦。 很多地方的技术陈旧，代码烂不是工程师水平低，而是历史原因了，不能随便动。
- 第二看人，之前做 RF 二次开发的那个人还在不在这里， 或者团队里还有没有其他技术骨干 (可以影响 boss 的想法的)，你的这个推广会不会撬动了他们的利益和地位，不是所有人都那么豁达的。
- 第三看老大是不是挺你， 你是否能说服老大力排众议，甚至不顾其他人的反对和不配合强行推下去。
- 第四看你能不能用新框架在一个业务线上做出明显比之前的框架好很多的成绩。一开始就全面推广是不大靠谱的， 一般都是先找个业务线试点， 这个就看你自己的功力了，能否在这个业务线上带着他们做出明显比之前好的成绩来。 这中间你可能面对其他人技术能力差，不会写代码，不配合，个人情绪等等， 当然也可能给你分一个特别给力的 team。 如果这阶段做不好，除非你是 boss 的小舅子。。否则基本就凉了。
以上是在你的框架比 RF 强很多的情况下你需要面对的。 当然了如果要我说，从长远来看写代码做自动化的效率肯定比 RF 强很多， 但从你的描述看，你们团队应该有不少人不会写代码吧。 所以之前才用 RF 来做就是为了迁就没有代码能力的同学。 那么问题就来了，在你们这个团队的人员水平下，你的框架还真不敢说就比 RF 更适合。 毕竟 RF 做关键字驱动已经很长时间了， 而且如果你们的业务就比较小，case 量较少，那用 RF 还是用新框架也无所谓的。 大炮威力再强再好，可是如果人家只想打个蚊子呢？
综上所述，其实我很少去硬推什么东西，硬推一个东西的成本和风险都太大了，收益也不一定高。如果团队已经有积累了，只要没什么大问题就让他们先用着。 主要精力还是留着去优化和开荒比较好，尽量慎重做颠覆性的决策。 当然你可以把新框架用在一个还没有自动化的业务线上，这样阻力会很小，他人的抵触情绪也比较低，也容易成功， 把它做成一个标杆项目，那么不用你推进，自然有人会来找你。
三不走：内部自己玩溜了，别整的还热乎乎的就往外推，第二步：数据化展示你这套自动化架构价值，因为这个你们项目人力成本下降，发现了某些手工测试不容易发现 BUG，这一步就是 flag 立住了，第三步：就是发起培训，感兴趣参加培训，及推广部门需要指定对接人去学习使用，而不是一股脑的让全公司都认可，这样没人屌你。
1、首先框架再怎么封装也没有平台化来的效果显著，多人协作脚本、数据、版本等等无法实时统一和规范，数据量大了还会显得很臃肿，导致后期维护成本极高。个人建议是平台化将所有脚本数据版本等统一管理和指定规范，数据脚本实时共享和脚本结果可视化，对于后期 ci/cd、集成、拓展都比较方便。
2、手工参与那就是上面的平台化，根据给定的规则进行用例编写。不管是任何框架或是平台，增加工作量是不可避免的，所以这个我就不做解释了。
3、一般自动化满足冒烟、回归、主要流程就可以了，需要更细化的流程或者异向流程那就看你们自身公司是否有这人力了。
4、如何推动，这个不是你能左右的，这个需要你的 leader 和 pm 来推动，需要把编写自动化脚本的时间计算在每个测试的身上。
RF 建议放弃，虽然很多公司都用，比如中兴啊之类的，但是限制太多，debug 不方便，自动化要的就是快，编写快，修改快，pytest 明显写代码强过写关键字。RF 可能你数量少不觉得，等有超过 2000 条 case 的时候，就觉得 RF 是噩梦了
感觉不是怎么推广的问题，是领导有没有决心，如果仅仅是推广，没有制定计划进行普及，你就是炮灰， 还是有就是绩效的问题；使用你框架，产生的绩效算谁的，你的么 是我也我不会用； 测试行业看似很简单，其实也有水呢，如果工具还是一锅粥，无法系统的对其他人员的利益进行包容和包装，就先掂量一下，还有就是领导的决心到底有多大，畏畏缩缩的领导主持这件事情，你自己还要三思；
先小范围试用下，看看哪个效率高吧
感觉一点介绍不足以让其他人采用呀，除了这些对比介绍，还要你的详细使用说明，迁移方案，甚至培训讲解