功能测试自动化的投入和产出

发表于:2011-4-28 16:28

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:朱少民    来源:51Testing软件测试网采编

  测试自动化,对于系统性能测试、负载测试等效果是明显的,而且我们也不得不为之。我们知道,没有测试工具进行负载模拟,要通过手工测试完成系统测试任务,几乎是不可能的。但在功能测试中,情况就大不一样了。

  手工测试在功能测试中的优势还是比较大的,工具本身并没有想象力和灵活性,而人对界面美观性、逻辑合理性,容易作出判断。所以功能测试自动化主要的应用在回归测试中,而且产品的界面(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-drivenstructure using data pools
8.4
18
9.6
Framework structure
9.8
15
5.2
Framework / data-driven (hybrid) structure focusingon views of the application and using data pools
11.6
19
7.4

《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号