小道消息 听猫哥聊聊测试工具和平台(上篇)

兔子🐰 for 一起听播客 · 2022年06月17日 · 1772 次阅读

本期嘉宾:江湖人称猫哥,在 TesterHome 论坛著有专栏《测试求道之路》,是 2022 MTSC 大会技术委员会成员。擅长质量工具设计与开发,在前沿领域有多处落地经验。

先上两个小链接,总有一个你喜欢😼

一、为什么需要测试工具和平台?

测试行业发展了很多年,但是并没有非常有亮点的东西,而且一直存在一个非常严重的断层。比如:游戏行业很早就在做压测,然而互联网行业兴起后,大家纷纷转投互联网的怀抱,游戏压测的很多经验都没有被沉淀下来。做测试工具和测试平台,一方面可以降本提效,另一方面更是围绕公司体系形成知识沉淀。

对于测试工具和平台,个人建议先从工具做起,逐渐形成更加完善的功能并且得到公司内部更多认可后,再逐步推进做成平台。当然,如果你已经有丰富的开发工具的经验,并且已有经验和现在的需求匹配度很高,也可以一步到位做平台。

二、不断涌现的新工具和平台,是不是重复发明轮子?

重复造轮子的嫌疑可能有,但是很多情况下,是由于已有工具/平台没有满足需求。

就开源工具/平台来说,很多不是可以直接拿来用,没有做到大而全(提供基础方法)而是把东西限制的比较死。导致要么开源会跟不上工具/平台升级的速度,要么无法完全匹配需求,就只好做自研。

另一方面,开发新工具/平台也是对代码能力的历练。从这一点来说,哪怕有重复造轮子的嫌疑也不完全是坏事。

三、创业公司需要什么样的测试平台,需要实现什么样的功能?

首先要看创业公司里的人员配置,如果在人员配置上仅仅只能做功能测试,但是想要尝试做测试工具/平台,建议先从合适的开源方案入手。
我们的工作首先是满足项目组的交付要求,在这个基础上,对于有意愿或者能力开发工具/平台的同学,建议先做框架,在框架层面再做平台。
进一步,对于平台的前后端开发,在人力不足的情况下,要看组里同学擅长什么,不强求一定要包揽前后端开发。但确实,从推广和给老板看这两个点出发,前端很重要也很有价值。
从优先级上说,个人建议 UI 自动化工具/平台,放在接口和压测之后。

四、如何评判测试工具/平台的 “好坏”?

测试工具/平台也是一个产品,与其它产品一样,它的好与不好也是看能否满足用户需求。

有些工具/平台在技术和概念上比较超前,用户(测试/开发人员)可能不理解,进而不会去使用。但是不能直接说这样的工具/平台就是不好的。这种情况下,就需要工具/平台的开发方给用户 “培训”,让用户了解这个工具/平台,愿意使用。

更推荐的方式是,在开发平台前,先得了解对方的认知。特别是公司里一般不会有专门的推广团队,运营和推广测试工具/平台。在进入开发前,比如做一份调查问卷,先收集对方需要什么再去开发;比自己先开发,再销售给对方的效果好很多。

在测试工具/平台的需求收集方面,我们也遇到过问题:
测试工具/平台的使用者算是甲方,工具/平台的测试开发同学算乙方。有时候甲方提了很模糊的需求,比如 “一句话需求”,但是乙方测开同学没有进一步了解需求,直接接下来进行开发。导致需求返工或者迟迟不能交付,这种情况其实应该由 “乙方” 测开同学自己负责。

在走过弯路后,我们进行了反思和总结,约定了测试工具/平台的开发流程:需求要尽量清晰,明确工具的使用方、验收者,给出工具的价值和定位;并且把各方人员拉到同一个群里,即保证沟通便利直接,也方便让使用方长期了解工具/平台如何使用。

五、开发测试工具和平台有没有对应文档?

有文档,我们的文档分为三个阶段:
第一个阶段是基础的需求概述。用来说明谁提的需求,想实现什么作用,使用方是谁以及需求范围。

第二阶段是详细设计文档。在需求概述文档确认后,圈定了需求范围,投入开发前会编写详细的设计文档。如果工具/平台是分多期上线,那么就按上线排期,先编写第一期的设计文档。详细设计文档里会包含的内容,例如展示什么、技术栈是什么、数据库的建表是什么,以及开发时间等。

在功能发布前,我们会主动联系使用方/验收,同步发布时间和发布的内容等信息。

第三阶段是 Read Me/ Wiki 文档。用来帮助对方更好地使用工具/平台,或者已经发布的功能。同时也会有反馈收集机制,收集对方在使用过程中遇到的问题。

六、测试开发同学是 one man one team:集产品、开发和测试于一身?

之前我跟一位朋友也聊到过类似的问题,他当时在一家 AI 公司,他觉得公司里每一位测试开发同学都得懂 AI。我并不完全赞同这种看法,在一个团队中,是可以有分工的。

对于测试工具/平台的开发团队来说,最好的情况是,一个团队中有三块分工:

一是有非常懂业务的人。怎么懂业务呢?就是说懂测试业务,懂程序的业务,知道使用方要什么。

二是有懂推广的人。比如善于沟通,别人愿意把问题告诉他,他也乐于做推广的工作。这样的团队成员,在日常开发工作的基础上可以兼职做推广。

三是愿意追求技术的人。这一点也是非常重要的,避免了有些想法没人能实现,或者实现了也做不到让人眼前一亮,就很揪心。

我们团队目前基本做到了这样的分工,但不是一步到位就有了这么齐全的人员配置,也是一步一步做出让老板觉得有价值的东西后,才形成现在的团队规模。

七、测试工具/平台的增效和后期维护

在运维方面我们也走过弯路。2020 年的时候,我们一步到位做了一个多租户的中台概念的平台,包括自建 K8s;一旦有了自建 K8s,等同于整套的发布和运维都是我们自己来。后来公司包安全漏洞报到我们的平台(中台)上,这个时候我们的自建 K8s 已经使用了半年多,但是无奈只能往运维平台迁移。

所以我建议大家做平台的时候,最好跟运维部门商量好,把平台的运维工作交给他们,或者帮忙承担一部分运维的职责。这样我们可以专注于开发,而不是什么活都放在自己团队这里,实际上人力可能不够。

另一方面,关于维护周期。我们不可能一开始就把一个工具设计的非常好,而是需要分成不同的阶段来做。每做完一个阶段,我们再收集一下反馈和意见,看看有什么需要改动的地方。一步一步地完善一个工具/平台的功能。

八、 “头疼” 需求 VS“真爱 “需求

我原来的想法是,要做口碑,就什么需求都接。

遇到过比较坑的情况有两种:
一种是开发的工具/平台,一半功能在自己这边,一半在另外一个组。这种情况向下,一旦功能出现问题,很容易陷入无尽的扯皮中。
另一种情况是,对方提的需求跟自己的本职部门没关系。举个例子,假设我们所在的是自动化部分,但是对方提了一个工具/平台的需求,跟自动化没关系,并且他们的需求不通用。就是纯粹帮他们定制化了一个工具,对自己的绩效也没有什么好处。

最好的 “真爱” 需求是,对方需要的东西刚好也跟自己的 OKR 匹配。帮对方开发工具/平台,也是帮自己实现 OKR 的目标,双赢。

九、如何衡量测试工具/平台的收益?

一个工具/平台,如果能够实现批量处理或者解决重复劳动的问题,它的价值就会比较高。例如,游戏或者其它软件产品,设计了一个概率性的功能,比方说抽奖抽中的概率。在测试的时候,不可能真的去抽成千上万次进行验证。这个时候,如果能用测试工具实现就很有价值。

另一方面,在软件开发生命周期的不同阶段,所需要的工具/平台可能是不一样的。如果你的工具/平台能在最被需要的阶段提供服务,也会更有价值。例如:对于 UI 自动化,在快速交付的时候,用来跑遍冒烟,比上线前巡检会更有价值;对于压测,一般是上线前就要压一次,不会等上线了再考虑做压测。

针对上文所述,关于工具/平台的价值,一定要整理出对应的定性表格:区分这个工具/平台在什么阶段更有价值——我们自己公司已经在实施。

还有一类工具,是在日常工作中都可以用到,不限于项目开发的某个阶段。能帮助测试同学增加测试覆盖率以及稍微减轻工作时间。比方说挂钩检查或者指定对应目录对文件进行监控,在开发每次提交后,这个工具能把每次的变更项推给对应的测试。再比如自动化造测试账号,手工造一个测试账号可能要三分钟,自动化一分钟就能造 50 个账号,特别是需要海量测试账号时这个测试工具就很有意义。

十、测试工具一般怎么做推广?

就我个人经验来说,测试工具的推广方式也跟团队构成有关。如果是配置了产品岗位的测试开发团队,是由产品同学负责推广。

如果团队中没有产品岗,是测试开发同学 “兼职” 做推广,更多地是通过跟使用方(QA)达成共识、在 “聊天” 中推广工具。有的测试开发同学是跟使用方(QA)坐在一起的,这种情况下就更容易了解和应答他们的需求,也更容易在日常工作中推广工具/平台。有时候测试开发同学跟项目组是分开的,那就要利用周会等活动加强沟通。

测试开发说到底是服务提供方,要想走得更远更好,跟项目组维系好关系还是非常重要的。
在测试工具/平台的推广方面,我们也做过专门的推广活动,比如宣讲会。但实际效果并不好,大家也不太愿意在会上提问发言,反而不如日常工作中聊天。

推广测试工具/平台是为了让潜在使用方知道、进而使用,有时候对方不愿意用自己的工具/平台可能是出于 KPI 压力、也有类似的开发计划。如果是这种情况,可以好好跟对方商量,进行共建、共同分享成果。哪怕在绩效上对方多占一些,共建是双赢,能让大家共同成长。

十一、如果投入和产出严重不成正比,是坚持做工具和平台,还是砍掉平台去做功能测试?

对于这种情况,我个人不赞成完全砍掉和放弃平台。哪怕现在开发工具/平台的人之前就是做功能测试的,在工具/平台交付不顺利的情况下,可以先考虑 “降级”:比如不做平台了,做框架,或者换个方向来开发。但是一旦完全砍掉,就意味着原来的沉淀都没了,假设将来又想做就是再次从零开始。

十二、什么方向的测试工具/平台属于 “新手友好型”?

在方向上,因为业内整体对接口、压测、UI 自动化工具/平台的意识非常高,所以申报立项时更容易通过,算是好的切入点。

但是,如果完全没有测试工具/平台的开发经验,建议先从写代码调用已有工具/平台开始,在调用的基础上也可以按需进行二次开发。在积累了一定经验,对工具/平台有了足够的了解后,再真正动手开发。


看到这里,给你点个赞,希望你又 get 了有用的新知识。《听猫哥聊测试工具和平台》未完待续,敬请期待 “下篇”。

本篇对应的完整音频分享,我们下期再会:https://m.ximalaya.com/sound/543259389

把眼睛留给路上风景,把耳朵留给小道消息播客

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