D介紹-概述

INTRODUCTION

THE SELENIUM PROJECT AND TOOLS

Selenium controls web browsers

Selenium is many things, but at its core it's a toolset for web browser automation that uses the best techniques available to remotely control browser instances and emulate a user's interaction with the browser.

It allows users to simulate common activities performed by end-users; entering text into fields, selecting drop-down values and checking boxes, and clicking links in documents. It also provides many other controls such as mouse movement, arbitrary JavaScript execution, and much more.

Although used primarily for front-end testing of websites, Selenium is at its core a browser user agent library. The interfaces are ubiquitous to their application, which encourages composition with other libraries to suit your purpose.

One interface to rule them all

One of the project's guiding principles is to support a common interface for all (major) browser technologies. Web browsers are incredibly complex, highly engineered applications, performing their operations in completely different ways but which frequently look the same while doing so. Even though the text is rendered in the same fonts, the images are displayed in the same place and the links take you to the same destination. What is happening underneath is as different as night and day. Selenium 「abstracts」 these differences, hiding their details and intricacies from the person writing the code. This allows you to write several lines of code to perform a complicated workflow, but these same lines will execute on Firefox, Internet Explorer, Chrome, and all other supported browsers.

Tools and support

Selenium's minimalist design approach gives it versatility to be included as a component in bigger applications. The surrounding infrastructure provided under the Selenium umbrella gives you the tools to put together your own grid of browsers so tests can be run on different browsers and multiple operating systems across a range of machines.

Imagine a bank of computers in your server room or data centre all firing up browsers at the same time hitting your site's links, forms, and tables—testing your application 24 hours a day. Through the simple programming interface provided for the most common languages, these tests will run tirelessly in parallel, reporting back to you when errors occur.

It's an aim to help make this a reality for you, by providing users with tools and documentation to not only control browsers, but to make it easy to scale and deploy such grids.

Who uses Selenium

Many of the most important companies in the world have adopted Selenium for their browser-based testing, often replacing years-long efforts involving other proprietary tools. As it has grown in popularity, so have its requirements and challenges multiplied.

As the web becomes more complicated and new technologies are added to websites, it's the mission of this project to keep up with them where possible. Being an open source project, this support is provided through the generous donation of time from many volunteers, every one of which has a 「day job」.

Another mission of the project is to encourage more volunteers to partake in this effort, and build a strong community so that the project can continue to keep up with emerging technologies and remain a dominant platform for functional test automation.

History

When Selenium 1 was released in 2004, it was out of the necessity to reduce time spent manually verifying consistent behaviour in the front-end of a web application. It made use of what tools were available at the time, and relied heavily on the injection of JavaScript to the web page under test to emulate a user's interaction.

Whilst JavaScript is a good tool to let you introspect the properties of the DOM and to do certain client-side observations that you would otherwise not be able to do, it falls short on the ability to naturally replicate a user's interactions as if the mouse and keyboard are being used.

Since then, Selenium has grown and matured a lot, into a tool widely used by many—if not most—of the largest organisations around the world. Selenium has gone from a homebrewed test automation toolkit developed at Thoughtworks for a niché audience and a specific use case, to the world's de facto browser automation library.

Just as Selenium RC made use of the tools of the trade available at the time, Selenium WebDriver drives that tradition on by taking the browser interaction part to the browser vendor's home turf, and asking them to take responsibility of the backend, browser-facing implementations. Recently this work has evolved into a W3C standardisation process where the goal is to turn the WebDriver component in Selenium into the du jeur remote control library for user agents.

ON TEST AUTOMATION

First, start by asking yourself whether or not you really need to use a browser. Odds are good that, at some point, if you're working on a complex web application, you will need to open a browser and actually test it.

Functional end-user tests such as Selenium tests are expensive to run, however. Furthermore, they typically require substantial infrastructure to be in place to be run effectively. It's a good rule to always ask yourself if what you want to test can be done using more lightweight test approaches such as unit tests or with a lower-level approach.

Once you have made the determination that you're in the web browser testing business, and you have your Selenium environment ready to begin writing tests, you will generally perform some combination of three steps:

1. Set up the data
2. Perform a discrete set of actions
3. Evaluate the results

You will want to keep these steps as short as possible; one to two operations should be enough much of the time. Browser automation has the reputation of being 「flaky」, but in reality that is because users frequently demand too much of it. In later chapters, we will return to techniques you can use to mitigate apparent intermittent problems in tests, in particular on how to overcome race conditions between the browser and WebDriver.

By keeping your tests short and using the web browser only when you have absolutely no alternative, you can have many tests with minimal flake.

A distinct advantage of Selenium tests are their inherent ability to test all components of the application, from backend to frontend, from a user's perspective. So in other words, whilst functional tests may be expensive to run, they also encompass large business-critical portions at one time.

Testing requirements

As mentioned before, Selenium tests can be expensive to run. To what extent depends on the browser you're running the tests against, but historically browsers' behaviour has varied so much that it has often been a stated goal to cross-test against multiple browsers.

Selenium allows you to run the same instructions against multiple browsers on multiple operating systems, but the enumeration of all the possible browsers, their different versions, and the many operating systems they run on will quickly become a non-trival undertaking.

Let’s start with an example

Larry has written a web site which allows users to order their own custom unicorns.

The general workflow (what we'll call the 「happy path」) is something like this:

• Create an account
• Configure their unicorn
• Add her to the shopping cart
• Check out and pay
• Give feedback about their unicorn

It would be tempting to write one grand Selenium script to perform all these operations–many will try.Resist the temptation! Doing so will result in a test that (a) takes a long time, (b) will be subject to some common issues around page rendering timing issues, and (c) is such that if it fails, it won't give you a concise, 「glanceable」 method for diagnosing what went wrong.

The preferred strategy for testing this scenario would be to break it down to a series of independent, speedy tests, each of which has one 「reason」 to exist.

Let's pretend you want to test the second step: Configuring your unicorn. It will perform the following actions:

• Create an account
• Configure a unicorn

Note that we're skipping the rest of these steps– we will test the rest of the workflow in other small, discrete test cases, after we're done with this one.

To start off, you need to create an account. Here you have some choices to make:

• Do you want to use an existing account?
• Do you want to create a new account?
• Are there any special properties of such a user that need to be taken into account before configuration begins?

Regardless of how you answer this question, the solution is to make it part of the 「set up the data」 portion of the test– if Larry has exposed an API which enables you (or anyone) to create and update user accounts, be sure to use that to answer this question– if possible, you want to launch the browser only after you have a user 「in hand」, whose credentials you can just log in with.

If each test for each workflow begins with the creation of a user account, many seconds will be added to the execution of each test. Calling an API and talking to a database are quick, 「headless」 operations that don't require the expensive process of opening a browser, navigating to the right pages, clicking and waiting for the forms to be submitted, etc.

Ideally, you can address this set-up phase in one line of code, which will execute before any browser is launched:

// Create a user who has read-only permissions--they can configure a unicorn, // but they do not have payment information set up, nor do they have // administrative privileges. At the time the user is created, its email // address and password are randomly generated--you don't even need to // know them. User user = UserFactory.createCommonUser(); //This method is defined elsewhere. // Log in as this user. // Logging in on this site takes you to your personal "My Account" page, so the // AccountPage object is returned by the loginAs method, allowing you to then // perform actions from the AccountPage. AccountPage accountPage = loginAs(user.getEmail(), user.getPassword());

As you can imagine, the UserFactory can be extended to provide methods such as createAdminUser(), and createUserWithPayment(). The point is, these two lines of code do not distract you from the ultimate purpose of this test: configuring a unicorn.

The intricacies of the Page Object model will be discussed in later chapters, but we will introduce the concept here:

Your tests should be composed of actions, performed from the user's point of view, within the context of pages in the site. These pages are stored as objects, which will contain specific information about how the web page is composed and how actions are performed– very little of which should concern you as a tester.

What kind of unicorn do you want? You might want pink, but not necessarily. Purple has been quite popular lately. Does she need sunglasses? Star tattoos? These choices, while difficult, are your primary concern as a tester– you need to ensure that your order fulfillment center sends out the right unicorn to the right person, and that starts with these choices.

Notice that nowhere in that paragraph do we talk about buttons, fields, drop-downs, radio buttons, or web forms. Neither should your tests! You want to write your code like the user trying to solve their problem. Here is one way of doing this (continuing from the previous example):

// The Unicorn is a top-level Object--it has attributes, which are set here. // This only stores the values; it does not fill out any web forms or interact // with the browser in any way. Unicorn sparkles = new Unicorn("Sparkles", UnicornColors.PURPLE, UnicornAccessories.SUNGLASSES, UnicornAdornments.STAR_TATTOOS); // Since we're already "on" the account page, we have to use it to get to the // actual place where you configure unicorns. Calling the "Add Unicorn" method // takes us there. AddUnicornPage addUnicornPage = accountPage.addUnicorn(); // Now that we're on the AddUnicornPage, we will pass the "sparkles" object to // its createUnicorn() method. This method will take Sparkles' attributes, // fill out the form, and click submit. UnicornConfirmationPage unicornConfirmationPage = addUnicornPage.createUnicorn(sparkles);

Now that you've configured your unicorn, you need to move on to step 3: making sure it actually worked.

// The exists() method from UnicornConfirmationPage will take the Sparkles // object--a specification of the attributes you want to see, and compare // them with the fields on the page. Assert.assertTrue("Sparkles should have been created, with all attributes intact", unicornConfirmationPage.exists(sparkles));

Note that the tester still hasn't done anything but talk about unicorns in this code– no buttons, no locators, no browser controls. This method of modelling the application allows you to keep these test-level commands in place and unchanging, even if Larry decides next week that he no longer likes Ruby-on-Rails and decides to re-implement the entire site in the latest Haskell bindings with a Fortran front-end.

Your page objects will require some small maintenance in order to conform to the site redesign, but these tests will remain the same. Taking this basic design, you will want to keep going through your workflows with the fewest browser-facing steps possible. Your next workflow will involve adding a unicorn to the shopping cart. You will probably want many iterations of this test in order to make sure the cart is keeping its state properly: Is there more than one unicorn in the cart before you start? How many can fit in the shopping cart? If you create more than one with the same name and/or features, will it break? Will it only keep the existing one or will it add another?

Each time you move through the workflow, you want to try to avoid having to create an account, login as the user, and configure the unicorn. Ideally, you'll be able to create an account and pre-configure a unicorn via the API or database. Then all you have to do is log in as the user, locate Sparkles, and add her to the cart.

TYPES OF TESTING

TODO: Add paragraphs about acceptance testing, performance testing, load testing, regression testing, test driven development, and/or behavior-driven development (JBehave, Capybara, & Robot Framework), with how they relate to Selenium.

ABOUT THIS DOCUMENTATION

These docs, like the code itself, are maintained 100% by volunteers within the Selenium community. Many have been using it since its inception, but many more have only been using it for a short while, and have given their time to help improve the on-boarding experience for new users.

If there is an issue with the documentation, we want to know! The best way to communicate an issue is to visit https://github.com/seleniumhq/docs/issues and search to see whether or not the issue has been filed already. If not, feel free to open one!

Many members of the community frequent the #selenium IRC channel at irc.freenode.net. Feel free to drop in and ask questions and if you get help which you think could be of use within these documents, be sure to add your contribution! We can update these documents, but it's much easier for everyone when we get contributions from outside the normal committers.

介紹

SELENIUM項目和工具

Selenium控制網頁瀏覽器

Selenium包含多東西，但其核心是一個Web瀏覽器自動化工具集，它是應用於遠程控制瀏覽器和模擬用戶與瀏覽器交互的最佳技術。

它容許用戶模擬終端用戶執行常見操做; 在字段中輸入文本，選擇下拉值和複選框，而後單擊文檔中的連接。它還提供許多其餘控件，如鼠標移動，任意JavaScript執行等。

雖然Selenium主要用於網站的前端測試，但它的核心是瀏覽器用戶代理庫。這些接口在應用程序中無處不在，它鼓勵與其餘庫合成以適應您的目的。

一個接口來管理他們

該項目的指導原則之一是支持全部（主要）瀏覽器技術的通用界面。Web瀏覽器是很是複雜且高度工程化的應用程序，它們以徹底不一樣的方式執行其操做，儘管在執行操做時常常看起來相同。即便文本以相同的字體呈現，圖像也會顯示在相同的位置，而且連接會將您帶到相同的目的地。下面發生的事情就像白天和黑夜同樣不一樣。Selenium「摘錄」了這些差別，隱藏了人們編寫代碼的細節和複雜性。這讓您編寫幾行代碼就能執行復雜的工做流程，用同一套代碼就能Firefox，Internet Explorer，Chrome和全部其餘支持的瀏覽器上執行。

工具和支持

selenium的極簡主義設計方法賦予其多功能性，可做爲更大應用中的組件。Selenium傘下提供的周邊基礎架構爲您提供了將本身的瀏覽器網格放在一塊兒的工具， 這樣測試能夠在各類機器上的不一樣瀏覽器和多個操做系統上運行。

想象一下，您服務器機房或數據中心內的一組計算機會同時觸發瀏覽器，同時擊中您網站的連接，表格和表格 - 天天24小時測試您的應用程序。經過爲大多數經常使用語言提供的簡單編程界面，這些測試能夠不知疲倦地並行運行，並在發生錯誤時向您報告。

咱們的目標是經過爲用戶提供工具和文檔來幫助您實現這一目標，不只能夠控制瀏覽器，還能夠輕鬆擴展和部署此類網格。

誰使用Selenium

世界上許多最重要的公司都採用Selenium進行基於瀏覽器的測試，一般取代涉及其餘專有工具的長達數年的努力。隨着它愈來愈受歡迎，它的要求和挑戰也愈來愈大。

隨着網絡變得愈來愈複雜，新技術被添加到網站中，這個項目的使命就是在可能的狀況下跟上它們。做爲一個開源項目，這種支持是經過從許多志願者慷慨捐贈的時間提供的，每一個志願者都有一份「平常工做」。

該項目的另外一個使命是鼓勵更多的志願者參與這項工做，並創建一個強大的社區，以便該項目可以繼續跟上新興技術的發展，並繼續成爲功能測試自動化的主要平臺。

歷史

當Selenium 1於2004年發佈時，減小了在Web應用程序的前端手動驗證一致行爲的時間，這是沒必要要的。它利用了當時可用的工具，並嚴重依賴將JavaScript注入被測網頁以模擬用戶的交互。

雖然JavaScript是一種很好的工具，可讓您反思DOM的屬性並執行某些客戶端觀察，不然您沒法執行此操做，但它沒法天然複製用戶的交互，就像鼠標和正在使用鍵盤。

從那時起，Selenium已經成長併成熟了許多，成爲全世界許多（甚至是大多數）大型組織所普遍使用的工具。Selenium已經從在Thoughttworks開發的一個自制測試自動化工具包中爲niché的觀衆和一個特定的使用案例轉向了世界上事實上的瀏覽器自動化庫。

就像Selenium RC利用當時可用的交易工具同樣， Selenium WebDriver經過將瀏覽器交互部分提供給瀏覽器供應商的主頁來驅動這一傳統，並要求他們負責後端，面向瀏覽器的實現。最近，這項工做已經發展成爲一個W3C標準化流程，其目標是將Selenium中的WebDriver組件轉變爲用戶代理的du jeur遠程控制庫。

自動化測試

首先，先問本身是否真的須要使用瀏覽器。在某些狀況下，若是您正在處理一個複雜的Web應用程序，您將須要打開瀏覽器並進行實際測試。

可是，功能最終用戶測試（如Selenium測試）運行起來很昂貴。此外，他們一般須要大量基礎設施纔能有效運行。經過使用更輕量級的測試方法（如單元測試或低級方法）來老是問本身是否想要測試什麼是一個很好的規則。

一旦你肯定你在網絡瀏覽器測試業務，而且你的Selenium環境準備好開始編寫測試，你一般會執行三個步驟的組合：

1. 設置數據
2. 執行一組離散的操做
3. 評估結果

您將但願儘量縮短這些步驟; 一到兩次操做應該足夠多。瀏覽器自動化具備「片狀」的聲譽，但實際上這是由於用戶常常要求太多。在後面的章節中，咱們將回到能夠用來緩解測試中明顯的間歇性問題的技術，特別是如何克服 瀏覽器和WebDriver之間的競爭條件。

經過保持簡短的測試和僅在徹底沒有其餘選擇的狀況下使用Web瀏覽器，您能夠進行許多測試，只需不多的剝落。

Selenium測試的一個明顯優點是其從用戶的角度來測試應用程序的全部組件（從後端到前端）的內在能力。換句話說，儘管功能測試運行起來可能很昂貴，但它們同時也包含大量業務關鍵部分。

測試要求

如前所述，Selenium測試的運行可能很昂貴。在多大程度上取決於您正在運行測試的瀏覽器，但從歷史上看，瀏覽器的行爲差別很是大，所以常常是針對多個瀏覽器進行交叉測試的既定目標。

Selenium容許您針對多個操做系統上的多個瀏覽器運行相同的指令，可是全部可能的瀏覽器，它們的不一樣版本以及它們所運行的許多操做系統的枚舉將很快成爲一項非調整性任務。

咱們從一個例子開始

Larry編寫了一個網站，容許用戶訂購他們本身的獨角獸。

通常的工做流程（咱們稱之爲「開心路徑」）就像這樣：

• 建立一個賬戶
• 配置他們的獨角獸
• 將她添加到購物車
• 退房並付款
• 提供關於他們的獨角獸的反饋

編寫一個盛大的Selenium腳原本執行全部這些操做是頗有誘惑力的 - 不少人都會嘗試。 抵制誘惑！ 這樣作會致使測試（a）須要很長時間，（b）會受到圍繞頁面渲染時間問題的一些常見問題的影響，而且（c）若是它失敗了，它不會給你一個簡潔，「可視」的方法來診斷出錯的地方。

測試這種狀況的首選策略是將其分解爲一系列獨立，快速的測試，其中每一個測試都存在一個「緣由」。

讓咱們僞裝你想要測試第二步：配置你的獨角獸。它將執行如下操做：

• 建立一個賬戶
• 配置獨角獸

請注意，咱們正在跳過其他的這些步驟 - 在完成這一步以後，咱們將在其餘小型離散測試案例中測試其他的工做流程。

首先，您須要建立一個賬戶。在這裏你能夠作出一些選擇：

• 你想使用現有的賬戶嗎？
• 你想建立一個新賬戶嗎？
• 在配置開始以前是否須要考慮這種用戶的任何特殊屬性？

不管您如何回答此問題，解決方案都是使其成爲測試的「設置數據」部分的一部分 - 若是Larry公開了API（使您（或任何人）能夠建立和更新用戶賬戶的API），請確保使用它來回答這個問題 - 若是可能的話，你只有在你有一個用戶「在手」以後才能啓動瀏覽器，你的用戶憑據能夠登陸。

若是每一個工做流程的每一個測試都是從建立一個用戶賬戶開始的，那麼每一個測試的執行都會添加不少秒。調用API和與數據庫交談是快速的「無頭」操做，不須要昂貴的過程來打開瀏覽器，瀏覽正確的頁面，單擊並等待表單提交等。

理想狀況下，您能夠在一行代碼中解決這個設置階段，這將在任何瀏覽器啓動以前執行：

建立具備只讀權限的用戶——它們能夠配置獨角獸，但它們沒有設置支付信息，也沒有管理權限。在用戶建立時，它的電子郵件地址和密碼是隨機生成的——甚至不須要知道它們。

// Create a user who has read-only permissions--they can configure a unicorn, // but they do not have payment information set up, nor do they have // administrative privileges. At the time the user is created, its email // address and password are randomly generated--you don't even need to // know them. User user = UserFactory.createCommonUser(); //This method is defined elsewhere.建立一個對象 登陸此網站。登陸到您的我的「個人賬戶」頁面，所以，經過LogiNAS方法返回ActudioPage對象，容許您從ActudiPage執行操做。 // Log in as this user. // Logging in on this site takes you to your personal "My Account" page, so the // AccountPage object is returned by the loginAs method, allowing you to then // perform actions from the AccountPage. AccountPage accountPage = loginAs(user.getEmail(), user.getPassword());// 填入用戶名和密碼

正如你能夠想象的那樣，UserFactory能夠擴展爲提供諸如createAdminUser()和的方法createUserWithPayment()。問題是，這兩行代碼不會分散您的注意力，使其不能完成此測試的最終目的：配置獨角獸。

頁面對象模型 的複雜性 將在後面的章節中討論，但咱們將在這裏介紹這個概念：

您的測試應該由站點中頁面上下文中從用戶角度執行的操做組成。這些頁面存儲爲對象，其中將包含關於如何組成網頁以及如何執行操做的特定信息 - 其中不多應該將您做爲測試人員。

你想要什麼樣的獨角獸？你可能想粉紅色，但不必定。紫色近來頗受歡迎。她須要太陽鏡嗎？星紋身？這些選擇雖然困難，但做爲測試人員是您的主要關注點，您須要確保您的訂單履行中心將正確的獨角獸發送給合適的人員，並從這些選擇開始。

請注意，該段落中沒有關於按鈕，字段，下拉列表，單選按鈕或Web表單的介紹。 你的測試也不該該！ 你想寫你的代碼，像用戶試圖解決他們的問題。這是作這件事的一種方法（繼續前面的例子）：

// The Unicorn is a top-level Object--it has attributes, which are set here. // This only stores the values; it does not fill out any web forms or interact // with the browser in any way.

獨角獸是一個頂層對象，它具備屬性，這裏設置了屬性。這隻存儲值；它不填寫任何Web窗體或以任何方式與瀏覽器交互。 Unicorn sparkles = new Unicorn("Sparkles", UnicornColors.PURPLE, UnicornAccessories.SUNGLASSES, UnicornAdornments.STAR_TATTOOS); // Since we're already "on" the account page, we have to use it to get to the // actual place where you configure unicorns. Calling the "Add Unicorn" method // takes us there.

由於咱們已經在「賬號」頁面上，因此咱們必須使用它來到達配置獨角獸的實際位置。調用「添加獨角獸」方法將咱們帶到那裏。 AddUnicornPage addUnicornPage = accountPage.addUnicorn(); // Now that we're on the AddUnicornPage, we will pass the "sparkles" object to // its createUnicorn() method. This method will take Sparkles' attributes, // fill out the form, and click submit.

既然咱們在AddUnicornPage上，咱們將把「Sparkles」對象傳遞給它的createUnicorn()方法。此方法將採起Sparkles屬性，填寫表單，而後單擊提交。 UnicornConfirmationPage unicornConfirmationPage = addUnicornPage.createUnicorn(sparkles);

 

// The exists() method from UnicornConfirmationPage will take the Sparkles // object--a specification of the attributes you want to see, and compare // them with the fields on the page.

從UnicornConfirmationPage中的exists()方法將使用Sparkles對象——您但願看到的屬性的規範，並將其與頁面上的字段進行比較。 Assert.assertTrue("Sparkles should have been created, with all attributes intact", unicornConfirmationPage.exists(sparkles));

請注意，測試人員尚未作任何事情，只是談論這個代碼中的獨角獸 - 沒有按鈕，沒有定位器，沒有瀏覽器控件。即便下週Larry決定再也不喜歡Ruby on Rails並決定在最新的Haskell綁定中從新實現整個站點，這種對應用程序進行建模的方法也容許您保持這些測試級命令的位置和不變。與Fortran前端。

你的頁面對象將須要一些小的維護，以符合網站的從新設計，但這些測試將保持不變。採用這種基本設計，您將但願經過儘量少的面向瀏覽器的步驟繼續完成工做流程。您的下一個工做流程將涉及在購物車中添加獨角獸。爲了確保購物車保持其狀態，您可能須要進行屢次此測試：在您開始以前，購物車中是否有多個獨角獸？購物車中可裝多少個？若是您建立具備相同名稱和/或功能的多個，它會中斷嗎？它只會保留現有的或將添加另外一個？

每次移動工做流程時，都要儘可能避免建立帳戶，以用戶身份登陸並配置獨角獸。理想狀況下，您能夠建立一個賬戶並經過API或數據庫預先配置獨角獸。而後，您所要作的就是以用戶身份登陸，找到Sparkles，並將其添加到購物車。

測試類型

TODO：添加關於驗收測試，性能測試，負載測試，迴歸測試，測試驅動開發和/或行爲驅動開發（JBehave，Capybara和Robot Framework）的段落，以及它們與Selenium的關係。

關於此文檔

這些文檔與代碼自己同樣，由Selenium社區內的志願者維護100％。自從成立以來，許多人一直在使用它，可是還有不少人只是在短期內使用它，而且花時間幫助改善新用戶的入職體驗。

若是文檔存在問題，咱們想知道！溝通問題的最佳方式是訪問https://github.com/seleniumhq/docs/issues 並搜索以查看問題是否已經提交。若是沒有，請隨時打開一個！

社區的許多成員在irc.freenode.net上頻繁出現#selenium IRC頻道。隨意下載並提出問題，若是您得到了您認爲能夠在這些文檔中使用的幫助，請務必添加您的貢獻！咱們能夠更新這些文檔，可是當咱們從常規提交者以外得到貢獻時，每一個人都會更容易。