《軟件測試52講》
測試基礎知識篇
01——你真的懂測試嗎？從“用戶登錄”測試談起
從“用戶登錄”測試談起，“用戶登錄”功能作為測試對象
作為測試工程師，你的目標是要保證系統在各種應用場景下的功能是符合設計要求的，所以你需要考慮的測試用例就需要更多、更全面。
等價類划分方法，是將所有可能的輸入數據划分成若干個子集，在每個子集中，如果任意一個輸入數據對於揭露程序中潛在錯誤都具有同等效果，那么這樣的子集就構成了一個等價類。后續只要從每個等價類中任意選取一個值進行測試，就可以用少量具有代表性的測試輸入取得較好的測試覆蓋結果。
邊界值分析方法，是選取輸入、輸出的邊界值進行測試。因為通常大量的軟件錯誤是發生在輸入或輸出范圍的邊界上，所以需要對邊界值進行重點測試，通常選取正好等於、剛剛大於或剛剛小於邊界的值作為測試數據。
基於等價類划分和邊界值分析方法，設計的測試用例
顯式功能性需求和非功能性需求
顯式功能性需求：軟件本身需要實現的具體功能
非功能性需求：安全性、性能、兼容性
安全性測試用例包括：
1、用戶密碼后台存儲是否加密；
2、用戶密碼在網絡傳輸過程中是否加密；
3、密碼是否具有有效期，密碼有效期到期后，是否提示需要修改密碼；
4、不登錄的情況下，在瀏覽器中直接輸入登錄后的URL地址，驗證是否會重新定向到用戶登錄界面；
5、密碼輸入框是否不支持復制和粘貼；
6、密碼輸入框內輸入的密碼是否都可以在頁面源碼模式下被查看
7、用戶名和密碼的輸入框中分別輸入典型的“SQL注入攻擊”字符串，驗證系統的返回頁面；
8、用戶名和密碼的輸入框中分別輸入典型的“XSS跨站腳本攻擊”字符串，驗證系統行為是否被篡改；
9、連續多次登錄失敗情況下，系統是否會阻止后續的嘗試以應對暴力破解；
10、同一用戶在同一終端的多種瀏覽器上登錄，驗證登錄功能的互斥性是否符合設計預期；
11、同一用戶先后在多台終端的瀏覽器上登錄，驗證登錄是否具有互斥性。
性能壓力測試用例包括：
1、單用戶登錄的響應時間是否小於3秒；
2、單用戶登錄時，后台請求數量是否過多；
3、高並發場景下用戶登錄的響應時間是否小於5秒；
4、高並發場景下服務端的監控指標是否符合預期；
5、高集合點並發場景下，是否存在資源死鎖和不合理的資源等待；
6、長時間大量用戶連續登錄和登出，服務器端是否存在內存泄露。
兼容性測試用例包括：
1、不同瀏覽器下，驗證登錄頁面的顯示以及功能正確性；
2、相同瀏覽器的不同版本下，驗證登錄頁面的顯示以及功能正確性；
3、不同移動設備終端的不同瀏覽器下，驗證登錄頁面的顯示以及功能正確性；
4、不同分辨率的界面下，驗證登錄頁面的顯示以及功能正確性。
測試的不可窮盡性，即絕大多數情況下，是不可能進行窮盡測試的。“窮盡測試”，是指包含了軟件輸入值和前提條件所有可能組合的測試方法，完成窮盡測試的系統里應該不殘留任何未知的軟件缺陷。
在絕大多數的軟件工程實踐中，測試由於受限於時間成本和經濟成本，是不可能去窮盡所有可能的組合的，而是采用基於風險驅動的模式，有所側重地選擇測試范圍和設計測試用例，以尋求缺陷風險和研發成本之間的平衡。
02——如何設計一個“好的”測試用例“
好的”測試用例必須具備哪些特征？
在具體的用例設計時，首先需要搞清楚每一個業務需求所對應的多個軟件功能需求點，然后分析出每個軟件功能需求點對應的多個測試需求點，最后再針對每個測試需求點設計測試用例。
具體到測試用例設計本身的設計，兩個關鍵的點：
1、從軟件功能需求出發，全面地、無遺漏地識別出測試需求是至關重要的，這將直接關系到用例的測試覆蓋率。
2、對於識別出的每個測試需求點，需要綜合運用等價類划分、邊界值分析和錯誤推測方法來全面地設計測試用例。
用例設計的其他經驗
1、只有深入理解被測試軟件的架構，你才能設計出”有的放矢“的測試用例集，去發現系統邊界以及系統集成上的潛在缺陷。
2、必須深入理解被測軟件的設計與實現細節，深入理解軟件內部的處理邏輯。
3、需要引入需求覆蓋率和代碼覆蓋率來衡量測試執行的完備性，並以此為依據來找出遺漏的測試點。
03——什么是單元測試？如何做好單元測試
單元測試
單元測試是批，對軟件中的最小可測試單元在與程序其他部分相隔離的情況下進行檢查和驗證的工作，這里的最小可測試單元通常是指函數或者類。
如何做好單元測試？
第一，代碼的基本特征與產生錯誤的原因
第二，單元測試用例詳解（單元測試的用例是一個“輸入數據”和“預計輸出”的集合。）
第三，驅動代碼，樁代碼和Mock代碼（驅動代碼是用來調用被測函數的，而樁代碼和Mock代碼是用來代替被測函數調用的真實代碼的。）
驅動代碼、樁代碼和Mock代碼三者的邏輯關系。
驅動代碼（Driver）指調用被測函數的代碼，在單元測試過程中，驅動模塊通常包括調用被測函數前的數據准備、調用被測函數以及驗證相關結果三個步驟。
樁代碼（Stub）是用來代替真實代碼的臨時代碼。
Mock代碼和樁代碼的本質區別是：測試期待結果的驗證（Assert and Expectiation）
實際項目中如何開展單元測試？
1、並不是所有的代碼都要進行單元測試，通常只有底層模塊或核心模塊的測試中才會采用單元測試。
2、你需要確定單元測試框架的選型，這和開發語言直接相關。Java（Junit和TestNG），Python（Pytest、Unitest）
3、為了能夠衡量單元測試的代碼覆蓋率，通常你還需要引入計算代碼覆蓋率的工具。Java（JaCoCo）
4、最后你需要把單元測試執行、代碼覆蓋率統計和持續集成流水線做成集成，以確保每次代碼遞交，都會自動觸發單元測試，並在單元測試執行過程中自動統計代碼覆蓋率，最后以“單元測試通過率”和“代碼覆蓋率”為標准來決定本次代碼遞交是否能夠被接受。
04——為什么要做自動化測試？什么樣的項目適合做自動化測試
自動化測試
自動化測試是，把人對軟件的測試行為轉化為由機器執行測試行為的一種實踐
什么樣的項目適合自動化測試？
第一，需求穩定，不會頻繁變更
第二，研發和維護周期長，需要頻繁執行回歸測試
第三，需要在多種平台上重復運行相同測試的場景
第四，某些測試項目通過手工測試無法實現，或者手工成本太高
第五，被測軟件的開發較為規范，能夠保證系統的可測試性
第六，測試人員已經具備一定的編程能力
第六點的阻力：
（1）前期的學習成本通常會比較大，很難在短期內對實際項目產生實質性的幫助，此時如果管理層對自動化測試沒有正確的預期，很可能會叫停自動化測試；
（2）測試工程師通常會非常熱衷於學習使用自動化測試技術，以至於他們的工作重點會發生錯誤的偏移，把大量的精力放在自動化測試技術的學習與實踐中，而忽略了測試用例的設計，這將直接降低軟件整體的質量。
05——你知道軟件開發各階段都有哪些自動化測試技術嗎？
單元測試的自動化技術
第一，用例框架代碼生成的自動化
第二，部分測試輸入數據的自動化生成
第三，自動樁代碼的生成
第四，被測代碼的自動化靜態分析
靜態分析主要指代碼的靜態掃描，目的是識別出違反編碼規則或編碼風格的代碼行。目前比較常用的代碼靜態分析工具有Sonar和Coverity等
第五，測試覆蓋率的自動統計與分析
Web Service測試的自動化技術
Web Service測試，主要是指SOAP API和REST API這兩類API測試，最典型的是采用SoapUI或Postman等類似的工具。但這類測試工具基本都是界面操作手動發起Request並驗證Response，
所以難以和CI/CD集成，於是就出現了API自動化測試框架。
Web Service測試自動化包括：
第一，測試腳本架代碼的自動化生成
第二，部分測試輸入數據的自動生
第三，Response驗證的自動化
Response驗證自動化的核心思想是自動比較兩次相同API調用的返回結果，並自動識別出有差異的字段值，比較過程可以通過規則配置去掉諸如時間戳、會話ID（Session ID）等動態值。
第四，基於SoapUI或者Postman的自動化腳本生成
GUI測試的自動化技術
GUI自動化測試主要分為兩大方向：傳統Web瀏覽器和移動端原生應用（Native Appp）的GUI自動化。附加（小程序）
傳統Web瀏覽器的GUI自動化測試：Selenium、Puppteer
移動端原生應用：Appium
06——你真的懂測試覆蓋率嗎？
測試覆蓋率
測試覆蓋率通常被用來衡量測試的充分性和完整性，從廣義的角度來講，測試覆蓋率主要分為兩大類，一類是面向項目的需求覆蓋率，另一類是更偏向技術的代碼覆蓋率。
需求覆蓋率
需求覆蓋率是指測試對需求的覆蓋程度，通常的做法是將每一條分解后的軟件需求和對應的測試建立一對多的映射關系，最終目標是保證測試可以覆蓋每個需求，以保證軟件產品的質量。
代碼覆蓋率
代碼覆蓋率是批至少被執行了一次的條目數占整個條目數的百分比。
三種代碼覆蓋率指標
代碼覆蓋率的價值
統計代碼覆蓋率的根本目的是找出潛在的遺漏測試用例，並有針對性的進行補充，同時還可以識別出代碼中那些由於需求變更等原因造成的不可達的廢棄代碼。
代碼覆蓋率的局限性
總結來講，高的代碼覆蓋率不一定能保證軟件的質量，但是低的代碼覆蓋率一定不能保證軟件的質量。
代碼覆蓋率工具
JaCoCo是一款Java代碼的主流開源覆蓋率工具
Javascript的代碼覆蓋率：JSCoverage和Istanbul
07——如何高效填寫軟件缺陷報告？
一份高效的缺陷報告主要由哪些部分組成及各部分的關鍵點。
1、缺陷標題
缺陷標題通常是別人最先看到的部分，是對缺陷的概括性描述，通常采用“在什么情況下發生了什么問題”，的模式。
2、缺陷概述
缺陷概述通常會提供更多概括性的缺陷本質與現象的描述，是缺陷標題的細化。
3、缺陷影響
4、環境配置
5、前置條件
6、缺陷重現步驟
7、期望結果和實際結果
8、優先級（Priority）和嚴重程度（Severity）
9、變通方案（Workaround）
10、根原因分析（Root Cause Analysis）
11、附件（Attachment）
08——以終為始，如何才能做好測試計划？
一份好的測試計划要包括：
1、測試范圍
明確“測什么”和“不測什么”
2、測試策略
明確“先測什么后測什么”和“如何來測”
（1）功能測試（2）兼容性測試（3）性能測試 等
3、測試資源
明確“誰來測”和“在哪里測”
4、測試進度
明確開始時間、所需工作量、預計完成時間、上線發布時間
行為驅動開發，BDD，最典型的框架是“Cucumber”
5、測試風險預估
明確如何有效應地各種潛在的變化
09——軟件測試工程師的核心競爭力是什么？
測試開發崗位的核心其實是“測試”，“開發”的目的是更好地服務於測試
傳統測試工程師的核心競爭力
1、測試策略設計能力
（1）測試要具體執行到程度；
（2）測試需要借助於什么工具；
（3）如何運用自動化測試以及自動測試框架，以及如何選型；
（4）測試人員資源如何合理分配；
（5）測試進度如何安排；
（6）測試風險如何應對。
2、測試用例設計能力
提高測試用例設計能力，平時要多積累，對常見的缺陷模式、典型的錯誤類型以及遇到過的缺陷，不斷總結、歸納、舉一反三。
3、快速學習能力
4、探索性測試思維
5、缺陷分析能力
6、自動化測試技術
7、良好的溝通能力
測試開發工程師的核心競爭力
1、測試系統需求分析能力
2、更寬廣的知識體系
10——軟件測試工程師需要掌握的非測試知識有哪些？
1、網站架構的核心知識
2、容器技術
Docker和Kubernetes
3、雲計算技術
Sauce Labs 測試執行環境公有雲服務
Appium+Selenium Grid集群 搭建移動終端設備的測試執行私有雲
4、DevOps思維
Jenkins
5、前端開發技術
11——互聯網產品的測試策略應該如何設計？
發布流程通常包含了代碼靜態掃描、單元測試、編譯、打包、上傳、下載、部署和測試的全流程
傳統軟件產品的測試策略設計
互聯網產品的測試策略設計
互聯網產品的菱形測試策略（重量級API測試、輕量級GUI測試、輕量級單元測試）
1、以中間層的API測試為重點做全面的測試。
2、輕量級的GUI測試，只覆蓋最核心直接影響主營業務流程的E2E場景。
3、最上層的GUI測試通常利用探索式測試思維，以人工測試的方式發現盡可能多的潛在問題。
4、單元測試采用“分而治之”的思想，只對那些相對穩定並且核心的服務和模塊開展全面的單元測試，而應用層或者上層業務只會做少量的單元測試。