自动化框架！自动化框架！自动化框架
这个版块名叫“自动化框架”，但是进来后却发现基本没有框架方面讨论的内容而自己目前在准备一个自动化框架的搭建（目前主要是GUI部分的自动化），有好几个关于框架上的问题，还麻烦大家来讨论一下，也算-抛砖引玉吧^_^
1-文件的管理存储方式，B/S架构，并行执行，基线管理，权限设置，备份机制等，请问用哪种配置管理工具比较合适呢？clearcase可以吗？
2-GUI文件的粒度划分，管理；函数，过程的粒度划分，管理？
3-代码重用：涉及到函数接口的规划，最小功能函数需要小到什么程度呢？又大约能够保证多少的重用度呢？
4-代码效验机制：业界有没有比较成熟的TSL语言评估和检查的checkpoint呢？
5-用例管理：手工用例和自动化用例需要分开到什么程度呢？如果合在一起，使用标记实现两者的区分可以吗？
6-整个架构是如何驱动的呢？即GUI测试工具+用例管理工具+被测软件三者的驱动，我计划是用tcl进行驱动。
7-架构的可扩展性问题，如果以后继续扩展性能测试工具，其他GUI测试工具，需要现在就预留做哪些工作呢？
一口气问了这么多问题，还望各位不吝解答了
谢谢！^_^ 1. Either CVS or ClearCase can do.
2. Component based.
3. It depends, I recommend "action-driven" framework to maximize the reusability.
4. Google "CheckStyle" eclipse plug-in.
5. Use Test Manager to assoicate a manual tc and an automated tc with a tc artifact.
6. Drive it from Test Manager.
7. Dont worry about it until you face it, you can write some adapters to make it. 楼主的问题我也比较关注，你的第一个问题我到不考虑，其他问题我也想了解在别的公司是怎么考虑的，希望在自动化测试做得比较成熟的同行能介绍一些经验。
参考答案
1. [配置管理]用过Perforce、CVS、ClearCase和VSS；推荐Perforce，价格公道，量也足。2. [粒度划分]我们测试小组的划分是（某某某1 - 提交、某某某2 - 审查、某某某3 - 发布、某某某4 - 回顾）
3. [代码重用]以角色进行（连长吃排长、营长吃连长，等等），以基本功能点（基础１－左转，可以衍生左转、左转、再左转的功能点）
4. [效验机制]Google
5. [用例管理]个人认为自动化用例本来源于手动测试用例，只是选择不同的执行方法，加标记表示是否被自动化则可。
6. [框架驱动]你有多少钱、多少人、大牛比例？
7. [可扩展性]你的测试周期是多少？长期的话，不要把框架套在一个或者几个工具上，可以试试以角色和角色行为来规范。短的话就先别想了。 感谢各位热心的解答
说一下自己的情况先
这个自动化框架的搭建是为了提高我们测试的效率，感觉现在测试组已经到了一个瓶颈，急需用自动化手段来提高效率，GUI自动化测试是尝试性的第一步，以后会扩充进性能测试，协议测试，白盒测试等（所以这也是我为什么关心可扩展性的原因）
这个自动化框架计划使用的时间至少为2，3年，可以投入人力大概为6，7人四个月时间，都是较有经验的测试工程师
周边有较为充足的测试工具支持力量，包括tcl支持，测试平台支持。领导也是重视和支持的。
现在看一下最开始的问题，大多数都得到了比较满意的答复，目前有疑问的是2，3两个问题（其实两个问题可以归结为1个）
在我的构想中，这个自动化框架将是一个比较宏伟的东西，首先是将整个自动化构架分为4层
-------------------------------------------------------------------------
1-文本层（用例的手动写作构造）
------------------------------------------------------------------------
2-文本翻译层（通过一个词法分析器，从文本中抽取关键词，构造顺序，驱动下一层）
--------------------------------------------------------------------------
3-用例组合层（通过第二层传下来的关键词和顺序，对基础函数进行自动组合，生成执行函数）
----------------------------------------------------------------------------
4-基础函数层（函数库中涵盖最基础的各种操作函数，只需要对其进行顺序组合，就可以执行功能）
------------------------------------------------------------------------------------
目前的问题就在于这最下面的一层，要构造好这一层，有这样一个难题：
函数的通用性，GUI的通用性。这涉及到的就是函数，GUI的粒度和管理问题。粒度太大通用性和可构造性不强，而粒度太细的话又会导致管理的混乱和关联执行时需要过多考虑函数间的环境影响（则可能需要构造大量的结果判别函数，使工作量大大加剧）。
ls朋友的2，3点解答，有一些没有看明白
第2点粒度划分和小组划分有什么联系吗？
第3点前半部分大致明白，也是前面这个可重用的思想，但是后半部分的“左转”具体是什么意思呢？
谢谢！ 期待进一步的讨论 學習中,.... 测试框架是否支持随意用例得组合测试呢?
就是项目1用到测试用例A,B,C;项目2用到测试用例B,C,D;这样得框架该怎么实现呢? en正在做类似的事经验之谈啊见识了 LZ的自动化框架里ms缺少了几点：
1.测试用例的自动化执行；
2.监控测试过程；
3.统计测试结果； 建议参考一下Ant源码
不知道楼主打算用什么语言来做，java为例
>> 1-文本层
XML很灵活，很通用
>>2-文本翻译层 --3-用例组合层--4-基础函数层
解析xml，根据tag，反射来得到类，对象，调方法，一个类就是一个组件
.
支持楼上的观点http://bbs.pep.com.cn/images/default/sigline.gif
走自己的路!!斗地主拖拉机繁体字金山杀毒免费杀毒软件 -------------------------------------------------------------------------
1-文本层（用例的手动写作构造）
------------------------------------------------------------------------
2-文本翻译层（通过一个词法分析器，从文本中抽取关键词，构造顺序，驱动下一层）
--------------------------------------------------------------------------
3-用例组合层（通过第二层传下来的关键词和顺序，对基础函数进行自动组合，生成执行函数）
----------------------------------------------------------------------------
4-基础函数层（函数库中涵盖最基础的各种操作函数，只需要对其进行顺序组合，就可以执行功能）
------------------------------------------------------------------------------------
我们打算
第一层 配置层 貌似就是你的第一层吧 主要是描述本次测试需要测试那些测试用例
第二层 测试执行层 解析配置层的配置文件，按配置文件中的顺序执行测试用例
第三层 数据层 测试用例的执行中需要用到的测试数据 比如输入、预期输入＝＝
还有一些七七八八的如log、报告等等 不晓得应该如何分层
页:
[1]
