软件测试验收方法

by Todd Chaffee

托德·查菲(Todd Chaffee)

验收测试是美丽的魔术。 这就是它可以改善您的生活的方法。 (Acceptance testing is beautiful magic. Here’s how it can improve your life.)

More accurately,automatedacceptance testing in the browser is beautiful magic.

更精确地，浏览器中的自动验收测试是美丽的魔术。

Actually, what I really want to say is that automated acceptance testing might lead to discussing the superb finish of your favorite Pinot Noir with your friends over dinner. I promise this will all make sense by the end of this short article.

实际上，我真正想说的是，自动验收测试可能会导致您在晚餐时与您的朋友讨论您最喜欢的黑比诺葡萄酒的绝妙完成。 我保证在这篇简短的文章结束时，所有这些都将是有意义的。

Back tobeautiful magic.

回到美丽的魔法。

关于自动验收测试的一些知识 (A bit about automated acceptance testing)

Every programmer loves automated browser testing when they first see it. I have seen jaded programmers, not easy to impress, who have laughed with joy the first time they see it. I’ll admit I laughed the first time. When you start the tests, your browser will open up and then, without doing anything else, it looks like someone is clicking around and doing stuff.

每个程序员在第一次看到自动浏览器测试时都喜欢自动测试。 我见过那些疲惫不堪的程序员，他们不容易留下深刻的印象，他们在第一次看到它时就高兴地笑了。 我承认我是第一次笑。 当您开始测试时，您的浏览器将打开，然后无需进行任何其他操作，就好像有人在四处闲逛并在做任何事情。

It’s so creepy or fun or fascinating that Chrome feels the need to pop up a warning at the top of the browser: “Chrome is being controlled by automated test software.” I suppose this is to clarify that it’s not ghosts or robots? Let’s call it robots anyway. But no matter how cool it looks at first (even if you’re not impressed with my animated GIF), that’s not even the kind of beautiful magic I am talking about.

Chrome令人毛骨悚然，有趣或令人着迷，以至于Chrome觉得有必要在浏览器顶部弹出警告：“ Chrome正在由自动测试软件控制。” 我想这是为了澄清这不是鬼魂还是机器人？ 我们还是称它为机器人。 但是，不管一开始看起来多么酷(即使您对我的动画GIF都不满意)，这也不是我所谈论的那种美丽的魔术。

As a lifelong programmer, I mostly care about the beautiful magic that makes us better at our jobs. Before I try to sell you on the benefits of automatedacceptancetesting, let’s quickly put it in context. There are lots of types of testing when it comes to software. One classic way to categorize testing is by how much of the software the tests cover:

作为一生的程序员，我主要关心使我们在工作中变得更好的美丽魔力。 在尝试向您出售自动化验收测试的好处之前，让我们快速介绍一下相关内容。 关于软件，有很多测试类型。 对测试进行分类的一种经典方法是通过测试涵盖多少软件：

Unit testing— tests the smallest possible unit of source code, typically a function or method

单元测试-测试源代码的最小可能单元，通常是函数或方法

Integration testing— builds on unit testing by checking how well units work together when they call each other

集成测试-通过检查单元之间相互协作的良好程度，在单元测试的基础上进行构建

Acceptance testing— tests that EVERYTHING works from a user perspective

验收测试-从用户角度测试一切正常

You can do acceptance testing the hard way. First, the programmers click through the entire website, going through manual tests, dozens or hundreds of times. Then the client — who’s paying you — goes through the same painful and time-consuming exercise (and surely misses things). Which leads us from beautiful magic into a mystery:

您可以用困难的方式进行验收测试。 首先，程序员点击整个网站，进行数十次或数百次手动测试。 然后，向您付款的客户-经历了同样痛苦而费时的练习(肯定错过了事情)。 这使我们从美丽的魔法变成了一个谜：

Why are people, who are paid to automate things, manually doing something over and over again that can be done far faster by a robot?

为什么有人付钱使他们自动化，却又一次又一次地手动做一些可以用机器人更快完成的事情？

I won’t attempt to solve that mystery. Instead, I want to tell you a short story about all the kinds of beautiful magic automated acceptance testing can bring into your programming life.

我不会尝试解决这个谜。 相反，我想告诉您一个简短的故事，内容涉及可以带入您的编程生活中的各种精美的魔术自动验收测试。

通过自动验收测试使freeCodeCamp更好 (Making freeCodeCamp better with automated acceptance testing)

The Beta version of freeCodeCamp has some impressive improvements for people learning how to code. One is a feature that allows students to click a button and verify that their project assignment works. You saw a robot clicking that button in the animated GIF above. The button turns green once all the features are working in the student’s project. It provides value to students, because when they click and then see the green light, they can be confident they are finished with the project.

freeCodeCamp的Beta版对学习编码的人们进行了一些令人印象深刻的改进。 一种功能是允许学生单击按钮并验证他们的项目分配是否有效。 您在上面的动画GIF中看到一个机器人单击了该按钮。 一旦学生项目中的所有功能都起作用，该按钮将变为绿色。 它为学生提供了价值，因为当他们单击并看到绿灯时，他们可以确信自己已完成项目。

Thanks to the hard work of Peter Weinberg, Anis Nouira, Tracey Bushman Christian Paul, Sean Smith, Andre Alonzo, and others, we have this feature for 15 of the project assignments on the beta version of freeCodeCamp. You can see an example of each project over at CodePen, and even run the tests manually yourself.

由于Peter Weinberg ， Anis Nouira ， Tracey Bushman Christian Paul ， Sean Smith ， Andre Alonzo和其他人的辛勤工作，我们在freeCodeCamp的beta版中为15个项目分配了此功能。 您可以在CodePen上查看每个项目的示例，甚至可以自己手动运行测试。

This feature is a type of test, but it’s not the kind of testing we are talking about. So let’s continue to call it a feature to avoid confusion. The feature has a web UI that students use just like any feature on any other web site. Someone had to code that UI. And for each assigned student project, someone had to write a separate set of code that describes the unique features of that project. You can see all the code over at the GitHub repo (please consider volunteering if you would like to help us improve this feature).

此功能是一种测试，但不是我们正在谈论的那种测试。 因此，让我们继续称其为功能以避免混淆。 该功能具有一个Web UI，学生可以像使用其他任何网站上的任何功能一样使用它。 有人必须编写该UI。 对于每个分配的学生项目，都必须编写一组单独的代码来描述该项目的独特功能。 您可以在GitHub存储库中查看所有代码(如果您想帮助我们改进此功能，请考虑自愿)。

Each contributor also has the responsibility of making sure this feature works for the hundreds of thousands of eventual freeCodeCamp students that will use it. It is a production feature that lives on the web like any other website feature.

每个贡献者还负责确保此功能适用于成千上万将要使用它的freeCodeCamp学生。 它是一项生产功能，与其他任何网站功能一样，都存在于网络中。

Savvy programmers will have already figured out where I’m heading: writing automated acceptance tests for this feature. And yes, this feature is a test, so we are testing the tests. Does this sound liketoo much testing? It’s not. As long as an end user somewhere is going to use your feature on the web, there is good reason to automate the testing of that feature. Even if the feature itself is a sort of test. Enough meta, let’s move on.

精明的程序员已经弄清楚了我要去的方向：为此功能编写自动验收测试。 是的，此功能是一项测试，因此我们正在测试这些测试。 这听起来像是过多的测试？ 不是。 只要某个地方的最终用户要在网络上使用您的功能，就有充分的理由自动进行该功能的测试。 即使功能本身是一种测试。 足够的元数据，让我们继续前进。

When I joined the project that provides this feature, I was asked along with other volunteers to fix some bugs students had discovered.

当我加入提供此功能的项目时，我和其他志愿者一起被要求修复学生发现的一些错误。

I happily reproduced the first issue and started coding. Pretty quickly I fixed my first bug, and then it came time to test my solution. Argh, the pain! The hair being torn out in frustration! The absurd amount of time it took me! This was my process:

我愉快地复制了第一期并开始编码。 很快，我修复了我的第一个错误，然后是时候测试我的解决方案了。 啊，痛苦！ 头发被挫败了！ 我花了荒谬的时间！ 这是我的过程：

Fork the sample CodePen project for the test I just fixed.分叉我刚刚修复的示例CodePen项目。 Change the Javascript settings to use my local bundle instead of the CDN.更改Javascript设置以使用我的本地捆绑包而不是CDN。 Some other manual steps left out here like changing the CodePen view and refreshing the project…. you see them all in the GIF at the start of this story.这里遗漏了一些其他手动步骤，例如更改CodePen视图和刷新项目…。 您会在故事开始时在GIF中看到它们。 Click the “Run Tests” button.点击“运行测试”按钮。 Wait for the tests to complete and check if they are successful.等待测试完成，然后检查是否成功。

And this is the worst part:go back to step 2 and repeat for each of the other fourteen CodePen sample projects!

这是最糟糕的部分：回到步骤2，对其他14个CodePen示例项目中的每一个重复！

If, at any point, you find and fix another problem with your code, you need to repeat the entire thing.

如果您在任何时候发现并解决了代码的另一个问题，则需要重复整个过程。

It took me about ten minutes to reproduce and fix my first issue. Andalmost an hourof boring clicking to test my changes and make sure my fix did not break something else. I knew this couldn’t continue. I didn’t want it to continue.

我花了大约十分钟的时间来重制和修复我的第一期杂志。 无聊的点击将近一个小时，以测试我的更改并确保我的修复程序不会破坏其他功能。 我知道这将无法继续。 我不想继续下去。

It wasn’t scalable, and we are hoping to add more camper projects and to eventually support more frameworks like Angular. We also wanted to make sure the feature works on all modern browsers and operating systems — and I had only tested it on Linux with Chrome. Did I need to recruit another volunteer for an hour of their time to test on Mac? What about Windows?

它不是可扩展的，我们希望添加更多的露营项目，并最终支持更多的框架，例如Angular。 我们还想确保该功能在所有现代浏览器和操作系统上都能正常工作-我只在Linux和Chrome上对其进行过测试。 我是否需要招募一个小时的志愿者来在Mac上进行测试？ Windows呢？

It felt like the testing process was going to make the project a bad experience for volunteers. It was already a bad experience for me. Almost no time would be spent doing the actual fun part: the programming. So I returned to the fun part, and wrote a program to automate the acceptance testing using Selenium.

感觉测试过程将使该项目成为志愿者的糟糕经历。 对我来说已经是很糟糕的经历。 几乎没有时间会花在做真正有趣的部分上：编程。 因此，我回到了有趣的部分，并编写了一个程序来使用Selenium自动化验收测试。

Here is the test process now that we have automated it with Selenium:

现在，我们已经使用Selenium自动化了测试过程：

npm test

That’s it. You can immediately return to programming (or whatever it is you enjoy more than the grunt work of manually testing) and come back four minutes later to see if all the tests passed. An hour-long manual process reduced to four minutes. Robots can be fast.

而已。 您可以立即返回编程(或者您可以享受比手动测试更艰巨的工作)，并在四分钟后回来查看所有测试是否通过。 一个小时的手动过程减少到四分钟。 机器人可以很快。

美丽的魔法 (The beautiful magic)

The number one thing I get out of automated acceptance testing ismore time to do the things I really enjoy.Since it might not be obvious from my story, here’s a list of some of the other beautiful magic you can get out of automating your acceptance tests.

我从自动化验收测试中学到的第一件事就是花更多的时间去做我真正喜欢的事情。由于从我的故事中可能并不明显，因此，这里列出了一些其他一些神奇的魔术，您可以从自动化验收测试中获得这些魔术。

It’s repeatable. A robotneverforget any of the tests.

可重复的。 机器人永远不会忘记任何测试。

If you do it right, it should be a lot faster than manual tests. More on this in the link at the end of this article.如果操作正确，它应该比手动测试快很多。 有关更多信息，请参见本文结尾处的链接。

GitHub allows you to run the tests automatically on a continuous integration server when you create a pull request. You can make sure every PR passes the tests before it is merged. Here is a link to the output of the Travis CI tests for one of our PRs.

创建拉取请求时，GitHub允许您在连续集成服务器上自动运行测试。 您可以确保每个PR在合并之前都通过测试。 这是我们PR之一的Travis CI测试输出的链接 。

It is scalable. As a project gets bigger, it takes more and more time to test it. Can you imagine manually testing the Amazon website with all its features?它是可扩展的。 随着项目规模的扩大，测试它会花费越来越多的时间。 您能想象手动测试具有所有功能的亚马逊网站吗？ It’s free documentation. Your source code is a list of every test that should be performed. The output of your test suite also provides a human-readable list of what tests were performed (see the Travis CI output from point 3, above).它是免费的文档。 您的源代码是应执行的每个测试的列表。 测试套件的输出还提供了人类可读的执行了哪些测试的列表(请参阅上面第3点的Travis CI输出)。

You can cover far more configurations. A human tester will usually have access to one or two operating systems and a couple of browsers (at most). Maybe a couple of different mobile phones. With automated testing, you can run your tests on hundreds of combinations of operating systems, mobile phones, and browser versions.

您可以涵盖更多配置。 人工测试人员通常可以访问一个或两个操作系统以及两个浏览器(最多)。 也许有几个不同的手机。 借助自动化测试，您可以在数百种操作系统，移动电话和浏览器版本的组合上运行测试。

One final benefit. Let’s imagine a client calls you on a Friday nightas you are about to sit down to dinner with friends. You make the mistake of answering the call because it’s one of your better clients. They desperately need one line of code changed to fix something minor for a huge weekend sale. It’s an easy fix so you bang it out in five minutes. Now you have two choices (I’m not including the unwise “choice” of not testing your change):

最后的好处。 假设有一个客户在星期五晚上与您坐下来共进晚餐时打电话给您。 您接听电话是错误的，因为它是您更好的客户之一。 他们迫切需要更改一行代码，以解决大型周末销售中的一些小问题。 这是一个简单的解决方法，因此您可以在五分钟之内将其完成。 现在，您有两个选择(我不包括不测试更改的不明智的“选择”)：

Do you go throughat least an hour-longprocess of manually testing every feature on the website to make sure your fix did not break anything? In your rush not to leave your friends waiting, what tests will you miss?

您是否经历了至少一个小时的手动测试网站上所有功能的过程，以确保您的修复程序没有中断任何事情？ 急于不让您的朋友等待，您会错过哪些测试？

Or do you typenpm testand let a robot take over so you can return to the company of your friends, who havejust opened a bottle of your favorite Pinot Noir? One hundred percent confident you haven’t broken anything and your weekend of fun can begin (while your client’s big sale makes them buckets of money).

还是您键入npm test并让机器人接管，以便您可以回到朋友的陪伴下，他们刚打开了一瓶您最喜欢的黑比诺葡萄酒？ 百分之一百的信心，您什么都没做，周末的乐趣就可以开始(而客户的大笔交易使他们赚了很多钱)。

If that’s not beautiful magic — I did promise and deliver wine — then you might never be convinced to give automated acceptance testing a try.

如果那不是美丽的魔力-我确实保证并交付了葡萄酒-那么您可能永远不会说服您尝试自动验收测试。

If you’d like to learn more about how you can make your automated tests reliable and fast, check out my article on Reliable Selenium NodeJS Tests. Wine not included.

如果您想了解更多有关如何使自动测试可靠且快速的信息，请查看我有关Reliable Selenium NodeJS Tests的文章。 不包括葡萄酒。

Did you like this article? If so, give me some claps so more people see it. Thanks!

你喜欢这篇文章吗？ 如果是这样，给我鼓掌，让更多的人看到它。 谢谢！

翻译自: /news/acceptance-testing-is-beautiful-magic-heres-how-it-can-improve-your-life-41759775d19d/

软件测试验收方法

如果觉得《软件测试验收方法_验收测试是美丽的魔术。 这就是它可以改善您的生活的方法。...》对你有帮助，请点赞、收藏，并留下你的观点哦！