靜態測試

靜態測試概述

靜態檢查好比審查(reviews)和基於工具的代碼和文檔分析能夠很好的改進質量。靜態測試沒有測試數據和測試執行。目的是發現缺陷和與規格說明書、相關標準及項目計劃的誤差，並能夠優化開發流程。側重於缺陷預防。

評審的對象爲書面能夠看到的內容，涉及合同、需求、設計規格、程序代碼、測試計劃、測試用例、測試報告、手冊等等。一般須要須要各部門人員通力合做來完成。

評審系統地使用人的分析和思考能力來檢查和評估問題。

審查是軟件開發重要環節之一，也是測試活動之一，即靜態測試——評審。藉助審查保證用戶需求在市場/產品需求文檔及其相關文檔中獲得準確、完整、無歧義的反映，並使各種開發人員在需求理解上達成一致。

軟件評審是對軟件元素或者項目狀態的一種評估手段，以肯定其是否與計劃的結果保持一致，並使其獲得改進。一般須要仔細閱讀來理解和檢查。相關標準參見IEEE 1028。

評審能減小缺陷、下降後期開發測試等成本，加強更多人員對產品和質量責任感的好處。據統計評審能夠發現多達70%的缺陷，減小14–25%的研發時間。

評審須要有明確的目的、選擇合適的評選者。

部分結構良好的文檔，好比UML文檔，可用先用工具發現一部分問題。

標準評審流程

標準的評審流程有計劃，kick-off, 我的準備，評審會議、修正以及跟蹤組成。

計劃階段管理層須要肯定哪些須要評審；評審須要什麼技術；參與評審的人員；並和項目計劃聯繫在一塊兒。複雜的評審還須要創建進入和退出標準。評審未必會覆蓋因此文檔，因此還須要考慮不評審的風險。

kick-off：主要會議評審作材料和人員準備及培訓等。並制定評審檢查表。複雜的評審須要檢查進入標準。

我的準備：參評者須要精讀相關材料並準備好缺陷、問題和評論。

修正： 管理層對問題進行分析，確認哪些目前須要修改。

跟蹤： 修改較大的狀況下，須要第2次會議評審，通常只評審修改的部分。改動小的狀況下可不開會離線評審。評審會議及其結果須要評估，以方便後期改進評審流程。檢查表等也要適時調整。複雜的文檔還須要檢查退出準則。

評審會議： 一般由項目部主持，能夠由其餘懂得外交策略者代理。主持人全部專家能及時到場，確認評審會議的結果是接受或者須要改進甚至重寫。

• 輸出：小結報告（包含評審對象、與會者及角色、發現的問題簡介、結論；發現的問題列表。

• 評審的規則：

• 評審會議一般不建議超過2個小時，並保證每間隔50分鐘能休息10分鐘，以保持你們的頭腦清醒，提升效率。

• 與會者不能到場或者評審人員準備不充分，主持人能夠取消或者中止評審。

• 評審的是文檔等材料，而不是做者。與會人員儘可能保持公正，對事不對人。評審者要注意表達方式，儘可能避免衝突。做者不要竭力維護本身或者文檔（可是能夠解釋）。

• 主持人不能參與具體評審。

• 不得討論風格（手冊以外的）等與主題無關的問題。

• 評審團隊不討論解決方案，這些會下整理好再另找時間討論。

• 每一個評審者有機會充分展現本身及相關問題。

• 與會者達成的協議必須一致。

• 問題儘可能不能對做者的命令形式體現，儘可能以建議的方式展現。

• 分區域進行評審並有分級：Critical，Major，Minor，Good。

• 評審結論：Accept (不須要修改), Accept (須要修改，可是不須要評審)，Do not accept（須要從新評審）

• 評審者簽名。

修正： 管理層對問題進行分析，確認哪些目前須要修改。

跟蹤： 修改較大的狀況下，須要第2次會議評審，通常只評審修改的部分。改動小的狀況下可不開會離線評審。 評審會議及其結果須要評估，以方便後期改進評審流程。檢查表等也要適時調整。複雜的文檔還須要檢查退出準則。

評審會議角色和責任

管理者：選擇評審的對象及相關資源和人員，一般是技術總監組成。管理者通常不建議參加具體評審，以避免評審不能自由發揮，再者，管理者可能由於時間等緣由不真正瞭解技術細節。

主持人：執行評審，全流程跟蹤，併發出評審報告。注意要保持中立。

做者：若是做者有多個，須要一個統籌負責。做者要明白評審是爲了提升產品質量。

評審者：從不一樣角度(好比開發、測試、架構、產品、運維等）評審對象，儘可能控制在5人之內。不一樣的評審者可有不一樣的分工。標準評審中，評審者須要在會前發送本身發現的問題和建議給主持人。

記錄員：記錄問題（難題、action、決定、建議等）。一般由做者兼任。

評審方法

審查：是最標準的評審流程。後面會有詳細描述。其餘評審都是它的精簡。適用於主要的需求，設計和測試文檔等。

結對評審：一般用戶開發互相評審代碼。能夠沒有會議，可是要深刻到文檔的每一行。

走查：通常用於不是特別重要的文檔，做者主持會議，講述主要流程，好比代碼走讀。能夠共同窗習提升。主持人須要抓住重點，深刻關鍵點。

輪查：相似於走查，可是隻抽查部分流程。

非正式評審：能夠沒有會議的評審，一般用於部門內部，好比測試用例的組內評審。可是要有評審的紀要。

評審的技術

檢查表、場景分析、頭腦風暴和工具等

檢查表（checklist）是一種經常使用的的質量保證手段，也是正式技術評審的必要工具，評審過程每每由檢查表驅動。一份精心設計的檢查表，對於提升評審效率、改進評審質量具備很大幫助。

• 可靠性。人們藉助檢查表以確認被檢查對象的全部質量特徵均獲得知足，避免遺漏任何項目

• 效率。檢查表概括了全部檢查要點，比起冗長的文檔，使用檢查表具備更高的工做效率。

需求分類

需求分爲功能性需求和非功能性需求，功能性的需求相對容易肯定，非功能性的需求難以肯定。

• 必須清楚需求

• 明確需求的優先級

• 需求分解得越細，對測試用例的設計質量越有幫助

• 需求仍是衡量測試覆蓋率的重要依據

• 需求是規劃具體項目資源和時間的基礎。

功能性需求主要是根據產品規格說明書來檢驗被測試的系統是否知足軟件各方面的功能的使用要求，包括用戶界面的友好性。

• 程序安裝、啓動正常，有相應的提示框、錯誤提示

• 各項功能符合設計要求，正常運行並輸出正確結果

• 功能邏輯合理，並能處理各類異常操做

• 能接受正確的數據輸入，輸出結果準確，格式清晰

• 系統的各類狀態按照業務流程而變化並保持穩定

• 支持各類應用環境，能配合硬件設備

用戶界面是和用戶進行交互的窗口，其友好程度直接影響用戶對於軟件產品或軟件服務的滿意度。良好的用戶體驗，簡單、方便和明瞭，讓用戶舒暢、愉悅

• 通用框架、浮動窗口和文字等總體佈局合理

• 文字顯示正常，且內容格式正確、美觀。

• 色彩協調，風格先後一致，

• 文字標記和超連接能夠打開和跳轉成功

KISS – Keep it simple, stupid, Don’t make me think

• 非功能性質量需求，包括系統性能、安全性、兼容性、擴充性，其測試需求會因不一樣的項目類型差別較大。

• 客戶端軟件，如字處理軟件、媒體播放軟件等佔用較少資源，在容錯性、兼容性等方面要求高。

• Web應用系統對性能、安全性等有很高要求

• 客戶端/服務器應用系統。

• 大型複雜企業級系統。

SaaS (Software as a Service)是軟件服務模式，廠商將應用軟件統一部署在本身的服務器上，客戶能夠根據本身實際需求定購所需的應用軟件服務。主要分爲On-Demand Service和On-Premise Service。

• 軟件運行的服務質量（QoS, Quality of service）

• QoS要求是指定某些系統特性的技術規範。

SaaS的非功能性需求：

• 性能要求，系統響應能力。

• 可用性, 7x24 不間斷服務

• 可伸縮性，系統容量擴充能力，使系統能夠支持來自擴大用戶羣體的額外負載。

• 安全性要求，肯定可能潛在的安全威脅並找處處理策略。

• 可維護性要求，對部署系統進行維護的難易程度，可維護性與可用性之間關係密切

正確理解需求的過程

見ppt上面的圖

需求評審重要性

• 發現需求定義中的問題，儘早發現缺陷，下降劣質成本。

• 保證軟件需求的可測試性。

• 與市場、產品、開發等相關人員在需求理解上認識一致，以避免後期的爭吵。

• 更好的理解產品的功能性與非功能性需求，爲制定測試計劃打下基礎。

• 肯定測試目標與範圍。雖然此後需求會發生變動，但能獲得有效控制，下降測試風險。

需求評審重要性

• 正確性

• 完備性

• 易理解性

• 一致性

• 可行性

• 易修改性

• 易測試性

• 易追溯性

詳細準則請參考評審檢查表

測試人員在需求評審中做用

需求評審歸爲靜態測試範疇，包含了文檔評審和技術評審雙重內容，一般經過正式的評審會議來進行。而測試人員主要起着評審員的做用，檢查需求定義是否合理和清楚。

• 明確本身的角色和責任

• 熟悉評審內容，爲評審作好準備

• 針對問題闡述觀點，而非針對我的

• 從客戶角度想問題，多問幾個爲何

• 在會前或會後提出本身建設性的意見

• 對發現的問題跟蹤到底

• 針對需求文檔等報告問題

設計評審

成功的產品開發和演化依賴於體系結構恰當的選擇。軟件設計通常能夠分爲體系結構設計和詳細設計。測試人員參與設計評審保證需求能在設計中獲得準確和完整的表示，也就是保證產品規格說明書的質量。

• 系統架構的審查

• 設計規格說明書的審查

• 系統部署設計的審查

• 多層次審查:high-level及low-level

系統設計的評審標準

• 設計技術評審標準。穩定、清晰、合理

• 非功能性質量特性的設計評審要求。安全、性能、穩定、擴展、可靠。

• 評審的輸入：體系結構文檔、設計規範與指南、風險列表

• 評審的輸出：經承認的軟件體系結構文檔、變動需求、評審記錄

• 評審的檢查點：軟件體系結構、設計模式、部署視圖、進程視圖、封裝體、協議。

系統設計的評審標準

系統架構設計的基本要求就是保證系統具備高性能、高可靠性、高安全性、高擴展性和可管理性 。系統架構設計評審就是保證這些特性在設計中獲得充分考慮。

採用分層評審和總體評審相結合，通過總體評審到分層評審、再從分層評審到總體評審的過程，這樣既能確保評審的深度，又能確保評審的一致性

• 整個系統不該該存在單一故障點

• 系統是否創建了故障轉移機制

• 是否創建了良好的負載平衡機制

• 關鍵業務 或關鍵任務 ？

組件設計的審查

• 功能和接口定義正確

• 算法的有效性和優化

• 合理的數據結構、數據流和控制流

• 可測試性 等

要特別注意模塊的獨立性，儘可能減小耦合性。

界面設計的審查

• 易懂性、易用性

• 一致性和規範性

• 美觀與協調性

• 遵照慣例和通用法則

• 獨特性

• 快捷方式的組合

• 自助功能

• 錯誤保護

UI標準中描述了字體 ，顏色搭配等規範。

界面設計的審查

系統部署設計的審查是基於軟件服務的質量目標，用來審查軟件部署的目標、策略是否合理，是否獲得完全的執行。

• 着重是否服從和遵照部署設計的技術規範

• 邏輯設計的審查

• 物理設計的審查

• 可用性設計的審查

• 可伸縮型設計的驗證

• 安全性設計的驗證

靜態分析

靜態分析和評審相似，但使用了工具。前提是文檔要遵循必定的格式，好比UML、HTML、XML等。通常在單元和集成測試階段使用。通常的公司只有代碼符合靜態分析的標準。

靜態分析可能會誤報，建議使用時的輸出信息從簡單到詳細。靜態分析不能發現變量除零等動態錯誤，可是能發現違反編程規範、易出錯的數據結構等問題。通常的編譯器都有靜態分析功能，還有專門的分析器，能發現的錯誤以下：

• 語法錯誤

• 違反編程標準和約定

• 控制流異常

• 數據流異常

• 安全隱患（緩衝區溢出及沒有檢查輸入數據的邊界等）

編譯器

• 生成不一樣的程序元素的交叉引用列表（例如，變量，函數）

• 嚴格檢查數據和變量的數據類型使用

• 檢測未聲明的變量

• 檢測dead代碼

• 檢測邊界溢出

• 檢查接口的一致性

• 檢查跳轉的label

約定和標準的符合性

好比python中的https://pypi.python.org/pypi/pep8和https://pypi.python.org/pypi/autopep8等。

數據流分析

主要分析數據流異常，好比變量未賦值就引用，或者變量從未使用。主要分爲3類：Defined (d)、Referenced (r)、Undefined (u)。異常分類：

• ur-anomaly:讀取未定義的變量

• du-anomaly：變量定義但未使用

• dd-anomaly：變量被連續賦值兩次，第一次的賦值沒有使用過

實例：

void exchange (int& Min, int& Max) {
  int Help;
  if (Min > Max) {
    Max = Help;
    Max = Min;
    Help = Min;
  }}

Help未賦值就引用；Max連續賦值2次；Help的最後賦值沒有任何引用。

控制流分析

控制流中，單個或多個程序語句用節點表示，這些語句做爲一個總體執行。程序執行的改變由if等語句決定，控制流程圖能夠清晰地看出控制流異常。控制流圖一般用工具生成。若是部分圖或者整個圖很複雜，事件也難以理解，一般就須要調整。

維度計算：v(G) = e - n + 2。e爲邊數(edge),n爲節點數(node)。McCabe建議維度儘可能不要超過10。 v(G) = cyclomatic number of the graph G e = number of edges of the control flow graph n = number of nodes of the control flow graph

參考資料

• 需求與設計的評審

• Rocky.Nook.Software.Testing.Foundations.4th.Edition.Mar.2014

• 做者博客：http://my.oschina.net/u/1433482

• 類型：翻譯