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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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