公司自己的 App 在做自动化测试的时候遇到如下问题：
1.自动化测试只能有后端人员来写脚本，因为公司的测试人员没有这个技能。
2.没有设计合理的测试用例，只能通过用户行为驱动去覆盖 app 的功能。
3.在上线新功能的时候，测试人员已经把所有的功能都测试完了，自动化测试方面都还没有进行或者进展很慢，跟不上发版计划。
4.在实际使用过程中，很容易出现一些异常情况，例如：单个测试用例运行毫无问题，一旦串行多个测试用例或多或少的会出现一些异常现象。 该怎么来规避？
作为一个后端开发刚开始兼职做自动化测试感觉很迷茫。各位大佬有什么建议~
如果只是根据自身的问题来讨论事情是否有必要，就等同于给自己找一个不去做这件事的理由。
同样的，我们也可以给单元测试，接口测试，甚至测试这个事情找到同样多的理由。但是 “测试是否有必要？” 这个问题相信你也有显而易见的答案吧？
所以还不如多花点时间去想怎么解决你的问题吧，或者如果你自己想不通为什么一个后端开发要来做自动化测试，要不和你领导聊一下，让他另请高明，你专心做开发？
吐槽归吐槽，尝试给你一些建议：
1.自动化测试只能有后端人员来写脚本，因为公司的测试人员没有这个技能。
-- 这是一个很奇怪的理由，后端人员也没有 APP 自动化测试的技能啊，为什么就只能由后端人员来写呢？ 没有对口技能的人员，要么从外面招一些进来，要么从内部挖掘可以转型的资源（或许你老板就是考虑到后端人员有对应的开发背景，上手自动化测试更快）。但即使是这样，也不能定义成后端人员在写自动化测试，而是后端人员转型或者学多一个技能兼职自动化测试。这样想是不是就没那么奇怪了？
2.没有设计合理的测试用例，只能通过用户行为驱动去覆盖 app 的功能。
-- 这是需要整个团队考量的，自动化测试怎么和回归测试相结合。通常的做法是从回归用例里面提取和整合出来需要的自动化测试用例去实施。
而你后面提到的用户行为驱动，是怀疑自动化测试能不能覆盖后端所有逻辑？如果是这样，应该是要分层测试结合起来去做的，单元测试，接口测试加 UI 自动化测试。
3.在上线新功能的时候，测试人员已经把所有的功能都测试完了，自动化测试方面都还没有进行或者进展很慢，跟不上发版计划。
-- 自动化测试一般我们理解有两种模式：
-第一种：以回归测试为目的。你的每个新功能不是上线之后就不需要再测试的，每次发版，功能变更，甚至只是服务器做个操作系统升级，都需要进行回归测试。所以这种需要频繁执行的测试用自动化测试去覆盖是理论上可以最大程度节省人力的。
- 第二种：与开发同步的自动化测试。需求文档确定下来之后，开发根据设计去写代码，其实测试也可以同步去写自动化测试用例（只是没办法马上联调）。当开发交付之后，只需要把对应的 locator 补充上去就可以执行（甚至如果这个 locator 已经在设计阶段定义好了，则可以无缝开始测试）。 至于你说跟不上开发发版计划，这是和你们的人力投入有关的。要达到什么目的，才能去看需要补充投入多少人力；如果人力是没办法补充的 那整个事情也就无从说起了。
4.在实际使用过程中，很容易出现一些异常情况，例如：单个测试用例运行毫无问题，一旦串行多个测试用例或多或少的会出现一些异常现象。 该怎么来规避？
-- 这些都是自动化测试框架需要考虑的因素，而且业界已经有很多最佳实践的分享。还是得多投入点时间去看怎么优化。
针对你的几个问题我的理解是：
2.没有设计合理的测试用例，只能通过用户行为驱动去覆盖 app 的功能。
依据用户行为覆盖功能也算是一种场景测试方法吧，这个也算合理呀
3.在上线新功能的时候，测试人员已经把所有的功能都测试完了，自动化测试方面都还没有进行或者进展很慢，跟不上发版计划。
这个是指脚本还没运行还是脚本还没开发完成呢
4.在实际使用过程中，很容易出现一些异常情况，例如：单个测试用例运行毫无问题，一旦串行多个测试用例或多或少的会出现一些异常现象。 该怎么来规避？
异常现象是指的是脚本出错还是程序出错呢？脚本出错的话就要具体原因具体解决；程序出错的话，是不是说明出现 BUG 了呢
首先指出你对自动化的错误理解，当然这可能是因为你是开发，不了解测试的一些东西也算正常：
1.针对第三点，你说发版前业务测试人员已经测完了，自己还没开发完用例，这是典型的想把自动化当功能测试用的思维，测试界认为，UI 自动化是针对已经成熟的业务，稳定的业务（已经发版且稳定运行的业务），用来回归节省时间 替代人工重复劳动，测试人员不愿做的回归工作，你这上来就想把自动化用来还未发版的业务，是错误认知。建议以后不要往这方面做，要遵循测试行业已经流行的做法。
2.针对第二点，没有合理的用例：找业务测试人员，与产品，让他们评估你们业务的主流程 核心历程，这些就是 UI 自动化需要首先覆盖的点，让他们一起确定好哪些用例合理，让领导排班就，你只负责编码 自动化体系的稳定的运行。这样也可以甩锅。
3.针对第四点：全流程业务的异常，这个很正常，自动化出现不稳定很正常，这也是面试中面试官为何要考察一些异常问题处理的原因，也是区分一个初级自动化与一个高级自动化工程师的间隔所在。一套稳定的自动化体系，需要自动化工程师对自己的架构 细节 原理深刻的认识，以及丰富的经验积累，你作为一个开发，十有八九是自学的，而且自己大部分时间是在开发后端，时间发在自动化上少也正常，所以出现自动化频频报错 不能稳定运行 不能合理处理也很正常，如果你想解决问题，有两个方法，一是你重新系统学习 UI 自动化，借鉴他人经验，以及多花时间调试 运行积累经验。二是让公司招一个成熟的自动化工程师。
总之，感觉你司是个小公司，不太规范，提出让做自动化的这个领导也没有对 APP 自动化有正确的了解，你再思考思考，该如何摆明事实，与领导沟通，改变其认知，达到一个合理的结果
当然重要，要不你看看小红书 APp 大面积启动 Crash 这个是不是 App 自动化测试没有做？
如果业务测的测试人员没有能力去写自动化测试脚本的话，是否可以考虑引入第三方可视化平台？不需要写脚本的那种，就可以由业务测的测试进行编写和日常维护，毕竟他们做功能测试对业务很熟悉，也方便维护；至于维护跟不上发版速度的问题，自动化是针对已经稳定的业务的，本来就不应该包含新发版的业务，不需要紧跟版本迭代啊。
Jerry li
回复
赞同你所说，应该着力解决问题。 就是想请教一下，目前就对于一个 app 做 ui 自动化测试应该是采用什么样的技术方案呢？我现在就是使用的 appium + python 脚本
作为一个做自动化测试的人来看，你的问题都是因为不够了解自动化测试导致的。
测试人员没有这方面的技能， 可以招， 研发缺少测试相关的知识和思想，对测试了解有限，需要学， 不了解的情况下做出来的自动化肯定会差强人意。
如果目前只能你做自动化的情况下，我个人的一些建议：
1.用例让测试提供，至于测试覆盖率要怎么提高也应该由他们去复盘想办法，你只需要评估他们的用例哪些是可以自动化的，然后实现这些场景；
2.自动化主要不是用来找 bug 的，而是保证迭代过程中各个基本功能可以正常运行，而且自动化是一个长期的过程，是针对不经常变更，稳定的功能模块来做的，所以肯定是赶不上迭代速度的；
3.可以带着测试一起做，让他们慢慢熟悉，并接手自动化，其实框架搭建好了，写自动化脚本很容易上手的，我的一个同事，以前没有任何代码基础，后来跟着团队用 python 写 UI 自动化脚本，写了一年 了，还是只懂基础的 python 知识，但是别人只写脚本，依葫芦画瓢，也是能胜任的，实在搞不定的找 team 大佬指点下就好了。。。。
1.自动化测试只能有后端人员来写脚本，因为公司的测试人员没有这个技能。
---- 我是后端开发，又不是测试，为啥要我来写 ？
2.没有设计合理的测试用例，只能通过用户行为驱动去覆盖 app 的功能。
---- 我不会测试设计，怎么办 ？
3.在上线新功能的时候，测试人员已经把所有的功能都测试完了，自动化测试方面都还没有进行或者进展很慢，跟不上发版计划。
---- 好像来不及自动化，版本就要上线了，自动化了个寂寞。
4.在实际使用过程中，很容易出现一些异常情况，例如：单个测试用例运行毫无问题，一旦串行多个测试用例或多或少的会出现一些异常现象。 该怎么来规避？
---- 这他么自动化有这么多坑，咋填 ？
大概翻译了一下你的迷茫，翻译错了的话，切勿对号入座！！！解决方案：
1、怒吼老板：尼玛是舍不得花钱请自动化专业人才吗 ？让老子一个后端来顶。滚！要不就自己滚！很显然，开发经理对于自己的重臣，是不会抛出去接这个锅的。被抛出去的，肯定不是领导的心腹。
2、环境太差，舍不得滚，怎么办 ？硬着头皮上，恭喜你成功从后端开发转型成为测试开发！新任自动化测试经理一枚 
如果你真的只想往开发方向深入，这种公司建议尽早离开吧。
其他几个答案，前面大佬都有很好的方案了，针对第四条，我说一下我的经验吧。
1，增加 case 重试次数
2，引入 allure 测试报告，在初期给每一个点击都加上标识
3，加入显示等待，确保 load 消失在继续往下操作
4，采用链式调用，每条 case 开始前都做一下初始化，确定之前的操作不影响该条 case 的使用
5，不是每条 case 都适合自动化，可以拆解用例，或者直接舍弃
就吐槽一句，都 2023 年了，居然还有软件测试行业从业者，不会编写代码来实现基本的自动化测试，这个行业到底是怎么了？
快速迭代和频繁需求变更就不推荐做自动化测试了，而且这没有明确自动化测试的目的。自动化测试主要做的是回归测试。如果想跟着迭代不断新增自动化测试脚本和用例，没有专职的自动化测试工程师来支撑是很难完成。最后不要盲目推崇自动化测试。
如果想跟着迭代'走的，最好是做接口自动化测试，而不是 UI 自动化
- 只有后端人员写测试用例？你们那没测试么？实在不行就用关键字框架，以 excel 的形式驱动啊，测试人员不懂代码 excel 总会写吧
- 没有成熟的自动化用例？自动化用例都是从功能转化的，难道你们不做功能测试？
- 自动化测试难道不是在测试阶段进行的？手工都测完了还去跑自动化有什么意义？
- 异常，按你的描述，猜想是页面的切换导致的问题，比如说渲染过程中异常，加载过程中异常，在框架里加入异常报告截图啊，多分析一下就能找到具体原因了。
至于有没有必要做，看能不能提高能效，减少错误率啊，总之就是一点，不要为了做自动化而做，而是为了降低时间成本，减少错误率去做
