有收获

产品、UI、开发人员的共同点是需求相关的东西，可以讲一讲需求流程管理的重要性

这种情况属于别人的代码看少了，多看看 github 上别人的项目

期待大佬分享分享第一点的一些细节

不至于，找个 Unity 教程学一下呗，或者直接看官方文档

开这么多线程，本身就有很多时间片的开销了吧

期待（下）的高见

我有个想法，写一个插件统计 drawcall 然后绘制成曲线，把这个加入到性能测试报告里面去，但是不太确定这个曲线对于性能分析的意义有多大

大佬，关于 drawcall 的统计，你是怎么处理场景是否静态合批 (Static Batching) 对于 drawcall 的影响的呢

respect，我 17 年毕业入行，感觉很多东西都还搞不清楚

这种情况建议写一个异常处理返回应用主界面，所有用例都从应用主界面开始就会好很多，把步骤解耦出来

游戏这种非 android 原生控件，需要用到图像识别

讲的不错，其中关于 UI 和接口的结合使用，我最近也在思考。感觉用好了应该很有作用。
关于图像识别的部分，我提个建议，跟元素封装类似，把图片也封装。然后跟项目组使用的图片同名，通过 git 同步更新。意思就是说美术上传了图片后，执行机更新 git 时，顺便把 UI 自动化使用的图片也同步维护了。

关于你说的无脑回归，我想试着解释下。看下面的公式：

自动化维护脚本的时间成本/自动化运行次数=单次运行分摊的维护成本

自动化用例写好，单纯执行时是没有成本的对不对？
那么每当有项目中的任意资源变动一次（配置，代码，美术资源等等所有资源），执行一次自动化，是不是就可以减小单次运行分摊的维护成本。
只要项目内容有变动，就至少运行一次在我看来是合理的。

受教，感谢！

结论虽然没错，但是前面的推导过程根本就不构成因果关系，就好像说 “因为美国是 ZB 主义，所以 TW 会回归一样”

找开发帮忙在 loading 函数前后插个时间日志，输出到日志文件里面去

https://testerhome.com/topics/29843

感觉你们做的配置表检查，各有各的优点，确实学到不少东西。respect!

不敢当，大家互相学习，互相进步，一起推动游戏测试行业的发展

。。。描述缺乏必要信息

good job

不是刚成立的，之前的哥们离职了。
地位是要看成果的，目前协议测试已经落地投产，并且有稳定的产出。
还有一个前人写的内核自动化也在稳定运行和产出
我手上马上搞完的协议自动化也要投入使用了，目前已经发现 BUG 了。

有用肯定是有用的。
我个人是觉得是有性价比的，当然也要看落地做的怎么样，如果不用心，敷衍了事那就不行

今天自动化发现了一个策划配置 BUG，据测试同学说，这个 BUG 靠人工发现的难度很高