軟體測試的工程師階層是指隨著行業的飛速發展，測試人員猶如身在洪流之中“逆水行舟不進則退”。知其然已經無法滿足當今的測試人員，還要知其所以然。所以測試人員不僅僅要關注系統外部結構，還得了解系統內部的邏輯結構，需要把系統拆成模組，模組拆成單元進行更細緻的測試。進行模組級別的拆分後，再把各種部件歸納組合，儘可能多地去遍歷測試點，以保證系統的可靠性和穩定性。

1．單元測試

單元測試在實際工作中，是由開發人員在開發完成後自行進行的測試。
在這裡先要明確一個概念，單元測試是一種測試，它需要獨立設計測試用例及執行bug修復
的過程，而不是開發在完成程式的除錯工作。除錯是除錯，測試是測試，希望大家不要混滑這兩種不同的概念。單元測試是指對軟體中的基本組成單位進行的測試，如一個模組、一個過程等。它是軟體動態測試的最基本的部分，也是最重要的部分之一，其目的是檢驗軟體基本組成單位的正確性。單元測試方法包括：控制流測試、資料流測試、排錯測試、分域測試等。

站在測試的角度，測試人員希望開發人員能夠在開發程式後進行單元測試。原因有二：
（1）對於程式設計師，單元測試能保證一定程度的開發質量，對於程式設計師自身能力的提高和自我
約東能起到很好的作用。很多情況下，整體測試執行中的bug數會被體現在開發的績效中。而在
單元測試環節，開發就能夠通過自測修復一部分bug。
（2）對於測試員，單元測試在保證開發質量的基礎上，也減少了測試執行的成本。這個成本
分為兩方面。

• 測試執行不僅包括測試人員執行測試用例，很多時間是花費在程式設計師與測試員的互動上。這種互動是由於bug管理而產生的。因為bug數的減少，這部分測試執行的成本會被壓縮。
• 測試執行大約佔整個測試過程13的比例。由於開發質量問題造成測試增大工作量或者被
  推翻重來的情況很多。為了讓測試成本可控並且有效地減少專案的成本代價，單元測試
  就是有效維護開發質量的方式。
  這裡向大家推薦一個測試交流圈q裙：1007119548。
  當開發做了單元測試後，測試人員就利用冒煙測試檢查單元測試成果。如果冒煙測試通過，
  專案正式進人測試階段。如果不通過，則程式被退回，需要開發自行測試通過後，再交於測試人員進行冒煙測試流程。
  還有另外兩種情況如下:
  （1）單元測試並不是由開發完成的。而是由專業的單元測試人員完成的。
  （2）單元測試是由測試人員提供測試用例，但測試執行由程式設計師自己完成。
  這兩種情況雖然和我們常規的單元測試定義不同。但理論是死的人是活的，只要測試部與序
  發部能夠達成一致，對該專案有推進作用，那就是可行的方法。

2．整合測試

整合測試是在單元測試之後進行的測試。專案中的整合測試大多由開發自己完成，開發把這
種測試叫作介面聯調。獨立的整合測試專案是指在軟體系統整合過程中所進行的測試，其主要目的是檢查軟體單位之間的介面是否正確。它根據整合測試計劃，一邊將模組或其他軟體單位組合成越來越大的系統，一邊執行該系統，以分析所組成的系統是否正確。
整合測試的策略主要有自頂向下和自底向上兩種。
（1）自頂向下的整合是從主控模組（主程式，即根結點）開始，按照系統程式結構，沿著控
制層次從上而下，逐漸將各模組組裝起來。在從上向下的整合測試過程中，需對那些未經整合的
模組開發柱模組。在整合過程中，可以採用寬度優先或深度優先的策略向下推進。
（2）自底向上的整合是從最底層模組（葉子結點）開始，按照呼叫圖的結構，從下而上，逐層
將各模組組裝起來。在從下而上的整合測試環境中，需對那些未經整合測試的模組開發驅動模組
大部分情況，測試人員所做的整合測試又被稱為介面測試。這也是本書所要述的測試重點
介面測試主要分為兩種情況。
（1）系統層面

• 模組與模組間的介面傳輸是否正確。
• 系統與系統間的介面的傳輸是否正確。
  （2）程式碼層面
  類與方法的呼叫。
  測試人員會在系統未被組建完全前，對模組的介面呼叫進行測試。當確定模組的介面傳輸正
  確時，我們可以初步認定模組被整合後不會出現問題。模組與模組間的介面是否傳輸正確，也可以通過功能測試的方法進行辨別。
  對於複雜大型的系統架構面言，系統與系統間的介面測試比模組與模組間的介面測試更為重員
  要。例如，一個資金入賬的功能，就可能需要通過入賬平臺、第三方支付平臺、資金平臺、財務驗平臺等多平臺共同工作完成。這時平臺與平臺間的介面測試就尤為重要了。模組與模組間的介面問題，你或許可以通過系統測試時的功能測試被發現。但平臺與平臺間的介面問題，則需要獨立後的整合測試才能被儘早發現。這部分內容，會在介面測試章節中做出詳細解析。

3．系統測試

系統測試是在整合測試之後進行的測試，也是測試人員接觸最多的測試環節。系統測試是指
對已經整合好的軟體系統進行測試，以驗證軟體系統的功能正確性和效能等是否能滿足其需求規
格說明書所指定的要求。軟體系統測試方法很多，主要有功能測試、效能測試、相容性測試等。例
在系統測試中，我們會經常用到迴歸測試和冒煙測試。
（1）迴歸測試是指修改了舊程式碼後，重新進行測試以確認修改沒有引入新的錯誤或導致其他不
程式碼產生錯誤，迴歸測試的困難在於不好確定哪些內容應當被重新測試。
（2）冒煙測試是指對軟體基本的功能進行測試。測試的物件是每一個新編譯的需要正式測試
的軟體版本，目的是確認軟體基本的功能正常，保證軟體系統能跑起來，可以進行後續的正式
試工作。
系統測試在工作中的實踐情況為：
系統測試是測試人員遇見最多的測試；功能測試就是系統測試的主要組成部分；
在測試人員完成功能測試後，如果需求規格書上有對系統效能、安全性、相容性等方面的要求，測試人員應該根據其規定的指標，進行效能測試、安全性測試以及相容性測試。

系統測試分為：測試需求提取、測試框架確定、測試用例編寫、測試用例執行、測試報告編
寫及評審階段。測試人員在編寫測試用例時，需考慮測試執行的順序。在測試用例執行階段，測試人員通常可以將其分為三輪測試及迴歸測試進行。將整體測試用例合理地分為三輪測試，最好能做到有兩輪測試重複驗證重要功能的情況出現，我們稱為雙重保證。這就需要測試人員去思考，怎樣佈置測試用例能夠保險且不影響測試效率。在測試人員完成測試提交測試基線前，通常還會安排一次整體的迴歸測試以確保主要業務流程的正確性。

4．驗收測試

驗收測試是在系統測試結果後進行的測試。由客戶或終端使用者執行，旨在向軟體的購買者展
示該軟體系統滿足其使用者的需求。它的測試資料通常是系統測試的測試資料的子集。所不同的是
驗收測試常常有軟體系統的購買者代表在現場，甚至是在軟體安裝使用的現場。這是軟體在投人使用之前的最後測試。
通常驗收測試分為兩個部分。
（1） Alpha測試：由使用者在開發環境的場所進行，並且在測試人員對使用者的“指導”下進行
測試。測試人員負責記錄發現在錯誤和使用中遇到的問題。總之， Alpha測試是在受控的環境中進行的。
（2）Beta測試：由軟體的終端使用者們在一個或多個客戶現場進行。與 Alpha測試不同，開發
及測試人員通常不在Beta測試的現場，所以Beta測試是軟體在測試開發人員不能控制的環境中
的“真實”應用。使用者記錄在Beta測試過程中遇到的一切問題並且定期把這些問題報告給開發者。
接收到在Beta測試期間報告的問題之後，測試人員會初步篩選確定其是否為缺陷，再由開發人員對軟體產品進行必要的修改，並將最終的軟體產品釋出給全體客戶。
在很多專案中，除了需求、開發、測試、專案經理這些T職稱外，還有一類職稱叫作實施人員。他們是業務人員與運維人員的綜合體。他們可以介人測試階段幫助測試人員一起測試，也是驗收階段的主要執行人員。驗收測試一般不由測試人員直接進行，因為經過長時間的測試執行過程，測試人員的思維會形成固式（思維侷限性）。實施人員精通業務，他們是需求的創始者，最後會脫離測試用例的約束，真正從初始需求的角度配置生產環境進行驗收測試，做好面向客戶的最後一道防線。

結語

感謝您的觀看，如有不足之處，歡迎批評指正。

獲取資料

本次給大家推薦一個免費的學習群，裡面概括Python/效能/介面/安全/自動化軟體測試以及面試資源等。
對測試感興趣的同學，歡迎加入Q群：1007119548，不管你是小白還是大牛我都歡迎，還有大牛整理的一套高效率學習路線和教程與您免費分享，同時每天更新視訊資料。
最後，祝大家早日學有所成。