ci 数据库异常捕获

by Joyz

通过乔伊斯

系统地捕获错误：如何通过4个步骤构建GitLab CI测试管道 (Catch bugs systematically: how to build a GitLab CI testing pipeline in 4 steps)

Your first app is a hit the day it’s launched. But one week later, you realize that it has no retention. You discover that this is because whenever a user clicks the “send” button, their comments get posted twice.

您的第一个应用在发布之日就很受欢迎。但是一周后，您意识到它没有保留。您发现这是因为每当用户单击“发送”按钮时，他们的评论都会被发布两次。

The bug was so minor, but it killed your momentum. But that’s okay. For your second app, you and your partner check more carefully. You both click, click, click your app all day and night to prevent minor bugs like that from happening again.

该错误很小，但是却扼杀了您的动力。但是没关系。对于您的第二个应用程序，您和您的合作伙伴会更加仔细地检查。你们全天都单击，单击和单击您的应用程序，以防止类似的小错误再次发生。

For one app, that’s okay. But after a year, you have a company building 7 apps on different platforms, including web, iOS, and Android. Your team now does code review before any app launch. You test through the apps and do your clicking before they’re shipped. But your nightmare from app #1 returns: users drop the app and this time it’s because their posts showing strange characters when they type an emoji. You end up with 1-star ratings after launch.

对于一个应用程序，没关系。但是一年后，您有一家公司在不同的平台(包括Web，iOS和Android)上构建了7个应用程序。现在，您的团队会在任何应用启动之前进行代码审查。您可以对应用进行测试，然后在发布前进行点击。但是您从应用程序＃1的噩梦又回来了：用户放弃了该应用程序，这次是因为他们输入表情符号时帖子显示奇怪的字符。启动后，您将获得1星评级。

There are 3 types of product-making companies: those who do not test, those who test, and those who test fast, accurately and frequently.

产品制造公司分为3种类型：不测试的公司，测试的公司以及快速，准确且频繁地测试的公司。

Is an automated testing system with continuous integration (CI) just a dream? CI seems like a “nice-to-have”, especially since services that run tests and generate reports like Sauce Labs, BrowserStack, Test Complete are expensive. The good news is, there are many free and popular tools out there that you can mix and match to set up a free automated testing system. As a QA tester, I figured out a free testing pipeline setup, so I’m sharing it to save you time and money.

具有持续集成(CI)的自动化测试系统只是梦想吗？ CI似乎是“必备”，特别是因为运行测试并生成诸如Sauce Labs ， BrowserStack ， Test Complete之类的报告的服务非常昂贵。好消息是，这里有许多免费且流行的工具，您可以将其混合使用以建立免费的自动化测试系统。作为质量检查测试人员，我想出了免费的测试管道设置，因此我将其共享以节省您的时间和金钱。

Why did my company want to set up an automated system? Here are some reasons below:

我的公司为什么要建立一个自动化系统？以下是一些原因：

We hate manual repetitive jobs that are prone to human error.
我们讨厌容易发生人为错误的手动重复性工作。
We want a smoother process (test it when there is a code update), and reduce the waiting time.
我们想要一个更流畅的过程(在有代码更新时进行测试)，并减少等待时间。
We want to schedule the tests and make them under control.
我们希望安排测试时间并使它们处于受控状态。

设置您的UI测试 (Setting up your UI tests)

This post introduces a practical pipeline setup that can run web-based UI (User Interface) tests automatically and continuously. The later part maybe a bit technical but it’s quite fun to build!

这篇文章介绍了一种实用的管道设置，可以自动连续地运行基于Web的 UI(用户界面)测试。后面的部分可能有点技术性，但是构建起来很有趣！

I have set up the whole system with these free and open-source tools:

我已经使用以下免费和开源工具设置了整个系统：

Selenium — to script and automate browsers to perform tests
Selenium-编写脚本并自动执行浏览器以执行测试
Docker — to build an image for test environment and ship it fast
Docker-为测试环境构建映像并快速交付
Gitlab CI — to trigger, build and run the test upon code updates
Gitlab CI —在代码更新时触发，构建和运行测试
Skygear — to save test result for report on demand
Skygear —保存测试结果以按需报告

步骤1：编写脚本并在本地运行 (Step 1: Write the script and run it locally)

First of all, we write the test script, to let our original manual test run automatically. Selenium is a well-known tool for web automation. It supports different client languages including Java, Ruby, Python, etc.

首先，我们编写测试脚本，以使我们原始的手动测试自动运行。 Selenium是用于Web自动化的著名工具。它支持不同的客户端语言，包括Java，Ruby，Python等。

Here’s an example on perform a button click on a website in Python.

这是使用Python在网站上执行按钮单击的示例。

Update: Added usage of Chrome official headless mode (details here).
更新：新增了Chrome官方无头模式的用法( 在此处查看详细信息)。

With the idea of a basic unit test model, we could easily identify these three major components in the script:

通过基本单元测试模型的思想，我们可以轻松地在脚本中识别出这三个主要组件：

Set up
建立
Run test case
运行测试用例
Tear down
拆除

In this script, it will run test_case_1 and test_case_2 respectively, both with setUp before the test and tearDown after the test. We use unittest as our testing framework in this example. Feel free to use what you like, such as pytest or nose in Python.

在此脚本中，它将分别运行test_case_1和test_case_2 ，在测试之前使用setUp ，在测试之后使用tearDown 。在此示例中，我们使用unittest作为测试框架。随意使用您喜欢的东西，例如pytest或Python中的鼻子。

You can add more test cases, such as filling in forms and clicking on elements, depending on your website's interface.

您可以添加更多测试用例，例如填写表单和单击元素，具体取决于您的网站界面。

步骤2：使用测试环境构建映像 (Step 2: Build an image with your testing environment)

Test running requires a clean environment. To create a clean environment, we definitely do not want to set up a real machine every time and wait for hours to install all the software needed. The container concept helps.

测试运行需要一个干净的环境。为了创建一个干净的环境，我们绝对不希望每次都设置一台真实的计算机，而是等待数小时来安装所有需要的软件。容器概念会有所帮助。

Docker helps you build your testing environment into an image. The image includes all the software that needs to be pre-installed and run on that container like a virtual machine. With Docker, you can just create a new container and pull the same image every time you want to start over from your default environment.

Docker帮助您将测试环境构建到映像中。该映像包括需要预安装并在该容器上运行的所有软件，例如虚拟机。使用Docker，您每次只要要从默认环境重新开始，就可以创建一个新容器并提取相同的映像。

To perform our test with the Selenium Python client, we want our image to pre-install the following:

要使用Selenium Python客户端执行测试，我们希望我们的映像预先安装以下内容：

Python
Python
Google Chrome
谷歌浏览器
Chrome driver
Chrome驱动
Xvfb
Xvfb

Xvfb is a virtual display server that helps you to launch a browser in a headless mode (without display). It is necessary to run the UI tests in a container. It cannot connect to a display output to show the browser visually.

Xvfb是一个虚拟显示服务器，可帮助您以无头模式 (无显示)启动浏览器。必须在容器中运行UI测试。它无法连接到显示输出以直观显示浏览器。

Then, we will also install the Selenium package inside the container. Not all projects need the same list of packages.

然后，我们还将Selenium软件包安装在容器内。并非所有项目都需要相同的软件包列表。

We create a Dockerfile, build the image and upload to our Docker Cloud.

我们创建一个Dockerfile ，构建映像并上传到我们的Docker Cloud 。

You could find this image through this link, or directly pull this image with this command:

您可以通过此链接找到该图像，或使用以下命令直接拉出该图像：

docker pull joyzoursky/python-chromedriver:3.6-xvfb

Then you will have an environment ready for performing the UI tests.

然后，您将为执行UI测试做好准备。

Update: Added new Docker image built with Xvfb deprecated (details here).
更新：添加了不推荐使用Xvfb构建的新Docker映像( 在此处查看详细信息)。

第三步：设置GitLab CI (Step 3: Set up GitLab CI)

GitLab provides a CI/CD Pipelines feature, to continuously build and run your projects. The setup is like other CI tools such as Travis CI or Jenkins. This requires a .gitlab-ci.ymlfile to configure your build process.

manbetx客户端打不开提供CI / CD管道功能，以持续构建和运行您的项目。该设置类似于其他CI工具，例如Travis CI或Jenkins。这需要一个.gitlab-ci.yml文件来配置您的构建过程。

Take a look at this example:

看一下这个例子：

Update: Added example with Xvfb deprecated (details here).
更新：添加了不推荐使用Xvfb的示例( 此处有详细信息)。

When new codes are pushed to the repository, GitLab will look for .gitlab-ci.yml from the root directory, and trigger a build according to your settings.

将新代码推送到存储库后，GitLab将从根目录中查找.gitlab-ci.yml ，并根据您的设置触发构建。

In this script, it pulls the environment image from joyzoursky/python-chromedriver:3.6-xvfb in the first line. Then it installs the required packages like Selenium, sets variables needed, and then it starts the process.

在此脚本中，它从第一行中的joyzoursky/python-chromedriver:3.6-xvfb中提取环境映像。然后，它安装所需的程序包(如Selenium)，设置所需的变量，然后启动该过程。

Note that there are 2 stages of the build process in this example: test and report. In each stage, the jobs in that stage will be run concurrently. You can define tests in the same stage if they could run in sync.

请注意，在此示例中，构建过程分为两个阶段： test和report 。在每个阶段中，该阶段中的作业将同时运行。如果测试可以同步运行，则可以在同一阶段定义测试。

Go to the Pipelines page to see the flow and completion here:

转到“管道”页面以查看此处的流程和完成情况：

So where do we run our tests actually?

那么，我们实际上在哪里运行测试？

GitLab hosts some shared runners which are free. By looking into the build log, we can find the container information in the first few lines:

GitLab托管了一些免费的共享跑步者。通过查看构建日志，我们可以在前几行中找到容器信息：

Running with gitlab-ci-multi-runner 1.10.4 (b32125f)Using Docker executor with image joyzoursky/python-chromedriver:3.5 ...Pulling docker image joyzoursky/python-chromedriver:3.5 ...Running on runner-4e4528ca-project-2749300-concurrent-0 via runner-4e4528ca-machine-1489737516-5e0de836-digital-ocean-4gb...

It shows the container name running on Digital Ocean.

它显示了在Digital Ocean上运行的容器名称。

Of course, you can also create your specific runners to run the test on your self-hosted machines. GitLab supports runners on different platforms including Docker and Kubernetes. But, as GitLab is a new platform, it goes through many updates. So the specific runners may sometimes break when they are out-of-date. You should always refer to the official repository when configuring the setup.

当然，您也可以创建特定的运行程序以在自托管计算机上运行测试。 GitLab在包括Docker和Kubernetes在内的不同平台上支持跑步者。但是，由于GitLab是一个新平台，它需要进行许多更新。因此，特定跑步者有时会在过时时中断。配置设置时，您应始终参考官方存储库。

第4步：定期运行并报告 (Step 4: Run and report periodically)

You may want to have your tests run periodically. You can achieve this by setting up cron jobs, but you may not want to set up a server just to run a one-line cron job. My company’s open source serverless back-end is Skygear. We can use it to write a simple cloud code function with the @every decorator and trigger the test pipeline on an interval of time.

您可能希望定期运行测试。您可以通过设置cron作业来实现此目的，但是您可能不希望仅运行单行cron作业来设置服务器。我公司的开源无服务器后端是Skygear 。我们可以使用它使用@every装饰器编写一个简单的云代码函数，并在一定时间间隔内触发测试管道。

Login to your Skygear portal
登录到您的Skygear门户
Find your Cloud Code Git URL
查找您的Cloud Code Git URL
Clone the quick start codes
克隆快速入门代码
Edit to add the little piece of code below
编辑以添加下面的一小段代码
Push the codes and the cron job will trigger the test every hour
推送代码，cron作业将每小时触发一次测试

Update: Used GitLab 10.0 pipeline scheduler instead of cron job (details here).
更新：使用了GitLab 10.0管道调度程序，而不是cron作业( 此处有详细信息)。

Assume that you have already written some code to generate test reports. Would you like to receive and read the test reports every hour? Of course not. So, we also link Skygear’s free Cloud DB service to store the test result. The system only sends alerts when a test case changes from PASS to FAIL, or FAIL to PASS. This notification approach may vary according to the project need.

假设您已经编写了一些代码来生成测试报告。您想每小时接收和阅读测试报告吗？当然不是。因此，我们还链接了Skygear的免费Cloud DB服务来存储测试结果。仅当测试用例从PASS更改为FAIL或从FAIL更改为PASS时，系统才会发送警报。此通知方法可能会根据项目需求而有所不同。

To save and retrieve data from the Skygear database, we could use the existing SDK. Or if you are a Python user, you may use this little Python DB Client to help write your data handler . We use it to save test results after each test case, and retrieve the reports after running all test suites.

要从Skygear数据库保存和检索数据，我们可以使用现有的SDK。或者，如果您是Python用户，则可以使用这个小的Python DB客户端来帮助编写数据处理程序。我们用它来保存每个测试用例之后的测试结果，并在运行所有测试套件后检索报告。

Finally, we can have the test result alerts sent on demand.

最后，我们可以按需发送测试结果警报。

P.S. We use Slack real time messaging API to do the reporting, so we can receive notifications in the corresponding project channels.

PS：我们使用Slack 实时消息传递API进行报告，因此我们可以在相应的项目渠道中接收通知。

结论 (Conclusion)

Now, whenever there is a code update on the production branch, this automated UI test is triggered and tests are done automatically. Failure results will be pushed back to our Slack channel to notify our developers.

现在，只要生产分支上有代码更新，就会触发此自动UI测试并自动完成测试。失败结果将被推回到我们的Slack频道，以通知我们的开发人员。

The biggest barrier to setting up a free automated UI test is probably researching the tools if you are not already a professional QA tester. Since QA is my full-time job, I hope that sharing our upgraded UI Test stack will help free up your time as well!

如果您还不是专业的QA测试人员，则设置免费的自动UI测试的最大障碍可能是研究工具。由于质量检查是我的全职工作，所以我希望共享升级的UI测试堆栈也将有助于您节省时间！

If you found this useful, please click the ? below so other people can see it too. Thank you!

如果您发现此功能有用，请单击“？”。在下方，其他人也可以看到。谢谢！