1樓：百度文庫精選
內容來自使用者:opw1124q8i6yo
一、bug處理流程圖：
流程描述：1、測試人員發現bug提交給開發。2、開發人員判斷是否是bug。
3、如果是bug，進行修改，修改完成後更改bug狀態為已解決。4、如果不是bug，退回給測試人員並描述退回原因，或為設計如此，或為外部原因，或者不能重現。
5、開發人員修改完成的bug，由測試人員進行驗證，確認修改正確，關閉bug。6、驗證未通過的bug重新啟用，開發人員繼續修改，直至驗證通過，關閉bug。7、測試人員需要對開發人員退回的bug進行確認。
8、確認不是bug關閉。9、如與開發人員意見不一致，認為是bug，需提交專案負責人仲裁。10、專案負責人確認是bug由開發人員修改，不是bug由測試人員關閉。
注：除提交專案負責人仲裁環節外，其他環節都可以在禪道上完成。
二、各角色應關注的狀態1.開發人員：啟用、重新開啟
啟用：開發人員要對處於啟用狀態的bug進行處理，處理後將其狀態置成「已解決」、「設計如此」、「無法重現」、「外部原因」、「重複bug」或「延期處理」。重新開啟：
重新開啟的bug是已解決的bug經過測試人員驗證，未修改正確，需要繼續修改。
2.測試人員：已解決、無法重現、設計如此、外部原因、延期處理
已解決：測試人員發現狀態為「已解決」的bug，要及時驗證，如果確實已解決，要將其置為「關閉」。否則「重新開啟」無法重現：測試人員發現狀態為「無法重現」的bug，要及
2樓：家淖杏細
我們團隊用日bai事清做bug的管du理，建立了嚴謹的zhi規範。bug管理流程為：
dao測試工程師
1. 根據規範提內交容bug；
2. 及時驗證bug是否已解決；
3. 及時關注開發拒絕bug，和相關人員溝通討論解決方式；
測試經理
1. 審核測試工程師提交的bug；
2. 定期review bug，報告現狀，並給出解決意見；
開發工程師
1. 以優先順序為依據分析解決bug
開發主管
1. 定期 review bug，對bug多的模組加強code review和單元測試；
2. 分析bug解決進度，對產品質量及進度進行風險評估；
產品1、當開發和測試存在意見分歧時，進行需求確認2、從產品角度劃分bug修改的優先順序；
對於程式設計師來說，通過日事清的統計功能，可以清楚手頭還有多少bug沒解決，多少解決後又重新開啟的，有沒可能修改引發，bug根源，拒絕修復的原因是什麼；
對於qa來說，通過日事清做bug管理，通過看板和標籤制度，可以每乙個bug背後的屬性，即測試階段、bug型別、重現規律、嚴重級別等。程式猿笑了！
軟體測試bug流程？
3樓：匿名使用者
1.軟體測試流程，一般是這樣：需求了解——測試計畫——測試設計——測試用例編寫——測試執行——bug管理跟蹤——測試報告生成
2.bug就是測試過程中發現的程式缺陷，可以指需求上的，也可以指功能、效能上的
3.bug提交有多種方式，可以通過測試管理工具來管理bug，比如qc等
4.bug的生命週期： 發現bug（open）——修復bug（fixed）——關閉bug（closed）
4樓：中原浪子
一是專案經理通過和客戶的交流，完成需求文件，由開發人員和測試人 員共同完成需求文件的評審，評審的內容包括：需求描述不清楚的地 方和可能有明顯衝突或者無法實現的功能的地方。專案經理通過綜合 開發人員，測試人員以及客戶的意見，完成專案計畫。
然後sqa進入專案，開始進行統計和跟蹤。
二是開發人員根據需求文件完成需求分析文件，測試人員進行評審，評審的主要內容包括是否有遺漏或 者雙方理解不同的地方。測試人員完 成測試計畫文件，測試計畫包括的內容上面有描述。
三是測試人員根據修改好的需求分析文件開始寫測試用例，同時開發人 員完成概要設計文件，詳細設計文件。此兩份文件成為測試人員撰寫 測試用例的補充材料。
四是測試用例完成後，測試和開發需要進行評審。
五是測試人員搭建環境
六是開發人員提交第乙個版本，可能存在未完成功能，需要說明。測試 人員進行測試，發現 bug 後提 交給 bugzilla。
七是開發提交第二個版本，包括 bug fix 以及增加了部分功能，測試人員進行測試。
八重複上面的工作，一般是 3-4 個版本後 bug 數量減少，達到出貨 的要求。
九是如果有客戶反饋的問題，需要測試人員協助重現以及回歸測試。
在傳統的 bugzilla 中，bug 描述應該包括以下的資訊：① 和 bug 產生對應的軟體版本；② 開發的介面人員；③ bug 的優先順序；④ bug 的嚴重程度；⑤ bug 可能屬於的模組，如果不能確認，可以用開發人員來判斷；⑥ bug 標題，需要清晰的描述現象；⑦ bug 描述，需要盡量給出重新 bug 的步驟；⑧ bug 附件中能給出相關的日誌和截圖。
高質量的 bug 記錄就是指很容易理解的 bug 記錄， 所以，對於描述的要求高，能提供的資訊多且準確，很好的幫助開發人員定位。
我們公司一直使用日事清來進行軟體測試bug。日事清是一款簡單易用的軟體測試管理，它能夠合理讓員工規劃軟體測試工作日程，讓管理者及時掌握測試員工工作飽和度、軟體測試工作進展狀況等等。這樣不管是個人高效完成工作，還是團隊協同作業，都可以輕鬆搞定。
日事清的核心功能是日程管理、任務協作和工作筆記，三者有機結合互為一體，讓工作體驗變得輕鬆。
5樓：命之云云魚
寫測試用例，執行用例，發現問題，記錄問題，程式設計師修改，測試回歸測試，關閉問題，望採納
軟體測試的流程是什麼？bug具體是什麼？怎麼提交？
6樓：匿名使用者
軟體測試工作流程：
1、需求分析、需求評審需求分析和評審就是分析客戶的需求可不可行，需要怎麼進行測試。
2、編寫測試計畫編寫測試計畫通俗一點講就是什麼人在什麼時間做什麼事，最後產出什麼東西。那也就是測試人員要測試哪些模組、在什麼期限內，提交哪些文件。
3、編寫測試用例、用例評審測試用例就是指導測試的文件，比如我們要測試**登入、買東西等功能，通過測試方法和策略設計測試用例。評審就是評價審查，不能想當然該怎麼測。不能只是輸入正確的使用者名稱和密碼，能登入進去就完事了。
作為軟測工程師需要有破壞性，比如密碼輸錯時怎麼辦，會不會有相應的報錯等等。
4、執行測試、提交bug、回歸測試bug就是缺陷，發現bug之後，要提交給開發人員讓他們去修改，然後進行回歸測試，驗證開發人員有沒有改好。
5、編寫測試總結報告bug都改好了之後，要編寫測試總結報告，這款軟體的質量如何。
bug的標題和詳細描述:
標題主要是對你所提交的bug進行簡明扼要的描述；
詳細描述是對bug進行進一步詳細的描述，例如在什麼情況下發生等；也可以直接將標題作為描述部分。
兩者都是為了讓檢視bug的人員很清楚的知道你所表達的意思。
bug測試環境：
在什麼環境中發現的這個bug，例如：什麼系統，哪個版本等。對於bug環境的描述可以通過簡單的羅列即可（精簡為主）
7樓：啄木鳥學院
1.軟體測試流程:需求了解,測試計畫,測試設計,測試用例編寫,測試執行,bug管理跟蹤,測試報告生成.
2.bug:測試過程中發現的程式缺陷,可以指需求上的,也可以指功能,效能上的.
3.bug提交有多種方式,可以通過測試管理工具來管理bug,比如qc等.
4.bug的生命週期: 發現bug,修復bug,關閉bug.
8樓：
簡單跟你講下吧，
1.軟體測試流程，一般是這樣：需求了解——測
試計畫——測試設計——測試用例編寫——測試執行——bug管理跟蹤——測試報告生成
2.bug就是測試過程中發現的程式缺陷，可以指需求上的，也可以指功能、效能上的
3.bug提交有多種方式，可以通過測試管理工具來管理bug，比如qc等
4.bug的生命週期： 發現bug（open）——修復bug（fixed）——關閉bug（closed）
9樓：六洋易沛若
額，先和開發討論吧，讓他說出這個問題是怎麼一回事，為什麼會出現這個問題。
要是伺服器、網速問題的話，就不算是bug
要是程式問題，你就提bug到bug庫中，讓程式設計師自己去改！
10樓：
軟體測試的流程：
1）專案經理通過和客戶的交流，完成需求文件，由開發人員和測試人 員共同完成需求文件的評審，評審的內容包括：需求描述不清楚的地 方和可能有明顯衝突或者無法實現的功能的地方。專案經理通過綜合 開發人員，測試人員以及客戶的意見，完成專案計畫。
然後 sqa 進入 專案，開始進行統計和跟蹤 2）開發人員根據需求文件完成需求分析文件，測試人員進行評審，評審的主要內容包括是否有遺漏或 者雙方理解不同的地方。測試人員完 成測試計畫文件，測試計畫包括的內容上面有描述。
3）測試人員根據修改好的需求分析文件開始寫測試用例，同時開發人 員完成概要設計文件，詳細設計文件。此兩份文件成為測試人員撰寫 測試用例的補充材料。
4）測試用例完成後，測試和開發需要進行評審。
5）測試人員搭建環境
6）開發人員提交第乙個版本，可能存在未完成功能，需要說明。測試 人員進行測試，發現 bug 後提 交給 bugzilla。
7）開發提交第二個版本，包括 bug fix 以及增加了部分功能，測試人員進行測試。
8）重複上面的工作，一般是 3-4 個版本後 bug 數量減少，達到出貨 的要求。
9）如果有客戶反饋的問題，需要測試人員協助重現以及回歸測試。
在傳統的 bugzilla 中，bug 描述應該包括以下的資訊
① 和 bug 產生對應的軟體版本
② 開發的介面人員
③ bug 的優先順序
④ bug 的嚴重程度
⑤ bug 可能屬於的模組，如果不能確認，可以用開發人員來判斷
⑥ bug 標題，需要清晰的描述現象
⑦ bug 描述，需要盡量給出重新 bug 的步驟
⑧ bug 附件中能給出相關的日誌和截圖。
高質量的 bug 記錄就是指很容易理解的 bug 記錄， 所以，對於描述的要求高，能提供的資訊多且準確，很好的幫助開發人員定位。
希望對你有用！
軟體測試工程師bug管理工具（JIRA TD）
這種工具一般是裝載windows伺服器版本上的 比如 2000 2003 2008 裝xp上能用 但是不推薦 畢竟xp是主推家庭使用的 itest 愛測試 最懂測 試人的開源測試管理軟體隆重發布 net p itest cn開源敏捷管理，testops 踐行者 itest 可按測內試包分配測試用例容...
專案助理還是軟體測試,測試專案管理和普通的軟體測試有什麼區別呢
做測試吧。我是做測試的。不過專案助理是什麼?我不清楚 我猜想,專案助理應該是具備一些專業知識的行政崗位,需要有比較高的人際交往能力,測試是屬於技術崗位,需要比較高的專業技術知識還要細心耐心。都比較適合女孩子的,看你想要往哪個方向發展。專案助理吧,要想幹好測試需要的知識應該比開發多,做專案助理可以比較...
軟體測試具體的流程及所要用到的工具
流程復 需求分析 測試 一般測試 流程 1.需求分析階段 只要就是對業務的學習，分析需求點。2.測試計專劃階段 測試組長就要屬根據sow開始編寫 測試計畫 其中包括人員，軟體硬體資源，測試點，整合順序，進度安排和風險識別等內容。3.測試設計階段 測試方案一般由對需求很熟的高資深的測試工程師設計，測試...