軟件測試過程改進的大致內容

　　測試過程改進的大致內容：

　　1.重視測試軟件的需求分析：

　　在測試過程改進中要特別注意這一點，很多公司的測試人員都不太重視測試需求分析，由于時間緊或測試人員有限，不得不看了一部分需求，就開始編寫相應的測試用例，這也不是什么大驚小怪的事了。我建議：首先，了解獲取需求的渠道，保證測試需求比較全面準確。

　　其次，可以羅列出功能測試或業務測試需求點，讓用戶和項目組成員評審確認，避免測試后期由于時間原因而導致漏測。

　　2.提高測試計劃的可執行性：

　　很多時候，測試部門測試經理在項目測試初期，編寫了一個測試計劃以后，后面不管是發生了什么情況，測試計劃都不會做相應的調整，這就導致測試計劃成了擺設，應付領導檢查了事的文檔，沒有真正發揮測試計劃的指導性作用。不知道大家是否有同感。我的做法：把測試計劃分成大計劃和小計劃。先寫大計劃，后編寫小計劃。大計劃通過估算一旦確定后，基本上改動不大。小計劃要跟隨項目的測試情況，隨時調整或修改，當然這就對“測試經理”預估測試工作量的能力要求比較高。預估不準那就每周改計劃吧，呵呵!

　　3.合理安排測試活動的順序：不合理的測試順序，可能會引起務工，測試效率低下。如果不立即采取相應的措施，到后來還會導致測試進度失控。比如說一個項目中，哪些測試活動必須有先后順序，哪些測試活動能夠并行開展，哪些測試活動可以合并，作為測試Leader必須要非常清楚。不明白測試活動的順序，讓測試活動自由發展，何談測試過程改進?

　　4.優化測試文檔設計： 測試文檔的優化，也不是一蹴而就的事情，需要我們不斷提高測試文檔的編寫能力，循序漸進逐步提高。我們盡量保證測試文檔的可讀寫高，任何人都能夠看懂，都能夠執行，也許這是一個理想化的境界吧，呵呵!!在這個前提下，盡量保證較少的測試用例，覆蓋較多的需求內容，可能這一點實施難度比較大。

　　5.強化測試資源的最優配置：

　　軟件測試是一個非常復雜的過程，需要人力資源、測試設備、測試環境等多個因素密切相關。比如說測試設備配置多少個為最佳?每個模塊配置的測試人員的能力水平需要達到什么程度?需要多少個測試人員?等等問題。我們必須給出一個最優的資源配置方案。

　　6.參與部分開發文檔的討論：

　　一般情況下，不懂開發的測試人員，很難發現深層次、嚴重等級較高的缺陷。比如說Web測試，如果你不懂Oracle數據庫設計文檔，你很難確定頁面顯示的結果是否是真實的數據。不了解詳細設計文檔，很多業務流程可能就不會太清晰，這也就是為什么第一輪測試時，測試人員老是去問開發人員的原因?如果在測試前期，參與了部分開發文檔的討論，盡量了解每個數據庫中每個字段的意思，對開發了解深入一些，可能測試深度就不一樣了。

　　7.全面分析測試結果，確定合理的測試度量標準：

　　全面分析階段測試結果，總結測試經驗和系統缺陷，分析測試過程中存在的問題，提交有價值的測試報告，推動相關高層管理人員予以關注，促進問題和缺陷得到有效的解決，這才能夠起到關鍵性的作用。同時，要確定一個比較合理的測試度量標準，不斷實踐、不斷總結、不斷改進，提出符合公司實際情況的測試過程改進措施。

　　8.兼顧成本的前提下，盡量保證測試的覆蓋率：

　　在保證測試成本的前提下，我們要盡可能的提高測試的覆蓋率。其中測試覆蓋：包括測試內容覆蓋、測試技術覆蓋和測試過程覆蓋。我們可以通過測試用例覆蓋率來提高測試的質量，保證較多的缺陷在版本發布以前被測試組發現。也可以通過提高測試技術覆蓋率，用實踐來驗證，不能夠輕易相信部分行業人士的一面之詞，而誤入歧途。在保證公司盈利的情況下，盡量提高測試的覆蓋率，提高測試質量。

　　測試過程改進的注意事項：

　　1.切忌“好高騖遠”脫離公司實際：

　　很多時候，軟件公司大家都一窩蜂的趕時髦。我們一提到測試過程改進，大家都想像“測試規范”一樣弄得非常全面，大部分都停留在理論上，花了大量的人力和物力，往往脫離了公司的實際情況，得不喪失，結果可想而知。

　　2.測試過程改進不能盲目跟風，切不可趕潮流：

　　一個公司近年來的發展方向一旦確定，那就要堅持走下去。如果定位不一樣，那對測試過程改進的要求也就不一樣。比如說一個小公司，本來測試人員都很少，測試資源都有限，正常測試都無法保證，那你覺的談“測試過程改進”還有意義嗎?再比如說小公司有測試過程改進的經濟實力，那也無法和大公司相比，畢竟企業也要賺錢、盈利、生存。所以，測試改進時，一定要考慮測試部門的規模、公司的商業機會、企業經濟實力等等方面的因素，更不應該盲目跟風。合適的才是最好的!過程改進，切不可趕潮流!

　　3.測試過程改進最好由專人負責：

　　在中國，很多時候，一個人干多個人的事情，拿到的工資與付出不成正比，虧呀!!!比如說在我們公司，凡是涉及到軟件測試的工作，都由測試經理負責，包括“測試過程改進”、“測試規范制定”、“測試模板制定”、“自動化測試”呀?什么的，都一個人干，甚至包括QA的工作，都快被累死了，呵呵!!最主要是一個人干幾個人該做的事情，很容易分散精力，并且考慮也不會很周到，也沒有一個人專業了。建議由專人來負責測試過程的改進比較好，測試過程改進成功的幾率會大很多。

　　4.測試過程改進并不等于花費大量資金

　　大部分的測試公司，在測試過程改進上都是走走過場，為得都是應付客戶。有的公司是請一些測試專家進行咨詢，不僅花費大量的時間，還耗費的大量的資金。有的公司是買一些測試工具、缺陷工具，當然開銷也不小。我覺得：如果條件允許的情況下，各方面都可以跟上，那樣比較理想。如果公司經濟條件有限，我建議針對公司的實際情況，合理利用測試部門的集體智慧，改進測試過程方為良策。

　　5.測試過程改進不能夠急于求成：

　　軟件測試過程改進，作為軟件測試的一個階段，我們只能夠循序漸進，不能急于求成。我們應該正確處理好測試和測試過程改進的主次關系，一步一步用實踐驗證來完善。相信只要經過測試部門的不斷努力，測試過程改進一定會取得成功.

原文轉自：http://www.anti-gravitydesign.com