在我有限的软件测试经历中，我曾经有过一次全职自动化测试的经历。接触自动化的时候，我首先接触的是自动化测试。团队使用Python，接口自动化测试框架为requests+Excel+Jenkins，APP自动化测试框架为Appium。当时整个公司都有一个现成的APP，所以在试用期间，我的任务就是完成现有APP的自动化脚本编写和调试。我记得我刚刚起步，而且我非常缺乏经验。和功能测试同学了解了业务后，就专心部署环境了。突然有一天，测试主管问我要不要输出一个自动化测试用例。恍然大悟，于是我参考了功能测试的用例，筛选了用例，输出了一个自动化测试用例（现在回想起来，当时的做法真的很马虎，没有自动化测试计划，我没复习自动化用例，只知道功能测试同学的痛点是迭代太快，回归太晚）。用例输出后，用了一个月左右的时间完成了环境部署和基本用例脚本的编写。当时大概实现了40、50个场景，完成了测试报告的自动发送。剩下的两个月，逐渐把场景扩大到200多个，这期间也遇到了一些问题，比如获取登录图形验证码，不过很快用OCR图形识别解决了，同事也使用云编码等平台。最大的问题是当APP版本更新迭代时，固定页面的所有id、class等属性都会发生变化，因为这些都是硬编码在代码中的。如果要改，意味着每一个页面都要改，工作量非常大，需要一些工具来获取这些属性，比如Appium自带的UIAutoTomatorviewer和Inspector。忙了一阵子，先找了一个Android开发者，跟他核对了一下。他找不到问题，所以他找到了另一个开发人员。检查后发现是Android混淆打包的问题。他给了我一个解决方案。通过创建一个不会混淆和打包的应用程序解决了这个问题。还有一个比较大的问题就是APP自动化测试的运行时间很长。如果我们有两三百个用例，如果加上失败重试的话，大概需要四五个小时才能跑完，而且还会出现中间脚本跑不起来而停止的问题。.我记得一个很深的印象是我们要在第二天发布版本。第一天下班前就开始跑脚本。直到晚上才收到测试报告邮件，于是晚上十点多赶回公司，发现自动化Script已经停止了。对于长期存在的问题，我会尝试引入UIAuTomator2（以下简称u2）框架来替代Appium。毋庸置疑，u2在执行速度上有很大的优势。我比较了这两个框架。同样的场景，Appium耗时60多秒，u2只用了20多秒，节省了三分之二的时间。但是随之而来的新问题是u2不是很稳定。在Appium中查找元素很有用，比如显式等待、隐式等待和强制等待。不过u2好像不需要这些。其实多跑几次场景会发现u2执行的太快，找不到元素，所以需要手动添加强制等待。这不会节省太多时间。这个问题当时没有解决。而是在我离开公司后，通过研究pytest-xdist的文档，发现pytest-xdist可以基于ssh和socket实现分布式执行。比如有200个场景，同时启动两台执行机，那么100个场景会被推送到执行机-1，另外100个场景会被推送到执行机-2，最后是两者的测试executionmachines的报告合并为一份报告。如果届时能将这样的方案应用到实践中，将完美解决APP自动化测试时间过长的问题。唯一需要注意的是，每个场景必须是独立的，不能相互依赖。话虽如此，APP的自动化测试似乎并没有产生多少收益，因为只有我一个人开发和维护，所以维护阶段费时费力，尤其是固定页面的时候被更改或在中间插入一个新集合。这样的逻辑意味着需要调整相当多的页面。第二次接触这个项目，差不多几个月后，公司开始建立新的项目，新项目一开始就确定要做接口测试，于是我又接触了这个项目，参与了在项目立项会上，参与了技术评审，了解了要做什么，接口文档怎么管理，接口怎么定义等等之后，新项目的接口测试开始了。在那个阶段，在接口不多的情况下，使用requests读取excel的方式还是比较方便的，因为代码框架比较固定，只需要在excel中修改参数即可。但是随着接口越来越多，也意味着接口之间的依赖越来越多。Excel管理简直就是一场灾难。在Excel中整理不同接口的依赖关系是一件非常头疼的事情。后来用Postman做了一些快速测试，等时间充裕了，就慢慢加入了整个主进程的接口测试。接口测试阶段，前后发现了一些问题，但最大的不足是没有解决Excel存储数据的问题，也没有验证数据的正确性。而且我们还是做支付相关的业务，这使得接口测试结果只能保证服务正常，返回码正常，而无法知道数据是否正确。直到后来，自动化组换了一批人，新同事开始实现Java栈，使用Springboot+httpclient+Maven作为接口自动化框架，基本抛弃了之前的Python自动化脚本。那几个月，几个同事都在为同一个项目埋头编写界面自动化脚本。相比之前我一个人负责的两个项目的自动化，情况确实好很多。这个自动化也是基于场景的，包括正常和异常输入的验证，最后的入库检查。脚本体积非常大，所有异常场景的请求数据和预期结果都存储在存储中。在进行后续请求时，先从数据库中获取请求数据并发送请求，获取响应结果并与数据库的预期结果进行比较。正常场景下，需要手动编写逻辑，将响应结果中重要字段的值与数据库中的值进行比较。当时考虑了很多前端无法检测到的复杂场景，比如并发、幂等，所以发现的缺陷更有意义，但是维护成本还是比较高。什么是自动化？最近一两年，我有时会思考什么是自动化测试？自动化测试本来就是为提高测试效率而诞生的，有时使用不当，反而成为测试活动中的负担。但不可否认的是，自动化测试还是有效的，区别只是动机和使用方式不同，在我看来，做好自动化测试需要避免以下几点：1.不为自动化而自动化为了自动化。基于KPI，取决于当前项目是否适合自动化，是否有足够的资源投入，以及外部团队的配合。2.自动化不是万灵药。不要贪图完美，想象所有的测试场景都可以通过自动化实现，尤其是更新迭代快的项目。实现稳定的功能，做好回归就够了。3、自动化的场景，其中一个是基础场景，另一个可以是前端无法实现的场景。对接口中无穷无尽的字段进行严格的异常检查，以确保程序足够健壮，但有时并不是那么必要。因为一个开发周期短的公司一周有好几个版本，开发没有时间做一些不太重要的字段的异常处理。当然，重要字段的类型、长度、非空检查还是要做的。4、对自动化的认识有的同事认为自动化就是找缺陷，但是自动化发现的缺陷不如功能测试。将无法发现的缺陷自动化是没有意义的吗？事实并非如此，特别是对于一些回归测试。自动化，一方面是为了提高效率，另一方面是增强团队上线前的信心。5.团队人才的培养我遇到了一些公司，他们终于开始做自动化了，做的还不错。负责人走后，就没人维护了，又招了一些自动化测试人员，开始新炉子。反反复复，归根结底是没有人做技术备份。
