自动化测试在计算机软件开发中的应用

人们一般认为新技术可以解决面临的所有问题，但任何一项技术都不是万能的，自动化测试也不例外。在具体实施自动化测试的时候，总是会出现这样或那样的问题，严重影响自动化测试的效率，造成事倍功半甚至前功尽弃的后果，使自动化测试成了一副空架子。自动化测试与其他技术一样，也有适合使用和不适合使用的情况。

▶6.3.2.1　适合自动化测试的情况

下面是一些适合使用自动化测试的情况。

（1）产品型项目

对于产品型项目，每个项目只需改进少量的功能，但每个项目必须反反复复地测试那些没有改动过的功能。这部分测试完全可以由自动化测试来承担，同时可以把新加入的功能的测试也慢慢地加入自动化测试当中。

（2）增量式开发、持续集成项目

由于这种开发模式是对频繁地发布新版本进行测试，也就需要自动化测试来频繁地测试，以便把人从重复性工作中解脱出来测试新的功能。

（3）回归测试

回归测试是自动化测试的强项，它能够很好地确保是否引入了新的缺陷，老的缺陷是否修改过来了。尤其是在软件经常进行版本更新的环境中。当新版本测试时，只需要几分钟时间启动已有的测试用例即可自动完成对新版本的回归测试，在某种程度上可以把自动化测试工具叫作回归测试工具。

（4）多次重复、机械性动作的测试

自动化测试的优势更好地体现在那些包含有多次重复、机械性动作的测试，比如要向系统输入大量的相似数据来测试，自动化工具比手工输入准确性高，还可以将测试人员从重复性劳动中解脱出来，将精力专注于如何设计好的测试用例。

（5）手工测试很难达到或无法完成的测试

使用手工执行大规模的多用户并发测试是很难实现的，但是使用自动测试工具模拟多用户就是很容易的事情了，用户场景测试随时都可以运行，测试执行人员不需要了解应用程序的复杂业务逻辑。

手工测试时，期望的输出通常包含明显的标志，可以让测试人员识别。但是，有很多属性是很难由人工来确认的。例如：图形界面测试中，界面操作经常会触发一些事件，但是并没有立刻输出结果。在这种情况下，测试工具可以检测到事件被触发，并执行相应的操作。

▶6.3.2.2　不适合自动化测试的情况

自动化测试并不最适合所有的公司或所有的项目。下列情况不适宜进行自动测试。(www.xing528.com)

（1）定制型项目（一次性的）

为客户定制的项目，维护期由客户方承担的，甚至采用的开发语言、运行环境也是客户特别要求的，即公司在这方面的测试积累就少，这样的项目不适合做自动化测试。

（2）周期短的项目

项目周期很短，测试周期也很短，就不值得花精力去投资自动化测试。好不容易建立起的测试脚本，不能得到重复的利用是很浪费财力和人力的。

（3）业务规则复杂的对象

业务规则复杂的对象，有很多的逻辑关系、运算关系，工具就很难测试。

（4）美观、声音、易用性测试

界面的美观、声音的体验、易用性的测试等属于主观方面的，而不是客观的，而且这些测试结果很容易通过人员验证，而对于自动化测试来说又比较难以实现。所以这方面的测试只能由人来完成。

（5）测试很少运行

测试很少运行，对自动化测试就是一种浪费。自动化测试就是让它不厌其烦地、反反复复地运行才有效率。

（6）软件更改比较频繁

如果软件的用户界面和功能频繁更改，那么修改自动化测试的成本比较大，因此不适合自动化测试。另外，如果软件运行不稳定，则会由于这些不稳定因素导致自动化测试的失败。

（7）测试中涉及物理交互

测试工具很难完成与物理设备的交互。例如断开设备的连接，开/关电源等。