【摘要】 我们对自动化测试充斥了期望，但是，自动化测试却常常带给我们懊丧和扫兴。固然，自动化测试能把我们从困难的环境中解放出来，在实行自动化测试解决问题的同时，又带来同样多的问题。在开展自动化测试的工作中，症结问题是遵循软件研发的基础规则。本文引见自动化测试的 7 个步骤：改进自动化测试过程，定义需求，验证概念，支持产品的可测试性，具有可延续性的设计( design for sustainability )，有计划的安排和面对成功的挑战。依照以上 7 个步骤，部署你的人员、工具和制定你的自动化测试项目计划，你将会通往一条成功之道。

　　一个故事 :

　　我在非常多软件公司工作过，公司范围有大有小，也和来自其他公司的人员交换，因此阅历过或听道过影响自动化测试成效的各种各样的的问题。本文将提供若做方法规躲可能在自动化测试中出现的问题。我先给大家道一个故事，以便各位了解自动化测试会出现哪些问题。

　　以前，我们有一个软件项目，研发小组内所有的人都认为应该在项目中采用自动化测试。软件项目的经理是 Anita Delegate 。她评估了所有可能采用的自动化测试工具，最后选择了一种，并且买购了几份拷贝。她委派一位员工 ??Jerry Overworked 负责自动化测试工作。 Jerry 除了负责自动化测试工作，更有其他的非常多任务。他尝试使用刚刚买购的自动化测试工具。当把测试工具运用到软件产品测试中的时候，遇见了问题。这个测试工具太复纯，难于设置。他不得不给测试工具的客户支持暖线打了几个电话。最后， Jerry 认识到，他需要测试工具的技术支持人员到现场帮助安装测试工具，并找出其中的问题。在打过几个电话后，测试工具厂商派过去一位技术专家。技术专家达到后，找出问题所在，测试工具能正常工作了。这还算是顺利了。不过，几个月后，他们还是没有真正实现测试自动化， Jerry 谢绝继续从事这个项目的工作，他惧怕自动化测试会一事无成，只是挥霍时间而已。

　　项目经理 Anita 把项目沉新指派给 Kevin Shorttimer ，一位刚刚被雇佣来做软件测试的人员。 Kevin 刚刚刚取得盘算机迷信的教位，盼望通过这份工作迈背更有应战性的、值得往做的工作。 Anita 送 Kevin 加入工具培训，防止 Kevin 步 Jerry 的后尘 ?? 由于使用测试工具遇见困难而变得懊丧，导致废弃负责的项目。 Kevin 非常高兴。这个项目的测试需要反复测试，有面令人厌恶，因此，他非常愿意采用自动化测试。一个主要的版本宣布后， Kevin 筹备开始全天的自动化测试，他非常盼望得到一个时机证明自人能写非常庞杂的，有难度的代码。他树立了一个测试库，使用了一些技能的方法，能支持大部门的测试，这比原筹划多消费了非常多时间，不过， Kevin 使整个测试工作开展的非常顺利。他用已有的测试套测试新的产品版本，并且确凿发现了 bug 。接下来， Kevin 得到一个从事软件研发职位的机遇，分开了自动化的岗位。

　　Ahmed Hardluck 接手 Kevin 的工作，从事自动化测试执行工作。他发现 Kevin 留下的文件不只少，并且没有太多的价值。 Ahmed 花省不少时间去弄清楚已有的测试设计和研究怎么开展测试执行工作。这个过程中， Ahmed 阅历了非常多失败，并且不能确信测试执行的方法是否正确。测试执行中，执行失败后的同伴的提醒信息也没有太多的参考价值，他不得不更深的钻研。一些测试执行看起来似乎永久没有停止。另外一些测试执行需要一些特定的测试环境搭建需求，他更新测试环境拆建文件，持之以恒地工作。当时，在自动化测试执行中，他发现几个执行失败的结果，经过分析，是回归测试的软件版本中有 BUG ，导致测试执行失败，发现产品的 BUG 后，每个人都非常愉快。接下来，他细心分析测试套中的内容，希看通过优化测试套使测试变得更可靠，不过，这个工作不断没有完成，预期的优化结果也没有达到。遵照计划，产品的下一个发布版本有几个主要的改动， Ahmed 便时认识到产品的改动会损坏已有的自动化测试设计。接下来，在测试产品的新版本中，续大少数测试用例执行失败了， Ahmed 对执行失败的测试研究了非常长时间，然后，从其别人那里追求助助。经过切磋，自动化测试应该根据产品的新接口做修改，自动化测试才能运转起来。最后，大家根据新接口修改自动化测试，测试都通过了。产品发布到了市场上。接下来，用户立即挨来投诉电话，投诉软件无法工作。大家才发现自人改写了一些自动化测试脚本，导致一些错误提醒信息被忽略了。固然，实际上测试执行是失败的，不过，由于改写脚本时的一个编程过失导致失败的测试执行结果被忽详了。这个产品末于失败了。

　　这是我的故事。大概你原来亲自阅历了故事当中某些情节。不过，我希看你没有这样的类似结局。本文将给出一些倡议，防止出现这样的结局。

　　问题

　　那个故事说明了几个使自动化测试项纲堕入窘境的缘由：

　　自动化测试时光不充分：依据项目规划的部署，测试人员去去被布置应用本人的个人时光或者项目前期参与自动化测试。这使得自动化测试无法失掉充足的光阴，无法得到实正的闭注。

　　缺少清楚的目的：有非常多佳的理由来展开自动化测试工作，诸如自动化测试能节俭时光，使测试愈加简略，提高测试的笼罩率，能让测试人员坚持更好的测试自动性。不过，自动化测试不可能同时知足上述的目本。不同的人员对自动化测试有不同的期望，这些盼望当当提进去，否则非常可能面对的是扫兴。

　　短缺经验：尝试测试自己的程式的低级的程式员经常采用自动化自动化测试。由于缺少经验，非常难确保自动化测试的顺利开展。

　　更新换代屡次( High turnover )：测试自动化往往需要破费非常多时间进修的，当自动化测试更新换代屡次的时候，你就损失了刚刚刚刚教习到的自动化测试经验。

　　对于失望的反映：在测试还遥没有开始的时候，问题就已潜起在软件中了。软件测试不过是发现了这些埋伏的问题而已。就测试自身而行，测试是一件非常困难的工作。当在建改过的软件上一遍接一遍的测试时，测试人员变得疲逸起来。测试什么时候后停止?当依照计划的部署，软件应该托付的时候，测试人员的续看变得尤其强烈。如果不用测试，那该有多好呀!在这种环境中，自动化测试可能是个能选择的解决方法。不过，自动化测试却已必是最好的选择，他不是个现实的解决方法，更像是个盼望。

　　不愿念考软件测试：非常多人发现实现产品的自动化测试比测试自身更有趣。在非常多软件项目发生这样的情况，自动化工程师不参和到软件测试的具体运动中。由于测试的自动化和测试的人为割裂，导致非常多自动化对软件测试并没有太大的助助。

　　关注于技术：怎么真现软件的自动化测试是个非常呼惹人的技术问题。不过，过多的关注怎么实隐自动化测试，导致忽详了自动化测试计划能否契合测试需要。

　　遵照软件研发的规矩

　　你可能了解 SEI (软件工程研究所)提出的 CMM (才能幼稚度模型)。 CMM 分为 5 个界别，该模型用来对软件研发组织区分等级。 Jerry Weinberg (好邦有名软件工程专家)也创立了自己的一套软件组织模型，在他的组织模型中增长了一个额定的级别，他称之为零级别。非常显然，一个零模式的组织实际上也是研发软件;零模式组织中，在研发人员和用户之间没有差异 [Weinberg 1992] 。恰恰在这类组织环境中，经常采用自动化测试方法。因此，把资流用于自动化测试，并且把自动化测试当作一个软件研发活动看待，把软件测试自动化晋升到一级。这是解决测试自动化的中心的方案。我们应该像运作其他的研发项目相同来运作软件自动化测试项目。

　　像其他软件研发项目相同，我们需要软件研发人员专注于测试自动化的研收义务;像其他软件研发项目雷同，自动化测试能自动完成具体的测试任务，关于详细的测试义务来道，自动化研发人员能够不是这方面的专野，因而，软件测试专家应当提供具体测试义务相干的征询，并且提供测试自动化的需求;像其他软件研发项目相同，假如在研发编码之前，对于测试自动化作了整体设计有帮于测试自动化研发的顺本展开。像其他软件研发项目相同，自动化测试代码需求和踪和保护，因彼，需要采用本初码治理。像其他软件研发项目雷同，测试自动化也会呈现 BUG ，因此，需要有规划的和踪 BUG ，并且对改动后的 BUG 入行测试。像其他软件研发项目雷同，用户需要晓得怎么使用软件，因此，需要提求用户使用手册。