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