軟件開發(fā)與測(cè)試配合

1、軟件開發(fā)與測(cè)試配合工作流程2004年11月目 錄1簡(jiǎn)介32適用范圍33術(shù)語、名詞定義33.1送測(cè)軟件33.2開發(fā)文檔33.3測(cè)試文檔43.4被測(cè)程序43.5送測(cè)單43.6BUG單43.7測(cè)試循環(huán)44參考文獻(xiàn)45測(cè)試與開發(fā)的配合55.1 文檔和軟件保存目錄55.2 輔助工具的使用65.2.1 輔助測(cè)試系統(tǒng)1.065.2.2 SourceSafe6.065.3 開發(fā)與測(cè)試配合的流程66. 送測(cè)單76.1送測(cè)單的填寫86.2 工作流程97BUG單97.1 BUG單的填寫97.2 工作流程108測(cè)試階段的結(jié)束119. 備注119.1 開發(fā)階段與測(cè)試階段119.2 待測(cè)模塊的組合與測(cè)試原則119.3 B

2、UG的分類評(píng)級(jí)原則119.4 國標(biāo)中有關(guān)BUG數(shù)量的描述139.5 測(cè)試階段的劃分131 簡(jiǎn)介本流程文件旨在規(guī)定一個(gè)簡(jiǎn)單的可使開發(fā)人員和測(cè)試人員在軟件開發(fā)的編碼階段相互配合工作的工作流程，其中包括測(cè)試與開發(fā)的配合、送測(cè)單和BUG單的填寫、測(cè)試循環(huán)的結(jié)束等部分。開發(fā)階段與測(cè)試循環(huán)的關(guān)系、測(cè)試模塊的組合與測(cè)試原則、BUG的分類評(píng)級(jí)原則等也在本流程文件中有相關(guān)的描述。鑒于公司的技術(shù)要求，目前質(zhì)量部的測(cè)試人員不僅要完成黑盒測(cè)試工作，而且還要進(jìn)行白盒測(cè)試中的“代碼走查”工作。其它的白盒測(cè)試工作，目前還不在測(cè)試人員的工作職責(zé)之內(nèi)。由于公司已經(jīng)為質(zhì)量管理部開發(fā)完成“輔助測(cè)試系統(tǒng)1.0”，因此本測(cè)試流程的制定

3、就建立在輔助測(cè)試系統(tǒng)之上，如果輔助測(cè)試系統(tǒng)有了新的版本，質(zhì)量部將根據(jù)其變化適當(dāng)調(diào)整測(cè)試流程。2 適用范圍本流程文件適用于公司開發(fā)軟件并需要測(cè)試服務(wù)的任何軟件開發(fā)項(xiàng)目組、軟件開發(fā)人員，以及任何測(cè)試人員。當(dāng)項(xiàng)目組在輔助測(cè)試系統(tǒng)中注冊(cè)以后，公司領(lǐng)導(dǎo)可以使用本系統(tǒng)查詢了解所有在本系統(tǒng)中注冊(cè)的項(xiàng)目的測(cè)試信息，項(xiàng)目的質(zhì)量管理員可以使用本系統(tǒng)查詢了解項(xiàng)目的當(dāng)前測(cè)試進(jìn)展情況。程序員和測(cè)試員都可以使用本系統(tǒng)查詢到自己產(chǎn)生的送測(cè)單和BUG單。3 術(shù)語、名詞定義3.1 送測(cè)軟件送測(cè)軟件包括一切軟件執(zhí)行必須的文件、數(shù)據(jù)、數(shù)據(jù)庫配置等。開發(fā)人員必須提供所有的詳細(xì)的資料以保證測(cè)試人員可以像客戶一樣的運(yùn)行被測(cè)軟件。3.2

4、開發(fā)文檔開發(fā)人員提供給測(cè)試人員的開發(fā)文檔至少包括以下幾種：用戶需求，概要設(shè)計(jì)，詳細(xì)設(shè)計(jì)，用戶手冊(cè)等。開發(fā)人員應(yīng)當(dāng)在開發(fā)每階段完成后三天內(nèi)就向測(cè)試人員傳送本階段完成的開發(fā)文檔，以利于測(cè)試人員的工作。3.3 測(cè)試文檔測(cè)試文檔包括測(cè)試計(jì)劃、測(cè)試用例說明、BUG報(bào)告及分析、測(cè)試總結(jié)，以及測(cè)試工作全部完成后的測(cè)試報(bào)告等。測(cè)試文檔由測(cè)試人員編寫并維護(hù)，也屬于開發(fā)文檔的一部分。3.4 被測(cè)程序被測(cè)程序指的是開發(fā)人員提交測(cè)試的軟件可執(zhí)行的部分。被測(cè)程序應(yīng)當(dāng)既包括單獨(dú)的工程文件，以便測(cè)試人員進(jìn)行代碼走查工作；而且還要包括已經(jīng)編譯打包好的可執(zhí)行文件。3.5 送測(cè)單送測(cè)單是指開發(fā)人員向測(cè)試人員提交被測(cè)軟件時(shí)必須填寫

5、的提交報(bào)告。開發(fā)人員應(yīng)當(dāng)謹(jǐn)慎填寫送測(cè)單上的被測(cè)程序的版本號(hào)，保證和被測(cè)程序的版本號(hào)一致。送測(cè)單必須有送測(cè)重點(diǎn)，以利于測(cè)試人員工作。3.6 BUG單BUG單是指測(cè)試人員在測(cè)試完成后，向開發(fā)人員提交的BUG匯總報(bào)告。開發(fā)人員確認(rèn)并修改BUG后，必須填入修改意見并將BUG單返回給測(cè)試人員以驗(yàn)證是否修改成功。3.7 測(cè)試循環(huán)測(cè)試循環(huán)是指從軟件單元/模塊的第一次提交測(cè)試到本編碼階段結(jié)束中間經(jīng)過的所有的有關(guān)的測(cè)試行為和過程。其開始的標(biāo)志是本階段的第一份提交的送測(cè)單，其結(jié)束標(biāo)志是測(cè)試總結(jié)或測(cè)試報(bào)告的提交和審批通過。4 參考文獻(xiàn)1. 計(jì)算機(jī)軟件測(cè)試文件編制規(guī)范，GB 9386-882. <<客戶機(jī)

6、/服務(wù)器系統(tǒng)測(cè)試>>，（美）Bourne，K.C.著，機(jī)械工業(yè)出版社，1998.5.3. 軟件開發(fā)規(guī)范，航空工業(yè)標(biāo)準(zhǔn)6464-905 測(cè)試與開發(fā)的配合目前，質(zhì)量部已經(jīng)裝備測(cè)試工作專用的工具“輔助測(cè)試系統(tǒng)1.0”，因此測(cè)試與開發(fā)的配合將結(jié)合此工具展開；并且質(zhì)量部已經(jīng)有自己專用的測(cè)試服務(wù)器，從而可以大體上做到測(cè)試與開發(fā)獨(dú)立進(jìn)行。本文件中規(guī)定的流程就是按照這個(gè)思想形成。由于目前公司自主開發(fā)的軟件產(chǎn)品基本上都是基于客戶機(jī)/服務(wù)器模式，因此，要做到測(cè)試與開發(fā)獨(dú)立進(jìn)行，只需要把軟件用到的數(shù)據(jù)庫分開安裝到不同的服務(wù)器上就可以了，從而保證開發(fā)與測(cè)試不會(huì)產(chǎn)生數(shù)據(jù)沖突。如果是采用B/S結(jié)構(gòu)的軟件，只需

7、要在開發(fā)部的服務(wù)器上建立一個(gè)可執(zhí)行包就可以了；在必要的情況下，也可同時(shí)在質(zhì)量部服務(wù)器上建立可執(zhí)行包。在此系統(tǒng)的基礎(chǔ)之上，又采取用Microsoft SourceSafe6.0來對(duì)開發(fā)文檔和軟件進(jìn)行管理，從而減少了文檔傳遞失誤的機(jī)會(huì)，提高了測(cè)試自動(dòng)化的程度，也降低了測(cè)試人員的工作量。5.1 文檔和軟件保存目錄公司目前采取的開發(fā)方式，用SourceSafe來對(duì)整個(gè)開發(fā)的產(chǎn)品來進(jìn)行管理，因此對(duì)于測(cè)試人員來說，不必再單獨(dú)對(duì)開發(fā)文檔、軟件模塊進(jìn)行復(fù)制和保存，測(cè)試服務(wù)器上的共享目錄只是用于保存最終發(fā)行的軟件產(chǎn)品。共享目錄在項(xiàng)目開始階段由測(cè)試小組的負(fù)責(zé)人在質(zhì)量部專用的測(cè)試服務(wù)器上建立，并由測(cè)試負(fù)責(zé)人在整個(gè)項(xiàng)

8、目期間進(jìn)行維護(hù)。共享目錄的內(nèi)容包括評(píng)審?fù)ㄟ^的最終軟件（源代碼和可執(zhí)行文件）、各種開發(fā)文檔（包括測(cè)試文檔）。最終的共享目錄TsPrjName的結(jié)構(gòu)如下所示：TsPrjName子目錄“開發(fā)文檔”子目錄“最終軟件”具體的建立規(guī)則如下：1 假設(shè)項(xiàng)目中文簡(jiǎn)稱為PrjName, 則共享目錄的名字必須是TsPrjName。如項(xiàng)目簡(jiǎn)稱為“寶開二期”，則共享目錄的名字就是“Ts寶開二期”。2 子目錄“開發(fā)文檔”用于存放開發(fā)人員傳遞到測(cè)試組的所有“完整的”開發(fā)文檔，這里的“完整”指經(jīng)過公司技術(shù)委員會(huì)評(píng)審確認(rèn)的、能獨(dú)立向所有使用者發(fā)行的文檔。當(dāng)不同的文檔使用人員對(duì)其內(nèi)容產(chǎn)生歧義時(shí)，都以這里保存的文檔作為仲裁依據(jù)。其

9、二級(jí)子目錄可以分為規(guī)格說明、需求分析、概要設(shè)計(jì)等等，由開發(fā)人員和測(cè)試人員商量決定。3 子目錄“最終軟件”存放已經(jīng)通過內(nèi)部評(píng)審的軟件，如果軟件是分為幾個(gè)階段開發(fā)的，并且每個(gè)階段的產(chǎn)品都要發(fā)行給用戶，則測(cè)試員必須備份每個(gè)階段最終發(fā)行給用戶的產(chǎn)品。5.2 輔助工具的使用輔助工具目前有兩個(gè)：輔助測(cè)試系統(tǒng)1.0和Microsoft SourceSafe6.0。5.2.1 輔助測(cè)試系統(tǒng)1.0輔助測(cè)試系統(tǒng)1.0是一個(gè)B/S系統(tǒng)，通過IExplorer訪問，建立在質(zhì)量部服務(wù)器上，由質(zhì)量部維護(hù)，使用人員通過在IE地址欄中輸入http:/qa-bck/test/訪問。輔助測(cè)試系統(tǒng)的用戶必須在該系統(tǒng)中具有用戶賬號(hào)，

10、否則無法使用。輔助測(cè)試系統(tǒng)中的使用人員共分為六種身份：測(cè)試主管，測(cè)試員，項(xiàng)目經(jīng)理，程序員、領(lǐng)導(dǎo)和超級(jí)用戶。相同的用戶賬號(hào)只能具有一種身份，所有的用戶只能由超級(jí)用戶建立。通過輔助測(cè)試系統(tǒng)，用戶可以查閱到當(dāng)前項(xiàng)目中程序員的送測(cè)信息和模塊的送測(cè)情況，可以隨時(shí)了解程序中仍然存在的BUG信息，并可以看到查詢出來的信息的統(tǒng)計(jì)結(jié)果。除了領(lǐng)導(dǎo)和超級(jí)用戶身份以外，對(duì)于其它身份登陸的用戶，系統(tǒng)具有自動(dòng)提醒功能，既登陸后系統(tǒng)可以自動(dòng)提醒用戶現(xiàn)在需要處理的一些工作。所以，要求處于測(cè)試中的程序的相關(guān)人員，如項(xiàng)目經(jīng)理、程序員、測(cè)試主管和測(cè)試員等，每天都必須在不同時(shí)段登陸本系統(tǒng)至少三次以上。5.2.2 Microsoft

11、SourceSafe6.0使用SourceSafe6.0的主要作用在于能減少文檔的傳遞次數(shù)，從而能有效的降低文檔的不一致性，提高文檔的及時(shí)性和有效性。開發(fā)人員使用SourceSafe6.0可以保證所有人員包括測(cè)試人員看到的是同一個(gè)版本的文檔，從而避免理解上的偏差。SourceSafe6.0的服務(wù)器建立在開發(fā)部門的服務(wù)器上，由開發(fā)部門維護(hù)，測(cè)試人員對(duì)其數(shù)據(jù)庫的訪問由項(xiàng)目經(jīng)理控制。測(cè)試人員通過計(jì)算機(jī)上的SourceSafe客戶端對(duì)服務(wù)器上的數(shù)據(jù)庫進(jìn)行訪問。測(cè)試人員在測(cè)試過程中形成的測(cè)試文檔，也應(yīng)當(dāng)按照項(xiàng)目經(jīng)理指定的目錄保存在SourceSafe里面，這樣既方便了同開發(fā)人員之間的交流，也使得所有項(xiàng)目

12、產(chǎn)品有了一個(gè)統(tǒng)一的存放地點(diǎn)。對(duì)SourceSafe中保存的其他開發(fā)文檔和軟件產(chǎn)品，原則上測(cè)試人員都只能讀而不能寫，比如對(duì)于文檔和軟件產(chǎn)品只能使用“get last version”命令來進(jìn)行閱讀，測(cè)試人員在得到這些產(chǎn)品以后，都不必再把它們放回去。不同的測(cè)試人員只能對(duì)他/她自己負(fù)責(zé)測(cè)試的部分具有讀的權(quán)利，對(duì)于其它項(xiàng)目的軟件產(chǎn)品和文檔，不具有訪問的權(quán)利。5.3 開發(fā)與測(cè)試配合的流程è 開發(fā)人員在輔助測(cè)試系統(tǒng)中填寫送測(cè)單，提交待測(cè)模塊代碼、可執(zhí)行文件和相應(yīng)的設(shè)計(jì)文檔給項(xiàng)目經(jīng)理確認(rèn)。è 項(xiàng)目經(jīng)理檢查送測(cè)單上的內(nèi)容后，執(zhí)行確認(rèn)工作，并將打包好的可執(zhí)行代碼發(fā)布到開發(fā)部服務(wù)器的Sourc

13、eSafe中（如果是B/S結(jié)構(gòu)的軟件，要把可執(zhí)行代碼發(fā)布到IIS上），將相關(guān)的數(shù)據(jù)庫發(fā)布到質(zhì)量部服務(wù)器上。è 測(cè)試人員接受送測(cè)單后，從SourceSafe中獲得程序代碼，開始測(cè)試。測(cè)試包括兩方面的內(nèi)容：一是代碼走查工作，其次是功能測(cè)試工作。è 代碼走查以公司下發(fā)的編碼規(guī)范及管理辦法為檢查依據(jù)。如果在本次送測(cè)的某個(gè)模塊中的代碼走查中發(fā)現(xiàn)存在5個(gè)以上違反編碼規(guī)范的地方，則將該模塊返回給程序員重新送測(cè)，本模塊的測(cè)試結(jié)束，繼續(xù)下一個(gè)模塊的測(cè)試。如果所有模塊都不能通過代碼走查工作，則本次測(cè)試全部結(jié)束，不必再進(jìn)行下一步的功能測(cè)試。è 功能測(cè)試以公司下發(fā)的質(zhì)量部測(cè)試管理辦法為測(cè)

14、試依據(jù)。測(cè)試人員應(yīng)當(dāng)嚴(yán)格按照管理辦法上的相關(guān)規(guī)定開展工作，并認(rèn)真完成BUG紀(jì)錄的填寫。完成測(cè)試后，將BUG單傳遞給測(cè)試主管確認(rèn)。è 測(cè)試人員測(cè)試完成后，測(cè)試主管必須對(duì)BUG單執(zhí)行“驗(yàn)證”過程，即檢驗(yàn)BUG單上描寫的BUG是否都是正確的。驗(yàn)證完以后，測(cè)試主管將BUG單返回給程序員。è 程序員對(duì)BUG單上的所有紀(jì)錄都必須認(rèn)真處理后，再把BUG單連同修改完成的軟件產(chǎn)品一起返回給測(cè)試員進(jìn)行回歸測(cè)試。對(duì)于具體的使用輔助測(cè)試系統(tǒng)的開發(fā)與測(cè)試配合的工作流程可以參見輔助測(cè)試系統(tǒng)使用手冊(cè)（由開發(fā)2部負(fù)責(zé)編寫，預(yù)計(jì)會(huì)在8月初完成），也可以參見qawangl軟件測(cè)試測(cè)試流程圖。. 送測(cè)單送測(cè)單用

15、于開發(fā)人員向測(cè)試人員提交被測(cè)軟件，由程序員填寫并通過項(xiàng)目經(jīng)理傳遞到測(cè)試人員。在輔助測(cè)試系統(tǒng)中，已經(jīng)將送測(cè)單的填寫集成進(jìn)去了，這里給出送測(cè)單的主要元素及其填寫方法。如果在輔助測(cè)試系統(tǒng)中的送測(cè)單的形式與這里列出的不同，請(qǐng)參考本文件的規(guī)定執(zhí)行。送測(cè)單的形式如下所示：送測(cè)單項(xiàng)目名稱送測(cè)模塊送測(cè)階段項(xiàng)目經(jīng)理送測(cè)人送測(cè)日期版本號(hào)工程文件路徑和名字可執(zhí)行文件路徑和名字軟件配置測(cè)試要求（重點(diǎn)）：收測(cè)人收測(cè)日期6.1送測(cè)單的填寫其填寫規(guī)則約定如下：1 項(xiàng)目名稱、送測(cè)內(nèi)容、送測(cè)人和送測(cè)日期等四個(gè)字段由送測(cè)人填寫。送測(cè)內(nèi)容指的是本次送測(cè)的程序模塊。在輔助測(cè)試系統(tǒng)中，項(xiàng)目名稱和模塊名稱由項(xiàng)目經(jīng)理加入，程序員在填寫送測(cè)

16、單時(shí)只需要選擇就可以了；而送測(cè)人和送測(cè)日期兩個(gè)字段系統(tǒng)可以根據(jù)用戶登陸信息自動(dòng)添加。2 項(xiàng)目經(jīng)理字段在項(xiàng)目經(jīng)理確認(rèn)了本送測(cè)單填寫的所有內(nèi)容都正確無誤之后，由本人填寫。在輔助測(cè)試系統(tǒng)中，項(xiàng)目經(jīng)理要對(duì)送測(cè)單的處理方式做出選擇，可供選擇的項(xiàng)有不處理、打回和通過，還有一個(gè)備注字段可供項(xiàng)目經(jīng)理填寫個(gè)人意見。3 送測(cè)階段指的是當(dāng)前測(cè)試的階段，由程序員填寫。輔助測(cè)試系統(tǒng)中可供選擇的項(xiàng)有單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、安裝測(cè)試和發(fā)行測(cè)試等。這里的階段由項(xiàng)目經(jīng)理和測(cè)試員共同確定后，通知每一個(gè)程序員。在每個(gè)階段中，對(duì)一個(gè)模塊只產(chǎn)生一個(gè)送測(cè)單和BUG單，當(dāng)送測(cè)單生成以后，BUG單隨即產(chǎn)生，在整個(gè)階段中，開發(fā)人員和測(cè)試

17、人員都只用這一張BUG單來交流。4 “工程文件路徑和名字”和“可執(zhí)行文件路徑和名字”兩個(gè)字段由程序員填寫，項(xiàng)目經(jīng)理必須檢查確認(rèn)這兩個(gè)字段所填寫的信息是否都是準(zhǔn)確無誤的。工程文件路徑和名字是指送測(cè)的模塊在SourceSafe中的路徑和具體的模塊名字?？蓤?zhí)行文件路徑指的是：如果本次送測(cè)的模塊要用IE打開，請(qǐng)?zhí)顚憺g覽器地址或超級(jí)聯(lián)接地址；如果是exe文件，請(qǐng)?zhí)顚懌@取的路徑和文件名稱。5 版本號(hào)字段請(qǐng)?zhí)顚懕敬嗡蜏y(cè)的模塊的版本號(hào)。單元測(cè)試中，版本號(hào)指的是本次送測(cè)的模塊的窗體的統(tǒng)一版本號(hào)；其他測(cè)試中，請(qǐng)?zhí)顚懕敬嗡蜏y(cè)的工程的版本號(hào)。6 軟件配置字段的填寫內(nèi)容有兩個(gè)，一是本模塊的相關(guān)設(shè)計(jì)文檔的位置、源代碼的位

18、置等；二是運(yùn)行本模塊需要的一些軟件設(shè)置，如環(huán)境參數(shù)設(shè)置、動(dòng)態(tài)聯(lián)接庫版本等。軟件配置字段由送測(cè)人和開發(fā)經(jīng)理共同確定并填寫。7 測(cè)試重點(diǎn)是指開發(fā)人員或客戶在使用本模塊時(shí)，對(duì)本模塊在穩(wěn)定性，可靠性，易用性等任何本模塊應(yīng)該滿足的一些要求，比如對(duì)于“酒樓收銀”模塊，數(shù)據(jù)計(jì)算的正確性是應(yīng)該首先達(dá)到的最基本的要求。測(cè)試重點(diǎn)由送測(cè)人和項(xiàng)目經(jīng)理共同確定，并由送測(cè)人填寫。8 收測(cè)人和收測(cè)日期字段由被指定測(cè)試本模塊的測(cè)試員填寫。在輔助測(cè)試系統(tǒng)中，此部分是一個(gè)單獨(dú)的模塊，由測(cè)試員操作。6.2 工作流程è 開發(fā)人員填寫送測(cè)單，提交待測(cè)模塊和相應(yīng)的詳細(xì)設(shè)計(jì)文檔給項(xiàng)目經(jīng)理確認(rèn)。在輔助測(cè)試系統(tǒng)中，項(xiàng)目名稱和模塊名稱

19、都由超級(jí)用戶在系統(tǒng)管理模塊中添加，程序員在填寫送測(cè)單時(shí)只需要從列表框中選擇就可以了。但送測(cè)模塊的版本號(hào)由程序員自己填寫，而且必須填寫。è 項(xiàng)目經(jīng)理確認(rèn)所填信息都正確無誤，并且把可執(zhí)行文件在開發(fā)服務(wù)器上發(fā)布，數(shù)據(jù)庫文件同時(shí)發(fā)布到開發(fā)服務(wù)器和測(cè)試服務(wù)器上，對(duì)模塊進(jìn)行簡(jiǎn)單的試用之后，簽字送測(cè)。上述過程中任何一步出現(xiàn)問題，項(xiàng)目經(jīng)理都可把測(cè)試單打回給程序員，進(jìn)行重新送測(cè)。è 測(cè)試員在輔助測(cè)試系統(tǒng)的“送測(cè)單接收”模塊中收到送測(cè)單。è 測(cè)試員確認(rèn)需要的文檔資料和程序，簽收后根據(jù)測(cè)試重點(diǎn)開始測(cè)試，并填寫B(tài)UG單。如果這不是本模塊的第一次送測(cè)，測(cè)試員還應(yīng)當(dāng)驗(yàn)證一下上一次的BUG是否

20、都已經(jīng)全部處理了。BUG單每一個(gè)送測(cè)單將對(duì)應(yīng)的產(chǎn)生一個(gè)BUG單。BUG單由測(cè)試員填寫后交開發(fā)人員處理，最終返回到測(cè)試員手中。BUG單模塊也已經(jīng)集成到輔助測(cè)試系統(tǒng)當(dāng)中了，這里給出BUG單的主要元素及其填寫方法。如果在輔助測(cè)試系統(tǒng)中BUG單的形式與這里列出的不同，請(qǐng)參考本文件的規(guī)定執(zhí)行。BUG單的形式如下：Bug 單項(xiàng)目名稱被測(cè)模塊項(xiàng)目經(jīng)理送測(cè)版本送測(cè)人測(cè)試員驗(yàn)證人收測(cè)日期最后修改日期修訂版本BUG描述BUG類別BUG級(jí)別BUG處理備注7.1 BUG單的填寫在輔助測(cè)試系統(tǒng)中，一旦測(cè)試員接收了送測(cè)單，對(duì)應(yīng)的BUG單會(huì)自動(dòng)產(chǎn)生，因此在上面的BUG單中基本上測(cè)試員只需要填寫B(tài)UG描述、BUG類別和BUG

21、級(jí)別字段，而送測(cè)的程序員只需要填寫修訂版本和BUG處理就行了。填寫規(guī)則規(guī)定如下：1 BUG描述和BUG級(jí)別兩個(gè)字段由測(cè)試員填寫。1）對(duì)發(fā)現(xiàn)的BUG按測(cè)試發(fā)現(xiàn)的順序排序。BUG描述可以分三種形式：一是BUG；二是問題；三是建議。BUG和問題的描述中，操作步驟和BUG現(xiàn)象用“=”加以區(qū)分，“=”以前是重復(fù)本問題的步驟，以后是測(cè)試員認(rèn)為不對(duì)的地方。建議的描述可以直接寫出來，不必用“=”加以區(qū)分。2）對(duì)每一個(gè)BUG的評(píng)級(jí)工作由測(cè)試員完成并由驗(yàn)證人加以確認(rèn)。BUG按其嚴(yán)重性級(jí)別來評(píng)級(jí)，共分A、B、C、D、E五級(jí)（參見本文第9.3節(jié)表1中的描述），在系統(tǒng)提供的列表框中選擇。對(duì)于問題和建議，它們的級(jí)別應(yīng)當(dāng)選

22、擇為“未定義”。2 對(duì)于每一條BUG，除了判定它的級(jí)別以外，還要判定BUG的技術(shù)分類：功能性錯(cuò)誤、系統(tǒng)錯(cuò)誤、邏輯錯(cuò)誤、用戶界面錯(cuò)誤、數(shù)據(jù)錯(cuò)誤和編碼錯(cuò)誤等，以及問題和建議，由測(cè)試員根據(jù)實(shí)際情況做出選擇。3 BUG處理一欄由開發(fā)人員填寫。對(duì)BUG描述一欄中的每一條，開發(fā)人員都要做出相應(yīng)的回答并給出是否已修改或者暫不修改的理由。對(duì)BUG和問題的回答有三種方式：一是“已修改”；二是“暫不修改”；三是“不存在”。對(duì)于后兩種回答都必須給出相應(yīng)的理由。一個(gè)BUG是否暫不修改必須由項(xiàng)目經(jīng)理審查并確認(rèn)。對(duì)于建議的回答有兩種方式：“采用”和“不采用”，可酌情給出解釋或不給出解釋。4 備注字段在開發(fā)人員向測(cè)試人員解

23、釋自己的回答時(shí)由開發(fā)人員填寫，也可在測(cè)試人員向開發(fā)人員詳細(xì)解釋BUG描寫的時(shí)候填寫。5 開發(fā)人員處理完BUG單上所有的BUG后，要將修訂BUG后的模塊和BUG單分別傳遞給項(xiàng)目經(jīng)理和測(cè)試人員，這時(shí)如果不是進(jìn)入下一個(gè)測(cè)試階段，就不必再填寫新的送測(cè)單，只需要重新發(fā)布新的代碼和可執(zhí)行文件。但必須更新BUG單上的“修訂版本”字段。6 測(cè)試員接到程序員處理過的BUG單后，首先驗(yàn)證新的模塊版本號(hào)是否和BUG單上的“修訂版本”字段相同。如果是，則測(cè)試員驗(yàn)證是否按照處理方法的描述解決了所有問題；否則將BUG單再次返回給程序員。其次，測(cè)試員要測(cè)試模塊是否產(chǎn)生了新的BUG。7 對(duì)于確定已經(jīng)修改成功的BUG，測(cè)試員要

24、將BUG的狀態(tài)置為“CLOSE”；如果一張BUG單上的所有紀(jì)錄都已經(jīng)CLOSE，則測(cè)試人員可以將本BUG單的狀態(tài)置為CLOSE，這樣此張BUG單將退出測(cè)試流程，輔助測(cè)試系統(tǒng)提供選項(xiàng)可使BUG單再重新進(jìn)入測(cè)試流程；此時(shí)測(cè)試員應(yīng)當(dāng)保存模塊的修訂版本，并口頭通知開發(fā)人員。7.2 工作流程è 測(cè)試員在輔助測(cè)試系統(tǒng)的BUG單填寫模塊中，驗(yàn)證程序的版本號(hào)是否和BUG單上的送測(cè)版本號(hào)相同（如果不是第一次送測(cè)，這里應(yīng)當(dāng)對(duì)比修訂版本號(hào)）。不相同就把BUG單打回給程序員。è 如果不是第一次送測(cè)，測(cè)試員根據(jù)BUG的處理情況驗(yàn)證程序員對(duì)上一次測(cè)試所發(fā)現(xiàn)的BUG的修改情況，并把已經(jīng)修改完成的BUG的

25、狀態(tài)置為CLOSE。否則繼續(xù)下一步。è 測(cè)試員根據(jù)送測(cè)單上的測(cè)試重點(diǎn)設(shè)計(jì)或選取測(cè)試用例。è 測(cè)試員根據(jù)測(cè)試用例做測(cè)試，將發(fā)現(xiàn)的BUG現(xiàn)象填入對(duì)應(yīng)的BUG單中。è 測(cè)試員提交BUG單給測(cè)試主管進(jìn)行驗(yàn)證并由測(cè)試主管傳遞給程序員。è 程序員確認(rèn)BUG，并將處理意見填入BUG紀(jì)錄的備注字段中。è 程序員返還BUG單給測(cè)試人員。è 如果本BUG單已經(jīng)CLOSE，則由測(cè)試人員口頭通知程序員，否則重復(fù)以上的步驟。測(cè)試階段的結(jié)束測(cè)試以本階段所有已開發(fā)模塊都經(jīng)過測(cè)試，并且仍存在的BUG數(shù)量滿足國標(biāo)中的規(guī)定為本階段的結(jié)束，也可以根據(jù)實(shí)際情況由軟件開發(fā)部門

26、的經(jīng)理、項(xiàng)目經(jīng)理和測(cè)試主管共同確定本階段是否結(jié)束。本階段的測(cè)試工作結(jié)束后，測(cè)試主管（或其指定人員）應(yīng)該提交一份本階段的測(cè)試報(bào)告。內(nèi)容包括對(duì)當(dāng)前版本軟件已測(cè)模塊的測(cè)試評(píng)估，已發(fā)現(xiàn)BUG的分類統(tǒng)計(jì)，未修改的BUG及其原因，當(dāng)前的測(cè)試工作的總結(jié)等。測(cè)試報(bào)告提交后，項(xiàng)目經(jīng)理、開發(fā)部門經(jīng)理、質(zhì)量部經(jīng)理以及公司的技術(shù)委員會(huì)將審閱或簽字確認(rèn)，并將成為軟件是否可發(fā)行的參考資料之一。. 備注以下內(nèi)容屬于流程之中的一些原則和測(cè)試工作中的一些做法，寫在這里供開發(fā)人員參考。9.1 開發(fā)階段與測(cè)試階段測(cè)試階段對(duì)應(yīng)于開發(fā)過程中的編碼階段，每一個(gè)相對(duì)獨(dú)立的編碼階段都可以形成一個(gè)測(cè)試階段，比如單元測(cè)試、集成測(cè)試等。編碼階段的

27、劃分由開發(fā)組和項(xiàng)目經(jīng)理負(fù)責(zé)，各階段的完成標(biāo)志應(yīng)當(dāng)明確的告知測(cè)試組，以利于測(cè)試組在測(cè)試計(jì)劃中分階段的安排測(cè)試工作、設(shè)計(jì)測(cè)試用例和調(diào)配測(cè)試資源。9.2 待測(cè)模塊的組合與測(cè)試原則開發(fā)組應(yīng)當(dāng)首先完成軟件的核心模塊，和軟件的主界面設(shè)計(jì)。每一次軟件送測(cè)時(shí)，把已完成并通過開發(fā)組內(nèi)部測(cè)試的模塊聯(lián)編入核心模塊中送測(cè)，已經(jīng)通過測(cè)試的模塊不應(yīng)當(dāng)被取出。測(cè)試組在測(cè)試時(shí)，重點(diǎn)測(cè)試本次送測(cè)新添加的模塊。對(duì)于已測(cè)試過的模塊，可以酌情加以發(fā)揮性的測(cè)試，但在所有的測(cè)試階段之后，每個(gè)模塊至少保證測(cè)試過兩遍以上。9.3 BUG的分類評(píng)級(jí)原則BUG 的大小、嚴(yán)重性在不同的系統(tǒng)中相差很多，最嚴(yán)重的BUG 會(huì)讓開發(fā)者立刻放下手中的其他事

28、來改正它們。不太嚴(yán)重的則是在時(shí)間和資源允許的情況下才去理會(huì)它們。BUG按其嚴(yán)重性可以分為以下幾類：表1 按嚴(yán)重性劃分BUG嚴(yán)重等級(jí)描述A極嚴(yán)重1）可能有災(zāi)難性的后果或是會(huì)出人命的2) 故意留有程序后門B嚴(yán)重產(chǎn)生錯(cuò)誤的結(jié)果，導(dǎo)致系統(tǒng)不穩(wěn)定的問題1）造成數(shù)據(jù)庫不穩(wěn)定的錯(cuò)誤；2）系統(tǒng)崩潰，無法繼續(xù)操作3）列在說明中的需求未在最終系統(tǒng)中實(shí)現(xiàn)4）業(yè)務(wù)流程不正確C中等的不正確的，但不會(huì)影響系統(tǒng)穩(wěn)定性的1） 過程調(diào)用或其它腳本錯(cuò)誤；2） 打印錯(cuò)誤或打印出來的結(jié)果與用戶的要求不一致3） 系統(tǒng)刷新錯(cuò)誤；4） 產(chǎn)生錯(cuò)誤結(jié)果，如計(jì)算結(jié)果錯(cuò)誤等5） 功能的實(shí)現(xiàn)有問題。如在系統(tǒng)實(shí)現(xiàn)的界面上，一些可接受輸入的控件點(diǎn)擊后無

29、作用；對(duì)數(shù)據(jù)庫的操作不能正確實(shí)現(xiàn)6） 編碼時(shí)數(shù)據(jù)類型、長(zhǎng)度定義錯(cuò)誤的；7） 對(duì)用戶的使用有操作順序上的限制8） 雖然正確性不受影響，但系統(tǒng)性能和響應(yīng)時(shí)間受到影響D一般性的不正確的，但是沒有特別損害的輸出，或者使系統(tǒng)使用起來不太方便的錯(cuò)誤1）系統(tǒng)的提示語不明確，不簡(jiǎn)明2）滾動(dòng)條無效3）可編輯區(qū)和不可編輯區(qū)不明顯，4）光標(biāo)跳轉(zhuǎn)設(shè)置不好，鼠標(biāo)（光標(biāo)）定位錯(cuò)誤；5）對(duì)庫記錄指針，方向鍵無效時(shí)沒有變灰6）界面不一致，或界面不正確E輕微的1）日期或時(shí)間初始值錯(cuò)誤（起止日期、時(shí)間沒有限定）2）按鈕或標(biāo)簽上有拼寫錯(cuò)誤的單詞、不正確的大小寫除了按嚴(yán)重性來分類，BUG還可以按技術(shù)種類分為以下幾類：表2 按技術(shù)種類劃分BUG類別描述功能性錯(cuò)誤列在說明中的需