自动化测试实施步骤跟最佳实践.docx
《自动化测试实施步骤跟最佳实践.docx》由会员分享，可在线阅读，更多相关《自动化测试实施步骤跟最佳实践.docx（15页珍藏版）》请在冰豆网上搜索。
自动化测试实施步骤跟最佳实践
自动化测试实施步骤和最佳实践
一个故事:
我在很多软件公司工作过，公司规模有大有小，也和来自其他公司的人员交流，因此经历过或者听说过影响自动化测试效果的各种各样的的问题。
本文将提供若干方法规避可能在自动化测试中出现的问题。
我先给大家讲一个故事，以便各位了解自动化测试会出现哪些问题。
以前，我们有一个软件项目，开发小组内所有的人都认为应该在项目中采用自动化测试。
软件项目的经理是AnitaDelegate。
她评估了所有可能采用的自动化测试工具，最后选择了一种，并且购买了几份拷贝。
她委派一位员工——JerryOverworked负责自动化测试工作。
Jerry除了负责自动化测试工作，还有其他的很多任务。
他尝试使用刚刚购买的自动化测试工具。
当把测试工具应用到软件产品测试中的时候，遇到了问题。
这个测试工具太复杂，难于配置。
他不得不给测试工具的客户支持热线打了几个电话。
最后，Jerry认识到，他需要测试工具的技术支持人员到现场帮助安装测试工具，并找出其中的问题。
在打过几个电话后，测试工具厂商派过来一位技术专家。
技术专家到达后，找出问题所在，测试工具可以正常工作了。
这还算是顺利了。
但是，几个月后，他们还是没有真正实现测试自动化，Jerry拒绝继续从事这个项目的工作，他害怕自动化测试会一事无成，只是浪费时间而已。
项目经理Anita把项目重新指派给KevinShorttimer，一位刚刚被雇佣来做软件测试的人员。
Kevin刚刚获得计算机科学的学位，希望通过这份工作迈向更有挑战性的、值得去做的工作。
Anita送Kevin参加工具培训，避免Kevin步Jerry的后尘——由于使用测试工具遇到困难而变得沮丧，导致放弃负责的项目。
Kevin非常兴奋。
这个项目的测试需要重复测试，有点令人讨厌，因此，他非常愿意采用自动化测试。
一个主要的版本发布后，Kevin准备开始全天的自动化测试，他非常渴望得到一个机会证明自己可以写非常复杂的，有难度的代码。
他建立了一个测试库，使用了一些技巧的方法，可以支持大部分的测试，这比原计划多花费了很多时间，不过，Kevin使整个测试工作开展的很顺利。
他用已有的测试套测试新的产品版本，并且确实发现了bug。
接下来，Kevin得到一个从事软件开发职位的机会，离开了自动化的岗位。
AhmedHardluck接手Kevin的工作，从事自动化测试执行工作。
他发现Kevin留下的文档不仅少，并且没有太多的价值。
Ahmed花费不少时间去弄清楚已有的测试设计和研究如何开展测试执行工作。
这个过程中，Ahmed经历了很多失败，并且不能确信测试执行的方法是否正确。
测试执行中，执行失败后的错误的提示信息也没有太多的参考价值，他不得不更深的钻研。
一些测试执行看起来仿佛永远没有结束。
另外一些测试执行需要一些特定的测试环境搭建要求，他更新测试环境搭建文档，坚持不懈地工作。
后来，在自动化测试执行中，它发现几个执行失败的结果，经过分析，是回归测试的软件版本中有BUG，导致测试执行失败，发现产品的BUG后，每个人都很高兴。
接下来，他仔细分析测试套中的内容，希望通过优化测试套使测试变得更可靠，但是，这个工作一直没有完成，预期的优化结果也没有达到。
按照计划，产品的下一个发布版本有几个主要的改动，Ahmed立刻意识到产品的改动会破坏已有的自动化测试设计。
接下来，在测试产品的新版本中，绝大多数测试用例执行失败了，Ahmed对执行失败的测试研究了很长时间，然后，从其他人那里寻求帮助。
经过商讨，自动化测试应该根据产品的新接口做修改，自动化测试才能运转起来。
最后，大家根据新接口修改自动化测试，测试都通过了。
产品发布到了市场上。
接下来，用户立刻打来投诉电话，投诉软件无法工作。
大家才发现自己改写了一些自动化测试脚本，导致一些错误提示信息被忽略了。
虽然，实际上测试执行是失败的，但是，由于改写脚本时的一个编程错误导致失败的测试执行结果被忽略了。
这个产品终于失败了。
这是我的故事。
或许您曾经亲身经历了故事当中某些情节。
不过，我希望你没有这样的相似结局。
本文将给出一些建议，避免出现这样的结局。
问题
这个故事阐明了几个使自动化测试项目陷入困境的原因：
1.自动化测试时间不充足：
根据项目计划的安排，测试人员往往被安排利用自己的个人时间或者项目后期介入自动化测试。
这使得自动化测试无法得到充分的时间，无法得到真正的关注。
2.缺乏清晰的目标：
有很多好的理由去开展自动化测试工作，诸如自动化测试可以节省时间，使测试更加简单，提高测试的覆盖率，可以让测试人员保持更好的测试主动性。
但是，自动化测试不可能同时满足上述的目标。
不同的人员对自动化测试有不同的希望，这些希望应该提出来，否则很可能面对的是失望。
3.缺乏经验：
尝试测试自己的程序的初级的程序员经常采用自动化自动化测试。
由于缺乏经验，很难保证自动化测试的顺利开展。
4.更新换代频繁（Highturnover）：
测试自动化往往需要花费很多时间学习的，当自动化测试更新换代频繁的时候，你就丧失了刚刚学习到的自动化测试经验。
5.对于绝望的反应：
在测试还远没有开始的时候，问题就已经潜伏在软件中了。
软件测试不过是发现了这些潜伏的问题而已。
就测试本身而言，测试是一件很困难的工作。
当在修改过的软件上一遍接一遍的测试时，测试人员变得疲劳起来。
测试什么时候后结束？
当按照计划的安排，软件应该交付的时候，测试人员的绝望变得尤其强烈。
如果不需要测试，那该有多好呀！
在这种环境中，自动化测试可能是个可以选择的解决方法。
但是，自动化测试却未必是最好的选择，他不是一个现实的解决方法，更像是一个希望。
6.不愿思考软件测试：
很多人发现实现产品的自动化测试比测试本身更有趣。
在很多软件项目发生这样的情况，自动化工程师不参与到软件测试的具体活动中。
由于测试的自动化与测试的人为割裂，导致很多自动化对软件测试并没有太大的帮助。
7.关注于技术：
如何实现软件的自动化测试是一个很吸引人的技术问题。
不过，过多的关注如何实现自动化测试，导致忽略了自动化测试方案是否符合测试需要。
遵守软件开发的规则
你可能了解SEI（软件工程研究所）提出的CMM（能力成熟度模型）。
CMM分为5个界别，该模型用来对软件开发组织划分等级。
JerryWeinberg（美国著名软件工程专家）也创建了自己的一套软件组织模型，在他的组织模型中增加了一个额外的级别，他称之为零级别。
很显然，一个零模式的组织实际上也是开发软件；零模式组织中，在开发人员和用户之间没有差别[Weinberg1992]。
恰恰在这类组织环境中，经常采用自动化测试方法。
因此，把资源用于自动化测试，并且把自动化测试当作一个软件开发活动对待，把软件测试自动化提升到一级。
这是解决测试自动化的核心的方案。
我们应该像运作其他的开发项目一样来运作软件自动化测试项目。
像其他软件开发项目一样，我们需要软件开发人员专注于测试自动化的开发任务；像其他软件开发项目一样，自动化测试可以自动完成具体的测试任务，对于具体的测试任务来说，自动化开发人员可能不是这方面的专家，因此，软件测试专家应该提供具体测试任务相关的咨询，并且提供测试自动化的需求；像其他软件开发项目一样，如果在开发编码之前，对测试自动化作了整体设计有助于测试自动化开发的顺利开展。
像其他软件开发项目一样，自动化测试代码需要跟踪和维护，因此，需要采用源代码管理。
像其他软件开发项目一样，测试自动化也会出现BUG，因此，需要有计划的跟踪BUG，并且对修改后的BUG进行测试。
像其他软件开发项目一样，用户需要知道如何使用软件，因此，需要提供用户使用手册。
本文中不对软件开发做过多讲述。
我假定您属于某个软件组织，该组织已经知道采用何种合理的、有效的方法开发软件。
我仅仅是推动您在自动化测试开发过程中遵守已经建立的软件开发规则而已。
本文按照在软件开发项目中采用的标准步骤组织的，重点关注测试自动化相关的事宜和挑战。
*改进软件测试过程
*定义需求
*验证概念
*支持产品的可测试性
*可延续性的设计（designforsustainability）
*有计划的部署
*面对成功的挑战
1.改进软件测试过程
如果你负责提高一个商业交易操作的效率，首先，你应该确认已经很好的定义了这个操作的具体过程。
然后，在你投入时间和金钱采用计算机提供一套自动化的商业交易操作系统之前，你想知道是否可以采用更简单、成本更低的的方法。
同样的，上述过程也是用于自动化测试。
我更愿意把“测试自动化”这个词解释成能够使测试过程简单并有效率，使测试过程更为快捷，没有延误。
运行在计算机上的自动化测试脚本只是自动化测试的一个方面而已。
例如，很多测试小组都是在回归测试环节开始采用测试自动化的方法。
回归测试需要频繁的执行，再执行，去检查曾经执行过的有效的测试用例没有因为软件的变动而执行失败。
回归测试需要反复执行，并且单调乏味。
怎样才能做好回归测试文档化的工作呢？
通常的做法是采用列有产品特性的列表，然后对照列表检查。
这是个很好的开始，回归测试检查列表可以告诉你应该测试哪些方面。
不过，回归测试检查列表只是合于那些了解产品，并且知道需要采用哪种测试方法的人。
在开始测试自动化之前，你需要完善上面提到的回归测试检查表，并且，确保你已经采用了确定的的测试方法，指明测试中需要什么样的数据，并给出设计数据的完整方法。
如果测试掌握了基本的产品知识，这会更好。
确认可以提供上面提到的文档后，需要明确测试设计的细节描述，还应该描述测试的预期结果，这些通常被忽略，建议测试人员知道。
太多的测试人员没有意识到他们缺少什么，并且由于害怕尴尬而不敢去求助。
这样一份详细的文档给测试小组带来立竿见影的效果，因为，现在任何一个具有基本产品知识的人根据文档可以开展测试执行工作了。
在开始更为完全意义上的测试自动化之前，必须已经完成了测试设计文档。
测试设计是测试自动化最主要的测试需求说明。
不过，这时候千万不要走极端去过分细致地说明测试执行的每一个步骤，只要确保那些有软件基本操作常识的人员可以根据文档完成测试执行工作既可。
但是，不要假定他们理解那些存留在你头脑中的软件测试执行的想法，把这些测试设计的思路描述清楚就可以了。
以前负责过一个软件模块的自动化测试工作。
这个模块的一些特性导致实现自动化非常困难。
当我了解到这项工作无需在很短的时间内完成后，决定制定一个详细回归测试设计方案。
我仔细地检查了缺陷跟踪库中与该模块相关的每个已经关闭的缺陷，针对每个缺陷，我写了一个能够发现该问题的测试执行操作。
我计划采用这种方法提供一个详细的自动化需求列表，这可以告诉我模块的那一部分最适合自动化测试。
在完成上述工作后，我没有机会完成测试自动化的实现工作。
不过，当我们需要对这个模块做完整回归测试的时候，我将上面提到的文档提供给若干只了解被测试产品但是没有测试经验的测试人员。
依照文档的指导，几乎不需要任何指导的情况下，各自完成了回归测试，并且发现了BUG。
从某种角度看，这实际上是一次很成功的自动化测试。
在这个项目中，我们与其开发自动化测试脚本，还不如把测试执行步骤文档化。
后来，在其它项目中，我们开发了自动化测试脚本，发现相关人员只有接受相关培训才能理解并执行自动化测试脚本，如果测试自动化设计的很好，可能会好一些。
不过，经过实践我们总结出完成一份设计的比较好的测试文档，比完成一份设计良好的测试脚本简单的多。
另外一个提高测试效率的简单方法是采用更多的计算机。
很多测试人员动辄动用几台计算机，这一点显而易见。
我之所以强调采用更多的计算机是因为，我曾经看到一些测试人员被误导在单机上努力的完成某些大容量的自动化测试执行工作，这种情况下由于错误的使用了测试设备、测试环境，导致测试没有效果。
因此，自动化测试需要集中考虑所需要的支撑设备。
针对改进软件测试过程，我的最后一个建议是改进被测试的产品，使它更容易被测试，有很多改进措施既可以帮助用户更好的使用产品，也可以帮助测试人员更好的测试产品。
稍后，我将讨论自动化测试的可测试需求。
这里，我只是建议给出产品的改进点，这样对手工测试大有帮助。
一些产品非常难安装，测试人员在安装和卸载软件上花费大量的时间。
这种情况下，与其实现产品安装的自动化测试，还不如改进产品的安装功能。
采用这种解决办法，最终的用户会受益的。
另外的一个处理方法是考虑开发一套自动安装程序，该程序可以和产品一同发布。
事实上，现在有很多专门制作安装程序的商用工具。
另一些产品改进需要利用工具在测试执行的日志中查找错误。
采用人工方法，在日志中一页一页的查询报错信息很容易会让人感到乏味。
那么，赶快采用自动化方法吧。
如果你了解日志中记录的错误信息格式，写出一个错误扫描程序是很容易的事情。
如果，你不能确定日志中的错误信息格式，就开始动手写错误扫描程序，很可能面临的是一场灾难。
不要忘记本文开篇讲的那个故事中提到的测试套无法判断测试用例是否执行失败的例子。
最终用户也不愿意采用通过搜索日志的方法查找错误信息。
修改错误信息的格式，使其适合日志扫描程序，便于扫描工具能够准确的扫描到所有的错误信息。
这样，在测试中就可以使用扫描工具了。
通过改进产品的性能对测试也是大有帮助的。
很显然的，如果产品的性能影响了测试速度，鉴别出性能比较差的产品功能，并度量该产品功能的性能，把它作为影响测试进度的缺陷，提交缺陷报告。
上面所述的几个方面可以在无需构建自动化测试系统的情况下，大幅度的提高测试效率。
改进软件测试过程会花费你构建自动化测试系统的时间，不过改进测试过程无疑可以使你的自动化测试项目更为顺利开展起来。
2.定义需求
在前面的故事中，自动化工程师和自动化测试的发起者的目标存在偏差。
为了避免这种情况，需要在自动化测试需求上保持一致。
应该有一份自动化测试需求，用来描述需要测试什么。
测试需求应该在测试设计阶段详细描述出来，自动化测试需求描述了自动化测试的目标。
很多人认为自动化测试显然是一件好事情，但是，他们不愿意对自动化测试的目标给出清晰的描述。
下面是人们选用自动化测试的几个原因：
*加快测试进度从而加快产品发布进度
*更多的测试
*通过减少手工测试降低测试成本
*提高测试覆盖率
*保证一致性
*提高测试的可靠性
*测试工作可以由技术能力不强测试人员完成
*定义测试过程，避免过分依赖个人
*测试变得更加有趣
*提高了编程技能
开发管理、测试管理和测试人员实现自动化测试的目标常常是有差别的。
除非三者之间达成一致，否则很难定义什么是成功的自动化测试。
当然，不同的情况下，有的自动化测试目标比较容易达到，有的则比较难以达到。
测试自动化往往对测试人员的技术水平要求很高，测试人员必须能理解充分的理解自动化测试，从而通过自动化测试不断发现软件的缺陷。
不过，自动化测试不利于测试人员不断的积累测试经验。
不管怎么样，在开始自动化测试之前应该确定自动化测试成功的标准。
手工测试人员在测试执行过程中的一些操作能够发现不引人注意的问题。
他们计划并获取必要的测试资源，建立测试环境，执行测试用例。
测试过程中，如果有什么异常的情况发生，手工测试人员立刻可以关注到。
他们对比实际测试结果和预期测试结果，记录测试结果，复位被测试的软件系统，准备下一个软件测试用例的环境。
他们分析各种测试用例执行失败的情况，研究测试过程可疑的现象，寻找测试用例执行失败的过程，设计并执行其他的测试用例帮助定位软件缺陷。
接下来，他们写作缺陷报告单，保证缺陷被修改，并且总结所有的缺陷报告单，以便其他人能够了解测试的执行情况。
千万不要强行在测试的每个部分都采用自动化方式。
寻找能够带来最大回报的部分，部分的采用自动化测试是最好的方法。
或许你可能发现采用自动化执行和手动确认测试执行结果的方式是个很好的选择，或许你可以采用自动化确认测试结果和手工测试执行相结合和方式。
我听到有人讲，除非测试的各个环节都采用自动化方式，否则不是真正意义上的自动化测试，这真是胡言乱语。
如果仅仅是为了寻找挑战，可以尝试在测试的每个环节都采用自动化方法。
但是，如果寻找成功测试的方法，请关注那些可以快速建立的，可以反复利用的自动化测试。
定义自动化测试项目的需求要求我们全面地、清楚地考虑各种情况，然后给出权衡后的需求，并且可以使测试相关人员更加合理的提出自己对自动化测试的期望。
通过定义自动化测试需求，距离成功的自动化测试近了一步。
3.验证概念
在前面的故事当中，那个自动化测试人员在对测试方向一片茫然的情况下一头扎进了自动化测试项目中。
不过，在项目的进行中，他得到了来自各个方面的支持。
可能还没有认识到这一点，不过，你必须验证自动化测试项目的可行性。
验证过程花费的时间往往比人们预期的要长，并且需要来自你身边的各种人的帮助。
很多年前，我从事一个测试自动化项目的工作，参加项目的人员有各种各样的好点子。
我们设计了一个复杂的自动化测试系统，并且非常努力工作去实现系统的每个模块。
我们定期的介绍测试自动化的设计思路和工作进度，甚至演示已经完成的部分功能。
但是，我们没有演示如何利用该套测试自动化系统如何开展实际的测试工作。
最后，整个项目被取消了，此后，我再也没有犯这个错误。
你需要尽可能快地验证你采用的测试工具和测试方法的可行性，站在产品的角度验证你所测试的产品采用自动化测试的可行性。
这通常是很困难的，需要尽快地找出可行性问题的答案，需要确定你的测试工具和测试方法对于被测试的产品和测试人员是否合适。
你需要做是验证概念——一个快速、有说服力的测试套可以证明你选在测试工具和测试方法的正确性，从而验证了你的测试概念。
你选择的用来验证概念的测试套是评估测试工具的最好的方式。
对于很多人来说，自动化测试意味着GUI自动化测试，我不同意这种观点。
我曾经做过GUI和非GUI自动化测试，并惊奇的发现这两类测试的测试计划有很大的互补性。
不过，GUI测试工具很昂贵、并且过分讲究。
选择合适的GUI测试工具是很重要的，因为，如果没有选择合适的测试工具，你会遇到很多不可预测的困难。
ElisabethHendrickson曾经写过一篇关于选择测试的工具的指导性文章[Hendrickson1999]。
我建议在评估测试工具中，找出能够验证你的想法的证据是很重要的环节。
这需要测试工具至少有一个月试用期，你可能打算现在购买一份测试工具，然后直到评估完成后再购买更多份。
你需要在付出大笔金钱购买测试工具的之前，找出工具存在的问题。
这样，你可以从测试工具供应商得到更好的帮助，当你打算更换工具的时候，你不会感觉很为难。
下面是一些候选的验证概念的试验：
*回归测试：
你准备在每个版本运行同样的测试用例吗？
回归测试是最宜采用自动化测试的环节。
*配置测试：
你的软件支持多少种不同的平台？
你打算在所有支持的平台上测试执行所有的测试用例吗？
如果是的，那么采用自动化测试是有帮助的。
*测试环境建立：
对于大量不同的测试用例，可能需要相同的测试环境搭建过程。
在开展自动化测试执行之前，先把测试环境搭建实现自动化。
*非GUI测试：
实现命令行和API的测试自动化比GUI自动化测试容易的多。
无论采用什么测试方法，定义一个看得见的目标，然后集中在这个目标上。
验证你自动化测试概念可以使自动化更进一步迈向成功之路。
4.支持产品的可测试性
软件产品一般会用到下面三种不同类别的接口：
命令行接口（commandlineinterfaces，缩写CLIs）、应用程序接口（API）、图形用户接口（GUI）。
有些产品会用到所有三类接口，有些产品只用到一类或者两类接口，这些是测试中所需要的接口。
从本质上看，API接口和命令行接口比GUI接口容易实现自动化，去找一找你的被测产品是否包括API接口或者命令行接口。
有些时候，这两类接口隐藏在产品的内部，如果确实没有，需要鼓励开发人员在产品中提供命令行接口或者API接口，从而支持产品的可测试性。
下面，更多多的讲解GUI自动化测试相关内容。
这里有几个原因导致GUI自动化测试比预期的要困难。
1.需要手工完成部分脚本。
绝大多数自动化测试工具都有“录制回放”或者“捕捉回放”功能，这确实是个很好的方法。
可以手工执行测试用例，测试工具在后台记住你的所有操作，然后产生可以用来重复执行的测试用例脚本。
这是一个很好的方法，但是很多时候却不能奏效。
很多软件测试文章的作者得出结论“录制回放”虽然可以生成部分测试脚本，但是有很多问题导致“录制回放”不能应用到整个测试执行过程中。
[Bach1996,Pettichord1996,Kaner1997,Linz1998,Hendrickson1999,Kit1999,Thomson1999,Groder1999].结果，GUI测试还是主要由手工完成。
2.把GUI自动化测试工和被测试的产品有机的结合在一起需要面临技术上的挑战。
经常要在采用众多专家意见和最新的GUI接口技术才能使GUI测试工具正常工作。
这个主要的困难也是GUI自动化测试工具价格昂贵的主要原因之一。
非标准的、定制的控件会增加测试的困难，解决方法总是有的，可以采用修改产品源代码的方式，也可以从测试工具供应商处升级测试工具。
另外，还需要分析测试工具中的BUG，并且给工具打补丁。
也可能测试工具需要做相当的定制，以便能有效地测试产品界面上的定制控件。
GUI测试中，困难总是意外出现，让人惊奇。
你也可能需要重新设计你的测试以规避那些存在问题的界面控件。
3. GUI设计方案的变动会直接带来GUI自动化测试复杂度的提高。
在开发的整个过程中，图形界面经常被修改或者完全重设计，这是出了名的事情。
一般来讲，第一个版本的图形界面都是很糟糕。
如果处在图形界面方案不停变动的时候，就开展GUI自动化测试是不会有任何进展的，你只能花费大量的时间修改测试脚本，以适应图形界面的变更。
不管怎样，即便界面的修改会导致测试修改脚本，你也不应该反对开发人员改进图形界面。
一旦原始的设计完成后，图形界面接口下面的编程接口就固定下来了。
上面提到的这些原因都是基于采用GUI自动化测试的方法完成产品的功能测试。
图形界面接口当然需要测试，可以考虑实现GUI测试自动化。
不过，你也应该考虑采用其他方法测试产品的核心功能，并且这些测试不会因为图形界面发生变化而被中断，这类测试应该采用命令行接口或者API接口。
我曾经看到有人选择GUI自动化测试，因为，他们不打算修改被测试产品，但是，最终他们认识到必须对产品做修改，以保证GUI测试自动化可以正常工作。
无论你选择哪种方法，自动化都需要对被测试的产品做修改。
因此，采用可编程的接口是最可靠的。
为了让API接口测试更为容易，应该把接口与某种解释程序，例如Tcl、Per
升级会员 