自动化

忘记原文在哪了，当时没要求填写原文地址

1.什么是自动化测试？

自动化测试，顾名思义就是自动完成测试工作。通过一些自动化测试工具或自己造轮子实现模拟之前人工点点/写写的工作并验证其结果完成整个测试过程，这样的测试过程，便是自动化测试。自动化测试，看上去很美，感觉好像是第一次工业革命，它开创了以机器代替手工劳动的时代，实则不然,因为每一个自动化测试的case都是从手工测试做起的，如果没有手工测试的基础，是没法进行自动化测试。

2.自动化测试有什么优势和劣势？

自动化测试的优势：
  1.替代大量手工机械重复性劳动
  2.提升回归测试效率
  3.利用无人值守时间频繁执行测试
  4.高效实现某些手工测试无法完成或者代价巨大的测试类型，如关键业务7x24小时持续运行的系统稳定性测试和高并发场景的压力测试
  6.保证每次测试执行的操作以及验证的一致性和可重复性
  自动化测试的劣势：
  1.不能取代手工测试，只能替代手工测试中执行频率高、机械化的步骤
  2.远比手工测试脆弱
  3.自动化测试的开发工作量远大于单次手工测试
  4.自动化测试仅能发现回归测试范围内的缺陷
  5.测试的效率依赖自动化测试用例的设计及实现质量
  6.初期自动化测试用例开发效率低
  7.业务知识和自动化技术需要紧密结合，才能高效开展自动化测试
  8.自动化测试开发人员需要具备一定的编程能力

3.什么样的项目适合做自动化测试？

有以下几个特点的项目比较适合自动化测试：
  1.项目需求稳定，不会频繁变更
  2.研发和测试周期长，需要频繁执行回归测试
  3.需要在多种平台上重复运行相同测试的场景
  4.某些测试项目通过手工测试无法实现，或者手工成本太高
  5.被测软件的开发较为规范，能够保证系统的可测试行
  6.项目资源足够（自动化不是一个人完成的，需要一帮人长期维护）

4.被测系统适合在哪些环节做自动化测试

自动化测试覆盖的范围很广：单元测试、集成测试、接口测试，GUI测试等等都可以实现自动化执行；同时，不同的系统情况是不一样，有的适合或是可以做GUI的自动化测试,有的可能只适合做接口的自动化测试,所以需要针对不同的被测项目,考虑具体在哪一个环节作自动化测试。比如说针对搜索引擎，前端往往比较简单，只是一个文本框和提交按钮，大部分的逻辑处理都是在后端完成的，这种情况做自动化的接口测试就可以达到事半功倍的效果；如果是被测系统有很多的页面操作，那么可以考虑GUI的自动化测试；以上这两种情况都不是绝对的，如果测试资源足够，那么在各个环节都是可以开展自动化测试的。此外，还有一点需要考虑的是自动化测试的可行性，比如说对一个系统而言，做GUI测试是最合适的，也是最有效，但是有可能通过各种工具或者是脚本很难实现GUI的自动化测试，那么就需要考虑变通，考虑是否可以将自动化测试调整到接口测试或是集成测试等环节。

5.使用什么测试工具、测试框架？

假如你已经确认了XX 项目适合做自动化测试，那么接下来你要做的就是选测试工具了。
  首先要先确认你所测试的产品是桌面程序（C/S）还是web应用（B/S）。
  桌面程序的工具有：QTP、 AutoRunner
  web应用的工具有：QTP、AutoRunner、Robot Framework、watir、selenium
  由于B/S架构的诸多优势，早几年前大量C/S架构的应用转为B/S结构。从而也推动了web开发与测试技术的发展。假如，被测试有产品是C/S架构的，那么推荐QTP ，QTP在UI自动化测试领域占到了一半的试用率。所以，足以说明QTP在自动化领域强大，易用性等。学习主流的工具也可以使你获得更多的机会。市面上关于QTP的书籍也非常丰富。当然，要想学好QTP ，你必须要掌握VBS脚本语言。
  如果，被测产品是B/S 结构，那么推荐selenium ，为什么不是QTP 或其它工具？因为selenium 对B/S应用支持很好，更重要的一点，它支持多语言的开发，真正的试用selenium ，你所要掌握的不仅仅是一个工具而已，你还需要学习一门语言。我为什么要选择selenium？还要学一门语言，这无疑增加了我的学习成本。增加成本的同时，也增加的你的竞争力，而且，在这个过程中你不单单只是学会了一个自动化工具而已，你完全可以使用所学的语言去做更多的事情。好吧！假如你决定试用selenium 了之后，你又面临了一个新的问题，选择一门语言。selenium 是支持java、python、ruby、php、C#、JavaScript 。
  从语言易学性来讲，首选ruby ，python
  从语言应用广度来讲，首选java、C#、php、
  从语言相关测试技术成度（及 资料）来讲：ruby ,python ,java
  或者你可以考虑整个技术团队主流用什么语言，然后选择相应的语言。

6.开展自动化测试需要哪些资源（包括：人员、机器、时间）

确定了使用何种测试工具、测试框架，就需要确定需要的资源，如：需要几个自动化测试工程师、需要购买的测试工具、测试机（服务器、客户机）、以及开发自动化框架所需要的时间；

7.怎么编写自动化测试用例，如何将自动化测试用例和手工测试用例相辅相成

用例选型注意事项：
1、不是所有的手工用例都要转为自动化测试用例。
2、考虑到脚本开发的成本，不要选择流程太复杂的用例。如果有必要，可以考虑把流程拆分多个用例来实现脚本。
3、选择的用例最好可以构建成场景。例如一个功能模块，分n个用例，这n个用例使用同一个场景。这样的好处在于方便构建关键字测试模型。
4、 选择的用例可以带有目的性，例如这部分用例是用例做冒烟测试，那部分是回归测试等，当然，会存在重叠的关系。如果当前用例不能满足需求，那么唯有修改用例来适应脚本和需求。
5、选取的用例可以是你认为是重复执行，很繁琐的部分，例如字段验证，提示信息验证这类。这部分适用回归测试。
6、选取的用例可以是主体流程，这部分适用冒烟测试。
7、自动化测试也可以用来做配置检查，数据库检查哦。这些可能超越了手工用例，但是也算用例拓展的一部分。项目负责人可以有选择地增加。
8、如果平时在手工测试时，需要构造一些复杂数据，或重复一些简单机械式动作，告诉自动化脚本，让他来帮你。或许你的效率因此又提高了。

用例转型注意事项：
1、首先测试人员应该了解脚本是怎么替代人工来执行用例。
2、当你写自动化测试用例时，你需要意识到你的用例是写给一个“智障人士”执行，执行对象是脚本。
3、当前的测试用例前置配置信息要写清楚。
4、每一个步骤都要衔接好，错了，脚本要报异常。
5、每一个步骤要做什么，验证什么要写清楚，写具体。有时一个检查点，你只需看一眼，但是脚本要写一堆代码去验证，这样的做法是不可行的。
6、用例之间不要有关联性，自动化测试开发同样是软件开发工程，脚本编写同样提倡高内聚低耦合的理念。
7、不是每一个步骤都需要验证点。
8、别在多个地方重复相同的验证，除非有必要。
9、开门记得要关门，配置信息要回归原点，否则脚本要迷路。
10、当你设计自动化测试用例时，难免对一个用例的功能点加加减减。不要因此而剪掉了一些验证点。因为手工用例+自动化用例=1