開篇詞 | 從“小工”到“專家”，我的軟件測試修煉之道

隨著自動化測試用例設(shè)計與開發(fā)、測試框架選型、測試框架自行研發(fā)、測試基礎(chǔ)架構(gòu)設(shè)計以及最新的測試服務(wù)化（Test as a Service，TaaS）等一系列技術(shù)的變革與發(fā)展，測試項目幾乎涵蓋了所有種類，包括嵌入式系統(tǒng)測試、金融平臺單元測試、平臺 SDK 測試、軌道交通安全軟件測試、Web Service 測試、大型電商網(wǎng)站 GUI 自動化以及性能全鏈路壓測等。

第一步，成為互聯(lián)網(wǎng)時代合格的測試工程師。

你必須具有快速學(xué)習(xí)的能力，能迅速掌握被測軟件的業(yè)務(wù)功能與內(nèi)部架構(gòu)，并在此基礎(chǔ)上運(yùn)用各種測試方法，盡可能多地發(fā)現(xiàn)潛在缺陷，并能夠在已知缺陷的基礎(chǔ)上進(jìn)一步發(fā)現(xiàn)相關(guān)的連帶缺陷。

從知識體系上看，你需要有比開發(fā)人員更全面的計算機(jī)基礎(chǔ)知識，還需要了解互聯(lián)網(wǎng)的基礎(chǔ)架構(gòu)、安全攻擊、軟件性能、用戶體驗和常見缺陷等知識。

從測試技術(shù)上看，你需要能夠使用常見的測試框架或者工具，需要具有一定的自動化測試腳本的開發(fā)能力，這可以把你從大量重復(fù)的工作中解放出來，然后你才能有時間去做更有意思的工作。

第二步，成為互聯(lián)網(wǎng)時代優(yōu)秀的測試工程師。

首先，合格的測試工程師關(guān)注的是純粹的測試，而優(yōu)秀的測試工程師關(guān)注更多的是軟件整體的質(zhì)量，需要根據(jù)業(yè)務(wù)風(fēng)險以及影響來制定測試策略，有效控制測試的時間和成本，并且能夠?qū)y試框架以及工具做出適合項目需求的選型。

第三步，成為互聯(lián)網(wǎng)時代的測試架構(gòu)師。

面對大量測試用例的執(zhí)行，無論是 GUI 還是 API，都需要一套高效的能夠支持高并發(fā)的測試執(zhí)行基礎(chǔ)架構(gòu)；再比如，面對測試過程中的大量差異性數(shù)據(jù)要求，需要統(tǒng)一的測試數(shù)據(jù)準(zhǔn)備平臺；再比如，為了可以更方便地和持續(xù)集成與發(fā)布系統(tǒng)（CI/CD）以解耦的形式做集成，需要統(tǒng)一發(fā)起測試執(zhí)行的接口。

這樣的例子還有很多，如果你已經(jīng)能夠站在這樣的高度看待軟件測試，那么恭喜你，你已經(jīng)具備了測試架構(gòu)師的視野。當(dāng)然，你還必須對一些前沿的測試方法和技術(shù)有自己的理解，并能夠在恰當(dāng)?shù)臅r候、因地制宜地把它們應(yīng)用到實際項目中。

01 | 你真的懂測試嗎？從“用戶登錄”測試談起

功能測試用例：

基本

1. 輸入已注冊的用戶名和正確的密碼，驗證是否登錄成功；

2. 輸入已注冊的用戶名和不正確的密碼，驗證是否登錄失敗，并且提示信息正確；

3. 輸入未注冊的用戶名和任意密碼，驗證是否登錄失敗，并且提示信息正確；

4. 用戶名和密碼兩者都為空，驗證是否登錄失敗，并且提示信息正確；

5. 用戶名和密碼兩者之一為空，驗證是否登錄失敗，并且提示信息正確；

6. 如果登錄功能啟用了驗證碼功能，在用戶名和密碼正確的前提下，輸入正確的驗證碼，驗證是否登錄成功；

7. 如果登錄功能啟用了驗證碼功能，在用戶名和密碼正確的前提下，輸入錯誤的驗證碼，驗證是否登錄失敗，并且提示信息正確。

高級

1. 用戶名和密碼是否大小寫敏感；
2. 頁面上的密碼框是否加密顯示；
3. 后臺系統(tǒng)創(chuàng)建的用戶第一次登錄成功時，是否提示修改密碼；
4. 忘記用戶名和忘記密碼的功能是否可用；
5. 前端頁面是否根據(jù)設(shè)計要求限制用戶名和密碼長度；
6. 如果登錄功能需要驗證碼，點擊驗證碼圖片是否可以更換驗證碼，更換后的驗證碼是否可用；
7. 刷新頁面是否會刷新驗證碼；
8. 如果驗證碼具有時效性，需要分別驗證時效內(nèi)和時效外驗證碼的有效性；
9. 用戶登錄成功但是會話超時后，繼續(xù)操作是否會重定向到用戶登錄界面；
10. 不同級別的用戶，比如管理員用戶和普通用戶，登錄系統(tǒng)后的權(quán)限是否正確；
11. 頁面默認(rèn)焦點是否定位在用戶名的輸入框中；
12. 快捷鍵 Tab 和 Enter 等，是否可以正常使用。

一個質(zhì)量過硬的軟件系統(tǒng)，除了顯式功能性需求以外，其他的非功能性需求即隱式功能性需求也是極其關(guān)鍵的。

安全性測試用例：

1. 用戶密碼后臺存儲是否加密；
2. 用戶密碼在網(wǎng)絡(luò)傳輸過程中是否加密；
3. 密碼是否具有有效期，密碼有效期到期后，是否提示需要修改密碼；
4. 不登錄的情況下，在瀏覽器中直接輸入登錄后的 URL 地址，驗證是否會重新定向到用戶登錄界面；
5. 密碼輸入框是否不支持復(fù)制和粘貼；
6. 密碼輸入框內(nèi)輸入的密碼是否都可以在頁面源碼模式下被查看；
7. 用戶名和密碼的輸入框中分別輸入典型的“SQL 注入攻擊”字符串，驗證系統(tǒng)的返回頁面；
8. 用戶名和密碼的輸入框中分別輸入典型的“XSS 跨站腳本攻擊”字符串，驗證系統(tǒng)行為是否被篡改；
9. 連續(xù)多次登錄失敗情況下，系統(tǒng)是否會阻止后續(xù)的嘗試以應(yīng)對暴力破解；
10. 同一用戶在同一終端的多種瀏覽器上登錄，驗證登錄功能的互斥性是否符合設(shè)計預(yù)期；
11. 同一用戶先后在多臺終端的瀏覽器上登錄，驗證登錄是否具有互斥性。

性能壓力測試用例:

1. 單用戶登錄的響應(yīng)時間是否小于 3 秒；
2. 單用戶登錄時，后臺請求數(shù)量是否過多；
3. 高并發(fā)場景下用戶登錄的響應(yīng)時間是否小于 5 秒；
4. 高并發(fā)場景下服務(wù)端的監(jiān)控指標(biāo)是否符合預(yù)期；
5. 高集合點并發(fā)場景下，是否存在資源死鎖和不合理的資源等待；
6. 長時間大量用戶連續(xù)登錄和登出，服務(wù)器端是否存在內(nèi)存泄漏。

兼容性測試用例：

1. 不同瀏覽器下，驗證登錄頁面的顯示以及功能正確性；
2. 相同瀏覽器的不同版本下，驗證登錄頁面的顯示以及功能正確性；
3. 不同移動設(shè)備終端的不同瀏覽器下，驗證登錄頁面的顯示以及功能正確性；
4. 不同分辨率的界面下，驗證登錄頁面的顯示以及功能正確性。

一個優(yōu)秀的測試工程師必須具有很寬廣的知識面，如果你不能對被測系統(tǒng)的設(shè)計有深入的理解、不明白安全攻擊的基本原理、沒有掌握性能測試的基本設(shè)計方法，很難設(shè)計出“有的放矢”的測試用例。

在絕大多數(shù)的軟件工程實踐中，測試由于受限于時間成本和經(jīng)濟(jì)成本，是不可能去窮盡所有可能的組合的，而是采用基于風(fēng)險驅(qū)動的模式，有所側(cè)重地選擇測試范圍和設(shè)計測試用例，以尋求缺陷風(fēng)險和研發(fā)成本之間的平衡。

總結(jié)

首先，對于高質(zhì)量的軟件測試，用例設(shè)計不僅需要考慮明確的顯式功能性需求，還要涉及兼容性、安全性和性能等一系列的非功能性需求，這些非功能性需求對軟件系統(tǒng)的質(zhì)量有著舉足輕重的作用。

其次，優(yōu)秀的測試工程師必須具有寬廣的知識面，才能設(shè)計出有針對性、更易于發(fā)現(xiàn)問題的測試用例。

最后，軟件測試的用例設(shè)計是不可窮盡的，工程實踐中難免受制于時間成本和經(jīng)濟(jì)成本，所以優(yōu)秀的測試工程師需要兼顧缺陷風(fēng)險和研發(fā)成本之間的平衡。

02 | 如何設(shè)計一個“好的”測試用例？

“好的”測試用例一定是一個完備的集合，它能夠覆蓋所有等價類以及各種邊界值，而跟能否發(fā)現(xiàn)缺陷無關(guān)。

“好的”測試用例必須具備哪些特征？

一個“好的”測試用例，必須具備以下三個特征。

1. 整體完備性： “好的”測試用例一定是一個完備的整體，是有效測試用例組成的集合，能夠完全覆蓋測試需求。
2. 等價類劃分的準(zhǔn)確性： 指的是對于每個等價類都能保證只要其中一個輸入測試通過，其他輸入也一定測試通過。
3. 等價類集合的完備性： 需要保證所有可能的邊界值和邊界條件都已經(jīng)正確識別。

做到了以上三點，就可以肯定測試是充分且完備的，即做到了完整的測試需求覆蓋。

對大多數(shù)的軟件測試而言，綜合使用等價類劃分、邊界值分析和錯誤推測這三大類方法就足夠了。

具體到測試用例本身的設(shè)計，有兩個關(guān)鍵點需要你注意。

1. 從軟件功能需求出發(fā)，全面地、無遺漏地識別出測試需求是至關(guān)重要的，這將直接關(guān)系到用例的測試覆蓋率。 比如，如果你沒有識別出用戶登錄功能的安全性測試需求，那么后續(xù)設(shè)計的測試用例就完全不會涉及安全性，最終造成重要測試漏洞。
2. 對于識別出的每個測試需求點，需要綜合運(yùn)用等價類劃分、邊界值分析和錯誤推測方法來全面地設(shè)計測試用例。 這里需要注意的是，要綜合運(yùn)用這三種方法，并針對每個測試需求點的具體情況，進(jìn)行靈活選擇。
   以“用戶登錄”的功能性測試需求為例，你首先應(yīng)該對“用戶名”和“密碼”這兩個輸入項分別進(jìn)行等價類劃分，列出對應(yīng)的有效等價類和無效等價類，對于無效等價類的識別可以采用錯誤猜測法（比如，用戶名包含特殊字符等），然后基于兩者可能的組合，設(shè)計出第一批測試用例。
   等價類劃分完后，你需要補(bǔ)充“用戶名”和“密碼”這兩個輸入項的邊界值的測試用例，比如用戶名為空（NULL）、用戶名長度剛剛大于允許長度等。

用例設(shè)計的其他經(jīng)驗

除了上面介紹的方法外，我再跟你分享三個獨(dú)家“秘籍”，希望能夠幫你設(shè)計出“好的”測試用例集。

1. 只有深入理解被測試軟件的架構(gòu)，你才能設(shè)計出“有的放矢”的測試用例集，去發(fā)現(xiàn)系統(tǒng)邊界以及系統(tǒng)集成上的潛在缺陷。
   作為測試工程師，切忌不能把整個被測系統(tǒng)看作一個大黑盒，你必須對內(nèi)部的架構(gòu)有清楚的認(rèn)識，比如數(shù)據(jù)庫連接方式、數(shù)據(jù)庫的讀寫分離、消息中間件 Kafka 的配置、緩存系統(tǒng)的層級分布、第三方系統(tǒng)的集成等等。
2. 必須深入理解被測軟件的設(shè)計與實現(xiàn)細(xì)節(jié)，深入理解軟件內(nèi)部的處理邏輯。
   單單根據(jù)測試需求點設(shè)計的用例，只能覆蓋“表面”的一層，往往會覆蓋不到內(nèi)部的處理流程、分支處理，而沒有覆蓋到的部分就很可能出現(xiàn)缺陷遺漏。在具體實踐中，你可以通過代碼覆蓋率指標(biāo)找出可能的測試遺漏點。
   同時，切忌不要以開發(fā)代碼的實現(xiàn)為依據(jù)設(shè)計測試用例。因為開發(fā)代碼實現(xiàn)的錯誤會導(dǎo)致測試用例也出錯，所以你應(yīng)該根據(jù)原始需求設(shè)計測試用例。
3. 需要引入需求覆蓋率和代碼覆蓋率來衡量測試執(zhí)行的完備性，并以此為依據(jù)來找出遺漏的測試點。 關(guān)于什么是需求覆蓋率和代碼覆蓋率，我會在后續(xù)的文章中詳細(xì)介紹。

總結(jié)

最后，我來簡單總結(jié)一下今天的主要內(nèi)容。

首先，你需要明白，“好的”測試用例一定是一個完備的集合，它能夠覆蓋所有等價類以及各種邊界值，而能否發(fā)現(xiàn)軟件缺陷并不是衡量測試用例好壞的標(biāo)準(zhǔn)。

其次，設(shè)計測試用例的方法有很多種，但綜合運(yùn)用等價類劃分、邊界值分析和錯誤推測方法，可以滿足絕大多數(shù)軟件測試用例設(shè)計的需求。

再次，“好的”測試用例在設(shè)計時，需要從軟件功能需求出發(fā)，全面地、無遺漏地識別出測試需求至關(guān)重要。

最后，如果想設(shè)計一個“好的”測試用例，你必須要深入理解被測軟件的架構(gòu)設(shè)計，深入軟件內(nèi)部的處理邏輯，需求覆蓋率和代碼覆蓋率這兩個指標(biāo)可以幫你衡量測試執(zhí)行的完備性。

03 | 什么是單元測試？如何做好單元測試？

1. 代碼要做到功能邏輯正確，必須做到分類正確并且完備無遺漏，同時每個分類的處理邏輯必須正確；
2. 單元測試是對軟件中的最小可測試單元在與軟件其他部分相隔離的情況下進(jìn)行的代碼級測試；
3. 樁代碼起到了隔離和補(bǔ)齊的作用，使被測代碼能夠獨(dú)立編譯、鏈接，并運(yùn)行。

04 | 為什么要做自動化測試？什么樣的項目適合做自動化測試？

自動化測試是，把人工對軟件的測試轉(zhuǎn)化為由機(jī)器執(zhí)行測試行為的一種實踐，可以把測試工程師從機(jī)械重復(fù)的測試工作中解脫出來，將更多的精力放在新功能的測試和更全面的測試用例設(shè)計上。

然而自動化測試試一把“雙刃劍”，雖然它可以從一定程度上解放測試工程師的勞動力，完成一些人工無法實現(xiàn)的測試，但并不適用于所有的測試場景，如果維護(hù)自動化測試的代價高過了節(jié)省的測試成本，那么在這樣的項目中推進(jìn)自動化測試就會得不償失。

06 | 你真的懂測試覆蓋率嗎？

這章以后要多看幾遍，了解的還是有很大的欠缺 。

測試覆蓋率通常被用來衡量測試的充分性和完整性，從廣義的角度來講，測試覆蓋率主要分為兩大類，一類是面向項目的需求覆蓋率，另一類是更偏向技術(shù)的代碼覆蓋率。

需求覆蓋率

需求覆蓋率是指測試對需求的覆蓋程度，通常的做法是將每一條分解后的軟件需求和對應(yīng)的測試建立一對多的映射關(guān)系，最終目標(biāo)是保證測試可以覆蓋每個需求，以保證軟件產(chǎn)品的質(zhì)量。

代碼覆蓋率

簡單來說，代碼覆蓋率是指，至少被執(zhí)行了一次的條目數(shù)占整個條目數(shù)的百分比。

測試覆蓋率通常被用來衡量測試的充分性和完整性，包括面向項目的需求覆蓋率和更偏向技術(shù)的代碼覆蓋率。而需求覆蓋率的統(tǒng)計方式不再適用于現(xiàn)在的敏捷開發(fā)模式，所以現(xiàn)在談到測試覆蓋率，大多是指代碼覆蓋率。

但是，高的代碼覆蓋率不一定能保證軟件的質(zhì)量，因為代碼覆蓋率是基于現(xiàn)有代碼，無法發(fā)現(xiàn)那些“未考慮某些輸入”以及“未處理某些情況”形成的缺陷。

另外，對于代碼覆蓋率的統(tǒng)計工具，我希望你不僅僅是會用的層次，而是能夠理解它們的原理，知其然知其所以然，才能更好地利用這些工具完成你的測試工作。

07 | 如何高效填寫軟件缺陷報告？

具體看文章比較好，講的很詳細(xì)。

缺陷報告是測試工程師與開發(fā)工程師交流溝通的重要橋梁，也是測試工程師日常工作的重要輸出。

一份高效的軟件缺陷報告，應(yīng)該包括缺陷標(biāo)題、缺陷概述、缺陷影響、環(huán)境配置、前置條件、缺陷重現(xiàn)步驟、期望結(jié)果和實際結(jié)果、優(yōu)先級和嚴(yán)重程度、變通方案、根原因分析，以及附件這幾大部分。

缺陷報告的每一部分內(nèi)容，都會因為目的、表現(xiàn)形式有各自的側(cè)重點，所以想要寫出一份高效的軟件缺陷報告，需要對其組成有深入的理解。

08 | 以終為始，如何才能做好測試計劃？

需要的時候看原文，寫的很詳細(xì)。

軟件測試同軟件項目一樣，也要制定詳細(xì)的測試計劃。雖然在敏捷開發(fā)模式下，軟件測試不再局限于厚重的、正式的計劃文檔，但是測試計劃的重要性絲毫沒有發(fā)生變化。

一份成功的測試計劃，必須清楚地描述：測試范圍、測試策略、測試資源、測試進(jìn)度和測試風(fēng)險預(yù)估這五個最重要的方面。

測試范圍需要明確“測什么”和“不測什么”；測試策略需要明確“先測什么后測什么”和“如何來測”；測試資源需要明確“誰來測”和“在哪里測”；測試進(jìn)度是需要明確各類測試的開始時間，所需工作量和預(yù)計完成時間；測試風(fēng)險預(yù)估是需要明確如何有效應(yīng)對各種潛在的變化。

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

我把測試工程師按照工作內(nèi)容，分為了功能測試工程師（即傳統(tǒng)測試工程師）和測試開發(fā)工程師兩類，分別給你分享了他們的核心競爭力。

對于功能測試工程師來說，其核心競爭力包括：測試策略設(shè)計能力、測試用例設(shè)計能力、快速學(xué)習(xí)能力、探索性測試思維、缺陷分析能力、自動化測試技術(shù)和良好的溝通能力這七大部分，你可以有針對性地提升自己某方面的能力，去獲取更大發(fā)展空間的“敲門磚”。

而對于測試開發(fā)工程師來說，你需要具備優(yōu)秀的測試系統(tǒng)需求分析能力和完備的知識體系，這樣才能保證你設(shè)計的測試工作和平臺，可以更好地滿足提升測試效率的要求。

11 | 互聯(lián)網(wǎng)產(chǎn)品的測試策略應(yīng)該如何設(shè)計？

傳統(tǒng)軟件通常采用金字塔模型的測試策略，而現(xiàn)今的互聯(lián)網(wǎng)產(chǎn)品往往采用菱形模型。菱形模型有以下四個關(guān)鍵點：

• 以中間層的 API 測試為重點做全面的測試。
• 輕量級的 GUI 測試，只覆蓋最核心直接影響主營業(yè)務(wù)流程的 E2E 場景。
• 最上層的 GUI 測試通常利用探索式測試思維，以人工測試的方式發(fā)現(xiàn)盡可能多的潛在問題。
• 單元測試采用“分而治之”的思想，只對那些相對穩(wěn)定并且核心的服務(wù)和模塊開展全面的單元測試，而應(yīng)用層或者上層業(yè)務(wù)只會做少量的單元測試。

12 | 從0到1：你的第一個GUI自動化測試

第一，Selenium 1.0 的工作原理

1. 測試用例通過基于不同語言的 Client Libraries 向 Selenium RC Server 發(fā)送 Http 請求，要求與其建立連接。
2. 連接建立后，Selenium RC Server 的 Launcher 就會啟動瀏覽器或者重用之前已經(jīng)打開的瀏覽器，把 Selenium Core（JavaScript 函數(shù)的集合）加載到瀏覽器頁面當(dāng)中，并同時把瀏覽器的代理設(shè)置為 Http Proxy。
3. 測試用例通過 Client Libraries 向 Selenium RC Server 發(fā)送 Http 請求，Selenium RC Server 解析請求，然后通過 Http Proxy 發(fā)送 JavaScript 命令通知 Selenium Core 執(zhí)行瀏覽器上控件的具體操作。
4. Selenium Core 接收到指令后，執(zhí)行操作。
5. 如果瀏覽器收到新的頁面請求信息，則會發(fā)送 Http 請求來請求新的 Web 頁面。由于 Launcher 在啟動瀏覽器時把 Http Proxy 設(shè)置成為了瀏覽器的代理，所以 Selenium RC Server 會接收到所有由它啟動的瀏覽器發(fā)送的請求。
6. Selenium RC Server 接收到瀏覽器發(fā)送的 Http 請求后，重組 Http 請求以規(guī)避“同源策略”，然后獲取對應(yīng)的 Web 頁面。
7. Http Proxy 把接收的 Web 頁面返回給瀏覽器，瀏覽器對接收的頁面進(jìn)行渲染。

第二，Selenium 2.0 的工作原理

1. 當(dāng)使用 Selenium2.0 啟動瀏覽器 Web Browser 時，后臺會同時啟動基于 WebDriver Wire 協(xié)議的 Web Service 作為 Selenium 的 Remote Server，并將其與瀏覽器綁定。綁定完成后，Remote Server 就開始監(jiān)聽 Client 端的操作請求。
2. 執(zhí)行測試時，測試用例會作為 Client 端，將需要執(zhí)行的頁面操作請求以 Http Request 的方式發(fā)送給 Remote Server。該 HTTP Request 的 body，是以 WebDriver Wire 協(xié)議規(guī)定的 JSON 格式來描述需要瀏覽器執(zhí)行的具體操作。
3. Remote Server 接收到請求后，會對請求進(jìn)行解析，并將解析結(jié)果發(fā)給 WebDriver，由 WebDriver 實際執(zhí)行瀏覽器的操作。
4. WebDriver 可以看做是直接操作瀏覽器的原生組件（Native Component），所以搭建測試環(huán)境時，通常都需要先下載瀏覽器對應(yīng)的 WebDriver。

13 | 效率為王：腳本與數(shù)據(jù)的解耦 + Page Object模型

“測試腳本和數(shù)據(jù)解耦”的本質(zhì)是實現(xiàn)了數(shù)據(jù)驅(qū)動的測試，讓操作相同但是數(shù)據(jù)不同的測試可以通過同一套自動化測試腳本來實現(xiàn)，只是在每次測試執(zhí)行時提供不同的測試輸入數(shù)據(jù)。

“頁面對象模型”的核心理念是，以頁面為單位來封裝頁面上的控件以及控件的部分操作。而測試用例使用頁面對象來完成具體的界面操作。

16 | 腦洞大開：GUI測試還能這么玩（Page Code Gen + Data Gen + Headless）？

頁面對象模型，是以 Web 頁面為單位來封裝頁面上的控件以及控件的部分操作，而測試用例基于頁面對象完成具體操作。最典型的模式就是：XXXPage.YYYComponent.ZZZOperation。

1. 對于頁面對象自動生成，商用測試軟件已經(jīng)實現(xiàn)了這個功能。但是，如果你選擇開源測試框架，就需要自己實現(xiàn)這個功能了。
2. GUI 測試數(shù)據(jù)自動生成，主要是基于測試輸入數(shù)據(jù)的類型以及對應(yīng)的自定義規(guī)則庫實現(xiàn)的，并且對于多個測試輸入數(shù)據(jù)，可以基于笛卡爾積來自動組合出完整的測試用例集合。
3. 對于無頭瀏覽器，你可以把它簡單地想象成運(yùn)行在內(nèi)存中的瀏覽器，它擁有完整的瀏覽器內(nèi)核。與普通瀏覽器最大的不同是，它在執(zhí)行過程中看不到運(yùn)行的界面。目前，Headless Chrome 結(jié)合 Puppeteer 是最先進(jìn)的無頭瀏覽器方案，如果感興趣，你可以下載試用。

17丨精益求精：聊聊提高GUI測試穩(wěn)定性的關(guān)鍵技術(shù)

1. 對于非預(yù)計的彈出對話框引起的不穩(wěn)定，可以引入“異常場景恢復(fù)模式”來解決。
2. 對于頁面控件屬性的細(xì)微變化造成的不穩(wěn)定，可以使用“組合屬性”定位控件，并且可以通過“模糊匹配技術(shù)”提高定位識別率。
3. 對于 A/B 測試帶來的不穩(wěn)定，需要在測試用例腳本中做分支處理，并且需要腳本做到正確識別出不同的分支。
4. 對于隨機(jī)的頁面延遲造成的不穩(wěn)定，可以引入重試機(jī)制，重試可以是步驟級別的，也可以是頁面級別的，甚至是業(yè)務(wù)流程級別的。
5. 對于測試數(shù)據(jù)引起的不穩(wěn)定，我在這里沒有詳細(xì)展開，留到后續(xù)的測試數(shù)據(jù)準(zhǔn)備系列文章中做專門介紹。

25 | 不破不立：掌握代碼級測試的基本理念與方法

代碼級測試的測試方法一定是一套測試方法的集合，而不是一個測試方法。

代碼級測試方法主要分為兩大類，分別是靜態(tài)方法和動態(tài)方法。靜態(tài)方法，顧名思義就是在不實際執(zhí)行代碼的基礎(chǔ)上發(fā)現(xiàn)代碼缺陷的方法，又可以進(jìn)一步細(xì)分為人工靜態(tài)方法和自動靜態(tài)方法；動態(tài)方法是指，通過實際執(zhí)行代碼發(fā)現(xiàn)代碼中潛在缺陷的方法，同樣可以進(jìn)一步細(xì)分為人工動態(tài)方法和自動動態(tài)方法。

人工靜態(tài)方法，本質(zhì)上通過開發(fā)人員代碼走查、結(jié)對編程、同行評審來完成的，理論上可以發(fā)現(xiàn)所有的代碼錯誤，但也因為其對“測試人員”的過渡依賴，局限性非常大；自動靜態(tài)方法，主要的手段是代碼靜態(tài)掃描，可以發(fā)現(xiàn)語法特征錯誤、邊界行為特征錯誤和經(jīng)驗特征錯誤這三類“有特征”的錯誤；人工動態(tài)方法，就是傳統(tǒng)意義上的單元測試，是發(fā)現(xiàn)算法錯誤和部分算法錯誤的最佳方式；自動動態(tài)方法，其實就是自動化的邊界測試，主要覆蓋邊界行為特征錯誤。

無非就是用驅(qū)動代碼去調(diào)用被測函數(shù)，并根據(jù)代碼的功能邏輯選擇必要的輸入數(shù)據(jù)的組合，然后驗證執(zhí)行被測函數(shù)后得到的結(jié)果是否符合預(yù)期。

28 | 帶你一起解讀不同視角的軟件性能與性能指標(biāo)

對于不同類型的系統(tǒng)，軟件性能的關(guān)注點各不相同，比如：Web 類應(yīng)用和手機(jī)端應(yīng)用，一般以終端用戶感受到的端到端的響應(yīng)時間來描述系統(tǒng)的性能；非交互式的應(yīng)用，比如典型的電信和銀行后臺處理系統(tǒng)，響應(yīng)時間關(guān)注更多的是事件處理的速度，以及單位時間的事件吞吐量。

一個優(yōu)秀的性能測試工程師，一般需要具有以下技能：性能需求的總結(jié)和抽象能力；根據(jù)性能測試目標(biāo)，精準(zhǔn)的性能測試場景設(shè)計和計算能力；性能測試場景和性能測試腳本的開發(fā)和執(zhí)行能力；測試性能報告的分析解讀能力；性能瓶頸的快速排查和定位能力；性能測試數(shù)據(jù)的設(shè)計和實現(xiàn)能力；面對互聯(lián)網(wǎng)產(chǎn)品，全鏈路壓測的設(shè)計與執(zhí)行能力，能夠和系統(tǒng)架構(gòu)師一起處理流量標(biāo)記、影子數(shù)據(jù)庫等的技術(shù)設(shè)計能力；深入理解性能測試工具的內(nèi)部實現(xiàn)原理，當(dāng)性能測試工具有限制時，可以進(jìn)行擴(kuò)展二次開發(fā)；極其寬廣的知識面，既要有“面”的知識，比如系統(tǒng)架構(gòu)、存儲架構(gòu)、網(wǎng)絡(luò)架構(gòu)等全局的知識，還要有大量“點”的知識積累，比如數(shù)據(jù)庫 SQL 語句的執(zhí)行計劃調(diào)優(yōu)、JVM 垃圾回收（GC）機(jī)制、多線程常見問題等等。

目前，獲取用戶行為模式的方法，主要分為兩種：
對于已經(jīng)上線的系統(tǒng)來說，往往采用系統(tǒng)日志分析法獲取用戶行為統(tǒng)計和峰值并發(fā)量等重要信息；而對于未上線的全新系統(tǒng)來說，通常的做法是參考行業(yè)中類似系統(tǒng)的統(tǒng)計信息來建模，然后分析。

29 | 聊聊性能測試的基本方法與應(yīng)用領(lǐng)域

當(dāng)系統(tǒng)并發(fā)用戶數(shù)較少時，系統(tǒng)的吞吐量也低，系統(tǒng)處于空閑狀態(tài)，我們往往把這個階段稱為 “空閑區(qū)間”。

當(dāng)系統(tǒng)整體負(fù)載并不是很大時，隨著系統(tǒng)并發(fā)用戶數(shù)的增長，系統(tǒng)的吞吐量也會隨之呈線性增長，我們往往把這個階段稱為 “線性增長區(qū)間”。

隨著系統(tǒng)并發(fā)用戶數(shù)的進(jìn)一步增長，系統(tǒng)的處理能力逐漸趨于飽和，因此每個用戶的響應(yīng)時間會逐漸變長。相應(yīng)地，系統(tǒng)的整體吞吐量并不會隨著并發(fā)用戶數(shù)的增長而繼續(xù)呈線性增長。我們往往把這個階段稱為系統(tǒng)的“拐點”。

隨著系統(tǒng)并發(fā)用戶數(shù)的增長，系統(tǒng)處理能力達(dá)到過飽和狀態(tài)。此時，如果繼續(xù)增加并發(fā)用戶數(shù)，最終所有用戶的響應(yīng)時間會變得無限長。相應(yīng)地，系統(tǒng)的整體吞吐量會降為零，系統(tǒng)處于被壓垮的狀態(tài)。我們往往把這個階段稱為“過飽和區(qū)間”。
30 | 工欲善其事必先利其器：后端性能測試工具原理與行業(yè)常用工具簡介
完整的后端性能測試應(yīng)該包括性能需求獲取、性能場景設(shè)計、性能測試腳本開發(fā)、性能場景實現(xiàn)、性能測試執(zhí)行、性能結(jié)果報告分析、性能優(yōu)化和再驗證。

33 | 無實例無真相：基于LoadRunner實現(xiàn)企業(yè)級服務(wù)器端性能測試的實踐（下）

驗證腳本的正確性

以單用戶的方式，在有思考時間的情況下執(zhí)行腳本，確保腳本能夠順利執(zhí)行，并且驗證腳本行為以及執(zhí)行結(jié)果是否正確；

以單用戶的方式，在思考時間為零的情況下執(zhí)行腳本，確保腳本能夠順利執(zhí)行，并且驗證腳本行為以及執(zhí)行結(jié)果是否正確；

以并發(fā)用戶的方式，在有思考時間的情況下執(zhí)行腳本，確保腳本能夠順利執(zhí)行，并且驗證腳本行為以及執(zhí)行結(jié)果是否正確；

以并發(fā)用戶的方式，在思考時間為零的情況下執(zhí)行腳本，確保腳本能夠順利執(zhí)行，并且驗證腳本行為以及執(zhí)行結(jié)果是否正確。

34 | 站在巨人的肩膀：企業(yè)級實際性能測試案例與經(jīng)驗分享

性能基準(zhǔn)測試；穩(wěn)定性測試；并發(fā)測試；容量規(guī)劃測試。
性能基準(zhǔn)測試，可以保證新發(fā)布系統(tǒng)的整體性能不會下降；穩(wěn)定性測試，主要通過長時間模擬被測系統(tǒng)的測試負(fù)載，觀察系統(tǒng)在長期運(yùn)行過程是否存在問題；并發(fā)測試，往往被當(dāng)作功能測試的補(bǔ)充去發(fā)現(xiàn)多線程、資源競爭、資源死鎖之類的問題。容量規(guī)劃測試，主要用于確定給定負(fù)載下的系統(tǒng)集群規(guī)模，其測試結(jié)果可以被用作系統(tǒng)容量設(shè)計的依據(jù)。