A. 軟體測試中，BUG 提交不了有什麼原因造成的呢根據是什麼呢
Hi, 你說的提交不了是指bug已經確認可以提交，然後管理軟體出問題了提交不了還是指有人報了這個bug，但是因為一些原因不能去提交？
若是前者，請截圖或是說更詳細一些，讓我們能了解問題
若是後者，那麼bug不能被提交可能有以下問題：
1 這個bug本身就不是bug
2 目前的階段還沒有正式開始，所以還不能報bug
3 這個bug影響非常的小，對於用戶沒有太大影響，但是開發人員則要費大力氣去修改，這個問題就不會去提交
4 成本不允許，或是開發人員想要後期才去解決這個問題
5 目前階段處於測試的後期，一些不是很嚴重的bug就不會去上報了
6 之前已經報過了，然後被標稱 willneverfix之類的就不會上報了
B. 軟體測試提交bug時包括哪些內容
Bug的標題（Title）和詳細描述（Descriptions）:
標題是對你所提交的Bug進行簡明描述；詳細描述是對Bug進行詳細描述，例如在什麼情況下發生等；也可以直接將標題作為描述部分。
回歸（Regression）：
是測試前一個版本有沒有此類bug（稱為回歸測試）。
Bug測試環境（Environment）：
發現的這個bug的環境，例如：什麼系統，哪個版本等。對於bug環境的描述可以通過簡單的羅列即可。
復現的詳細步驟（Repro Steps）：
將測試的過程簡單的寫一下，從你開始測試軟體的最開始到你發現bug的時為止。
實際結果（Actual Results）和預期結果（Expected Results）：
實際結果是在測試軟體的過程中，軟體所表現出來的特徵或者行為；預期結果就是軟體需要設計所要求達到的結果或者目標。
備注（Notes）:
對bug的一些補充，例如：其它系統也發生，上個版本不發生等需要補充的內容。
內容還包括bug的嚴重等級、優先等級等，對於不同的bug，要做出相應的提交內容
C. 詳解BUG（又名：BUG的生命周期）
測試人員最本質的工作就是尋找bug，提交bug、驗證bug、推進bug的解決，直至軟體達到發布的標准，提高軟體的質量，及研發的工作效率和質量。
軟體的BUG,狹義概念是指軟體程序的漏洞或缺陷，廣義概念除此之外還包括測試工程師或用戶所發現和提出的軟體可改進的細節、或與需求文檔存在差異的功能實現等。
生命周期中 缺陷狀態 ：新建-->指派-->已解決-->待驗-->關閉
發現BUG-->提交BUG-->指派BUG-->研發確認BUG-->研發去修復BUG-->回歸驗證BUG-->是否通過驗證-->關閉BUG
1、發現bug
1）按照測試用例進行操作，發現和測試用例的預期結果不一致的,都可以被稱之為Bug。
2）測試用例不可能窮盡，總有超出你預料之外的因素,或者是神操作出現的bug。
3）成本問題，沒有充足的時間編寫測試用例，發現的bug
2、提交bug
在提交一個缺陷的缺陷，首先盡量描述這個缺陷的屬性。Bug重現環境，bug類型，bug等級，bug的優先順序以及詳細的重現步驟，結果與期望等。
當然，我們在提交一個問題之前首先應該保證，這個缺陷是沒有被提過的，以免造成重復缺陷單。
3、指派bug
這一步不是必須的，跟項目模式有關，有些公司測試部門與開發部門獨立，那麼測試人員就不確定自己測試的模塊是由哪位開發人員負責的，在這種情況下，測試人員統一把問題指派給項目組長或經理，由項目組長（或經理）對問題進行確認後再次分配給相應的開發人員。
有些測試人員是穿插到不同研發團隊中的，所以對不同的開人發員負責的開發模塊非常清楚，這個時候就可以將問題直接指派給相應的開發人員。
也有一種情況，本來此問題應該由A開發人員負責，但由於A開發人員的調離或辭職，些問題為轉交給其它人員處理。「分配」強調是上級對下級；「轉交」強調的是平級之間。
4、 確認缺陷
當開發人員接到一個缺陷時，首先是對其進行分析與重現，如果對其進行分析發現不是缺陷（可能由於測試人員不了解需求）或無法對此問題進行重現，那麼就需要將此問題反回給測試人員，並註明原因。如果確認為缺陷則需要對其進行處理。
5、修復BUG
推遲處理
在處理問題之後，還需要進行一次判斷，是否需要推遲處理，有些需求已經確認了是問題，由於其可能在極端情況下才會出現，或需要對系統架構進行改動，或其優先順序非常低，所以暫時不需要對此問題進行處理（或到下個版本進再進行修復）。
固定
對於推遲處理的問題可以暫時進行固定（「固定」為QC中的叫法。）一般固定的問題需要經過項目經理與測試經理協商後才能固定。
處理缺陷
開發人員在確認完一個問題需要處理時，那麼就對其進行處理工作。（例如，redmine 是支持處理人時時更新問題處理進度的，如 已處理30% ，已處理80% 等，當然，對於短時間內可以修復的問題就沒必要時時的去更新處理進度。）
6、回歸驗證BUG
回歸缺陷對於測試人員來說是非常重要的工作，其有三個入口兩個出口。
確認非缺陷問題：對於提交的一個缺陷，開人員處理為非問題或無法重現，然後直接轉交給測試人員回歸。測試人員再次確認，如果真如開發人員所說，則將問題關閉。如果非開發人員所說，是由於問題描述模糊或其它原因喂重現問題，則再次註明原因轉給開發人員。
確認修復問題：對開發人員修復的問題再次進行確認，確認能過，則關閉問題。確認不通過，將問題再次打開並轉給開發人員。
確認固定問題：有計劃的對固定問題進行確認，有些固定問題隨著時間的推移，版本的更新或已經不存在了，對這類問題應該及時關閉。有些固定問題依然存在且變得緊急，對於這類問題應該及時打開交給開發人員處理。
7、關閉缺陷
對於已經修復的缺陷進行關閉，這也是一個缺陷的最後一個狀態。
在做介面測試的時候可以使用國產的介面測試和介面文檔生成工具 apipost
D. 地下城BUG提交怎麼填寫完了交不上去啊 什麼都填了啊我。圖片也對啊。
很明顯的問題，不是所有玩家的意見都會被處理的。就好先據報外G一樣。你看TX現在掉線外G這兩大問題都解決不了哪還有心思去解決別的問題呢。另外，如果你像提交BUG，只有測試服會好一點。
E. 一條軟體缺陷（或者叫Bug）記錄都包含了哪些內容如何提交高質量的軟體缺陷（Bug）記錄
你好：
1) 通用UI要統一、准確
缺陷報告的UI要與測試的軟體UI保持一致，便於查找定位。
2) 盡量使用業界慣用的表達術語和表達方法
使用業界慣用的表達術語和表達方法，保證表達准確，體現專業化。
3) 每條缺陷報告只包括一個缺陷
每條缺陷報告只包括一個缺陷，可以使缺陷修正者迅速定位一個缺陷，集中精力每次只修正一個缺陷。校驗者每次只校驗一個缺陷是否已經正確修正。
4) 不可重現的缺陷也要報告
首先缺陷報告必須展示重現缺陷的能力。不可重現的缺陷要盡力重現，若盡力之後仍不能重現，仍然要報告此缺陷，但在報告中要註明無法再現，缺陷出現的頻率。
5) 明確指明缺陷類型
根據缺陷的現象，總結判斷缺陷的類型。例如，即功能缺陷、界面缺陷、數據缺陷，合理化建議這是最常見的缺陷或缺陷類型，其他形式的缺陷或缺陷也從屬於其中某種形式。
6) 明確指明缺陷嚴重等級和優先等級
時刻明確嚴重等級和優先等級之間的差別。高嚴重問題可能不值得解決，小裝飾性問題可能被當作高優先順序。
7) 描述 (Description) ，簡潔、准確，完整，揭示缺陷實質，記錄缺陷或缺陷出現的位置
描述要准確反映缺陷的本質內容，簡短明了。為了便於在軟體缺陷管理資料庫中尋找制定的測試缺陷，包含缺陷發生時的用戶界面（UI）是個良好的習慣。例如記錄對話框的標題、菜單、按鈕等控制項的名稱。
8) 短行之間使用自動數字序號，使用相同的字體、字型大小、行間距
短行之間使用自動數字序號，使用相同的字體、字型大小、行間距，可以保證各條記錄格式一致，做到規范專業。
9) 每一個步驟盡量只記錄一個操作
保證簡潔、條理井然，容易重復操作步驟。
10) 確認步驟完整，准確，簡短
保證快速准確的重復缺陷，「完整」即沒有缺漏，「准確」即步驟正確，「簡短」即沒有多餘的步驟。
11) 根據缺陷，可選擇是否進行圖象捕捉
為了直觀的觀察缺陷或缺陷現象，通常需要附加缺陷或缺陷出現的界面，以圖片的形式作為附件附著在記錄的「附件」部分。為了節省空間，又能真實反映缺陷或缺陷本質，可以捕捉缺陷或缺陷產生時的全屏幕，活動窗口和局部區域。為了迅速定位、修正缺陷或缺陷位置，通常要求附加中文對照圖。
附加必要的特殊文檔和個人建議和註解
如果打開某個特殊的文檔而產生的缺陷或缺陷，則必須附加該文檔，從而可以迅速再現缺陷或缺陷。有時，為了使缺陷或缺陷修正者進一步明確缺陷或缺陷的表現，可以附加個人的修改建議或註解。
12) 檢查拼寫和語法缺陷
在提交每條缺陷或缺陷之前，檢查拼寫和語法，確保內容正確，正確的描述缺陷。
13) 盡量使用短語和短句，避免復雜句型句式
軟體缺陷管理資料庫的目的是便於定位缺陷，因此，要求客觀的描述操作步驟，不需要修飾性的詞彙和復雜的句型，增強可讀性。
以上概括了報告測試缺陷的規范要求，隨著軟體的測試要求不同，測試者經過長期測試，積累了相應的測試經驗，將會逐漸養成良好的專業習慣，不斷補充新的規范書寫要求。此外，經常閱讀、學習其他測試工程師的測試缺陷報告，結合自己以前的測試缺陷報告進行對比和思考，可以不斷提高技巧。
14) 缺陷描述內容
缺陷描述的內容可以包含缺陷操作步驟，實際結果和期望結果。操作步驟可以方便開發人員再現缺陷進行修正，有些開發的再現缺陷能力很差，雖然他明白你所指的缺陷，但就是無法再現特別是對系統不熟悉的新加入開發人員，介紹步驟可以方便他們再現。實際結果可以讓開發明白錯誤是什麼，期望結果可以讓開發了解正確的結果應該是如何。
希望樓主採納 ，謝謝！
F. QQBUG提交！
1.先卸載原來的qq 2.清理注冊表(優化大師或超級兔子) 3.下載新軟體安裝(建議到官方網站下載比較有保障 http://im.qq.com/ ) 4.「QQ程序出錯，請重新安裝」這類QQ故障在很多用戶都產生了這種類似的現象，其主要原因如下： (1)電腦引導區，染上了病毒，需要進行徹底殺毒（建議在DOS下用殺毒軟體DOS引導盤進行查殺） (2)、針對騰訊公司推出的QQ2008base2類型的版本，其穩定性以及Bug修復方面並未完善，只注重了實用性，並未深入考慮穩定性。 建議修改密碼
滿意請採納
G. 提一個bug需要寫哪些必要的因素
BUG被提交到了BUG系統後，應該先改哪些BUG呢？在普元，對於BUG的修復有以下幾條規則：產品剛進入測試階段時，BUG的修復先後順序由開發人員依據BUG的嚴重程度，以及測試人員的要求，自行決定先修復哪些BUG，主要原則是保證基本用例能夠通過，不阻礙測試進度；到了接近產品發布的里程碑時，比如發布Alpha版，Beta1版，Beta2版等里程碑版本時，則必須根據每個里程碑版本的發布目標，由產品經理、項目經理和開發Leader需要共同商定，結合每個BUG的影響程度，來分配每個BUG修改的優先順序，BUG優先順序定義的規則如下：
P0級，必須要盡快修復的BUG，這些BUG直接影響到產品發布進度和最重要的功能使用，這些BUG不修復，將會阻礙其他任務的完成，項目組必須組織人力，馬上進行修復；
P1級，在每個里程碑結束前必須修復的BUG，對修正的要求不是非常迫切，但是必須在里程碑版本發布之前修復掉；
P2級，如果時間允許就修正的BUG，這樣的BUG一般來說不會影響里程碑版本的使用，是否需要修復根據項目組的時間和資源情況考慮，如果時間允許，就會修正；
P3級，很低優先順序的BUG，可以根據項目組時間和資源情況，決定是否修復，或遺留到產品發布後作為遺留BUG進行修復，在下一個版本中進行發布。
同時項目經理為每個版本制定出一份BUG修復計劃，明確每個BUG的修復優先順序、修復時間、修復版本，這時開發人員就必須按照這個計劃進行BUG修復；
我們團隊現在直接在日事清內進行「bug管理」，提bug人員將bug輸入到「收集」狀態，由產品助理集中處理，視bug具體情況將bug拖拽到其他集中狀態。如果拖拽到「確認」，在該bug下添加相應技術人員讓其處理，技術人員會在日事清協作系統內收到通知並且bug同步到其收納箱，方便技術人員集中處理，解決後由技術人員拖拽到「已解決」狀態卡片。
H. bug的概念和分類
大家好，我是十一。
前面篇我們都在講測試用例設計的案例、設計方法、工具。本篇呢我們來聊聊bug，程序里的小蟲子。
所謂「（Bug）」，是指程序中隱藏的錯誤或者缺陷。
早在 軟體測試的工作周期 一文附錄中我們就已經對bug來源做了解釋，感興趣的點擊鏈接回顧。
一條Bug記錄最基本應包含：
※bug編號：bug的唯一id，以方便盡快找到此bug。
※bug標題：bug摘要，闡述bug大體內容。
※bug嚴重級別，優先順序：作為缺陷是否修復以及缺陷修復優先順序的決定性因素。
※bug產生的模塊：記錄bug所屬模塊，方便開發定位問題。
※bug對應的版本：bug對應的軟體版本，方便後續的統計歸檔以及開發定位問題。
※bug描述：bug的產生環境、詳細步驟，期望結果、實際結果。
※附件：包括但不僅限於截圖、日誌、錄像、所用到的示例文件以及應用；同樣是方便復現解決缺陷的。
以上是上報bug（創建）bug必須的，在後續我們還會對bug進行修復、復測等工作，那在為了記錄後續工作，bug還應該包含：
※bug狀態：開始、修復中、修復完成、提測、測試中、測試通過/失敗、關閉等，後續bug周期中會講到。
※bug修訂人：bug修訂人員。
※bug復測人：通常是誰報的bug最後返回給誰測試，但是在某些情況下比如bug報告人任務積累太多/不在的情況下也會分給其他人，所以通常會記錄bug復測責任人。
※bug修訂說明：由bug修訂人來寫，說明bug產生原因，修改思路等。
※bug復測說明：由復測人員來寫，說明復測過程，復測結果等。
※bug備註：備注，以便記錄一些額外信息。
俗話說，事有輕重緩急。生活如此，工作亦如此。軟體缺陷也並不是平等的，根據當前環境我們將不同的缺陷按照嚴重程度以及優先順序進行分類，開發通過這個分類來決定bug是否修改以及bug修改的先後順序（「缺陷的輕重緩急」）。
具體劃分方法各個公司不盡相同，但是通用原則大體一樣：
※ 嚴重性 ：表示軟體缺陷的惡劣程度，當用戶碰到該缺陷時影響的可能性和程度。
※ 優先順序 ：表示修復缺陷的重要程度和緊迫程度。
下面我們給出嚴重性和優先順序的常用劃分方法，需要注意的是，我們這個只是示例，每個公司劃分方法也都不盡相同，多多少少有些改變，大家作為參考即可。
嚴重性：
a.系統崩潰、數據丟失、數據毀壞、安全性被破壞、核心功能未實現（比如QQ 沒有做聊天功能）、主體功能實現與需求不符（比如QQ聊天功能只能發消息不能收消息）
b.操作性錯誤、結果錯誤、功能模塊的某個點未實現（比如QQ沒有做消息提醒）,兼容性錯誤
c.小問題、拼寫錯誤，UI布局不美觀、特定情況下的罕見bug
d.一些易用性的建議（也可以歸為3）
優先順序：
a.立即修復，阻止了進一步測試
b.在產品發布之前必須修復
c.如果時間允許應該修復
d.可能會修復，不影響發布。
再次重申，上述清單只是範例，具體的缺陷劃分規則還要依據實際項目、應用場景來制定。比如：通常我們認為毀壞用戶數據的缺陷比簡單的拼寫錯誤缺陷嚴重。但是如果數據毀壞僅在用戶幾乎用不到的罕見特例中出現，而拼寫錯誤導致所有用戶安裝軟體產生問題呢？此時數據毀壞與拼寫錯誤的優先順序和嚴重性就不言而喻了，必然是拼寫錯誤的嚴重性和優先順序高於數據毀壞的。
嚴重性和優先順序對於審查缺陷報告並決定哪些軟體缺陷應該修復，以何種順序修復的人員極為重要。如果一個程序員受命修復10個缺陷，他就應該先從嚴重性為1 、優先順序為1這樣的缺陷著手，而不是優先修復簡單的，有簡到難。
同樣，兩個項目經理--一個管理廣告門戶網站/游戲軟體，一個管理醫院檢測儀/性能檢測類軟體，對待同樣的問題就會做出兩種選擇，比如同樣都是頁面美觀問題，在前者那優先順序可能就是2，在後者那可能就是3或者4了。
好了，今天到此結束。如有任何問題請留言及時與我溝通，我會盡快回復大家！謝謝大家~我們下次再見！
I. 我經常看到手機的某個版本的BUG少，麻煩給我解釋一下BUG是什麼
BUG就是缺陷 漏洞想意思
「BUG」的由來：
Bug一詞的原意是「臭蟲」或「蟲子」。但是現在，在電腦系統或程序中，如果隱藏著的一些未被發現的缺陷或問題，人們也叫它「Bug」，這是怎麼回事呢？
原來，第一代的計算機是由許多龐大且昂貴的真空管組成，並利用大量的電力來使真空管發光。可能正是由於計算機運行產生的光和熱，引得一隻小蟲子�Bug鑽進了一支真空管內，導致整個計算機無法工作。研究人員費了半天時間，總算發現原因所在，把這只小蟲子從真空管中取出後，計算機又恢復正常。後來，Bug這個名詞就沿用下來，表示電腦系統或程序中隱藏的錯誤、缺陷或問題。
與Bug相對應，人們將發現Bug並加以糾正的過程叫做「Debug」，意即「捉蟲子」或「殺蟲子」。遺憾的是，在中文裡面，至今仍沒有與「Bug」准確對應的詞彙，於是只能直接引用「Bug」一詞。雖然也有人使用「臭蟲」一詞替代「Bug」，但容易產生歧義，所以推廣不開。
所謂「（Bug）」，是指電腦系統的硬體、系統軟體（如操作系統）或應用軟體（如文字處理軟體）出錯。硬體的出錯有兩個原因，一是設計錯誤，一是硬體部件老化失效等。軟體的錯誤全是廠家設計錯誤。那種說用戶執行了非法操作的提示，是軟體廠商不負責的胡說八道。用戶可能會執行不正確的操作，比如本來是做加法但按了減法鍵。這樣用戶會得到一個不正確的結果，但不會引起bug發作。軟體廠商在設計產品時的一個基本要求，就是不允許用戶做非法的操作。只要允許用戶做的，都是合法的。用戶根本就沒有辦法知道廠家心裡是怎麼想的，哪些操作序列是非法的。
從電腦誕生之日起，就有了電腦BUG。第一個有記載的bug是美國海軍的編程員，編譯器的發明者格蕾斯·哈珀（GraceHopper）發現的。哈珀後來成了美國海軍的一個將軍，領導了著名計算機語言Cobol的開發。
1945年9月9日，下午三點。哈珀中尉正領著她的小組構造一個稱為「馬克二型」的計算機。這還不是一個完全的電子計算機，它使用了大量的繼電器，一種電子機械裝置。第二次世界大戰還沒有結束。哈珀的小組日以繼夜地工作。機房是一間第一次世界大戰時建造的老建築。那是一個炎熱的夏天，房間沒有空調，所有窗戶都敞開散熱。
突然，馬克二型死機了。技術人員試了很多辦法，最後定位到第70號繼電器出錯。哈珀觀察這個出錯的繼電器，發現一隻飛蛾躺在中間，已經被繼電器打死。她小心地用攝子將蛾子夾出來，用透明膠布帖到「事件記錄本」中，並註明「第一個發現蟲子的實例。」[1]
從此以後，人們將計算機錯誤戲稱為蟲子（bug），而把找尋錯誤的工作稱為（debug）。
J. 測試中遇到不可重現的Bug怎麼辦
測試中遇到不可重現的Bug處理辦法：
一、一定要提交。
1． 記得有這么個缺陷，以後再遇到的時候可能就會了解發生的原因。
2． 盡力去查找出錯的原因，比如有什麼特別的操作，或者一些操作環境等。
3． 程序員對程序比測試人員熟悉的多，也許你提交了，即使無法重新，程序員也會了解問題所在。
4． 無法重現的問題再次出現後，可以直接叫程序員來看看問題。
5． 對於測試人員來說，沒有操作錯誤這條.既然遇到，就是問題。即使真的操作錯了，也要推到程序員那裡，既然測試人員犯錯誤，用戶也可能會犯同樣的錯誤。錯誤發生的時候，Tester最大。
二、程序不是測試人員寫的，出問題也不是測試人員的原因。
至於無法重現，可能的原因很多，因為測試人員看到的只是程序的外部，無法深入程序內部，所以把責任推給測試人員是不對的。測試人員的任務只是盡力重現問題，而不是必須重現。
三、下次再遇到的時候，拉他們來看就可以了。
因為問題如果無論如何無法重現，程序員確實也沒有什麼好的解決方法。而且此類問題即使程序員說修改了，測試員也沒有好的方法去驗證是不是。
四、你可以告訴程序員，測試過程是沒有錯誤的。
測試人員只是檢查程序中可能存在的問題，雖然測試人員使用一定的手段方法努力去覆蓋所有的情況，但這些都是理論的推測。在實際中，可能因為人員、環境、配置等種種原因出現各種各樣的問題，在測試人員這里發現問題是公司內部的事情，程序發到外面可就是公司的形象問題了。
五、問題無法重現，也要提出，程序員那裡可以回復無法再現。問題放在那裡，等到再次出現的時候，就立刻叫程序員過來查看。實在沒有再次出現，最後可以寫到報告中，說出現了什麼現象，但無法再現（比較嚴重的問題才如此處理，小問題經理之間商量商量可能就算了）。