怎么设定自动化测试目标？

      我们不管做什么事情都应该有个目的，有了目的就会产生一个对应的目标，接着基于这个目标再进行相关活动的实施，以此来达到目的。

     类似的，我们在进行自动化测试的时候，首先要明确自动化测试的目标，即实现了自动化测试究竟能为我们带来什么好处，解决了什么问题？我们不能为了自动化而去自动化，必须在实施自动化之前明确我们的自动化测试目标。

一般来说，通用的自动化测试目标有如下几个：

（1）首先是提高测试人员的工作成就感和幸福感，减少手工测试中的重复性工作。

  当下，就比如我们目前的开发、测试模式，手工测试还是占日常测试中的大部分比例，同时测试必须随开发人员不断地进行迭代开发和测试，同一个功能模块可能在整个开发周期中会反反复复地被测试超过10次以上。

    那么，如何改变这种现状呢？使用自动化测试肯定是一个很好的选择，脚本写好以后，可以不断重复运行，而以往需要手工测试花费很长的时间，现在只要很短的时间就可以轻松完成，测试工作的成就感和幸福感油然而生。

（2）提高测试用例的执行效率，实现快速的自动化回归测试，快速的给开发团队进行质量反馈。

    使用手动测试来执行用例，速度必然是很慢的。在测试用例非常多的情况下，完整的测试一遍所有测试用例的时间成本就会相当高了。

    使用自动化测试替代手动测试，那么测试用例的执行者变成了机器执行，它可以不知疲倦的快速完成测试脚本指派给它的测试任务。这种方式可以大大提高测试执行效率，减少测试用例执行时间，提高测试执行的准确性。

    尤其是敏捷开发模式的应用。敏捷开发对于被开发产品的质量反馈有着很高的要求，需要每星期甚至每天开发出一个build版本，并且部署在测试环境上，希望测试人员能够给出快速的质量反馈。目前只有通过自动化测试的方式才能真正实现对于敏捷开发项目快速的质量反馈需求，缺少自动化测试的敏捷开发项目会大大增加项目失败的风险。

（3）插入大量测试数据。

     在系统测试过程中，经常要插入大量的测试数据来验证系统的处理能力，例如产品测试过程中，要构造不同类型的产品及对应的设备，比如天然气表产品，对应的设备有1000个，水表产品对应的设备有1000个，电表产品对应的设备有1000……，这样构造数据，若通过自动化脚本，既测试了场景，又极大的提高了效率。具体可以通过三种自动化方式来实现上述测试数据插入。

    第一种方式：测试人员编写数据库的存储过程脚本，在数据库的不同数据表中插入测试数据，使用这样的方式可以实现海量数据的快速插入。当然此方式也有缺点，如果搞不清楚数据库中各个表的逻辑关系和数据格式的插入要求，很可能插入错误数据，导致无法被前台的程序所正确展示和使用。

    第二种方式：按照系统接口的调用规范要求，在测试系统的接口层编写测试脚本调用插入数据的系统接口，实现测试数据的快速插入，速度虽然不一定有第一种方式快，但是能够基本保证数据的正确性。我们物联网产品有接口层，通过此种方式，能相对快速插入数据，同时能保证数据的正确性。如果被测试系统没有接口层，那么此种方式就无法实施了。比如使用泛微系统实现的项目经理工作台，因测试系统没有接口层，就不能通过接口调用实现数据插入。

   第三种方式：使用前台的自动化测试工具，在系统的前台界面模拟用户的真实操作行为来输入各类测试数据，然后再提交达到测试系统中。此方式的优点是可以真正模拟用户插入数据的行为，确保数据插入的准确性和完整性，包含前台界面的系统均可使用此种方式。此方式的缺点是插入数据的速度较前两种方式慢很多。

 （4）常见的错误目标：使用自动化测试可完全替代手工测试，使用自动化测试发现好更多的新bug。

     如果想用自动化测试完全替代手工测试，若设定此目标则会让自动化测试实施带来极大的困难。

     测试工作本身就是一种艺术，需要使用测试人员的智慧去探索系统中可能出现的问题，并且需要在测试过程中使用不同的测试方法、测试数据和测试策略来发现更多的问题。而自动化测试的实施方式则是使用固定的方法和固定的数据去实施测试，无法像人一样根据测试系统的响应情况作出及时的测试策略调整，势必会造成测试逻辑的低覆盖率。同时，测试用例中有很多异常操作很难使用程序来进行模拟，若要完全实现自动化测试来模拟则会带来极大的技术难度挑战。

     所以，只要设定自动化测试能够替代一定比例的手动测试工作为目标即可，万不可对自动化测试的覆盖度设定过高的比例要求。

     另外，部分人员期望通过自动化测试来发现更多新的bug，这个也是一个常见误区。虽然在编写自动化测试用例的过程中会发现大部分的bug，但是自动化测试本身的作用不是用来发现新bug的，而是用来验证以前能够正常工作的功能是否依旧可以正常工作的。

     举例来说，一个被测试系统有100个功能点，由5万行代码来实现，这100个功能在上一个版本中均测试通过，在下一个迭代的版本开发中，开发人员根据产品人员的5个新需求修改了5个复杂的功能点，并且新增和修改了500行代码，那么测试人员针对这样的场景如何来测试这个版本的产品呢？因为测试人员不知道被修改的500行代码到底会怎样影响整体的100个功能点，所以只能把100个功能点都测试一遍才能放心让这个版本进行发布和上线。100个功能点的测试工作量就这样产生了。如果采用手工测试的方式，则测试用例的执行周期肯定会十个很长的周期并且测试人员发现了新bug后，开发人员又修改了100行代码，那么是不是又要重新测试这100行代码的功能点呢？如果再次测试，那么测试人员就陷入了周而复始的重复劳动中，如果不测试这100个功能点，那么被修改代码产生的不确定性又难以得到评估。如果测试人员拥有了这100个功能点的自动化测试脚本，就不会出现进退两难的境地了，测试人员可以使用自动化测试脚本快速验证原有的95个功能点是否正常工作。

     自动化测试可以大大降低手工测试的重复性，测试人员只要手动测试5个被修改的功能即可。测试人员重复测试这5个功能点并确认没有bug产生后，可以新增编写这5个功能点的自动化测试用例，用于下一个版本的自动化测试即可。从上面的例子可以看出，自动化测试更适合于回归测试，而不是用来发现新bug。