谈谈自动化测试

在业界，只要涉及测试，自动化是避不开的话题。

毫不避讳地说，对于一名QA人员而言，手工黑盒测试是最low的行为。在这个基础上，不同风格的QA有不同的发展方向：成为业务专家、钻研自动化测试、进行白盒测试、性能测试等。这篇文章主要从自动化的角度进行分析。

进行自动化，首先就是要进行自动化框架的选择。目前开源的自动化框架简直不能更多：底层的junit 、testng、 pyunit，以及业务类型强相关的webdriver、 selenium、 uiautomation等等。对于这些框架的选取，只有合不合适，并不存在绝对意义上的好或者坏，在这里也无意进行对比。而对于实际的业务痛点，这些框架也各有各的难处，也不多述。下面的正文主要是根据实际的业务痛点，谈论下对自动化框架的诉求，实现难点以及一点思路（如果有可能，实现方式等放在其他文章中说明）。

痛点1：开发框架日新月异，而测试框架却鲜有新意。

单元测试需要深入代码逻辑，不过这基本是RD同学的任务，与QA人员貌似没有太大关系，所以此处不提。

可能是基于测试活动的本身的特点，测试框架的种类范围总是不大。自动化测试和项目本身在某种意义上讲是分离的：不论是UI测试，还是接口测试，都是从外部去对系统进行检验，可以认为是一种比较高端的黑盒测试。UI测试方面，基于Web的Webdriver、基于APP的Appium、Macaca都是CS模式，写作用例的同学写的本质上都是webdriver的客户端，客户端组装WebDriver请求，发送到服务端，服务端再通过js脚本进行具体操作；接口测试方面，最常用的就是模拟HTTP/HTTPS协议发送请求到服务端，再根据服务端的返回进行校验。而testing这类底层框架，需要做的就是按照既定的流程去执行已经实现的各个功能，并声称测试报告。

当然，刚才提到UI和接口对应的两类测试方式，都是基于手工测试抽象出来的，本身并没有问题，也足以覆盖绝大部分场景。不过由于基础测试手法的单调（或者说对自动化测试需求不多），自动化框架的花样也比较少，无非是从不同的业务角度进行细化。

解决方案：暂时没有。自动化测试就是手工测试的抽象，手工测试变革之前，自动化测也会保持现有的状态。不过严格来讲，上述内容本质上只是一个现状，并不是亟待解决的问题。

痛点2：频繁变更的业务需求，导致自动化的维护成本巨大。

现在进入主题。除非极少数纯粹为了KPI而写自动化的同学，一般而言，所有同学都希望自动化case能够稳定执行，闲来无事发现几个bug也是极好的。不过现实却是：每当用例失败时，排除用例本身问题，绝大多数情况下，都是需求变动导致的。这恐怕也是大部分自动化测试同学的痛点，尤其是当case足够多时，很难跟着版本去维护已有的case（与产品代码不同，各个测试case的代码往往是相对独立的，彼此之间并没有足够的逻辑性，修改case时很可能需要把case完整看一遍；同时，在一个版本中，测试同学投入在自动化中的精力并不高，无法和开发同学投入项目的精力相提并论）。总而言之，case修改的进度肯定是很难赶上项目代码修改的进度的。

解决方案：为什么难？因为改测试case代码成本高。成本高一方面是人员能力的问题，很多自动化case都是照猫画虎写出来的，QA同学对于case的原理并不清楚。遇到小的业务逻辑修改还可以接受；当变动大时，很可能会涉及到测试框架底层的修改，这种情况下，不少QA同学就被阻塞住了。所以，QA人员的能力提升就很重要。

不过，针对这个问题，框架能做什么？我希望这个框架能够屏蔽掉代码层，而仅仅从功能点的层面进行修改。框架本身就可以提供一个UI界面，每个case是一个一系列功能点在UI界面的罗列，执行时是对每个功能的串行。当需求变动时，只需要修改串行列表的内容和参数，而不需要修改代码。如此一来，另一个问题就出来了，具体如何屏蔽，功能点怎么来的？按照痛点1所说，所有测试行为的本质无非那么几个。对于UI——找元素、点击、输入、拖动；对于接口——发HTTP/HTTPS请求，收HTTP/HTTPS响应，对结果的校验几乎等价于对xml/json的校验。将这些主要功能点抽象出来，保留适当的接口，结合具体业务进行参数化配置即可。

痛点3：测试过程和结果的稳定性堪忧。

即使代码不改动，在执行自动化case时，成功率也经常难以令人满意。原因在于，影响最终输出结果的因素中， 除去代码逻辑，还包括产品的配置、上下游服务调用时传递的消息、底层数据库数据、中间件数据等。对于一个小系统来说，这些因素的可控性强一些；而对于较大的系统，一个测试团队往往只测试其中某一个模块，对于其他模块以及其他模块对基础数据的影响时无能为力的。

解决方案：对于可控的部分而言，做到环境可配置以及环境可恢复是很重要的，我认为这也是很多测试框架在具有test之外，还具有before 和 after的原因。不过这种方式也存在一些问题：1、修改成本高。修改数据库、中间件数据，甚至修改产品配置，都需要通过代码完成，而这些配置对于普通自动化协作人员而言，成本还是比较高的。2、case之间难免存在相互依赖活着相互影响的关系，尽管before和after执行的是一些基本操作，但并不能保证一定可以完全执行，当二者的某个过程执行失败时，势必造成数据的异常，而这种异常对其他case的影响，也是难以预知的。针对上述问题，也有两点方案：1、收敛环境配置所需要的操作，尽量做到可固化，并进行封装；2、重新设计自动化测试流程，尽最大努力保证before和after中的操作能够完全执行。

对于不可控部分，需要能够mock数据，这样就减少了对其他系统的依赖。

痛点4：对于执行结果的校验和问题定位不完善。

已有的自动化框架中，检测用例是否成功的方法主要是流程是否执行完成以及通过assert判断某些关键数据是否正确。我将这种校验方式理解为散点式的校验，校验的结果仅限于流程是否正确，对于数据计算的正确性是无法覆盖到的。同时，一个完善的数据校验，除了针对返回结果，还应该针对执行过程进行校验：同步/异步调用参数、数据落盘、关键日志等都是在手工测试时会关注但自动化覆盖不到的部分。所以说，怎样做到从散点到线再到到面的覆盖，同时控制住自动化case的写作和维护成本，可以作为判断自动化框架优劣的标准。根据我目前的了解，现有开源自动化框架是可以做到这些的，问题在于成本太高。

解决方案：1、由点到线——横向。横向指的是对返回数据（UI自动化通过webdriver协议，获取页面信息的过程也可以理解为返回数据）校验的扩展。一般的自动化case校验点主要是返回状态码，或者页面是否包含某些关键字，但涉及到数据的结构（比如json串的树状结构、页面的html结构）、数据的准确性时，往往无能为力。一个重要的原因是在，这些数据对于case而言是不可控的：手工测试可以一步步从底层数据计算出最终数据，但自动化测试没这么灵活。一个解决方法是，通过与基础分支的对比进行校验。针对同一个case，在两套代码上分别（分别为master分支和dev分支）跑一次，以master代码的结果为基准，对两次的结果进行diff，进而判断用例是否执行成功。说到这里，又会延伸出很多其他问题，比如基础数据一致性、两套代码所部署环境的拓扑信息、diff校验方法、噪音处理等等，此处不多表述，后续在做框架设计时，会给出方案。

2、由点到线——纵向。纵向是指除了对返回数据校验之外，对系统本身的数据校验。这块目前时没有太多技术难度的，难点在于时间成本。一个更加复杂的用例，在写作和维护时都需要更多的时间。降低时间成本的方法，还是在于对功能的收敛和抽象和封装，从业务中将功能进行抽离，封装成通用功能，并提供合适的接口。

从单点开始，进行两个维度的扩展，最终可以实现自动化从点到面的扩展。

总结： 进行自动化写作，目的是维护系统稳定性，保证产品质量，而非单纯KPI。自动化用例框架，存在一个貌似悖论的问题：应用灵活的自动化框架，往往比较复杂，对人员要求更高；简单易用的框架，灵活性又比较差，不易适配业务需求。解决这个“悖论”的问题，需要从更宏观的角度来看。个人认为有两点：1、人员能力。老生长谈，不说也罢。2、更改框架模式。根据实际业务状态，在已有开源框架的基础上，进行二次开发；或是另起炉灶，写一个全新的自动化框架。目前正在构思一个测试框架，设计思路、实现思路应该也会写在这里。

上面是我收集的一些视频资源，在这个过程中帮到了我很多。如果你不想再体验一次自学时找不到资料，没人解答问题，坚持几天便放弃的感受的话，可以加入我们扣扣群【313782132 】，里面有各种软件测试资源和技术讨论。

当然还有面试，面试一般分为技术面和hr面，形式的话很少有群面，少部分企业可能会有一个交叉面，不过总的来说，技术面基本就是考察你的专业技术水平的，hr面的话主要是看这个人的综合素质以及家庭情况符不符合公司要求，一般来讲，技术的话只要通过了技术面hr面基本上是没有问题（也有少数企业hr面会刷很多人）
我们主要来说技术面，技术面的话主要是考察专业技术知识和水平，上面也是我整理好的精选面试题。

加油吧，测试人！如果你需要提升规划，那就行动吧，在路上总比在起点观望的要好。事必有法，然后有成。

资源不错就给个推荐吧~