軟件開發(fā)與測試工作流程

軟件開發(fā)與測試

工作流程

版本2.0XXX軟件股份有限公司質量部XXXX年XX月1．簡介 錯誤！未定義書簽。2．適用范圍 錯誤！未定義書簽3．術語、名詞定義 錯誤！未定義書簽3.1送測軟件 錯誤！未定義書簽3.2開發(fā)文檔 錯誤！未定義書簽3.3測試文檔 錯誤！未定義書簽3.4被測程序 錯誤！未定義書簽3.5送測單 錯誤！未定義書簽BUG單 錯誤！未定義書簽。測試循環(huán) 錯誤！未定義書簽4．參考文獻 錯誤！未定義書簽5．測試與開發(fā)的配合 錯誤！未定義書簽文檔和軟件保存目錄 錯誤！未定義書簽輔助工具的使用 錯誤！未定義書簽輔助測試系統(tǒng)1.0 錯誤！未定義書簽SourceSafe6.0 錯誤！未定義書簽開發(fā)與測試配合的流程 錯誤！未定義書簽.送測單 錯誤！未定義書簽送測單的填寫 錯誤！未定義書簽工作流程 錯誤！未定義書簽．BUG單 錯誤！未定義書簽BUG單的填寫 錯誤！未定義書簽。工作流程 錯誤！未定義書簽．測試階段的結束 錯誤！未定義書簽.備注 錯誤！未定義書簽開發(fā)階段與測試階段 錯誤！未定義書簽待測模塊的組合與測試原則 錯誤！未定義書簽BUG的分類評級原則 錯誤！未定義書簽。9.4國標中有關BUG數量的描述 錯誤！未定義書簽。9.5測試階段的劃分 錯誤！未定義書簽1．簡介本流程文件旨在規(guī)定一個簡單的可使開發(fā)人員和測試人員在軟件開發(fā)的編碼階段相互配合工作的工作流程，其中包括測試與開發(fā)的配合、送測單和BUG單的填寫、測試循環(huán)的結束等部分。開發(fā)階段與測試循環(huán)的關系、測試模塊的組合與測試原則、BUG的分類評級原則等也在本流程文件中有相關的描述。鑒于公司的技術要求，目前質量部的測試人員不僅要完成黑盒測試工作，而且還要進行白盒測試中的“代碼走查”工作。其它的白盒測試工作，目前還不在測試人員的工作職責之內。由于公司已經為質量管理部開發(fā)完成“輔助測試系統(tǒng)1.0”，因此本測試流程的制定就建立在輔助測試系統(tǒng)之上，如果輔助測試系統(tǒng)有了新的版本，質量部將根據其變化適當調整測試流程。2．適用范圍本流程文件適用于公司開發(fā)軟件并需要測試服務的任何軟件開發(fā)項目組、軟件開發(fā)人員，以及任何測試人員。當項目組在輔助測試系統(tǒng)中注冊以后，公司領導可以使用本系統(tǒng)查詢了解所有在本系統(tǒng)中注冊的項目的測試信息，項目的質量管理員可以使用本系統(tǒng)查詢了解項目的當前測試進展情況。程序員和測試員都可以使用本系統(tǒng)查詢到自己產生的送測單和BUG單。3．術語、名詞定義送測軟件送測軟件包括一切軟件執(zhí)行必須的文件、數據、數據庫配置等。開發(fā)人員必須提供所有的詳細的資料以保證測試人員可以像客戶一樣的運行被測軟件。3.2開發(fā)文檔開發(fā)人員提供給測試人員的開發(fā)文檔至少包括以下幾種：用戶需求，概要設計，詳細設計，用戶手冊等。開發(fā)人員應當在開發(fā)每階段完成后三天內就向測試人員傳送本階段完成的開發(fā)文檔，以利于測試人員的工作。3.3測試文檔測試文檔包括測試計劃、測試用例說明、BUG報告及分析、測試總結，以及測試工作全部完成后的測試報告等。測試文檔由測試人員編寫并維護，也屬于開發(fā)文檔的一部分。3.4被測程序被測程序指的是開發(fā)人員提交測試的軟件可執(zhí)行的部分。被測程序應當既包括單獨的工程文件，以便測試人員進行代碼走查工作；而且還要包括已經編譯打包好的可執(zhí)行文件。3.5送測單送測單是指開發(fā)人員向測試人員提交被測軟件時必須填寫的提交報告。開發(fā)人員應當謹慎填寫送測單上的被測程序的版本號，保證和被測程序的版本號一致。送測單必須有送測重點，以利于測試人員工作。3.6BUG單BUG單是指測試人員在測試完成后，向開發(fā)人員提交的BUG匯總報告。開發(fā)人員確認并修改BUG后，必須填入修改意見并將BUG單返回給測試人員以驗證是否修改成功。3.7測試循環(huán)測試循環(huán)是指從軟件單元/模塊的第一次提交測試到本編碼階段結束中間經過的所有的有關的測試行為和過程。其開始的標志是本階段的第一份提交的送測單，其結束標志是測試總結或測試報告的提交和審批通過。4．參考文獻計算機軟件測試文件編制規(guī)范，GB9386-88vv客戶機/服務器系統(tǒng)測試>>,（美）Bourne,K.C.著，機械工業(yè)出版社,1998.5.軟件開發(fā)規(guī)范，航空工業(yè)標準6464-905．測試與開發(fā)的配合目前，質量部已經裝備測試工作專用的工具“輔助測試系統(tǒng)1.0”，因此測試與開發(fā)的配合將結合此工具展開；并且質量部已經有自己專用的測試服務器，從而可以大體上做到測試與開發(fā)獨立進行。本文件中規(guī)定的流程就是按照這個思想形成。由于目前公司自主開發(fā)的軟件產品基本上都是基于客戶機/服務器模式，因此，要做到測試與開發(fā)獨立進行，只需要把軟件用到的數據庫分開安裝到不同的服務器上就可以了，從而保證開發(fā)與測試不會產生數據沖突。如果是采用B/S結構的軟件，只需要在開發(fā)部的服務器上建立一個可執(zhí)行包就可以了；在必要的情況下，也可同時在質量部服務器上建立可執(zhí)行包。在此系統(tǒng)的基礎之上，又采取用MicrosoftSourceSafe6.0來對開發(fā)文檔和軟件進行管理，從而減少了文檔傳遞失誤的機會，提高了測試自動化的程度，也降低了測試人員的工作量。文檔和軟件保存目錄公司目前采取的開發(fā)方式，用SourceSafe來對整個開發(fā)的產品來進行管理，因此對于測試人員來說，不必再單獨對開發(fā)文檔、軟件模塊進行復制和保存，測試服務器上的共享目錄只是用于保存最終發(fā)行的軟件產品。共享目錄在項目開始階段由測試小組的負責人在質量部專用的測試服務器上建立，并由測試負責人在整個項目期間進行維護。共享目錄的內容包括評審通過的最終軟件（源代碼和可執(zhí)行文件）、各種開發(fā)文檔（包括測試文檔）。最終的共享目錄TsPrjName的結構如下所示：具體的建立規(guī)則如下：假設項目中文簡稱為PrjName,則共享目錄的名字必須是TsPrjName。如項目簡稱為“寶開二期”，則共享目錄的名字就是“Ts寶開二期”子目錄“開發(fā)文檔”用于存放開發(fā)人員傳遞到測試組的所有“完整的”開發(fā)文檔，這里的“完整”指經過公司技術委員會評審確認的、能獨立向所有使用者發(fā)行的文檔。當不同的文檔使用人員對其內容產生歧義時，都以這里保存的文檔作為仲裁依據。其二級子目錄可以分為規(guī)格說明、需求分析、概要設計等等，由開發(fā)人員和測試人員商量決定。子目錄“最終軟件”存放已經通過內部評審的軟件，如果軟件是分為幾個階段開發(fā)的，并且每個階段的產品都要發(fā)行給用戶，則測試員必須備份每個階段最終發(fā)行給用戶的產品。5.2輔助工具的使用輔助工具目前有兩個：輔助測試系統(tǒng)1.0和MicrosoftSourceSafe6.0。5.2.1輔助測試系統(tǒng)1.0輔助測試系統(tǒng)1.0是一個B/S系統(tǒng)，通過【Explorer訪問，建立在質量部服務器上，由質量部維護，使用人員通過在IE地址欄中輸入http://qa-bck/test/訪問。輔助測試系統(tǒng)的用戶必須在該系統(tǒng)中具有用戶賬號，否則無法使用。輔助測試系統(tǒng)中的使用人員共分為六種身份：測試主管，測試員，項目經理，程序員、領導和超級用戶。相同的用戶賬號只能具有一種身份，所有的用戶只能由超級用戶建立。通過輔助測試系統(tǒng)，用戶可以查閱到當前項目中程序員的送測信息和模塊的送測情況，可以隨時了解程序中仍然存在的BUG信息，并可以看到查詢出來的信息的統(tǒng)計結果。除了領導和超級用戶身份以外，對于其它身份登陸的用戶，系統(tǒng)具有自動提醒功能，既登陸后系統(tǒng)可以自動提醒用戶現在需要處理的一些工作。所以，要求處于測試中的程序的相關人員，如項目經理、程序員、測試主管和測試員等，每天都必須在不同時段登陸本系統(tǒng)至少三次以上。5.2.2MicrosoftSourceSafe6.0使用SourceSafe6.0的主要作用在于能減少文檔的傳遞次數，從而能有效的降低文檔的不一致性，提高文檔的及時性和有效性。開發(fā)人員使用SourceSafe6.0可以保證所有人員包括測試人員看到的是同一個版本的文檔，從而避免理解上的偏差。SourceSafe6.0的服務器建立在開發(fā)部門的服務器上，由開發(fā)部門維護，測試人員對其數據庫的訪問由項目經理控制。測試人員通過計算機上的SourceSafe客戶端對服務器上的數據庫進行訪問。測試人員在測試過程中形成的測試文檔，也應當按照項目經理指定的目錄保存在SourceSafe里面，這樣既方便了同開發(fā)人員之間的交流，也使得所有項目產品有了一個統(tǒng)一的存放地點。對SourceSafe中保存的其他開發(fā)文檔和軟件產品，原則上測試人員都只能讀而不能寫，比如對于文檔和軟件產品只能使用"getlastversion”命令來進行閱讀，測試人員在得到這些產品以后，都不必再把它們放回去。不同的測試人員只能對他/她自己負責測試的部分具有讀的權利，對于其它項目的軟件產品和文檔，不具有訪問的權利。5.3開發(fā)與測試配合的流程9開發(fā)人員在輔助測試系統(tǒng)中填寫送測單，提交待測模塊代碼、可執(zhí)行文件和相應的設計文檔給項目經理確認。9項目經理檢查送測單上的內容后，執(zhí)行確認工作，并將打包好的可執(zhí)行代碼發(fā)布到開發(fā)部服務器的SourceSafe中（如果是B/S結構的軟件，要把可執(zhí)行代碼發(fā)布到IIS上），將相關的數據庫發(fā)布到質量部服務器上。9測試人員接受送測單后，從SourceSafe中獲得程序代碼，開始測試。測試包括兩方面的內容：一是代碼走查工作，其次是功能測試工作。9代碼走查以公司下發(fā)的《編碼規(guī)范及管理辦法》為檢查依據。如果在本次送測的某個模塊中的代碼走查中發(fā)現存在5個以上違反編碼規(guī)范的地方，則將該模塊返回給程序員重新送測，本模塊的測試結束，繼續(xù)下一個模塊的測試。如果所有模塊都不能通過代碼走查工作，則本次測試全部結束，不必再進行下一步的功能測試。9功能測試以公司下發(fā)的《質量部測試管理辦法》為測試依據。測試人員應當嚴格按照管理辦法上的相關規(guī)定開展工作，并認真完成BUG紀錄的填寫。完成測試后，將BUG單傳遞給測試主管確認。9測試人員測試完成后，測試主管必須對BUG單執(zhí)行“驗證”過程，即檢驗BUG單上描寫的BUG是否都是正確的。驗證完以后，測試主管將BUG單返回給程序員。9程序員對BUG單上的所有紀錄都必須認真處理后，再把BUG單連同修改完成的軟件產品一起返回給測試員進行回歸測試。對于具體的使用輔助測試系統(tǒng)的開發(fā)與測試配合的工作流程可以參見《輔助測試系統(tǒng)使用手冊》（由開發(fā)2部負責編寫，預計會在8月初完成），也可以參見qa\wangl\軟件測試\測試流程圖\。6.送測單送測單用于開發(fā)人員向測試人員提交被測軟件，由程序員填寫并通過項目經理傳遞到測試人員。在輔助測試系統(tǒng)中，已經將送測單的填寫集成進去了，這里給出送測單的主要元素及其填寫方法。如果在輔助測試系統(tǒng)中的送測單的形式與這里列出的不同，請參考本文件的規(guī)定執(zhí)行。送測單的形式如下所示：送測單項目名稱送測模塊送測階段項目經理送測人送測日期版本號工程文件路徑和名字可執(zhí)行文件路徑和名字軟件配置測試要求（重點）：收測人收測日期6.1送測單的填寫其填寫規(guī)則約定如下：1．項目名稱、送測內容、送測人和送測日期等四個字段由送測人填寫。送測內容指的是本次送測的程序模塊。在輔助測試系統(tǒng)中，項目名稱和模塊名稱由項目經理加入，程序員在填寫送測單時只需要選擇就可以了；而送測人和送測日期兩個字段系統(tǒng)可以根據用戶登陸信息自動添加。2．項目經理字段在項目經理確認了本送測單填寫的所有內容都正確無誤之后，由本人填寫。在輔助測試系統(tǒng)中，項目經理要對送測單的處理方式做出選擇，可供選擇的項有不處理、打回和通過，還有一個備注字段可供項目經理填寫個人意見。3．送測階段指的是當前測試的階段，由程序員填寫。輔助測試系統(tǒng)中可供選擇的項有單元測試、集成測試、系統(tǒng)測試、安裝測試和發(fā)行測試等。這里的階段由項目經理和測試員共同確定后，通知每一個程序員。在每個階段中，對一個模塊只產生一個送測單和BUG單，當送測單生成以后，BUG單隨即產生，在整個階段中，開發(fā)人員和測試人員都只用這一張BUG單來交流。4．“工程文件路徑和名字”和“可執(zhí)行文件路徑和名字”兩個字段由程序員填寫，項目經理必須檢查確認這兩個字段所填寫的信息是否都是準確無誤的。工程文件路徑和名字是指送測的模塊在SourceSafe中的路徑和具體的模塊名字?？蓤?zhí)行文件路徑指的是：如果本次送測的模塊要用IE打開，請?zhí)顚憺g覽器地址或超級聯(lián)接地址；如果是exe文件，請?zhí)顚懌@取的路徑和文件名稱。5．版本號字段請?zhí)顚懕敬嗡蜏y的模塊的版本號。單元測試中，版本號指的是本次送測的模塊的窗體的統(tǒng)一版本號；其他測試中，請?zhí)顚懕敬嗡蜏y的工程的版本號。6．軟件配置字段的填寫內容有兩個，一是本模塊的相關設計文檔的位置、源代碼的位置等；二是運行本模塊需要的一些軟件設置，如環(huán)境參數設置、動態(tài)聯(lián)接庫版本等。軟件配置字段由送測人和開發(fā)經理共同確定并填寫。7．測試重點是指開發(fā)人員或客戶在使用本模塊時，對本模塊在穩(wěn)定性，可靠性，易用性等任何本模塊應該滿足的一些要求，比如對于“酒樓收銀”模塊，數據計算的正確性是應該首先達到的最基本的要求。測試重點由送測人和項目經理共同確定，并由送測人填寫。8．收測人和收測日期字段由被指定測試本模塊的測試員填寫。在輔助測試系統(tǒng)中，此部分是一個單獨的模塊，由測試員操作。工作流程9開發(fā)人員填寫送測單，提交待測模塊和相應的詳細設計文檔給項目經理確認。在輔助測試系統(tǒng)中，項目名稱和模塊名稱都由超級用戶在系統(tǒng)管理模塊中添加，程序員在填寫送測單時只需要從列表框中選擇就可以了。但送測模塊的版本號由程序員自己填寫，而且必須填寫。9項目經理確認所填信息都正確無誤，并且把可執(zhí)行文件在開發(fā)服務器上發(fā)布，數據庫文件同時發(fā)布到開發(fā)服務器和測試服務器上，對模塊進行簡單的試用之后，簽字送測。上述過程中任何一步出現問題，項目經理都可把測試單打回給程序員，進行重新送測。9測試員在輔助測試系統(tǒng)的“送測單接收”模塊中收到送測單。9測試員確認需要的文檔資料和程序，簽收后根據測試重點開始測試，并填寫B(tài)UG單。如果這不是本模塊的第一次送測，測試員還應當驗證一下上一次的BUG是否都已經全部處理了。7．BUG單每一個送測單將對應的產生一個BUG單。BUG單由測試員填寫后交開發(fā)人員處理，最終返回到測試員手中。BUG單模塊也已經集成到輔助測試系統(tǒng)當中了，這里給出BUG單的主要元素及其填寫方法。如果在輔助測試系統(tǒng)中BUG單的形式與這里列出的不同，請參考本文件的規(guī)定執(zhí)行。BUG單的形式如下：Bug單項目名稱被測模塊項目經理送測版本送測人測試員驗證人收測日期最后修改日期修訂版本BUG描述BUG類別BUG級別BUG處理備注1.7.1BUG單的填寫在輔助測試系統(tǒng)中，一旦測試員接收了送測單，對應的BUG單會自動產生,因此在上面的BUG單中基本上測試員只需要填寫B(tài)UG描述、BUG類別和BUG級別字段，而送測的程序員只需要填寫修訂版本和BUG處理就行了。填寫規(guī)則規(guī)定如下：BUG描述和BUG級別兩個字段由測試員填寫。1）對發(fā)現的BUG按測試發(fā)現的順序排序。BUG描述可以分三種形式：一是BUG；二是問題；三是建議。BUG和問題的描述中，操作步驟和BUG現象用“=〉”加以區(qū)分，“=〉”以前是重復本問題的步驟，以后是測試員認為不對的地方。建議的描述可以直接寫出來，不必用“=〉”加以區(qū)分。2）對每一個BUG的評級工作由測試員完成并由驗證人加以確認。BUG按其嚴重性級別來評級，共分A、B、C、D、E五級（參見本文第9.3節(jié)表1中的描述），在系統(tǒng)提供的列表框中選擇。對于問題和建議，它們的級別應當選擇為“未定義”。對于每一條BUG，除了判定它的級別以外，還要判定BUG的技術分類：功能性錯誤、系統(tǒng)錯誤、邏輯錯誤、用戶界面錯誤、數據錯誤和編碼錯誤等，以及問題和建議，由測試員根據實際情況做出選擇。BUG處理一欄由開發(fā)人員填寫。對BUG描述一欄中的每一條，開發(fā)人員都要做出相應的回答并給出是否已修改或者暫不修改的理由。對BUG和問題的回答有三種方式：一是“已修改”；二是“暫不修改”；三是“不存在”對于后兩種回答都必須給出相應的理由。一個BUG是否暫不修改必須由項目經理審查并確認。對于建議的回答有兩種方式：“采用”和“不采用”，可酌情給出解釋或不給出解釋。第13頁4．備注字段在開發(fā)人員向測試人員解釋自己的回答時由開發(fā)人員填寫，也可在測試人員向開發(fā)人員詳細解釋BUG描寫的時候填寫。開發(fā)人員處理完BUG單上所有的BUG后，要將修訂BUG后的模塊和BUG單分別傳遞給項目經理和測試人員，這時如果不是進入下一個測試階段，就不必再填寫新的送測單，只需要重新發(fā)布新的代碼和可執(zhí)行文件。但必須更新BUG單上的“修訂版本”字段。測試員接到程序員處理過的BUG單后，首先驗證新的模塊版本號是否和BUG單上的“修訂版本”字段相同。如果是，則測試員驗證是否按照處理方法的描述解決了所有問題;否則將BUG單再次返回給程序員。其次，測試員要測試模塊是否產生了新的BUG。對于確定已經修改成功的BUG，測試員要將BUG的狀態(tài)置為“CLOSE”；如果一張BUG單上的所有紀錄都已經CLOSE，則測試人員可以將本BUG單的狀態(tài)置為CLOSE，這樣此張BUG單將退出測試流程，輔助測試系統(tǒng)提供選項可使BUG單再重新進入測試流程;此時測試員應當保存模塊的修訂版本，并口頭通知開發(fā)人員。工作流程9測試員在輔助測試系統(tǒng)的BUG單填寫模塊中，驗證程序的版本號是否和BUG單上的送測版本號相同（如果不是第一次送測，這里應當對比修訂版本號）。不相同就把BUG單打回給程序員。9如果不是第一次送測，測試員根據BUG的處理情況驗證程序員對上一次測試所發(fā)現的BUG的修改情況，并把已經修改完成的BUG的狀態(tài)置為CLOSE。否則繼續(xù)下一步。9測試員根據送測單上的測試重點設計或選取測試用例。9測試員根據測試用例做測試，將發(fā)現的BUG現象填入對應的BUG單中。9測試員提交BUG單給測試主管進行驗證并由測試主管傳遞給程序員。9程序員確認BUG，并將處理意見填入BUG紀錄的備注字段中。9程序員返還BUG單給測試人員。9如果本BUG單已經CLOSE，則由測試人員口頭通知程序員，否則重復以上的步驟。8．測試階段的結束測試以本階段所有已開發(fā)模塊都經過測試，并且仍存在的BUG數量滿足國標中的規(guī)定為本階段的結束，也可以根據實際情況由軟件開發(fā)部門的經理、項目經理和測試主管共同確定本階段是否結束。本階段的測試工作結束后，測試主管（或其指定人員）應該提交一份本階段的測試報告。內容包括對當前版本軟件已測模塊的測試評估，已發(fā)現BUG的分類統(tǒng)計，未修改的BUG及其原因，當前的測試工作的總結等。測試報告提交后，項目經理、開發(fā)部門經理、質量部經理以及公司的技術委員會將審閱或簽字確認，并將成為軟件是否可發(fā)行的參考資料之一。9.備注以下內容屬于流程之中的一些原則和測試工作中的一些做法，寫在這里供開發(fā)人員參考。開發(fā)階段與測試階段測試階段對應于開發(fā)過程中的編碼階段，每一個相對獨立的編碼階段都可以形成一個測試階段，比如單元測試、集成測試等。編碼階段的劃分由開發(fā)組和項目經理負責，各階段的完成標志應當明確的告知測試組，以利于測試組在測試計劃中分階段的安排測試工作、設計測試用例和調配測試資源。待測模塊的組合與測試原則開發(fā)組應當首先完成軟件的核心模塊，和軟件的主界面設計。每一次軟件送測時，把已完成并通過開發(fā)組內部測試的模塊聯(lián)編入核心模塊中送測，已經通過測試的模塊不應當被取出。測試組在測試時，重點測試本次送測新添加的模塊。對于已測試過的模塊，可以酌情加以發(fā)揮性的測試，但在所有的測試階段之后，每個模塊至少保證測試過兩遍以上。9?3BUG的分類評級原則BUG的大小、嚴重性在不同的系統(tǒng)中相差很多，最嚴重的BUG會讓開發(fā)者立刻放下手中的其他事來改正它們。不太嚴重的則是在時間和資源允許的情況下才去理會它們。BUG按其嚴重性可以分為以下幾類：表1按嚴重性劃分BUG嚴重等級描 述A極嚴重1） 可能有災難性的后果或是會出人命的2） 故意留有程序后門B嚴重產生錯誤的結果，導致系統(tǒng)不穩(wěn)定的問題1） 造成數據庫不穩(wěn)定的錯誤；2） 系統(tǒng)崩潰，無法繼續(xù)操作3） 列在說明中的需求未在最終系統(tǒng)中實現4） 業(yè)務流程不正確C中等的不正確的，但不會影響系統(tǒng)穩(wěn)定性的1） 過程調用或其它腳本錯誤；2） 打印錯誤或打印出來的結果與用戶的要求不一致3） 系統(tǒng)刷新錯誤；4） 產生錯誤結果，如計算結果錯誤等5） 功能的實現有問題。如在系統(tǒng)實現的界面上，一些可接受輸入的控件點擊后無作用；對數據庫的操作不能正確實現6） 編碼時數據類型、長度定義錯誤的；7） 對用戶的使用有操作順序上的限制8） 雖然正確性不受影響，但系統(tǒng)性能和響應時間受到影響D一般性的不正確的，但是沒有特別損害的輸出，或者使系統(tǒng)使用起來不太方便的錯誤

1） 系統(tǒng)的提示語不明確，不簡明2） 滾動條無效3） 可編輯區(qū)和不可編輯區(qū)不明顯，4） 光標跳轉設置不好