split函数引发的测试思考

上一篇 / 下一篇  2011-12-22 11:09:06 / 个人分类:经验总结

背景:首先跑程序失败,原因是非常常见的数组越界异常。可以说这个异常很普遍,但是对于运行了好久没有变过 的程序突然报这个错失败可能突然会让人觉得有种大呼why的感觉,那么最直接的猜想就是数据源和以前不一样了。事实证明的确是这样,某日数据库中not null的字段多出了两条''空字符串的记录,也就是mysql中经典的NOT NULL和空字符串的区别。

出问题的语句:split函数使用:outValue = inValue.toString().split("01")[1]。(根据^A字符进行分隔取image_url)

数据:1487994190:16041774^Ai6/65752791/T2WodbXehzXXXXXXXX_!!65752791.jpg$
正常处理。
1487994190:16041774^A$
调用上面那个函数:java.lang.ArrayIndexOutOfBoundsException(常见的数组越界异常)
原因:当作为分隔符的最后一个字段是空的时候,默认为根本就没那个字段,而不是认为是空。

eg: String s =":a:";
String test[]=s.split(":");
System.out.println(test.length);

结果:2(不是3)
如果这样调用:System.out.println(test[2]);很明显就是越界了。
处理方法:
1,进行异常处理,捕获这个异常进行处理。(已经触发了数组越界异常)
2,使用publicString[]split(Stringregex, int limit)这个函数。

String test[]=s.split(":",3);
System.out.println(test.length);
结果:3
但是这样写死在程序里面对于加字段了话不进行更改会引发数据不正确的错误,通用性不好。
3.(推荐方法,最好再加入个长度判断就更完美了)

String test[]=s.split(":",-1);

System.out.println(test.length);

结果:3

思考:
1.参加代码review做些什么:可 能在代码review的时候大家更关注在怎么实现的,实现的方法好不好,这些开发大牛们有很多想法,是从整体上看的,说实话如果之前没参加过什么设计评审 也不了解需求,功力一般的QA(例如现在的我)很难有什么有价值的建议。那我得寻找我参加review的价值啊,我想那我可以代码的某些部分敏感,提前发 现潜在问题把它们扼杀在摇篮里,比如当程序里用数组取东西的时候有没有进行长度判断,比如用迭代器的时候有没有判断hasnext,用一些容器的时候有没 有判断非空再进行处理,对于输入输出有没有进行编码转换,有没有catch异常进行处理,捕获异常进行处理可以保证程序很稳定的运行,不会因为一点脏数据 就全部失败等等,这点都是很重要的,也是需要我进行不断积累的,而且这些东西有时候并不是黑盒测试都可以发现的,而且如果在代码review的时候就提出 来kill掉对项目的整体效率来说也是很好的。
2.数据源的脏数据是否真的是程序失败与成功的理由:如 果数据源的数据基本都不对,那没什么好说的,数据源的数据基本都是错的,下游干什么都白扯。但是如果只是部分记录甚至是只有几条脏数据,程序就失败,肯定 是不值得的,这也就是考验程序的健壮性,我想最简单的就是对异常情况的捕获和处理,而在进行黑盒测试的时候是根据字段以及数据的特点进行造数据,异常情况 的数据可能想的并不够变态,那么我想直接白盒扫一下程序使用的函数有可能抛异常的是否进行了try catch处理挺好的,这也算是对黑盒的补充。
3.如果有时间的话,可以对于程序使用的函数查下api,看有米有风险存在,自己进行下评估,拿不准的可以和开发沟通。
4.日志的重要性:重 要信息存日志,错误信息更一定要记录到日志,这点当遇到问题的时候是非常重要的,给大家举个例子,假如我们的数据源有1亿的数据,有几百个part,某天 你程序遇到问题,然后你猜测是某一个part里的数据出问题了,怎么办,那么多part去一个一个找?而如果你的log很给力,记录了哪个part出问 题,出问题的part的记录是哪条,这样是不是一下子就能发现问题,觉得很爽呢。

TAG:

 

评分:0

我来说两句

Open Toolbar