缺陷送出
by:授客 QQ：1033553122
怎麼送出缺陷？測試過程中都要注意什麼？
第一.缺陷截圖
理由：
缺陷可能難以重制，而在你再次驗證該缺陷前你并不知道這點，是以養成先對缺陷截圖的習慣，這樣不管啥時候，你都可以對相關人員直覺的展示出現過的問題。至少别人不可以否認你說“問題壓根不存在”
第二.是否重制
對于發現的缺陷，至少進行2-3次的重複驗證。
1.判斷缺陷是否可重制
2.确定重制缺陷需要的最簡單步驟
遇到難以重制的缺陷怎麼處理？
a) 停止操作，開始記錄
盡量回憶之前的操作步驟、操作過程，并記錄下來。包括操作環境。是以，個人覺得測試前有必要準備一個記錄模版，專門用于記錄這類問題。這個有助于後續的缺陷跟蹤。
b)判斷缺陷的嚴重性
缺陷雖然難以重制，但是難保該缺陷不出現在使用者現場，是以需要估量一下有什麼潛在的風險？
1.如果缺陷很嚴重，那麼做上重點标記，多花點時間，盡量重制問題。
2.如果問題比較輕微，比如在使用者可接受的範圍内，那麼可以考慮暫時擱置，把時間用在别的子產品的驗證測試，等其它子產品完成了再回過頭來找原因，因為時間有限，不要撿了芝麻丢了西瓜。
說明：難重制的缺陷一定要關注，因為有時候它背後可能潛伏着嚴重問題
c) 聯系相關開發人員一起分析問題
一旦重制，保留現場，聯系開發人員進行分析。試想，要是程式背景都有操作記錄日志的記錄，那是不是問題分析是不是簡單多了？
d) 缺陷跟蹤
原則上：測試過程中出現的任何異常問題都要送出
實際情況：
1.開發人員和測試人員都無法重制的情況下，送出的缺陷一般是不會被處理的（特别是開發也忙的時候，是不會去排查的），常以“無法重制”或者“無效缺陷”拒絕處理
2.缺陷考核，有些公司對測試人員有考核，比如使用者使用産品過程中出現了問題，但是測試如果沒提，那就算漏測缺陷，有對應處罰；對開發人員也有考核，比如按嚴重缺陷數扣錢
那怎麼做好呢？
在有考核的情況下，不管是否可重制，直接送出到公用缺陷管理系統
1.符合原則
2.涉及個人利益，誰想被扣錢或其它處罰呢？？
在無考核的情況下，視缺陷嚴重程度而決定是否直接送出
1、缺陷等級比較嚴重，直接送出到公用缺陷管理系統
理由：這個必須要引起重視，難保使用者現場就出現了
2、缺陷等級比較一般或輕微，先私下進行文檔形式記錄，再看情況決定是否送出缺陷管理系統
理 由：不可重制的缺陷可能由于外界環境因素引起的，比如網絡不穩定，某一瞬間可能沒網絡，你恰在這個點進行重新整理操作，沒刷出内容，這時，你不知道是網絡引起，直接把它當成缺陷了，，站在這個角度看，是不是可以說缺陷實際是不存在呢？你送出了這個缺陷，那就意味着相關人員，如開發人員，要去對這個缺陷進行分 析和關注，這個是要時間投入的
推薦做法：
一般的小問題，文檔記錄，要是後續重複出現，再考慮把文檔中記錄的缺陷送出到缺陷管理系統，這樣送出的缺陷更具有實際意義。
說明：
送出缺陷管理系統的難重制缺陷應該有個監控周期，一般可以考慮監控2-3個版本，過期還是未重制，可以考慮關閉
第三、是否需求
缺陷是針對需求來說的，如果需求中沒有相關說明，有些比較不好确定是否為缺陷的建議如下：
1.如果組織内部有約定，比如送出給需求負責人，則按約定送出(推薦方式)
2.如果組織内沒有約定，那以建議的方式送出缺陷。
建議類缺陷統一送出給産品負責人,好處是，一來和已固定需求分離，避免在開發周期内又新增需求，擾亂計劃；二來建議類的是否作為缺陷，是否需要實作，還得産品及其他相關人員進行評審；建議組織内部應該進行約定，比如方式二中，比較不老成的開發可能直接拒絕或把缺陷視為無效缺陷關閉了，而正确做法應該是轉需求的。
第四、缺陷的編寫
以禅道PSM的建立缺陷為例，截圖所示
由上圖可知，缺陷一般包含以下元素組成，因為一般我們都是用工具自動化生成資料統計結果的，如果相關元素美填寫，那就無法生成相關資料，是以送出前要依據實際項目想清楚要關注哪些元素
-----------------------------------------------------------------------
産品子產品：
産品的功能子產品，根據子產品的缺陷統計，可以看到缺陷的分布情況，那個子產品的缺陷比較多，品質較差
所屬項目：
一個産品可關聯多個項目，一個項目可以有多個版本，每一個版本都擁有自己的缺陷(一般分兩部分，一部分是回歸測試中未解決的缺陷，一部分是新發現的其它缺陷)
舉例：我們公司有做資料庫審計類産品，該類産品細分為一體機資料庫審計系統，分離式資料庫審計系統，一體機資料庫審計系統-醫療專版，一體機資料庫審計系統-财經專版…等等各種産品，針對每個産品又細分多個版本，一體機資料庫審計系統2012Q1版本，一體機資料庫審計系統2012Q2版。。。等等各種版本。
影響版本：
項目的完成通過多個小版本的疊代實作
目前指派：
根據缺陷管理，這裡一般是指派相關負責人，比如測試經理、項目經理、開發人員。個人比較建議直接指派給直接負責人，直線溝通
缺陷标題：
第一：順藤摸瓜>見到标題就知道缺陷屬于哪個子產品的
第二：見名知意>見到标題就知道缺陷描述的是什麼
綜合這兩點：我給的建議書寫格式：大子產品(-子子產品)-問題描述，如下圖。
附加好處：缺陷分析時，就算不用工具也可以某個影響版本進行統計，Excel缺陷清單中查找大子產品或子子產品名稱，檢視其數目便可以得出缺陷分布情況(前提是組員在送出缺陷時統一遵守約定)，對此也提醒下，子產品的劃分及名稱要适當。
重制步驟:
資料和邏輯分離
好處：
第一：邏輯清晰，易讀易懂，因為缺陷是給别人看的。
第二：不因為資料失效而失效。如果資料和邏輯混合:
1.打開資料分析-資料庫審計查詢
2.輸入時間範圍：1012-12-22
00：00：00到2012-12-22
59：59：59,10.4.0.6，點選查詢
問題：是不是隻有這天的ip資料，這個特定的ip才會出現缺陷呢？？（測試驗證缺陷，開發驗證缺陷，回歸驗證缺陷），是不是很難說呀
例：如下圖
資訊要全面，[前提]，[步驟]，[結果]，[期望]，[測試賬号]，[缺陷頁面位址]，根據實際情況有選擇的添加
相關需求：
與bug管理的需求，，這個實際中比較難以做到，一般不填
相關任務：
同上，這個實際中也比較難做到，一般不填
類型/嚴重程度
:
“類型”這東西有時候真不大好細分，大部分都可看成是設計缺陷，做不到就算了吧，簡單就是效率，但是嚴重程度必須有。
“嚴重程度”：
第一：分輕重>事分輕重緩急，同樣，缺陷是給别人看的，别人更在乎重點，是以建議不要随便給個數字(我們可以把數字和自己定義的嚴重程度進行對應，在進行缺陷分析時進行缺陷等級統計時，就看這個了)
根據一般的産品管理系統看，缺陷等級分為
五個等級：
1建議
2輕微
3一般
4嚴重
5緻命
至于這些等級對應什麼樣的缺陷内容，這個不大好說，感覺應該多站在客戶角度看待。另一個方面，根據個人經驗及其它人的看法，組織内部進行個規範定義。
系統/浏覽器：
這個根據具體情況而定，比如要适應多種環境，要同時相容好幾個浏覽器，那要把其作為缺陷内容重要部分進行送出，假如隻是指定某一浏覽器的相容，那不寫也罷。直接在bug重制步驟中添加[作業系統/浏覽器]
，省得每次都點選指定
關鍵詞：
附件：
這個挺有用的，比如bug描述中無法放圖檔時，可放截圖，還可以放相關錯誤資訊等
最後
一個缺陷隻描述一個或同一類的問題
缺陷優先級
優先級不應該給tester指定，這也是很多缺陷流程制定者容易忽略到的地方——很大一部分原因是流程制定者沒有做過項目管理的工作或者學習過項目管理的知識。
為什麼這麼說呢？
因為Tester隻是項目團隊的成員之一，對缺陷管理、項目進度和項目風險都不可避免的會“盲人摸象”、“管中窺豹”，隻“看”到自己“看”到的那個部分。
一般來說，一個被測系統往往需要多個tester的，而每個tester往往隻關注自己發現的缺陷，不大會去了解其他tester所發現的缺陷，那麼在這種情況下，他如何能夠決定這個缺陷被修複的優先級别呢？！
這裡再次強調一次，大家必須了解“Priority”真正的含義和作用——它是給管理者來據此做項目決策的，也就是說，缺陷優先級将直接導緻工作安排的優先順序。PM正是通過參考缺陷優先級來安排開發人員的工作順序（這甚至能在Project裡展現），使得項目風險降低、項目成本降低，解決問題更高效。
其實，這在微軟内部就叫做“基于風險的測試”，
也就是指評估測試的優先級，先做高優先級的測試，如果時間或精力不夠，低優先級的測試可以暫時先不做。有一個圖，橫軸代表影響，豎軸代表機率，根據一個軟
件的特點來确定：如果一個功能出了問題，它對整個産品的影響有多大，這個功能出問題的機率有多大？如果出問題的機率很大，出了問題對整個産品的影響也很
大，那麼在測試時就一定要覆寫到。對于一個使用者很少用到的功能，出問題的機率很小，就算出了問題的影響也不是很大，那麼如果時間比較緊的話，就可以考慮不
測試。
話說回來，網上有很多自稱專家的人在那裡大談特談所謂的優先級标準，什麼“系統當機是進階别，界面錯誤是低級别”之類。其實這些指的是缺陷的嚴重級别（Serverity）！
作者：授客
QQ：1033553122
全國軟體測試QQ交流群：7156436
Git位址：https://gitee.com/ishouke
友情提示：限于時間倉促，文中可能存在錯誤，歡迎指正、評論！
作者五行缺錢，如果覺得文章對您有幫助，請掃描下邊的二維碼打賞作者，金額随意，您的支援将是我繼續創作的源動力，打賞後如有任何疑問，請聯系我!!!
微信打賞
支付寶打賞 全國軟體測試交流QQ群