1、軟件質(zhì)量保證和管理,- Ch.16 軟件測試之質(zhì)量,軟件測試之質(zhì)量,程序測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程 - G.J.Myers,第16章 軟件測試之質(zhì)量,16.1 軟件測試 16.2 測試的現(xiàn)實和原則 16.3 測試的方法應用之道 16.4 測試目標實現(xiàn)的完整性和有效性 16.5 測試過程的評審和質(zhì)量保證 16.6 軟件測試組織和管理,16.1 軟件測試,16.1.1 軟件測試和質(zhì)量保證的關系 16.1.2 測試在軟件開發(fā)各個階段的任務 16.1.3 軟件測試目標,16.1.1 軟件測試和質(zhì)量保證的關系,二者都是貫穿整個軟件開發(fā)生命周期的流程,16.1.2 測試在軟件開發(fā)各個階段的任務,1

2、6.1.3 軟件測試目標,軟件測試的目標，就是為了更快、更早地將軟件產(chǎn)品或軟件系統(tǒng)中所存在的各種問題找出來，并促進程序員盡快地解決這些問題，最終及時地向客戶提供一個高質(zhì)量的軟件產(chǎn)品 軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程 一個好的測試能夠在第一時間發(fā)現(xiàn)程序中存在的錯誤 一個好的測試是發(fā)現(xiàn)了至今尚未發(fā)現(xiàn)的錯誤的測試。,16.2 測試的現(xiàn)實和原則,16.2.1 軟件測試的現(xiàn)實 16.2.2 軟件測試的原則,16.2.1 軟件測試的現(xiàn)實,測試工作總存在風險 測試不能提高質(zhì)量，但軟件產(chǎn)品發(fā)布后，缺陷較多，往往被認為是測試人員的錯。 測試人員的素質(zhì)和待遇。 測試時間往往被壓縮,16.2.2 軟件測試的原

3、則,所有測試的標準都是建立在用戶需求之上。 軟件測試必須基于“質(zhì)量第一”的思想去開展各項工作， 事先定義好產(chǎn)品的質(zhì)量標準。 軟件項目一啟動，軟件測試也就是開始。應當把“盡早和不斷地測試”作為測試人員的座右銘。 窮舉測試是不可能的。 第三方進行測試會更客觀，更有效。 軟件測試計劃是做好軟件測試工作的前提。 測試用例是設計出來的，不是寫出來的。 不可將測試用例置之度外，排除隨意性。 對發(fā)現(xiàn)錯誤較多的程序段，應進行更深入的測試。,16.3 測試的方法應用之道,16.3.1 測試的三維構(gòu)成 16.3.2 測試方法的辯證統(tǒng)一 16.3.3 驗證和確認缺一不可 16.3.4 測試用例設計方法的綜合運用 1

4、6.3.5 測試工具的有效使用 16.3.6 開發(fā)高質(zhì)量的測試腳本,16.3.1 軟件測試的三維空間,單元測試,系統(tǒng)測試,驗收測試,性能測試,兼容性測試,功能測試,白盒測試方法,層次或過程,方法（哲學思想）,特性-質(zhì)量目標,適用性測試,可靠性測試,集成測試,安全性測試,灰盒測試方法,黑盒測試方法,16.3.2 測試方法的辯證統(tǒng)一,白盒測試方法 vs. 黑盒測試方法 靜態(tài)測試 vs. 動態(tài)測試 手工測試 vs. 自動化測試 有計劃測試 vs. 隨機測試 新功能測試 vs. 回歸測試,白盒測試 vs. 黑盒測試,需求,事件,輸入,輸出,功能測試 數(shù)據(jù)驅(qū)動測試,結(jié)構(gòu)測試 邏輯驅(qū)動測試,靜態(tài)測試 vs

5、. 動態(tài)測試,評審,動態(tài)測試,手工測試 vs. 自動化測試,手工測試,有計劃測試 vs. 隨機測試,新功能測試 vs. 回歸測試,16.3.3 驗證和確認缺一不可,Verification：Are we building the product right？是否正確地構(gòu)造了軟件？即是否正確地做事，驗證開發(fā)過程是否遵守已定義好的內(nèi)容 驗證產(chǎn)品滿足規(guī)格設計說明書的一致性 Validation： Are we building the right product? 是否構(gòu)造了正是用戶所需要的軟件？即是否正在做正確的事。 驗證產(chǎn)品所實現(xiàn)的功能是否滿足用戶的需求,16.3.4 測試用例設計方法的綜合運用

6、,白盒設計方法又分為邏輯覆蓋法和基本路徑覆蓋法，或者分為語句覆蓋、判定覆蓋、條件覆蓋方法 黑盒設計方法分為等價類劃分法、邊界值劃分法、錯誤推測法、因果圖法等。 在實際測試用例設計過程中，不僅根據(jù)需要、場合單獨使用這些方法，常常綜合運用多個方法，使測試用例的設計更為有效。,例子,Dim a,b as Integer Dim c as Double If （a 0 and b 0） Then c = c/ a End If If （a1 or c1） Then c=c+1 End If c=b+c,判定-條件覆蓋的測試用例,條件組合覆蓋的測試用例,邊界值分析法和等價類劃分方法,16.3.5 測試工

7、具的有效使用,1基本要點或原則 2選擇測試工具 3運行框架,測試自動化的集成運行環(huán)境,16.3.6 開發(fā)高質(zhì)量的測試腳本,線性腳本，用于腳本的初始化或用于演示等。 結(jié)構(gòu)化腳本，具有各種邏輯結(jié)構(gòu)、函數(shù)調(diào)用功能等。有很好的可重用性、靈活性，易于維護。 共享腳本，腳本語言允許一個腳本調(diào)用另一個腳本。 數(shù)據(jù)驅(qū)動腳本，將測試輸入存儲在獨立的（數(shù)據(jù)）文件中，而不是存儲在腳本中。 關鍵字驅(qū)動腳本，將測試邏輯按照這些關鍵字進行分解，形成數(shù)據(jù)文件,而測試工具只要能夠解釋這些關鍵字即可對其應用自動化,16.4 測試目標實現(xiàn)的完整性和有效性,16.4.1 集成測試 16.4.2 功能測試和適用性測試 16.4.3

8、性能測試和容量測試 16.4.4 容錯性測試和安全性測試 16.4.5 回歸測試 16.4.6 安裝測試,16.4.1 集成測試,非漸增式測試模式 漸增式測試模式 將兩種模式有機結(jié)合起來，采用并行的自頂向下、自底向上集成方式，而形成改進的三明治方法。而更重要的是采取持續(xù)集成的策略,16.4.2 功能測試和適用性測試,程序安裝、啟動正常，有相應的提示等 每項功能符合實際要求 系統(tǒng)的界面清晰、美觀 能接受正確的數(shù)據(jù)輸入，對異常數(shù)據(jù)的輸入可以進行提示、容錯處理等 數(shù)據(jù)的輸出結(jié)果準確，格式清晰 功能邏輯清楚，符合使用者習慣 支持各種應用的環(huán)境 軟件升級后，能繼續(xù)支持舊版本的數(shù)據(jù),除了正確性和實用性之外

9、，還包括：符合標準和規(guī)范、直觀性、一致性、靈活性、舒適性,16.4.3 性能測試和容量測試,性能測試的重點在于前期數(shù)據(jù)的設計與后期數(shù)據(jù)的分析 盡量模擬不同的加載方式來進行系統(tǒng)的性能測試 性能測試要求測試環(huán)境應盡量與產(chǎn)品運行環(huán)境保持一致 通過比較和分析，可以清楚知道系統(tǒng)的性能狀況，以及什么樣的條件下系統(tǒng)性能達到最佳狀況、什么地方是性能的瓶頸 壓力測試、容量測試和性能測試的手段和方法很相似，有時可以交織在一起進行測試。壓力測試的重點在于發(fā)現(xiàn)系統(tǒng)方面的一些缺陷（性能瓶頸）。容量測試和性能測試更著力于提供性能與容量方面的指標數(shù)據(jù)。,16.4.4 容錯性測試和安全性測試,容錯性測試 輸入異常數(shù)據(jù)或進行異

10、常操作，以檢驗系統(tǒng)的保護性。 災難恢復性測試。通過各種手段，讓軟件強制性地發(fā)生故障，然后驗證系統(tǒng)已保存的用戶數(shù)據(jù)是否丟失、系統(tǒng)和數(shù)據(jù)是否能很快恢復。,安全性測試,應用程序級別的安全性，包括對數(shù)據(jù)或業(yè)務功能的訪問，在預期的安全性情況下，操作者只能訪問應用程序的特定功能、有限的數(shù)據(jù)。 系統(tǒng)級別的安全性，可確保只有具備系統(tǒng)訪問權限的用戶才能訪問應用程序，而且只能通過相應的網(wǎng)關來訪問，包括對系統(tǒng)的登錄或遠程訪問。,16.4.5 回歸測試,回歸測試的目的就是在程序有修改的情況下保證原有功能正常的一種測試策略和方法 。 選擇回歸測試方法應該兼顧測試風險（覆蓋面）和有效性兩個方面 基于風險選擇測試 基于操作

11、剖面選擇測試 再測試修改的部分,16.4.6 安裝測試,環(huán)境的不同設置或配置。 安裝文檔的準確性。 安裝的媒體制作是否有問題。,16.5 測試過程的評審和質(zhì)量保證,16.5.1 測試計劃的有效性和全面性 16.5.2 測試用例的復審 16.5.3 嚴格執(zhí)行測試 16.5.4 準確報告軟件缺陷 16.5.5 提高測試覆蓋度 16.5.6 測試結(jié)果分析和質(zhì)量報告,16.5.1 測試計劃的有效性和全面性,測試計劃主要集中在測試目標、質(zhì)量標準、測試策略、測試范圍、測試用例設計方法、所需資源和日程安排等，其關鍵是制定有效的測試策略，界定清楚地測試范圍，識別出測試中所存在的各種風險并找出風險回避、監(jiān)控和管

12、理的方法。針對不同的測試目標或階段確定測試方法，對測試工作量及所需的資源、時間進行合理的估算,細說測試計劃,制定測試策略 確定測試范圍 所需資源和日程安排 編制測試計劃的技巧 測試項目計劃的評審,16.5.2 測試用例的復審,測試用例設計的整體思路是否清晰，結(jié)構(gòu)和邏輯是否合理； 測試用例設計的有效性，測試的重點是否突出； 測試用例的覆蓋面； 測試用例的描述是否符合所定義的標準； 測試環(huán)境是否準確； 測試用例的復用性和可維護性； 測試用例可管理性、易于自動化測試等,16.5.3 嚴格執(zhí)行測試,如何確保測試環(huán)境滿足測試用例所描述的要求？ 如何保證每個測試人員清楚自己的測試任務和要達到的目標？ 如何

13、保證每個測試用例得到百分之百的執(zhí)行？ 如何保證所報告的軟件缺陷正確、描述清楚、沒有漏掉信息？ 如何在驗證Bug或新功能與回歸測試之間尋找平衡？ 如何跟蹤Bug處理的進度使嚴重的Bug及時得到解決？,16.5.4 準確報告軟件缺陷,單一準確 可以再現(xiàn) 完整統(tǒng)一 短小簡練 特定條件 補充完善 不做評價,16.5.5 提高測試覆蓋度,通過不斷的測試覆蓋度評估，掌握測試的實際狀況與測試覆蓋度目標的差距，及時采取措施，以提高測試的覆蓋度。 基于需求的測試覆蓋評估 基于代碼的測試覆蓋評估,16.5.6 測試結(jié)果分析和質(zhì)量報告,缺陷分布分析 缺陷趨勢分析 缺陷年齡分析 測試結(jié)果進度分析,缺陷趨勢分析,16.

14、6軟件測試組織和管理,16.6.1 測試項目的管理原則 16.6.2 測試資源的合理分配 16.6.3 測試進度和成本的控制 16.6.4 測試風險的管理,16.6.1 測試項目的管理原則,始終能夠把質(zhì)量放在第一位 可靠的需求 能夠制定好測試策略、有計劃地安排工作、系統(tǒng)的解決方案、制定合理的時間表。 充分測試并盡早測試。 遇到問題，在根本上解決問題 通用項目管理原則，,16.6.2 測試資源的合理分配,測試資源的分配，不僅要考慮測試團隊的構(gòu)成，而且要考慮不同的所需要的人數(shù)和對人員的要求是不同的。 在測試資源的分配上盡量做到合理，既不過于保守，浪費資源；也不過于激進 ，使資源的使用總是處于緊張狀態(tài) 。,16.6.3 測試進度和成本的控制,項目的進度管理是一門藝術，是一個動態(tài)的過程，需要不斷調(diào)度、協(xié)調(diào)，保證項目的均衡發(fā)展 項目的進度管理主要通過里程碑、關鍵路徑的控制并借助工具來實現(xiàn)，同時要把握好進度與質(zhì)量、成本的關系 1進度的數(shù)量和質(zhì)量的雙重特性 2測試進度的管理方法,16.6.4 測試風險的管理,質(zhì)量需求或產(chǎn)品的特性理解不準確，造成測試范圍分析的誤差； 測試用例沒有得到百分之百的執(zhí)行； 需求的臨時/突然變化； 質(zhì)量標準不都是很清晰的