自动化测试理解

以下问题，可以帮助我们更深入的理解自动化测试，而不只是停留在自动化测试工具的使用上。

什么是自动化测试？

通过工具记录或编写脚本的方式模拟手工测试的过程，通过回放或运行脚本来执行测试用例，从而代替人工对系统的功能进行验证。

自动化测试和手工测试的区别？

手动测试优点：

1.在测试过程中充分发挥人的主观能动性，灵活性

2.可以充分利用发散思维和优秀的逻辑思维能力，分析能力以及判断力

3.费用小，测试用例容易维护

4.可以测试界面布局，排版，色彩等，以及用户体验

5.验证bug，测试规律性不强的issue

根据大家的经验大部分的bug是通过手动测试发现的，大大提高效率的是自动化测试，其可以日夜执行！

自动化测试优点：

1.解放人力于重复的测试，测试人员可以做更多有意义的测试

2.可以运行更多的繁琐测试，以及一些手工无法执行的测试

3.生成大量数据，快速完成大量数据的测试

4.可重复性强

5.人为因素低，测试结果更可靠

6.回归测试，提高资源利用率

什么情况下适合做自动化？

1.软件需求变动不频繁

　　测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。

　　项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。

2.项目周期较长

   由于自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成。这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。

3.自动化测试脚本可重复使用

　　自动化测试脚本的重复使用要从三个方面来考量，一方面所测试的项目之间是否很大的差异性（如C/S系统和B/S系统的差异）；所选择的测试工具是否适应这种差异；最后，测试人员是否有能力开发出适应这种差异的自动化测试框架。

你的自动化测试用例是怎么写的？什么样的用例适合转成自动化？

     自动化测试用例的来源是手动测试整理的数据，把涉及到功能的测试点和测试数据整理出来就可以了。

用例选型注意事项：

1、  不是所有的手工用例都要转为自动化测试用例。

2、  考虑到脚本开发的成本，不要选择流程太复杂的用例。如果有必要，可以考虑把流程拆分多个用例来实现脚本。

3、  选择的用例最好可以构建成场景。例如一个功能模块，分n个用例，这n个用例使用同一个场景。这样的好处在于方便构建关键字测试模型。

4、  选择的用例可以带有目的性，例如这部分用例是用例做冒烟测试，那部分是回归测试等，当然，会存在重叠的关系。如果当前用例不能满足需求，那么唯有修改用例来适应脚本和需求。

5、  选取的用例可以是你认为是重复执行，很繁琐的部分，例如字段验证，提示信息验证这类。这部分适用回归测试。

6、  选取的用例可以是主体流程，这部分适用冒烟测试。

7、  自动化测试也可以用来做配置检查，数据库检查。这些可能超越了手工用例，但是也算用例拓展的一部分。项目负责人可以有选择地增加。

8、  如果平时在手工测试时，需要构造一些复杂数据，或重复一些简单机械式动作，告诉自动化脚本，让他来帮你。或许你的效率因此又提高了。

你的自动化用例是如何来实施的？

    脚本中别光跑业务逻辑，在需要功能验证的地方,多加一些判断语句，增加一些检查点，Reporter或者写到其他日志文件。

有什么样的策略来开展自动化工作？

    我们在制定自动化测试实施策略时，首先应该考虑其中可能存在的风险。 

     1.自动化测试时间不充足

     2.对自动化测试期望过高

     3.缺乏自动化测试实施的经验

    4.自动化测试工具更新过于频繁 

    5.自动化测试工具对软件测试本身没有起到帮助作用 

    6.当我们有了针对自动化测试实施风险的准备后，就可以开始考虑： 

6.1  需要在什么阶段开始启动自动化测试？ 

    在何时启动自动化测试，每个公司的情况都不同。有的公司是在测试用例都手工执行过并且测试用例不再修改时，再开发相应的自动化测试脚本；而有的公司则是在开发测试用例的同时，就进行脚本的开发。如果团队中测试用例的设计者是一个有着丰富测试用例设计经验的工程师，他所开发的测试用例是高效的，未来改动较少，则可以考虑在开发测试用例的同时，同步开发自动化测试脚本。如果团队中测试用例的设计者是一个测试用例设计经验不丰富或是设计的测试用例质量不高效的人，其开发的测试用例需要在后期经常进行许多的改动，则还是考虑等到测试用例本身稳定后，再开始脚本开发。 

6.2  自动化测试的人力投入方式如何？ 

      大部分公司是由专人进行自动化测试脚本开发的，少部分大公司则是全民开发自动化测试脚本。这两种方式都各有利弊：专人进行脚本开发，优点是开发脚本的专业技能可以不断地得到强化，开发效率大大提高；缺点是由于对开发模块的测试用例了解并不深入，有可能开发出的自动化测试脚本只是“翻译”测试用例，发现bug的概率较小。而有的大公司，由于员工的整体素质较高，通常都具备一定的开发能力，则由每个模块的手工测试者自行开发自动化测试脚本。虽然，手工测试者脚本开发的熟练程度没有专门的脚本开发者熟练，但是由于手工测试者是最了解测试用例真谛的人，因此他开发出的测试脚本就不仅仅是“翻译”，而可能是对测试用例的“升华”，其测试脚本发现bug的概率会更大。   

    如何执行测试脚本才更高效？ 

   （1）N个测试环境同步并行执行测试脚本，可以将自动化测试脚本执行的总时间成本降低为1/N。 

  （2）由专门的自动化测试执行工程师来执行批量的自动化测试脚本。自动化测试脚本运行失败的前3大因素大致为： 测试环境问题 脚本错误 被测目标出现bug 

     由于专门的自动化测试执行工程师对大量失败的脚本分析经验的积累，通常可以非常高效地定位脚本失败的原因，提高自动化测试脚本执行的效率。 

   (3)独立的自动化测试环境供脚本执行团队使用。如前所述，测试环境问题是测试脚本失败的原因。而测试环境影响测试脚本执行的两大杀手：一个是测试环境被前一个失败脚本破坏而未还原；另一个则是测试环境被其他项目的同事给破坏了。对于第一种情况，我们可以在测试脚本的代码结构中加入足够的系统恢复代码来解决；对于第二种情况，则只有依赖于公司领导的政策支持，是否愿意腾出足够的测试环境给自动化测试执行小组专用。 

  （4）在测试脚本中加入丰富的脚本失败的定位信息。自动化测试脚本一旦失败，我们就只有依靠脚本自身打印的信息进行定位了，定位问题的速度快慢除了依赖脚本执行人员自身的经验外，更依赖脚本中是否有着丰富的脚本打印信息。 

  （5）使用自动化测试基线软件版本。当出现大批量测试脚本失败的情况时，可以在排除了测试环境问题后，直接把这些失败的测试脚本在基线软件版本中运行。如果在基线版本中运行全通过了，则证明脚本失败原因是产品新bug引起的，而不用逐个地去阅读这些失败测试脚本的源代码来分析脚本自身原因。