持續集成和QA

Question

在我的項目中，我們正在建立持續集成環境，並且作爲此過程的一部分，建議在QA測試周期中同時修復缺陷。

將它發佈到質量保證環境時，通常採用的流程是什麼？這些修補程序是否立即部署到質量保證環境中（集成測試後），還是累積到當前測試周期完成？

Answer 1

給自己一個不斷移動的目標是非常困難的。在部署到QA之前，我們傾向於批量修復 - 通常每日部署QA。 QA在早上第一件事情時就會獲得輸出，如果一個真正關鍵的錯誤阻礙了大量測試，那麼QA就會「按需要」。

CI更多的是一個基本的代碼質量基準（例如，它構建，它通過單元/煙霧測試） - 不需要QA需要從CI中獲取每個構建。

Answer 2

在我理解正確的情況下，您問的是具有持續積分週期的項目中QA週期的持續時間是多少？

我們使用日常QA週期。如果成功的話，夜間測試可以在第二天進行測試。

Answer 3

nitzmahone的答案是平衡您從CI系統獲得的更頻繁的構建，QA需要擁有已知的測試目標。

您可以利用持續集成在作爲每個版本的一部分運行的單元/煙霧測試之上獲得額外的測試。這裏有幾件事情我做：

• 建立在你的CI系統的作業運行計劃作業（如每天，而不是通過修改源代碼被觸發）上做了性能測試你的系統，並記錄結果。通過這種方式，您可以隨時追蹤性能，並發現對性能有不利影響的任何更改。
• 如果構建和單元測試成功，並且讓IT監視器（例如Nagios）檢查部署的系統，讓您的CI構建作業自動部署您的系統。這充當了一個快速和骯髒的系統測試，通常可以發現單元測試未捕獲到的錯誤。我寫了一個blog post，如果你對這種類型的測試感興趣，你可能會覺得有用。

Answer 4

立即部署到QA環境（集成測試後），這些修補程序或者是他們累積，直到目前的測試周期的完成。

這取決於。如果問題是阻止並且不允許測試人員運行更多測試，爲了完成整個測試計劃（即完成他們的工作），那麼顯然需要立即發佈修復程序。如果問題不是阻塞問題，那麼排隊修復並在下一個版本中提供它可能更可取。但是這需要大量的管理工作（記錄問題，註釋測試用例等）。

現在，如果QA在開發過程中很早發生（即，如果您沒有使用非常連續的開發週期），如果測試人員正在與開發人員密切合作，那麼一旦發現問題就可以解決問題，甚至避免創建一個錯誤清單（大量浪費）。

Answer 5

在測試周期開始時我傾向於如果有阻止被解決的bug只需要新版本。這可以讓我的團隊避免新建和驚喜迴歸造成的衝擊。發佈的早期部分通常用於瞭解功能是如何實際實現的，以及產品是否符合最低限度的接受標準。

在測試周期的中間，我更頻繁地接受構建，以確保修復儘可能多地曝光，並儘快識別錯誤修復的錯誤。除了我們正在進行長期壓力測試或性能測試的環境以外，這通常是每日一次。

隨着發佈版本的臨近，我對哪些bug進行了更多控制（例如：當前版本是分支的，我們有更嚴格的代碼行策略），我們將繼續構建版本，因爲我們發現版本阻止的bug 。目前，構建通常被稱爲測試版或候選版。

Answer 6

這取決於項目開發風格。假設你是敏捷團隊。

• 有迭代
• CI的目的是發現和迭代過程中修正錯誤迭代結束，並在測試中，測試的兩個層次。測試類型集中在單元，功能和故事實施上
• 您在此類敏捷團隊中發現的錯誤應該在發佈到質量保證環境之前得到修復
• QA環境應該用於執行迴歸和集成測試。這種測試的目的應該是尋找回歸和整合而不是功能功能

以上是一般的做法，偏離當然，這在很大程度上取決於你的軟件和團隊的性質CI過程中發現

Answer 7

錯誤開發團隊儘快發現它們需要修復。質量保證團隊在定期發佈週期或補丁週期期間收到常規版本，而非CI構建問題。

由於CI建設汽車測試吸引了衆多QA和非QA相關的錯誤，所以直接導致對其他QA活動表現沉重的負擔。

所有取決於公司QA政策，有些人可能還是有些人可能不與我的觀點一致:)

Answer 8

這可以通過將QA團隊爲子團隊即內部和外部來完成。內部質量保證部門作爲開發團隊的一部分負責開發經理和外部質量保證部門的工作，對正在開發的產品進行測試。

內部QA團隊負責product.They的健全測試評估通過執行健全流動構建的基本健康檢查。如果任何理智流程失敗或者主要/新創建的模塊崩潰，IQA會將電子郵件路由到發佈經理/開發經理以開發新的構建。一旦理智流程通過，構建已準備好由外部QA團隊負責測試。

構建計劃每天的基礎上，故障是由外部質量檢查的報告。內部質量檢查人員在那裏進行理智流動，並與開發人員進行快速溝通和討論。通過這種方式，可以提升整個過程，並通過將其添加到開發團隊中來降低QA-Dev差距。

希望這回答你的問題！歡呼:)