開篇詞 | 從“小工”到“專家”堡纬，我的軟件測(cè)試修煉之道
隨著自動(dòng)化測(cè)試用例設(shè)計(jì)與開發(fā)乖订、測(cè)試框架選型板壮、測(cè)試框架自行研發(fā)斥难、測(cè)試基礎(chǔ)架構(gòu)設(shè)計(jì)以及最新的測(cè)試服務(wù)化（Test as a Service枝嘶，TaaS）等一系列技術(shù)的變革與發(fā)展，測(cè)試項(xiàng)目幾乎涵蓋了所有種類哑诊，包括嵌入式系統(tǒng)測(cè)試群扶、金融平臺(tái)單元測(cè)試、平臺(tái) SDK 測(cè)試镀裤、軌道交通安全軟件測(cè)試竞阐、Web Service 測(cè)試、大型電商網(wǎng)站 GUI 自動(dòng)化以及性能全鏈路壓測(cè)等暑劝。
第一步骆莹，成為互聯(lián)網(wǎng)時(shí)代合格的測(cè)試工程師。
你必須具有快速學(xué)習(xí)的能力铃岔，能迅速掌握被測(cè)軟件的業(yè)務(wù)功能與內(nèi)部架構(gòu)汪疮，并在此基礎(chǔ)上運(yùn)用各種測(cè)試方法，盡可能多地發(fā)現(xiàn)潛在缺陷毁习，并能夠在已知缺陷的基礎(chǔ)上進(jìn)一步發(fā)現(xiàn)相關(guān)的連帶缺陷智嚷。
從知識(shí)體系上看，你需要有比開發(fā)人員更全面的計(jì)算機(jī)基礎(chǔ)知識(shí)纺且，還需要了解互聯(lián)網(wǎng)的基礎(chǔ)架構(gòu)盏道、安全攻擊、軟件性能载碌、用戶體驗(yàn)和常見缺陷等知識(shí)猜嘱。
從測(cè)試技術(shù)上看，你需要能夠使用常見的測(cè)試框架或者工具嫁艇，需要具有一定的自動(dòng)化測(cè)試腳本的開發(fā)能力朗伶，這可以把你從大量重復(fù)的工作中解放出來，然后你才能有時(shí)間去做更有意思的工作步咪。
第二步论皆，成為互聯(lián)網(wǎng)時(shí)代優(yōu)秀的測(cè)試工程師。
首先猾漫，合格的測(cè)試工程師關(guān)注的是純粹的測(cè)試点晴，而優(yōu)秀的測(cè)試工程師關(guān)注更多的是軟件整體的質(zhì)量，需要根據(jù)業(yè)務(wù)風(fēng)險(xiǎn)以及影響來制定測(cè)試策略悯周，有效控制測(cè)試的時(shí)間和成本粒督，并且能夠?qū)y(cè)試框架以及工具做出適合項(xiàng)目需求的選型。
第三步禽翼，成為互聯(lián)網(wǎng)時(shí)代的測(cè)試架構(gòu)師屠橄。
面對(duì)大量測(cè)試用例的執(zhí)行，無論是 GUI 還是 API闰挡，都需要一套高效的能夠支持高并發(fā)的測(cè)試執(zhí)行基礎(chǔ)架構(gòu)；再比如解总，面對(duì)測(cè)試過程中的大量差異性數(shù)據(jù)要求贮匕，需要統(tǒng)一的測(cè)試數(shù)據(jù)準(zhǔn)備平臺(tái)；再比如花枫，為了可以更方便地和持續(xù)集成與發(fā)布系統(tǒng)（CI/CD）以解耦的形式做集成刻盐，需要統(tǒng)一發(fā)起測(cè)試執(zhí)行的接口。
這樣的例子還有很多劳翰，如果你已經(jīng)能夠站在這樣的高度看待軟件測(cè)試敦锌，那么恭喜你，你已經(jīng)具備了測(cè)試架構(gòu)師的視野佳簸。當(dāng)然乙墙，你還必須對(duì)一些前沿的測(cè)試方法和技術(shù)有自己的理解颖变，并能夠在恰當(dāng)?shù)臅r(shí)候、因地制宜地把它們應(yīng)用到實(shí)際項(xiàng)目中听想。
01 | 你真的懂測(cè)試嗎腥刹？從“用戶登錄”測(cè)試談起
功能測(cè)試用例：
基本
輸入已注冊(cè)的用戶名和正確的密碼，驗(yàn)證是否登錄成功汉买；
輸入已注冊(cè)的用戶名和不正確的密碼衔峰，驗(yàn)證是否登錄失敗，并且提示信息正確蛙粘；
輸入未注冊(cè)的用戶名和任意密碼垫卤，驗(yàn)證是否登錄失敗，并且提示信息正確出牧；
用戶名和密碼兩者都為空穴肘，驗(yàn)證是否登錄失敗，并且提示信息正確舔痕；
用戶名和密碼兩者之一為空梢褐，驗(yàn)證是否登錄失敗，并且提示信息正確赵讯；
如果登錄功能啟用了驗(yàn)證碼功能盈咳，在用戶名和密碼正確的前提下，輸入正確的驗(yàn)證碼边翼，驗(yàn)證是否登錄成功鱼响；
如果登錄功能啟用了驗(yàn)證碼功能，在用戶名和密碼正確的前提下组底，輸入錯(cuò)誤的驗(yàn)證碼丈积，驗(yàn)證是否登錄失敗，并且提示信息正確债鸡。
高級(jí)
- 用戶名和密碼是否大小寫敏感朴肺；
- 頁面上的密碼框是否加密顯示断序；
- 后臺(tái)系統(tǒng)創(chuàng)建的用戶第一次登錄成功時(shí)，是否提示修改密碼；
- 忘記用戶名和忘記密碼的功能是否可用肋乍；
- 前端頁面是否根據(jù)設(shè)計(jì)要求限制用戶名和密碼長(zhǎng)度秸脱；
- 如果登錄功能需要驗(yàn)證碼帆啃，點(diǎn)擊驗(yàn)證碼圖片是否可以更換驗(yàn)證碼鱼喉，更換后的驗(yàn)證碼是否可用；
- 刷新頁面是否會(huì)刷新驗(yàn)證碼模她；
- 如果驗(yàn)證碼具有時(shí)效性稻艰，需要分別驗(yàn)證時(shí)效內(nèi)和時(shí)效外驗(yàn)證碼的有效性；
- 用戶登錄成功但是會(huì)話超時(shí)后侈净，繼續(xù)操作是否會(huì)重定向到用戶登錄界面尊勿；
- 不同級(jí)別的用戶僧凤，比如管理員用戶和普通用戶，登錄系統(tǒng)后的權(quán)限是否正確元扔；
- 頁面默認(rèn)焦點(diǎn)是否定位在用戶名的輸入框中躯保；
- 快捷鍵 Tab 和 Enter 等，是否可以正常使用摇展。
一個(gè)質(zhì)量過硬的軟件系統(tǒng)吻氧，除了顯式功能性需求以外溺忧，其他的非功能性需求即隱式功能性需求也是極其關(guān)鍵的咏连。
安全性測(cè)試用例：
- 用戶密碼后臺(tái)存儲(chǔ)是否加密；
- 用戶密碼在網(wǎng)絡(luò)傳輸過程中是否加密鲁森；
- 密碼是否具有有效期祟滴，密碼有效期到期后，是否提示需要修改密碼歌溉；
- 不登錄的情況下垄懂，在瀏覽器中直接輸入登錄后的 URL 地址，驗(yàn)證是否會(huì)重新定向到用戶登錄界面痛垛；
- 密碼輸入框是否不支持復(fù)制和粘貼草慧；
- 密碼輸入框內(nèi)輸入的密碼是否都可以在頁面源碼模式下被查看；
- 用戶名和密碼的輸入框中分別輸入典型的“SQL 注入攻擊”字符串匙头，驗(yàn)證系統(tǒng)的返回頁面漫谷；
- 用戶名和密碼的輸入框中分別輸入典型的“XSS 跨站腳本攻擊”字符串，驗(yàn)證系統(tǒng)行為是否被篡改蹂析；
- 連續(xù)多次登錄失敗情況下舔示，系統(tǒng)是否會(huì)阻止后續(xù)的嘗試以應(yīng)對(duì)暴力破解；
- 同一用戶在同一終端的多種瀏覽器上登錄电抚，驗(yàn)證登錄功能的互斥性是否符合設(shè)計(jì)預(yù)期惕稻；
- 同一用戶先后在多臺(tái)終端的瀏覽器上登錄，驗(yàn)證登錄是否具有互斥性蝙叛。
性能壓力測(cè)試用例:
- 單用戶登錄的響應(yīng)時(shí)間是否小于 3 秒俺祠；
- 單用戶登錄時(shí)，后臺(tái)請(qǐng)求數(shù)量是否過多借帘；
- 高并發(fā)場(chǎng)景下用戶登錄的響應(yīng)時(shí)間是否小于 5 秒锻煌；
- 高并發(fā)場(chǎng)景下服務(wù)端的監(jiān)控指標(biāo)是否符合預(yù)期；
- 高集合點(diǎn)并發(fā)場(chǎng)景下姻蚓，是否存在資源死鎖和不合理的資源等待宋梧；
- 長(zhǎng)時(shí)間大量用戶連續(xù)登錄和登出，服務(wù)器端是否存在內(nèi)存泄漏狰挡。
兼容性測(cè)試用例：
- 不同瀏覽器下捂龄，驗(yàn)證登錄頁面的顯示以及功能正確性释涛；
- 相同瀏覽器的不同版本下，驗(yàn)證登錄頁面的顯示以及功能正確性倦沧；
- 不同移動(dòng)設(shè)備終端的不同瀏覽器下唇撬，驗(yàn)證登錄頁面的顯示以及功能正確性；
- 不同分辨率的界面下展融，驗(yàn)證登錄頁面的顯示以及功能正確性窖认。
一個(gè)優(yōu)秀的測(cè)試工程師必須具有很寬廣的知識(shí)面，如果你不能對(duì)被測(cè)系統(tǒng)的設(shè)計(jì)有深入的理解告希、不明白安全攻擊的基本原理扑浸、沒有掌握性能測(cè)試的基本設(shè)計(jì)方法，很難設(shè)計(jì)出“有的放矢”的測(cè)試用例燕偶。
在絕大多數(shù)的軟件工程實(shí)踐中喝噪，測(cè)試由于受限于時(shí)間成本和經(jīng)濟(jì)成本，是不可能去窮盡所有可能的組合的指么，而是采用基于風(fēng)險(xiǎn)驅(qū)動(dòng)的模式酝惧，有所側(cè)重地選擇測(cè)試范圍和設(shè)計(jì)測(cè)試用例，以尋求缺陷風(fēng)險(xiǎn)和研發(fā)成本之間的平衡伯诬。
總結(jié)
首先晚唇，對(duì)于高質(zhì)量的軟件測(cè)試，用例設(shè)計(jì)不僅需要考慮明確的顯式功能性需求盗似，還要涉及兼容性哩陕、安全性和性能等一系列的非功能性需求，這些非功能性需求對(duì)軟件系統(tǒng)的質(zhì)量有著舉足輕重的作用桥言。
其次萌踱，優(yōu)秀的測(cè)試工程師必須具有寬廣的知識(shí)面，才能設(shè)計(jì)出有針對(duì)性号阿、更易于發(fā)現(xiàn)問題的測(cè)試用例并鸵。
最后，軟件測(cè)試的用例設(shè)計(jì)是不可窮盡的扔涧，工程實(shí)踐中難免受制于時(shí)間成本和經(jīng)濟(jì)成本园担，所以優(yōu)秀的測(cè)試工程師需要兼顧缺陷風(fēng)險(xiǎn)和研發(fā)成本之間的平衡。
02 | 如何設(shè)計(jì)一個(gè)“好的”測(cè)試用例枯夜？
“好的”測(cè)試用例一定是一個(gè)完備的集合弯汰，它能夠覆蓋所有等價(jià)類以及各種邊界值，而跟能否發(fā)現(xiàn)缺陷無關(guān)湖雹。
“好的”測(cè)試用例必須具備哪些特征咏闪？
一個(gè)“好的”測(cè)試用例，必須具備以下三個(gè)特征摔吏。
- 整體完備性： “好的”測(cè)試用例一定是一個(gè)完備的整體鸽嫂，是有效測(cè)試用例組成的集合纵装，能夠完全覆蓋測(cè)試需求。
- 等價(jià)類劃分的準(zhǔn)確性： 指的是對(duì)于每個(gè)等價(jià)類都能保證只要其中一個(gè)輸入測(cè)試通過据某，其他輸入也一定測(cè)試通過橡娄。
- 等價(jià)類集合的完備性： 需要保證所有可能的邊界值和邊界條件都已經(jīng)正確識(shí)別。
做到了以上三點(diǎn)癣籽，就可以肯定測(cè)試是充分且完備的挽唉，即做到了完整的測(cè)試需求覆蓋。
對(duì)大多數(shù)的軟件測(cè)試而言筷狼，綜合使用等價(jià)類劃分瓶籽、邊界值分析和錯(cuò)誤推測(cè)這三大類方法就足夠了。
具體到測(cè)試用例本身的設(shè)計(jì)桑逝，有兩個(gè)關(guān)鍵點(diǎn)需要你注意棘劣。
- 從軟件功能需求出發(fā)俏让，全面地楞遏、無遺漏地識(shí)別出測(cè)試需求是至關(guān)重要的，這將直接關(guān)系到用例的測(cè)試覆蓋率首昔。 比如寡喝，如果你沒有識(shí)別出用戶登錄功能的安全性測(cè)試需求，那么后續(xù)設(shè)計(jì)的測(cè)試用例就完全不會(huì)涉及安全性勒奇，最終造成重要測(cè)試漏洞预鬓。
-
對(duì)于識(shí)別出的每個(gè)測(cè)試需求點(diǎn)，需要綜合運(yùn)用等價(jià)類劃分赊颠、邊界值分析和錯(cuò)誤推測(cè)方法來全面地設(shè)計(jì)測(cè)試用例格二。 這里需要注意的是，要綜合運(yùn)用這三種方法竣蹦，并針對(duì)每個(gè)測(cè)試需求點(diǎn)的具體情況顶猜，進(jìn)行靈活選擇。
以“用戶登錄”的功能性測(cè)試需求為例痘括，你首先應(yīng)該對(duì)“用戶名”和“密碼”這兩個(gè)輸入項(xiàng)分別進(jìn)行等價(jià)類劃分长窄，列出對(duì)應(yīng)的有效等價(jià)類和無效等價(jià)類，對(duì)于無效等價(jià)類的識(shí)別可以采用錯(cuò)誤猜測(cè)法（比如纲菌，用戶名包含特殊字符等）挠日，然后基于兩者可能的組合，設(shè)計(jì)出第一批測(cè)試用例翰舌。
等價(jià)類劃分完后嚣潜，你需要補(bǔ)充“用戶名”和“密碼”這兩個(gè)輸入項(xiàng)的邊界值的測(cè)試用例，比如用戶名為空（NULL）椅贱、用戶名長(zhǎng)度剛剛大于允許長(zhǎng)度等懂算。
用例設(shè)計(jì)的其他經(jīng)驗(yàn)
除了上面介紹的方法外唉韭，我再跟你分享三個(gè)獨(dú)家“秘籍”，希望能夠幫你設(shè)計(jì)出“好的”測(cè)試用例集犯犁。
-
只有深入理解被測(cè)試軟件的架構(gòu)属愤，你才能設(shè)計(jì)出“有的放矢”的測(cè)試用例集，去發(fā)現(xiàn)系統(tǒng)邊界以及系統(tǒng)集成上的潛在缺陷酸役。
作為測(cè)試工程師住诸，切忌不能把整個(gè)被測(cè)系統(tǒng)看作一個(gè)大黑盒，你必須對(duì)內(nèi)部的架構(gòu)有清楚的認(rèn)識(shí)涣澡，比如數(shù)據(jù)庫(kù)連接方式贱呐、數(shù)據(jù)庫(kù)的讀寫分離、消息中間件 Kafka 的配置入桂、緩存系統(tǒng)的層級(jí)分布奄薇、第三方系統(tǒng)的集成等等。 -
必須深入理解被測(cè)軟件的設(shè)計(jì)與實(shí)現(xiàn)細(xì)節(jié)抗愁，深入理解軟件內(nèi)部的處理邏輯馁蒂。
單單根據(jù)測(cè)試需求點(diǎn)設(shè)計(jì)的用例，只能覆蓋“表面”的一層蜘腌，往往會(huì)覆蓋不到內(nèi)部的處理流程沫屡、分支處理，而沒有覆蓋到的部分就很可能出現(xiàn)缺陷遺漏撮珠。在具體實(shí)踐中沮脖，你可以通過代碼覆蓋率指標(biāo)找出可能的測(cè)試遺漏點(diǎn)。
同時(shí)芯急，切忌不要以開發(fā)代碼的實(shí)現(xiàn)為依據(jù)設(shè)計(jì)測(cè)試用例勺届。因?yàn)殚_發(fā)代碼實(shí)現(xiàn)的錯(cuò)誤會(huì)導(dǎo)致測(cè)試用例也出錯(cuò)，所以你應(yīng)該根據(jù)原始需求設(shè)計(jì)測(cè)試用例娶耍。 - 需要引入需求覆蓋率和代碼覆蓋率來衡量測(cè)試執(zhí)行的完備性免姿，并以此為依據(jù)來找出遺漏的測(cè)試點(diǎn)。 關(guān)于什么是需求覆蓋率和代碼覆蓋率伺绽，我會(huì)在后續(xù)的文章中詳細(xì)介紹养泡。
總結(jié)
最后，我來簡(jiǎn)單總結(jié)一下今天的主要內(nèi)容奈应。
首先澜掩，你需要明白，“好的”測(cè)試用例一定是一個(gè)完備的集合杖挣，它能夠覆蓋所有等價(jià)類以及各種邊界值肩榕，而能否發(fā)現(xiàn)軟件缺陷并不是衡量測(cè)試用例好壞的標(biāo)準(zhǔn)。
其次，設(shè)計(jì)測(cè)試用例的方法有很多種株汉，但綜合運(yùn)用等價(jià)類劃分筐乳、邊界值分析和錯(cuò)誤推測(cè)方法，可以滿足絕大多數(shù)軟件測(cè)試用例設(shè)計(jì)的需求乔妈。
再次蝙云，“好的”測(cè)試用例在設(shè)計(jì)時(shí)，需要從軟件功能需求出發(fā)路召，全面地勃刨、無遺漏地識(shí)別出測(cè)試需求至關(guān)重要。
最后股淡，如果想設(shè)計(jì)一個(gè)“好的”測(cè)試用例身隐，你必須要深入理解被測(cè)軟件的架構(gòu)設(shè)計(jì)，深入軟件內(nèi)部的處理邏輯唯灵，需求覆蓋率和代碼覆蓋率這兩個(gè)指標(biāo)可以幫你衡量測(cè)試執(zhí)行的完備性贾铝。
03 | 什么是單元測(cè)試？如何做好單元測(cè)試埠帕？
- 代碼要做到功能邏輯正確垢揩，必須做到分類正確并且完備無遺漏，同時(shí)每個(gè)分類的處理邏輯必須正確搞监；
- 單元測(cè)試是對(duì)軟件中的最小可測(cè)試單元在與軟件其他部分相隔離的情況下進(jìn)行的代碼級(jí)測(cè)試水孩；
- 樁代碼起到了隔離和補(bǔ)齊的作用镰矿，使被測(cè)代碼能夠獨(dú)立編譯琐驴、鏈接，并運(yùn)行秤标。
04 | 為什么要做自動(dòng)化測(cè)試绝淡？什么樣的項(xiàng)目適合做自動(dòng)化測(cè)試？
自動(dòng)化測(cè)試是苍姜，把人工對(duì)軟件的測(cè)試轉(zhuǎn)化為由機(jī)器執(zhí)行測(cè)試行為的一種實(shí)踐牢酵，可以把測(cè)試工程師從機(jī)械重復(fù)的測(cè)試工作中解脫出來，將更多的精力放在新功能的測(cè)試和更全面的測(cè)試用例設(shè)計(jì)上衙猪。
然而自動(dòng)化測(cè)試試一把“雙刃劍”馍乙，雖然它可以從一定程度上解放測(cè)試工程師的勞動(dòng)力，完成一些人工無法實(shí)現(xiàn)的測(cè)試垫释，但并不適用于所有的測(cè)試場(chǎng)景丝格，如果維護(hù)自動(dòng)化測(cè)試的代價(jià)高過了節(jié)省的測(cè)試成本，那么在這樣的項(xiàng)目中推進(jìn)自動(dòng)化測(cè)試就會(huì)得不償失棵譬。
06 | 你真的懂測(cè)試覆蓋率嗎显蝌？
這章以后要多看幾遍，了解的還是有很大的欠缺 订咸。
測(cè)試覆蓋率通常被用來衡量測(cè)試的充分性和完整性曼尊，從廣義的角度來講酬诀，測(cè)試覆蓋率主要分為兩大類，一類是面向項(xiàng)目的需求覆蓋率骆撇，另一類是更偏向技術(shù)的代碼覆蓋率瞒御。
需求覆蓋率
需求覆蓋率是指測(cè)試對(duì)需求的覆蓋程度，通常的做法是將每一條分解后的軟件需求和對(duì)應(yīng)的測(cè)試建立一對(duì)多的映射關(guān)系神郊，最終目標(biāo)是保證測(cè)試可以覆蓋每個(gè)需求葵腹，以保證軟件產(chǎn)品的質(zhì)量。
代碼覆蓋率
簡(jiǎn)單來說屿岂，代碼覆蓋率是指践宴，至少被執(zhí)行了一次的條目數(shù)占整個(gè)條目數(shù)的百分比。
測(cè)試覆蓋率通常被用來衡量測(cè)試的充分性和完整性爷怀，包括面向項(xiàng)目的需求覆蓋率和更偏向技術(shù)的代碼覆蓋率阻肩。而需求覆蓋率的統(tǒng)計(jì)方式不再適用于現(xiàn)在的敏捷開發(fā)模式，所以現(xiàn)在談到測(cè)試覆蓋率运授，大多是指代碼覆蓋率烤惊。
但是，高的代碼覆蓋率不一定能保證軟件的質(zhì)量吁朦，因?yàn)榇a覆蓋率是基于現(xiàn)有代碼柒室，無法發(fā)現(xiàn)那些“未考慮某些輸入”以及“未處理某些情況”形成的缺陷。
另外逗宜，對(duì)于代碼覆蓋率的統(tǒng)計(jì)工具雄右，我希望你不僅僅是會(huì)用的層次，而是能夠理解它們的原理纺讲，知其然知其所以然擂仍，才能更好地利用這些工具完成你的測(cè)試工作。
07 | 如何高效填寫軟件缺陷報(bào)告熬甚？
具體看文章比較好逢渔，講的很詳細(xì)。
缺陷報(bào)告是測(cè)試工程師與開發(fā)工程師交流溝通的重要橋梁乡括，也是測(cè)試工程師日常工作的重要輸出肃廓。
一份高效的軟件缺陷報(bào)告，應(yīng)該包括缺陷標(biāo)題诲泌、缺陷概述盲赊、缺陷影響、環(huán)境配置档礁、前置條件角钩、缺陷重現(xiàn)步驟、期望結(jié)果和實(shí)際結(jié)果、優(yōu)先級(jí)和嚴(yán)重程度递礼、變通方案惨险、根原因分析，以及附件這幾大部分脊髓。
缺陷報(bào)告的每一部分內(nèi)容辫愉，都會(huì)因?yàn)槟康摹⒈憩F(xiàn)形式有各自的側(cè)重點(diǎn)将硝，所以想要寫出一份高效的軟件缺陷報(bào)告恭朗，需要對(duì)其組成有深入的理解。
08 | 以終為始依疼，如何才能做好測(cè)試計(jì)劃痰腮？
需要的時(shí)候看原文，寫的很詳細(xì)律罢。
軟件測(cè)試同軟件項(xiàng)目一樣膀值，也要制定詳細(xì)的測(cè)試計(jì)劃。雖然在敏捷開發(fā)模式下误辑，軟件測(cè)試不再局限于厚重的沧踏、正式的計(jì)劃文檔，但是測(cè)試計(jì)劃的重要性絲毫沒有發(fā)生變化巾钉。
一份成功的測(cè)試計(jì)劃翘狱，必須清楚地描述：測(cè)試范圍、測(cè)試策略砰苍、測(cè)試資源潦匈、測(cè)試進(jìn)度和測(cè)試風(fēng)險(xiǎn)預(yù)估這五個(gè)最重要的方面。
測(cè)試范圍需要明確“測(cè)什么”和“不測(cè)什么”师骗；測(cè)試策略需要明確“先測(cè)什么后測(cè)什么”和“如何來測(cè)”历等；測(cè)試資源需要明確“誰來測(cè)”和“在哪里測(cè)”；測(cè)試進(jìn)度是需要明確各類測(cè)試的開始時(shí)間辟癌，所需工作量和預(yù)計(jì)完成時(shí)間；測(cè)試風(fēng)險(xiǎn)預(yù)估是需要明確如何有效應(yīng)對(duì)各種潛在的變化荐捻。
09 | 軟件測(cè)試工程師的核心競(jìng)爭(zhēng)力是什么黍少？
我把測(cè)試工程師按照工作內(nèi)容，分為了功能測(cè)試工程師（即傳統(tǒng)測(cè)試工程師）和測(cè)試開發(fā)工程師兩類处面，分別給你分享了他們的核心競(jìng)爭(zhēng)力厂置。
對(duì)于功能測(cè)試工程師來說，其核心競(jìng)爭(zhēng)力包括：測(cè)試策略設(shè)計(jì)能力魂角、測(cè)試用例設(shè)計(jì)能力昵济、快速學(xué)習(xí)能力、探索性測(cè)試思維、缺陷分析能力访忿、自動(dòng)化測(cè)試技術(shù)和良好的溝通能力這七大部分瞧栗，你可以有針對(duì)性地提升自己某方面的能力，去獲取更大發(fā)展空間的“敲門磚”海铆。
而對(duì)于測(cè)試開發(fā)工程師來說迹恐，你需要具備優(yōu)秀的測(cè)試系統(tǒng)需求分析能力和完備的知識(shí)體系，這樣才能保證你設(shè)計(jì)的測(cè)試工作和平臺(tái)卧斟，可以更好地滿足提升測(cè)試效率的要求殴边。
11 | 互聯(lián)網(wǎng)產(chǎn)品的測(cè)試策略應(yīng)該如何設(shè)計(jì)？
傳統(tǒng)軟件通常采用金字塔模型的測(cè)試策略珍语，而現(xiàn)今的互聯(lián)網(wǎng)產(chǎn)品往往采用菱形模型锤岸。菱形模型有以下四個(gè)關(guān)鍵點(diǎn)：
- 以中間層的 API 測(cè)試為重點(diǎn)做全面的測(cè)試。
- 輕量級(jí)的 GUI 測(cè)試板乙，只覆蓋最核心直接影響主營(yíng)業(yè)務(wù)流程的 E2E 場(chǎng)景能耻。
- 最上層的 GUI 測(cè)試通常利用探索式測(cè)試思維，以人工測(cè)試的方式發(fā)現(xiàn)盡可能多的潛在問題亡驰。
- 單元測(cè)試采用“分而治之”的思想晓猛，只對(duì)那些相對(duì)穩(wěn)定并且核心的服務(wù)和模塊開展全面的單元測(cè)試，而應(yīng)用層或者上層業(yè)務(wù)只會(huì)做少量的單元測(cè)試凡辱。
12 | 從0到1：你的第一個(gè)GUI自動(dòng)化測(cè)試
第一戒职，Selenium 1.0 的工作原理
- 測(cè)試用例通過基于不同語言的 Client Libraries 向 Selenium RC Server 發(fā)送 Http 請(qǐng)求，要求與其建立連接透乾。
- 連接建立后洪燥，Selenium RC Server 的 Launcher 就會(huì)啟動(dòng)瀏覽器或者重用之前已經(jīng)打開的瀏覽器，把 Selenium Core（JavaScript 函數(shù)的集合）加載到瀏覽器頁面當(dāng)中乳乌，并同時(shí)把瀏覽器的代理設(shè)置為 Http Proxy捧韵。
- 測(cè)試用例通過 Client Libraries 向 Selenium RC Server 發(fā)送 Http 請(qǐng)求，Selenium RC Server 解析請(qǐng)求汉操，然后通過 Http Proxy 發(fā)送 JavaScript 命令通知 Selenium Core 執(zhí)行瀏覽器上控件的具體操作再来。
- Selenium Core 接收到指令后，執(zhí)行操作磷瘤。
- 如果瀏覽器收到新的頁面請(qǐng)求信息芒篷，則會(huì)發(fā)送 Http 請(qǐng)求來請(qǐng)求新的 Web 頁面。由于 Launcher 在啟動(dòng)瀏覽器時(shí)把 Http Proxy 設(shè)置成為了瀏覽器的代理采缚，所以 Selenium RC Server 會(huì)接收到所有由它啟動(dòng)的瀏覽器發(fā)送的請(qǐng)求针炉。
- Selenium RC Server 接收到瀏覽器發(fā)送的 Http 請(qǐng)求后，重組 Http 請(qǐng)求以規(guī)避“同源策略”扳抽，然后獲取對(duì)應(yīng)的 Web 頁面篡帕。
- Http Proxy 把接收的 Web 頁面返回給瀏覽器殖侵，瀏覽器對(duì)接收的頁面進(jìn)行渲染。
第二镰烧，Selenium 2.0 的工作原理
- 當(dāng)使用 Selenium2.0 啟動(dòng)瀏覽器 Web Browser 時(shí)拢军，后臺(tái)會(huì)同時(shí)啟動(dòng)基于 WebDriver Wire 協(xié)議的 Web Service 作為 Selenium 的 Remote Server，并將其與瀏覽器綁定拌滋。綁定完成后朴沿，Remote Server 就開始監(jiān)聽 Client 端的操作請(qǐng)求。
- 執(zhí)行測(cè)試時(shí)败砂，測(cè)試用例會(huì)作為 Client 端赌渣，將需要執(zhí)行的頁面操作請(qǐng)求以 Http Request 的方式發(fā)送給 Remote Server。該 HTTP Request 的 body昌犹，是以 WebDriver Wire 協(xié)議規(guī)定的 JSON 格式來描述需要瀏覽器執(zhí)行的具體操作坚芜。
- Remote Server 接收到請(qǐng)求后，會(huì)對(duì)請(qǐng)求進(jìn)行解析斜姥，并將解析結(jié)果發(fā)給 WebDriver鸿竖，由 WebDriver 實(shí)際執(zhí)行瀏覽器的操作。
- WebDriver 可以看做是直接操作瀏覽器的原生組件（Native Component）铸敏，所以搭建測(cè)試環(huán)境時(shí)缚忧，通常都需要先下載瀏覽器對(duì)應(yīng)的 WebDriver。
13 | 效率為王：腳本與數(shù)據(jù)的解耦 + Page Object模型
“測(cè)試腳本和數(shù)據(jù)解耦”的本質(zhì)是實(shí)現(xiàn)了數(shù)據(jù)驅(qū)動(dòng)的測(cè)試杈笔，讓操作相同但是數(shù)據(jù)不同的測(cè)試可以通過同一套自動(dòng)化測(cè)試腳本來實(shí)現(xiàn)闪水，只是在每次測(cè)試執(zhí)行時(shí)提供不同的測(cè)試輸入數(shù)據(jù)。
“頁面對(duì)象模型”的核心理念是蒙具，以頁面為單位來封裝頁面上的控件以及控件的部分操作球榆。而測(cè)試用例使用頁面對(duì)象來完成具體的界面操作。
16 | 腦洞大開：GUI測(cè)試還能這么玩（Page Code Gen + Data Gen + Headless）禁筏？
頁面對(duì)象模型持钉，是以 Web 頁面為單位來封裝頁面上的控件以及控件的部分操作，而測(cè)試用例基于頁面對(duì)象完成具體操作篱昔。最典型的模式就是：XXXPage.YYYComponent.ZZZOperation每强。
- 對(duì)于頁面對(duì)象自動(dòng)生成，商用測(cè)試軟件已經(jīng)實(shí)現(xiàn)了這個(gè)功能旱爆。但是舀射，如果你選擇開源測(cè)試框架，就需要自己實(shí)現(xiàn)這個(gè)功能了怀伦。
- GUI 測(cè)試數(shù)據(jù)自動(dòng)生成，主要是基于測(cè)試輸入數(shù)據(jù)的類型以及對(duì)應(yīng)的自定義規(guī)則庫(kù)實(shí)現(xiàn)的山林，并且對(duì)于多個(gè)測(cè)試輸入數(shù)據(jù)房待，可以基于笛卡爾積來自動(dòng)組合出完整的測(cè)試用例集合邢羔。
- 對(duì)于無頭瀏覽器，你可以把它簡(jiǎn)單地想象成運(yùn)行在內(nèi)存中的瀏覽器桑孩，它擁有完整的瀏覽器內(nèi)核拜鹤。與普通瀏覽器最大的不同是，它在執(zhí)行過程中看不到運(yùn)行的界面流椒。目前敏簿，Headless Chrome 結(jié)合 Puppeteer 是最先進(jìn)的無頭瀏覽器方案，如果感興趣宣虾，你可以下載試用惯裕。
17丨精益求精：聊聊提高GUI測(cè)試穩(wěn)定性的關(guān)鍵技術(shù)
- 對(duì)于非預(yù)計(jì)的彈出對(duì)話框引起的不穩(wěn)定，可以引入“異常場(chǎng)景恢復(fù)模式”來解決绣硝。
- 對(duì)于頁面控件屬性的細(xì)微變化造成的不穩(wěn)定蜻势，可以使用“組合屬性”定位控件，并且可以通過“模糊匹配技術(shù)”提高定位識(shí)別率鹉胖。
- 對(duì)于 A/B 測(cè)試帶來的不穩(wěn)定握玛，需要在測(cè)試用例腳本中做分支處理，并且需要腳本做到正確識(shí)別出不同的分支甫菠。
- 對(duì)于隨機(jī)的頁面延遲造成的不穩(wěn)定挠铲，可以引入重試機(jī)制，重試可以是步驟級(jí)別的寂诱，也可以是頁面級(jí)別的拂苹，甚至是業(yè)務(wù)流程級(jí)別的。
- 對(duì)于測(cè)試數(shù)據(jù)引起的不穩(wěn)定刹衫，我在這里沒有詳細(xì)展開醋寝，留到后續(xù)的測(cè)試數(shù)據(jù)準(zhǔn)備系列文章中做專門介紹。
25 | 不破不立：掌握代碼級(jí)測(cè)試的基本理念與方法
代碼級(jí)測(cè)試的測(cè)試方法一定是一套測(cè)試方法的集合带迟，而不是一個(gè)測(cè)試方法音羞。
代碼級(jí)測(cè)試方法主要分為兩大類，分別是靜態(tài)方法和動(dòng)態(tài)方法仓犬。靜態(tài)方法嗅绰，顧名思義就是在不實(shí)際執(zhí)行代碼的基礎(chǔ)上發(fā)現(xiàn)代碼缺陷的方法，又可以進(jìn)一步細(xì)分為人工靜態(tài)方法和自動(dòng)靜態(tài)方法搀继；動(dòng)態(tài)方法是指窘面，通過實(shí)際執(zhí)行代碼發(fā)現(xiàn)代碼中潛在缺陷的方法，同樣可以進(jìn)一步細(xì)分為人工動(dòng)態(tài)方法和自動(dòng)動(dòng)態(tài)方法叽躯。
人工靜態(tài)方法财边，本質(zhì)上通過開發(fā)人員代碼走查、結(jié)對(duì)編程点骑、同行評(píng)審來完成的酣难，理論上可以發(fā)現(xiàn)所有的代碼錯(cuò)誤谍夭，但也因?yàn)槠鋵?duì)“測(cè)試人員”的過渡依賴，局限性非常大憨募；自動(dòng)靜態(tài)方法紧索，主要的手段是代碼靜態(tài)掃描，可以發(fā)現(xiàn)語法特征錯(cuò)誤菜谣、邊界行為特征錯(cuò)誤和經(jīng)驗(yàn)特征錯(cuò)誤這三類“有特征”的錯(cuò)誤珠漂；人工動(dòng)態(tài)方法，就是傳統(tǒng)意義上的單元測(cè)試尾膊，是發(fā)現(xiàn)算法錯(cuò)誤和部分算法錯(cuò)誤的最佳方式媳危；自動(dòng)動(dòng)態(tài)方法，其實(shí)就是自動(dòng)化的邊界測(cè)試眯停，主要覆蓋邊界行為特征錯(cuò)誤济舆。
無非就是用驅(qū)動(dòng)代碼去調(diào)用被測(cè)函數(shù)，并根據(jù)代碼的功能邏輯選擇必要的輸入數(shù)據(jù)的組合莺债，然后驗(yàn)證執(zhí)行被測(cè)函數(shù)后得到的結(jié)果是否符合預(yù)期滋觉。
28 | 帶你一起解讀不同視角的軟件性能與性能指標(biāo)
對(duì)于不同類型的系統(tǒng)，軟件性能的關(guān)注點(diǎn)各不相同齐邦，比如：Web 類應(yīng)用和手機(jī)端應(yīng)用椎侠，一般以終端用戶感受到的端到端的響應(yīng)時(shí)間來描述系統(tǒng)的性能；非交互式的應(yīng)用措拇，比如典型的電信和銀行后臺(tái)處理系統(tǒng)我纪，響應(yīng)時(shí)間關(guān)注更多的是事件處理的速度，以及單位時(shí)間的事件吞吐量丐吓。
一個(gè)優(yōu)秀的性能測(cè)試工程師浅悉，一般需要具有以下技能：性能需求的總結(jié)和抽象能力；根據(jù)性能測(cè)試目標(biāo)券犁，精準(zhǔn)的性能測(cè)試場(chǎng)景設(shè)計(jì)和計(jì)算能力术健；性能測(cè)試場(chǎng)景和性能測(cè)試腳本的開發(fā)和執(zhí)行能力；測(cè)試性能報(bào)告的分析解讀能力粘衬；性能瓶頸的快速排查和定位能力荞估；性能測(cè)試數(shù)據(jù)的設(shè)計(jì)和實(shí)現(xiàn)能力；面對(duì)互聯(lián)網(wǎng)產(chǎn)品稚新，全鏈路壓測(cè)的設(shè)計(jì)與執(zhí)行能力勘伺，能夠和系統(tǒng)架構(gòu)師一起處理流量標(biāo)記、影子數(shù)據(jù)庫(kù)等的技術(shù)設(shè)計(jì)能力褂删；深入理解性能測(cè)試工具的內(nèi)部實(shí)現(xiàn)原理飞醉，當(dāng)性能測(cè)試工具有限制時(shí)，可以進(jìn)行擴(kuò)展二次開發(fā)屯阀；極其寬廣的知識(shí)面冒掌，既要有“面”的知識(shí)噪裕，比如系統(tǒng)架構(gòu)蹲盘、存儲(chǔ)架構(gòu)股毫、網(wǎng)絡(luò)架構(gòu)等全局的知識(shí)，還要有大量“點(diǎn)”的知識(shí)積累召衔，比如數(shù)據(jù)庫(kù) SQL 語句的執(zhí)行計(jì)劃調(diào)優(yōu)铃诬、JVM 垃圾回收（GC）機(jī)制、多線程常見問題等等苍凛。
目前趣席，獲取用戶行為模式的方法，主要分為兩種：
對(duì)于已經(jīng)上線的系統(tǒng)來說醇蝴，往往采用系統(tǒng)日志分析法獲取用戶行為統(tǒng)計(jì)和峰值并發(fā)量等重要信息宣肚；而對(duì)于未上線的全新系統(tǒng)來說，通常的做法是參考行業(yè)中類似系統(tǒng)的統(tǒng)計(jì)信息來建模悠栓，然后分析霉涨。
29 | 聊聊性能測(cè)試的基本方法與應(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ù)的增長(zhǎng)往枷，系統(tǒng)的吞吐量也會(huì)隨之呈線性增長(zhǎng)，我們往往把這個(gè)階段稱為 “線性增長(zhǎng)區(qū)間”凄杯。
隨著系統(tǒng)并發(fā)用戶數(shù)的進(jìn)一步增長(zhǎng)错洁，系統(tǒng)的處理能力逐漸趨于飽和，因此每個(gè)用戶的響應(yīng)時(shí)間會(huì)逐漸變長(zhǎng)戒突。相應(yīng)地屯碴，系統(tǒng)的整體吞吐量并不會(huì)隨著并發(fā)用戶數(shù)的增長(zhǎng)而繼續(xù)呈線性增長(zhǎng)。我們往往把這個(gè)階段稱為系統(tǒng)的“拐點(diǎn)”妖谴。
隨著系統(tǒng)并發(fā)用戶數(shù)的增長(zhǎng)窿锉，系統(tǒng)處理能力達(dá)到過飽和狀態(tài)。此時(shí)膝舅，如果繼續(xù)增加并發(fā)用戶數(shù)嗡载，最終所有用戶的響應(yīng)時(shí)間會(huì)變得無限長(zhǎng)。相應(yīng)地仍稀，系統(tǒng)的整體吞吐量會(huì)降為零洼滚，系統(tǒng)處于被壓垮的狀態(tài)。我們往往把這個(gè)階段稱為“過飽和區(qū)間”技潘。
30 | 工欲善其事必先利其器：后端性能測(cè)試工具原理與行業(yè)常用工具簡(jiǎn)介
完整的后端性能測(cè)試應(yīng)該包括性能需求獲取遥巴、性能場(chǎng)景設(shè)計(jì)千康、性能測(cè)試腳本開發(fā)、性能場(chǎng)景實(shí)現(xiàn)铲掐、性能測(cè)試執(zhí)行拾弃、性能結(jié)果報(bào)告分析、性能優(yōu)化和再驗(yàn)證摆霉。
33 | 無實(shí)例無真相：基于LoadRunner實(shí)現(xiàn)企業(yè)級(jí)服務(wù)器端性能測(cè)試的實(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è)級(jí)實(shí)際性能測(cè)試案例與經(jīng)驗(yàn)分享
性能基準(zhǔn)測(cè)試；穩(wěn)定性測(cè)試悼潭；并發(fā)測(cè)試庇忌；容量規(guī)劃測(cè)試。
性能基準(zhǔn)測(cè)試舰褪，可以保證新發(fā)布系統(tǒng)的整體性能不會(huì)下降皆疹；穩(wěn)定性測(cè)試，主要通過長(zhǎng)時(shí)間模擬被測(cè)系統(tǒng)的測(cè)試負(fù)載占拍，觀察系統(tǒng)在長(zhǎng)期運(yùn)行過程是否存在問題略就；并發(fā)測(cè)試，往往被當(dāng)作功能測(cè)試的補(bǔ)充去發(fā)現(xiàn)多線程晃酒、資源競(jìng)爭(zhēng)表牢、資源死鎖之類的問題。容量規(guī)劃測(cè)試贝次，主要用于確定給定負(fù)載下的系統(tǒng)集群規(guī)模崔兴，其測(cè)試結(jié)果可以被用作系統(tǒng)容量設(shè)計(jì)的依據(jù)。
