后疫情时代裸辞后面试软件测试工程师被拒，写下一些感悟和面试心得

今天去面试一家公司，被面试官给打击到了，倒不是这真的被打击到，而是被面试官给指导了很多，真的是受益匪浅，学到了，学到了

然后搁这儿呢，也算是面试有所感吧，作者就闲着和大家聊聊测试吧。聊些什么呢，就聊聊对测试的一些看法吧。作者从事软件测试的工作也三年有余了。在这里仅代表本人个人观点，如果有什么错误的地方，还请大家指正。

功能测试

大部分人都是从这个开始干，想来也不会陌生。黑盒嘛，点点点，很多人都觉得这玩意儿是个人就能干的来。也有很多做功能的兄弟们不太受待见，有种不太受重视的感觉。我只想说，很正常。真的很正常，国内市场就是这样，黑盒不受重视，反而更倾向于那些会使用工具的测试员。诚然不知，黑盒测试在测试工作中与那些工具比起来要重要多少。工具只是一种手段，主要还是辅助性的作用，为了完成测试达到预期目标使用工具无可厚非的。但是测试的主导，毕竟还是测试人员本身。测试人员的专业素质，测试思想才能保证测试工作的核心。

而且功能测试真的不轻松。可能大家看到的只是我们的点点点。实际上，点点点，是从功能上完成了对整个产品的功能验证，并不局限于功能的验证。除了功能的验证，还涉及到了接口的数据验证，代码的逻辑。

有些同学可能会产生疑惑，怎么点点点就扯到了接口的数据验证，代码的逻辑了呢？功能上的测试，通过模块之间的交互的测试，就能够在UI层面上对接口进行测试了。这里是能够验证接口的调用，数据的验证。因为接口调用或者是数据错误，在客户端是必然会出错的。而作为功能测试的我们，在经验欠缺的时候是无法意识到的罢了。然后就是代码的逻辑。我们在验证每一个功能点的时候，都有自己的测试的逻辑。我们往深了看，程序员在编写代码的时候，也是有自己的逻辑的。每一个函数，类，模块，都包含着程序员的逻辑。这些集成之后，最终形成了我们所看到的web页面或者是客户端。如果代码的逻辑出现错误，那么在UI层上也是能够检测出来的。

除了上面说的那些，还包括健壮性，稳定性，可靠性，app的专项测试（笔者是做的app测试）。每一项测试，都有其存在的必要性。这里不再叙述，只是告诉大家功能测试，不仅仅局限于对功能的验证。

自动化测试

自动化测试目前是最火的热门技术。几乎各大网站，各个公司的招聘需求上都会要求会自动化，会使用qtp，会使用selenium/appium/webdriver等等。笔者对自动化的认知并没有很深刻，也是前几天试着玩了一下selenium，在这里只是谈一下本人对自动化测试的看法。

自动化是分层的。看过我的移动app测试经验分享的同学应该想必都是知道测试金字塔的。不知道的同学可以去看看，也可以去百度一下测试金字塔。

我们上面所说到的自动化，其实仅仅只是UI层的自动化，也是大多数人眼中的自动化。

UI层的自动化，是有一定的局限性的。主要的用途实际上是用来进行辅助回归测试。首先对那些需求变动频繁，以及场景过多的模块确实不太适用。然后就是维护成本，这也是一个问题，无论你是录制，还是自己编写的脚本，你总得维护吧？这两个因素就在一定程度上制约了UI自动化的使用。

UI层的自动化，实际上就是定位元素，然后通过调用键鼠操作的方法，模拟真实用户进行操作。也是最贴近实际场景的自动化测试。

然后，还有些对UI层自动化测试不甚了解的同学，甚至会认为可以使用自动化测试代替人工测试。之前的项目中，一次例会上，我提出申请招人，我一个人实在忙不过来。我的技术总监就告诉我说可以写一个自动化测试的脚本替你进行测试，我竟无言以对。UI层的自动化测试，也就仅仅只是用来辅助回归测试的好嘛。你让我这样做，我是不是要先去写个AI机器人呢？

接口自动化测试，接口的自动化测试按照我目前的认知，应该是可以对接口的数据进行验证的。包括数据的正确性，数据格式，响应时间。这个不仅仅能够辅助回归测试，而是实实在在的可以用到测试执行当中的。接口测试的主要目的也就是为了验证数据。所以对于接口自动化，可能更适用一些后台管理的应用，或者是那些更加关注数据不太关注UI层的系统。

相比UI层的自动化，接口自动化能够更早的介入并开始测试，颗粒度也比UI层的颗粒度会小，能够在一定程度上减少项目的成本，提升工作效率。

博主曾思考过一个问题。UI层的自动化，主要用途是在UI层进行回归测试。然后接口测试，是通过接口测试逻辑，理论上来说的话，逻辑只要没错误，功能应该就是没错的吧？那么做UI层的自动化还有什么意义呢？我直接做接口的自动化不就好了吗？

在最初思考的时候，我是钻了牛角尖。后来才想明白，UI层的自动化毕竟只是用来辅助回归测试的，而接口的自动化是验证数据，接口逻辑的。本身的定位就不同，作用也不一样。再回到我们前面说的问题，接口的错误，在客户端是必然会产生错误的，而UI层的错误，却不一定会是接口层的错误。再者，UI层自动化是通过对元素的定位，模拟用户操作，而接口自动化则是通过接口的调用。所以说所以两者还是有些区别的，也是不可互相替代的。

我看到有些同学在讨论，自动化测试会不会取代手工测试？

真的，我觉得这完全是没必要关心的问题。自动化测试真的能取缔手工测试吗？笔者认为这是不可能的。因为实现起来难度太大了。就像我前面讲到的。去写个AI吗？就算是写个AI，那不也是人完成的吗？何况，真的要是到了那一天，如果你还是个手工测试，你也就没必要混下去了。程序的本身是由人的逻辑构成的，但是它始终是个程序，在面对复杂的场景，异常的场景的时候要怎么办呢？而且如果真的要设计这么一个自动化的程序，它的投入和产出怎么算，真的值得吗？这又值得思考。

使用工具还是学代码？

这个问题相信大家也都遇到过。我们做测试不就是因为不喜欢代码吗？而且现在的工具很多，学起来也很方便。干嘛要学代码呢？我之前也是这个想法。不过在我学习了python之后是彻底改观了。当然我不是自愿的，被逼着学的。

学代码能够锻炼你的动手能力和逻辑。其次学习代码，能够帮助你更加清晰的去了解你说开展的工作的核心思想。只有了解了核心思想才能够更加清晰的知道，要去怎么做。而工具的使用，并不能让你那么清晰的去认知它的核心。就好像黑盒与白盒一样。你可以通过写代码的方法，更加深刻直接的去了解认识，而工具，则是像一个黑盒子一样，挡住了你的视线，只能通过经验的积累去试探着感知。

而且就算你用工具，你不还是一样要对脚本进行维护吗？这也是需要代码基础的。如果真的要在测试这条路上走下去，我个人觉得，始终都会走上写代码的这条路。当然，管理路线发展的同学可以无视我的这段话。

关于工具录制脚本和自己写脚本的对比。

现在很多工具都可以录制脚本，那么和自己编写脚本相比孰优孰劣呢？又将怎么选择呢？首先工具是强大的，我们不能否认，很方便也很全面。录制脚本，最多也就自己修改一点参数，方法之类的。相比较工具的录制，自己编写的脚本可能就没有那么全面，不过却是更加灵活，能够完全的按照自己想要做的东西去写，这点是工具无法比拟的。而且自己编写的脚本，在报错的时候修改起来也会很方便，因为都是自己写的，定位起来就比较快。而录制的脚本，可能就比较流程化，不够灵活，出现报错的话，解决起来可能就没有自己编写的脚本那么方便了。重点是，自己写脚本，你不觉得逼格很高吗？

说了那么多，其实无非也就是为了保证产品质量，提升工作效率。自动化也好，功能测试也好，都是为了去保证产品的质量，只是一个是代码或者工具来执行，一个是人手动执行。

自动化的使用无非就是想提升工作效率。而提升工作效率的方法，却不仅仅只有自动化一种方法，包括测试流程的改进，测试方法的改进，团队的管理等等都是提升工作效率的方法。这些咱们下回再看。

目前对于测试的认知也就这么多吧。算是我一些粗浅的看法。欢迎不同看法的朋友提出宝贵意见。

再啰嗦两句哈。现在软件测试方向很多，工具也很多。可能有些同学就会感到有些迷茫，不知道该如何选择，这个也想学，那个也想做。没错，自动化现在很火，但是它也不是那么容易做的。性能，安全也都不容易。包括功能测试也并没有我们想象的那么简单，还是有很多地方值得我们去发掘的。关于是泛还是精这个问题就不说了，每个人有每个人的选择。但是我真心建议从代码开始学。认准一个方向，坚持下去就好。贵在坚持。我现在每天晚上除非写blog或者是有事，不然都会坚持学习到12点，定期总结。越学习越发现自己的不足。只有不断的认清自己，才能不断地提高自己。

待遇都是暂时的，你技术过硬的时候，一切都会好起来的。而且，为什么人家技术大牛总是不鸟咱们？因为你没那个价值啊。古语讲，人以群分。你都没有价值，人家理你干嘛呢？可能无聊的时候也会帮你解答一下问题吧。不要羡慕别人的工资，因为人家在做事的时候，你在玩，你在做事的时候，人家还在做事，你在休息的时候，人家没准儿还在学习呢。所以还是努力吧骚年。

如果对软件测试、接口测试、自动化、性能测试、LR脚本开发、面试经验感兴趣可以关注公️号，会有不定期的发放资料链接，都是从各个技术网站搜集，具体详细内容可自行查看哦！

可拉进交流群，有大佬指点迷津你的问题往往有人遇到过。