使你的测试大规模自动化的5个建议

使你的测试大规模自动化的5个建议

#1 自动化测试不是关于ROI而是关于速度

Parkeon，是我们其中的一个客户以及智能城市工业的领导者，已经开发出一个庞大的系统(超过300人/年)来为大城市管理票务和运输。他们采用 敏捷实践 和运用BDD建立了成千上万的自动化测试。一部分测试在API层面执行，一部分测试在GUI层面执行，还有一部分通过一个机器人输入数据到真实的设备来执行。

你能想象得到，建立这样的基础设施是很昂贵的。但是这些投入是值得的，因为他们寻找的价值就是 速度的回报 。它们可以很快地检测到因为代码的改变而产生的不可预料的影响。这可以让团队 更快地重复测试 ，更确定地添加和修改新的功能。

#2 要小心对待记录和回放工具

你使用自动化测试，还要尝试用记录和回放工具去扩展你的实践?那么你的实践就可能会像下图的样子：

你推你前面的雪，你越向前推那个雪堆会积得越大。到了一定程度你将再也不能移动了。那就是所有团队使用记录和回放工具要面对的维护的问题。

我要很抱歉地说一个糟糕的事实。根本没有魔术，“你可以无需任何技术性的技能就能使用自动化”的承诺是一条死路。记录和回放作为一个快速启动策略是很有用的，但是你应该能在代码的水平上确定地直接地修改和维护脚本。

#3 保证你具有那些技能

因此如果你想开始使用自动化测试，首先确保你在你的团队中有合适的技能。总的来说你应该只专注于自动化测试，如果你有能力在产品代码中开展工作，你也可以称这些人为自动化测试工程师、开发人员或者SDETs(测试方面的软件开发者)。自动化测试的代码也应该与你的应用程序一样存储在同一个仓库中。

当你进行 自动化测试 时你必须要决定是否要在GUI层面、API层面进行测试，或者如果有单元测试是否有必要进行。因此在开发者和测试者之间需要进行一次真正的讨论。我记得有一次在好多个月前我和一个想开展自动化测试的测试领导进行了一次讨论。我问了一连串关于他们开发团队使用的堆的问题。他回答：“我不知道他们在印度，我不清楚他们使用的语言和框架……”。与开发者没有合作意味着这是一个真的真的很坏的起点。

#4 每一个测试应该讲一个关于你的应用程序的故事

我们知道的一个很流行的问题是：哪些测试我应该用自动化?我的第一个回答通常是一样的：为什么你创建了这个脚本?执行那个用例用手动还是自动都是没关系的。告诉我做这个测试的目的是什么!猜猜是什么?大部分时间那个回答都是不清晰的。所以人们都在讨论自动化，因此就做了很大的投入而那个“为什么”还是不明确的。

那么要保证你的测试是可读的和有一个明确的目的。每一个单独的测试用例都要讲一个 关于应用程序的故事 。这就是我认为 BDD 真的是一个很棒的途径的原因。你的测试/示例都是你的软件的 生动的规范 ，还是为开发人员做的验证测试：同一个硬币的两面。

一旦你 明确了你为什么要做测试还有测试的价值，你就可以开始考虑自动化了 。

当然如果你想像我们那样做 持续集成 和交付，你就应该尝试让你所有脚本自动化(如果可能)因为你需要速度作为回报。

#5 在层次上建立你的测试框架

最后，如果你希望你的框架可以扩大规模，那么可以用 多分层方法(multiple layered approach) 。

在业务层次上你要使用一致的业务术语(步骤)去定义你的测试。这就是在设计测试用例时自动建议功能(auto-suggestion)和重构的一个真正的关键点。确保你没有用“登录进入(Sign in)”的步骤或“登录(Login)”的步骤来写测试用例，因为这两个步骤意思一样只不过用了两种不同的方式来写。那样会让自动化更加难进行。

一旦你的测试用例有了好的设计，变得易读以及有明确的目的，那就是时候去执行步骤(测试装置)了。有很多模式你可以用于测试执行例如Page Object或者Journey pattern。

在不同层面都有一个框架可以使你在变化产生时减少影响，还可以使你更容易维护它们。

总结：如果你真的想你的自动化测试框架扩大规模，那是没有捷径的，你将需要：在开发人员和测试人员之间进行努力工作，需要技术性的技能和合作。