1. 程式人生 > >軟體測試員的要求比軟體開發員的要求低嗎?

軟體測試員的要求比軟體開發員的要求低嗎?

首先,表面上是這樣的,但是本質上並不是,想知道原因,我用一篇文章告訴你看到的都是表象。很多小公司對於測試的流程和要求並不是很高,就更加顯得測試比開發的要求低。

即使說經過這幾年的發展,測試行業已經比以前成熟和正規許多,但是你攔不住很多公司並不在乎什麼流程,什麼計劃。因為對於很多小公司來說,開發人員是他們的命脈,可能有10個開發,但是隻有1個測試。在這些老闆的主觀認為,開發解決的是有無的問題,而測試是解決好壞的問題。在缺乏長遠目光、追求眼前利益的情況下,對於產品的態度也就是隻求“過的去”,不求“過的硬”。

所以,覺得測試比開發的要求低,有一部分國內行業現狀造成,這是第一個原因。身邊確實接觸到很多的測試做了很多年,還是一個點點點,培訓三四個月出來的就比他會的多,你說是他們公司的原因,還是他個人的原因?

那麼說覺得軟體測試比開發要求低的原因是這個工作性質的原因,這是第二個原因。

大家都知道,軟體測試入門簡單,開發入門比較難。但是開發入門難,精進更難,測試是入門容易,精進也難。做測試到中級測試工程師,必須要接觸到介面、效能、自動化方面,而這又涉及到程式碼、指令碼、框架,所以說那些說測試比開發要求低,我只能還是在門外或者還是沒有深刻的認識測試行業。

所以,最終的結論就是:軟體測試人員比軟體開發員入門、初級的要求低,但是把這個工作當做事業去做,按照長久的職業去發展的,要求並不低。

從這個問題發散去思考,發現的確當下無論是行業內還是行業外,對於軟體測試還是存在一些誤區的,通過和身邊做測試的朋友深入的去交流,也歸納整理出來一些問題合集,那麼在此就佔用一些篇幅絮叨絮叨。如果你真的想清楚的認識這個行業,一定要耐心的看下去,無論你的技術牛不牛!
在這裡插入圖片描述


自己整理了軟體測試人員最容易陷入的28個誤區,老規矩,文章思維導圖放在文末,需要原圖私信或者留言都行。文章共2000多字,預計閱讀時間4分鐘,希望對你們有所幫助。

80%的軟體測試人員都不知道的28個誤區 視訊連線

1、測試和開發永遠都是死對頭

雖然測試與開發的工作性質是對立的,但是目的都是為了專案更好的發展。

我以前發起過一個倡議:我們討論的時候不要用他們(開發人員)和我們(測試人員),而是統一用咱們,因為開發人員和測試人員本來就是一起的。如果測試人員能與開發人員成為朋友,你會發現,工作會非常順心,在我所在的企業中,測試人員和開發人員關係非常融洽,互相尊重,對大家的工作能力和技術表示肯定。

其中的訣竅重點在於測試這邊的溝通,誰也接受不了別人指責自己得意之作,所以測試要以幫助開發讓開發的‘孩子’更健康,讓開發‘帶孩子’別那麼辛苦;

測試是系統它爹,開發是系統它媽,當媽的那麼痛苦的生出來,當爹的要揍,當媽的能同意麼,脾氣上來了,當爹你就緩一下,哄哄,當媽的也不是傻子,她也知道對錯的,當媽的要實在糊塗,那你還猶豫什麼,抽她(哈哈,開個玩笑,還是要以理服人)。

2、測試人員不需要了解軟體開發知識

測試人員跟開發人員交流不暢,主要是有以下幾個原因:

(1)測試人員如果看不懂開發程式碼,會導致BUG描述不清晰,不準確,開發人員不明白BUG應該怎麼重現,或者你想說的是什麼,甚至是一些很膚淺的bug,卻被測試人員認為是非常嚴重的問題。

(2)測試人員的開發知識匱乏,將不是BUG的BUG提交給開發人員,或者提出的建議性意見在開發中實現起來比較困難,又無法給出一個合理的解決辦法(開發人員易於實現的辦法)。

(3)測試出BUG的同時,無法清晰準確地定位BUG出現的源頭,導致與開發人員交涉次數過於頻繁,時間是寶貴的,缺乏交流有害,交流過多也容易出問題。

所以,測試人員對開發知識的瞭解是必須的。

(4)如果不瞭解開發知識,測試人員很容易被開發人員牽著鼻子走,對於一些BUG的PK,經常是理屈詞窮,因為開發人員隨便一忽悠,你如果不瞭解箇中奧妙,你一個字也說不上來。

(5)自動化測試和效能測試包括專案管理,都會要求對軟體開發有深入的理解,如何能設計一個好的自動化框架,好的效能測試用例,如何管理一個開發團隊,這都需要我們在軟體開發方面有所掌握。

所以,測試瞭解軟體開發知識是必須的。

3、軟體測試很簡單

軟體測試入門相對比開發人員確實更容易一些,原因是開發一開始就要掌握一門語言,而測試到中後期才需要掌握開發語言技術,測試更重視的是測試思路,方法,以及測試工具的掌握。但是到了中後期,軟體測試需要掌握的知識量將遠大於開發人員,測試後期要掌握功能,效能,自動化,介面,協議,抓包,安全性,包括移動端等一系列測試工具,技術難度性絲毫不亞於開發技術。

4、測試就是為了找到bug

測試人員不僅需要找到bug,還要跟蹤bug直至問題得以被修復,對缺陷進行確認測試並關閉缺陷,測試員還需要分析問題原因,避免因此問題影響到其他功能。

不僅如此,測試還需要對軟體進行效能測試、自動化測試和安全性測試等一系列其他測試手段,目的是找出系統漏洞,找出效能瓶頸,伺服器抗壓能力及穩定性。這已經遠遠超過找bug的範疇。

5、自動化測試太難

很多初學者都認為自動化測試相比效能和功能都要難很多,實際上每個測試方向做精通都不容易,自動化只是測試其中的一部分,功能測試做到極致也不容易,效能測試做到精通也同樣需要各種技術手段,自動化無非就是需要懂一些程式碼,難點不在技術,而是思路和實施操作,實際上只要付出同樣多的努力,無論是效能還是自動化,都可以做的很好。

6、手工測試沒有挑戰性

手工測試是測試的基本功,也是每一個測試必經之路,但是真正做好的人沒有幾個,很多人認為手工測試就是點點點,我認為這個說法就是對測試的汙衊,手工測試的範圍很大,包含涉及的內容也非常多,例如資料準確性,表單值域,邏輯分析,業務梳理,互動易用性,逆向思維,UI相容性,cookie等…單單說業務邏輯和業務流程測試,就有多少人測試不全面,分析不到位而導致釋出上線後出現嚴重問題。

7、軟體測試工作重複又枯燥

軟體測試的範圍很廣,測試的手段和方法也是不一樣的,而且每個人測試一個專案的思路也不同,實際上認為重複性工作的人,往往是技術差的人,因為他始終沒有任何成長。

真正做好測試的人對待每一個專案都可以使用不一樣的測試方法,介面測試結束就測功能,功能測完了就做做自動化,上線之前做做效能測試,測試工具也可以隨意更換,對於我來說,每一個新專案的開始,都是一次新的挑戰,工作8年,絲毫沒有感覺到枯燥乏味。

8、女生比較適合做軟體測試

很多人都覺得女生做測試比較吃香,事實上身邊做測試的也確實女生比男生要多,一個是因為女生天生比男生細心,二是很多人都覺得因為開發大多是男生,女生做測試跟開發溝通會更順暢,這其實是一些客觀的實際因素,但是並不代表男生不適合做測試。經過統計,各大公司的測試負責人男生比女生要更多。

9、白盒測試是開發人員乾的事:

一個合格的測試人員必須掌握白盒測試,理解其中的原理。不管什麼樣的測試,都必須要有測試人員的思維才能做好,白盒測試有著其測試理論與技術,完全可以有專職的白盒測試人員進行,避免開發人員自己測試自己的程式。

10、測試就是給開發擦屁股的

大家應該都清楚,在實際的工作中通常是測試驅動開發的,也就是說是測試在主導著專案的進展,開發人員的技術水平直接體現在bug的數量上,開發的能力測試一清二楚,也是測試人員在驅動著開發人員做出改變。如果測試不能驅動開發,被開發牽著鼻子走,只有一個原因,就是測試人員能力弱,無法勝任這個角色。

11、我不適合做開發,做測試吧

這個觀點特別適應於應屆畢業生,在以前面試的過程中,有些人就覺得我程式碼寫的不好,所以入行轉做測試的工作,還有一部分人稍微明白一點開發,但是覺得自己在開發方面沒什麼優勢,主動給自己定位做測試工作。其實測試要掌握的技能遠比開發多得多,至少面要廣得多,要做一個好的測試人員,遠比做一個開發人員難得多。

12、機器自動化將會代替手工測試

現在很多人都在傳自動化測試將會替代手工測試,首先有這種想法的人,一定還沒有真正瞭解自動化測試,自動化是為了做迴歸測試的,自動化指令碼是人工編寫或錄製完成的,只能覆蓋大體的業務流程,並不能對軟體進行詳細的測試覆蓋,詳細的測試還是需要手工完成的,不然自動化指令碼維護的時間成本將會大大增加,適得其反。而且新功能是必須進行手工測試的,只有老功能才可以進行自動化測試。自動化是為了提高測試效率而存在的測試手段,而不是為了替代手工測試而出現的。

13、使用了測試工具,就是進行了有效的測試

測試工具是為了協助測試工程師更高效的完成測試工作,是否能夠有效測試,完全取決於使用工具的人的技術水平。水平強,則測試結果有參考價值,水平弱,則測試結果一塌糊塗。

建議大家還是要以手工測試為基礎,工具只是為了提高測試效率,為了更好的完成測試工作,並不是用工具測試就一定有效。

14、規範化軟體測試是增加專案成本

一個軟體測試過程如果不規範的話,結果一定不會很理想,規範嚴謹的測試過程,可以大大提高測試質量,這不是增加專案成本,而是減少了專案的隱患,甚至是上線後的損失。

一家不重視測試規範的公司,其產出的軟體一定不會有太大的市場競爭力。其後果,也不應該由測試人員承擔。
15、期望短期通過增加軟體測試投入,迅速達到零bug率

測試人員都應該知道一個原則,就是完全測試是不可能的,所謂的零BUG,就連阿里巴巴也做不到,並且軟體測試是貫穿整個專案生命週期的,需要儘早的介入測試,如果在專案後期加大測試力度,也並不能有效的提高測試質量。因為測試人員沒有時間理解軟體的業務流程和介面邏輯。

16、忽視需求階段的參與

軟體測試的開展一定是從需求階段展開的。沒有需求文件就無法衡量測試周期和測試範圍,也就無法編寫測試計劃和測試用例,所以忽視需求階段的參與,對於專案質量來說是災難性的結果。

17、忽視使用者操作密集和核心功能的迴歸測試

很多人認為使用者經常操作的地方就不會出現問題,但是一個專案更新後,很可能導致以前的核心功能受到了影響,新的程式碼對老的業務造成了破壞,所以說,迴歸測試一定不能忽視核心功能以及使用者密集操作的模組。相反,應該重點回歸!

18、忽視軟體測試建檔

軟體測試建檔,指的是軟體的測試記錄是否有效的儲存,是否可查詢,如果測試不建檔,那麼測試報告就無從考察,測試結果也有沒有了依據,所以測試建檔是必要環節,不可忽略。

19、軟體開發完成之後進行軟體測試

軟體測試是貫穿整個專案生命週期的,必須要在需求階段的時候介入,在單元測試完成後就進行整合測試也就是介面測試,這可以發現80%的軟體缺陷。如果開發完成才介入測試,那麼專案釋出上線的時間即將會大大延長。而且很多問題修復成本也將會大大增加。

20、軟體釋出如果發現質量問題,都是測試人員的錯

很多人都覺得測試通過後,在使用者使用時發現bug一定是測試人員沒有測試到位而導致的,我曾經的工作中就經歷過多次這類問題,但是測試人員堅持認為該功能缺失測試過,並且沒有出現這類問題。後來經過本人的辯論終於找到了問題的原因,就是開發人員的疏忽導致封包封版時,沒有儲存最新程式碼導致問題出現。

首先,如果大家以後遇到這樣的情況出現,千萬不要心急如焚,手忙腳亂。要先確定該功能是否測試過,是否通過測試了。如果沒有測試,那麼毫無疑問測試背鍋,如果測試通過還出現了問題,極有可能是開發人員封版時沒有儲存最新的程式碼而導致的。或者是開發人員在釋出最終版本時擅自修改了部分程式碼。

21、專案進度緊的時候少做些測試,時間富裕時多做測試

專案測試時間緊張的時候很容易出現測試不到位,測試不全面,導致釋出後出現問題的情況,正常的處理辦法,應該是使用敏捷測試方法,測試範圍堅決不能縮水,測試用例可以忽略掉表單值域的用例,著重編寫流程性測試用例。並且開發完成了一個模組,測試就測試一個模組,這樣可以大大加快測試效率。本人很喜歡使用敏捷測試的方法,不僅可以減少測試時間,質量也不會打折扣。記住一點,敏捷測試一定要對人員進行明確的分工。避免重複性測試帶來的效率降低。

22、軟體測試工作沒有前途,只有程式設計師才是軟體高手

相信很多人都認為測試沒有開發人員厲害,這確實是市場現狀,很多測試技術確實不如開發強,但是論前途,我覺得測試比開發更有挖掘潛力,測試的發展是多樣化的,而且範圍很廣,薪資也完全不亞於開發人員。真正的全棧測試工程師,技術也絕不會輸給開發,甚至超越開發。小編在工作中,也經常會遇到開發人員前來向我請教效能技術和自動化技術。

23、軟體測試就是保證軟體無故障執行

軟體測試不僅要保證軟體無故障執行,更要保障軟體的易用性,健壯性,穩定性,安全性,相容性,使用者體驗等一系列的因素,所以單純為了無故障則顯得有些膚淺了。

24、軟體測試的環境就選使用者的環境

軟體測試分為三個環境,分別是“測試環境”、“HA環境”(準線上環境)、“線上環境”,使用者環境指的是第三個“線上環境”,而測試的重點用該是在“測試環境”和“HA環境”中。使用者環境中並不能隨意提交資料進行測試,只能在最後beta驗收階段時才會採用這個環境的測試。

25、開發人員更適合做軟體測試

我們常常聽到這樣的問題:“為什麼軟體的開發者們不適合測試他們自己開發的軟體?”事實上,軟體開發人員測試自己所開發軟體的行為就如同學生在完成考試試卷後再對自己的成績進行評估。這種做法毫無意義

(1)開發人員對其所寫程式碼有主觀認同感

人們通常會對自己所犯錯誤視而不見或者拒絕承認。同樣的,在軟體開發領域,程式設計師們對待其開發的應用程式就像對待自己的孩子一樣,拒絕承認自己的孩子有什麼不好的地方。這就是為什麼軟體開發人員難於發現和改正自己的錯誤。

(2)開發人員對軟體過於樂觀的心態

開發人員進行開發的目標是將軟體所需的功能完美的展現出來。當程式的功能運轉正常的時候他們會自我感覺良好,因為他們的主要目標就是功能二字。而測試人員與他們想的卻不一樣。測試人員通常會從不同的角度切入進軟體內部,打破程式設計師們慣有的思維方式,通過各種不同的測試用例把軟體潛在的不足之處引發出來。

26、bug越多測試越有效

測試Bug的數量並不能說明測試的有效性,反倒能說明開發人員的技術水平。測試bug數量多則改的程式碼就多,改的越多,越可能引發其他問題的出現,甚至到後期bug越來越多。原本沒有問題的模組也開始出現問題。測試的有效性不能以發現bug的數量而決定,更應該根據問題的隱蔽性或嚴重性來決定。

27、關注測試的執行而忽略了測試的設計

執行測試一定是按照提前設計好的方法進行的,測試的方法就是測試用例,如果不進行測試用例的設計,直接進行測試執行階段,再強大的測試工程師也無法保證測試的全面性。相信大家都知道編寫測試用例的原則,是100%的覆蓋需求,可見測試設計階段的重要性。

28、測試是為了證明軟體的正確性

測試不僅要證明軟體的正確性,更應該證明軟體是錯的,測試人員不能只考慮正確的流程,往往出錯最多的是逆向思維測試,反邏輯測試,違背常規的測試是最有效的測試,所以說測試不是為了證明軟體的正確性,而是恰恰相反的證明軟體的錯誤性。

在這裡插入圖片描述

覺得有用的話,文章和圖片都可以馬起來留著以後用!上傳圖片不清晰的話,可以在評論區中留言,我將原圖傳給你

評論獲取更多測試資料哦