【摘要】 我们对自动化测试充满了希望，然而，自动化测试却经常带给我们沮丧和失望。虽然，自动化测试可以把我们从困难的环境中解放出来，在实施自动化测试解决问题的同时，又带来同样多的问题。在开展自动化测试的工作中，关键问题是遵循软件开发的基本规则。本文介绍自动化测试的 7 个步骤：改进自动化测试过程，定义需求，验证概念，支持产品的可测试性，具有可延续性的设计（ design for sustainability ），有计划的部署和面对成功的挑战。按照以上 7 个步骤，安排你的人员、工具和制定你的自动化测试项目计划，你将会通往一条成功之路。
我在很多软件公司工作过，公司规模有大有小，也和来自其他公司的人员交流，因此经历过或者听说过影响自动化测试效果的各种各样的的问题。本文将提供若干方法规避可能在自动化测试中出现的问题。我先给大家讲一个故事，以便各位了解自动化测试会出现哪些问题。
Automation Project Management and Automation Architecture
By M.N. Alam IMI Systems Inc.
Introduction
Numerous white papers and articles are written on test automation. Most are well researched and present a wide range of views about the benefits of using automation. Some of the articles are the collection of individual experiences (some are more painful than others) to make the automation work for them. In this paper, I would like to discuss automation from project management and architecture standpoint and hope this may help others to establish a process that fit their testing environment.
Since a great deal of important information is already available on cost/benefit analysis of automation, I will not attempt to engage in further discussion on this. But I will say that it is very important to do a cost/benefit analysis of the test cases that require automating. James Hancock wrote: “When to Automate Testing - A Cost-Benefit Analysis” which is an excellent article on this subject.
任何工具没有最好的,只有最适合的. 自动化测试工具也是如此. 针对不同的公司,不同的应用,如何挑选最适合自己的自动化测试工具?
下面的几点也许可以作为你的参考.
List of points on which the new automation tool for functional and
regression testing is evaluated:
1. Ability to Identify all controls i.e. support Custom controls
2. Number of controls supported - Windows, IE, Netscape, .Net, Java
3. Number of OS Lang supported - English, Japanese, French etc.,
What are Best Practices?
Best practices are guidelines and advice on the best way to do something; collected over time and based on experience with previous projects. Best practices in an organization should come from the bottom of the organization up, rather than being mandated by management. These best practices might even differ from organization to organization, but certain key factors are present in successful organizations and projects. Discussed in this article are twelve of the most important practices that can assist you in ensuring successful implementation of functional test automation on your projects and in your organization.
—看看mercury的自动化已经发展到什么程度
传统自动化测试的限制
软件的自动化测试在过去一段时间中有长足的进步。每个世代的产品都成功解决了某些重要的挑战，但是同时也引进了不同的问题等待解决。
第一代的自动化测试大概在15年前开始，透过硬件的方式录制键盘的输入并播放，但缺少检查点（checkpoint）的功能，而且测试脚本很难维护。
第二代的自动化测试则大约在10年前开始的，这时已经由硬件转变成透过软件录制/播放（capture/playback）的方式产生测试脚本（script）， 并且也增加了检查点的功能，可以对软件做验证，测试的范围也比硬件方式的自动化方式大了许多。比较大的问题是测试脚本也是一种程序语言，所以测试人员也需 要懂程序语言，换句话说就是要会写程序。而且当软件有变动时，测试脚本也需要同步更新，这对测试人员来说是一大挑战，测试人员常常就是整个测试脚本再重新 录制一遍。
在2001年开始了第三代的自动化测试称为「测试框架（test framework）」，主要是把测试脚本给抽象化（abstraction）（注：如Keyword-Driven Test），让非技术人员（如系统分析师、使用者等）即使不懂测试脚本，不会写程序的情况下，也可以使用自动化测试工具建立自动化测试个案。
第四代Mercury Business Process Testing：专注于业务需求的自动化测试
Mercury 在 Quality Center 8.0 时就推出 Business Process Testing，到现在已经进步到 9.0 的版本了。会什么 Mercury 发展出 Business Process Testing 呢？Business Process Testing 的好处在哪？要如何使用Business Process Testing？我将在以下的文章为大家做个介绍。
一、概述
软件测试自动化，从计算机这一庞大学科发展至今，最根本的意义是解决手工劳动的复杂性，成为替代某些重复性行为模式的最佳工具。
二、实施软件测试自动化的理由
1. 提高测试效率和降低测试成本
2. 将重复性强的测试由手工转为可以独立开来自动实现的。
3. 实现快速的回归测试，提高新版本发布的速度和质量，尤其是不能适应目前流行的迭代开发，回归测试频度高、工作量大，人工的测试很难对新的迭代版本作出快速评估
4. 自动测试可以避免，人工测试容易犯的错误：错误测试、漏测试、多测试和重复测试等
5. 典型的应用，例如多用户并发注册、并发交易请求和并发交易应答，这种情况用人工测试几乎是办不到的，而自动测试却很容易。
6. 对于很常用的功能性边界测试测试，人工测试非常耗费时间，而自动测试很快且准确
上周参加公司的自动化测试研讨会，今年的主题是ROI（投资回报），个人感觉这是一个很严肃的话题，也是领导最关心的一个问题。不过谈测试自动化的投资回 报似乎并不是一件容易的事情。测试自动化本身是一个需要持续投入的系统工程。他并不像开发过程一样那么容易衡量产出和回报。另外，对于测试自动化的投资回 报似乎不应该在一开始提到一个很高的高度。否则对自动化的开展非常不利。
另外，测试自动化并不是简单的把手工的测试转化成自动化的代码或 者脚本这么简单的过程，而是要贯穿在产品的生命周期中，进行不断地执行，只有不断地执行，才能得到收益，根据经验，回归测试的自动化测试用例在不考虑被测 对象改变带来自动化测试脚本维护的前提下，反复执行4-7轮才能收回成本。如果被测对象本身不是十分稳定，或者缺陷比较多，产品不成熟，这个时候介入测试 自动化是非常得不偿失的。
测试自动化在很大程度也依赖于被测对象或者被测设备的稳定性，系统的设计应该考虑到可测试性，Design for Test。测试自动化越早加入到产品的开发周期，成功的机会越大。
关 于测试自动化的效果衡量不是简单的发现了多少缺陷，其实自动化测试并不能比手工测试发现更多的缺陷，如果要发现更多的缺陷，一定要进行必要的手工测试。自 动化测试的效果或者投资回报可以通过其他一些方法进行衡量，比如节省的测试人力成本，可以通过统计手工测试的时间，自动化测试的开发时间，自动化测试的执 行之间，执行次数，刨去维护时间，进行计算得到。另外，还可以从回归测试能加快产品的发布时间上进行衡量。
最后，关于产品的自动化程度， 究竟多少比例的产品需要被自动化，这个取决于产品本身，以及这个产品本身可以被自动化的程度有关系，还要考虑自动化所需要花费的代价。一般来说，不是所有 的测试用例都需要自动化，也不是所有的测试用例都能够自动化。据个简单的例子，有一个测试用例，需要重新启动机房里面一台服务器，常规来说，是不能也不需 要自动化。但是有没有可能自动化呢？肯定有，不过肯定不会为了这个自动化这个测试用例而去花费巨大的代价开发一个机器人帮你完成这个任务。当然这是一个极 端的例子。目的是告诉大家，不是所有的测试用例都需要自动化，也不是所有的用力都能自动化。衡量的依据是不同产品和代价得多少。
谈到自动化测试,自然离不开自动化测试工具. 其实自动化测试和自动化测试工具还有很大的差别,不过很多人提起来自动化测试就想到自动化测试工具,其实是不全面的，更有人提到自动化测试就想到QTP,LoadRunner,Test Manager,那就更是片面的了。
自 动化测试工具是开展自动化测试的必备利器，就好像你要进行性能测试自动化，但是缺少工具。传统的方法比如压力测试是号召大伙某个固定的时间，登陆某台测试 对象或者测试设备进行同时测试。这在现在看来是有些不切实际，而且实际的测试效果往往因为无法有效组织或者无法模拟实际情况大打折扣。而利用自动化测试工 具就可以很好的满足这样的需求，最简单的就是模拟500用户并发测试web服务器的性能。
不单单性能测试，往往功能测试自动化也是这样的，只是性能测试表现得更加明显罢了。功能测试自动化如果能有效的利用自动化测试工具，有的时候可以收到事半功倍的效果。
简单的分析到这里，关于测试工具的一个很全面地总结，可以参考前面的一篇日志。
你正在浏览的汇总是: 测试自动化
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Dec | ||||||
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 | |
