E浅谈自动化测试(word).docVIP

浅谈自动化测试 由安博测试空间技术中心/提供 [说明] 既然是“浅谈”，那当然是浅浅的谈了，再说了，深的我也谈不来^_^ 本文为本人个人结合自己在公司中的实践情况谈的一些感想，欢迎讨论，但不想理论。哎，实在是本人理论功底不好，而且懒于辩论。从初中开始，语文就没很好过- -！ 自动化测试从广义上来说包括自动化功能测试、自动化性能测试、自动化安全测试、自动化单元测试等等。而我们日常常说的自动化测试一般是指自动化功能测试，本文主要也是从自动化功能测试角度考虑。 [正文] 说起自动化测试的强大，很多人起先的了解来自于测试论坛或者说来自于自动化测试工具厂商对工具的介绍。咱们先来看一段我因为需要而写的一段有关自动化测试的描述（不代表本人真实想法，这是因为有需要才为之的）： 这段话，个人感觉或许对于像微软这些大公司而言是对的，但就目前中国软件企业现状来说，自动化测试是不是像这段话说的这样真的很难说。单不说我们的定制项目战略与大公司的通用产品战略的差距，就我们公司的质量意识也能使这段话失效。就说以下这点，进行了程序修改后，需要对程序进行比较全面的测试这点，我们的很多公司就不做。原因很简单，上级认为这没有必要、而且是浪费时间，另一点，定制项目的利润可比通用产品少得多得多，哪有那么多钱让我们认真测试呢。而定制项目好像还是我们的主流。 对于自动化测试，有这么一句总结的定义“利用程序测试程序”。这句话很简练吧，自动化测试归根到底也确实是这么个味道。利用工具、利用软件、利用小脚本等等都可以进行自动化测试。本人一直认为自动化测试是一种技术，是一种能力。既然是一种技术，那就不应该用太固定的框框把它限死了。应该是做到随需所用、依需而定。既然是一种能力，就应该用发散的思维去发挥它更多更大的作用。就像阅读这个能力，谁说一定要先划定中心思想，谁说一定要精读，更没人说一定要用三遍阅读法哦。阅读当然得根据读者的目的以及所读文章的特点，甚至是读者的水平来确定读此文章的方法。自动化测试也一样，不一定要用在回归测试上，也不一定要用在集成测试上。有时甚至可以写个小脚本用在解决功能人员测试难的小问题上。这不也是很好的自动化测试嘛。 关于自动化测试工具，厂商说的可以说基本不可信。说什么“录制/回放”就可以实现，“简单得很”。要真相信这个，那你自动化测试的失败也会“快得很”。当然，微软所吹嘘的，要自己编程序来进行自动化测试，而不应该想着使用自动化测试工具来实现自动化测试。这个观点对于微软来说，应该是正确的。但是得看看微软什么现状：就微软的产品，有哪个自动化测试工具能支持得了全自动化测试的？再说了，微软的产品是全世界在卖，那质量要求高，而且利润更高，有的是钱请牛人来编写自动化测试程序。而且微软的人才也是我们这些公司不可企盼的。因此，如果有好的工具，甚至小工具或开源工具，只要能更好的解决公司中的问题，那何乐而不为呢？ 可以毫不客气的说，想要进行自动化测试，那还真得会编码。就拿易用性方面名声不错的QTP来说，要是不会编写VBScript脚本，要是不会综合应用QTP内置的对象和函数，要是不了解QTP支持的扩展，那么就是对QTP这个工具没有很深入的了解，那么如何做到能灵活应用呢。要是真碰到特殊问题，那很容易就GameOver了。我曾经拿几个自动化测试工具（如QTP9.2版、RFT7.1版、TestComplete5.0版）试了试一些基本的标准html页面的功能。有的没法完全回放成功，而如果要进行一些特殊的判断或处理，那“录制”基本就不可能了。而且，即使录制的都能成功回放，那能说明这就实现了自动化测试嘛？自动化测试重点还是在测试，要实现的是测试的目的，而不是在于几个工具的使用上。 自动化测试是一种技术、是一种能力，它不是绑定在某种工具上的。在实际的实践中，发现一些自动化测试人员，在熟练掌握一个自动化测试工具后，非常的高兴，而且有点炫耀的味道。于是乎，本人就问他：“你以为会这个工具，你就会自动化测试了吗？你最多就算会这个工具，或精通这个工具，跟自动化测试无关。”（本人说话较直，总喜欢实话实说- -！）。这里要说的是，要注意自动化测试不是工具的必然。如果只是把自动化测试定位在一两个工具上，那这个人到头来可能会的不是自动化测试技术，而是工具。当然如果要直接从自动化测试技术入手，可能学起来会没有感观认识，而且进入那个自动化测试思维大门较难。因此，一般的学习和进阶方法可以如下：找一个或两个比较容易实现自动化测试的工具，进行深入的学习，并在项目中进行实践，等有一定实践经验后，自然会有一定的认识的。而这时就需要自己的思维脱离这些自动化测试工具，进而思考自动化测试技术的方方面面。然后当然就是可以试用其他的测试工具（强调一下，不要以为只有测试工具才能用于自动化测试，其他工具也可以的，只