【分享】10大常見軟件測試誤解！

最近，看到一篇名為《對軟件測試的十大誤解》的文章，個人認為這篇文章對軟件測試總結(jié)的很到位想分享給更多真正從事軟件測試行業(yè)的業(yè)者。但由于多人發(fā)布，找不到文章來源。因此小編聲明，本文解釋權(quán)歸原作者所有哦，不代表北大青鳥觀點，要是您認為小編侵權(quán)，請?zhí)峁┠牡刂?，然后我就刪除呦。

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

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

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

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

真相

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

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

二、測試工作不需要什么專業(yè)技能

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

開發(fā)和測試是兩個不同的技術(shù)領(lǐng)域，我們不能以同樣的技術(shù)標準來衡量兩種不同的工作 。

真相

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

三、測試就是寫測試用例，然后執(zhí)行

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

在瀑布研發(fā)模式下，很多測試工作被嚴格地要求有非常完備的測試設(shè)計文檔，然后依照這些文檔進行覆蓋式地執(zhí)行驗證。可能高級測試工程師負責編寫，然后初級工程師來執(zhí)行。這更多是工廠式的質(zhì)量管理經(jīng)驗在軟件行業(yè)的錯誤應(yīng)用。

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

真相

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

四、產(chǎn)品出現(xiàn)問題，說明沒有很好地進行測試

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

真相

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

五、通過測試可以發(fā)現(xiàn)所有的bug

這個誤解和上一條原因比較類似，都是因為認為測試應(yīng)該保證產(chǎn)品發(fā)布的質(zhì)量并提前發(fā)現(xiàn)所有未知的問題。這是不可能辦到的。產(chǎn)品是否能有效工作和很多因素有關(guān)。不同的測試環(huán)境、測試場景，不同用戶操作使用軟件的操作習慣、使用路徑都有可能引起軟件不同的表現(xiàn)。測試人員會盡量站在用戶角度來考慮軟件的使用場景，但是他并不能預測所有的用戶行為，也不可能提前預知所有的運行環(huán)境和場景。所以在測試工作中，限定測試范圍并告知用戶經(jīng)過驗證的場景是相對嚴謹?shù)淖龇ā?/span>

真相

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

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

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

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

真相

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

七、測試應(yīng)放在開發(fā)環(huán)境后期進行

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

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

真相

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

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

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

真相

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

九、測試工程師是質(zhì)量守門員

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

真相

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

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

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

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

真相

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

總結(jié)

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

版權(quán)說明：文章來源網(wǎng)絡(luò)，著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。