《軟件測試52講》——測試基礎知識篇

《軟件測試52講》

一、測試基礎知識篇——（0~11講）

二、GUI自動化測試篇——（12~21講）

持續更新中~

測試基礎知識篇

01——你真的懂測試嗎？從「用戶登陸」測試談起

從「用戶登陸」測試談起，「用戶登陸」功能做爲測試對象

　　做爲測試工程師，你的目標是要保證系統在各類應用場景下的功能是符合設計要求的，因此你須要考慮的測試用例就須要更多、更全面。

　　等價類劃分方法，是將全部可能的輸入數據劃分紅若干個子集，在每一個子集中，若是任意一個輸入數據對於揭露程序中潛在錯誤都具備同等效果，那麼這樣的子集就構成了一個等價類。後續只要從每一個等價類中任意選取一個值進行測試，就能夠用少許具備表明性的測試輸入取得較好的測試覆蓋結果。

　　邊界值分析方法，是選取輸入、輸出的邊界值進行測試。由於一般大量的軟件錯誤是發生在輸入或輸出範圍的邊界上，因此須要對邊界值進行重點測試，一般選取正好等於、剛剛大於或剛剛小於邊界的值做爲測試數據。

基於等價類劃分和邊界值分析方法，設計的測試用例

顯式功能性需求和非功能性需求

　　顯式功能性需求：軟件自己須要實現的具體功能

　　非功能性需求：安全性、性能、兼容性

安全性測試用例包括：

　　一、用戶密碼後臺存儲是否加密；

　　二、用戶密碼在網絡傳輸過程當中是否加密；

　　三、密碼是否具備有效期，密碼有效期到期後，是否提示須要修改密碼；

　　四、不登陸的狀況下，在瀏覽器中直接輸入登陸後的URL地址，驗證是否會從新定向到用戶登陸界面；

　　五、密碼輸入框是否不支持複製和粘貼；

　　六、密碼輸入框內輸入的密碼是否均可以在頁面源碼模式下被查看

　　七、用戶名和密碼的輸入框中分別輸入典型的「SQL注入攻擊」字符串，驗證系統的返回頁面；

　　八、用戶名和密碼的輸入框中分別輸入典型的「XSS跨站腳本攻擊」字符串，驗證系統行爲是否被篡改；

　　九、連續屢次登陸失敗狀況下，系統是否會阻止後續的嘗試以應對暴力破解；

　　十、同一用戶在同一終端的多種瀏覽器上登陸，驗證登陸功能的互斥性是否符合設計預期；

　　十一、同一用戶前後在多臺終端的瀏覽器上登陸，驗證登陸是否具備互斥性。

性能壓力測試用例包括：

　　一、單用戶登陸的響應時間是否小於3秒；

　　二、單用戶登陸時，後臺請求數量是否過多；

　　三、高併發場景下用戶登陸的響應時間是否小於5秒；

　　四、高併發場景下服務端的監控指標是否符合預期；

　　五、高集合點併發場景下，是否存在資源死鎖和不合理的資源等待；

　　六、長時間大量用戶連續登陸和登出，服務器端是否存在內存泄露。

兼容性測試用例包括：

　　一、不一樣瀏覽器下，驗證登陸頁面的顯示以及功能正確性；

　　二、相同瀏覽器的不一樣版本下，驗證登陸頁面的顯示以及功能正確性；

　　三、不一樣移動設備終端的不一樣瀏覽器下，驗證登陸頁面的顯示以及功能正確性；

　　四、不一樣分辨率的界面下，驗證登陸頁面的顯示以及功能正確性。

 　　測試的不可窮盡性，即絕大多數狀況下，是不可能進行窮盡測試的。「窮盡測試」，是指包含了軟件輸入值和前提條件全部可能組合的測試方法，完成窮盡測試的系統裏應該不殘留任何未知的軟件缺陷。

　　在絕大多數的軟件工程實踐中，測試因爲受限於時間成本和經濟成本，是不可能去窮盡全部可能的組合的，而是採用基於風險驅動的模式，有所側重地選擇測試範圍和設計測試用例，以尋求缺陷風險和研發成本之間的平衡。

02——如何設計一個「好的」測試用例「

好的」測試用例必須具有哪些特徵？

 　　在具體的用例設計時，首先須要搞清楚每個業務需求所對應的多個軟件功能需求點，而後分析出每一個軟件功能需求點對應的多個測試需求點，最後再針對每一個測試需求點設計測試用例。

具體到測試用例設計自己的設計，兩個關鍵的點：

　　一、從軟件功能需求出發，全面地、無遺漏地識別出測試需求是相當重要的，這將直接關係到用例的測試覆蓋率。

　　二、對於識別出的每一個測試需求點，須要綜合運用等價類劃分、邊界值分析和錯誤推測方法來全面地設計測試用例。

用例設計的其餘經驗

　　一、只有深刻理解被測試軟件的架構，你才能設計出」有的放矢「的測試用例集，去發現系統邊界以及系統集成上的潛在缺陷。

　　二、必須深刻理解被測軟件的設計與實現細節，深刻理解軟件內部的處理邏輯。

　　三、須要引入需求覆蓋率和代碼覆蓋率來衡量測試執行的完備性，並以此爲依據來找出遺漏的測試點。

03——什麼是單元測試？如何作好單元測試

單元測試

　　單元測試是批，對軟件中的最小可測試單元在與程序其餘部分相隔離的狀況下進行檢查和驗證的工做，這裏的最小可測試單元一般是指函數或者類。

如何作好單元測試？

　　第一，代碼的基本特徵與產生錯誤的緣由

　　第二，單元測試用例詳解（單元測試的用例是一個「輸入數據」和「預計輸出」的集合。）

　　第三，驅動代碼，樁代碼和Mock代碼（驅動代碼是用來調用被測函數的，而樁代碼和Mock代碼是用來代替被測函數調用的真實代碼的。）

驅動代碼、樁代碼和Mock代碼三者的邏輯關係。

　　驅動代碼（Driver）指調用被測函數的代碼，在單元測試過程當中，驅動模塊一般包括調用被測函數前的數據準備、調用被測函數以及驗證相關結果三個步驟。

　　樁代碼（Stub）是用來代替真實代碼的臨時代碼。

 　　Mock代碼和樁代碼的本質區別是：測試期待結果的驗證（Assert and Expectiation）

實際項目中如何開展單元測試？

　　一、並非全部的代碼都要進行單元測試，一般只有底層模塊或核心模塊的測試中才會採用單元測試。

　　二、你須要肯定單元測試框架的選型，這和開發語言直接相關。Java（Junit和TestNG），Python（Pytest、Unitest）

　　三、爲了可以衡量單元測試的代碼覆蓋率，一般你還須要引入計算代碼覆蓋率的工具。Java（JaCoCo）

　　四、最後你須要把單元測試執行、代碼覆蓋率統計和持續集成流水線作成集成，以確保每次代碼遞交，都會自動觸發單元測試，並在單元測試執行過程當中自動統計代碼覆蓋率，最後以「單元測試經過率」和「代碼覆蓋率」爲標準來決定本次代碼遞交是否可以被接受。

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——如何高效填寫軟件缺陷報告？

一份高效的缺陷報告主要由哪些部分組成及各部分的關鍵點。

　　一、缺陷標題　　

　　　　缺陷標題一般是別人最早看到的部分，是對缺陷的歸納性描述，一般採用「在什麼狀況下發生了什麼問題」，的模式。

　　二、缺陷概述

　　　　缺陷概述一般會提供更多歸納性的缺陷本質與現象的描述，是缺陷標題的細化。

　　三、缺陷影響

　　四、環境配置

　　五、前置條件

　　六、缺陷重現步驟

　　七、指望結果和實際結果

　　八、優先級（Priority）和嚴重程度（Severity）

　　九、變通方案（Workaround）

　　十、根緣由分析（Root Cause Analysis）

　　十一、附件（Attachment）

08——以終爲始，如何才能作好測試計劃？

一份好的測試計劃要包括：

一、測試範圍

　　明確「測什麼」和「不測什麼」

二、測試策略

　　明確「先測什麼後測什麼」和「如何來測」

　　（1）功能測試（2）兼容性測試（3）性能測試 等

三、測試資源

　　明確「誰來測」和「在哪裏測」

四、測試進度

　　明確開始時間、所需工做量、預計完成時間、上線發佈時間

　　行爲驅動開發，BDD，最典型的框架是「Cucumber」

五、測試風險預估

　　明確如何有效應地各類潛在的變化

09——軟件測試工程師的核心競爭力是什麼？

　　測試開發崗位的核心實際上是「測試」，「開發」的目的是更好地服務於測試

傳統測試工程師的核心競爭力

　　一、測試策略設計能力

　　　　（1）測試要具體執行到程度；

　　　　（2）測試須要藉助於什麼工具；

　　　　（3）如何運用自動化測試以及自動測試框架，以及如何選型；

　　　　（4）測試人員資源如何合理分配；

　　　　（5）測試進度如何安排；

　　　　（6）測試風險如何應對。

　　二、測試用例設計能力

　　　　提升測試用例設計能力，平時要多積累，對常見的缺陷模式、典型的錯誤類型以及遇到過的缺陷，不斷總結、概括、觸類旁通。

　　三、快速學習能力

　　四、探索性測試思惟

　　五、缺陷分析能力

　　六、自動化測試技術

　　七、良好的溝通能力

測試開發工程師的核心競爭力

　　一、測試系統需求分析能力

　　二、更寬廣的知識體系

10——軟件測試工程師須要掌握的非測試知識有哪些？

一、網站架構的核心知識

二、容器技術

　　Docker和Kubernetes

三、雲計算技術

　　Sauce Labs 測試執行環境公有云服務

　　Appium+Selenium Grid集羣 搭建移動終端設備的測試執行私有云

四、DevOps思惟

　　Jenkins

五、前端開發技術

11——互聯網產品的測試策略應該如何設計？

　　發佈流程一般包含了代碼靜態掃描、單元測試、編譯、打包、上傳、下載、部署和測試的全流程

傳統軟件產品的測試策略設計

 互聯網產品的測試策略設計

 互聯網產品的菱形測試策略（重量級API測試、輕量級GUI測試、輕量級單元測試）

　　一、以中間層的API測試爲重點作全面的測試。

　　二、輕量級的GUI測試，只覆蓋最核心直接影響主營業務流程的E2E場景。

　　三、最上層的GUI測試一般利用探索式測試思惟，以人工測試的方式發現儘量多的潛在問題。

　　四、單元測試採用「分而治之」的思想，只對那些相對穩定而且核心的服務和模塊開展全面的單元測試，而應用層或者上層業務只會作少許的單元測試。