测试需求明确，不会频繁变动
回归测试为主的项目
软件系统界面稳定，变动少
每次迭代需要在多平台（或多OS、多Browser）上运行重复的case。
软件维护支持周期长
手工测试无法模拟的场景。如压力测试、并发测试等
具备基础的自动化测试平台
二、以下是曾经参与过的一个项目的自动化测试框架
实现了自动更新代码、编译、打包、部署、重启服务、定时执行脚本任务，日志报告输出，自动发送邮件通知。
在自动化开始前需要确定预期，需要达到怎样的目的。而不是抽象的减少人力成本，尽可能多地发现Bug或节省时间等等。自动化测试应该是发现那些可以被工具化自动化的重复性活动而后实现的，并非100%的Case都可以自动化，测试人员的经验，逻辑判断和探索性的测试方法都不能被有效自动化。
在一般的项目中，需要保证被测版本的基本质量，可以进行大量的功能测试和压力测试。
（1）发现环境层级的缺陷。
项目系统测试阶段发现的很多缺陷，都会听到开发人员自测时没问题的，甚至在本地测试时无此缺陷 ，直接将Bug打回，标注为无法重现。这就是环境问题了，曾经遇到过一个一级菜单点选时导致子菜单错乱的问题（与其他一级菜单的子菜单混淆显示了）。经排查才知是，开发将菜单的坐标值写死了，导致换环境后无法正常识别菜单信息。这是典型的环境问题，只有通过复测才能发现。另一种就是开发自测时是在本地，而自己机器上利用管理员权限部署了一些安装包或工具，自测时也无法清楚地知道被测版本是否依赖了这些包或工具。而部署到测试环境时才发现一些问题。类似于以上的问题如果及时构建了被测版本，且自动执行了基本功能，会在正式测试前发现这些环境问题，而不是等到系统测试阶段才去排查 。
（2）尽快发现集成阶段的错误。
集成测试阶段的缺陷若未暴露出或不影响到正常流程，无法确定错误是哪个开发人员负责的模块，同时开发人员因时间问题，不能测试出大部分的潜在的集成缺陷 ，导致部署到系统测试阶段暴露出的错误，无疑更增加了开发测试的时间。如果每次构建都可以自动化执行到基本功能 ，使开发能及时地发现集成错误 ，同时也可弥补单元测试的不足，快速提供系统级的测试反馈。
原文：http://blog.51cto.com/hongz/2066800