2.4 实用性自动化测试策略

自动化测试永远是测试人员心中的痛。一方面，测试人员在长期的手工测试中已经不胜其烦，梦想着使用测试工具轻松地实现自动化测试；另一方面，一旦尝试了自动化测试，又会发现有太多的阻碍，这些阻碍来自工具、管理和人。

2.4.1 自动化测试工具的问题

首先碰到的问题是测试工具的问题，现在很多商业上的工具都存在这样或那样的问题，大部分会有以下缺点。

1.厂商脚本语言

大部分商业测试工具会指定某种语言，例如：WinRunner（TSL），SilkTest（4test）， Robot（Test Basic），但是，一些新的工具也开始使用标准语言，例如QTP（VB Script）， XDE Tester（Java）。

所以，在选择测试工具时要考虑这点。最好选择支持标准语言的测试工具，而且，尽量与所在项目组的开发人员所使用并熟悉的语言一致。这样可以充分利用现有的编程知识和语言知识，而不需要花时间去熟悉厂商特定的语言（这些语言只能在这个工具上使用），并且可以借助开发人员丰富的开发知识来协助进行测试脚本的设计和编写。

2.对新平台、个性化控件的支持不够好

大部分商业测试工具没能很好地支持新的平台和很多的第三方控件、个性化控件。例如，新的.NET版本、操作系统，以及普遍使用的第三方控件，如Component One、Infragistics、Janus等。

如果项目中使用这些较新的平台或大量使用这些第三方控件的话，就要小心选择测试工具了，否则会导致后面的脚本编写难度加大。建议在选用之前，充分评估并在项目的应用程序上试用。

3.与源代码控制的结合不好

很多工具没有与源代码控制工具集成，使用临时文件和目录（WinRunner），有些则把信息存储在外部的库中，例如Rational。

源代码控制对于测试脚本的管理非常重要，除非希望每个测试员使用自己的一套脚本，或者通过原始的复制方式来进行共享和管理。

在选用工具时，还会碰到选择商业工具还是开源工具的问题。在这里，同样需要考虑项目的上下文，还有成本问题。目前，开源社区的测试工具大部分是单元测试工具，成熟的自动化测试工具还不多，如果选用这些工具的话，需要考虑维护和修改调整工具的成本。

2.4.2 自动化测试的管理规范

当兴冲冲地拿到测试工具准备大展拳脚时，先停一停，考虑一下自动化测试如何开展。首先，对测试人员的培训是必不可少的，培训需要包括工具的内部培训、脚本语言的培训、自动化测试规范的培训。

选用开源的测试工具一般不会有培训课程，即使是购买的测试工具也未必会附带培训课程。所以对于工具的内部培训，一般可由前期负责工具选型和试用的人员进行内部培训。熟悉工具附带的帮助文档和 Sample 文件会对工具的学习，还有脚本语言的学习有很大的帮助。

培训还包括制定出自动化测试规范，并对参与测试的人员进行培训。规范可以从以下几方面进行制定。

1.测试用例的选择

并不是所有测试用例都能用自动化的方式执行，自动化测试适合在机械化的执行和比较中使用，让一个自动化测试对用户界面规范性进行检查，那是“不可能完成的任务”。另外，还要注意测试用例自动化实现的顺序，优先实现简单的、主体的，例如，按以下顺序来实现测试用例自动化：

遍历所有界面的冒烟测试->测试用例中的主成功场景->扩展场景、扩展流程->……

2.脚本命名规范、注释规范

为了让测试脚本的维护性、可读性更强，应该制定出命名规范和注释规范。例如，要求在每个脚本函数前面注明测试目的，简要的测试过程描述等；对脚本中的主要步骤、复杂代码进行注释。

3.对公用测试数据的维护

如果测试涉及的数据在不同测试人员编写的很多脚本都要使用到，则应该制定出相应的数据维护规范，例如，要求测试脚本对数据的操作要考虑数据的备份和恢复等问题。

另外，还要考虑自动化脚本编写方法，不同的脚本编写方法对脚本的可维护性、开发成本的影响程度不一样，对测试员的编程技能要求程度也不一样。

2.4.3 自动化测试中人的因素

在进行自动化测试时，除了要做好准备，制定好规范和策略外，还少不了对人的管理，项目整体管理流程的配合。

（1）测试人员有时候会不知不觉地陷在测试脚本的编写中，没有很好地评估测试的时间要求，没有选择合适的测试脚本编写方法。这其实也是阻碍自动化测试成功进行的因素之一。

例如，对一些测试工具支持不是很好的控件，有时候会出现无法识别的问题，这时候不要花太多的时间去研究为什么不能识别，或尝试其他很多识别的办法，而是先用最简单的方法解决，即使方法看起来比较老土，例如，很多无法识别的控件都可以通过键盘操作、Tab键定位等方式解决。

（2）造成自动化测试艰难进行的问题，很可能是软件的可测试性问题，也就是说，软件提供的可测试性接口不够强大，或者是在设计时没有很好地考虑可测试性问题，而这些都是开发人员可以为自动化测试提供的，可以让开发人员提供对软件的编程接口、Hook、更换一个等同效果但是测试工具可以识别的控件等。

（3）配置管理。项目的配置管理没有做好也可能会影响到自动化测试。有些开发人员喜欢时不时地调整一下自己的代码，重构一下设计，如果这些方面没有控制好的话，可能造成自动化测试的脚本大面积作废和修改，虽然在开发方面看来这些重构和调整是那么的轻而易举和微小。例如，对控件的命名的更改就可能导致大部分操作这些控件的测试脚本的修改。

因此，软件的配置管理工作，对被测试系统的源代码控制有时候可能成为自动化测试成功的关键。应该确保被测系统的更改得到评审和通知，评审要把对自动化测试的影响纳入考虑范围。