掌握測試過程中的測試級別
掌握回歸測試的概念與策略
掌握測試過程模型
了解測試過程規(guī)范
測試階段劃分
單元測試(UnitTesting)
集成測試(Integration Testing)
系統(tǒng)測試(System Testing)
測試過程模型
測試過程規(guī)范
02-測試過程單元集成系統(tǒng)及比較
單元測試
單元測試是針對軟件基本組成單元(軟件設(shè)計的最小單位)來進行正確性檢驗的測試工作
單元測試的目的是檢測軟件模塊對《詳細設(shè)計說明書》的符合程度 函數(shù)
詳細設(shè)計說明書:詳細設(shè)計說明書又可稱程序設(shè)計說明書诵姜。編制目的說明一個軟件各個層次中的每一個程序
(每個模塊或子程序)的設(shè)計考慮,如果一個軟件系統(tǒng)比較簡單,層次很少,本文件可以不單獨編寫,有關(guān)
內(nèi)容合并入概要設(shè)計說明書翅娶。
集成測試
集成測試是在單元測試的基礎(chǔ)上,將所有模塊按照概要設(shè)計要求組裝成為子系統(tǒng)或系統(tǒng),驗證組裝后
功能以及模塊間接口是否正確的測試工作
集成測試的目的是檢測軟件模塊對《概要設(shè)計說明書》的符合程度? 測接口
系統(tǒng)測試
系統(tǒng)測試是將已經(jīng)集成好的軟件系統(tǒng),作為整個基于計算機系統(tǒng)的一個元素,與計算機硬件隅居、外設(shè)
缀辩、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起,在實際運行(使用)環(huán)境下,對計算機系統(tǒng)
進行一系列的測試工作
系統(tǒng)測試的目的在于通過與《需求規(guī)格說明書》作比較,發(fā)現(xiàn)軟件與系統(tǒng)需求定義不符合或與之矛盾的地方
軟件需求說明書
SRS(Software Requirements Specification),軟件需求說明書的編制是為了使用戶和軟件開發(fā)者雙方對該軟件的
初始規(guī)定的一個共同的理解,使之成為整個開發(fā)工作的基礎(chǔ)撤摸。包含硬件忠藤、功能掉冶、性能、輸入輸出糙及、接口界面详幽、警示信息
、保密安全、數(shù)據(jù)與數(shù)據(jù)庫唇聘、文檔和法規(guī)的要求版姑。
單元、集成迟郎、系統(tǒng)測試的比較
測試方法不同
單元測試屬于白盒測試范疇
集成測試屬于灰盒測試范疇
系統(tǒng)測試屬于黑盒測試范疇
考察范圍不同
單元測試主要測試單元內(nèi)部的數(shù)據(jù)結(jié)構(gòu)剥险、邏輯控制、異常處理等
集成測試主要測試模塊之間的接口和接口數(shù)據(jù)傳遞關(guān)系,以及模塊
組合后的整體功能
系統(tǒng)測試主要測試整個系統(tǒng)相對于需求的符合度
評估基準不同
單元測試的評估基準主要是邏輯覆蓋率
集成測試的評估基準主要是接口覆蓋率
系統(tǒng)測試的評估基準主要是測試用例對需求規(guī)格的覆蓋率
03-測試過程回歸測試流程1
軟件配置 回歸測試
測試配置 測試 測試結(jié)果? 結(jié)果分析 錯誤? 改正錯誤 改正的軟件
測試工具 ? 預期結(jié)果 可靠性分析 預測的可靠性
測試過程信息流
回歸測試(2) 軟件在測試或其他活動中發(fā)現(xiàn)的缺陷經(jīng)過修改后,應該進行回歸測試(Regression Testing)宪肖。 目的是驗證缺陷得到了正確的修復,
同時對系統(tǒng)的變更沒有影響以前的功能
回歸測試可以發(fā)生在任何一個階段,包括單元測試表制、集成測試和系統(tǒng)測試
回歸測試流程
以下流程適合于單元測試、集成測試和系統(tǒng)測試
1控乾、在測試策略制定階段,制定回歸測試策略
2么介、確定需要回歸測試的版本
3、回歸測試版本發(fā)布,按照回歸測試策略執(zhí)行回歸測試
4蜕衡、回歸測試通過,關(guān)閉缺陷跟蹤單(問題單)
5夭拌、回歸測試不通過,缺陷跟蹤單返回開發(fā)人員,開發(fā)人員重新修改問題,再次提交測試人員回歸測試。
04-測試過程回歸測試策略
回歸測試流程
以下流程適合于單元測試衷咽、集成測試和系統(tǒng)測試
1、在測試策略制定階段,制定回歸測試策略
2蒜绽、確定需要回歸測試的版本
3镶骗、回歸測試版本發(fā)布,按照回歸測試策略執(zhí)行回歸測試
4、回歸測試通過,關(guān)閉缺陷跟蹤單(問題單)
5躲雅、回歸測試不通過,缺陷跟蹤單返回開發(fā)人員,開發(fā)人員重新修改問題,再次提交測試人員回歸測試
回歸測試策略
完全重復測試:
重新執(zhí)行所有在前期測試階段建立的測試用例,來確認問題修改的正確性和修改的擴散局部影響性
選擇性重復測試:
即有選擇地重新執(zhí)行部分在前期測試階段建立的測試用例,來測試被修改的程序
回歸測試策略
選擇性重復測試
覆蓋修改法
即針對被修改的部分,選取或重新構(gòu)造測試用例驗證沒有錯誤再次發(fā)生的用例選擇方法鼎姊。
周邊影響法:
該方法不但要包含覆蓋修改法確定的用例,還需要分析修改的擴散影響,對那些受到修改間接影響的部分選擇測試用例驗證它沒有受到不良影響
該方法比覆蓋修改法更充分一點。
指標達成方法
這是一種類似于單元測試的方法,在重新執(zhí)行測試前,先確定一個要達成的指標,如修改部分代碼100%的覆蓋相赁、與修改有關(guān)的接口60%的覆蓋率等
基本于這種要求選擇一個最小的測試用例集合相寇。
回歸測試自動化(1)
1.回歸測試是一個重用以前成功的測試,很難預料到要經(jīng)過多少次回歸系統(tǒng)才能達到滿意的水平,結(jié)果,這種
回歸測試將可能演變成一種重復的、令人心煩意亂的工作,效果與任媛媛的積極性將大打折扣,因此,在回歸測試道路上的自動化便是我們工作的追求
2.回歸測試的自動化包括測試程序的自動運行钮科、自動配置,測試用例的管理和自動輸入,測試的自動執(zhí)行,測試信息與結(jié)果的自動采集,測試結(jié)果的自動比較
和結(jié)論的自動輸出,尤其前面提到的各類數(shù)據(jù)的共享決策
3.對系統(tǒng)測試功能比較簡單唤衫、測試界面相對穩(wěn)定并且用例良好組織的測試來說,采用“捕捉回放”工具是比較合適的,這類工具有QTP、Robot绵脯、SilkTest等
4.為了實現(xiàn)測試用例的自動化并實現(xiàn)測試結(jié)果的自動判斷,腳本化的佳励、包含控制結(jié)構(gòu)、內(nèi)部實現(xiàn)結(jié)果判斷的測試用例是唯一的選擇,此類腳本語言有TCL蛆挫、Python赃承、Perl等
5.對于特定系統(tǒng)的、復雜的測試來講,如果沒有通用的商用工具可供選擇,探索開發(fā)專門的自動化測試工具是靈活且易于擴充的方法
6.回歸測試的自動化(或者說工具化)的問題是一個需要盡早考慮的問題,在做測試方案時就要考慮這種可能性,必要時要投入資源進行開發(fā),
能形成可供繼承與推廣的工具則是最終目的
-----------------------------------------------------------------------------
05-測試過程驗收測試alpha和beta測試
其他測試階段
單元測試悴侵、繼承測試瞧剖、系統(tǒng)測試是軟件開發(fā)過程中在軟件組織內(nèi)部進行的測試階段
軟件正式發(fā)布前還可能進行有 用戶參與 的其他一些測試,如:
驗收測試
在通過了內(nèi)部系統(tǒng)測試及軟件配置審查之后,就可以開始驗收測試
驗收測試是以用戶為主的測試,驗收組應該由項目組成員、用戶代表等組成
驗收測試原則上在用戶所在地進行,但如經(jīng)用戶同意也可以在公司內(nèi)模擬用戶環(huán)境進行
驗收測試根據(jù)合同、《需求規(guī)格說明書》或《驗收測試計劃》對成品進行驗收測試
驗收測試的結(jié)果有兩種情況:
軟件功能抓于、性能等質(zhì)量特性與用戶的要求一致,軟件可以接受
軟件功能做粤、性能等質(zhì)量特性與用戶的要求有差距,不被用戶接受
α(ALPHA)測試
α測試
α測試由用戶在開發(fā)環(huán)境下進行的測試,也可以是開發(fā)機構(gòu)內(nèi)部的用戶在模擬實際操作環(huán)境下進行的測試
α測試時,軟件在一個自然設(shè)置狀態(tài)下使用。軟件開發(fā)者坐在用戶旁.隨時記下錯誤情況和使用中的問題毡咏。這是
在受控制的環(huán)境下進行的測試
α測試的目的主要是評價軟件產(chǎn)品的FLURPS(即功能驮宴、局域化、可用性呕缭、可靠性堵泽、性能和技術(shù)支持)
β(BETA)測試
β測試是由軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進行的測試
與α測試不同的是,β測試時開發(fā)者通常不在測試現(xiàn)場。因此,β測試是在開發(fā)者無法控制的環(huán)境下進行的軟件現(xiàn)場應用
06-測試過程階段劃分
測試階段劃分
測試計劃階段-測試計劃
測試計劃：指明測試范圍恢总、方法迎罗、資源,以及相應測試活動的時間進度安排表的文檔。
測試方案：指明為完成軟件或軟件集成特性的測試而進行的設(shè)計測試方法的細節(jié)文檔片仿。
測試用例：指明為完成一個測試項的測試輸入纹安、預期結(jié)果、測試執(zhí)行條件等因素的文檔砂豌。
測試規(guī)程：指明執(zhí)行測試是測試活動序列的文檔厢岂。
測試報告:指明執(zhí)行測試結(jié)果的文檔。
測試日報:每天測試執(zhí)行情況的記錄和總結(jié)阳距。
測試設(shè)計階段-測試方案
測試實現(xiàn)階段-測試用例夯接、測試規(guī)程
測試執(zhí)行階段-測試報告
測試過程模型
測試過程規(guī)范
07-測試過程模型瀑布V
常見的測試過程模型
瀑布模型
H模型
V&V模型
08-測試過程模型W
V---W? 開發(fā)一個V 測試一個V
測試V&V模型(2)
V&V模型實現(xiàn)了測試設(shè)計和測試執(zhí)行相分離
V&V模型揭示了軟件測試活動分層和分階段的本質(zhì)特性,的順序與開發(fā)活動相反
09-測試過程模型H
測試準備 測試就緒點? 測試執(zhí)行 測試流程
其他流程(如設(shè)計流程)
測試分兩類活動：
測試準備活動,包括測試需求分析甩栈、測試計劃、測試設(shè)計、測試編碼芍阎、測試驗證
另一類是測試執(zhí)行活動,包括測試運行琉苇、測試報告做鹰、測試結(jié)果分析等
單元測試完成才能做集成測試
軟件測試不僅僅指測試執(zhí)行,還包括很多其他的活動雏门。
測試是一個獨立的流程,貫穿產(chǎn)品整個周期,與其他流程并發(fā)地進行。
測試要盡早準備,盡早執(zhí)行馍管。
各個不同階段的測試除了簡單的時間上的先后關(guān)系外,還存在觸發(fā)郭赐、反復、迭代和量增關(guān)系确沸。
010-測試過程模型驗證和確認
驗證與確認V&V
驗證(Verificaition)
驗證是保證軟件正確地特定功能的一系列活動
驗證是檢測每一階段形成的工作產(chǎn)品是否與前一階段定義的規(guī)格相一致
“Are we building the product right?”
確認(Validation)
確認是指保證所產(chǎn)生的軟件可追溯到用戶需求的一系列活動
確認是檢測每一階段的工廠產(chǎn)品是否與最初定義的軟件需求規(guī)格相一致
"Are we building the right product?"
011-測試過程規(guī)范過程要素
測試過程規(guī)范
CMM關(guān)于過程的要素
計劃? 設(shè)計 實現(xiàn) 執(zhí)行
管理? 主管? 軟件工程師 初級測試工程師
角色(Roles)
入口準則(EntryCriteria)
輸入(Inputs)
活動(Activities)
輸出(Outputs)
出口準則(ExitCtiteria)
評審和審計(Reviews and Audits)
可管理和受控的工作產(chǎn)品(WorkProducts Managed and Controlled)
測量(Measurements)
書面規(guī)程(DocumentedProcedures)
培訓(Training)
工具(Tools)
012-測試過程規(guī)范系統(tǒng)測試輸入輸出
系統(tǒng)測試過程與開發(fā)階段
需求分析解讀那 概要設(shè)計 詳細設(shè)計 編碼 單元測試執(zhí)行 集成測試執(zhí)行 系統(tǒng)測試執(zhí)行
系統(tǒng)測試計劃
系統(tǒng)測試設(shè)計
系統(tǒng)測試實現(xiàn)
------------------------------------------
系統(tǒng)測試各階段的輸入堪置、輸出
軟件開發(fā)計劃
軟件測試計劃 需求規(guī)格說明書
需求規(guī)格說明書 系統(tǒng)測試計劃
系統(tǒng)測試計劃階段 系統(tǒng)測試設(shè)計階段
系統(tǒng)測試計劃 系統(tǒng)測試方案
需求規(guī)格說明書 系統(tǒng)測試計劃
系統(tǒng)測試計劃 系統(tǒng)測試方案
系統(tǒng)測試方案 系統(tǒng)測試用例
系統(tǒng)測試實現(xiàn)階段 系統(tǒng)測試預測試項
系統(tǒng)測試用例 系統(tǒng)測試規(guī)程
系統(tǒng)測試規(guī)程 系統(tǒng)測試執(zhí)行階段
系統(tǒng)測試預測試項 系統(tǒng)預測試報告、
系統(tǒng)測試報告
缺陷報告
013-測試過程規(guī)范需求分析階段工作任務和角色及職責
需求分析階段的主要任務(需求分析是重要和困難的工作
1.交流-業(yè)務张惹、環(huán)境
2.不斷的變化
3.復雜? 需求1小時小時 設(shè)計2.5小時 編碼5小時 測試25小時 維護時間更長
)
需求分析,完成SRS
軟件需求規(guī)格說明書的評審
進行需求跟蹤
系統(tǒng)測試計劃
系統(tǒng)測試計劃的評審
----------------------------------------------------------
需求階段的角色和職責
軟件開發(fā)項目經(jīng)理
A舀锨、帶領(lǐng)項目組分析審核工作任務書;
B、帶領(lǐng)項目組與系統(tǒng)工程師進行需求交流并進行分析和文檔化;
C宛逗、組織SRS文檔評審;
D坎匿、組織需求跟蹤;
軟件開發(fā)工程師
A、完成SRS文檔;
B、完成需求跟蹤;
C替蔬、參加SRS review
D告私、根據(jù)SRS評審專家意見,修改SRS文檔;
E、參加系統(tǒng)測試計劃的評審;
軟件經(jīng)理
A承桥、在SRS評審結(jié)束后,批準SRS文檔;
QA(質(zhì)量保證)
A驻粟、監(jiān)督項目組遵循需求管理流程;
B、參加相關(guān)文檔review
C凶异、保證相關(guān)組參加文檔review
CCB的負責人(CCB 變更控制委員會)
A蜀撑、控制需求的變更;
軟件測試項目經(jīng)理
A、參與開發(fā)人員的軟件需求分析,提出可測試性需求;
B剩彬、組織人員參與SRS的評審工作;
C酷麦、軟件系統(tǒng)測試計劃寫作;
D、組織系統(tǒng)測試計劃的評審;
E喉恋、組織本階段測試需求跟蹤;
軟件測試工程師
A沃饶、參與SRS評審工作;
B、協(xié)助軟件測試項目經(jīng)理完成軟件系統(tǒng)測試計劃寫作;
C轻黑、參加系統(tǒng)測試計劃的評審;
D糊肤、完成本階段測試需求跟蹤;
014-測試過程規(guī)范執(zhí)行階段角色及職責
UT/IT/ST執(zhí)行階段的角色和職責(1)
開發(fā)組項目經(jīng)理
A、確保缺陷分給相關(guān)軟件工程師并監(jiān)督及時得到解決;
B氓鄙、提出轉(zhuǎn)系統(tǒng)測試申請;
軟件開發(fā)人員
A轩褐、修正缺陷;
B、驗證相關(guān)的缺陷已經(jīng)被修正;
C玖详、參加各階段測試報告的評審;
UT/IT/ST執(zhí)行階段的角色和職責(2)
QA
A、監(jiān)督項目遵循測試執(zhí)行流程;
B勤讽、參加測試報告和轉(zhuǎn)系統(tǒng)測試評審;
C蟋座、保證相關(guān)組參加測試報告和轉(zhuǎn)系統(tǒng)測試評審;
CCB的負責人
A、對缺陷的修改進行裁決; 變更 跟蹤
UT/IT/ST執(zhí)行階段的角色和職責(3)
軟件測試項目經(jīng)理
A脚牍、組織所有的測試執(zhí)行活動,安排并監(jiān)督測試執(zhí)行任務;
B向臀、確保選擇合適的測試工具以及測試環(huán)境的建立;
C、確保缺陷分發(fā)給相關(guān)軟件工程師并及時得到解決;
D诸狭、組織測試報告和系統(tǒng)測試預測試報告的寫作;
E券膀、組織測試報告的評審;
F、組織轉(zhuǎn)系統(tǒng)測試評審;
軟件測試工程師
A驯遇、搭建測試環(huán)境;
B芹彬、執(zhí)行測試用例;
C、發(fā)現(xiàn)缺陷后提交缺陷報告;
D叉庐、回歸測試;
E舒帮、每天提交測試日報;
F、測試報告及系統(tǒng)測試預測試報告寫作;
G、參加測試報告的評審
H玩郊、參加賺系統(tǒng)測試評審;
