由于每个系统的差别都非常大，用自己公司的产品举例别人不一定能理解，所以还是用一个流行的例子，一个最简单的erp系统，有新建账号，登陆，浏览消息等最基本的功能，我们来关注它的新建账号功能。
按照我现在实际运用的想法，脚本会分成两类，一种对功能验证，一种对业务逻辑验证。
脚本A 登陆
脚本B 浏览新建账号页面，对每个必填条件，输入格式，唯一性，提示信息进行验证
脚本C 退出
对别的模块也这样做，然后就可以在tm里组织起一整套单独模块的功能验证脚本。

脚本A 登陆
脚本B 新建一个设定账号
脚本C 退出
脚本D 用新建账号登陆
脚本E 浏览自己收到的消息（这里没考虑权限的问题，实际上的业务逻辑比这复杂的多）
这个可以看做是一个基本流，由于业务流程非常复杂，需要我们划分优先级

例子不一定恰当，要表达的意思到了就行，抛砖引玉，欢迎大家说出自己的心得，我记得以前有些朋友的公司脚本设计组织是非常好的，希望能把你们的经验拿出来分享。

一直都比较关注对脚本的设计和组织，高效、可复用、模块化的脚本才算是真正有价值的自动化测试脚本。但好像现在对脚本、对测试框架的搭建的讨论和例子都很少，很希望有高手能够在这方面多多传授一些经验，共同提高大家的测试水平。

对于一个企业级应用系统，不仅要考虑业务逻辑，同时也要考虑脚本的可重用性以及脚本的维护量。
我使用ROBOT编写脚本的思路是：
1、设定全局变量；
2、提取功能的共性做成LIB文件。
3、Script脚本尽量只包含LIB文件里的过程函数。
4、基本流和备选流要尽量分开编写。因为一般版本发布或回归测试时，只需运行基本流脚本。
5、编写脚本时尽量考虑脚本的可扩展性，避免需求变更引起脚本的改动量过大。

1，2，4肯定是会有的，楼上对5能详细说说？

1、设定全局变量；

不推荐使用全局变量，因为我在测试时发现修改全局变量后，不会自动编译，执行时还是会使用修改前的值
除非修改使用全局变量的脚本（这样再次执行时会重新编译一遍）后才能使用更改后的全局变量

4、基本流和备选流要尽量分开编写。因为一般版本发布或回归测试时，只需运行基本流脚本。

既然是自动化了，还只运行基本流干什么？全部跑一遍也不会很费时间啊，难道怕发现bug？

我理解的脚本要想提高其可扩展性，首先要考虑会有哪些东西在测试过程中是易于变换的，而且变化后要求脚本也跟着变化。我想到的有两点：测试数据的变换和测试程序界面的变换。

测试程序界面变换的特点是一般只会局限在小范围内变化，比如一个对话框以内。所以应该把每一个对话框的操作独立出来，做成单独的函数（函数有参数来说明具体操作什么），其它脚本如果也使用这个对话框就不要在录制了只调用这些函数。

对于测试数据的变换，解决办法自然是把脚本改成数据驱动的。不要使用验证点，而应该使用丛数据池里读取结果和真实结果相比较自己写日志来记录测试是否成功的方法，也就是说验证点也作为测试数据放到数据池理。

把上面两条结合起来，总结出一个良好的测试框架，不但能跳高脚本的可扩展性，还可以提高编写自动化脚本的效率，当然前提是必须有一定的变成基础而且对robot足够熟悉了。

能全部跑当然最好了，但是需求这个东西变起来是很难说的，从优先级上来说肯定是先运行基本流了
可扩展性在自动化测试里是一个很头痛的问题，希望大家继续发言

最好能尽量的细化每一个功能模块，并且要编写参数化的功能函数，让每个测试组的成员方便的调用

另外，界面的变动也可以简单的改动对应该界面的功能函数，不需要修改所有的脚本，这样使脚本的重复可用性会大大的增加

如果，在例子中能写入关于第三方控件的使用问题，那就更好了，期待楼主

赞成将一部分功能包装写到组件中，这样代码维护起来会方便一些。而且robot的数据类型和有些DB中的数据类型长度定义不同，这样会造成用robot读不到不支持的数据格式而失败。如果写在第三方组件中就可以先处理一下，保证数据的正确读取和写入。希望xdjm们来补充补充，enjoy ^_^

不错,请大家继续讨论
九楼的"最好能尽量的细化每一个功能模块，并且要编写参数化的功能函数，让每个测试组的成员方便的调用"
能做到吗? 因为好多用例都有前置条件的

我们这里通常是编写一个主脚本，之后call其他子脚本并传递参数，而且尽量保证每个子脚本的初始环境与结束环境是一样的，这样后面的脚本对之前脚本就没有什么依赖，维护或替换起来也很方便。
通用功能提取出来，对变量或输入数值进行统一管理也会方便维护。

引用:

原帖由 youyun 于 2006-2-8 22:25 发表
1、设定全局变量；

不推荐使用全局变量，因为我在测试时发现修改全局变量后，不会自动编译，执行时还是会使用修改前的值
除非修改使用全局变量的脚本（这样再次执行时会重新编译一遍）后才能使用更改后的全局 ...

通常我们改了全局变量以后都要compile all一下 大概需要半个小时.....  不过我这半年里只改过一次.... 有些东西确认不会频繁改变的话 用全局变量还是不错的
另外我想说的是 脚本还应该考虑到不同的操作系统啊～

其實，我個人認為自動化測試的初期，不應該應用於單一、獨特的個案，
反而該關注能涵蓋大部份情況的個案，尤其是對於自動化程度/能力相對不足的團體。

因為，之所以要使用自動化測試的工具，就是看重了自動化測試只需要投注一份的心力，
爾後能重覆使用，能收到多份的效果。

因此，我建議要使用自動化測試的用戶，先檢視一下自己重覆性最高的個案，由這個地方下手，
往往比較能夠看到具體的成效，但至於重覆性最高的個案是啥，就得視大家的需求而定，我也沒法舉出實際的例子。

1.主控制脚本设置一些const用来控制测试的产品和需要测试的特性
2.globe.sbh定义测试框架的全局变量和const,globe.sbl定义基本的操作函数
3.每个模块维护自己的,sbh,sbl这样便于自己维护
4.批处理的应用有时会大大减少脚本的编写量
5.编写DLL用于扩展功能，如vb_DLL实现正则表达式,VC_DLL实现一些数据分析等等，这将大大加速问题的定位速度-很实用
6.编写自己的log系统
7.将于每个用例相关的测试信息，按照一定的结构保存便于判断
8.自动出一份自己的测试报告与你的log文件夹相连 （html）
9.自动填写测试报告和一些分析的图表(excal)

可以向dll封装的文件里加东西吗，命令是什么

引用:

原帖由 jinrk 于 2006-6-29 11:10 发表
不错,请大家继续讨论
九楼的"最好能尽量的细化每一个功能模块，并且要编写参数化的功能函数，让每个测试组的成员方便的调用"
能做到吗? 因为好多用例都有前置条件的

能做到，只要功能划分合理，参数设置灵活，完全可以达到

引用:

原帖由 Iolia 于 2007-6-22 23:28 发表
可以向dll封装的文件里加东西吗，命令是什么

我知道可以生成dll文件然后进行调用，不知道你说的是不是这个意思

引用:

原帖由 gyh_2000 于 2007-3-6 21:13 发表
1.主控制脚本设置一些const用来控制测试的产品和需要测试的特性
2.globe.sbh定义测试框架的全局变量和const,globe.sbl定义基本的操作函数
3.每个模块维护自己的,sbh,sbl这样便于自己维护
4.批处理的应用有时会大大 ...

lz经过相当熟练使用总结的经验，非常值得学习

真是太强了