1.基本功能开发自己测，或者使用冒烟脚本过一遍。
2.开发列一个改动点，测试根据改动点针对测试。

可以考虑使用自动化进行回归

其实我没明白， 自动化上不去，他们是怎么有胆子重构的

同意一楼，增加开发自测， 测试人员不够可以要求开发多增加单元测试，测试的重点放在集成测试上。

小公司完全是开发主导产品，和运维、测试、产品（可能都没有真正的产品）没关系。

。。。很正常，很多开发都是有 KPI 指标的，尤其还有不怕死的赶在业务最繁忙的时间整个框架升级重构的。。。
然后还有一个离奇的动机是技术总监为了跳槽之前有好的资历。。。

还有很多团队打着敏捷、快速迭代的牌子，完全不测试就往外放的

总体来说~有权力管这个事的人没时间或者没有办法读懂这些代码
然后不少设计文档写的和需求、产品设计完全没关系，没办法落实到非常细致的管理，一般也就到项目进度和一些粗的质量指标上

首先建议和产品沟通，根据业务的重要性把用例的优先级划分出来，把最关键的 I/O 点做自动化覆盖，放到持续集成去

然后根据开发的技术方案逐层往下覆盖，其中关键的业务方法和工具类要求开发必须有单元测试保障

上述的事情记得要整理出文档，给出定性和定量的指标，比如：

1. 资损表
2. 与开发确认的需要覆盖的路径、在设计文档有没有体现、对应模块责任人是谁
3. 定期汇报覆盖率和单元测试覆盖场景抽查的结果
4. 重构的改动量和需求改动量的比较

以上，如果不能直接汇报给老板，最起码要汇报给 HR 或者和绩效相关的部门
如果遇到技术上层管理不执行的情况，至少会有人帮你推动