軟件測試培訓

1、軟件測試培訓,火龍果軟件（www.uml.org.cn）北京：teacher@uml.net.cn上海：shanghai@uml.net.cn深圳：shenzhen@uml.net.cn,培訓列表,軟件測試的目的和策略測試方法學測試的技巧測試工具的選擇軟件開發(fā)中的測試過程實例講解測試活動在軟件工程中的應用,軟件測試的目的和策略,典型測試步驟,1.計劃： 定義目標確定策略確定方法2.執(zhí)行：

2、 建立環(huán)境執(zhí)行計劃3.檢查：一步步驗證執(zhí)行完畢？4.循環(huán)：沒有改正繼續(xù)執(zhí)行,誰參與測試？,用戶方代表軟件最終使用者軟件開發(fā)人員軟件測試人員高層經(jīng)理的支持過程保證人員（SQA）,什么試缺陷？,缺陷：最終產(chǎn)品同用戶的期望不一致缺陷的分類錯誤遺漏超出需求的部分缺陷（未觸發(fā)）VS.錯誤（應首先解決）,測試的商業(yè)意義,降低風險（風險：就是不希望發(fā)生的事情的可能性）測試計劃中必須標明商業(yè)上的風險

3、。測試人員職責：評估商業(yè)上的風險如實的向管理層匯報項目情況,目前公司內測試組織的等級,測試是一件藝術品，很難掌握。測試是一門手藝，精通很困難。測試使用的是已定義好的測試流程，有規(guī)則可尋。測試有較高級的組織形式。世界級的測試組織。,測試的職責,驗證在整個軟件開發(fā)周期中，各個階段的軟件質量是否合格。驗證最終交付給用戶的系統(tǒng)是否滿足用戶的需要，是否符合需求。通過樣本測試數(shù)據(jù)，檢查系統(tǒng)在運行過程中的情況。,對待可能產(chǎn)生的風險的

4、策略,我們無法消除風險，但是我們可以降低在風險發(fā)生時的損失。降低系統(tǒng)風險的最有效的辦法就是對其進行有針對性的測試。,系統(tǒng)風險列舉,如果某部分產(chǎn)生了錯誤會導致的結果？未被驗證的數(shù)據(jù)交換如果被接受如果文件的完整性被破壞系統(tǒng)是否能被安全恢復（完全恢復成備份時的狀態(tài)）是否能暫停系統(tǒng)的運行進行維護工作時，系統(tǒng)性能是否會下降到不能接受的水平。系統(tǒng)的安全性是否有保證,系統(tǒng)風險列舉（繼續(xù)……）,系統(tǒng)的操作流程是否符合用戶的組織策略和長遠規(guī)

5、劃系統(tǒng)是否可靠，穩(wěn)定系統(tǒng)是否易于使用系統(tǒng)是否便于維護是否易于與其它系統(tǒng)相連,測試工作量,太少的測試是不負責任，過多的測試是一種犯罪。100％的測試是不可能的，不同的用戶采用的測試策略是不同的。,缺陷產(chǎn)生的原因,測試原因導致的缺陷：測試目標定義錯誤在開發(fā)生命周期中，錯誤的選擇了測試介入時期選擇了低效的測試技術測試人員專業(yè)知識培訓不夠，工作低效計劃不夠詳細，測試的隨意性很大測試人員同開發(fā)人員溝通困難,續(xù)……,軟件方面

6、使用了不完全的或者不正確的判定標準來設計軟件。錯誤的處理了用戶的非法操作忽略了對關鍵數(shù)據(jù)的輸出檢查數(shù)據(jù)問題出現(xiàn)了不完整的數(shù)據(jù)，不正確的數(shù)據(jù)，過期的數(shù)據(jù),測試效果的好壞是組織級的問題,有效的測試最好由一個獨立的團隊來實施。便于確定工作目標便于人員的培養(yǎng)與升遷利于團隊建設對質量的忠誠度高利于新技術，新方法的產(chǎn)生和推廣工作職責明確,測試規(guī)劃,好的測試不是碰巧發(fā)生的，而是規(guī)劃出來的。時間上人員上環(huán)境上技術上關系上

7、組織能力上資金上,結構化測試方法,傳統(tǒng)的軟件開發(fā)生命周期：需求，設計，編碼，測試，系統(tǒng)維護經(jīng)驗：測試不應該被局限在單一的階段大量的系統(tǒng)問題產(chǎn)生在軟件開發(fā)前期越早進行測試越有效，投入產(chǎn)出比越高,開發(fā)生命周期中的驗證活動,測試策略,在測試策略中必須標明可能存在的風險，這樣在測試后的系統(tǒng)中可以有效的降低被標明的風險發(fā)生的可能性。測試要素：需要被標明的風險也是我們測試的重點。測試階段：在整個開發(fā)生命周期中，測試工作介入的時期。

8、,測試要素,正確性：數(shù)據(jù)輸入，過程處理和輸出的正確性（IPO）。文件完整性：文件被正確使用，恢復和存儲的數(shù)據(jù)正確。授權：特殊的授權可以執(zhí)行一個特殊的操作。進程追蹤：當進程運行中，程序有能力證實進程在正常工作。系統(tǒng)運行的連續(xù)性：當有非致命性問題發(fā)生后，系統(tǒng)有能力繼續(xù)運行關鍵的任務。服務水平：系統(tǒng)有緊急情況發(fā)生時，要求程序的輸出結果不經(jīng)或進行簡單的處理后就可以直接使用。權限控制：防止系統(tǒng)被誤用（意外或者有意的）,測試要素(續(xù)……

9、),一致性：確保最終設計和用戶需求完全一致可靠性：在規(guī)定的時間內都可以正常運轉。易于使用：多數(shù)人均感覺易于使用?？删S護性：可以很容易的定位問題，并且進行修改。可移植性：數(shù)據(jù)或者程序易于移至到其它系統(tǒng)上。耦合性：系統(tǒng)中的組件可以很容易的聯(lián)接。性能：系統(tǒng)資源的占用率，響應時間，并發(fā)處理操作性：易于操作（Operator）,確定測試策略,選擇并確定測試要素的等級多數(shù)情況下選擇3～7個確定開發(fā)階段明確商業(yè)風險開發(fā)人員，重要

10、用戶和測試人員通過評審的方式對這些風險達成一致的意見。把風險列表存放在需求矩陣中矩陣中可以將風險同測試用例對應起來。,測試方法學,測試方法,測試策略測試要素測試階段測試戰(zhàn)略簡要描述如何在以后的測試活動中實現(xiàn)測試策略,確定測試戰(zhàn)略,流水線的概念輸入：標準的入口或者是個可執(zhí)行的程序執(zhí)行過程：按照工作分配執(zhí)行檢查過程：確定輸出符合預定義的標準輸出：符合現(xiàn)存的標準或者是認可的可交付的版本,QC和QA,質量控制驗證產(chǎn)品的正確

11、性，當發(fā)現(xiàn)與設計不一致的時候進行糾正。質量保證充當支持執(zhí)行全面質量管理的角色,測試涉及的定義和概念,缺陷與需求規(guī)格說明書不一致的地方。靜態(tài)檢查確保系統(tǒng)按照組織的標準和過程運行，主要依賴于評審和非運行的手段來檢查。動態(tài)檢查在生命周期中進行測試（運行）,續(xù)……,靜態(tài)測試在不運行程序的情況下檢查程序的運行情況。動態(tài)測試運行程序代碼測試分類單元測試集成測試（組裝測試）系統(tǒng)測試驗收測試回歸測試,續(xù)……,功能測試測

12、試功能需求結構測試驗證系統(tǒng)架構黑盒測試在不了解系統(tǒng)結構的情況下以說明書作為基礎進行測試。白盒測試以系統(tǒng)內部結構和相關知識為基礎進行測試。,為什么缺陷很難被找出？,看不到看到但是抓不到典型的缺陷類型需求解釋有錯誤用戶定義錯了需求需求記錄錯誤設計說明有誤編碼說明有誤程序代碼有誤數(shù)據(jù)輸入有誤測試錯誤問題修改不正確正確的結果是由于其它的缺陷產(chǎn)生的,靜態(tài)測試,需求評審設計評審代碼走查代碼檢查,動態(tài)測試,單

13、元測試集成測試系統(tǒng)測試用戶的驗收測試回歸測試,使用靜態(tài)和動態(tài)測試來進行結構和功能測試,確定測試戰(zhàn)術的八個步驟,確定并且學習測試策略確定項目開發(fā)類型確定軟件系統(tǒng)類型確定項目范圍鑒別戰(zhàn)術風險確定開始測試時會遇到的問題建立系統(tǒng)測試計劃建立單元測試計劃,確定并學習測試策略,在眾多的測試策略中那些是重要的那些風險是最重要的如果軟件不能正常運行時，商業(yè)上會有什么損失如果軟件不能及時完成，商業(yè)上會有什么損失誰是最清楚風險

14、影響的人,確定項目開發(fā)類型,傳統(tǒng)的系統(tǒng)開發(fā)交互式開發(fā)/原型法系統(tǒng)維護購買/簽約/合同軟件項目,確定軟件系統(tǒng)類型,模擬數(shù)據(jù)采集數(shù)據(jù)顯示流程控制決策&輔助協(xié)助圖形&圖象處理數(shù)據(jù)庫管理診斷軟件計算機操作系統(tǒng)傳感器和信號處理軟件開發(fā)工具,確定項目范圍,新系統(tǒng)的開發(fā)會影響那一個商業(yè)領域與現(xiàn)有系統(tǒng)的接口在現(xiàn)有的系統(tǒng)上開發(fā)只是修正Bug？重新設計維護？增加新的功能？對其它系統(tǒng)有無影響？為了減小

15、商業(yè)上的風險？,識別在戰(zhàn)術上的風險,將策略風險分解成戰(zhàn)術風險建立測試計劃，定位這些風險將風險分布于各個階段的測試計劃中戰(zhàn)術風險的種類結構風險技術風險工作量的風險,測試開始時應確定的工作,需求階段確定測試策略確定收集了足夠的需求產(chǎn)生功能性的測試用例設計階段確定設計和需求之間的聯(lián)系確定進行了足夠的設計產(chǎn)生結構和功能的測試用例編碼階段確定和設計之間的聯(lián)系確定擁有執(zhí)行的足夠條件產(chǎn)生結構和功能的測試用例,續(xù)……,

16、測試階段確定設計了足夠的測試用例測試應用系統(tǒng)已經(jīng)完成關鍵資源已經(jīng)到位安裝階段將測試完成的系統(tǒng)變?yōu)楫a(chǎn)品維護階段修改和重新測試,建立計劃,建立系統(tǒng)測試計劃建立單元測試計劃在測試戰(zhàn)術上我們要花多長時間？“如果計劃作失敗了，那就在計劃失敗”時間花在計劃上要比花在重復的測試上有效,測試的技巧,測試技巧分類,結構測試相對于功能測試動態(tài)測試相對于靜態(tài)測試手工測試相對于自動測試,結構測試技巧,壓力測試執(zhí)行測試恢復測試操

17、作測試復合性測試（與過程的復合性)安全測試,壓力測試,目標模擬出實際用戶環(huán)境怎么用產(chǎn)生測試數(shù)據(jù)測試組模擬用戶處理被創(chuàng)建的數(shù)據(jù)例子確定是否分配了足夠的磁盤空間通訊的容量是否足夠測試系統(tǒng)過載的情況什么時間使用當關于容量的信息不確定的時候,性能測試技巧,目標確定系統(tǒng)達到了希望達到的性能水平如何使用使用軟件和硬件的監(jiān)視器使用模擬的監(jiān)控模型，對關心的性能指標進行監(jiān)控創(chuàng)建一個小程序例子計算通信的時間單位時間

18、處理的信息量什么時候使用－ 在程序開發(fā)的早期進行,恢復測試,目標當在進行安裝或組裝操作過程中，文件丟失時或發(fā)生意外后系統(tǒng)有能力重新進行操作如何使用程序的安裝，運行方式，工具的使用和關鍵技術經(jīng)過足夠的評估系統(tǒng)開發(fā)完畢后，介紹一下發(fā)生失敗后的處理過程例子人為的使一個系統(tǒng)在安裝或者組裝過程中產(chǎn)生錯誤什么時間去使用當操作的連續(xù)性是個重點的時候,操作測試,目標確定計算機的操作文檔已經(jīng)完整如何使用作為計算機正常操作的一部分

19、來執(zhí)行測試例子操作的介紹被文檔化，操作者被培訓什么時候使用預先將程序進行產(chǎn)品化。操作性是系統(tǒng)的一個重要指標的時候。,復合性測試,目標校驗程序的開發(fā)是否依照已定義的標準，流程和操作方式進行的。如何去使用將文檔/程序同標準相比較比較有效的方法是檢查過程例子代碼互查（一行一行）什么時候使用依賴于管理的需要,安全性測試,目標安全性的缺陷很難被發(fā)現(xiàn)。大多數(shù)的情況下組織能夠防止一般性的破壞者。如何使用對安全性的需求進

20、行評審分析與安全性有關的處理流程轉包給專業(yè)的人員例子定義了被保護的資源，權限進行了控制，日志文件和審查追蹤是可用的。什么時間使用當被保護的資源對于組織具有重要的價值的時候,功能測試技巧,需求測試回歸測試錯誤處理測試支持手冊的測試系統(tǒng)兼容測試控制性測試并行測試,需求測試,目標用戶的需求可以被實現(xiàn)如何使用創(chuàng)建測試用例和功能檢查列表例子建立測試矩陣去證實系統(tǒng)需求均被文檔化什么時候使用每一個應用程序都要進行

21、需求測試,回歸測試,目標程序修改后，確保功能的正確性如何使用重新測試應用程序中沒有改變的部分例子重新執(zhí)行以前的測試用例什么時間使用當新的程序有可能影響老的功能的時候,錯誤處理測試,目標所有可能的錯誤條件均經(jīng)過了驗證如何使用一組有經(jīng)驗的人員預測在那里會出現(xiàn)問題例子建立一個錯誤處理的列表什么時候使用貫穿整個開發(fā)生命周期,支持手冊測試,目標檢驗操作過程被文檔化了，并且完整了。如何使用對過程有足夠的介紹可以協(xié)

22、助用戶正常使用例子系統(tǒng)在一定的條件下產(chǎn)生一個提示，用戶被告知如何采取必要的操作。什么時候使用最佳時機是在安裝測試的時候，但是應該在開發(fā)全過程中。,兼容性測試,目標檢驗當使用適當?shù)膮?shù)和數(shù)據(jù)時，需要的信息可以在兩個系統(tǒng)中正確的交換如何使用文件和數(shù)據(jù)被用來在多系統(tǒng)之間傳遞。例子典型的由一個系統(tǒng)到另一個系統(tǒng)的數(shù)據(jù)交換程序。什么時候使用當兩個應用程序之間的參數(shù)有可能發(fā)生變化的時候,管理能力測試,目標驗證數(shù)據(jù)交換時有足夠的

23、審計追蹤能力如何使用關鍵數(shù)據(jù)或者有價值的數(shù)據(jù)例子從負面來看程序，是否確保了會出錯的條件都被保護了。什么時候使用系統(tǒng)測試的一部分,并行測試,目的新版本和老版本同時運行，用以確保新版本的程序運行正確。如何使用需要對兩個系統(tǒng)輸入相同的數(shù)據(jù)來運行例子運行新舊兩個工資支付系統(tǒng)什么時間使用當對新系統(tǒng)的的運行情況不確定的時候,單元測試,關注單元一級代碼分析和測試功能分析和測試結構分析和測試以錯誤為導向的分析和測試,測

24、試要素/測試技巧矩陣,繼續(xù)……,測試工具的選擇,測試工具,測試標準邊界值分析因果圖檢查表代碼比較對照以編譯為基礎的分析確認/檢查控制流分析,測試工具(繼續(xù)……),能證明正確性的數(shù)據(jù)以覆蓋為基礎的測試數(shù)據(jù)字典數(shù)據(jù)流分析以設計為基礎的功能測試設計評審桌面檢查災難性測試,測試工具(繼續(xù)……),錯誤猜測執(zhí)行的規(guī)則全面的測試實況調查流程圖檢查,視察使用儀器設備綜合測試設備映射圖,測試工具(繼續(xù)……),建

25、模并行操作并行模擬代碼互查風險矩陣系統(tǒng)控制的評審得分快照(把系統(tǒng)一個時刻的情況保存下來),測試工具(繼續(xù)……),完成特征系統(tǒng)日志測試用例測試用例的產(chǎn)生形式跟蹤工具程序容量的測試走查(講解開發(fā)思路),選擇和使用測試工具,按照用途選擇匹配的工具在適當?shù)纳芷谶x擇工具按照測試人員的實際技能選擇匹配的工具選擇一個可提供的工具,測試工具/測試技巧矩陣,測試工具/測試技巧矩陣(繼續(xù)),測試工具/測試技巧矩陣(繼續(xù)

26、),測試工具/測試技巧矩陣(繼續(xù)),測試工具/測試技巧矩陣(繼續(xù)),軟件開發(fā)生命周期/測試工具對照表,軟件開發(fā)生命周期/測試工具對照表( 繼續(xù)）,軟件開發(fā)生命周期/測試工具對照表( 繼續(xù)）,軟件開發(fā)生命周期/測試工具對照表( 繼續(xù)）,測試工具管理,工具管理者的職責對工具負責幫助同事使用這些工具培訓工具得使用方法負責同工具的廠家聯(lián)系每年給出有關工具使用和購買得計劃工具得升級工具情況報告工具管理者得任期不易太長,軟件的測試過

27、程,軟件的測試過程,估算測試計劃需求設計編碼測試總結安裝，交付維護,估算,估算什么,測試對軟件工作量的估算的準確性測試評估軟件系統(tǒng)的狀況的準確性關注點：不準確的估算不適當?shù)拈_發(fā)過程不真實的狀態(tài)報告,對工作量的估算,如何知道對工作量的估算是正確的估算工作量的工具很容易出錯對軟件工作量的估算需要策略五個一般的方法猜加入一些約束條件以一些數(shù)據(jù)為基礎模擬進行工作將一些參數(shù)模型化,參數(shù)模型法,回歸模型：將現(xiàn)

28、有的參數(shù)與已有的歷史數(shù)據(jù)相擬和。啟發(fā)式模型：對歷史數(shù)據(jù)進行觀察和解釋現(xiàn)象模型：假設軟件開發(fā)過程可以依據(jù)一些更廣泛的可適用的過程解釋。,模型遵循的共同模式,估算軟件的大小將大小轉化成人力的估算，并且作出可能的成本的估算依據(jù)項目的特性進行估算的調整將整體的估算劃分到不同的項目階段中估算不包括技巧上面的人力和計算機的運行時間將以上內容相加,對估算進行檢驗,檢驗估算模型的合理性檢驗模型是否包含了必須的測試要素檢驗模型的正確性,

29、校驗估算模型的正確性,重新進行估算校驗輸入是否正確校驗輸入是否合理校驗對數(shù)據(jù)的計算是否合理有效比較延期的估算是否符合項目實際情況讓謹慎的人來作測試驗證工作對軟件中的冗余價值估算,影響估算正確與否的因素,軟件規(guī)模新設計新代碼的比例復雜程度設計和編碼的困難使用什么語言安全性需求的揮發(fā)性,續(xù)……,組織因素項目計劃人員開發(fā)環(huán)境計算機資源人員利用率膨脹因素估算就是估算，不是保證書,軟件進展測試,追蹤系統(tǒng)的瓶頸

30、工作完成點同配置管理系統(tǒng)緊密的結合如何使用模塊列表里程碑工作完成點用計算所有工作的完成度來檢查系統(tǒng)工作過程。,測試計劃,開發(fā)測試計劃,目標詳細的描述怎樣能成功的完成測試工作，其中應包含必須的資源和實施計劃?？赡艿牟焕蛩兀簺]有得到足夠的培訓心里準備不足缺乏測試工具缺乏管理的標準和支持缺乏客戶和最終使用者的參與沒有足夠的時間進行測試對于獨立的測試人員過度信任版本改變的太快測試人員處于不受重視的情況中不

31、能說不,實施過程,聽取各方面的意見和建議標明項目風險測試要素聯(lián)系測試矩陣建立測試計劃對計劃進行評審,建立測試計劃,定義測試目標開發(fā)測試矩陣軟件模型結構特性批量測試的階段和用例為在線系統(tǒng)作概念上的測試腳本軟件測試矩陣定義測試管理測試計劃的一般性信息定義測試里程碑定義管理上的檢查點書寫測試計劃,評審測試計劃,涉及評審的問題評審測試的開始時間是否會延期有沒有抵觸評審的角色一段時間內是否很難得到工作的檢查信

32、息。更換工具有可能導致他們反感評審工作評審結果可能會影響對個人的工作評價對于最終成品的檢查項目的需求規(guī)格說明書軟件返工/維護的文檔升級后的技術文檔被更改的源程序測試計劃用戶手冊（包括在線幫助）,續(xù)……,正式評審中的角色緩和劑（SQA）讀者記錄者作者檢測員正式評審發(fā)現(xiàn)的缺陷應包含的信息起因類型分類級別,評審流程,計劃和組織通篇的講解（可選）個人準備評審會議修訂和反復,需求階段的測試,測試成本,

33、在軟件開發(fā)的所有階段進行測試被設計用來減少測試成本IBM的數(shù)據(jù)大約 60個缺陷/千行2/3的缺陷產(chǎn)生在需求和設計階段在需求和設計階段發(fā)現(xiàn)的缺陷修正的花費最小修正系統(tǒng)測試階段發(fā)現(xiàn)的缺陷，花費是以上的10倍發(fā)布產(chǎn)品以后，修正缺陷的花費是原來的100倍,生命周期的測試概念,在軟件開發(fā)過程中持續(xù)的進行測試在盡可能早的階段點去修正缺陷需要正式的開發(fā)流程來支持組建測試團隊當開發(fā)開始進行的時候，測試就開始進行了,需求階段的測試,

34、準備風險列表確定風險組確定風險風險分析風險檢查表建立控制目標確定有足夠的控制力度,分析測試要素,需求的設計是否遵循了已定義的方法提交了已定義的功能說明定義了系統(tǒng)界面已經(jīng)估計了性能標準容忍度被預先估計預先定義了權限規(guī)則需求中預先定義了文件完整性預先定義了需求的變更流程預先定義了失敗的影響權限定義,需求走查,建立基本規(guī)則選擇小組/通報參與者項目介紹問題/建議形成最終報告,需求階段測試,所有的花費都是值得

35、的大部分缺陷將不會進入到設計&編碼階段目標需求正確的表現(xiàn)出了用戶的需要需求已經(jīng)被定義和文檔化了花費和收益成正比需求的控制被明確有合理的流程可遵循有合理的方法可供選擇,設計階段的測試,設計階段的測試,交付的產(chǎn)品輸入說明過程說明文件說明輸出說明控制說明系統(tǒng)流程圖硬件和軟件的需求操作手冊說明書數(shù)據(jù)保留的策略,設計階段測試任務,給測試要素打分分析測試要素對設計進行評審檢查修改的部分,分析測試要素,

36、測試涉及的內容：設計了對數(shù)據(jù)完整性的控制設計了權限規(guī)則設計了對文件完整性的控制設計了審計追蹤設計了發(fā)生意外情況時的計劃設計了如何達到服務水平的方法定義了權限流程定義了完整的方法學設計了保證需求一致性的方法進行了易用性的設計設計是可維護的設計是簡單的交互界面設計完畢定義了成功的標準需要同實際操作者溝通,對設計進行評審,選擇評審組成員對評審組進行培訓通報項目組分配足夠的時間只對文檔化的事實進行評審和項

37、目組一起進行評審對評審形成建議和項目組對建議一起進行評審準備正式的報告,編碼階段的測試,形成的輸出,編碼說明書程序文檔計算機程序列表可執(zhí)行的程序程序流程圖操作介紹單元測試結果,測試活動的關注點,完成對數(shù)據(jù)完整性的控制定義完畢授權的規(guī)則完成對文件完整性的控制實現(xiàn)審計追蹤規(guī)劃出意外情況發(fā)生后的處理計劃對系統(tǒng)如何達到預定義的服務水平做了計劃完成了對安全問題的處理流程編碼工作是依據(jù)規(guī)定的方法完成的編碼與設計相一

38、致（正確性）編碼與設計相一致（易用性）代碼是可維護的編碼與設計相一致（簡潔性）編碼與設計相一致（耦合性）已開發(fā)了操作流程定義出程序成功的標準（性能上）,測試的職責,編碼是一個純技術的工作，幾乎不需要用戶的參與項目領導者有參與測試的責任監(jiān)督過程的有效性,建議的測試方式,桌面調試語法上的結構上的功能上的代碼互查建立基本的互查規(guī)則選擇互查的team對成員進行培訓選擇互查的方法提供互查的材料流程圖，源程序，典

39、型的處理流程對互查進行必要的管理給出互查結論提供最終的報告,編碼階段的測試需解決的問題,系統(tǒng)是可維護的嗎？系統(tǒng)說明是否已經(jīng)完成了？編碼是否按照既有的標準進行，過程是否易于實踐？是否有足夠的測試計劃用來評估可執(zhí)行的程序？是否編制了足夠的文檔。,測試關注點,在需求，設計，編碼階段多進行一些測試，在系統(tǒng)測試階段就會少一些問題。文檔測試階段的測試計劃測試用例前期測試的測試結果第三方測試反饋，例如：計算機操作人員正式的測

40、試總結報告,典型測試類型,手冊，回歸，功能點測試一致性測試（授權）功能點測試（完整性）功能點測試（審計，追蹤）覆蓋性的測試（測試的連續(xù)性）壓力測試（服務水平）一致性測試（安全性）依照預先定義的測試方法功能點測試（正確性）支持手冊的測試（易用性）檢查（可維護性）災難性的測試（可攜帶性）功能和回歸測試（耦合性）一致性的測試（性能）操作性的測試（易用性）,建議測試方法,測試方法測試用例的概念是簡單的建立有效的測

41、試用例是復雜的設計測試文件測試用例應當包含合法的和非法的輸入每一個動作只進行一次關鍵操作輸入測試數(shù)據(jù)分析結果嘗試將測試文件違反程序的規(guī)則進行輸入容量測試的測試工具以大信息量的數(shù)據(jù)進行輸入這是一個昂貴的測試，應根據(jù)需要來選擇在線系統(tǒng)需要做壓力測試,測試總結,測試報告,目標表示出目前項目的實際狀況明確什么是測試做的工作，什么是不作的工作。給出系統(tǒng)的操作性能的評價明確什么時候系統(tǒng)可以進行產(chǎn)品化的工作關注點測試報

42、告只有真正需要的時候才有用，需要配合市場和管理測試的信息是不充分的（對于評價一個項目來說）測試狀況并不能真實的反應個人的狀況,測試期間數(shù)據(jù)的收集,有關測試結果的積累數(shù)據(jù)測試任務，測試集合和測試事件的描述缺陷分析由于計劃的問題，導致沒有發(fā)現(xiàn)的缺陷的數(shù)據(jù)嚴重的缺陷缺陷類型為什么缺陷沒有發(fā)現(xiàn)效果,測試報告,報告目前的軟件狀態(tài)功能/測試矩陣功能測試的狀態(tài)報告，側重點分析關于功能的工作時間軸期望發(fā)現(xiàn) VS 實際發(fā)現(xiàn)的缺陷

43、比沒有發(fā)現(xiàn)的缺陷和改正的缺陷的差距按照類型分類，沒有改正的缺陷的平均值缺陷分類報告測試活動報告,最終的報告匯總,各個階段的項目測試總結報告繼承性測試報告系統(tǒng)測試報告確認測試報告,安裝測試,安裝階段的測試準備,安裝計劃安裝流程圖安裝文件和程序清單測試安裝程序給出測試結果將程序運行的軟硬件要求放入產(chǎn)品說明中對于新操作人員的使用說明書對于新使用者的操作說明和操作流程安裝過程中的各項可能發(fā)生的結果的說明,測試關注點,

44、對程序安裝的正確性和完整性進行核對校驗產(chǎn)品文件的完整性安裝的審查，追蹤被記錄安裝之前，該系統(tǒng)已經(jīng)被證實沒有問題如果安裝失敗，系統(tǒng)有相應的解決方案安裝過程，進行了權限控制（安全性）安裝遵循一定的方法，步驟需要的配套程序和數(shù)據(jù)已經(jīng)放進了產(chǎn)品中已交付使用說明相關文件已經(jīng)完整(可維護性）接口已經(jīng)被合理調整（耦合性）綜合的性能達到了用戶要求,建議測試工具,測試工具檢查表選擇測試的范圍選擇檢查表明白這些問題的用意提前測

45、試用戶的檢查表使用該檢查表模擬運行一遍自己向自己匯報一次將有用的信息記錄下來評估檢查表和檢查流程,續(xù)……,測試標準數(shù)據(jù)的正確性將程序產(chǎn)品化向操作者和用戶進行講解校驗檢查表和產(chǎn)品的正確性使用測試標準去檢驗發(fā)生的問題,驗收測試,軟件驗收流程,定義用戶角色定義驗收標準編制驗收計劃執(zhí)行驗收計劃填寫驗收結論,定義用戶角色,確定最終用戶的范圍確認臨時的和最終產(chǎn)品的驗收標準計劃每一個驗收過程由誰和如何執(zhí)行計劃資源分配

46、計劃時間分配準備驗收計劃為每一項驗收工作給出結論,確定驗收標準,功能上性能上接口質量上過載后的軟件質量安全性軟件的穩(wěn)定性,編寫驗收計劃,項目描述用戶職責行政上的流程驗收活動描述每一個驗收項的評審最終的驗收測試步驟,執(zhí)行和結論,執(zhí)行驗收計劃驗收測試和評審進行管理驗收的結果典型的驗收結果在進入下一個活動之前問題或者變更必須被接受工作可以繼續(xù)，但是下次評審之前必須更正沒有任何的更改,維護階段,工作重點和目標

47、,兩個重要的工作：測試和培訓目標：開發(fā)一些測試用例，預先發(fā)現(xiàn)一些問題在運行情況發(fā)生變化后，預先的修正一些錯誤編寫必要的培訓材料對有關的人員進行培訓同用戶進行接觸,開發(fā)更新測試計劃,測試計劃要簡短，必須在短時間內完成。只測試變化的部分兩點：測試什么，如何測試測試要素變化的數(shù)據(jù)交換變化的程序操作流程用戶的操作習慣不同系統(tǒng)之間的互聯(lián)語言版本安全性備份/恢復,編制培訓計劃,對系統(tǒng)進行概覽對系統(tǒng)假定一些錯誤，給

48、出處理方法培訓材料對項目內容的陳述用戶使用方法對錯誤列表上的問題給出解釋對報告進行解釋，并且說明如何使用他們（圖標，數(shù)據(jù)等）對輸入數(shù)據(jù)進行解釋,反饋,反饋包括：用戶反饋和測試反饋，又分成錯誤和建議。沒有反饋意見，程序很難提高反饋的類型測試的數(shù)量和內容發(fā)現(xiàn)的問題數(shù)量和分類區(qū)分是技術上的還是應用上的問題將反饋信息重新整理，加入到相關的測試數(shù)據(jù)中,實例講解測試活動在軟件工程中的應用,活動階段分類,需求階段設計階段編