【运维心得】K8S的又一个“坑”
K8S的又一个坑此“坑”非彼坑测试之殇此“坑”非彼坑这个坑字,打了引号。为什么呢?且听我慢慢道来:由于研发比较抗拒上K8S,所以这个坑可以说是研发扣给K8S的。现象是这样的:有一个手机注册的界面,在K8S部署以后,始终无法注册成功。在排除了configmap和host(外部供应商应用需要配置)这些低级错误之后。仍然无法注册成功。开发反应,之前旧的环境(传统部署)里,是可以注册的,多人围观...
此“坑”非彼坑
这个坑字,打了引号。为什么呢?且听我慢慢道来:
由于研发比较抗拒上K8S,所以这个坑可以说是研发扣给K8S的。
现象是这样的:
有一个手机注册的界面,在K8S部署以后,始终无法注册成功。在排除了configmap和host(外部供应商应用需要配置)这些低级错误之后。仍然无法注册成功。开发反应,之前旧的环境(传统部署)里,是可以注册的,多人围观证实。无奈之下,大家一起用手机号测试,经过打印容器内日志,发现问题出在外部应用返回的错误。具体来说,就是如果一个新的手机号注册,首先要进行信用评估,会取得一个字符串回来,然后进行int转换,作为用户的评级。但是由于我们测试的手机号在外部应用返回的json中,是没有信用评估的,结果int转换出错,造成注册失败。
但是,为什么旧的环境就可以注册呢?
经过查询,原来之前在旧的环境中注册的手机,都是在外部应用中有个信用评估的,所以并没有触发int转换的错误,至此,此“坑”还是开发和测试的锅炸出来的。
测试之殇
最后的解决方案就是在int转换的时候做一个判断,说起来很简单。但是为了填这个坑,5个同事查了1个小时,程序员的时间,就是这么流逝过去的。
说到底,还是没有一个完整的测试用例,大家对于测试用例的关注度,远远低于查错,其实,很多错误,都是可以用过完善的测试用例测试出来。
写下此文,为今后的排错和测试给自己提个醒吧。
更多推荐
所有评论(0)