測試策略的實現

《持續交付 發佈可靠軟件的系統方法》讀書筆記

很多項目只依靠手工的驗收測試來驗證軟件是否滿足它的功能需求和非功能需求。即使某些項目有一些自動化測試，但這些測試常常因無人維護或很少維護而過時，所以還是需要大量的手工測試作爲補充。

測試是跨職能部門的活動，是整個團隊的責任，應該從項目一開始就一直做測試，從一開始就將質量內嵌於產品之中。

質量內嵌是指從多個層次（單元、組件和驗收）上寫自動化測試，並將其作爲部署流水線的一部分來執行，即每次應用程序的代碼、配置或環境以及運行時所需軟件發生變化時，都要執行一次。手工測試也是質量內嵌的關鍵組成部分，如演示、可用性測試和探索性測試在整個項目過程中都應該持之以恆地做下去。質量內嵌還意味着，你要不斷地改進自動化測試策略。

測試策略的設計主要是識別和評估項目風險的優先級，以及決定採用哪些行動來緩解風險的一個過程。好的測試策略會帶來很多積極作用。測試會建立我們的信心，使我們相信軟件可按預期正常運行。也就是說，軟件的缺陷較少，技術支持所需的成本較低，客戶認可度較高。測試還爲開發流程提供了一種約束機制，鼓勵團隊採用一些好的開發實踐。

一個全面的自動化測試套件甚至可以提供最完整和最及時的應用軟件說明文檔，這個文檔不僅是說明系統應該如何運行的需求規範，還能證明這個軟件系統的確是按照需求來運行的。

測試的分類

業務導向且支持開發過程的測試

自動的 - 功能驗收測試

技術導向且支持開發過程的測試

自動的 - 單元測試、集成測試、系統測試

業務導向且評價項目的測試

手工的 - 演示、易用性測試、探索性測試

技術導向且評價項目的測試

自動的 / 手工的 - 非功能性驗收測試，包括容量測試、安全性測試等

現實中的情況與應對策略

新項目

新項目有機會實現所描述的理想國，最重要的事情就是一開始就要寫自動化驗收測試。爲了能做到這一點，你需要：

  1. 選擇技術平臺和測試工具；

  2. 建立一個簡單的自動化構建；

  3. 制定遵守 INVEST 原則 [即獨立的（Independent）、可協商的（Negotiable）、有價值的（Valuable）、可估計的（Estimable）、小的（Small）且可測試的（Testable）] 的用戶故事 [ddVMFH] 及考慮其驗收條件；

然後就可以嚴格遵守下面的流程：

  1. 客戶、分析師和測試人員定義驗收條件；

  2. 測試人員和開發人員一起基於驗收條件實現驗收測試的自動化；

  3. 開發人員編碼來滿足驗收條件；

  4. 只要有自動化測試失敗，無論是單元測試、組件測試還是驗收測試，開發人員都應該把它定爲高優先級並修復它。

遵守我們所說的流程，會改變開發人員寫代碼的方式。同後補驗收測試的項目相比，那些從一開始就使用了自動化驗收測試的代碼庫一般總是有更好的封裝、更清晰的表達、更清楚的職責分離和更多的代碼重用。這的確是一個良性循環：在正確的時機寫測試會產出更好的代碼。

項目進行中

引入自動化測試最好的方式是選擇應用程序中那些最常見、最重要且高價值的用例爲起點。這就需要與客戶溝通，以便清楚地識別真正的業務價值是什麼，然後使用測試來做迴歸，以防止功能被破壞。

遺留系統

在這種情況下，如果沒有自動化構建流程，那麼最高優先級的事兒就是創建一個，然後再創建更多的自動化功能測試來豐富它。如果有文檔，或能夠找到那些曾經或正工作在這個系統之上的成員的話，創建自動化測試套件會更容易一些。然而現實往往並非如此。

項目的出資人（sponsor）並不願意讓開發團隊把時間花費在一些看上去低價值的活動上，比如爲已經在生產環境中使用的功能創建測試。他們會問：“這些功能不是已經在之前被 QA 團隊驗證過了嗎？” 因此，一定要聚焦於系統中高價值的功能。向客戶解釋一下，創建迴歸測試套件的價值在於保護系統當前的功能，這樣就很容易啦。

坐下來與用戶一起識別系統中高價值的功能是非常重要的。利用前面一節所說的技術，創建一套廣泛的自動化測試，覆蓋這些高價值的核心功能。當然，我們不該在這上面花太長時間，因爲這只是一個保護已有功能的框架。有了這個測試套件之後，就要逐漸爲新增功能添加相應的測試。對於遺留系統來說，這些覆蓋核心功能的測試就是非常重要的冒煙測試了。

集成測試

假如你的應用程序需要通過一系列不同的協議與各種外部系統進行交互，或者它由很多鬆散耦合的模塊組成，而模塊之間還有很複雜的交互操作的話，集成測試就非常重要了。

我們所說的 “集成測試” 是指那些確保系統的每個獨立部分都能夠正確作用於其依賴的那些服務的測試。

我們要確保在正式部署到生產環境之前，應用程序不要與真實的外部系統進行交互，否則就要想辦法告訴外部系統，這個應用程序所發送的數據只是用於測試的。一般來說，有兩種常見的方法來保證你可以安全地測試自己開發的應用程序，而不必與真正的外部系統進行交互，而且通常要同時使用這兩種方法。

  1. 在測試環境中使用一個 “防火牆” 將該應用程序與外部系統隔離開來，而在開 發過程中，越早這麼做越好。當外部系統不可用時，這也是測試應用程序行爲 的一個好方法。

  2. 在應用程序中使用一組配置信息，讓其與外部系統的模擬版本進行交互。

流程

在每個迭代開始時，召集所有的項目干係人開個會。假如沒有做迭代式開發，那麼就在某個用戶故事開始開發的前一週召開這樣的會議。讓客戶、分析人員、測試人員坐在一起，找到最高優先級的測試場景。

測試人員和開發人員在開發前應該儘早一起討論這些驗收測試。這會讓開發人員更好地瞭解用戶故事，並理解最重要的場景是什麼樣的。與開發完用戶故事之後再溝通相比，這會大大減少開發人員和測試人員之間的反饋循環，有助於減小遺漏功能的幾率，並有助於減少缺陷。

管理待修復缺陷列表

理想情況下，你的應用程序根本不應該有缺陷。如果使用測試驅動開發和持續集成，並有一個全面的自動化測試集，其中包括系統級別的驗收測試，以及單元測試和組件測試，在測試人員和用戶發現缺陷之前，開發人員就應該能夠捕獲它們。然而探索性測試、演示以及用戶使用的過程中，都可能會發現應用程序的缺陷，這也許是不可避免的。這些缺陷都會放在待修復缺陷列表（backlog）中。

我們可以把缺陷分爲嚴重（critical）、阻塞（blocker）、中（medium）和低（low）四個級別。根據這種分類方式，就能在待修復缺陷列表中根據優先級將缺陷與用戶故事按相同方式來排序，並可將二者一起放置。

小結

在很多項目中，測試被認爲是一個由一些專職人員負責的獨立階段。可是，只有當測試成爲與軟件交付相關的每個人的責任，並從項目一開始就被引入並持續進行時，才能產生高質量的軟件。測試主要是建立反饋環，而這個反饋環會驅動開發、設計和發佈等活動。將測試推遲到項目後期的計劃最終都會失敗，因爲它破壞了產生高質量、高生產率，以及（最重要的）反映項目進展情況的反饋環。

如果每次修改後都能運行一次自動化測試集合，就能建立最短的反饋環。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/GZ-sLRlQNgXUFk6ZK1flfg

猜你喜歡