有三种主要类型的自动化测试。

一、自动化单元测试​编辑

自动化单元测试在代码级别上进行测试。bug是在开发人 员编写的函数、方法和例程中识别出来的。

一些公司要求开发人员自己进行单元测试，而有些公司则雇用专门的测试自动化资源。这些资源可以访问源代码，它们编写单元测试来破坏生产代码。由于单元测试的存在，每当代码编译时，所有单元测试都会运行，并告诉我们是否所有功能都正常工作。如果任何单元测试失败，这意味着现在生产代码中存在一个bug。

市场上最流行的一些工具是NUnit和联合股。微软还提供了自己的单元测试框架，称为MSTest。通过这些工具的网站，他们将提供如何编写单元测试的示例和教程。

二、自动化Web服务/API测试

应用程序编程接口(API)使软件能够与其他软件应用程序进行对话。就像任何其他软件一样，API也需要进行测试。在这种测试中，桂通常不涉及。

我们在这里测试的通常是功能、遵从性和安全性问题。在Web应用程序中，我们可以测试应用程序的请求和响应是否安全和加密。

这是我们可以使用API测试的示例之一。最流行的api测试工具是SOAPUI它既有免费版本也有付费版本。还有其他工具，您可以根据需要使用这些工具。

三、自动GUI测试​编辑

这种类型的自动化测试是最严格的自动化形式，因为它涉及应用程序的用户界面测试。

这很难，因为GUI很容易改变。但是，这种类型的测试也最接近于用户对我们的应用程序所做的操作。由于用户将使用鼠标和键盘，自动GUI测试也通过使用鼠标和键盘来单击或写入用户界面上的对象来模仿相同的行为。因此，我们可以尽早发现bug，并且可以在许多场景中使用，比如回归测试或填充表单，这需要花费太多的时间。

最流行的GUI测试工具是QTP(现称UFT), 硒, 测试完成和Microsoft编码UI(这是VisualStudio终极版和高级版的一部分)。

四、自动化测试的几个误区

多年来，我听到了一些关于测试自动化的误解。我想我也应该在这篇文章中澄清这些问题。

误解#1. 自动化将取代手动测试人员。

测试自动化是为了帮助测试人员以更快、更可靠的方式进行测试。它永远无法取代人类。

把测试自动化想象成一辆汽车。如果你走路，你大约要花20分钟才能到达你的家。但是如果你用一辆车，两分钟内你就会到达。汽车的司机仍然是你，一个人，但是.汽车帮助人类更快地实现他/她的目标。而且，你的大部分精力都被节省了，因为你没有走路。所以你可以利用这些能量来做更重要的事情。

自动化测试也是如此。您可以使用它快速测试大部分重复的、冗长的、乏味的测试，并节省您的时间和精力来集中精力和测试新的和重要的功能。

如詹姆斯·巴赫一句精彩的话说：

“工具是不会测试的。只有人来测试。工具只执行“帮助”人们测试的操作。

工具可以单击对象。但是点击的位置总是由手动测试人员来告诉的。我想你现在明白我的意思了。

误解2. 阳光下的一切都可以自动实现。

如果您尝试100%地自动化您的测试用例，也许您将能够这样做，但是如果您可以这样做，那么我们的第一点就会变成错误。因为如果一切都是自动化的，手动测试人员将做什么？

困惑？对吗？

实际上，关键是，您不能100%地自动化您的测试用例。因为我们，作为测试人员，相信没有一个应用程序可以100%测试。总会有一些我们会错过的情景。只有当客户端使用您的应用程序时，才会出现bug。

因此，如果应用程序无法进行100%的测试，如何保证100%的自动化？

而且，您能够自动化所有现有测试用例的可能性非常小。总是有一些场景很难自动化，而且更容易手工完成。

例如一个用户输入数据，第二个用户批准数据，第三个用户查看数据，第四个用户禁止查看数据。这些场景可以自动化，但它们需要大量的时间和精力。所以如果你只需要手动的话就更容易了。

请记住，我们使用汽车的距离，但可能会有很长的信号在路上，会有燃料消耗，会有停车空间的问题，停车收费和更多的头痛。在某些情况下，我们只需步行到达目的地：).

因此，您不应该尝试自动化一切。只需要自动化那些重要的场景，并且需要花费大量的时间来手动完成。

误解#3. 自动化只涉及录制和播放。

请不要生活在幻想的世界里。这种幻想实际上是由来自不同自动化工具供应商的虚假广告造成的。他们说，您只需记录和播放您的步骤，您的测试用例将被自动化。这是个大谎言！

自动化就是一切，除了录音和回放。纯自动化工程师通常根本不使用录音和回放功能。录制和回放通常用于了解工具是如何为我们的步骤生成脚本的。

一旦我们了解了脚本，我们总是使用脚本来创建自动化的测试。记住，如果你想要进行测试自动化，你必须知道编程。. 另一方面，如果你不懂编程的话，就不要胆大妄为。因为和任何其他任务一样，编程也可以通过实践和奉献来学习。

我认识一些人，他们甚至不是计算机科学背景的人，但他们学会编程，现在他们是了不起的自动化工程师。在微软，他们雇佣会编程的测试人员。他们被称为SDET(测试软件开发工程师)。职务描述的第一行说：“sdet编写了许多代码….“

请学习编程，不要逃避它。它会让你惊人的测试器

一个组织要实施自动化测试，首先就要对自动化测试有一个正确的理解。我们通常对自动化测试，都会有一些理解误区，比如：

误解#4. 所有测试用例都可以自动化

首先讲所有的测试用例都自动化本身就是不必要的，因为自动化测试要开发测试脚本，而且执行自动化测试，也是需要时间的，把所有测试用例全部自动化，未必就是性价比最高的。

另一方面自动化测试，主要的是用来减少回归测试的工作量，而回归测试，最重要的是避免最基本的功能和最常用的功能受到影响，从这个理论上来说，我们会把最基本的功能和最常用的功能的测试用例进行自动化，这个就足够了。

现在世界上自动化测试率，最高的也只是达到80%左右。

误解#5. 自动化测试找不到bug

自动化测试，主要是避免由于代码的修改导致原有的正确的功能出现bug，而不是去挖掘更多更深层次的bug。更多更深层次的bug，是把测试人员解放出来后，由测试人员通过探索性测试来发现的。

误解#6. 自动化测试一定会马上大量减少测试人员数量

自动化测试虽然会最终减少测试的工作量，但是他不会是立竿见影的，因为你要实现自动化测试，首先就要进行自动化测试脚本的开发和自动化测试环境的搭建，这需要投入大量的人员和精力。自动化测试能够多长时间见到效果，要取决于这个过程的长短。

误解#7. 自动化测试能代替手工测试

自动化测试，只适用于回归测试，对于新功能测试，还是要依赖于测试人员人员设计测试用例，手动执行。

误解#8. 只有性能测试才需要自动化

自动化测试除了应用于性能测试外，还被大量应用于功能测试。

国外有超过半数的自动化测试脚本，都是用于功能验证测试的。

误解#9. 自动化测试太难上手

自动化测试，已经推行了很长时间，在网上可以找到很多自动化测试的框架、工具、教程。如果你真想实施自动化测试，只要安排专业的测试人员上手学习，自动化测试会很容易实现的。

心动不如行动。

最后，自动化测试既没有那么神奇——能够解决测试的所有问题，也不会非常高精尖——那么难以上手，正确认识自动化测试，脚踏实地地实施自动化测试，你就能享受到自动化测试给你带来的收益。

这正是：

谈虎变色不足取，当成银弹不可行

正确认识自动化，脚踏实地去实施

今天的分享就到此结束了，大家还有什么不懂的可以评论区下提问哈，如果我的文章对你有所帮助的话，可以点赞三联支持一下哈