1、AuthorVersionLast UpdatedBy 肖楠楠肖楠楠2n軟件測試理論軟件測試理論n軟件測試重要性軟件測試重要性n軟件測試概念軟件測試概念n測試級別測試級別n一般應用測試的類型，以及特定類型的測試一般應用測試的類型，以及特定類型的測試n測試的靜態(tài)和動態(tài)的度量方法測試的靜態(tài)和動態(tài)的度量方法n測試生命周期測試生命周期n測試策略測試策略n測試工具測試工具n測試過程管理測試過程管理3測試定義軟件測試是為了發(fā)現錯誤而執(zhí)行程序的過程。軟件測試是根據軟件開發(fā)階段的規(guī)格說明和程序的內部結構而精心設計的一批測試用例即輸入數據及預期的輸出結果），并利用這些測試用例去運行程序，以發(fā)現錯誤的過程。4測試

2、目的測試是運行程序的過程，目的在于發(fā)現錯誤，在用戶使用應用之前發(fā)現問題。測試是為了證明程序有錯，而不是證明程序無錯誤。 一個好的測試用例在于能夠發(fā)現至今未發(fā)現的錯誤。一個成功的測試是發(fā)現了至今未發(fā)現的錯誤的測試。5n質量的定義質量的定義n所完成的軟件產品滿足需求，符合確定的測量標準，遵循所完成的軟件產品滿足需求，符合確定的測量標準，遵循標準的開發(fā)過程。標準的開發(fā)過程。n質量要求質量要求n產品質量：產品質量是所生產的主要產品的質量，包括軟產品質量：產品質量是所生產的主要產品的質量，包括軟件和系統以及組成它們的所有元素。件和系統以及組成它們的所有元素。n過程質量：過程質量是指為保證產品質量而采用的

3、實現過過程質量：過程質量是指為保證產品質量而采用的實現過程包括措施和標準）。程包括措施和標準）。n測試與質量保證有別測試與質量保證有別6n盡早地和不斷地進行軟件測試；盡早地和不斷地進行軟件測試；n測試用例應由測試輸入數據和與之對應的預期輸出結果測試用例應由測試輸入數據和與之對應的預期輸出結果這兩部分組成；這兩部分組成；n程序員應避免檢查自己的程序，單元測試除外；程序員應避免檢查自己的程序，單元測試除外；n在設計測試用例時，應當包括合理的輸入條件和不合理在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件；的輸入條件；n充分注意測試中的群集現象；充分注意測試中的群集現象；n嚴格執(zhí)行測試計劃

4、，排除測試的隨意性；嚴格執(zhí)行測試計劃，排除測試的隨意性；n應當對每一個測試結果做全面檢查；應當對每一個測試結果做全面檢查；n妥善保存測試計劃，測試用例，妥善保存測試計劃，測試用例，Bug統計和最終分析報統計和最終分析報告，為維護提供方便。告，為維護提供方便。n測試發(fā)現的缺陷數應有逐漸減少的趨勢。測試發(fā)現的缺陷數應有逐漸減少的趨勢。7n瀑布模型瀑布模型n螺旋模型螺旋模型n V模型模型n W模型模型8n瀑布模型是早期經典的軟件生命周期模型，之所以叫做瀑瀑布模型是早期經典的軟件生命周期模型，之所以叫做瀑布模型，是因為每一個階段劃分的比較清晰，逐層向下，布模型，是因為每一個階段劃分的比較清晰，逐層向下

5、，具有和瀑布類似的特點。具有和瀑布類似的特點。 方案需求設計編碼測試維護瀑布模型的缺點：瀑布模型的缺點： 依賴于早期依賴于早期 的需求調查，的需求調查，不適應需求的變化不適應需求的變化 單一流程單一流程 ，不可逆。，不可逆。 風險往往遲至后期才顯風險往往遲至后期才顯露，失去較早糾正的機露，失去較早糾正的機會。會。 測試僅是編碼后的一個測試僅是編碼后的一個階段。階段。瀑布模型的優(yōu)點：瀑布模型的優(yōu)點： 開發(fā)的各個階段比較開發(fā)的各個階段比較清晰清晰 強調早期計劃及需求強調早期計劃及需求調查調查 適合需求穩(wěn)定的產品適合需求穩(wěn)定的產品開發(fā)開發(fā)9n螺旋模型是在瀑布模型的基礎上提出來的，之所以叫做螺螺旋模型

6、是在瀑布模型的基礎上提出來的，之所以叫做螺旋模型，是因為這是個迭代開發(fā)的過程，每一迭代過程均旋模型，是因為這是個迭代開發(fā)的過程，每一迭代過程均由需求、設計、編碼、測試、集成等階段組成。由需求、設計、編碼、測試、集成等階段組成。2.設計設計3.編碼編碼設計/人 1.方案/分析 4.測試測試10用戶需求概要設計詳細設計編碼單元測試集成測試驗收測試規(guī)格定義系統測試nV模型屬于比較新的模型，之所以叫做模型屬于比較新的模型，之所以叫做V模型，是因為其模型，是因為其形狀看起來像個形狀看起來像個V字。字。11nV模型的優(yōu)點就是詳細表示了測試的各個階段以及參考依模型的優(yōu)點就是詳細表示了測試的各個階段以及參考依

7、據：據：n 單元測試參考的是單元測試參考的是詳細設計詳細設計n 集成測試參考的是集成測試參考的是概要設計概要設計n 系統測試參考的是系統測試參考的是評審等。評審等。26n審核測試審核測試n 通常由獨立于項目組的質量管理人員定期舉行。對通常由獨立于項目組的質量管理人員定期舉行。對項目的開發(fā)過程、規(guī)定的活動、進度計劃進行審核，主要項目的開發(fā)過程、規(guī)定的活動、進度計劃進行審核，主要是對開發(fā)的過程進行控制。審核的結果，常常就是對一個是對開發(fā)的過程進行控制。審核的結果，常常就是對一個項目或計劃進行重大調整的依據。如：質量保證部門對開項目或計劃進行重大調整的依據。如：質量保證部門對開發(fā)過程的驗證等。發(fā)過程

8、的驗證等。n檢查測試檢查測試n 通常也是由項目組以外、甚至企業(yè)組織以外的人員通常也是由項目組以外、甚至企業(yè)組織以外的人員進行。檢查測試往往是針對特定的課題，按照事先確定的進行。檢查測試往往是針對特定的課題，按照事先確定的要求進行嚴格的審查。當檢查有權威性行業(yè)機構組織實施要求進行嚴格的審查。當檢查有權威性行業(yè)機構組織實施時，檢查的結果往往影響深遠。如時，檢查的結果往往影響深遠。如CMM認證的正式審核。認證的正式審核。27按測試用例設計方法：按測試用例設計方法：白盒測試白盒測試黑盒測試黑盒測試28n黑盒測試黑盒測試n功能功能n系統性能系統性能n白盒測試白盒測試n靜態(tài)質量分析靜態(tài)質量分析n覆蓋測試分

9、析覆蓋測試分析nRUNTIME問題檢測問題檢測n代碼執(zhí)行性能代碼執(zhí)行性能n測試執(zhí)行方式測試執(zhí)行方式n動態(tài)動態(tài)n靜態(tài)靜態(tài)2930n白盒測試白盒測試n結構測試、邏輯驅動測試結構測試、邏輯驅動測試n結構測試將程序的執(zhí)行表現與編碼意圖作比較結構測試將程序的執(zhí)行表現與編碼意圖作比較n隨著隨著CASECASE工具的發(fā)展，白盒測試的內容相應擴展工具的發(fā)展，白盒測試的內容相應擴展應用程序典型白盒測試方法典型白盒測試方法靜態(tài)分析靜態(tài)分析動態(tài)測試動態(tài)測試31n黑盒測試n功能測試、數據驅動測試、基于規(guī)格說明的測試n將程序的執(zhí)行表現與功能需求規(guī)格說明作比較輸入輸出典型黑盒測試方法典型黑盒測試方法等價類劃分等價類劃分因

10、果圖因果圖邊界值分析邊界值分析32n如果想用黑盒測試來發(fā)現程序中的所有錯誤，就必須用輸如果想用黑盒測試來發(fā)現程序中的所有錯誤，就必須用輸入數據的所有可能值來檢驗程序是否都能產生預期的結果，入數據的所有可能值來檢驗程序是否都能產生預期的結果，但是這個顯然是不可能的：但是這個顯然是不可能的：n 窮舉輸入窮舉輸入n 設計規(guī)格說明書設計規(guī)格說明書n因而不能單純依靠功能測試，還必須研究程序的邏輯和結因而不能單純依靠功能測試，還必須研究程序的邏輯和結構，來分析程序的總體質量狀況。構，來分析程序的總體質量狀況。3334從測試級別上說從測試級別上說單元測試單元測試集成測試集成測試自底向上測試自底向上測試自上向

11、下測試自上向下測試系統測試系統測試驗收測試驗收測試35n設計評審設計評審n靜態(tài)分析靜態(tài)分析n功能測試功能測試n用戶界面測試用戶界面測試n性能測試性能測試n壓力測試壓力測試n容量測試容量測試n配置測試配置測試n安裝測試安裝測試36n設計評審設計評審n 評審在軟件需求分析階段產生的軟件需求規(guī)格說明書、評審在軟件需求分析階段產生的軟件需求規(guī)格說明書、數據要求規(guī)格說明，以及在軟件概要設計階段產生的軟件數據要求規(guī)格說明，以及在軟件概要設計階段產生的軟件概要設計說明書等。概要設計說明書等。3738n功能測試功能測試n驗證軟件是否提供了所期待的服務。包括：驗證軟件是否提供了所期待的服務。包括：n“主要主要方

12、案方案-所有的輸入是合法的。所有的輸入是合法的。n“輔助輔助方案方案-一些或所有的輸入是不合法的。一些或所有的輸入是不合法的。394041424344 Maintenance維護需求分析設計開發(fā) Revision Build Build實施實施Exec.測試計劃缺陷追蹤測試開發(fā)測試設計缺陷分析45Exec.Exec.Test PlanningDefect TrackingTestDevelopment測試設計Evaluation Build BuildExec. Build464748495051?5253軟件測試測試團隊測試組管理員測試組成員測試過程/方法測試工具測試計劃及設計工具測試開發(fā)及

13、實施工具測試評估及缺陷跟蹤工具54測試設計工程師/測試開發(fā)工程師測試團隊測試經理 測試系統管理員測試執(zhí)行工程師55以上我們學習了：以上我們學習了：軟件測試的重要性軟件測試的重要性基本概念回顧：測試的定義，測試目的等基本概念回顧：測試的定義，測試目的等測試的級別：單元、集成、系統、驗收測試的級別：單元、集成、系統、驗收測試術語小結測試術語小結測試類型：功能、界面、性能、壓力、容量、配置、安裝等測試類型：功能、界面、性能、壓力、容量、配置、安裝等測試度量：靜態(tài)度量、動態(tài)度量測試度量：靜態(tài)度量、動態(tài)度量測試策略：制定策略應考慮到的因素測試策略：制定策略應考慮到的因素測試生命周期：方案、設計、實現、執(zhí)

14、行、評估以及缺陷跟測試生命周期：方案、設計、實現、執(zhí)行、評估以及缺陷跟蹤蹤測試工具測試工具測試過程管理測試過程管理56一、設有一個檔案管理系統，要求用戶輸入以年月表示的日期。假設日期限定在1990年1月2049年12月，并規(guī)定日期由6位數字字符組成，前4位表示年，后2位表示月。現用等價類劃分法設計測試用例，來測試程序的“日期檢查功能”。 571)劃分等價類并編號,下表等價類劃分的結果輸入等價類輸入等價類有效等價類有效等價類無效等價類無效等價類日期的類型及長度日期的類型及長度6位數字字符位數字字符有非數字字符少于有非數字字符少于6位數位數字字符多于字字符多于6位數字字符位數字字符年份范圍年份范圍

15、在在19902049之間之間小于小于1990大于大于2049月份范圍月份范圍在在0112之間之間等于等于00大于大于122)設計測試用例，以便覆蓋所有的有效等價類在表中列出了設計測試用例，以便覆蓋所有的有效等價類在表中列出了3個有效等價類，編號分別為、，設計的測試用個有效等價類，編號分別為、，設計的測試用例如下：例如下： 測試數據測試數據 期望結果期望結果 覆蓋的有效等價類覆蓋的有效等價類 201911 輸入有效輸入有效 、 583)為每一個無效等價類設計一個測試用例，設計結果如下：為每一個無效等價類設計一個測試用例，設計結果如下： 測試數據測試數據 期望結果期望結果 覆蓋的無效等價類覆蓋的無

16、效等價類 95June 無效輸入無效輸入 20196 無效輸入無效輸入 2019006 無效輸入無效輸入 198912 無效輸入無效輸入 205001 無效輸入無效輸入 201900 無效輸入無效輸入 201913 無效輸入無效輸入 59二、假定一臺二、假定一臺ATM機允許提取的增量為機允許提取的增量為50元，總額為從元，總額為從50元不等的現金元不等的現金;并要求一次最多取并要求一次最多取2000元，一天最多取元，一天最多取5000元，一天最多取元，一天最多取3次。請運用等價類和邊界值的思想次。請運用等價類和邊界值的思想編寫測試用例。編寫測試用例。60用例編號用例編號輸入數據輸入數據預期結果

17、預期結果1一次取一次取50元元提取成功提取成功2一次取一次取20元元友好提示：至少為友好提示：至少為50元或倍數元或倍數3取三次：取三次：2000+2000+10005000提取成功提取成功4取三次：取三次：2000+2000+10505050友好提示：一天不能多于友好提示：一天不能多于50005取三次：取三次：50+50+50150提取成功提取成功6取四次：取四次： 50+50+50+50友好提示：一天最多不能超過友好提示：一天最多不能超過4次次7ATM機余額不足機余額不足友好提示友好提示“ATM機余額不足機余額不足”;用戶的用戶的提款操作被取消提款操作被取消8卡內余額不足卡內余額不足友好提示友好提示“卡內余額不足卡內余額不足”;用戶的提用戶的提款操作被取消款操作被取消9取款的過程中機器出現故障取款的過程中機器出現故障友好提示友好提示“機器故障機器故障”;用戶的提款操用戶的提款操作被取消作被取消10卡被吞掉卡被吞掉友好提示友好提示“請和工作人員聯系請和工