在IT行業，特別是那些并不真正從事軟件測試行業的業者，對軟件測試往往有一些常見的誤解，對測試行業的發展和健康都有不利的影響。本文總結了10大常見誤解，希望能起到一些正本清源的作用。 



一、測試工程師的工作是破壞軟件

“測試工程師的工作就是破壞軟件”是一個常見的誤解。作為程序員十大金句之首的“在我機器上是好的”往往來源于這一誤解。測試人員好像有什么魔力，能夠把正確運行的程序在測試環境上搞得不能工作。

但是這不是測試工程師破壞了軟件，測試工程師并不能在軟件中創造某些bug。他們只是做了些程序員沒有考慮到的某些操作，比如在測試環境上，沒有執行相關的依賴操作。程序員在自測時很多情況下會默認某些場景，或者是開發的新功能而沒有考慮到對原有功能的影響。這也是為什么我們不推薦完全由開發者本人完成功能的測試。

真相

軟件bug只會來源于產生它們的代碼，測試工程師不實現代碼，所以他們并不能破壞軟件，他們只是發現了軟件不工作的觸發條件并且報告了出來。

“測試工程師對軟件進行破壞”往往會導致團隊開發和測試的對立情緒，甚至將軟件沒有滿足客戶要求和大量因解決問題的額外工作量歸咎于測試工程師的勞動。這是非常不利于團隊和產品成功的。

二、測試工作不需要什么專業技能

很多人認為軟件測試是個簡單的工作，不需要會編寫程序，也不需要很深厚的專業技術能力。這也是一個很常見的誤解。誠然，很多優秀的測試工程師都不會編寫專業的程序，也不具備軟件開發領域的一些專業技能如架構、抽象等。但是這并不是說測試就是一個簡單的工作。JamesBach在《測試與檢查》一文中對測試和檢查的區別進行了詳細的闡述。測試是一系列創造性活動的集合，包括提問、研究、建模、觀察、推理、試驗等多方面的技巧。

開發和測試是兩個不同的技術領域，我們不能以同樣的技術標準來衡量兩種不同的工作 。

真相

測試工作不同于開發工作，兩者會有一些技能重疊，但是也存在很大的區別。開發工作的重點是高效、高質量地實現功能，而測試工作的重點是盡可能多地將軟件失效在交付用戶前暴露出來。測試工程師擅長開發技能可以幫助測試工程師更加深入地理解軟件或幫助自己提供輔助手段來測試軟件，但是這不能作為測試工作是否專業的評判標準。

三、測試就是寫測試用例，然后執行

測試就是把需求轉換成測試用例，然后在軟件中執行這些用例。這是一個在瀑布研發模式時代非常廣泛的一個錯誤看法，然而在如今敏捷研發模式時代，也換了個模樣，但是依然存在類似的認知。

在瀑布研發模式下，很多測試工作被嚴格地要求有非常完備的測試設計文檔，然后依照這些文檔進行覆蓋式地執行驗證?？赡芨呒墱y試工程師負責編寫，然后初級工程師來執行。這更多是工廠式的質量管理經驗在軟件行業的錯誤應用。

即使在敏捷研發模式得到大量應用的今天，我們還是可以看到類似認知的變種，比如測試由開發人員做好單元測試的充分覆蓋就可以了。這其實依然是把測試工作文檔化，只是這個文檔變成了單元測試代碼，執行變成了計算機。本質依然是測試=測試設計+執行 。

真相

輸出測試設計文檔，并不是真的那么重要。測試中，更重要的永遠是那些創造性的東西。提問、研究、建模、觀察、推理、試驗等。文檔是這些活動的一個輸出形式，我們不應該把測試簡單看作是這些文檔的機械生成和執行 。

四、產品出現問題，說明沒有很好地進行測試

軟件發布后，如果出現問題，很多人會首先歸咎于測試的失職。認為測試沒有做好份內的工作。軟件測試的七大原則中，重要的一條就是窮盡測試是不可能的，何況測試并沒有直接編寫產生bug的代碼。所以產品出現bug，是整個研發過程中整體流程的作用后果，不能也不應該據此作為評判測試工作好壞的標準。

真相

任何軟件都不可能被詳盡地完全測試。測試工作和開發工作、需求分析工作密不可分，產品的總體質量是整個研發團隊共同作用的結果。軟件發布后的bug產生是評估產品研發整體質量的一個重要標準，但僅以此來評判測試工作好壞有失偏頗。

五、通過測試可以發現所有的bug

這個誤解和上一條原因比較類似，都是因為認為測試應該保證產品發布的質量并提前發現所有未知的問題。這是不可能辦到的。產品是否能有效工作和很多因素有關。不同的測試環境、測試場景，不同用戶操作使用軟件的操作習慣、使用路徑都有可能引起軟件不同的表現。測試人員會盡量站在用戶角度來考慮軟件的使用場景，但是他并不能預測所有的用戶行為，也不可能提前預知所有的運行環境和場景。所以在測試工作中，限定測試范圍并告知用戶經過驗證的場景是相對嚴謹的做法。

真相

測試人員不可能估計到所有的可能性，也不可能預測到所有的用戶行為。而軟件會因為不同的用戶行為和不同的運行場景產生超出預期的問題或bug。所以不可能要求測試人員提前發現所有的潛在bug。一個優秀的團隊，會盡可能多地考慮到不同的用戶場景，并根據發布目標調整覆蓋場景的優先級。簡單要求所有bug都能提前檢測是不可能辦到的任務。

六、自動化測試可以代替測試

這個誤解在現如今幾乎已經成為信條了。確實，理論上，所有的測試用例都可以通過技術手段來實現并自動執行，但是正如我們在前面提過的，測試并不是測試用例+測試執行的疊加。測試還包括大量的創造性的活動。所以自動化測試代替測試是個偽命題(除非有朝一日，人工智能發展到能夠打敗人類的創造性。那時可能整個IT行業都不需要人力勞動了)

除此之外，即使自動化測試能把所有的測試用例都實現通過機器執行，也不意味著應該這么做。因為自動化測試本身也是一項投資，有大量的投入在其中。很多測試場景通過自動化測試可以產生很大的價值，比如大量重復性的驗證。但是也有很多場景，不需要通過自動化的投入來實現，比如很多一次性的功能驗證，還有依賴人進行主觀判斷的功能等。

真相

測試中的檢查工作，很大一部分可以通過自動化測試代替，但是測試工作不會被自動化測試代替。即使可以實現自動化測試的場景，我們也要通過ROI的衡量(如測試金字塔)來確定實施自動化測試的必要性 。

七、測試應放在開發環境后期進行

傳統的瀑布研發模式中，在研發后期會有專門的測試階段，包括集成測試、系統測試、驗收測試等。所以長期形成一個誤解，測試是在開發階段后發生的。

可是這是一個錯誤的認識，這依然是傳統工廠流水線思想的產物，并不適用于軟件研發。即使在瀑布研發模式下，前期的開發階段和需求設計階段也都明確了測試人員參與的必要性。在現代敏捷研發模式下，更加強調測試工作的遷移，測試在需求澄清、系統設計、代碼走查、結對編程等等階段都扮演著重要的角色。

真相

測試是貫穿在研發生命周期全流程的一項活動，并不是某一個割裂開的獨立階段。測試越早介入對產品最終質量就更能產生積極的效果。

八、任何人都可以做好測試

這句話就好像《21天精通X語言》，《你也能做CEO》，《XXX三天速成》等故事一樣，任何事情，懂得些雞毛蒜皮都很容易，并不一定是測試，任何行當其實都是這樣。10000小時定律對任何行業都適用。

真相

做一個好的測試工程師，一定是需要專業的技能訓練以及經驗積累。測試是一個廣泛的范疇，各種各樣不同的測試概念以及對應的測試方法、測試工具都需要大量的實踐和學習才能在需要的時候應對自如。

九、測試工程師是質量守門員

這個誤解幾乎在所有IT企業都存在。測試工程師被當做質量守門員(背鍋俠)，測試人員需要為所測試的軟件質量背書。測試人員被當做產品質量的最后一道防線，測試結果似乎決定了軟件產品最終的交付質量。

真相

實際情況下，測試無法決定產品質量，只能將產品中當前發現的問題暴露出來，并據此進行質量評估。而且無論是因為研發周期還是問題修復成本等問題，測試人員并不能左右產品是否能夠交付給用戶。測試人員針對測試過程的總結和報告，更多是體現當前測試場景和測試范圍下，軟件產品的質量評估情況，測試工程師其實無法充當守門員角色。

十、測試即QA(質量保證)

在很多企業，往往會混淆QA和Testing兩種角色，認為Testing就是QA(QualityAssurence)。應該說兩者有相關性，或者說QA>testing。

前面說過，質量不會由測試來決定，質量更多是從需求、設計、開發環節就確定的。所以QA工作除了包含測試外，更主要的是流程改進，通過流程關鍵節點的管控來保證質量水準。

真相

QA涵蓋的范圍比測試更大，二者側重點也不同。QA更關注軟件研發全流程的質量管控，測試則更關注將當前軟件中的缺陷暴露出來。二者的關注點不同，所需要的技能也不相同。不能簡單地把測試和QA工作劃等號。

總結

測試是一門涵蓋范圍廣泛的專業，但是業界對測試工作卻普遍存在或多或少的誤解。