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

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

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

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

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

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

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

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

第三步实苞，成為互聯(lián)網(wǎng)時(shí)代的測試架構(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(shí)候磨确、因地制宜地把它們應(yīng)用到實(shí)際項(xiàng)目中沽甥。

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

功能測試用例：

基本

1. 輸入已注冊的用戶名和正確的密碼乏奥，驗(yàn)證是否登錄成功摆舟；

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

3. 輸入未注冊的用戶名和任意密碼媳瞪，驗(yàn)證是否登錄失敗，并且提示信息正確照宝；

4. 用戶名和密碼兩者都為空蛇受，驗(yàn)證是否登錄失敗，并且提示信息正確厕鹃；

5. 用戶名和密碼兩者之一為空兢仰，驗(yàn)證是否登錄失敗，并且提示信息正確剂碴；

6. 如果登錄功能啟用了驗(yàn)證碼功能把将，在用戶名和密碼正確的前提下，輸入正確的驗(yàn)證碼忆矛，驗(yàn)證是否登錄成功察蹲；

7. 如果登錄功能啟用了驗(yàn)證碼功能，在用戶名和密碼正確的前提下催训，輸入錯(cuò)誤的驗(yàn)證碼递览，驗(yàn)證是否登錄失敗，并且提示信息正確瞳腌。

高級

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

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

安全性測試用例：

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

性能壓力測試用例:

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

兼容性測試用例：

1. 不同瀏覽器下，驗(yàn)證登錄頁面的顯示以及功能正確性凰兑；
2. 相同瀏覽器的不同版本下速妖，驗(yàn)證登錄頁面的顯示以及功能正確性；
3. 不同移動設(shè)備終端的不同瀏覽器下聪黎，驗(yàn)證登錄頁面的顯示以及功能正確性罕容；
4. 不同分辨率的界面下备恤，驗(yàn)證登錄頁面的顯示以及功能正確性。

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

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

總結(jié)

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

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

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

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

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

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

一個(gè)“好的”測試用例廊佩，必須具備以下三個(gè)特征。

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

做到了以上三點(diǎn)，就可以肯定測試是充分且完備的践剂，即做到了完整的測試需求覆蓋鬼譬。

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

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

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

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

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

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

總結(jié)

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

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

其次蓝厌，設(shè)計(jì)測試用例的方法有很多種玄叠，但綜合運(yùn)用等價(jià)類劃分古徒、邊界值分析和錯(cuò)誤推測方法，可以滿足絕大多數(shù)軟件測試用例設(shè)計(jì)的需求读恃。

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

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

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

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

04 | 為什么要做自動化測試？什么樣的項(xiàng)目適合做自動化測試嚎杨？

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

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

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

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

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

需求覆蓋率

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

代碼覆蓋率

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

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

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

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

07 | 如何高效填寫軟件缺陷報(bào)告饲握？

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

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

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

缺陷報(bào)告的每一部分內(nèi)容，都會因?yàn)槟康睦涫亍⒈憩F(xiàn)形式有各自的側(cè)重點(diǎn)，所以想要寫出一份高效的軟件缺陷報(bào)告惊科，需要對其組成有深入的理解拍摇。

08 | 以終為始，如何才能做好測試計(jì)劃馆截？

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

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

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

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

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

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

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

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

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

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

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

12 | 從0到1：你的第一個(gè)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í)把瀏覽器的代理設(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 在啟動瀏覽器時(shí)把 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 時(shí)跪但，后臺會同時(shí)啟動基于 WebDriver Wire 協(xié)議的 Web Service 作為 Selenium 的 Remote Server履羞，并將其與瀏覽器綁定。綁定完成后，Remote Server 就開始監(jiān)聽 Client 端的操作請求忆首。
2. 執(zhí)行測試時(shí)爱榔，測試用例會作為 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 實(shí)際執(zhí)行瀏覽器的操作揣钦。
4. WebDriver 可以看做是直接操作瀏覽器的原生組件（Native Component），所以搭建測試環(huán)境時(shí)漠酿，通常都需要先下載瀏覽器對應(yīng)的 WebDriver冯凹。

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

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

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

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

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

1. 對于頁面對象自動生成蒜绽，商用測試軟件已經(jīng)實(shí)現(xiàn)了這個(gè)功能。但是桶现，如果你選擇開源測試框架躲雅，就需要自己實(shí)現(xiàn)這個(gè)功能了。
2. GUI 測試數(shù)據(jù)自動生成骡和，主要是基于測試輸入數(shù)據(jù)的類型以及對應(yīng)的自定義規(guī)則庫實(shí)現(xiàn)的相赁，并且對于多個(gè)測試輸入數(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ù)計(jì)的彈出對話框引起的不穩(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 | 不破不立：掌握代碼級測試的基本理念與方法

代碼級測試的測試方法一定是一套測試方法的集合片仿，而不是一個(gè)測試方法。

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

人工靜態(tài)方法，本質(zhì)上通過開發(fā)人員代碼走查映跟、結(jié)對編程蓄拣、同行評審來完成的，理論上可以發(fā)現(xiàn)所有的代碼錯(cuò)誤努隙，但也因?yàn)槠鋵Α皽y試人員”的過渡依賴球恤，局限性非常大；自動靜態(tài)方法荸镊，主要的手段是代碼靜態(tài)掃描咽斧，可以發(fā)現(xiàn)語法特征錯(cuò)誤堪置、邊界行為特征錯(cuò)誤和經(jīng)驗(yàn)特征錯(cuò)誤這三類“有特征”的錯(cuò)誤；人工動態(tài)方法张惹，就是傳統(tǒng)意義上的單元測試舀锨，是發(fā)現(xiàn)算法錯(cuò)誤和部分算法錯(cuò)誤的最佳方式；自動動態(tài)方法宛逗，其實(shí)就是自動化的邊界測試坎匿，主要覆蓋邊界行為特征錯(cuò)誤。

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

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

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

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

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

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

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

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

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

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

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

驗(yàn)證腳本的正確性

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

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

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

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

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

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