3）运行的频度与收益的关系
每个系统的自动化开发时间固定的情况下，测试脚本程序使用的情况也是决定收益的最为关键的因素之一，现在广为流传的一种说法就是自动化用得越多则效果越好，我们就以自动化冒烟、回归测试为例，看一下这种说法是否正确并且是否有依据。
◆ 运行次数越多，分摊到每次运行所需的测试脚本程序的平均开发成本越低，而维护修改的成本则累积上升。考虑到版本测试的质量问题，冒烟测试和回归测试的越频繁越好，由此可以引申为：自动化测试运行的次数越多，版本的质量更容易保证。
◆ 假设开发一个系统的测试脚本程序需要P（常量）人日，该系统每年发版本个数为M（常量），平均每个版本的测试执行时间是N（常量）工作日，平均每X天向测试环境修复移交部署一次，必须冒烟测试，每Y（变量）天自动化冒烟测试一次，每次冒烟测试手工需要A（常量）人日，自动化需要J（常量）人日，每个版本回归测试一次，每次回归测试手工需要B（常量）人日，自动化需要K（常量）人日，每次运行因程序更新而带来的脚本程序更新需要Q（常量）人日。除去测试相关工具和硬件资源等不可变成本，按系统测试要求冒烟测试频率不得小于移交频率的要求，那么，我们能看到的人力上的效益将能通过如下公式计算：
◆ 由以上公式可知变量Y的取值影响到测试人力的投入与产出，我们带入具体的值：开发一个系统的测试脚本程序需要60人日，每年发版本15个，平均每个版本的执行时间是12工作日，平均每2天向测试环境修复移交部署一次，每2天冒烟测试一次，每次冒烟测试手工需要1.5人日，自动化需要0.5人日，每个版本回归测试一次，每次回归测试手工需要2人日，自动化需要0.5个人日（由于绝大部分使用自动化并行执行，故而与冒烟测试一致），每次运行因程序更新而带来的脚本程序更新需0.5人日。那么利用公式计算首年收益为104.43，次年收益等于104.71；如果每1.5天自动化执行一次则首年收益为74.78，次年为74.89；如果每1天自动化执行一次则首年收益为14.69，次年为14.85。这样一来，我们发现自动化执行次数越接近版本变更部署次数，则收益越大；同时我们可以知道，自动化开发完毕之后使用多少年对收益来说没有多大影响，每一年内自动化测试所能获取的利益在数字上只有很细微的差别。
◆ 我们不妨对这个公式做更多的猜测与引申，上面的公式中大部分是常量参数，如果把情况设想得稍微复杂一些，考虑的变参量多一些呢？
● 首先明确一点：在符合系统测试质量要求的前提下（冒烟测试频率不得小于系统修复移交频率），并非测试执行频率越大获取的收益越多，只有在测试执行频率等于变更移交频率的时候，收益才能最大化，而版本数量越多则受益越多。
● 如果平均每次运行和每次因维护测试脚本程序所花的时间总和超过了每次手工执行所花的时间（ A<J+Q， B<K ），那么无论如何努力，自动化也无法带来任何人力上的收益，所以要使得每次自动化运行的时间越短越好，维护所需要花的时间越短越好。
● 如果首期开发投入时间P较多则维护所花的时间Q所需较少，反之，P值越小则Q值越大，这是自动化测试脚本程序本身的健壮性所决定的。由此结合以上公式可知：如果测试环境修复版本移交的频率越大、向生产版本发布的次数越多就越应该控制维护脚本所花的时间，也就是说首期开发时必须投入相对较多的时间以保证测试脚本程序的质量。否则，即便是被减数P值很小，得出的结果也可能是负值，即，得不偿失。
● 最根本的一点，自动化测试在每次冒烟测试中的使用。如果只是任自动化测试脚本自生自灭，测试运行就不作为缺陷发现或者版本变更跟踪的手段——即，无视每次冒烟测试带来的作用，只是为了运行而运行，那么不难从上面的公式中得出这么一个结论：自动化开发基本不会带来任何效益。
4）软件成熟度与收益的关系
软件成熟度与自动化测试的关系本文在第一章第二节已有简述，它又与自动化测试收益之间有什么关系呢？笔者认为，软件开发成熟度越高，自动化测试收益越明显。原因如下：
◆ 需求管理更为科学，自动化测试脚本程序修改、维护的工作量因用户需求变更的管控而变得可控制、可估量。即便不考虑考虑其他手段带来的测试设计时间、人力的减少，只要没有因反复的用户需求导致测试脚本程序的反复修改更新，客观上也已经是一种变相的成本降低了，而成本的降低也就意味着收益的提升。
◆ 系统编码设计人员所采用的开发模式较为先进，可以轻易做到高度复用并且十分规范的软件系统开发，在这样的开发模式下，有经验的测试人员在结合需求规格很容易知道一个操作之后下一个页面上的细节会是什么样的，这样测试分析设计可以很早地介入。由于系统操作的预期结果很容易预判，自动化开发可以在设计、编码的同时进行，甚至可以领先于系统编码的进度，而且由于开发难度的降低，自动化开发速度可以大幅提高，从而自动化开发的投入可以相对少很多，开发完成之后应用的次数也会比较多。
