DevOps之工具选择
序 言
谈起敏捷，很多人并不陌生，可能你的公司依旧在使用瀑布开发模式，可能已经转型为敏捷或者DevOps，也有可能正在处在这个转型期。不可否认的是，这个开发模式已经越来越热，甚至很多在几年前接触到但是抵触敏捷开发模式的公司，现在也慢慢的开始转型。从互联网公司到银行，从欧美公司到国内企业。
本人在上述三种“可能”的公司里都工作过，也帮助过一些公司从瀑布模式转型敏捷，有了一些经验。工作之余喜欢思考，这里就和大家分享一些个人的想法和遇到的事情。希望大家多多指教，互相交流。
本文是受身边一个朋友经历的事情所启发，针对当下企业转型DevOps中，工具的选择进行的探讨。大家可以忽略故事中工具的名字，因为这里只是来做论证用，不是做广告。
如以上内容涉及版权或原创作者有不同见解之处，敬请及时告知，乐于接受并给予修正。
目 录
1 概述
本文是要通过在一个故事中，H公司是如何选择自动化测试工具的，来探讨DevOps下自动化工具的选择策略，并不是推荐一个合适的工具给您。
2 故事
这是一个真实的故事。
一个朋友在外企H做测试工作，这个测试部门成立了十几年，大部分的人是做手工测试的，不懂编程。现在H公司也想让所有懂业务的员工参与进自动化，全民编写自动化用例。问题来了，选择哪个自动化测试工具呢？起初尝试过QTP和selenium，不过他们没有编程基础，天天工作任务又很重，没有时间学习，所以自动化没有搞起来。后来一个合作公司推荐他们使用Tosca。公司让每个员工先自己用起来，过一段时间看看效果。
这里简单介绍下Tosca，这是一个印度公司做出来的工具，不需要懂编程，甚至连xpath都不需要你自己去写，工具可以直接捕获浏览器上的元素然后通过它自己的简单的选项就可以进行操作了。看到这儿，相信很多人和我一样，觉得这种方式并不适合自己，毕竟亲手编程比较随意自在，使用你集成好的功能，对于我来说并不方便。我想，过段时间他们就应该会转回selenium吧。
3 意想不到的结果
结果当然和我想的不一样。过了一段时间后，朋友把Tosca研究透了，H公司内也大加推广Tosca。不久前，H公司亚太地区的技术部门召开一次分享会，由朋友向美国总部分享她们部门是如何使用Tosca的。在分享会上她说道：“现在都谈DevOps，我理解的DevOps就是更快更好地交付产品。在我们部门，大部分的都是英语专业毕业的，不懂编程。要是让我们这些懂业务但是不懂编程的人去学习selenium，可能光培训学习就得用个一年半载的，耽误工作进度不说，质量也难以保障。学习Tosca使得我在依然不懂编程的情况下用这个工具能做自动化测试。现在我已经达到了能完成当前项目的自动化测试。对于其他技术较强的公司来说可能更适合selenium，毕竟selenium市场占有率在90%以上说明了现状。但是对于我们部门，这个工具更合适，更能让我们实现快速的交付。学习了一个月的UI测试后，我现在准备开始下一步进行接口测试了。”
4 DevOps工具的选择
我这个朋友并没有专门去学习敏捷或者DevOps的理论，她说的话只是根据她的实际经验，总结为什么这个小众的工具能在他们部门快速的使用起来时想到的。我们总说搞DevOps，自动化工具的使用一定要跟得上。那么选择什么样的工具来为我们公司服务呢？是选择市场占有率高的呢还是选择功能更强大的呢？其实都不是，要的是哪个更适合我们。这个适合需要综合考虑，包括符合公司的技术和业务要求，财政要求，安全要求，但是更多的时候我们忽略的是员工的使用成本，因为不管工具怎么样，效果最终来自于员工使用起来怎么样。人是一种情感动物，如果每日的工作中，受使用工具所累，就会渐渐产生厌烦的心理；相反如果他能掌控这个工具，帮助他轻松自如的完成当前的工作，那么他很大概率上还会进一步研究这个工具更深的操作，完成更高级的任务（就像朋友完成UI测试后，自发的去学习接口测试，正由于第一步的成功，让他有了信心和动力去学习以前反感的技术方向。）
如果一个工具让员工的学习成本更低，较之前的工作风格改变的更少，那么公司换工具的这个成本就更低，这个工具就是当下更适合的。
5 题外话
引申来看，我们帮助一些公司做敏捷或者DevOps转型的时候，是不是也要考虑这点？如果一个团队一次性引入很多新工具，学习成本本身就很高，在压缩了员工的正常工作时间的情况下，又打击了他们学习的积极性，对于转型这个事情来说，就增加了新的阻力。所以我们是不是可以分阶段引入一个一个的新工具？在做了流程改变的情况下，是不是可以先用熟悉的工具然后再在工作中慢慢引入新工具？
- 点赞
- 收藏
- 关注作者
评论（0）