為了便于大家理解，在開始談如何提交有效缺陷這一問題之前，想先和大家談?wù)勱P(guān)于“吐槽”的觀點(diǎn)。

“吐槽”一詞，是指從對(duì)方的語言或行為中找到一個(gè)漏洞或關(guān)鍵詞作為切入點(diǎn)，發(fā)出帶有調(diào)侃意味的感慨或疑問。普通話里相當(dāng)于相聲的“捧哏”。

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

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

不知道大家做測(cè)試的時(shí)候有沒有遇到一個(gè)現(xiàn)象：

當(dāng)你提出一個(gè)問題，開發(fā)會(huì)不認(rèn)可你，或者客戶也不認(rèn)可你。

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

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

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

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

2、開發(fā)為什么要為你提出的問題去花時(shí)間去改？

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

所以說回來我們?nèi)粘５耐虏郏總€(gè)人都會(huì)吐槽，但是并不是每個(gè)人都能吐槽到正確的點(diǎn)上。

其實(shí)很多事情都是存在爭議的，并沒有絕對(duì)的對(duì)與錯(cuò)，看待一個(gè)問題更多的是站在不同的角度和環(huán)境下能得出不同的結(jié)論。

那么在這么一個(gè)前提下，我們測(cè)試工程師的工作就顯得比較富有意義了，因?yàn)檐浖y(cè)試是一種過程，在這個(gè)過程中，你需要做的就是找出缺陷，讓開發(fā)改掉它，并得出軟件質(zhì)量能達(dá)到預(yù)期的最終結(jié)論（也就是上線）。

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

是否能有效地提交缺陷始終是界定一個(gè)測(cè)試人員的標(biāo)準(zhǔn)，而測(cè)試人員掌握代碼知識(shí)也是為了更好地進(jìn)行有效缺陷地提交。如果你對(duì)如何提交有效測(cè)試有什么不明白的，或者對(duì)自動(dòng)化測(cè)試和性能測(cè)試感興趣的話可以加680748947，了解一下測(cè)試大師們是如何優(yōu)雅地提交bug，在團(tuán)隊(duì)中混得如魚得水，加群記得備注（缺陷），希望大家可以一起交流進(jìn)步。

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

一，我們?yōu)楹我虏郏ㄌ崛毕荩?/p>

我們吐槽可能有很多原因，基本上可以總結(jié)為下面三點(diǎn)：

主觀意識(shí)的提升

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

其次意識(shí)到自己的責(zé)任和義務(wù)，比如在測(cè)試人員在公司上班的時(shí)候，就算你不想吐槽，為了工作的正常進(jìn)行，你也不得不吐槽（提缺陷）。

為了工作環(huán)境的和諧

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

證明與表達(dá)自己

基本上每個(gè)人都預(yù)測(cè)過某些事情，比如他如果不這么做，就會(huì)怎么怎么樣。通過自己的得到的信息資源的整合，做出一個(gè)預(yù)測(cè)其實(shí)也是一種知識(shí)的體現(xiàn)。

二、如何進(jìn)行有效吐槽（提缺陷）

吐槽要吐到點(diǎn)上

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

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

符合邏輯：提交缺陷的時(shí)候一定是要符合邏輯的，問題的出現(xiàn)總是有前因后果，不可能因?yàn)槲遗W(xué)習(xí)所以他考上了大學(xué)。

吐槽要引起共鳴

代表大多數(shù)人的想法：要為自己的觀點(diǎn)樹立堅(jiān)實(shí)的群眾基礎(chǔ)，如果大家都認(rèn)為你是對(duì)的，工作就能很輕松的進(jìn)行下去。但是不是你找出一個(gè)缺陷它就一定是一個(gè)缺陷。

制造不同觀點(diǎn)的討論：也可以提出不同觀點(diǎn)讓大家來討論，特別是你自己都不確定是否是缺陷的時(shí)候，提前發(fā)現(xiàn)總比被開發(fā)懟回來強(qiáng)。

三、吐槽和缺陷

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

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

比如說釘釘，釘釘有個(gè)功能是已讀回執(zhí)，老板發(fā)了一條信息，只要你點(diǎn)開了老板就知道你已經(jīng)讀取了這條信息，這會(huì)給你壓力，讓你盡快回復(fù)老板的信息。你可能覺得這個(gè)功能很爛，給你造成了壓迫感。但是從整個(gè)使用環(huán)境來說這能有效地提升工作效率，增強(qiáng)公司上下溝通能力。

很多設(shè)計(jì)都是基于吐槽而來的，比如產(chǎn)品需求分析的時(shí)候，有人吐槽說以后使用的人變多了怎么辦？那么這就是一個(gè)有效的吐槽，開發(fā)人員會(huì)根據(jù)將發(fā)生的情況做出合理的設(shè)計(jì)避免負(fù)載嚴(yán)重。

四、有效缺陷

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

比如點(diǎn)擊提交失敗，開發(fā)一般是不樂意改這樣的bug的，因?yàn)槟愕娜毕莶粔蛴行В荒芙Y(jié)合相關(guān)的數(shù)據(jù)定位到問題的所在。開發(fā)要花很多時(shí)間幫你排查這到底是業(yè)務(wù)問題還是底層問題。所以為什么功能測(cè)試真的很輕松，因?yàn)檫@都是別人花了大量的時(shí)間幫你把本來屬于你的工作任務(wù)完成掉了。可能你不會(huì)認(rèn)同我的觀點(diǎn)，但事實(shí)就是這樣，開發(fā)和測(cè)試和運(yùn)維的界限不是那么明顯。

當(dāng)開發(fā)覺得他可以自測(cè)試，自驗(yàn)證的時(shí)候他就可以把你干掉了，因?yàn)槟愀緵]有什么存在的價(jià)值。而所謂的開發(fā)不能測(cè)試自己的程序，他只要把程序再給其他開發(fā)再測(cè)一遍就行了。

因此測(cè)試人員在devops團(tuán)隊(duì)的時(shí)候，通常都會(huì)有一種感覺，就是自己的存在價(jià)值太低了。在整個(gè)團(tuán)隊(duì)進(jìn)行快速迭代敏捷開發(fā)的時(shí)候本身留給測(cè)試的時(shí)間就不多了，如果你不能快速，準(zhǔn)確定位問題并提交。在一周迭代一次的版本中，那確實(shí)沒什么存在必要。

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