这两天，我一直在做“测试人员”，不过跟一般的测试人员不同的是，我是在写代码做测试，这些代码是我头脑中的某种设计理念的表示，我坚信，只有不断的“测试”我的这些设计，才能够找到最优的解决方案。
最近我在设计开发一个“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 字符，