活动背景
移动互联网时代，移动应用的数量进入了爆炸式增长阶段。为了提升提升用户体验、推动用户增长，高频次的产品迭代越来越常见，高效率高质量的测试方法承担起了为移动应用在产品迭代和用户体验保驾护航的重任。

本场分享，我们邀请 Testin、极光、谐云科技、Shopee 等企业的资深大咖，为大家带来测试方面的分享，分享他们如何进行高效测试，帮助产品自我完善与进化，希望能给大家带来能多的思考。

主持人：给大家介绍一下极光，因为有些小伙伴可能以前参加过我们的极光开发者沙龙，有些可能是第一次来。极光最开始是做开发者服务的，有很多同学可能知道我们极光，最开始是做极光推送。从2011年开始到现在7年时间我们也累积服务有34.4万的开发者，有88.7万的APP使用了我们极光的开发者服务，我们极光开发者服务现在已经从极光推送也扩展到极光IM统计、分享、短信等等五大开发者服务，希望今天来的小伙伴记住我们极光，今后有需要的时候来使用我们的极光产品。

刚刚我们有放一个极光7周年的宣传片，这是我们在这七年中使用我们极光一小部分的开发者给我们拍的小视频，我们也希望现在或者以前使用极光开发者服务的小伙伴，现场有兴趣的可以跟我们联系，我们也欢迎更多的小伙伴为我们拍摄小视频，加入到这个小视频当中去，可能下一次就能在其他的极光开发者沙龙上面看到自己的影子出现在里面，而且我们也会有很多的小礼品来赠送。

今天沙龙的主题就是高效测试赋能产品迭代，我们邀请到极光、云测、谐云以及Shopee四位大咖为我们分享怎么样通过高效率高质量的测试方法来为移动应用的产品迭代和用户体验保驾护航。

第一个分享的嘉宾就是来自于云测自动化专家邹世海老师，他拥有15年的互联网IT经验，先后服务过华为、中兴BAT巨头，他分享的题目是从0到1打造自动化测试。

邹世海：大家下午好，我是来自云测的邹世海，今天人很多的，大家冒雨过来参加这个会议，我今天从0到1打造自动化的话题，从互联网发展到这个产品的迭代，要提高我们的效率，保证质量跟大家做分享。

今天我分享的内容有两方面：
第一，看看自动化的发展。
第二，聊一下移动端UI自动化。

这个图片有点意思，是我们现在都拥有的小汽车来说明这个产品的迭代。可能每一位开发者和测试者都有一个理想的想法，就像超跑一样，我们把轮子做得非常漂亮做得性能非常好， 底盘做得非常好，所有的部件都做得非常专业，非常好了，我们才把它组装成一台跑车，这样就万事大吉，也没有太多的后顾之忧了。

但是实际上我们现实的产品迭代往往可能没有那么理想，我们可能是时间紧，产品要快速地上线，开始一个跑车有一个轮子、方向盘，还可以载一个人，就推出产品了，随着我们发布以后用户的需求不断叠加；可能最开始是有一个可以跑快一点，轮子慢一点，可能是自行车；最后是我装一个发动机，然后就是摩托车，后面发展成我们理想的状态，可能都经历了相当多的变化，经过了无数次的迭代才出现现实的产品。中间我们的开发人员，我们的测试人员可能都在努力倾情奋斗，写代码、测试，可能他们24小时没停过，为了改一个版本的上线。基于此是不是我们现实的产品迭代，有没有好的办法把我们所有的测试人员、测试内容，产品设立的人员给他们的时间能够空一块出来，陪陪女朋友，出去玩一玩。我们希望出一套自动化的测试，让测试人员的测试时间缩短了，同时我们开发人员的时间是不是也相应地缩短了。版本的迭代时间就可以按照我们计划时间来。

接下来聊一下我们希望的自动化具体内容：
自动化我们希望能够覆盖，我们应用可能有PC端、桌面、移动端等等的上层端对端。我们希望覆盖PC端、移动端，甚至不同系统之间的接口的自动化，可能一直以来都有性能，也希望能提升进去，能够实现测试任务管理的系统，实现所有的测试设备、测试的工具管理，我们能够在整个自动化测试的过程中，透明地去实时看我们测试的过程。比如说测试过程中用得比较多，我们是不是可以让它可以分布到不同测试的终端设备上，还有就是测试完以后，测试结果的回收等等。这是我们所希望达到的一套比较庞大的自动化测试的系统。

看一下这些系统大致有什么样类型的自动化情况：
代码怎么样自动化？首先是开发人员进行代码的测试，当然也有测试人员，可能做一些比较深层次的白盒测试，这里面会给我们安全代码扫描纳到代码测试的自动化。往上走是接口测试，主要是在进行系统里面后端系统的接口之间的通讯请求，一些响应以及逻辑这一块的验证，这一块的验证我们可能做一次就可以解决我们从用户层面返回回来的十个甚至更多的问题，经过我们的接口测试可以解决。

现在我们产品希望看到的就是UI自动化，主要是端对端，包括PC端、桌面以及移动端包括IOS、安卓的，我们是以用户的角度去验证验收，让我们所有的业务系统，看我们的APP是不是正常的，功能完备，业务逻辑是OK的。

看一下各种类型的自动化优缺点：
首先是代码测试，这是收益是最高的，当然随之而来是技术难度也是最大的，对自动化的测试者要求要懂底层的语言。如果你想引入第三方的时候，第三方是很难介入的，而且成本也非常高。

接口测试这一块，投入产出比也比较高，可能我对一个接口测出一个接口的问题以后，其实就解决我上层从UI层、用户层很多反馈回来的一系列问题，它的收益是非常高的，但是接口测试不能解决UI层面的问题，比如说UI的不适配等等。

从用户的角度就是UI的测试，UI测试感觉是可以看得到，不管是开发、测试还是产品人员不懂技术与用户看得到的测试。这边比较麻烦是什么？它的平台要适配不同的手机终端，所以它的成本，这个平台的要求非常高，开源还不能完全覆盖所有的终端设备。要想真正地覆盖更全面，更多的机型终端和系统版本，可能需要商业软件优化平台。同时用例也是投入成本比较高，UI自动化如果说逻辑有稍微的变动，我们的脚本就要做一些调整，维护成本非常高。同时UI自动化能够发现的问题，也不像代码测试和接口测试能发现比较底层比较直接的问题。这是他们各自的优缺点。

我们再看一下现在较流行的接口自动化和UI自动化的应用场景。接口自动化在我们开发阶段，开发人员在做单元测试或者做接口这一块都可以做一些测试，我们系统开发完了，每个单元开发完之后，在进行总集成SIG的时候也是可以我们的接口自动化，做我们接口的问题回归，同时可以做到一些敏捷系统的持续集成。

UI自动化主要集中在SIT、UAT、版本上线之前的状态情况下的测试，主要也是功能的回归，能够做到敏捷系统里面进行集成。UI自动化可能对我们业务系统，就是对我们的APP这边，相对来讲可能需要比较稳定的状态，投入产出比收益会非常高。

我们要做自动化都需要真正样的长期准备？三个方面：
第一，我们选择什么样的平台。现在安卓测试这一块有很多的开源工具，这些测试框架会解决部分的问题，但是往往我们在使用的过程中，因为开源并不是商业的产品，所以用起来会有很多的问题，它的覆盖面也没有那么广。我们可以选择比较成熟的商业工具。

第二，环境支持。我们要做自动化，包括是不是有独立或者共享的比较稳定的测试环境？还有测试数据的管理这一块，测试数据在做自动化的时候，我们要随时随地要准备匹配性的数据。我们环境支持这一块还需要我要提升我的测试效率，我的执行CASE、脚本是不是能够并发的能力，执行的管理。

第三，要做自动化除了工具和环境以外，还需要多方的配合，就是流程优化，需要产品、开发、测试、运维的人员参与进来，在什么阶段，怎么样准备这些数据，怎么样准备环境。

接下来给大家分享三个自动化以及敏捷这一块的一些案例：
首先是持续集成，在座今天有自动化开发的朋友吗？有一位，应该对这一块有研究；除了整个集成的过程，是把我们开发者，开发者向Github提交代码，然后通过我的WEBHOOK然后上构建我们的Docker，把测试通过的代码推向Docker，这样的过程能够把我们的整个流程；达到一定通过率直接可以上传我们的应用市场。

这是模型测试（MBT），这也是这几年的概念，之前火过，但是现在可能没有那么热衷了。当时我们一直在构想MBT的专家，我们自动化测试准备我们脚本的时候，会投入很多的精力，是不是说能够通过测试模型，比较了解我们的业务流程，比较了解底层的数据，自动设计出我的模型，自动地生成测试的用例、脚本。如果能够自动实现，自动化的效率是非常高的，但是实际上并非如此，MBT对于业务的逻辑，对编制的逻辑人要求是非常高的，之前我们也参与过，当我们在设计这个逻辑的时候，稍微有偏差，我们输出的用例以及后续的脚本就会有一些自动化处理不了或者跑偏的情况。这一块并不是像我们设想的一样去发展，而且基于这个模型的自动化，其实它的投入产出比是非常低的，人员要求又非常高。

现在比较流行的，也是为了解决自动化脚本投入比较大，投入产出比比较低的情况，我们公司投入了非常多的人员和精力研究深度学习，AI这一块。像行业里面一般都是说，首先是对移动端的基础控件识别，我们能掌握能够控制住，能够识别到所有的移动端UI上面的控件。最终能够做两个页面甚至所有页面的链接，最终到适应组合我们的业务分类，推动到行业，针对不同的行业可能同业类APP有很多的共性地方，通过这些AI，通过深度学习，能把我们每个行业的测试用例以及脚本通过机器人学习的方式自动地生成，这样来提升我们脚本用例准备的时间，降低我们的时间。

前面大概给大家分享一下我们现在自动化的具体版本迭代需求，以及自动化到现在为止发展的方向以及互联网、移动互联网不断地发展，手机的适配、UI自动化的情况。

接下来看一下我们公司做的移动端UI自动化：
这是我们Testin Pro云测做的一套移动端基于UI自动化大致的展示图。首先这个平台会把无数多的手机通过自动化的平台把它管理起来，我们的手机放在屏蔽机柜里面，就像一直以来IDC的服务器存储，让它们在稳定环境，包括温度、湿度还有WIFI信号隔离的情况下，稳定的环境里面去做UI自动化的Testin脚本。一方面对手机终端的管理和分布，另外就是自动化流程基于无脚本零门槛无语言的录制方式，现在能够做到基本上百分之九十多页面的元素识别，包括我们控件、图片、中间过程中的数据异常等等的识别，最终能够覆盖到页面原数，所有的复杂业务场景能够串起来，最终把我们的问题给找出来，定位出来。

这套系统并不是孤立的，我们提供丰富的API的接口，可以和现有的一些TKS或者敏捷的系统直接打通，实现敏捷的开发。这套系统主要是能够实现为了安全性、独立性和保密性这一块，我们可以做私有化，放在客户的机房里面自己使用，安全级别非常高。

看一下我们的业务架构，通过我们这一套自动化的私有云的平台，能够覆盖到UI自动化包括功能型测试，如果我们的手机有足够的机型还可以做手机的适配，兼容性的测试。还有比如说某一些页面的跳转的响应速度以及整个系统在运行自动化跑APP运行的时候，它的一些CPU、内存等等相关的数据都可以抓出来。同时还可以实现APP的稳定测试，这个稳定测试不仅仅是像安卓Monkey的稳定性测试，我们可以让它的反复运行我们固定一条逻辑的反复运行，来看我们这个业务系统在这个过程中，是不是存在一些问题，评估这个系统是不是有一些稳定方面的问题。中间还会把我们手机管理起来，其实一直以来每个企业都有很多的测试手机，开发、测试如果手机没有通过集中管理，没有一个智能的管理的话，有可能这个手机，每次要用的时候，把时间全部浪费在手机找的过程中。有了这个以后，可以通过每个人只要有帐号，不管开发还是测试，只要有帐号，远程访问过去，就和我们USB连到我们手机一样，通过我们的开发环境直接连过去可以做底层的开发和测试，以及问题的回归等等。

上面还有我们的版本管理、项目管理；下面是相关的模块，接下来说一下这个平台，业务架构有三种不同的角色，下面是超级管理员，主要是在维护整个平台的一些底层硬件，包括主机服务器、存储，以及所有使用后端的调用问题，还有手机的上下线。旁边是业务的管理人员，这边可以根据具体的公司情况建不同的项目组，生成不同的使用人员以及不同的项目组使用不同的设备等等。

另外是普通使用者的入口，就是在某一个测试人员可以到这边使用自动化测试、做脚本，执行批量的脚本测试任务，来看我们的UI自动化测试以后的结果，帮助开发定位问题，快速地解决问题。

这一套可能大家会觉得有点奇怪，怎么会有两个呢？这套是属于私有化部署的，有的企业可能说我没有地方放这些东西，放主机设备，我希望买云服务的方式使用我们的自动化服务。我们现在也是很灵活地支持，可以把我们的后端服务以及手机放在Testin云测的机房，可以分为两部分：一是跑自动化任务，二是跑远程做调试的。但是有些企业还是希望看的到手机具体运行的情况， 这个时候我们可以把客户专有的手机设备放在一个独立的机柜，放在客户指定的办公室或者机房，这样的话领导就不会说，你们买了一个自动化服务什么都负责，这是TestinPro自动化。这是我们专有云。

接下来看一下整体的自动化的网络图谱，中间比较大的是屏蔽机柜，里面放了很多的手机，连接到安卓的控制机，连接到苹果的控制机，录制好的脚本上传以后，把脚本推送过去，通过安卓或者苹果的控制器能读的APP或者一些命令然后执行，执行完以后把所有执行过程中的UI，我们还可以指定整个过程跑的脚本的步项，可以取回到后端进行所有过程、测试过程出现问题的定位，分析，最终形成一个报告，使用者就可以直接登录我们的平台，查看报告。我可以定时定量地去跑我自动化的测试。

还有的开发桌面有两台手机，我们可以通过网络的方式引到办公桌面把我们的手机自动化控制起来，可以随时地上线。通过这一套自动化的平台，基本上我们的合作客户可以做到白天进行开发，晚上下班就出包，我们自动化平台可以定时，比如说晚上21：00把之前准备好的两千台用例脚本自动化地跑，差不多凌晨的时候，跑出来的结果就出来了，平台会以短信、微信的方式通知到相关的人员。如果通过率达到我们的要求，比如说100%，我们可以安安心心地睡觉，如果没有达到测试通过率的话，可以准备想想它哪里有问题，第二天继续干。这样的话可以做到整个开发测试每日一构件的状态，效率是非常高的，而且我们的开发人员、测试人员基本都不用通宵达旦地去盯着。

这里罗列了一些TestinPro自动化平台的特点，首先拥有这一套平台的话，我们的自动化测试工程师要求门槛就特别低了，零门槛，所有都是自然语言，会用触屏就会用脚本，所有的脚本都是通过记录式的方式，把小脚本串联成大脚本，这样的方式降低脚本的开发时间，非常容易用。我们平台上如果，开发人员自动化测试的工程师写脚本的，一旦流失的话，再重新找一个没有基础的工程师也很容易，基本上一到两天就可以进入我们的状态，不会因为我们用的自动化平台，对测试工程师要求比较高，一般人很难去使用，我们这个平台来讲，对人员要求会比较低。

另外是脚本案例，其实更多情况是说，我们这个平台怎么样去匹配市面上众多的平台，硬件手机厂商以及系统的不断更新的适应。作为商业化，我们云测基本上在一个礼拜到半个月之间就会把新手机接过来能够控制，这边基本上能支持到全对象的控制，中间会包含OCR的获取，包括验证码，里面会有文字，或者有字母都会自动化地进行获取。还有中断机制还有脚本的打包，这是当前的版本需要我们去录制脚本，我们现在有一个AI的团队正在加快脚步研发深度学习的脚本开发机器人自动学习的平台，自动化录制的平台，应该不久的将来就会跟大家见面。这样的话，后续脚本录制这一块基本上不需要我们测试工程师过度地操心，基本上自动化就可以出来测试的用例和脚本。

这是测试数据，现在我们做到第四代的自动化测试的状态，能够实现逻辑和数据的分离，比如说登录这一块，如果我写一个脚本，里面没有数据分离的话，如果我们的系统没有设置好状态的话，一个脚本只能在一台手机上运行，当我们实现逻辑与数据分离以后，我可以参数化增加很多的登录名和密码帐户，最终匹配多少台手机上面执行我就提供多少条登录帐户，这样来实现写脚本的时间节省。还有全局、局部变量来增加参数化获取某一些值，比如说转帐比如说股票的买卖等等，通过我们的用例，通过参数化就可以实现。还有一部分就是做前端的功能验证和数据验证的时候，更多是证券、银行他们更多想验证后端的数据和前端数据的一致性，我们可以通过自己搭建的API的服务器，或者通过数据库的接口，直接去抓取后端相关的字段和前端做一个比较，来验证前后端数据是否一直。

这是测试执行，我写了五千的脚本，我肯定希望这五千条脚本在200台手机上执行，这样能提升我的效率。一个平台是否能够正常管理测试的设备，能让我们自动化的脚本分布式地在上面运行，我们也能做到，包括我们现在可以实现安卓和IOS的非入程非月历状态下的自动化执行和控制。同时还可以在我们提测的时候，可以做定时定量指定机型的测试，结果通过邮件、微信反馈回来。

接下来说一下敏捷，敏捷这一块现在提供丰富的接口，CI集成的接口，现在像平安银行、平安证券等等很多的客户，都和他们的现有开发系统集成在一起了，基本上能够实现敏捷的状态。

最后就是手机管理，通过我们平台管理以后，不管是执行任务还是说平常使用过程中的手机保管包括资产管理，包括节约中间去寻找设备的时间，可以把它完全划归为零，通过这些方式提升整体的自动化的覆盖，提升我们的效率，保证我们的测试质量。我今天的分享内容就这么多，看看各位有什么问题或者疑问。

提问：老师您好，我想问一下通过自动化来进行测试跟通过真人来进行测试，它本质上应该是会有一些区别的，自动化测出来的问题，真人测不出来，你们是怎么避免这种情况出现的？
邹世海：这个问题问得特别好，一直以来也是我们所想上自动化平台关心的问题。我们在做这个自动化的时候，首先第一点，机器能做的人肯定能做，这边会牵涉到自动化做的过程中，同时能做的情况下，自动化不会像人一样会打瞌睡，精神不好，它的执行力非常好，它不会累，这一块它的质量方面会比人做得好。
还有投入产出比这块，自动化为什么一定要相对稳定的应用？其实现阶段如果要人工去录脚本的话，如果我们版本、架构、功能不变的话，每次去维护花的时间非常多。我们做过一个比较，一个稳定的版本如果说通过人工去做和自动化去做，人力的投入产出大概是执行四轮就能够扯平，我们执行的次数越多，收益就越高。所以自动化是做一些重复工作，它的执行力比较好。

提问：您好老师，我想问一个问题，你们的设备怎么保证的？有时候自动化跑的时候有可能设备有问题的，比如说设备运用时间太长，反应慢了，怎么保证设备不出问题？
邹世海：这个不是完全能够保证的，手机本身有电池会有老化的原因。一般会让我们的手机运行一段时间以后，会让它去休息，另外在稳定的环境保持温度、适度恒定的情况下运行，来保证手机它的稳定时长能够达到更长，但是没有100%的保证，手机本身的具体情况就是这样的，而且我们手机的厂商，不同的厂商用的硬件不一样，因为我们平台上经历过比较差的厂商比较便宜的机型，有可能一个月就坏了，不仅是电池还有屏幕还有主板，所以坏机型这一块只能说通过一些方式延长使用寿命，没有办法做到可以用几十年不坏的状态，这是达不到的。

提问：您好，我是做医疗行业的，如果普通的APP用您的工具是可以的，医疗行业内部一个系统可能有几十个子系统里面，医疗行业的业务相对复杂，我们有50、60个系统其实是一次大版本更新，一个版本更新时间可能要一个小时的话，举个例子我一次版本更新涉及到底层的版本更新和APP更新，能不能有一个判断，因为目前的医疗行业的自动化程度非常低，有没有一些医疗行业的自动化测试，因为它的版本比较多，业务复杂，有的还跟互联网的APP相关，这种测试有什么比较好的建议？
邹世海：这一块我PPT里面有讲到，我们要做自动化首先要有一些前提，你选择什么样的平台和工具；二是自动化要准备很多的数据，你有没有独立的环境，你们这边如果有非常多的子系统接入，我们是不是有合适的挡板能够返回数据把整个流程走通？正常情况下，像证券也是一样的，银行也是一样的，他们会接核心的系统，不是他们自己的，银行也是一样的，会接央行，他们测试系统都会有自己做的挡板，或者他们的开发商提供的测试数据挡板，最终把业务流程走通，自动化走通。谢谢大家。

主持人：谢谢邹老师，接下来给大家分享的是极光测试部的主管刘铁柱老师，刘老师他有近十年的测试工作经验，擅长自动化测试、性能测试，持续集成、质量管理等等方面的工作，现在主要负责极光所有业务线产品测试的管理工作，他将以极光推送后台业务是如何开展测试工作为例，跟大家分享如何敏捷测试，如何控制版本质量，大家欢迎。

刘铁柱：大家好，我叫刘铁柱，今天我跟大家分享一下敏捷测试中的质量管理。为什么会讲这个东西？因为现在我们在移动互联网的阶段，加上很多公司都有大数据的产品，我们公司现在也是一个大数据的公司，我们的业务形态是比较多的，有很多种产品，而且产品上线的速度非常快，我们每天所有的业务线要上线好几个版本，今天我就是以Jpush推送业务的后台讲一下测试的技术演变。这是极光现在的规模，刚刚主持人大概讲了一下，34.4万开发者，88.7万款APP，150亿活跃终端，还有10亿的活跃设备，市场的覆盖面大概90%。

今天我讲的内容分五块：一是先讲一下业务背景，二是讲一下这一块业务的测试难点；三是讲一下改进方案；四是我们后面还没有做的事情，包括正在做的事情优化；五是测试过程中遇到的问题。

这是极光公有云的服务，左边是开发者对接极光公有云的一些业务系统，极光公有云对它提供API的服务，极光官网上面也有这一块的东西。这是我们的官网，也会对接公有云的服务。这个是我们的移动设备，总的流程不管从开发者还是官网，通过我们公有云的服务把消息推送到手机上面来。

这是我们对公有云的服务内部模块，这一块就是有对外的API服务，有一些消息的中转，还有对华为、魅族、苹果设备的一些PMS的服务业务推送，通过他们推送平台再推送到用户的手机上。还有用户的手机介入我们的SDK，我们业务会有一些标签，比如说我现在可以把广东省途牛APP的所有用户打一个标签。

还有数据库处理部分的其他模块，这一块全部是通过HPP还有RPS通过内部的交互跟传输，这里说的这些模块都是大的模块，而每个模块里面可能包括很多小的模块。而我们后台这一块，用到很多数据库，比如说CB、redis、HbiwAse、Mysql、Es、Pika，所以我们在这种大推送的业务机制下，我们对我们的性能并发要求是非常高的。我们之前给一个客户做过性能的指标要求，大概每秒可以做到八万GPS的消息推送。

下面看一下这些模块的统计：
我刚刚提到API服务，包括它的业务子模块，对于我们测试来讲，一个版本我就认为它是一个模块，而API服务大概有十个模块；segment有12个，Tagahas有10个，Db有15个，Xpns有8个，Pushtask有6个。

这是我们的业务组件，消息队列现在用到Rabbit MQ，ROCKET MQ还有卡夫卡。分布式的框架比如说SE的服务都会有；业务用到的语言C++是主流，还有Golang Python ELSE。这是测试难点的迭代速度，我统计一下我们后台小组，从三月份开始，一个月一个测试小团队测试37个版本，四月份大概是29个版本，五月份是36个版本，6月份是45个版本，7月份是35个版本，我说的版本就是我们刚刚说的子模块。而且这些模块全部是数据的传输。

针对后台目前的架构它的测试难点我们做了一些改进方案，比如说版本控制，首先作为一个测试人员或者说作为一个开发者，我们对版本的质量要求始终是不能变的，我们现在后台这一块开发大概有几十个，但是针对这部分有15—20个，对六个测试，他们是并行开发的，一个模块两个人可以同时开发，开发完了以后这个模块同时交给测试，这个测试人员把这两个板块测完。我们定义一些版本规范的方法，比如说开发通过自己的提测分支，自测完以后用该分支去直接打包，打包完了以后再通过该分支直接上线，最后把这个分支合并Master，而另外一个开发如果要改这个模块的话，再拉一次，这样避免代码不同步，这是一种方式，可能别的公司用别的方式，我们现在是用这种方式，但是别的业务线也会用别的方式，这一块没有统一，因为不同的业务对这一块的要求是不一样的。

第二，测试流程，这也是比较简单的东西，但是简单的东西一牵涉到流程，很多大团队合作的时候肯定会出问题，一会说需求不能直接提测等等问题，最后我们跟开发人员和产品人员沟通一下，基本上目前是按照这个流程走的：一个是需求分析、测试设计、测试执行、提交缺陷、回归测试，还有测试报告。测试流程里面我们是进行了优化，因为快速迭代的时候不可能每个版本提过来，这个版本假如说发现BUG，最后你测试不通过，测试不通过第二轮又提测，开发说我就改一个汉字，你怎么弄？所以针对这一块我们对用例进行解耦，比如说对应业务的模块，针对每个用例对它的用例级别进行划分，这样可以快速地根据改革的模块里面的具体点，我们筛选出要测的点。这样可以大大提高测试效率。

第三，测试用例。一个是需求出来了，较上测试评审，又测试理解需求，准备测试。二是紧急需求，明天要上线，开发人员开发完了，转给测试，这个时候测试根本没有什么设计用例，他要测的时候肯定要想测哪些点，测完以后把这个用例上传，我希望如果不能保证当前的话，一定在测试前要有现场用例，但是在下个版本这个模块再改的时候，要有上个版本所有的用例。

测试用例还有就是要精简，我们现在测试用例会出现一个问题，比如说用例一二三步，有的比较多，第一个用例依赖第二个用例，最后这个用例还不能单独执行，要等上一个执行结果，最后我们把用例精简了一下，精简的目的在于敏捷的过程中，这个用例如果写得太复杂，最后很难维护。我们要的是一个测试点，测试工作可以根据它这个点的需求复杂度进行调整，有的可以简单有的可以简单，但是用例步骤不能太多，多了的话，可能一二三执行过了，第四步失败了，这个用例有失败了，这一块我们都进行了调整，这样后期测试人员在维护这一块用例，比如说A组人员测完了，A组人员最后离职了，B组人员可以很快地上手，而不用去做大量的修改。

还有敏捷过程中，这样做有一个好处，对测试人员它的发散思维，比如说现在要测登录，这个输入框帐户跟密码，我列了几个字母组合完了，我可能不会限制这个编辑词，如果这种情况下，这个用例这样写的话，最后A测试的同学和B测试的同学可能用的不同数据，比如说我现在写字母组合给一个ABC，A组人员测的时候用ABC，B组人员测的时候还是用ABC，最后这个用的都是ABC；你发现不出新的东西。

最后就是测试报告，传统的测试流程对测试的报告要求非常复杂，有固定的格式，对应的标准，我们公司是用GIR流程，就是一个测试发布任务转到测试这边来，测试测完以后，我们把要测试的点，主要是这个功能改的一个点，把它按照临时的用例设置加上去，这个BUG重现以后，这个BUG替换为新版本，BUG修复了，自动化用例好了，这个用例就过了，只要备注一下就行的，后台不用太复杂。但是有一点要补充，比如说APP测试，我们公司有很多SDK，这个跟APP测试，一旦版本发出去收不回来，后台上线出现一个问题，我及时修复就可以把版本替换掉，业务逻辑完全就变了，但是APP和SDK的产品发布到市场以后，你收不回来，所以这种产品测试的时候一定要走正规的流程，不能草率。

改进方案的自动化技术落地：
第一，自动化框架，我们Jpush后台这一块团队在组建的时候就一个人，我来的时候是第二个人，最后是两三个四五个这样过来。所以我们在现有的资源情况下，要利用开源的东西，什么样的东西能够满足我们现在的需求，并且在快速迭代的情况下？最终我们组内讨论加上语言以后用了python+Robitframework。为什么选Python？这个语言现在比较主流，特别是AI这一块用得比较多，从我们目前团队扩大到30几个人，我们所有的测试人员从招进来上手语言都没有问题。为什么用Robitframework？它给我们解决两个问题，一个就是它是一个框架是一个工具，只是提供这么一个框架，它的框架就是我可以做很好的自动化用例管理，第二个可以帮我们生成对应的报告，还有就是它能跟Jpush无缝对接。我们用它现有的东西拿过来用可以满足我们现在的需求。

第二，自动化用例的规范。如果你要用这个框架，你在一个小组，一个小组有五六个人大家用这个框架的时候，你会发现A和B同学最后写的东西不一样，不是说业务逻辑不一样，很多东西不一样，命名都不一样，就是步骤依赖性都会有，所以我们定义了自动化设置的规范，比如说命名的规范，业务逻辑的规范，还有我们自己开发的自动化API这一块怎么使用，相互之间怎么共享，我们不做二次开发，因为我们的资源有限，我们只能这样去做。

第三，自动化的第一阶段，就是我们刚刚前面提到，后台业务的复杂度，我们对HTTP、SOCKET、RPC对它的接口协议的进行自动化设计，对它的数据返回值，比如说现在是PD的格式协议，接着就是它的数据库我要解包，解包以后要对它里面所有的K管理，这也是有。另外是HTTP协议，我给他发一个POS请求，我请求里面有很多数据，他返回给我的话，这是业务自定义的Cord，他可能还给我反馈一些数据，比如说请求成功，我们对这些东西都要进行断页。但是接口自动化这一块上一位也提过，我补充一下，借口自动化对于静态数据，就是你返回的结果，如果是静态的话，我可以对数据层进行断页，如果返回是动态的数据的话，目前不好做；比如说我要查今天深圳有多少个酒店，我一分钟前查和一分钟后查的结果是完全不一样，除非它有对应到库里，这样我去库里面捞出来，之后跟它的结果匹配。

第四，自动化第二阶段，后台这一块的业务模块，内部主要通过消息队列的形式反馈，比如说现在我给一个客户发一个消息，这个业务处理完以后把消息推到MQ，一条线会拉得很长，自动化第二阶段就是解决这个问题，一个是数据消费的数据对不对，是不是我预期的数据。二是我们第一阶段没有做，为什么没有做？因为你用这个工具的时候要考虑这个工具是不是能长期使用，万一用到一定量的时候这个工具有什么问题了，这个量是非常大的，所以我们第二阶段才去做。涉及到数据库断言，你自动化的业务逻辑会更复杂，这样维护成本非常高，我要考虑测试人员能不能扛得住，目前的情况来说还不错。

第三个就是持续集成，开发者提交代码给GITLAB，测试人员通过jenkins在Gitlab获取代码，因为我们现在还没有容器化，我们没有大量地用Docker，现在一些包没有放在容器里面，所以我们通过SSH和SCP的方式把这个包放在测试组里面，测试环节有两个，一套是日常测试环境，一套是自动化环境，这两个环境大概有100台训练机，平均的配置大概都在8和16G左右。

这就是我们目前的自动化数据，这里只统计后台，11131用例六个人维护。87%已经做成自动化，13%还没有做，13%就是我们后面做的，这里的自动化只是功能自动化，不谈性能、兼容性，不谈网络丢包各种异常的用例。我们期望的结果是我们自动化的用例可以达到99%，这是针对于监控后台这一块，不谈UI。

还有后面优化一个点，我们要容器化，现在也准备做了，可以帮我们解决什么问题？一是版本控制，一个后台的架包给你发过来，一天给你发十个包，你怎么判断哪个是第一个，哪个是第二个，它一般不会给你标版本，就算标也是开发改的。所以我们后面要做的容器化，它Docker标签功能可以帮我们解决这个问题，我们可以对标签动态生成，这个规范我们自己可以定，让它不会重复，每次提测后台模块的时候可以给我们这个标签，这样的话我们可以解决这个问题。

第二，持续集成，因为容器化之后又牵涉这样的问题，这么大的业务要维护，这还只是测试环境，另外你的人力有限，必须要想一些好一点的办法快速迭代，我们用K8S+Docker+Jenkins，这个没有问题，只是我们业务上在往上对接，包括build、deploy交互或者说部署，技术上都没有什么问题，只不过业务对接的时候，有一些配置更新，业务系统要随着开发，这一块我们现在也在做。

第三，快速部署。Docker是毫秒级的，我们用人为的操作去做这个事情，可能要几十秒。

第四，自动恢复，我们目前测试环境有200多台VM，大概有11—12物理机，都是48和360多G的配置，测试环境网络是完全隔离的，部署的模块有400多个，很多都是测试人员自己维护，跟生产环境是隔离的。

最后讲一下我们遇到的问题：
第一，技能问题。你在组建这样的团队时候，包括自动化、性能，大家的能力是不一样的，有的人工作三年，有的工作十年，工作十年的不一定能比工作三年的好，但是经验会更丰富，他测性能跟写自动化的脚本是很熟悉的，工作三年可能会比较生疏。还要让这些人达到进一步统一，所以我们把一些东西给抽象化或者我们进行简单化，比如说自动化规范包括前期的技术调用、落地，自动化有的方案要落地时候，比如说Robbit MQ消费的模式，我推一个消息通过API去调用，调用以后MQ有一个消息下来，通过自动化的方式写一个脚本让你把这个消息收到，我把这个消息解包，再把里面的数据拿出来，跟我推送的消息匹配，当然这个消息已经差距很多，我们只做关键数据的匹配，不做全量数据的匹配。

还有性能测试，今年还好，去年的时候特别多，很多种性能测试场景，你发现到我们这种MQ的生产和消费模式不支持，只能自己写脚本，我们要自己写脚本，我们写着写着就弄了一套比较适合我们压测的通用脚本，就是利用python的多携程还有多进程的方式写了一个大概的框架，测试人员只要往里面最终的函数里面写逻辑就行，这样的话我们可以把资源，我们的压力机的资源最大化。python也有它的缺点，可能几千上万测的时候，会发现准备了很多机在那里压，但是JAVA很快就压上去，下一步我们要改用（多浪）的环境来压，只不过现在是过渡的过程。

第二，环境问题。我们的环境从最开始可能几十台到现在已经有快250台，最开始可能一两台物理机，现在已经扩展到十几台，所以这一块变化很大，我们对环境要求也越来越高。还有稳定性还有多个团队要一起在测试环境测试，比如说我们有SDK的组，要用Jpush的后台，对接我们QAU环境，我们给他们搭了一个独立的自动化环境，我们现在是测试人员在弄，如果测试人员搞不定才会找开发。

第三，脚本维护的问题。刚刚看到我们脚本的量了，脚本这么大的量，版本的迭代，有时候可能会漏，这个模块改可能会影响那个模块，我们怎么做呢？我把模块划分到具体的人，最后这个模块测什么东西，你最后测完以后要把对应的自动化脚本更新，比如说增加什么功能，这个功能自动化方式可以实现，就在现有的脚本上改，最后提交上去就行。还有每日构建，我们与也是自动化环节，我们必须要每日构建，我们要检测这个环境所有的业务正确性，不是放在那里死的，做自动化的时候很容易出现这个问题，脚本开发完了，迭代两个版本，版本迭代太快，没人维护了，放弃了，就会出现这样的问题，我们做了每日构建，如果这个脚本执行失败就会发送给测试人员。

第四，自动化遍历问题。前期我们做自动化的时候，我们对协议跟接口的返回值包括它的状态做了断页，后来我们的模块在做的时候，我们的人力不够，最后想办法为什么内部模块不能自动化？比如说Robbit MQ做得最多，我们查它官方的API，查看它的API有没有对外提供的方法能供我们测试这边用，有一些东西可以通过这种方式来遍历，而且有一些服务写了一些桩，SDK要注册登录上线各种交互我们写了一个服务，是为了自动化。

提问：你好，我们做自动化测试的过程中会遇到这样的情况：比如说我们要降一些字段，这些是经过很复杂的开发计算逻辑来得到的结果，如果我们要去校验这些结果，如果要做自动化的话，大部分跟开发的逻辑一样去校验，它的成本会比较高，而且在大部分都是敏捷的开发过程中，我想问一下，你们有没有遇到这样的情况，你们是怎么去做处理的？
刘铁柱：这个问题我们确实遇到过，我刚刚讲到前面的时候，第一个就是你说的分包解包的类似问题，数据它不是明文，比如说你发一个数据过去以后还是这个数据，我们现在有两种情况：一是ACP发送请求，我们要对这个协议的字段它的值有一些KDY通过MD5或者反向加解密的方式通过我们的业务数据筛进去，最后服务端通过这个方式去解析，如果你不按照这个逻辑来做，自动化是做不了的，你随便去发一个请求，是请求不了的。针对这种情况我们按照开发的逻辑写了一个类或者一个方法，大家可以按照这个去做，把对应的数据给它传进去，最后就会生成我们想要的结果，最后我们把那个结果传到协议的值里面。
二是内部消息处理的时候，通过他们定义的结构来解析，对每个数据进行判断。我们是做了，你们没做的事情我们已经做了。但是你先不用考虑成本，如果这个事情重复性非常高，自动化都要用到的话，你是必须要做的，当然成本不会你想得那么高。

提问：你好，我是从事金融测试这一块，我们这边会遇到一个问题，结果或者说要两到三天得到一个结果，假设我要做一个对帐要到第三天才有结果，这个自动化怎么做呢？
刘铁柱：三天两天这个时间是定了吗？
提问：基本上是定了。
刘铁柱：这个我觉得可能要分两块：
第一，按照现有的方式去做，不管是数据的进跟出还是按照它的方式去做。但是你后面可能要写一个脚本，做一个定时任务放到后面，比如说两到三天是固定死的，最后在环境里面做一个定时任务，过两三天以后再起这个脚本，这个脚本拿上一个脚本两天前跑的诗句，把数据落到文件里面，这两个数据做一个比对就完了。

提问：当中如果是版本迭代的话，一天的时候就要有一个结果出来，时间的跨度有点长。
刘铁柱：那没办法，三天以后给你数据，你是没有办法的，不可能给你一个假的数据，迭代速度就是你们内部的问题，如果你非要把自动化跑完之后再处理这个事情，我觉得应该是要往这个方向走，不可能说我跑自动化的过程中再迭代一个版本，是不是要把这两个版本自动化执行完以后才能上线，必须要有一个时间差，我们现在是不测试的产品开发不轻易上。

提问：测试的过程中是以结果测试为主，因为我们现在是采用两套的路径在走，一套是功能测试是以JD为准，自动化是以Robbit为准，但是这两套执行起来配合没有那么好，有一部分人做了季米特之后就不会去维护一些自动化东西，但是有一部分维护自动化的东西，但是用了自动化就不会用季米特用接口的功能测试，有没有必要两套工具并行走？
刘铁柱：季米特自动化这个东西我不建议用，季米特开发语言对测试人员的要求比较高，如果你季米特做自动化，简单的功能可以实现，但是复杂的功能实现不了。我给你举个很简单的例子，我们做接口自动化的时候，我们要发一个SDK请求，它有一个值，你用季米特来做，可能有些东西直接写一个数字就完了，我们用python是怎么做的？我们写一个函数，我每次去调一下它，它给我返回一个1—10随机的数字，我们是这样做的，不是一个固定的东西，这样python可以帮你解决这个问题，我建议你们要抛弃季米特，季米特帮你们做简单的功能测试，它最大的优势就是它的技能属性。

提问：最近我们公司在做一个CI的环境，会出现这样的问题，虽然做这样的接口，会关联很多的系统，但是做测试的时候发现报错的时候很难去跟踪具体哪个系统出了问题，你们做CI环境有没有遇到这样的问题，或者说怎么解决这个问题的？接口跑不下去了，报错，但是我不知道是哪个后台出现的问题。最终给自动化开发提供的接口是很前端的接口，后台对接的接口很多。
刘铁柱：不是有日志吗？
提问：但是它的日志最多返回自动化，我不知道这个错误来自于哪个系统，或者是哪个系统报的错。
刘铁柱：后面对接多个系统的自动化任务，我们的模块是解耦，自动化也是按照项目结藕，我们每个自动化模块跑的可能是几百条，多可能上千条，只是被一个业务系统，我们对接自动化实现的时候，是完整的日志的输出，我们把业务返回给我们的日志模块，最后可以看到，相关的信息都可以在后端查，我们全部是公开，你们是混到一块，如果业务和相关信息是可以查出来的，那个报告是很详细的。
提问：要分系统去设置吗？
刘铁柱：我觉得是分业务模块。比如说API有十个模块，就是API有十个服务，每个服务都是一个工程，有对应的自动化脚本，我都是定时任务，比如说每天早上八点来跑，你全部用到一块的话，你发现跑了几千上万，这个时候确实定位下来很麻烦。

主持人：接下来为大家准备了茶歇。
（茶歇）

主持人：接下来分享的是来自于谐云的徐运元老师，他是谐云科技技术的合作人兼云平台架构师，他目前是主导过大型的PaaS平台的软件定义网络控制平台项目开发和落地工作，致力于容器PaaS平台，企业级容器云平台的方案设计和技术落地，我们欢迎他来做分享。

徐运元：非常感谢各位，今天下午非常高兴有这样的机会来跟大家分享一下，其实杭州谐云科技是做一体化的DevOps的解决方案，其中测试对于我们来讲也是非常重要的一块，今天我带来的主题就是讲在DevOps的场景下，我们怎么通过APM的工具来提升测试以及DevOps团队的效率。

在演讲开始之前想做一个小的调查，现在在座的各位有多少公司里面已经在推进DevOps？或者是有一些做敏捷的也算。不多。大家有听过APM这个词吗？还是不少，也算是有一部分受众，其实我刚刚在上来之前，上一场最后一位提问的同学好像跟我的托一样，我如何更好更快更有效率去排查系统里面的故障以及到底哪里出了问题，我相信我这个PPT可以在某种程度给您带来一些思想上的开拓。

我们公司是初创公司，前身是浙江大学的SAU实验室，这是我今天分享的几个标题：DevOps下测试面临的挑战；会介绍一下APM以及APM在测试场景下，我们可以做哪些实践。最后介绍一下我们公司的产品特色。

首先先跟大家一起聊一下DevOps，DevOps这个概念其实是2007年2008年左右开始非常盛行，从国外传过来的一个理论，那个时候只有大规模的一些企业才能够去践行DevOps这套东西，为什么？其实DevOps不是一个非常具体的方法论，同时刚出来的时候，也没有太多的工具链去支持DevOps的实践，所以在那时候风靡一段时间，大公司纷纷去跟风做这个DevOps，但是后来大部分就不了了之，但是现在DevOps又重新火起来了。为什么？跟它的工具链发展是分不开的，我们的DOCKER开源软件的盛行，大大降低了DevOps的成本。这段时间大家会觉得DevOps好像突然又风靡了起来，它其实是跟着一些工具链的发展是分不开的。

最早我们去网上看概念都非常模糊，官方的介绍就是要通过增强各个部门各个组织内部合作提升整个软件开发的效率，来加速整个软件的迭代，听起来很有道理，但是讲了跟没讲一样。其实现在国内已经在开始着手制定DevOps的标准，国内也成立一个DevOps的标准委员会，叫开发运营一体化的标准。现在我们再来聊DevOps相对会比较清晰了，包括敏捷开发流程还有持续交付也会包括技术运营以及在每个阶段都会有相应的工具链很好地去支持如何实践这样的理论。这个就是简单DevOps的介绍，其实很多测试人员会不会有这样的恐慌，DevOps不是要把测试人员干掉吗？会不会有这样的恐慌？其实并不是。

这是我们在实践DevOps或者实践敏捷之前每个组织的分工，它相对是比较明确的，当然各个部门各个公司会有自己的特有一些组织结构和流程，但是大的方向来讲还是分为开发，我把产品提交，我要把代码写出来，做代码提交，测试人员把代码做测试，进入到运维以后，运维人员做运维。

DevOps把整个圈子收紧了，我们怎么样才能加强内部的沟通合作？我就是要把这个流程或者把职能要做收紧，其实这里收紧不仅测试人员会做一些决策上的转变或者说技能要求上的提升，在DevOps的思想里面，我并不是说把测试人员干掉，而是说我测试可能分工、职责会做更大程度的拓展，我们称之为测试的左移和测试的右移，因为你必须左移你跟开发去沟通，你们两个项目去合作，我才能提升效率。右移也是一样，生产环境上的问题测试环境能不能测试出来，我生产环境的特有类似于刚刚提到的用户访问类的全链路的监控，在测试环境能不能把它模拟出来，是不是可以更早一步模拟生产环境的一些测试场景？这个就是我们称之为测试的左移和右移，所以大家不用担心，我们所做的工作会变得更加重要而且更加有意义，但是一个前提条件就是对我们的能力提升也是有一个更高的要求。

在这个基础上我们也需要有一些工具来帮助我们，这也回到我们刚刚聊得比较多的一块，就是自动化测试，自动化测试因为聊得比较多，我这边也不会做深入的解读。我更多来解读测试右移，怎么把运维上做的监控东西如何在测试环境可以把它做得更好或者是如何提早在测试阶段把问题暴露，这个时候成本还不太高，等你上线之后进行大量的修复成本就会变得非常高。

这是我们平台之上的DevOps的流程图，其实也提到几个大块，今天讲的就是我在开发、测试、UAT环境以及生产环境之间，虽然我们用了容器的方式来部署，但是其实我们还是没有办法来完全模拟或者是完全在测试环境进行生产环境一般的监控或者运维，为什么？其实最大程度就是中间我们会找了一个很重要的工具，就是APM的工具。

接下来给大家简单地介绍一下什么是APM？APM其实就是一个分布式的系统追踪系统，这个讲了也跟没讲一样，我们从两个视角看一下APM是干吗。

第一，从技术的视角，APM是做什么事情？它其实是做一件分布式事物的追踪，简单理解什么意思？可能会讲到另外一个概念微服务化，我们目前的互联网化的应用，不像以前的前端后台数据库完了，其实每个测试人员和开发人员都非常明确知道我这个应用部署在哪，怎么跟其他应用做交互的，在容器化或者是微服务化之后，这个概念就会相对变得比较弱，因为它的基础设施层不会像以前一样以物理机、虚拟机一台台做计算，而是一个比较抽象的资源概念。这种情况下怎么追踪用户做一个访问，我会到哪个模块，比如说它可能又会来调用很多后台不同的模块，或者还要经过一个分布式的消息系统，在这样的情况下它的电路复杂度会非常复杂，可能在整个公司只有架构师懂，其他人都不一定特别明了说当前的测试结构具体是怎么样的。

所以APM它其实就是来解决这样的问题，目前市面上APM怎么做的？基于谷歌DAPPER论文去做的，它其实就是一篇论文，论文阐述的根基就是要做好一个分布式跟踪要怎么样，这个就是它的具像表现，我利用每一步调用去增加唯一标识把单词的链路调用串起来，这个是一个技术视角，对于用户来讲很简单，我可以让你知道你单次的调用，就像最后提问的小伙伴说的，我单次调用出错了，需要知道在哪里出错。APM会给你出来一个全局调用的链路图，你调用有可能卡顿、异常，比如说红点或者黄色的线来表示单次调用是A到B出问题，你UI出问题的概率其实不是很大，大部分是后台模块出问题，通过APM的方式可以解决刚才说的这种问题。

又回到刚刚的主题，我为什么要有APM？其实我个人认为APM在非常传统的企业并不是必需，如果你还是以一个相对比较单极的来做，你所有的模块耦合在一块，你就是一个后台，你没有太大的必要做APM，因为你的链路没有那么复杂，虽然你模块多，但是有可能统一的文件，直接登录到某一台机器把文件一看问题也就出来了。因为在比较简单的架构和调用关系的情况下，你人工去做这件事情成本并不是很高，其实跟自动化也类似，如果你是一个单次的测试完全没有必要用自动化的方式来做，它会面对的场景是我们现在越来越流行的场景，就是在互联网冲击之下，我们要面临传统企业或者传统应用面临微服务化的场景下，如何通过APM提升测试的效率？其实这里会列一些比较主要的场景，就是性能测试，影响的因素非常大。当然我单体对每个应用进行测试，是一个方法，我也可以说我整体做性能测试，但是借助APM排查出某一个环节出问题。另外是针对偶发性的场景，就是出了一个BUG，跟开发纠缠不清，为什么？当时我也不知道我点了什么东西，可能这是在功能测试、手工测试的产品比较凸显。我们自动化测试也发现过，你的数据也是有变化的，某个特殊场景发现问题，如何保留这个现场，这个也是APM可以做的事情。

同时也涉及到刚刚提的，目前我们通常的测试人员给开发人员提的BUG形式，很大程度就是我慢了，我出问题了，但是你给不到开发任何的线索和证据，通过APM的方式，我保留的整个当时出错的现场，全部会在监控系统里面做保存，而且这个保存是很细。这个就是说在传统的形式之下，我们需要通过APM去做的一些事情。

它其实主要做两大块事情，首先宏观上讲，APM给你展示的是总体的链路，而不是说我单次逼着你调用，而是无限延伸或者你有多个实例，具体到哪个实例上，这些可以在宏观上展现出来，APM也可以给到你的应用工作状态其实很大程度跟你的服务器工作状态相关联，它同时也可以给到你，当你在单次应用调用发生故障时候，你整体的服务器状态是不是正常，我们也遇到测出来性能、应用没有问题，但是由于服务器本身可能是跟其他环境有共享，它的性能也在波动，状态也在波动，这种情况下我们也可以通过APM做一个整体的查看；同时还可以展示跟业务相关的数据，也可以去展现出来，如果你想看的话。

微观上可以看到你在性能测试场景下所有的方法，异常调用以及异常的一些报文，所有的数据都是基于单次列入调用的数据，而不是说我性能比较差，如果有一些偶发性的问题，其实我在偶发性的当下，为什么会出了问题？单次的链路调用所有的数据也都包含在APM的数据库里面。

第三，会给大家介绍一下目前APM在测试场景，我们觉得会对测试人员比较大的提升的几块：
一是环境审查，因为我经过了一段时间的调用之后，其实我是可以给你展现出来我整个调用链的一层关系，我拿的是一个相对比较简单的拓扑，很大情况下我们会用到这样的场景，在我们测试进行很大一段时间之后，我突然发现这个环境可能并没有配置得特别准确，我可以发现调用有异常的，这种情况下如果你继续去测试就是浪费时间，通过APM的全链路展示可以第一时间观察到我当前的应用调用会直观展示在你的面前，都可以一目了然很大程度上节约测试在错误环境上的时间投入。

二是慢方法的调用，这里展示的是每一段调用的时间，全部会以分段叠加的形式，这次调用时间是后面的时间的叠加，这次调用是后面调用的叠加，如果你方法慢了，你慢在哪里，你在做压测的时候，你对整个全链路做压测，我不是说对单个模块，基本上都是在90%以上的环境，这种情况下怎么模拟一个用户直接使用你的前端然后进行服务访问，通过我们的慢方法可以快速定位这样的问题，所有的时间都显示出来。同时这个时间是一个信息，点进去你的应用，甚至可以查看具体每个应用执行的时间，不仅是网络上消耗的时间，也有执行、处理的时间也都会以数据的形式展现在我们的面前。

这个就是定位一个慢的方法，因为这里你查看下去会知道我本身网络访问并不慢，你点进去发现应用反馈时间非常慢，这是一个具体的执行函数，你会看到执行的函数执行很长的时间，说明你的代码可能需要进行一些调优，可以直接把这个结果反馈给开发人员，开发人员可以快速定位他的问题。

这里也有一个多样化的测试报表，我们在进行性能测试的时候，除非你是用阿里的全链路压测，每个模块每个节点的压力状态测试报告，只要你用开源的软件或者商业版的软件去做，基本上很难得到整体链路的压测报告，你能得到的就是后台都是黑盒，对你来说其实你得到整个处理完的数据报告。但是通过APM，我们可以给每个节点指定要生成报表的数据，在你进行一整轮压力测试以后可以得到每个模块的压力数据，不需要单个模块一个一个去测试，这个场景可能快要上线去模拟生产上的会相关，如果你要测试单个应用在有限资源使用情况下的极限性能，这个可能不适合，因为这个会有随同理论，你的短板可能会决定你的性能报告，这个对我们性能上线是非常有用的。

这里同时也有测试无人职守的场景，这个是什么概念？我们在进行压力测试过程中，其实我们会花费非常多的时间，大部分情况下也不会说每天无聊去盯着这个报告去看，在不出意外的情况下是挺好的，但是也有可能发现一种场景你早上来公司，中午开始跑测试，其实3点的时候整个链路已经挂掉了，可能我们比较忙，没有发现这个事情，如果有APM这个工具，如果我们有频繁地出现一些异常和频繁地出现一些错误的情况下，可以通过我们的告警无人职守的系统及时通知测试人员，说这个时候你需要进行人为干预，而不是很明显出错的情况下再去跑，我们肯定要进行一轮的调优，再进行下一次的性能测试，这是我们对于无人职守测试的概念。

这个和刚刚展示的全链路调用有什么区别？我刚刚展示的是全链路，它里面所提供的数据会有后台具体的算法是相对平均的数据，会展示我性能测到现在为止整个链路的情况，这个指的是我可以给出某一次调用的具体信息，这个就是刚刚提到的，比如说偶发性的故障，因为我是测试数据，肯定是以某一些业务有一些特殊的业务上的数据是可以供我查询的。比如说我按照出故障的时间，这个数据出来就很多的，不是特别推荐的。我会以业务ID或者UI方式查询异常，这个时间点出来，如果针对用户来进行模拟测试，通常ID就是用户自己的ID，再加上你的时间，相对就会在小范围里面单次调用链路的结果，很明显中间这个过程就是非常慢的。可能就针对一次调用非常慢，也把这一次调用所有的信息记录下来，可以看这一次调用为什么慢，是方法执行慢还是网络抖动；这个对于保留一些偶发性场景的事故现场是非常有用的。

最后一个场景就是会适用于功能测试的场景，目前APM可以通过类似于网络录屏的功能来完整记录你当时测试的过程，以前我们的测试过程中都会以一些基本的截图作为整个测试的保留，目前我们可以说有网页录屏的功能，当一个测试人员开始进行测试，可以在APM开启说我这个网页录屏，但是不建议一直开着，因为会消耗一定的资源，但是在测试环境我们纯粹做功能测试，我们是比较推荐，可以以这样的方式去做。现在看起来播放的是一个视频，其实我们所有的东西都是通过后期记录的点击以及点击到的对象，我们把它重新还原一个视频结果，所以它占用的资源并不会像整个视频那么大，同时在后期如果真的遇到一些刚才提到的问题排查时候，可以通过现场回放的功能提升开发排查的效率。

我刚刚讲的这些功能，大部分只要是一款APM的工具，包括开源的软件也可以做到刚才全链路的展示功能，但是整体来讲，有些东西他们是做不到的，APM的产品是以程序探针和网络抓包去设计的，一般来讲程序探针就是程序探针，程序探针可以做到程序之间的互相调用，都是类似一些探针来实现。程序探针加网络抓包合起来以后可以做更多的事情，比如说负载均衡的感知，如果你存的一个程序探针是做不到负载均衡的感知，你感知到它是一个节点，但是无法识别它是负载均衡。利用程序探针+网络抓包的形式，就可以把它识别出来，在整个链路里面经过一层负载均衡我是知道的，同时程序里面也有很多网络协议，目前大部分的中间件都是通过特殊的协议做的，我们也可以把它识别出来，在网络里面展现出来，这也是具体的中间件，以程序探针去做也是做不到的。

还支持业务细粒度的排查，就是刚刚说的，为什么我们这边可以根据一个手机号就去把这段时间执行的慢方法或者有错误的东西抓取出来，也很简单，因为在网络包里面通过抓包的方式可以达到你的某些业务信息的，这些业务信息你是可以直接做一个排查的，如果你直接通过程序探针也做不到，因为程序探针更多传的是调用关系的传输，更多是通过抓包的方式把它所有的业务信息记录下来。

这个就是讲的我们怎么基于程序探针+网络抓包的方式实现故障的排查，另外一个特点就是我们唯一支持预先故障采集的监控，这个是涉及到性能的问题，大部分的APM市面上来说都是以直接采样算法，什么意思？就是上来从根源上我就是采样，你这个包从我程序探针抓到之后，我就是以一个采样的形式去抓，抓的过程中就是采样了，我不会做预先判断，会出现什么问题？比如说你的采样率1%，真的是一些偶发性问题，相对概率没有那么高，你是抓步道的，可能在根源上直接抛掉了，对于APM来讲，会预先会有一个过滤器，我们的算法预先过滤它的慢调用、异常或者错误，只有发现没有错，才会继续用采样的方式去做，如果发现有错误的，我们会100%保留。这个意味着不管是多小概率的事物，都会被我们的APM所抓到。当然有一个意外就是慢方法，慢方法这个东西需要手工去开启，为什么？因为慢方法全部是以打开的形式去做，这个性能的损耗不管是谁都是接受不了。除了程序慢方法执行慢的过程，只要出现了错误，你的网络上的调用慢或者执行有异常，所有的信息都会直接被APM平台所获取。

采样算法是可以根据主机负载和网络负载进行动态采样，这也是满足用户在很大情况下，其实我不想说以采样率那么低的形式收集我的信息，可能我需要采集业务上的东西做分析，我的需求是在网络和主机负载允许的情况下，动态调整我的采样算法，也就是为了100%我APM的执行不能影响应用的执行。比如说我检测它本身的应用占用量非常高，同时在也台机器上的主机状况不是特别良好，马上要达到我们设置的预期，我们会动态降低它的采样频率，尽量保证APM不会影响主程序的运行。

因为我们本身是做容器平台的，所以在这个基础上我们还有大的优势就是服务自动聚合，如何识别多实例的例子，因为这个在我们测试还是问题排查中还是非常重要，既要知道这两个实例是同一个服务，又得知道我单次调用是调用到哪个实例之上的，所以你得有一个本身基于多实例的服务聚合和展开，细粒度排查的功能。第二块就是全链路的日志查询功能，就是我确实观测到在整个链路上调用是出了问题，如何一次性聚合来看我整个链路上所有应用的日志不是一个一个打开容器，一个一个打开我的EAS去查看。在你查询的时候可以把单次，仅仅你调用所产生的这部分日志全部展现在这个功能上，让大家做一个一次性的聚合查找。没有特别多的一些测试上的实践上的东西，希望可以给大家提供一个思路，我们可以有一些更好的工具，也不一定用我们的产品，市面上也有很多产品，只是给大家提供一个思路，可以用类似于APM的工具解决我们目前测试过程中，以及之后我个人之后容器和微服务肯定会越来越普及的趋势，以及在大的趋势下如何提高整个团队的测试效率。谢谢各位。

刘铁柱：因为讲这个东西跟我们现在的业务有一些比较契合的东西，因为我们的业务架构你也看到，模块解耦，全链路跟踪你们这个产品能不能达到高并发的空间？比如说我现在测性能测试，每个模块都要往上报一次，你这个系统能不能扛得住。

徐运元：我们需要以采样的形式解决在高并发情况下的数据量，其实首先扛不住是网络，如果我所有的数据都上报，等于我会再走一次网络层面的流量，这也是我们压测过程中会发现，我们才说这边有一个动态的采样算法来保证压测过程中可以提供最大的数据采集能力，没有办法采集所有，除非你给我足够高的带宽和配置，但是我觉得公司也不会这样去滥用资源。

刘铁柱：接入的成本高不高？

徐运元：如果你用开源的话，肯定成本会比较高，但是对于我们产品的转入，我们会有自己的一套安装方式来做，会把成本降到最低。

刘铁柱：安全吗？

徐运元：可以私有化部署也可以SaaS服务。

提问：我用这个APM是不是我对自己的程序要改造？

徐运元：不需要改造，这个是无侵入的安装，刚刚提到两个东西，一是网络层的东西，二是类似于PAGP的探针，只需要在启动的时候把这个加载进去。是无改造的。

主持人：谢谢徐老师，接下来是最后一位分享嘉宾，他是Shopee的测试主管丁茂，拥有近十年测试工作的经验，主持过华为多个大型项目的测试，支撑PE级的数据和三亿以上的用户，擅长服务器的自动化测、性能测试、可靠性测试和质量预防等等，我们欢迎他来做分享。

丁茂：谢谢大家，今天很荣幸受极光的邀请过来跟大家做一个分享。
其实我前面一些东西跟前面的嘉宾有一些重复，我就简单过一下，重要是两个字“质量”。我们的测试这个行业，刚刚前面的嘉宾讲到，DevOps的出现是不是我们的测试已经OVER了？其实没有，重要的是我们产品的质量需要测试去执行，但是我们守护的质量不是自己提交几个BUG或者说写写自动化，我希望我今天的分享能够给大家带来不同的看法。

现在跟大家共勉一个故事，在春秋战国有扁鹊，有一人问扁鹊说，你们家三个人都精于医术，到底哪一位最好？他说长弟最好，中兄次之，我最差。故事比较长我就不直接念了，我简单说一下，比较重要的原因是什么，扁鹊这个人是很出名，都是大家病入膏肓的时候动手术，但是最重要的是预防，这个时候去成本最低，同时起到的效果是最好，所以他说他的长兄是最厉害的，从这个故事当中给我们一个启示。就是在源头开始，重在预防，跟我们测试行业是非常至关重要的。

下面我分享一下我今天给大家介绍的简单摘要，前面就简单过一下，重点是说一下DevOps每个环节怎么做的，另外就是讲一下灰度的部署和灰度的测试最后给大家分享，现在产品要求越来越高，我们怎么做双云的部署。

DevOps其实这个概念我想说的是，我们之前测试、开发和运维实际上是相对独立的团队，但是到DevOps出现以后，测试不仅仅是测试，要参与到整个研发流程和规范制定和评审，这是一个重要的转变，这是因为DevOps的出现。

为什么推行DevOps？就是之前的目标不一致，自己各自为政，现在要统一思想去完成一个产品交付一个任务。就是典型的金字塔，底层是方案设计，测试就是自动化，其实还有两点也非常重要，在上线和测试之间有个“灰度”，最终是上线，日常运维和监控告警，可以快速定位问题出现在哪个环节。

DevOps可以提供可视化的数据，包括研发的质量，测试的质量，包括上线之后的产品质量，可以比较清楚地看出来整个产品的情况，可视化应该是领导最喜欢的，领导可能不关心这个产品的过程怎么样，他是要知道产品的曲线，从开发到上线阶段清晰的列出来。其实DevOps给我体会最深的一句话就是：我们有了DevOps之后目标一致了，能够更快更高标准地交付产品。

我是刚从华为出来，现在到shopee那边，这是之前华为公司的实践方案，我希望这个方案可以给大家带来一些帮助。DevOps的实践方案其实有千万种，最重要要根据自身的产品情况去定制。第一个就是DevOps流程有开发、测试和最终上线发布的几个环节，说白了这么多东西我们想要怎么样保证质量？在每个环节，每个可覆盖的点或者关键的控制点，我们有相应的措施去保证它，在前端要是没有这些控制点，你到后端发现有重大问题的时候，你发现这个成本非常高。我们开发的原则就是业界最牛逼的公司应该是谷歌，谷歌可以五分钟可以出一个补丁，一天发一个版本，它为什么能这么牛逼？这个思路一讲可能大家略知一二。

我们公司之前做的是整个开发测试和发布是DevOps流水线，从我一提交代码之后，编译、打包是自动部署，你提交代码就整个流水线往下走了，不需要做人为的干预。后面有一个专测门禁，这个关键环节的时候，到下一步能不能进入到实施环节的指标，如果你前面开发，比如说检测静态扫描不符合我们设定的标准，我们的通过率不满足我们的要求又回来，再来一次。如果OK进入测试环节，测试环节也是一样的，测试环节有自动部署、供冷自动化、性能自动化、安全测试，最后到发布的环节，发布的环节就是整个性能、功能自动化安全测试行不行，有一个相应的指标，再到下面发布，发布就分两块：首先是灰度，有一个灰度部署、灰度测试，最后满足灰度的条件之后再转到全量放开的环节，实际上我们的部署还会有一些双云容灾还有在线测试，我们在线上也在测试，其实大家可以通过我们这个流程看出来什么？在每个环节贯穿着测试，每个环节贯穿着保证质量的关键措施。上线之后还有监控、告警还有一些问题定位的平台，像前面讲的APM，出现问题以后可以发现问题在哪个接口，在哪个环节，就很清晰地看到，它有个树状的关系图。

现在讲一下大家平时少接触的东西，讲一下灰度部署是怎么做的？灰度部署现在每个公司都有在做，但是做的方式可能不一样。其实我们的灰度部署就是先定好部署策略，举个例子有20台主机要部署，线上有20台主机已经上线了，列一个表清楚，然后选取对应的灰度，然后先下线再部署再上线再导流量，可以有很多种选择，这个根据场景的测试，比如说可以根据手机号，要是终端是APP，APP不同的分流就是灰度服务上。最先比如说1%到2%、10%最后到30%，基本上灰度到20%到30%就可以了，基本上就不会有重大的问题出现了，到后面可以全面上线了。

前面有一个灰度测试，我们的灰度测试在业界做得比较超前的，灰度测试是什么？跟大家之前说的完全不是一个概念，灰度测试是在于灰度部署期间，我们的灰度测试流量是往真实的流量收集，流量入库，灰度测试分为两条线，一是设计线二是运行的线。设计线就是我写相应的用例，因为我们目前只是做接口级的灰度测试，主要是接口级的做灰度测试。

重点跟大家说一下流量匹配，流量匹配是什么概念？大家都是做测试行业，做过基本测试，假如说我获取一个用户IP，我想把用户IP分成不同类型的场景，我可能还有一些错误码，分成不同的类，但是这里肯定不是做得那么全面，不会像功能自己在那个阶段做得那么详细，主要是看有没有出现错误。左边是我的设计，右边是真实的流量，相互匹配，匹配到以后就OK，匹配不上要么是错误，要么是测试用例还没写，没写我再去加，相当于不断地循环，最后把我的测试用例设计的场景补全，同时，流量经过一段时间之后，证明没有问题了。

其实想说一点，我们在测试阶段是作为一个正向的设计，灰度测试是做一个反向的，通过流量匹配我的用例和场景，如果匹配上就是PaaS，匹配不上就废了。

最后跟大家分享一下这张图，很多测试人员可能对我们最终上线的部署结构和整个数据流可能不是很清楚，这张图就是分几个层：下面I层不用我们管的，都有专业的团队管，这一层是PaaS层，在我们公司PaaS层分了两个PaaS层，一是GPaaS和APaaS，实际上也一块就是GPaaS，主要是做数据中心链，另外就是一些通用的中间件，我们称之为APaaS。我想讲一个双云部署，我们是怎么样去保证可以做到双云的部署方案。

大家看到这张图，数据层在最下方，我先说一下APaaS是做什么事情的，APaaS当中这个是数据层的监控，这上面是高可靠性的集群，保证在任何一个机房出现任何故障，这个机房级的监控做什么？做一件整体机房的监控，主要是判断VPC1和VPC2的整体状况，就是这个机房整体坏了，DBM主要判断整个业务对应的集群整体的健康状态，如果坏了，这里会实时监控到状况，Server可以感知到情况。

我举个简单的例子，比如说中间这条线崩了，这个时候我们会发生什么事情？在我们现在预定的环境下，通常会有一个预设我会保第一个机房，这边是OK的，DCM把这个清掉，右边的server就不会出现流量进来，所有的流量就到左边。再跟大家说一下复杂的场景，就是左边这个机房全部当掉了或者说这个机房整体网络或者说电源掉电了，这种情况下会发生什么事情？我们的数据都是连在左边的，为什么数据是连在一边呢？连到一边是为了数据的一致性，这边坏了，马上会监控到机房坏了，这个server会监控到，马上会知道了，现在是哪个机房坏了，同时DBM获取这个状态，虽然说这个时候数据库是好的，因为它收到一个指令，我VCP1已经坏了，马上把VPC1连接到右边的数据里面。右边的机房同样可以正常使用，基本上在五分钟之内所有的事情搞定。通过这个解决方案之后，因为我之前是做华为的手机，我们是要求在五分钟之内完成所有的事情，保证业务不中断，包括数据和应用。

总结一下：DevOps就是工程方法思想，具体实践还是要结合实际情况去做，高质量产品不是我们测试出来的，其实是靠设计出来的；测试的价值不是说仅仅找到开发提供的代码几个BUG，最重要的是我们要在整个的产品生命周期之间，提出一些有效的点子，提升产品的可靠性和功能的健全方法和体验。