公司业务数据量以及规则都很多，权限控制也很繁琐。昨天遇到一个问题是由于商品基础数据配置少了一个字段导致的问题，大致排查出来就是因为商品单位为空导致价格没有计算出来。所以想问一下测试需要对所有的业务数据负责吗？如果要那高权限的管理员修改后怎么确定基础数据是否正确？
换个思路看，其实也算配置规则的测试没考虑完全。
是要负责的。修改者要根据业务规则修改就能保证基础数据正确。
个人理解，测试没办法对所有业务人员的配置正确性负责（权限上线上业务人员权限分分钟比测试还高，测试没法把控），但需要对系统的健壮性负责，即要能尽量确保系统配置不符合业务规则时，能明确提示；对应的降级容错措施能把业务问题降到最低。
不过大部分内部配置系统规则都会比较复杂，全部做校验成本比较高，产品和开发是不愿意的。而且运营人员流动性很大，本身也不一定熟悉系统，配错漏配真的是常事，最终造成线上故障，测试肯定逃不掉要协助排查处理。所以我们内部实际落地还有一种方式，就是重要活动/配置在配置完未发布时，给测试在预发环境进行验证，确保配置正确无遗漏。既然配置容易出问题，出问题后测试都是要投入，事前投入保障没事故，比出故障后费劲排查要高效得多。
陈恒捷
回复
同意你的观点，测试协助排查是一定的这样能提高效率。但是我么经常出现这种情况，由于不同部门的人员对系统里的某一个参数进行了修改之后导致的基础数据问题。而现在的系统比较灵活（简陋吧）同一个商品计算方式也比较多所以不能定很详细的业务规则，基本上都是人工配置的。这样就导致数据今天对过一点事件可能就不对了。
Ouroboros
回复
恩，就是因为我们的计算规则和复杂，比如一个商品系统按斤计算，实际按包卖最后按吨出货商品之间的转换比较多。很难很详细定义这些规则
BigDel
回复
看出问题概率高不高，高的话就要在灵活和安全两个里面做取舍，牺牲灵活性。比如收回多部门的编辑权限变为某个部门集中设置，或者每个这种规则的变更都需要上级审核确认后才能生效（比如线上数据库变更的玩法）。
数据都不测？我们必须保证数据的正确性哇~
恒温
回复
也不是说不测，也不是没测，是很多时候其他人会进行修改，但是可能修改之后数据就错了。比如说你修改一个单位，在计算的时候单位转换错了，那么金额是不是就错了，现在系统没做纠错处理所以比较常见这种数据问题。
不管多少人会改, 改完必须测试通过才能发布
改动较多, 可通过对比前后两个版本的数据来确定所有改动, 直接检查数据
之后也需要在业务中时间检查下是否生效, 是否有问题