持续交付 移动端 UI 频繁改动的 app 项目，如何多、快、好、省的做好回归测试？
在业务频繁变动迭代的产品团队中，尤其是移动端 UI 交互经常变化，核心业务大都承载在移动 app（类游戏系列）时，如何做好回归测试，缩短测试周期，实现快速交付呢？大家有没有好的策略与手段，如何平衡时间、成本、质量的合一化？
看到培训机构软文，看起来标题吸引人，不知道有没有落地，实施效果如何？
《智能遍历测试在回归测试与健壮性测试的应用》
文不对题，发个广告软文都不专业
管理员能不能把这种帖子删了。
好吧，首先楼主估计就是来打广告的……
看到帖子里提及 Fastbot 工具，确实好用，平时跟 Fastbot 团队同学往来十分密切，有多次出差约饭的经历，在 app 稳定性测试上，Fastbot 应该是市面公开最好用的工具之一了吧。不过外部公开的是超级阉割版，内部还有各种多机遍历、用户模拟、定向测试等高级特性，很多都是跟 Fastbot 服务端有直接通信的，算法模型直接放在服务端而非客户端，估计短时间也不会公开。
核心业务大都承载在移动 app（类游戏系列）时，如何做好回归测试，缩短测试周期，实现快速交付呢
不过，Fastbot 只是用来做稳定性测试，换而言之它只能断言崩溃卡死问题（如果 app 本身接了 apm 那就更好），无法识别 UI 层面甚至白屏黑屏的问题。
这种这么范的问题，妄想通过加一个工具就能解决，第一个还是先从流程上解决沟通效率问题，流程顺了各自分工明确了效率就会高起来。
UI 自动化用来做回归测试，绝大多数就是一个谎言，现阶段大多数公司甚至大厂，UI 自动化本质上只是一个定向遍历的驱动器。除了少量的核心 case 能用 UI 自动化做最基本的检测外（往往这种检测的断言还很粗犷，起不到效果），要想拓展 UI 自动化的应用范围和效果，其实还需要非常多配套设施，除了 UI 自动化框架本身，最核心的点是：一、降低 UI 自动化编写维护员成本；二、提高 UI 自动化断言准确性。在字节跳动内部也就是还在各种探索的阶段……
捉虫子的小强
回复
楼哥，说的很对，一眼就看出实践过自动化的人发出来的心酸之言，首先是二个维度，流程规范的执行到位确实能避免一些问题，但是如果没有这个段位、能力影响组织变革，那对应测试内部来说，就先做好自己，只能考虑采用技术去改变解决问题了，大家都明白，工具只是辅助人去更好的完成工作，都要在时间、成本、质量做到平衡的。
捉虫子的小强
回复
如果发帖目的是想解决实际问题，建议分享下你的实践经验和思考吧，这样才能真的帮助的大家。
只是发各种不同文章的链接，也没有你自己的思考（比如你觉得里面哪部分说得有道理，哪部分觉得没啥道理），对于帮助解决实际问题，真的帮助不大。而且你已经连续好几天发同类型文章了，如果有诚意想分享经验，请看看别的分享文章怎么写的，调整下你的写法把。
陈恒捷
屏蔽了此话题：想分享观点或者讨论问题，请在发帖正文直接说出你的问题和你的观点思考，不要正文只抛问题，回复发观点，阅读体验非常差。
同时想解决实际问题，请分享你的思路或者经验，外部引用应该是辅助，不应该是主体内容。
09月28日 23:03
考虑到答复里有同学回复了不错的内容，所以这个帖子暂时先不屏蔽。
也请 @ 捉虫子的小强 后续发帖前，先看看精华帖或者其它问答帖是怎么讨论的。分享观点就应该正文里写观点，提问就应该正文里写清楚上下文和想寻求帮助。现在这种正文一堆没有上下文的问题，自己的回复一味抛外部链接，帮助不了解决问题，反而阅读体验非常差。
社区不想随便屏蔽任何人花时间发出的帖子，但也希望大家讨论时保持好一种诚心学习交流的气氛。请大家一起维护好这个气氛。