測試執(zhí)行與缺陷報告跟蹤

1、第十三章測試執(zhí)行與缺點匯報、跟蹤1/49目 錄 軟件測試執(zhí)行與跟蹤 1 軟件缺點描述2 軟件缺點相關信息3 軟件缺點跟蹤和分析4 軟件缺點跟蹤系統(tǒng)52/491軟件測試執(zhí)行與跟蹤 3/491.軟件測試過程關鍵點不一樣測試階段執(zhí)行關鍵點測試用例執(zhí)行團體建設與溝通測試執(zhí)行結束 4/491.軟件測試過程關鍵點測試執(zhí)行實踐過程執(zhí)行前開一個動員會，嚴格審查測試環(huán)境抽查性質探索式測試，驗證高風險區(qū)域測試質量交叉交換測試人員所測試模塊，能夠發(fā)揮互補作用良好溝通，如每七天例會，以及和開發(fā)人員及時溝通測試時間被壓縮 測試策略優(yōu)化、計劃調(diào)整 測試需求優(yōu)先級、調(diào)整測試范圍常規(guī)缺點審查，及時發(fā)覺問題、糾正問題，使整個測

2、試進程在控制軌道上發(fā)展。階段性結果分析，確保階段性測試任務得到完整執(zhí)行并到達預定目標。5/492.測試項目進度管理方法 測試項目里程碑任 務天任 務天任 務天任 務天M21: 測試計劃制訂11M23: 測試設計12開發(fā)測試過程5驗證測試結果2確定項目1測試用例設計7測試和調(diào)試測試過程2調(diào)查突發(fā)結果1定義測試策略2測試用例審查2修改測試過程2生成缺點日志1分析測試需求3測試工具選擇1建立外部數(shù)據(jù)集1M62: 測試評定3估算測試工作量1測試環(huán)境設計2重新測試并調(diào)試測試過程2評定測試需求覆蓋率1確定測試資源1M26: 測試開發(fā)15M42:功效測試9評定缺點0.5建立測試結構組織1建立測試開發(fā)環(huán)境1設

3、置測試系統(tǒng)1決定是否抵達測試完成標準0.5生成測試計劃文檔2錄制和回放原型過程2執(zhí)行測試4測試匯報16/492.測試項目進度管理方法 進度與質量關系 進度與成本關系 7/492.測試項目進度管理方法 測試進度 S曲線法 進度S曲線法經(jīng)過對計劃中、嘗試與實際進度三者對比來實現(xiàn)，其采取基本數(shù)據(jù)主要是測試用例或測試點數(shù)量 8/492.測試項目進度管理方法 測試進度NOB曲線法在整個測試期間主要搜集當前全部打開缺點數(shù)量，也能夠將嚴重級別缺點分離出來進行控制，從而形成NOB曲線，在一定程序上反應了軟件質量和測試進度時間發(fā)展趨勢9/492.測試項目進度管理方法 10/493.測試過程管理工具 商業(yè)性工具：

4、HP ALM，IBM Rational Test Manager和Team Test，Compuware QADirector、Borland SilkCentral Test Manager和Microsoft Visual Studio Team System等開源工具：TestLink、Bugzilla Test Runner、驗收測試管理工具FitNesse、基于XML文件測試用例管理工具JtestCas、Eclipse測試和性能工具平臺（Test & Performance Tools Platform，TPTP）。除此之外，還有其它一些測試管理框架，如TestMaker、Salom

5、eTMF、JTR （Java Test Runner）、Jetif、Marathon、Grinder、TESTARE等11/492軟件缺點描述12/491.軟件缺點生命周期軟件缺點生命周期指是一個軟件缺點被發(fā)覺、匯報到這個缺點被修復、驗證直至最終關閉完整過程缺點生命周期是各類開發(fā)人員一起參加、協(xié)同測試過程。軟件缺點一旦發(fā)覺，便進入嚴密監(jiān)控之中，直至軟件缺點生命周期終止，這么即可確保在較短時間內(nèi)高效率地關閉全部缺點，縮短軟件測試進程，提升軟件質量，同時降低開發(fā)、測試和維護成本。 13/491.軟件缺點生命周期基本缺點生命周期發(fā)覺-打開：測試人員找到軟件缺點并將軟件缺點提交給開發(fā)人員。 打開-修復

6、：開發(fā)人員再現(xiàn)、修復缺點，然后提交給測試人員去驗證。 修復-關閉：測試人員驗證修復過軟件，關閉已不存在缺點。 發(fā)覺 打開 修復 關閉 14/491.軟件缺點生命周期實際缺點生命周期創(chuàng)建激活狀態(tài)Send email to DEV是否清楚、可再現(xiàn)？已處理狀態(tài)已修正狀態(tài)Send email to QA不能再現(xiàn)缺乏信息缺點評審關閉狀態(tài)延期增強設計無法處理需要處理驗證是否經(jīng)過Unit test, code reviewCheck in CVSNoNoYesYes15/492.嚴重性和優(yōu)先級嚴重性（severity）衡量缺點對客戶滿意度影響程度致命（fatal）、嚴重（critical）、普通（major

7、）、微小（minor）優(yōu)先級(Priority)：指缺點被修復緊急程度。缺點優(yōu)先級 描述 馬上處理(P1級) 缺點造成系統(tǒng)幾乎不能使用或測試不能繼續(xù)，需馬上修復 高優(yōu)先級(P2級） 缺點嚴重，影響測試，需要優(yōu)先考慮 正常排隊(P3級） 缺點需要正常排隊等候修復 低優(yōu)先級(P4級） 缺點能夠在開發(fā)人員有時間時候被糾正。 16/493.缺點其它屬性缺點標識（ID）缺點類型（type），如功效、UI、性能、文檔缺點產(chǎn)生可能性（frequency）/可再現(xiàn)概率缺點起源（source）：需求、設計、編碼缺點原因（cause）：數(shù)據(jù)格式、計算錯誤、接口參數(shù)、變量定義與引用等見 P.327328 諸表17/

8、494.完整缺點信息見 P.328 表15-7ID標題前提環(huán)境操作步驟期望結果實際結果頻率嚴重程度優(yōu)先級類型缺點提交人缺點指定處理人起源產(chǎn)生原因構建包跟蹤版本跟蹤提交時間修正時間驗證時間所屬項目/模塊產(chǎn)品信息狀態(tài)18/494.完整缺點信息“步驟”提供了怎樣重復當前缺點準確描述，應簡明而完備、清楚而準確。這些信息對開發(fā)人員是關鍵，視為修復缺點向導 “期望結果”與測試用例標準或設計規(guī)格說明書或用戶需求等一致，到達軟件預期功效。是驗證缺點依據(jù)。 “實際結果”實際執(zhí)行測試結果，不一樣于期望結果，從而確認缺點存在 19/495.缺點描述基本要求單一準確 能夠再現(xiàn) 完整統(tǒng)一短小簡練特定條件補充完善 不做評

9、價 20/496.軟件缺點匯報 任何一個缺點跟蹤系統(tǒng)關鍵都是“軟件缺點匯報”，一份軟件缺點匯報詳細信息如表：分類 項目 描述 可跟蹤信息 缺點ID 唯一、自動產(chǎn)生缺點ID，用于識別、跟蹤、查詢 軟件缺點基本信息 缺點狀態(tài) 可分為“打開或激活”、“已修正”、“關閉”等 缺點標題 描述缺點最主要信息 缺點嚴重程度 普通分為“致命”、“嚴重”、“普通”、“較小”等四種程度 缺點優(yōu)先級 描述處理缺點緊急程度， 1是優(yōu)先級最高等級，2是正常，3是優(yōu)先級最低 缺點產(chǎn)生頻率 描述缺點發(fā)生可能性1%-100% 缺點提交人 缺點提交人名字（會和郵件地址聯(lián)絡起來），普通就是發(fā)覺缺點測試人員或其它人員 缺點提交時間

10、 缺點提交時間 21/496.軟件缺點匯報 軟件缺點基本信息 缺點所屬項目/模塊 缺點所屬項目和模塊，最好能較準確定位至模塊 缺點指定處理人 預計修復這個缺點開發(fā)人員，在缺點狀態(tài)下由開發(fā)組長指定相關開發(fā)人員；也會自動和該開發(fā)人員郵件地址聯(lián)絡起來，并自動發(fā)出郵件 缺點指定處理時間 開發(fā)管理員指定開發(fā)人員修改此缺點時間 缺點驗證人 驗證缺點是否真正被修復測試人員；也會和郵件地址聯(lián)絡起來 缺點驗證結果描述 對驗證結果描述（經(jīng)過、不經(jīng)過） 缺點驗證時間 對缺點驗證時間 缺點詳細描述 步驟 對缺點操作過程，按照步驟，一步一步地描述 期望結果 按照設計規(guī)格說明書或用戶需求，在上述步驟之后，所期望結果，即正

11、確結果 實際發(fā)生結果 程序或系統(tǒng)實際發(fā)生結果，即錯誤結果 測試環(huán)境說明測試環(huán)境 對測試環(huán)境描述，包含操作系統(tǒng)、瀏覽器、網(wǎng)絡帶寬、通訊協(xié)議等 必要附件 圖片、Log文件 對于一些文字極難表示清楚缺點，使用圖片等附件是必要；對于軟件瓦解現(xiàn)象，需要使用Soft_ICE工具去捕捉日志文件作為附件提供給開發(fā)人員。 22/496.軟件缺點匯報 示例優(yōu)異缺點匯報重現(xiàn)步驟 :打開一個編輯文字軟件而且創(chuàng)建一個新文檔（這個文件能夠錄入文字）在這個文件里隨意錄入一兩行文字 選中一兩行文字，經(jīng)過選擇Font 菜單然后選擇Arial字體格式 一兩行文字變成了無意義亂字符 期望結果：當用戶選擇已錄入文字并改變文字格式時候

12、，文本應該顯示正確文字格式不會出現(xiàn)亂字符顯示。實際結果:它是字體格式問題，假如改變文字格式成Arial之前，你保留文件，缺點不會出現(xiàn)。缺點僅僅發(fā)生在Windows98而且改變文字格式成其它字體格式，文字是顯示正常。 見所附圖片 23/496.軟件缺點匯報 散漫缺點匯報重現(xiàn)步驟：在Window98上打開一個編輯文字軟件而且編輯存在文件 文件字體顯示正常 我添加了圖片，這些圖片顯示正常 在此之后，我創(chuàng)建了一個新文檔 在這個文檔中我隨意錄入了大量文字 在我錄入這些文字之后，選擇幾行文字.而且經(jīng)過選擇Font 菜單然后選擇Arial字體格式改變文字字體。 有三次我重現(xiàn)了這個缺點 我在Solaris操作

13、系統(tǒng)運行這些步驟，沒有任何問題。 我在Mac操作系統(tǒng)運行這些步驟，沒有任何問題。期望結果：當用戶選擇已錄入文字并改變文字格式時候，文本應該顯示正確文字格式不會出現(xiàn)亂字符顯示。 實際結果：我試著選擇少許不一樣字體格式，不過只有Arial字體格式有軟件缺點，不論怎樣，它可能會出現(xiàn)在我沒有測試其它字體格式 24/493軟件缺點相關信息25/491.軟件缺點圖片信息軟件缺點相關信息包含軟件缺點圖片、統(tǒng)計信息和怎樣再現(xiàn)和分離軟件缺點，使開發(fā)人員和其它測試人員更輕易分離和重現(xiàn)它。一些包括用戶界面(User Interface)軟件缺點可能極難用文字清楚地描述，所以軟件測試人員經(jīng)過附上圖片比較直觀地表示缺點

14、發(fā)生在產(chǎn)品界面什么位置、有什么問題等。 26/492.使用WinDBG統(tǒng)計軟件缺點信息WinDbg是微軟公布源碼級調(diào)試工具，用于Kernel模式調(diào)試和用戶模式調(diào)試，可用于調(diào)試軟件瓦解后形成Dump文件，包含操作系統(tǒng)信息、進程運行狀態(tài)、時間和環(huán)境變量、匯編指令、調(diào)用堆棧等安裝、使用詳細操作方法，如提供了圖形界面和命令行兩種運行方式調(diào)試方式：遠程調(diào)試、Dump調(diào)試、當?shù)剡M程調(diào)試windbg remote npipe:server=SERVER_NAME,pipe=PIPE_NAMEwindbg z DUMP_FILE_NAME Windbg p “process id”慣用命令 P30327/49

15、3.使用Soft-ICE統(tǒng)計軟件缺點信息Soft-ICE是 Compuware企業(yè)產(chǎn)品NuMega DriverStudio中一個代表性工具，用于跟蹤軟件運行時變量、內(nèi)存等狀態(tài)，而且能夠捕捉系統(tǒng)瓦解時狀態(tài)。使用它能夠統(tǒng)計產(chǎn)品發(fā)生缺點地方，同時生成日志文件。 28/493.使用Soft-ICE統(tǒng)計軟件缺點信息怎樣使用Soft-ICE在開始測試之前，已經(jīng)安裝了Soft-ICE并開啟了“faults on”命令。當軟件發(fā)生瓦解現(xiàn)象時，能夠使用下面命令去捕捉必要信息：stack u eip-80 假如數(shù)據(jù)窗口是開啟狀態(tài)，能夠輸入”wd”來關閉該窗口，然后再輸入 “dd esp-20”命令。stack

16、、dd esp-20是為了標注跟蹤信息。經(jīng)過輸入x，退出 Soft-ICE窗口；假如還是無法退出Soft-ICE，需要輸入faults off，然后輸入x。 打開Soft-ICE應用程序，馬上保留日志文件。一旦再次打開Soft-ICE，請輸入faults on 29/494.分離和再現(xiàn)軟件缺點 確保全部步驟都被統(tǒng)計。特定條件和時間。壓力和負荷、內(nèi)存和數(shù)據(jù)溢出相關邊界條件?？紤]資源依賴性包含內(nèi)存、網(wǎng)絡和硬件共享相互作用等。 不能忽略硬件。與軟件不一樣，硬件不按預定方式工作。 和開發(fā)人員緊密合作30/494.分離和再現(xiàn)軟件缺點 分離和調(diào)試軟件缺點之間區(qū)分 再現(xiàn)軟件缺點現(xiàn)象所需最少步驟有哪些？這些步

17、驟成功再現(xiàn)可能性多大？ 軟件缺點是否成立存在？換句話說，測試結果是否可能起源于測試原因或者測試人員本身錯誤，還是影響用戶需求、系統(tǒng)真正故障？哪些外部原因產(chǎn)生軟件缺點？ 哪些內(nèi)部原因，是代碼、網(wǎng)絡、還是環(huán)境引發(fā)軟件缺點？ 怎樣才能在不產(chǎn)生新缺點條件下使這個軟件缺點得到修復？ 這種修復是否經(jīng)過調(diào)試，單元是否經(jīng)過測試？ 問題處理了嗎？它是否經(jīng)過了確認和回歸測試，確定系統(tǒng)其余部分仍工作正常？ 31/494軟件缺點跟蹤和分析32/491.軟件缺點處理和跟蹤 對缺點跟蹤管理，普通而言需要到達以下目標：確保每個被發(fā)覺缺點都能夠被處理，“處理”意思不一定是被修正，也可能是其它處理方式（比如，延遲到下一個版本中

18、修正或者因為技術原因不能被修正），總之，對每個被發(fā)覺BUG處理方式必須能夠在開發(fā)組織中到達一致；搜集缺點數(shù)據(jù)并依據(jù)缺點趨勢曲線識別測試處于測試過程中哪個階段； 決定測試過程是否結束，經(jīng)過缺點趨勢曲線來確定測試過程是否結束是慣用而且較為有效一個方式。搜集缺點數(shù)據(jù)并在其上進行數(shù)據(jù)分析，作為組織過程改進財富。 33/492.軟件缺點處理技巧 審閱。能夠由測試管理員、項目管理員或其它人來進行，審閱缺點匯報質量水平；拒絕。假如審閱者決定需要對一份缺點匯報進行重大修改，應該和測試人員一起討論，由測試人員糾正缺點匯報，然后再次提交； 完善。完整地描述了問題特征并將其分離，那么審查者就會必定這個匯報； 分配。

19、分配給適當開發(fā)人員，假如不知道詳細開發(fā)人員，應分配給項目開發(fā)組長，由開發(fā)組長再分配給對應開發(fā)人員； 34/492.軟件缺點處理技巧 驗證。缺點修復需要得到測試人員驗證，同時還要進行回歸測試，檢驗這個缺點修復是否會引入新問題； 重新打開。重新打開一個缺點，需要加注釋說明、電話溝通等，不然會引發(fā)“打開-修復”多個往返，造成測試人員和開發(fā)人員無須要矛盾 關閉。只有測試人員相關閉缺點權限，開發(fā)人員沒有這個權限。 暫緩。假如每個人都同意將確實存在缺點移到以后處理，應該指定下一個版本號或修改日期。一旦新版本開始時，這些暫緩缺點應該重新被打開。35/493.缺點趨勢分析軟件項目怎樣發(fā)展：軟件缺點打開/關閉圖

20、表產(chǎn)品開發(fā)質量情況取決于累積打開/關閉曲線趨勢。 項目進度取決于累積關閉/打開曲線起點時間差。 開發(fā)人員、測試人員工作進度、效率也能得到反應理想趨勢圖36/493.缺點趨勢分析新發(fā)覺、修復、關閉累計缺點數(shù)理想趨勢圖37/493.缺點趨勢分析微軟企業(yè)基于缺點趨勢圖里程碑定義日期1234567891011121314Bug數(shù)量匯報Bug處理BugBug收斂點38/493.缺點趨勢分析微軟企業(yè)基于缺點趨勢圖里程碑定義39/494.缺點分布分析最慣用缺點分析方法：缺點分布匯報，允許將缺點計數(shù)作為一個或多個缺點參數(shù)函數(shù)來顯示，生成缺點數(shù)量與缺點屬性函數(shù)。如測試需求和缺點狀態(tài)、嚴重性分布情況等。缺點趨勢匯報，按各種狀態(tài)將缺點計數(shù)作為時間函數(shù)顯示。趨勢匯報能夠是累計，也能夠是非累計；缺點年紀匯報，顯示缺點處于活動狀態(tài)時間，展示一個缺點處于某種狀態(tài)時間長短，從而了解處理這些缺點進度情況。測試結果進度匯報，展示測試過程在被測應用幾個版本中執(zhí)行結果以及測試周期40/494.缺點分布分析軟件缺點為何發(fā)生：根本原因圖表41/495.缺點跟蹤方法當前缺點狀態(tài) Bug Das