某项技术方案是否投产时，会考虑什么？
日常的研发流程中，我们会遇到多种差异问题，版本差异，配置差异，数据环境差异，大大增加了工程师的时间损耗。但当出现一个方案 “还不错” 就意味着它其实满足了一部分需求。
我们不以简单的投产公式计算花时间写脚本是不是值得，或者去评估研究某技术栈是否有必要学习。就黑盒测试来看，UI 自动化是值得做而且需要长期做的。况且自动化集成还能够帮忙完成耐久性测试、性能基准测试等靠叠加人工无法完成的工作。
但是 UI 自动化的实施过程中往往会遇到各种各样的问题，查找元素麻烦、session 不稳定、误报率高、工具链集成难度高，等等。而且 UI 是最上层，业务等因素会导致 UI 变更频繁，维护成本高，覆盖粒度也不好把控，造成用例灾荒。这些也同样是 Macaca 团队长期以来遇到并且一直在解决的。
还需要说的是，大规模 UI 自动化与本地跑一个 demo 是两码事。这需要配合一定的系统分层测试，越下层覆盖度会越高，数据接口层的覆盖率可以很高。但实践起来有相当的门槛，基础设施需要开发和长期维护，中大规模团队做比较适合。
话说回来，同样的语言、框架还是工具，不同的人会有不同的用法和使用深度。就此讨论下去就偏题啦，去实践就好。
测试正面临全栈化，需要掌握的技术栈也越来越多。与此同时还要在日常的研发、测试工作中总结和沉淀个人的方法论。以往测试被少数人看作开发辅助，这是完全片面的，测试需要从方案的全局思考，从架构的整体看待问题，要求高于开发。还需要不拘泥于哪个语言，还是什么工具，而是关注当下问题的最优解法。
自动化测试的本质并不是表面意义的 “代码测代码”，而是 “软件开发”，自动化是对工程师能力上的补充。然而实施自动化的时候思维关注点很容易被分散，难以聚焦。而且不容易辨别什么是 “测试方案”，什么是 “辅助测试” 手段。
大部分用例可以在开发提交测试之前编写，为 TDD 奠定基础，相对框架更有价值的是那些基于标准沉淀下来的测试用例。另外，测试用例需要考虑模块化、可测试性、数据驱动等现实问题，这些也是同样容易被忽略的。
先说这么多，接下来分享技术细节。
欢迎讨论，互相学习。
微博: http://weibo.com/xudafeng
Github: https://github.com/xudafeng