有很多附加因素决定何时进行自动化。以下分析是基于1996年以来在多个公司做了多个项目的实际经验。
2.2.1 自动化的时间总是第一因素
建立自动化测试项目比建立手工测试项目花费的前期时间多。自动化在开始阶段没有捷径。你必须执行所有手工测试要执行的相同步骤。自动化应在所有测试用例根据完善的需求（这是乐观的想法）定义好之后，并在AUT的一个构建版本可交付之后进行。
此外，被自动化测试的应用程序特征必须有效。如果需求或应用特征不能100%有效，就不能根据它来创建有效的完整的自动化测试。自动化测试的基本目的是一旦需求确认后，验证后继构建版本或AUT的修改版是否正确实现了需求。而且，因为自动化测试减少了执行回归测试所需的时间，这是它被认可的好处。
如果你做一个进度紧迫的项目，项目管理有非常紧张的交付进度表，你就不要考虑自动化了，除非专门为它分配了充分的时间。
2.2.2 一个极端的例子
让我们看看要交付的AUT构建版本的数目和复杂度。如果你只是要得到一个普通规模和复杂度的项目的一个构建版本，进行测试自动化可能就没什么好处。实际上如果只在维护期重用一次（这样情况很少见），测试自动化就根本不合理。即使项目本身相对复杂点，如果重构建版本的数目和测试的交付物只限于修补，也不值得花时间进行自动花。
如果该项目将重复地被交付测试，而新的特征集将在多个测试间隔交付，且特征集很复杂，自动化测试可能就会有很大益处。普遍接受的看法是自动化测试要花费执行手工测试的3~4倍的时间。如果你能在项目早期预先判定会有超过3~4个重要的可测试构建版本交付给你，那么你的项目就可选择自动化测试。
没有奇迹的组合或精确的公式决定何时应该和不应该执行自动化。以下几点可供考虑。
AUT中的特征集本身是简单还是复杂？
AUT中的特征集在开发过程和阶段中是否会改变很大？
AUT中的特征集当前是否按需求所述工作？
AUT中的特征集是否需要大量的数据组合来确认所有业务规则？
自动化测试所使用的工具是否能与测试目的的特征的所有必要属性交互？（例如，它是否能象用户一样交互？我们是否能从GUI和子对象获得所有必要数据？）
如你所见，这些问题很复杂且难判断。总的来说，这里有一些实践准则，可用来决定是否进行自动化测试。
如果AUT不复杂且不太大，不要自动化。
如果你只将接收（3个或更少）建构版本，不要自动化。
如果一个特征不是100%有效，不要对它执行自动化测试，不管该AUT的规模或复杂度如何（你可以为它制定计划，但不要创建真的自动化测试脚本，除非该特征能够完成并100%有效）。
如果开发周期的时间表很紧，每次交付间隔时间很短，你就没有时间自动化。
如果一个特征不能通过自动化达到100% 准确测试，就不要进行自动化了，除非它能节省大量的手工测试时间。这并不意味着特征必须要100%的测试。注意软件测试几乎不可能覆盖到AUT的每个特征。不要妄图达到这个目标。你执行的测试不应该是主观的。结果应是可预见的，而且应该能指出通过或失败的条件。
2.2.3 一个定量的例子
AUT的一个特征集要花6小时进行手工测试。如果执行这些测试要花6小时，那么使用自动化测试工具记录测试最少要多花6小时（很可能更多，因为你会在手工测试和测试数据/测试脚本创建之间切换）。普遍接受的看法是要另花12个小时来组织和建立自动化测试脚本。情况就是这样，这个特征集的自动化测试前期会花18个小时，是执行手工测试时间的3倍。一般来说，重新运行一个测试脚本只要手工测试执行时间的1/10。测试运行接近于机器速度，通常只受应用程序反应时间及任何插入测试脚本的延迟（比如模拟用户思考时间）的限制。
据说，自动化测试执行时间大约是36分钟。因此，在第4次对该特征集执行测试时，自动化测试开始比手工测试节省大约5.5小时测试时间，而且此后每次对这个AUT的特征集执行回归测试时都能节省同样的时间。自动化前期要花费较多时间，但在每次回归测试执行时都能迅速回报。不仅能节省时间，而且因除去人为交互因素而使得测试执行的准确性更高。
节选于《软件测试自动化》（-Just Enough Software Test Automation）（美）莫斯里（Mosley,D.J.）等著；邓波等译. -北京：机械工业出版社，2003.10
个人目的：很多测试的朋友都不知道为什么要进行自动化测试，于是我摘录《软件测试自动化》中一段话来解释这个问题，同时也希望能达到拨乱反正的目的。
