遵循软件开发原则
你可能熟悉用于给软件开发组织分级的成熟度模型（CMM）中的5个台阶。软件工程学院（SEI）的能力成熟度模型是一个著名的例子。Jerry Weinberg有他自己的组织模型，他增加了一个叫做pattern zero的格外的等级。一个pattern zero的组织忘记了正在开发软件的事实；在用户和开发人员之间没有任何区别。在哪里都可以找到自动化测试。因此，测试自动化有专用的资源并且把它作为一项开发活动，提升到了第一级别。这是解决测试自动化问题的核心所在。我们需要象我们做其他的软件开发项目一样做测试自动化项目。和其他的软件开发项目一样，我们需要有专门负责开发测试自动化的开发人员。和其他的软件开发项目一样，测试自动化自动化开发人员在那方面可能不是专家的一个任务。因此，应该咨询内行的测试人员并提供需求。和其他的软件开发项目一样，如果我们在开始编码之前先设计我们的方法，测试自动化就可能获益。和其他的软件开发项目一样，需要记录并保护测试自动化代码。因此我们需要使用源代码管理工具。和其他的软件开发项目一样，测试自动化也有错误。因此我们需要计划记录并测试它们。和其他的软件开发项目一样，用户需要知道如何使用它。因此我们需要用户文档。
我不会在这里告诉你如何开发软件。我假设你们已经知道一些关于怎样将合理并有效的方法用于开发软件的软件组织中的一员。我只是力促你们同样遵循软件开发的原则作为自己测试自动化的原则。这篇文章由那些我们所有用在软件开发项目的标准步骤组成，并且在专为测试自动化考虑和挑战的地方做了特别的说明。
1． 改进测试流程
2． 定义需求
3． 证实想法
4． 拥护产品的可测试性
5． 设计可持续性
6． 计划部署
7． 面对成功的挑战
步骤一、改进测试流程
如果你负责改进一项业务的效率，你首先应该确信流程已经被很好地定义了。在投资时间和金钱在自动化正在使用计算机的系统之前，你也应该了解是否有简单且廉价的方法使事情变得更容易。当然，同样要把握测试自动化。实际上，我喜欢认为“测试自动化”这个术语只是流水线化测试的流程，将事情更快地向前推进且很少有延期的现象。在机器上运行自动化测试脚本只是一个备选方案。
例如，许多团队通过自动化他们的回归测试开始自动化测试。它常常需要运行多次测试，以检查并确保以前可以运行的功能没有因为新的更改而被破坏。它经常要运行并且相当乏味的。如何更好地文档化你的回归测试呢？常见的方法是利用需要检查的功能列表。这是一个非常好的开始。关于测试目标的提示应该适合于那些了解产品并需要理解采用的测试方法的人。
但是在你开始自动化之前，你需要改进这些文档以使测试更加清楚。指出测试需要使用的名字，数据或者提供编辑它们的指南。假如测试人员有基本的产品知识可能是安全的。当然这肯定需要其他地方有相关的文档。但是你还是需要明确测试设计的细节。你需要说明期望的结果。这个常常没有说明，建议测试人员应该知道。很多的测试人员没有意识到他们正在遗漏什么或是因为不好意思而没有问的问题。由于现在任何一个对产品有基本认识的人就可以执行测试，这种详细的文档马上就可以给你的团队带来收益。在你开始做更彻底地自动化之前，这些是必须先完成的。你的测试设计将会是自动化测试的首要需求陈述，因此必须十分清楚也重要。它有可能因为清楚地指出需要执行测试的每一个步骤而走向极端。假设让那些了解如何操作软件的人员执行测试是比较可靠的。但是不要假设他们也理解你的关于如何测试的观点。
我曾经做过自动化测试一个软件模块的工作。这个模块有一些比较难自动化的功能。当我意识到我不可能在短时间内完成它时，我断定我需要一份详细的回归测试设计。我浏览了这个模块所有的已关闭的错误，并且为每一个错误都写了一个如何发现错误的描述。我的计划是它将会给我提供一份详细的关于可以帮我决定模块的哪些部分最需要自动化支持的自动化需求清单。当然，我从未有编写自动化的机会。但是当我们需要运行这个模块的完整的回归测试时，我们可以把测试说明书给那些了解产品但是没有测试经验的人。利用这份详细的测试说明，他们能够进行独立地测试。他们可以在没什么监督的情况下发现错误。在某种程度上，这就是非常好地自动化。实际上，在这个项目里，我们最好使用书面的测试用例，而不是使用我们拥有的其他产品模块的自动化测试脚本。我们知道自动化测试脚本需要太多的培训以致于其他人不仅仅是拿起脚本就开始运行。如果自动化测试可以更好地设计，这将不是一个问题，但是我们发现创建设计良好的测试文档比起创建同样设计良好的测试自动化更容易些。
另一个改进测试效率的简单方法是获得更多的计算机。许多的测试人员很容易让几台机器保持繁忙。这是显而易见的事情，但是我之所以提出这一点是因为我曾经看到过一些被误导的自动化试图将所有的测试在一台机器上完成。测试自动化可能是处理设备短缺的一种昂贵且冒险的方法。比较好的是，集中拿出一个你所需设备的证据。
最后一个关于改进测试流程的建议是改进产品以便更容易测试。有许多可以帮助用户和测试人员的改进办法。稍后我会讨论自动化所需的可测试性。这里我只想建议识别可以帮助手工测试的产品改进方法。
有一些产品很难安装，测试人员发现花费了大量的时间在安装和重新安装上。与其自动化这个安装过程，不如改进安装程序。客户也可以从中受益。另外一个方法就是考虑开发一个成形的自动化安装程序以使其可以和产品一起交付。实际上有许多可用的商业工具可以自定义设计安装程序。
另一个产品改进是利用工具扫描安装或运行日志中的错误。虚拟扫描一页页的日志来寻找错误信息这样会更快。所以让我们自动化它吧，好吗？如果你知道错误信息是什么样的话，编写一个扫描工具是非常容易的。但是如果你不确定，这将把你自己推向灾难。还记得那个关于遗漏错误的测试包吗？客户也不想通过扫描日志来查找错误。为产品增加一个错误扫描器很可能会产生一个更可靠的扫描器，或者要求修改错误日志系统以确保捕捉了所有的错误。这是一个测试可以依赖的工具。
性能是另一个产品需要改进且可以帮助测试的方面。这很明显。如果产品的反映迟钝耽误了你的测试，找出反应慢的功能，估量它，并且将它作为一个阻碍测试的错误提交。
这些是在不建立一个测试自动化系统的时候你可以为改进测试效率做的事情。改进测试流程可能可以节约一些时间给测试自动化，使你的自动化项目更加平滑。
步骤二、定义需求
在我们的故事里，我们可以看到和发起人相比自动化人员有不同的目标。为了避免这种情况，我们需要确信大家在测试自动化的需求上达成了一致。我们已经有描述哪些地方需要测试的测试需求。它要详细地描述我们的测试设计，而且要有描述自动化目标的自动化需求。很多人认为测试自动化就是目标，不需要再描述他们希望得到的是什么。以下是几个人们为什么选择自动化测试的原因：
加速测试以加快发布版本 测试可以执行地更加频繁 通过减少人力以减少测试的成本 提高测试覆盖率 确保一致性 提高测试的可靠性 允许没有什么技术的人员测试 定义测试流程并减少对了解产品的少数人的依赖 使测试更有意思 发展程序技能开发管理层，测试管理层，测试人员和自动化测试的人员的目标经常是不同的。除非他们达成了一些协议，否则很难获得成功。
当然，以上有一些测试目标比其他的目标更容易达到。测试自动化实际上经常提高了测试人员所需的技能水平，因为他们必须要能够充分地理解已自动化的测试以便他们能够重现发现的问题。自动化不能帮助你从你的职员中抽取测试知识。无论如何，先清楚人们认为成功是什么。
手工测试人员在运行测试时，做了很多没有意识的事情。他们计划然后得到所需的资源。他们设置然后执行测试。他们注意是否有任何不正常的事情发生。他们对照测试结果。他们记录结果并重新设置系统以准备下一次测试。他们分析错误并调查古怪的行为。他们寻找失败的模式并想办法执行更多的测试以帮助定义缺陷。然后记录缺陷报告以使其得到修复，总结报告以让其他人知道他们已经测试了哪些地方。
不要硬逼自己自动化测试的每一部分。寻找你将来可能得到最大回报的地方。部分的自动化都是可行的。你可能发现最好的是自动化执行过程加上手工验证结果。或者你会选择自动化验证过程加上手工执行测试。我曾经听一些人说除非自动化测试完成了所有的事情，否则不是真正的自动化。那是胡说。如果你只是单纯地寻求挑战，那么你会尝试做所有的事。但是如果你是寻找成功，那么就集中精力在你可以快速获得能够让你再三使用的自动化测试上。
为你的测试自动化项目定义需求将促使多样的权衡变得更清晰。它也有助于合理地设置不同团体的期望。通过定义你的目标，你已经迈出了通往测试自动化成功的下一步。
文章来源于领测软件测试网 https://www.ltesting.net/
