[技術思考] 軟件可測性分析和實踐

軟件測試中可測性通常是指對系統的可控性、可觀測性進行的評估，藉以反映系統設計、實現對測試的友好程度和相應的測試成本。可測性在測試階段會對系統的測試成本及關聯產品代碼的Patch次數產生重大影響。如何提升可測性成爲軟件生命週期特別是前期（設計階段、coding階段）重要的一環。 本文帶領你們探索在實際項目中可測性相關的實戰經驗和對應的改進措施。

1 提升可測性的切入點

可測性的評估和改進最先開始於兩個階段：

a. 新項目的設計階段；

b. 已有項目新功能、新策略的提測階段。

這些是提升團隊設計的系統可測性和維持系統的設計高可測性的關鍵時間點。測試人員會利用各類場合、機會強化開發人員對於可測性的重視：

1. 可測性的重要性每次設計討論會， 測試負責人必提醒你們在設計時注意可測性。不然設計出來的功能極可能須要進行重構。
2. 可控性

   每次晨會中的討論環節， 測試負責人會提醒模塊設計人員，設計的功能須要必要的外部控制、執行動做支持，不然QA沒法精確控制過程及縮短測試耗時。

3. 可觀測性每一個功能進行測試設計階段，提早和開發人員溝通必要的功能，觀察結果集合能夠系統外部得到，錯誤結果能夠被暴露而不是由內部邏輯徹底消化。

那可控性和可觀測性又指哪些方面呢？ 如何向開發人員合理的解釋可測性？

1.1 可控性

可控性指系統的狀態可受外部控制改變，而不是由內部模塊自發的完成。

舉個常見的例子：

A. 當某文件存在的時候，該模塊自動退出；

B. 當某pid.lock文件存在時，該模塊不能啓動，即便啓動也退出。

上面的狀態改變都是由一個外部的文件控制，擁有可控性。

說到這裏，問題來了，擁有可控性就萬事大吉了嗎？ 請你們思考，你在實際項目過程當中遇到過哪些有可控性但可控性較差的狀況？

1.2 可觀測性

可觀測性指系統內的重要狀態、信息可經過必定手段由外部得到。可觀測性不只能觀測系統的輸出是否符合設計要求，還影響該系統是否可控。系統的必要狀態信息在系統測試控制階段起決定做用。沒有準確的狀態信息，測試人員沒法判斷是否要進行下一步的控制變動。沒法控制狀態變動，可控性又從何談起？

口說無憑，咱們來看幾個做者實際項目中遇到的真實案例。

2 實戰分析

[1] 垃圾回收GC

垃圾回收GC模塊是常見的系統內模塊，相信不少測試人員遇到過下面場景或者相似場景：

開發人員終於在大吼一聲後宣佈垃圾回收模塊完成，她的描述以下：

1) 該模塊定時自動觸發。觸發條件是天天晚上1點。

2) 該模塊觸發後每秒的處理量是N/s。是根據線上狀況獲得的經驗值，硬編碼到代碼中。

而後，就沒有而後了。

測試人員一陣迷茫，這就是所有的詢問換來的基本上是「它都是全自動的了，你還想要什麼的」表情。

所以這個新功能完成後的二次返工是必然的了。

首先，該模塊的可控性太差。測試環境不能夠等待天天晚上1點這個時刻，必須有外部能影響這個」全自動「的手段提供。不然全量的系統測試用例迴歸會被限定在固定測試時間點且沒法調整和更改。

其次，該模塊的每秒處理量必須能更改到符合測試環境。測試環境基本上都是真實環境的放縮，特別是分佈式系統等大規模應用。測試環境機器不管是數量仍是類型都遠低於實際環境。這種條件下，參數的定量調整是必需要完成的輔助支持。

再次，沒有必要的描述如何判斷哪些文件/數據被GC掉了。沒法觀測到執行結果集帶來的後果是沒法精確的預期測試結果。

而相應的改進措施就是解決上面提到的問題。

[2] 系統內部狀態信息

爲了保證存儲的數據高可用，分佈式系統會採起多機存儲副本方法。即一個數據被N（>=2）個機器以必定的算法存儲相同的數據副本。這個時候常常會遇到的問題：

a) 機器間的數據因爲數據複製順序的不一樣，會有數據差別。a、b、c三臺機器，a、b機器可能已完成一次數據的更新到最新數據版本data1，c還處於老版本data0.

b) 因爲版本差別，內部必須維護副本revision的版本號以進行數據同步和異常處理。

這種狀況， 好的設計原則上要保證多機副本的必要狀態信息被外部獲取。

A. 數據的副本分佈信息、副本的revision版本號等須要提供接口得到

B.因爲機器宕機形成的副本分佈變化要可以及時反映和更新。（好比帶必定間隔週期的更新）

只有在這種必要信息被獲取的狀況下，測試人員才能更好的掌握系統狀態並根據系統狀態進行清晰的測試結果預期。

[3] 參數的熱設定

參數的熱設定是常常碰到的問題。一個系統越複雜、可定製，它可設定的參數就越多。一個好的設計應該能熱設定其中的參數，而後執行從新加載動做。

舉個實際的例子， 下面的配置文件是一個系統的存儲節點配置文件截圖。該截圖僅展現了大約1/5的配置參數。

a. 若是參數不可從新熱加載，那麼測試用例執行過程當中都必須進行進程的重啓。

進程的重啓勢必形成單個測試用例的時間拉長，複雜系統成百+的測試用例會形成整體測試時間的拉長。每一個多消耗1-2分鐘，總體就是小時級別的時間消耗。這對Slow build或完整性測試集執行來講是個災難。可測性也比較差。

b. 參數不可熱加載會在系統運維期間失去熱調整參數的機會，可能致使系統的間斷性停服務。這對基礎服務來講是個噩夢，上層依賴於基礎服務的應用可能成百上千，停服的代價過於大。一些gdb強行attach進程進行等修改變量的臨時方法因爲進程狀態的不肯定性因素會帶來不小的風險。做者負責的項目曾出現gdb熱修改帶來集羣主控節點宕機停集羣的慘痛經歷。

參數的熱設定和加載雖然增長了必定的邏輯複雜度，但對比帶來的收益是值得付出並實踐的。

[4] 系統使用信息統計

系統使用信息的統計在以下方面特別重要:

1) 產品線運營數據，爲產品運營、後續產品改進等環節提供一手資料

2) 運用系統、集羣狀態信息監控以解決運維過程當中發生的問題

3) 利用系統狀態信息進行內部運行狀態斷定，以測試是否達預期

1和2雖然不直接涉及可測性，但測試人員在系統設計階段須要進行這方面的考慮以防止系統開發後期進行的功能性重構帶來測試總體架構重構。系統接近尾聲進行的功能性重構對測試人員來講是個很是頭疼的問題。測試用例依賴的統計信息等接口可能被大量使用，這類的更改帶來不小的用例調整、更正工做。

測試人員在信息統計的設計階段須要瞭解系統在現有的設計基礎上可能衍生的二期、三期甚至更後期的功能，以提早影響當前的功能設計，提升數據、接口、操做方面的可擴展性。爲之後可能產生的新功能打好可測性基礎。少埋坑、多考慮場景適應性。

上面的場景是做者在實際測試項目中常常遇到的，所以抽取出來作個示例。實際的項目測試遇到的場景遠比這些複雜、多樣且不可預知。這個時候須要你們多思考場景，多根據已有的經驗進行防護性準備。

那有沒有通用的提供可測性的方法呢？

3 提升可測性的通用方法

1. 摒棄原有的開發人員只進行單純的代碼單元測試的觀念，讓開發人員也進行系統級測試。做者在實踐過程當中最推崇的方法就是此條。具體地說，開發人員進行的是系統級測試，禁止刷行覆蓋率型的單純函數覆蓋UT。由系統級接口或者功能來驅動整個測試過程。沒法直接進行驅動的測試行爲須要撰寫模擬器或者模擬模塊進行。這樣開發人員會切身的感覺到可控性和可觀測性的重要性。進而推進系統在這兩個方面的實現更易用和便於測試。由此而來的良性循環能讓系統總體可測性始終處於較好水平。
2. 測試人員深度瞭解被測系統，可以在可測性出現問題的時候及時指出問題所在。只有深度瞭解被測系統，詳細分析系統實現邏輯和代碼，作到可黑盒、可白盒測試的程度，才能提早預測可測性薄弱環節，提早預防這樣的事情發生。在可測性出現問題時，及時介入和提出建設性意見。在須要進行測試代碼植入以方便測試流暢進行等方面親自動手，協助開發人員解決問題。

可測性問題可能出如今系統的各個方面，但只要在系統生命週期的各個環節嚴格要求並輔以正確的方法，可測性問題就不會成爲軟件測試中不可攻破的難關。各位朋友，你遇到過哪樣的可測性難題呢？若是讓你從設計階段就貫徹好的可測性要求並在整個流程中嚴格遵照，可否解決你的難題呢？

歡迎你們關注公號, 一塊兒在技術領域互動和討論.