让我们看看要交付的Aur构建版本的数目和复杂度。如果你只是要得到一个普通规模和复杂度的项目的一个构建版本，进行测试自动化可能就没什么好处。实际上如果只在维护期重用一次(这样情况很少见)，测试自动化就根本不合理。即使项目本身相对复杂点，如果重构建版本的数目和测试的交付物只限于修补，也不值得花时间进行自动化。
如果该项目将重复地被交付测试，而新的特征集将在多个测试间隔交付．且特征集很复杂，自动化测试可能会有很大益处。普遍接受的看法是自动化测试要花费执行手工测试的3～4倍的时间。如果你能在项目早期预先判定会有超过3～4个重要的可测试构建版本交付给你，那么你的项目就可选择自动化测试。
没有奇迹的组合或精确的公式能决定何时应该和不应该执行自动化。以下几点可供考虑。
·AuT中的特征集本身是简单还是复杂?
·AuT中的特征集在开发过程和阶段中是否会改变很大?
·AuT中的特征集当前是否按需求所述工作?
·AuT中的特征集是否需要大量的数据组合来确认所有业务规则?
·自动化测试使用的测试工具是否能与用于测试目的的特征的所有必要属性交互?(例如，它是否能像用户一样交互?我们是否能从GUI和 子对象获得所有必要数据?)
如你所见，这些问题很复杂且难判断。总的来说，这里有一些实践准则，可用来决定是否进行自动化测试。
1)如果AUT不复杂且不太大．不要自动化。
2)如果你只将接收几个(3个或更少)构建版本，不要自动化。
3)如果一个特征不是100％·有效，不要对它执行自动化测试，不管该Aur的规模或复杂度如何(你可以为它制定计划．但不要创建真的自动化测试脚本，除非该特征能够完成并100％有效)。
4)如果开发周期的时间表很紧，每次交付间隔时间很短，你就没有时阿自动化。
5)如果一个特征不能通过自动化测试达到100％准确测试，就不要进行自动化了，除非它能节省大量的手工测试时间。这并不意味着特征必须要100％的测试。注意软件测试几乎不可能覆盖到AuT的每个特征。不要妄图达到这个目标。你执行的测试不应该是主观的。结果应是可预见的，而且应该能指出通过或失败的条件。
文章来源于领测软件测试网 https://www.ltesting.net/