个人白盒测试的一点经验（一）

        在写代码之前，作为一个程序员，应该对自己使用的框架有比较深入的了解，包括但不限于组件注册原理、注册顺序、工作方式、底层实现逻辑以及不同框架版本对于其他组件的影响。前期工作做的充分才不会导致后期在添加功能时因为不可预知的BUG增加工作负担。

        举一个比较典型的例子就是JAVA中各类常用ORM框架各版本对于JSR310时间规范的问题，这里面的雷容易踩也容易爆。我在几年前写过一个内部员工优惠的项目，使用的框架是spring 4.2.4，ORM框架使用当时刚刚接触不久心醉神迷的JPA，JDK版本使用的JAVA8。当时看完DEMO就踌躇满志的动手了,当时我在某一个实体类中定义这么一行人畜无害的变量：

@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")
@DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss")
private LocalDateTime createTime;

        按照我配置的序列化策略，JPA框架会在数据库中创建一个实体类的表，其中必然包含着某个名为"createTime"或"create_time"的列，里面保存着时间信息，对吗？

        大概在项目正式运行几年后，由于新财年优惠策略变动，我在不久之前重新启动了这个项目，并根据过去的维护状况，在不修改原有数据的情况下，把该项目使用的框架升级成spring boot 2.X + spring boot jpa。一番修修补补技术升级之后，这个实体类中这个属性的注解变成了这个样子：

@Column(name="createTime",columnDefinition = "BLOB",nullable = false)
@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")
@DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss")
private LocalDateTime createTime;

       发现问题了吗？在版本升级后，为了与原有的数据格式进行适配，我不得不显式声明createTime列为BLOB类型。因为在项目刚刚创建的时候，我所使用的spring data jpa 1.10.X 并不支持JSR310标准下时间数据格式。而按照JPA自己的规则，除了注册的特定数据类型外，其余的成员变量统一按照Object类型进行存取，暨以BLOB的数据格式进行存取，并在读取成功后由JDK中的对象反序列化API还原成类中注册的实际变量类型。当初发现这个问题的时候我心里庆幸不已，万幸JAVA时间库里的对象都显式声明了序列化ID，否则入库字段能否正确成功还原成原始变量，能否保证存入的数据保证不丢失都成了问题。

       这问题大吗？不大，确实不影响标准业务流程。但是预期datetime变blob类型，首先造成的问题是数据库中的数据不直观观测困难，大家观察数据表看到的都是一坨二进制数据，我个人认为能肉眼把BLOB数据还原成JAVA对象的人我想这个星球上应该没几个，另外一个问题是后期在做通过createtime这个条件进行实体对象查询功能的时候，无论是JPA标准规范关键字查询入口，还是通用的Specification查询条件，都会返回无法预期的结果。

      这个问题在检查过JPA拼接后的SQL之后就很容易理解。因为JPA并不能保证Object属性（表现在数据库中的就是blob格式字段）在常用的比较运算符（比如 >  < =）中的计算结果，指望被储存为blob字段的字段在SQL查询时就进行各种比较筛选属于想太多，返回的查询结果无法预料。涉及到这类字段条件的复杂查询，需要在通过包含其他条件的SQL语句返回结果后在代码内重新进行一次筛选。至于参与分页，那就是更加复杂的问题了。

      显然，如果我当初对JAVA8新增时间API的标准了解得再深入一些，还会出现使用不带JSR310数据标准的框架的情况吗？如果我对JPA标准再熟悉一点，也不会做出在SQL语句中做出对象比较运算这种异想天开的事了。退后一万步说，如果我在测试时仔细观察了查询结果和数据库里的数据结构，早点意识到blob字段对于二次开发造成的困难，我也不用绕这么多弯子了。这对我而言是很深刻的教训。

       工欲善其事必先利其器，这只是举一个小例子说明熟练掌握工具的重要性。通读源码对普通开发人员来说耗时耗力，事倍功半，但是在使用工具前，多了解其实现过程、写些测试样例、观察运行结果并总结经验对于开发来说却是值得一做的事。至少这里花费的功夫越多，后期白盒测试绕弯路、二次开发给自己挖坑的概率也会越低，总不是一件坏事。

      顺带提一句，JPA升级同样改变了主键注解@Id中strategy属性的默认值，如果框架升级需要匹配带自增主键的表，需要显式声明:

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;

）。

最后

以上就是高兴黄蜂为你收集整理的个人白盒测试的一点经验（一）的全部内容，希望文章能够帮你解决个人白盒测试的一点经验（一）所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。