多樣化的軟件測試實施方法

　　國標：

　　這東東真不想講，涵蓋的內容非常多，這里摘錄幾個主要質量特性，有興趣的可自行查閱資料。

　　功能性：與一組功能及其指定的性質有關的一組屬性。

　　可靠性：與在規定的一段時間和條件下，軟件維持其性能水平的能力有關的一組屬性。

　　易用性：與一組規定或潛在的用戶為使用軟件所需作的努力和對這樣的使用所作的評價有關的一組屬性。

　　效率：與在規定的條件下，軟件的性能水平與所使用資源量之間關系有關的一組屬性。

　　維護性：與進行指定的修改所需的努力有關的一組屬性。

　　可移植性：與軟件可從某一環境轉移到另一環境的能力有關的一組屬性。

　　測試范圍：

　　測試范圍的確定過程其實就是測試需求分析的過程，如何進行分析呢?

　　如果是新系統，列舉所需實現的功能，從每一功能的起點(入口)出發，需要經過多少步操作多少交互才能達到功能終點(數據提交，數據展現……)。在此過程中每步操作每次交互均可看成一個節點，我們并不關心節點與節點之間的上下文關系(那是場景法要考慮的)，我們關注的是需要經過多少節點多少條路徑才能從起點到達終點。這些節點、路徑就是我們的測試范圍，也就是我們的測試需求。

　　如果是老系統改造，列舉出所有的改造點，注意，是改造點不是影響點。從改造點的源頭出發，需要經過多少節點、路徑才能達到改進目標。這些節點、路徑就包含影響點。但是，如果改造點無法準確評估怎么辦?對系統進行優化，開發都不知道要改多少處代碼怎么辦?常規解決方式有以下三種：

　　業務關系分析：通過產品業務分析大概會有多少功能需要修改。這種方式需要對同類型業務進行長期維護。優點是對于大多數測試工程師而言效率比較高，缺點是范圍不夠精準。

　　代碼依賴分析：通過代碼間的依賴關系分析有多少關聯代碼需要修改。這種方式精度有所提高，但效率大大降低，特別是在對產品代碼不熟悉的情況下實施起來會很吃力。

　　代碼靜態掃描：通過代碼掃描查找類似代碼片段以確定修改點。這種方式誤差比較大精度不會太高，同時效率也一般，仍然需要不少人工分析工作。

　　以上方式均是治標不治本。那治本的是什么?代碼重構。說白了這是軟件維護性差的問題，注意，維護性由四個子特性組成，其中就包含可測性。那么我們要做的是在系統設計、代碼實現階段，對產品的維護性進行全面評估。具體如何評估本文不做詳細論述，后續有專門文章進行介紹，下文會有少量涉及。

　　系統設計測試：

　　一句話，測試設計的過程就是對系統設計進行測試的過程。

　　好吧，就說一句估計會被扁。

　　記得在2009年，部門做了次測試方法大PK，過程轟轟烈烈，結果嘛，怪可惜的。PK過程中對測試設計如何做有很多爭論，但核心思路高度一致，進行UML建模。通過建模梳理測試思路，通過圖形明確待測產品的測試流程，此過程中我們的待測產品有哪些?需求、UC，還有就是系統設計(更多指的概設)。當然，與開發人員不同的地方是，在建模過程中，開發更多考慮的是如何實現，測試更多考慮的是此實現是否合理，并會思考具體用何種測試手段去支撐測試思路，同時對可測性會進行評估。另外補充一點，測試用例設計也是測試設計的一部分，不要分開。至于測試人員針對待測產品如何進行建模本文不做論述，大家可自行查閱資料。

　　測試有個經典概念：V&V，驗證與確認，驗證產品已實現的功能是否正確，確認產品是否正確實現了功能。其中驗證過程主要集中在產品實現后，確認則貫穿全程，尤其是在產品建設前期，確認過程顯得尤為重要。在確認過程中要針對產品各項質量特性進行全面評估，例如針對軟件維護性，可通過質量檢查表(比方說編碼規范)對待測產品進行評分，還可以通過“90-10測試”來衡量。具體方式有很多，本文不具體描述了，后續會有專門文章進行系統介紹。

　　看到這里也許有很多人會說，“我一直就是這么做的啊，原來我一直有對系統設計進行測試”。沒錯，你一直都在做，可惜你一直都不知道，知道自己為啥不知道嗎?

　　可測性：

　　軟件維護性由四個子特性組成：易分析性、易改動性、穩定性、易測試性。

　　軟件可測試性通常是指軟件發現故障并隔離、定位其故障的能力特性，以及在一定的時間和成本前提下，進行測試設計、測試執行的能力。這里摘錄下《軟件可測試性需求設計》一文中的幾個重點評估指標，詳細信息大家可查看全文：

　　可控制性設計需求

　　可分解性設計需求

　　穩定性設計需求

　　易理解性設計需求

　　可觀察性設計需求

　　測試驅動和樁的設置

　　適合增量式開發的可測性設計

　　可查詢設計

　　自愈合功能

　　輸出結果

　　提供統一的操作執行面板

　　每一條都有具體的評估標準，衡量待測產品可測性的優劣可以據此參考，我就不添油加醋了。另外我推薦一款google的開源代碼可測性度量工具“Testability explorer”，有興趣的同學可以試用下。

　　全過程測試：

　　產品研發過程前期，靜態測試采用的越多，這是和待測產品的特性有關。大家都知道測試越提前，產品質量風險就越小，各項成本就越少。但要真正落實測試提前必須有個大前提，就是測試工程師個人能力的不斷提升。不具備相應的測試能力，有再好的測試方法測試手段也沒用。

　　一個測試團隊的成長，一定是從發現缺陷到缺陷預防，真正能做到缺陷預防的團隊才是成熟的團隊。上文所說的大多仍是發現缺陷，如何做缺陷預防本文不探討，但只有測試提前，只有真正做到了全過程測試，才有看到缺陷預防成功的那一天。

　　測試手段多樣化并不僅僅是多幾個測試工具，更主要的是豐富測試思路。不同業務背景、技術背景的產品我們首先要能清楚應該如何下手，然后再看需要何種技術手段支撐。先有測試思路，然后尋求技術支持。而不是先搞個技術，然后再硬生生的嵌入現有的測試過程中。當然，技術儲備是持續要做的。

原文轉自：http://www.anti-gravitydesign.com