🍅?點(diǎn)擊文末小卡片，免費(fèi)獲取軟件測試全套資料，資料在手，漲薪更快???

一、軟件測試基礎(chǔ)面試題

1、闡述軟件生命周期都有哪些階段? 常見的軟件生命周期模型有哪些?

軟件生命周期是指一個(gè)計(jì)算機(jī)軟件從功能確定設(shè)計(jì)，到開發(fā)成功投入使用，并在使用中不斷地修改、增補(bǔ)和完善，直到停止該軟件的使用的全過程(從醞釀到廢棄的過程)

生命周期從收到應(yīng)用軟供開始算起，到該軟件不再使用為止。

它有如下各方面的內(nèi)容：

初始構(gòu)思、需求分析、功能設(shè)計(jì)、內(nèi)部設(shè)計(jì)、文檔計(jì)劃、測試計(jì)劃、文檔準(zhǔn)備、集成、測 試、維護(hù)升級(jí)、再測試、逐步淘汰 (phase-out)、等等

常見的軟件生命周期模型：

瀑布模型，迭代式模型，快速原型模型，螺旋模型

2、什么是版本控制，常用的版本控制系統(tǒng)有哪些?

版本控制 (Revision control) 是一種軟件工程技巧，在在開發(fā)的過程中，確保由不同人所編輯的司一文件都得到更新及歷史記錄的保存。Git(讀音為/git/。)是一個(gè)開源的分布式版本控制系統(tǒng)，可以有效、高速的處理從很小到非常大的項(xiàng)目版本管理。?

Git 是 Linus Torvalds 為了幫助管理 Linux 內(nèi)核開發(fā)而開發(fā)的一個(gè)開放源碼的版本控制軟件。?https://git-scm.com/docSVN 是 Subversion 的簡稱，是一個(gè)開放源代碼的版本控制系統(tǒng)，相較于 RCS、CVS，它采用了分支管理系統(tǒng)，它的設(shè) 計(jì)目標(biāo)就是取代CVs .互聯(lián)網(wǎng)上很多版本控制服務(wù)已從CVs 遷Subversion移https://tortoisesvn.net/support.htm

3、簡述軟件測試與軟件開發(fā)之間的關(guān)系?

1.項(xiàng)目規(guī)劃階段:負(fù)責(zé)從單元測試到系統(tǒng)測試的整個(gè)測試階段的監(jiān)控。

2.需求分析階段:確定測試需求分析、系統(tǒng)測試計(jì)劃的制定，評審后成為管理項(xiàng)目。測試需求分析是對產(chǎn)品生命周期中測試所需求的資源配置、每階段評判通過的規(guī)約，系統(tǒng)測試計(jì)劃則是依據(jù)軟件的需求規(guī)格說明書，制定測試計(jì)劃和設(shè)計(jì)相應(yīng)的測試用例。

3.詳細(xì)設(shè)計(jì)和概要設(shè)計(jì)階段: 確保集成測試計(jì)劃和單元測試計(jì)劃完成。

4.編碼階段: 由開發(fā)人員進(jìn)行自己負(fù)責(zé)部分的代碼的測試。在項(xiàng)目較大時(shí)，由專人進(jìn)行編碼階段的測試任務(wù)

5.測試階段(單元、集成、系統(tǒng)測試) :?

依據(jù)測試代碼進(jìn)行測試，并提交相應(yīng)的測試狀態(tài)報(bào)告和測試結(jié)束報(bào)告開發(fā)和測試是一個(gè)有機(jī)的整體!在產(chǎn)品的發(fā)布之前，開發(fā)和測試是循環(huán)進(jìn)行的， 測出的缺陷要經(jīng)開發(fā)人員修改后繼續(xù)測試。在開發(fā)的同時(shí)測試經(jīng)理開始編寫測試用例，測 試文檔要參考開發(fā)文檔，所以開發(fā)和測試是不可分割的，少了任何一個(gè)都不能開發(fā)出產(chǎn)品。從角色方面看，像理論和實(shí)驗(yàn)的關(guān)系，開發(fā)人員通過自己的想象創(chuàng)造出一套思想，之 后測試人員再對它進(jìn)行檢驗(yàn)、證偽，開發(fā)人員再修改的過程從而不斷豐富產(chǎn)品。

從方法方 面看，是演繹和歸納的關(guān)系，一個(gè)要掌握大量的技術(shù)一個(gè)要不斷的從實(shí)例中學(xué)習(xí)。因這 兩方面的不司，所以開發(fā)和測試看上去做的工作很不一樣開發(fā)與測試是相輔相承、密不可分的，開發(fā)人員開發(fā)出新的產(chǎn)品后要通過測試判斷產(chǎn) 品是否完全滿足用戶的需求。如果發(fā)現(xiàn)缺陷，提交給開發(fā)人員進(jìn)行修復(fù)，然后再轉(zhuǎn)交測試 人員進(jìn)行回歸測試，直到產(chǎn)品符合需求規(guī)格說明。符合用戶需求的產(chǎn)品是開發(fā)和測試 共同努力的成果

4、請根據(jù)”V”模型分別概述測試人員在軟件的需求定

義階段、設(shè)計(jì)階段、編碼階段、系統(tǒng)集成階段的工作任務(wù)及其相應(yīng)生成的文檔?

需求定義階段:根據(jù)項(xiàng)目需求提取測試需求 并形成測試需求文檔，根據(jù)提取的測試需求和項(xiàng)目計(jì)劃進(jìn)行測試計(jì)劃的擬定，測試計(jì)劃文檔

設(shè)計(jì)階段: 根據(jù)測試需求擬訂測試方案并形成測試方案文檔，根據(jù)測試方案制定測試用例，并形成測試用例文檔

編碼階段:執(zhí)行測試并完善測試用例文檔

系統(tǒng)集成階段:測試總結(jié)報(bào)告，階段問題統(tǒng)計(jì)報(bào)告，測試問題報(bào)告

5、W 模型的描述?

W 模型也稱之為雙V 模型，一個(gè)V 是開發(fā)的生命同期，另一個(gè)V 是測試的生命周期，W 模型與V模型有一個(gè)很大的不同，就是W 模型是一個(gè)并行的模型，V 模型是一個(gè)串行的模型，W 模型開始是從需求分析開始就開始了，而不是等到編碼完成后才開始。

并且測試階段的劃分更清楚，而不僅僅是單元測試、集成測試、系統(tǒng)測試，還包括前期的測試計(jì)劃、測試方案等內(nèi)容，這更符合現(xiàn)在企業(yè)測試的流程。W 模型強(qiáng)調(diào)測試伴隨著整個(gè)軟件開發(fā)周期，而且測試的對象不僅僅是程序需求、設(shè)計(jì)等同樣要測試，也就是說，測試與開發(fā)是同步進(jìn)行的。W 模型有利于盡早全面地發(fā)現(xiàn)問題。

從需求分析開始測試工程師就參與到項(xiàng)目的測試中，當(dāng)需求分析完成后，測試工程師就需要參與到需求的驗(yàn)證和確認(rèn)活動(dòng)中，并需要提供可測試性需求分析說明書，這樣可以盡早地發(fā)現(xiàn)需求階段的缺陷。同時(shí)，對需求的測試也有利子及時(shí)了解項(xiàng)目難度和測試風(fēng)險(xiǎn)，及早制定應(yīng)對指施，這將顯著減少總體測試時(shí)間，加快項(xiàng)目進(jìn)度。

但W 模型也存在局限性，需求、設(shè)計(jì)、編碼等活動(dòng)被視為是串行的，同時(shí)，測試和開發(fā)活動(dòng)也保持著一種線性的前后關(guān)系，上一階段完全結(jié)束，才可正式開始下一階段工作，這樣就無法支持迭代的開發(fā)模型。對于當(dāng)前軟件開發(fā)復(fù)雜多變的情況，W 模型并不能解除測試管理面臨的床惑。

總之W 模型具有以下特征：

(1)測試階段戈分得更全面，不僅僅是單元測試、集成測試和系統(tǒng)測試，

(2)測試與開發(fā)是并行的，從需求測試就應(yīng)該開始介入

(3)提出盡早測試的概念，這樣可以險(xiǎn)低缺陷修復(fù)成本;

(4)測試對象不僅僅是程序，還包括需求或其他的相關(guān)文檔

6、編寫測試計(jì)劃的目的是?

使測試工作順利進(jìn)行，使項(xiàng)目參與人員溝通更舒暢，使測試工作更加系統(tǒng)化

7、測試計(jì)劃編寫的六要素?

why一一為什么要進(jìn)行這些測試

what一測試哪些方面，不同階段的工作內(nèi)容

when一測試不同階段的起止時(shí)間

where一相應(yīng)文檔，缺陷的存放位置，測試環(huán)境等

who一項(xiàng)目有關(guān)人員組成，安排哪些測試人員進(jìn)行測試

how一如何去做，使用哪些測試工具以及測試方法進(jìn)行測試。

8、項(xiàng)目版本執(zhí)行過程中，測試人員如何把控測試進(jìn)度?

在項(xiàng)目的系統(tǒng)測試過程中，測試負(fù)責(zé)人要及時(shí)了解測試進(jìn)度，跟蹤 BUG 提交、修復(fù)及驗(yàn)證情況以及系統(tǒng)的拷機(jī)情況。在開發(fā)初期階段，測試組執(zhí)行BBFV 時(shí)，很多模塊、功能點(diǎn)的開發(fā)完成進(jìn)度和原計(jì)劃會(huì)存在一定的偏差，就需要測試負(fù)責(zé)人動(dòng)態(tài)的刷新WBS 計(jì)劃，根據(jù)實(shí)際的開發(fā)進(jìn)度調(diào)整測試計(jì)劃。

在開發(fā)階段，存在版本編譯不出來導(dǎo)致無法測試，開發(fā)人員修復(fù)代碼太隨意導(dǎo)致版本穩(wěn)定性反復(fù)，需求變更過大導(dǎo)致后端測試開發(fā)變更嚴(yán)重等現(xiàn)象，會(huì)導(dǎo)致測試工作無法正常進(jìn)行。

就需要測試負(fù)責(zé)人及時(shí)反饋出來，根據(jù)項(xiàng)目本身的特點(diǎn)講行對應(yīng)的處理。當(dāng)測試進(jìn)度出現(xiàn)延期時(shí)，要及時(shí)確認(rèn)問題原因如果是問題協(xié)查導(dǎo)致，則需及時(shí)與研發(fā)人員進(jìn)行溝通協(xié)商，看問題是否必須在測試環(huán)境進(jìn)行排查，若為必現(xiàn)問題可與研發(fā)協(xié)商要求其在自己環(huán)境進(jìn)行排查，若必須占用測試環(huán)境，則需及時(shí)調(diào)整測試計(jì)劃，若因此可能影響版本的發(fā)布，則應(yīng)及時(shí)與 SE 確認(rèn)。

若發(fā)現(xiàn)有較多BUG 未解決，則應(yīng)主動(dòng)聯(lián)系 SE 及研發(fā)人員召開BUG 會(huì)確定問題的解決時(shí)間。若發(fā)現(xiàn)有較多BUG未驗(yàn)證，則應(yīng)提醒項(xiàng)目組的測試人員及時(shí)進(jìn)行驗(yàn)證，對于一些拷機(jī)或非必現(xiàn)的BUG，建議測試人員在此 BUG 上現(xiàn)做拷機(jī)標(biāo)記連續(xù)拷機(jī)一周未再復(fù)現(xiàn)的做關(guān)閉處理，若再次復(fù)現(xiàn)則繼續(xù)進(jìn)行排查。疑難問題的跟控: 比較難復(fù)現(xiàn)的問題，怎么去嘗試復(fù)現(xiàn)。

比較難定位的問題，怎么驅(qū)動(dòng)、反饋給SE，協(xié)調(diào)開發(fā)人員定位問題。比較難處理的問題，怎么跟控反饋進(jìn)度等每天下班前確認(rèn)拷機(jī)內(nèi)容，每天上班第一件事需確認(rèn)拷機(jī)結(jié)果，只有這樣才能保證拷機(jī)的效果，實(shí)現(xiàn)拷機(jī)的真正意義。

9、測試人員在軟件開發(fā)過程中的任務(wù)是什么?

尋找 Bug；避免軟件開發(fā)過程中的缺陷;衡量軟件的品質(zhì)，關(guān)注用戶的需求?？偟哪繕?biāo)是：確保軟件的質(zhì)量。

10、軟件缺陷有哪些？

1）軟件未實(shí)現(xiàn)產(chǎn)品說明書要求的功能

2）軟件出現(xiàn)了產(chǎn)品說明書指明不應(yīng)該出現(xiàn)的錯(cuò)誤

3）軟件實(shí)現(xiàn)了產(chǎn)品說明書未提到的功能

4）軟件未實(shí)現(xiàn)產(chǎn)品說明書雖未明確提及但應(yīng)該實(shí)現(xiàn)的目標(biāo)

5）軟件難以理解、不易使用、運(yùn)行緩慢或者從測試員的角度看最終用戶會(huì)認(rèn)為不好

為了發(fā)現(xiàn)軟件產(chǎn)品中的各種缺陷，而對軟件產(chǎn)品進(jìn)行驗(yàn)證和確認(rèn)的活動(dòng)過程，此過程貫穿整個(gè)軟件開發(fā)生命周期。簡單的說，軟件測試是以發(fā)現(xiàn)錯(cuò)誤為目的而執(zhí)行的一個(gè)程序或系統(tǒng)的過程。

11、你如何理解軟件測試的目的？

• 驗(yàn)證軟件需求和功能是否得到完整實(shí)現(xiàn)

• 驗(yàn)證軟件是否可以發(fā)布

• 盡可能多的發(fā)現(xiàn)軟件中的bug

• 盡可能早的發(fā)現(xiàn)軟件中的bug

• 對軟件質(zhì)量做出合理評估

• 預(yù)防下個(gè)版本可能出現(xiàn)的問題

• 預(yù)防用戶使用可能出現(xiàn)的問題

• 發(fā)現(xiàn)開發(fā)過程中的問題和風(fēng)險(xiǎn)

12、軟件測試有哪些原則?

• 所有測試的標(biāo)準(zhǔn)都是建立在用戶需求之上 。

• 合理控制測試深度與廣度，完全測試不可能，測試的投入與產(chǎn)出要均衡。

• 80-20原則，軟件中80%的bug可以在分析、設(shè)計(jì)與評審階段就能被發(fā)現(xiàn)與修正，16%的缺陷在系統(tǒng)的軟件測試中發(fā)現(xiàn)，最后剩下的4%是用戶長期使用的過程中才能暴露出來。

• 盡可能早的開展測試，越早發(fā)現(xiàn)錯(cuò)誤，修改的代價(jià)越小。

• 發(fā)現(xiàn)錯(cuò)誤較多的程序段，應(yīng)進(jìn)行更深入的測試。

• 軟件項(xiàng)目一啟動(dòng)，軟件測試也就是開始，而不是等程序?qū)懲?#xff0c;才開始進(jìn)行測試 。

• 軟件開發(fā)人員即程序員應(yīng)當(dāng)避免測試自己的程序

• 嚴(yán)格執(zhí)行測試計(jì)劃，排除測試的隨意性，以避免發(fā)生疏漏或者重復(fù)無效的工作

優(yōu)秀測試人員應(yīng)具備的素質(zhì)：

1）溝通能力與表達(dá)能力?

2）好奇心與懷疑精神?

3）責(zé)任感與抗壓能力?

4）自信心，堅(jiān)持自己的觀點(diǎn)

5）耐心與細(xì)心?

6）逆向思維的能力?

7）善于學(xué)習(xí)與總結(jié)?

8）團(tuán)隊(duì)協(xié)作精神?

9）文檔編寫能力

優(yōu)秀測試人員應(yīng)具備的技能：

1）精通業(yè)務(wù)知識(shí)?

2）具備軟件編程能力，比如C,C++,JAVA等。

3）可以用腳本語言編寫小測試工具

4）主流操作系統(tǒng)應(yīng)用與網(wǎng)絡(luò)知識(shí)，可以搭建測試環(huán)境?

5）熟練掌握各種數(shù)據(jù)庫知識(shí)?

6）精通軟件測試?yán)碚撆c方法?

7）掌握常用測試與開發(fā)工具的使用?

8）優(yōu)秀的文檔編寫能力

13、說一說軟件測試的組織架構(gòu)

1）項(xiàng)目型的測試組織：

測試人員作為項(xiàng)目組的固定成員，從頭到尾的跟著項(xiàng)目走

2）智能型的測試組織：

測試人員參與到項(xiàng)目中，是以獨(dú)立的測試部門委派的方式進(jìn)入

3）綜合型的測試組織：

項(xiàng)目型與職能型的結(jié)構(gòu)組合并加以改造而產(chǎn)生的。測試部門把測試人員，分為常規(guī)項(xiàng)目測試人員與專項(xiàng)測試人員。測試部門會(huì)把常規(guī)測試人員長期委派到項(xiàng)目組中，成為項(xiàng)目中的一員。專項(xiàng)測試人員，一般由性能測試工程師、自動(dòng)化測試工程師、安全性測試工程師等組成。只有當(dāng)項(xiàng)目發(fā)生專門需求測試時(shí)，測試部門才靈活把專項(xiàng)測試人員委派到各個(gè)項(xiàng)目組進(jìn)行專項(xiàng)測試。

14、軟件測試常見分類有哪些？

1）按照是否執(zhí)行被測試軟件來分：

靜態(tài)測試：是指不運(yùn)行軟件，測試包括代碼檢查、靜態(tài)結(jié)構(gòu)分析、代碼質(zhì)量度量等，主要對軟件需求說明書、設(shè)計(jì)說明書、軟件源代碼進(jìn)行檢查與分析。

動(dòng)態(tài)測試：指通過運(yùn)行被測程序，檢查運(yùn)行結(jié)果與預(yù)期結(jié)果的差異，分析差異原因，并分析軟件運(yùn)行效率、健壯性等性能。動(dòng)態(tài)測試是目前公司主要的測試方式

2）按照測試技術(shù)分為黑盒測試和白盒測試：

黑盒測試：黑盒測試又叫功能測試或數(shù)據(jù)驅(qū)動(dòng)測試，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，通過軟件的外部表現(xiàn)來發(fā)現(xiàn)其缺陷和錯(cuò)誤。

白盒測試：白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動(dòng)測試，它是按照程序內(nèi)部的結(jié)構(gòu)進(jìn)行測試程序，通過測試來檢測產(chǎn)品內(nèi)部邏輯是否按照設(shè)計(jì)規(guī)格說明書的規(guī)定正常進(jìn)行，檢驗(yàn)程序中的每條通路是否都能按預(yù)定要求正確工作。

3）按照測試手段來分：可以分為手工測試和自動(dòng)化測試

4）按照過程階段來分：可以分為單元測試、集成測試、系統(tǒng)測試和驗(yàn)收測試

單元測試：通過模塊(類/方法/函數(shù))測試，使代碼達(dá)到設(shè)計(jì)要求 主要目的是針對編碼過程中可能存在的各種錯(cuò)誤，例如用戶輸入驗(yàn)證過程中的邊界值的錯(cuò)誤。

集成測試：將經(jīng)過單元測試的模塊逐步組裝成完整的程序。主要目的是檢查各單元與其它程序部分之間的接口是否存在問題，各模塊功能之間是否有影響。

系統(tǒng)測試：是將已經(jīng)確認(rèn)的軟件、計(jì)算機(jī)硬件、外設(shè)、網(wǎng)絡(luò)等其他元素結(jié)合在一起進(jìn)行測試。系統(tǒng)測試是針對整個(gè)產(chǎn)品系統(tǒng)進(jìn)行的測試，目的是驗(yàn)證系統(tǒng)是否滿足了需求規(guī)格的定義，找出與需求規(guī)格不符或與之矛盾的地方 ，進(jìn)行改正。

驗(yàn)收測試：驗(yàn)收測試是在軟件產(chǎn)品完成了單元測試、集成測試和系統(tǒng)測試之后，產(chǎn)品發(fā)布之前所進(jìn)行的最后一次軟件測試活動(dòng)，也稱為交付測試。通常由業(yè)務(wù)專家或用戶進(jìn)行，以確認(rèn)產(chǎn)品能真正符合用戶業(yè)務(wù)上的需要。

15、軟件開發(fā)流程和開發(fā)模型？

軟件生命周期：

計(jì)劃-》需求分析-》設(shè)計(jì)-》程序編寫-》測試-》運(yùn)行/維護(hù)

軟件測試流程：

測試計(jì)劃-》需求分析-》測試用例-》測試用例執(zhí)行-》提交bug-》回歸測試

瀑布模型：適用于需求很明確的項(xiàng)目，分階段向下進(jìn)行，無法回溯

迭代模型：需求不明確，迭代版本系統(tǒng)

敏捷開發(fā)模型：

敏捷開發(fā)是一種以人為核心、迭代、循序漸進(jìn)的開發(fā)方法。在敏捷開發(fā)中，軟件項(xiàng)目被切分成多個(gè)子項(xiàng)目，各個(gè)子項(xiàng)目的成果都經(jīng)過測試，具備集成和可運(yùn)行的特征。換言之，就是把一個(gè)大項(xiàng)目分為多個(gè)相互聯(lián)系，但也可獨(dú)立運(yùn)行的小項(xiàng)目，并分別完成，在此過程中軟件一直處于可使用狀態(tài)。

測試驅(qū)動(dòng)開發(fā)模型：先編寫測試代碼，再寫開發(fā)代碼

16、軟件測試模型有哪些？

V模型：反映了測試與開發(fā)階段之間一一對應(yīng)的特點(diǎn)，測試在開發(fā)之后，出錯(cuò)后回歸測試量大

W模型：測試伴隨整個(gè)開發(fā)周期，測試與開發(fā)同步進(jìn)行，有利于盡早發(fā)現(xiàn)問題

H模型：軟件測試活動(dòng)完全獨(dú)立，與其他流程并行

二、WEB功能測試面試題

1、Student-coures-Studentcourse表關(guān)系如下:

student(sno,sname,age,sdept)學(xué)生表

course(cno,cname,teacher)課程表

Studentcourse(sno,cno,grade)選課表寫出sql語句:

·查詢所有課程都及格的學(xué)生號(hào)和姓名·查詢平均分不及格的課程號(hào)和平均成績

找出各門課程的平均成績，輸出課程號(hào)和平均成績

找出沒有選擇c2課程的學(xué)生信息

2、請說出XHTML和HTML的區(qū)別

1、文檔頂部doctype聲明不同，xhtml的doctype頂部聲明中明確規(guī)定了xhtml DTD的寫法;

2.?html元素必須正確嵌套，不能亂;3、屬性必須是小寫的;

4、屬性值必須加引號(hào);

5、標(biāo)簽必須有結(jié)束，單標(biāo)簽也應(yīng)該用“/”來結(jié)束掉;

3、很多網(wǎng)站不常用table iframe這兩個(gè)元素，知道原因嗎

因?yàn)闉g覽器頁面渲染的時(shí)候是從上至下的，而table和iframe這兩種元素會(huì)改變這樣渲染規(guī)則，他們是要等待自己元素內(nèi)的內(nèi)容加載完才整體渲染。用戶體驗(yàn)會(huì)很不友好。

4、jpg和png格式的圖片有什么區(qū)別?

jpg是有損壓縮格式，png是無損壓縮格式。所以，相同的圖片，jpg體積會(huì)小。

比如我們一些官網(wǎng)的banner圖，一般都很大，所以適合用jpg類型的圖片。

但png分8位的和24位的，8位的體積會(huì)小很多，但在某些瀏覽器下8位的png圖片會(huì)有鋸齒。

5、簡述—下src與href的區(qū)別

瀏覽器會(huì)識(shí)別href引用的文檔并行下載該文檔，并且不會(huì)停止對當(dāng)前文檔的處理

當(dāng)瀏覽器解析到src引|用時(shí)，會(huì)暫停瀏覽器的渲染,直到該資源加載完畢。這也是將js腳本放在底部而不是頭部的原因。

6、:before和::before區(qū)別?

單冒號(hào)(t)用于CSS3偽類，雙冒號(hào)(:)用于CSS3偽元素。

對于CSS2之前已有的偽元素，比如:before，單冒號(hào)和雙冒號(hào)的寫法::before作用是一樣的。

7、如何理解HTML結(jié)構(gòu)的語義化?

所謂標(biāo)簽語義化，就是指標(biāo)簽的含義。語義化的主要目的就是讓大家直觀的認(rèn)識(shí)標(biāo)簽(markup)和屬性(attribute)的用途和作用，對搜索引擎友好，有了良好的結(jié)構(gòu)和語義我們的網(wǎng)頁內(nèi)容便自然容易被搜索引擎抓取，這種符合搜索引擎收索規(guī)則的做法，網(wǎng)站的推廣便可以省下不少的功夫，而且可維護(hù)性更高，因?yàn)榻Y(jié)構(gòu)清晰,十分易于閱讀。這也是搜索引擎優(yōu)化SEO重要的一步。

8、常見的視頻編碼格式有幾種?視頻格式有幾種?

視頻格式:MPEG-1、MPEG-2和MPEG4 、AVl .RM、ASF和WMV格式

視頻編碼格式:H.264、MPEG-4、MPEG-2.WMA-HD以及VC-1

9、JS中null, undefined的區(qū)別?

null表示一個(gè)對象被定義了，但存放了空指針，轉(zhuǎn)換為數(shù)值時(shí)為0。

undefined表示聲明的變量未初始化，轉(zhuǎn)換為數(shù)值時(shí)為NAN。

typeof(null) - object;

typeof(undefined) - undefined

10、什么是sql注入，什么是跨站腳本，什么是跨站請求偽造?

SQL注入攻擊是注入攻擊最常見的形式(此外還有OS注入攻擊( Struts 2的高危漏洞就是通過OGNL實(shí)施OS注入攻擊導(dǎo)致的))，當(dāng)服務(wù)器使用請求參數(shù)構(gòu)造SQL語句時(shí)，惡意的SQL被嵌入到SQL中交給數(shù)據(jù)庫執(zhí)行。SQL注入攻擊需要攻擊者對數(shù)據(jù)庫結(jié)構(gòu)有所了解才能進(jìn)行，攻擊者想要獲得表結(jié)構(gòu)有多種方式：

1. 如果使用開源系統(tǒng)搭建網(wǎng)站，數(shù)據(jù)庫結(jié)構(gòu)也是公開的(目前有很多現(xiàn)成的系統(tǒng)可以直接搭建論壇，電商網(wǎng)站，雖然方便快捷但是風(fēng)險(xiǎn)是必須要認(rèn)真評估的);
2. 錯(cuò)誤回顯（如果將服務(wù)器的錯(cuò)誤信息直接顯示在頁面上，攻擊者可以通過非法參數(shù)引發(fā)頁面錯(cuò)誤從而通過錯(cuò)誤信息了解數(shù)據(jù)庫結(jié)構(gòu)，Web 應(yīng)用應(yīng)當(dāng)設(shè)置友好的錯(cuò)誤頁，一方面符合最小驚訝原則，一方面屏蔽掉可能給系統(tǒng)帶來危險(xiǎn)的錯(cuò)誤回顯信息);
3. 盲注。防范SQL注入攻擊也可以采用消毒的方式，通過正則表達(dá)式對請求參數(shù)進(jìn)行驗(yàn)證，此外，參數(shù)綁定也是很好的手段，這樣惡意的SQL會(huì)被當(dāng)做SQL的參數(shù)而不是命令被執(zhí)行，JDBC中的PreparedStatement 就是支持參數(shù)綁定的語句對象，從性能和安全性上都明顯優(yōu)于Statement。

xss (Cross Site Script，跨站腳本攻擊）是向網(wǎng)頁中注入惡意腳本在用戶瀏覽網(wǎng)頁時(shí)在用戶瀏覽器中執(zhí)行惡意腳本的攻擊方式?？缯灸_本攻擊分有兩種形式:

反射型攻擊（誘使用戶點(diǎn)擊一個(gè)嵌入惡意腳本的鏈接以達(dá)到攻擊的目標(biāo)，目前有很多攻擊者利用論壇、微博發(fā)布含有惡意腳本的URL就屬于這種方式)

持久型攻擊（將惡意腳本提交到被攻擊網(wǎng)站的數(shù)據(jù)庫中，用戶瀏覽網(wǎng)頁時(shí)，惡意腳本從數(shù)據(jù)庫中被加載到頁面執(zhí)行，QQ郵箱的早期版本就曾經(jīng)被利用作為持久型跨站腳本攻擊的平臺(tái))。

CSRF 攻擊(Cross Site Request Forgery，跨站請求偽造)是攻擊者通過跨站請求，以合法的用戶身份進(jìn)行非法操作（如轉(zhuǎn)賬或發(fā)帖等）。CSRF的原理是利用瀏覽器的Cookie或服務(wù)器的Session ,盜取用戶身份，其原理如下圖所示。防范CSRF的主要手段是識(shí)別請求者的身份，主要有以下幾種方式：

1. 在表單中添加令牌(token) ;
2. 驗(yàn)證碼;
3. 檢查請求頭中的Referer (前面提到防圖片盜鏈接也是用的這種方式)。

令牌和驗(yàn)證都具有一次消費(fèi)性的特征，因此在原理上一致的，但是驗(yàn)證碼是一種糟糕的用戶體驗(yàn)，不是必要的情況下不要輕易使用驗(yàn)證碼，目前很多網(wǎng)站的做法是如果在短時(shí)間內(nèi)多次提交一個(gè)表單未獲得成功后才要求提供驗(yàn)證碼，這樣會(huì)獲得較好的用戶體驗(yàn)。

三、APP測試面試題

（1）基礎(chǔ)篇

1、請介紹一下，APP測試流程？

APP測試流程與web測試流程類似，分為如下七個(gè)階段：

1.根據(jù)需求說明書編寫測試計(jì)劃；

2.制定測試方案，主要是測試任務(wù)、測試人員和測試時(shí)間的分配；

3.測試準(zhǔn)備，包括搭建測試環(huán)境，準(zhǔn)備測試數(shù)據(jù)，確定測試方法；

4.測試用例的設(shè)計(jì)與編寫，進(jìn)行用例評審及補(bǔ)充完善；

5.執(zhí)行測試時(shí)首先進(jìn)行冒煙測試，然后對主功能流程進(jìn)行測試，包括客戶端的單個(gè)功能模塊，及功能業(yè)務(wù)邏輯功能交互，回歸測試；

6.提交測試結(jié)果，包括測試用例，測試計(jì)劃；

7.日常維護(hù)性測試；

APP測試周期可根據(jù)項(xiàng)目的開發(fā)周期來確定測試時(shí)間，一般測試時(shí)間為兩三周，根據(jù)項(xiàng)目情況以及版本質(zhì)量可適當(dāng)縮短或延長測試時(shí)間。

2、APP測試需要提前準(zhǔn)備哪些測試資源？

具體要準(zhǔn)備的測試資源，根據(jù)實(shí)際項(xiàng)目來，可以從以下幾個(gè)方面出發(fā)：

1.IOS設(shè)備、Android設(shè)備（選取市面上主流手機(jī)產(chǎn)品）；

2.支付寶/銀聯(lián)支付的項(xiàng)目，需要提前申請支付寶/銀聯(lián)賬戶等等；

3.有秒殺專題的題目，需要規(guī)劃秒殺時(shí)間表；

4.有優(yōu)惠券使用的項(xiàng)目，需要添加優(yōu)惠券數(shù)據(jù)；

3、APP測試和Web測試的區(qū)別？

單純從功能測試的層面上來講的話，APP 測試、web 測試在流程和功能測試上是沒有區(qū)別的。

相同點(diǎn)：

1.同樣的測試用例設(shè)計(jì)方法；

2.同樣的測試方法：都會(huì)依據(jù)原型圖或效果圖檢查UI；

3.測試頁面載入和翻頁的速度、登錄時(shí)長、內(nèi)存是否溢出等；

4.測試應(yīng)用系統(tǒng)的穩(wěn)定性；

不同點(diǎn)：

1.系統(tǒng)結(jié)構(gòu)方面

• web項(xiàng)目，b/s架構(gòu)，基于瀏覽器的；web測試只要更新了服務(wù)器端，客戶端就會(huì)同步更新。

• app項(xiàng)目，c/s結(jié)構(gòu)的，必須要有客戶端；app 修改了服務(wù)端，則客戶端用戶所有核心版本都需要進(jìn)行回歸測試一遍。

2.性能方面

• web項(xiàng)目 需監(jiān)測 響應(yīng)時(shí)間、CPU、Memory；

• app項(xiàng)目 除了監(jiān)測 響應(yīng)時(shí)間、CPU、Memory外，還需監(jiān)測 流量、電量等；

3.兼容性方面

• web項(xiàng)目：瀏覽器（火狐、谷歌、IE等）；操作系統(tǒng)（Windows7、Windows10、Linux等）。

• app項(xiàng)目：設(shè)備系統(tǒng):iOS（ipad、iphone）、Android（三星、華為、聯(lián)想等） 、Windows（Win7、Win8）、OSX（Mac）；手機(jī)設(shè)備可根據(jù) 手機(jī)型號(hào)、分辨率、屏幕尺寸不同。

4.測試工具方面

• 自動(dòng)化工具：APP 一般使用 Appium; Web 一般使用 Selenium；
• 性能測試工具：APP 一般使用Monkey、 JMeter; Web 一般使用 LR、JMeter；

4、相對于 Web 項(xiàng)目，APP有哪些專項(xiàng)測試

1）干擾測試：中斷，來電，短信，關(guān)機(jī)，重啟等。

2）弱網(wǎng)絡(luò)測試（模擬2g、3g、4g、5g，wifi網(wǎng)絡(luò)狀態(tài)以及丟包情況）；網(wǎng)絡(luò)切換測試（網(wǎng)絡(luò)斷開后重連、3g切換到4g、5g/wifi 等）。

3）安裝、更新、卸載，中斷、前后臺(tái)切換。

• 安裝：需考慮安裝時(shí)的中斷、弱網(wǎng)、安裝后刪除安裝文件，全新安裝、升級(jí)安裝、第三方工具安裝等情況；

• 卸載：需考慮第三方工具卸載、直接卸載卸，載后是否刪除app相關(guān)的文件；

• 更新：分強(qiáng)制更新、非強(qiáng)制更新、增量包更新、斷點(diǎn)續(xù)傳、弱網(wǎng)狀態(tài)下更新；

• 中斷：來電中斷、短信中斷、鬧鐘中斷、手機(jī)鎖定、手機(jī)斷電、手機(jī)死機(jī)；

4）界面操作：關(guān)于手機(jī)端測試，需注意手勢，橫豎屏切換，多點(diǎn)觸控，前后臺(tái)切換。

5）安全測試：安裝包是否可反編譯代碼、安裝包是否簽名、權(quán)限設(shè)置，例如訪問通訊錄等。

6）邊界測試：可用存儲(chǔ)空間少、沒有SD卡/雙SD卡、飛行模式、系統(tǒng)時(shí)間有誤、第三方依賴（QQ、微信登錄）等。

7）權(quán)限測試：設(shè)置某個(gè)App是否可以獲取該權(quán)限，例如是否可訪問通訊錄、相冊、照相機(jī)等。

5、Android手機(jī)和IOS手機(jī)，系統(tǒng)有什么區(qū)別？

1.兩者運(yùn)行機(jī)制不同：IOS采用的是沙盒運(yùn)行機(jī)制，安卓采用的是虛擬機(jī)運(yùn)行機(jī)制。

IOS 沙盒運(yùn)行機(jī)制:

• 每個(gè)程序都有自己的虛擬地址空間。所以，程序之間不能進(jìn)行訪問。

• 默認(rèn)只會(huì)將應(yīng)用的最后運(yùn)行數(shù)據(jù)，記錄在RAM里面。

Android 虛擬機(jī)運(yùn)行機(jī)制：

• 所有的應(yīng)用程序都是運(yùn)行在虛擬機(jī)中，用戶界面其實(shí)是由虛擬機(jī)傳遞的，并且通過虛擬機(jī)，Android的任何程序都就可以輕松訪問其他程序文件。

• 所有的Android的應(yīng)用程序都是運(yùn)行在RAM里面的，所以會(huì)發(fā)現(xiàn)有時(shí)候Android用著用著就開始有點(diǎn)卡頓。

2.兩者后臺(tái)制度不同：IOS中任何第三方程序都不能在后臺(tái)運(yùn)行；安卓中任何程序都能在后臺(tái)運(yùn)行，直到?jīng)]有內(nèi)存才會(huì)關(guān)閉。

3.IOS中用于UI指令權(quán)限最高，安卓中數(shù)據(jù)處理指令權(quán)限最高。

6、IOS和Android的APP測試有什么區(qū)別？

1.物理按鍵：Android長按home鍵呼出應(yīng)用列表和切換應(yīng)用，然后右滑則終止應(yīng)用；iOS所有的返回上一層，只能靠頁面功能實(shí)現(xiàn)。

2.多分辨率測試：Android端20多種；IOS較少。

3.手機(jī)操作系統(tǒng)：Android較多，IOS較少且不能降級(jí)，只能單向升級(jí)；新的IOS系統(tǒng)中的資源庫不能完全兼容低版本中的IOS系統(tǒng)中的應(yīng)用，低版本IOS系統(tǒng)中的應(yīng)用調(diào)用了新的資源庫，會(huì)直接導(dǎo)致閃退。

4.操作習(xí)慣：Android，Back鍵是否被重寫，測試點(diǎn)擊Back鍵后的反饋是否正確；應(yīng)用數(shù)據(jù)從內(nèi)存移動(dòng)到SD卡后能否正常運(yùn)行等。

5.push測試：Android點(diǎn)擊home鍵，程序后臺(tái)運(yùn)行時(shí)，此時(shí)接收到push，點(diǎn)擊后喚醒應(yīng)用，此時(shí)是否可以正確跳轉(zhuǎn)；IOS點(diǎn)擊home鍵關(guān)閉程序和屏幕鎖屏的情況（紅點(diǎn)的顯示）。

6.安裝卸載測試：Android可以通過手機(jī)自帶的應(yīng)用市場或者是第三方的手機(jī)助手進(jìn)行下載，下載和安裝的平臺(tái)和工具和渠道比較多；IOS主要有app store，iTunes和testflight下載。

7.升級(jí)測試：可以被升級(jí)的必要條件：新舊版本具有相同的簽名；新舊版本具有相同的包名；有一個(gè)標(biāo)示符區(qū)分新舊版本（如版本號(hào)）。

8.支付方式：對于一些有內(nèi)購功能的APP，Android直接調(diào)用第三方支付渠道完成支付；IOS需要先在APP store里綁定支付方式，然后通過APP store去完成支付操作。

9.消息推送機(jī)制：Android使用第三方或者自建平臺(tái)進(jìn)行消息推送；IOS的消息推送渠道由蘋果官方提供。

7、介紹一個(gè)APP抓包工具？

一般用Fiddler，主要用來做app抓包使用，先在Fiddler客戶端做好各項(xiàng)配置，端口設(shè)置為8888;然后在手機(jī)上設(shè)置代理，就可以抓包，主要看的是服務(wù)器返回的值、還能夠修改傳入?yún)?shù)、傳出的參數(shù)、模擬網(wǎng)絡(luò)延時(shí)，構(gòu)造不同場景。

8、APP日志如何抓取？

• 可以使用adb命令：adb logcat | find "com.sankuai.meituan" >d:\test.txt

• 也可以用ddms抓取，手機(jī)連上電腦，打開ddms工具；

• 或者在Android Studio開發(fā)工具中，打開DDMS；

9、常用的adb命令有哪些？

1.查看幫助手冊列出所有的選項(xiàng)說明及子命令：
adb help

2.獲取設(shè)備列表及設(shè)備狀態(tài)：
adb devices

3.安裝應(yīng)用：adb install 路徑\xx.apk, 安裝應(yīng)用；adb install -r 重新安裝。
adb install
adb install -r

4.獲取設(shè)備的狀態(tài)，設(shè)備的狀態(tài)有 device , offline , unknown3種，其中device：設(shè)備正常連接，offline：連接出現(xiàn)異常，設(shè)備無響應(yīng)，unknown：沒有連接設(shè)備。
adb get-state

5.卸載應(yīng)用：adb uninstall <包名>, 后面的參數(shù)是應(yīng)用的包名，區(qū)別于 apk 文件名。
adb uninstall

6.將 Android 設(shè)備上的文件或者文件夾復(fù)制到電腦本地：adb pull <遠(yuǎn)程路徑> <本地路徑>, 如復(fù)制 Sdcard 下的 pull.txt 文件到 D 盤：adb pull sdcard/pull.txt d:\，重命名：adb pull sdcard/pull.txt d:\rename.txt。
adb pull

7.推送本地文件至 Android 設(shè)備：adb push <本地路徑> <遠(yuǎn)程路徑>, 如推送 D 盤下的 ITester.txt 至 Sdcard：adb push d:\ITester.txt sdcard/ （注意sdcard 后面的斜杠不能少）。
adb push

8.結(jié)束和啟動(dòng)adb服務(wù)：adb kill-server /adb start-server , 結(jié)束 adb 服務(wù)/啟動(dòng) adb 服務(wù)，通常兩個(gè)命令一起用，設(shè)備狀態(tài)異常時(shí)使用 kill-server，運(yùn)行 start-server 進(jìn)行重啟服務(wù)。
adb kill-server
adb start-server

9.打印及清除系統(tǒng)日志：adb logcat , 打印 Android 的系統(tǒng)日志 ；adb logcat -c,清除日志。
adb logcat
adb logcat -c

10.查找包名/活動(dòng)名
adb logcat | findstr START

10、adb三個(gè)組件是指？

ADB作為一個(gè)客戶端/服務(wù)器架構(gòu)的命令行工具，主要由3個(gè)部分組成。

• adb clent（客戶端）：可以通過它對Android應(yīng)用進(jìn)行安裝、卸載及調(diào)試。

• adb service（服務(wù)器）：管理客戶端到Android設(shè)備上abd后臺(tái)進(jìn)程的連接，負(fù)責(zé)管理client和damon進(jìn)行通信。

• adb daemon（守護(hù)進(jìn)程）：運(yùn)行在Android設(shè)備上的adb后臺(tái)進(jìn)程。

（2）進(jìn)階篇

1、介紹一下Android四大組件？

Android四大基本組件：Activity、BroadcastReceiver廣播接收器、ContentProvider內(nèi)容提供者、Service服務(wù)。

• Activity：應(yīng)用程序中，一個(gè)Activity就相當(dāng)于手機(jī)屏幕，它是一種可以包含用戶界面的組件，主要用于和用戶進(jìn)行交互。一個(gè)應(yīng)用程序可以包含許多活動(dòng)，比如事件的點(diǎn)擊，一般都會(huì)觸發(fā)一個(gè)新的Activity。

• BroadcastReceiver廣播接收器：應(yīng)用可以使用它對外部事件進(jìn)行過濾只對感興趣的外部事件(如當(dāng)電話呼入時(shí)，或者數(shù)據(jù)網(wǎng)絡(luò)可用時(shí))進(jìn)行接收并做出響應(yīng)。廣播接收器沒有用戶界面。然而，它們可以啟動(dòng)一個(gè)activity或serice 來響應(yīng)它們收到的信息，或者用NotificationManager來通知用戶。通知可以用很多種方式來吸引用戶的注意力──閃動(dòng)背燈、震動(dòng)、播放聲音等。一般來說是在狀態(tài)欄上放一個(gè)持久的圖標(biāo)，用戶可以打開它并獲取消息。

• ContentProvider內(nèi)容提供者：內(nèi)容提供者主要用于在不同應(yīng)用程序之間實(shí)現(xiàn)數(shù)據(jù)共享的功能，它提供了一套完整的機(jī)制，允許一個(gè)程序訪問另一個(gè)程序中的數(shù)據(jù)，同時(shí)還能保證被訪問數(shù)據(jù)的安全性。只有需要在多個(gè)應(yīng)用程序間共享數(shù)據(jù)時(shí)才需要內(nèi)容提供者。例如：通訊錄數(shù)據(jù)被多個(gè)應(yīng)用程序使用，且必須存儲(chǔ)在一個(gè)內(nèi)容提供者中。它的好處：統(tǒng)一數(shù)據(jù)訪問方式。

• Service服務(wù)：是Android中實(shí)現(xiàn)程序后臺(tái)運(yùn)行的解決方案，它非常適合去執(zhí)行那些不需要和用戶交互而且還要長期運(yùn)行的任務(wù)（一邊打電話，后臺(tái)掛著QQ）。服務(wù)的運(yùn)行不依賴于任何用戶界面，即使程序被切換到后臺(tái)，或者用戶打開了另一個(gè)應(yīng)用程序，服務(wù)仍然能夠保持正常運(yùn)行，不過服務(wù)并不是運(yùn)行在一個(gè)獨(dú)立的進(jìn)程當(dāng)中，而是依賴于創(chuàng)建服務(wù)時(shí)所在的應(yīng)用程序進(jìn)程。當(dāng)某個(gè)應(yīng)用程序進(jìn)程被殺掉后，所有依賴于該進(jìn)程的服務(wù)也會(huì)停止運(yùn)行（正在聽音樂，然后把音樂程序退出）。

2、Activity生命周期？

生命周期即活動(dòng)從開始到結(jié)束所經(jīng)歷的各種狀態(tài)，從一個(gè)狀態(tài)到另一個(gè)狀態(tài)的轉(zhuǎn)變，從無到有再到無，Activity本質(zhì)上有四種狀態(tài)：

• 運(yùn)行（Active/Running）:Activity處于活動(dòng)狀態(tài)，此時(shí)Activity處于棧頂，是可見狀態(tài)，可以與用戶進(jìn)行交互。

• 暫停（Paused）:當(dāng)Activity失去焦點(diǎn)時(shí)，或被一個(gè)新的非全面屏的Activity，或被一個(gè)透明的Activity放置在棧頂時(shí)，Activity就轉(zhuǎn)化為Paused狀態(tài)。此刻并不會(huì)被銷毀，只是失去了與用戶交互的能力，其所有的狀態(tài)信息及其成員變量都還在，只有在系統(tǒng)內(nèi)存緊張的情況下，才有可能被系統(tǒng)回收掉。

• 停止（Stopped）:當(dāng)Activity被系統(tǒng)完全覆蓋時(shí)，被覆蓋的Activity就會(huì)進(jìn)入Stopped狀態(tài)，此時(shí)已不在可見，但是資源還是沒有被收回。

• 系統(tǒng)回收（Killed）:當(dāng)Activity被系統(tǒng)回收掉，Activity就處于Killed狀態(tài)。

如果一個(gè)活動(dòng)在處于停止或者暫停的狀態(tài)下，系統(tǒng)內(nèi)存缺乏時(shí)會(huì)將其結(jié)束（finish）或者殺死（kill）。這種非正常情況下，系統(tǒng)在殺死或者結(jié)束之前會(huì)調(diào)用onSaveInstance()方法來保存信息，同時(shí)，當(dāng)Activity被移動(dòng)到前臺(tái)時(shí)，重新啟動(dòng)該Activity并調(diào)用onRestoreInstance()方法加載保留的信息，以保持原有的狀態(tài)。

在上面的四中常有的狀態(tài)之間，還有著其他的生命周期來作為不同狀態(tài)之間的過渡，用于在不同的狀態(tài)之間進(jìn)行轉(zhuǎn)換。

3、請介紹一下，Android SDK中自帶的幾個(gè)工具？

有如下幾個(gè)工具：

• ddms：Dalvik Debug Monitor Service，是 Android 開發(fā)環(huán)境中的Dalvik[虛擬機(jī)]調(diào)試監(jiān)控服務(wù)。

• monkey：Android中的一個(gè)命令行工具，可以運(yùn)行在模擬器里或?qū)嶋H設(shè)備中。它向系統(tǒng)發(fā)送偽隨機(jī)的用戶事件流(如按鍵輸入、觸摸屏輸入、手勢輸入等)，實(shí)現(xiàn)對正在開發(fā)的應(yīng)用程序進(jìn)行壓力測試。

• uiautomator：UIAutomator是Eclipse自帶的用于UI自動(dòng)化測試工具，可仿真APP上的單擊、滑動(dòng)、輸入文本等操作。

• monitor：同uiautomator

• adb：ADB的全稱為Android Debug Bridge，就是起到調(diào)試橋的作用。通過ADB我們可以在Eclipse中方面通過DDMS來調(diào)試Android程序，就是debug工具。

4、你所了解的APP測試工具？

APP自動(dòng)化測試工具：

• Appium

• Airtest

• uiautomator2（python）

APP穩(wěn)定性測試工具：

• Monkey

• MonkeyRunner

• Maxim

• UICrawler

APP性能測試工具：

• Perfdog

• SoloPi

APP弱網(wǎng)測試&抓包工具：

• Fiddler

• Charles

APP兼容性測試工具：

• TestIn

• 騰訊優(yōu)測

• 百度MTC

• 阿里MQC

APP安全測試工具：

• OWASP ZAP

• Drozer

• MobSF

• QARK

5、介紹一下冷啟動(dòng)、暖啟動(dòng)、熱啟動(dòng)、首屏啟動(dòng)？

APP啟動(dòng)會(huì)發(fā)生多個(gè)事件，測試人員需要知道整個(gè)環(huán)節(jié)是否出現(xiàn)問題，需要了解到具體是哪個(gè)環(huán)節(jié)存在問題：

• 冷啟動(dòng)：當(dāng)進(jìn)程不存在的時(shí)候，從進(jìn)程創(chuàng)建開始到界面的展示的過程；

• 暖啟動(dòng)：有一部分資源已經(jīng)存在，進(jìn)程存在，相對于熱啟動(dòng)要消耗更多資源。當(dāng)用戶退出應(yīng)用程序時(shí)，進(jìn)程還會(huì)存在，暖啟動(dòng)相較于冷啟動(dòng)只是少了進(jìn)程的創(chuàng)建；

• 熱啟動(dòng)：大部分資源都在，只是應(yīng)用之間的切換；

• 首屏啟動(dòng)：第一屏加載完整；

標(biāo)準(zhǔn)：

• 冷啟動(dòng)：需要5秒甚至更長；

• 暖啟動(dòng)：需要2秒甚至更長；

• 熱啟動(dòng)：需要1.5秒甚至更長；

整個(gè)啟動(dòng)過程可以用adb工具進(jìn)行分析，利用adb logcat獲取啟動(dòng)數(shù)據(jù)，或者錄屏，使用ffmpeg拆幀分析。
adb logcat

首先定義一個(gè)變量，這個(gè)變量填寫用到的包名。
package=com.xueqiu.android

清除緩存數(shù)據(jù)：
adb shell pm clear $package

停止進(jìn)程：
adb shell am force-stop $package

通過以上命令就做好了冷啟動(dòng)的環(huán)境，下面啟動(dòng)app并獲取數(shù)據(jù)。啟動(dòng)App
adb shell am start -S -W $package/.view.WelcomeActivityAlias

-S表示啟動(dòng)之前先停止應(yīng)用進(jìn)程
-W是表示等待對應(yīng)的activity啟動(dòng)完成

獲取數(shù)據(jù)：
bash adb logcat |grep -i displayed

獲取的時(shí)間如下：

6、談?wù)剬鋯?dòng)的理解？

應(yīng)用的啟動(dòng)可以分為冷啟動(dòng)，熱啟動(dòng)和溫啟動(dòng)，而啟動(dòng)最慢、耗時(shí)最長的就是冷啟動(dòng)。

冷啟動(dòng)開始時(shí)，系統(tǒng)會(huì)依次執(zhí)行三個(gè)任務(wù)去啟動(dòng)APP:

• 加載和啟動(dòng)應(yīng)用程序；

• APP啟動(dòng)后，立即創(chuàng)建一個(gè)空白的啟動(dòng)Window；

• 創(chuàng)建APP的進(jìn)程；

在這三個(gè)任務(wù)執(zhí)行后，系統(tǒng)創(chuàng)建了應(yīng)用進(jìn)程，那么應(yīng)用進(jìn)程接下來會(huì)執(zhí)行下一步：

• 創(chuàng)建APP對象；

• 開啟一個(gè)主線程；

• 創(chuàng)建啟動(dòng)頁的Activity；

• 加載View；

• 布局view到屏幕；

• 進(jìn)行初始繪制顯示視圖；

當(dāng)應(yīng)用進(jìn)程完成初始繪制之后，系統(tǒng)進(jìn)程用啟動(dòng)頁的Activity來替換當(dāng)前顯示的空白Window，這個(gè)時(shí)刻用戶就可以使用App了。

四、接口測試常見面試題

1、請描述下HTTP接口？

了解HTTP接口首先需要知道HTTP是什么。

HTTP的全稱為：HyperText Transfer Protocol，即超文本傳輸協(xié)議 。百度百科中對HTTP協(xié)議的解釋是http是一個(gè)簡單的請求-響應(yīng)協(xié)議，通常運(yùn)行在TCP之上。它指定了客戶端可能發(fā)送給服務(wù)器什么樣的消息及會(huì)得到什么樣的響應(yīng)。請求和響應(yīng)消息的頭以ASCII碼形式給出；而消息內(nèi)容則具有一個(gè)類似MIME的格式。

所以HTTP是工作于 客戶端/服務(wù)端架構(gòu)之上的。通常情況下，常用的web服務(wù)器有Apache服務(wù)器、 IIS服務(wù)器等等。?

OSI模型中的七層結(jié)構(gòu)見下圖，而HTTP是屬于應(yīng)用層，定義應(yīng)用程序的功能 。

用戶通過URL向HTTP服務(wù)端發(fā)送請求，HTTP服務(wù)器經(jīng)過一系列的算法處理請求后再把相應(yīng)的結(jié)果返回給用戶（即瀏覽器）。

2、GET接口與 POST接口分別有什么特點(diǎn)，有什么區(qū)別？

GET接口是從指定的資源中獲取數(shù)據(jù)的，參數(shù)通過URL發(fā)送

POST是把需要處理的數(shù)據(jù)提交到指定的資源 POST的參數(shù)不能通過URL發(fā)送，只能從請求的的消息主體中發(fā)送。

3、HTTP1.1版本中有哪些請求方法？

1.0版本中有三種方法即GET POST HEAD。?

http1.1版本中新增了OPTIONS DELETE PUT CONNECT TRACE5種請求方法.

4、HTTP響應(yīng)消息由哪些部分組成？

響應(yīng)消息包括狀態(tài)行，消息報(bào)頭和響應(yīng)正文

5、HTTP某個(gè)狀態(tài)碼的含義（如：304代表什么）或是XX狀態(tài)碼頭的含義

1xx表示請求已接收 ，繼續(xù)處理

2xx 請求成功接收

3xx 重定向 ，需要進(jìn)一步操作

4xx 請求錯(cuò)誤 ，屬于客戶端錯(cuò)誤

5xx 請求合法，但服務(wù)器無法處理，屬于服務(wù)端錯(cuò)誤?

常見的狀態(tài)碼見下圖：

6、你怎么理解RPC接口，有什么作用？

RPC 的全稱為：Remote Procedure Call Protocol即遠(yuǎn)程過程調(diào)用協(xié)議。

RPC通過網(wǎng)絡(luò)從遠(yuǎn)程的服務(wù)器上請求服務(wù)無需了解底層技術(shù)協(xié)議 。RPC采用的是客戶端/服務(wù)端模式，RPC的作用是開發(fā)方便、直接，安全性高，特別是在一些大型項(xiàng)目中，內(nèi)部的子系統(tǒng)及接口比較多的情況下，采用網(wǎng)絡(luò)分布式的多個(gè)APP開發(fā)更加容易 。

7、RPC的工作流程是怎樣的？

下圖為RPC的工作流程：

8、請描述下RPC的各個(gè)核心部件

Remoting 網(wǎng)絡(luò)通信框架 實(shí)現(xiàn)了消息機(jī)制 RPC遠(yuǎn)程過程調(diào)用 ，支持集群，負(fù)載均衡? Registry服務(wù)目錄框架

9、接口測試的流程

接口測試流程也與公司要求、項(xiàng)目性質(zhì)有所區(qū)別，可以適當(dāng)增減節(jié)點(diǎn)。

閱讀接口文檔（接口文檔形式各個(gè)公司不同）

設(shè)計(jì)接口測試用例

準(zhǔn)備測試環(huán)境、測試工具及測試數(shù)據(jù)

執(zhí)行測試

提交缺陷報(bào)告，回歸測試

編寫測試報(bào)告

10、你之前使用過的接口測試工具有哪些

postman、jmeter、RESTClient、loadrunner、SoapUI等

本人常用的有postman、jmeter

postman使用操作非常簡單，支持測試case的管理 ，文件上傳、響應(yīng)驗(yàn)證以及環(huán)境參數(shù)管理還可以批量運(yùn)行

jmeter是一款免費(fèi)開源的輕量工具，可以用來做簡單的壓力測試，也可以自己寫接口腳本驗(yàn)證。

11、調(diào)用HTTP接口時(shí)如何獲取到HTTPClient庫？

使用maven管理的話可以加入GroupId及 ArtifactID均為 commons-httpclient的依賴即可。

12、你之前怎么做RPC接口測試，有哪些準(zhǔn)備工作？

接口調(diào)用客戶端依賴包 配置接口遠(yuǎn)程服務(wù)端的Consumer Provider 編寫RPC接口測試腳本。

13、說說HTTP單接口測試與 RPC接口測試的特點(diǎn)

RPC接口編寫測試腳本時(shí)是需要導(dǎo)入JAR包，并且配置好Consumer。Http單接口測試是提交數(shù)據(jù)的方式 ，常用的提交數(shù)據(jù)方式有application/x-www-form-urlencoded ?? multipart/form-data

14、針對你之前做的項(xiàng)目中簡單描述下日志工具是怎么配置的

以maven為例，首先，需要引入Log4j，在CLASSPATH目錄下建立一個(gè)文件log4j.properties,然后使用API輸出日志

15、GIT代碼版本控制工具的常用命令

第一次從Git下載新代碼：git clone xx.git “下載目錄”

從遠(yuǎn)程倉庫克隆：git clone “url”

添加目錄：git ?add ?“要添加的目錄”

提交：commit

查看所有的本地分支：git branch

查看所有的遠(yuǎn)程分支：git branch -r

新建分支：git branch 新建分支名稱

切換分支：git checkout ?切換分支名稱

合并分支：git merge 要合并的分支

查看git狀態(tài)：git status

查看當(dāng)前文件與上次時(shí)的區(qū)別：git diff 文件名

查看提交日志：git log

回退到上一個(gè)版本：git reset

刪除版本庫的文件：git rm 文件名

16、簡要說明JUnit的測試框架

JUnit是用Java語言編寫的單元測試框架，使用JUnit進(jìn)行測試前需要先繼承TestCase類。應(yīng)用比較多的領(lǐng)域有重構(gòu)和極限編程。

17、TestNG常用的annotation關(guān)鍵字的含義

@Test 標(biāo)記一個(gè)類或方法?

@BeforeSuite被@BeforeSuite注解的方法，會(huì)在所有測試運(yùn)行之前運(yùn)行。

@AfterSuite被@AfterSuite注解的方法，會(huì)在所有測試運(yùn)行之后運(yùn)行。

@BeforeTest被@BeforeTest注解的方法，在測試執(zhí)行之前運(yùn)行。

@AfterTest被@AfterTest注解的方法，在測試執(zhí)行之后運(yùn)行。

@BeforeClass被@BeforeClass注解的方法會(huì)在當(dāng)前類的第1個(gè)測試方法運(yùn)行前運(yùn)行。

@AfterClass被@AfterClass注解的方法會(huì)在當(dāng)前類的第1個(gè)測試方法調(diào)用后運(yùn)行。

@BeforeMethod被@BeforeMethod注解的方法，會(huì)在每個(gè)測試方法調(diào)用之前運(yùn)行。

@AfterMethod被@AfterMethod注解的方法會(huì)在每個(gè)測試方法調(diào)用后運(yùn)行。

18、TestNG常用的斷言方法

assertTrue判斷是否為True

assertFalse判斷是否為false

assertNull判斷是否為null

assertNotNull判斷是否不為null

assertSame判斷引用地址是否相同

assertNotSame判斷引用地址是否不同

19、TestNG多線程測試時(shí)的annotation如何使用

invocationCount \threadPoolSize

20、TestNG怎么導(dǎo)出測試報(bào)告?

TestNG自帶了導(dǎo)出測試報(bào)告的功能 ，但可讀性較差，可以用maven下載ReportNG的依賴并在pom.xml中進(jìn)行配置。也可以使用插件。

五、自動(dòng)化測試面試真題

（1）編程語法題

1 、 python 有哪些數(shù)據(jù)類型

• python 數(shù)據(jù)類型有很多，基本數(shù)據(jù)類型有整型（數(shù)字）、字符串、元組、列表、字典和布爾類型等

2 、怎么將兩個(gè)字典合并

• 調(diào)用字典的 update 方法，合并 2 個(gè)字典。

3 、 json.l python 如何將 json 寫到文件里？

• loads（） 是將字符串轉(zhuǎn)化為字典

• json.load()是將文件打開從字符串轉(zhuǎn)換成數(shù)據(jù)類型

• json.dumps (） 是將字典轉(zhuǎn)化為字符串

• json.dump()是將數(shù)據(jù)類型轉(zhuǎn)換成字符串并存儲(chǔ)在文件中

4 、 __init__ 和 __new__ 區(qū)別？

• __new__是在實(shí)例創(chuàng)建之前被調(diào)用的，因?yàn)樗娜蝿?wù)就是創(chuàng)建實(shí)例然后返回該

  實(shí)例對象，是個(gè)靜態(tài)方法。

• __init__是當(dāng)實(shí)例對象創(chuàng)建完成后被調(diào)用的，然后設(shè)置對象屬性的一些初始值，通常用在初始化一個(gè)類實(shí)例的時(shí)候。是一個(gè)實(shí)例方法。

5 、什么是可變、不可變類型？

• 可變數(shù)據(jù)類型：列表 list 和字典 dict；

• 不可變數(shù)據(jù)類型：整型 int、浮點(diǎn)型 float、字符串型 string 和元組 tuple

6 、 mysql 注入點(diǎn)，用工具對目標(biāo)站直接寫入一句話，需要哪些條件？

mysql 寫入一句話需要具備

• 1.secure-file-priv=''，即：my.ini 文件，打開找到 secure-file-priv 參數(shù)改空

• 2.當(dāng)前用戶具備 root 權(quán)限

• 3.已獲取到應(yīng)用程序的絕對路徑，且目錄可以進(jìn)行文件寫入操作。?

7 、 python 深淺拷貝的區(qū)別

• 對于不可變數(shù)據(jù)來說深淺拷貝的結(jié)果一致會(huì)重新創(chuàng)一個(gè)數(shù)據(jù)的副本。淺拷貝對于

  可變類型來說只會(huì)拷貝其元素的引用。

• 深拷貝對于可變元素來說會(huì)遞歸的整個(gè)重新創(chuàng)建一個(gè)原數(shù)據(jù)的副本。

8 、 python 為什么使用 *args 和 **kwargs

如果我們不確定要往函數(shù)中傳入多少個(gè)參數(shù)，或者我們想往函數(shù)中以列表和元組

的形式傳參數(shù)時(shí)，那就使用*args；如果我們不知道要往函數(shù)中傳入多少個(gè)關(guān)

鍵詞參數(shù)，或者想傳入字典的值作為關(guān)鍵詞參數(shù)時(shí)，那就要使用**kwargs。args

和 kwargs 這兩個(gè)標(biāo)識(shí)符是約定俗成的用法，你當(dāng)然還可以用*bob 和**billy，

但是這樣就不太專業(yè)。

9 、重寫和重載有什么區(qū)別？

• 重寫：用在類的繼承當(dāng)中。子類對父類的同名方法，進(jìn)行重寫。在子類同名方法

  內(nèi)部，如果要延用父類的方法，可以使用 super 調(diào)用。

• 重載：用在類當(dāng)中，對于同一個(gè)方法名，支持不同類型的參數(shù)，支持不同數(shù)量的

• 參數(shù)。由于 python 的函數(shù)本身就對參數(shù)不作類型限定，也有*args 和**kwargs

  支持不定長度參數(shù)。

10 、 python 實(shí)現(xiàn) get 數(shù)據(jù)庫的表？你是怎么實(shí)現(xiàn)的？

python 當(dāng)中對于不同數(shù)據(jù)庫，都有不同的第三庫來實(shí)現(xiàn)連接和數(shù)據(jù)庫操作。

比較熟悉的是對 mysql 的操作。使用的是 pymysql 這個(gè)第三方庫。第一步是建立

數(shù) 據(jù) 庫 連 接 ；第 二 步 調(diào) 用 execute 方 法 執(zhí) 行 sql 語 句 ， 第 三 步 使 用

fetchone,fetchall,fetchmany 去獲取不同條數(shù)的結(jié)果。

11 、對象 ( 實(shí)例 ) 方法，類方法，靜態(tài)方法的定義有何不同？分別適用于什么場

景？

• python 中，類中定義的普通函數(shù)就是對象方法，對象方法中的第一個(gè)形參一般

  會(huì)定義為`self`，表示調(diào)用的對象本身，當(dāng)對象調(diào)用對象方法時(shí)會(huì)被隱式的傳遞

  給這個(gè)形參。所以當(dāng)函數(shù)需要用到對象或?qū)ο蟮膶傩詴r(shí)一般會(huì)將其定義為對象方

  法。

• 類方法定義時(shí)，需要使用裝飾器`classmethod`進(jìn)行裝飾，類方法中的第一個(gè)形

  參一般會(huì)定義為`cls`，表示類本身。當(dāng)對象調(diào)用或類調(diào)用類方法時(shí)，類會(huì)被隱

  式的傳遞給這個(gè)形參。所以當(dāng)函數(shù)需要用到類或者類的屬性時(shí)一般會(huì)將其定義為

  類方法。

• 靜態(tài)方法定義時(shí)，需要使用裝飾器`staticmethod`進(jìn)行裝飾，其他與普通函數(shù)沒

  有區(qū)別。一般會(huì)將一些與對象和類無關(guān)的工具函數(shù)定義為靜態(tài)方法，方便調(diào)用。

12 、 SQL 連表查詢，去重查詢，查詢重復(fù)的數(shù)據(jù)？

兩表查詢：SELECT 字段 1,字段 2,字段 3,…… FROM 表名 1 INNER JOIN 表名 2ON 關(guān)聯(lián)條件；去重查詢：SELECT distinct ...;查詢重復(fù)的數(shù)據(jù)：select 列名 from 表名 group by 列名 having count(列名) > 1;

13 、 python 的單例模式？

• 單例模式是：確保類有且只有一個(gè)對象被創(chuàng)建為唯一對象提供訪問點(diǎn)，令其可被全局訪問控制共享資源的并行訪問

• 具體實(shí)現(xiàn)方式可以通過模塊導(dǎo)入、裝飾器、控制 __new__方法 等等。

14 、什么是 PEP 8 ？

• EP 8 代表 Python Enhancement Proposal，它可以定義為幫助我們提供有關(guān)如何編寫 Python 代碼的指南的文檔。它基本上是一組規(guī)則，指定如何格式化

• Python 代碼獲得最大的可讀性。它由?Guido van Rossum、Barry Warsaw 和Nick Coghlan 于 2001 年編寫

15 、 PO 模式的封裝原則有哪一些？

公共方法表示頁面提供的服務(wù)。比如把登錄封裝成 login 方法，搜索操作封裝成?search 方法，注冊操作封裝成 register 方法。

• 盡量不要暴露頁面的內(nèi)部，比如頁面的 HTML, 頁面的上下結(jié)構(gòu)

• 一般不做斷言，做到頁面邏輯和測試邏輯的分離。

• 方法返回 self 或者其他 PageObjects，也可以是元素屬性等。

• 不需要封裝整個(gè)頁面行為，用到什么邏輯封裝什么邏輯

• 同一操作如果出現(xiàn)不同結(jié)果，可以用不同的方法表示。比如登錄成功有跳轉(zhuǎn)，登錄失敗報(bào)錯(cuò)，登錄未授權(quán)，?

（2）編碼題

1 、冪的遞歸，計(jì)算 x 的 n 次方，如：3 的 4 次方 為 3*3*3*3=81

# 遞歸的方式def mi(x, n):if n == 0:return 1else:return x*mi(x, n-1)print(mi(3, 4))非遞歸的方式：def mix(x,n):result = 1for count in range(n):result *= xreturn resultprint(mi(3,4))

2 、統(tǒng)計(jì)列表（list ）中每個(gè)元素出現(xiàn)的次數(shù)

# 統(tǒng)計(jì)列表（list）中每個(gè)元素出現(xiàn)的次數(shù)lista = [1, 2, 3, 4, 12, 22, 15, 44, 3, 4, 4, 4, 7, 7, 44, 77, 100]new_dict = {}for item in lista:if item not in new_dict.keys():new_dict[item] = lista.count(item)print(new_dict)

3 、 ['abc13','abv89'] 這種列表，打印最大長度的共同的前綴，列表元素個(gè)數(shù)不確定

def test_str(iterable):return_str=''for i in zip(*iterable):if len(set(i))==1:return_str +=i[0]else:breakprint(return_str)return return_str

4 、對 list 去重并找出列表 list 中的重復(fù)元素

from collections import Counter #引入 Countera = [1, 2, 3, 3, 4, 4]b = dict(Counter(a))print(b)print ([key for key,value in b.items() if value > 1]) #只展示重復(fù)元素print ({key:value for key,value in b.items() if value > 1}) #展現(xiàn)重復(fù)元素和重復(fù)次數(shù)

5 、已知一個(gè)隊(duì)列 [1, 3, 6, 9, 7, 3, 4, 6]

1. 按從小到大排序

2. 按從大大小排序

3. 去除重復(fù)數(shù)字

a = [1, 3, 6, 9, 7, 3, 4, 6]# 1.sort 排序，正序a.sort()print(a)#?2.sort?倒序a.sort(reverse=True)print(a)# 3.去重b = list(set(a))print(b)

6 、任選語言完成雙向冒泡排序算法程序（[8,6,4,3,9,1,2,5,7] 升序）

def cocktail_sort(arr):    n = len(arr)    start = 0    end = n - 1    swapped = True
    while swapped:        # 正向冒泡，找到最大元素放到后面        swapped = False        for i in range(start, end):            if arr[i] > arr[i + 1]:                arr[i], arr[i + 1] = arr[i + 1], arr[i]                swapped = True
        # 如果沒有元素進(jìn)行交換，則排序完成        if not swapped:            break
        # 在反向冒泡之前，重新標(biāo)記 swapped 為 False        swapped = False        end -= 1
        # 反向冒泡，找到最小元素放到前面        for i in range(end - 1, start - 1, -1):            if arr[i] > arr[i + 1]:                arr[i], arr[i + 1] = arr[i + 1], arr[i]                swapped = True
        start += 1
    return arr
# 測試排序算法arr = [8, 6, 4, 3, 9, 1, 2, 5, 7]sorted_arr = cocktail_sort(arr)print(sorted_arr)

（3）自動(dòng)化基礎(chǔ)能力評估

1 、 python 列表和字典的區(qū)別，列表和元組的區(qū)別？

• 列表是有序的，字典是無序的。列表通過索引獲取、字典通過 key 獲取。

• 列表是可變的，可以修改、添加、刪除其中的元素，但是元組是不可變的，不能修改、添加、刪除其中的元素。

• 對于一個(gè)元素的元組，必須要在元素后加逗號(hào)，而列表不需要。

2 、 Python 用到的庫

• • 單元測試框架：unittest pytest

  • 操作 mysql 數(shù)據(jù)庫：pymysql

  • http 請求庫：requests

  • web 自動(dòng)化：selenium

  • 處理日志:logging

  • json 數(shù)據(jù)提取和 json 文件讀寫:json，jsonpath

  • pyyaml:yaml 文件讀寫

3 、 unittest 和 pytest 區(qū)別？

• • pytest 是第三方庫，基于 unittest 的擴(kuò)展框架，比 unittest 更簡潔，高效

  • pytest 有豐富的插件系統(tǒng)

  • pytest 的夾具使用更加靈活

  • pytest 可以很方便的過濾用例

4 、 python 當(dāng)中如何操作數(shù)據(jù)庫 ?

• • python 不同的數(shù)據(jù)庫，都有對應(yīng)的第三方庫。比如 mysql 數(shù)據(jù)庫有 pymysql庫，oracle 數(shù)據(jù)庫有 cx_Oracle

  • 安裝成功第三方庫后，代碼中將包導(dǎo)進(jìn)來 ·接下來就是連接數(shù)據(jù)庫，提供數(shù)據(jù)庫的服務(wù)器地址、端口號(hào)、訪問的用戶名和密碼、數(shù)據(jù)庫名稱，通過調(diào)用對應(yīng)的方法去連接

  • 連接成功之后，調(diào)用執(zhí)行 sql 語句的方法去操作數(shù)據(jù)庫

  • 操作完成之后，釋放數(shù)據(jù)庫連接

5 、 jmeter 或 postman 實(shí)現(xiàn)多接口關(guān)聯(lián)測試 ? 怎么做關(guān)聯(lián) ?

6 、接口自動(dòng)化的斷言怎么做

7 、如果需要用自動(dòng)化測刪除接口，斷言怎么做

8 、做自動(dòng)化的過程中如何處理驗(yàn)證碼

• • 讓開發(fā)屏蔽驗(yàn)證碼，邀請開發(fā)處理，在測試環(huán)境，預(yù)發(fā)和正式環(huán)境恢復(fù)

  • 讓開發(fā)設(shè)置一個(gè)萬能驗(yàn)證碼，使用復(fù)雜的其他人無法猜到的驗(yàn)證碼

  • 基于圖像識(shí)別，破解驗(yàn)證碼

9 、自動(dòng)化測試用例如何編寫

自動(dòng)化測試本質(zhì)是測試，是用自動(dòng)化手段，替代部分手工測試。

• 自動(dòng)化測試用例，源自功能測試用例，都應(yīng)包含前置/后置，步驟，斷言。

• 自動(dòng)化用例設(shè)計(jì)原則，與功能用例一致。

• 自動(dòng)化用例需要自行解決：環(huán)境依賴問題。比如手工測試時(shí)，遇到前置條件不滿足，手工去準(zhǔn)備前置條件再測試。

• 自動(dòng)化用例斷言要明確：將手工測試看到的期望效果，轉(zhuǎn)成代碼。

• 自動(dòng)化用例需要考慮重復(fù)執(zhí)行不受影響。

考慮好以上 5 點(diǎn)，使用工具或者代碼的測試框架編寫即可。

10 、 pytest 的前置實(shí)現(xiàn)有哪幾種方式？

11 、 Appium 都有哪些啟動(dòng)方式

12 、 web ui 自動(dòng)化中顯式等待、隱式等待有什么區(qū)別

相同點(diǎn)：都是智能等待，在一定時(shí)間范圍內(nèi)不斷查找元素，一旦找到立刻執(zhí)行后續(xù)代碼，沒找到就會(huì)一直查找到超時(shí)為止

不同點(diǎn)：

• 顯式等待：顯示等待是單獨(dú)針對某個(gè)元素，設(shè)置一個(gè)等待時(shí)間，設(shè)置一個(gè)查詢間隔時(shí)間，在等待時(shí)間內(nèi)會(huì)按照設(shè)置的間隔時(shí)間對該元素進(jìn)行查找，超過設(shè)置的等待時(shí)間尚未出現(xiàn)則拋異常；顯示等待必須在每個(gè)需要等待的元素前面進(jìn)行聲明

• 隱式等待：隱式等待是全局的是針對所有元素，設(shè)置一個(gè)等待時(shí)間，在設(shè)置的等待時(shí)間內(nèi)，程序會(huì)不停檢測頁面元素是否全部加載完成，加載完成則繼續(xù)向下，超過設(shè)置的等待時(shí)間尚未出現(xiàn)則拋異常；隱式等待只需要聲明一次，聲明之后對整個(gè) drvier 的生命周期都有效不用重復(fù)聲明；程序會(huì)一直等待整個(gè)頁面加載完成

13、 有沒有遇到元素定位不到情況？如何處理的？

• • 頁面加載元素過慢，添加等待時(shí)間

  • 頁面有 frame 框架頁，需要先跳轉(zhuǎn)入 frame 框架再定位

  • 可能該元素是動(dòng)態(tài)元素，定位方式要優(yōu)化，可以使用部分元素定位或通過父節(jié)點(diǎn)或兄弟節(jié)點(diǎn)定位。

  • 可能識(shí)別了元素，但是不能操作，比如元素不可用，不可寫等。需要使用js 先把前置的操作完成，

  • 元素定位的表達(dá)式寫錯(cuò)了。

14 、請盡可能多的列出自動(dòng)化的元素定位方式，以及你最喜歡的定位方式？

web 自動(dòng)化的定位方式：

1、通過 id：find_element_by_id2、通過 name 屬性：find_element_by_name3、通過 class 屬性：find_element_by_name4、通過標(biāo)簽名：find_element_by_tag_name5、通過文本定位鏈接標(biāo)簽：find_element_by_link_text6、通過文本部分匹配，定位鏈接標(biāo)簽：find_element_by_partial_link_text 7、通過 xpath 定位：find_element_by_xpath8、css 選擇器定位：find_element_by_css_selector最常用的：id,xpath 和 css 這三種

15 、如果同一個(gè)瀏覽器打開兩個(gè)窗口，要用 selenium 里面哪個(gè)指令進(jìn)行切換？

1、窗口切換??2、iframe?切換?3、alert?切換

16 、 App 自動(dòng)化有做過嗎？知道用到哪些技術(shù)框架嗎？

• • 做過，app 自動(dòng)化主要使用的開源框架 appium，結(jié)合測試框架 pytest，還有 PO設(shè)計(jì)思想，共同搭建了 app 自動(dòng)化測試框架。

17 、 ui 自動(dòng)化出現(xiàn)的異常，以及出現(xiàn)這些異常后你是如何處理的？

• • 元素定位失敗異常，處理方式為檢查元素定位表達(dá)式，添加等待；

  • 定位超時(shí)異常，檢查定位方式，檢查是否有 iframe ；

  • 元素?zé)o法交互，檢查是否定位到正確元素。

18 、什么是 PO 模式，什么是 page factory ？

• PO 模式是 page object model 的縮寫，顧名思義， 是一種設(shè)計(jì)模式，把每個(gè)頁面當(dāng)成一個(gè)頁面對象，頁面層寫定位元素方法和頁面操作方法,實(shí)現(xiàn)腳本的page 和真實(shí)的網(wǎng)站頁面 Map 起來，一對應(yīng)起來PO 模式業(yè)務(wù)代碼和測試代碼被分開，降低耦合性維護(hù)成本低，減少代碼冗余?

19?、簡述 selenium 的原理

selenium 涉及到三個(gè)組件的通訊，分別是

• • 瀏覽器

  • webdriver

  • client

client 負(fù)責(zé)通過對應(yīng)的編程語言函數(shù)發(fā)送請求給 webdriver

client 其實(shí)并不知道瀏覽器是怎么工作的，但是 driver 知道，在 selenium 啟動(dòng)以后，driver 其實(shí)充當(dāng)了服務(wù)器的角色，跟 client 和瀏覽器通信，client根據(jù) webdriver 協(xié)議發(fā)送請求給 driver，driver 解析請求，并在瀏覽器上執(zhí)行相應(yīng)的操作，并把執(zhí)行結(jié)果返回給 client。這就是 selenium 工作的大致原理。

20?、 UI 自動(dòng)化測試用例在運(yùn)行過程中經(jīng)常會(huì)出現(xiàn)不穩(wěn)定的情況，也就是說這次可以通過，下次就沒有辦法通過了，如何去提升用例的穩(wěn)定性？

• 1. 界面上無法預(yù)測的彈框。頁面上經(jīng)常會(huì)根據(jù)用戶行為推送或者彈出動(dòng)態(tài)的信息，比如版本更新，消息通知，推薦產(chǎn)品等等，當(dāng)這些彈框出現(xiàn)以后，原來的頁面元素會(huì)被遮擋，無法被定位，此時(shí)可能會(huì)造成自動(dòng)化測試腳本運(yùn)行錯(cuò)誤。

• 2. 頁面元素的動(dòng)態(tài)變化；主要有兩方面的變化，第一方面，前端需求經(jīng)常發(fā)生變化導(dǎo)致前端代碼頻繁修改，當(dāng)前端頁面變化以后可能會(huì)造成之前的元素?zé)o法被定位；第二方面，頁面可能會(huì)根據(jù)用戶的狀態(tài)和等級(jí)展示不同的頁面，或者是這一次訪問的數(shù)據(jù)和下一次會(huì)不同。

• 3. 隨機(jī)的頁面延遲造成控件識(shí)別失敗；受限于網(wǎng)絡(luò)環(huán)境和設(shè)備狀態(tài)，自動(dòng)化代碼每次運(yùn)行時(shí)可能會(huì)產(chǎn)生隨機(jī)的超時(shí)處理。

• 4. 測試數(shù)據(jù)變更。ui 測試每個(gè)用例的測試步驟會(huì)有很大的區(qū)別，他們不能共享同一套代碼邏輯，當(dāng)測試數(shù)據(jù)變更時(shí)，如果不能及時(shí)更新自動(dòng)化代碼，會(huì)造成腳本執(zhí)行出錯(cuò)等問題。

（4）自動(dòng)化項(xiàng)目實(shí)戰(zhàn)能力評估

1 、介紹一下你的自動(dòng)化測試框架？

我的框架主要根據(jù)分層思想設(shè)計(jì)了幾個(gè)獨(dú)立模塊：

• 模塊一：主要存放通用業(yè)務(wù)代碼，比如接口訪問，數(shù)據(jù)庫操作，excel 操作，等

• 模塊二：主要負(fù)責(zé)用例收集和用例執(zhí)行，生成測試報(bào)告。

• 模塊三：主要負(fù)責(zé)存放測試用例數(shù)據(jù)。通常是使用 excel, yaml, 等通用數(shù)據(jù)格式。

• 模塊四：主要存放測試用例方法和測試邏輯相關(guān)代碼。這里會(huì)調(diào)用模塊的通用方法。

2 、講一下在工作中怎么做的自動(dòng)化測試？

• • a. 根據(jù)自動(dòng)化測試特性整理需求

  • b. 根據(jù)優(yōu)先級(jí)，和公司人員狀況制定自動(dòng)化測試計(jì)劃

  • c. 制定自動(dòng)化測試執(zhí)行方案

  • d. 自動(dòng)化測試用例設(shè)計(jì)或從功能測試用例中挑選適合的用例

  • e. 自動(dòng)化腳本的開發(fā)

  • f. 自動(dòng)化測試執(zhí)行，生成報(bào)告

3 、自動(dòng)化測試框架至少包含哪些核心模塊。

• • 基礎(chǔ)方法

  • 數(shù)據(jù)驅(qū)動(dòng)

  • PO 分層

  • 接口分層

  • 接口數(shù)據(jù)管理

  • 異常處理 - 工具包

  • 配置

  • 日志收集

  • 測試報(bào)告

4 、框架中的接口參數(shù)傳遞怎么做的？是否有優(yōu)化，第三庫有沒有用到，方法是什么？

• 框架當(dāng)中接口參數(shù)傳遞主要涉及 2 部分：一是數(shù)據(jù)生成或者提取，二是替換。在框架當(dāng)中，數(shù)據(jù)從響應(yīng)結(jié)果提取用的 jsonpath，提取表達(dá)式直接寫在 excel 當(dāng)中，提取之后存儲(chǔ)到變量類 Data 當(dāng)中，作為它的類屬性。

• 替換時(shí)，則直接訪問 Data 類的類屬性，將其值拿到并替換。在 excel 中要替換的標(biāo)志為#value#。因?yàn)闀?huì)存在有多個(gè)要替換的值，所以用正則表達(dá)式來查找到所有要替換的標(biāo)識(shí)，然后全部替換。

• 用到第三方庫的話，一個(gè)是 jsonpath，一個(gè)是 re

5 、拿到一個(gè)項(xiàng)目，怎么衡量這個(gè)項(xiàng)目做接口自動(dòng)化還是 UI 自動(dòng)化？

1、不管什么項(xiàng)目都可以做接口自動(dòng)化

2、偏公司內(nèi)部人員使用的管理平臺(tái)無需做 UI 自動(dòng)化，對外用戶的可以考慮做

UI 自動(dòng)化

6?、框架的數(shù)據(jù)庫驗(yàn)證在你 excel 中 check_sql 放的是什么，你如何做比對？

• check_sql 中存放的是一個(gè)列表，列表的成員是字典，字典有 3 個(gè) key,一個(gè)是sql 語句，第二個(gè)是期望結(jié)果，第三個(gè)是 sql 的查詢方式(查詢總條數(shù)/查詢值)在收到響應(yīng)結(jié)果以后，會(huì)遍歷 check_sql 中的列表，將每一個(gè)字典取出來，執(zhí)行sql 語句查詢結(jié)果 ，并與期望結(jié)果做比較。

7 、自動(dòng)化測試中，測試用例的執(zhí)行是怎么讓他按照你寫的用例一條一條執(zhí)行的？

在我的項(xiàng)目接口自動(dòng)化中，我用?pytest 框架。

一個(gè)接口的用例，我的用例數(shù)據(jù)是寫在 excel 當(dāng)中，在編寫時(shí)就是按照順序?qū)懙?#xff0c;從 excel 讀取出來使用數(shù)據(jù)驅(qū)動(dòng) 方式就是按照 excel 中的順序；

多個(gè)接口的用例，因?yàn)槲沂且粋€(gè)接口一個(gè) py 測試文件，所以我在 py 測試文件命名中用 00-99 數(shù)字按順序編寫的。

8、Login 這些用例數(shù)據(jù)是在哪里取的？excel 嗎？用到什么方法？什么第三方庫？

具體公司的業(yè)務(wù)：業(yè)務(wù)怎么開展 項(xiàng)目的介紹？( 或者簡單介紹最熟悉的項(xiàng)目介紹：)

主要考察 2 個(gè)方面：一是表達(dá)能力和業(yè)務(wù)的熟悉度。二是做的項(xiàng)目復(fù)雜度如何，是否能勝任復(fù)雜項(xiàng)目的測試工作。

一般是根據(jù)自己的業(yè)務(wù)來回答。最好是能講出有挑戰(zhàn)性有難度或者復(fù)雜的業(yè)務(wù)場景。面試官不一定聽得懂，但是他覺得復(fù)雜挺難的就可以。

最后感謝每一個(gè)認(rèn)真閱讀我文章的人，禮尚往來總是要有的，雖然不是什么很值錢的東西，如果你用得到的話可以直接拿走：

這些資料，對于做【軟件測試】的朋友來說應(yīng)該是最全面最完整的備戰(zhàn)倉庫，這個(gè)倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！凡事要趁早，特別是技術(shù)行業(yè)，一定要提升技術(shù)功底。