灌水 如何向整个测试部推广自己二次封装的自动化测试框架

红客联盟 · 2018年12月28日 · 最后由 萝卜 回复于 2019年06月05日 · 553 次阅读

最近用 yaml+pytest+allure 封装了一个框架,个人和领导看起来不错。之前公司测试部在推 RF 二次封装做自动化,可能效果一般吧。所以领导想向整个测试部推广,得到其他自动化测试和手工测试的支持。想求教各位大佬应该从哪些方面来论述呢,有经验吗。感觉就几个方面吧,一是 yaml+pytest+allure 对比之前 RF 框架的优势在哪里。不足在哪里,如何弥补。二是手工如何参与进来,比如协助编写测试用例,而不是增加工作量。三是测试框架能覆盖多少级别的用例,怎样减少手工回归测试的辛苦(公司项目比较稳定,变化不大,但是业务很复杂,适合自动化)。各位来讨论一下,或者有没有资料对比 RF 和 pytest 的优点缺点,感激不尽

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 16 条回复 时间 点赞

感觉一点介绍不足以让其他人采用呀,除了这些对比介绍,还要你的详细使用说明,迁移方案,甚至培训讲解

先小范围试用下,看看哪个效率高吧

感觉不是怎么推广的问题,是领导有没有决心,如果仅仅是推广,没有制定计划进行普及,你就是炮灰, 还是有就是绩效的问题;使用你框架,产生的绩效算谁的,你的么 是我也我不会用; 测试行业看似很简单,其实也有水呢,如果工具还是一锅粥,无法系统的对其他人员的利益进行包容和包装,就先掂量一下,还有就是领导的决心到底有多大,畏畏缩缩的领导主持这件事情,你自己还要三思;

RF 建议放弃,虽然很多公司都用,比如中兴啊之类的,但是限制太多,debug 不方便,自动化要的就是快,编写快,修改快,pytest 明显写代码强过写关键字。RF 可能你数量少不觉得,等有超过 2000 条 case 的时候,就觉得 RF 是噩梦了

1、首先框架再怎么封装也没有平台化来的效果显著,多人协作脚本、数据、版本等等无法实时统一和规范,数据量大了还会显得很臃肿,导致后期维护成本极高。个人建议是平台化将所有脚本数据版本等统一管理和指定规范,数据脚本实时共享和脚本结果可视化,对于后期 ci/cd、集成、拓展都比较方便。
2、手工参与那就是上面的平台化,根据给定的规则进行用例编写。不管是任何框架或是平台,增加工作量是不可避免的,所以这个我就不做解释了。
3、一般自动化满足冒烟、回归、主要流程就可以了,需要更细化的流程或者异向流程那就看你们自身公司是否有这人力了。
4、如何推动,这个不是你能左右的,这个需要你的 leader 和 pm 来推动,需要把编写自动化脚本的时间计算在每个测试的身上。

说得对,重要的是领导的决心。

韩将 回复

具体说说呢,之前他们跑 ui 自动化一万条用例用 rf 似乎很痛苦,我想听听你的经历,更有说服力

三不走:内部自己玩溜了,别整的还热乎乎的就往外推,第二步:数据化展示你这套自动化架构价值,因为这个你们项目人力成本下降,发现了某些手工测试不容易发现 BUG,这一步就是 flag 立住了,第三步:就是发起培训,感兴趣参加培训,及推广部门需要指定对接人去学习使用,而不是一股脑的让全公司都认可,这样没人屌你。

孙高飞 回复

第一点 RF 也只是试点,而且做出来问题很多,可以说基本没用,老大也说只是个人做着玩玩,没有实际用在工程项目上
第二点推 RF 的人在一个部门,不过不在一个组,其他几个自动化测试都是新来的,他们明确支持我使用的框架,因为可定制度高
第三点老大和部门经理都比较支持我,推广出去的意思是让手工来一起联调,提意见,帮助转化自动化测试用例,毕竟贴近业务才是有用的。要让手工模块负责人放心这部分模块可以交给代码去做。
第四点我这个框架本来就是要做在与之前 RF 不同的全新的业务线上,而且协调其他自动化测试在这个业务线上统一用这个框架,老大说过的

红客联盟 回复

按这情况看来, 所有人都支持你推广新框架, 那还犹豫什么 ~直接搞起了

如果大家对 RF 并不是特别熟悉,我觉得 RF 的对比不大需要太突出。一个新框架本来就有学习成本,还多加一个对比,成本更高了。

建议突出自动化的好处(手工一起参与编写,写完后不用乏味地重复劳动),以及你的框架如何简单易用(如 xx 步写好一个自动化测试用例,套路一定要简单,容易听懂),让大家产生试用的冲动就达到目的了。

起步阶段,很多 pytest 的特性其实不大需要介绍,否则会让大家觉得复杂兴趣消退。只需要介绍起步阶段最常用的几个就好了。

另外:强烈建议先找个合适的团队(感兴趣、有技术底子)试点,丰富你的实际使用案例,再全面铺开,会顺利不少。

孙高飞 回复

主要是想请教如何将情怀落地,也就是真正做出有效果的工具让大家使用。而不是自嗨。最后做出的东西没有用,这个过程需要注意哪些地方,比如开发某个模块和经验丰富的手工多交流?每做一点有个评审?你们是怎么处理的呢·

陈恒捷 回复

嗯嗯,其实想继续问下如何做出一个让大家都觉得效果不错的框架呢,在开发之初就应该考虑的东西?而不是做完了发现很难用,而且准确率不高,效果差。目前想到的是写完一个模块要和手工联调,问问他们的意见

红客联盟 回复

如果是设计时就不想有太大偏差,建议是开发之前,就需要进入项目或者和项目人员深度交流,了解大家最需要什么,项目特点是什么。比如项目如果是流程较长,链路较长型的,单个接口如果没有准备好数据很难测试,那就需要能比较简单就可以把多个用例组装起来,达到可以符合流程自动化执行的目标,方便快速把数据造起来。

然后框架有个雏形后,就轮岗进入项目中,自己加上少数项目中对这个有兴趣的同学一起作为先锋把最需要自动化的几个用例用自己的框架实现并在项目中跑起来,然后再推广。这个时候你可以针对项目说出很多接地气的例子,大家也就更容易接受,不会自嗨。

你的想法也不错,写完一个模块就和手工联调,及时修正。如果可以,建议问下有没有一些手工对这个有兴趣,抽出 30%-50% 的时间陪你一起做,这样沟通更多,修正也更快。

韩将 回复

我认为这个东西和上层支持不支持相比,简直不值一提

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册