在複雜的網絡環境下構建 DevOps 測試的最佳實踐

DevOps 技術簡介

“DevOps”是“Development”和“Operations”的組合。表示通過吸引並協調軟件交付生命週期中的所有參與者來完成其工作 ( 參與者包括業務團隊、架構師、開發人員和測試人員、還有 IT 運營和生產人員等 ) 他們都有一個共同的目標：持續創新，通過持續交付來支持持續創新，並通過持續反饋來改進創新。具體地說，就是在軟件交付和部署的過程中溝通合作，更快速更可靠地發佈質量更好的產品應用。

一個典型的 DevOps 由下面四個不斷循環的步驟所組成：

規劃與度量 (Steer)
開發和測試（Develop/Test）
發佈和部署 (Deploy)
監控和優化 (Operate)

圖 1. DevOps 流程圖

點擊查看大圖

圖 2. 傳統的開發流程

點擊查看大圖

DevOps 強調了系統的整體協作性能，而不是單個參與者或團隊的性能和輸出。

在傳統的工作流中，通過識別需求（由業務團隊進行）、構建需求（由開發和測試團隊進行），然後將需求傳遞到 IT 操作進行部署並交付給用戶。業務團隊想要使解決方案可以盈利（控制成本）；開發和測試團隊想要使解決方案可以處理儘可能多的新特性和缺陷（最大化改變）；IT 操作團隊想要是的解決方案可以擴展、安全且不易被破壞（最大程度地減少更改）。這樣的結果往往會導致最終的項目產品和客戶預期產生偏差，而且工作週期也很長

在 DevOps 工作流中，業務團隊常常提早接觸客戶，以便不斷掌握和重塑需求。開發和測試團隊與操作團隊協同工作，並使用共同目標和流程來構建解決方案，這些解決方案很穩定，而且很容易供 IT 操作團隊進行交付和維護。另外，將相同的部署工具用於所有開發和測試環境，有助於儘早檢測出錯誤並進行修復。

引入 DevOps 之前項目開發遇到的問題

對客戶的需求反饋不及時

客戶的真實需求往往隱藏在具體需求之中，這需要產品經理、開發以及測試人員一起進行挖掘和及時反饋才能得到，但是原先傳統的開發流程並不能及時獲取用戶的需求並及時進行反饋和修正。而且到了項目後期產品預發佈之前經常會出現當前開發的功能與用戶實際需求的偏差，後期的修復成本很高，往往會導致項目的延期。

開發和測試人員的溝通存在障礙

溝通問題還是由於傳統開發流程所導致，只有開發人員正式提交版本之後測試人員才能進行測試，這樣很多本應在重構、迭代初期就能發現的問題只能累積到測試版本提交的時候才能發現。

項目開發週期過長

一方面是由於傳統的編碼測試開發流程工作流模式所導致；另外一方面往往在項目後期產品預發佈之前才發現當前開發的功能與用戶實際需求會有一定程度的偏差，爲了滿足客戶需求，又需要進行編碼測試的流程，這樣預期之外的流程也會導致項目的延期和開發週期變長。

測試範圍不明確

當項目交付週期臨近時，每一個新版本出來以後，測試範圍到底應該覆蓋原先的所有模塊，還是將有限的時間和精力放在新功能和需求測試上面，這是每個測試人員感到疑惑的地方，往往會導致測試範圍的不明確。

項目週期內測試覆蓋率不高

在有限的項目週期內由於不能進行完整測試，會導致測試覆蓋率不高

測試人員搭建環境和重複性手工測試的耗費時間過長

現在軟件的安裝和部署日趨複雜，導致了測試人員很多時候不得不將過多的時間耗費在環境的搭建上面，而且由於自動化測試的普及率不高，重複的手工測試也會耗費很多精力。

其他挑戰和解決方式

除此之外，在部署環境和項目進展過程中還有其他挑戰，其解決方式如下：

挑戰一：網絡環境橫跨幾道防火牆，測試服務器位於不同國家

如圖所示，如果想訪問客戶端（Client）機器，原先的連接步驟是通過防火牆後登陸服務器（也稱登陸節點 Login Node)，然後通過內部防火牆後才能訪問到 Client 機器。

圖 3. 網絡拓撲圖

點擊查看大圖

解決方案：爲了將複雜的網絡環境簡單化，方便開發調試和測試用例的執行，我們採用遠程端口轉發技術來構建 SSH 隧道。通過端口轉發技術，我們將 GUI 和 CLI 後臺的命令調用統一轉發到到指定的登錄節點機器上面，這樣不僅避免了反覆通過 BSO 登錄到實際節點的繁瑣步驟，也爲後面的自動化測試提供了一個外部能訪問的 http 站點。這樣只需要通過直接訪問 Server 就能達到控制和操作 Client 的目的 ( 極大的提高了開發、測試效率 )

圖 4. 網絡解決方案圖

點擊查看大圖

Figure-2. Remote port forwarding.

相關的轉發代碼如下：

 ssh -Nf -g -L 8080:10.0.XX.X:8080 172.X.XXX.XXX 
 ssh -Nf -g -L 2111:10.0.XX.X:2111 172.X.XXX.XXX

注：轉發到遠端：ssh -L 本地端口 : 目標 IP: 目標端口用戶名 @ 目標 IP

轉發到本地：ssh – R 本地端口 : 目標 IP: 目標端口用戶名 @ 目標 IP

-f ：後臺認證用戶 / 密碼，通常和 -N 連用，不用登錄到遠程主機。

-N ：不執行腳本或命令，通常與 -f 連用。

-g ：在 -L/-R/-D 參數中，允許遠程主機連接到建立的轉發的端口，如果不加這個參數，只允許本地主機建立連接。

挑戰二：開發新特性所依賴的硬件版本不穩定

儘管所有功能必須依託該硬件才能進行開發和測試，但是由於特殊條件導致硬件的固件版本並不穩定，給開發和測試帶來了極大的困擾。由圖可以看出，2 月到 3 月這一個月之間固件就升級了 4 次，而且並非每次都是穩定版本。

圖 5. 固件版本更新列表

點擊查看大圖

解決方案：敏捷開發和持續測試的思路就是不要等到固件版本完美了再開始。開發採用設置樁模塊的方式先繞過該硬件 ( 這裏假定固件版本沒有問題 )，進行後續的開發工作。測試先採用一個暫時穩定的內部版本進行測試，待產品每個週期 (Sprint) 結束之前再替換成正式穩定版。

挑戰三：需要支持的操作系統很多，各種 arch 平臺 (LE/BE/x64) 都需要測試

由於項目的需要，Redhat Enterprise/Centos/Ubuntu 的各種版本，以及 x86_64 LE BE 各種架構平臺都需要支持，這給開發和測試帶來了極大的挑戰，如何在有限的時間內完成各種平臺測試和開發。

圖 6. 系統和平臺列表

點擊查看大圖

解決方案：操作系統和架構平臺太多，在限定時間內每個平臺都完整測試顯然不太可能，因此根據市場佔有率的權重，經開發和測試討論生成一個測試矩陣，使用該測試矩陣來在單位時間內覆蓋客戶 / 市場所需的絕大部分平臺和操作系統，測試矩陣覆蓋範圍之內的所有平臺都需要完整測試以保證交付客戶的產品質量；其餘的平臺則採用最小測試方案，來有效的減少測試工作量。與此同時，也在一定程度上提高了測試覆蓋率。

結合 DevOps 的項目開發測試流程簡介

爲了解決了上述的一系列問題，我們依據 DevOps 將整個項目劃分爲：測試範圍策略的制定、行爲驅動開發、測試環境管理、自動化功能測試四大階段，然後再細分爲九個具體子步驟。具體的內容以及相應階段的負責人蔘見下表：

圖 7. 開發步驟圖

點擊查看大圖

圖 8. 完整開發流程圖

點擊查看大圖

結合 DevOps 的項目開發測試具體流程

S1[ 測試範圍策略的制定 ] 制定測試範圍

爲了及時的對客戶需求進行反饋，一旦客戶的需求被產品經理所批准，產品經理需要和開發以及測試人員一起討論明確需求，當需求明確以後開發和測試人員一起討論並制定測試範圍，下面這些問題在需求文檔中都需要得到體現：

用戶的真實需求是什麼？是需要一個新功能還是希望解決一個已知的 bug
爲了滿足客戶需求，是否有些潛在的風險和依賴關係需要被解決？ ( 通常這些潛在的風險會將項目週期放大 )
此次開發最主要的功能是哪些？
我們是否需要引入自動化測試來覆蓋其他的範圍？

注：

1. 這裏假定產品經理角色來完成與客戶的溝通和前期需求討論工作，也可以依據項目的不同由其他人員來代替

2. 測試範圍一旦討論劃分清楚，測試計劃也可以同步生成並提供

S2[ 測試範圍策略的制定 ] 及時矯正測試範圍和資源分配

測試人員需要依據客戶需求和開發人員在開發工作中的設計流程調整來及時矯正測試範圍

開發人員隨着開發的進度不斷深入會發現客戶需求的變更，而且有時由於資源的限制（通常是開發進度 deadline 的原因）導致計劃的調整
一旦開發人員有計劃的調整，測試範圍和資源的分配也要相應進行調整

注：只有開發和測試的高度一致性才能保證項目的進度

S3[ 測試範圍策略的制定 ] 自動化測試用例和腳本的優化

項目的進行過程中，測試人員需要不斷的優化自動化測試用例和腳本

優化和規劃測試用例能保證自動用例的覆蓋範圍最大化

下面一個例子就是 7x24 小時的規劃樣例

表 1. 自動化測試 7x24 小時的規劃樣例

週六 ~ 週日	週一 ~ 週五
完整的自動化測試 ( 覆蓋產品所有模塊 )	自動化冒煙測試	手工測試
48 小時	晚上 19:00~ 次日早上 8:00	早上 9:00~ 下午 18:00

注：這裏假定測試服務器只有一臺，測試人員的所有行爲都需要在該測試環境裏面進行