关于GUI自动化测试的收益回收期分析
作者: 未知 来源: 网络转载
摘 要：软件的界面测试是一项复杂而烦琐的工作，本文对程序界面的手工测试与自动测试两种方法进行比较，重点讨论了自动测试的收益回收期问题。
关键词：程序界面测试 捕捉/回放工具
the Break even of GUI Automation Test
BEIJING HORIZON INFORMATION & TECHNOLOGY CO.,LTD.
Ding Yuwei dyw@horizon-biz.com
Abstract: since GUI testing is an complicated and annoying work, here we compared automation and manual test , talk about the break even of automation test.
key words：GUI Testing GUI CR-tools(capture & replay tools)
引言
对于一个软件产品的评估，从用户角度来讲，程序的界面部分是相当受关注的，这里包括程序界面的交互能力、稳定性、健壮性等，同时今天的软件产品越来越复杂，通常一套软件包括会大量的用户界面，每个界面里又有很多的控制对象，以及各种信息的交互。对于这样一套软件，即便测试只覆盖到部分界面，工作量也是相当大的。由此人们想到利用工具来进行自动化测试，本文希望通过对自动测试与手工测试的比较，指导人们进行测试方法的选择。
CR-tools介绍
程序界面测试（GUI testing）主要包括两项内容：界面显示测试和界面功能测试，这里重点讲解功能测试（black box functional testing）。界面功能的自动测试可以用捕捉/回放工具来完成，（GUI CR-tools ：capture & replay tools )，但是在实际应用过程中，常常因为CR-tools固有的缺隙而大大削弱了它的效力，从而引起人们对自动化测试工具可用性的忧虑。如：
CR-tools对GUI对象的识别能力严重依赖于被测软件所使用的编程语言，这一因素大大增加了测试脚本的维护工作量。例如如果CR-tools可以识别C++语言开发环境、OO方法定义的对象(如buttons、menu等)，通常在界面布局调整时，它仍然可以识别出新界面上的所有元素，但是很可能它不能够识别Oracle应用程序，如用OCX开发的程序界面中的对象，这时我们不得不向供应商寻找相应的支持选件。
CR-tools通过对程序运行过程的录制产生的测试脚本，通常只能做为设计测试用例的初始原型，必须经过大量的修改和对脚本编程的工作，才能重复利用，如增加检查点（check point）、进行参数化等。因此，GUI自动测试的设计也是一项复杂的编程与开发工作。
当然以上问题我们也可以通过采取一些措施尽可能避免，如通过建立测试用例库，实现用例的重用、脚本功能的扩展、脚本语言的规范化、以及减少维护工作量等。所以，虽然自动化测试工具还存在很多问题，但它最大的好处是可以通过用例的重用，来大大减少重复的测试设计工作量，这也是至今人们还坚持不懈研究自动化测试技术的原因。
手工测试与自动化测试的比较
下面我们对手工测试与自动测试的成本开销进行比较，找出影响自动化测试效率的重要因素：自动测试的重复运行次数。
首先我们把软件开发过程定义为六个阶段：定义、分析、设计、实现、测试、发布，其中的测试阶段又可以细分为：测试设计、测试执行、测试分析、问题解决。.
表1是相关实验显示的比较结果：
实验的前提条件：
测试执行前录制程序运行产生测试脚本，在脚本重复回放期间，是完全自动执行的，没有做进一步修改，及其它人工的干预，尽管这在实际情况中会有一定的困难。
表1：
|
测试 项目 |
测试准备（V） |
测试执行（D） |
N |
手工支出/自动支出(E)（n次自动测试） | |||||
|
手工(m) |
自动(a) |
手工(m) |
自动(a) |
n=1 |
n=5 |
n=10 |
n=20 | ||
|
1 |
16 |
56 |
24 |
1 |
1.74 |
143 |
45 |
26 |
15 |
|
2 |
10 |
14 |
2 |
0.1 |
2.11 |
118 |
73 |
50 |
32 |
|
3 |
10 |
16 |
4.5 |
0.2 |
1.40 |
112 |
52 |
33 |
20 |
|
4 |
20 |
28 |
1.5 |
0.1 |
6.15 |
131 |
105 |
86 |
64 |
|
5 |
10 |
15 |
1 |
0.1 |
5.56 |
137 |
103 |
80 |
57 |
|
6 |
10 |
15 |
1.5 |
0.1 |
3.57 |
131 |
89 |
64 |
43 |
|
7 |
10 |
11.5 |
0.75 |
0.1 |
2.31 |
108 |
87 |
71 |
54 |
|
8 |
10 |
11.5 |
0.5 |
0.1 |
3.75 |
110 |
96 |
83 |
68 |
|
9 |
10 |
14 |
3 |
0.1 |
1.38 |
108 |
58 |
38 |
23 |
|
10 |
10 |
10.6 |
0.5 |
0.1 |
1.50 |
102 |
89 |
77 |
63 |
|
总计(t) |
116 |
191.6 |
39.25 |
2.1 |
2.03 |
125 |
65 |
42 |
26 |
注：测试准备和测试执行是以小时工作量为单位
Vm：测试设计的时间支出；
Va：测试设计+重复测试的脚本定制、数据准备等支出；
Dm：手工执行一次的时间；
Da：自动测试执行完成后的整理工作量。不含执行过程的时间，因测试是在CR-TOOLS的管理下自动执行的，不需人工干预。
En := Aa/Am = (Va + n*Da)/ (Vm + n*Dm).
实验分析
分析1：
以第二个测试项目为例进行说明，测试准备和设计需要10小时（Vm），如果进行自动测试另外还需4小时的工作，整个自动测试准备阶段需14小时（Va）。手工执行（Dm）与结果分析需2小时，自动执行（Da）与测试结果分析需0。1小时。以上是自动执行一次的情况，由此我们可以计算出重复运行5、10、20次的成本开销比较，其中如果自动运行5次，自动测试的成本是手工运行5次成本的73%，即：
E5 = Aa/Am = (Va + 5*Da) / (Vm + 5*Dm) = (14 + 5*0,1) / (10 + 5*2) = 14,5/20 = 0,725 = 73 %
由此可见，成本回收期限是由测试脚本的重复运行次数，或自动测试脚本的利用率决定的，
分析2：
根据等式：
EN = Aa/Am = 100%.
Ntotal =2,03
可见在自动测试第二次执行完成后，手工测试与自动测试的成本支出基本持平。
分析3：
如果你的测试工具在捕捉程序运行生成测试脚本后，只做了一次回放工作，这样的开销是手工测试的125%，因为附加的准备工作开销无法回收：191/116=165%。这里很可能是因为测试脚本语言的编程支持太弱，导致每一次重复运行时都有大量的维护、修改工作量，没有体现出自动测试的优势。
分析4：
对于一个自动测试过程，只要能够重复利用10次，测试费用就能降低40%，可见自动测试的效率提高还是相当显著的。
另外，此结果可以适用于小型、中等软件公司和开发团队的规模情况。当然这些实验和分析没有考虑被测软件、开发环境，测试流程等因素的影响。
结论
1.利用脚本语言编程实现测试用例的自动执行，自动执行一次的资源开销是手工测试一次的165%，在正常情况下，如果第二次重复测试，自动与手工的资源开销基本持平。
2.影响自动测试效率的因素：未经培训的测试人员、人员没有测试开发和编程经验、在软件产品还不稳定情况下过早启动测试、开发与测试人员沟通不足，致使软件修改后测试人员未能及时知道。
3.进行GUI自动化测试需要掌握大量与测试工具相关的知识和技能，因此必须事先经过很好的培训。
4.实现自动测试的过程是一个复杂的软件开发过程，需要测试人员具有相当的的软件测试组织、实施经验和专业的软件开发经验。
5.建立并长期维护一套测试用例库，?能够帮助我们节省资源并能够快速培养测试人员。
文章来源于领测软件测试网 https://www.ltesting.net/
