哎！没有错，技术就是这么牛逼
连拷贝代码都不用
只需要轻轻的加个开关
切换下 False/True
你就需要把所有的地方都给我验一遍

可以 这就是 自动化测试 的需求场景

没懂，就是标准化产品，然后不同客户不同环境，不同地区的版本如果都没有客户定制化的需求，那不是整理一版全量通用的测试用例合集用作功能测试，然后搞接口自动化，通过配置文件来区分 env，然后线上定时运行。

你这种就是最保险的方法就是完整测试，就怕环境变动带来的不可预知问题。接口自动化不保险、UI 自动化不值得。不知道你是不是那种 H5 的小活动，或者你可以用 airtest 快速写个交互验证的自动化

没自动化测试的基建，只能手工测试的话，就说服大家认可你分析出来的各个区域不同点和需要测试的地方，单独对不同配置做下测试就行了。不建议花时间做这么大强度的重复劳动。。。

公司只有我在本地的搭建的自动化框架，而且都是为了方便测试，自己编写的，只有两个功能测试包括我，没有分组长

目前的问题是，技术只需要开发一次，但是测试需要测试很多次，然后技术又在编写新的需求，跟不上技术的进度

按照业务经验去识别没有差异的地方，识别出来之后和研发对一遍达成共识，相同的地方只测一次，不同的地方再不同测试。不然就是把自己的时光浪费在重复测试兜底给人安心的破事上，没啥意义。要做一个聪明的测试

有问题的话。还是得测试背锅啊

搞一回多次测试，就总结一波：主要问题出在哪一块，哪些可以省略测试，哪些不能省略，然后下次按这个思路继续总结，最终形成同质化内容只测一次 + 差异化多次测试的策略啊

项目是一个流程多个分支，没办法只测试一部分流程

先用 monkey，airtest 去跑，用抓包工具搜一下域名是不是都换掉了，再手动走核心功能，基本能覆盖全

你本地有搭建，那替换下域名，几套环境弄同样的鉴权用户，然后测接口会走不通么...而且你都说了测好几遍功能测试的重复工作，我理解这种测试范围肯定是可以缩减的，根据前几轮测下来的经验

这就是观念意识层面的问题了，质量本来就是共同的，如果研发和测试在这一块达不成共识，只能说爱莫能助。