Macaca [基于 Node.js 的自动化测试-Macaca] - 全栈测试时代已来
UI 自动化的乌托邦？
某项技术方案是否投产时，会考虑什么？
- 实施成本如何？
- 维护成本如何？
- 投入产出比高吗？
- 可作为中长期方案存在吗？
日常的研发流程中，我们会遇到多种差异问题，版本差异，配置差异，数据环境差异，大大增加了工程师的时间损耗。但当出现一个方案 “还不错” 就意味着它其实满足了一部分需求。
我们不以简单的投产公式计算花时间写脚本是不是值得，或者去评估研究某技术栈是否有必要学习。就黑盒测试来看，UI 自动化是值得做而且需要长期做的。况且自动化集成还能够帮忙完成耐久性测试、性能基准测试等靠叠加人工无法完成的工作。
但是 UI 自动化的实施过程中往往会遇到各种各样的问题，查找元素麻烦、session 不稳定、误报率高、工具链集成难度高，等等。而且 UI 是最上层，业务等因素会导致 UI 变更频繁，维护成本高，覆盖粒度也不好把控，造成用例灾荒。这些也同样是 Macaca 团队长期以来遇到并且一直在解决的。
还需要说的是，大规模 UI 自动化与本地跑一个 demo 是两码事。这需要配合一定的系统分层测试，越下层覆盖度会越高，数据接口层的覆盖率可以很高。但实践起来有相当的门槛，基础设施需要开发和长期维护，中大规模团队做比较适合。
话说回来，同样的语言、框架还是工具，不同的人会有不同的用法和使用深度。就此讨论下去就偏题啦，去实践就好。
工程角色的变化
测试正面临全栈化，需要掌握的技术栈也越来越多。与此同时还要在日常的研发、测试工作中总结和沉淀个人的方法论。以往测试被少数人看作开发辅助，这是完全片面的，测试需要从方案的全局思考，从架构的整体看待问题，要求高于开发。还需要不拘泥于哪个语言，还是什么工具，而是关注当下问题的最优解法。
自动化测试的本质
自动化测试的本质并不是表面意义的 “代码测代码”，而是 “软件开发”，自动化是对工程师能力上的补充。然而实施自动化的时候思维关注点很容易被分散，难以聚焦。而且不容易辨别什么是 “测试方案”，什么是 “辅助测试” 手段。
大部分用例可以在开发提交测试之前编写，为 TDD 奠定基础，相对框架更有价值的是那些基于标准沉淀下来的测试用例。另外，测试用例需要考虑模块化、可测试性、数据驱动等现实问题，这些也是同样容易被忽略的。
先说这么多，接下来分享技术细节。
欢迎讨论，互相学习。
微博: http://weibo.com/xudafeng
Github: https://github.com/xudafeng
工具开发本身就是开发了。
#1 楼 @lihuazhang 开发测试界限淡化了
#3 楼 @lihuazhang 自动化赖以生存的根基就是业务，初衷也是服务业务。技术驱动型产品不同。
#3 楼 @lihuazhang 不是的，我并不这样认为。测试本身不管是技术，还是管理，还是测试开发。都应该在测试的基础的理论和对于业务详细的理解，以及扎实的技术去做的。其实底层都是一样的
对一个测试老人来说，全栈是个伪命题，且不说功能、性能、安全、测试环境等全部，就某一项性能测试来说，横向划分：B/S、C/S、。。。，纵向划分：前端、后端，后端再划分：程序服务、缓存服务、数据库。。。，再以某一项数据库性能划分：sql 调优、分布式设计、参数调优等等，谁还有资格说全栈的。
可能说的有点尖锐，此概念误导新人，光性能测试的前端一小项，能搞出点名堂就不错了，扪心自问，经得起推敲的 “大神” 有几个。。。
如果问题已经简言之为 “退一步” 还是 “进一步”，相信这已经不是问题了
测试开发有两个重要的目标：
1，提高测试专业性
2，技术驱动提高效率
企业想要的是花 10k 请一个样样会的带一群实习生
看了文章，很多想法不谋而合，很多顾虑和实际中的问题也体现在大家下面的讨论中
Testhome 中会有很多精华的分享，这些分享给了大家新的思路也看到了各位作者的在各自公司的努力和发展
工作本身其实就是兼容并包，应该受流程和业务呈现的局限，而是效率，效率，还是效率；效率本身靠什么来提高；效率的挺高需要团队中的他，她或者某一个两个人具有全面的，扎实，落地的专业能力，依赖分层测试的一字贯通，体会每层的痛点并落地改善，整体效率才能提高，并且努力的让团队中的每个同学都能有特种兵的技能，这样的融合和讨论具体问题时的迸发才彰显有意义。
时间是检验大家团队方法论的标准，具体的方法需要持续的更新，改进
慢慢进入了全栈工程师时代
未来的方向，全栈测试
这年头哪都说全栈啊
