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!

如果您發現此功能有用，請單擊“？”。在下方，其他人也可以看到。謝謝！