自动化测试的7个步骤

领测软件测试网

　　当然，不同的情况下，有的自动化测试目标比较容易达到，有的则比较难以达到。测试自动化往往对测试人员的技术水平要求很高，测试人员必须能理解充分的理解自动化测试，从而通过自动化测试不断发现软件的缺陷。不过，自动化测试不利于测试人员不断的积累测试经验。不管怎么样，在开始自动化测试之前应该确定自动化测试成功的标准。  

　　手工测试人员在测试执行过程中的一些操作能够发现不引人注意的问题。他们计划并获取必要的测试资源，建立测试环境，执行测试用例。测试过程中，如果有什么异常的情况发生，手工测试人员立刻可以关注到。他们对比实际测试结果和预期测试结果，记录测试结果，复位被测试的软件系统，准备下一个软件测试用例的环境。他们分析各种测试用例执行失败的情况，研究测试过程可疑的现象，寻找测试用例执行失败的过程，设计并执行其他的测试用例帮助定位软件缺陷。接下来，他们写作缺陷报告单，保证缺陷被修改，并且总结所有的缺陷报告单，以便其他人能够了解测试的执行情况。  

　　千万不要强行在测试的每个部分都采用自动化方式。寻找能够带来最大回报的部分，部分的采用自动化测试是最好的方法。或许你可能发现采用自动化执行和手动确认测试执行结果的方式是个很好的选择，或许你可以采用自动化确认测试结果和手工测试执行相结合和方式。我听到有人讲，除非测试的各个环节都采用自动化方式，否则不是真正意义上的自动化测试，这真是胡言乱语。如果仅仅是为了寻找挑战，可以尝试在测试的每个环节都采用自动化方法。但是，如果寻找成功测试的方法，请关注那些可以快速建立的，可以反复利用的自动化测试。  

　　定义自动化测试项目的需求要求我们全面地、清楚地考虑各种情况，然后给出权衡后的需求，并且可以使测试相关人员更加合理的提出自己对自动化测试的期望。通过定义自动化测试需求，距离成功的自动化测试近了一步。  

　　步骤三：验证概念  

　　在前面的故事当中，那个自动化测试人员在对测试方向一片茫然的情况下一头扎进了自动化测试项目中。不过，在项目的进行中，他得到了来自各个方面的支持。  

　　你可能还没有认识到这一点，不过，你必须验证自动化测试项目的可行性。验证过程花费的时间往往比人们预期的要长，并且需要来自你身边的各种人的帮助。  

　　很多年前，我从事一个测试自动化项目的工作，参加项目的人员有各种各样的好点子。我们设计了一个复杂的自动化测试系统，并且非常努力工作去实现系统的每个模块。我们定期的介绍测试自动化的设计思路和工作进度，甚至演示已经完成的部分功能。但是，我们没有演示如何利用该套测试自动化系统如何开展实际的测试工作。最后，整个项目被取消了，此后，我再也没有犯这个错误。  

　　你需要尽可能快地验证你采用的测试工具和测试方法的可行性，站在产品的角度验证你所测试的产品采用自动化测试的可行性。这通常是很困难的，需要尽快地找出可行性问题的答案，需要确定你的测试工具和测试方法对于被测试的产品和测试人员是否合适。你需要做是验证概念 —— 一个快速、有说服力的测试套可以证明你选在测试工具和测试方法的正确性，从而验证了你的测试概念。你选择的用来验证概念的测试套是评估测试工具的最好的方式。  

　　对于很多人来说，自动化测试意味着 GUI 自动化测试，我不同意这种观点。我曾经做过 GUI 和非 GUI 自动化测试，并惊奇的发现这两类测试的测试计划有很大的互补性。不过， GUI 测试工具很昂贵、并且过分讲究。选择合适的 GUI 测试工具是很重要的，因为，如果没有选择合适的测试工具，你会遇到很多不可预测的困难。 Elisabeth Hendrickson 曾经写过一篇关于选择测试的工具的指导性文章 [Hendrickson 1999] 。我建议在评估测试工具中，找出能够验证你的想法的证据是很重要的环节。这需要测试工具至少有一个月试用期，你可能打算现在购买一份测试工具，然后直到评估完成后再购买更多份。你需要在付出大笔金钱购买测试工具的之前，找出工具存在的问题。这样，你可以从测试工具供应商得到更好的帮助，当你打算更换工具的时候，你不会感觉很为难。  

　　下面是一些候选的验证概念的试验：  

　　回归测试：你准备在每个版本运行同样的测试用例吗？回归测试是最宜采用自动化测试的环节。  

　　配置测试：你的软件支持多少种不同的平台？你打算在所有支持的平台上测试执行所有的测试用例吗？如果是的，那么采用自动化测试是有帮助的。  

　　测试环境建立：对于大量不同的测试用例，可能需要相同的测试环境搭建过程。在开展自动化测试执行之前，先把测试环境搭建实现自动化。  

　　非 GUI 测试：实现命令行和 API 的测试自动化比 GUI 自动化测试容易的多。  

　　无论采用什么测试方法，定义一个看得见的目标，然后集中在这个目标上。验证你自动化测试概念可以使自动化更进一步迈向成功之路。  

　　步骤四：支持产品的可测试性  

　　软件产品一般会用到下面三种不同类别的接口：命令行接口（ command line interfaces ，缩写 CLIs) 、应用程序接口（ API ）、图形用户接口（ GUI ）。有些产品会用到所有三类接口，有些产品只用到一类或者两类接口，这些是测试中所需要的接口。从本质上看， API 接口和命令行接口比 GUI 接口容易实现自动化，去找一找你的被测产品是否包括 API 接口或者命令行接口。有些时候，这两类接口隐藏在产品的内部，如果确实没有，需要鼓励开发人员在产品中提供命令行接口或者 API 接口，从而支持产品的可测试性。  

　　下面，更多多的讲解 GUI 自动化测试相关内容。这里有几个原因导致 GUI 自动化测试比预期的要困难。第一个原因是需要手工完成部分脚本。绝大多数自动化测试工具都有 “ 录制回放 ” 或者 “ 捕捉回放 ” 功能，这确实是个很好的方法。可以手工执行测试用例，测试工具在后台记住你的所有操作，然后产生可以用来重复执行的测试用例脚本。这是一个很好的方法，但是很多时候却不能奏效。很多软件测试文章的作者得出结论 “ 录制回放 ” 虽然可以生成部分测试脚本，但是有很多问题导致 “ 录制回放 ” 不能应用到整个测试执行过程中。 [Bach 1996, Pettichord 1996, Kaner 1997, Linz 1998, Hendrickson 1999, Kit 1999, Thomson 1999, Groder 1999]. 结果， GUI 测试还是主要由手工完成。  

　　第二个原因，把 GUI 自动化测试工和被测试的产品有机的结合在一起需要面临技术上的挑战。经常要在采用众多专家意见和最新的 GUI 接口技术才能使 GUI 测试工具正常工作。这个主要的困难也是 GUI 自动化测试工具价格昂贵的主要原因之一。非标准的、定制的控件会增加测试的困难，解决方法总是有的，可以采用修改产品源代码的方式，也可以从测试工具供应商处升级测试工具。另外，还需要分析测试工具中的 BUG ，并且给工具打补丁。也可能测试工具需要做相当的定制，以便能有效地测试产品界面上的定制控件。 GUI 测试中，困难总是意外出现，让人惊奇。你也可能需要重新设计你的测试以规避那些存在问题的界面控件。  

　　第三个原因， GUI 设计方案的变动会直接带来 GUI 自动化测试复杂度的提高。在开发的整个过程中，图形界面经常被修改或者完全重设计，这是出了名的事情。一般来讲，第一个版本的图形界面都是很糟糕。如果处在图形界面方案不停变动的时候，就开展 GUI 自动化测试是不会有任何进展的，你只能花费大量的时间修改测试脚本，以适应图形界面的变更。不管怎样，即便界面的修改会导致测试修改脚本，你也不应该反对开发人员改进图形界面。一旦原始的设计完成后，图形界面接口下面的编程接口就固定下来了。  

文章来源于领测软件测试网 https://www.ltesting.net/

TAG: 自动测试