大佬告诉你2023年从事软件测试的工资！

lsekfe

不知道从什么时候开始，软件测试行业就和“自动化”这个词联系在一起了，对于如今的测试人来说，几乎没有人不知道「自动化测试」，甚至查看各大招聘网站，你从任何一个招聘渠道来看最近两年对测试岗位的要求，几乎都要求会自动化测试。
　　其实测试行业未来发展之路是几乎所有关于软件测试工程师都会在意的话题，相信各位看官也很迷茫自己的发展路线。为了方便大家选择和比较，我也将我的经验和观点分享出来，以作参考。如果小伙伴们有更好的观点，欢迎分享和探讨，互相学习！
　　接触自动化
　　第一次上手自动化测试，团队里用的是Python，接口自动化测试的框架是requests+Excel+Jenkins，APP自动化测试的框架是Appium。
　　整个公司当时有一款已有的APP，因此在试用期内，我的任务是完成对已有APP的自动化脚本编写和调试。
　　记得当时刚开始去，很没有经验，在跟功能测试同学了解了业务之后，只顾埋着头部署环境，突然有一天，测试主管问我，是否要输出一份自动化测试用例。我恍然大悟，于是把功能测试的用例拿来参考了一下，对用例做了一次筛选，输出了一份自动化测试用例（现在回过头看，当时的做法真的很草率，既没有一个自动化测试计划，也没有对自动化用例做评审，只知道功能测试同学的痛点就是迭代太快，回归来不及做）。
　　用例输出后，大概花了一个月的时间，完成了环境部署和基本用例脚本的编写，那时候大概实现了四五十个场景，并且完成了自动发送测试报告。剩下的两个月，我就一步一步将场景扩充为二百多个。
　　其间也遇到了一些问题，比如登录图形验证码的获取，不过使用OCR图形识别很快就得到了解决，同事也有使用云打码一类的平台。
　　最大的一个问题是，当APP版本更新迭代后，固定页面所有的id、class等属性都会变化，因为这些都是写死在代码里的，如果要更改意味着每个page都要更改，工作量非常之大，而且获取这些属性还需要借助一些工具，如UI AuTomatorviewer 、Appium自带的Inspector。
　　在忙碌了一段时间后，先找到一个安卓开发，跟他排查了一下，他也找不到问题所在，后面又找了另一个开发，他排查之后发现是安卓混淆打包的问题，他给我出了一个不做混淆打包的APP，这才解决了这一问题。
　　另外一个比较大的问题是，APP自动化测试的运行时间非常久，我们两三百条用例，如果加上失败重试，大概要跑四五个小时，而且还会出现中间脚本出错运行停止的问题。
　　记得一个印象比较深的事情是，我们第二天要发版了，头一天下班前我开始跑脚本，等到晚上我一直没有收到测试报告的邮件，于是晚上十点多赶回公司，发现自动化脚本已经停止了。
　　对于时间久的问题，后面我尝试引入UI AuTomator2（以下简称u2）框架来代替Appium，毋庸置疑，u2在执行速度上有很大优势。
　　我曾经对比过这两个框架，同一个场景，Appium需要耗时60多秒的，u2只需要20多秒，足足节省了三分之二的时间。
　　但随之而来新的问题是，u2不太稳定，Appium中查找元素有用到显式等待、隐式等待和强制等待，而u2中看似不需要这些，实际上多跑几遍场景就会发现u2执行太快会找不到元素，因此还得手动加上强制等待。这样一来时间并没有节省多少。
　　这个问题当时没有得到解决，反而是在我离职后的一段时间里，通过学习pytest-xdist的文档，发现pytest-xdist可以基于ssh和socket来实现分布式执行。
　　举个例子，假如有200条场景，同时启动2个执行机，那么就会往执行机-1上推送100个场景，往执行机-2上推送另外100个场景，最终两个执行机的测试报告会集成为一个报告。这样的解决方案如果当时能应用到实践中，那么APP自动化测试时间过长的问题会得到完美解决，唯一需要注意的是，每个场景要独立，不能相互依赖。
　　话说回来，APP自动化测试做下来好像没有产生多少收益，因为只有我一个人开发和维护，所以到了维护阶段就显得耗时耗力，特别是本来一个固定的页面改了或者中间插入了一套新的逻辑，就意味着相当多的页面需要调整。
　　第二次接触项目
　　差不多这样做了几个月后，公司开始立新的项目，新的项目一开始就下决心要做接口测试，因此我又介入到这个项目中，参加立项会议、参加技术评审，了解了要做哪些，并且接口文档怎么管理，接口怎么定义等等之后，就开始了新项目的接口测试。
　　那个阶段，使用requests读取Excel的方式在接口不多的时候还挺方便，因为代码框架比较固定，只需要Excel里修改参数。
　　但随着接口越来越多，也意味着接口之间的依赖越来越多，Excel管理简直就是灾难，在Excel里要理清不同接口的依赖关系，是非常头痛的一件事。
　　后来我使用Postman做了一些快速测试，等待时间充裕的时候，再慢慢把整个主流程的接口测试加上。在接口测试阶段，前前后后发现了一些问题，但很大的不足是没有解决Excel存储数据的问题和没有做数据正确性的校验。
　　而且我们还是和支付相关的业务，这使得接口测试结果只能保证服务是正常的，返回码是正常的，但是数据是否正确无从得知。
　　直到后来，自动化团队换了一批人，新来的同事开始推行Java栈，使用Springboot+httpclient+Maven来作为接口自动化框架，基本舍弃了之前的Python自动化脚本。
　　那几个月好几位同事投入到同一个项目的接口自动化脚本的编写中，对比之前我一个人负责两个项目的自动化，情况的确好了很多。
　　这个自动化也是基于场景的，有做正常和异常输入的校验，以及最后的入库检查，脚本量非常大，所有异常场景的请求数据和期望结果都是入库的，后续请求的时候，先从数据库拿到请求数据发送请求，得到响应结果再和数据库的期望结果做比较，正常场景需要手动写逻辑，响应结果里重要字段的值和数据库里的值做比较。
　　那个时候，考虑了很多前端无法测到的复杂的场景，并发、幂等之类的，因此发现的缺陷更有意义一点，但是维护成本依然比较高。
　　自动化是什么？
　　最近的一两年，我有时会想到自动化测试是什么？自动化测试本来是为提高测试效率而生，有时候使用不得当，却成为测试活动中的累赘。
　　但不可否认的是，自动化测试仍然是行之有效的，区别只是使用的动机和使用的方式，在我看来，做好自动化测试需要规避以下几点：
　　（1） 不要为了自动化而自动化
　　自动化测试不能基于KPI，而要看当前的项目适不适合做自动化，有没有足够资源的投入和外部团队的配合。
　　（2） 自动化不是万能的
　　不要贪多求全，妄想所有的测试场景都能通过自动化实现，尤其是更新迭代快的项目。能把稳定的功能实现，并且做好回归 ，已经足够了。
　　（3） 自动化的场景
　　一种是基本场景，另一种可以是前端无法实现的场景。
　　而对于接口中无穷无尽的字段进行严苛的异常校验，来保证足够程序足够健壮，有时候反而没有那么必要。
　　因为开发周期短的公司一周好几个版本，开发根本就没时间对一些不太重要的字段做异常处理，当然重要字段的类型、长度、非空校验等还是要做。
　　（4） 对自动化的认知
　　有些同行认为，自动化就是为了发现缺陷的，但是自动化发现的缺陷根本比不上功能测试，发现不了缺陷的自动化就没有意义吗？
　　事实并非如此，尤其是一些回归测试的自动化，一方面是为了提高效率，一方面是为了增强上线前团队的信心。
　　（5） 团队人才的培养
　　遇到了一些公司，好不容易做起了自动化，做得也不错，等到负责人离职之后，就没人维护了，然后再招一些自动化测试人员另起炉灶，反反复复，归根结底是没有人做技术备份。

bellas

很详细

bellas

很详细