有想法，可以实际中使用有限制。
不如 7 楼说的直接用 jmeter，而且 Jenkins 中有现成的 jmeter 插件，报告也有了～
ps:貌似京东的某团队的接口测试就是 jmeter＋jenkins

inpsect 的时候会访问 chrome-devtools-frontend.appspot.com:443 这个地址。
但由于伟大的长城的存在，这个地址有时候会无法访问，所以会弹出一个空窗口了。

原文：http://www.april1985.com/2014/02/16/2014-02-16-chrome-remote-debugging-blank-webview-inspect-window/

ps：本人已确认

#10 楼 @uncle_mm
不要做的没有思想的工具，～～
do the right thing～

#8 楼 @uncle_mm
转换一下思维，结果导向。做自动化为的是减少手工嘛？貌似不行哦，是为了快速回归一些主要的常见的功能或场景，那么就看看哪些功能或场景，能最快实现即可。
用例形式不要受手工的影响，因为自动化不能替代手工。

#3 楼 @jack1785 公司现在在北四环，清华科技园玉泉慧谷。正在准备搬家，年后会更靠近市区

#9 楼 @kevin_xu_v
其实最到最后，基本上除了真实的开发业务逻辑之外，整个架构从硬件到软件，从与 boss 谈判到动手搬机房，从人员招聘到团队稳定建设，真真的统统摸索了一遍。在国内来说，团队不够成熟的话，ui 自动化测试没有半年以上的迭代周期，可以先别碰了。

成本太大的话不走自动化也是一条路

大家想法都是一样的，不赚钱的买卖都是没有必要的～ *

说说我们的经历吧。
三年前
背景：一个传统软件做 UI 层面的自动化测试
没有 CI，手工打包，没有 UT，jquery4 个版本混用....
开始做自动化测试，前先花了三个月左右（中间还有其他事情）的时间，使用 jenkins＋ant 实现自动打包，不能算 CI
然后一个月左右开始给大领导和其他利益相关群体做 “洗脑” 工作。半个月之后，得到结果开始执行，但是必须要有可量化的指标:

1. 自动化测试覆盖率＝ 自动化测试覆盖的手工测试用例／手工测试用例总数 这其中有很大的问题，之前的用例根本就不是良好的用例。没有上下文，没有数据，
2. 自动化测试的价值＝自动化测试执行的时间／自动化测试代替手工测试的时间 这个还算客观，但是它依赖前一个指标

好了开始做了，

第一个问题：没有环境

怎么办？折腾以前淘汰的机器定制环境（先是 xp，后来统一升级到 win7）

第二个问题：环境不能自动部署

工程是跟 tomcat 耦合在一起的；而且 linux 部署还不成功！！
折腾 autoit，实现 windows 上的自动更新，自动部署（后台跟 webqq 做关联，qq 上发个消息就能自动部署了，还能查询状态和系统信息）

第三个问题：没有测试用例，也没有可使用的数据，这是一个大坑

又话费了接近三个月的时间，才梳理出来一个关键模块的测试用例（基于 BDD 的）跟它的数据。中间还返工了一次，因为版本更新，用例重构了。
然后陆陆续续花费了接近两个月的时间才准备好了相关数据。制定了以后数据准备的方案

第四个问题：人员能力差

这个问题从开始就很明显！没办法，招人，一边独自做，一边招人，来来回回折腾了 5 个人，最后一个人稳定了两年多。中间做了不下十次培训，文档写了至少三遍

第五个问题：版本也在更新，前台重构，对应的底层控件经常出妖怪问题

这些问题，有产品自身的可测性问题；也有 webdriver 的妖怪问题。
导致我们架构重构了两次，并分别做了针对不同版本的适配（主要是前台控件的操作适配）

简单来说是这些，还有很多与其他利益相关体的扯皮的因素（你懂得，有人的地方就有江湖）。这样一晃接近两年的过去了。
最终我们达到一个什么效果，不到 20% 的覆盖率，但是效果很明显。最先实现的那个模块（功能逻辑相对固定），从两年前开始到现在都是 bug 最少的！

现在

虽然换个团队，换个产品，以互联网的方式设计产品，设计架构。但是考虑到成本问题，毅然决然的抛弃了 UI。到目前为止只做接口测试。

啰啰嗦嗦写了不少，目的只有一个，别做收益不够的投资！

ok 了

果然，上传图片不行。
photos POST 500 Internal Server Error text/html