[原创] 三种我们要做或不做的自动化的场景

三种我们要做或不做的自动化的场景

 

3 scenarios when weshould automate (or not)

 

原作者：Shuchi

 

译者：Maurice, Testone, Jenvee, Wally

 

原文地址：

http://www.learnqtp.com/3-scenarios-when-we-should-automate-software-testing/

 

 

 

 

日期：2009-10-27

【E测中国翻译团队作品】

 

E测中国翻译团队作品下载：

http://download.5etesting.com/questions.php?parentID=182&typeID=184

这是一个由访客Shuchi写的文章。
Shuchi是一位多国集团的首席顾问，并且在IT行业有着10年的开发/测试经验。她的工作与自动化测试工具有着密切的联系，同时还涉及参与测试策略相关的决策。
为什么要自动化?
在IT界一个普遍的观念是，在默认的情况下，自动化测试将提高测试的质量。
这个观念的真实性如何？
正像世人皆知的习语所述，“说话看场合，做事看时机”，自动化测试也是要看时机和场合的。
在以下情况下，自动化通常是一个不错的选择：
1.
重复性测试
 一个需要定期执行重复测试的系统，就是一个很好的自动化的对象。例如，为了支持项目必须对每一个项目需求或用户需求执行回归测试 。在这种情况下，手动测试的投入往往是巨大的，而且容易出错；而自动化确被证明是非常有效的。
选择一款带有版本控制库的测试工具来管理测试脚本，这样做是明智的。
自动化的成本和脚本创建初期的投入通常都高于手工测试，必须加以分析这项投资的回收期有多长。以下一些忠告有助于做出自动化的决策：

l
预计重复测试多少次，持续多久？脚本的“生命”越长，则暗示越有利于自动化的程度。
l
自动化测试工具的成本多高？
l
需要多少时间/精力才能创建出脚本？自动化不是简单的录制和回放，为了达到预期的结果，可能需要大量的设计和编码。
l
预计需要增加测试脚本的变更吗？
l
团队的测试成员需要工具的培训吗？

“重复测试=>自动化”是一条经验法则，但这并不是一成不变的。一方面是昂贵的自动化的部署设置（工具）；另一方面则是，快速投放构建之后进行匆忙的手动测试，而且你可能会发现，即使你期望的一定数量的重复性测试也无法用自动化实现。

2. 手动不可行的测试在某个应用部署到生产环境之前，它（自动化测试）可能是至关重要的，以确定在庞大的用户负载下如何运转，或当处理数以百万的记录时又是如何运转。
这类测试场景通常是最易被自动化所模拟。在高风险的条件下，任何一个遗漏的测试代价都是灾难性的，即使是一个不可复用的自动化测试，也可能是一个值得的决定。
3.低安全性/“人为的”缺陷自动化在某些工作方面的表现远远超过人们的预期。给自动化测试工具和测试人员各2个10000行数据的EXCLE表格并核对这两个表格的数据。不用猜就知道谁会做的更快而且准确无误。
但手工测试在其他类型的测试中更胜一筹。测试人员可以注意到测试记录之外的异常。界面是否过于杂乱？当鼠标移过按钮时是否有奇怪的闪烁？强制回应窗口背后的屏幕是否只是闪烁？
自动化仅限于测试那些程序所能执行的功能。人们（手工测试）能够观察/分析的所有事务并不都能被程序化，因此，在查找缺陷时，自动化测试将会有所遗漏。问题来了：那些遗漏的缺陷是否很重要？一个不稳定的系统可能不具备自动化的条件，因为严重的“手工”缺陷也可能被忽略。自动化更适用于“手工”测试发现缺陷较少且严重等级较低的系统。

结束语

值得牢记的一点是，自动化测试与手工测试也不是一个进退两难的选择。二者结合也能奏效。在一个多步骤的工作流中，测试中的某些步骤也许适合做自动化，而不是整个流程。那么仅仅自动化那些可以得益于自动化的步骤吧。

This is a guest article byShuchi.
Shuchi is a principal consultantin a multi national corporation and has ten years of development/testingexperience in the IT industry. She has worked closely with test automationtools and has been involved in test strategy-related decisions.
In her off-work hours she writesabout cryptic crosswords. Check out her crypticcrossword guide on the blog, Crossword Unclued.
Why Automate?A prevalent belief among IT folk is that automation, bydefault, will enhance the quality of testing.
How true is that belief?
“There is a time and place for everything”, as the popularidiom goes, and that holds true for test automation too.
Certain scenarios in which automation is generally a goodoption:
1. Repetitive TestsA system that needs the same tests executed periodically is a goodcandidate for automation. Take for example, support projects that must performregression tests for every PR/CR. Manual effort in such cases tends to be hugeand error-prone. Automation can prove very efficient in such cases.
It makes sense to opt for a testing tool with a versioncontrolled repository to manage the test scripts.
The cost of automation and the initial effort investmentfor script creation is usually greater than for manual testing, and it must beanalyzed how far this investment will pay off in the end. A few pointers tohelp make that decision:

• How many repetitions of tests are     expected, for how long? A longer “life” of the test scripts tips the scale     in favor of automation.
• How expensive is the tool?
• How much time/effort will it take     to create the test scripts? Automation may not simply be record-and-play,     a lot of design and coding may have to go in to achieve the desired     result.
• Are incremental changes expected     to the scripts?
• Do testers on the team require     training on the tool?

“Repetitive tests => automation” is a fair thumb rulebut not an inviolable one. A costly automation setup on one hand andquick-to-build on-the-fly manual tests on the other, and you might just findthat automation will not be useful even if you expect a certain number ofrepetitions.
2. Manually Infeasible TestsBefore an application is deployed in the productionenvironment, it might be critical to determine how the application will behaveunder huge user load or when dealing with millions of records.
Such test scenarios are usually best simulated withautomation. In high risk conditions, where the cost of missing a test might bedisastrous, even a single-time use of automation might be a worthwhiledecision.
3. Low Severity/Probability Of “Human” BugsAutomation can perform some jobs far better than a humancan hope to do. Give the tool and the human tester two excel sheets with 10,000rows of data each to reconcile with each other. No prizes for guessing who cando it faster, without errors.
But then, humans are far better at another sort of testing.Humans can notice oddities beyond documented tests. Does the UI look toocluttered? Does the mouse flicker strangely when moved over the button? Did thescreen behind the modal window just blink?
Automation is limited to testing what it is programmed todo. Not everything that the human mind can observe/analyze can be programmed,and so, automation will miss out on capturing some bugs. The question to askis: how important are those missed-out bugs? An unstable system might not beready for automation, as severe “manual” bugs may get ignored. Automation isbetter suited to systems in which the “human” bugs are expected to be fewer andare of low severity.
In Closing
A point worth remembering is that automation vs. manualdoes not have to be an either-or decision. A mix can work. Take a multi-stepworkflow – a couple of steps might be fit for automation, not the entire flow.Automate only those steps that will benefit from automation.

 

版权声明：本文为E测翻译团队原创作品。E测中国(www.5etesting.com)网及相关内容提供者拥有5etesting.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。