陈晔：测试平台化是趋势，但不应强求

2016年12月21日晚8点半，Gettalk创始人、《大话移动 App 测试》系列丛书作者陈晔带来了主题为“移动无线应用基础平台从0到1建设怎么做”的Chat交流。以下是主持人小冰对交流精彩片段的记录。

问：我目前是在一个创业型的公司，已经开始搭建起一套测试平台，包括自动化测试（web app 接口 压测 都已经可以支持）, 测试工具， 测试管理；目前在平台硬件和软件上正在处于0->1的搭建和完善过程中；不过相比较这些技术问题的困扰，人员的问题也很头疼；比如，我老板对这个平台的支持一般，虽然他不反对我做这个事情，但感觉他的态度就是有也行 没有也行，反正没有平台也不影响眼前的业务测试工作；同事们对这个东西的热情也一般，技术上他们愿意学习，但是实际要做事情的时候，需要花时间 花精力 额外加班来做的时候 一个个的又会往后退缩；希望谈谈在测试平台0->1建设过程中，对于人员（包括老板和同事）的0->1的建设的经验？

答：这是一个好问题，同时这个问题并不是那么好回答，因为涉及到了太多的上下文和客观因素影响。我就简单分三种不同的场景来说，大家看的时候有别的问题也欢迎随时提哈。

在蚂蚁的时候，老板并不是什么都赞同的，也有一种不温不火的情况。当然，我们先排除这个老板本身就不行的情况。一般来讲老板也有自己的想法，我现在越来越感觉到了位置不同，看到的东西不同，角度也不同。往往老板可能自己是有自己所谓的重要，紧急的事情，我觉得我们可以尝试沟通下。就比如说我们这样一个平台，的确需要硬件，也需要软件，更需要人员上的支持。我们这个时候可以尝试着列举平台里的多个方案给老板，比如说我们有方案A，达到什么效果，B达到什么效果，C达到什么效果。分别需要什么资源，怎么落地等。让他去做选择，如果都觉得可有可无，那么我们也完全可以接受这些方案都不做，但老板需要指明一条方向道路。

然后人员的话，在阿里其实很简单。kpi一共三部分，人员技术能力提升，业务质量和团队协作。我个人觉得还是很正确的，首先所有花精力，加班要做的事情一定要和kpi挂钩，也就是说和人员的利益挂钩，其次平台还是一步一步来，结合自己团队人员的能力来。就好比，如果暂时达不到，那么就先第一阶段大家学习代码，做一些提升自己手上工作的脚本。第二阶段再写些完整的自动化用例，第三阶段再看看能不能做一个完整的平台or应用。毕竟开发一个平台所用的技术栈真心还是很多的。不容易。

第二种情况我曾经在创业公司的时候，基本上做的时候就是把我文章中所有的那些细节的东西和提升用户体验的东西全部去掉。比如只有简单的jenkins轮询打包，简单的扫描（不配置规则），正向的尽可能多的api自动化测试用例（没有数据驱动和suite，也没有太多逆向的用例），等等。创业公司的老板的确很重要，我个人的经验老板不阻碍测试去落地一些东西其实已经很不错了。所以在创业公司，我觉得主要的点并不在于能建立一个平台，0到1是让开发和测试都感觉到jenkins，api测试，打包等是对自己，开发，项目有帮助的。毕竟大部分工程师还是关注自己手上的东西，本来都是996的状态，效率能提升，方便大家是第一位的。

第三种情况然后是互联网金融行业，金融行业老板和下面的同学其实在新技术的更新上以及互联网思想上与真正的互联网公司还是有一定差距的。老板的话，最好就是必要的时候就是需要支持下，比如告诉大家，大家是需要技术提升的，而不是维持现状，这种测试推不动，需要老板出面。其他时候尽可能的让下属放手去做就好了。从同事们来讲，其实这个过程中我强烈的感受到一定需要提升他们的便捷度。比如说jenkins，他们用不来，那么我就做一个很好的理解的前端web给他们用，后端调用jenkins的rest的接口。其实说实话，很多人会觉得多此一举，但要推动事情，那么平台必须那么做。比如打包下载，那么至少比以前自己下载，自己安装来的快捷，他们才会去用。我们作为整体平台的架构师，可能我们有自己的远大愿望，远大的目标，也知道我们应该做哪些东西，但企业的大部分人毕竟用的只是部分功能，他们更不会关心你的远大计划。所以第一要素还是提升效率，如果他们觉得没有太大的帮助，那么就不会来使用你的平台，哪怕你用的是最最先进的技术。

最后我补充一下这就好像昨天还有人问我，面对现在那么多技术栈的测试行业，应该学什么，怎么样才能够学到既有深度也有广度。我说其实说白了，靠自己的努力，可能可以学深某个技术的。但你要精通，甚至同时要求广度的话，那么一定是需要有很好的项目，一个接着一个去磨炼的，在项目中成长是最快的。平台也是这个道理。其实平台的底层使用到的技术就好像我们自己学习一门技术，大家都可以做到。但真正会平台化，最终是否一定会走向这样一个目标，是要看项目需要，看整体公司需要，看大家提出的需求的，也就是所谓的相辅相成。恩，其实说实话，我们每个人都有自己的规划，谁不想平台做的漂亮，做的高大上一点。但毕竟现实没有那么美好。就好像我们加入一家公司可能不是最好的时机，那可能只能等到下一次时机。但在过程中，我们尽可能的营造适合下一个时机到来的环境和氛围。强求的话基本上是反效果了。

问：文章写得不错，不过看完之后，感觉这种强大的平台对于中小型创业公司来说还是比较难以实施的，那有没有其他途径或者方案可以提高中小型公司的工程效率呢？

答：谢谢，编写文章用了我洪荒之力了。创业公司的确是比较难实施的，所以就如第一个问题那样，我建议的是创业公司要做到的就是，麻雀虽小，五脏俱全的状态。项目管理上我们可以使用redmine，teambition这样的敏捷性的软件，实际效果还是很不错的。

另外就是文档，文档一定是需要去写的，任何的开发模块，代码规范等都需要落文档，创业公司尤其重要的就是后端的接口文档。就因为公司小，更需要去写。同时类似站会的沟通交流机制也需要有。接着从工程流程上来讲，持续集成Jenkins一定是需要搭建的，需要定制好构建的策略。从自动化角度来讲，性价比最高的就是静态扫描和接口自动化，尽可能的做全，做细，做便捷。然后才是UI自动化等。接着就是线上的埋点，数据监控要做好，创业公司在这方面有独特的优势，那就是快，大家好沟通。

用户使用什么功能多，crash率多少，界面打开时间多少等等，这些做起来都会比大公司快好多好多。前端展现我推荐用百度的echarts，很好用。后端数据可以使用阿里的odps，数据清洗就直接mysql。

我觉得小公司有小公司的优势，在平台搭建的这件事情上面，大公司要做，小公司更要做。我曾经在上海去过一家公司交流，叫Glow。我去见过他们测试搭建的平台（当时就一个测试）。那个监控平台简直让我佩服的五体投地。小公司的要点在于放弃高大上的表面，去追求有效率的本质。

问：自动化测试人力不住怎么办，如只有2个人却要完成整个自动化平台+脚本？

答：这个问题其实我觉得就有两个关键点，第一个关键点在于，平台组只做平台，不能负责脚本。我现在搭建的平台，所有的脚本都是在在线化的，让业务方去补充。平台组绝对不能鱼与熊掌兼得。

所以一定是业务方来补充脚本，但平台组需要提供快捷的补充方式。比如说我现在提供的在线编辑case，远程执行等等。包括引入BDD，数据驱动等 。

第二个关键点就在于人本身的技能。我现在所在的地方，服务的话已经快5个业务线了。整个平台搭建，我文章里提到的都完成了。平台核心开发人员就3个。我觉得2个人不是问题，但技术上要过硬，否则就很难适应现在这样一个快速发展的社会，迭代快速的项目里，其实要的就是果断，知道要做什么，而不是一直犹豫选什么框架，人不行就换，再不行就跳槽，不要被一些可以改变的事情所阻碍：）

问：请问TDD测试自动化对于小公司来说有没有必要，我指的投入产出比高不高？

答：TDD其实主要关键在于这个T，这个T本身其实指的就是UT。那么其实所谓的ROI高不高就要看这个UT做的好不好，团队配合好不好。必要性来讲的话，我去过好多创业公司，其实没有绝对的。合适的团队做合适的事情。我见过有TDD做的很好的，但大部分可能是一个UT都没有的。从本质来讲，UT是很必要的，你看投入产出高不高的话，还是要看你们的开发是不是愿意去做，是不是懂得配合。

问：自动化系统部署在测试环境，在新的大版本提测初期，是否有比较好的可行方案，减少自动化系统在时间和规模上的维护投入？

答：这个问题我觉得还是蛮复杂的，因为在我了解下来并没有非常好的解决方案。首先测试环境下我们需要一个稳定的测试数据库的支撑，也就是说一个固定的测试环境，这个环境上有很多测试账号，测试数据供我们使用。环境需要准备多套。然后我不是很清楚提问者这里所在的领域是什么，在移动互联网现在的情况其实有两种方式。

第一种就是基本上只维护核心的case，并不在迭代中去补充新的功能作为自动化用例了第二种方式其实也有很多公司尝试，其中也分成两部分。第一部分叫做遍历，也就是说不根据一个功能一个功能的去实现，使用算法的方式去遍历所有的新功能，达到一个测试效果。

第二部分就是所谓的自动生成。比如说case，大家这几年也都尝试过在做MBT，也就是模型生成测试用例。

这是一种方式。还有比如说api的测试，比如swagger就可以自动的根据文档生成api test case。也有很多是接口做了一层监控，在平时调用的时候就会自动的录制req、res等信息，从而可以在自动化的时候回放。这些都是可以减少自动化系统维护投入的手段。

问：需要依赖关联方提供数据以运行完整流程的测试，如何提高效率？目前做了一些仿真接口，但精度和效率都无法满意。

答：这个其实你做的已经很好了。很多企业，团队都是需要依赖3rd的东西。唯一的方式其实也就是mock了。如果还不能满意的话，我建议就是看看能不能更深入的去做些事情。我这里只能举些例子了。比如说，文档上能不能更仔细。比如说，我们mock他们，我们能不能同时为了更好的对接，帮助他们mock我们。比如说，他们可能有多套环境，我们能不能在他们的环境下去mock，达到更好的一些效果等等。其实效率这个东西，要提高都在细节里面。沟通顺畅，接口，功能上的定义，数据结构，类型都清楚了，环境也都保持一致了，那么mock自然就得心应手，效率提高了。（这个上下文一般都很复杂，我只能笼统的说了，希望能有帮助。）

问：jenkins有没有较为完整的资料分享一下，网上多是构建项目的，构建测试的比较少？

答：这个问题的话，首先是没有。然后其次的话，jenkins测试相关的东西。我有个建议，就是说一个一个去解决。首先就是看google，还有国外的一些技术人的blog，这些很关键。然后你就是一个一个有目的性的去搜索和看。东西还是很多的。但要说整体的话。完整的还是jenkins的官网，基本上我这边平台的改造，包括对外public的rest接口，都是通过官网的。

问：我有个问题，关于移动专项测试的。现在感觉到有移动专项测试的需求了，但是我们团队小，而且每个人移动测试经验不多，如何能找到一个合适的切入点开始移动专项测试工作呢？

答：合适的切入点，第一位还是看你们的产需求是什么吧，就是从需求入手。我举个例子来讲，比如当初钱包第一位的就是启动慢，网络流量消耗大。那么我们都不懂，那么就从启动慢和网络入手。启动的话，涉及到了软件启动，硬件的渲染。我们就开始研究方案，比如说埋点，adb，比如说高速摄像机，比如说看systrace看掉帧率等。然后网络的话，我们就尝试了ATC这类热点的解决方案，也尝试了charles这种proxy的方式，尝试了用真的运营商的卡去测试不同的网络。所以我建议切入点就是从你们的具体需求，痛点入手。不要多，一个一个来。一个一个沉淀，积累。一般一个专项的积累起步就是半年。

问：测试平台化是否是一种趋势，与传统过程中做的自动化测试或者测试方案有什么本质的区别？为什么大部分公司会选择去平台化。

答：测试平台化肯定是一个趋势。其实这和移动互联网本身的状态是有关系的。比如说以前我们尽可能的做好UI自动化，API自动化，单元测试，性能压测，冒烟，回归等等。做好这些已经不容易了，但在移动互联网现在很多产品迭代快的前提下，这些其实已经不满足需求，或者说其实达不到“保证质量”这样一个目的。

平台化本身除了包括我们之前说的这些xx测试以外，也会对于公司内很多特殊的需求做定制化的工具。举个例子，公司产品每个包都针对不同的服务网关，同时push推送也针对不同的环境，那么我们就需要快速的切换环境的功能，同时切换之后为了方便测试，我们也会需要一个方便的api mock平台。那么这些需求都会合入测试平台中。同时平台还有一个功能，那就是评估质量。我们可以想想，现在有公司自己的app发布出去之后，有多少的测试，开发，项目经理能够一句话说出自己这次迭代的产品质量到底怎么样的，很少很少。我们如果连评估质量的能力都没有，那么更不要提什么保证质量了。我们建立了质量大盘，建立了定时的代码覆盖率文件的上传，有了线上的接口巡检机制等等。这些都是让我们有能力去评估线上产品质量的手段。所以其实平台化既是给予我们整个项目团队提升效率的渠道，也同时能够让我们能够去快速的应对突如其来的故障，同时也能够评估我们的质量。这也是现在所说的测试到质量转变很大的一个进步点。

（以上内容转自GitChat，版权归GitChat所有，转载请联系GitChat，微信号：GitChat，原文： 《陈晔：测试平台化是趋势，但不应强求》）

本文转载自异步社区。

原文链接：https://www.epubit.com/articleDetails?id=NC7E3EF936E60000153D5FB201D6017C8