你为什么要写自动化测试？为什么该选择用人工测试而不是自动化？什么时候该做这样的选择呢？事实上，几乎所有的测试工程师早晚都要面对的问题就是是否选择自动化以及自动化测试的程度。如果你只打算执行一次测试，根本没有必要自动化。可是，如果你打算测试两次呢？这也不意味着你应该使用自动化。有些软件在发布之前或者在维护阶段，可能需要执行上百次，上千次，甚至百万次的测试。有些因素有助于在具体环境下  准确地评估自动化的益处。如下是其中几个需要考量的因素：

投入

确定创建自动化测试的投资回报率（ROI--Return On Investment）的第一步是确定要花费的投入和成本。 有些种类的产品或功能的自动化很简单，而其他的自动化却不可避免得很麻烦。例如，应用程序编程接口（API--Application Programming Interface）测试，以及别的通过编程对象的方式 展现给用户的功能测试，对其自动化往往都能够直截了当。而在另一方面，用户界面（UI--User Interface）的自动化测试常会遇到问题而需要花费更多的精力。----注---需要考量自动化的实施成本，难度太大的自动化不值得采用。

测试的生命期

一个自动化测试在变得无用之前将会运行多少次？对测试的长期价值的评估是决定是否对某个特定的场景或者测试用例实现自动化的考量的一部分。要考虑被测试的产品本身的使用寿命和产品开发周期长度。对于短期内就要发布而且将来不打算更新的产品，和对于两年后要发布将来也会有多次更新发布的产品，自动化的选择必须是不一样的。----注---短期内即可结束且后期不再多次迭代的软件项目，自动化可不必采用。软件周期较长，会经历多次迭代过程，自动化对于后期的回归测试会很有帮助。

价值

要考虑自动化测试在其生命周期内的价值。有些测试人员说测试用例的价值是找到缺陷，但是很多自动化测试所找到的缺陷是在测试第一次运行时或者在写自动化测试时发现的。当缺陷被修复以后，这些测试成为了回归测试——确认最近的改动不会导致以前能够正常运行的功能停止工作。很多自动化测试技术通过改变测试用的数据，或者改变每次测试运行路径的方法，从而在测试的生命期中继续找到缺陷。对一个生命周期很长的产品来说，不断增长的回归测试套件有很大的优势：随着底层软件功能越来越复杂，存在大量的能确认以前工作的功能能够继续工作的测试是极为有用的  。----注---对于后期需要多次迭代，或者项目完成后需要长期维护并进行版本更新的项目，自动化的实施有很大价值，便于后期的回归验证。

切入点

我目睹的许多成功的测试自动化项目都是测试团队从最开始的时候就参与了。代码写到尾声或者完成之后才开始想到加入自动化测试的项目通常都是失败的。----注---测试团队什么时候能参与项目的自动化测试过程中、项目时间安排是否允许加入自动化实施过程、测试人员的工作负载是否允许、人力资源的投入多少等都可能影响测试人员的自动化实施工作及效果。

准确性

好的自动化测试在每次运行后会报告准确结果。企业管理层对自动化测试最大的抱怨之一是自动化测试中误报的数量。误报是指测试报告中的测试失败是由测试本身的某些问题造成的，与产品无关。项目的有些领域（例如经常变化的用户界面组件）难以用自动化测试分析，且较容易产生误报。 ----注---测试团队的自动化实施是否确定能达到预期的要求和效果、是否存在较大的技术难点和障碍等问题应该在确定是否实施自动化时加以考虑，否则有可能达不到预期的自动化测试效果，反而浪费了人力和时间。

注：本文为《微软的软件测试之道》一书10.1章节内容整理后的阅读笔记，感谢本书作者Alan Page。