感覺軟件測試的課程難度不大？

如果你并非計算機相關(guān)專業(yè)畢業(yè)，也沒有過測試的相關(guān)經(jīng)歷（例如：去某家公司實習從事測試工作），那還是建議去參加一下培訓。因為測試工作看上去不過就是點點點，但實際上我們進入到測試工作后會發(fā)現(xiàn)，并不是那么簡單。在點點點的背后，還有非常非常多的知識域和方法論，甚至我們做到一定的時候，測試就是一個初中級的程序員了。

在測試工作中，我們常常看到的那些點點點的工作，實際上是黑盒測試的其中一部分。

用比較理論的語言來說，黑盒測試就是運營軟件，對系統(tǒng)的輸入輸出進行測試驗證，但不關(guān)心其中的實現(xiàn)過程。

舉個例子：我現(xiàn)在把一只貓放進黑色的盒子里面，過一會我把黑盒子里面的東西拿出來，發(fā)現(xiàn)是一條狗，剛好我期望的結(jié)果就是把貓變成狗，那么這個結(jié)果滿足我的要求，我也并不關(guān)心黑盒子里面是怎么把貓變成狗的。

而做黑盒測試也并不是我們拿著手機打開APP或者電腦里面打開一個網(wǎng)頁就各種點點點就完了，在這個之前我們還有很多的事情需要做。

第一步：作為一個測試，是需要參加產(chǎn)品的評審的，并且需要在評審的過程中給出自己對于質(zhì)量、功能的要求。當然，對于需求的理解是需要非常透徹的，往往測試是比研發(fā)更懂產(chǎn)品經(jīng)理的人。

第二步：作為一個測試，在拿到了產(chǎn)品設(shè)計和需求分析文檔以后，自然就需要開始做測試計劃和測試用例了。

測試計劃，顧名思義，即使根據(jù)現(xiàn)在的測試需求、項目周期、剩余資源情況來進行工作的安排，并且預(yù)測出需要達到的目標（測試覆蓋率、測試通過率等等）。

測試用例，就是對系統(tǒng)的功能或者流程分析以后，將我準備輸入的內(nèi)容和我預(yù)期的結(jié)果整理出來。這個過程可以說是最為復雜的，我們最終統(tǒng)計測試覆蓋率也是要依賴于用例的完善程度。一個優(yōu)秀的測試用例可以達到什么程度呢？假設(shè)這個用例拿給研發(fā)，研發(fā)可以按照這個測試用例無腦的進行編碼了。

第三步：自然就是執(zhí)行用例了，也就是點點點的過程，我們根據(jù)用例的規(guī)劃，一條一條的執(zhí)行用例。通常情況下，我們在執(zhí)行用例之前，還會進行以下冒煙測試，看看提測的系統(tǒng)是否達到了可以執(zhí)行用例的水平。如果冒煙測試通不過的話，測試小伙伴一般都會想跳起來罵人。

隨便說一下啥是冒煙測試？

還是先來官方一點的解釋，就是我們在正式測試前，對產(chǎn)品或系統(tǒng)的此次迭代影響功能點進行一次簡單的驗證性測試。實際上就是對這次改動的功能頁面挨著點一下，看看會不會報錯。

執(zhí)行用例的過程中，很多時候我們并不是點點點就能夠解決的，我們必須掌握一些基礎(chǔ)工具的使用，例如：Postman或者數(shù)據(jù)庫工具。因為，在一些接口測試的時候，我們要對數(shù)據(jù)進行輸入并不是通過頁面，而是通過接口，那么就需要模擬HTTP或者其他形式的請求，同時，我們要對報文有基本的了解，知道怎么構(gòu)造報文、加密報文。接口數(shù)據(jù)輸入以后，怎么來判斷數(shù)據(jù)的對錯呢？這時候就可能還需要打開數(shù)據(jù)庫，通過SQL腳本把我們的數(shù)據(jù)查出來進行比對。也就是說，測試小伙伴也是需要一定的技術(shù)基礎(chǔ)和技能的。

因此，我們覺得測試工作比較簡單，那是因為我們只是認識到了測試工作中的一部分，還有大部分的內(nèi)容我們并沒有看到。那么，是不是我們做到以上的幾點，就算是一個比較厲害的測試了呢？No，No，No，僅僅是一個合格的測試人員。要知道，上面的內(nèi)容也只是黑盒測試中的一部分而已，如果一個測試想要進階，那么就還需要掌握更厲害的技能，例如黑盒測試的升級能力——自動化測試。

簡單來說，就是通過代碼和工具，自動的對系統(tǒng)進行測試。也就是從人工點點點轉(zhuǎn)變?yōu)閷懘a來點點點。

要想能夠做自動化測試，那么測試小伙伴就一定需要有寫代碼的能力，現(xiàn)在最流行的自動化測試語言就是Python，很多的自動化測試工具都支持寫Python的腳本。當然，也有一些是Java寫的，例如Jmeter，如果你懂Java，甚至可以自己去改造一下它。當測試小伙伴進階到了自動化測試小伙伴時，你就會覺得以前點點點的生活太苦悶了，現(xiàn)在我只要把腳本寫好了，每次迭代以后，我就改改我的腳本，甚至我在準備測試用例的同時就可以準備好我的腳本，到測試時，我簡單調(diào)整一下，然后鼠標一點，測試就完成了（事實上當然不是這樣，自動化測試是有局限性的，最終還是會要點點點，所以自動化測試小伙伴都比較傲嬌，不愿意去點點點）。

當然，如果測試到了這個水平，那么測試和程序員的界限就比較低了，測試和程序員就會有很多相同的技術(shù)棧。OK，我們到這里還僅僅說了黑盒測試，但測試還有一個領(lǐng)域叫做白盒測試。

我們還是用黑盒測試的例子來解釋，我們把一只貓放進一個透明的盒子里，然后我們要看著這個透明盒子是怎么工作的，一步步分析這個工作過程有沒有問題，最后，從盒子里出來一條狗，整個的變化過程和我期望的一致時，就是測試通過。

通常情況下，我們現(xiàn)在的系統(tǒng)很少回去做白盒測試。第一、白盒測試對于測試人員的要求非常高；第二、測試成本很高，大部分系統(tǒng)做不到這種程度；第三、測試人員如果對代碼的邏輯熟悉度低時，測試的效率非常差。因此，我們更多的是在研發(fā)內(nèi)部做code review，很少去做白盒。當然，白盒測試也是一種測試領(lǐng)域，某些時候還是有必要的。

OK，那到這里就是我們測試大致的里程了嗎？并不是的。

對于測試來說，我們還要了解很多測試管理乃至質(zhì)量管理的知識，因此，什么PMP、高級項目經(jīng)理、CMMI、6西格瑪?shù)鹊确矫娴闹R，都是測試未來需要學習的內(nèi)容。如果我們想要再考個證，那不經(jīng)過系統(tǒng)的學習，光靠著工作時候的經(jīng)驗積累，基本是過不了這些考試的。所以，在技術(shù)領(lǐng)域的任何崗位，都是一個不斷學習不斷進步的過程，沒有誰能夠隨隨便便就成功，未來還有很多的培訓、學習過程等著我們。與其把學習放到未來，不如現(xiàn)在就開始，從基礎(chǔ)的知識開始。因此，培訓一下還是很有必要的。