已经开始实践过一些selinum的自动测试，发现要维护好一个简单的case消耗的精力远远大于获得的回报。但是这个值得（技术能力）深入学，工具无好坏优劣之分，只有适合不适合。在网上看了很多关于自动化测试的文章，现摘录一二：

以下内容引自：2014年自动化的个人感想
自动化技术的应用场所
1、功能回归测试、冒烟测试。
2、数据精度要求高的测试，数据计算、比较、统计测试。
3、简单重复的大批量测试，测试组合众多，需要测试覆盖。
4、疲劳测试。
5、接口、底层、代码测试。
6、其他不便于进行手工的测试。
PPT解读： 自动化测试 是个较大的范畴，所有不用手工进行操作通过程序驱动的测试都可以理解为自动化测试。从技术层面来讲，但凡被技术实现的东西都可以被技术模拟和测试。在人们实践的过程中，自动化技术应用的领域会越来越广，测试也是一样，自动化本身不会去约束方式和行为，自动化能够做什么会超出我们的想象。
为什么需要测试框架
1、降低实现门槛。
2、统一技术风格。
3、量化测试成果。
4、底层前端分离。
PPT解读： 没有测试框架也可以实现自动化。每个测试人员技术背景不尽相同，擅长的语言、脚本、实施的技术水平参差不齐，没有框架约束技术实现和风格，他人的维护难度会很大，不利于大家朝同一个技术方向进行分享和交流。 框架本身已经封装了很多实际需要的接口和工具，测试人员不需要花费大量的精力再度开发，集中精力快速实现测试需求本身。统一的结构不仅多人可以同时维护一个项目，也便于测试结果的分析和汇总，众多项目的批量运行。框架和项目的分离，使双方各自影响的范围得到有效控制，便于项目单点维护和迁移。开发需要框架，同样测试开发作为一种开发活动也需要框架。
自动化效果体现
1、测试前置效果体现
2、测试范围效果体现
3、Daily Test 和批量执行效果体现
4、其他指标
PPT解读： 1、接口和单测可以通过BUG数量进行衡量。这个阶段所发现的BUG含金量更高，修复的成本更低，更有价值。此外代码行数、用例数量、代码覆盖率也可以很好的统计测试实际的效果。
2、自动化可以解决以往手工不能进行的测试，比如大数据量、中间件、随机数据等测试，可以列举由于引进自动化而增加的各种测试类型。
3、100个用例执行一次体现不了什么，但是100个用例在后续的两个月里执行了100次，所替代的人工就是很可观的。自动化项目坚持每日BUILD，一方面可以及时发现问题，维护更新用例。另一个方面每日测试的汇总数据也是自动化测试效果的展示。可以通过邮件、报告进行测试项目和用例的数据汇总，如果达到一定的量级还是很震撼的。
4、自动化还有代码行数，编译次数等指标。放在部署有平均部署时间，放在数据有平均一次生成数据量等。前端自动化不宜用BUG数量来衡量，因为主要选取的相对比较稳定的业务线和模块。

以下内容引自：QA请勿忘初心
大部分QA或者tester，仍然以UI自动化为重心。之所以反对盲目的UI自动化测试，因为变化频繁的UI设计，极低投入产生比，都应该让我们重新思考下UI自动化的价值。
我们需要一个实施UI自动化正确的方式：
能不用UI自动化测试就不用，梳理业务主线，只保留用户操作最频繁，交互最多的场景。
根据面向对象设计的原则，构建适合项目的UI自动化框架，无论自己编写框架，还是采用开源框架。
尽量采用独立测试数据，确保运行测试不受影响。例如采用mock数据库或者每次运行时还原测试数据库。

作为一个QA，我们不仅要检测项目中存在问题，也要改进团队的实践活动，更重要的是预防问题的发生。
每次bugbash或相应迭代完成后，要分析统计，找出产生缺陷的环节，并采取措施防止问题再现。例如每次release或者bug bash之后,我可以按照功能模块与bug类型进行统计划分，分析统计bug的成因，例如某次迭代我们bug数量激增，经调查，发现我们对某些模块的前端代码进行了重构，但缺乏相应的单元测试与集成测试，造成了我们没有及时发现bug。之后我们就对应的采取措施防止问题再现。
总结分析报告，及时反馈这些信息给团队。总结分析是一个长期的任务，每次bug数量的变动，都会直接体现整个团队上次迭代的开发质量，例如bug数量减少了，可以鼓励成员再接再厉。或者某几次迭代某些模块bug成上升趋势，那么就需要组织团队一起讨论问题根源，采取措施防止问题重现。

利用代码质量分析工具帮助我们尽早预防问题的发生。例如sonar代码质量管理平台，可以帮助我们从代码复杂度，重复代码，单元测试覆盖率，编码规范等纬度来分析我们代码所存在的问题。当然也有其他的开源工具，像RubyCritic，/plato不同的语言都会有相应的工具。
在线监控，利用像newrelic，airbnb等监控工具对部署在本地或在云中的web应用程序进行监控、故障修复、诊断、线程分析以及容量计划。这样就算们产品环境有任何问题，我们都会及时响应，尽早修复，减低损失。

以下内容摘自：自动化测试总结

4.合适引入自动化
项目周期长，系统版本不断，并且需求不会频繁变更，此时是适合引入自动化测试的。
系统的测试对象基本可以正常识别，以及对无法识别的控件能否提供一个解决方案。
系统中不存在大量的不可识别第三方控件。
需要反复测试，如可靠性测试、回归测试等需要进行上千次的系统测试。

5.不适合自动化
项目周期短，需求频繁变更。即使是周期长的项目，如果经常需求变更，也不适合做自动化。
软件版本还没有稳定的情况下，主功能或大量功能有被重新更改的可能话，也不适合做自动化。
没有明确的项目测试自动化计划，措施和管理。
多数对象无法识别，以及脚本维护频繁与艰难，二者有其一，自动化必定失败。

基于以上前人走过的路，目前我们单位自动化的需求（也可以说是我自己的，空余时间研究）包括：
1、当前生产发版的发版节奏由最初的一周一次变为20-30天一次，产品功能趋于稳定，测试人员2个，上线前回归压力大。如果可以自动回归测试，将解放不少生产力，当然自己的技术能力也能进阶。
2、自动化测试作为回归的正向验证切入运用场景，即自动化的验证功能是对的。
3、后台涉及用户使用频率最高的两个功能模块：商品管理和营销工具。