漫谈测试平台—建设模式探讨

以下文章来源于爱测未来 ，作者爱测未来

经常看到很多测试同仁讨论测试平台相关的一些话题，比如为什么要做测试平台，测试平台的价值到底是什么？怎么做测试平台？等等。这些问题说实话，仁者见仁，智者见智，没有最终的谁对谁错，所有观点都要代入到讨论者所在的实际工作场景中才能看出来它的合理性。今天我想跟大家探讨下在多行业多业务形态下公用测试平台构建中存在的一系列问题，也希望能够引起广泛的讨论与思考。

首先讲下场景，什么是”多行业多形态“。多行业指的是你的公司可能会涉及很多行业方面软件的开发，比如同时涉及政务、教育，同时涉及医疗、汽车等。多形态指的是，在你的公司的某个行业方向里，软件产品有很多种形态，有软件、有平台、有硬件等等。一般来说，一个公司规模变大了，其业务基本都会不断延伸，产品形态也会随着行业发展和行业需要不断变化。比如某公司教育行业的产品有app，也有平台，也有教学一体机，它的汽车行业产品有SDK、app、ROM、车机整机等等。那么"多行业多形态"给测试平台建设带来的挑战是什么呢？我这里先不说，大家先思考，后面的文章里我们再探讨。

场景介绍完了，我们进入正题。一般来说，测试平台建设有两种模式。

第一种：通过专项技术孵化测试平台。你可以简单的理解成做测试产品，这种模式一般比较适合于单业务或者在某个专业领域技术做的很深的团队。它通过对某项技术的深度理解和使用经验的总结，沉淀成可复用的测试技术平台，具有一定的先进性和被论证的实践价值。像早期起来的很多移动app云测平台，其实就是一个典型的代表。如果你的业务有很多app产品，云测平台对你而言是一个很好的选择，因为相比很多公司而言，他们是专业的（这里不是做广告，平心而论，国内绝大多数软件公司，测试技术水平其实还是比较差的，所以也要感谢阿里、百度、华为、testin等这些提供云测能力的厂商为行业赋能）。这种模式主要的问题有两个：

（1）泛技术要领先（技术、场景、方案、玩法，不仅仅是技术），否则容易被颠覆，被取代。也就是你需要不断的去提升这个测试平台的竞争力，在公司里不是说它越先进越好，而是最起码在你的公司里面要起到引领的作用。否则你在做测试平台的时候就会面临这样的问题：为什么要用你的而不是业界开源的？你的核心竞争力是什么？你能解决我什么问题？你的平台比我当前的测试方式更优的地方在哪里？对于单业务而言，其实这个问题并不突出，因为你需要满足的对象比较单一，你只要做到平台比当前的一些玩法略微先进就可以满足需要了，而且还可以通过强制使用等管理手段搞定（管理手段不是我们推崇的，所以后面的所有观点里，我都尽可能不提这个方式）。

（2）很难满足用户个性化的需求。跟做产品一样，在多业务都形态的背景下你的测试平台不可能做到面面俱到，大家提的需求五花八门。比如，在”多行业多形态“的场景下，我们做一个移动云测平台，照顾到了绝大多数APP类的业务，但是一些智能终端的业务就不干啦，你得给我们支持终端的接入，适配我们的接入协议。很多时候也不是说不能去做这些个性化的需求，因为在做的过程中我们需要平衡资源、时间进度、质量效果、技术实力、平台产品版本控制等等一系列因素，我们不得不做一些取舍。如果我们不能满足这些个性化的需求，会导致什么结果呢？用户流失。在公司里，这一类用户流失，意味着你的平台就丢失了一块市场。到这里，你一定会问，那为什么要在公司层面做测试平台呢，而不是进入到这些个性化的业务里去做满足他们需要的平台呢？这里涉及到的问题就是策略（测试平台分级建设）和资源的权衡，后面的文章里会详细探讨。

第二种模式：根据业务需求产生测试平台。你也可以简单的理解成做功能交付。这种模式比较普遍，也最直接，用户给我什么需求我就做什么。同样的，这种模式也有三个主要问题：

（1）需求不一定能通过当前技术实现。说实话这个问题要拆解来看，有可能是平台建设者的平台技术水平没达到，另一方面可能是需求确实天马行空了。相比第一种模式，需求在这种模式里其实是很难做到完全控制的。比如说，一些用户参加了某些大会，看到某些公司的平台宣传材料就觉得它很牛逼，就照葫芦画瓢提需求给你。这种模式下，为了规避实现上的风险，可能会加强需求的审核。但是如果你需要的是这样的强势客户，你怎么办呢？“我的需求你都满足不了，我为什么要给你提需求？”，“这个需求如果你不做，我就不用”。那就偏向虎山行吧！既然决定要做了，你就得在实现需求的过程中开始你漫长的技术调研。边实现边调研，其实是非常危险的，一方面可能会导致功能交付周期过长客户失去信息，另一方面调研成果有很大的不确定性，刚调研完成就立马投入平台建设的技术也存在不稳定不可靠的风险，毕竟没有经过实践检验。

（2）需求可以满足，但是可能会出现很多定制化的项目或功能，平台建设团队精力可能会被这些大量的定制化消耗殆尽。

（3）业务往往是短视的，能解决当前问题就行，把平台规划的重任放到了平台建设者身上，对平台建设者提出了更高的要求。而在很多公司里，平台建设者实际是跟业务分离的，他只做平台建设，缺少业务参与，少了一些对业务测试场景的理解，也就导致最终平台的规划存在不足甚至难产。因此，有一些公司意识到这种问题之后，开始把平台建设者放到业务里，跟业务测试人员捆在一起one team。

其实我们在这里讨论测试平台建设的时候，很多问题其实也同样可以放到产品研发、项目研发的角度，大家可以尝试体会一下。那么最后，”多行业多形态“场景下，测试平台应该选择哪种模式进行建设呢？亦或者是不是有更好的模式呢？有哪些问题需要我们解决呢？感兴趣的同学可以留言、回复、私信，各抒己见。下一篇我们展开讨论。

做测试平台其实不容易，它不是一个直接产出价值的东西，它更多的是一种辅助工具，很多企业其实对测试平台的认知并不深，在建设上一味的强调价值量化，往往忽略了它最本质的东西：赋能，最终导致在测试平台的投入上不足同时轻视了平台建设的复杂度。在这种情况下，往往需要我们权衡很多东西，寻找适合各自企业测试平台建设的模式。