这两天，我一直在做“测试人员”，不过跟一般的测试人员不同的是，我是在写代码做测试，这些代码是我头脑中的某种设计理念的表示，我坚信，只有不断的“测试”我的这些设计，才能够找到最优的解决方案。

　　最近我在设计开发一个“wcf邮件通信系统”，目的是为了在两个不能够直接通信的环境中使用邮件作为消息通道，所以系统的关键之一就是邮件收发的效率和稳定性，怎么样才能够使得邮件内容最小？哪种格式的邮件内容处理最快？哪种方案能够消耗最小的cup资源而又占用合适的内存大小？下面是我的一个测试过程：

　　1、对象序列化测试

　　象使用xml序列化，占用的存储量太大；

　　json序列化，由于使用的是第三方类库，无法控制序列化细节，占用存储量还是比较大；

　　自定义实体类序列化器，细节由我完全控制，占用存储量最小；

　　2、数据存储格式测试

　　数据采用文本还是二进制方式存储？当然二进制存储量最小，但是文本格式可以有很高的压缩比，而且可读性好，这恰是二进制的缺点；

　　3、字符编码格式测试

　　使用gb2312，utf-8还是ascii？gb2312比较适合汉字处理，utf-8不会有国际化表示问题，ascii显然不行，它是7位字节表示的，还有没有效率更高的？这就需要测试了，最后终于找到一种编码格式：iso-8551，这是一种8位编码格式，非常适合处理二进制的字节数据。

　　4、压缩格式测试

　　使用winrar？不开源，除了问题比较麻烦，而且客户机器需要安装它；

　　使用zip 格式？开源的用过，以前好像还是发现有问题；

　　使用gzip？.net框架自己带的，相信不会有大问题，但用的少，还是需要测试；

　　5、数据编码方案测试

　　经过反复测试，发现很多邮件系统对于正文中包含大量的ascii字符有可能识别为垃圾邮件或者病毒邮件，根本无法发送邮件，所以直接使用base64格式对正文编码的方案泡汤，来看只有自己编码了，那要怎么编码才会认为是安全的？看下面的数据格式：

　　686a，0f00，0105，--双16进制格式，

　　686a0f，000105，--3字节16进制格式，

　　显然，采用3字节16进制格式能够更节省存储量，但反复测试发现，当正文长度超过100，000，opensmtp组件发送邮件很不稳定，经常无法发出，但是双16进制位格式却没有任何问题，只有这样了：-《

　　经过这些天以来不断的测试，不断的修改原有的邮件收发的设计方案，最终采用了“自定义实体类序列化+二进制数据存储+iso-8551字符编码+双16进制格式数据编码 ”的设计方案，由于对象数据本身已经是二进制了，各种压缩工具对于二进制数据几乎没有压缩效率，所以省去了“数据压缩”这个过程，最终在数据存储量、传输效率、cpu效率方面取得了最佳平衡。

　　所以，测试不仅仅是测试人员的事情，作为开发设计人员，如果要让你的成果是最优的，那么采用tdd吧，反复测试你的设计，最终找到最优的解决方案。

　　下面是附带的测试数据：

　　--------------------------

　　**新版查询结果（采用最优方案）：
　　1，查询全部雇员数据：
　　198962 字符（编码前，下同）
　　500390 字符（编码后，下同）

　　2，查询客户数据，国家 usa，
　　1957 字符
　　4222 字符

　　------------------------

　　*旧版本结果（json序列化+base64编码+数据压缩）：
　　1，查询客户数据，国家 usa，
　　8706 字符
　　6230 字符

　　2，查询全部雇员数据：
　　534022 字符
　　830348 字符