记一个比较有趣的缺陷

经由协同的处理过后数据包在监狱的数据填报系统解压失败问题

缺陷描述：

在西藏减刑假释项目现场联调过程中，经由协同处理过后发送给监狱数据填报业务系统的数据包解压失败。

缺陷排查过程：

1、查看协同处理数据包的过程中有误问题，数据包流转过程阶段的压缩打包操作有无报错（无报错）

2、将协同生成给监狱业务系统的数据包下载下来，检查有无问题

a、用现场的电脑直接打开压缩包看有无问题：当时现在环境的PC用的是压缩软件是winRAR,结果用该软件打开协同产生的所有数据包都有问题（解压失败），可把我吓坏了，难道经过协同压缩打包的数据包都有问题，之前都没有发现？

b、将协同压缩打包的数据包换台PC解压无问题，现场运维人员告知刚刚那台PC的软件有点问题，经过验证确实如此。但是监狱的数据填报解压失败问题还是没有得到解决，监狱开发人员将数据包拿到本地结合代码排查，我则将数据包发回成研团队排查产生的数据包是否有问题

c、监狱开发得到的结果：当协同生成的数据包一进入程序的解压部分的代码就报错...但是代码应该没有问题才对。

d、成研团队反馈结果：协同压缩打包的数据包没有问题

3、于是思考是不是有可能协同打包使用编码或代码和监狱解压使用的编码或代码不一致导致的呢？带着这样的疑问询问了成研的开发大佬们，大佬们表示应该不是这个问题，协同就是普通的压缩方式，uit-8编码（普通的...）。排查过程再次陷入困境...

4、监狱的同事，同样也很困惑，数据包没有问题，但是通过业务系统解压，一进入方法就报错（解压部分的代码），但是把该数据包打开一次，然后再由业务系统解压就是正常的。由于我拿不到协同压缩那部分的代码，所以我建议把监狱解压这部分的代码给我，我发回成研让开发们看看。

5、代码发回去过后不久，经过排查总算找到了问题所在，确实协同生成的压缩包没有问题，监狱那边的代码也没有问题，但是二者相遇就有问题了：协同压缩解压部分的代码使用的Apache的库（当时是考虑到jdk自带的zipfile库对大文件解压压缩不友好）而监狱这边使用的是jdk自带的zipfile库，jdk自带的zipfile不支持解压Apache库压缩出来的数据包。至此真想大白，其实我们在现场排查时也有考虑到是不是这个原因，但是被否定了，因为我不懂代码，不能拿出协同这部分的代码来排查，只能通过现象排查，最后还是求助了成研的开发大佬们。

缺陷的修改：

由于我能改不了代码，所以这部分坑先让监狱的同事填了，解压部分的代码换成Apache的库。然后协同规划下个版本做出优化，并在发布时说明关于数据包压缩解压这部分存在的风险。

缺陷的总结：

1、问题的根源：该缺陷说大不大，但是遇到时又挺棘手的，最恐怖的是，在一般的测试过程中发现不了该缺陷。该缺陷是由于程序在设计时没有考虑到与业务系统对接时通过功能部分兼容的问题。（仅对于这个缺陷确实太难考虑到了）。但是有了这次的经验，以后就可以做的更好了...

2、反思：其实在现场联调之前，还经过了公司联调。但是在公司联调的过程中并没有发现该缺陷，原因是由于公司联调时我们用的不是同一份组织机构所以数据包的流转过程中有部分是手动完成的，在协同的生成数据包发给监狱后，监狱同事需要修改数据包的分布内容（主要是组织机构部分），再由业务系统解压入库。修改数据包的过程就相当于重新压缩了数据包，所以当时没有暴露该问题。所以以后公司内部联调时，需要做到尽量程序化，这样才可以暴露更多的问题，确保现场部署的过程中不出现纰漏。

3、启发：

a、这缺陷的产生说明了产品在我们测试发覆盖范围外还可能有着许多这样类似的缺陷，后续的测试过程可能需要考虑的更全面一点，保证覆盖覆盖范围（怎样做到？只得思考！）。

b、还好在现场及时的排查出了问题所在，这样归结于我们排查过程中的共同思考，没有直接把问题归结于监狱的或者协同的，另一方就置之不顾那么这个问题可能得不到迅速的解决。