严格来说防错设计一般不是软件测试的范畴，但是测试久了就会发现，如果软件在设计之初就设计的比较清晰明了，一些bug压根儿不会出现，也就不需要进行测试了。
下面举一个栗子：
广告投放业务：
目标：投放的链接在一家媒体进行投放，统计每日的曝光量。
具体实现： 每次广告曝光会调用一次我们的上报的接口，每调用一次就会将当天的曝光数据量进行+1，等到第二天需重新进行计算。
设计：由于仅仅是统计曝光的数值，最初的设计是这样的：
-
由于仅统计曝光数据，没有用到其他关系数据的计算，技术人员采用了redis来进行数据的存储
-
由于有第二天需重新开始计算的需求。技术人员通过设置redis key比如为count_A 不变，在每次累加赋值的时候，计算当天的剩余时间，然后不断修改redis的失效时间为每次赋值后的剩余时间，这样取数据的时候，只要读该count_A的值就好了。
3.项目上线后，很久没有出现问题。
直到某一天凌晨5点出现线上告警(远远超出前七天的均值)，（阈值假定200W）。
结合经验来看，由于凌晨~八点是业务低峰，且无新增大量投放，猜测极有可能是数据统计出现了问题。
经排查后技术人员的设计存在问题：当接近凌晨的时候，如果有大量的数据进来，且设置过期的时间的时候存在耗时：当赋值完成，设置过期时间的时候，时间跨过零点，当前的redis数据的过期时间就几乎变成了一天。即把昨天的数据累加到了今天，进而出现了数据量超出设计阈值的情况。
改进措施：redis的key设置每天是单独的一个值，过期时间可以设置的长一些，在读取得时候，仅读取当天的值即可。
总结反思： 当一个程序设计方案比较复杂，让人难以理解的时候，也就是很多概率会出现问题的时候。自己需要多去参与开发的计数方案评审，多去研读开发的代码，多去问几个为什么要这么设计？ 争取在项目早期发现此类问题。
对于一般的业务测试人员，如果没有对技术方案认真的去思考，且未验证凌晨的边界值，也是很难发现这个问题的。
测试人员的要求：
- 关注设计，当对设计存疑的时候多提出几个为什么
- 相关技术栈要丰富起来，redis，mq等技术深度要加强。
开发人员的要求：
- 好的设计很重要，在设计技术方案时要仔细推敲（防错设计）。
网友评论