When not to automate 什么时候不进行自动化

The cornerstone of test automation is the premise that the expected application behavior is known. When this is not the case, it is usually better not to automate.

测试自动化的基石的前提是预期的应用程序的行为是已知的。当不是这种情况下，最好不要进行自动化。

Unstable design

不稳定的设计

There are certain applications that are inherently unstable by design.For example, a weather-mapping system or one that relies on real-time data will not demonstrate sufficiently predictable results for automation. Unless you have a simulator that can control the inputs,automation will be difficult because the expected results are not known

有某些固有的不稳定性所设计的应用程序。例如，天气映射系统或依赖于实时数据的一个不将演示自动化充分可预知的结果。除非你有一个仿真器，它可以控制输入，自动化会困难，因为不知道预期的结果。

Also, if you can’t control the application test environment and data,then automation will be almost impossible. The investment required to develop and maintain the automated tests will not be offset by the benefits, since repeatability will be doubtful.

同时，如果你不能控制应用的测试环境和数据，那自动化几乎是不可能的。开发和维护的自动化测试所需投资将不被利益所抵消，因为重复性将是值得怀疑的。

If your application is highly configurable, for example, or has other attributes that make its design variable, then either forget automation or focus on implementing only selected configuration profiles. Whatever you do, don’t try to reproduce all of the configurability of the application into the test library, otherwise you will end up with excessive complexity, high probability of test failure, and increased maintenance costs.

如果你的应用是高度可配置的，例如，或具有使其设计变量的其他属性，然后要么忘了自动化或侧重落实唯一入选的配置文件。不管你做什么，不要尝试重现所有的应用程序到测试库的可配置性，否则就会落得过于复杂，测试失败的概率很高，而且增加了维护成本。

Inexperienced testers

没有经验的测试人员

If the person(s) automating the test are not sufficiently experienced with the application to know the expected behavior, automating their tests is also of doubtful value. Their tests may not accurately reflect the correct behavior, causing later confusion and wasted effort.Remember, an automated test is only as good as the person who created it.

如果自动化测试的人不是足够经验与应用程序知道预期的行为，自动化测试也是价值令人怀疑。他们的测试可能没有准确反映正确的行为，导致后来的混乱和浪费的精力。请记住，一个自动化的测试只是创建它的人一样好。

If you have inexperienced testers who are new to the team, they make the best manual testers because they will likely make the same mistakes that users will. Save automation for the experts.

如果你新加入团队的是有经验的测试人员，他们做的最好的手动测试因为他们将模拟出用户所犯的相同的错误。他们可以作为储备自动化专家。

Temporary testers

临时测试人员

In other cases, the test team may be comprised primarily of personnel from other areas, such as users or consultants, who will not be involved over the long term. It is not at all uncommon to have a “testfest” where other departments contribute to the test effort. But because of the initial investment in training people to use the test tools and follow your library design, and the short payback period of their brief tenure, it is probably not time or cost effective to automate with a temporary team. Again, let them provide manual test support while permanent staff handles automation.Again, let them provide manual test support while permanent staff handles automation.

在其他情况下，测试团队可能主要是从其他领域，不会在长期参与的人员如用户或顾问组成。这不奇怪，比如在其他部门的“测试牛人”对测试工作作出了贡献。但在初始投资在训练人员使用测试工具，并按照你的设计库，获得短期投资和回收，这不是临时的自动化团队可以做到的。再次，让他们提供手动测试支持，同时有长期工作的人处理自动化。

Insufficient time,resources

没有足够的时间，资源

If you don’t have enough time or resources to get your testing done manually in the short term, don’t expect a tool to help you. The initial investment for planning, training and implementation will take more time in the short term than the tool can save you. Get through the current crisis, then look at automation for the longer term.

如果你没有足够的时间和资源，让您的测试在短期内手工完成，不要指望一个工具来帮助你。规划，培训和实施的初期投资将花费更多的时间，在短期内手工测试比使用工具更能为您节省时间和资源。度过当前的危机，再看看自动化为更长期。

 

Keep in mind that automation is a strategic solution, not a short term fix.

请记住，自动化是一个战略性的解决方案，而不是一个短期的修复。

 

转载于:https://www.cnblogs.com/Ann-L/p/4487083.html