开头先声明一点 自动化测试 的本质是提高人工测试的效率。但是他不能完全代替人工。

本文就以下几点阐述以下本文的主题

一.不是所有项目都可以自动化
二.自动化测试的特点
三.自动化测试的误区
四.如何组建自动化测试团队

不是所有项目都可以自动化

  时间就是金钱

现在的互联网 机遇稍纵即逝，产品的的不断迭代才可以为公司找到一条合适的发展道路。有些活动更是‘千变万化’之后才带来差强人意的转化率。所以项目紧周期短是必然的！在复杂多变的业务需求中我们再去整理一套万能的自动化测试方案，显然是不合理的，这个时候还不如人工点击效率高。

但是这样我们就抛弃自动化了吗？

答案显然是否定的。

举个栗子：

某网周年庆活动，活动有20个分会场，每一个分会场的品类，促销以都是不同的。而且这个里面的商品也是在不每天不断变化的，第一天可能送的是品类券，实行了3天发现效果一般，然后改送平台券+满赠，但是新增了一种规则部分商品不能同时享受2种以上的促销，而且商品是动态的。这个时候对于自动化测试的用例来讲业务的变动导致他们还没有来得及修改代码，这个时候在去写自动化测试的代码显然时间不够了，这个时候还是先人工检查和审核 比如新增了20个品可能10分钟就都可以检测完成。

但是 在这种变化的过程中可以提炼几个要素去做自动化测试

1 现有逻辑是新增的 那么之前的品类满减和促销规则 是不变的 这个时候只需要执行现有的case即可

2 在用户下单的过程中登录注册部分领取优惠券部分都是固定不变的。这个时候也可以执行原有的case(如果后台代码模块分离则不需要执行)

不适合自动化的项目类别

1 外包类项目，这些项目做完以后是交付给客户使用，后期改动很小

2 一次性项目，生命周期端，业务模式简单 不适合自动化

3 复杂的游戏项目，大量的复杂的逻辑运算，需要人为的控制很多场景，在某些时候不适合自动化

4 硬件交互的，基于硬件的产品只能做到部分自动化。

5 项目形态不稳定，代码中有很多隐藏的BUG，带着很多BUG上线的项目，不适合立刻做自动化测试

总结一下：对于频繁变动项目，或者是只有一次性活动的项目，没有任何必要写自动化去保障他后续的回归测试。但是多变的项目也有一些不变的业务场景，对于这类场景可以提炼自动化的基本CASE

自动化测试的特点

1.所有测试都是用来发现BUG，自动化测试也不例外，只是更快的发现BUG。

2.自动测试远比手动测试脆弱，无法应对被测系统的变化，“开发手一抖，自动化测试忙一宿”，这也从侧面反映了自动化测试用例的维护成本一直居高不下的事实。其根本原因在于自动化测试本身不具有任何“智能”，只是按部就班地执行事先定义好的测试步骤并验证测试结果。对于执行过程中出现的明显错误和意外事件，自动化测试没有任何处理能力。

3.自动化测试用例的开发工作量远大于单次的手工测试，所以只有当开发完成的测试用例的有效执行次数大于等于5 次时，才能收回自动化测试的成本。

4.自动化测试仅仅能发现回归测试范围的缺陷。测试的效率很大程度上依赖自动化测试用例的设计以及实现质量，不稳定的自动化测试用例实现比没有自动化更糟糕。实行自动化测试的初期，用例开发效率通常都很低，大量初期开发的用例通?；嵩谡鲎远馐蕴逑党墒?，和测试工程师全面掌握测试工具后，需要重构。业务测试专家和自动化测试专家通常是两批人，前者懂业务不懂自动化技术，后者懂自动化技术但不懂业务，只有二者紧密合作，才能高效开展自动化测试。自动化测试开发人员必须具备一定的编程能力，这对传统的手工测试工程师会是一个挑战。

适合自动化的项目类别

1.需求基本稳定，不会频繁变更

2.核心逻辑基本不变，项目周期长，需要大量的回归测试

3.在各种平台上都要进行相同的测试场景。

自动化测试的误区

转自 乐搏软件测试

1、自动化的软件测试与手工的软件测试过程一样自动化测试所需要的技巧与手工测试所需要的技巧是不一样的。通常，你的项目经理会被那些测试工具销售们迷惑，认为自动化的软件测试就是简单地按一个录制的按钮，产生测试脚本。而事实上并没有那么简单。区分自动化测试所需要的技巧与手工测试所需要的技巧是非常重要的。最重要的是，自动化测试工程师需要掌握软件开发技巧，没有接受任何培训的手工测试人员，或者没有编程背景的手工测试人员，在实施自动化测试时会碰到很多困难。

2、自动化测试一定会马上大量减少测试人员数量自动化测试不会马上大量减少测试人员数量。因为开展自动化测试初期需要投入一定的人力进行自动化测试脚本开发，并逐渐将自动化测试脚本用于日常的测试中，逐步减少手工测试人员从事重复劳动的时间和人数。为了缩短自动化测试脚本的开发时间，可以考虑将自动化测试脚本的开发工作借助外包的力量来早日实现大规模的自动化测试。

3、测试自动化就是录制和回放仅仅录制得到的不是有效的自动化脚本。很多项目经理仍然把测试自动化等同于使用录制回放工具。而事实上，录制得到的脚本通常是不可重用的脚本，脚本中充满了硬编码的值，这些值应该被参数化，否则脚本仅仅适用于一个测试情况，脚本还应该加入条件判断、循环等结构，以便增强测试脚本的灵活性。

4、自动化测试找不到bug自动化测试不直接找bug，而是通过解放有经验的测试工程师的生产力，让其从重复的回归测试中解放出来，从事新的测试方法和测试手段的研究。通过自动化测试解放出测试人员的时间和精力来间接地找到更多、更深层次的新bug，将产品质量再提高一个档次。

5、自动化测试工具是“万能”的很多人一听到自动化测试，就认为自动化测试工具可以完成一切测试工作，从测试计划到测试执行再到测试结果分析，都不需要任何人工干预。显然，这是一种理想状态，现实中还没有哪个测试工具有这个能力，并且将来也不会有。在现实中有关的测试设计、测试案例，以及一些关键的测试任务还是需要人工参与的，即自动化测试是对手工测试的辅助和补充，它永远也不可能完全取代手工测试。

6、自动化测试工具容易使用对于这一点，很多测试工程师有同样的错误观点，认为测试工具可以简单地通过捕获（录制）客户端操作生成脚本，且脚本不加编辑就可用于回放使用。事实上，自动化测试不是那么简单的，捕获的操作是否正确，以及脚本编辑是否合理都会影响测试结果。因此，自动化测试需要更多的技能，也需要更多的培训。

7、自动化能提供百分百的测试覆盖率并非所有内容都可以被自动化地测试到。不可能覆盖所有可能的输入，所有可能的组合和路径。自动化测试可以增加测试的广度和深度，但是仍然无法达到100%的测试覆盖率，因为没有足够的时间或资源。

8、忘记了测试的最终目标：找到BUG在自动化测试中，同样要注意把边界值分析、等价类分析、基于风险的测试方法、挑选最合适的测试用例等技术应用起来。通常在自动化测试过程中，我们都忙着搭建自动化框架和编写测试脚本，但是我们往往忘记了测试的本来目的：找bug。项目经理可能雇佣了最好的自动化开发人员来搭建框架，使用了最新最好的自动化开发技术，创建了成千上万的自动化测试脚本。但是如果BUG仍然被遗漏了，那些本该被自动化测试脚本捕捉到的BUG，结果没有被捕捉到，那么你的自动化测试仍然会被认为是失败的。

9、所有测试用例都可以自动化不是所有的测试用例和测试步骤都可以转化为自动化测试。在自动化测试投入较多的行业，领先企业的自动化测试率有的能达到80%左右，但仍有20%左右的测试用例需要手工来进行。在国外，通常从开发第一版测试用例时，就同步进行自动化测试脚本的开发，所以自动化测试率普遍比中国企业高。10、只有性能测试才需要自动化自动化测试不光进行性能测试，更被大量应用于功能测试验证，在国外超过半数的自动化测试脚本都是用于功能验证测试的。

11、测试工具可适用于所有的测试每种自动化测试工具都有它的应用范围和可用对象，所以不能认为一种自动化测试工具能够满足所有测试的需求。针对不同的测试目的和测试对象，应该选择合适的测试工具来对它进行测试。在很多情况下，需要利用多种测试工具或者开发自动化测试框架才能达到自动化测试的目的。商业和开源的测试工具能够用来进行自动化测试，但是我们需要根据自身产品的特点，开发自动化测试框架，在框架中提供常用的测试用例，加快测试速度，达到测试用例复用，这是今后测试自动化发展的道路。

12、自动化测试能发现大量新缺陷发现更多的新缺陷应该是手工测试的主要目的，不能期望自动化测试去发现更多新缺陷。事实上，自动化测试主要用于发现原来的缺陷。自动化测试用于回归测试，而大量的新业务测试更多地还是依赖手工测试。除了以上列举的常见误区外，还有其他不同的认识误区。自动化测试认识误区的产生，归根到底最本质的原因是由于对自动化测试不现实的期望，也就是期望过高造成的。如果没有建立一个正确的软件测试自动化的观念，认为测试自动化可以完全代替手工测试，或者认为测试自动化可以发现大量新缺陷，或者不愿在初期投入比较大的开支等，则自动化测试一定会让我们大失所望。

如何组建自动化测试团队

1 组内培训

如果测试团队的成员没有任何开发编程的基础，那你想要推行自动化测试就会有比较大的阻力。这个阻力会来自于两个方面：前期的学习成本通常会比较大，很难在短期内对实际项目产生实质性的帮助，此时如果管理层对自动化测试没有正确的预期，很可能会叫停自动化测试；

测试工程师通?；岱浅Ｈ戎杂谘笆褂米远馐约际?，以至于他们的工作重点会发生错误的偏移，把大量的精力放在自动化测试技术的学习与实践上，而忽略了测试用例的设计，这将直接降低软件整体的质量。所以在培训的同时也要更好的设计测试用例。

2 手工测试双备份

公司在不具备完全自动化测试的能力之前，每一个业务部门至少要配备2个能够设计好测试用例的同学，通过他们的手工测试提高产品质量，在后期可以提供测试用例给自动化测试小组，完善自动化测试小组代码的覆盖率，两者结合共同提高。

3 优化产出

在主流程覆盖到一定的面的时候，其实已经解放了一半手工测试同学的生产力，这个时候可以优化人员分配，集中将人员提供给变动频繁需求较大的项目组。

4 全员自动化
在项目情况允许的情况下督促开发自己写自动化测试脚本，完备的单元测试更加能够提高产品的质量，减少项目在线事故的发生。

附送一个随手整理的学习大纲

自动化测试的学习步骤

第一 、了解测试
1.1 测试用例
1.2 测试范围
………………

  介绍

第二、 在充分认识测试的前提下 学习前端语言---WEB基础

    2.1 HTMl介绍
    2.2 HTML常用标签
    2.3 HTML框架 和表单    
    2.4 CSS的基本介绍
    2.5 CSS选择器
    2.6 CSS定位
    2.7 CSS--DIV布局
    2.8 JS的基本介绍
    2.9 JS函数
    2.10 JS的对象
    2.11 JS的BOM和DOM

第三 、 python的学习

  3.1 什么是python
  3.2 python命名规则
  3.3 数据类型
  3.4 流程运算符
  3.5 函数
  3.6 文件操作
  3.7 面向对象
  3.8 异常处理
  3.9 模块化

第四 、 数据库的学习

  4.1 数据库的基本介绍
  4.2 Nivicat 和Mysql的使用
  4.3 数据库的增删改查
  4.4 聚合查询和分页查询
  4.5 mysql和python交互

第五 、 selenium的学习

 5.2 框架介绍
 5.3 浏览器的操作
 5.4 元素的定位和等待时间设置
 5.5 selenium的常用类介绍
 5.6 selenium截屏和断言
 5.7 selenium日志系统

自动化测试实施阶段

阶段一：需求收集——分析自动化测试需求

1.对被测试的系统进行总体描述
2. 分析出哪些项目是可测试和可自动化的
3. 评估哪些测试可以自动化
4.对自动化软件测试和测试中需要的工具进行评估，并提出建议
5.给出可以自动化的测试的建议报告
6.数据需求的初始化测试阶段

二：测试用例设计和开发

１.明确手头上的任务以及自动化的相关的目标
２.考虑风险，确定缓解风险的策略
３.如果存在手动测试用例和过程，对其进行评估，考虑是否重用或转换为自动化测试
４.定义自动化软件测试的架构和设计５.定义并开发测试数据
６.走查一遍自动化软件测试测试用例／过程，并确定优先级
７.记录要自动化的高层次测试用例，以及详细的测试步骤
８.按照阶段／优先级、时间表来实现测试用例
９.过一遍自动化软件测试的架构和设计
１０.更新时间表---确定进度表

阶段三：开发自动化软件测试框架和测试脚本

1.搭建自动化测试框架，开发新的满足测试用例需求的脚本
2.测试环境
    1.)验证所使用的测试数据的有效性，即考虑测试数据的深度和广度
    2.)验证与各种业务规则或访问权限接触的数据集是正确的
    3.)确定测试环境的具体配置，考虑留出时间订购硬件
    4.)进行性能测试活动时，测试环境反应了产品环境，或者确定使用用于构建初始功能测试的虚拟环境是有效的
4.大致走查一遍自动化测试用例
5.走查一遍测试环境配置

阶段四------自动化测试的执行和结果报告

1.理解并遵循准入和准出的标准
2.从开发环境中隔离出测试环境
3.执行自动化框架和测试脚本
4.记录每个测试运行的通过或失败状态
5.遵循缺陷跟踪生命周期，生成软件问题报告，跟踪缺陷直至关闭
6.跟踪效率和进度

测试阶段五----审查和评估程序

1.完成自动化软件测试自动化工作
2.记录经验和教训
3.进行任何问题的根源分析和采取适当的措施
4.最终的自动化软件测试项目报告，包括到目前为止讨论的所有相关工作，如：状态指标、各种测试结果、根源分析等