《管理信息化自动化测试实施步骤和最佳实践》由会员分享，可在线阅读，更多相关《管理信息化自动化测试实施步骤和最佳实践（14页珍藏版）》请在金锄头文库上搜索。
1、自动化测试实施步骤和最佳实践一个故事 : 我在很多软件公司工作过，公司规模有大有小，也和来自其他公司的人员交流，因此经历过或者听说过影响自动化测试效果的各种各样的的问题。本文将提供若干方法规避可能在自动化测试中出现的问题。我先给大家讲一个故事，以便各位了解自动化测试会出现哪些问题。 以前，我们有一个软件项目，开发小组内所有的人都认为应该在项目中采用自动化测试。软件项目的经理是 Anita Delegate 。她评估了所有可能采用的自动化测试工具，最后选择了一种，并且购买了几份拷贝。她委派一位员工 Jerry Overworked 负责自动化测试工作。 Jerry 除了负责自动化测试工作，还有其
2、他的很多任务。他尝试使用刚刚购买的自动化测试工具。当把测试工具应用到软件产品测试中的时候，遇到了问题。这个测试工具太复杂，难于配置。他不得不给测试工具的客户支持热线打了几个电话。最后， Jerry 认识到，他需要测试工具的技术支持人员到现场帮助安装测试工具，并找出其中的问题。在打过几个电话后，测试工具厂商派过来一位技术专家。技术专家到达后，找出问题所在，测试工具可以正常工作了。这还算是顺利了。但是，几个月后，他们还是没有真正实现测试自动化， Jerry 拒绝继续从事这个项目的工作，他害怕自动化测试会一事无成，只是浪费时间而已。 项目经理 Anita 把项目重新指派给 Kevin Shortti
3、mer ，一位刚刚被雇佣来做软件测试的人员。 Kevin 刚刚获得计算机科学的学位，希望通过这份工作迈向更有挑战性的、值得去做的工作。 Anita 送 Kevin 参加工具培训，避免 Kevin 步 Jerry 的后尘 由于使用测试工具遇到困难而变得沮丧，导致放弃负责的项目。 Kevin 非常兴奋。这个项目的测试需要重复测试，有点令人讨厌，因此，他非常愿意采用自动化测试。一个主要的版本发布后， Kevin 准备开始全天的自动化测试，他非常渴望得到一个机会证明自己可以写非常复杂的，有难度的代码。他建立了一个测试库，使用了一些技巧的方法，可以支持大部分的测试，这比原计划多花费了很多时间，不过， K
4、evin 使整个测试工作开展的很顺利。他用已有的测试套测试新的产品版本，并且确实发现了 bug 。接下来， Kevin 得到一个从事软件开发职位的机会，离开了自动化的岗位。 Ahmed Hardluck 接手 Kevin 的工作，从事自动化测试执行工作。他发现 Kevin 留下的文档不仅少，并且没有太多的价值。 Ahmed 花费不少时间去弄清楚已有的测试设计和研究如何开展测试执行工作。这个过程中， Ahmed 经历了很多失败，并且不能确信测试执行的方法是否正确。测试执行中，执行失败后的错误的提示信息也没有太多的参考价值，他不得不更深的钻研。一些测试执行看起来仿佛永远没有结束。另外一些测试执行需
5、要一些特定的测试环境搭建要求，他更新测试环境搭建文档，坚持不懈地工作。后来，在自动化测试执行中，它发现几个执行失败的结果，经过分析，是回归测试的软件版本中有 BUG ，导致测试执行失败，发现产品的 BUG 后，每个人都很高兴。接下来，他仔细分析测试套中的内容，希望通过优化测试套使测试变得更可靠，但是，这个工作一直没有完成，预期的优化结果也没有达到。按照计划，产品的下一个发布版本有几个主要的改动， Ahmed 立刻意识到产品的改动会破坏已有的自动化测试设计。接下来，在测试产品的新版本中，绝大多数测试用例执行失败了， Ahmed 对执行失败的测试研究了很长时间，然后，从其他人那里寻求帮助。经过商讨
6、，自动化测试应该根据产品的新接口做修改，自动化测试才能运转起来。最后，大家根据新接口修改自动化测试，测试都通过了。产品发布到了市场上。接下来，用户立刻打来投诉电话，投诉软件无法工作。大家才发现自己改写了一些自动化测试脚本，导致一些错误提示信息被忽略了。虽然，实际上测试执行是失败的，但是，由于改写脚本时的一个编程错误导致失败的测试执行结果被忽略了。这个产品终于失败了。 这是我的故事。或许您曾经亲身经历了故事当中某些情节。不过，我希望你没有这样的相似结局。本文将给出一些建议，避免出现这样的结局。问题这个故事阐明了几个使自动化测试项目陷入困境的原因：1. 自动化测试时间不充足：根据项目计划的安排，测
7、试人员往往被安排利用自己的个人时间或者项目后期介入自动化测试。这使得自动化测试无法得到充分的时间，无法得到真正的关注。2. 缺乏清晰的目标：有很多好的理由去开展自动化测试工作，诸如自动化测试可以节省时间，使测试更加简单，提高测试的覆盖率，可以让测试人员保持更好的测试主动性。但是，自动化测试不可能同时满足上述的目标。不同的人员对自动化测试有不同的希望，这些希望应该提出来，否则很可能面对的是失望。3. 缺乏经验：尝试测试自己的程序的初级的程序员经常采用自动化自动化测试。由于缺乏经验，很难保证自动化测试的顺利开展。4. 更新换代频繁（ High turnover ）：测试自动化往往需要花费很多时间学
8、习的，当自动化测试更新换代频繁的时候，你就丧失了刚刚学习到的自动化测试经验。5. 对于绝望的反应：在测试还远没有开始的时候，问题就已经潜伏在软件中了。软件测试不过是发现了这些潜伏的问题而已。就测试本身而言，测试是一件很困难的工作。当在修改过的软件上一遍接一遍的测试时，测试人员变得疲劳起来。测试什么时候后结束？当按照计划的安排，软件应该交付的时候，测试人员的绝望变得尤其强烈。如果不需要测试，那该有多好呀！在这种环境中，自动化测试可能是个可以选择的解决方法。但是，自动化测试却未必是最好的选择，他不是一个现实的解决方法，更像是一个希望。6. 不愿思考软件测试：很多人发现实现产品的自动化测试比测试本身
9、更有趣。在很多软件项目发生这样的情况，自动化工程师不参与到软件测试的具体活动中。由于测试的自动化与测试的人为割裂，导致很多自动化对软件测试并没有太大的帮助。7. 关注于技术：如何实现软件的自动化测试是一个很吸引人的技术问题。不过，过多的关注如何实现自动化测试，导致忽略了自动化测试方案是否符合测试需要。遵守软件开发的规则 你 可能了解 SEI （软件工程研究所）提出的 CMM （能力成熟度模型）。 CMM 分为 5 个界别，该模型用来对软件开发组织划分等级。 Jerry Weinberg （美国著名软件工程专家）也创建了自己的一套软件组织模型，在他的组织模型中增加了一个额外的级别，他称之为零级别
10、。很显然，一个零模式的组织实际上也是开发软件；零模式组织中，在开发人员和用户之间没有差别 Weinberg 1992 。恰恰在这类组织环境中，经常采用自动化测试方法。因此，把资源用于自动化测试，并且把自动化测试当作一个软件开发活动对待，把软件测试自动化提升到一级。这是解决测试自动化的核心的方案。我们应该像运作其他的开发项目一样来运作软件自动化测试项目。 像其他软件开发项目一样，我们需要软件开发人员专注于测试自动化的开发任务；像其他软件开发项目一样，自动化测试可以自动完成具体的测试任务，对于具体的测试任务来说，自动化开发人员可能不是这方面的专家，因此，软件测试专家应该提供具体测试任务相关的咨询，
11、并且提供测试自动化的需求；像其他软件开发项目一样，如果在开发编码之前，对测试自动化作了整体设计有助于测试自动化开发的顺利开展。像其他软件开发项目一样，自动化测试代码需要跟踪和维护，因此，需要采用源代码管理。像其他软件开发项目一样，测试自动化也会出现 BUG ，因此，需要有计划的跟踪 BUG ，并且对修改后的 BUG 进行测试。像其他软件开发项目一样，用户需要知道如何使用软件，因此，需要提供用户使用手册。 本文中不对软件开发做过多讲述。我假定您属于某个软件组织，该组织已经知道采用何种合理的、有效的方法开发软件。我仅仅是推动您在自动化测试开发过程中遵守已经建立的软件开发规则而已。本文按照在软件开发
12、项目中采用的标准步骤组织的，重点关注测试自动化相关的事宜和挑战。 * 改进软件测试过程 * 定义需求 * 验证概念 * 支持产品的可测试性 * 可延续性的设计（ design for sustainability ） * 有计划的部署 * 面对成功的挑战 1. 改进软件测试过程 如果你负责提高一个商业交易操作的效率，首先，你应该确认已经很好的定义了这个操作的具体过程。然后，在你投入时间和金钱采用计算机提供一套自动化的商业交易操作系统之前，你想知道是否可以采用更简单、成本更低的的方法。同样的，上述过程也是用于自动化测试。我更愿意把 “ 测试自动化 ” 这个词解释成能够使测试过程简单并有效率，使测
13、试过程更为快捷，没有延误。运行在计算机上的自动化测试脚本只是自动化测试的一个方面而已。 例如，很多测试小组都是在回归测试环节开始采用测试自动化的方法。回归测试需要频繁的执行，再执行，去检查曾经执行过的有效的测试用例没有因为软件的变动而执行失败。回归测试需要反复执行，并且单调乏味。怎样才能做好回归测试文档化的工作呢？通常的做法是采用列有产品特性的列表，然后对照列表检查。这是个很好的开始，回归测试检查列表可以告诉你应该测试哪些方面。不过，回归测试检查列表只是合于那些了解产品，并且知道需要采用哪种测试方法的人。在开始测试自动化之前，你需要完善上面提到的回归测试检查表，并且，确保你已经采用了确定的的测
14、试方法，指明测试中需要什么样的数据，并给出设计数据的完整方法。如果测试掌握了基本的产品知识，这会更好。确认可以提供上面提到的文档后，需要明确测试设计的细节描述，还应该描述测试的预期结果，这些通常被忽略，建议测试人员知道。太多的测试人员没有意识到他们缺少什么，并且由于害怕尴尬而不敢去求助。这样一份详细的文档给测试小组带来立竿见影的效果，因为，现在任何一个具有基本产品知识的人根据文档可以开展测试执行工作了。在开始更为完全意义上的测试自动化之前，必须已经完成了测试设计文档。测试设计是测试自动化最主要的测试需求说明。不过，这时候千万不要走极端去过分细致地说明测试执行的每一个步骤，只要确保那些有软件基本
15、操作常识的人员可以根据文档完成测试执行工作既可。但是，不要假定他们理解那些存留在你头脑中的软件测试执行的想法，把这些测试设计的思路描述清楚就可以了。以前负责过一个软件模块的自动化测试工作。这个模块的一些特性导致实现自动化非常困难。当我了解到这项工作无需在很短的时间内完成后，决定制定一个详细回归测试设计方案。我仔细地检查了缺陷跟踪库中与该模块相关的每个已经关闭的缺陷，针对每个缺陷，我写了一个能够发现该问题的测试执行操作。我计划采用这种方法提供一个详细的自动化需求列表，这可以告诉我模块的那一部分最适合自动化测试。在完成上述工作后，我没有机会完成测试自动化的实现工作。不过，当我们需要对这个模块做完整回归测试的时候，我将上面提到的文档提供给若干只了解被测试产品但是没有测试经验的测试人员。依照文档的指导，几乎不需要任何指导的情况下，各自完成了回归测试，并且发现了 BUG 。从某种角度看，这实际上是一次很成功的自动化测试。在这个项目中，我们与其开发自动化测试脚本，还不如把测试执行步骤文档化。后来，在其它项目中，我们开发了自动化测试脚本，发现相关人员只有接受相关培训才能理解并执行自动化测试脚本，如果测试自动化设计的很好，可能会好一些。不过，经过实践我们总结出完成一份设计的比较好的测试文档，比完成一份设计良好的测试脚本简单的多。另外一个提高测试效率的简单方法是采用更多的
