軟件測試手段的多樣化

　　本文為分享會而準備，保持一年一次的傳統，照例開篇公告諸位：下面會有大量個人思想，不喜勿看。

　　國標：

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

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

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

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

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

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

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

　　測試范圍：

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

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

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

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

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

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

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

　　系統設計測試：

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

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

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

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

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

原文轉自：http://www.uml.org.cn/Test/201201042.asp