軟體專案交付後,bug太多?測試 這鍋我不背!

2021-09-10 12:21:10 字數 2189 閱讀 7851

--「 兄弟,又開始寫bug啦?」

--「 兄弟,感謝你養活了我們整個組。」

一萬個測試工程師在酒吧門外呼嘯而過

乙個測試工程師走進一家酒吧,什麼也沒要

乙個測試工程師走進一家酒吧,要了一杯啤酒

乙個測試工程師走進一家酒吧,要了一杯咖啡

乙個測試工程師走進一家酒吧,要了0.7杯啤酒

乙個測試工程師走進一家酒吧,要了nan杯null

乙個測試工程師走進一家酒吧,要了2^32杯啤酒

乙個測試工程師走進一家酒吧,要了一杯燙燙燙的錕斤拷

乙個測試工程師走進一家酒吧,要了乙份asdfqwer@24dg!&*(@

乙個測試工程師化裝成老闆走進一家酒吧,要了500杯啤酒並且不付錢

1t測試工程師衝進一家酒吧,要了500t啤酒咖啡洗腳水野貓狼牙棒奶茶

乙個測試工程師走進一家酒吧,又走出去又從窗戶進來又從後門出去從下水道鑽進來

乙個測試工程師走進一家酒吧,又走出去又進來又出去又進來又出去,最後在外面把老闆打了一頓

測試工程師們滿意地離開了酒吧。

然後一名顧客點了乙份炒飯,酒吧炸了。。。

如果把酒吧理解成乙個資料庫……

上面那個段子就是說在測試的時候請求各種合法的不合法的資料都正常執行了,然後投入使用分分鐘被沒考慮到的請求搞崩了

若是如此,那在外包或眾包軟體下的測試工程師豈不是更慘?

翠花為了弄清楚這個問題,果斷找了客棧平台上的優質測試forkey問了問~

forkey來自福建漳州,已經30的他,和大多數人一樣正值芳華,與妻子恩愛,事業順利。從事軟體測試5年多。

找到他後,翠花就想到自己不懂測試呀!摔!!不管了,既然足夠優秀,那就直接請教吧~就這樣,開啟了小白翠花對測試工程師無下限詢問的旅程:

原來測試是分好多種的,在forkey的描述中,測試有功能測試、自動化測試、安全測試、效能測試等。

其中常用的測試就會包括測試用例的編寫,然後找bug ,提交bug ,回歸bug後產品上線啥的。也就是他們常說的手動測試吧~

遠端兼職做專案,一把做好的產品提交給客戶,就會出現類似於開頭那個段子出現的酒吧**的情況,這是為什麼呢?

forkey告訴翠花,這種情況會是由於很多原因的。

比如產品原型不清楚,有歧義。導致產品經理跟客戶之間是有歧義的,導致後期交付到專案方手裡,被當作了bug。

還比如是在專案開發方面,開發人員開發完後並沒有先自測,測試在測試回歸階段會因為一些隱秘的東西,測不全。

或者是後期更改需求了,開發者加進去了,但是測試並不知道,遠端可能這點不太好,有變化,應該及時反饋,做到團隊悉知。

在遠端兼職做專案中,測試在客戶驗收的出現「很多客戶反饋,測試都是他們自己測的,測試人員很多只走一下流程,沒有按照交付去測試」的這種吃力不討好的現象呢?

forkey說,在產品原型之後應該馬上讓測試人員介入,和產品經理一起再次梳理原型,這樣對於一些漏洞,能夠提早的說出來,進行改進,加固需求完善性,減少後面開發按照錯誤的原型進行開發。

當然在他看來編寫測試用例是非常必要的。這是基於和產品經理一起梳理需求之後的乙個自然而然的步驟。當然評審也很重要「測試用例評審的話,bug肯定會好的。」對於一些潦草,功能點沒展開的測試用例,評審的話專案經理會幫助改進一下。

比如你檢查出這個是bug,讓開發去更改,但是這時候可能需求是正確的,但是開發與測試理解的是兩種含義。當然這時候也可能包括客戶的描述不清楚,那麼這時候就不是bug而是模凌兩可了。

解決辦法不是沒有,對於容易產生歧義的地方,產品經理應該會給出注釋。除非本身他們自己也沒想到,這個都是沒辦法的,身而為人,翠花覺得bug這事確實緣由太多了,若是單純在交付後出現bug去形成一種測試並沒有做好的工作的看法,就是一種偏見了

因為在翠花的公司:

如果有一天,我老無所依

請把我留在bug堆裡吧!!!

—— 董開發

軟體測試 測試可交付成果

測試可交付成果列表 測試策略文件 測試計畫文件 測試成本估算報告 通常使用者估算執行相關測試所需要的花費的人力和物力成本和時間 測試情境和劇本 通常是按照功能需求文件衍生而來 測試用例和測試指令碼 測試資料 需求跟蹤測試陣列 rtm 用於檢查測試用例和產品需求的覆蓋程度 缺陷報告 測試執行結果 產品...

軟體測試完後,還有BUG,是測試人員的問題嗎

bug也要分情況 1 需求裡面有明確說明或者測試應該測試到的點,如果還有bug,那就是測試的責任 2 如果還有優化類的bug不能算測試的責任 3 如果還有不符合使用者要求但是需求設計就錯了的,不算測試的bug 為了測試不背鍋,所有關於bug溝通的記錄都要有記錄,方便以後不背黑鍋 1 測試發現這個問題...

軟體測試總結之bug處理

軟體測試工程師的職責是找bug。當然了也不能說只是找bug,高大上一點應該還 功能的健壯性,但是回歸到本質,碰到bug怎麼處理呢?1.記錄問題 1.1 bug的標題,即一句話簡要的概括bug 1.2 bug的描述,詳細的描述bug,是否是相容問題 1.3 bug的復現,記錄bug的復現步驟 1.4 ...