问答 | App自动化测试是否有必要？

最近，身边有一位小伙伴提出一个问题：

公司自己的App在做自动化测试的时候遇到如下问题：

1.自动化测试只能由后端人员来写脚本，因为公司的测试人员没有这个技能。

2.没有设计合理的测试用例，只能通过用户行为驱动去覆盖app的功能。

3.在上线新功能的时候，测试人员已经把所有的功能都测试完了，自动化测试方面都还没有进行或者进展很慢，跟不上发版计划。

4.在实际使用过程中，很容易出现一些异常情况，例如：单个测试用例运行毫无问题，一旦串行多个测试用例或多或少的会出现一些异常现象。该怎么来规避？

作为一个后端开发刚开始兼职做自动化测试感觉很迷茫。各位大佬有什么建议~

观点一

如果只是根据自身的问题来讨论事情是否有必要，就等同于给自己找一个不去做这件事的理由。

同样的，我们也可以给单元测试，接口测试，甚至测试这个事情找到同样多的理由。但是 “测试是否有必要？” 这个问题相信你也有显而易见的答案吧？

所以还不如多花点时间去想怎么解决你的问题吧，或者如果你自己想不通为什么一个后端开发要来做自动化测试，要不和你领导聊一下，让他另请高明，你专心做开发？

吐槽归吐槽，尝试给你一些建议：

1.自动化测试只能由后端人员来写脚本，因为公司的测试人员没有这个技能。

这是一个很奇怪的理由，后端人员也没有 APP 自动化测试的技能啊，为什么就只能由后端人员来写呢？没有对口技能的人员，要么从外面招一些进来，要么从内部挖掘可以转型的资源（或许你老板就是考虑到后端人员有对应的开发背景，上手自动化测试更快）。但即使是这样，也不能定义成后端人员在写自动化测试，而是后端人员转型或者学多一个技能兼职自动化测试。这样想是不是就没那么奇怪了？

2.没有设计合理的测试用例，只能通过用户行为驱动去覆盖app的功能。

这是需要整个团队考量的，自动化测试怎么和回归测试相结合。通常的做法是从回归用例里面提取和整合出来需要的自动化测试用例去实施。

而你后面提到的用户行为驱动，是怀疑自动化测试能不能覆盖后端所有逻辑？如果是这样，应该是要分层测试结合起来去做的，单元测试，接口测试加UI自动化测试。

3.在上线新功能的时候，测试人员已经把所有的功能都测试完了，自动化测试方面都还没有进行或者进展很慢，跟不上发版计划。

自动化测试一般我们理解有两种模式：

第一种：以回归测试为目的。你的每个新功能不是上线之后就不需要再测试的，每次发版，功能变更，甚至只是服务器做个操作系统升级，都需要进行回归测试。所以这种需要频繁执行的测试用自动化测试去覆盖是理论上可以最大程度节省人力的。

第二种：与开发同步的自动化测试。需求文档确定下来之后，开发根据设计去写代码，其实测试也可以同步去写自动化测试用例（只是没办法马上联调）。当开发交付之后，只需要把对应的locator补充上去就可以执行（甚至如果这个locator已经在设计阶段定义好了，则可以无缝开始测试）。至于你说跟不上开发发版计划，这是和你们的人力投入有关的。要达到什么目的，才能去看需要补充投入多少人力；如果人力是没办法补充的 那整个事情也就无从说起了。

4.在实际使用过程中，很容易出现一些异常情况，例如：单个测试用例运行毫无问题，一旦串行多个测试用例或多或少的会出现一些异常现象。该怎么来规避？

这些都是自动化测试框架需要考虑的因素，而且业界已经有很多最佳实践的分享。还是得多投入点时间去看怎么优化。

观点二

针对你的几个问题我的理解是：

针对第二点：依据用户行为覆盖功能也算是一种场景测试方法吧，这个也算合理呀

针对第三点：这个是指脚本还没运行还是脚本还没开发完成呢

针对第四点：异常现象是指的是脚本出错还是程序出错呢？脚本出错的话就要具体原因具体解决；程序出错的话，是不是说明出现BUG了呢

观点三

首先指出你对自动化的错误理解，当然这可能是因为你是开发，不了解测试的一些东西也算正常：

1.针对第三点，你说发版前业务测试人员已经测完了，自己还没开发完用例，这是典型的想把自动化当功能测试用的思维，测试界认为，UI 自动化是针对已经成熟的业务，稳定的业务（已经发版且稳定运行的业务），用来回归节省时间 替代人工重复劳动，测试人员不愿做的回归工作，你这上来就想把自动化用来还未发版的业务，是错误认知。建议以后不要往这方面做，要遵循测试行业已经流行的做法。

2.针对第二点，没有合理的用例：找业务测试人员，与产品，让他们评估你们业务的主流程 核心历程，这些就是 UI 自动化需要首先覆盖的点，让他们一起确定好哪些用例合理，让领导排班就，你只负责编码 自动化体系的稳定的运行。这样也可以甩锅。

3.针对第四点：全流程业务的异常，这个很正常，自动化出现不稳定很正常，这也是面试中面试官为何要考察一些异常问题处理的原因，也是区分一个初级自动化与一个高级自动化工程师的间隔所在。一套稳定的自动化体系，需要自动化工程师对自己的架构 细节 原理深刻的认识，以及丰富的经验积累，你作为一个开发，十有八九是自学的，而且自己大部分时间是在开发后端，时间发在自动化上少也正常，所以出现自动化频频报错 不能稳定运行 不能合理处理也很正常，如果你想解决问题，有两个方法，一是你重新系统学习 UI 自动化，借鉴他人经验，以及多花时间调试 运行积累经验。二是让公司招一个成熟的自动化工程师。

总之，感觉你司是个小公司，不太规范，提出让做自动化的这个领导也没有对 APP 自动化有正确的了解，你再思考思考，该如何摆明事实，与领导沟通，改变其认知，达到一个合理的结果。

观点四

如果目前只能你做自动化的情况下，我个人的一些建议：

1.用例让测试提供，至于测试覆盖率要怎么提高也应该由他们去复盘想办法，你只需要评估他们的用例哪些是可以自动化的，然后实现这些场景；

2.自动化主要不是用来找bug的，而是保证迭代过程中各个基本功能可以正常运行，而且自动化是一个长期的过程，是针对不经常变更，稳定的功能模块来做的，所以肯定是赶不上迭代速度的；

3.可以带着测试一起做，让他们慢慢熟悉，并接手自动化，其实框架搭建好了，写自动化脚本很容易上手的，我的一个同事，以前没有任何代码基础，后来跟着团队用python写UI自动化脚本，写了一年 了，还是只懂基础的python知识，但是别人只写脚本，依葫芦画瓢，也是能胜任的，实在搞不定的找team大佬指点下就好。

观点五

其他几个答案，前面大佬都有很好的方案了，针对第四条，我说一下我的经验吧。

1.增加case重试次数；

2.引入allure测试报告，在初期给每一个点击都加上标识；

3.加入显示等待，确保load消失在继续往下操作；

4.采用链式调用，每条case开始前都做一下初始化，确定之前的操作不影响该条case的使用；

5.不是每条case都适合自动化，可以拆解用例，或者直接舍弃。

其他观点

如果业务测的测试人员没有能力去写自动化测试脚本的话，是否可以考虑引入第三方可视化平台？不需要写脚本的那种，就可以由业务测的测试进行编写和日常维护，毕竟他们做功能测试对业务很熟悉，也方便维护；至于维护跟不上发版速度的问题，自动化是针对已经稳定的业务的，本来就不应该包含新发版的业务，不需要紧跟版本迭代啊。

作为一个做自动化测试的人来看，你的问题都是因为不够了解自动化测试导致的。测试人员没有这方面的技能，可以招，研发缺少测试相关的知识和思想，对测试了解有限，需要学， 不了解的情况下做出来的自动化肯定会差强人意。

就吐槽一句，都 2023 年了，居然还有软件测试行业从业者，不会编写代码来实现基本的自动化测试，这个行业到底是怎么了？

快速迭代和频繁需求变更就不推荐做自动化测试了，而且这没有明确自动化测试的目的。自动化测试主要做的是回归测试。如果想跟着迭代不断新增自动化测试脚本和用例，没有专职的自动化测试工程师来支撑是很难完成。最后不要盲目推崇自动化测试。

最后： 为了回馈铁杆粉丝们，我给大家整理了完整的软件测试视频学习教程，朋友们 如果需要可以自行免费领取 【保证100%免费】

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。