一.前言：
“最佔時間的是測試階段。”你曾經聽到過這樣的說法嗎?這是大多數非測試人員在從事項目工作時的表現，他們不瞭解軟件測試有多強大。
軟件測試是一門藝術，不是每個軟件專家都能精通，然而很多人都低估了它。本文就將澄清技術界盛行的關於軟件測試的誤解。今天我們來盤點軟件測試的誤解，至今爲止，可能很多人都軟件測試的認識都停留在表面，今天基於我的經驗，一菲給大家總結了軟件測試的幾個常見誤解，解開這些誤解，你會發現新的世界！
二.正文：
1.做測試簡單、輕鬆，點點點就行了，是個人都能做？
作爲一名軟件測試工程師，我在和很多開發的同事聊天的時候，他們很多人都持有這樣的想法。雖然我不知道爲什麼會產生這樣的想法，但是我想說的是，測試並不是像他們說的那樣簡單輕鬆，只是點點點。
當然不排除有些公司對測試不夠重視，所以就可能會只要求測試在UI層上，只要驗證UI層沒有問題就行了。但這樣的測試流程，根本就不可能控制好軟件的質量。
所以這才導致了在國內的測試行業裏，開發對測試產生的誤解。
2.測試人員不需要代碼能力？
這個問題不是絕對的，具體還要看測試的工作。有些工作可能只是看看視頻的畫質和流暢度，看上去確實不需要什麼代碼能力。
但是考慮到自動化測試，測試工具都是需要用代碼堆起來的。即便是有現成的測試工具，積累測試用例也是需要一定的代碼能力。當然，如果測試人員本身對硬件代碼有更深的理解，絕對會體現在測試質量上，對你未來的成長也有很大幫助。
3.產品出現問題，說明沒有很好地進行測試？
其實有很多不太懂測試的人就會產生一種誤解，認爲要測試的幹嘛呢？既然我們花了錢用你，就應該保證我們的產品沒有缺陷啊！
對於這種想法，我只能說不太理智，測試並沒有直接編寫產生bug的代碼。所以產品出現bug，是整個研發過程中整體流程的作用後果，而不應該據此作爲評判測試工作好壞的標準。測試只是提高產品質量，而並非保證產品質量。
在這裏插入圖片描述
4.測試應該在開發環境後期進行？
在傳統研發模式中，研發後期會有專門的測試階段，包括集成測試、系統測試、驗收測試等。
所以大家可能會形成一個誤解，認爲測試是在開發階段後期進行的。但其實不然，在現代研發模式下，更加強調測試工作的遷移。
實則測試是貫穿在研發生命週期全流程的一項活動，並不是某一個獨立階段。測試越早介入對產品最終質量就更能產生好的效果。
5.測試是枯燥乏味，缺乏創造力的工作？
一個好的測試是需要經過計劃，設計到執行。爲了設計好的測試用例，你需要充分發揮你的想象力。對於一個缺乏想象力的測試人員來說，你可以勝任測試執行的工作，但是卻無法設計出高質量的測試用例。其實無論是從事開發還是測試，都應當從工作中去尋找樂趣，不斷地改進和完善自己。
6.測試即QA(質量保證)
在很多企業，往往會混淆QA和Testing兩種角色，認爲Testing就是QA（Quality Assurence）。應該說兩者有相關性，或者說QA > testing。 前面說過，質量不會由測試來決定，質量更多是從需求、設計、開發環節就確定的。所以QA工作除了包含測試外，更主要的是流程改進，通過流程關鍵節點的管控來保證質量水準。
QA涵蓋的範圍比測試更大，二者側重點也不同。QA更關注軟件研發全流程的質量管控，測試則更關注將當前軟件中的缺陷暴露出來。二者的關注點不同，所需要的技能也不相同。不能簡單地把測試和QA工作劃等號。
7.測試人員不會成爲項目經理。
許多人認爲，測試人員缺乏管理方面的專業培養。但這兩者本就是互不干涉的。經理需要掌握人員管理、成本管理、時間管理等技能。無論是測試人員、開發人員，還是其他任何技術人員，這些技能都與他們的工作無關。
項目管理技能需要單獨培養，並且世界上無論從事哪種技術，屬於哪個流派的人員都可以進行培養。因此，作爲一名測試人員，對項目管理的追求並不會受到鼓勵或阻止。大家還記得那句話嗎，只要你想努力，全世界都會爲你讓路，不怕！在這裏插入圖片描述
8.向開發主管進行工作彙報是測試人員職業生涯的阻礙。”
理想情況下應有獨立的垂直部門，開發主管和QA主管都應向項目經理進行工作彙報。然而有時候可能會出現測試團隊和開發團隊有同一個開發主管的情況，這時候就必須向一個並不懂得如何進行深入測試的人彙報工作。
但其實，只要把工作做好，並耐心地幫助領導完成評估實踐，就不會有什麼差錯，也不會對職業生涯產生長期的負面影響。
9.編碼技能差的人才會從事軟件測試。
大多數情況下，測試還包括編碼。測試人員需編寫複雜的結構化查詢語言(SDL)來驗證數據，或者在進行提取轉換加載(ETL)測試/數據驗證時創建測試數據。進行遷移測試時，測試人員需將編寫的代碼從一個數據庫轉換到另一個數據庫。進行自動化測試時，測試人員需用Java、Perl或其他編程語言編寫腳本。
因此，這個觀點根本站不住腳。
10.軟件測試就是隨意點擊。
人們通常認爲，測試就是在用戶界面(UI)隨意點擊，然後在Excel或其他文檔中記錄細節。事實上，測試人員會執行非常明確的測試步驟，以確保UI/應用在極特殊情況下也能夠正常工作。因此，視域纔是最重要的。
用戶對操作限制沒有概念，測試人員也一樣。因此探索用戶界面很重要，這種探索可能看起來像很多隨意的點擊。只有測試人員知道這種瘋狂的操作是有方法步驟的。
11.測試就是文件記錄，或者說填充Excel表格。
首先，需要強調一下：每個參與項目的人都必須進行文件記錄。一份準確和完整的文件可以爲項目提供基本證明和歷史證明。
然而，對於測試人員來說，文件記錄尤爲重要，因爲我們創造的產物不是一個程序或模塊，而是通過人工呈現的一種質量保證。Microsoft Office套件是大多數團隊的首選，但如果要做得更好，就請使用測試管理軟件。
12.做測試員賺不了多少錢。
如果這種說法用在測試人員身上，那就大錯特錯了。這種思想可能需要轉變一下。即便如此，薪酬取決於很多因素，把測試員這一身份作爲薪酬較低的唯一原因是錯誤的。
在這裏插入圖片描述
在這裏推薦一個軟件測試及交流羣，qq:642830685,羣中inghui不定期的分享軟件測試資源，測試面試題以及行業資訊。
13.測試員得不到賞識。
軟件測試有時像是一種“喫力不討好”的工作，這取決於公司文化對團隊的重視程度。試着保持積極的心態，並用工作證明一切。我認同以下說法：如果公司和客戶欣賞QA團隊，事情會好辦很多。但如果他們不欣賞QA團隊，我們也不必低估自己。
歡迎關注微信公衆號：程序媛一菲
1.免費領取一份216頁軟件測試工程師面試寶典文檔資料。
2.軟件測試學習路線以及相對應的視頻學習教程免費分享！
14.測試員拖慢項目交付進度。
不管是否與開發團隊同時開始工作，測試人員都必須等到開發徹底完成後才能開始測試。這就給人一種粗略的印象，即測試一次又一次地拖慢項目進度。
如果在計算機上對測試周期進行預先計劃，就不會出現這個問題。因此，測試不是使項目延遲的原因，不正確的計劃和不合理的預期纔是罪魁禍首。
15.自動化測試人員不必擔心手工測試。
沒有什麼比這種說法更令人難以置信了。
自動化測試也是測試，不同之處在於測試的方式。不要忘了，自動化測試一直延續或遵循着手工測試的流程。不是所有的項目都是自動化項目，同樣地，同時掌握手工測試和自動化測試的測試人員也是很罕見的。
手工測試是測試員需要培養的一項基本技能，它是基礎。自動化測試很厲害，它是質量控制領域最像魔法的東西。但在軟件測試領域中，我們並不願意去評價它們孰優孰劣。
自動化測試人員可以在一些項目中進行手工測試，而手工測試人員也可以在某些情況下進行自動化測試。
16.測試主管不參與測試。
事實上，在行業標準裏，測試主管在協調方面的工作僅爲10%，他們也是QA團隊的一員，需負責協助測試活動。當然，還有其他任務。
因此，QA主管必須把一小部分精力花在測試活動上。要想成爲一名測試員，就必須準備好在以後的職業生涯中完成作爲一名普通QA團隊成員應執行的所有任務，否則是時候考慮換個領域了。
17.測試員質疑一切，在IT行業以‘吹毛求疵’聞名。”
懷疑一切的人的生活是最難的。如果我們真的懷疑一切，我們甚至會質疑軟件的存在、運用和效率，這意味着在相信產品毫無用處的情況下，我們依然在爲它工作。
你覺得這種看法正確嗎?我們真的可以在一個軟件系統上花費大量的時間，而又認爲它毫無用處嗎?與普遍的觀點相反，測試人員相信軟件的性能、效率、生產力和用途，並且幫助它在實際運用中取得成功。
但是，測試人員要確保軟件處於最佳狀態。在測試時要記住，產品是優秀的，我們必須識別並消除任何可能對這個優秀產品產生負面影響的因素。我們真的認可它，是它的忠實粉絲。
18.測試工程師的工作是破壞軟件
“測試工程師的工作就是破壞軟件”是一個常見的誤解。作爲程序員十大金句之首的“在我機器上是好的”往往來源於這一誤解。測試人員好像有什麼魔力，能夠把正確運行的程序在測試環境上搞得不能工作。 但是這不是測試工程師破壞了軟件，測試工程師並不能在軟件中創造某些bug。他們只是做了些程序員沒有考慮到的某些操作，比如在測試環境上，沒有執行相關的依賴操作。程序員在自測時很多情況下會默認某些場景，或者是開發的新功能而沒有考慮到對原有功能的影響。這也是爲什麼我們不推薦完全由開發者本人完成功能的測試。
而軟件bug只會來源於產生它們的代碼，測試工程師不實現代碼，所以他們並不能破壞軟件，他們只是發現了軟件不工作的觸發條件並且報告了出來。 “測試工程師對軟件進行破壞”往往會導致團隊開發和測試的對立情緒，甚至將軟件沒有滿足客戶要求和大量因解決問題的額外工作量歸咎於測試工程師的勞動。這是非常不利於團隊和產品成功的。
19自動化測試可以代替測試
這個誤解在現如今幾乎已經成爲信條了。確實，理論上，所有的測試用例都可以通過技術手段來實現並自動執行，但是正如我們在前面提過的，測試並不是測試用例+測試執行的疊加。測試還包括大量的創造性的活動。所以自動化測試代替測試是個僞命題（除非有朝一日，人工智能發展到能夠打敗人類的創造性。那時可能整個IT行業都不需要人力勞動了） 除此之外，即使自動化測試能把所有的測試用例都實現通過機器執行，也不意味着應該這麼做。因爲自動化測試本身也是一項投資，有大量的投入在其中。很多測試場景通過自動化測試可以產生很大的價值，比如大量重複性地驗證。但是也有很多場景，不需要通過自動化的投入來實現，比如很多一次性的功能驗證，還有依賴人進行主觀判斷的功能等。
測試中的檢查工作，很大一部分可以通過自動化測試代替，但是測試工作不會被自動化測試代替。即使可以實現自動化測試的場景，我們也要通過ROI的衡量（如測試金字塔）來確定實施自動化測試的必要性
20.測試就是寫測試用例，然後執行
測試就是把需求轉換成測試用例，然後在軟件中執行這些用例。這是一個在瀑布研發模式時代非常廣泛的一個錯誤看法，然而在如今敏捷研發模式時代，也換了個模樣，但是依然存在類似的認知。 在瀑布研發模式下，很多測試工作被嚴格地要求有非常完備地測試設計文檔，然後依照這些文檔進行覆蓋式地執行驗證。可能高級測試工程師負責編寫，然後初級工程師來執行。這更多是工廠式的質量管理經驗在軟件行業的錯誤應用。 即使在敏捷研發模式得到大量應用的今天，我們還是可以看到類似認知的變種，比如測試由開發人員做好單元測試的充分覆蓋就可以了。這其實依然是把測試工作文檔化，只是這個文檔變成了單元測試代碼，執行變成了計算機。本質依然是測試=測試設計+執行
輸出測試設計文檔，並不是真的那麼重要。測試中，更重要的永遠是那些創造性的東西。提問、研究、建模、觀察、推理、試驗等。文檔是這些活動的一個輸出形式，我們不應該把測試簡單看作是這些文檔的機械生成和執行
好了，以上就是一菲總結說的關於軟件測試的20個誤解，希望能夠給需要的小夥伴們帶來幫助喔，如果大家有補充的內容歡迎私信我，我們可以做出史上最全軟件測試破謠葵花寶典。