? ? ?為了保證后續(xù)在功能設計階段可以提高產品整體的可測試性举瑰，已達到更好的提升產品的易用性类腮、可維護性以及可測試性等方面的后期效率和降低成本的目標鉴裹，故針對產品的可測試性方面進行一些常規(guī)化的梳理卿吐，同時針對一些項目中常見的可測試性方面的案例進行了對應的分析把夸，便于大家在實踐中能夠更好的實踐和提高在可測試性方面的意識而线。
可測試性的定義
軟件測試中的可測性一般是指對系統(tǒng)的可控性、可觀測性進行的評估恋日，借以反映系統(tǒng)設計、實現(xiàn)對測試的友好程度和相應的測試成本嘹狞。
可測性在測試階段會對系統(tǒng)的測試成本及后期產品使用過程中的易用性岂膳、維護成本等會產生重大影響。如何提高可測性成為軟件生命周期特別是前期（設計階段磅网、coding階段）重要的一環(huán)谈截。
可測試性的常用指標
可測試性的最佳切入時間
? ? 新項目的設計階段；
? ? 已有項目新功能涧偷、新策略的提測階段簸喂。
可測試性的常用分析維度
一般來說，我們可以從以下幾個方面來評價軟件的整體可測試性：
? ?可觀測性
? ?可控制性
? ?可追蹤性
? ?可理解性
各部分指標的具體分析
可觀察（能否容易的觀察程序的行為燎潮、輸入和輸出）
任何一項操作或輸入都應該有預期的喻鳄、明確的響應或輸出，不管是正確的還是錯誤的甚至是異常的确封，這樣軟件才是可測的除呵；
當前、過去的系統(tǒng)狀態(tài)和變量應可見或可查詢爪喘，“可見”是指運行時可見颜曾、維護時可見或者調試時可見，“不可見”就“不可發(fā)現(xiàn)”秉剑，可測試性就低泛豪；
所有影響輸出的因素可見；
可自動檢測、報告內部錯誤诡曙；
錯誤輸出易于識別吕粹，無論通過日志自動分析還是界面高亮顯示的方式，要能有助于發(fā)現(xiàn)岗仑；
增加輸出參數(shù)匹耕、減少變量重用，包括打印內部信息荠雕、將局部變量作為輸出稳其、增加斷言、增加局部變量等炸卑。
可控制（能否容易的控制程序的行為既鞠、輸入和輸出）
提供適當?shù)氖侄危谕饨缰苯踊蜷g接的控制系統(tǒng)的狀態(tài)及變量盖文，例如對于某些全局類型的變量嘱蛋、特殊結構等，可以進行分類并封裝到接口中五续；
采用模塊化設計洒敏，各模塊支持獨立測試，對于每個相對獨立的模塊設計專用的測試驅動和測試樁疙驾，模塊異常時不影響其他模塊的測試（控制測試范圍凶伙，就能更快地分解、定位問題）它碎；
業(yè)務流程和場景易于分解函荣，可以針對單獨業(yè)務流程進行測試；
提供對外接口扳肛，便于構造測試環(huán)境模擬外部系統(tǒng)傻挂；（如單獨針對測試的一些配置/開關等）
定時觸發(fā)、固定大小/空間觸發(fā)等
提供適當?shù)氖侄瓮谙ⅲ梢源蜷_或關閉調試輸出或打印函數(shù)金拒。
測試人員、維護人員能夠控制程序的流程旋讹、場景殖蚕、輸入和輸出，才能有針對性的執(zhí)行各種用例或實驗沉迹。通過接口開放流程控制睦疫、參數(shù)讀寫功能，也是支持實現(xiàn)自動化測試的基礎鞭呕。
可追蹤（能否容易的跟蹤程序的操作蛤育、狀態(tài)、性能、錯誤瓦糕、GUI事件以及通信情況）
跟蹤記錄關鍵函數(shù)的持續(xù)時間底洗、外部庫調用；
跟蹤記錄關鍵流程的函數(shù)執(zhí)行過程咕娄、輸入輸出參數(shù)亥揖；
嚴格遵從日志規(guī)范，正確設置日志級別圣勒，輸出日志格式標準統(tǒng)一的费变，便于自動查詢和分析；
定義日志類別圣贸，區(qū)分安全類挚歧、業(yè)務類、性能類日志吁峻，便于問題分析滑负；
約定不同類別、不同級別日志的作用及意義用含；
日志文件至少保存 15 天矮慕，以便對以“周”為頻次發(fā)生的異常分析。
追蹤的目的是可見耕餐。日志是一種維護性可見的方式凡傅；運行時以及調試時可見，可以通過專門的追蹤回顯代碼或者各種追蹤工具軟件實現(xiàn)肠缔，這兒就不詳細說了。
可理解（是否提供了足夠的信息哼转，易于獲取明未、易于理解、易于使用）
遵循行業(yè)的標準及規(guī)范壹蔓；
提供用戶文檔（使用手冊等）趟妥、工程師文檔（設計文檔等）、程序資源（軟件源代碼等）以及質量信息（測試報告等）佣蓉；
文檔披摄、接口、流程勇凭、代碼疚膊、注釋、提示信息易于理解虾标。
待測模塊是否可以/易于自動化測試
針對自動化測試關鍵環(huán)節(jié)的一些接口寓盗、權限設計等
具體的可測試性典型案例
可控制性
案例1（文件控制）
當某文件存在的時候，該模塊自動退出；
當某pid.lock文件存在時傀蚌，該模塊不能啟動基显，即使啟動也退出。
上面的狀態(tài)改變都是由一個外部的文件控制善炫，擁有可控性撩幽。
案例2（參數(shù)/配置控制）
nvs云主機的單節(jié)點的disable特性，可通過配置disable的屬性控制節(jié)點是否外部可見/可用
上面的狀態(tài)由配置/參數(shù)控制箩艺，擁有可控性
案例3：nlb網關
nlb的網關部分窜醉，目前不具有disable的特性，故該部分網關新增時舅桩，實際上有一定的風險酱虎，如果該網關有問題的話，可能業(yè)務就會直接受損了
上面的狀態(tài)擂涛，由于nlb網關沒有針對節(jié)點外部使用的可控性读串，導致無法控制新增節(jié)點階段的網關從上線到驗證ok階段的外部使用控制，所以缺少從部分來看撒妈，不具有可控性
可觀測性
案例1
老云neutron實現(xiàn)中句惯，svlan的擴容網段功能克婶，因創(chuàng)建ip部分無法指定具體的vlan網段，故新增的網段從測試層面，是無法保證新建的ip會創(chuàng)建在新增的網段中的捧挺，所以該部分從可測試性角度來說，是有一定的不足的（目前通過bridge檢查以及dhcp namespace層面的互通性檢查等方式來完成覆蓋）
案例2
zk與數(shù)據(jù)庫之間的數(shù)據(jù)一致性岛抄，前期該部分沒有單獨的接口進行檢測判斷數(shù)據(jù)庫和zk中的數(shù)據(jù)是否一致璃诀，所以對測試和運維來說，進行某次操作以后谷暮，就很難觀測到對應的一致性情況是否完好蒿往，在目前提供了該部分的接口以后，該部分的可觀測性就有了很好的保障
案例3
為了保證存儲的數(shù)據(jù)高可用湿弦，分布式系統(tǒng)會采取多機存儲副本方法瓤漏。即一個數(shù)據(jù)被N（>=2）個機器以一定的算法存儲相同的數(shù)據(jù)副本。這個時候經常會遇到的問題：
機器間的數(shù)據(jù)由于數(shù)據(jù)復制順序的不同颊埃，會有數(shù)據(jù)差異蔬充。a、b班利、c三臺機器饥漫，a、b機器可能已完成一次數(shù)據(jù)的更新到最新數(shù)據(jù)版本data1肥败，c還處于老版本data0.
由于版本差異趾浅，內部必須維護副本revision的版本號以進行數(shù)據(jù)同步和異常處理愕提。
這種情況， 好的設計原則上要保證多機副本的必要狀態(tài)信息被外部獲取皿哨。
數(shù)據(jù)的副本分布信息浅侨、副本的revision版本號等需要提供接口獲得
由于機器宕機造成的副本分布變化要能夠及時反映和更新。（比如帶一定間隔周期的更新）
只有在這種必要信息被獲取的情況下证膨，測試人員才能更好的掌握系統(tǒng)狀態(tài)并根據(jù)系統(tǒng)狀態(tài)進行清晰的測試結果預期如输。
