TDD（测试驱动设计）：通过大量测试寻找最优解决方案

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

    最近我在设计开发一个“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 字符，