我说说我之前游戏公司流程吧 ，首先出包这个并不会需要开发的时间，当时我们出包都是自己去 jenkins 上打包就行，而且我们需要测试包包括测试服、预发布服、正式服。出包这个问题是不是可以参考我之前公司的这个方法解决，然后配置问题的话我们是有一个配置后台，在测试服跟预发布服测试是有配置权限的自己配测试的配置就行，在正式服才需要运营去配置。至于测多个包体这个问题可能我也不太了解，我们一般都是测试服、预发布会仔细测试，正式服的包只需要冒烟测试即可。

不懂就问，如果把 3，打混淆包时间太长的问题解决了，是不是能起到很大作用呢。我觉得肯定有很多提升的地方，比如多机器并发，优化脚本之类，这方面可以请教下大厂方面有经验的人。
另外就是混淆包和 dev 包有很大区别导致混淆包出现很多 bug，这个其实就有问题了吧。一般而言大概率不会出问题，即使出问题也是一些很容易就出现的 crash，如果连功能都有影响，很怀疑你们那边开发团队的能力了

看了你的描述，我觉得目前你这边能做的，就是转测前出一份冒烟用例给到开发，提高转测前的质量，以此来减少不必要的流程时间

其实说下来还是流程不清晰：
混淆版，开发版和正式版的区别： 这几个版本之间除了配置不一样， 还存在什么不同？ 你要和开发坐下来去聊， 把最重要的测试放在开发版，改 bug，重测，回归这些都按流程去走。 当开发版认为已经没问题了， 再出混淆版和正式版， 然后走个冒烟测试，以及重点关注配置的验证，比如商品配置，是否关闭 debug 等。一定要保证不同版本之间不存在业务代码的差别，不然你永远测不完。

1、打包的开关和配置，能不能写成默认配置项，打哪种包就勾选对应配置模式？
2、测试包验证通过后，生产包还是要验证一遍的。这个是避免不了的。
3、审核时出现了哪些问题呢？可以记录下来具体分析，准备一个 checklist 在提审前逐一检查勾选。

这里我们这边不能这样做，我们这边是研发出的包，研发出的可能是审核服的包体，审核服内的就给苹果审核人员看的，功能不完善，就一个小游戏差不多的界面，不用怎么测试，我们这边是基于研发给的包体，再去做修改或者混淆的，需要开发来做

我们的开发就一言难尽了，现在就剩一个 iOS 开发，我对他经手的项目，是很不放心的，出个包都有时候会漏开/关一些功能，需要重新出包，所以我还会着重注意他的项目

哎，这个可以有，我试试给到一些用例点去推动一下开发，看看能不能让他去做一下（虽然可能推不动）

目前大概就是这样的流程，出现的情况就是修修改改，bug 要改好几次，主要就是开发不太行，不自检就扔过来

其实每个公司有每个公司的情况，考虑现实的情况，每个人的建议对楼主不一定有用，不如从根本上去考虑一些问题。比如，先考虑自身方面，流程和测试效率上能否调整改善，能不能使用某些工具，简化你的测试工作等等，再比如，交接的内容，比如开发，你可以让开发怎么样去提升双方的效率，一定是要共赢的，这样开发才会觉得你这样才算是优化，才会配合，不然根本推不下去的。开发自测，测试左移，流程简化...等等，结合业务和项目组的实际情况来考虑改善吧

是的，楼上说的建议我都有思考的，我也试过从自身方面出发，去写一些小工具脚本去提高效率，但是涉及到 iOS 的开发就不行了，私底下跟开发沟通了，他的意思就是 “混日子，躺平，不愿意多做事，不关自己事的就推出去，觉得是别的开发上的 bug，也不去对接解决问题，就甩出去算了”，大家都是打工的，在没有犯错的情况下，这样子我也没办法要求做什么事

一个项目测试完成后， 出一份详细的测试报告， 测试报告重点包含 发现多少 bug，哪些 bug 比较严重且不应该出现，测试了多少版本。然后抄送给对应的领导， 通过版本质量来 push 研发提供质量或者整个研发流程

买一台 mac pro 用来打包，速度提升飞快，亲测