問題1：用需、軟需文檔不夠完整，需求不夠明確，功能細節描述不足。
解決：
需求維護：Jira上的產品建議、運維反饋的產品建議。
需求文檔維護。（系統的主要功能、流程在文檔中都需描述，功能實現細節可在需求評審補充或
用例設計時加入）
需求評審（召開版本迭代會討論明確需求）
版本迭代會：項目經理規劃版本之時，召開版本迭代會，對需求進行說明，開發和
測試人員有問題可共同探討，避免需求理解歧義。（其他組的經驗）
問題2：完善需求OR完善用例？
討論：
嚴格意義測試應該從需求開始抓起，參與需求的評審，對詳細設計也要測試，如果可以做到這樣，那么無需求測試的狀況就不會出現了；但目前我們并沒有做這么多，或者說做得不完全。所以測試人員都會或多或少的遇到這種無完善需求文檔的測試狀況，這時候我們需要謹記的則是我們必須保證我們的
測試用例包含了你所要測試對象的所有功能點。Openqs目前來看完善需求文檔和完善用例都是比較痛苦的。因此建議是兩頭同時開展，一方面，系統的主要功能流程在需求文檔（用需）補充。另一方面提高測試用例覆蓋需求度，補充異常的驗證流程等。
問題3：jira上的缺陷描述不規范。
解決：
全員規范缺陷描述，注意事項：
1. 對于無法重現或不好重現的問題，備注說明測試地址、賬號、密碼等，供開發人員排查。
2. 針對兼容性類的缺陷，說明缺陷使用的瀏覽器、分辨率、
操作系統等情況。
3. 1個缺陷盡量只描述1個問題，不要描述多個問題。避免開發人員對缺陷沒有修改全，或者只修改一部分，一部分后面才修改。
4. 一些缺陷若文字描述無法準確表達的話，最好都能帶上附件截圖說明。比如一些提示信息啊、樣式顯示啊、另外一些顯示代碼類的錯誤都必須截圖說明。
5. 開發人員解決完缺陷，若可能的話最好備注說明修改的情況及可能影響的功能。
6. 測試人員驗證缺陷，若缺陷重新打開，增加備注說明驗證的情況。
問題4：系統環境搭建較為復雜，測試環境更新未走標準化流程，系統安裝更新手冊說明不足。
解決：
自動構建、減少人工的配置操作、簡化環境搭建和更新步驟
完善系統安裝手冊、系統維護手冊、系統更新手冊。
問題5：測試過程中，采用邊測邊改的方式，更新測試環境頻繁，導致功能重復測試較多，測試效率不高，同時遺留缺陷的風險較大。
解決：
引入周更新測試，規范測試。
問題6：提交的缺陷，沒有安排解決時間表，不斷遺留和累積，感覺測試的工作成果得不到重視。 解決：
建議制定迭代計劃時，將缺陷安排到迭代任務中解決，在迭代的
系統測試進行驗證。
問題7：缺陷解決流程沒有形成規范，存在缺陷關注不足，缺陷不解決，解決后未驗證、無法驗證等情況。
解決：
制定缺陷解決流程，按規范嚴格執行。
配置人員權限
功能測試階段：
項目測試類型我覺得可先大致可分為兩類：周更新測試和系統測試（含性能測試、安全測試、穩定性測試等專項測試）。
周更新測試
周更新測試：主要是針對每周的各組件更新需求，進行測試。
組件更新是否提交測試可由組件負責人自行判斷，不一定需要提交測試。
提交測試需保證更新的主要功能已完成并已自測，若發現因為主要功能有問題導致無法繼續測試，則退回測試。
提交測試需由組件負責人說明清楚更新的內容和可能的影響功能。
測試人員主要針對更新的內容及可能影響的功能進行測試，并對系統的主要流程進行冒煙測試，其他功能不進行測試。（1.增加的新功能以及新修復的bug。2.系統中重要的功能，如果有將測試用例分優先級的話，優先級高的測試用例應該要被執行到。3.與開發人員交流，確定哪些功能是受最新的改變而有可能發生問題的，開發人員認為最有可能出問題的功能，應該重點測試。）
測試結束一般不出具測試報告，可大概整理下早會說明或者通過郵件、QQ向組件負責人、項目經理、產品經理說明下測試情況。
一般在測試完畢后才允許更新環境進行第二輪的驗證測試。（盡量減少測試過程中更新測試環境的頻率，除非因出現大問題影響測試不得不更新環境）
周更新測試發現的缺陷統一登記到jira上。
系統測試
系統測試：建議比較大版本的功能開發結束，提交一次比較完整的系統測試。（包含之前做的幾次周更新測試）
系統測試可按循環進行，第一循環測試后，在開發人員修改完第一循環缺陷后再提交第二循環測試。如此進過2-3個循環，最終使產品達到發布上線的標準。
系統測試結束后出具系統測試報告。
系統測試環境由測試人員搭建和更新。
提交測試時說明測試的內容（哪些要測試、哪些不測試）
系統測試準入條件
1. 需求文檔已納入SVN，功能需求明確，已通過評審。
2. 項目經理提交測試申請單(參考測試申請單模板)
3. 本迭代的測試用例已完成并通過評審。
由于版本周期問題，組內其他成員可能沒時間看，測試人員可按優先級羅列測試點，測試計劃。組內測試人員之間，也可以互評。若有時間產品經理和主要開發人員也可參與評審。
4. 版本開發結束，開發人員自測。
開發不宜提交太過頻繁，不應提交無法構建，編譯錯誤的代碼。且應該在有較大改動，或進行較大更新時，有一定的可測性，才提交測試。若開發提交測試的產品，主流程主功能出現問題，較大影響測試開展，則測試人員可中止測試，待改善后重新進入。
相對獨立的功能需求，可分別提交測試；但如果多個需求關聯性緊密，應該開發完畢后一起提交測試，避免測試人員過多重復勞動。
對于沒有完成的功能，不能提交測試，必須在代碼中注釋掉。
5. 代碼已提交配置庫，并提供安裝說明文檔。
注1：功能測試可以分測試循環進行，如第一循環測試完畢后，開發人員對缺陷進行修改，將大部分缺陷均已修改，然后提交第二循環測試。第二循環驗證缺陷和進行針對性的測試。若缺陷還較多，再提交第三循環。如此反復直至滿足測試退出準則結束功能測試。
注2：功能測試由于人力資源限制，提交太過頻繁，建議有比較大改動或要進行較大更新才提交測試。其他類型采用周更新測試的方式，大體如現在我們進行的測試類型。
注3：若提交的產品，主要流程出現大問題，較大影響測試進行，向項目經理中止測試，待改善后再提交測試。
系統測試退出標準
1. 測試用例均已執行，用例通過率90%。
2. 功能需求都已經開發和測試完成，系統性能和功能已達到需求標準。
3. 嚴重缺陷均已修改（若有遺留由項目經理和產品經理審批）、總體缺陷修復率達到80%（暫定80%，后續根據產品要求可提高）