[资源] 自动化测试的目标
我们做任何事情都应该有个目的，有了目的就会产生一个对应的目标，然后再基于这个目标进行相关活动的实施，以此来达到目的。类似地，我们在进行自动化实施的时候，首先要明确自动化测试的目标，即实现了自动化测试到底能为我们带来什么好处、解决了什么问题？我们不能为了自动化而自动化，必须在实施自动化测试之前明确自动化测试的目标。
笔者基于多年的自动化测试实践，列出了一些相对通用的自动化测试目标。
目前，在中国的大部分中小企业中，手工测试占日常测试工作的大部分比例，测试人员必须跟随开发团队一起不断地进行迭代式开发和测试，一个功能模块可能在整个测试周期被重复测试的次数超过10次以上。测试人员在执行了如此多的重复工作之后，常常会对于“IT民工”这个词有着更加深刻的理解。
如何改变这个现状呢？使用自动化测试肯定是个很好的选择，脚本写好以后，可以不断地重复运行，测试人员只需要单击某个按钮就可以开始测试工作了，然后去喝喝茶看看报纸，一会儿回来看一下测试结果，就完成了以往手工测试需要花费很长时间的工作。测试工作的成就感和幸福感油然而生，测试人员也会有精力和意愿去主动地推进自动化测试在不同项目中的深入实施。
如何验证达到了此目的呢？可以通过测试人员的满意度调查来了解是否提高了测试人员的成就感和满意度。
使用手工方式来执行测试用例，执行速度必然是很慢的。人是一种生物，而不是机器，工作时间长了必然会觉得劳累，测试执行的速度自然就慢了下来，在测试用例非常多的情况下，完整测试一遍所有测试用例的时间成本就会相当高。
使用自动化测试取代手工测试，那么测试用例的执行者就变成了机器执行，机器可以24 小时不停地执行，它可以毫无怨言地、不知疲倦地、快速地完成测试脚本指派给它的测试任务。此种方式势必可以大大提高测试执行的效率，减少测试用例的执行时间，提高测试执行的准确性。
目前，敏捷开发模式也在各类软件企业中开始普及和应用。敏捷开发对于被开发产品的质量反馈有着很高的要求，需要每星期甚至每天开发出一个build 版本，并且部署在测试环境上，同时希望测试人员能够给予质量的快速反馈。目前，只有通过自动化测试的方式才能真正实现对于大型敏捷开发项目的质量反馈需求，缺少自动化测试的敏捷开发项目会大大增加项目失败的风险。
如何验证达到了此目的呢？可以和以前手工测试的执行时间进行对比，看看是否明显缩短了测试用例的执行时间，询问开发人员项目的质量反馈速度能否为快速地发布产品带来很大帮助。
在大部分IT企业的运营成本中，50%～70%的成本是人工成本，如何能够更好地控制人工成本，对于企业的发展有着重要意义。使用自动化测试方式，势必会减少手工测试的工作量，从而达到减少测试人员的目的，进而降低企业的人工成本，增强企业的盈利能力。
如何验证达到了此目的呢？在相同级别测试工作量的情况下，企业可以测算在使用自动化测试后，项目中是否减少了测试人员投入数量和工作时长。
在完成产品开发和测试工作后，产品会被发布到生产环境，正式地为用户提供服务。但是产品在生产环境的运营过程中，总是会由于各类原因造成这样或者那样的运行问题或故障。如何快速发现这样的问题呢？有人说“出了问题一定会有用户给客服打电话进行投诉的，那么我们就可以发现生产环境中的问题了”。如果采用这样的处理方式，势必会降低用户对于产品使用的满意度。另外，如果没有热心的用户进行投诉，那么生产环境问题被发现的时间会被大大推迟，所以依靠客户投诉的方式是不可取的。
为了保证快速、及时地发现生产环境的不定期问题，建议采用拨测的方式来监控产品的运行状态，可以编写自动化测试脚本测试产品的主要功能逻辑，定时运行测试脚本检查产品系统是否依旧可以正常工作，如果运行测试脚本后没有发现任何问题，则休眠等待一段时间后再运行测试脚本检测产品系统的运行状态。如果测试脚本发现了产品系统的运行问题，在重试几次之后确认产品系统的问题依旧存在，则测试脚本会自动给系统运维的值班人员发出报警邮件和短信，相关人员收到报警后可以人工去处理系统出现的运行故障，这样就达到了实时监控产品系统的目的，可以在第一时间发现和处理系统的故障。
如何验证达到了此目的呢？在生产环境运行的产品系统出现问题，系统可以在几分钟内实现自动报警。
在系统级别的测试过程中，经常要插入大量的测试数据来验证系统的处理能力。比如测试人员想要插入100个注册用户，并且每个用户都有特定的10条用户数据，那么需要插入的数据量足有1000条之多，使用手工的方式来插入这些数据势必会花费很长的时间和精力。测试人员可以通过3种自动化的方式来实现上述测试数据的插入要求。
第一种方式：测试人员编写数据库的存储过程脚本，在数据库的不同数据表中插入测试数据，使用这样的方式可以实现海量数据的快速插入。当然此方式也有缺点，如果搞不清楚数据库中各个表的逻辑关系和数据格式的插入要求，很可能插入错误数据，导致无法被前台的程序所正确展示和使用。
第二种方式：按照系统接口的调用规范要求，在测试系统的接口层编写测试脚本调用插入数据的系统接口，实现测试数据的快速插入，速度虽然不一定有第一种方式快，但是能够基本保证插入数据的正确性。如果被测试系统没有接口层，那么此方式就无法实施了。
第三种方式：使用前台的自动化测试工具，在系统的前台界面模拟用户的真实操作行为来输入各类测试数据，然后再提交到测试系统中。此方式的优点是可以真正模拟用户插入数据的行为，保证数据插入的准确性和完整性，包含前台界面的系统均可使用此方式。此方式的缺点是插入数据的速度要比前两种方式慢好几倍。
针对被测试系统的实际情况，测试人员可以使用3种方式之一实现测试数据的插入需求。
很多测试人员都有一个错误的想法，就是想用自动化测试完全替代手工测试，如果设定此目标则会让自动化测试的实施带来极大的困难。测试工作本身就是一门艺术，需要测试人员用智慧去探索系统中可能出现的问题，并且需要在测试过程中使用不同的测试方法、测试数据和测试策略来发现更多问题。而自动化测试的实施方式则是使用固定的方法和数据去实施测试，无法像人一样根据测试系统的响应情况作出及时的测试策略调整，势必会造成测试逻辑的低覆盖率。另外，测试用例中有很多异常操作很难使用程序来进行模拟，若要完全实现自动化测试来模拟则会带来极大的技术难度挑战。所以，只要设定自动化测试能够替代一定比例的手工测试工作为目标即可，千万不可对自动化测试的覆盖度设定过高的比例要求。
还有的测试人员期望使用自动化测试来发现更多的新bug，这个也是一个常见误区。虽然在编写自动化测试用例的过程中会发现大部分的bug，但是自动化测试本身的作用不是用来发现新bug，而是用来验证以前能够正常工作的功能是否依旧可以正常工作。举一个例子，一个被测试系统有100个功能点，由5万行代码来实现，这100个功能在上一个版本中均通过测试，在下一个迭代的版本开发中，程序员根据产品人员的5个新需求修改了5个复杂的功能点，并且新增和修改了500行代码，那么测试人员针对这样的场景如何来测试这个版本的产品呢？因为测试人员不知道被修改的500行代码到底会怎样影响整体的100个功能点，所以只能把100个功能点都测试一遍才能放心地让这个版本发布和上线。100个功能点的测试工作量就这样产生了。如果采用手工测试的方式，则测试用例的执行周期肯定会很长，并且测试人员发现了新bug后，程序员又修改了100行代码，那么是不是又要重新测试这100个功能点呢？如果再次测试，那么测试人员就陷入了周而复始的重复劳动中；如果不测试全部100个功能点，那么被修改代码产生的不确定性又难以得到评估。如果测试人员拥有了这100个功能点的自动化测试脚本，就不会进入进退两难的境地了，测试人员可以使用自动化测试脚本快速验证原有的95个功能点是否正常工作。自动化测试可以大大降低手工测试的重复性，测试人员只要手工测试5个被修改的功能即可。测试人员充分测试这5个功能点并确认没有bug产生后，可以新增编写这5个功能点的自动化测试用例，用于下一个版本的自动化测试即可。从上例可以看出，自动化测试更适合用于回归测试，而不是用来发现新bug。
基于以上6个常见的自动化测试目标，测试人员应根据测试项目的具体要求正确地设定自动化测试目标。
想要高效的完成app功能测试，就需要选择一款合适的功能测试工具。尽管现阶段存在少数不采用任何功能测试工具，从事功能测试外包项目的软件服务企业。短期来看，这类企业盈利状况尚可，但长久来看，它们极有可能被自动化程度较高的软件服务企业取代。
TestBird - 手游和App自动化测试平台
