第一，需求稳定，不会频繁变更

第二，研发和维护周期长，需要频繁执行回归测试

第三，需要在多种平台上重复运行相同测试的场景。

第四，某些测试项目通过手工测试无法实现，或者手工成本太高。

第五，被测软件的开发较为规范，能够保证系统的可测试性。另外，某些用例的自动化必须要求开发人员在产品中预留可测试性接口，否则后续的自动化会很难开展。

第六，测试人员已经具备一定的编程能力。

可以说，如果满足了以上十点，大部分的测试工作都可以通过自动化来完成了。

1. 任务测试比较明确，不会频繁变动

这个意思是说，你要测哪些内容，有哪些测试任务、工作，这些工作都要周而复始去做，不容易变动，而且，未来的很长一段时间都需要做这些工作。这样，这个工作长期来看，工作量就很大，也将有大部分的要进行自动化开展的工作，包括重复性劳动

2. 持续的构建持续构建就是每日构建，每天都有一个版本或者隔两天一个版本，这时候也就意味着回归测试的任务比较重，所以这时候可以考虑用自动化。

3. 繁琐的回归测试

比较频繁的回归测试与第二点可以相对应，

4. 软件系统界面稳定

软件界面稳定，变动较少的时候，也就是界面元素稳定下来了，这个时候，UI自动化自然就可以开展了。

5. 跨平台测试

应用需要跨平台运行吗？在Windows测试一遍，又要去Linux去测试一遍，甚至还有安卓、iOS平台，每个平台相同的功能都去测试一遍，都是重复性的劳动。

6. 软件维护周期长

软件维护周期长，这个维护时长到底是多长呢，没有固定评判标准，依赖于实际情况。但是，对于周期特别短的，就很容易分辨出来。如一个项目就三个月，开发自动化测试就需要两个月，然后用了一个月就丢掉了，这种情况毫无疑问不适合。与其费力开发自动化，不如直接上人工就可以了。因此软件维护周期较长，版本迭代较多，适合用自动化。

7. 项目进度压力

项目进度压力决定了是否允许去投入自动化开发，需要考虑自动化测试的投入产出比。前期是需要投入人力、精力，如果项目进度压力不大，就可以在合适的时机介入自动化工作。

8. 被测软件（系统）规范性

被测试软件（系统）的规范性，也决定了其可测性。例如单元测试、接口测试、UI测试等，如果前期能够规范开发，考虑并兼容自动化测试介入，那么自动化测试开展起来就较容易。如果前期没有按照规范做，就会在后期自动化开展过程中造成很多问题。问题越多，可测性就越低。

9. 自动化平台

测试团队掌握大量的自动化工具，如QTB、UFT、Robot、RFT、Selenium等。而这些工具需要大量储备的技能、框架，才能开展、支撑自动化测试。如果团队里面全是手工，要开展自动化，很明显是不现实的。

10. 较强的编程能力

较强的编程能力，这是什么意思？不能单一的认为测试就是动动手指，来回点点，也并不是简单的录制和回放。我们需要一定的开发能力，既能够做简单的录制脚本，也能够对脚本就行一定的修改，进行二次开发。在这个过程中沉淀、输出符合我们团队、项目的自动化思路、框架。因此，测试人员应该具备一定的编程能力。

测试任务明确，不会频繁变动，比较频繁的回归测试，软件系统界面稳定，变动少。需要在多平台上运行相同的测试用例，大量重复任务

如上图所示，真正工作中无法全部满足以上条件，所以需要作出权衡，一般来说，只需要满足以下几点，就可以对项目开展自动化测试（图中红色框标注的选项）

可以参考以下几点：

测试任务明确， 不会频繁发生变化

每日构建后的测试验证

比较频繁的回归测试

软件系统界面稳定，变动少

需要在多平台上运行相同的测试案例、组合便利型的测试，以及大量的测试任务

软件维护周期长

项目进度压力不太大

被测软件系统开发较为规范，能够保证系统的可测试性

具备大量的自动化测试平台

测试人员具备较强的编程能力

自动化测试是，把人对软件的测试行为转化为由机器执行测试行为的一种实践

第一，需求稳定，不会频繁变更。

第二，研发和维护周期长，需要频繁执行回归测试

• 
  

1. 在我看来，软件产品比软件项目更适合做自动化测试。首先，软件产品的生命周期一般都比较长，通常会有多个版本陆续发布，每次版本发布都会有大量的回归测试需求。同时，软件产品预留给自动化测试开发的时间也比较充裕，可以和产品一起迭代。其次，自动化测试用例的执行比高于 1:5，即开发完成的用例至少可以被有效执行 5 次以上时，自动化测试的优势才可以被更好地体现。

• 
  

1. 对于软件项目的自动化测试，就要看项目的具体情况了。如果短期的一次性项目，就算从技术上讲自动化测试的可行性很高，但从投入产出比（ROI）的角度看并不建议实施自动化，因为千辛万苦开发完成的自动化用例可能执行一两次，项目就结束了。我还遇到过更夸张的情况，自动化测试用例还没开发完，项目都已经要上线了。所以，对于这种短期的一次性项目，我觉得你应该选择手工探索式测试，以发现缺陷为第一要务。而对于一些中长期项目，我的建议是：对比较稳定的软件功能进行自动化测试，对变动较大或者需求暂时不明确的功能进行手工测试，最终目标是用 20% 的精力去覆盖 80% 的回归测试。

第三，需要在多种平台上重复运行相同测试的场景。

*1.对于 GUI 测试，同样的测试用例需要在多种不同的浏览器上执行；
2.对于移动端应用测试，同样的测试用例需要在多个不同的 Android 或者 iOS 版本上执行，或者是同样的测试需要在大量不同的移动终端上执行；
3.对于一些企业级软件，如果对于不同的客户有不同的定制版本，各个定制版本的主体功能绝大多数是一致的，可能只有个别功能有轻微差别，测试也是需要覆盖每个定制版本的所有测试；

第四，某些测试项目通过手工测试无法实现，或者手工成本太高。

• 对于所有的性能和压力测试，很难通过手工方式实现。比如，某一个项目要求进行一万并发用户的基准性能测试（Benchmark test），难道你真的要找一万个用户按照你的口令来操作被测软件吗？又比如，对于 7×24 小时的稳定性测试，难道你也要找一批用户没日没夜地操作被测软件吗？这个时候，你就必须借助自动化测试技术了，用机器来模拟大量用户反复操作被测软件的场景。当然对于此类测试是不可能通过 GUI 操作来模拟大量用户行为的，你必须基于协议的自动化测试技术

第五，被测软件的开发较为规范，能够保证系统的可测试性。

如果要实现稳定的自动化测试，被测软件的开发过程就必须规范。比如，GUI 上的控件命名如果没有任何规则可寻，就会造成 GUI 自动化的控件识别与定位不稳定，从而影响自动化测试的效率。

另外，某些用例的自动化必须要求开发人员在产品中预留可测试性接口，否则后续的自动化会很难开展。

• 比如，有些用户登录操作，需要图片验证码，如果开发人员没有提供绕开图片验证码的路径，那么自动化测试就必须借助光学字符识别（OCR）技术来对图片验证码进行模式识别，而它的设计初衷是为了防止机器人操作，可想而知 OCR 的识别率会很低，就会直接影响用例的稳定性。

第六，测试人员已经具备一定的编程能力。

1.如果测试团队的成员没有任何开发编程的基础，那你想要推行自动化测试就会有比较大的阻力。这个阻力会来自于两个方面：
前期的学习成本通常会比较大，很难在短期内对实际项目产生实质性的帮助，此时如果管理层对自动化测试没有正确的预期，很可能会叫停自动化测试；
2.测试工程师通常会非常热衷于学习使用自动化测试技术，以至于他们的工作重点会发生错误的偏移，把大量的精力放在自动化测试技术的学习与实践上，而忽略了测试用例的设计，这将直接降低软件整体的质量。

①需求稳定，不会频繁变更

自动化测试最大的挑战就是需求的变化，而自动化脚本本身就需要修改、扩展、debug，去适应新的功能，如果投入产出比太低，那么自动化测试也失去了其价值和意义；

折中的做法是选择相对稳定的模块和功能进行自动化测试，变动较大、需求变更较频繁的部分用手工测试；

②多平台运行，组合遍历型、大量的重复任务

测试数据、测试用例、自动化脚本的重用性和移植性较强，降低成本，提高效率和价值；

③软件维护周期长，有生命力

自动化测试的需求稳定性要求、自动化框架的设计、脚本开发与调试均需要时间，这其实也是一个软件开发过程，如果项目周期较短，没有足够的时间去支持这一过程，那自动化测试也就不需要了；

④被测系统开发较为规范，可测试性强

主要出于这几点考虑：被测试系统的架构差异、测试技术和工具的适应性、测试人员的能力能否设计开发出适应差异的自动化测试框架；