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

常常看到不少测试同仁讨论测试平台相关的一些话题,好比为何要作测试平台,测试平台的价值究竟是什么?怎么作测试平台?等等。这些问题说实话,仁者见仁,智者见智,没有最终的谁对谁错,全部观点都要代入到讨论者所在的实际工做场景中才能看出来它的合理性。今天我想跟你们探讨下在多行业多业务形态下公用测试平台构建中存在的一系列问题,也但愿可以引发普遍的讨论与思考。app

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

场景介绍完了,咱们进入正题。通常来讲,测试平台建设有两种模式。
第一种:经过专项技术孵化测试平台。你能够简单的理解成作测试产品,这种模式通常比较适合于单业务或者在某个专业领域技术作的很深的团队。它经过对某项技术的深度理解和使用经验的总结,沉淀成可复用的测试技术平台,具备必定的先进性和被论证的实践价值。像早期起来的不少移动app云测平台,其实就是一个典型的表明。若是你的业务有不少app产品,云测平台对你而言是一个很好的选择,由于相比不少公司而言,他们是专业的(这里不是作广告,平心而论,国内绝大多数软件公司,测试技术水平其实仍是比较差的,因此也要感谢阿里、百度、华为、testin等这些提供云测能力的厂商为行业赋能)。这种模式主要的问题有两个:
(1)泛技术要领先(技术、场景、方案、玩法,不只仅是技术),不然容易被颠覆,被取代。也就是你须要不断的去提高这个测试平台的竞争力,在公司里不是说它越先进越好,而是最起码在你的公司里面要起到引领的做用。不然你在作测试平台的时候就会面临这样的问题:为何要用你的而不是业界开源的?你的核心竞争力是什么?你能解决我什么问题?你的平台比我当前的测试方式更优的地方在哪里?对于单业务而言,其实这个问题并不突出,由于你须要知足的对象比较单一,你只要作到平台比当前的一些玩法略微先进就能够知足须要了,并且还能够经过强制使用等管理手段搞定(管理手段不是咱们推崇的,因此后面的全部观点里,我都尽量不提这个方式)。
(2)很难知足用户个性化的需求。跟作产品同样,在多业务都形态的背景下你的测试平台不可能作到面面俱到,你们提的需求五花八门。好比,在”多行业多形态“的场景下,咱们作一个移动云测平台,照顾到了绝大多数APP类的业务,可是一些智能终端的业务就不干啦,你得给咱们支持终端的接入,适配咱们的接入协议。不少时候也不是说不能去作这些个性化的需求,由于在作的过程当中咱们须要平衡资源、时间进度、质量效果、技术实力、平台产品版本控制等等一系列因素,咱们不得不作一些取舍。若是咱们不能知足这些个性化的需求,会致使什么结果呢?用户流失。在公司里,这一类用户流失,意味着你的平台就丢失了一块市场。到这里,你必定会问,那为何要在公司层面作测试平台呢,而不是进入到这些个性化的业务里去作知足他们须要的平台呢?这里涉及到的问题就是策略(测试平台分级建设)和资源的权衡,后面的文章里会详细探讨。测试

第二种模式:根据业务需求产生测试平台。你也能够简单的理解成作功能交付。这种模式比较广泛,也最直接,用户给我什么需求我就作什么。一样的,这种模式也有三个主要问题:
(1)需求不必定能经过当前技术实现。说实话这个问题要拆解来看,有多是平台建设者的平台技术水平没达到,另外一方面多是需求确实天马行空了。相比第一种模式,需求在这种模式里实际上是很难作到彻底控制的。好比说,一些用户参加了某些大会,看到某些公司的平台宣传材料就以为它很牛逼,就照葫芦画瓢提需求给你。这种模式下,为了规避实现上的风险,可能会增强需求的审核。可是若是你须要的是这样的强势客户,你怎么办呢?“个人需求你都知足不了,我为何要给你提需求?”,“这个需求若是你不作,我就不用”。那就偏向虎山行吧!既然决定要作了,你就得在实现需求的过程当中开始你漫长的技术调研。边实现边调研,实际上是很是危险的,一方面可能会致使功能交付周期过长客户失去信息,另外一方面调研成果有很大的不肯定性,刚调研完成就立马投入平台建设的技术也存在不稳定不可靠的风险,毕竟没有通过实践检验。
(2)需求能够知足,可是可能会出现不少定制化的项目或功能,平台建设团队精力可能会被这些大量的定制化消耗殆尽。
(3)业务每每是短视的,能解决当前问题就行,把平台规划的重任放到了平台建设者身上,对平台建设者提出了更高的要求。而在不少公司里,平台建设者实际是跟业务分离的,他只作平台建设,缺乏业务参与,少了一些对业务测试场景的理解,也就致使最终平台的规划存在不足甚至难产。所以,有一些公司意识到这种问题以后,开始把平台建设者放到业务里,跟业务测试人员捆在一块儿one team。版本控制

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

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

本文由博客一文多发平台 OpenWrite 发布!
相关文章
相关标签/搜索