Important Considerations for Test Automation
自动化测试的要点
实施自动化测试的十个要点，原文作者是chinmay kolachalam，译者sincky zhang。
转载请注明本网站和作者联系方式： sinckyzhang@msn.com
Often when a test automation tool is introduced to a project, the expectations for the return on investment are very high. Project members anticipate that the tool will immediately narrow down the testing scope, meaning reducing cost and schedule. However, I have seen several test automation projects fail - miserably.
当一款自动化测试工具引入到一个项目中，我们通常对它给予很高的期望；项目成员希望工具能够尽可能的缩小测试范围、节约成本并缩短项目进度，然而可悲的是，很多采用自动化测试的项目依然失败了。
The following very simple factors largely influence the effectiveness of automated testing, and if not taken into account, the results is usually a lot of lost effort, and very expensive ‘shelfware’.
以下几个方面严重影响着自动化测试的效率，如果处理不当，将会造成事倍功半甚至前功尽弃的后果，自动化测试也成了一副空架子。
Scope - It is not practical to try to automate everything, nor is there the time available generally. Pick very carefully the functions/areas of the application that are to be automated.
一是测试的范围：想要百分百的实现自动化测试是不现实的，而且从时间投入上也是不可行的；有选择性的挑选应用程序的一些功能或区域模块，采用自动化测试。
Preparation Timeframe - The preparation time for automated test scripts has to be taken into account. In general, the preparation time for automated scripts can be up to 2/3 times longer than for manual testing. In reality, chances are that initially the tool will actually increase the testing scope. It is therefore very important to manage expectations. An automated testing tool does not replace manual testing, nor does it replace the test engineer. Initially, the test effort will increase, but when automation is done correctly it will decrease on subsequent releases.
二是测试时间的准备工作：自动化测试脚本的开发时间必须考虑在内，一般来说，开发测试脚本的时间要比手工测试多出三分之二，因为现实里工具会在初始阶段增加测试的范围；因此，对自动化测试保持适度的期望值很重要：工具不能取代手工测试，更不能代替测试工程师。测试初始阶段，投入会比较大，当自动化完成后，将会大大缩短后续的版本的测试时间。
Return on Investment - Because the preparation time for test automation is so long, I have heard it stated that the benefit of the test automation only begins to occur after approximately the third time the tests have been run.
三是投资的回报：自动化测试的准备工作如此漫长，据说自动化测试的效益只会出现在测试被执行三次以后的时间里。
When is the benefit to be gained? Choose your objectives wisely, and seriously think about when & where the benefit is to be gained. If your application is significantly changing regularly, forget about test automation - you will spend so much time updating your scripts that you will not reap many benefits. [However, if only disparate sections of the application are changing, or the changes are minor - or if there is a specific section that is not changing, you may still be able to successfully utilise automated tests]. Bear in mind that you may only ever be able to do a complete automated test run when your application is almost ready for release – i.e. nearly fully tested!! If your application is very buggy, then the likelihood is that you will not be able to run a complete suite of automated tests – due to the failing functions encountered.
四是何时获得自动化测试的收益：定位合适的测试目标，并认真分析自动化测试的收益出现在何时、何处。如果测试程序频繁进行大幅度变更或修改，还是放弃自动化测试吧！－你将会耗费相当的时间去修改测试脚本，但收益是微乎其微的。（但是，如果应用程序频繁变更的模块彼此独立，或者修改较小，或者只是特定区域的变更，那么仍然可以成功采用自动化测试。）另外，谨记只有当应用程序将近发布时，才可以进行完整的自动化测试；如果应用程序缺陷太多，功能点运行失败，想要运行全面的测试套件程序是不太可能的。
The Degree of Change – The best use of test automation is for regression testing, whereby you use automated tests to ensure that pre-existing functions (e.g. functions from version 1.0 - i.e. not new functions in this release) are unaffected by any changes introduced in version 1.1. And, since proper test automation planning requires that the test scripts are designed so that they are not totally invalidated by a simple gui change (such as renaming or moving a particular control), you need to take into account the time and effort required to update the scripts. For example, if your application is significantly changing, the scripts from version 1.0. may need to be completely re-written for version 1.1., and the effort involved may be at most prohibitive, at least not taken into account! However, if only disparate sections of the application are changing, or the changes are minor, you should be able to successfully utilise automated tests to regress these areas.
五是变更的程度：自动化测试最适合用于回归测试，将那些已经存在并相对完善的功能进行自动化测试；例如应用程序1.0版本的功能模块已经稳定，没有引入1.1版本的新功能，这种情况下，我们对其制订自动化测试计划并设计测试脚本，不至于因为简单的GUI变更（例如某个控件改名或移动）而使脚本无效。我们也需要将修改脚本的时间考虑在内，例如，如果应用程序的版本升级造成很大的功能改变，那么也许要全部重新书写测试脚本，这种情况是我们不愿意看到的。但是，如果只是某个相对独立的功能模块发生变更，或者变更较小，我们可以成功的实现在回归测试里的自动化。
Test Integrity - how do you know (measure) whether a test passed or failed ? Just because the tool returns a ‘pass’ does not necessarily mean that the test itself passed. For example, just because no error message appears does not mean that the next step in the script successfully completed. This needs to be taken into account when specifying test script fail/pass criteria.
六是测试的完整性：我们如何度量一个测试是否通过或失败呢？单单凭借工具返回的“pass”不足以证明测试本身通过无误，例如，没有错误的提示信息出现并不意味着脚本的下一步动作能够成功进行。因此这一要点需要在规划测试脚本的通过与否标准上考虑在内。
Test Independence - Test independence must be built in so that a failure in the first test case won't cause a domino effect and either prevent, or cause to fail, the rest of the test scripts in that test suite. However, in practice this is very difficult to achieve.
七是测试的独立性：测试的独立性应该被考虑在内，从而不至于某一个测试用例的运行失败引起全局影响，甚至阻止整个测试套件程序里其他脚本的运行；但是，在实践中对该问题的把握并不容易，需要一定的努力达到此目标。
Debugging or "testing" of the actual test scripts themselves - time must be allowed for this, and to prove the integrity of the tests themselves.
八是对测试脚本本身的调试和测试：必须花费一定的时间进行该工作，以检验测试本身的完整性。
Record & Playback - DO NOT RELY on record & playback as the SOLE means to generates a script. The idea is great. You execute the test manually while the test tool sits in the background and remembers what you do. It then generates a script that you can run to re-execute the test. It's a great idea - that rarely works (and proves very little).
九是录制/回放：不要完全把工具的录制/回放功能作为创建测试脚本的唯一方法，这个观念是很重要的。测试者在后台运行测试工具，再手工执行测试，工具将测试者的动作记录下来，自动生成一个脚本，以便测试者可以重新运行测试动作，这虽然是个好想法，但对测试工作本身并无太大意义。
Maintenance of Scripts - Finally, there is a high maintenance overhead for automated test scripts - they have to be continuously kept up to date, otherwise you will end up abandoning hundreds of hours work because there has been too many changes to an application to make modifying the test script worthwhile. As a result, it is important that the documentation of the test scripts is kept up to date also.
十是对测试脚本的维护：最后一点，对自动化测试脚本的维护是一个高投入的
