后台测试自动化平台开发的第一个弯路

平台开发以来，进度还是蛮快的。
最近因为项目忙，疏于管理。结果项目走样了。犯了几个错误。

1、Excel解析到TC，是一个兄弟开发的。他采用了GBK编码。因为Excel文件是GBK编码我们的系统默认的。
而且Excel很难转换到UTF8，默认的excel没有提供此功能。
我是一直推崇UTF8的。有点担心GBL，但是为了项目的统一性，我让大家修改了编码为GBK。结果麻烦就来了。
很多ruby的库都是不支持GBK的，在运行，以及使用中，遇到了GBK的很多问题。耗费了不少时间。
GBK始终是有隐患的。以后随着数据的处理复杂，以及与多系统，数据库，web进行协作的时候，这个编码也会成为隐患。

2、模块是分开开发的。有两位DEV，在开发过程中，进行了大量的扩展。这也是我的失误，之前没有让他们了解透彻。中间又没有去check他们的进度与代码。导致了功能重复，设计思路有点乱。
而且底层的两个哥们直接进行联调了，把框架架空了。
进度可喜，对整体设计不利。把其他人架空了。

3、接口之间的定义不是太清晰。导致一些关键的衔接，还需要重新去整理。


接下来的解决方法。

1、碍于excel的固有缺点，还是采用GBK去读，但是扩展一个方法，把GBK全部转换为utf8。系统还是采用utf8编码。
2、我写一个主线联通的CASE,主动去联调所有的模块。把大家的注意力拉到框架上来。
3、接口之间的定义，通过联调，最终确定下来。



一些其他方面的计划。

1、配置解析模块完全不要。为了更好的扩展，采用yaml或者xml去序列化，反序列化配置。Yaml不支持汉字，不果可以通过扩展实现支持汉字。测试已经通过了。具备可行性。
2、编写几个常用的业务。去模拟使用整个框架。
3、Project模块增加版本代码比对功能。
4、项目二期启动。



今天去听淘宝主办的《互联网测试技术交流会》，挺好的。只听了上午了演讲。很精彩。
从分享中领悟到不少新的东西，对我们的平台设计很有启发。
下午没有机会去听淘宝的测试平台框架介绍了。可惜。

我们部门的框架还需要继续完善与调整，我相信，我们部门可以做到最优秀，可以超越淘宝的那个框架。
我们可以更快的去实现他们没有实现的功能。

好多的设想，我都压着，不想把这个平台前期做的很优秀。
毕竟是集体开发的项目，先求稳，可以扩展。然后再去更好的设计。
我对设计的要求还是很苛刻的，我是个完美主义者。我的创新思维也是很活跃的。
所以我相信，我们可以做到最优秀。

我们的技术小组，也可以做到同心协力，做出最优秀的产品。