《軟體測試的有效方法（第2版）》筆記（一）

版權聲明：本文為部落客chszs的原創文章，未經部落客允許不得轉載。 https://blog.csdn.net/chszs/article/details/1351616

《軟體測試的有效方法（第2版）》筆記（一）

第一章 評估軟體測試的能力和人員資格

1、軟體開發過程：計劃P、執行D、檢查C、行動A。－－PDCA循環

2、軟體測試涉及的人員：軟體客戶、軟體使用者、開發人員、測試人員、資訊技術管理人員、進階組織管理人員、審計員。

3、軟體測試的多種角色：制造、創作工廠中的房間、專業化過程。

4、缺陷：與期望的産品屬性存在的差異。分兩類：

（1）産品規格書中的缺陷；

（2）與客戶/使用者的期望不符。

另一種分法：

（1）錯誤；

（2）遺漏；

（3）超額。

故障：當缺陷引起了運作錯誤或對客戶/使用者産生了消極影響時。

××注意：至少90%的缺陷是由于過程問題引起的。

建立軟體時産生缺陷的數量主要取決于過程是否完備，完備指過程中可以允許多大的變化。

風險：指不希望的事件發生的可能性。

5、軟體測試中的“三步測試法”：

（1）确定目前測試能力的狀态；

（2）确定改進目标；

（3）制訂測試計劃以達到測試目标。

6、品質保證協會QAI确定了與世界級軟體測試組織普遍相關的八項标準：

（1）測試計劃；

（2）對測試人員的教育訓練；

（3）對測試工作的管理；

（4）使用者對測試的滿意程度；

（5）測試過程的使用；

（6）有效的測試實踐；

（7）應用測試工具；

（8）對測試全過程的品質控制。

如果一組織能達到這八項标準的要求，就可以稱他為世界級的軟體測試組織。

7、評估現有測試過程的品質

實作過程：

（1）組建評估小組；

（2）完成評估調查問卷；

（3）建立Kiviat圖；

（4）評估結果。

軟體測試工程師認證CSTE

通用知識主題CBOK：五大類：

（1）一般技能；

（2）測試技巧/方法；

（3）測試計劃；

（4）執行測試計劃；

（5）測試分析的報告與改進。

第二章 制定軟體測試政策

1、确定解決方法的有效性是解決問題的必要步驟。測試就是用來确定解決方法的技術。

三個方面：

（1）在軟體系統開發生命周期的每個節點對軟體有效性的證明；

（2）根據使用者的需要和要求确定最終系統的有效性；

（3）通過使用樣本測試資料執行軟體來檢查系統的行為。

問題的緊急程度決定了解決方案。明确測試需求。

2、風險：是引起損失的一種情況。系統在開發和安裝階段可能存在的政策風險是：

（1）可能得出不正确的結果；

（2）系統接受了未經授權的事務處理；

（3）計算機檔案的完整性受到破壞；

（4）處理過程不可重建。

（5）失去處理的連續性；

（6）提供給使用者的服務達不到滿意的程度；

（7）系統安全性達不到标準；

（8）處理過程不符合組織原則或政府規定；

（9）系統結果不可靠；

（10）系統使用難度大；

（11）程式不可維護；

（12）系統不能移植到其它硬體或軟體中；

（13）系統不能與其它計算機系統互連；

（14）性能不合格；

（15）系統操作難度大。

有效的測試方法就是明确和評價計算機系統的各種風險。

“太少的測試是犯罪，太多的測試是罪惡。”

測試中的問題産生的原因：

（1）沒有定義測試目标；

（2）測試軟體生命周期的錯誤階段；

（3）使用無效的測試技術。

測試費用的有效性可用測試費用曲線來表示。

3、測試資訊服務系統不僅僅是一類IT問題，還是一類組織問題。

一些技術的發展會導緻測試方法的修改，如下：

（1）一體化；

（2）系統連結；

（3）多米諾骨牌效應；

（4）依賴電子商務；

（5）多使用者。

4、建立測試原則 四項标準：

（1）測試的定義：定義一個清晰、扼要、明确的測試；

（2）測試系統：通過這一方法實作測試和強制測試；

（3）評價：資訊服務管理将如何衡量和評價測試；

（4）标準：衡量測試的标準。

建立測試原則的方法：

（1）直接管理：一個或多個進階管理者制定的原則；

（2）資訊服務一緻原則：IT管理部門召集一些進階專家和有聲望的人來參與原則的制定；

（3）使用者會議：聯合IT各部門管理使用者的關鍵人員制定測試原則。

5、測試的結構化方法

測試過程要包括生命周期的每個階段：

（1）需求——決定驗證方法；确定需求是否恰當；生成功能測試資料；确定設計是否符合需求。

（2）設計——确定設計是否恰當；生成結構合功能測試資料；确定是否符合設計。

（3）程式設計——确定程式完成得是否恰當；生成程式的結構合功能測試資料。

（4）測試——測試應用系統。

（5）安裝——把測試過的系統投入生産。

（6）維護——修改和重新測試。

在每個階段都要完成的活動有：

（1）分析該階段的産品結構是否适合于測試；

（2）根據該階段的結構産生測試單元。

另外，在設計和程式設計階段完成的活動：

（1）确定該階段的結構是否符合前面階段産生的結構；

（2）精煉或重新定義前面階段生成的測試單元。

6、測試政策的兩個元件是：

（1）測試因素：需要由測試政策确定的風險和問題；

（2）測試階段：系統開發生命周期裡需要測試的各階段。

7、測試因素：正确性、檔案完整性、合法性、審計跟蹤、處理的連續性、服務水準、通路控制、符合性、可靠性、易用性、可維護性、可移植性、耦合、性能、易操作性。

8、制定測試政策 步驟：

（1）選擇和分級測試因素；

（2）明确系統開發階段；

（3）明确系統開發時的商業風險；

（4）把風險置于矩陣中。

9、建立測試政策樣例：

（1）選擇和分類測試因素；

（2）明确受到影響的階段；

（3）聯系每個階段和因素，确定測試需要考慮的問題；

（4）定義測試政策。

10、測試方法論：與測試政策相統一，代表了測試應用系統的詳細工作程式。工作程式用測試方法論立方體表示。

第三章 建立軟體測試方法論

測試方法論是使測試政策得以實施的一套方法。依照需求恰當的使用測試政策矩陣。任務是決定測試、制定可行的測試方法，識别出風險。

1、測試目的：發現和消除軟體的缺陷或者與預期結果的偏差。兩類缺陷：

（1）與規格說明不符；

（2）與期望不符。

2、導緻軟體缺陷的原因：

（1）資訊技術對需求的解釋不正确；

（2）使用者提出了錯誤需求；

（3）沒有正确記錄使用者的需求；

（4）設計規格說明不正确；

（5）程式規格說明不正确；

（6）程式編碼中有錯誤；

（7）資料輸入錯誤；

（8）測試錯誤；

（9）糾錯時出現錯誤；

（10）糾錯條件導緻另外的缺陷。

測試的費用主要取決于在項目生命周期的什麼時期開始測試，越晚越貴。

測試應該從生命周期的第一個階段開始，并貫穿于整個軟體開發的生命周期。

生命周期測試：是對解決方案的持續測試，即使在軟體開發計劃完成後或者被測試的系統處于執行狀态的時候，都不能中斷測試。直到正式開始開發過程，生命周期測試才能開始。

3、四個測試技術：

（1）驗證：確定系統遵循組織标準和規程，主要靠評審或一些不可執行的方法。

驗證需要的評審有：

    （1.1）需求評審：研究并讨論計算機系統的需求，以確定它能滿足使用者的需要及其可行性；

    （1.2）代碼走查：對程式源代碼進行非正式的分析，以發現缺陷并且驗證編碼技術；

    （1.3）代碼審查：對程式源代碼進行正式的分析，以發現為符合計算機系統設計規格說明所發生的設計缺陷；

    （1.4）設計評審：研究并讨論計算機系統的設計，以確定它支援系統需求；

    （1.5）回顧評審。

（2）确認：通過一系列可以看到和評價的測試來執行系統功能，以確定系統操作按照計劃實作。

确認的測試有：

    （2.1）單元測試：單獨程式、子產品或代碼單元的測試；

    （2.2）內建測試：相關的程式子產品、代碼單元測試；

    （2.3）系統測試：對于整個計算機系統的測試；

    （2.4）使用者驗收測試：對于計算機系統或系統某部分的測試，確定它們能配合系統工作，而無需考慮系統需求。

（3）功能測試：即黑盒測試。基本隻能使用确認技術。

（4）結構測試：白盒測試。主要使用驗證技術。

功能測試的優勢：模拟實際系統的使用；進行沒有系統結構的設想。

功能測試的不足：遺漏軟體中潛在的邏輯錯誤；可能造成備援測試。

結構測試的優勢：可以測試軟體的結構邏輯；測試時不用考慮是否完成了功能測試。

結構測試的不足：不能保證是否滿足使用者的需求；結構測試不可以模拟現實世界的情況。

兩者結合才能确認整個系統。

4、工作流程：是一種方法，它用圖示或文檔的方式來說明指定的活動是如何完成的。

每一個工作流程由以下四個部分組成：輸入、執行過程、檢查過程、輸出。

工作流程的概念可用作系統建立步驟的圖示說明。

5、開發測試方法論中要考慮的八個問題

（1）擷取和研究測試政策；

（2）确定開發項目的類型；

（3）确定軟體系統的類型；

（4）确定項目的範圍；

（5）确定戰術風險；

（6）确定何時進行測試；

（7）建立系統測試計劃；

（8）建立單元測試計劃。

步驟如下：

項目類型：指開發的軟體環境或方法論。

當環境變化大了，測試風險也會不同。

（3）确定軟體系統的類型

軟體系統的類型指該系統要完成的處理過程，一般有16種不同的軟體處理類型：

    （3.1）批處理：可以運作一般的批量處理；

    （3.2）事件控制：由外部事件引發的實時處理資料；

    （3.3）處理控制：從外部接收資料，根據收到的資料發出指令來控制某些行為；

    （3.4）規程控制：控制其它軟體；

    （3.5）進階數學模型：類似于模拟和商業政策軟體，但具有過多運用數學模型造成的複雜性；

    （3.6）消息處理：管理輸入輸出消息，處理文本或者文本包中包含的資訊；

    （3.7）診斷軟體：檢測和隔離硬體錯誤，這些硬體存在于電腦或與其通信的硬體中；

    （3.8）傳感器和信号處理：類似于消息處理，但需更多的處理過程來分析輸入資料，并使之轉換成可用的資料處理格式；

    （3.9）模拟：模拟一種環境、任務狀況、其它硬體；從這些輸入中得出對計算機程式或硬體最真實的評價；

    （3.10）資料庫管理：管理資料的存儲和通路；

    （3.11）資料采集：實時接收資訊，并以某種形式儲存資料，用作以後的處理；

    （3.12）資料表示：格式化資料及轉化資料；

    （3.13）決策和計劃輔助：使用人工智能技術提供一個專家系統來評價資料，為決策和政策制訂者提供附加的資訊和考慮；

    （3.14）圖形和圖像處理：生成和處理計算機圖像；

    （3.15）計算機系統軟體：為運作計算機程式提供服務；

    （3.16）軟體開發工具：為輔助軟體開發提供服務；

（4）确定項目的範圍：指包含在被測試的軟體中的所有行為——可以了解的系統需求和規格說明的範圍。

（5）确定戰術風險  戰術風險分為三類：

    （5.1）結構化風險：應用系統及建立應用系統的方法中所涉及的風險；

    （5.2）技術風險：建立和操作應用系統的技術所涉及的風險；

    （5.3）規模風險：軟體各方面的規模所設計的風險。

确定戰術風險的步驟：

    第一，了解風險和對風險的分級；

    第二，确定被測試的軟體系統中适當級值；

    第三，計算和累計風險分數。

（6）确定何時進行測試

測試在項目的各個階段都應該進行。在這些階段的測試行為有：

  A. 需求階段行為：确定測試政策；确定需求是否恰當；建立功能測試條件。

  B. 設計階段行為：确定需求設計符合性；确定設計是否恰當；建立結構和功能測試條件。

  C. 程式設計階段行為：确定設計符合性；确定執行是否恰當；建立程式單元的結構和功能測試條件。

  D. 測試階段行為：确定測試計劃是否恰當；測試應用系統。

  E. 安裝階段行為：修改和重新測試系統。

（7）建立系統測試計劃

測試計劃要提供測試軟體的背景資訊、測試目标和風險，以及測試的業務功能和要完成的特殊測試。

測試計劃類似于執行測試的路線圖，它被分解成特殊測試和低級測試。

測試執行後，要測試結果生成測試報告。

（8）建立單元測試計劃

把系統分成元件和單元來執行具體的處理，這些單元都要有自己的測試計劃。根據軟體對品質的要求程度，決定這些計劃的複雜程度。

單元測試計劃着重确定單元測試完成時間。