现在遇到一些问题：
1、目前 H5 是镶嵌到 APP 上的（例如：H5 改动，之前测试通过了，但是后面因为其他问题，做了一下修改，回归问题时通过，但是之前 H5 的一些页面出现了其他问题，回归时注意了改动点，但是未覆盖到影响到的其他情况，而且回归时因为是镶嵌到 APP 的所以又出现了系统兼容的问题，目前能做的就是回归主流程，后面系统兼容也看，但是没有其他好办法，测试就两个人，上线任务较多，每次回归很浪费人力，也容易遗漏，UI 自动化成本又比较高，公司也不打算做，问问大家有没有好的办法）
2、每次发布时，发布一些功能回归了，但是发现 H5 总有遗漏的地方（例如：做了一些改动，但是影响到了另外一个页面，但是本次改动不应该涉及该页面，回归时没有覆盖到，目前做法是把那个页面记下来，下次回归的时候关注到，但是感觉有点死板，而且意义也不是很大，因为不是每次改动都会涉及那个页面）
目前一些改动点的影响开发也不是能评估到，所以有什么保证这个质量的方法么？
听楼主的说明，本质问题是 “改动点的影响开发也不是能评估到” ，即代码质量失控。本质问题不解决，你能做的只是把兜底做得更完善（比如用更多的回归用例兜底，最多加点自动化减少下人力成本），没办法真正减少工作量，而且也只会越做越累。
这类问题背后有可能是因为开发新接手不熟悉，也可能是本身架构设计不好太多共用，牵一发动全身。个人想到的几个解决方向，大方向还是测试要提高代码能力，倒逼和补充开发这个地方的短板：
1、联合开发做好 bad case 收集学习。正文里提到的这些曾经遗漏到线上的问题，都进行复盘，明确直接原因（代码改动点）和根本原因（为何会产生预期外影响但开发 + 测试都评估不到），以及制定落实优化措施（代码本身耦合度高的，提技术优化任务，进行重构优化；新人不清楚的，代码里补充好注释和写好项目代码介绍文档），持续提高这些容易出问题地方的代码质量。
2、经常出问题的部分项目，要求开干前做技术方案设计，测试参与到方案评审中。通过这个来倒逼开发做好设计方案，和评估好此方案的影响范围，思考好再开始写代码，降低风险。这个要去争取开发 leader 的支持，一般他参与评审，开发才会更认真进行设计，而且他把关质量才有保障。
3、提高自己的代码能力，去 review 开发代码，做到每一行改动都明确是在干嘛，和本次需求是否有直接关系，是否有连带影响其它位置。
是我的话可能会这样去做：
- 确保出现过的问题不会再次出现，记录 bug 清单，尽量做成自动化，工作量不算多的
- 主流程回归，同样尽量自动化吧
- 代码 review，每次测试花一点时间看开发的代码，不说每一段代码都能看懂、看出问题，至少要对整体的技术方案、影响到的页面、组件、接口等等有所了解，合理的技术方案一般代码看起来结构都是很清晰的，让人困惑的地方往往是 bug 所在的地方。