作者 | 趙志佳

持續(xù)測(cè)試基礎(chǔ)設(shè)施的必要性

基礎(chǔ)設(shè)施作為應(yīng)用程序的支柱，為之提供關(guān)鍵的運(yùn)行環(huán)境、網(wǎng)絡(luò)連接和資源調(diào)度等支持。一旦基礎(chǔ)設(shè)施出現(xiàn)故障，整個(gè)應(yīng)用生態(tài)系統(tǒng)都可能面臨嚴(yán)重的連鎖反應(yīng)，如性能降低、數(shù)據(jù)丟失乃至系統(tǒng)崩潰。因此，基礎(chǔ)設(shè)施的穩(wěn)定性和可靠性對(duì)于運(yùn)行在其上的應(yīng)用程序至關(guān)重要。

持續(xù)測(cè)試可以在基礎(chǔ)設(shè)施的整個(gè)生命周期中進(jìn)行檢查，確保一切運(yùn)行正常，盡早發(fā)現(xiàn)并解決潛在問(wèn)題，減少影響擴(kuò)散。此外，持續(xù)測(cè)試通過(guò)為團(tuán)隊(duì)提供即時(shí)的狀態(tài)反饋，有助于提高基礎(chǔ)設(shè)施的可維護(hù)性和可擴(kuò)展性，進(jìn)而支持業(yè)務(wù)持續(xù)增長(zhǎng)和變化的需求。

因此，持續(xù)測(cè)試不僅是持續(xù)交付高質(zhì)量軟件的必要保障，對(duì)于基礎(chǔ)設(shè)施而言，其價(jià)值和影響更為深遠(yuǎn)。

本文來(lái)分享一下我們團(tuán)隊(duì)是如何對(duì)基礎(chǔ)設(shè)施進(jìn)行測(cè)試的。

測(cè)試的范圍

首先我們要識(shí)別出需要測(cè)什么。在 IaC（基礎(chǔ)設(shè)施即代碼）的實(shí)踐中，我們以測(cè)試金字塔和敏捷測(cè)試四象限為指導(dǎo)原則，適用的測(cè)試方案包括：

• 單元測(cè)試：對(duì)實(shí)現(xiàn)中的特殊邏輯，比如環(huán)境差異、批量處理等進(jìn)行部署前的驗(yàn)證。
• 組件測(cè)試：對(duì)部署的獨(dú)立組件進(jìn)行驗(yàn)證，部署結(jié)果與預(yù)期一致。比如 S3 bucket 部署配置。
• 功能測(cè)試：對(duì)多個(gè)需要串聯(lián)合作使用才能達(dá)成實(shí)現(xiàn)一個(gè)功能的組件進(jìn)行驗(yàn)證，保證組件間配置的正確性。比如通過(guò)公網(wǎng)域名可以訪問(wèn)到 app。
• 冒煙測(cè)試：在服務(wù)、組件部署完成之后進(jìn)行端到端驗(yàn)證，確保服務(wù)基本可用和出入口配置的正確性。
• 安全性測(cè)試：驗(yàn)證各項(xiàng)安全配置是否已經(jīng)啟用。比如數(shù)據(jù)庫(kù)、域名是否采取了 TLS 且無(wú)法在不加密情況下進(jìn)行連接。其它的如權(quán)限控制、代碼漏洞等。
• 可靠性測(cè)試：基礎(chǔ)設(shè)施的容災(zāi)耐力、數(shù)據(jù)，混沌工程等。
• 部署測(cè)試：確保應(yīng)用在發(fā)布的過(guò)程中，平臺(tái)提供了正確可用的部署能力。
• 性能、可用性測(cè)試：服務(wù)的響應(yīng)時(shí)間、吞吐量、并發(fā)用戶數(shù)等指標(biāo)。由于平臺(tái)在服務(wù)間添加了一些基礎(chǔ)設(shè)施級(jí)組件和服務(wù)，如 Service Mesh、Styra，所以也會(huì)受到影響。因此，平臺(tái)團(tuán)隊(duì)可以構(gòu)建一個(gè)覆蓋了影響范圍的簡(jiǎn)單應(yīng)用，對(duì)其進(jìn)行驗(yàn)證。

明確了測(cè)試方案，我們就需要識(shí)別測(cè)試優(yōu)先級(jí)，在不同階段開展相應(yīng)的測(cè)試：

• 首先覆蓋關(guān)鍵路徑和高價(jià)值，如單元測(cè)試、組件測(cè)試、功能測(cè)試。這些代碼變化而引發(fā)的測(cè)試在代碼變化時(shí)都應(yīng)該進(jìn)行。
• 其次是覆蓋代碼變化之外由我們可控因素導(dǎo)致的問(wèn)題，如證書到期、磁盤空間滿、token 失效等，保證運(yùn)行時(shí)環(huán)境相關(guān)組件和功能。如冒煙測(cè)試、部署測(cè)試、可用性測(cè)試等?？梢栽谄脚_(tái)功能上了生產(chǎn)環(huán)境后，核心功能交付無(wú)壓力時(shí)進(jìn)行。
• 最后是在平臺(tái)相較穩(wěn)定后（即被測(cè)功能不會(huì)有大的變動(dòng)時(shí)），以提高平臺(tái)可靠性為目的的測(cè)試。用來(lái)驗(yàn)證在面對(duì)代碼之外，不可控的因素導(dǎo)致的問(wèn)題發(fā)生時(shí)我們的應(yīng)對(duì)能力。如外部依賴變化、數(shù)據(jù)恢復(fù)能力、容災(zāi)重建能力等。通常在平臺(tái)上的應(yīng)用服務(wù)在生產(chǎn)環(huán)境已有真實(shí)用戶投入使用后進(jìn)行。

測(cè)試工具的選擇

市面上有很多可以測(cè)試工具可以選擇：

• 最基礎(chǔ)和單一的是 Shell 腳本語(yǔ)言，典型如 Bash。
• 之后是應(yīng)用開發(fā)語(yǔ)言的測(cè)試框架，如 Bash 的 bats、Ruby 的 RSpec 和 JavaScript 的 Jest。

1. 最后是在語(yǔ)言提供的能力上對(duì)三方 cli 和 API 進(jìn)行封裝的測(cè)試庫(kù)，如 Ruby 的 AWSpec，Go 的 Terratest 等。

比較來(lái)看，shell 優(yōu)點(diǎn)是原生，直接調(diào)用服務(wù)方提供的 CLI，如 AWS CLI, Kubectl；缺點(diǎn)是面對(duì)復(fù)雜場(chǎng)景編寫起來(lái)費(fèi)心費(fèi)力；

使用封裝起來(lái)的測(cè)試庫(kù)看起來(lái)很簡(jiǎn)單，但開發(fā)者日常就要使用 CLI/Curl 命令來(lái)進(jìn)行基礎(chǔ)驗(yàn)證，而用封裝庫(kù)進(jìn)行開發(fā)就需要多學(xué)習(xí)一套知識(shí)；而且在被測(cè)服務(wù)發(fā)布新功能后，平臺(tái)想跟進(jìn)卻發(fā)現(xiàn)測(cè)試庫(kù)沒(méi)能跟進(jìn)，導(dǎo)致最后還得用原生方式來(lái)寫。比如 AWSpec 支持 RDS，但是很長(zhǎng)時(shí)間都沒(méi)有支持 Aurora。如果已經(jīng)寫了很多測(cè)試，就只能在 Aurora 這里使用其它方式驗(yàn)證，最后導(dǎo)致各處驗(yàn)證方式不統(tǒng)一。

所以我推薦選擇團(tuán)隊(duì)熟悉的應(yīng)用開發(fā)語(yǔ)言的測(cè)試框架，優(yōu)點(diǎn)如下：

• 可以直接通過(guò)系統(tǒng)命令調(diào)用 CLI，開發(fā)者平常工作怎么驗(yàn)證，測(cè)試代碼就怎么寫，拷貝過(guò)來(lái)能用。
• 相較 shell 來(lái)說(shuō)，良好的測(cè)試框架支持。比如在多級(jí) JSON 中驗(yàn)證部分內(nèi)容，jq 驗(yàn)證起來(lái)就很麻煩。
• 各種驗(yàn)證場(chǎng)景統(tǒng)一實(shí)現(xiàn)，不用學(xué)習(xí)多框架或多語(yǔ)言。比如 Terratest 只適合驗(yàn)證 infra，如果需要想做冒煙測(cè)試，還要另起爐灶。
• 如果確實(shí)有必要集成測(cè)試庫(kù)，也可以按需集成。

我的選擇則是 Ruby/RSpec，因?yàn)?Ruby 簡(jiǎn)潔自然的語(yǔ)法和 RSpec 的強(qiáng)大驗(yàn)證器，讓測(cè)試代碼中很少出現(xiàn)語(yǔ)言自身導(dǎo)致的難懂和多余的代碼。

如何測(cè)

組件測(cè)試加上人工驗(yàn)證是交付環(huán)境能夠成功部署的主要信心來(lái)源，而在有邏輯分支的時(shí)候，單元測(cè)試可以用來(lái)成為對(duì)組件測(cè)試的補(bǔ)充：組件測(cè)試驗(yàn)證代碼的主干，單元測(cè)試在部署前來(lái)驗(yàn)證分支，以實(shí)現(xiàn)對(duì)代碼的測(cè)試全覆蓋。

下面我們基于 Terraform 實(shí)現(xiàn)，以單元測(cè)試和組件測(cè)試為例進(jìn)行測(cè)試。其它 IaC 實(shí)現(xiàn)和不依賴外部工具的測(cè)試都可以參考來(lái)實(shí)現(xiàn)。

注意這些由代碼變化產(chǎn)生的測(cè)試都應(yīng)在 Pipeline 的流水線中，而不是手動(dòng)觸發(fā)。任何不攔截在上線必經(jīng)之路的測(cè)試，最終都將無(wú)人理睬。

部署前

(1) 單元測(cè)試

在 Terraform 中，通常需要人工來(lái)驗(yàn)證 terraform plan 的結(jié)果，但是它只能覆蓋當(dāng)前 state 和配置參數(shù)下的結(jié)果。當(dāng)我們代碼中包含邏輯時(shí)，我們就需要通過(guò)配置 local backend、不同配置和 state 文件來(lái)本地驗(yàn)證對(duì)應(yīng)的 plan 結(jié)果。示例：

(2) 檢查 plan 結(jié)果

在部署流水線中，通過(guò) terraform plan 加人工驗(yàn)證。在測(cè)試環(huán)境中 apply 后，人工測(cè)試來(lái)保證正確性。驗(yàn)證完成后，對(duì)于后續(xù)環(huán)境來(lái)說(shuō)在測(cè)試環(huán)境的 plan 結(jié)果就是其它環(huán)境的參考輸入，由人工核對(duì)確認(rèn)后進(jìn)行 apply。

部署后

在資源生成后，我們便可以通過(guò)測(cè)試腳本調(diào)用 CLI/API 請(qǐng)求目標(biāo)資源，來(lái)驗(yàn)證產(chǎn)生的結(jié)果與預(yù)期一致。比如服務(wù)可以被成功訪問(wèn)、數(shù)據(jù)庫(kù)確實(shí)被創(chuàng)建出來(lái)并配有正確的參數(shù)，密鑰管理器中被保存下來(lái)的數(shù)據(jù)庫(kù)密鑰我們可以成功連接到數(shù)據(jù)庫(kù)等等。與應(yīng)用測(cè)試一樣，任何一條失敗的測(cè)試都應(yīng)讓我們的 Pipeline 變紅，向團(tuán)隊(duì)告警。并確保只有在前一個(gè)環(huán)境被驗(yàn)證通過(guò)后，我們才向下一個(gè)環(huán)境前進(jìn)。

一個(gè)測(cè)試的范例

我們以 Ruby/RSpec 為例。在一個(gè)代碼庫(kù)中，以生成的目標(biāo)資源上下文劃分測(cè)試文件。

比如對(duì)于 RDS 數(shù)據(jù)庫(kù)的創(chuàng)建，我們可以組織這三個(gè)文件：

• rds_spec.rb: 用來(lái)驗(yàn)證 AWS RDS 生成的資源，如 cluster、db parameter。
• db_spec.rb: 用來(lái)驗(yàn)證在 DB 中進(jìn)行的設(shè)置，比如支持動(dòng)態(tài)數(shù)據(jù)庫(kù)憑證所在 DB 中創(chuàng)建的資源，DB 的 extension 被正確啟用。
• vault_spec.rb：用來(lái)驗(yàn)證 Vault 中創(chuàng)建的資源、比如 master 憑證的存儲(chǔ)、支持動(dòng)態(tài)數(shù)據(jù)庫(kù)憑證所需的資源。

一個(gè)文件中的組織結(jié)構(gòu)如下：

下面是一個(gè)驗(yàn)證 RDS 的 DB parameter 按預(yù)期被創(chuàng)建的例子：

可以看出測(cè)試代碼非常的語(yǔ)義化，沒(méi)有額外的數(shù)據(jù)結(jié)構(gòu)定義和難懂的語(yǔ)法?？疵靼琢诉@個(gè)測(cè)試，其它命令行相關(guān)的測(cè)試也就全都會(huì)寫了。平臺(tái)開發(fā)者們可以專注于業(yè)務(wù)驗(yàn)證，而不會(huì)因?yàn)闇y(cè)試框架帶來(lái)額外的負(fù)擔(dān)。

IaC 可以測(cè)試驅(qū)動(dòng)開發(fā)嗎？

當(dāng)然，只需要我們能在編寫功能代碼之前被測(cè)內(nèi)容是什么。我們可以通過(guò)各種文檔來(lái)識(shí)別出被測(cè)內(nèi)容，比如 Kubectl、AWS、Vault 等 CLI，或各種服務(wù)的 API。如果我們無(wú)法識(shí)別出被測(cè)內(nèi)容時(shí)，那就需要通過(guò)拆解步驟、手動(dòng)部署資源等方式分析出來(lái)。像在其它語(yǔ)言進(jìn)行測(cè)試驅(qū)動(dòng)開發(fā)時(shí)一樣，小步驗(yàn)證，紅綠重構(gòu)。

進(jìn)行測(cè)試驅(qū)動(dòng)在其它語(yǔ)言中帶來(lái)的優(yōu)點(diǎn)，在 IaC 也一樣大部分適用：

• 促進(jìn)模塊化設(shè)計(jì)和提交
• 簡(jiǎn)化調(diào)試過(guò)程
• 更快地反饋循環(huán)
• 更好地設(shè)計(jì)決策
• 易于重構(gòu)
• 減少過(guò)度工程
• 保障測(cè)試覆蓋率：這點(diǎn)需要單獨(dú)提一下，目前還沒(méi)有什么好的方案可以檢查 IaC 代碼的測(cè)試覆蓋率，所以在測(cè)試驅(qū)動(dòng)中「只實(shí)現(xiàn)剛好可以通過(guò)測(cè)試的代碼」對(duì)保障覆蓋率很重要。

總結(jié)

自動(dòng)化測(cè)試是高代碼質(zhì)量和穩(wěn)定開發(fā)效率的重要保障，應(yīng)用服務(wù)開發(fā)如是，基礎(chǔ)設(shè)施因?yàn)閾?dān)負(fù)著更大的使命和責(zé)任更是如此。測(cè)試驅(qū)動(dòng)能幫助開發(fā)者更好的設(shè)計(jì)和實(shí)現(xiàn)。在 IaC 開發(fā)過(guò)程也同樣適用。在工具選型上，避免選擇編寫成本過(guò)高和太復(fù)雜的語(yǔ)言和工具，大部分 Ops 們更習(xí)慣編寫動(dòng)態(tài)語(yǔ)言的腳本，方便和順手更重要。

希望本文能對(duì)你的工程實(shí)踐帶來(lái)啟發(fā)，從下一個(gè) IaC feature 開始測(cè)試驅(qū)動(dòng)開發(fā)。