Bamboo 測試工程師

自動化測試

測試工程師除了利用Bamboo 自動化部署測試環境，還有一個最大的需求，就是驅動自動化測試用例的執行。

很多測試工程師會糾結於Bamboo 支持什麼測試框架，類似的疑問開發工程師也會問到，比如是否支持某種語言的編譯構建，總是擔心不能夠支持自己所使用的技術棧。

其實這都是對CI/CD 這類工具平台不夠理解造成的。CI/CD 工具是無所謂使用者使用什麼技術棧的，因為它的主要作用是驅動任務在某個環境中執行，雖然主機有操作系統的限制，但是執行節點可以是各類系統，也可以遠程到特定執行環境中去執行某項任務。

所以無論是什麼語言，無論是哪種框架，測試工程師只要關注是否能夠通過命令行啟動就可以了，而CI/CD 工具只是去啟動它們。

當然，這是最基礎的功能之一。我們自然是希望，工具不但能夠幫我們執行，還期望，能夠幫我們覆蓋更多的場景。比如測試環境部署完成後去執行，執行完成後更新測試用例的執行結果到用例管理平台，更友好的展示自動化測試報告等等。

客觀講，Bamboo 對測試工程師來說，並沒有那麼友好。如果不熟悉，你可能都找不到測試工作的入口，它並沒有一個專門的測試類項目。因此，只能使用構建類項目來覆蓋測試工程師的構建工作和測試工作。

與DevOps 工程師一樣，測試工程師的自動化測試代碼也維護在代碼倉庫，也會需要自身的構建。我曾經做過一個方案，是把自動化測試封裝在容器鏡像中，隨應用的版本發布，供團隊內部人員方便的調用。

如果你的團隊正好在用這種方式，也可以在Bamboo 中完成這項工作。

更多時候，我們只是在Bamboo 中使用特定的容器環境去執行自動化測試代碼。

自動化測試任務的配置通常沒有那麼複雜，主要是被測對象的一些信息，如果自動化測試框架設計中引入了中間件，那麼中間件的信息也需要作為輸入做好配置。

如果我們使用單元測試框架來執行自動化測試腳本，那測試報告會很自然的被收集到測試標籤頁。

除此之外，我們也可以使用一些第三方的測試報告框架，比如Allure Reporting Tool ，Bamboo 也有該報告框架集成的插件。

但這其實並不符合測試管理者的辦公習慣，沒有人會每天進入到繁多的自動化任務頁面去查看一個個的測試報告，他們更需要一個集中展示的報告平台。

測試場景的觸發規則靈活多變，幾乎是一種隨心所欲的操作，但有一些必要的觸發場景還是要保證到。

比如部署完成後，觸發自動化測試流水線。

再比如，自動化測試代碼有變更，理應也觸發自動化執行，以確保沒有自動化代碼變更帶來的代碼層面的問題。在這一點上，其實跟開發工程師的構建流水線觸發很類似。

其他觸發規則就需要根據團隊協作的習慣，做一些梳理。

原則上我們是建議自動化測試流水線順序執行，如果需要並行，就需要注意各流水線之間是否存在干擾，衝突主要集中在數據和性能上。這方面，則需要以自動化測試架構設計為主要切入點了。

如果說Bamboo 只是用作驅動自動化執行，就浪費了Atlassian 生態的價值。

在流水線執行記錄的Issues 標籤頁下，可以關聯Jira 上的缺陷記錄，這個關聯信息，在Jira 頁面上也會有所體現。在這裡，可以方便的看到關聯的缺陷修復進度。