PPT：
演讲稿：
P1-P2：大家好，今天跟大家分享的主题是拥抱变化的自动化测试系统。
介绍
P3：作为一个从业十多年的测试经理，从过程管理做到研发，从研发做到测试，扎根测试十多年，经历过单机版、CS系统、BS系统、B/CS系统、3D沉浸式系统、云计算，等等数十个产品和项目，在传统或者敏捷开发项目管理模式下，推动自动化测试都有一个痛点，就是不断变化的系统对已实现自动化用例的冲击。
P4：今天根大家分享的主题是如何在不断变化的需求和页面下，打造一个健壮的APP页面自动化测试系统。
变更对自动化测试的挑战
P5：在APP的自动化测试中，我们遇到过一个令人悲伤的故事。我们的自动化测试人员从无到有，从零开始学习研究APP自动化，花了半年的时间完成了产品主要业务用例的自动化，刚用了几个星期，种种原因下，产品页面重构了！！！元素都变了，用例都废了！虽然提前把页面、数据、用例都实现了分离，但是扛不住操作步骤都变了！伤心，愤怒，难过，没办法，又花了几个星期重写了用例，结果没用多长时间，产品业务重构了！！这个产品已经是做了好几年相对成熟的产品了，但是现在是一个拥抱变化的时代！！这样用例又得跟着重构一次！
P6：也有一些项目在项目热度很高的时候，有钱有人，花了大力气实现了数千个上万个自动化测试用例，结果用了没多久，项目自动化人员撤走了，维护这些用例成了不可承受之重。因为执行这些用例就要数个小时，当页面变化或者功能变化造成自动化测试失败，去维护这些用例的成本就更高了。到最后这些写好的自动化用例大部分都“死了”，因为再也不会去执行。
P7：一个稳定的自动化测试系统，要受到多种变更带来的挑战：
页面变化：包括界面元素增删改，元素位置变化，定位属性发生变化，等，一旦发生，写好的自动化用例就会失败。
业务流程变化：更大范围的变化，涉及到业务功能和流程的变更，这样失败的自动化用例会更多。
相关系统变化：接口定义变化，返回值变化，环境变化，都会造成自动化用例的失败。
还有其他的各种变更，都可能会造成自动化测试用例的失败。
怎么才算是健壮的自动化测试系统呢？
P8：成功率高：同样的用例跑来跑去都是一样的结果，不会出现以下情况。第一遍成功了，第二遍又失败了；我的机器上成功了，换个机器执行就失败了；这个版本成功了，下个版本失败了；等等。
维护成本低：当变更发生时，修改点少而且好修改。通俗易懂，新的自动化人员可以很快上手维护。
我们想做的是，在拥抱变化的锤炼中，慢慢打造健壮性越来越好的自动化测试系统，降低维护自动化的成本。
P9：咱们分析一下会造成自动化测试失败的变化原因：
页面元素找不到了。可能位置变了，可能名字/ID变了，甚至可能被删了。
期望结果对不上。可能是业务变了，可能是多了一个弹出窗口步骤变了，也可能是相关系统的返回值变了。
为了拥抱变化，自动化测试系统要做好以下准备：
提高成功率：
P10：一次编辑，处处成功
部分功能变化，只有少数用例失败。操作步骤变化时，仅影响变化流程，其他业务不受影响，让变更辐射范围最小化。比如淘宝上商品上架流程变了后，购买下单流程虽然用到了商品，但是购买下单流程的自动化不需要修改。
相关系统接口发生变化时，非交互业务用例不受影响，隔离交互操作。
降低维护成本：
P11：页面元素变化时，可以修改一处，其他联动变化，降低其维护成本。比如有200个用例都用到了页面A，当页面A变化时，只需要修改页面元素定义，那200个用例都不用修改。
期望结果发生变化时，只影响当前用例。
不同测试数据，相同的测试步骤，只需要写一遍。这样测试数据发生变化时，只需要修改数据即可
代码写的通俗易懂。
打造健壮的页面自动化测试系统
P12：
这里给大家介绍下一种提高页面自动化健壮性的解决方式，大家可以根据项目的实际投入和精力，参考不同的方案，通过一步步的锤炼，逐步打造一个在各种变更和问题中浴火重生的自动化系统，逐步降低自动化的维护成本，提高其使用效率，创造更大的价值。
写好的代码
分层之前，先解决掉失败率的问题。同样的用例第一遍成功了，第二遍又失败了；我的机器上成功了，换个机器执行就失败了。这个是技术的问题，技术不熟练，代码写的不到位，就会出现这些问题。如何解决这些问题呢？
多写多练：我知道这个建议很土，简直是太实在了，但是提高技术的最佳途径就是多练习，熟能生巧，这个是很难绕过去的。天资聪颖擅长举一反三的天才有，毕竟是少数，不在讨论之列哈。
多读书：踩在别人失败的肩膀上，吸取他们的经验，避免犯常识性的错误，少走弯路。
多执行几遍代码：在不同机器上，不同环境下，甚至是同样的环境下，尽量多运行一下自己的代码，自己就能发现这些问题，改正错误了。错误改正了，失败率就降低了。
研发是我们的好兄弟。自动化用例离不开产品研发兄弟的支持，页面元素好定位，自动化代码好实现，需要研发同事在开发时符合一定的规范，例如给页面元素加ID，页面变化时尽量保持ID不变，等等。
P13：下面是APP页面自动化测试中一些我们趟过的坑，给大家提个醒：
等待时间时间不合理，比如网速好的时候系统0.1秒就返回结果了，网速差的时候可能1分钟页面都刷不出来，如果没有合理的等待，那网速好的时候写好的用例，在网速差的时候就会失败。
代码中的方法依赖特定环境，比如，代码用了JDK9的新方法，但是运行的机器是JDK7，不支持这个方法。
代码中写死了变量。比如，直接在步骤中写死用账户A的密码，用账户B登陆就失败了。
没有处理不同权限下的情况。比如，用管理员账户可以去创建账户，用普通用户登陆也执行了同样的用例就失败了。
自动化用例写的太多了，维护不过来，有些自动化用例写完就再也不执行了。
分层与隔离
P14：如果没有分层，所有的步骤和测试数据都写到了一起，当有一个变化时，所有的点都要改，工作量大不说，漏改了用例就失败了。我们分层的目的是为了减少修改量，并且降低系统变更带来的失败率。
P15：自动化分层有几种情况，页面自动化的分层和接口自动化有所区别，这里讨论的是页面自动化测试的一种分层实现。
测试数据和用例分离：包括登陆账户信息，被测产品的各种对象，某些操作的期望结果，等等。
测试页面和用例分离：页面元素统一维护，方便变更时修改一处即可。
操作和用例分离：常用操作，与业务无关的通用操作，这些可以封装起来，便于变更发生时只维护一处，减少维护工作量。
测试用例原子化：将测试用例尽可能拆分到小单位，便于后续根据各种场景的需要进行组织和调用。
测试用例的组织：根据各种测试场景的需要，执行不同的测试用例组。
下面介绍使用Appium实现APP页面自动化测试系统时，各种分层实现时的参考实现。
P16：
测试数据是我们的基础，讲测试用例抽取出来有一下好处：
- 同样的步骤调用不同的数据，验证不同的期望结果；减少代码量，减少维护工作量；
- 某些测试数据可以在不同系统中通用，比如说同样的业务，有的用APP实现，有的用web实现，有的用H5接口实现，等等；这样某些系统的测试数据可以直接拿来复用。
- 测试数据独立后，可以统一用一套数据文件读取和维护方式，提高稳定性。
P17：
页面元素的在同一个地方定义后，一旦变化，只需要修改一处。页面定位的方式有很多种，但是页面元素定义只有一处。
我们还可以把页面元素的定位抽取为通用操作封装起来，更好的操作和维护。
P18：
通用操作的封装后，同样是一处定义，处处使用，减少了开发量；一旦变化，减少维护工作量。
通用操作的一般是指与业务无关的一些操作，比如点击，双击，滑动，翻页，等等。
同样的也有一些常用操作的封装起来，在测试用例中调用，也可以提高效率和稳定性。例如，登录，退出，买卖操作中的商品添加，等。
P19：
测试用例在编写中，注意实现原子化。就是说尽可能颗粒小的业务单位。这样做的意义是，越短的执行步骤，失败的可能性越小；越小的颗粒度，引用和调用的时候越方便。
写用例的时候，我们可以把页面校验用例和业务用例分开来写。这样页面变化时，页面校验用例失败，但是业务用例关注的是流程，在基础操作调整完毕后，业务用例不用调整。业务用例关注是流程和数据传递。
我们在写业务用例时，要关注用例调用和调用顺序，提高其稳定性。
P20：
有了上述各种抽取和分离后，稳定的原子化用例可以根据测试场景的需要，执行不同的用例。
功能测试的时候执行所有相关用例；主流程用例关注主要业务用例的验证；等等。
P21：
自动化完成后，如果有条件，可以结合Jenkins实现自动化打包部署和自动化，共同提高产品质量，更多更好的利用已经写好的自动化测试用例，尽早发现缺陷。
基本步骤有：
搭建打包服务器，包括安装Android Studio，下载源代码，配置Android Studio下载需要的支持包，修改配置文件，启动打包服务。能成功的打包出可运行的APK后，这一步就完成了。
配置Jenkins服务器：包括Jenkins的安装，相关插件的安装，创建Jenkins工程运行在打包服务器上，完成源代码同步下载，打包脚本执行，备份生成的测试包。
进一步配置Jenkins工程，完成各种测试环境下的打包，如生产环境，演示环境，测试环境，挡板环境，等。
配置Jenkins工程，根据需要执行指定的自动化测试用例，生成测试报告。
P22：
这是一个实例，通过在Jenkins上执行要生成的各种环境下测试包，然后运行指定的测试用例。左侧是配置的测试脚本的一部分。
小结
P23：
为了打造稳定的自动化测试系统，拥抱变化，减少变更发生时自动化测试系统的维护工作量，提高自动化测试用例的利用率，用的多了，健壮性就逐渐打造出来了。这次我们介绍了成熟的代码，分层和隔离，通过Jenkins推动测试左移，与研发一起利用自动化提高测试质量，这些方式来逐步打造健壮的变化友好的自动化测试系统。
希望这个分享能给大家起到一个抛砖引玉的作用，在大家的工作中提供一点点新思路和帮助。
感谢云 社区提供的机会，本文参加【技术创作101训练营】活动。
