為了便于大家理解，在開始談如何提交有效缺陷這一問題之前，想先和大家談談關于“吐槽”的觀點。

“吐槽”一詞，是指從對方的語言或行為中找到一個漏洞或關鍵詞作為切入點，發出帶有調侃意味的感慨或疑問。普通話里相當于相聲的“捧哏”。

那么為什么要談的是測試如何提交有效缺陷卻說到“吐槽”去了呢，二者之間是否有什么聯系呢？大家不妨先思考一下，下面進入正題：

大家對吐槽都不陌生，可以說每天都在吐槽，而大家每天吐槽的點基本上都差不多。比如：為什么我找不到功能測試的好工作呢；為什么我在公司里不被重視呢；為什么我提交的缺陷開發總是不樂意改呢，等等。其實這些吐槽都是比較表面的，沒什么作用的吐槽，更像是一種抱怨和茫然。

不知道大家做測試的時候有沒有遇到一個現象：

當你提出一個問題，開發會不認可你，或者客戶也不認可你。

你就會說公司軟件bug那么多，大家又不接受我提交的缺陷，那我有什么辦法。

最后結論是：這公司不適合我，我的工作不受重視。

但是大家更深層次的想過問題的根源嗎：

1、你提交的bug到底是不是bug？

2、開發為什么要為你提出的問題去花時間去改？

所以最重要的問題就是：當你提交bug給開發，讓開發去改的時候，如果你不能讓他信服，人家憑什么配合你去改這個BUG？

所以說回來我們日常的吐槽，每個人都會吐槽，但是并不是每個人都能吐槽到正確的點上。

其實很多事情都是存在爭議的，并沒有絕對的對與錯，看待一個問題更多的是站在不同的角度和環境下能得出不同的結論。

那么在這么一個前提下，我們測試工程師的工作就顯得比較富有意義了，因為軟件測試是一種過程，在這個過程中，你需要做的就是找出缺陷，讓開發改掉它，并得出軟件質量能達到預期的最終結論（也就是上線）。

而且不管你現在做的功能測試，還是將來要做的接口、自動化、性能等等，你要考慮的首要問題都是如何提交bug以及讓開發人員能心甘情愿的改掉這個bug，最牛逼的就是你提出一個bug，開發不但不反感還覺得你提的bug避免了未來可能會出現的事故。一個好的測試工程師總能做到這點，而且他總是團隊里面的“潤滑劑”，協調好開發、產品、運維之間的關系，貫穿于軟件質量生命周期的全過程。

是否能有效地提交缺陷始終是界定一個測試人員的標準，而測試人員掌握代碼知識也是為了更好地進行有效缺陷地提交。如果你對如何提交有效測試有什么不明白的，或者對自動化測試和性能測試感興趣的話可以加680748947，了解一下測試大師們是如何優雅地提交bug，在團隊中混得如魚得水，加群記得備注（缺陷），希望大家可以一起交流進步。

下面幫大家梳理一下從有效吐槽到有效缺陷的轉變過程：

一，我們為何要吐槽（提缺陷）？

我們吐槽可能有很多原因，基本上可以總結為下面三點：

主觀意識的提升

首先你會意識到與自己有關，與我無關的事情沒人會去吐槽，或者說根本不知道要怎么吐槽好。突然想到這也可能會是一個尬聊的原因，如果你根本不了解一個人，他和你的槽點都不一樣的話，兩個人一定是沒話說的。

其次意識到自己的責任和義務，比如在測試人員在公司上班的時候，就算你不想吐槽，為了工作的正常進行，你也不得不吐槽（提缺陷）。

為了工作環境的和諧

人人都是有自己的思想的，不可能大家不進行交流也能把工作做好，大家都需要把自己的想法說出來，表明自己工作中需要得到的幫助和協調，然后再一起努力并最終完成工作。

證明與表達自己

基本上每個人都預測過某些事情，比如他如果不這么做，就會怎么怎么樣。通過自己的得到的信息資源的整合，做出一個預測其實也是一種知識的體現。

二、如何進行有效吐槽（提缺陷）

吐槽要吐到點上

內容準確：作為一個測試工程師需要保證提交的缺陷內容上是準確的，如果開發看到都不知道你寫的缺陷是什么那怎么修改。

結果清晰：要把缺陷的結果清晰的描述出來，更加方便開發知道哪里出錯，定位缺陷做出修改。不要只考慮自己工作的完成，開發花時間定位bug浪費的是大家的時間。

符合邏輯：提交缺陷的時候一定是要符合邏輯的，問題的出現總是有前因后果，不可能因為我努力學習所以他考上了大學。

吐槽要引起共鳴

代表大多數人的想法：要為自己的觀點樹立堅實的群眾基礎，如果大家都認為你是對的，工作就能很輕松的進行下去。但是不是你找出一個缺陷它就一定是一個缺陷。

制造不同觀點的討論：也可以提出不同觀點讓大家來討論，特別是你自己都不確定是否是缺陷的時候，提前發現總比被開發懟回來強。

三、吐槽和缺陷

吐槽的主要原因是每個人看待問題的方式和維度不同，它一般是基于支持的體系、你的大局觀，你的利益。舉個栗子，我是火箭的球迷那我肯定是要為火箭說話的，吐槽的點都是裁判判罰的是否對火箭有利。這是基于一個球迷的角度。

缺陷和吐槽要有一致性。缺陷的提出總是基于公司的利益，為了讓公司的軟件質量更高你需要提缺陷。那么基于軟件技術提缺陷你能否做到測試左移？你能在系統測試級別還是在集成測試級別還是在單元測試級別甚至在需求級別就能找到缺陷？基于用戶需求提出缺陷成本是很低的，但這需要你不斷的思考。

比如說釘釘，釘釘有個功能是已讀回執，老板發了一條信息，只要你點開了老板就知道你已經讀取了這條信息，這會給你壓力，讓你盡快回復老板的信息。你可能覺得這個功能很爛，給你造成了壓迫感。但是從整個使用環境來說這能有效地提升工作效率，增強公司上下溝通能力。

很多設計都是基于吐槽而來的，比如產品需求分析的時候，有人吐槽說以后使用的人變多了怎么辦？那么這就是一個有效的吐槽，開發人員會根據將發生的情況做出合理的設計避免負載嚴重。

四、有效缺陷

有的缺陷提的太表面，比如字體大小不一致，選擇框一個上一個下。很多時候我們提缺陷的時候，業務不夠精通不能站在用戶的角度去說服開發的時候，那么這時候你需要的就是考慮用技術。所以說現在做測試為什么越來越需要開發的能力，你需要懂得調試的功能，只有這樣你才能明白這是底層的問題還是表面的問題。

比如點擊提交失敗，開發一般是不樂意改這樣的bug的，因為你的缺陷不夠有效，不能結合相關的數據定位到問題的所在。開發要花很多時間幫你排查這到底是業務問題還是底層問題。所以為什么功能測試真的很輕松，因為這都是別人花了大量的時間幫你把本來屬于你的工作任務完成掉了。可能你不會認同我的觀點，但事實就是這樣，開發和測試和運維的界限不是那么明顯。

當開發覺得他可以自測試，自驗證的時候他就可以把你干掉了，因為你根本沒有什么存在的價值。而所謂的開發不能測試自己的程序，他只要把程序再給其他開發再測一遍就行了。

因此測試人員在devops團隊的時候，通常都會有一種感覺，就是自己的存在價值太低了。在整個團隊進行快速迭代敏捷開發的時候本身留給測試的時間就不多了，如果你不能快速，準確定位問題并提交。在一周迭代一次的版本中，那確實沒什么存在必要。

那么，作為軟件測試工程師的你，將會如何選擇未來的路？