☰

Ubuntu團隊是如何進行自動化測試的？

tag-icon • tag-icon canonical quality
Ubuntu團隊是如何進行自動化測試的？

Ubuntu 團隊如何確保錯誤不會再出現？

我已經看過好幾次了。軟體包安裝後無法使用。

是的，有時錯誤會很快修復。

但我認為沒有努力改進自動化測試，以便該錯誤不會再次出現。

以下是過去兩週影響我的兩個例子：

還有更多範例，但列出它們並不是問題的一部分。

Bug 頁面的一則評論vsftp：

請幫我們測試這個新包。看https://wiki.ubuntu.com/Testing/EnablePropose有關如何啟用和使用建議的文件。您的回饋將幫助我們將此更新發佈給其他 Ubuntu 用戶。

好的，但是上面引用中的“測試”是手動的測試。

確保品質自動化的需要進行測試。

對我來說手動測試是浪費時間。另一方面，建立自動化測試確實可以確保品質。

這裡再次提出問題：

Ubuntu 團隊如何確保錯誤不再出現？

這個問題的歷史

首先，標題是「Ubuntu 團隊如何確保錯誤不再出現？」。現在是「Ubuntu團隊是如何做自動化測試的？」。這樣做是因為我相信手動測試不是解決方案。請不要對僅解釋手動測試完成方式的答案投反對票。

答案1

Ubuntu 確實有自動化測試。例如，自動化測試用於防止您的第一個錯誤範例再次發生。我是修復你提到的第一個 vsftpd bug 的人，同時我還添加了一個自動化測試來防止同樣的事情再次發生。您可以在發佈到錯誤本身的變更日誌條目中看到這一點：

vsftpd (3.0.2-1ubuntu2.14.04.1) trusty; urgency=medium

  * d/p/ubuntu-seccomp-gettimeofday.patch: permit gettimeofday() for logging
    calls (LP: #1219857).
  * Add dep8 smoke test.
 -- Robie Basak <[email protected]> Tue, 29 Apr 2014 15:33:07 +0000

我不知道為什麼您認為該錯誤是缺乏自動化測試的一個例子，因為我在該錯誤中多次提到了這一點。例如，我在摘要中說「新增了 dep8 測試以在將來檢測此問題」和「包含的 dep8 測試自動驗證此錯誤的修復」。

請記住，Ubuntu 是一個發行版：它是許多我們稱為上游的外部專案的整合聚合。如果沒有更廣泛的自由軟體生態系統中其他人的工作，Ubuntu 就不可能實現，同樣，我們經常依賴上游作者提供測試，因為他們是軟體方面的專家。

此外，由於我們是不同項目的聚合，因此單一的自動測試基礎設施沒有意義。不同的地區有不同的需求。因此，我們的測試策略非常廣泛，可以滿足這些需求，涵蓋透過許多不同基礎設施進行的手動和自動測試。

當上游專案提供自動化測試時，我們將它們作為套件建置的一部分運行。如果測試未通過，則套件建置失敗。確保以這種方式啟用任何可用的自動化測試是我們的一部分主要包含的要求:如果套件附帶了一個測試套件，並且沒有明顯的原因導致它在構建期間無法工作（例如，它需要root 權限或網絡訪問權限），則應該在包構建期間運行它，並且失敗的測試套件應該使構建失敗。

此外，我們根據名為的規格執行“自動安裝套件測試”dep8，旨在測試包之間的整合是否正常運作。回歸 dep8 測試的軟體包更新在修復之前不會進入開發版本。

我不太熟悉桌面和電話團隊所做的自動化測試，但我知道有更多機制，因為多年來我看到了對它們的引用，其中包括我認為令人印象深刻的自動化 GUI 測試。我歡迎另一個涵蓋自動化桌面和電話測試的答案。

答案2

有多種方法。

  1. 很多眼睛。

    Ubuntu 是開源的，這意味著任何人都可以查看程式碼並了解問題所在。有興趣查看代碼的人通常會在其中或在使用代碼時發現錯誤，並且在啟動板上報告它們和公眾甚至可以修復它們。

    當您測試並建議修復後，您要求與主 Ubuntu 軟體包合併。其他開發人員會審查此更改，如果獲得批准，則會添加它。

    因為任何人都可以修復它們，所以它們很快就會被發現並接受審查，因此它們不太可能停留一段時間。這引出了下一點。

    這些眼睛還包括電腦眼睛：

    必須記錄/演示上游 QA 流程，並從 SRU 追蹤錯誤連結。在其他情況下，此類上游自動測試不可用...

    這表示通常自動測試已經到位。

  2. 測試版發布

    在 Ubuntu 向公眾發布之前，有多個測試版本。目前是 15.10 Beta，即將發布發佈於2015年10月22日。在它發布之前，很多很多人都會使用、審查和修復錯誤（例如5個月22天在這種情況下）。

    這意味著任何錯誤都會及時刪除（因為「眾眼」），典型用戶不會受到影響，因為它在正式發布之前就已修復。

  3. 專家程式碼編寫者

    善於編寫高品質程式碼的人就是正在編寫程式碼的人。不只是一個人這樣坐著寫 Ubuntu：

    這裡有來自世界各地的員工，也有 Ubuntu 背後的公司 Canonical 的員工。所有這些人都貢獻了一點新程式碼。如果我寫2000行程式碼，就會有很多bug。如果200個人只寫10個，就會少很多。

  4. 穩定的基礎

    據我所知，Ubuntu 並不是每次有新版本時都從頭開始重寫。相反，下一個版本將從當前版本開始（即 2015 年 4 月 30 日，15.10 和 15.04 相同），並從那裡添加新功能。

    如果您有良好的工作基礎，那麼您需要編寫的程式碼就會減少，並且可以信任已經存在的程式碼。如果您可以依賴現有的內容，那麼出現的錯誤就會減少。

  5. 版本控制與記錄軟體

    如果相同錯誤多次出現（在不同版本中，或者修復不起作用，或者由於另一個補丁而導致錯誤再次出現），那麼他們有文件來解釋它是如何修復的 - 並且他們可以再次修復它。

據我所知，沒有自動化測試。但什麼是自動化測試呢？如果編譯通過，是那個嗎？你不能只說「自動化測試」而不解釋它是什麼

答案3

不要寫有錯誤的程式碼。哈哈，好吧。我失去了對此寫詳細回應的意願。這是一篇不錯的文章： https://www.iiitd.edu.in/~jalote/papers/CommonBugs.pdf

這是一本關於製作的好書C++ 中的錯誤

最好的答案可能是只承擔一些軟體開發任務，然後親自看看問題來自哪裡。根據我的經驗，處理意外的輸入/結果是一個相當大的問題。然後還有下游錯誤。就像有人在 iostream.h 中發現漏洞一樣，呼叫該程式庫的每個軟體也可能存在該錯誤，至少需要進行審查。

至於自動化測試，確實存在，但也有限制。我不知道有哪個解決方案適用於每種語言。如果您真的有興趣，請為我們編寫一個帶有人工智慧的遺傳程式碼調試器。據我所知，所有這些都還處於起步階段，以下是博士生的一些工作： https://www.cs.cmu.edu/~clegoues/docs/legoues-icse09.pdf

相關內容