好运，外企英语很重要 (不是那种都是中国人的)

问下 google 是哪个产品用啊

十年测试路过，从手工测试到 UI 自动化到接口自动化又回归手工测试

哈哈哈，加入的同学逃过了今年的发红包啊

恩，地点加上

赞，让我想起键盘打 fifa 的日子

规范可以逐步引入，类似现在工程的迭代，每个阶段形成一些文档，里面制定一些必要的规则，充分沟通得到老大的支持；大公司也是逐步推进的，就像我目前的产品，经过了 4 年才把整个流程做得顺畅，随着人员的进出，隔段时间还需要对新进人员进行培训

日上免税行，听着很高大，居然不租办公室

V5，小伙加油

我先看看不说话

换一个文风写，你就是手拿多个 offer 如何选择的帖子了

金融软件得努力啊，p0,p1bug 都有，好多检查项

很详细，赞下。

1. 不干这么 low 的事情
2. 可以爆负责人

要分解细讲啊，北京的沙龙可以每期安排一讲了～

TesterHome 论坛 管理规范、干活多~~~

公司台式 ubuntu， 笔记本 mac air，家里 T400 win7

补充下，请报名的同学实名制，因为拿到入场券的同学我会帮她办理环球金融中心的电梯访客卡，这个卡需要在前台出示身份证领取。

#17 楼 @actionwind ，

1. 元素变更并不能说明被测程序的不好也不说明测试脚本不好，恰好说明维护成本高。我们让开发来参与 webdriver 的编写可以让开发了解 UI 自动化，提高可测试性，比如过去开发对元素不命名或不给 ID，通过编写 webdriver，有了开发的配合，加上 debugid，可以让元素定位更便利，但这种行为并不是每个开发都能做到或者说一直坚持。
2. timeout 正好说明 webdriver 不好的一面——耗时，也无法体现被测程序的好坏以及测试脚本的好坏。UI 自动化可以很好的模拟用户行为，但是在前端很多关联依赖的情况下，一个用例跑完用时很长，可以增加等待时间，不过会极大的消耗硬件成本。
3. 关于 Flaky，@chenhengjie123 已经提到，在做浏览器兼容性测试会经常碰到，各个浏览器速度不一样。
4. 测试团队如何在资源有限的情况下更高效，比如我的测试团队只有 3 个人 (Google 里开发测试比 10 比 1 很常见)，测试团队参与各种类型的测试，那么在 UI 自动化应该投入多少呢，在实践中需要不断调整，你是愿意让你的团队成员每天陷入维护 UI 自动化还是做更多其他类型的测试。
5. 软件质量是一个全员的工作，不是独立的，测试无法保证质量，测试提供及时的反馈和警示风险，开发才能保证质量，在明确的需求下，开发的代码质量是最关键的，如何让开发认识到质量的重要性，推动开发的质量意识，是一个长期的工作。