后台自动化测试框架设计初步设想

最近正在为部门设计后台自动化测试框架。
以前，其他部门的同事已经搞好了一个框架，写的蛮好的。
当时因为自己业务基础太差，担心会沉溺于代码，所以就没有放功夫上去。
现在终于可以有能力与信心去做了。


之前的框架有一些小瑕龇
1、配置解析比较臃肿
2、脚本散乱，没有采用函数的形式，也没有一个完善的管理框架，管理麻烦，而且导致无法很好复用。
3、模块化不够，使用一些自动化操作不方便。耦合严重，不利于通用。
4、运行TC太慢。多设计一些并发可能效果会更好些。很多TC是可以并发的。



本次的初步设计如下

1、TC管理模块，尽量和之前的框架一致。减少重复劳动，也有利于以后的交流。
2、对部门功能进行脚本的函数化，并纳入到函数库中进行统一管理。这部分脚本，同时可以为其他部门服务。
3、无人值守。定期监控svn。一旦有代码变更，立即回归测试。
4、把内存泄漏测试，代码覆盖率检测，c++代码静态测试，性能测试，以及代码性能监控测试全部纳入到平台中去。
5、引入场景机制，可以实现多进程无不干扰的运行。
6、模块化设计，让其他部门也可以借用其中的功能。
7、配置部分重新设计，是个难点。如何更人性化的去配置，更容易让人使用是个难点。初步计划使用yaml来代替xml。这样会更简练。
8、TC编写简化。真想考虑采用DSL去搞个自己的部门语言去实现。不过还是easy下，使用一般的方法去调用吧。
9、数据构造分割为单独的部分，构造数据有必要深挖下。
10、结果解析要更加简便。借鉴xwaitr结构。
11、整体结构借鉴微软的那套自动化测试框架结构。


前期整理需求，设计不幻想这么多。
下两个周就要好好的画设计图了。


几条纪律要牢记

1、项目流程要规范
2、进度安排要合理
3、需求，设计文档要齐备
4、不要另立山头，要多请教别人，尽量统一
5、里程碑要把握好。

最大的问题，是时间。大家都有项目，而且项目也很多，不能全身心的投入势必会影响进度的。
只能挤时间了。
最近沉默了很多，时间与精力不够，少管闲事，明哲保身暂时成为了座右铭。