3 脚本修复技术的提出

　　脚本修复技术是修复非法的事件序列，使得这些脚本可以在修改过的GUI上执行。表1中将GUI的变化主要是由3类构成的，对象的增加（例如增加了新的按钮），对象的删除（原有按钮被删除），对象的修改（原先的按钮变成了菜单选项）[30]。如果将这三类分析清楚，那么脚本修复功能就能够实现。除此之外，还有考虑依赖关系，因为对象如果存在被依赖关系，那么它的改变势必会对其产生依赖的对象产生一定的影响，因此可以将GUI的变化分为六类。下面分别介绍这六种状况。

表1 GUI的六类变化

对象变化类型  是否被依赖
增加对象  独立
增加对象  存在被依赖关系
删除对象  独立
删除对象  存在被依赖关系
修改对象  独立
修改对象  存在被依赖关系

3.1 增加对象

(1) 该对象不存在被依赖关系

　　存在事件序列(e1,e2...en)。新增对象i，如果在该序列中不存在对对象i的依赖事件，那么关于i的事件ei可以不放入该队列中。如图6中“事件序列图1”所示，因此原事件序列可以不用改变。

图6. 事件序列图1

(2)该对象存在依赖关系

　　存在事件序列(e1,e2...en)。如果在该序列中存在对对象i的依赖事件，即ei是某个事件运行的前提条件。那么关于i的事件ei要放入该队列中。将ei放入依赖事件之前，这样可以保证原理的事件序列可以正常运行。因为对象树被更新，所有对象的事件集合也会被更新。因此在事件序列中只需要将原来ex（依赖于ei），更换为ex'（ex'为默认操作，包含了对i的操作）。如图7中“事件序列图2”所示，ex'替代了ex加入到新的事件序列中。

图7. 事件序列图2

　　可见对于新增对象，只要原有事件序列没有产生对其的依赖，原有事件序列依然可以正常运行。

3.2 删除对象

(1) 该对象不存在被依赖关系

　　存在事件序列(e1,e2...ei...en)。如果在该序列中不存在对对象i的依赖事件，那么关于i的事件ei可以直接从该队列中删除。如图8中“事件序列图3”所示，因此原事件序列只用删除ei事件。

图8. 事件序列图3

(2) 该对象存在被依赖关系

　　存在事件序列(e1,e2...ei...en)。如果在该序列中存在对对象i的依赖事件，那么除了关于i的事件ei要被删除之外，同时要将ex更改为ex'（ex'为默认操作，在默认操作中也删除了对i的依赖事件）。如图9中“事件序列图4”所示，新的事件序列中原有ei被删除。

图9. 事件序列图4

　　对于删除对象来说，判断该对象的依赖关系是修复事件序列的前提。而这些都可以通过更新对象层和事件层来完成。

3.3 修改对象

(1) 该对象不存在被依赖关系

　　存在事件序列(e1,e2...ei...en)。如果在该序列中不存在对对象i的依赖事件，那么原事件序列不要更改，只需要更新ei，因为对象树被更新，因此可以使用事件编辑器对ei进行更新。如图10“事件序列图5”所示，原事件序列没有改变。

图10. 事件序列图5

(2) 该对象存在被依赖关系

　　同图5所示，利用事件编辑器更新事件集合，原有事件序列不需要改变。

　　对于修改对象，其实可以看成是先删除对象，在新增一个对象。它的处理方式相对简单。

　　在脚本修复技术中，所有的事件序列的处理，都是要有对象和事件作为支持的，同时判断对象之间的依赖关系也是尤为重要的技术环节。所以在对脚本修复之间，需要动态的更新对象层与事件层的相关信息。

　　测试脚本修复思想产生的最初考虑就是以现有测试脚本为基础，尽可能使更多的原脚本可以稍加修改就可以用于频繁的回归测试过程。所以它完全可以作为一个现有方法的扩展，在计算能力足够强大或者时间要求相对宽松的条件下为了满足测试覆盖标准的要求（考虑到某一个或者某几个事件的重要性或者排除它们受到影响的可能，需要这些事件必须出现在回归测试集的脚本当中，就必须对该方法进行扩展）而进行应用。