关键字驱动的过去和未来(4)

　　2.作为一个软件，易用性和复杂度总是成反比的，当框架提供了方便的表格化编写case功能时，也相对的增加了底层的复杂度(虽然没看过robot framework的代码，但是相信底层代码的分层也应该比较复杂)，对于想要真的掌握框架的团队来说，无形中增加了一道门槛。另外，复杂度与可扩展性也是成反比的，就像我可以用木头做一辆车，也可以把木头车拆了做些别的东西，但是我没法把一辆汽车拆了弄成别的东西——前两年广东美院那位把解放卡车拆了做成关公像的牛人除外。当然，最终实施自动化时到底如何进行框架选型，就要团队自己在易用性/复杂度/可扩展性上进行评估了。

　　3.把excel里面的manual test case通过新的关键字驱动直接变成可执行的脚本是最好的方法吗?这似乎只是一个传统system test 的惯性思维在作怪，为什么没看过开发人员把unit test 也写到一个个表格里面?为什么manual test case 就一定要先写在excel里面，而不是一开始就是代码?

　　4.如果仅仅是考虑把 step组装起来，再把case组织成suite执行，其实代码实现上可以说毫无技术含量，但是对于一个没有开发经验的tester来说，这毕竟是一个跟 coding简单亲密接触的机会，可以让tester从低难度的代码开始培养兴趣和信息。而keyword，无论新的还是旧的，却剥夺了这个机会;当 tester希望学习框架的时候，会发现表格的层面跟下层框架之间的不是楼梯，而是一道沟。

　　3. “关键字驱动”的未来

　　我们如今所处的环境总是在变化着，今天与10年前相比，最大的变化就是测试行业获得了极大的发展，大多数企业都认可了测试工作的重要性，并且开始思考如何提升测试工作自身的质量和效率，而且不同规模的企业都在探索着合适自己的研发流程和技术;而tester们的技术能力也在不断增强，至少能写代码的人比5年前多了很多。当然，还要感谢开源世界带来的众多框架、组件，让自动化的门槛不断降低。

　　就像传统的关键字驱动已经远去一样，新的关键字驱动未来会如何，大家讨论吧。:-)

原文转自：http://www.uml.org.cn/Test/201501065.asp