51testingno一種業(yè)務(wù)邏輯驅(qū)動(dòng)的G

1、第二十八期2013年01月一種業(yè)務(wù)邏輯驅(qū)動(dòng)的GUI自動(dòng)測試框架設(shè)計(jì)測試二三事關(guān)于缺陷分析的一些思考如何使用關(guān)鍵字驅(qū)動(dòng)測試克服自動(dòng)化測試HTML5安全風(fēng)險(xiǎn)總結(jié)Loadrunner開發(fā)的URL編碼問題讓自動(dòng)化測試失敗的5個(gè)方法完成UAT測試的7大及如何克服軟件測試最佳實(shí)踐快速軟件測試的前提51 測試天地第二十八期：2013 年 1 月專業(yè)軟件測試軟件測試的軟件測試者的大舞臺(tái)主辦：上海博為峰軟件技術(shù)：51 測試天地編輯部主編：周春江地址：云南北路 59 號(hào)1510 室副主編：張曉曉：200001編輯：張燕青、蘇昊波、王河：本期責(zé)任編輯：張燕青傳真：投稿/意見反饋：editor主頁：目錄51 測試天地

2、. 2目錄3刊首語4一種業(yè)務(wù)邏輯驅(qū)動(dòng)的 GUI 自動(dòng)測試框架設(shè)計(jì)5【淘測試專欄】測試二三事9關(guān)于缺陷分析的一些思考14如何使用關(guān)鍵字驅(qū)動(dòng)測試克服自動(dòng)化測試29【淘測試專欄】HTML5 安全風(fēng)險(xiǎn)36LoadRunner開發(fā)的 URL 編碼問題51讓自動(dòng)化測試失敗的 5 個(gè)方法59完成 UAT 測試的 7 大及如何克服62軟件測試最佳實(shí)踐65快速軟件測試的前提75351 測試天地第二十八期刊首語2012 年，伴隨著我們生命的航船，匆匆而去；2013 年，仿佛大海深處一朵奇異的浪花，迎面而來。走過世界，51 測試天地第 28 期與大家一起相約在冬季。如何解決 GUI 自動(dòng)化功能測試帶來的系統(tǒng)界面變更

3、后測試維護(hù)代價(jià)高昂、系統(tǒng)開發(fā)完成后才能開始 GUI 自動(dòng)化測試用例的實(shí)現(xiàn)、熟悉業(yè)務(wù)邏輯的測試工程師和熟悉自動(dòng)化技術(shù)的自動(dòng)化測試工程師難以有效合作等問題的困擾？自動(dòng)化測試無可否認(rèn)是任何 QA 經(jīng)理的主要策略之一，他們也都有很好的理由：自動(dòng)化保證回歸快，生產(chǎn)效率高，質(zhì)量好，降低成本。然而，許多 QA 經(jīng)理卻無法達(dá)到這些結(jié)果。他們所面對(duì)的是交付的延遲，昂貴的工具，并處理了很多的挫折。但是，這是什么呢？內(nèi)容等待您的閱讀。51 測試天地為加強(qiáng)測試經(jīng)驗(yàn)與技術(shù)的交流，做出了不懈的努力。在這里，您可以看到測試行業(yè)的蓬勃發(fā)展；在這里，您可以看到測試朋友無私辛勤的寫作；在這里，您可以盡情表達(dá)對(duì)測試行業(yè)發(fā)展的看法和

4、建議我們熱忱期待您的參與。回首過去，我們豪情滿懷；展望未來，我們?nèi)沃氐肋h(yuǎn)。新的一年，一如既往，夢想不斷延伸，腳步依舊執(zhí)著。在測試領(lǐng)域中，找準(zhǔn)方向，我們何懼路遠(yuǎn)！ 51 測試天地編輯部上海博為峰軟件技術(shù) 二一三年一月451 測試天地第二十八期一種業(yè)務(wù)邏輯驅(qū)動(dòng)的 GUI 自動(dòng)測試框架設(shè)計(jì)作者：茹炳晟摘要：軟件的 GUI 自動(dòng)化功能測試在很大程度上提高了軟件測試的效率，大幅度減少了測試的重復(fù)工作量，但與此同時(shí)也帶來了系統(tǒng)界面變更后測試維護(hù)代價(jià)高昂、系統(tǒng)開發(fā)完成后才能開始 GUI 自動(dòng)化測試用例的實(shí)現(xiàn)、熟悉業(yè)務(wù)邏輯的測試工程師和熟悉自動(dòng)化技術(shù)的自動(dòng)化測試工程師難以有效合作等問題的困擾，嚴(yán)重阻礙了軟件

5、GUI 自動(dòng)化測試的推廣與發(fā)展。本框架設(shè)計(jì)提出了一種全新的測試業(yè)務(wù)邏輯與軟件界面操作相的層次化 GUI 自動(dòng)化測試框架，通過引入“業(yè)務(wù)”和“操作”的概念，建立 GUI 界面操作層、基本功能層和業(yè)務(wù)邏輯層的層次化框架結(jié)構(gòu)，大幅度提高自動(dòng)化測試框架的靈活性和可復(fù)用程度，實(shí)現(xiàn)了由業(yè)務(wù)邏輯來驅(qū)動(dòng)自動(dòng)化測試的自動(dòng)生成和執(zhí)行，從根源上部分解決了自動(dòng)化測試中的主要難題。本框架設(shè)計(jì)思想不依賴特定的自動(dòng)化測試工具，可普遍適用于目前主流的 GUI 自動(dòng)化測試工具，比如 QTP，RFT，Ruby+Watir 等。關(guān)鍵字：業(yè)務(wù)邏輯驅(qū)動(dòng)；測試框架；GUI 自動(dòng)化測試；BDD； 一、GUI 自動(dòng)化測試的難點(diǎn)GUI 自動(dòng)化

6、測試在幫助提供測試效率的同時(shí)，也引入了一系列的問題與挑戰(zhàn)。歸納起來主要有以下四個(gè)方面：1、GUI 自動(dòng)化測試的開發(fā)與維護(hù)代價(jià)高昂。目前主流的 GUI 自動(dòng)化測試結(jié)合了業(yè)務(wù)邏輯和完成業(yè)務(wù)邏輯所需要的界面操作步驟，無論是 GUI 界面、GUI 操作流程或者是業(yè)務(wù)邏輯發(fā)生變化的時(shí)候，都會(huì)有大量的測試用例需要修改。2、對(duì)于 GUI 自動(dòng)化的開發(fā)，需要即非常熟悉業(yè)務(wù)邏輯，又能熟練掌握自動(dòng)化語言的工程師。通常而言，熟悉業(yè)務(wù)的手工測試工程師通常對(duì)自動(dòng)化的編寫不是非常熟悉，而熟練掌握自動(dòng)化技術(shù)的工程師通常很少是業(yè)務(wù)領(lǐng)域的?，F(xiàn)實(shí)情況是，手動(dòng)測試工程師會(huì)把實(shí)現(xiàn)業(yè)務(wù)邏輯的測試步驟以及檢查點(diǎn)以文檔的形式下來，自動(dòng)化工

7、程師再將這些用例文檔“翻譯”成自動(dòng)化測試，這些步驟是即耗時(shí)又耗力的。3、被測系統(tǒng)開發(fā)與 GUI 自動(dòng)化測試不能同步并發(fā)進(jìn)行，這使得自動(dòng)化測試開發(fā)的周期變短。通常，自動(dòng)化測試用例的開發(fā)是在系統(tǒng)內(nèi)部版發(fā)布以后才551 測試天地第二十八期正式開始的，因?yàn)樽詣?dòng)化統(tǒng)的界面對(duì)象與控件。在完成業(yè)務(wù)測試邏輯時(shí)需要很大程度依賴于被測系4、系統(tǒng)開發(fā)過程中，由于變更在所難免，會(huì)出現(xiàn)測試用例設(shè)計(jì)文檔與實(shí)際實(shí)現(xiàn)不同步的情況，通常自動(dòng)化已經(jīng)更新了，而文檔則會(huì)滯后，這就進(jìn)一步加大了自動(dòng)化測試的維護(hù)工作量。二、基于業(yè)務(wù)邏輯驅(qū)動(dòng)的 GUI 自動(dòng)化測試框架設(shè)計(jì)以上種種問題與，本文提出了一種全新的測試業(yè)務(wù)邏輯與軟件界面操作相的層次

8、化 GUI 自動(dòng)化測試框架，通過引入“業(yè)務(wù)”和“操作”的概念，建立 GUI 界面操作層、基本功能層和業(yè)務(wù)邏輯層的層次化框架結(jié)構(gòu)，大幅度提高自動(dòng)化測試框架的靈活性和可復(fù)用程度，實(shí)現(xiàn)了由業(yè)務(wù)邏輯來驅(qū)動(dòng)自動(dòng)化測試的自動(dòng)生成和執(zhí)行，大幅度提高了自動(dòng)化測試的投入產(chǎn)出比。相比傳統(tǒng)的自動(dòng)化測試框架，本框架設(shè)計(jì)思想的優(yōu)勢主要體現(xiàn)在以下幾個(gè)方面：651 測試天地第二十八期1、在此框架下，將由熟知業(yè)務(wù)的（可以是需求工程師、系統(tǒng)目標(biāo)用戶，手工測試工程師）基于業(yè)務(wù)邏輯設(shè)計(jì)基于自然語言的次測試用例，然后通過的“開發(fā)”，由自動(dòng)化框架提供機(jī)制與基本功能層來實(shí)現(xiàn)“業(yè)務(wù)”工程師實(shí)現(xiàn)“操作”、界面對(duì)象識(shí)別以及對(duì)象庫的管理，框架提

9、供相應(yīng)機(jī)制完成“業(yè)務(wù)”和“操作”間的。在此框架下工作，熟知業(yè)務(wù)的和自動(dòng)化工程師各自都能發(fā)揮最擅長的能力，避免了傳統(tǒng)模式下，手動(dòng)測試工程師不擅長自動(dòng)化的開發(fā)與調(diào)試，而自動(dòng)化工程師不熟悉業(yè)務(wù)邏輯的窘境。2、通常而言業(yè)務(wù)邏輯比較穩(wěn)定，而 GUI 操作流程、GUI 界面以及控件的變動(dòng)會(huì)比較平凡。在此框架下，對(duì)于 GUI 界面和控件的變化，只需要修改 GUI 界面操作層的相關(guān)部分；對(duì)于 GUI 操作流程的變化，只需要修改基本功能層；只要業(yè)務(wù)邏輯不變更，上層的測試業(yè)務(wù)邏輯層完全不需要變更，最大限度地降低了測試的維護(hù)工作量，同時(shí)保證了業(yè)務(wù)層測試用例的穩(wěn)定性和可讀性。3、被測系統(tǒng)尚未開發(fā)完成前，就可以根據(jù)被測

10、系統(tǒng)需求的測試需求，實(shí)現(xiàn)業(yè)務(wù)邏輯層和部分基本功能層來完成“業(yè)務(wù)”的開發(fā)，系統(tǒng)發(fā)布后，在框架的支持下，由“業(yè)務(wù)”自動(dòng)生成實(shí)際可執(zhí)行的自動(dòng)化測試并執(zhí)行，使自動(dòng)化測試開發(fā)和系統(tǒng)開發(fā)并行化，有效地利用了傳統(tǒng)自動(dòng)化測試的空檔期，提高了自動(dòng)化測試開發(fā)的效率。4、由于次的測試用例設(shè)計(jì)是通過業(yè)務(wù)邏輯層的“業(yè)務(wù)”表達(dá)的，而在此框架設(shè)計(jì)中，“業(yè)務(wù)”本身就是自然語言，具有極佳的可讀性，因此由“業(yè)務(wù)”設(shè)計(jì)文檔和的測試用例本身就是測試設(shè)計(jì)文檔。這使得自動(dòng)化測試用例之間的同步工作量幾乎為零。以下介紹本框架設(shè)計(jì)的層次結(jié)構(gòu)以及實(shí)現(xiàn)原理：業(yè)務(wù)邏輯層：在系統(tǒng)正式遞交測試之前，就可以由熟悉需求的基于自然語言來設(shè)計(jì)業(yè)務(wù)邏輯層的測試用

11、例。在這個(gè)層面上的測試用例完全基于業(yè)務(wù)邏輯，從描述業(yè)務(wù)層面描述需要做什么以及期待的結(jié)果是什么。測試用例中基于自然語言的每一步操作都會(huì)通過 BLL-BFL Mapping到基本功能層提供的行為描述函數(shù)。同時(shí)，這些測試用例本身就可以作為測試用例的設(shè)計(jì)文檔。基本功能層：基本功能層主要提供各種類型的行為描述函數(shù)。大多數(shù)行為描述函數(shù)基于頁面類來封裝，每一個(gè)頁面類中包含頁面操作方法和驗(yàn)證方法。這些方法中描述了完成該操作需要在界面上具體執(zhí)行的操作步驟，需要特別注意的是，這些步驟僅僅描述需要在界面上執(zhí)行什么操作，至于如何找到界面控件并實(shí)751 測試天地第二十八期際執(zhí)行并不在這層實(shí)現(xiàn)。具體實(shí)現(xiàn)對(duì)象識(shí)別和操作的代

12、碼會(huì)在 GUI 界面操作層中實(shí)現(xiàn)，兩者通過 BOL Mapping。在 BOL Mapping機(jī)制的支持下，基本功能層并不依賴于 GUI 操作層所采用的界面自動(dòng)化方案或工具（QTP 或 Ruby+Watir 等）GUI 界面操作層：GUI 界面操作層負(fù)責(zé)具體實(shí)現(xiàn)界面對(duì)象的識(shí)別和操作， 可以由 QTP 或者 Ruby+Watir 或者其他 GUI 自動(dòng)化測試工具實(shí)現(xiàn)，并且可以在BOL Mapping的支持下實(shí)現(xiàn)最終的自動(dòng)生成。三、基于業(yè)務(wù)邏輯驅(qū)動(dòng)的 GUI 自動(dòng)化測試框架設(shè)計(jì)目前該框架設(shè)計(jì)已經(jīng)在 HP 軟件部門內(nèi)部的多條線上得到應(yīng)用，并取得了很好的效果，明顯降低了大型復(fù)雜線的自動(dòng)化測試的維護(hù)工作

13、量。851 測試天地第二十八期作者簡介：茹炳晟：擅長領(lǐng)域：自動(dòng)化測試、測試框架開發(fā)、白盒測試、系統(tǒng)測試、測試工具需求分析與開發(fā)、測試用例設(shè)計(jì)，7 年軟件測試經(jīng)驗(yàn)和 3 年開發(fā)經(jīng)驗(yàn)。歷任測試技術(shù)主管、高級(jí)測試工程師等職位，具有豐富的測試框架設(shè)計(jì)與自動(dòng)化測試經(jīng)驗(yàn)。【淘測試專欄】測試二三事作者：柳七迄今為止，幾段工作和研究經(jīng)歷都和測試有著或多或少的關(guān)系，下面我僅敘述下工作經(jīng)歷和我對(duì)于測試的一些思考，希望能夠有所幫助。我最早接觸的測試是協(xié)議測試，那個(gè)時(shí)候正處于網(wǎng)絡(luò)硬件快速發(fā)展的階段。從最開始的有線網(wǎng)絡(luò)到無線網(wǎng)絡(luò)，不絡(luò)硬件如何發(fā)展、如何更新?lián)Q代，大家都需要遵循統(tǒng)一的約束網(wǎng)絡(luò)協(xié)議，因此那個(gè)時(shí)候最主要的工作

14、就是基于網(wǎng)絡(luò)協(xié)議，驗(yàn)證網(wǎng)絡(luò)對(duì)于協(xié)議約束的一致性測試。具體的做法就是：根據(jù)協(xié)議描述（通常都是協(xié)議的 RFC 描述文檔），分析協(xié)議的特性、流程、關(guān)鍵字， 再根據(jù)這些提取出要測試的部分待測點(diǎn)；根據(jù)待測點(diǎn)構(gòu)建待測環(huán)境（通常都是一臺(tái)或者數(shù)臺(tái)終端和網(wǎng)絡(luò)設(shè)備組成的一個(gè)局域網(wǎng)或者類廣域網(wǎng)），進(jìn)而撰寫腳本，對(duì)于待測點(diǎn)進(jìn)行驗(yàn)證；通過對(duì)于提取出的所有待測點(diǎn)的驗(yàn)證情況，評(píng)估待測網(wǎng)絡(luò)對(duì)于其支持網(wǎng)絡(luò)協(xié)議的一致性情況；最后將驗(yàn)證結(jié)果通告網(wǎng)絡(luò)制造商，其根據(jù)結(jié)果對(duì)于進(jìn)行改進(jìn)。在協(xié)議測試的后期，由于無線網(wǎng)絡(luò)的迅猛發(fā)展，無線網(wǎng)絡(luò)的也越來越多，因此的工作是關(guān)于無線網(wǎng)絡(luò)協(xié)議的測試。無線網(wǎng)絡(luò)不僅需要在協(xié)議的一致性測試上需要花費(fèi)一定的精力

15、，其另外一個(gè)特性越來越多的受到了廠商、測試、用戶的重視：無線網(wǎng)絡(luò)的安全性。因?yàn)闊o線網(wǎng)絡(luò)報(bào)文的開放性，同時(shí)由于無線網(wǎng)絡(luò)協(xié)議在安全性方面也不是盡如人意，所以其安全性相對(duì)于有線網(wǎng)絡(luò)顯的更加脆弱，所以無線網(wǎng)絡(luò)一般都需要對(duì)其進(jìn)行安全性測試。這個(gè)時(shí)期的主要工作就是：對(duì)于無線網(wǎng)絡(luò)協(xié)議進(jìn)行分析、提取，找出其中可能被的漏洞，搭建網(wǎng)絡(luò)環(huán)境（基本都是無線局域網(wǎng) WLAN），首先根據(jù)提取出的漏洞編寫對(duì)于無線網(wǎng)絡(luò)設(shè)備進(jìn)行，對(duì)結(jié)果進(jìn)行驗(yàn)證，待測無線網(wǎng)絡(luò)設(shè)備是否具有該安全漏洞。在進(jìn)行協(xié)議分析的時(shí)候，有些漏洞比較容易找出來，但是有些流程性漏洞卻需要分析對(duì)于協(xié)議有了非常充分的了解，進(jìn)而根據(jù)協(xié)議流程推斷出可能發(fā)生的安全漏洞。要對(duì)

16、網(wǎng)絡(luò)協(xié)議進(jìn)試，首先必須要讀懂 RFC 文檔，大部分的 RFC 文檔都是英文撰寫的，雖說現(xiàn)在有一部分中文翻譯的 RFC 文檔，但是讀懂文檔之后還需對(duì)網(wǎng)絡(luò)協(xié)議有著充分的了解，并且在腦海中有了該協(xié)議的大概模型和流程，然后才能提取協(xié)議的漏洞和待測點(diǎn)。這就要求測試不僅需要良好的語言功底，不錯(cuò)951 測試天地第二十八期網(wǎng)絡(luò)基礎(chǔ)，還要需要優(yōu)秀的抽象、建模能力，這對(duì)于測試的要求是相當(dāng)高的。雖說大部分的測試都是由撰寫測試自動(dòng)化運(yùn)行完成，但是這前期的準(zhǔn)備工作不可謂不充分，需要的工作量也是比較大的。之后我來到了 C 公司進(jìn)行軟件測試方面的研究工作，C 公司是一家著名的國際互聯(lián)網(wǎng)硬件公司，其軟件的整個(gè)生命周期嚴(yán)格遵守

17、“瀑布模式”：從需求階段，到開發(fā)階段，再到測試階段，一環(huán)一環(huán)，緊密相扣。當(dāng)時(shí)我所在的部門是C公司的某款服務(wù)器進(jìn)試，復(fù)雜的邏輯和相對(duì)穩(wěn)定的架構(gòu)就是測試的全部，測就需求文檔就行 review，就功能點(diǎn)達(dá)成一致；等開發(fā)試首先要和開發(fā)完成后，測試根據(jù)需求描述，首先生成測試?yán)?，然后再由測試根據(jù)測試?yán)珜戇M(jìn)試或者手動(dòng)測試。這整個(gè)流程的迭代周期是相當(dāng)長的，但是好處也是顯而易見的：開發(fā)、測試各司其職，分工明確，而且有比較充足的時(shí)間對(duì)于功能進(jìn)行反復(fù)測試的測試覆蓋率、穩(wěn)定性都維持在一個(gè)相當(dāng)高的水準(zhǔn)上，而 bug 幾乎是可以忽略的存在。之所以采用這樣的測試流程，我后來分析了下，我個(gè)人總結(jié)如下：首先C 公司的追求的是

18、質(zhì)量，因此公司的一切活動(dòng)都以此為導(dǎo)向，而在追求絕對(duì)的質(zhì)量的基礎(chǔ)上可能會(huì)有勞動(dòng)力的浪費(fèi)、的浪費(fèi)、工作的重復(fù)，但是只要達(dá)到了質(zhì)量，一切都是在可以承受的范圍之內(nèi)。同時(shí)，C 公司的種類不多，版本也進(jìn)行著嚴(yán)格的，這也就意味著的迭代周期會(huì)比較長，“瀑布模型”的迭代流程是一個(gè)比較經(jīng)典也比較穩(wěn)妥的選擇。最后，對(duì)于部門的待測的架構(gòu)進(jìn)行簡單的分析，因?yàn)榇郎y是屬于服務(wù)器，邏輯相對(duì)穩(wěn)定，穩(wěn)定的就需要一個(gè)穩(wěn)定的測試流程對(duì)其質(zhì)量進(jìn)行保障，而“瀑布模型”在流程上是一個(gè)四平八穩(wěn)、出太多漏洞的流程。我在 C 公司實(shí)際從事業(yè)務(wù)線的測試不多，大部分時(shí)間是想辦法做測試上的優(yōu)化，進(jìn)而提高測試的工作效率。雖說迭代周期長，但是測試為了保證

19、工程質(zhì)量在一個(gè)很高的水準(zhǔn)，基本要實(shí)現(xiàn) 100%的覆蓋率，這對(duì)他們的要求是非常高的，一個(gè)細(xì)節(jié)不注意，可能就會(huì)發(fā)生測試?yán)齺G失的現(xiàn)象，因此他們的工作量是非常大的。幸運(yùn)的是，由于架構(gòu)的相對(duì)穩(wěn)定性，絕大部分的功能模塊都可以進(jìn)行模型化，于是就開發(fā)了一個(gè)基于模型的測試工具，這個(gè)工具可以對(duì)于功能模塊的模型進(jìn)行分析，自動(dòng)生成所有的符合要求的測試?yán)@樣既提高了測試效率，也提高了測試的覆蓋率。1051 測試天地第二十八期相對(duì)于協(xié)議測試，C 公司不僅要求測試需要他們能夠?qū)τ跍y試結(jié)果進(jìn)行分析，準(zhǔn)確對(duì)于業(yè)務(wù)邏輯非常熟悉，同時(shí)也到 bug。我現(xiàn)在淘寶從事測試工具開發(fā)工作。作為互聯(lián)網(wǎng)公司，其迭代模式就會(huì)遵循互聯(lián)網(wǎng)公司的一些

20、規(guī)律：迭代周期短、更新?lián)Q代速度快。相對(duì)于 C 公司，淘寶在迭代速度上有了明顯的要求，有的時(shí)候的速度甚至勝于一切。這就要求測試在測試速度和測試質(zhì)量之間產(chǎn)生了一個(gè)取舍：在不影響迭代周期的前提上，保證測試質(zhì)量，自動(dòng)化測試和回歸自然就成為了測試業(yè)務(wù)的主流。淘寶有著一套完備的自動(dòng)化測試方案，可以實(shí)現(xiàn)自動(dòng)化測試和自動(dòng)化的回歸測試，同時(shí)也可以對(duì)測試結(jié)果進(jìn)行統(tǒng)計(jì)和分析，提升了測試效率的同時(shí)也保證了質(zhì)量。淘寶測試自動(dòng)化程度很高，這就要求測試?yán)斫?，也需要一定的編程基礎(chǔ)，同時(shí)還能根據(jù)不僅需要具有對(duì)于業(yè)務(wù)邏輯的日志分析出真正的bug。當(dāng)然由于迭代速度很快，這一切都需要在一個(gè)很短的周期內(nèi)完成，這就對(duì)測試人員提出了更高的

21、要求：必須快、準(zhǔn)，要不然等發(fā)現(xiàn)出 bug 可能下一個(gè)期都開始了！迭代周因質(zhì)工作的，有的時(shí)候會(huì)思考：如何能夠在不影響迭代周期的前提下最大程度上提高么樣的？質(zhì)量？ 如何能讓測試的門檻降低？以后的測試模式是什在此之前，讓我們來花點(diǎn)時(shí)間想測試的本質(zhì)。我之前一直到現(xiàn)在的幾段經(jīng)歷都是測試工作：協(xié)議測試、測試、安全測試，那么這么多門類繁多的測試，帶著不同頭銜的測試，他們的本質(zhì)是什么呢？從簡單的層面說，測試無外乎就是最后給出一個(gè)結(jié)果：“是”或者“否”，一切的、一切的操作最后其實(shí)都是為了達(dá)到這個(gè)目的。如何才能得到“是”或者“否”呢，很明顯需要通過比較才能得到這樣的結(jié)果；而比較的基準(zhǔn)是什么呢，基準(zhǔn)必須是各方認(rèn)定的

22、一個(gè)衡量標(biāo)準(zhǔn)，前面說的 RFC 文檔、需求，就是我們比較的基準(zhǔn)，只是我們對(duì)其進(jìn)行了再次提取和分析；比較的前提就是我們的測試環(huán)境；而比較并且最后得到結(jié)果的過程，其實(shí)就是我們測試的過程；至于結(jié)果是“是”還是“否”，首先需要比較的前提有沒有問題，比較的過程有沒有問題，最后才能出結(jié)果的真?zhèn)?，而這個(gè)過程就是結(jié)果分析和 bug的過程。因此，我們可以給測試下一個(gè)這樣的定義：測試就是在一定的環(huán)境下，通過某種特定的進(jìn)行證實(shí)或者證偽的一個(gè)過程。，對(duì)于基準(zhǔn)的描述1151 測試天地第二十八期有了上面的描述，我們對(duì)于某些問題可能就有了一個(gè)大致的思路了。首先我們的工作就是要把基準(zhǔn)進(jìn)行抽象，抽象之后的基準(zhǔn)要具有通用性、可讀

23、性、明確性，這樣才便于我們找出它們的規(guī)律。對(duì)于以下的描述：太陽是紅色的，我們可以抽象成：sunColor = red，對(duì)于有過一些編程經(jīng)驗(yàn)的人來說，后面的語句顯然是更加易于理解的?？梢耘e一個(gè)稍微復(fù)雜的例子：今天下雨，所以今天沒有太陽，對(duì)于這句話可以這么描述：sunColor = nullweather=rainy，這就產(chǎn)生了條件和因果關(guān)系了。這樣的例子比較簡單，對(duì)于一個(gè)很復(fù)雜的系統(tǒng)，要把其所有的基準(zhǔn)（描述）抽象出來，這本身是一個(gè)很復(fù)雜的過程。因此我們才有了很多的建模技術(shù)，我們使用了很多的建模方法（狀態(tài)機(jī)、流程圖、UML 圖、petri 網(wǎng)）這些技術(shù)唯一的目的就是把待測對(duì)象抽象成一個(gè)易于理解的、

24、便于分析的、明確的系統(tǒng)，為什么要這么多，說白了是讓我們易于理解、易于掌握，進(jìn)而好對(duì)其下手。要打敗你的敵人，首先要了解你的敵人；在測試領(lǐng)域，要測試好你的對(duì)象，首先要了解你的待測對(duì)象，了解了， 就好下手了，不管是功能測試、性能測試、安全測試，還不是手到擒來么。我在做協(xié)議測試的時(shí)候，協(xié)議的每個(gè)狀態(tài)有多個(gè)屬性，同時(shí)協(xié)議具有一定的時(shí)效性， 因此使用 petri 網(wǎng)來抽象出協(xié)議的運(yùn)行流程；我在 C 公司的時(shí)候，因?yàn)榇郎y系統(tǒng)流程轉(zhuǎn)換很多，所以我們使用了流程圖和狀態(tài)機(jī)來抽象整個(gè)系統(tǒng)；其實(shí)使用何種抽象無所謂，只要能夠關(guān)心的那一面描述出來，那就是好的抽象方法。進(jìn)而再說環(huán)境準(zhǔn)備，環(huán)境準(zhǔn)備指的是待測對(duì)象要具備完成測試

25、過程所需要的初始條件。比如我們前面的例子：sunColor = nullweather=rainy 中， weather=rain 其實(shí)是表示今天沒有太陽的一個(gè)初始條件，我們要驗(yàn)證的就是今天是不是有太陽，那么今天下雨就是我們要驗(yàn)證今天有沒有太陽的一個(gè)必備條 件。很多人可能會(huì)忽略環(huán)境準(zhǔn)備的重要性，環(huán)境準(zhǔn)備其實(shí)是測試過程中一個(gè)非常重要的一個(gè)必不可好的環(huán)節(jié)，很多時(shí)候最終測試結(jié)果可能就因?yàn)槌跏辑h(huán)境準(zhǔn)備的差異而有著迥然不同的變化。隨著各個(gè)公司對(duì)于測試的重視，測試范圍越來越大， 待測系統(tǒng)越來越復(fù)雜，測試環(huán)境的準(zhǔn)備逐漸成為了一個(gè)很復(fù)雜、很麻煩的流程。測試環(huán)境的準(zhǔn)備包括多個(gè)方面：場景復(fù)現(xiàn)、數(shù)據(jù)準(zhǔn)備、測試框架準(zhǔn)

26、備，我經(jīng)常碰到的問題就是：測試過來抱怨，其實(shí)要驗(yàn)證的功能點(diǎn)非常簡單，搭個(gè)環(huán)境卻要搭半天。因此，我們?nèi)绻転橛脩魷?zhǔn)備一些標(biāo)準(zhǔn)的、不受任何干擾的、穩(wěn)定的、正確的環(huán)境，最通俗的說法是，只要掌握了流程，上來就能用，上來就會(huì)用的一個(gè)穩(wěn)定的測試環(huán)境，這能解決多少因?yàn)榄h(huán)境帶來的困擾?。?251 測試天地第二十八期環(huán)境都準(zhǔn)備好了，測試對(duì)象也抽象化，在這里簡單的說明一下：此處的測試對(duì)象抽象化，指的是通過某種技術(shù)對(duì)其進(jìn)行抽象，并且能夠通過對(duì)于該技術(shù)的分析得到其所有待測點(diǎn)。例如我們用流程圖刻畫出了某個(gè)對(duì)象，那么我們自然可以這個(gè)流程圖得到這個(gè)對(duì)象所有的運(yùn)行規(guī)則，這些運(yùn)行規(guī)則就是我們需要得到的測試?yán)?；而?duì)于流程圖的，其

27、僅僅是一個(gè)算法問題。所有的都準(zhǔn)備好了，我們來談一談測試流程，其實(shí)我們發(fā)現(xiàn)：好像一切都變的簡單了，我們只要按照測試?yán)谔囟ǖ臏y試環(huán)境下使用特定的操作就行了，這個(gè)時(shí)候需要的只是一點(diǎn)對(duì)于業(yè)務(wù)的了解和編程知識(shí)就可以了，甚至都不需要測試寫程序。把一個(gè)測試所有的注意力集中到要測試的業(yè)務(wù)本身，這才是測試的終極目標(biāo)。好了，我們是不是說所有的工作都做完了？萬事大吉，測試方案已經(jīng)完美了？為了對(duì)這個(gè)問題做一個(gè)回答，我們可以同樣用上面舉過的例子：sunColor= nullweather=rainy，今天我把環(huán)境觀察好了：下雨，而且我也看了天空：沒太陽，看上去測試完成了；那么，明天怎么辦？明天是不是我還是要觀察下天

28、空有沒有下雨，再觀察下天空有沒有太陽？后天呢？為了避免每天都問這樣一個(gè)問題，我們其實(shí)需要的只是每天的天氣就可以了，甚至我們可以通過傳感器監(jiān)測是否下雨自動(dòng)天氣，剩下的，都交給計(jì)算機(jī)吧。上面的例子其實(shí)說明了測試當(dāng)中的一個(gè)極其重要的部分：測試的可維護(hù)性。我們不愿意浪費(fèi)時(shí)間在重復(fù)做著同樣的事情，我們可以借助計(jì)算機(jī)來完成。計(jì)算機(jī)的一個(gè)重要的作用就是一些重復(fù)的、有規(guī)律的事情可以通過它來完成，因此我們可以借助計(jì)算機(jī)來幫我們完成一些重復(fù)性工作，但是需要給其一些特別的指令：比如定期掃描環(huán)境有沒有變化、當(dāng)環(huán)境發(fā)生變化時(shí)改變其運(yùn)行規(guī)律、定期給我們一個(gè)提醒等。我們可以讓計(jì)算機(jī)幫我們管理數(shù)據(jù)、管理、管理環(huán)境、結(jié)果分析等

29、；當(dāng)需要調(diào)整我們的測試計(jì)劃時(shí)，我們只需要給其幾個(gè)簡單的指令。在現(xiàn)在不少公司，測試的可維護(hù)結(jié)構(gòu)相對(duì)穩(wěn)定，的時(shí)候是功能是增加、修改、刪除，對(duì)也就愈發(fā)強(qiáng)烈。說了這么多，其實(shí)就是一句話：能夠使得測試不用關(guān)注除了測試內(nèi)容之外的其他繁冗復(fù)雜的事物的測試方案才是一個(gè)好的測試方案。1351 測試天地第二十八期關(guān)于缺陷分析的一些思考作者：-ing前言：工作多年，發(fā)現(xiàn)諸多測試新人對(duì)缺陷分析了解甚少，市面上也很少有書籍專門對(duì)缺陷分析方法進(jìn)行介紹。故在此總結(jié)一些些思路。內(nèi)容提要的經(jīng)驗(yàn)，希望能提供一對(duì)于如何有效分析缺陷，本文將分三個(gè)部分向大家介紹：（一）BUG 屬性分解：我們首先一起來解讀 BUG 的諸多屬性，為何我們

30、需要這些屬性，這些屬性對(duì)我們后續(xù)的分析有何幫助？在這一部分會(huì)為大家做一定解析。（二）單項(xiàng)目 BUG 分析與質(zhì)量評(píng)估：獲取 BUG 后如何解讀缺陷，如何通過這些缺陷了解項(xiàng)目質(zhì)量和風(fēng)險(xiǎn)？本文將以改編的案例形式重點(diǎn)介紹。（三）綜合分析與數(shù)據(jù)度量：放大的視角，把缺陷全局化，用管理者的眼光建立基線指標(biāo)，指導(dǎo)后續(xù)項(xiàng)目提升與改進(jìn)。將此作為真正意義上缺陷分析工作的擴(kuò)展。：缺陷分析；質(zhì)量評(píng)估；數(shù)據(jù)度量；正文（一）BUG 屬性分解1、BUG 屬性所謂 BUG 屬性，其實(shí)簡單講就是我們?nèi)粘Ｌ釄?bào) BUG 時(shí)要求填寫的內(nèi)容，每個(gè)公司都有的填寫標(biāo)準(zhǔn)，內(nèi)容會(huì)有所差異，這里向大家介紹一些基礎(chǔ)字段1451 測試天地第二十八期屬

31、性描述項(xiàng)目名稱由公司自行定義，用于區(qū)分本次測試與其他測試項(xiàng)目項(xiàng)目所屬模塊由公司自行定義，用于標(biāo)識(shí)本次測試范圍BUG 標(biāo)題一般是對(duì) BUG 的簡要描述，依據(jù)各公司要求規(guī)范填寫B(tài)UG 類型需求錯(cuò)誤，設(shè)計(jì)錯(cuò)誤，編碼錯(cuò)誤，其他參考 2 章節(jié)BUG 嚴(yán)重程度致命，嚴(yán)重，一般，建議參考 3 章節(jié)BUG 優(yōu)先級(jí)高優(yōu)先級(jí)，中優(yōu)先級(jí)，低優(yōu)先級(jí)參考 4 章節(jié)缺陷描述：描述重現(xiàn)步驟，預(yù)期結(jié)果和實(shí)際結(jié)果缺陷狀態(tài)：活動(dòng)，已解決，已關(guān)閉，待決定參考 5 章節(jié)BUG 提出者缺陷提出者，一般為項(xiàng)目測試BUG 制造者缺陷制造者，一般為程序開發(fā)BUG 版本號(hào)一般分為 BUG 發(fā)現(xiàn)版本和 BUG 修復(fù)版本兩類BUG 解決者缺陷解決

32、這，通常為缺陷制造者本人2、BUG 類型例如：3、BUG 嚴(yán)重程度BUG 嚴(yán)重程度的定義，每個(gè)公司的標(biāo)準(zhǔn)區(qū)別很大，在某些公司 UI 界面的 BUG也會(huì)被認(rèn)為是嚴(yán)重的，但對(duì)有些公司則無關(guān)緊要。下面給出一種參考：4、BUG 優(yōu)先級(jí)1551 測試天地第二十八期嚴(yán)重級(jí)別具體表現(xiàn)致命數(shù)據(jù)庫破壞。系統(tǒng)停機(jī)。擴(kuò)展到其它系統(tǒng)的系統(tǒng)停機(jī)。嚴(yán)重界面：UI 界面無法打開/報(bào)錯(cuò)，無法正常完成測試工作的。非配置文件中的錯(cuò)誤的頁面，此類屬于硬編碼到代碼中必須重新發(fā)布程序的錯(cuò)誤。程序：功能實(shí)現(xiàn)問題（指程序模塊的功能或優(yōu)先級(jí)高的特殊功能）。數(shù)據(jù)庫：數(shù)據(jù)表設(shè)計(jì)字段與用戶需求不符（字段、字段數(shù)據(jù)類型不符、字段冗余）。數(shù)據(jù)表字段保

33、存全。一般界面:界面提示不規(guī)范（提示信息錯(cuò)誤，提示內(nèi)容與實(shí)際不符， 提示信息不友好等）界面布局不規(guī)范（同級(jí)別字體樣式未統(tǒng)一、段落未對(duì)齊、頁面框架不統(tǒng)一）文字錯(cuò)誤（包括按鈕文字，頁面文字，選項(xiàng)框文字等） 程序：普通功能操作和輸入輸出項(xiàng)與用戶需求不符（包括輸入輸出項(xiàng)、名稱不符和必填項(xiàng)不符）。建議界面:是否改動(dòng)都不影響發(fā)布和用戶驗(yàn)收程序:可以更好改進(jìn)的, 但是對(duì)測試質(zhì)量影響的編號(hào)類型描述1需求錯(cuò)誤需求本身不符合邏輯導(dǎo)致的錯(cuò)誤2設(shè)計(jì)錯(cuò)誤因設(shè)計(jì)文檔和需求不符導(dǎo)致的錯(cuò)誤3編碼錯(cuò)誤程序和需求不符導(dǎo)致的錯(cuò)誤4其他其他錯(cuò)誤優(yōu)先級(jí)的定義目的是為了讓開發(fā)知曉哪些 BUG 影響到測試進(jìn)度需要優(yōu)先處理的，哪些是可以放緩

34、處理進(jìn)度的。例如：5、缺陷狀態(tài)通常缺陷狀態(tài)是整個(gè) BUG 的解項(xiàng)目進(jìn)展所關(guān)注的重要指標(biāo)。引擎，牽動(dòng)著 BUG 的進(jìn)展，也是項(xiàng)目經(jīng)理了缺陷狀態(tài)的擬定也是各有不同，最簡單的狀態(tài)遷移一般包含“活動(dòng)/已解決/待決定/已關(guān)閉”四種，這四種狀態(tài)的參與者主要是測試和開發(fā)，由測試人員發(fā)起，最終也需要測試結(jié)項(xiàng),可參考如下模型：6、小結(jié)通過介紹 BUG 屬性，也許大家對(duì) BUG 編寫會(huì)有些新的認(rèn)識(shí)，建議大家認(rèn)真對(duì)待，理由很簡單，BUG 分析也是環(huán)環(huán)相扣的，只有正確選擇 BUG 屬性才談得上后續(xù)的項(xiàng)目 BUG 分析，不然分析出來的結(jié)果并不能指導(dǎo)我們的質(zhì)量評(píng)估，后續(xù)的數(shù)據(jù)度量也成為空談?？梢杂孟逻叺沫h(huán)狀模型加強(qiáng)理解。

35、1651 測試天地第二十八期編號(hào)優(yōu)先級(jí)描述1高優(yōu)先級(jí)給予高度重視的 BUG2中優(yōu)先級(jí)需要正常排隊(duì)等待修復(fù)和處理的 BUG3低優(yōu)先級(jí)BUG 可以在方便時(shí)被修正（二）單項(xiàng)目 BUG 分析與質(zhì)量評(píng)估單項(xiàng)目 BUG 分析是日常工作中最常見的分析指標(biāo)，可以通過缺陷在項(xiàng)目各環(huán)節(jié)的變化來了解項(xiàng)目質(zhì)量和項(xiàng)目進(jìn)度，并預(yù)估項(xiàng)目風(fēng)險(xiǎn)。項(xiàng)目缺陷分析有很多入手點(diǎn)，下面有三個(gè)案例，短期維護(hù)類項(xiàng)目，小型工程類項(xiàng)目和中小型重構(gòu)項(xiàng)目，以部分 BUG 屬性作為分析依據(jù)。1、短周期維護(hù)類項(xiàng)目缺陷分析案例一：通過三個(gè)基礎(chǔ)指標(biāo)（BUG 類型/BUG 嚴(yán)重程度/BUG 缺陷狀態(tài)）分析項(xiàng)目缺陷，假設(shè)人力，時(shí)間等因素均正常。Point1：1

36、751 測試天地第二十八期關(guān)注時(shí)間點(diǎn)第 7 個(gè)工作日 中午項(xiàng)目經(jīng)理向測試人員詢問測試進(jìn)展備注說明當(dāng)前 BUG描述BUG 類型需求錯(cuò)誤設(shè)計(jì)錯(cuò)誤編碼錯(cuò)誤其他錯(cuò)誤其他錯(cuò)誤（其中 UI 錯(cuò)誤 2， 建議類 1 個(gè)）0043BUG 嚴(yán)重程度嚴(yán)重一般建議建議的 BUG 為 UI BUG241BUG 狀態(tài)活動(dòng)已解決已關(guān)閉待決定其中嚴(yán)重程度最高的 2 個(gè)BUG 為關(guān)閉狀態(tài)2230用例覆蓋情況高優(yōu)先級(jí)用例執(zhí)行 100% ，中優(yōu)先級(jí)用例執(zhí)行 30%，低優(yōu)先級(jí)用例執(zhí)行 0%項(xiàng)目類型某市場活動(dòng)功能描述節(jié)即將來臨，某一些特定策劃了節(jié)促銷活動(dòng)項(xiàng)目周期10 個(gè)工作日需求分析與評(píng)審 2 個(gè)工作日，設(shè)計(jì)與編碼 3 個(gè)工作日測試

37、 4 個(gè)工作日，驗(yàn)收與發(fā)布 1 個(gè)工作日人力投入5.5 人項(xiàng)目經(jīng)理 1 人，需求分析師 1 人，UI 設(shè)計(jì) 1 人，開發(fā)1 人，測試1.5 人Ponit2：Point3：1851 測試天地第二十八期關(guān)注時(shí)間點(diǎn)第9 天 下午 項(xiàng)目經(jīng)理確認(rèn)是否可按時(shí)發(fā)布備注說明當(dāng)前 BUG描述BUG 類型需求錯(cuò)誤設(shè)計(jì)錯(cuò)誤編碼錯(cuò)誤其他錯(cuò)誤其他錯(cuò)誤（其中 UI 錯(cuò)誤 6， 建議類 1 個(gè)）0067BUG 嚴(yán)重程度嚴(yán)重一般建議建議的 BUG 為 UI BUG 1 個(gè)用戶體驗(yàn) 1 個(gè)292BUG 狀態(tài)活動(dòng)已解決已關(guān)閉待決定活動(dòng)狀態(tài)（剩余 1 個(gè)用戶體關(guān)注時(shí)間點(diǎn)第 8 天 下午 項(xiàng)目經(jīng)理向測試詢問測試進(jìn)展備注說明當(dāng)前 BU

38、G描述BUG 類型需求錯(cuò)誤設(shè)計(jì)錯(cuò)誤編碼錯(cuò)誤其他錯(cuò)誤其他錯(cuò)誤（其中 UI 錯(cuò)誤 6， 建議類 1 個(gè)）0066BUG 嚴(yán)重程度嚴(yán)重一般建議建議的 BUG 為 UI BUG 1 個(gè)用戶體驗(yàn) 1 個(gè)282BUG 狀態(tài)活動(dòng)已解決已關(guān)閉待決定已關(guān)閉狀態(tài)（2 個(gè)嚴(yán)重 BUG， 4 個(gè)一般 BUG）活動(dòng)狀態(tài)（2 個(gè)一般 BUG，2個(gè)建議 BUG）。4260用例覆蓋情況高優(yōu)先級(jí)用例執(zhí)行 100% ，中優(yōu)先級(jí)用例執(zhí)行 100%，低優(yōu)先級(jí)用例執(zhí)行 0%測試 的分析A：測試工作已開展了 3 天，并未發(fā)現(xiàn)需求和設(shè)計(jì)上的錯(cuò)誤，可以排除需求變更方面的風(fēng)險(xiǎn)。 B：從嚴(yán)重程度上分析，并未出現(xiàn)新的嚴(yán)重 BUG，說明項(xiàng)目穩(wěn)定程度

39、無太大問題。C：從 BUG 修復(fù)情況來看，過半 BUG 已被修復(fù)，且活動(dòng)狀態(tài)的 BUG 一般為建議型 BUG，無影響修復(fù)進(jìn)度方面的風(fēng)險(xiǎn)。測試 的回復(fù)項(xiàng)目進(jìn)展情況正常，無特殊情況可按時(shí)完成測試任務(wù)。測試的分析A：測試工作已開展了 1.5 天，并未發(fā)現(xiàn)需求和設(shè)計(jì)上的錯(cuò)誤，暫時(shí)排除了需求變更方面的風(fēng)險(xiǎn)。B：從嚴(yán)重程度上分析，嚴(yán)重 BUG 已修復(fù)，并且得到驗(yàn)證，說明項(xiàng)目能穩(wěn)定測試，無影響項(xiàng)目進(jìn)度的BUG 待修復(fù)。測試的回復(fù)項(xiàng)目進(jìn)展情況正常，暫無影響進(jìn)度的風(fēng)險(xiǎn)。2、小規(guī)模工程類項(xiàng)目缺陷分析案例二：以“版本管控”為主線，結(jié)合三個(gè) BUG 屬性（BUG 類型/BUG 嚴(yán)重程度/BUG 缺陷狀態(tài)）分析項(xiàng)目缺陷

40、。假設(shè)人力，時(shí)間等因素均正常。Ponit1：1951 測試天地第二十八期關(guān)注時(shí)間點(diǎn)第 20 個(gè)工作日下午（第一輪測試第 2天）備注說明當(dāng)前 BUG描述BUG 類型需求錯(cuò)誤設(shè)計(jì)錯(cuò)誤編碼錯(cuò)誤其他錯(cuò)誤其他錯(cuò)誤（其中 UI 錯(cuò)誤 2）0582BUG 嚴(yán)重程度嚴(yán)重一般建議5100BUG 狀態(tài)活動(dòng)已解決已關(guān)閉待決定嚴(yán)重錯(cuò)誤狀態(tài)（2 個(gè)已解決，2個(gè)已關(guān)閉，1 個(gè)活動(dòng)）21030用例覆蓋情況郵件訂閱和通知的主體流程 相關(guān)用例執(zhí)行 80%項(xiàng)目類型小規(guī)模工程類項(xiàng)目功能描述某大型 ERP 系統(tǒng)需要新增郵件訂閱和通知功能項(xiàng)目周期35 個(gè)工作日需求分析與評(píng)審 8 個(gè)工作日，設(shè)計(jì)與編碼 10 個(gè)工作日測試 12 個(gè)工作日

41、，驗(yàn)收與發(fā)布 5 個(gè)工作日計(jì)劃測試版本12 個(gè)工作日第一輪測試：郵件訂閱和通知的主體流程 3天第二輪測試：全面測試，保證需求點(diǎn) 100% 覆蓋 4天第三輪測試：ERP 系統(tǒng)外部接口測試 2 天第四輪測試：回歸測試 3 天人力投入9 人項(xiàng)目經(jīng)理 1 人，需求分析1 人，UI 設(shè)計(jì)1人，開發(fā)3 人，測試3 人10120驗(yàn) BUG）用例覆蓋情況高優(yōu)先級(jí)用例執(zhí)行 100% ，中優(yōu)先級(jí)用例執(zhí)行 100%，低優(yōu)先級(jí)用例執(zhí)行 100%測試人員的分析A：測試工作已進(jìn)入收尾階段，后續(xù)發(fā)現(xiàn)的 BUG 嚴(yán)重級(jí)別不高，且缺陷狀態(tài)基本修復(fù)完成，未修復(fù)的 BUG 為用戶體驗(yàn)方面的建議。測試人員的回復(fù)項(xiàng)目進(jìn)度正常，并詢問項(xiàng)

42、目經(jīng)理是否需要在本次修復(fù)用戶體驗(yàn)方面的缺陷。若回復(fù)暫不修復(fù)則該 BUG 更新為待決定狀態(tài)，若要求修復(fù)，則等待開發(fā)修復(fù)后驗(yàn)證。Point2：Ponit3：2051 測試天地第二十八期關(guān)注時(shí)間點(diǎn)第 26 個(gè)工作日 下午（第三輪測試第1 天）備注說明當(dāng)前BUG描述BUG 類型需求錯(cuò)誤設(shè)計(jì)錯(cuò)誤編碼錯(cuò)誤其他錯(cuò)誤其他錯(cuò)誤（其中 UI 錯(cuò)誤 14 個(gè)， 建議錯(cuò)誤 1 個(gè)）283215BUG 嚴(yán)重嚴(yán)重一般建議關(guān)注時(shí)間點(diǎn)第 24 個(gè)工作日下午（第二輪測試第 3天）備注說明當(dāng)前 BUG描述BUG 類型需求錯(cuò)誤設(shè)計(jì)錯(cuò)誤編碼錯(cuò)誤其他錯(cuò)誤其他錯(cuò)誤（其中 UI 錯(cuò)誤 14 建議錯(cuò)誤 1）082815BUG 嚴(yán)重程度嚴(yán)重一

43、般建議7413BUG 狀態(tài)活動(dòng)已解決已關(guān)閉待決定嚴(yán)重錯(cuò)誤狀態(tài)為（1 個(gè)已解決，6 個(gè)已關(guān)閉，）1526100用例覆蓋情況高優(yōu)先級(jí)用例執(zhí)行 100% 中優(yōu)先級(jí)別用例執(zhí)行 80% 低優(yōu)先級(jí)用例執(zhí)行10%說明：以上執(zhí)行用例比例不包含接口部分的用例測試人員的分析A：從 BUG 類型來看，發(fā)現(xiàn)的 BUG 主要集中在功能方面，頁面上的問題也大量涌現(xiàn)，設(shè)計(jì)和需求類錯(cuò)誤無明顯變化。B：從 BUG 嚴(yán)重程度上來看，嚴(yán)重 BUG 數(shù)量上無明顯大幅增長，主要集中在一般級(jí)別的 BUG 上。C：從 BUG 修復(fù)狀態(tài)來看，多數(shù) BUG 已被修復(fù)，但活動(dòng) BUG 存在的數(shù)量依然較多，已解決的 BUG 關(guān)閉較少。經(jīng)進(jìn)一步確認(rèn)

44、，發(fā)現(xiàn)部分 BUG 狀態(tài)是已解決但實(shí)際并未完全解決，或引出新 BUG，導(dǎo)致 BUG 無法順利關(guān)閉。建議組織局部會(huì)議，分析頻繁來回修復(fù) BUG 的 ， 處理BUG。測試人員的過程分析A：從 BUG 類型來看，發(fā)現(xiàn)的 BUG 主要集中在主流程功能方面，符合測試設(shè)計(jì)。B：從 BUG 嚴(yán)重程度上來看，嚴(yán)重 BUG 發(fā)現(xiàn)的數(shù)量較多，初期測試屬正?，F(xiàn)象。C：從 BUG 修復(fù)狀態(tài)來看，多數(shù) BUG 已被修復(fù)，但有一個(gè)嚴(yán)重 BUG 處于活動(dòng)狀態(tài)，存在一定風(fēng)險(xiǎn)需要同開發(fā)確認(rèn)。（確認(rèn)結(jié)果：不影響時(shí)間點(diǎn)，當(dāng)天能提交測試）Point4：2151 測試天地第二十八期關(guān)注時(shí)間點(diǎn)第 27 個(gè)工作日下午（第四輪測試第 2天）

45、備注說明當(dāng)前BUG描述BUG 類型需求錯(cuò)誤設(shè)計(jì)錯(cuò)誤編碼錯(cuò)誤其他錯(cuò)誤其他錯(cuò)誤（其中 UI 錯(cuò)誤 14 個(gè)建議錯(cuò)誤 2 個(gè)）283616BUG 嚴(yán)重程度嚴(yán)重一般建議8504BUG 狀態(tài)活動(dòng)已解決已關(guān)閉待決定嚴(yán)重錯(cuò)誤狀態(tài)（2 個(gè)已解決，6個(gè)已關(guān)閉）58490用例覆蓋情況高優(yōu)先級(jí)用例執(zhí)行 100% 中優(yōu)先級(jí)別用例執(zhí)行 100% 低優(yōu)先級(jí)用例執(zhí)行 100%說明：不包含接口部分的用例回歸測試人員的分析A：經(jīng)調(diào)整，發(fā)現(xiàn) BUG 量開始穩(wěn)定下降，沒有產(chǎn)生新的設(shè)計(jì)和需求類BUG。B：從 BUG 嚴(yán)重程度上來看，一般基本 BUG 數(shù)量上保持平穩(wěn)下降趨勢， 嚴(yán)重 BUG 并未增加。程度8463BUG 狀態(tài)活動(dòng)已解決

46、已關(guān)閉待決定嚴(yán)重錯(cuò)誤狀態(tài)為（2 個(gè)活動(dòng)，6個(gè)已關(guān)閉，）54480用例覆蓋情況ERP 系統(tǒng)外部接口測試相關(guān)用例執(zhí)行 20%（高優(yōu)先級(jí)用例執(zhí)行 80%，其余未執(zhí)行）測試人員的分析A：在 BUG 類型中發(fā)現(xiàn)有 2 個(gè)需求錯(cuò)誤，初步分析是需求同外部接口設(shè)計(jì)不一致導(dǎo)致的問題，其中一個(gè)是郵件接口，另外一個(gè)是 接口， 同屬一類問題，但會(huì)阻礙后續(xù)工作開展。B：從 BUG 嚴(yán)重程度上來看，嚴(yán)重 BUG 數(shù)量上保持平穩(wěn)下降趨勢，主要集中在一般級(jí)別的 BUG 上。C：從 BUG 修復(fù)狀態(tài)來看，多數(shù) BUG 已被修復(fù)，但需求錯(cuò)誤還處于活動(dòng)狀態(tài)，需要 PM 確認(rèn)解決方案。項(xiàng)目經(jīng)理的回復(fù)項(xiàng)目經(jīng)理組織協(xié)調(diào)工作會(huì)，會(huì)后得到如

47、下結(jié)論：A：接口開其特殊要求定制化，需重新評(píng)估此部分的工作量預(yù)計(jì)開發(fā)周期 2 個(gè)工作日B：郵件接口調(diào)用方負(fù)責(zé)修改，預(yù)計(jì)開發(fā)周期 2 個(gè)工作日。新的版本計(jì)劃第三輪測試：ERP 系統(tǒng)外部接口測試 1 個(gè)工作日（除去同問題部門的接互，繼續(xù)完成原定測試任務(wù)）。第四輪測試：回歸測試壓縮為 2 天（排除接互部分回歸測試）。第五輪測試：問題部分的測試，及接口部分的回歸測試 2 天。備注：按原定計(jì)劃提交驗(yàn)收測試，接口部分內(nèi)容的測試暫緩 1 天提交。Ponit5：3、中小型重構(gòu)類項(xiàng)目缺陷分析案例三：以“用例覆蓋度”+“版本”結(jié)合三個(gè) BUG 屬性（BUG 類型/BUG嚴(yán)重程度/BUG 缺陷狀態(tài)）分析項(xiàng)目風(fēng)險(xiǎn)。假

48、設(shè)人力，時(shí)間等因素均正常。2251 測試天地第二十八期項(xiàng)目類型中小型重構(gòu)類項(xiàng)目功能描述某電子訂票系統(tǒng)計(jì)劃重構(gòu)原有系統(tǒng)，并增加國外訂單業(yè)務(wù)項(xiàng)目周期62 個(gè)工作日需求分析與評(píng)審 8 個(gè)工作日，設(shè)計(jì)與編碼 20 個(gè)工作日 測試 24 個(gè)工作日，驗(yàn)收與發(fā)布 10 個(gè)工作日人力投入9 人項(xiàng)目經(jīng)理 1 人，需求分析1 人，UI 設(shè)計(jì)2人，開發(fā)3 人，測試2 人待測模塊1. 酒店預(yù)訂 國內(nèi)2. 機(jī)票預(yù)訂 國內(nèi)3. 熱游精選 國內(nèi)關(guān)注時(shí)間點(diǎn)第 30 個(gè)工作日中午（第五輪測試第 3天）備注說明當(dāng)前BUG描述BUG 類型需求錯(cuò)誤設(shè)計(jì)錯(cuò)誤編碼錯(cuò)誤其他錯(cuò)誤其他錯(cuò)誤（其中 UI 錯(cuò)誤 14 建議類錯(cuò)誤 4）283818

49、BUG 嚴(yán)重程度嚴(yán)重一般建議8526BUG 狀態(tài)活動(dòng)已解決已關(guān)閉待決定已解決（UI 錯(cuò)誤 2 個(gè)，建議類2 個(gè)）04620用例覆蓋情況接口測試用例100%執(zhí)行接口外的回歸測試用例高級(jí)別用例 100%，中級(jí)別用例 50%，低級(jí)別用例 0%測試人員的分析A：通過最后一輪的緊張測試，BUG 并無增加的跡象，共計(jì)發(fā)現(xiàn)了 4 個(gè)BUG，均為 UI 或建議類 BUG，說明主體功能可穩(wěn)定運(yùn)行。B：從 BUG 修復(fù)狀態(tài)來看，多數(shù) BUG 已被修復(fù)，僅 4 個(gè) BUG 處于待驗(yàn)證狀態(tài).C：從 BUG 修復(fù)狀態(tài)來看，多數(shù) BUG 已被修復(fù)，需求錯(cuò)誤也按周期順利提交測試等待第五輪驗(yàn)證。項(xiàng)目經(jīng)理的回復(fù)經(jīng)協(xié)調(diào)，再次為測試爭取了 2 個(gè)工作日。項(xiàng)目順延 2 天，按正常進(jìn)度提交即可。新的版本計(jì)劃第五輪測試：變更的內(nèi)容，及接口部分的回歸測試 2 天主流程業(yè)務(wù)交叉回歸測試 2 天Ponit1：Ponit2：（為方便查看，這里僅展示本輪次測試的 BUG 數(shù)量）2351 測試天地第二十八期關(guān)注時(shí)第二輪測試第 3 天 下午備注說明關(guān)注時(shí)間點(diǎn)第一輪測試第 2 天 下午備注說明當(dāng)前 BUG描述BUG 類型需求錯(cuò)誤設(shè)計(jì)錯(cuò)