测试开发大势所趋
1、互联网在深耕细作的发展阶段需要测试发挥更多的影响。
2、技术在测试工作中的占比无限的趋近开发。
3、建立学习型和成长型的测试团队。
4、持续关注个人的成长，测试人员更注重价值体现。
PPT解读： 1、互联网是快速发展的行业，时刻需要idea迅速的转化为生产力。频繁迭代的开发，追求建立快速的响应机制，要求测试的时效性。较短的测试排期需要加入技术成分从而替代手工回归测试所带来的工作量。
2、测试是技术岗，测试环节的上游是代码产品，对上游环节的摸索和尝试是不可拒绝的。测试人员越来越了解和参与开发职位的工作既可以起到测试前置的作用也可以扩大测试的范围。测试和开发必将在未来融合。
3、测试团队需要持续发展的节奏，技术成长是其中的重要一环。学习型的团队最具竞争力、战斗力和向心力。
4、功能测试是互联网时代产物，也会随着时代的发展而消亡。测试人员普遍存在危机感，对于测试技术的学习和成长要求是迫切的。测试人员越来越不满足于手工测试所带来的成就感。
自动化技术的应用场所
1、功能回归测试、冒烟测试。
2、数据精度要求高的测试，数据计算、比较、统计测试。
3、简单重复的大批量测试，测试组合众多，需要测试覆盖。
4、疲劳测试。
5、接口、底层、代码测试。
6、其他不便于进行手工的测试。
PPT解读： 自动化测试是个较大的范畴，所有不用手工进行操作通过程序驱动的测试都可以理解为自动化测试。从技术层面来讲，但凡被技术实现的东西都可以被技术模拟和测试。在人们实践的过程中，自动化技术应用的领域会越来越广，测试也是一样，自动化本身不会去约束方式和行为，自动化能够做什么会超出我们的想象。
POP的自动化领域
1、平台SOA化
2、大数据量和云计算
3、数据挖掘
4、移动互联网
PPT解读： O2O做为2014年京东的战略在POP端会持续发酵。平台的发展需要模块化，越来越来可适配。公共模块直接会被底层服务化，而前端模块大量的被暴露数据接口，更多的测试要求在不可视化的情况下进行。POP的发展积累了庞大的历史数据和商家数据而且还在增长，对于海量数据进行迁移、计算、合并、修改和数据挖掘，需要精准的完成数据测试，需要倚赖自动化测试。虽然移动端未在POP中应用，但是商家说不定哪天就有在手机上管理商品的需要，移动端在POP的布局现在没影，但是需要的时候也会很迅猛，这些都需要我们未雨绸缪。
为什么需要测试框架
1、降低实现门槛。
2、统一技术风格。
3、量化测试成果。
4、底层前端分离。
PPT解读： 没有测试框架也可以实现自动化。每个测试人员技术背景不尽相同，擅长的语言、脚本、实施的技术水平参差不齐，没有框架约束技术实现和风格，他人的维护难度会很大，不利于大家朝同一个技术方向进行分享和交流。 框架本身已经封装了很多实际需要的接口和工具，测试人员不需要花费大量的精力再度开发，集中精力快速实现测试需求本身。统一的结构不仅多人可以同时维护一个项目，也便于测试结果的分析和汇总，众多项目的批量运行。框架和项目的分离，使双方各自影响的范围得到有效控制，便于项目单点维护和迁移。开发需要框架，同样测试开发作为一种开发活动也需要框架。
功能测试人员做自动化
1、实践为主培训为辅
2、差别化培养
3、测试意识的转化
4、触发危机意识
5、考核标准
PPT解读： 1、开展定期的技术培训，包括灌输测试理念，扩展测试思路，培训新的测试技术。培训更多的是了解和灌输理念。重点是实际的动手。培训只占个人成长的10%，需要制定挑战性的任务，让每个人主动亦或是被动的去动手完成，在动手的过程中发现问题解决问题。技术是练出来的，而不是培训出来的。
2、功能测试人员中个人水平和意愿不尽相同，对有一定技术能力或者有强烈自动化愿望的人重点培训，开小灶，单独辅导，让他们成长的更快一些，对没有自信或者对自动化产生疑虑的人，起到示范带头的效果。
3、功能测试人员需要在日常测试中转化意识，一个需求过来先考虑如何用自动化实现，当不能实现的时候再考虑手工测试，人们往往按照自己熟悉的方式进行，但是不一定是最好的方式，自动化做的多了，意识转化的也就越快。 4、测试行业本身的竞争很激烈，需要让测试人员意识到这一点。 5、放在KPI中进行考核，效果是不容小觑的。
自动化效果体现
1、测试前置效果体现
2、测试范围效果体现
3、Daily Test 和批量执行效果体现
4、其他指标
PPT解读： 1、接口和单测可以通过BUG数量进行衡量。这个阶段所发现的BUG含金量更高，修复的成本更低，更有价值。此外代码行数、用例数量、代码覆盖率也可以很好的统计测试实际的效果。
2、自动化可以解决以往手工不能进行的测试，比如大数据量、中间件、随机数据等测试，可以列举由于引进自动化而增加的各种测试类型。
3、100个用例执行一次体现不了什么，但是100个用例在后续的两个月里执行了100次，所替代的人工就是很可观的。自动化项目坚持每日BUILD，一方面可以及时发现问题，维护更新用例。另一个方面每日测试的汇总数据也是自动化测试效果的展示。可以通过邮件、报告进行测试项目和用例的数据汇总，如果达到一定的量级还是很震撼的。
4、自动化还有代码行数，编译次数等指标。放在部署有平均部署时间，放在数据有平均一次生成数据量等。前端自动化不宜用BUG数量来衡量，因为主要选取的相对比较稳定的业务线和模块。
自动化开展的步骤
1、特殊测试需求响应
2、重点业务线全局自动化
3、其他业务线局部自动化
4、流程性约束
5、技术分享和外部推广
PPT解读： 自动化的开展需要的有重点、分步骤的进行。既要保证效果，又要体现团队的技术提升，分成两条线，各不冲突。
1、对于特殊的测试需求，比如大数据量、中间件、复杂的底层服务和技术接口、高性能组件等对技术能力要求较高的测试需求由专门的自动化组来承担。一方面集中优势力量可以快速完成任务，另一方面挑战性的任务可以实践和摸索新的测试方法，积累新的技术经验。
2、重点业务线可以选择一个，偏中间件和接口，或者功能测试人员尚未覆盖的业务线，由自动化组承担。目前的人力来看，可以独立承担一个业务模块全部测试，避免混用投放功能测试人员和自动化测试人员。作为试验田从代码编写到最后的上线，由自动化全覆盖，进行整体流程的尝试和布局，方便快速产生短期效果。自动化人员也可以避免不会长期脱离业务线。
3、其他业务线在统一培训之后，使用框架根据自己的业务特点在局部开展自动化，各自形成独立的项目。后续会尝试接入Matrix或者开发自己的平台和容器，进行整体项目群的维护和管理。随着自动化覆盖度的慢慢提升，长期效果将会展现。
4、长期效果的展现的同时需要在测试流程上进行一些制约，比如测试报告上面增加自动化的选项和测试覆盖，比如开发提测前需要先进行自动化的冒烟测试等，保证自动化长期有效的实施。
5、整个技术团队有了自动化显著提升，可以推广到其他团队，可以进行跨部门的技术交流。
自动化目前还需要什么样的条件
1、稳定的测试环境
2、独立的业务线
3、多样的技术测试人才
4、团队共识 PPT解读： 1、测试环境的稳定是自动化成败的关键。不稳定环境会使效果大打折扣，掩盖本应该发现的很多功能问题，会使自动化的实施有很强挫败感。同时本地调试和远程批量运行，同样对环境的稳定性有较高的要求。如果有足够的条件，可以为自动化量身一套环境，测试数据相对独立，也避免和手工测试互相干扰。
2、专门的自动化测试人员需要拥有独立的业务线，一方面防止长期脱离业务，闭门造车。另一方面可以在业务线上不受干扰的实施自己的思路。
3、需要更多的测试人才。内部挖潜，从目前来看，难度很大，很多人在技术方面是一张白纸，也无法为技术测试提供更多的支持。如果有社招的机会，选才第一标准还是技术，标准定得高一些，好的技术人才还是非常难得的，相较业务也需要很长的时间才能培养出来。随着自然的新陈代谢，整个团队的技术水准也会有所提升。
4、从领导到员工对自动化开展要尽量达成共识，大家有共同的努力方向。一个人的成功不算成功，团队提升才是最重要的。虽然每个人的水平有高有低，但是本着不抛弃不放弃的原则，希望带动每个人都有所成长。让周围人变的足够优秀，让测试快乐起来，才是我们做自动化的真正意义。
本文出自 hanlingzhi 的51Testing软件测试博客：http://www.51testing.com/?547282
最新内容请见作者的GitHub页：http://qaseven.github.io/