自动化测试中的测试执行自动化

“自动化测试”这个术语的使用是如何对团队深挖自动化益处产生束缚作用的，Richard Bradshaw 在 Agile Testing Days 2015 上对此进行了探讨分析。

InfoQ 有幸采访到了 Bradshaw，就测试和检查的不同之处以及为什么两者都很重要、自动化能怎样支持测试、自动化框架的使用以及为什么测试人员应当时刻紧盯测试中的问题等话题与其进行了交流。

InfoQ：请您详细说明一下测试和检查二者之间的区别。

Bradshaw：关于这点，我建议每个人都去读一下 James Bach 及 Michael Bolton 写的精析测试与检查这篇文章，形成下自己的看法，我的观点目前和两位作者在文章中所阐述的一致。对我来说，测试和检查的主要区别在于是否以学习为中心。学习是知识的获取。我们通过测试软件来获得软件自身的知识，这些知识实质是业务需求，后面做出明智的决策均基于此基础上。在测试的时候，我们可以自由随意地研究系统，遵循启发式思路，在已有结果的基础上进行研究，去探寻新的信息。在这个过程中，我们在不断学习。而检查，确切地说，就是只有检查。我们依靠某些模型来检查系统，去检测有违模型的变化之处。我们所执行的只不过是一系列的算法步骤。这中间没有学习。我们还得评估所有这些检查的结果，为了找出其中是否存在问题。而这些只有人方能办到。

InfoQ：您为什么认可这两者都是重要的呢？

Bradshaw：它们二者互相补充。在我看来，二者若缺其一，剩下的一个也将独木难支。我们需要对系统的关键行为进行检查，尤其是那些会消耗商业资源或破坏商业声誉的行为。当然了，你也可以说所有的 bug 都会造成这样的后果，所以我说的是诸如不能在亚马逊上下单，或者不能在 Slack 里发送信息之类的重要事件。与此同时，还要测试系统的新功能，尽管从业务层面能够理解系统行为，但我们的测试还是要做，得弄清楚这些新功能是怎样影响系统其它部分的。检查有助于引导此类测试活动，检查活动就像当检测到了某一部分的变化时，对外发出公开邀请，以对变化部分做进一步的探索和测试。

InfoQ：您在讲演中提到，自动化应是对测试形成支持，而不是去替代测试。请您解释下这个观点。

Bradshaw：在以前的工作里，别人告诉我，自动化的目标是替代测试活动，主要是替代回归测试。好几次我甚至还碰到过这样的讨论，说自动化实际上能够替代测试工程师。这当然不过是空谈。讲演中提及这个观点的主要原因，是为了保持我在测试和检查上的观点的一致性。在我看来，大多数人口中的自动化测试，实际上只是自动化检查。他们为系统制定了一个模型，照着这个模型做检查。但正如前面所说的，我们还需要测试，所以需要理解的是，这些自动化检查支撑了我们的测试成果，而不是替代测试成果。另外，如果认可测试是必需的话，我们应当去研究怎样才能让测试变得更快、更深入，或者研究如何才能进一步延拓测试范围。什么样的工具我们能用来支撑测试，完成像数据管理、状态控制以及日志文件解析等事务。

InfoQ：您正在用哪些自动化框架？您在测试过程中是如何应用它们来达成自动化的？请举些例子谈谈。

Bradshaw：我喜欢用类似于拼出来的架构，拼图性质的架构。用拼图来描述抽象和解耦比较朗朗上口。在架构设计时，我一般会把它们设计为一个个独立的部分。比如说，GUI 自动化检查方法通常是这样的，有一部分代码用做数据管理，从电子表格程序中读数据或者在数据库里创建数据，另一部分代码用于创建浏览器实例，供测试人员使用，还有一部分代码用于管理测试人员和页面的交互，最常见的就是 PageObjects，最后还有一部分代码用于处理报告结果。把所有这些部分拼在一起，就组成了一个能用于自动化检查 GUI 的工具了。既然设计出来的架构的粒度小，那么现在在整个测试过程中这些模块都可被我们利用了。我们可以为数据生成代码创建一个 GUI，或甚至是命令行接口，团队成员在测试的时候就可以用这部分代码来生成数据，而不用自己一头扎进 DB 里。另外一个例子是我目前正在做的，通过使用终端自动化架构中的部分内容，将 app 部署在 1-N 设备上，启动 app，执行登录和停止。这样我一下子就能完成手机批量更新，每个版本节省了大概 15~30 分钟的时间，多出的时间我可以去做测试。

InfoQ：在测试和自动化方面，您有什么心得体会想和其他测试人员分享的？

Bradshaw：我们对自动化的看法及其讨论都需要改变。应牢记我们所要解决的是测试问题，而不是“我们需要自动化”的问题。严肃认真地思考下你面临的测试问题，在最适合的环节使用工具，同时别忘了工具自有其局限性。

我想要表达的观点是，我目睹了很多公司盲目追求自动化，自动化好像是它非要不可的玩具一样。我也遇到过团队将自动化单纯地视为端到端的脚本，其中包含了一些启动项、一些动作项和一些断言语句。应破除这些模子。以批判性的眼光来审视测试过程中需要改进的部分，如果自动化对此能有所帮助，就加入相应部分的自动化。分析测试方法中的瓶颈之处，深入的挖掘分析，不要止步于比如回归测试耗时太长这种层次的分析。究竟是哪一部分的回归测试耗时过长？别只盯着瓶颈自动化，很多时候这远不是事情的全部。

最后一点，别忘了自动化本质上是笨呆的，实现自动化需要持续不断的培训。这会花费很多时间，你确定有这么多的时间吗？而测试人员作为一个鲜活的人，时刻都在不停学习，想象下，如果你手头上有一些趁手好使的工具，那该能对你的测试起到多么大的改善作用啊？

查看英文原文： Automation in Testing over Test Automation