本期嘉宾：江湖人称猫哥，在 TesterHome 论坛著有专栏《测试求道之路》，是 2022 MTSC 大会技术委员会成员。擅长质量工具设计与开发，在前沿领域有多处落地经验。
先上两个小链接，总有一个你喜欢
测试行业发展了很多年，但是并没有非常有亮点的东西，而且一直存在一个非常严重的断层。比如：游戏行业很早就在做压测，然而互联网行业兴起后，大家纷纷转投互联网的怀抱，游戏压测的很多经验都没有被沉淀下来。做测试工具和测试平台，一方面可以降本提效，另一方面更是围绕公司体系形成知识沉淀。
对于测试工具和平台，个人建议先从工具做起，逐渐形成更加完善的功能并且得到公司内部更多认可后，再逐步推进做成平台。当然，如果你已经有丰富的开发工具的经验，并且已有经验和现在的需求匹配度很高，也可以一步到位做平台。
重复造轮子的嫌疑可能有，但是很多情况下，是由于已有工具/平台没有满足需求。
就开源工具/平台来说，很多不是可以直接拿来用，没有做到大而全（提供基础方法）而是把东西限制的比较死。导致要么开源会跟不上工具/平台升级的速度，要么无法完全匹配需求，就只好做自研。
另一方面，开发新工具/平台也是对代码能力的历练。从这一点来说，哪怕有重复造轮子的嫌疑也不完全是坏事。
首先要看创业公司里的人员配置，如果在人员配置上仅仅只能做功能测试，但是想要尝试做测试工具/平台，建议先从合适的开源方案入手。
我们的工作首先是满足项目组的交付要求，在这个基础上，对于有意愿或者能力开发工具/平台的同学，建议先做框架，在框架层面再做平台。
进一步，对于平台的前后端开发，在人力不足的情况下，要看组里同学擅长什么，不强求一定要包揽前后端开发。但确实，从推广和给老板看这两个点出发，前端很重要也很有价值。
从优先级上说，个人建议 UI 自动化工具/平台，放在接口和压测之后。
测试工具/平台也是一个产品，与其它产品一样，它的好与不好也是看能否满足用户需求。
有些工具/平台在技术和概念上比较超前，用户（测试/开发人员）可能不理解，进而不会去使用。但是不能直接说这样的工具/平台就是不好的。这种情况下，就需要工具/平台的开发方给用户 “培训”，让用户了解这个工具/平台，愿意使用。
更推荐的方式是，在开发平台前，先得了解对方的认知。特别是公司里一般不会有专门的推广团队，运营和推广测试工具/平台。在进入开发前，比如做一份调查问卷，先收集对方需要什么再去开发；比自己先开发，再销售给对方的效果好很多。
在测试工具/平台的需求收集方面，我们也遇到过问题：
测试工具/平台的使用者算是甲方，工具/平台的测试开发同学算乙方。有时候甲方提了很模糊的需求，比如 “一句话需求”，但是乙方测开同学没有进一步了解需求，直接接下来进行开发。导致需求返工或者迟迟不能交付，这种情况其实应该由 “乙方” 测开同学自己负责。
在走过弯路后，我们进行了反思和总结，约定了测试工具/平台的开发流程：需求要尽量清晰，明确工具的使用方、验收者，给出工具的价值和定位；并且把各方人员拉到同一个群里，即保证沟通便利直接，也方便让使用方长期了解工具/平台如何使用。
有文档，我们的文档分为三个阶段：
第一个阶段是基础的需求概述。用来说明谁提的需求，想实现什么作用，使用方是谁以及需求范围。
第二阶段是详细设计文档。在需求概述文档确认后，圈定了需求范围，投入开发前会编写详细的设计文档。如果工具/平台是分多期上线，那么就按上线排期，先编写第一期的设计文档。详细设计文档里会包含的内容，例如展示什么、技术栈是什么、数据库的建表是什么，以及开发时间等。
在功能发布前，我们会主动联系使用方/验收，同步发布时间和发布的内容等信息。
第三阶段是 Read Me/ Wiki 文档。用来帮助对方更好地使用工具/平台，或者已经发布的功能。同时也会有反馈收集机制，收集对方在使用过程中遇到的问题。
之前我跟一位朋友也聊到过类似的问题，他当时在一家 AI 公司，他觉得公司里每一位测试开发同学都得懂 AI。我并不完全赞同这种看法，在一个团队中，是可以有分工的。
对于测试工具/平台的开发团队来说，最好的情况是，一个团队中有三块分工：
一是有非常懂业务的人。怎么懂业务呢？就是说懂测试业务，懂程序的业务，知道使用方要什么。
二是有懂推广的人。比如善于沟通，别人愿意把问题告诉他，他也乐于做推广的工作。这样的团队成员，在日常开发工作的基础上可以兼职做推广。
三是愿意追求技术的人。这一点也是非常重要的，避免了有些想法没人能实现，或者实现了也做不到让人眼前一亮，就很揪心。
我们团队目前基本做到了这样的分工，但不是一步到位就有了这么齐全的人员配置，也是一步一步做出让老板觉得有价值的东西后，才形成现在的团队规模。
在运维方面我们也走过弯路。2020 年的时候，我们一步到位做了一个多租户的中台概念的平台，包括自建 K8s；一旦有了自建 K8s，等同于整套的发布和运维都是我们自己来。后来公司包安全漏洞报到我们的平台（中台）上，这个时候我们的自建 K8s 已经使用了半年多，但是无奈只能往运维平台迁移。
所以我建议大家做平台的时候，最好跟运维部门商量好，把平台的运维工作交给他们，或者帮忙承担一部分运维的职责。这样我们可以专注于开发，而不是什么活都放在自己团队这里，实际上人力可能不够。
另一方面，关于维护周期。我们不可能一开始就把一个工具设计的非常好，而是需要分成不同的阶段来做。每做完一个阶段，我们再收集一下反馈和意见，看看有什么需要改动的地方。一步一步地完善一个工具/平台的功能。
我原来的想法是，要做口碑，就什么需求都接。
遇到过比较坑的情况有两种：
一种是开发的工具/平台，一半功能在自己这边，一半在另外一个组。这种情况向下，一旦功能出现问题，很容易陷入无尽的扯皮中。
另一种情况是，对方提的需求跟自己的本职部门没关系。举个例子，假设我们所在的是自动化部分，但是对方提了一个工具/平台的需求，跟自动化没关系，并且他们的需求不通用。就是纯粹帮他们定制化了一个工具，对自己的绩效也没有什么好处。
最好的 “真爱” 需求是，对方需要的东西刚好也跟自己的 OKR 匹配。帮对方开发工具/平台，也是帮自己实现 OKR 的目标，双赢。
一个工具/平台，如果能够实现批量处理或者解决重复劳动的问题，它的价值就会比较高。例如，游戏或者其它软件产品，设计了一个概率性的功能，比方说抽奖抽中的概率。在测试的时候，不可能真的去抽成千上万次进行验证。这个时候，如果能用测试工具实现就很有价值。
另一方面，在软件开发生命周期的不同阶段，所需要的工具/平台可能是不一样的。如果你的工具/平台能在最被需要的阶段提供服务，也会更有价值。例如：对于 UI 自动化，在快速交付的时候，用来跑遍冒烟，比上线前巡检会更有价值；对于压测，一般是上线前就要压一次，不会等上线了再考虑做压测。
针对上文所述，关于工具/平台的价值，一定要整理出对应的定性表格：区分这个工具/平台在什么阶段更有价值——我们自己公司已经在实施。
还有一类工具，是在日常工作中都可以用到，不限于项目开发的某个阶段。能帮助测试同学增加测试覆盖率以及稍微减轻工作时间。比方说挂钩检查或者指定对应目录对文件进行监控，在开发每次提交后，这个工具能把每次的变更项推给对应的测试。再比如自动化造测试账号，手工造一个测试账号可能要三分钟，自动化一分钟就能造 50 个账号，特别是需要海量测试账号时这个测试工具就很有意义。
就我个人经验来说，测试工具的推广方式也跟团队构成有关。如果是配置了产品岗位的测试开发团队，是由产品同学负责推广。
如果团队中没有产品岗，是测试开发同学 “兼职” 做推广，更多地是通过跟使用方（QA）达成共识、在 “聊天” 中推广工具。有的测试开发同学是跟使用方（QA）坐在一起的，这种情况下就更容易了解和应答他们的需求，也更容易在日常工作中推广工具/平台。有时候测试开发同学跟项目组是分开的，那就要利用周会等活动加强沟通。
测试开发说到底是服务提供方，要想走得更远更好，跟项目组维系好关系还是非常重要的。
在测试工具/平台的推广方面，我们也做过专门的推广活动，比如宣讲会。但实际效果并不好，大家也不太愿意在会上提问发言，反而不如日常工作中聊天。
推广测试工具/平台是为了让潜在使用方知道、进而使用，有时候对方不愿意用自己的工具/平台可能是出于 KPI 压力、也有类似的开发计划。如果是这种情况，可以好好跟对方商量，进行共建、共同分享成果。哪怕在绩效上对方多占一些，共建是双赢，能让大家共同成长。
对于这种情况，我个人不赞成完全砍掉和放弃平台。哪怕现在开发工具/平台的人之前就是做功能测试的，在工具/平台交付不顺利的情况下，可以先考虑 “降级”：比如不做平台了，做框架，或者换个方向来开发。但是一旦完全砍掉，就意味着原来的沉淀都没了，假设将来又想做就是再次从零开始。
在方向上，因为业内整体对接口、压测、UI 自动化工具/平台的意识非常高，所以申报立项时更容易通过，算是好的切入点。
但是，如果完全没有测试工具/平台的开发经验，建议先从写代码调用已有工具/平台开始，在调用的基础上也可以按需进行二次开发。在积累了一定经验，对工具/平台有了足够的了解后，再真正动手开发。
看到这里，给你点个赞，希望你又 get 了有用的新知识。《听猫哥聊测试工具和平台》未完待续，敬请期待 “下篇”。
本篇对应的完整音频分享，我们下期再会：https://m.ximalaya.com/sound/543259389
