精益測試

你們的測試開發比是多少？測試全階段參與，怎麼可能忙的過來？全階段都在測，那麼都需要哪些測試才能保證質量呢？自動化測試覆蓋率要求達到 99%，包括功能、性能，甚至還有易用性……

前面的第一個和第二個問題經常被人問到，是大家比較關心的問題，而第三個是某項目的真實要求。分別是關於測試人員如何測試、測試活動如何開展、測試覆蓋率該是多少的問題，都跟接下來要講的精益測試有關。

精益生產

在介紹精益測試之前，我們先了解精益生產的概念。

從維基百科可以看到對於 “精益生產”的解釋：精益生產主要來源於豐田生產方式 (TPS) 的生產哲學，因此也稱爲豐田主義 (Toyotism)，一直到 1990 年間才稱爲精益生產。精益生產的目標是控制庫存量，減少生產過程中的浪費，其核心是“Just in time”，旨在需要的時候，按需要的量，生產所需的產品，也就是用最少工作，創造價值。

精益測試

敏捷測試要求的測試左移、全程測試，其目的也是爲了快速反饋、降低成本，以交付高質量的軟件。如果把精益的概念引入敏捷測試，將有助於減少測試過程中的浪費，讓測試價值最大化。什麼是精益測試測試要做到精益，需要明白：**不能一味的追求測試覆蓋率，大而全的測試覆蓋是一種浪費，有效的測試更有價值。**不管是手工測試還是自動化測試，都要先搞清楚業務價值和質量目標，根據業務風險來執行測試，對於優先級高的要重點測，而優先級低的可以減少測試覆蓋。根據 “二八原則”，80% 的業務優先級可能只在其中 20% 的功能模塊上，而其他 80% 的功能模塊只佔有 20% 的業務。如果一視同仁，追求全面覆蓋，花費大量精力在那 80% 的低優先級模塊上，必然造成大量的浪費。相反地，不追求測試覆蓋率，追求測試的有效性，將會事半功倍，帶來更高的 ROI。因此，很多時候，測試恰到好處很關鍵，帶着 bug 上線也許是個好的策略。注意，這裏的質量目標是關鍵，對於一些事關生命安危的軟件系統，質量要求會特別高，全面的測試覆蓋都是有效的，也是恰到好處的一種。這就是是精益測試的思想。因此，精益測試可以定義爲：**以業務價值爲目標，以儘量少的成本交付高質量的軟件，測試測在能體現價值的點上，做到有效覆蓋，減少浪費。**精益測試的精髓基於精益測試的定義，可以將精益測試的精髓總結爲 TAT：適時（Time）、適量（Amount）、精準（Target）。

**適時（T）**敏捷測試要求測試全程參與，讓測試活動發生在敏捷軟件開發生命週期的每個環節，而讓每種類型的測試發生在它最該發生的時刻，這就是 “適時” 的概念。比如：開發前對需求的確認，開發代碼提交前自動化測試的實現和驗證，部署後對系統做的冒煙測試等等。**適量（A）**對於測試覆蓋率，有人會認爲越高越好，比如前面提到的有團隊要求 99% 的自動化測試覆蓋，就算這些測試覆蓋都是有效的，但是花費太多精力去測試一些不是那麼重要或者不是那麼容易出問題的模塊，也可能得不償失，造成浪費。我們建議測試覆蓋，不管是手動還是自動化的，都是適量就好，根據風險來確定需要加強測試的業務優先級和響應的測試覆蓋量，一定不能一味的追求高覆蓋。需要權衡利弊，把時間花在真正有價值的事情上，這也是精益的體現。比如，做用戶故事驗收的時候，需要測到多細一直是個有爭議的問題。我覺得主要路徑的正常用例，加上一些需要特別關注的點就可以了，特別關注的點包括易出錯的異常路徑、IE 這樣的特殊瀏覽器、高風險的安全問題等。不能也不需要在故事驗收的時候覆蓋所有的邊角情況，畢竟需求、開發和測試三方湊一起不容易，時間要儘量短些纔好。當然，可能有的團隊還需要在故事驗收的時候驗收日誌、性能等，只要做到儘量高效，按照團隊需求來就好，並沒有千篇一律的答案。**精準（T）**精準測試通常是指根據代碼改動所影響到的範圍去針對性的進行自動化測試。而這裏說的精準測試範圍更廣，可以理解爲基於風險的測試，風險可能來自於業務和架構層面，也可能來自於代碼改動，還可能跟系統特點或其他項目因素相關。執行測試之前更重要的是分析和設計，不能盲目的去測。

精益測試的指導框架

精益測試的指導框架常見的有兩個：測試四象限和測試分層，下面分別介紹。測試四象限敏捷測試四象限最早由 Brian Marick 提出，Lisa Crispin 和 Janet Gregory 在書籍《敏捷軟件測試：測試人員與敏捷團隊的實踐指南》中引用這個四象限框架，並做了詳細的介紹。由於該象限框架所起到的作用不僅侷限於敏捷的環境，我在這裏稱之爲測試四象限。

測試四象限矩陣的左右兩側指的是測試的作用，分別爲支持團隊和評價產品，而上下兩部分指的是測試面向的對象，分別爲面向業務和麪向技術。支持團隊的測試左側支持團隊的測試是用來告訴團隊要寫什麼代碼，起到明確需求、輔助設計的作用。其中，第一象限是面向技術的支持團隊的測試，幫助構建產品的內部質量，也就是代碼質量的保障，比如單元測試和 API 測試等；第二象限則是面向業務的支持團隊的測試，從更高層次以業務專家可以理解的方式確定系統期望的行爲，幫助團隊澄清業務以更好的理解真正的業務價值。這兩個象限的測試能夠快速提供反饋信息，並確保快速的解決問題，既指導了功能的開發，又提供了防止重構和新代碼的引入而導致不期望行爲發生的安全網。評價產品的測試程序員編寫的代碼可以使得左側面向業務的測試通過，但也可能沒有產生客戶真正想要的東西，因此還需要第三、第四象限的評價產品的測試。第三象限是面向業務的評價產品的測試，通過模仿真實用戶使用應用的方式，幫助確認是否構建了真正需要的產品；第四象限是面向技術評價產品的測試，主要採用工具和相應的技術來評價產品的性能、健壯性和安全性等非功能特性，並且在開發週期的每一步都要考慮這些測試的開展。這兩個象限的測試中產生的信息應該反饋到象限矩陣的左側，並用於創建新的測試來驅動下一步開發，形成良性的增強環路。測試象限的使用象限的順序跟測試執行的順序無關，敏捷開發往往開始於客戶測試（面向業務的測試）。與測試執行時機相關的因素通常有： 

測試象限提供一種需要哪些測試來保障質量的思考框架，可以根據項目具體情況，結合考慮以開展對應的測試。上圖所示爲藍鯨項目的測試象限體現的測試類型，跟 Lisa 書裏介紹的就不太一樣，這是根據項目當前跟客戶的合作方式、業務需求、質量要求等來確定的當下需要執行的測試，比如其中的安全測試就分爲業務部分和技術部分。測試分層關於測試分層的思想，主要是針對自動化測試，根據測試所能覆蓋的範圍分成不同的層。下面借用 Martin Fowler 網站上微服務架構的幾種測試分層結構圖來解釋測試分層的概念：

從圖中可以看到幾種不同類型的測試所能覆蓋的範圍大小是不一樣的。關於測試分層的概念，大家可能更爲熟悉的是測試金字塔，測試金字塔呈現的是不同種類測試比例的多少，底層單元測試較多，越往上層測試比例越少，呈現爲金字塔結構。

其實，隨着技術架構、系統特點、質量要求、團隊技能水平等因素的不同，每種測試的比例也不盡相同，不一定都是金字塔結構，如下圖所示的蜂巢結構或者甜筒冰淇淋結構都有可能。

不管比例如何，每層測試有着自己的特點。越往底層的測試越接近代碼，編寫成本更低、執行速度更快、定位問題也更準確，但是離業務較遠，不能很好的體現業務價值；越往上層的測試越接近業務，更能反應業務價值，但有着不夠穩定、執行速度慢、實現成本較高、問題定位難的不足。因此，需要權衡利弊，根據項目具體情況，真實的目標來確定每層測試的比例。

小結

精益測試的思想主要是幫助團隊制定合適的測試策略，並不是一種具體的測試方法。精益測試的精髓是將測試做到適時、適量和精準，就是讓測試做到恰到好處以減少浪費。測試策略受衆多因素的影響，需要做到目標驅動，並且根據具體情況隨着時間推移不斷的演進。測試四象限和測試分層都只是指導框架，不是必須遵守的規範，可以作爲測試策略制定的參考模型，具體項目的策略還需根據項目特定情況進行調整。

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

猜你喜歡