標準軟件測試工作流程解析(2)

　　7、項目經(jīng)理對編碼完成后的系統進(jìn)行確認，確保提交測試的系統是可運行的，測試負責人(或專(zhuān)門(mén)的PPQA)確認所有文檔和代碼都已經(jīng)commit到CVS。

　　六、測試設計與評審(開(kāi)發(fā)階段)

　　1、 在項目編碼階段，測試方案編寫(xiě)完成后，測試負責人或相關(guān)測試人員根據測試方案、規范文檔、功能列表和詳細設計進(jìn)行測試用例設計;

　　2、 測試案例設計的類(lèi)型包括功能測試，邊界測試，異常測試，性能測試，壓力測試等，在用例設計中，除了功能測試案例外，應盡量考慮邊界、異常、性能的情況，以便發(fā)現更多的隱藏問(wèn)題;

　　3、 在編寫(xiě)測試案例的過(guò)程中，對于存在疑問(wèn)的地方或測試重點(diǎn)，主動(dòng)與開(kāi)發(fā)負責人或項目經(jīng)理溝通討論，一方面有助于設計完善的測試案例，另一方面也有助于開(kāi)發(fā)進(jìn)一步清晰編碼思路;

　　4、 測試用例編寫(xiě)完成后，發(fā)郵件給開(kāi)發(fā)經(jīng)理、項目經(jīng)理、相關(guān)開(kāi)發(fā)人員和測試人員;

　　5、 開(kāi)發(fā)經(jīng)理、項目經(jīng)理、相關(guān)開(kāi)發(fā)人員和測試人員對所提交的測試案例進(jìn)行審查，開(kāi)發(fā)經(jīng)理與項目經(jīng)理對測試案例進(jìn)行總體性的檢查，各模塊負責人則負責檢查自己所負責的測試案例，將建議和意見(jiàn)以郵件的形式反饋給測試負責人;

　　6、 測試負責人收集大家的郵件對測試案例進(jìn)行修改完善，同時(shí)回復郵件說(shuō)明修改情況，如果存在爭議則召開(kāi)一個(gè)小型會(huì )議對異議進(jìn)行討論，修改后的測試案例commit到CVS;

　　7、 測試用例編寫(xiě)完成之后需要不斷完善，軟件產(chǎn)品新增功能或更新需求后，測試案例必須配套修改更新;在測試過(guò)程中發(fā)現設計測試案例時(shí)考慮不周，需要對測試案例進(jìn)行修改完善;在軟件交付使用后客戶(hù)反饋的軟件缺陷，而缺陷又是因測試案例存在漏洞造成，也需要對測試案例進(jìn)行完善;

　　8、 測試負責人(或專(zhuān)門(mén)的PPQA)對最終修改測試案例進(jìn)行檢查，并確認所有文檔都已經(jīng)commit到CVS。

　　七、測試實(shí)施(測試階段)

　　開(kāi)發(fā)進(jìn)行單元測試—〉開(kāi)發(fā)進(jìn)行聯(lián)調測試，確保交給測試是可用的—〉

　　1、代碼提交前一天準備相關(guān)的測試環(huán)境(如服務(wù)器或數據庫等)，代碼提交后測試人員向Build Master申請打包，并搭建正式測試環(huán)境，為了不做到測試以及確保產(chǎn)品可以跨平臺，每個(gè)測試人員各自搭建一個(gè)測試環(huán)境，每個(gè)平臺至少要有一個(gè)以上的測試人員負責;

　　2、測試環(huán)境搭建好后進(jìn)行煙霧測試，如果煙霧測試通過(guò)則繼續詳細的功能測試，否則中斷測試并返回給開(kāi)發(fā);

　　3、測試人員按照預定的測試計劃和測試方案逐項對測試案例進(jìn)行測試，在測試過(guò)程中發(fā)現的任何與預期目標不符的現象和問(wèn)題都必須詳細記錄下來(lái)，填 寫(xiě)測試記錄，在必要的時(shí)候協(xié)助開(kāi)發(fā)追蹤與修改所發(fā)現的問(wèn)題;如果在測試的過(guò)程中發(fā)現重大的bug或因為某些bug導致測試不能繼續，測試中斷并返回給開(kāi)發(fā);

　　4、每個(gè)測試階段測試結束后，由測試負責人總結測試情況，對測試結果進(jìn)行分析和下一階段測試測試計劃與可能引進(jìn)的bug數量進(jìn)行預測，并提交“測試階段分析報告”，并發(fā)送給開(kāi)發(fā)經(jīng)理、項目經(jīng)理、相關(guān)測試人員和開(kāi)發(fā)人員;

　　5、開(kāi)發(fā)經(jīng)理對測試階段分析報告中存在的問(wèn)題采取恰當的措施和調整相關(guān)資源，確保下一階段的開(kāi)發(fā)與測試計劃順利進(jìn)行;

　　6、開(kāi)發(fā)對bug進(jìn)行修改;

　　7、開(kāi)發(fā)對bug修改后測試人員進(jìn)行回歸測試，經(jīng)過(guò)修改的軟件可能仍然包含著(zhù)錯誤，甚至引入了新的錯誤，因此，對于修改以后的程序和文檔，按照修改的方法和影響的范圍，必須重新進(jìn)行有關(guān)的測試;

　　8、產(chǎn)品的功能比較完善后，進(jìn)行產(chǎn)品的性能壓力測試，并根據測試結果進(jìn)行性能調優(yōu);

　　9、確認測試，在軟件發(fā)布前，對產(chǎn)品進(jìn)行確認測試;

　　10、當測試產(chǎn)品達到測試計劃所制定的產(chǎn)品質(zhì)量目標和測試質(zhì)量目標，整理產(chǎn)品發(fā)布包和編寫(xiě)相關(guān)文檔，確認發(fā)布包和文檔完整后進(jìn)行產(chǎn)品發(fā)布。

　　八、產(chǎn)品發(fā)布

　　當測試產(chǎn)品達到測試計劃所制定的產(chǎn)品質(zhì)量目標和測試質(zhì)量目標，整理產(chǎn)品發(fā)布包和編寫(xiě)相關(guān)文檔，在發(fā)布前對照功能列表進(jìn)行一次全面的確認測試，確 認發(fā)布包和文檔完整后進(jìn)行產(chǎn)品發(fā)布。對于新產(chǎn)品來(lái)說(shuō)，必要的文檔必須包括：(1)產(chǎn)品安裝操作手冊;(2) 產(chǎn)品白皮書(shū);(3) 產(chǎn)品管理維護手冊;(4) 用戶(hù)操作手冊;(5) 總體測試報告(6)性能測試報告。

　　九、版本控制

　　在測試過(guò)程中，軟件的打包統一由Build Master完成。新版本軟件發(fā)布之后，馬上對代碼進(jìn)行質(zhì)量控制： (1) Build Master給新版本的源代碼打一個(gè)cvs tag，方便代碼回滾check out。比如，發(fā)布版本為IAGW1.0.0，則給該軟件源代碼也打一個(gè)與發(fā)布版本相同名字的tag IAGW1.0.0。這樣做的一個(gè)好處是，在目前的軟件的基礎上做了修改并發(fā)布新的版本后，如果需要check out某個(gè)版本的源代碼，則可以通過(guò)這個(gè)版本的tag來(lái)check out，代碼的修改可以在該版本上進(jìn)行。(2) Build Master對新發(fā)布的軟件源代碼進(jìn)行cvs lock，不允許開(kāi)發(fā)人員在軟件發(fā)布之后commit源代碼，直到有新版本需求修改再給開(kāi)發(fā)人員開(kāi)放commit權限。這樣做的好處是避免開(kāi)發(fā)人員隨意修 改和commit源代碼，確保源代碼服務(wù)器上的源代碼版本與當前最新的發(fā)布版本一致。

　　十、自動(dòng)測試

　　產(chǎn)品穩定后，進(jìn)行自動(dòng)測試工具開(kāi)發(fā)，對于穩定的功能使用自動(dòng)測試工具進(jìn)行測試，新增的功能使用手工測試，使用自動(dòng)測試+手工測試的模式，可以大大提供測試效率。

　　十一、小結：應用推廣思路與體會(huì )

　　整體思路是：首先對項目進(jìn)行需求分析，有效的需求分析方法是需求分析人員、項目經(jīng)理、開(kāi)發(fā)經(jīng)理與測試負責人分別閱讀規范與原始需求，特別是需求分析負責人與項目經(jīng)理，需要對需求進(jìn)行深入的分析研究，然后開(kāi)會(huì )討論，消除對需求的誤解與遺漏， 討論結束后編寫(xiě)功能列表說(shuō)明文檔與需求規格說(shuō)明書(shū)并評審;對于規范中不明確的問(wèn)題集中后由測試負責人(或需求分析負責人)直接與移動(dòng)總規范負責人直接交流，確保不會(huì )因為規范的理解不正確導致項目實(shí)現與需求不一致。需求分析完成后，編寫(xiě)項目計劃書(shū)與測試計劃書(shū);項目計劃、測試計劃編寫(xiě)前先開(kāi)會(huì )討論，由模塊 負責人估算工作量，能確定的問(wèn)題和時(shí)間安排都在討論中確定下來(lái)，然后根據工作量和工程需求制定項目計劃和測試計劃。開(kāi)發(fā)在編碼前需要進(jìn)行概要設計和詳細設計，開(kāi)發(fā)工程師在編碼前對系統的總體設計架構、各自所負責的模塊有一個(gè)清晰的設計思路，經(jīng)評審后確認模塊的設計是否合理;開(kāi)發(fā)在編碼完成后在提交測試前必 須進(jìn)行單元測試與聯(lián)調測試，提交給測試的軟件是一個(gè)可運行的產(chǎn)品。測試工作中，在項目設計或編碼階段，測試負責人對項目進(jìn)行測試設計，指導測試實(shí)施有依可循，在編寫(xiě)案例的過(guò)程中會(huì )遇到很多與流程和細節處理相關(guān)的問(wèn)題，與開(kāi)發(fā)一起討論也有助于提前發(fā)現問(wèn)題與完善代碼;在測試實(shí)施階段，測試人員記錄所發(fā)現的問(wèn) 題，并協(xié)助開(kāi)發(fā)及時(shí)解決，在測試過(guò)程中所遇到的問(wèn)題，測試負責人進(jìn)行記錄和分析，在每個(gè)階段完成后提交經(jīng)分析后的測試階段報告，在軟件測試階段報告中總結分析了測試過(guò)程中所發(fā)現的問(wèn)題并對這些問(wèn)題提出解決建議，在后續的開(kāi)發(fā)與測試中進(jìn)行改進(jìn)與調整，確保項目能夠按時(shí)保質(zhì)發(fā)布。為了節約資源，計劃或設計都是以郵件的形式進(jìn)行評審;對于存在嚴整分歧的問(wèn)題，組織一個(gè)小型會(huì )議進(jìn) 行討論有效解決問(wèn)題，小型討論會(huì )是解決問(wèn)題的一種有效途徑，任何問(wèn)題都可以通過(guò)face-to-face的交流達到共識。軟件的管理和版本管理則由 Build Master負責，確保軟件得到良好的控制。在整個(gè)項目實(shí)施的過(guò)程中，需要有一個(gè)PPQA對流程進(jìn)行檢查與監督。

原文轉自：http://kjueaiud.com