軟件測試知識帖(101-114)

軟件測試知識帖(101-114)

第101帖【2004－9－10】：USE CASE測試

USE CASE 是UML的核心，貫穿了RUP開發方法的整個過程，實際上RUP講的就是一種USE CASE 驅動的開發方法。我們可以使用Use Case來表示用戶的需求，並且Use Case避免了自然語言描述需求的二義性，可以自由的在不同的用戶之間傳遞信息，那麼我們在需求測試的時候，重點就落在瞭如何測試Use Case上了。

測試Use Case的方法有兩種：

 1、使用Use Case建模工具，比如Rational Rose，這類工具本身具有檢查Use Case的功能，包括語法的正確性，檢查是否完整，是否一致等。但是這類工具在檢查需求的遺漏或需求本身描述錯誤方面都比較弱，因此更好的測試方法是使用第二種方法；

 2、使用情景測試（Scenarios Testing）。在情景測試中，使用角色扮演的方法，在該方法中給每個項目組成員分配一個角色，角色可以是用戶、系統本身、其他系統，有時是系統維護的實體。然後，小組對Use Case的每一個情景進行走讀，扮演如何使用系統。在此過程中，將討論誰負責什麼事情，對每個角色的職責進行記錄。讓系統分析員扮演用戶或客戶的角色有助於真正地瞭解問題領域。另外，在情景測試過程中，讓用戶充分參與有助於發現一些遺漏或錯誤的需求。在第十五章中關於構架設計（Architecture Design）的評審方法中也用到了情景測試方法，可以一起進行參考。

第102帖【2004－9－13】：故障插入

故障插入（Fault Seeding）是一個統計的方法，用於評價遺留在一個程序中的故障的數量和種類。首先，故障被插入到一個程序中，然後，程序被測試，並且發現故障的數量被用於估計還沒有被發現故障的數量。計算公式如下：

原本錯誤總數 =（播入的錯誤總數/發現的播入錯誤數）×發現的原本錯誤數

殘留錯誤數 = 原本錯誤總數 - 發現的原本錯誤數

故障插入技術在軟件可靠性方面應用的比較廣泛，尤其在硬件的測試當中。例如一些汽車公司不惜花大價錢進行的汽車碰撞試驗，爲的就是發現汽車在碰撞過程中的潛在隱患，通過消除、改進這些隱患從而達到更高的性能。借鑑了硬件可靠性測試的方法，在軟件測試中引入故障插入技術，其主要目的是爲了評價系統的哪些模塊，哪些代碼是危險模塊，危險代碼，容易出問題，從而評價系統的容錯能力。在該技術中使用了故障加速技術，通過有意的插入故障來調用系統的故障容錯能力，從而在一個可控制的環境和期望的時間段內獲得完整的測試。它和現有的測試方法相比，最大的不同在於測試開始時的系統狀態不同，現有的測試都是從系統的正確狀態開始，測試系統如何轉入故障狀態，而故障注入測試則是從系統的故障狀態開始，測試系統在發生故障後的運行規律。

這裏要重點指出的是，故障插入不關注爲什麼出現這樣的故障，它關注的是出現了這樣的故障後系統如何處理。

故障插入也被用於驗證測試用例的有效性。其原理就是爲了檢查設計的測試用例是否能發現某一類型的故障，

人爲在被測系統中引入該類型的故障，如果在測試過程中能發現這個故障的話，則應該也可以測試出系統原來就存在的該類故障。

故障插入技術的一個難點是插入的故障在程序中是否能夠代表還沒有發現的故障。實際上，由於軟件的複雜性，故障的暴露往往和當時的運行環境、執行的路徑有很大的關係，能測試出故障插入的故障並不一定總是能測試出被測系統原本存在的該類型故障，所以，在上述的最後一步推論不一定總是成立。但是就從驗證測試用例的有效性角度來看，故障插入確實可以作爲一種手段。

第103帖【2004－9－14】：功能覆蓋率

功能覆蓋率（Function Coverage）是屬於黑盒測試範疇內的，在實際測試中，涉及到的覆蓋率一般都是結構化覆蓋率，與黑盒相關的覆蓋率比較少。

功能覆蓋中最常見的是需求覆蓋，其含義是通過設計一定的測試用例，要求每個需求點都被測試到。其公式是：

需求覆蓋 ＝ （被驗證到的需求數量）/（總的需求數量）

在黑盒測試中還有一個覆蓋叫接口覆蓋（或者稱爲入口點覆蓋），要求通過設計一定的用例使得系統的每個接口被測試到。

由於黑盒測試把被測系統理解爲一個黑盒，測試時，輸入測試數據，然後判定輸出結果是否與期望結果一致。根據這個可以得到輸入數據的覆蓋情況，即通過設計一定的用例，要求每種數據情況都被測試到。

第104帖【2004－9－15】：面向對象的覆蓋率

由於傳統的結構化度量沒有考慮面向對象的一些特性，如多態，繼承和封裝等。 傳統的結構化覆蓋必須被加強，以滿足面向對象特性，上下文覆蓋就是一種針對面向對象特性而增強的覆蓋。

上下文覆蓋可以應用到面向對象領域處理諸如多態，繼承和封裝的特性，同時該方法也可以被擴展用於多線程應用。通過使用這些面向對象的上下文覆蓋，結合傳統的結構化覆蓋的方法就可以保證代碼的結構被完整的執行，同時提高我們對被測軟件質量的信心。

有三個面向對象上下文覆蓋的定義，它們分別是：繼承上下文覆蓋（Inheritance Context Coverage），該覆蓋率用於度量在系統中的多態調用被測試得多好。基於狀態的上下文覆蓋（State-Based Context Coverage），該覆蓋用於改進對帶有狀態依賴行爲的類的測試。已定義用戶上下文覆蓋（User-Defined Context Coverage），該度量允許上下文覆蓋的方法被應用到傳統結構化覆蓋率無法使用的地方，例如多線程應用。

第105帖【2004－9－16】：軟件質量三角

在一個軟件企業中，要能夠良性的發展，必須關注組織，流程和人三者之間的關係。組織是流程成功實施的保障，好的組織結構能夠有效的促進流程的實施；流程對於產品的成功有着關鍵的作用，一個適合於組織特點和產品特點的流程能夠極大的提高產品開發的效率和產品質量，反之則會拖延產品開發進度，並且質量也無法得到保證；對企業來說，人是最寶貴的財富，它們是技術的載體，然而在組織中優秀的員工總是缺乏的，即使你擁有他們，也會有種種限制妨礙他們發揮作用。比如如果他們一週工作50到60小時，你不可能指望他們還能處理太多的挑戰性的問題。對於一個軟件公司來說，無論是開發人員還是測試人員，都非常關心其今後的發展通道，如果有一條清晰的技術發展線爲其指明今後的發展方向的話，這可以大大激勵員工的士氣和工作積極性，同時還可以爲企業積累各方面優秀的人才。另外技術發展的方向應該與現在的開發流程和規範相結合，這樣有利於專業技能的提高。

總之，組織，流程和人這三者是一個企業成功的鐵三角，理想的情況下它們彼此促進，糟糕的情況下它們彼此制約。

第106帖【2004－9－17】：流程對質量的貢獻

從一個軟件企業的長遠發展來看，如果要提高產品的質量首先應當從流程抓起，規範軟件產品的開發過程。這是一個軟件企業從小作坊的生產方式向集成化規範化的大公司邁進的必經之路，也是從根本上解決質量問題，提高工作效率的一個關鍵手段。

軟件產品的開發同其它產品（如汽車）的生產有着共同特性，即需要按一定的過程來進行生產。在工業界，流水線生產方式被證明是一種高效的，且能夠比較穩定的保證產品質量的一種方式。通過這種方式，不同的人員被安排在流程的不同位置，最終爲着一個目標共同努力，這樣可以防止人員工作間的內耗，極大的提供工作效率。並且由於其過程來源於成功的實例，因此其最終的產品質量能夠滿足過程所設定的範圍。軟件工程在軟件的發展過程中吸取了這個經驗並把它應用到了軟件開發中，這就形成了軟件工程過程，簡單的說就是開發流程。

不管我們做哪件事情，都有一個循序漸進的過程，從計劃到策略到實現。軟件流程就是按照這種思維來定義我們的開發過程，它根據不同的產品特點和以往的成功經驗，定義了從需求到最終產品交付的一整套流程。流程告訴我們該怎麼一步一步去實現產品，可能會有那些風險，如何去避免風險等等。由於流程來源於成功的經驗，因此，按照流程進行開發可以使得我們少走彎路，並有效的提高產品質量，提高用戶的滿意度。

目前流行的流程方法有很多種，如瀑布模型、螺旋模型、RUP模型、IPD流程等，不同的過程模型適合於不同 類型的項目。

第107帖【2004－9－18】：瀑布模型和螺旋模型

瀑布模型是應用最爲廣泛的一種模型，也是最容易理解和掌握的模型，然而它的缺陷也是顯而易見的。遺漏的需求或者不斷變更的需求會使得該模型無所適從。對於那些需求比較穩定、容易理解的項目比較合適。

螺旋模型是也是一個經典模型，它關注於發現和降低項目的風險。螺旋型項目從小的規模開始，然後探測風險，制定風險控制計劃，接着確定下一步項目是否還要繼續，然後進行下一個螺旋的反覆。該模型的最大優點就是隨着成本的增加，風險程度隨之降低。然而螺旋模型的缺點是比較複雜，且需要管理人員有責任心，專注以及有管理方面經驗。

第108帖【2004－9－20】：RUP模型

RUP（Rational Unified Process）是Rational公司提出的一套開發過程模型，它是一個面向對象軟件工程的通用業務流程。它描述了一系列相關的軟件工程流程，它們具有相同的結構，即相同的流程構架。RUP 爲在開發組織中分配任務和職責提供了一種規範方法，其目標是確保在可預計的時間安排和預算內開發出滿足最終用戶需求的高品質的軟件。RUP具有兩個軸，一個軸是時間軸，這是動態的。另一個軸是工作流軸，這是靜態的。在時間軸上，RUP劃分了四個階段：初始階段、細化階段、構造階段和發佈階段。每個階段都使用了迭代的概念。在工作流軸上，RUP設計了六個核心工作流程和三個核心支撐工作流程，核心工作流軸包括：業務建模工作流、需求工作流、分析設計工作流、實現工作流、測試工作流和發佈工作流。核心支撐工作流包括：環境工作流、項目管理工作流和配置與變更管理工作流。RUP 彙集現代軟件開發中多方面的最佳經驗，併爲適應各種項目及組織的需要提供了靈活的形式。作爲一個商業模型，它具有非常詳細的過程指導和模板。但是同樣由於該模型比較複雜，因此在模型的掌握上需要花費比較大的成本。尤其對項目管理者提出了比較高的要求。

第109帖【2004－9－21】：IPD流程

IPD（Integrated Product Development）流程是由IBM提出來的一套集成產品開發流程，非常適合於複雜的大型開發項目，尤其涉及到軟硬件結合的項目。IPD從整個產品角度出發，流程綜合考慮了從系統工程、研發（硬件、軟件、結構工業設計、測試、資料開發等）、製造、財務到市場、採購、技術支援等所有流程。是一個端到端的流程。在IPD流程中總共劃分了六個階段（概念階段、計劃階段、開發階段、驗證階段、發佈階段和生命週期階段），四個個決策評審點（概念階段決策評審點、計劃階段決策評審點、可獲得性決策評審點和生命週期終止決策評審點）以及六個技術評審點。IPD流程是一個階段性模型，具有瀑布模型的影子。該模型通過使用全面而又複雜的流程來把一個龐大而又複雜的系統進行分解並降低風險。一定程度上，該模型是通過流程成本來提高整個產品的質量並獲得市場的佔有。由於該流程沒有定義如何進行流程回退的機制，因此對於需求經常變動的項目該流程就顯得不大適合了。並且對於一些小的項目，也不是非常適合使用該流程。

第110帖【2004－9－22】：流程和技術

流程和成功不是等價的。沒有流程就成功就不可能得到保證，但有了流程並不意味着肯定能夠成功。這恐怕是很多迷信於流程的人所不能接受的。但這的確是個事實。記得有個做了將近30多年的需求分析專家說過：即使是一個已經達到CMM4級的公司，也完全有可能做不好需求分析。爲什麼？技術，技術是成功的另外一個必要條件。就好比現在你要從上海到北京去，流程給你指出了最短的路徑，技術提供給你最快的交通工具。兩者結合就是完美。

對於軟件開發來說，要保證軟件的質量，需要掌握多方面的技術，包括分析技術、設計技術、編碼技術和測試技術等等。在國內有一個普遍的非正常現象，就是大家覺得只有編程能力纔是玩電腦的真正技能。就好像造一套房子，其它都不重要，只要磚瓦匠有高超的技能就行了。儘管這個比喻會打擊很多程序員的自尊心，但這的確是一個事實。我們缺少系統級的工程師，在分析和設計方面的工作做得很不紮實。

需求是一個項目的靈魂。模棱兩可的需求帶來不可避免的後果便是返工—重做一些你認爲已做好的事情。返工會耗費開發總費用的4 0 %，而7 0 %～8 5 %的重做是由於需求方面的錯誤所導致的。

設計是最能體系一個工程師能力的地方。一個好的設計基本上決定了產品的最終質量。設計是把需求轉換成系統的一個關鍵步驟，它需要從自然語言描述的需求中尋找出設計的基礎單元，構建出整個系統的構架。關於設計方面的技能涉及面是很廣的，包括傳統的結構化設計到面向對象設計。

總之流程很關鍵，技術也很重要，魚和熊掌，兩者都不能放。

第111帖【2004－9－23】：Deming質量原則一

Deming質量原則一：要有一個堅定不移的目標

許多公司趨向於解決當前的問題而忽略將來的目標。根據Deming的原則：“對於一個公司，在沒有一個針對未來的計劃的前提下，它是不能存在於商業領域中的。”，一個堅定不移的目標需要：創新。如：一個長期的計劃，投資於研究和教育，並且不斷的改進產品和服務。

爲了應用該原則，一個質量保證組織可以：

1、開發一個質量保證計劃，提供一個長期的質量方向

2、需要軟件測試者爲每個項目開發並維護一個一致的測試計劃

3、鼓勵質量分析人員和測試人員遵循具有革新的方法來最大化產品的質量

4、致力於不斷改進質量過程

第112帖【2004－9－25】：Deming質量原則二

Deming原則二：質量成爲信仰

質量必須成爲一個新的信仰，根據Deiming的理論：“生存的成本和需要花錢購買的商品和服務的質量是成反比的，如：可靠的服務可以降低成本，延遲的服務或錯誤卻會提高成本”。由於延遲的服務和錯誤，商品和服務的消費被終止了，這降低了它們存在的意義。

爲了應用該原則，一個質量保證組織可以：

1、教育開發組織關於質量的價值和需要

2、提高質量保證部門的地位，使他們和別的部門同樣重要

3、糾正對質量部門是“看門狗”的消極看法

第113帖【2004－9－27】：Deming質量原則三

Deming質量原則三：不要依賴於海量的檢查

傳統的想法認爲檢查可以排除糟糕的質量。當難於確定在過程中一個缺陷在哪邊產生的時候，一個好的方法是關注於我們做的如何，而不應針對最終的產品。質量應當是內在的，而不是依賴於無數的檢查獲得的。

爲了使用該原則，一個質量保證組織可以：

1、在整個開發生命週期中，提高並使用技術評審、走讀和檢視來獲取質量。

2、在整個組織中灌輸質量意識，並把它作爲一個切實的，可度量的工作產品

3、需要信息技術質量的統計證據

第114帖【2004－9－28】：Deming質量原則五

Deming第五原則：產品和服務系統穩定的長期的提高

改進不是一時的努力——管理者有責任不斷的提高質量。“把火撲滅——很多公司稱之爲救火隊，並不是改進，尋找失去控制的地方，找到其特殊的原因並改正它，這只是把過程糾正回本來應該的位置。改進的責任是一個無止境的過程。”

爲了應用該原則，一個質量保證組織可以：

1、不斷的提高質量保證和測試過程

2、不要依賴於主管的判斷

3、使用統計技術，如測試分析和通過主因及效果分析揭示問題根源等方法