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

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

　　六、測試設計與評審(開發階段)

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

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

　　3、 在編寫測試案例的過程中，對于存在疑問的地方或測試重點，主動與開發負責人或項目經理溝通討論，一方面有助于設計完善的測試案例，另一方面也有助于開發進一步清晰編碼思路;

　　4、 測試用例編寫完成后，發郵件給開發經理、項目經理、相關開發人員和測試人員;

　　5、 開發經理、項目經理、相關開發人員和測試人員對所提交的測試案例進行審查，開發經理與項目經理對測試案例進行總體性的檢查，各模塊負責人則負責檢查自己所負責的測試案例，將建議和意見以郵件的形式反饋給測試負責人;

　　6、 測試負責人收集大家的郵件對測試案例進行修改完善，同時回復郵件說明修改情況，如果存在爭議則召開一個小型會議對異議進行討論，修改后的測試案例commit到CVS;

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

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

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

　　開發進行單元測試—〉開發進行聯調測試，確保交給測試是可用的—〉

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

　　2、測試環境搭建好后進行煙霧測試，如果煙霧測試通過則繼續詳細的功能測試，否則中斷測試并返回給開發;

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

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

　　5、開發經理對測試階段分析報告中存在的問題采取恰當的措施和調整相關資源，確保下一階段的開發與測試計劃順利進行;

　　6、開發對bug進行修改;

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

　　8、產品的功能比較完善后，進行產品的性能壓力測試，并根據測試結果進行性能調優;

　　9、確認測試，在軟件發布前，對產品進行確認測試;

　　10、當測試產品達到測試計劃所制定的產品質量目標和測試質量目標，整理產品發布包和編寫相關文檔，確認發布包和文檔完整后進行產品發布。

　　八、產品發布

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

　　九、版本控制

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

　　十、自動測試

　　產品穩定后，進行自動測試工具開發，對于穩定的功能使用自動測試工具進行測試，新增的功能使用手工測試，使用自動測試+手工測試的模式，可以大大提供測試效率。

　　十一、小結：應用推廣思路與體會

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

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