自动化的路怎么走，让我们迈出懦弱的一步吧
自动化的路怎么走，让我们迈出懦弱的一步吧曾经我们觉得自动化很神奇，曾经我们觉得自动化很难，曾经我们觉得掌握了QTP就掌握了自动化，若干年过去后，我们看看自己还在追赶国外的技术，我们真的有那么大的差距么？我想说的是未必！
大家可以看看行业中有名的那本自动化经典之书《QTP自动化测试权威指南》（印度人写的），在没看过之前，在我没有深入自动化之前，我也觉得我们离得可能很远，但是等我看到原版，看到翻译版，我觉得just so so，技术?我们从来没有学不过别人的，而唯一缺的却是胆量！就是认可自己的想法，认可自己的判断，而不是简单的重复前人走过的道路，我们需要勇敢的面对自己的判断能力，迂腐的把责任都推给别人。
常常我们会觉得IBM、HP的测试工具代表了测试的顶端，而其实他们就不是一个测试公司，而测试产品不过也是并购别的测试工具公司。回头看看包括我自己也是如此，总是觉得国外的月亮比自己的圆！但是在我看到越来越多客户在使用国外测试软件中遇到的问题时，我开始彷徨；当我开始分析和设计自己的测试工具的时候，我也逐渐找到了信心，而我现在想说的是，我们应该相信自己，特别是当我看到恒大赢球的那一刻，我勇敢的写下了现在的这篇文章，让我们相信自己，而不要总是徘徊吧。
下面我从4方面来说说我对自动化的理解：A.为什么要做自动化手工测试逐渐被大家定义为了低技术含量的工作，而确实大规模的手工测试不但效率低下而且质量还得不到保证。通过自动化测试，我们可以解决两个问题：1.相同成本下，自动化能做的比手工更好2.相同效果下，自动化能比手工更省钱对于现在很多行业中需要短时间大规模的发布，传统的瀑布模型长周期测试已经完全不能支持，自动化测试成为了必修之课。B.自动化到底能做什么其实自动化对于现在国内的企业来说，大多数情况下，是毫无用处的，主要原因在何处？相信做了自动化测试几年后的朋友会有点感受，对一个正确的东西跑100次还是正确的，除了能够看到一个报告能够满足一下自己YY的心理想法和获得一个自我心理安慰意外，真的提高了软件质量么？没有！问题在什么地方？就是使用工具的人和使用工具的目的产生了偏差，偏差在于手工测试的设计没有达到标准，如果没有办法有效的测试用例，自动化的效果会非常的低，而另一方面为了自动化而自动化，既然没有能力控制版本变化，那么就用自动化做全面回归测试吧，这样看起来很Cool。其次自动化并不是什么高深的东西，但是往往由于在研发中没有考虑到自动化的一些需要，让自动化做起来总是那么的别扭，简单说就是总是让测试去配合开发的不规范，而不是反过来。做过单元测试的朋友应该深深理解这句话，你这个东西就做的不规范让别人怎么测，还得配合你这个来测？我们现在要做自动化，并不是简单购买个工具就行的，而是真正成熟了团队、流程、去选择自动化工具来适合自己的团队，而且购买工具只是开始，实现自动化体系才是解决问题的关键。而自动化体系的实现无非就是两种：1.招一个高手，自己内部探索实现2.通过第三方咨询模式
C． 自动化框架应该怎么做
首先要提一个问题，为什么要做自动化框架？
对于所有自动化工具来说都提供自身框架，但是这些框架都只能做到方面用户使用，却无法做到真正的自动化体系，该体系就是打通自动化与各个系统的关系，而不是让自动化执行成为自动化唯一的孤岛。
自动化体系需要体现的是从需求到研发，从研发到发布，从发布到测试，从测试到分析统计等方面的全方位自动化，将人从繁重的执行工作和收集整理数据的工作中解放出来，把精力放在设计上，这才是自动化测试的目标。而自动化框架就是要解决工具的孤岛问题，将业务和技术分离，一方面让了解技术的人可以将复杂的技术简化给业务人员来用，另一方面将周边的各个系统都整合在一起，做到全方面的自动化。简单来说例如”微信”能解决你简单的查账、支付，但是它仍然是一个信息孤岛，能不能进一步的成为账号互相支付，理财，信用卡还款等一个完全的集中式的金融中心呢？其实支付宝已经做到了部分，现在出来了一个叫做”来往”的客户端，看”来往”能做成什么样吧！
每个公司都有自己的业务特点和使用习惯，自动化框架就是在这个基础上定制一套适合自身体系的流程自动化工具，其中困难的地方是在自动化流程的梳理和自动化工具的定制方面。首先公司很难有一个能在大局上把握住自动化流程体系的人物，其次由于大多数开发都对测试并不怎么认可，所以开发一个测试工具在需求沟通上就会存在很大的问题，往往测试人员由于自身开发能力的不足导致自动化框架在架构上设计上存在较多的问题。
最终导致很多框架做出来要么是技术有余业务不足，要么就是业务有余技术不足。D . 怎么去在公司开展自动化从上面两点来看第三点就比较清晰了，对于公司来说开展自动化并不是购买一个工具，而是全方面的评估考察，来帮助公司获得最佳的ROI（投资回报比）。工具永远都是最后考虑的内容，而整个系统需要自动化支持的原因，希望达到的目标，团队的规划是首先应该考虑的，根据公司被测系统的特点和相关人员的技术情况进行自动化工具评估，再逐步进入采购后的落地。首先将关键业务通过自动化实现回归，后逐步提高自动化覆盖率并加入其它自动化模块进入框架设计。当然在这其中你可能会遇到一些困难，因为一个人很难改变行业中的某些舆论，例如：1.选一个工具就选主流吧，QTP错不了！做一个简单的事情其实用什么都差不多，适合自己情况的才是最好的，而未必是某一个工具。2.我就算不选QTP，我有别的选的么？有，但是我不知道行业的宣传导致了这个结果，我们简单的认为了QTP就是自动化，自动化就是QTP，还好最近两年Selenium的异军突起，让我们开始认可或者正视QTP的霸主地位正在动摇。3.我不选QTP招不到人怎么办？作为一个招聘企业，其实换个角度来看更容易招聘到优秀的人才，别的公司都在招聘QTP人员，这类培训或者学习的人很多，但是素质、基础其实存在相对较差的情况，而自动化本身是很简单的，学会一个自动化工具再去学习别的自动化工具非常容易，更重要的学习和理解的能力，如果招聘在这方面另辟蹊径，反而可以从众多的简历中选择出真正理解自动化测试的人员，将招聘的主动权拿在自己手里，而对于员工来说也对公司的更加认可。
最后还是来说几句心里话：主流只是现在，不是未来，在我看来谁主动进入编程开放的年代，谁掌握了未来，QTP你已经Out了，因为你的懦弱，QTP just a tool,not mind,not soul。选择工具需要正确的比较，是要有真材实料而不是小便宜策略，开放式的病毒营销对于普通用户可能有效，对于专业用户是没有用的，我们应该来拼实力而不是所谓的宣传。不要等待别人来配合你，你应该推动行业，谁走在前面，谁能收获优秀的人员，谁能获胜，选择庸俗的人员只能让你的团队庸俗，带一群猪一样的队友怎么去战胜神一样的对手！ 不错。支持下！值得学习！ 值得一顶的好文 写的不错 期待有更多的文章 云板语言组织能力一如既往的好。:loveliness: 现在很多公司都在做自动化这块，但由于前期对自动化期望太高，不经调查就投入资源去做这件事，往往都夭折了。还有许多人或略了自动化测试不适用于快速迭代项目。一般都是报着试试看的态度，投入三两个人去做这件事。需求变更都跟不上，等自动化这边可以有产出的时候项目结束了。 顶贴的。云哥写的实在棒 有深度 妖西！ 不错，顶一下，陈老大 刚接触自动化，一切尽在学习中………… 老大的语言果然犀利，我喜欢这句话：带一群猪一样的队友怎么去战胜神一样的对手！ 每个公司的测试点与环境不同，所以需要的工具也不同。
建议按照公司的需求，自己开发小工具去自动化比较符合需求特点 自动化的路，任道重远 支持一下 写得不错{:4_101:} 写得很好 但不够实质 顶，希望能看到更精彩的文章 经典好文章。 格式有问题啊！帮你改过了~~ 这看你怎么看待自动化的，你希望自动化帮助你发现问题？OK，请提供严谨的开发流程，控制版本偏差，需求变动，让测试参与前期规格制定，提出易测性的需求，并且保证自动化的投入，否则的话，还是回归手工测试吧，自动化顶多给你提供一些小工具小便利，能达到半自动化就了不起了。
