問題1：用需、軟需文件不夠完整，需求不夠明確，功能細節描述不足。
解決：需求維護：jira上的產品建議、運維反饋的產品建議。
需求文件維護。（系統的主要功能、流程在文件中都需描述，功能實現細節可在需求評審補充或用例設計時加入）
需求評審（召開版本迭代會討論明確需求）
版本迭代會：專案經理規劃版本之時，召開版本迭代會，對需求進行說明，開發和測試人員有問題可共同**，避免需求理解歧義。（其他組的經驗）
問題2：完善需求or完善用例？
討論：嚴格意義測試應該從需求開始抓起，參與需求的評審，對詳細設計也要測試，如果可以做到這樣，那麼無需求測試的狀況就不會出現了；但目前我們並沒有做這麼多，或者說做得不完全。所以測試人員都會或多或少的遇到這種無完善需求文件的測試狀況，這時候我們需要謹記的則是我們必須保證我們的測試用例包含了你所要測試物件的所有功能點。openqs目前來看完善需求文件和完善用例都是比較痛苦的。因此建議是兩頭同時開展，一方面，系統的主要功能流程在需求文件（用需）補充。另一方面提高測試用例覆蓋需求度，補充異常的驗證流程等。
問題3：jira上的缺陷描述不規範。
解決：全員規範缺陷描述，注意事項：
1. 對於無法重現或不好重現的問題，備註說明測試位址、賬號、密碼等，供開發人員排查。
2. 針對相容性類的缺陷，說明缺陷使用的瀏覽器、解析度、作業系統等情況。
3. 1個缺陷盡量只描述1個問題，不要描述多個問題。避免開發人員對缺陷沒有修改全，或者只修改一部分，一部分後面才修改。
4. 一些缺陷若文字描述無法準確表達的話，最好都能帶上附件截圖說明。比如一些提示資訊啊、樣式顯示啊、另外一些顯示**類的錯誤都必須截圖說明。
5. 開發人員解決完缺陷，若可能的話最好備註說明修改的情況及可能影響的功能。
6. 測試人員驗證缺陷，若缺陷重新開啟，增加備註說明驗證的情況。
問題4：系統環境搭建較為複雜，測試環境更新未走標準化流程，系統安裝更新手冊說明不足。
解決：自動構建、減少人工的配置操作、簡化環境搭建和更新步驟
完善系統安裝手冊、系統維護手冊、系統更新手冊。
問題5：測試過程中，採用邊測邊改的方式，更新測試環境頻繁，導致功能重複測試較多，測試效率不高，同時遺留缺陷的風險較大。
解決：引入周更新測試，規範測試。
問題6：提交的缺陷，沒有安排解決時間表，不斷遺留和累積，感覺測試的工作成果得不到重視。
解決：建議制定迭代計畫時，將缺陷安排到迭代任務中解決，在迭代的系統測試進行驗證。
壓力測試問題
環境 兩台虛機配置，千m網絡卡 a 8cpu，32g記憶體 應用伺服器 b 2cpu，8g記憶體 資料庫 壓力測試資料 200使用者，每秒響應160 170次左右，cpu占用10 左右，記憶體占用穩定，始終無法提公升，網路使用率4 資料庫伺服器，cpu 2 記憶體占用穩定 資料庫一切正常，伺服器cp...
RabbitMQ 測試問題
使用eventlet併發consumer指令碼 eventlet.monkey patch all true msg per queue 50 queue num 10 rabbit host 10.23.54.150 5672 class consumer def init self,count ...
Linux lftp測試問題
1.客戶端安裝lftp，伺服器端安裝vsftpd 2.伺服器端啟動vsftpd服務 etc init.d vsftpd start 3.測試連線 lftp命令使用方法見 如果出現 delaying before reconnect 表示沒有連線成功，一般是伺服器端的設定問題。檢查以下項 1 檢查登入...