我們發現這個缺陷之后，如何進行有效的記錄？如何提交一個高質量的Bug
至少讓開發看到這個Bug的時候，他知道怎么樣去進行復現，然后他不會第二次第三次第四次來問你，呃，你這個是怎么操作的，你這個是怎么復現的？你這個準備資料是什么？
如果說你提了一個Bug之后，一個開發不斷的來跟你溝通，你的操作是什么樣子的，你有什么前提條件，你要準備什么樣的資料、環境，有這些問題就表示你的Bug提交得不到位，這個肯定會影響開發修改的效率，在這中間他懷疑你提交的Bug不好，你懷疑他的理解能力不夠，一來一回就很容易起沖突！
所以對于我們軟體測驗工程師第二職責就是如何去提交一個高質量的Bug，（第一職責如何去判斷一個問題是缺陷，或者說我如何來推動缺陷的修改，可以閱讀我往期的文章）
怎樣有效記錄缺陷，在這里我給大家總結了五個點，
第一個我們要保證這個缺陷是可以重現的，我們常見的Bug我們可以把它分為兩大類，一個是可以復現的Bug，第二一類是偶現的Bug，就是說低概率出現的Bug，
文章首發于公眾號程式員一凡，免費領取學習資料
對于第一類可以復現的Bug，比較簡單，比如我在我的界面打開一個檔案夾，然后進到某一個路徑，然后我某一個Excel表格打不開，那么這就是一個Bug，在這里不管我是在我的環境底下還是在開發的環境底下，都存在這個問題，你用同樣的這個操作（打開某一個檔案夾路徑，里面的表格檔案打不開）就依次可以復現的，那么對于這一類問題，我們就把它叫做可以復現的Bug，
對于第二一類的問題，比如說我打開某一個檔案夾，進到某一個路徑之后，有時候進來表格打不開，有時候又可以打開，對于這種出現的概率比較的低，是不穩定的，對于這一類我們就把它叫做偶現的問題，
對于這兩類問題我們做為軟體測驗工程師應該怎么樣去處理？
首先第一個點，對于偶現的bug也好還是可以復現的Bug也好，咱們都要提交，只要是一個Bug都要進行提交，只是在提交的時候呢，咱們偶現的Bug你要多提交一些東西，因為對于偶現的bug，開發那邊不一定能夠復現，開發不修改的幾率就大了，
第一個寫清楚當時的環境，第二個提供更多的幫助，讓開發來復現這個問題
去錄一些視頻，抓一些日志，你提供的這一些東西，都是能夠幫助開發提高修改這個Bug的概率的，
我一個人在測驗的時候，這個問題可能就是十分之一的概率，那么如果說是一百萬個人來進行同樣的操作，那么它可能會出現的概率就大大提高了，
既然它會出現，它就肯定會有一個穩定的路徑，只是目前我還沒有發現，所以說對于偶現的Bug我們千萬不能去忽視，反而要去重視，
第二一個的話呢，我們要去記錄這個缺陷的時候，就要把重現這個Bug的步驟寫出來，寫步驟的時候既不要太啰嗦，也不要太簡略，
第四一個，每一份報告中只記錄一個缺陷，前面我們提到的我打開一個檔案，里面的一個表格打不開，這是一個Bug，如果說我們在同一個路徑還發現了另外一個Bug比如檔案顯示不全，同樣的路徑同樣的操作我發現了兩個Bug，那么我們就需要分兩個Bug作為提交，
最后一個點就是我們在描述的時候，只要做到陳述事實就可以了，不要去做主觀臆斷，不要加上的主觀的一些情緒，或者說你自己的一些語氣助詞等等之類，
比如說對于我們產品界面的一個設計，然后你覺得這個界面設計不好看，不符合用戶的一個審美，那我們就比如說這個頁面什么內容沒有居中顯示，然后不太符合用戶的使用習慣或者整個頁面排版不太好看，這樣就秒速一個正常的現象，但是你不能寫成說你這個頁面設計得巨丑，太丑了，簡直無法看了，這個就加入了你自己個人的情緒語氣助詞，
產品或者設計看到提交的內容肯定會很不舒服，所有又會引起一些矛盾，
拓展：測驗要不要分析Bug？
對于功能測驗工程師來說，你能夠去發現這個Bug，并且去進行提交，就OK了，
但是對于對自己有要求，或者說我想要去提升自己的技術，接觸到更多的知識面，想讓開發盡快的來解決這個Bug的話，那么我們軟體測驗工程師要具有分析Bug的一個能力，
我們找到這個問題之后，要求專研精神，這個問題是怎么產生的呢？是前端問題還是后臺問題，當你開始這樣去思考的時候，你的成長就會非常的快，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/225585.html
標籤：其他