测试效能平台最佳实践 | 解决用户痛点，比堆叠功能更重要！

测试效能平台开发的难点是什么？

关于测试效能平台开发，从技术上提供指导的文章网上比比皆是，但从 0 到 1 全面阐述测试平台开发实战经验的文章就相对较少。

而且，即使对于不那么擅于写代码的测试同学而言，在平台开发过程中，技术其实也没什么难点。

最难的点在于你要利用最少的资源，在最快的时间内，选择最合适的实现方案来解决团队中特定的问题。

本文就记录分享一下我在公司国际化商城项目中，作为智能物料项目 PO，从零搭建一个快速创建测试物料的工具平台的一些心得和经验。该项目在四个月中，迭代了 5 个版本，服务了近 200 多个用户，帮助团队快速创建了两千多个物料，粗略估计相当于节省了一个员工一年多的工时。

以下是项目经验总结，抛砖引玉，期待与大家一起探讨。

一、为什么要做这个测试平台？

国际化商城的物料创建（如商品、优惠券、促销和下单等），一直是项目中多个角色最头疼的事情。部分站点是找业务创建，部分站点是找负责相应模块的测试同学创建。无论哪种方式，这一来二去的沟通成本是极其高昂的。最极端情况下，物料准备的时间能占到整个测试时间的三分之一到四分之一。所以解决测试物料创建的问题，可以突破商城相关测试人力占用瓶颈。

二、从 0 到 1 构建平台

项目 BRD

在接到这个任务的时候，是没有任何详细的需求，只有一个问题场景。所以要根据这个问题场景，梳理出平台最核心的价值是什么，要解决什么样的问题。从而延伸出需要解决的问题涉及的范围是多大。我根据自己的理解编写了 BRD，这个 BRD 包括以下内容：

1. 功能列表和描述 颗粒度可以很粗，这是对平台初期的一个定位。在开始没有demo出来之前，一定不要规划大而全的东西。实现出来的功能，一定是大家可能都会用到的功能，比如我们第一期做的就是通过选择模板创建测试商品，因为一切的物料都是以商品为基础。
2. 项目计划及排期 整个平台规划做多久，第一期做什么，做多久，用到的人力是多少。大概示意是这样的：

这个项目除了我从头至尾是全职投入，其他同事都或多或少有其他的事。所以一份包含人力投入的项目计划极为关键，这是向领导申请人力支援的凭证。如果有同事做到一半，业务缠身去做别的事情，领导一看这期要实现什么功能，几号就要上线，缺口了多少人力，一目了然。在还没开始之前，不知道具体的功能会遇到什么阻碍，具体需要多少人力投入，估个大概就行，实际在项目开发中，再动态调整。

1. 产品原型 作为内部的工具平台，不会有多少设计和产品资源支持。而且产品也不太了解你要做一个什么样的东西，你的流程你的期望你的诉求，产品都没你清楚。自己要思路清晰，理出个框架，如果条件允许，可以找产品同事帮你画出大家日常工作中熟悉的产品原型，当然你自己也可以照猫画虎的画出来，只要方便其他参与者更好理解和协作就行。至于功能细节及详细的交互，在今后可以自己慢慢填充和完善。这时开始就不需要产品再次介入了。
2. UI 设计 这是一个看脸的时代，好看的界面会叫人愿意多停留几秒，挽留下来的这几秒，会帮你争取到宝贵的注意力。也许他这个激活用户就看到了他感兴趣的东西了。得不到业务需求那样的设计资源，让设计同学帮你出一套页面样式规范还是可以争取到的。做前端页面时尽量遵照这套样式规范做，不会丑到哪里。看的人觉得赏心悦目，自然也愿意多用。
3. 需求 首先你要清晰且明确的知道你们的平台工具它的核心价值是什么？它要解决的核心问题是什么？围绕这两个问题，产品形态就会有个大概的轮廓，基于这个轮廓自己就可以往里填充功能了。

一个人或几个人的角度毕竟有限，可以找以后的用户做一下需求收集，听听他们的痛点和诉求。获取到这些东西后一定要做过滤。从用户侧收集到的需求是有噪音的， 他们会根据自己的立场和角度，可能给你一个小众需求，只能解决少数几个用户的问题。这时 要回过头来审视之前那两个问题：核心价值是什么？解决的核心问题是什么？

举个例子：商城中商品的创建会涉及到非常非常多的字段，有普通属性、销售属性、品牌、类目、运费模板等等。那在做商品物料创建的时候，是不是要给用户塞很多输入框或下拉框，这样不就可以满足很多不同场景的测试需求了。NO!商品的创建界面，我们只给用户一个下拉框选择平台定义好的最常用的几个商品模板，两个输入框一个输价格一个输入库存，就没有了，简单易用，完全是傻瓜式创建。

为什么这么做？多数人对于商品这些琳琅满目的繁杂字段是不敏感的，他们也不清楚那些到底有啥含义。给他那么多输入项，反而造成了困扰，不知道如何入手。**他们的诉求很简单，就是要一个某个类型测试商品，能用就行。**我们挑选一些最最常用的几种类型的商品（不同字段的组合），通过模板事先定义好，供用户选择。对于商品某些字段有高要求的用户，他们本身已经明白这些字段的含义，完全可以在运营端自己去操作。即使满足了多字段选择的需求，他们后面也有可能不用。因为你再全也没有运营端全。

这么做有两个好处：

• 大降低使用者的上手成本；
• 实现起来也比较简单，不用处理太多的逻辑判断，节省宝贵的开发时间；
• 减法艺术 做平台工具也是做产品。做产品就要做减法。可有可无的功能能不做就不做，交互和功能都要从减少用户上手成本出发。比如摄影中画面元素越少，越能凸显主题，让观者一下抓住画面的核心。

工具平台的价值是提升工作和生产效率，如果用户使用工具还要看很长的文档，研究半天，我个人觉得它已经失败一半了。有时候我们思维惯性，想把能呈现的功能能满足的需求，都尽可能的交付给用户，没有考虑用户能消化多少真正用多少。

要将用户的使用场景代入进来，帮他恰到好处的解决了平台能帮他解决的问题，没有多余的操作、选择、输入。断舍离很难，但很重要。

三、跨团队协作

做工具平台免不了其他团队的支持和协助，比如物料平台需要涉及多个研发团队和部门，有的甚至是跨地域的部门。在此特别感谢一下在平台建设过程中曾经帮助过我们的同事们。在他们百忙的工作中，抽空帮忙处理和解决与他们业务以及绩效毫无相关的事情。

后来接触的部门和人多了以后，也逐渐有了一点点自己寻求帮助的方式和心得。

1. 表明来意 在寻求不认识的同事协助的时候，要清晰明确言语简洁的表达清楚目的和意图。
2. 找到利益共同点 比如我们搭建了物料平台后，对于某些模块的研发同事来说。测试同事可以挤出更多的时间，好好测试他们的开发的需求，同时物料平台解决了因测试物料创建不当而引发的事故，就再没有人找他们紧急处理事故了。最后他们自己在调试功能时，再不需要找测试同学帮忙创建物料了。
3. 风险规避，解除戒心 物料平台会调很多模块的接口，轻者入参错误触发报警，重者接口暴露使用不当会有一定事故风险。本来是想着帮你，但一不小心，给自己添了麻烦。这就要我们事先帮他解除顾虑。我会事先和他们讲出我想到的风险，并告诉我的风险规避方案。比如我在调接口的时候先捞线上的 log 模拟入参，再在测试环境调接口，调没问题了，再切预发或线上。又比如我在调商品创建的接口时，硬编码写死某个商品的属性，来和线上正式商品做隔离，避免用户使用不当或误操作引发的事故。
4. 名单感谢 平台上线后，在开发者人员名单中，一一感谢曾经帮助和提供协助的同事们，这本来就供内部使用的平台，名单再长也无碍。虽然他们不一定会看，有一天一旦在这个名单中搜索到自己的名字时，看到你如此珍视他们哪怕一点点的付出，也是让人心悦的。

四. 做平台，作为测试，需要做哪些技术准备?

我的答案是，用什么学什么。

我个人以前只写过 Python 自动化脚本，测 iOS 客户端时学过一些 OC 和 Swift。物料平台的后台技术栈选择的是 Spring，当时对于 Java 怎么使用，Spring 具体怎么用，完全是懵的。在架构师帮我们设计好架构后，买了一本 Spring 的书结合网上的教学视频，学了依赖注入和切片就 clone 了一个公司内的 Spring 项目。

看里面的结构，启动一个项目必备的配置文件有啥。一个简单的 HTTP 请求从 contorller 到数据库，需要经过哪几层，分别做哪些处理。刚开始是十分痛苦的，都是陌生的概念和名词，在写通一两个接口后，后面虽然还是有很多不会，但知道在 Google 和百度上通过哪些关键字搜索了。后因前端开发资源紧缺，又利用之前的套路，快速上手了 Vue.js，通过先解 bug 学习 Vue.js 的使用，再逐渐熟悉就可以慢慢的开发功能了。

技术的革新很快，行业变革的也很快。不论研发还是测试，我们所面对的是日新月异的测试框架、技术和工具。在这个快速变化的行业里，掌握一招吃一辈子的情况越来越少见了。有了扎实的基础技术储备，比如熟练掌握一门编程语言，知道计算机和网络传输的原理，程序的几种常见设计模式等等，就能快速掌握和驾驭新框架、技术和工具。上层东西是不断变化的，向下走，他们底层原理都是大同小异，就像建筑造型无论怎么改变，他都是需要有地基和承重的。

以上，希望这些对于大家在测试平台的搭建上有一些思路上的帮助。