本文將從薪水，職業(yè)規(guī)劃，測試?yán)碚摶A(chǔ)，自動化測試基礎(chǔ)，常用自動化框架，計(jì)算機(jī)基礎(chǔ)及 Python 高頻面試題，測試相關(guān)高頻面試題出發(fā)，詳細(xì)內(nèi)容如下，希望能對大家有所幫助。

薪水

我把它放在最前面，讓大家能有一個基本的了解。綜合下來，應(yīng)屆生在互聯(lián)網(wǎng)公司的測開崗位薪水在 22~25 之間。

前景

我咨詢身邊認(rèn)識的同學(xué)關(guān)于測開的前景。

測試的發(fā)展路線為兩條，一條是業(yè)務(wù)型測試，另一個是技術(shù)型測試。業(yè)務(wù)型測試比較好理解，更加偏向業(yè)務(wù)，很可能最開始是從事測試方面的工作，后面去專門做了業(yè)務(wù)，其大概路線為功能測試，業(yè)務(wù)專家，行業(yè)業(yè)務(wù)專家，行業(yè)業(yè)務(wù)發(fā)展專家等，超級遙遠(yuǎn)的路羅。

對于技術(shù)型測試，更加偏向技術(shù)。從功能測試到測試開發(fā)，我遇到過一個測試，將開發(fā)的 Bug 揪出來就算了，還指導(dǎo)開發(fā)修改邏輯，哈哈哈哈哈哈，笑死我。其路線如下圖哦

左側(cè)為業(yè)務(wù)型測試，在工作中遇到一個姐姐，在銀行外包大概工作了11年，后面轉(zhuǎn)為行內(nèi)的業(yè)務(wù)，甲方爸爸羅。當(dāng)然是非常不容易的，所需要的付出不亞于走技術(shù)路線，不過你的業(yè)務(wù)路線會把自己的職業(yè)選擇固定在某一個特定的領(lǐng)域。

右邊是技術(shù)路線，職業(yè)選擇還是挺廣的了，功能測試，接口測試，性能測試，安全測試等等，也是面試的考察點(diǎn)，目前來看，純粹的功能測試太少太少，幾乎瀕臨淘汰羅，那么測試開發(fā)成為本文著重會說的復(fù)習(xí)內(nèi)容。

測試開發(fā)本質(zhì)

測試開發(fā)的本質(zhì)是助力業(yè)務(wù)成功。感覺很多同學(xué)一上來就是學(xué)習(xí)編程技術(shù)，技術(shù)學(xué)習(xí)比較枯燥，計(jì)算機(jī)基礎(chǔ)知識不扎實(shí)，很快就陷入了基礎(chǔ)知識的泥沼。

在我看來了解基礎(chǔ)理論后，學(xué)習(xí) Python，Git 等必備技巧，熟悉一門自動化框架就可以解決測試相關(guān)的面試了。

軟件測試存在的意義

通過一系列測試活動，「提前」發(fā)現(xiàn)和定位軟件產(chǎn)品質(zhì)量的薄弱環(huán)節(jié)，并倒逼開發(fā)人員修正，從而保證交付的軟件質(zhì)量滿足客戶需求。

有研究表明，越早發(fā)現(xiàn)軟件中存在的問題，開發(fā)費(fèi)用就越低，軟件質(zhì)量越高，軟件發(fā)布后的維護(hù)費(fèi)用越低。因此，提前發(fā)現(xiàn)和定位問題極為重要，而在軟件開發(fā)的整個歷程中，越是新興的軟件開發(fā)模型，越重視「提前測試」。提前測試可以使得在需求分析時期就可發(fā)現(xiàn)的錯誤，不必等到開發(fā)完成才被發(fā)現(xiàn)。

測試伴隨著軟件開發(fā)模型的演進(jìn)

說到開發(fā)模型，從軟件發(fā)展來看，比較典型的有瀑布模型，V 模型和 W 模型以及 敏捷開發(fā)模型。并不是說開發(fā)模型的選擇越新越好，需要根據(jù)項(xiàng)目的具體情況而選擇。

瀑布模型

我們知道，瀑布模型的主要特征在于項(xiàng)目完全按照階段劃分，只有前一階段完成，才能開始下一階段。具體到測試活動，則只能在全部編碼完成后、發(fā)布之前執(zhí)行，在這種開發(fā)模型中，測試活動被完全后置了，測試僅僅是編碼后的一個活動階段，測試的重要性沒有被凸顯出來。

V 模型

基于此，V 模型出現(xiàn)了。V 模型在整個開發(fā)過程中，不僅相對清晰地劃分了測試活動的不同級別，還將其不同級別的測試活動與軟件開發(fā)各階段清晰地對應(yīng)起來，強(qiáng)調(diào)了測試在整個開發(fā)過程中的重要性。但在 V 模型中，測試依舊是編碼之后才開始的，測試介入時間還是太晚。比如，需求分析階段出現(xiàn)的問題，要等到系統(tǒng)測試階段才能發(fā)現(xiàn)。

W 模型

為了彌補(bǔ)這一缺點(diǎn)，V 模型的進(jìn)一步深化版，即W 模型出現(xiàn)了。從 W 模型的示意圖中，可以看到，W 模型是把 V 模型左邊的每一個活動都加了一個測試設(shè)計(jì)活動，體現(xiàn)了“盡早和不斷地進(jìn)行測試”的原則。

敏捷模型

敏捷過程模型”是指基于迭代開發(fā)的軟件開發(fā)方法。敏捷方法將任務(wù)分解為較小的迭代, 或者部分不直接涉及長期計(jì)劃。在開發(fā)過程的開始就確定了項(xiàng)目范圍和要求。事先明確定義了有關(guān)迭代次數(shù), 每次迭代的持續(xù)時間和范圍的計(jì)劃。

每次迭代都被視為敏捷流程模型中的短時間”框架”, 通常持續(xù)一到四個星期。將整個項(xiàng)目分成較小的部分有助于最大程度地降低項(xiàng)目風(fēng)險(xiǎn), 并減少總體項(xiàng)目交付時間要求。每次迭代都涉及一個團(tuán)隊(duì), 在整個軟件開發(fā)生命周期中進(jìn)行工作, 包括計(jì)劃, 需求分析, 設(shè)計(jì), 編碼和測試, 然后再向客戶展示有效產(chǎn)品。

職業(yè)生涯

軟件測試開發(fā)流程

需求分析

在測試前拿到產(chǎn)品需求文檔，進(jìn)行需求分析及需求評審前先對需求文檔進(jìn)行詳細(xì)的閱讀，對有疑問的地方進(jìn)行標(biāo)注。

具體可從以下進(jìn)行：

• 分析產(chǎn)品功能點(diǎn)

• 產(chǎn)品核心競爭力

• Kano模型、馬斯洛需求分析、多問幾個為什么、上下文分析法

制訂測試用例（重要）

工欲善其事，必先利其器；對測試而言，測試用例就是器，做好了才能把好關(guān)

• 使用思維導(dǎo)圖列舉測試大綱，盡量發(fā)散，想到什么就寫什么，；先放后收，對知識點(diǎn)進(jìn)行總結(jié)和歸納，標(biāo)記重點(diǎn)測試模塊，刪除冗余及重復(fù)測試點(diǎn)。

• 可使用邊界值法、等價類劃分法、錯誤推測法、因果圖法等設(shè)計(jì)案例

• 根據(jù)測試大綱制定測試用例，需包含模塊名、測試優(yōu)先級、操作步驟、期望結(jié)果、測試結(jié)果、備注

評審測試用例

• 測試作為主導(dǎo)，聯(lián)合開發(fā)、項(xiàng)目經(jīng)理、PM進(jìn)行測試用例評審 ?

• 可先講解測試大綱，讓開發(fā)、項(xiàng)目經(jīng)理、PM心中對測試用例有個大概；后再進(jìn)行詳細(xì)測試用例講解 ?

執(zhí)行測試

• 根據(jù)測試用例執(zhí)行測試 ?

• 發(fā)現(xiàn)問題保留現(xiàn)場，記錄測試方法，通知開發(fā)解決問題 ?

• 覆蓋測試用例之外若有時間可進(jìn)行探索性測試 ?

提交 Bug 并推動 Bug 解決

• 在Bug管理工具上提交Bug，詳細(xì)記錄測試步驟

• 根據(jù)Bug嚴(yán)重程度劃分Bug等級:致命、嚴(yán)重、一般、提示

• 推動開發(fā)解決問題，記錄問題進(jìn)展，一般聊天溝通，若問題嚴(yán)重則需通過郵件推動解決

回歸測試

• 對已修復(fù)的 Bug 進(jìn)行驗(yàn)證

• 對 Bug 所在模塊進(jìn)行基本功能測試；整體進(jìn)行冒煙測試，確保不會因?yàn)樾薷?Bug 而引起其他功能出現(xiàn)問題

編寫并提交測試報(bào)告

可使用金字塔原理設(shè)計(jì)測試報(bào)告，先總后分，上級統(tǒng)領(lǐng)下級，下級推導(dǎo)出上級，環(huán)環(huán)相扣

• 對Bug進(jìn)行匯總，篩選出各個等級的Bug存活情況

• 制訂Bug發(fā)現(xiàn)及解決曲線圖，一般版本正常應(yīng)是前期多，后期收斂，存活的是級別較低的Bug

• 總結(jié)歸納版本情況，評估發(fā)布與否

軟件測試方法

白盒測試

概念：關(guān)注程序代碼的具體細(xì)節(jié)，根據(jù)軟件內(nèi)部代碼的邏輯結(jié)構(gòu)分析來進(jìn)行測試。主要是通過閱讀程序代碼或者通過使用開發(fā)工具中的單步調(diào)試來判斷軟件質(zhì)量。關(guān)注代碼的實(shí)現(xiàn)細(xì)節(jié)。主要對程序模塊的所有獨(dú)立執(zhí)行路徑至少測試一遍、對所有的邏輯判定，取“真”或“假”的兩種情況都要測試一遍，循環(huán)邊界和運(yùn)行界限內(nèi)執(zhí)行循環(huán)體等等

測試用例設(shè)計(jì)方法：邏輯覆蓋、循環(huán)覆蓋、基本路徑覆蓋、判定覆蓋

優(yōu)點(diǎn)：增大代碼的覆蓋率，提高代碼的質(zhì)量，發(fā)現(xiàn)代碼中隱藏的問題

缺點(diǎn)：系統(tǒng)龐大時測試開銷很大，難以測試所有運(yùn)行路徑；測試基于代碼，只能驗(yàn)證代碼是否正確，而不曉得代碼設(shè)計(jì)是否合理，可能會遺漏某些功能需求

黑盒測試

概念：不考慮其內(nèi)部結(jié)構(gòu)，即具體代碼實(shí)現(xiàn)，檢測軟件的各個功能能否得以實(shí)現(xiàn)，確認(rèn)軟件功能的正確性，依靠軟件說明書來判斷測試用例,關(guān)注具體的客戶需求及軟件功能。黑盒測試主要是為了發(fā)現(xiàn)：1.是否有不正確的或者遺漏的功能；2.輸入是否能輸出正確的結(jié)果；3.性能上是否滿足要求

優(yōu)點(diǎn)：①較為簡單，不需要了解程序內(nèi)部的代碼及實(shí)現(xiàn)，與軟件內(nèi)部實(shí)現(xiàn)無關(guān)；②從用戶角度出發(fā)，實(shí)際考慮用戶使用的功能及可能出現(xiàn)的問題

缺點(diǎn)：不可能覆蓋所有的代碼，覆蓋率較低

測試用例設(shè)計(jì)方法：邊界值分析法、等價類劃分、錯誤猜測法、因果圖法、狀態(tài)圖法、測試大綱法、隨機(jī)測試法、場景法

等價類

輸入域的各子集中，各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的。

• 等價類劃分：將全部輸入數(shù)據(jù)合理劃分成若干個等價類，在每一個等價類中取一個數(shù)據(jù)作為輸入條件，就可以用少量代表性測試數(shù)據(jù)取得較好的測試結(jié)果。分為有效等價類（合理、有意義的輸入數(shù)據(jù)構(gòu)成的集合）和無效等價類

• 邊界值分析法：大量錯誤是發(fā)生在輸入輸出范圍的邊界上，選定測試用例時應(yīng)該選取正好等于、剛剛大于、剛剛小于邊界值的值作為測試數(shù)據(jù)，而不是選取等價類中的任意值，作為對等價類劃分的補(bǔ)充

• 錯誤猜測法：基于經(jīng)驗(yàn)和直覺推測，列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況，根據(jù)這些情況選擇測試用例

• 因果圖法：考慮輸入條件之間的相互組合，也考慮輸出結(jié)果對輸入條件的依賴關(guān)系。原因即為輸入條件或者輸入條件的等價類，結(jié)果即為輸出條件，把因果轉(zhuǎn)換為決策表，為決策表中的每一列設(shè)計(jì)測試用例。

• 場景分析法：根據(jù)用戶場景來模擬用戶的操作步驟

• 大綱法：著眼于需求。將需求轉(zhuǎn)換為大綱的形式，大綱表示為樹狀結(jié)構(gòu)，在根和葉子節(jié)點(diǎn)之間存在唯一路徑，大綱為每條路徑定義了一個特殊的輸入條件集合，用于測試用例。

• 隨機(jī)測試法：不考慮任何用例和需求，完全站在用戶的角度對產(chǎn)品進(jìn)行測試

灰盒測試

關(guān)注輸入輸出的準(zhǔn)確性，也關(guān)注內(nèi)部的代碼，但是沒有白盒測試那么詳細(xì)完整。

動態(tài)測試：

實(shí)際運(yùn)行被測程序，輸入相應(yīng)的測試用例，檢查運(yùn)行結(jié)果與預(yù)期結(jié)果的差異，從而驗(yàn)證程序的正確性、有效性和可靠性，并且分析系統(tǒng)運(yùn)行的效率和健壯性。

α測試：

一個用戶在開發(fā)環(huán)境下的受控測試，模擬實(shí)際操作環(huán)境

β測試

多個用戶在實(shí)際使用環(huán)境下進(jìn)行的測試，如一些軟件的公測

冒煙測試

在大規(guī)模測試之前，先對軟件的基本、核心、主要功能進(jìn)行測試，節(jié)省資源

回歸測試

開發(fā)修正完代碼后再回過頭來做測試

隨機(jī)測試

跳出思維的限制，沒有思想、沒有步驟地隨機(jī)進(jìn)行測試

探索測試

有思想，有步驟地測試一些復(fù)雜的、不常用地功能

為什么引入自動化測試

自動化測試是將自動化工具和技術(shù)應(yīng)用于軟件測試，旨在減少測試工作，更快，更經(jīng)濟(jì)地驗(yàn)證軟件質(zhì)量。有助于以更少的工作量構(gòu)建質(zhì)量更好的軟件。

許多公司多多少少都在做自動化測試，但手動測試仍然占主要的比例，因?yàn)橛行﹫F(tuán)隊(duì)不知道如何在開發(fā)過程中更好的利用自動化測試來替代手動測試。

手工測試通常是工程師仔細(xì)的執(zhí)行預(yù)定義的測試用例，將執(zhí)行結(jié)果與預(yù)期的行為進(jìn)行手工比較并記錄結(jié)果。每次源代碼更改時都會重復(fù)這些手動測試，由于都是人為參與，這個過程中很容易出錯。

在組織中引入自動化測試時，需要投入大量財(cái)力和時間。然而，一般沒有太多的財(cái)務(wù)回報(bào)，至少在小規(guī)模開始時沒有。因此許多公司選擇開源測試自動化工具，特別是在開始引入自動化測試的階段。

通常，軟件公司害怕投資自動化測試，不是因?yàn)樨?fù)擔(dān)不起這個投入，而是因?yàn)樗麄儞?dān)心的回報(bào)不會像預(yù)期的那樣，或者根本不會產(chǎn)生積極的投資回報(bào)率。

1. 降低成本（特別是問題出現(xiàn)時的成本）

如前所述，開始自動化測試的初始成本并不高，比如選用免費(fèi)的開源工具。但是，一旦您的組織全面展開自動化測試，您就會希望投資更好的工具、更好的服務(wù)器，雇用人力來維護(hù)基礎(chǔ)設(shè)施等。這些成本絕對不是無關(guān)緊要的。

自動化測試不會自動生成。創(chuàng)建有價值的自動化測試需要花費(fèi)時間和精力，而且不會在一夜之間發(fā)生。

如果您想證明引入自動化測試的合理性，不能只關(guān)注財(cái)務(wù)回報(bào)，而應(yīng)考慮應(yīng)用出現(xiàn)問題導(dǎo)致的隱性成本。例如一個問題在手動測試沒有發(fā)現(xiàn)而出現(xiàn)在產(chǎn)品環(huán)境中，公司會花多少錢？你是否會失去客戶？需要花多少時間、資源和資金來糾正這種情況？

如果每次對代碼進(jìn)行更改時，都重復(fù)執(zhí)行一組非常強(qiáng)大的測試套件，可以降低問題出現(xiàn)在產(chǎn)品環(huán)境的風(fēng)險(xiǎn)。自動化測試有助于在軟件開發(fā)生命周期的早期發(fā)現(xiàn)錯誤，從而降低交付故障軟件的風(fēng)險(xiǎn)。

說到底，向市場提供高質(zhì)量的產(chǎn)品重要性遠(yuǎn)大于任何其他類型的節(jié)省。

2. 節(jié)省時間

雖然初期建立自動化測試需要花費(fèi)大量的時間和人力，但是一旦自動化測試建立了，您就可以重用這些測試。自動化測試的執(zhí)行速度明顯快于手動測試，不易出錯，且節(jié)省人力。

在日常的代碼修改過程中，您可以在每次提交時執(zhí)行自動化測試，而不必通過設(shè)置環(huán)境或記住執(zhí)行每個測試的步驟來持續(xù)執(zhí)行手動步驟。一切都是自動完成的。

只要首次設(shè)置完成后，就可以重復(fù)運(yùn)行你的自動化測試，從而將重復(fù)的手動測試時間從數(shù)周縮短至數(shù)小時。

同樣一旦編寫好，測試可以執(zhí)行任意次。與手動測試儀不同，測試也可全天候，無人值守的執(zhí)行。

在軟件開發(fā)團(tuán)隊(duì)中，通常的做法是每天多次（通常是每次提交）運(yùn)行基本單元測試，并且每天在下班后執(zhí)行耗時的集成測試和UI測試。

3. CI和DevOps

自動化測試構(gòu)成任何持續(xù)集成或DevOps設(shè)置的基礎(chǔ)。從本質(zhì)上講，CI（持續(xù)集成）和DevOps都依賴于“Fail fast, Fail early”的理念。對代碼庫的每次提交都將自動進(jìn)行測試，并將結(jié)果報(bào)告給開發(fā)人員。開發(fā)人員優(yōu)先修復(fù)任何導(dǎo)致構(gòu)建失敗或?qū)е轮饕獪y試失敗的錯誤，確保主線代碼始終按預(yù)期工作。

4. 準(zhǔn)確性和可靠性

由于運(yùn)行每個測試涉及多個先決條件，手動測試容易出錯。另外每個測試可能需要不同的執(zhí)行順序。

畢竟手動測試人員是人類，人有不善于執(zhí)行重復(fù)枯燥工作的特點(diǎn)，因此可以預(yù)料手動測試不會精確并有一定的幾率出錯。這會導(dǎo)致不準(zhǔn)確的結(jié)果反饋到開發(fā)團(tuán)隊(duì)。

自動化測試每次都執(zhí)行相同的步驟，不僅精確，而且結(jié)果可在最短的時間內(nèi)提供給所有相關(guān)人員。

可靠性的另一個方面是在不同服務(wù)器上重新執(zhí)行相同的測試。這使得能夠快速驗(yàn)證測試是否在所有服務(wù)器上按預(yù)期運(yùn)行，從而排除了服務(wù)器配置問題的可能性。

4. 性能測試

性能負(fù)載測試可確保您的應(yīng)用程序可以處理預(yù)期和意外的用戶負(fù)載。

如果您當(dāng)前只在項(xiàng)目中使用手動測試方法，則負(fù)載測試可能會推遲到開發(fā)周期結(jié)束。按照敏捷方法和持續(xù)集成理念，應(yīng)及早地進(jìn)行性能測試，但現(xiàn)實(shí)是很大一部分項(xiàng)目團(tuán)隊(duì)執(zhí)行做這個測試的時間太晚，最終導(dǎo)致產(chǎn)品發(fā)布推遲。

自動化性能測試能夠同時運(yùn)行數(shù)千個測試，模擬數(shù)百萬用戶，所有這些用戶手動測試幾乎都是不可能的。

5. 增加對軟件的信心

敏捷方法建議使用sprint，即短周期的迭代。每個sprint通常2-3周。這需要一種新的方式來組織測試工作并要求更高的效率。

每個sprint都專注于開發(fā)一組小功能，但必須在其結(jié)束的時候提供較完整的新功能特性，還包括之前sprint的所有功能特性。如果沒有適當(dāng)?shù)臏y試，在不破壞之前正常工作的功能特性的情況下提供全功能系統(tǒng)的風(fēng)險(xiǎn)很高。在每個sprint中反復(fù)手動測試所有功能會效率低下。

這也是自動化測試最大的好處。自動化測試并能夠在每個sprint中快速重復(fù)測試，可以確保所有事情都按預(yù)期工作。

6. 衡量質(zhì)量指標(biāo)

可用于自動化測試的擴(kuò)展和工具提供了測量許多代碼質(zhì)量指標(biāo)的功能，例如代碼覆蓋率（即實(shí)際測試的代碼百分比），技術(shù)債，代碼語義檢查等。

通常，當(dāng)測試作為持續(xù)集成或DevOps工作流程的一部分執(zhí)行時，可同時獲取這些方面的測量數(shù)據(jù)。

之所以能夠測量這些指標(biāo)，是因?yàn)樽詣踊瘻y試代碼本身與產(chǎn)品代碼共存，通過在自動構(gòu)建階段解析源代碼，能提供在幾分鐘內(nèi)測量巨大代碼庫質(zhì)量的機(jī)會。這在手動測試中根本不可能。

小結(jié)

如果您的產(chǎn)品質(zhì)量是您的首要目標(biāo)，我強(qiáng)烈建議您使用自動化測試作為日常開發(fā)實(shí)踐的一部分。它將確保您的應(yīng)用程序得到正確測試，并為研發(fā)、管理人員和客戶提供信心。

自動化測試需要前期投入，并且需要花時間進(jìn)行開發(fā)。這些投入會得到長期的回報(bào)：可以減少工作量，消除手動測試的錯誤，提高準(zhǔn)確性，最終節(jié)省成本和時間。

總的來說，自動化測試是一種比手動測試更快獲得故障反饋的方法，符合“快速失敗，早期失敗”的原則。它有助于實(shí)現(xiàn)手動測試無法提供的質(zhì)量。在自動化測試中，

行為驅(qū)動的自動化測試

現(xiàn)已廣泛為研發(fā)團(tuán)隊(duì)所接受，基于行為驅(qū)動(BDD)的測試腳本具有上手快、易維護(hù)、方便所有stakeholders溝通等特點(diǎn)。

如果您還沒有一款合適的自動化測試工具來確保軟件質(zhì)量，您可以了解

自動化測試框架包含哪些模塊

一個比較成熟的測試框架通常會包含 4 個部分，分別為基礎(chǔ)模塊，管理模塊，統(tǒng)計(jì)模塊和運(yùn)行模塊。

基礎(chǔ)模塊

造房子要穩(wěn)固需要良好的地基。如果把自動化測試框架比作一輛汽車，那么自動化測試基礎(chǔ)模塊就是那四只輪胎，沒有它們，這輛汽車寸步難行，它們一般包括如下部分。

• 可重用的組件

一般來說用來降低開發(fā)成本，常見有日志模塊，時間模塊等

• 配置文件

通常會包含測試環(huán)境的配置和應(yīng)用程序的配置。其中測試環(huán)境配置用來減少環(huán)境版本切換，從開發(fā)到上線

管理模塊

管理模塊就仿佛是車中的內(nèi)飾，它對測試框架的使用操作體驗(yàn)有著直接的影響，分為測試數(shù)據(jù)管理和測試文件管理

• 測試數(shù)據(jù)管理

測試數(shù)據(jù)一般是測試用例用到的各種測試數(shù)據(jù)，他們是為了驗(yàn)證業(yè)務(wù)正確性而構(gòu)造，每一組的測試案例通常會對應(yīng)一對或多對測試數(shù)據(jù)。測試數(shù)據(jù)的創(chuàng)建又分為實(shí)時創(chuàng)建和事先創(chuàng)建，

實(shí)時創(chuàng)建是測試代碼運(yùn)行的時候才生成測試數(shù)據(jù)。好處是測試數(shù)據(jù)和測試代碼解耦合，測試人員不用關(guān)心創(chuàng)建過程和業(yè)務(wù)調(diào)用鏈，通常用在測試的公用功能上。

事先創(chuàng)建，是指測試代碼運(yùn)行前就準(zhǔn)備好的數(shù)據(jù)文件，其好處是數(shù)據(jù)拿來即用，幾乎不耗費(fèi)時間，由于沒有業(yè)務(wù)調(diào)用，所以這在一定程度上減少了調(diào)用失敗的風(fēng)險(xiǎn)；壞處則是數(shù)據(jù)文件本身需要維護(hù)，以保持可用性和正確性。

• 測試文件管理

測試文件管理就仿佛是車子的外觀，給人第一印象。一個測試用例通常需要包含三個文件，分別是Page類文件，測試類文件和對象庫文件。

這三個文件共同描述一個完整的測試用例。測試文件的結(jié)構(gòu)清晰有助于他人理解測試框架的設(shè)計(jì)思想

運(yùn)行模塊

運(yùn)行模塊為測試框架的發(fā)送機(jī)，用于測試用例的組織和運(yùn)行，通常包含下面幾個部分

• 測試用例調(diào)度，驅(qū)動機(jī)制

• 錯誤恢復(fù)機(jī)制

測試框架應(yīng)該具有一定的錯誤恢復(fù)機(jī)制，測試案例執(zhí)行過程中，可能出現(xiàn)代碼運(yùn)行錯誤或環(huán)境導(dǎo)致的錯誤。

• 持續(xù)集成支持

  測試框架應(yīng)該能夠和 CI 系統(tǒng)低成本集成，包括通過用戶輸入?yún)?shù)指定運(yùn)行環(huán)境、測試結(jié)束后自動生成測試報(bào)告等。

統(tǒng)計(jì)模塊

統(tǒng)計(jì)模塊相當(dāng)于車子的品質(zhì)和口碑。一個完整的統(tǒng)計(jì)模塊，可以告訴你當(dāng)前測試有沒有 Bug，還能分析軟件質(zhì)量的變化情況，統(tǒng)計(jì)模塊一般包含下面幾個模塊

• 測試報(bào)告

測試報(bào)告應(yīng)該全面，包括測試用例條數(shù)統(tǒng)計(jì)、測試用例成功/失敗百分比、測試用例總執(zhí)行時間等總體信息。其中，對于單條測試用例，還應(yīng)該包括測試用例 ID、測試用例運(yùn)行結(jié)果、測試用例運(yùn)行時間、測試用例所屬模塊、測試失敗時刻系統(tǒng)截圖、測試的日志等信息。

• 日志模塊

測試框架應(yīng)該包括完善的日志文件，方便出錯時進(jìn)行排查和定位。

常用的測試框架類型

有的時候，面試官可能也會用你知道哪些測試框架，測試框架分為這樣幾種

模塊化測試框架

模塊化測試框架是利用 OOP 思想和 PO 模式改造而來的框架。

模塊化測試框架把整個測試分為多個模塊，模塊化有以下幾個特征：

• 我們將一個業(yè)務(wù)或者一個頁面成為一個 Page 對象；

• 這個 Page 對象，我們以一個 Page 類來表示它；

• 這個 Page 類里存放有所有這個 Page所屬的頁面對象、元素操作；

• 頁面對象和元素操作組成一個個的測試類方法，供測試用例層調(diào)用。

簡單來說，使用了 PO 模式的框架就可以叫作模塊化測試框架。

• 模塊化測試框架的好處在于方便維護(hù)，你的測試用例可以由不同模塊的不同對象組成；

• 壞處在于你需要非常了解你的系統(tǒng)及這些模塊是如何劃分的，才能在測試腳本里自如地使用，否則你就會陷入重復(fù)定義模塊對象的循環(huán)里。

數(shù)據(jù)驅(qū)動框架

數(shù)據(jù)驅(qū)動框架主要是解決測試數(shù)據(jù)問題。

在測試中，我們常常需要為同一個測試邏輯，構(gòu)造不同的測試數(shù)據(jù)以滿足業(yè)務(wù)需求，這些測試數(shù)據(jù)可以保存在測試代碼里，也可以保存在外部文件里（包括 Excel、File、DB）。

數(shù)據(jù)驅(qū)動框架的精髓在于，輸入 M 組數(shù)據(jù)，框架會自動構(gòu)造出 M 個測試用例，并在測試結(jié)果中把每一個測試用例的運(yùn)行結(jié)果獨(dú)立展示出來。

在 Python 架構(gòu)里，最出名的數(shù)據(jù)驅(qū)動框架就是 DDT。

關(guān)鍵字驅(qū)動框架

當(dāng)把一系列代碼封裝為要給關(guān)鍵字，在測試的過程中，通過組合關(guān)鍵字的方式來生成測試用例，而不關(guān)心關(guān)鍵字如何運(yùn)作的，這種為關(guān)鍵字驅(qū)動框架。

混合模型

并不一定要選擇上面的三種框架之一，需要根據(jù)需求靈活的選擇測試框架，在工作中可能經(jīng)常需要糅合不同的框架模型，這樣的模型就叫做混合模型。

測試框架設(shè)計(jì)原則

• 首先是清晰明了，學(xué)習(xí)成本低

其中包含代碼規(guī)范和模塊清晰明確。

• 通用性強(qiáng)，可維護(hù)，可擴(kuò)展

• 對錯誤的處理能力強(qiáng)

錯誤處理機(jī)制，能高效解決。系統(tǒng)日志清晰，方便調(diào)試。

• 運(yùn)行效率高且功能強(qiáng)大

支持測試環(huán)境切換，支持外部數(shù)據(jù)驅(qū)動，支持順序并發(fā)，遠(yuǎn)程運(yùn)行，報(bào)告完備詳盡。

• 支持版本控制和持續(xù)集成

版本控制回溯復(fù)盤，持續(xù)集成全局出發(fā)

如何設(shè)計(jì)一個不錯的測試案例

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

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

• 整體完備性 ? ：「好的」測試用例一定是一個完備的整體，是有效測試用例組成的集合，能夠完全覆蓋測試需求。

• 等價類劃分的準(zhǔn)確性 ? ：指的是對于每個等價類都能保證只要其中一個輸入測試通過，其他輸入也一定測試通過。

• 等價類集合的完備性 ? ：需要保證所有可能的邊界值和邊界條件都已經(jīng)正確識別。

三種最常用的測試用例設(shè)計(jì)方法：等價類劃分法、邊界值分析法、錯誤推測方法。

第一，等價類劃分法

我們只要從每個等價類中任意選取一個值進(jìn)行測試，就可以用少量具有代表性的測試輸入取得較好的測試覆蓋結(jié)果。現(xiàn)在，我給你看一個具體的例子：學(xué)生信息系統(tǒng)中有一個考試成績的輸入項(xiàng)，成績的取值范圍是 0~100 之間的整數(shù)，考試成績及格的分?jǐn)?shù)線是 60。為了測試這個輸入項(xiàng)，顯然不可能用 0~100 的每一個數(shù)去測試。通過需求描述可以知道，輸入 0~59 之間的任意整數(shù)，以及輸入 60~100 之間的任意整數(shù)，去驗(yàn)證和揭露輸入框的潛在缺陷可以看做是等價的。那么這就可以在 0~59 和 60~100 之間各隨機(jī)抽取一個整數(shù)來進(jìn)行驗(yàn)證。這樣的設(shè)計(jì)就構(gòu)成了所謂的“有效等價類”。

你不要覺得進(jìn)行到這里，已經(jīng)完成了等價類劃分的工作，因?yàn)榈葍r類劃分方法的另一個關(guān)鍵點(diǎn)是要找出所有「無效等價類」 。顯然，如果輸入的成績是負(fù)數(shù)，或者是大于100的數(shù)等都構(gòu)成了“無效等價類”。

在考慮了無效等價類后，最終設(shè)計(jì)的測試用例為：

有效等價類1：0~59之間的任意整數(shù)；

有效等價類2：59~100之間的任意整數(shù)；

無效等價類1：小于0的負(fù)數(shù)；

無效等價類2：大于100的整數(shù)；

無效等價類3：0~100之間的任何浮點(diǎn)數(shù)；

無效等價類4：其他任意非數(shù)字字符。

第二，邊界值分析方法 ? ? ? ? ? ?

邊界值分析是對等價類劃分的補(bǔ)充，你從工程實(shí)踐經(jīng)驗(yàn)中可以發(fā)現(xiàn)，大量的錯誤發(fā)生在輸入輸出的邊界值上，所以需要對邊界值進(jìn)行重點(diǎn)測試，通常選取正好等于、剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù)。我們繼續(xù)看學(xué)生信息系統(tǒng)中“考試成績”的例子，選取的邊界值數(shù)據(jù)應(yīng)該包括：-1，0，1，59，60，61，99，100，101。

第三，錯誤推測方法 ?

錯誤推測方法是指基于對被測試軟件系統(tǒng)設(shè)計(jì)的理解、過往經(jīng)驗(yàn)以及個人直覺，推測出軟件可能存在的缺陷，從而有針對性地設(shè)計(jì)測試用例的方法。** ? ? 這個方法強(qiáng)調(diào)的是對被測試軟件的需求理解以及設(shè)計(jì)實(shí)現(xiàn)的細(xì)節(jié)把握，當(dāng)然還有個人的能力。

錯誤推測法和目前非常流行的“探索式測試方法”的基本思想和理念是不謀而合的，這類方法在目前的敏捷開發(fā)模式下的投入產(chǎn)出比很高，因此被廣泛應(yīng)用。但是，這個方法的缺點(diǎn)也顯而易見，那就是難以系統(tǒng)化，并且過度依賴個人能力。

總結(jié)：在我看來，深入理解被測軟件需求的最好方法是，測試工程師在需求分析和設(shè)計(jì)階段就開始介入，因?yàn)檫@個階段是理解和掌握軟件的原始業(yè)務(wù)需求的最好時機(jī)。

計(jì)算機(jī)基礎(chǔ)

計(jì)算機(jī)基礎(chǔ)部分，如果時間緊張，可以直接看計(jì)算機(jī)網(wǎng)絡(luò)和數(shù)據(jù)庫的面試總結(jié)。如果想要更加精細(xì)的去學(xué)習(xí)相關(guān)的內(nèi)容，可以參考我之前寫的那篇2021C++學(xué)習(xí)路線，其中的計(jì)算機(jī)基礎(chǔ)部分是通用內(nèi)容。到

Python基礎(chǔ)

這里推薦大家看看《python入門到實(shí)踐》這本書，看完基本上就能使用 Python 了。

我們需要了解什么是 Python，它和 Java/C++有什么不一樣，基本數(shù)據(jù)類型有哪些，Python 控制流(for,while)怎么用。

Python 中 包管理，函數(shù)，模塊之間的關(guān)系等等。當(dāng)了解了基礎(chǔ)知識以后，就可以去看看匿名函數(shù)(lambda)如何使用，自省和反射是什么意思，閉包的基本概念，如何實(shí)現(xiàn)要給裝飾器等等。這里總結(jié)了一部分題目，可以參考，如果不明白或不清楚或覺得不對的地方，大家一定要記的去查閱哦。

什么是Python的命名空間？

在Python中，所有的名字都存在于一個空間中，它們在該空間中存在和被操作——這就是命名空間。它就好像一個盒子，每一個變量名字都對應(yīng)裝著一個對象。當(dāng)查詢變量的時候，會從該盒子里面尋找相應(yīng)的對象。

主（main）函數(shù)的作用

作為整個程序文件的入口。

調(diào)試代碼的時候，在if name__ == ‘__main’中加入一些我們的調(diào)試代碼，我們可以讓外部模塊調(diào)用的時候不執(zhí)行我們的調(diào)試代碼，但是如果我們想排查問題的時候，直接執(zhí)行該模塊文件，調(diào)試代碼能夠正常運(yùn)行！

cookie和session的關(guān)系和區(qū)別

由于 HTTP 協(xié)議是無狀態(tài)的協(xié)議，所以服務(wù)端需要記錄用戶的狀態(tài)時，就需要用某種機(jī)制來識具體的用戶，這個機(jī)制就是 Session.典型的場景比如購物車，當(dāng)你點(diǎn)擊下單按鈕時，由于 HTTP 協(xié)議無狀態(tài)，所以并不知道是哪個用戶操作的，所以服務(wù)端要為特定的用戶創(chuàng)建了特定的 Session，用于標(biāo)識這個用戶，并且跟蹤用戶，這樣才知道購物車?yán)锩嬗袔妆緯＿@個 Session 是保存在服務(wù)端的，有一個唯一標(biāo)識。在服務(wù)端保存 Session 的方法很多，內(nèi)存、數(shù)據(jù)庫、文件都有。集群的時候也要考慮 Session 的轉(zhuǎn)移，在大型的網(wǎng)站，一般會有專門的 Session 服務(wù)器集群，用來保存用戶會話，這個時候 Session 信息都是放在內(nèi)存的，使用一些緩存服務(wù)比如 Memcached 之類的來放 Session。

思考一下服務(wù)端如何識別特定的客戶？這個時候 Cookie 就登場了。每次HTTP請求的時候，客戶端都會發(fā)送相應(yīng)的Cookie信息到服務(wù)端。實(shí)際上大多數(shù)的應(yīng)用都是用 Cookie 來實(shí)現(xiàn) Session 跟蹤的，第一次創(chuàng)建 Session 的時候，服務(wù)端會在HTTP協(xié)議中告訴客戶端，需要在 Cookie 里面記錄一個 Session ID，以后每次請求把這個會話 ID 發(fā)送到服務(wù)器，我就知道你是誰了。

有人問，如果客戶端的瀏覽器禁用了 Cookie 怎么辦？一般這種情況下，會使用一種叫做 URL 重寫的技術(shù)來進(jìn)行會話跟蹤，即每次 HTTP 交互，URL 后面都會被附加上一個諸如 sid=xxxxx 這樣的參數(shù)，服務(wù)端據(jù)此來識別用戶。

Cookie 其實(shí)還可以用在一些方便用戶的場景下，設(shè)想你某次登陸過一個網(wǎng)站，下次登錄的時候不想再次輸入賬號了，怎么辦？這個信息可以寫到 Cookie 里面，訪問網(wǎng)站的時候，網(wǎng)站頁面的腳本可以讀取這個信息，就自動幫你把用戶名給填了，能夠方便一下用戶。這也是 Cookie 名稱的由來，給用戶的一點(diǎn)甜頭。

所以，總結(jié)一下：

Session是在服務(wù)端保存的一個數(shù)據(jù)結(jié)構(gòu)，用來跟蹤用戶的狀態(tài)，這個數(shù)據(jù)可以保存在集群、數(shù)據(jù)庫、文件中；

Cookie是客戶端保存用戶信息的一種機(jī)制，用來記錄用戶的一些信息，也是實(shí)現(xiàn)Session的一種方式。

new 和 init 的區(qū)別

new:創(chuàng)建對象時調(diào)用，會返回當(dāng)前對象的一個實(shí)例

init:創(chuàng)建完對象后調(diào)用，對當(dāng)前對象的一些實(shí)例初始化，無返回值

調(diào)用順序：先調(diào)用new__生成一個實(shí)例再調(diào)用__init方法對實(shí)例進(jìn)行初始化，比如添加屬性。

參數(shù)傳遞機(jī)制

如果實(shí)際參數(shù)的數(shù)據(jù)類型是可變對象（列表、字典），則函數(shù)參數(shù)的傳遞方式將采用引用傳遞方式。如果是不可變的，比如字符串、數(shù)值、元組，他們就是按值傳遞。

迭代器

迭代器是訪問集合元素的一種方式，他的對象從集合的第一個元素開始訪問，直到所有元素被訪問完結(jié)束，用iter()創(chuàng)建迭代器，調(diào)用next()函數(shù)獲取對象（迭代只能往前不能后退）。

兩者區(qū)別：

• 創(chuàng)建/生成，生成器創(chuàng)建一個函數(shù)，用關(guān)鍵字yield生成/返回對象；迭代器用內(nèi)置函數(shù)iter()和next()

• 生成器中yield語句的數(shù)目可以自己在使用時定義，迭代器不能超過對象數(shù)目

• 生成器yield暫停循環(huán)時，生成器會保存本地變量的狀態(tài)；迭代器不會使用局部變量，更節(jié)省內(nèi)存

PYTHONPATH變量是什么

Python中的環(huán)境變量，用于在導(dǎo)入模塊的時候搜索路徑。因此它必須包含Python源庫目錄以及含有Python源代碼的目錄。

模塊和包

模塊：python中包含并有組織的代碼片段，xxx.py的xxx就是模塊名

包：模塊之上的有層次的目錄結(jié)構(gòu)，定義了由很多模塊或很多子包組成的應(yīng)用程序執(zhí)行環(huán)境。包是一個包含init.py文件和若干模塊文件的文件夾。

庫：具有相關(guān)功能模塊的集合，python有很多標(biāo)準(zhǔn)庫、第三方庫…

yield

• 保存當(dāng)前運(yùn)行狀態(tài)（斷點(diǎn)），然后暫停執(zhí)行，即將函數(shù)掛起

• 將yeild關(guān)鍵字后面表達(dá)式的值作為返回值返回，此時可以理解為起到了return的作用，當(dāng)使用next()、send()函數(shù)讓函數(shù)從斷點(diǎn)處繼續(xù)執(zhí)行，即喚醒函數(shù)。

args和*kwargs的含義

不知道向函數(shù)傳遞多少參數(shù)時，比如傳遞一個列表或元組，就使用*args

def?func(*args):…?
????Func(1,2,3,4,5)?

不知道該傳遞多少關(guān)鍵字參數(shù)時，使用 **kwargs 來收集關(guān)鍵字參數(shù)（keyword argument）

python def func(**kwargs):… Func(a=1,b=2,c=3)

Python垃圾回收機(jī)制

（自動處理分配回收內(nèi)存的問題，沒用了內(nèi)存泄漏的隱患），以引用計(jì)數(shù)機(jī)制為主，標(biāo)記-清楚和分代收集兩種機(jī)制為輔

計(jì)數(shù)機(jī)制就是 Python 中的每一個對象都有一個引用計(jì)數(shù)的值，當(dāng)有引用的時候，這個值會增加，引用他的對象被刪除時，這個值減小，引用計(jì)數(shù)的值為0時，該對象生命結(jié)束，Python 會把這段內(nèi)存自動回收。（缺點(diǎn)，循環(huán)引用，如果 l1 和 l2 相互引用，沒用其他的對象引用他們，這兩段內(nèi)存永遠(yuǎn)無法被回收）

Python如何內(nèi)存管理

• 引用計(jì)數(shù)：python內(nèi)部使用引用計(jì)數(shù)，來保持追蹤內(nèi)存中的對象，Python內(nèi)部記錄了對象有多少個引用，即引用計(jì)數(shù)，當(dāng)對象被創(chuàng)建時就創(chuàng)建了一個引用計(jì)數(shù)，當(dāng)對象不再需要時，這個對象的引用計(jì)數(shù)為0時，它被垃圾回收。

• 垃圾回收：python會檢查引用計(jì)數(shù)為0的對象，清除其在內(nèi)存占的空間；循環(huán)引用對象則用一個循環(huán)垃圾回收器來回收

• 內(nèi)存池機(jī)制：在Python中，許多時候申請的內(nèi)存都是小塊的內(nèi)存，這些小塊內(nèi)存在申請后，很快又會被釋放，由于這些內(nèi)存的申請并不是為了創(chuàng)建對象，所以并沒有對象一級的內(nèi)存池機(jī)制。這就意味著Python在運(yùn)行期間會大量地執(zhí)行 malloc 和 free 的操作，頻繁地在用戶態(tài)和核心態(tài)之間進(jìn)行切換，這將嚴(yán)重影響Python的執(zhí)行效率。為了加速Python的執(zhí)行效率，Python引入了一個內(nèi)存池機(jī)制，用于管理對小塊內(nèi)存的申請和釋放。

Python 提供了對內(nèi)存的垃圾收集機(jī)制，但是它將不用的內(nèi)存放到內(nèi)存池而不是返回給操作系統(tǒng)。

Python 中所有小于 256 個字節(jié)的對象都使用 pymalloc 實(shí)現(xiàn)的分配器，而大的對象則使用系統(tǒng)的 malloc。另外 Python 對象，如整數(shù)，浮點(diǎn)數(shù)和List，都有其獨(dú)立的私有內(nèi)存池，對象間不共享他們的內(nèi)存池。也就是說如果你分配又釋放了大量的整數(shù)，用于緩存這些整數(shù)的內(nèi)存就不能再分配給浮點(diǎn)數(shù)。

深拷貝、淺拷貝和等號賦值

深拷貝：新建一個對象，把原來對象的內(nèi)存完全復(fù)制過來，改變復(fù)制后的對象，不會改動原來內(nèi)存的內(nèi)容。（兩個對象在復(fù)制之后是完全獨(dú)立的對象）

等號賦值：相當(dāng)于為原來的對象打一個新的標(biāo)簽，兩個引用指向同一個對象，修改其中的一個，另一個也會產(chǎn)生變化

淺拷貝：兩種情況，1. 淺拷貝的值是不可變對象（數(shù)值、字符、元組）時，和等于賦值一樣，對象的id值和淺拷貝原來的值相同；2. 如果是可變對象（列表、字典等），a. 一個簡單的沒有嵌套的對象，復(fù)制前后的對象相互之間不會影響，b. 對象中有復(fù)雜子對象，如列表嵌套，如果改變原來的對象中復(fù)雜子對象的值，淺拷貝的值也會受影響，因?yàn)樵跍\拷貝時只復(fù)制了子對象的引用（只拷貝父對象）。

Python有什么優(yōu)勢

• 解釋型，語法簡單易懂，可讀性強(qiáng)

• 有很多庫可以用，可以讓我們站在巨人的肩膀上簡單的實(shí)現(xiàn)想要的功能

• 可擴(kuò)展，和其他編程語言或其他軟件有可連接的接口

• 免費(fèi)開源、可移植

• 自動內(nèi)存管理，讓程序員可以專注于代碼的實(shí)現(xiàn)

Python 缺點(diǎn)

• 他的可解釋特征使其運(yùn)行速度變慢

• 動態(tài)語言的特點(diǎn)可能會增加運(yùn)行時錯誤。

面向?qū)ο蠛兔嫦蜻^程的區(qū)別

面向?qū)ο笫前褬?gòu)成問題的事務(wù)分解成各個對象，建立對象來描述某個事務(wù)在解決問題的步驟中的行為；

面向過程是分析出解決問題所需要的步驟，然后用一些函數(shù)把這些步驟一步步實(shí)現(xiàn)，使用的時候依次調(diào)用函數(shù)就行了。

寫一個裝飾器

import??functools
import?time
def?print_run_time(func):
[email protected](func)?def?wrapper(*args,**kw):
????????local_time=time.time()
????????func(*args,**kw)
????????t=time.time()-local_time
????????print(t)
????return?wrapper

@print_run_time
def?test(x):
????for?i?in?range(1000):
????????print(x,end='')
????print('\n')
????return?x

test(1)?

python 裝飾器@staticmethod和@classmethod區(qū)別和使用

@classmethod：類方法，類方法是給類用的，類在使用時會將類本身當(dāng)做參數(shù)傳給類方法的第一個參數(shù)，python為我們內(nèi)置了函數(shù)classmethod來把類中的函數(shù)定義成類方法。

@staticmethod：靜態(tài)方法

用上面兩個裝飾器就可以不用在實(shí)用類前對類進(jìn)行實(shí)例化了，

@property：將一個實(shí)例方法提升為屬性，便于訪問

Git

如果說功能測試工程師的日常工作是被測試用例文檔包圍，那么測試工程師則從代碼提交說起。

在當(dāng)前高度協(xié)作的今天，測試開發(fā)的任務(wù)也是各個負(fù)責(zé)相應(yīng)的模塊，每個模塊不同人負(fù)責(zé)，那么可能就出現(xiàn)下面這些問題

• 你和別人負(fù)責(zé)不同的模塊，代碼都提交后入俄整合

• 如果你在修改一份公共代碼，別人也在修改，如何提交和保存

• 如果想看人家提交的歷史記錄，如何回滾

說白了，我們需要一個版本控制系統(tǒng)來跟蹤我們的代碼，從而更好地解決沖突。

為啥大家都用 Git呢

• 高效的數(shù)據(jù)存儲方式

和其他的版本控制軟件不同的是，Git并不以文件表更列表的方式存儲信息，而是采用了快照流的方式對信息進(jìn)行存儲。

在 Git 提交更新的時候，Git會對項(xiàng)目全部文件創(chuàng)建一個快照并保存這個快照的索引。當(dāng)再次提交，更新的時候，如果存在沒有修改的文件，那么 Git 只保留一個鏈接指向之前存儲的文件，而不再重新存儲該文件，這樣就提高了存儲效率。

• 幾乎所有操作在本地執(zhí)行

在 Git 中，絕大部分的操作訪問本地文件和資源都無需聯(lián)網(wǎng)。

• 具備數(shù)據(jù)完整性保障

在 Git 中，任何操作在被操作前都需要使用 SHA-1 散列計(jì)算校驗(yàn)來保障數(shù)據(jù)的完整性。

Git 的工作流程

在 Git 中，項(xiàng)目文件可能處于這樣三種形態(tài)

• 已修改：表示修改了文件但還沒有保存到數(shù)據(jù)庫

• 已暫存：表示對一個已修改文件的當(dāng)前版本做了標(biāo)記，使之包含在下次提交的快照中

• 已提交：表示數(shù)據(jù)已經(jīng)安全地保存在本地?cái)?shù)據(jù)庫中

Git 項(xiàng)目的三個節(jié)點(diǎn)

對應(yīng)上面三種狀態(tài)，會有三個階段，為工作區(qū)，暫存區(qū)和 Git 目錄。

• 工作區(qū)

工作區(qū)是從 Git 倉庫提取出來的數(shù)據(jù)，也就是我們本地看到的代碼目錄，這里改動的代碼都在已修改狀態(tài)。

• 暫存區(qū)

暫存區(qū)是一個文件，保存了下次將要提交的文件列表信息，一般在 Git 倉庫目錄中。當(dāng)處于已修改狀態(tài)的文件被放入暫存區(qū)（Git Add）時，這些文件則會變?yōu)橐褧捍鏍顟B(tài)。

• Git 目錄

Git 倉庫目錄是 Git 用來保存項(xiàng)目的元數(shù)據(jù)和對象數(shù)據(jù)庫的地方。從其他計(jì)算機(jī)克隆倉庫時，復(fù)制的就是這里的數(shù)據(jù)。當(dāng)暫存區(qū)的文件被提交（Git Commit），則這些文件屬于已提交狀態(tài)。

Git 實(shí)踐

通過上方的內(nèi)容了解 Git 以后，最好動手實(shí)踐一波。

• 安裝 Git

• Git ?基本設(shè)置

• 流程

在公司中，通常都通過 Github 企業(yè)版或 GitLab 進(jìn)行托管，那么測試開發(fā)使用 Git 流程大概如下

通常在本地 Feature 分支進(jìn)行開發(fā)，隨后提交測試，本地測試完成則 pull request方式提交代碼，測試驗(yàn)證，驗(yàn)證完成后 Github 會根據(jù)條件自動出發(fā)測試驗(yàn)證流程，代碼 Merge,通過后 Merge 到 Master。

如果是新項(xiàng)目，如何初始化 Git 項(xiàng)目呢

首先通過 Git init 初始化項(xiàng)目，此時 Git 倉庫為空的，那我們就新建一個文件叫做 lanlan.py，寫完以后通過 git ?add 的方式提交到暫存區(qū)。

如果想刪除這個文件，那么可以通過 git rm 來刪除某個文件。

如果你想要查看當(dāng)前版本庫的狀態(tài)，可以使用 git status，它將列出文件夾在工作區(qū)和暫存區(qū)的狀態(tài)。

如果想要將暫存區(qū)的改動提交到本地版本庫，那就可使用 git commit -m，這里的 -m 后面一定要記得些提交的注釋喲。

如果想要本地的這份代碼提交到遠(yuǎn)程進(jìn)行協(xié)作開發(fā)，就需要使用下面的語句

#如下語法用來添加一個遠(yuǎn)程倉庫
$?git?remote?add?[shortname]?[url]
#將本地倉庫lagouTest和遠(yuǎn)程倉庫建立連接
$?git?remote?add?origin?https://github.com/yourCompany/lagouTest.git

既然是團(tuán)隊(duì)開發(fā)了，那么就先把本地版本代碼傳到遠(yuǎn)程庫，這樣其他的開發(fā)人員就可以拉取最新的代碼

git?push?-u?origin?master

想要獲取最新的代碼，就需要使用 git clone 拉去最新代碼。

可是通常不會在 master 上進(jìn)行開發(fā)，而是需要切換分支，使用 git checkout -b name 的方式切換分支。

使用 Git 的時候，可能遇到哪些問題呢

• 如何查看提交的歷史

如果想要查看某個文件的提交歷史，可以使用 git log filename 或 git log lanlan.py 的方式查看

• 如果本地正在開發(fā)，遠(yuǎn)程的 master 已經(jīng)更新了，如何更到本地分支

#?假設(shè)本地feature分支為newFeature
#?首先需要提交本地分支newFeature的改動至代碼倉庫
$?git?add?.
$?git?commit?-m?"本地分支修改comments"
#?然后，執(zhí)行g(shù)it?merge
$?git?merge?master
#?最后，再次提交
$?git?add?.
$?git?commit?-m?"merge?master?分支"

• 提交的時候出現(xiàn)沖突怎么辦

當(dāng)多人更改同一文件的時候就會出現(xiàn)沖突，此時 git 會列舉出沖突的內(nèi)容，可以通過手動的方式保留哪個版本，然后 git add 和 git commit 的方式再次提交

• 當(dāng)你正在進(jìn)行分支開發(fā)時，接到一個緊急任務(wù)，如何將當(dāng)前的改動保留和后續(xù)恢復(fù)？

當(dāng)你的 feature 分支開發(fā)了一半，然后接到了緊急任務(wù)需要支持，但是你又不想把功能不完善的代碼提交到代碼倉庫，此時可以使用 git stash 命令。

#?如果你要切換新分支但是有未保存的更改使用git checkout -b會報(bào)錯。此#?時可以通過git stash將所有未提交的修改（工作區(qū)和暫存區(qū)）保存至堆棧#?#?中，可用于后續(xù)恢復(fù).
$?git?stash
#?等你想恢復(fù)你保存的改動時，執(zhí)行g(shù)it stash pop。?它將緩存堆棧中的第一個stash刪除，并將對應(yīng)修改應(yīng)用到當(dāng)前的工作目錄下。
$?git?stash?pop

• 本地提交已提交到暫存區(qū)，但是不想要了怎么辦？

假設(shè)你的某次改動已經(jīng)提交到暫存區(qū)，還沒有 push，但是你想丟棄這個改動，可以采用如下辦法：

$?git?reset?--hard?HEAD

• 上線后有問題，代碼需要回退怎么辦？

$?git?revert?HEAD
$?git?push?origin?master

Linux

之前那一篇 3w 字的 Linux總結(jié)看完就差不多了哦，鏈接在此，在星球中同樣是有 PDF。

Docker

Docker基礎(chǔ)部分在之前的文章也給出了，大家可以花時間去學(xué)習(xí)一波。

Docker容器圈簡介

第二趴---Docker基本操作

數(shù)據(jù)庫

數(shù)據(jù)庫計(jì)劃的是三個部分，第一部分?jǐn)?shù)據(jù)庫基礎(chǔ)之前也完成了，不少小伙伴也打卡學(xué)習(xí)完了基礎(chǔ)部分，下個周會給出數(shù)據(jù)庫索引的面試題，一起加油哦。

操作系統(tǒng)

CICD

持續(xù)集成

持續(xù)集成（Continuous integration，簡稱CI），簡單來說持續(xù)集成就是頻繁地（一天多次）將代碼集成到主干。

每次集成都通過自動化的構(gòu)建（包括編譯、發(fā)布、自動化測試）來驗(yàn)證，從而盡快地發(fā)現(xiàn)集成錯誤。

持續(xù)集成強(qiáng)調(diào)開發(fā)人員提交了新代碼之后，立刻進(jìn)行構(gòu)建、（單元）測試。根據(jù)測試結(jié)果，可以確定新代碼和原有代碼能否正確地集成在一起。

持續(xù)集成的好處：

• 快速發(fā)現(xiàn)錯誤，每完成一點(diǎn)更新，就集成到主干，可以快速發(fā)現(xiàn)錯誤，定位錯誤也比較容易；

• 防止分支大幅偏離主干，如果不經(jīng)常集成，主干又在不斷更新，會導(dǎo)致以后集成的難度變大，甚至難以集成。

持續(xù)集成的目的

讓產(chǎn)品可以快速迭代，同時還能保持高質(zhì)量。它的核心措施是，代碼集成到主干之前，必須通過自動化測試。只要有一個測試用例失敗，就不能集成。

持續(xù)集成并不能消除 Bug，而是讓它們非常容易的發(fā)現(xiàn)和改正。

持續(xù)集成強(qiáng)調(diào)開發(fā)人員提交了新代碼之后，立刻進(jìn)行構(gòu)建、（單元）測試。根據(jù)測試結(jié)果，我們可以確定新代碼和原有代碼能否正確地集成在一起。

持續(xù)交付

持續(xù)交付（Continuous delivery）指的是：頻繁地將軟件的新版本，交付給質(zhì)量團(tuán)隊(duì)或者用戶，以供評審。如果評審?fù)ㄟ^，代碼就進(jìn)入生產(chǎn)階段

持續(xù)交付可以看作持續(xù)集成的下一步。它強(qiáng)調(diào)的是，不管怎么更新，軟件是隨時隨地可以交付的。

持續(xù)部署

持續(xù)部署（Continuous deployment）是持續(xù)交付的下一步，指的是代碼通過評審以后，自動部署到生產(chǎn)環(huán)境。

持續(xù)部署則是在持續(xù)交付的基礎(chǔ)上，把部署到生產(chǎn)環(huán)境的過程自動化。

持續(xù)部署的目標(biāo)是：代碼在任何時候都是可以部署的，可以進(jìn)入生產(chǎn)階段，持續(xù)部署的前提是能自動化完成測試、構(gòu)建、部署等步驟。

Selenium面試題

之前給星球的小伙伴修改簡歷，發(fā)現(xiàn)想要面試自動化測試相關(guān)的崗位，然而基本上沒有這方面的復(fù)習(xí)準(zhǔn)備，項(xiàng)目經(jīng)驗(yàn)也沒有。如果大家需要相關(guān)的項(xiàng)目，也可以找我拿羅，我都放在星球了。

什么是Selenium？

Selenium是一個開源的web自動化測試框架，主要是基于web uI的自動化測試。現(xiàn)在的版本，逐步增加了對移動端的自動化測試。Selenium支持多種語言進(jìn)行開發(fā)自動化測試腳本，有Java,python，C#，Javascript等等。Selenium支持跨瀏覽器平臺測試。

Selenium是否支持桌面應(yīng)用軟件的自動化測試。

Selenium不支持桌面軟件的自動化測試，Selenium是根據(jù)網(wǎng)頁元素的屬性才定位元素，而其他桌面軟件自動化測試工具是根據(jù)桌面元素的位置來定位元素，當(dāng)然現(xiàn)在也有根據(jù)桌面元素的屬性來定位的。

Selenium是否支持用例的執(zhí)行的引擎。

引擎好比就是一個發(fā)動機(jī)。Selenium是沒有關(guān)于測試用例和測試套件管理和執(zhí)行的模塊。我們需要借助第三方單元測試框架來實(shí)現(xiàn)用例管理和用例的執(zhí)行。例如Java中有Junit或者testNG,Python中有unittest單元測試框架。

Seleinum是否有讀取excel文件的庫

沒有，這里需要用到第三方工具。例如Apache POI插件。

Selenium有哪些組件？

最早的有Selenium IDE,IDE只支持安裝在fiefox上一個插件，支持錄制自動化腳本。還有
remote RC,和Grid 和webdriver。我們一般最重要的就是使用webdriver。

Selenium有什么限制或者缺陷

除了基于web的軟件和mobile的程序，selenium不支持桌面軟件自動化測試。軟件測試報(bào)告，和用例管理只能
依賴第三方插件，例如Junit/TestNG和unittest。由于它是免費(fèi)的軟件，所以沒有供應(yīng)商去提供支持和服務(wù)，有問題，只能求助selenium社區(qū)。還有一個就是，selenium入門門檻可能有點(diǎn)高，需要具備一定編程語言基礎(chǔ)的才能玩轉(zhuǎn)。

在selenium中，有哪些不同定位元素方法

ID/className/Name/LinkText/PartialLinkText/Xpath/CSS selector

什么是imlicitlyWait

imlicitlyWait是隱式等待，一般在查找元素的時候使用。例如，我設(shè)置一個查找元素最大時間為10秒，使用了
imlicitlyWait后，如果第一次沒有找到元素，會在10秒之內(nèi)不斷循環(huán)去找元素，知道超過10秒，報(bào)超時錯誤。

什么是expliciteWait

這個是顯式等待，就是不管如何都是要等10秒，如果你設(shè)置了10秒超時，這個是selenium2的功能
在selenium3中，我暫時沒有找到這個接口。

什么是線程等待

有時候，我們需要強(qiáng)制設(shè)置線程等待，Thread.sleep(2000),driver這個實(shí)例，就是當(dāng)前的線程。

什么是pollingEvery

這個是設(shè)置個一段時間就去做一件事，例如下面設(shè)置隔一秒就去查找元素一次。

WebDriverWait?wait?=?new?WebDriverWait(driver,30);
wait.pollingEvery(1,?TimeUnit.SECONDS);
driver.findElement(By.xpath("xxxx"));

你能解釋下Selenium這個框架嗎？

這個問題在面試中被問到的概率還是比較高的，同樣類似的問題有，selenium 的原理是什么？首先不要被這個問題嚇到，我們主要圍繞 selenium 的歷史版本演化和基本的組件去展開描述就好，最后回到 webdriver 這個組件上面，我們基本上都是在使用webdriver提供的API。所以這個題目的最好的答案就是把圖畫出來，然后自己解釋幾句就可以。早期 Selenium1.0 是有 Selenium Grid，Selenium RC, Selenium IDE, Webdriver 四部分組成，后來 Selenium RC 和 Webdriver 合并之后，就是 Selenium2，當(dāng)前我們在使用 Selenium3。

Selenium Grid：它是selenium框架的一部分，主要是專門用來把測試用例并行地在不同瀏覽器，不同操作系統(tǒng)，不同機(jī)器上運(yùn)行。一般我們寫腳本，調(diào)試都在單機(jī)上線性地一個測試用例接著一個測試用例執(zhí)行下去。如果有人問題如何提高測試用例執(zhí)行效率，告訴他Selenium Grid可以實(shí)現(xiàn)。Selenium IDE: 這個算Selenium里面最簡單的一個組建，只支持在火狐瀏覽器上安裝這個擴(kuò)展程序，支持錄制web ui腳本，然后導(dǎo)出不同語言的腳本，例如java c#等。這個功能算雞肋，因?yàn)楹芏鄷r候?qū)С瞿_本debug的時間還不如自己代碼重新寫來的快。

Selenium RC: RC是remote control的縮寫,主要的功能就是讓你不管使用什么語言（Selenium支持的這幾種語言之一）來寫測試腳本，只要是這個瀏覽器支持java script，那么寫一遍測試腳本，都能在這些不同瀏覽器運(yùn)行腳本。

Webdriver：這個是用來替代Selenium RC，就是一個網(wǎng)頁自動化工具，支持在不同瀏覽器上運(yùn)行測試腳本，運(yùn)行速度比Selenium RC要快很多。據(jù)說（我也記得不清楚），webdriver最早是google內(nèi)部開發(fā)的一個工具，用來捐給selenium了，變成開源了。

目前，我們做的 web ui 的自動化測試，大部分都是在使用 webdriver 提供的 API來模擬手動測試過程中的一系列動作和行為。基本上通過這個方式來回答這個問題，那就沒問題了。

你寫的測試腳本能在不同瀏覽器上運(yùn)行嗎，支持跨瀏覽器平臺嗎

這里出現(xiàn)了跨瀏覽器平臺的概念，就是寫一個測試用例，可以在主流的幾個瀏覽器跑起來。

是的，我寫的測試用例能在IE，火狐和谷歌這三種瀏覽器上運(yùn)行。主要是在windows平臺上運(yùn)行腳本，所以mac的safari瀏覽器暫時沒有寫過。主要實(shí)現(xiàn)這個跨瀏覽器的思想就是，把瀏覽器類型寫到配置文件，代碼里寫if語句去判斷配置文件的瀏覽器的類型，來決定用什么瀏覽器去執(zhí)行測試用例。

什么是POM，為什么要使用它

POM 是 Page Object Model 的簡稱，它是一種設(shè)計(jì)思想，而不是框架。大概的意思是，把一個一個頁面，當(dāng)做一個對象，頁面的元素和元素之間操作方法就是頁面對象的屬性和行為，所以自然而然就用了類的思想來組織我們的頁面。一般一個頁面寫一個類文件，這個類文件包含該頁面的元素定位和業(yè)務(wù)操作方法。

為了我們測試用例寫的簡單，清晰，我們很多時候在頁面對象會封裝很多業(yè)務(wù)操作方法，測試腳本只需要調(diào)用相關(guān)方法就可以。

還有一個可能和這個問題相關(guān)的面試題，如果頁面元素經(jīng)常發(fā)生需求變化，你是如何做，答案就是采用 POM 思想。好處就是只要該一個頁面，我就去修改這個頁面對象的元素定位和相關(guān)方法，腳本不需要修改。

在你做自動化過程中，遇到了什么問題嗎？舉例下

這個問題，不管是自動化還是任何工作，都會被問到。主要想知道你是如何解決問題的，從而推斷你問題分析和解決的能力。

當(dāng)然有遇到問題和挑戰(zhàn)，主要有以下幾點(diǎn)：

頻繁地變更UI，經(jīng)常要修改頁面對象里面代碼，運(yùn)行用例報(bào)錯和處理，例如元素不可見，元素找不到這樣異常，測試腳本復(fù)用，盡可能多代碼復(fù)用，一些新框架產(chǎn)生的頁面元素定位問題，例如ck編輯器，動態(tài)表格等，這個遇到的難點(diǎn)完全取決寫腳本人的代碼能力。回答三個左右就差不多，記得既然拋出了難點(diǎn)問題，一定要記得處理這個問題的方法。

舉例一下你遇到過那些異常，在selenium自動化測試過程中

通過這個問題，大概知道你寫過多少腳本。寫腳本過程最常見的異常就是，這個元素?zé)o法找到。常見的selenium有以下這些：

ElementNotSelectableException ：元素不能選擇異常

ElementNotVisibleException ：元素不可見異常

NoSuchAttributeException ：沒有這樣屬性異常

NoSuchElementException：沒有該元素異常

NoSuchFrameException ：沒有該frame異常

TimeoutException ：超時異常

Element not visible at this point ：在當(dāng)前點(diǎn)元素不可見

如何處理 alert 彈窗

我們常見的alert彈窗有兩種：基于windows彈窗和基于web頁面彈窗

我們知道，webdriver是能夠處理alert彈窗的，Selenium提供了Alert這個接口。相關(guān)操作代碼如下：

?//?切換到Alert
Alert?alert?=?driver.switchTo().alert();
//?點(diǎn)擊彈窗上確定按鈕
alert.accept();
//?點(diǎn)擊彈窗的取消按鈕
alert.dismiss()
//?獲取彈窗上線上的文本文字內(nèi)容
alert.getText();
//?有些彈窗還支持文本輸入，這個可以把要輸入字符通過sendkeys方法輸入
alert.sendkeys();

在selenium中如何處理多窗口？

這個多窗口之間跳轉(zhuǎn)處理，在實(shí)際selenium自動化測試經(jīng)常遇到。就是，你點(diǎn)擊一個鏈接，這個鏈接會在一個新的tab打開，然后你接下來要查找元素在新tab打開的頁面，所以這里需要用到swithTo方法。

需要獲取當(dāng)前瀏覽器多窗口句柄，然后根據(jù)判斷跳轉(zhuǎn)新句柄還是舊句柄

你查找元素遇到過在Frame里面嗎?你是如何處理Frame里面元素定位的？

有時候我們知道元素定位表達(dá)式?jīng)]有問題，但是還是提示 no such element，那么我們就需要考慮這個元素是否在frame中。如果在，我們就需要從 topwindow，通過 swithcTo.Frame() 方法來切換到目標(biāo) frame 中，可以通過 frame 的 name 和 id和索引三種方法來定位 frame。

怎么驗(yàn)證勾選框是enable/disabled/ checked/Unchecked/ displayed/ not displayed？

通過以下方法來驗(yàn)證元素是enable 還是disable

boolean?enabled?=?driver.findElement(By.xpath("元素定位表達(dá)式")).isEnabled();

通過以下方法來驗(yàn)證元素是select/check

boolean?checked?=?driver.findElement(By.xpath("元素定位表達(dá)式")).isSelected();

通過以下方法來驗(yàn)證元素是dispalyed還是not?display

boolean?displayed?=?driver.findElement(By.xpath("元素定位表達(dá)式")).isDisplayed();

關(guān)閉瀏覽器中quit和close的區(qū)別

簡單來說，兩個都可以實(shí)現(xiàn)退出瀏覽器session功能，close是關(guān)閉你當(dāng)前聚焦的tab頁面，而quit是關(guān)閉全部瀏覽器tab頁面，并退出瀏覽器session。知道這兩個區(qū)別，我們就知道quit一般用在結(jié)束測試之前的操作，close用在執(zhí)行用例過程中關(guān)閉某一個頁面的操作。

什么是頁面加載超時

Selenium中有一個 Page Load wait的方法，有時候，我們執(zhí)行腳本的速度太快，但是網(wǎng)頁程序還有一部分頁面沒有完全加載出來，就會遇到元素不可見或者元素找不到的異常。為了解決問題，讓腳本流暢的運(yùn)行，我們可以通過設(shè)置頁面加載超時時間。具體代碼是這個：

driver.manage().timeouts().pageLoadTimeout(10,TimeUnit.SECONDS);

這行作用就是，如果頁面加載超過10秒還沒有完成，就拋出頁面加載超時的異常。

在Selenium中如何實(shí)現(xiàn)截圖，如何實(shí)現(xiàn)用例執(zhí)行失敗才截圖

在Selenium中提供了一個TakeScreenShot這么一個接口，這個接口提供了一個getScreenshotAs（）方法可以實(shí)現(xiàn)全屏截圖。然后我們通過java中的FileUtils來實(shí)現(xiàn)把這個截圖拷貝到保存截圖的路徑。

代碼舉例：
File?src=((TakesScreenshot)driver).getScreenshotAs(OutputType.FILE);
try?{
//?拷貝到我們實(shí)際保存圖片的路徑
????FileUtils.copyFile(src,new?File("C:/selenium/error.png"));
}catch?(IOException?e)
{
????System.out.println(e.getMessage());
}

如果要實(shí)現(xiàn)執(zhí)行用例發(fā)現(xiàn)失敗就自動截圖，那么我們需要把這個截圖方法進(jìn)行封裝。然后在測試代碼中的catch代碼塊去調(diào)用這個截圖方法。這個我們在POM的框架中一般是把截圖方法封裝到BasePage這個文件中。

在Selenium中如何實(shí)現(xiàn)拖拽滾動條？

在Selenium中通過元素定位會自動幫你拖拽到對應(yīng)位置，所以是沒有自帶的scoll方法。但是這個是有限制，例如當(dāng)前頁面高度太長，默認(rèn)是頁上半部分，你定位的元素在頁尾，這個時候可能就會報(bào)元素不可見的異常。我們就需要利用javaScript來實(shí)現(xiàn)拖拽頁面滾動條。

我們一般可以兩個方法去拖拽，一個是根據(jù)拖拽的坐標(biāo)（像素單位），另外一個是根據(jù)拖拽到一個參考元素附件。

如何實(shí)現(xiàn)文件上傳？

我們在 web 頁面實(shí)現(xiàn)文件上傳過程中，可以直接把文件在磁盤完整路徑，通過sendKeys 方法實(shí)現(xiàn)上傳。如果這種方法不能實(shí)現(xiàn)上傳，我們就可能需要借助第三方工具，我用過一個第三方工具叫 autoIT.

你是如何管理你的測試用例并執(zhí)行？

寫用例和管理并執(zhí)行用例，我們都需要借助單元測試框架來實(shí)現(xiàn)，如果是Java語言一般有junit和TestNG，如果是python，常見的有unittest。

就你實(shí)際情況，說一下。例如我使用TestNG比較多，需要配置testng.xml文件來實(shí)現(xiàn)測試用例的執(zhí)行。有時候需要配置多個testng.xml去實(shí)現(xiàn)不同的任務(wù)場景。再展開，可能問你一下testng框架的知識點(diǎn)。例如，方法依賴，用例執(zhí)行優(yōu)先級，數(shù)據(jù)源驅(qū)動等。

關(guān)于自動化測試報(bào)告生成？

我個人一般用TestNG原生的測試報(bào)告，也有第三方叫reportNG的插件，不過我沒有實(shí)際使用過。

Python下報(bào)告生成一般使用HTMLTestRunner.py

哪些自動化測試工具

Appium

官網(wǎng)：Appium

AppUI自動化測試

Appium 是一個移動端自動化測試開源工具，支持iOS 和Android 平臺，支持Python、Java 等語言，即同一套Java Python 腳本可以同時運(yùn)行在iOS 和Android平臺，Appium 是一個C/S 架構(gòu)， 核心是一個 Web 服務(wù)器，它提供了一套 REST 的接口。當(dāng)收到[客戶端]()的連接后，就會監(jiān)聽到命令，然后在移動設(shè)備上執(zhí)行這些命令，最后將執(zhí)行結(jié)果放在 HTTP 響應(yīng)中返還給[客戶端]()。

License：免費(fèi)

Selenium

官網(wǎng)：Selenium

WebUI自動化測試

Selenium是一個用于Web應(yīng)用程序測試的工具，Selenium已經(jīng)成為 Web 自動化測試工程師能包括：測試與瀏覽器的兼容性——測試你的應(yīng)用程序看是否能夠很好得工作在不同瀏覽器和操作系統(tǒng)之上。測試系統(tǒng)功能——創(chuàng)建回歸測試檢驗(yàn)軟件功能和用戶需求。支持自動錄制動作和自動生成 .Net、Java、Perl等不同語言的測試腳本。Selenium 是 ThoughtWorks 專門為 Web 應(yīng)用程序編寫的一個驗(yàn)收測試工具。其升級版本為Webdriver。

License：免費(fèi)

Postman

官網(wǎng)：Postman

接口測試

Postman 提供功能強(qiáng)大的 Web API 和 HTTP 請求的調(diào)試，它能夠發(fā)送任何類型的HTTP 請求 (GET, POST, PUT, DELETE…)，并且能附帶任何數(shù)量的參數(shù)和 Headers。不僅如此，它還提供測試數(shù)據(jù)和環(huán)境配置數(shù)據(jù)的導(dǎo)入導(dǎo)出，付費(fèi)的 Post Cloud 用戶還能夠創(chuàng)建自己的 Team Library 用來團(tuán)隊(duì)協(xié)作式的測試，并能夠?qū)⒆约旱臏y試收藏夾和用例數(shù)據(jù)分享給團(tuán)隊(duì)。

License：免費(fèi)

Jmeter

官網(wǎng)：Jmeter

接口測試，性能測試

JMeter是Apache組織的開放源代碼[項(xiàng)目]()，它是功能和性能測試的工具，100%的用java實(shí)現(xiàn)；

JMeter可以用于測試靜態(tài)或者動態(tài)資源的性能（文件、Servlets、Perl腳本、java對象、數(shù)據(jù)庫和查詢、ftp服務(wù)器或者其他的資源）。JMeter用于模擬在服務(wù)器、網(wǎng)絡(luò)或者其他對象上附加高負(fù)載以測試他們提供服務(wù)的受壓能力，或者分析他們提供的服務(wù)在不同負(fù)載條件下的總性能情況。你可以用JMeter提供的圖形化界面分析性能指標(biāo)或者在高負(fù)載情況下測試服務(wù)器/腳本/對象的行為。

使用Jmeter做接口測試需要注意一點(diǎn)，小心使用“用戶定義變量”，Jmeter組件有優(yōu)先級的，如果多個線程同時執(zhí)行的時候，“用戶定義變量”組件定義的變量可能會亂套。

License：免費(fèi)

Loadrunner

官網(wǎng)：Loadrunner

性能測試

LoadRunner，是一種預(yù)測系統(tǒng)行為和性能的負(fù)載測試工具。通過以模擬上千萬用戶實(shí)施并發(fā)負(fù)載及實(shí)時性能監(jiān)測的方式來確認(rèn)和查找問題，LoadRunner能夠?qū)φ麄€企業(yè)架構(gòu)進(jìn)行測試。企業(yè)使用LoadRunner能最大限度地縮短測試時間，優(yōu)化性能和加速應(yīng)用系統(tǒng)的發(fā)布周期。LoadRunner可適用于各種體系架構(gòu)的自動負(fù)載測試，能預(yù)測系統(tǒng)行為并評估系統(tǒng)性能。

License：商業(yè)

Jenkins

官網(wǎng)：https://jenkins.io

持續(xù)集成

自動化構(gòu)建 編譯，部署，任務(wù)執(zhí)行，測試報(bào)告，郵件通知等。

License：免費(fèi)

智力題

Q：跳臺階問題

Q：4分鐘沙漏和7分鐘沙漏怎么漏出9分鐘

Q：兩個粗細(xì)不同的香，燃盡時間都是1個小時，怎么用這個2根香計(jì)算15分鐘的時間

Q：賽馬

Q：10堆蘋果，每堆10個，9堆每個50g，1堆每個40g，有一個稱，求只稱一次，找出這個輕的一堆

Q：飛機(jī)加油問題

Q：邏輯：四個開關(guān)四個燈泡

Q：地球弧形

測試面試真題

登陸測試

以用戶登錄為例，一般的小白可能只能夠想到一些功能性測試（如下）。

現(xiàn)在，針對“用戶登錄”功能，基于等價類劃分和邊界值分析方法，我們設(shè)計(jì)的測試用例包括： ? ?

• 輸入已注冊的用戶名和正確的密碼，驗(yàn)證是否登錄成功；? ?

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

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

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

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

• 如果登錄功能啟用了驗(yàn)證碼功能，在用戶名和密碼正確的前提下，輸入正確的驗(yàn)證碼，驗(yàn)證是否登錄成功；? ?

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

乍一看，感覺測試案例已經(jīng)夠多了，不過對于一個稍微有點(diǎn)經(jīng)驗(yàn)的工程師，可能會加上下面部分

• 用戶名和密碼是否大小寫敏感；? ?

• 頁面上的密碼框是否加密顯示；? ?

• 后臺系統(tǒng)創(chuàng)建的用戶第一次登錄成功時，是否提示修改密碼；? ?

• 忘記用戶名和忘記密碼的功能是否可用；? ?

• [前端]()頁面是否根據(jù)設(shè)計(jì)要求限制用戶名和密碼長度；? ?

• 如果登錄功能需要驗(yàn)證碼，點(diǎn)擊驗(yàn)證碼圖片是否可以更換驗(yàn)證碼，更換后的驗(yàn)證碼是否可用；? ?

• 刷新頁面是否會刷新驗(yàn)證碼；? ?

• 如果驗(yàn)證碼具有時效性，需要分別驗(yàn)證時效內(nèi)和時效外驗(yàn)證碼的有效性；? ?

• 用戶登錄成功但是會話超時后，繼續(xù)操作是否會重定向到用戶登錄界面；? ?

• 不同級別的用戶，比如管理員用戶和普通用戶，登錄系統(tǒng)后的權(quán)限是否正確；? ?

• 頁面默認(rèn)焦點(diǎn)是否定位在用戶名的輸入框中；? ?

• 快捷鍵Tab 和Enter等，是否可以正常使用。? ?

上述還僅僅只是功能測試，你還可以從其他的角度比如安全性、性能以及兼容性三大方面。在上面所有的測試用例設(shè)計(jì)中，我們完全沒有考慮對非功能性需求的測試，但這些往往是決定軟件質(zhì)量的關(guān)鍵因素。>

安全性測試用例包括

• 用戶密碼后臺存儲是否加密；? ?

• 用戶密碼在網(wǎng)絡(luò)傳輸過程中是否加密；? ?

• 密碼是否具有有效期，密碼有效期到期后，是否提示需要修改密碼；? ?

• 不登錄的情況下，在瀏覽器中直接輸入登錄后的URL地址，驗(yàn)證是否會重新定向到用戶登錄界面；? ?

• 密碼輸入框是否不支持復(fù)制和粘貼；? ?

• 密碼輸入框內(nèi)輸入的密碼是否都可以在頁面[源碼]()模式下被查看；? ?

• 用戶名和密碼的輸入框中分別輸入典型的“SQL注入攻擊”字符串，驗(yàn)證系統(tǒng)的返回頁面；? ?

• 用戶名和密碼的輸入框中分別輸入典型的“XSS跨站腳本攻擊”字符串，驗(yàn)證系統(tǒng)行為是否被篡改；? ?

• 連續(xù)多次登錄失敗情況下，系統(tǒng)是否會阻止后續(xù)的嘗試以應(yīng)對暴力破解；? ?

• 同一用戶在同一終端的多種瀏覽器上登錄，驗(yàn)證登錄功能的互斥性是否符合設(shè)計(jì)預(yù)期；? ?

• 同一用戶先后在多臺終端的瀏覽器上登錄，驗(yàn)證登錄是否具有互斥性。? ?

性能壓力測試用例包括: ? ?

• 單用戶登錄的響應(yīng)時間是否小于3秒；? ?

• 單用戶登錄時，后臺請求數(shù)量是否過多；? ?

• 高并發(fā)場景下用戶登錄的響應(yīng)時間是否小于5秒；? ?

• 高并發(fā)場景下服務(wù)端的監(jiān)控指標(biāo)是否符合預(yù)期；? ?

• 高集合點(diǎn)并發(fā)場景下，是否存在資源死鎖和不合理的資源等待；? ?

• 長時間大量用戶連續(xù)登錄和登出，服務(wù)器端是否存在內(nèi)存泄漏。? ?

兼容性測試用例包括： ? ?

• 不同瀏覽器下，驗(yàn)證登錄頁面的顯示以及功能正確性；? ?

• 相同瀏覽器的不同版本下，驗(yàn)證登錄頁面的顯示以及功能正確性；? ?

• 不同移動設(shè)備終端的不同瀏覽器下，驗(yàn)證登錄頁面的顯示以及功能正確性；? ?

• 不同分辨率的界面下，驗(yàn)證登錄頁面的顯示以及功能正確性。? ?

微信紅包測試

單個紅包： ? ?

• 紅包金額為空、0、0.01、200.00、200.01、199.99、200 ? ?

• 留言輸入數(shù)字、字母、漢字、特殊字符 ? ?

• 留言長度 ? ?

• 留言復(fù)制粘貼 ? ?

• 表情選擇收藏表情、其他表情 ? ?

• 刪除表情、重新選擇表情 ? ?

• 選擇支付方式 零錢、銀行卡、添加新卡支付。其中錢數(shù)<紅包錢數(shù)、其中錢數(shù)=紅包錢數(shù)、其中錢數(shù)>紅包錢數(shù) ? ?

• 使用指紋確認(rèn)付款（正確的、錯誤的指紋） ? ?

• 使用密碼確認(rèn)付款（正確的、錯誤的密碼） ? ?

• 紅包成功發(fā)送后 相應(yīng)支付方式中錢數(shù)減少（減少金額與紅包金額一致） ? ?

• 接受者能看到紅包具體信息，紅包金額、留言、表情均能正確顯示 ? ?

• 紅包被拆開后顯示已領(lǐng)取，領(lǐng)取者零錢中增加正確金額，再次領(lǐng)取只能查看紅包信息 ? ?

• 發(fā)紅包者自己領(lǐng)紅包 ? ?

• 紅包24小時未被領(lǐng)取提示紅包被退回，相應(yīng)支付方式中錢數(shù)增加（增加金額與紅包金額一致），對方不能領(lǐng)紅包 ? ?

群發(fā)紅包-普通紅包：（只寫了與單個紅包不同的地方）

• 紅包個數(shù) 為空、0、001、100、99、101 ? ?

• 紅包拆開每個金額一樣 均為發(fā)紅包時設(shè)置的單個金額對應(yīng)的錢數(shù) ? ?

• 紅包被拆時，有相應(yīng)提示 ? ?

• 發(fā)紅包者自己領(lǐng)紅包 ? ?

• 紅包24小時內(nèi)未被拆完，剩余錢被退回，相應(yīng)支付方式中錢數(shù)增加 ? ?

群發(fā)紅包-拼手氣紅包： ? ?

• 紅包每個人拆開金額不同，總金額與發(fā)紅包設(shè)置的總額一致 ? ?

• 紅包24小時內(nèi)拆完后顯示最佳手氣 ? ?

• 紅包24小時內(nèi)未被拆完不顯示最佳手氣

兼容性測試

兼容性： ? ? 安卓、蘋果 不同型號版本手機(jī)

UI測試： ? ? 界面無錯別字，風(fēng)格統(tǒng)一

中斷測試： ? ? 不同應(yīng)用之間切換、斷網(wǎng)、來電、短信、低電量、手機(jī)沒電

網(wǎng)絡(luò)測試： ? ? 2g/3g/4g WiFi 移動聯(lián)通電信 弱網(wǎng) 無網(wǎng)

微信朋友圈測試用例

朋友圈發(fā)送功能

• 只發(fā)送文本 ? ?

a、考慮文本長度：1-1500字符（該數(shù)據(jù)為[百度]()數(shù)據(jù)）、超出最大字符長度

b、文本是否支持復(fù)制粘貼

c、為空驗(yàn)證

• 只發(fā)送圖片 ? ?

a、本地相冊選擇/拍攝

b、圖片數(shù)量驗(yàn)證：1-9張圖片、超出9張

c、為空驗(yàn)證

• 只發(fā)送視頻 ? ?

a、本地相冊選擇/拍攝

b、視頻秒數(shù)驗(yàn)證：1-10s，超出10s

c、視頻個數(shù)驗(yàn)證：1個，超出1個

d、視頻格式驗(yàn)證：支持的視頻格式，例mp4、不支持的視頻格式

e、視頻大小驗(yàn)證：蘋果400kb以內(nèi)、Android200-300kb（此為[百度]()數(shù)據(jù)）、超出規(guī)定大小

f、視頻預(yù)覽增刪改操作

g、為空驗(yàn)證

• 發(fā)送文本+圖片：輸入滿足要求的文本、圖片進(jìn)行一次驗(yàn)證 ? ?

• 發(fā)送圖片+視頻：不支持發(fā)送 ? ?

• 朋友圈發(fā)送內(nèi)容是否有限制，例如涉及黃賭毒等敏感字 ? ?

• 所在位置 ? ?

a、不顯示位置：發(fā)送到朋友圈動態(tài)不顯示位置

b、選擇對應(yīng)位置：搜索支持、自動定位、手動編輯

C、點(diǎn)擊取消，返回上一級頁面

• 誰可以看 ? ?

a、設(shè)置公開：所有朋友可見

b、設(shè)置私密（僅自己可見）：自己查看朋友圈-可見、好友查看朋友圈-不可見

c、設(shè)置部分可見（部分朋友可見）：選擇的部分好友-可見、不被選擇的好友-不可見、是否有人數(shù)上限

d、設(shè)置不給誰看（選中的朋友不可見）：不被選中的朋友-可見、被選中的朋友-不可見、是否有人數(shù)上限

e、點(diǎn)擊取消，返回發(fā)送頁面

• 提醒誰看 ? ?

a、提醒單人/提醒多人：被提醒的朋友-收到消息提醒、未被提醒-未有消息提醒

b、是否有人數(shù)上限

c、點(diǎn)擊取消，返回發(fā)送頁面

• 同步QQ空間：默認(rèn)不同步、同步到QQ空間

• 取消發(fā)送朋友圈操作

a、選擇相機(jī)，點(diǎn)擊取消，返回朋友圈頁面

b、進(jìn)入朋友圈發(fā)送頁面，選擇文本圖片，點(diǎn)擊取消

13）朋友圈當(dāng)天發(fā)送次數(shù)是否有上限限制

朋友圈瀏覽功能

• 文本查看：? ?

a、過長文本內(nèi)容是否隱藏，并支持查看全文

b、右鍵選擇復(fù)制、收藏、翻譯

c、url鏈接是否支持點(diǎn)擊跳轉(zhuǎn)網(wǎng)頁

• 圖片查看 ? ?

a、小圖右鍵支持收藏/編輯

b、點(diǎn)擊支持大圖瀏覽

c、選擇發(fā)送給朋友、收藏、保存圖片、編輯

d、多張圖片支持左右滑動瀏覽

• 視頻查看 ? ?

a、右鍵視頻支持靜音播放/搜藏

b、點(diǎn)擊視頻播放按鍵支持播放視頻

c、選擇發(fā)送給朋友、收藏、保存視頻、編輯

• 分享動態(tài)瀏覽：QQ空間/公眾號文章/非[騰訊]()產(chǎn)品分享后朋友圈是否正常顯示

• 贊：點(diǎn)贊、取消點(diǎn)贊

• 評論

a、評論長度：評論字?jǐn)?shù)合理長度、評論超過字?jǐn)?shù)上限

b、評論類型：純中文、純數(shù)字、純字母、純字符、純表情（微信表情/手機(jī)自帶表情）、混合類型、包含url鏈接；

c、評論是否支持復(fù)制粘貼

d、為空驗(yàn)證

e、發(fā)表評論后刪除

f、評論回復(fù)操作

• 刪除朋友圈動態(tài)

• 更換相冊封面

• 刷新是否正常獲取新動態(tài)

• 上滑是否加載更多

界面/易用性測試 ? ?

1、技術(shù)人員角度：頁面布局設(shè)計(jì)是否跟產(chǎn)品原型圖/ui效果圖一致

2、但除了考慮1之外，我們同樣要考慮到用戶使用：功能操作是否簡便，頁面布局排版風(fēng)格是否美觀合理，提示語相關(guān)信息是否易于理解

中斷測試 ? ?

1、主要考慮：a)核心功能 b)當(dāng)前功能存在實(shí)時數(shù)據(jù)交換，例發(fā)朋友圈、瀏覽朋友圈進(jìn)行中斷，是否容易出現(xiàn)崩潰

2、中斷包括：前后臺切換、鎖屏解鎖、斷網(wǎng)重連、app切換、來電話/來短信中斷、插拔耳機(jī)線/數(shù)據(jù)線

網(wǎng)絡(luò)測試 ? ?

1、三大運(yùn)營商不同網(wǎng)絡(luò)制式測試

2、網(wǎng)絡(luò)切換測試：WIFI/4G/3G/2G

3、無網(wǎng)測試：對于緩存在本地的數(shù)據(jù)，部分朋友圈信息是否支持瀏覽

4、弱網(wǎng)測試：

a、延時：頁面響應(yīng)時間是否可接受、不同網(wǎng)絡(luò)制式是否區(qū)分超時時長、出現(xiàn)請求超時，是否給予相應(yīng)的提示

b、丟包：有無超時重連機(jī)制、如果未響應(yīng)，是否給予相應(yīng)提示

c、頁面呈現(xiàn)的完整性驗(yàn)證

兼容性測試 ? ?

1、Android手機(jī)端、蘋果手機(jī)端、pad版（主流）功能界面顯示是否正常

2、各平臺朋友圈展示數(shù)據(jù)是否一致

安全測試 ? ?

發(fā)送朋友圈時，文本輸入腳本代碼，是否出現(xiàn)異常

性能測試 ? ?

1、服務(wù)器性能測試

可通過loadrunner/jmeter工具實(shí)現(xiàn)，主要關(guān)注TPS、響應(yīng)時間、吞吐量、CPU、內(nèi)存等

2、app客戶端性能測試

可通過GT工具實(shí)現(xiàn)，運(yùn)行時關(guān)注cpu、內(nèi)存、流量、電量等占用率

3、app壓力穩(wěn)定性測試

通過monkey工具實(shí)現(xiàn)，頻繁發(fā)送朋友圈，瀏覽朋友圈請求，是否容易發(fā)生崩潰

測試一個輸入框(計(jì)數(shù))

相信不少朋友在筆試的時候都遇到過測試用例設(shè)計(jì)的筆試題。通常是一個登陸頁面，上面有用戶名，密碼的輸入框，再多一點(diǎn)的有個驗(yàn)證碼。

不過要是你見到的是以下的這道測試用例設(shè)計(jì)筆試題，不用問，面試官一定是看過《Google軟件測試之道》的。（也腦補(bǔ)一下，萬一面試官是看過CC先生的簡書呢…… 嗯嗯，夢想還是要有的）

出題時間： ? ?

在一個Web測試頁面上，有一個輸入框，一個計(jì)數(shù)器（count）按鈕，用于計(jì)算一個文本字符串中字母a出現(xiàn)的個數(shù)。這里的問題是，請?jiān)O(shè)計(jì)一系列測試用例用以測試這個Web頁面。

很多朋友可能拿到這道題的時候已經(jīng)開始寫下1.2.3.了，不過根據(jù)經(jīng)驗(yàn)上來說，追求數(shù)量而非質(zhì)量的傾向，是一種低效的工作方式。（特別在有面試官在旁邊看到你答題的時候，請保持沉思者狀保持10-15秒）

能夠針對題目提出一些問題來的候選者會被認(rèn)為更有潛質(zhì)來做測試人員，比如大寫還是小寫？只是英語嗎？計(jì)算完成后文本會被清除嗎？多次按下按鈕會發(fā)生什么事情？諸如此類。

通常說來，我們考慮一個測試對象的時候至少從以下六方面來考慮。

• 功能性

• 易用性

• 可靠性

• 性能

• 安全

• 兼容性

如果你是一個測試菜鳥，從功能性出發(fā)，你可能會列出以下一個典型的列表：

• “banana”：3（一個合法的英文字）。

• “A” 和“a”：1（一個簡單有正常結(jié)果的合法輸入）。

• “”：0（一個簡單的結(jié)果為0的合法輸入）。

• Null：0（簡單的錯誤輸入）。

• “AA” 和“aa”：2（個數(shù)大于1并且所有字符都為a/A的輸入）。

• “b”：0（一個簡單的非空合法輸入，結(jié)果為0）。

• “aba”：2（目標(biāo)字符出現(xiàn)在開頭和結(jié)尾，以尋找循環(huán)邊界錯誤）。

• “bab”：1（目標(biāo)字符出現(xiàn)在中間）。

• space/tabs：N（空白字符與N個a的混合）。

• 不包含a的長字符串：N（N大于0）。

• 包含a的長字符串：N（N是a的倍數(shù)，試試龍媽的名字）。

{java/C/HTML/[JavaScript]()}：N是a出現(xiàn)的個數(shù)（可執(zhí)行字符，或錯誤，或代碼解釋）。

更優(yōu)秀的測試工程師，會開始考慮后面五個方面，設(shè)計(jì)以下用例。

• 質(zhì)疑界面的外觀、調(diào)色板和對比度（這與相關(guān)應(yīng)用風(fēng)格一致么？）

• 文本框太小了，建議加長以便顯示更長的輸入字符串

• 這個應(yīng)用能否在同一臺服務(wù)器上運(yùn)行多個實(shí)例，多個用戶同時使用是否會有問題。

• 是否會根據(jù)用戶的輸入自動匹配內(nèi)容？

• 建議使用真實(shí)的數(shù)據(jù)，如從詞典或書中選擇輸入內(nèi)容。

• 提出疑問：“輸入的數(shù)據(jù)是否會被保存”，輸入字符串可能包含地址或其他身份信息。

• 輸入HTML和JavaScrip，看是否會破壞頁面渲染。

• 嘗試復(fù)制/粘貼字符串。

• 提出疑問：“計(jì)算足夠快么？在大并發(fā)下使用”。

• 提出疑問：“用戶怎么找到該頁面？”

• 提出疑問：“有快捷鍵的設(shè)置么？比如輸完字符后敲入回車鍵而不是點(diǎn)擊提交按鈕”

還有一些測試點(diǎn)，只有經(jīng)驗(yàn)豐富的測試工程師才會想到。

• 意識到計(jì)算會通過URL-encodedHTTP GET請求傳遞到服務(wù)器，字符串可能會在網(wǎng)絡(luò)傳輸時被截?cái)啵虼耍瑹o法保證支持多長的URL。

• 建議將此功能參數(shù)化，為什么只對字母a計(jì)算呢？

• 考慮計(jì)算其它語言中的a（α，Alpha）。

• 考慮到該應(yīng)用是否應(yīng)該國際化。

• 考慮到輸入法全角輸入和半角輸入是否相同。

• 考慮編寫腳本或者手工采樣來探知字符串長度的上限，然后確保在此區(qū)間內(nèi)功能正常。

• 考慮背后的實(shí)現(xiàn)和代碼。也許已經(jīng)有一個計(jì)數(shù)器遍歷該字符串。

• 提出疑問：“HTTP POST方法和參數(shù)會被黑掉碼？也許有安全漏洞？”

• 用腳本創(chuàng)建各種有趣的排列組合和字符串特性，如長度、a的個數(shù)等，自動生成測試輸入和驗(yàn)證。

測試百度搜索

我們可以從以下幾個角度進(jìn)行測試。

功能測試：

輸入搜索信息，點(diǎn)擊搜索按鈕是否能獲取搜索結(jié)果，跳到結(jié)果界面；?搜索結(jié)果界面彈出的信息是不是符合我輸入的信息 ， 沒有輸入信息，按搜索看會有什么結(jié)果 ，對輸入框能輸入的最大字符數(shù)進(jìn)行邊界測試，（假設(shè)限制是30個字符），那么分別輸入20，30，31個字符的文本進(jìn)行測試，測試超出輸入限制會出現(xiàn)的結(jié)果

測試輸入敏感詞時的搜索結(jié)果，輸入不同國家語言的搜索結(jié)果 ，查詢不到搜索結(jié)果的情況顯示的結(jié)果，從搜索結(jié)果界面返回的按鈕能不能正常返回

點(diǎn)擊[百度]()的標(biāo)簽?zāi)懿荒芴较嚓P(guān)的熱搜界面

測試[百度]()的圖片搜索能不能正常使用

圖片拖曳和上傳的功能是否均能實(shí)現(xiàn)，粘貼圖片網(wǎng)址能不能用

如果粘貼的圖片網(wǎng)址不存在是否能給出正確的提示反饋

輸入特別大的圖會發(fā)生什么現(xiàn)象

性能測試：

測試搜索時的響應(yīng)時間能否符合需求

網(wǎng)速慢的條件下還能不能正常搜索

多用戶同時訪問，或者一個時間點(diǎn)訪問量突然增大的情況，對這些特殊情況進(jìn)行模擬，測試還能不能進(jìn)行正常搜索

易用性測試：

使用操作是否簡單，是不是輸入查詢信息之后點(diǎn)擊搜索按鈕就行了；

在輸入框輸入搜索詞的過程中下拉框能否彈出相關(guān)的[聯(lián)想]()搜索（你可能要搜）

輸入框有沒有保存最近搜索的信息的記錄

除了點(diǎn)擊搜索按鈕進(jìn)行搜索，測試按回車進(jìn)行檢索的功能

兼容性測試：

多種系統(tǒng)下的多種不同的瀏覽器下是否能正常顯示、正常使用；

在不同的手機(jī)瀏覽器中打開是否能正常顯示、正常使用；

各種語言平臺下是否都能正常使用

安全性測試：

能不能防止搜索時對數(shù)據(jù)庫的惡意攻擊的情況，如SQL注入

UI

界面設(shè)計(jì)是否簡介，是否符合用戶審美

圖標(biāo)能不能正常顯示，界面有無錯別字

BUG描述、評級

對bug的描述盡量簡短但要求清晰，對bug出現(xiàn)的條件進(jìn)行詳細(xì)的描述，包括輸入的測試用例、使用的環(huán)境、有沒有和其他軟件同時運(yùn)行，以及需要寫清bug出現(xiàn)的位置，幫助開發(fā)更好定位。

按照用戶體驗(yàn)（bug是否很嚴(yán)重的影響用戶體驗(yàn)）、影響系統(tǒng)的程度進(jìn)行評級

一條bug記錄的組成

• bug內(nèi)容

• bug發(fā)現(xiàn)時間

• 測試條件（系統(tǒng)配置信息、環(huán)境、軟件版本、瀏覽器版本…）

• 預(yù)期結(jié)果和實(shí)際結(jié)果的對比，相關(guān)的分析

• 如何重現(xiàn)這個bug的步驟

• 這個bug的嚴(yán)重性（會多大程度的影響系統(tǒng)或用戶使用）

• bug發(fā)生的位置

QPS和TPS的區(qū)別

TPS：Transactions Per Second（每秒傳輸?shù)氖挛锾幚韨€數(shù)），即服務(wù)器每秒處理的事務(wù)數(shù)。TPS包括一條消息入和一條消息出，加上一次用戶數(shù)據(jù)庫訪問。

QPS：每秒查詢率QPS是對一個特定的查詢服務(wù)器在規(guī)定時間內(nèi)所處理流量多少的衡量標(biāo)準(zhǔn)

用來衡量服務(wù)器的機(jī)器性能。

是軟件測試結(jié)果的測量單位。

并發(fā)用戶數(shù)和在線用戶數(shù)的區(qū)別

在線用戶數(shù)：用戶同時在一定時間段的在線數(shù)量

并發(fā)用戶數(shù)：某一時刻同時向服務(wù)器發(fā)送請求的用戶數(shù)

（在線用戶只要在線就好了，并發(fā)用戶計(jì)算的是和服務(wù)器有交流的用戶，一般比例5%-20%）

試的階段

測試應(yīng)該盡早進(jìn)行。越早就可以花越少的消耗得到越大的回報(bào)。

書籍

《測試工程師全棧技術(shù)進(jìn)階與實(shí)踐》 茹炳晟

《Google測試之道》

測開高頻手撕代碼

測試開發(fā)崗面試時對代碼能力要求不太高，刷熟劍指offer就可以大膽地去面試?yán)瞺

下面是我總結(jié)的百度美團(tuán)京東等大廠常見的代碼題

1.將一個只含有-1和1的亂序數(shù)組變成-1全在1前面的數(shù)組
2.合并區(qū)間
3.最小覆蓋子串
4.最長不含重復(fù)字符的字符串
5.翻轉(zhuǎn)單詞順序
6.判斷回文串
7.兩數(shù)之和
8.最長回文子串
9.和為K的子數(shù)組
10.合并兩個有序數(shù)組
11.合并兩個有序鏈表
12.判斷鏈表有環(huán)、環(huán)的位置、環(huán)的長度
13.翻轉(zhuǎn)鏈表
14.奇偶鏈表
15.合并n個有序鏈表
16.去除駝峰字符串
17.統(tǒng)計(jì)一個數(shù)字在排序數(shù)組中的出現(xiàn)次數(shù)
18.輸入YYYY-MM-DAY 判斷是當(dāng)年的第多少天
19.括號匹配
20.判斷是否為合法字符
21，冒泡排序歸并排序 快速排序
22.最長連續(xù)數(shù)列
23.給出數(shù)組的所有子集
24.兩個棧實(shí)現(xiàn)一個隊(duì)列
25.尋找數(shù)組中前三大的值
26.兩個排序數(shù)組找到相同元素

HR常問

• 為什么想做測試

• 對測開的理解

• 測試過程中有沒有出現(xiàn)問題，是如何解決的

• 最近看了什么書？學(xué)了什么？為什么學(xué)？有看什么技術(shù)書籍嗎？

• 個人優(yōu)缺點(diǎn)，舉例

• 測試看重什么能力

• 項(xiàng)目問題細(xì)挖

• 為什么選擇xx公司？

• 你對我們公司有什么了解嗎？

• 之前實(shí)習(xí)收獲了什么

• 介紹下自己的優(yōu)缺點(diǎn)

• 抗壓能力如何，描述一件自己如何抗壓的經(jīng)歷

• 反問環(huán)節(jié)：你有什么問題想問我么？

• 項(xiàng)目中收獲了什么？

• 平時怎么學(xué)習(xí)的

• 為什么要離職？

• 你的期望薪資是多少？

• 如果在測試中發(fā)現(xiàn)一個?Bug?，但是開發(fā)經(jīng)理不認(rèn)為這是一個?Bug?，應(yīng)該怎么解決？

產(chǎn)生這種有爭議的?Bug?的幾個原因有

• 首先可能是測試人員自己的問題，是否描述該bug不太清晰，使得開發(fā)人員難以理解或者產(chǎn)生了歧義，這個時候要修改自己的描述，一定要清晰明了，無歧義，無冗余的步驟

• 其次可能是需求型的bug，找產(chǎn)品經(jīng)理溝通清楚該產(chǎn)品的需求，判斷是測試人員還是開發(fā)人員對該需求判斷有誤

• 還有可能是低概率性的?Bug?，出現(xiàn)了難以復(fù)現(xiàn)的?Bug?，這個時候要結(jié)合嚴(yán)重性、頻繁性、對用戶的影響以及產(chǎn)品交付時間與開發(fā)共同衡量是否修復(fù)該?Bug?，即使是選擇暫不修復(fù)，也需要將該?Bug?詳細(xì)地提交備案

• 為什么想要做測試？

• 你覺得你做測試的優(yōu)勢在哪里？

• 怎么看待測試中重復(fù)性工作較多的問題

• 談?wù)勀銓y試的理解

• 你的職業(yè)規(guī)劃

• 如何理解測試和測試開發(fā)？

• 測試就是在規(guī)定條件下檢測產(chǎn)品功能或者程序上的錯誤，對其是否滿足設(shè)計(jì)要求進(jìn)行評估。

• 測試開發(fā)需要開發(fā)一些自動化測試的平臺或者二次開發(fā)一些現(xiàn)有的開源工具，最終目的是提升測試效率，但是核心職能仍然是測試。

• 如果遇到一些低概率性的?Bug?會怎么辦？

首先要認(rèn)真記錄引發(fā)該?Bug?的情況（當(dāng)時的測試環(huán)境、測試數(shù)據(jù)、出現(xiàn)問題前的操作），不應(yīng)該在測試報(bào)告中因?yàn)槌霈F(xiàn)概率低而忽略這些?Bug?的存在

其次，會根據(jù)嚴(yán)重性、頻繁性、對用戶的影響這三個因素共同做決定，嚴(yán)重性就是判斷該bug是否導(dǎo)致嚴(yán)重的后果，比如是不是會讓整個程序崩潰？會導(dǎo)致用戶信息丟失嗎？還是僅僅是無關(guān)痛癢的小問題？；頻繁性就是指在用戶使用的過程中是否會經(jīng)常碰到該類問題？還是這個 Bug 出現(xiàn)在某些不太常用的功能中；對用戶的影響是指是否會影響到全部用戶的使用？還是只影響部分用戶的使用？（比如說這個?Bug?所在的程序如果只出現(xiàn)在app的舊版本中，那么它對用戶的影響就很小）

綜合上面幾點(diǎn)聯(lián)合考慮，然后視產(chǎn)品發(fā)布日期來決定，如果產(chǎn)品發(fā)布日期臨近，修改一些不太嚴(yán)重、出現(xiàn)不太頻繁的?Bug?反而可能得不償失，帶來其他的風(fēng)險(xiǎn)，因此此時僅僅將該?Bug?備案，其他情況下還是需要盡力定位、修復(fù)該bug。

• 項(xiàng)目最終結(jié)果不符合預(yù)期怎么辦？

• 作為一個測試開發(fā)工程師，要參與哪些流程？