测试自动化，对于系统性能测试、负载测试等效果是明显的，而且我们也不得不为之。我们知道，没有测试工具进行负载模拟，要通过手工测试完成系统测试任务，几乎是不可能的。但在功能测试中，情况就大不一样了。
手工测试在功能测试中的优势还是比较大的，我在“
测试方法的辩证统一（之二）”已做了讨论，工具本身并没有想象力和灵活性，而人对界面美观性、逻辑合理性，容易作出判断。所以功能测试自动化主要的应用在回归测试中，而且产品的界面(UI)和功能变化较大，自动化的脚本（Script）维护成本较大，投入和产出往往变成我们最关心的问题，在功能测试中实现测试自动化究竟是否合算？
举个例子：假如一个功能测试用例，手工运行
需要10分钟，而为此测试用例开发脚本需要4个小时，即240分钟，那么意味着这个测试脚本要被运行24次收回成本，如果在加上测试脚本的维护工作量（10％），需要重复运行40－50次，才收回成本。如果在产品的一个版本中要进行2－3轮测试（一般是需要的），这个产品需要发布
15－20个版本才收回成本。所以业界常说，产品发布
7个版本才收回成本。
如何降低成本、可以相对增加产出或者说更快地收回成本？关键是提高脚本开发速度、提高脚本运行的稳定性和降低维护脚本的工作量，主要方法有：
－ 选择较好的、更适合的测试工具
－ 选择适宜自动化的模块
－ 尽量将脚本写成数据驱动的脚本，这一点很重要。
－ 多录制脚本，然后结构化脚本。我们知道，不是所有的模块都可以变为数据驱动方式，这时就要抽象出脚本的结构，进行有效的组合，包括分层，形成有效的层次性。
－ 测试和脚本开发合二为一，效率更明显
下表也部分说明了这个问题。也希望得到您更好的想法。
|
结构
|
成本
|
收益
|
净收益
|
|
No Automation
|
0
|
0
|
0
|
|
Recording and Playback
|
8.3
|
11
|
2.7
|
|
Data-driven structure using data pools
|
8.4
|
18
|
9.6
|
|
Framework structure
|
9.8
|
15
|
5.2
|
|
Framework / data-driven (hybrid) structure focusing on views of the application and using data pools
|
11.6
|
19
|
7.4
|
发表于 @ 2006年06月14日 18:20:00|评论(loading...)|编辑