軟件測試最容易陷入的28個誤區

最近跟一些剛剛進入軟件測試行業的朋友去交流，發現了一個有趣的現象，就是對於這個行業的不少問題的認識都是一致的片面，固然也能夠理解爲誤區。本身利用一點時間，把他們對於這個行業的認識誤區都羅列出來，而後結合本身這麼多年的工做經驗和你們一同交流一下，畢竟本身也是從這個階段走過來的，後來者能少走些彎路是最好的。本身整理了軟件測試人員最容易陷入的28個誤區，文章後面附帶思惟導圖。

 

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

雖然測試與開發的工做性質是對立的，可是目的都是爲了項目更好的發展。

我之前發起過一個倡議：咱們討論的時候不要用他們(開發人員)和咱們(測試人員)，而是統一用我們，由於開發人員和測試人員原本就是一塊兒的。若是測試人員能與開發人員成爲朋友，你會發現，工做會很是順心，在我所在的企業中，測試人員和開發人員關係很是融洽，互相尊重，對你們的工做能力和技術表示確定。

其中的訣竅重點在於測試這邊的溝通，誰也接受不了別人指責本身得意之做，因此測試要以幫助開發讓開發的‘孩子’更健康，讓開發‘帶孩子’別那麼辛苦；

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

 

二、測試人員不須要了解軟件開發知識

測試人員跟開發人員交流不順暢，主要是有如下幾個緣由：

（1）測試人員若是看不懂開發代碼，會致使BUG描述不清晰，不許確，開發人員不明白BUG應該怎麼重現，或者你想說的是什麼，甚至是一些很膚淺的bug，卻被測試人員認爲是很是嚴重的問題。

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

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

因此，測試人員對開發知識的瞭解是必須的。

（4）若是不瞭解開發知識，測試人員很容易被開發人員牽着鼻子走，對於一些BUG的PK，常常是理屈詞窮，由於開發人員隨便一忽悠，你若是不瞭解箇中奧妙，你一個字也說不上來。

（5）自動化測試和性能測試包括項目管理，都會要求對軟件開發有深刻的理解，如何能設計一個好的自動化框架，好的性能測試用例，如何管理一個開發團隊，這都須要咱們在軟件開發方面有所掌握。

因此，測試瞭解軟件開發知識是必須的。

 

三、軟件測試很簡單

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

 

四、測試就是爲了找到bug

測試人員不只須要找到bug，還要跟蹤bug直至問題得以被修復，對缺陷進行確認測試並關閉缺陷，測試員還須要分析問題緣由，避免所以問題影響到其餘功能。

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

 

五、自動化測試太難

不少初學者都認爲自動化測試相比性能和功能都要難不少，實際上每一個測試方向作精通都不容易，自動化只是測試其中的一部分，功能測試作到極致也不容易，性能測試作到精通也一樣須要各類技術手段，自動化無非就是須要懂一些代碼，難點不在技術，而是思路和實施操做，實際上只要付出一樣多的努力，不管是性能仍是自動化，均可以作的很好。

 

六、手工測試沒有挑戰性

手工測試是測試的基本功，也是每個測試必經之路，可是真正作好的人沒有幾個，不少人認爲手工測試就是點點點，我認爲這個說法就是對測試的污衊，手工測試的範圍很大，包含涉及的內容也很是多，例如數據準確性，表單值域，邏輯分析，業務梳理，交互易用性，逆向思惟，UI兼容性，cookie等...單單說業務邏輯和業務流程測試，就有多少人測試不全面，分析不到位而致使發佈上線後出現嚴重問題。

 

七、軟件測試工做重複又枯燥

軟件測試的範圍很廣，測試的手段和方法也是不同的，並且每一個人測試一個項目的思路也不一樣，實際上認爲重複性工做的人，每每是技術差的人，由於他始終沒有任何成長。

真正作好測試的人對待每個項目均可以使用不同的測試方法，接口測試結束就測功能，功能測完了就作作自動化，上線以前作作性能測試，測試工具也能夠隨意更換，對於我來講，每個新項目的開始，都是一次新的挑戰，工做8年，絲毫沒有感受到枯燥乏味。

 

八、女生比較適合作軟件測試

不少人都以爲女生作測試比較吃香，事實上身邊作測試的也確實女生比男生要多，一個是由於女生天生比男生細心，二是不少人都以爲由於開發大可能是男生，女生作測試跟開發溝通會更順暢，這實際上是一些客觀的實際因素，可是並不表明男生不適合作測試。通過統計，各大公司的測試負責人男生比女生要更多。

 

九、白盒測試是開發人員乾的事：

一個合格的測試人員必須掌握白盒測試，理解其中的原理。無論什麼樣的測試，都必需要有測試人員的思惟才能作好，白盒測試有着其測試理論與技術，徹底能夠有專職的白盒測試人員進行，避免開發人員本身測試本身的程序。

 

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

你們應該都清楚，在實際的工做中一般是測試驅動開發的，也就是說是測試在主導着項目的進展，開發人員的技術水平直接體如今bug的數量上，開發的能力測試一清二楚，也是測試人員在驅動着開發人員作出改變。若是測試不能驅動開發，被開發牽着鼻子走，只有一個緣由，就是測試人員能力弱，沒法勝任這個角色。

 

十一、我不適合作開發，作測試吧

這個觀點特別適應於應屆畢業生，在之前面試的過程當中，有些人就以爲我代碼寫的很差，因此入行轉作測試的工做，還有一部分人稍微明白一點開發，可是以爲本身在開發方面沒什麼優點，主動給本身定位作測試工做。其實測試要掌握的技能遠比開發多得多，至少面要廣得多，要作一個好的測試人員，遠比作一個開發人員可貴多。

 

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

如今不少人都在傳自動化測試將會替代手工測試，首先有這種想法的人，必定尚未真正瞭解自動化測試，自動化是爲了作迴歸測試的，自動化腳本是人工編寫或錄製完成的，只能覆蓋大致的業務流程，並不能對軟件進行詳細的測試覆蓋，詳細的測試仍是須要手工完成的，否則自動化腳本維護的時間成本將會大大增長，拔苗助長。並且新功能是必須進行手工測試的，只有老功能才能夠進行自動化測試。自動化是爲了提升測試效率而存在的測試手段，而不是爲了替代手工測試而出現的。

 

1三、使用了測試工具，就是進行了有效的測試

測試工具是爲了協助測試工程師更高效的完成測試工做，是否可以有效測試，徹底取決於使用工具的人的技術水平。水平強，則測試結果有參考價值，水平弱，則測試結果一塌糊塗。

建議你們仍是要以手工測試爲基礎，工具只是爲了提升測試效率，爲了更好的完成測試工做，並非用工具測試就必定有效。

 

1四、規範化軟件測試是增長項目成本

一個軟件測試過程若是不規範的話，結果必定不會很理想，規範嚴謹的測試過程，能夠大大提升測試質量，這不是增長項目成本，而是減小了項目的隱患，甚至是上線後的損失。

一家不重視測試規範的公司，其產出的軟件必定不會有太大的市場競爭力。其後果，也不該該由測試人員承擔。

 

1五、指望短時間經過增長軟件測試投入，迅速達到零bug率

測試人員都應該知道一個原則，就是徹底測試是不可能的，所謂的零BUG，就連阿里巴巴也作不到，而且軟件測試是貫穿整個項目生命週期的，須要儘早的介入測試，若是在項目後期加大測試力度，也並不能有效的提升測試質量。由於測試人員沒有時間理解軟件的業務流程和接口邏輯。

 

1六、忽視需求階段的參與

軟件測試的開展必定是從需求階段展開的。沒有需求文檔就沒法衡量測試周期和測試範圍，也就沒法編寫測試計劃和測試用例，因此忽視需求階段的參與，對於項目質量來講是災難性的結果。

 

1七、忽視用戶操做密集和核心功能的迴歸測試

不少人認爲用戶常常操做的地方就不會出現問題，可是一個項目更新後，極可能致使之前的核心功能受到了影響，新的代碼對老的業務形成了破壞，因此說，迴歸測試必定不能忽視核心功能以及用戶密集操做的模塊。相反，應該重點回歸！

 

1八、忽視軟件測試建檔

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

 

1九、軟件開發完成以後進行軟件測試

軟件測試是貫穿整個項目生命週期的，必需要在需求階段的時候介入，在單元測試完成後就進行集成測試也就是接口測試，這能夠發現80%的軟件缺陷。若是開發完成才介入測試，那麼項目發佈上線的時間即將會大大延長。並且不少問題修復成本也將會大大增長。

 

20、軟件發佈若是發現質量問題，都是測試人員的錯

不少人都以爲測試經過後，在用戶使用時發現bug必定是測試人員沒有測試到位而致使的，我曾經的工做中就經歷過屢次這類問題，可是測試人員堅持認爲該功能缺失測試過，而且沒有出現這類問題。後來通過本人的辯論終於找到了問題的緣由，就是開發人員的疏忽致使封包封版時，沒有保存最新代碼致使問題出現。

首先，若是你們之後遇到這樣的狀況出現，千萬不要心急如焚，手忙腳亂。要先肯定該功能是否測試過，是否經過測試了。若是沒有測試，那麼毫無疑問測試背鍋，若是測試經過還出現了問題，極有多是開發人員封版時沒有保存最新的代碼而致使的。或者是開發人員在發佈最終版本時擅自修改了部分代碼。

 

2一、項目進度緊的時候少作些測試，時間富裕時多作測試

項目測試時間緊張的時候很容易出現測試不到位，測試不全面，致使發佈後出現問題的狀況，正常的處理辦法，應該是使用敏捷測試方法，測試範圍堅定不能縮水，測試用例能夠忽略掉表單值域的用例，着重編寫流程性測試用例。而且開發完成了一個模塊，測試就測試一個模塊，這樣能夠大大加快測試效率。本人很喜歡使用敏捷測試的方法，不只能夠減小測試時間，質量也不會打折扣。記住一點，敏捷測試必定要對人員進行明確的分工。避免重複性測試帶來的效率下降。

 

2二、軟件測試工做沒有前途，只有程序員纔是軟件高手

相信不少人都認爲測試沒有開發人員厲害，這確實是市場現狀，不少測試技術確實不如開發強，可是論前途，我以爲測試比開發更有挖掘潛力，測試的發展是多樣化的，並且範圍很廣，薪資也徹底不亞於開發人員。真正的全棧測試工程師，技術也毫不會輸給開發，甚至超越開發。小編在工做中，也常常會遇到開發人員前來向我請教性能技術和自動化技術。

 

2三、軟件測試就是保證軟件無端障運行

軟件測試不只要保證軟件無端障運行，更要保障軟件的易用性，健壯性，穩定性，安全性，兼容性，用戶體驗等一系列的因素，因此單純爲了無端障則顯得有些膚淺了。

 

2四、軟件測試的環境就選用戶的環境

軟件測試分爲三個環境，分別是「測試環境」、「HA環境」（準線上環境）、「線上環境」，用戶環境指的是第三個「線上環境」，而測試的重點用該是在「測試環境」和「HA環境」中。用戶環境中並不能隨意提交數據進行測試，只能在最後beta驗收階段時纔會採用這個環境的測試。

 

2五、開發人員更適合作軟件測試

咱們經常聽到這樣的問題：「爲何軟件的開發者們不適合測試他們本身開發的軟件？」事實上，軟件開發人員測試本身所開發軟件的行爲就如同窗生在完成考試試卷後再對本身的成績進行評估。這種作法毫無心義

（1）開發人員對其所寫代碼有主觀認同感

人們一般會對本身所犯錯誤視而不見或者拒絕認可。一樣的，在軟件開發領域，程序員們對待其開發的應用程序就像對待本身的孩子同樣，拒絕認可本身的孩子有什麼很差的地方。這就是爲何軟件開發人員難於發現和改正本身的錯誤。

（2）開發人員對軟件過於樂觀的心態

開發人員進行開發的目標是將軟件所需的功能完美的展示出來。當程序的功能運轉正常的時候他們會自我感受良好，由於他們的主要目標就是功能二字。而測試人員與他們想的卻不同。測試人員一般會從不一樣的角度切入進軟件內部，打破程序員們慣有的思惟方式，經過各類不一樣的測試用例把軟件潛在的不足之處引起出來。

 

2六、bug越多測試越有效

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

 

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

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

 

2八、測試是爲了證實軟件的正確性

測試不只要證實軟件的正確性，更應該證實軟件是錯的，測試人員不能只考慮正確的流程，每每出錯最多的是逆向思惟測試，反邏輯測試，違背常規的測試是最有效的測試，因此說測試不是爲了證實軟件的正確性，而是偏偏相反的證實軟件的錯誤性。

軟件測試學習路線圖:

 

測試學習交流羣：708228666