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