軟件測試功能/數(shù)據(jù)庫/linux/接口/自動(dòng)化/測試開發(fā)面試真題解析

功能測試：1、你的測試職業(yè)發(fā)展是什么编检？

測試經(jīng)驗(yàn)越多胎食，測試能力越高。所以我的職業(yè)發(fā)展是需要時(shí)間積累的允懂，一步步向著高級測試工程師奔去厕怜。而且我也有初步的職業(yè)規(guī)劃，前 2 年積累測試項(xiàng)目經(jīng)驗(yàn)蕾总，按如何做好測試工程師的要點(diǎn)去要求自己粥航，不斷更新自己改正自己，做好測試任務(wù)谤专。

然后學(xué)習(xí)自動(dòng)化測試躁锡，編程語言，測試開發(fā)技術(shù)置侍，能夠?yàn)闇y試圈帶來一些貢獻(xiàn)

2映之、你認(rèn)為測試人員需要具備哪些素質(zhì)？

做測試應(yīng)該要有一定的協(xié)調(diào)能力蜡坊，因?yàn)闇y試人員經(jīng)常要與開發(fā)接觸處理一些問題杠输，如果處理不好的話會(huì)引起一些沖突，這樣的話工作上就會(huì)不好做秕衙。還有測試人員要有一定的耐心蠢甲，有的時(shí)候做測試很枯燥乏味。

持有一顆懷疑的心据忘，不能輕易相信開發(fā)自測過

耐心加技術(shù)是測試人員在企業(yè)中生存之道

掌握基本的測試基礎(chǔ)理論本著找出軟件存在的問題的態(tài)度進(jìn)行測試鹦牛，不要以挑刺的形象出現(xiàn)可熟練閱讀需求規(guī)格說明書等文檔以用戶的觀點(diǎn)看問題有強(qiáng)烈的質(zhì)量意識細(xì)心和責(zé)任心良好的有效的溝通方式(與開發(fā)人員及客戶)具有以往的測試經(jīng)驗(yàn)?zāi)軌蚣皶r(shí)準(zhǔn)確的判斷出高危險(xiǎn)區(qū)在何處

3、軟件測試的目的是什么勇吊？

軟件測試的目的并不是證明軟件沒有錯(cuò)誤曼追，而是找出軟件產(chǎn)品中的錯(cuò)誤，使軟件盡可能的符合用戶的要求汉规。

當(dāng)然軟件測試是不可能找出全部錯(cuò)誤的礼殊。

4、測試分為哪幾個(gè)階段针史？

一般來說分為 5 個(gè)階段：單元測試晶伦、集成測試、確認(rèn)測試啄枕、系統(tǒng)測試婚陪、驗(yàn)收測試

5、結(jié)合你以前的學(xué)習(xí)和工作經(jīng)驗(yàn)射亏，你認(rèn)為如何做好測試近忙，做好軟件測試的一些關(guān)鍵點(diǎn)

具備較強(qiáng)的需求分析能力竭业，測試人員必須非常熟悉系統(tǒng)功能和業(yè)務(wù)測試要有計(jì)劃智润，而且測試方案要和整個(gè)項(xiàng)目計(jì)劃協(xié)調(diào)好必須實(shí)現(xiàn)編寫測試用例及舍，測試執(zhí)行階段必須根據(jù)測試用例進(jìn)行

易用性，功能窟绷，分支锯玛，邊界，性能等功能性和非功能性需求都要進(jìn)行測試

對于復(fù)雜的流程一定要進(jìn)行流程分支兼蜈，組合條件分析攘残，再進(jìn)行等價(jià)類劃分準(zhǔn)備相關(guān)測試數(shù)據(jù)

定位 bug 要盡量準(zhǔn)確，提高與開發(fā)人員協(xié)調(diào)的效率为狸，盡早的解決 bug 充實(shí)自己的技能：不僅熟練掌握軟件測試基礎(chǔ)知識和理論歼郭，還要學(xué)習(xí)編程語言、數(shù)據(jù)庫辐棒、linux 腳本病曾，自動(dòng)化測試、性能測試技術(shù) 6漾根、談?wù)勀阒皽y試的項(xiàng)目流程泰涂，在每個(gè)階段的輸出有哪些？

a 新功能：首先會(huì)召開需求分析會(huì)議辐怕，參加人員有產(chǎn)品逼蒙、開發(fā)和測試，主要是探討需求主要的一些功能點(diǎn)寄疏；(輸出：數(shù)據(jù)庫表設(shè)計(jì)是牢；接口設(shè)計(jì)，需求文檔,提測時(shí)間)

b.然后開發(fā)就排期進(jìn)行開發(fā)陕截，主管開始編寫測試計(jì)劃驳棱，對我們進(jìn)行任務(wù)分配。(輸出：：測試計(jì)劃)

c.我們參考需求規(guī)格說明書及原型圖編寫測試用例艘策，寫完之后會(huì)進(jìn)行用例評審蹈胡，有評審修改的就修改整理形成最終的用例版本；（輸出：測試用例）

d.提測（測試去 Jenkins 部署構(gòu)建）：開發(fā)人員版本編譯完成后朋蔫，我們會(huì)先進(jìn)行預(yù)測罚渐，主要對主功能業(yè)務(wù)進(jìn)行測試，接口測試

如果主業(yè)務(wù)流程不通過驯妄，直接返回給開發(fā)進(jìn)行修改荷并。預(yù)測通過，依據(jù)測試用例進(jìn)行系統(tǒng)測試青扔。測試過程中源织，提交 bug翩伪，跟蹤 bug，進(jìn)行回歸測試直至不存在嚴(yán)重 bug谈息，滿足用戶需求缘屹，（輸出：測試報(bào)告）

e.產(chǎn)品發(fā)布上線后，關(guān)注 web 是否正常運(yùn)行侠仇，要進(jìn)行常規(guī)的維護(hù)性測試轻姿。回歸測試

（輸出：上線記錄逻炊，上線的新功能）

7互亮、怎樣寫測試計(jì)劃和編寫測試用例？

簡單點(diǎn)余素，測試計(jì)劃里應(yīng)有詳細(xì)的測試策略和測試方法豹休，合理詳盡的資源安排等，至于測試用例桨吊，那是依賴于需求(包括功能與非功能需求)是否細(xì)化到功能點(diǎn)威根，是否可測試等。

1屏积、測試人員盡早介入医窿，徹底理解清楚需求，這個(gè)是寫好測試用例的基礎(chǔ)

2炊林、如果以前有類似的需求姥卢，可以參考類似需求的測試用例，然后還需要看類似需求的 bug 情況

3渣聚、清楚輸入独榴、輸出的各種可能性，以及各種輸入的之間的關(guān)聯(lián)關(guān)系奕枝，理解清楚需求的執(zhí)行邏輯棺榔，通過等價(jià)類、邊界值隘道、判定表等方法找出大部分用例

4症歇、找到需求相關(guān)的一些特性，補(bǔ)充測試用例

5谭梗、根據(jù)自己的經(jīng)驗(yàn)分析遺漏的測試場景

6忘晤、多總結(jié)類似功能點(diǎn)的測試點(diǎn)，才能夠?qū)懗鲑|(zhì)量越來越高的測試用例

7激捏、書寫格式一定要清晰

8设塔、為什要在一個(gè)團(tuán)隊(duì)中開展測試工作？

因?yàn)闆]有經(jīng)過測試的軟件很難在發(fā)布之前知道該軟件的質(zhì)量远舅，就好比 ISO 質(zhì)量認(rèn)證一樣闰蛔，測試同樣也需要質(zhì)量認(rèn)證痕钢，這個(gè)時(shí)候就需要在團(tuán)隊(duì)中開展軟件測試的工作。在測試的過程中發(fā)現(xiàn)軟件中存在的問題序六，及時(shí)讓開發(fā)人員得知并修改問題任连，在即將發(fā)布時(shí)，從測試報(bào)告中得出軟件的質(zhì)量情況难咕。

9课梳、你所熟悉的軟件測試類型有哪些?

測試類型有：功能測試距辆、性能測試余佃、界面測試

功能測試在測試工作中占有比例最大，功能測試也叫黑盒測試

性能測試是通過自動(dòng)化的測試工具模擬多種正常跨算、峰值以及異常負(fù)載條件來對系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測試爆土。負(fù)載測試和壓力測試都屬于性能測試，兩者可以結(jié)合進(jìn)行

界面測試诸蚕，界面是軟件與用戶交互的最直接的層步势，界面的好壞決定用戶對軟件的第一印象

區(qū)別在于，功能測試關(guān)注產(chǎn)品的所有功能背犯，要考慮到每個(gè)細(xì)節(jié)功能坏瘩，每個(gè)可能存在的功能問題。性能測試主要關(guān)注產(chǎn)品整體的多用戶并發(fā)下的穩(wěn)定性和健壯性漠魏。界面測試則關(guān)注與用戶體驗(yàn)相關(guān)內(nèi)容倔矾，用戶使用該產(chǎn)品的時(shí)候是否已用，是否易懂柱锹，是否規(guī)范(用戶無意輸入無效的數(shù)據(jù)哪自，當(dāng)然考慮到體驗(yàn)性，不能太粗魯?shù)膹棾鼍?禁熏。做某個(gè)性能測試的時(shí)候壤巷，首先它可能是個(gè)功能點(diǎn)，首先要保證它的功能是沒有問題的瞧毙，然后再考慮性能的問題胧华。

10、黑盒測試宙彪，編寫測試用例方法有哪些矩动？

黑盒測試也稱功能測試或數(shù)據(jù)驅(qū)動(dòng)測試，它是在已知產(chǎn)品所應(yīng)具有的功能您访，通過測試來檢測每個(gè)功能是否都能正常使用铅忿，在測試時(shí)，把程序看作一個(gè)不能打開的黑盆子灵汪，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下檀训，測試者在程序接口進(jìn)行測試柑潦，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)鋸而產(chǎn)生正確的輸出信息峻凫，并且保持外部信息（如數(shù)據(jù)庫或文件）的完整性渗鬼。

“黑盒”法著眼于程序外部結(jié)構(gòu)、不考慮內(nèi)部邏輯結(jié)構(gòu)荧琼、針對軟件界面和軟件功能進(jìn)行測試譬胎。“黑盒”法是窮舉輸入測試命锄，只有把所有可能的輸入都作為測試情況使用堰乔，才能以這種方法查出程序中所有的錯(cuò)誤。實(shí)際上測試情況有無窮多個(gè)脐恩，因此不僅要測試所有合法的輸入镐侯，而且還要對那些不合法但是可能的輸入進(jìn)行測試。

常用的黑盒測試方法有：等價(jià)類劃分法驶冒；邊界值分析法苟翻；因果圖法；場景法骗污；正交實(shí)驗(yàn)設(shè)計(jì)法崇猫；判定表驅(qū)動(dòng)分析法；錯(cuò)誤推測法需忿；功能圖分析法诅炉。

11.請說一下白盒測試是什么，編寫測試用例方法有哪些贴谎？

白盒測試也稱為結(jié)構(gòu)測試或邏輯驅(qū)動(dòng)測試汞扎，是針對被測單元內(nèi)部是如何進(jìn)行工作的測試。它根據(jù)程序的控制結(jié)構(gòu)設(shè)計(jì)測試用例擅这，主要用于軟件或程序驗(yàn)證澈魄。白盒測試法檢查程序內(nèi)部邏輯結(jié)構(gòu)，對所有的邏輯路徑進(jìn)行測試仲翎，是一種窮舉路徑的測試方法痹扇，但即使每條路徑都測試過了，但仍然有可能存在錯(cuò)誤溯香。因?yàn)椋焊F舉路徑測試無法檢查出程序本身是否違反了設(shè)計(jì)規(guī)范鲫构，即程序是否是一個(gè)錯(cuò)誤的程序；窮舉路徑測試不可能檢查出程序因?yàn)檫z漏路徑而出錯(cuò)玫坛；窮舉路徑測試發(fā)現(xiàn)不了一些與數(shù)據(jù)相關(guān)的錯(cuò)誤结笨。

白盒測試需要遵循的原則有：1. 保證一個(gè)模塊中的所有獨(dú)立路徑至少被測試一次；2. 所有邏輯值均需要測試真（true）和假（false）；兩種情況炕吸；3. 檢查程序的內(nèi)部數(shù)據(jù)結(jié)構(gòu)伐憾，保證其結(jié)構(gòu)的有效性；4. 在上下邊界及可操作范圍內(nèi)運(yùn)行所有循環(huán)赫模。

常用白盒測試方法：

靜態(tài)測試：不用運(yùn)行程序的測試树肃，包括代碼檢查、靜態(tài)結(jié)構(gòu)分析瀑罗、代碼質(zhì)量度量胸嘴、文檔測試等等，它可以由人工進(jìn)行斩祭，充分發(fā)揮人的邏輯思維優(yōu)勢劣像，也可以借助軟件工具（Fxcop）自動(dòng)進(jìn)行。

動(dòng)態(tài)測試：需要執(zhí)行代碼停忿，通過運(yùn)行程序找到問題驾讲，包括功能確認(rèn)與接口測試、覆蓋率分析席赂、性能分析、內(nèi)存分析等时迫。

白盒測試中的邏輯覆蓋包括語句覆蓋颅停、判定覆蓋、條件覆蓋掠拳、判定/條件覆蓋癞揉、條件組合覆蓋和路徑覆蓋。六種覆蓋標(biāo)準(zhǔn)發(fā)現(xiàn)錯(cuò)誤的能力呈由弱到強(qiáng)的變化：

1.語句覆蓋每條語句至少執(zhí)行一次溺欧。

2.判定覆蓋每個(gè)判定的每個(gè)分支至少執(zhí)行一次喊熟。

3.條件覆蓋每個(gè)判定的每個(gè)條件應(yīng)取到各種可能的值。

4.判定/條件覆蓋同時(shí)滿足判定覆蓋條件覆蓋姐刁。

5.條件組合覆蓋每個(gè)判定中各條件的每一種組合至少出現(xiàn)一次芥牌。

6.路徑覆蓋使程序中每一條可能的路徑至少執(zhí)行一次。

12聂使、Beta 測試與 alpha 測試的區(qū)別壁拉？

答：alpha 測試是公司內(nèi)部在模擬實(shí)際操作環(huán)境下進(jìn)行的一種驗(yàn)收，公司內(nèi)部會(huì)組織內(nèi)部員工進(jìn)行的測試柏靶，alpha 測試不能由程序員或者測試完成弃理。

Beta 測試是軟件的多個(gè)用戶在一個(gè)或多個(gè)用戶的實(shí)際使用環(huán)境下進(jìn)行的測試，beta 測試不能由程序員或測試員完成屎蜓。

13痘昌、寫過測試計(jì)劃或者是測試報(bào)告么？測試計(jì)劃包括哪些主要步驟和信息？測試報(bào)告包括哪些內(nèi)容辆苔？

測試報(bào)告交付文檔有哪些笔诵？

答：寫過；1姑子、測試計(jì)劃包括：項(xiàng)目信息乎婿、參與文檔、測試范圍街佑、測試策略谢翎、測試時(shí)間人員安排、測試環(huán)境沐旨；2森逮、測試報(bào)告包含：項(xiàng)目背景、參考資料磁携、測試范圍褒侧、測試結(jié)果及缺陷分析、測試結(jié)論與建議谊迄，風(fēng)險(xiǎn)評估闷供；3、交付文檔：主要是測試用例统诺、測試計(jì)劃歪脏、測試報(bào)告。

14粮呢、對于重現(xiàn)率不高的 BUG 怎么處理婿失？

先在出現(xiàn)問題的環(huán)境上盡量重現(xiàn)，保持瀏覽器環(huán)境啄寡、出現(xiàn)問題的特定賬號等的一致豪硅，多次嘗試仍然不能重現(xiàn)，也要記錄到 bug 平臺挺物，將出現(xiàn)問題的特征步驟盡量描述清楚懒浮，附帶問題截圖及日志截圖、注明偶現(xiàn)姻乓；如果項(xiàng)目時(shí)間允許嵌溢，bug 等級高，需要開發(fā)協(xié)助重現(xiàn)蹋岩；如果時(shí)間不允許赖草，記錄到 BUG 平臺后續(xù)在跟進(jìn)。

15剪个、bug 的生命周期秧骑？

答：Bug 的生命周期，就是一個(gè) bug 被發(fā)現(xiàn)到這個(gè) bug 被關(guān)閉的過程，生命周期中一般缺陷狀態(tài)：新建乎折、指派绒疗、已解決、待驗(yàn)骂澄、關(guān)閉

如果待驗(yàn)證的 bug 在驗(yàn)證是沒有解決好吓蘑，我們需要重新打開（激活）→指派→已解決→待驗(yàn)，循環(huán)這個(gè)過程坟冲，中間其他狀態(tài)：重新打開磨镶、拒絕、延期等

16健提、說一說 bug 的類型

Bug 類型

? 代碼錯(cuò)誤 界面優(yōu)化 設(shè)計(jì)缺陷 配置相關(guān) 安裝部署 安全相關(guān) 性能問題 標(biāo)準(zhǔn)規(guī)范 測試腳本 其他

17琳猫、當(dāng)你提了一個(gè) bug，開發(fā)認(rèn)為這不是 bug私痹，怎么處理脐嫂？

答：首先確認(rèn)開發(fā)環(huán)境是否跟自己測試環(huán)境一致，確認(rèn)在測試環(huán)境能重現(xiàn)紊遵，如果確認(rèn)是缺陷跟開發(fā)保持有效溝通账千，如果是級別較低的建議性 bug，可以先記錄到 bug 平臺癞蚕，先保留溝通蕊爵。如果是 bug 級別較高的問題，對應(yīng)需求文檔的預(yù)期結(jié)果跟開發(fā)說明桦山，更有說服力；耐心講解 BUG 的危害醋旦，不行就找產(chǎn)品確認(rèn)恒水，確實(shí)是 BUG 注明情況并再次指派給開發(fā)

18、有沒有你印象深刻的 bug饲齐，bug 的原因钉凌？

答：身份證末尾 X 結(jié)尾的， 實(shí)名認(rèn)證顯示成功捂人，但是在后面提現(xiàn)的時(shí)候御雕，會(huì)報(bào)錯(cuò)，后面發(fā)現(xiàn)是保存到庫里面的滥搭，都是小寫 X 的酸纲，導(dǎo)致提現(xiàn)這邊不識別，印象深刻的原因是因?yàn)榛艘欢ǖ臅r(shí)間去找到這個(gè) bug瑟匆，并且自己嘗試定位到原因闽坡，所以印象深刻。

19.作為測試工程師對需求分析的理解？（用戶場景）

a.了解需求背景及商業(yè)價(jià)值

明確了解背景疾嗅，為什么要做這個(gè)需求外厂，明白需求存在什么樣的商業(yè)價(jià)值后，才更明確該站在用戶哪個(gè)角度去判斷考慮該需求

b.站在用戶角度去分析需求

產(chǎn)品提出的功能代承，站在真實(shí)的用戶角度判斷該需求使用對用戶來說使用起來是否順暢汁蝶，操作路徑是否多且復(fù)雜存在冗余，有什么風(fēng)險(xiǎn)

顯性需求：產(chǎn)品明確提出的需求

隱性需求：明確需求背后可能存在的需求（異常場景）

功能性需求：顯性及隱形需求里面相關(guān)業(yè)務(wù)

非功能性需求：用戶體驗(yàn)论悴，性能掖棉，可靠性，安全性意荤，可維護(hù)性啊片，可繼承性

c.站在產(chǎn)品的實(shí)現(xiàn)角度去分析該需求

該需求對繼承性需求在邏輯上是否存在沖突，原有邏輯是否存在沖突玖像，遺漏

d.站在項(xiàng)目的角度去分析該需求

需求拆解的是否足夠細(xì)紫谷，是否可再拆解，是否可測試捐寥，優(yōu)先級如何笤昨，有什么風(fēng)險(xiǎn)

20.你在瀏覽器打開一個(gè) web 項(xiàng)目網(wǎng)址，中間發(fā)生了什么握恳？

網(wǎng)絡(luò)請求瞒窒，域名解析、請求后端接口乡洼，獲取接口響應(yīng)值崇裁，根據(jù)數(shù)據(jù)展示，關(guān)閉請求

1束昵、DNS 解析

2拔稳、TCP 連接

3、發(fā)送 HTTP 請求

4锹雏、服務(wù)器處理請求并返回 HTTP 報(bào)文（apach巴比，tomcat。nginx）

5礁遵、瀏覽器解析渲染頁面

6轻绞、連接結(jié)束

21.如何分析一個(gè) bug 是前端還是后端的問題？

檢查接口佣耐，前端和后臺之間是通過接口文件相互聯(lián)系的政勃，需要查看接口文件

檢查請求的數(shù)據(jù)是什么，反饋的數(shù)據(jù)又是什么

頁面可以直接 F12晰赞，或者抓包查看稼病。如果發(fā)送的數(shù)據(jù)是正確的选侨，但是后臺反饋的數(shù)據(jù)是不符合需求的，那就是后臺的問題然走；如果前端沒有請求接口或請求的時(shí)候發(fā)送數(shù)據(jù)與需求不符援制，那這個(gè)時(shí)候就是前端的問題了。

22芍瑞、V 模型和 W 模型

測試和開發(fā)應(yīng)該按照 W 模型的方式進(jìn)行結(jié)合晨仑，測試和開發(fā)同步進(jìn)行，能夠盡早發(fā)現(xiàn)軟件缺陷拆檬，降低軟件開發(fā)的成本洪己。

在 V 模型中，測試過程被加在開發(fā)過程的后半部分竟贯，單元測試所檢測代碼的開發(fā)是否符合詳細(xì)設(shè)計(jì)的要求答捕。集成測試所檢測此前測試過的各組成部分是否能完好地結(jié)合到一起。系統(tǒng)測試所檢測已集成在一起的產(chǎn)品是否符合系統(tǒng)規(guī)格說明書的要求屑那。而驗(yàn)收測試則檢測產(chǎn)品是否符合最終用戶的需求拱镐。V 模型的缺陷在于僅僅把測試過程作為在需求分析、系統(tǒng)設(shè)計(jì)及編碼之后的一個(gè)階段持际，忽視了測試對需求分析沃琅、系統(tǒng)設(shè)計(jì)的驗(yàn)證欣孤，因此需求階段的缺陷很可能一直到后期的驗(yàn)收測試才被發(fā)現(xiàn)喜颁，此時(shí)進(jìn)行彌補(bǔ)將耗費(fèi)大量人力物力資源客冈。

相對于 V 模型衷笋，W 模型增加了軟件各開發(fā)階段中應(yīng)同步進(jìn)行的驗(yàn)證和確認(rèn)活動(dòng)。W 模型由兩個(gè) V 字型模型組成凡伊，分別代表測試與開發(fā)過程糠馆，圖中明確表示出了測試與開發(fā)的并行關(guān)系橘茉。

W 模型強(qiáng)調(diào)：測試伴隨著整個(gè)軟件開發(fā)周期澈歉，而且測試的對象不僅僅是程序朱庆，需求、設(shè)計(jì)等同樣要測試闷祥，也就是說，測試與開發(fā)是同步進(jìn)行的傲诵。W 模型有利于盡早地全面的發(fā)現(xiàn)問題凯砍。例如，需求分析完成后拴竹，測試人員就應(yīng)該參與到對需求的驗(yàn)證和確認(rèn)活動(dòng)中悟衩，以盡早地找出缺陷所在。同時(shí)栓拜，對需求的測試也有利于及時(shí)了解項(xiàng)目難度和測試風(fēng)險(xiǎn)座泳，及早制定應(yīng)對措施惠昔，這將顯著減少總體測試時(shí)間，加快項(xiàng)目進(jìn)度挑势。

W 模型中測試的活動(dòng)與軟件開發(fā)同步進(jìn)行镇防，測試的對象不僅僅是程序，還包括需求和設(shè)計(jì)潮饱，因此能夠盡早發(fā)現(xiàn)軟件缺陷来氧，降低軟件開發(fā)的成本。

23.請回答集成測試和系統(tǒng)測試的區(qū)別香拉，以及它們的應(yīng)用場景主要是什么啦扬？區(qū)別：

1、計(jì)劃和用例編制的先后順序：從 V 模型來講凫碌，在需求階段就要制定系統(tǒng)測試計(jì)劃和用例扑毡，HLD 的時(shí)候做集成測試計(jì)劃和用例，有些公司的具體實(shí)踐不一樣盛险，但是順序肯定是先做系統(tǒng)測試計(jì)劃用例瞄摊，再做集成。

2枉层、用例的粒度：系統(tǒng)測試用例相對很接近用戶接受測試用例泉褐，集成測試用例比系統(tǒng)測試用例更詳細(xì)，而且對于接口部分要重點(diǎn)寫鸟蜡，畢竟要集成各個(gè)模塊或者子系統(tǒng)膜赃。

3、執(zhí)行測試的順序：先執(zhí)行集成測試揉忘，待集成測試出的問題修復(fù)之后跳座，再做系統(tǒng)測試。

應(yīng)用場景：

集成測試：完成單元測試后泣矛，各模塊聯(lián)調(diào)測試疲眷；集中在各模塊的接口是否一致、各模塊間的數(shù)據(jù)流和控制流是否按照設(shè)計(jì)實(shí)現(xiàn)其功能您朽、以及結(jié)果的正確性驗(yàn)證等等狂丝；可以是整個(gè)產(chǎn)品的集成測試，也可以是大模塊的集成測試哗总；集成測試主要是針對程序內(nèi)部結(jié)構(gòu)進(jìn)行測試几颜，特別是對程序之間的接口進(jìn)行測試。集成測試對測試人員的編寫腳本能力要求比較高讯屈。測試方法一般選用黑盒測試和白盒測試相結(jié)合蛋哭。

系統(tǒng)測試：針對整個(gè)產(chǎn)品的全面測試，既包含各模塊的驗(yàn)證性測試（驗(yàn)證前兩個(gè)階段測試的正確性）和功能性（產(chǎn)品提交個(gè)用戶的功能）測試涮母，又包括對整個(gè)產(chǎn)品的健壯性谆趾、安全性躁愿、可維護(hù)性及各種性能參數(shù)的測試。系統(tǒng)測試測試軟件《需求規(guī)格說明書》中提到的功能是否有遺漏沪蓬，是否正確的實(shí)現(xiàn)彤钟。做系統(tǒng)測試要嚴(yán)格按照《需求規(guī)格說明書》，以它為標(biāo)準(zhǔn)怜跑。測試方法一般都使用黑盒測試法样勃。

24、請你說一說 web 測試和 app 測試的不同點(diǎn)系統(tǒng)架構(gòu)方面：

web 項(xiàng)目性芬，一般都是 b/s 架構(gòu)峡眶，基于瀏覽器的

app 項(xiàng)目，則是 c/s 的植锉，必須要有客戶端辫樱，用戶需要安裝客戶端。

web 測試只要更新了服務(wù)器端俊庇，客戶端就會(huì)同步會(huì)更新狮暑。App 項(xiàng)目則需要客戶端和服務(wù)器都更新。

性能方面:

web 頁面主要會(huì)關(guān)注響應(yīng)時(shí)間

而 app 則還需要關(guān)心流量辉饱、電量搬男、CPU、GPU彭沼、Memory 這些缔逛。

它們服務(wù)端的性能沒區(qū)別，都是一臺服務(wù)器姓惑。

兼容方面：

web 是基于瀏覽器的褐奴，所以更傾向于瀏覽器和電腦硬件，電腦系統(tǒng)的方向的兼容

app 測試則要看分辨率于毙，屏幕尺寸敦冬，還要看設(shè)備系統(tǒng)。

web 測試是基于瀏覽器的所以不必考慮安裝卸載唯沮。

而 app 是客戶端的脖旱，則必須測試安裝、更新介蛉、卸載夯缺。除了常規(guī)的安裝、更新甘耿、卸載還要考慮到異常場景。包括安裝時(shí)的中斷竿滨、弱網(wǎng)佳恬、安裝后刪除安裝文件 捏境。

此外 APP 還有一些專項(xiàng)測試：如網(wǎng)絡(luò)、適配性毁葱。

25 請你說一說簡單用戶界面登陸過程都需要做哪些分析參考回答：一垫言、功能測試

1.輸入正確的用戶名和密碼，點(diǎn)擊提交按鈕倾剿，驗(yàn)證是否能正確登錄筷频。

2.輸入錯(cuò)誤的用戶名或者密碼,驗(yàn)證登錄會(huì)失敗，并且提示相應(yīng)的錯(cuò)誤信息前痘。

3.登錄成功后能否能否跳轉(zhuǎn)到正確的頁面

4.用戶名和密碼凛捏，如果太短或者太長，應(yīng)該怎么處理

5.用戶名和密碼芹缔，中有特殊字符（比如空格）坯癣，和其他非英文的情況

6.記住用戶名的功能

7.登陸失敗后，不能記錄密碼的功能

8.用戶名和密碼前后有空格的處理

9.密碼是否非明文顯示顯示最欠，使用星號圓點(diǎn)等符號代替示罗。

10.牽扯到驗(yàn)證碼的，還要考慮文字是否扭曲過度導(dǎo)致辨認(rèn)難度大芝硬，考慮顏色（色盲使 用者）蚜点，刷新或換一個(gè)按鈕是否好用

11.登錄頁面中的注冊、忘記密碼拌阴，登出用另一帳號登陸等鏈接是否正確

12.輸入密碼的時(shí)候绍绘，大寫鍵盤開啟的時(shí)候要有提示信息。

13.什么都不輸入皮官，點(diǎn)擊提交按鈕脯倒，檢查提示信息。

二捺氢、界面測試

1.布局是否合理藻丢，testbox 和按鈕是否整齊。

2.testbox 和按鈕的長度摄乒，高度是否復(fù)合要求悠反。

界面的設(shè)計(jì)風(fēng)格是否與 UI 的設(shè)計(jì)風(fēng)格統(tǒng)一。

界面中的文字簡潔易懂馍佑，沒有錯(cuò)別字斋否。

三、性能測試

1.打開登錄頁面拭荤，需要的時(shí)間是否在需求要求的時(shí)間內(nèi)茵臭。

2.輸入正確的用戶名和密碼后，檢查登錄成功跳轉(zhuǎn)到新頁面的時(shí)間是否在需求要求的時(shí)間內(nèi)舅世。

3.模擬大量用戶同時(shí)登陸旦委，檢查一定壓力下能否正常登陸跳轉(zhuǎn)奇徒。

四、安全性測試

1.登錄成功后生成的 Cookie缨硝，是否是 httponly (否則容易被腳本盜取)摩钙。

2.用戶名和密碼是否通過加密的方式，發(fā)送給 Web 服務(wù)器查辩。

3.用戶名和密碼的驗(yàn)證胖笛，應(yīng)該是用服務(wù)器端驗(yàn)證， 而不能單單是在客戶端用 javascript 驗(yàn)證宜岛。

4.用戶名和密碼的輸入框长踊，應(yīng)該屏蔽 SQL 注入攻擊。

5.用戶名和密碼的的輸入框谬返，應(yīng)該禁止輸入腳本 （防止 XSS 攻擊）之斯。

6.防止暴力破解，檢測是否有錯(cuò)誤登陸的次數(shù)限制遣铝。

是否支持多用戶在同一機(jī)器上登錄佑刷。

同一用戶能否在多臺機(jī)器上登錄。

五酿炸、可用性測試

是否可以全用鍵盤操作瘫絮，是否有快捷鍵。

輸入用戶名填硕，密碼后按回車麦萤，是否可以登陸。

輸入框能否可以以 Tab 鍵切換扁眯。

六壮莹、兼容性測試

1.不同瀏覽器下能否顯示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）。

2.同種瀏覽器不同版本下能否顯示正常且功能正常姻檀。

2.不同的平臺是否能正常工作命满，比如 Windows, Mac。

3.移動(dòng)設(shè)備上是否正常工作绣版，比如 Iphone, Andriod胶台。

4.不同的分辨率下顯示是否正常。

七杂抽、本地化測試

不同語言環(huán)境下诈唬，頁面的顯示是否正確。

26.如果做一個(gè)杯子的檢測缩麸，你如何測試參考回答：1.功能

（1）水倒水杯容量的一半

（2）水倒規(guī)定的安全線

（4）水杯容量刻度與其他水杯一致

（5）蓋子擰緊水倒不出來

（6）燙手驗(yàn)證

2.性能

（1）使用最大次數(shù)或時(shí)間

（2）掉地上不易損壞

（3）蓋子擰到什么程度水倒不出來

（4）保溫時(shí)間長

（5）杯子的耐熱性

（6）杯子的耐寒性

（7）長時(shí)間放置水不會(huì)漏

（8）杯子上放置重物達(dá)到什么程度杯子會(huì)被損壞

3.界面

（1）外觀完整铸磅、美觀

（2）大小與設(shè)計(jì)一樣（高、寬、容量愚屁、直徑）

（3）拿著舒服

（4）材質(zhì)與設(shè)計(jì)一樣

（5）杯子上的圖案掉落

（6）圖案遇水溶解

4.安全

（1）杯子使用的材質(zhì)毒或細(xì)菌的驗(yàn)證

（2）高溫材質(zhì)釋放毒性

（3）低溫材質(zhì)釋放毒性

5.易用性

（1）倒水方便

（2）喝水方便

（3）攜帶方便

（4）使用簡單济竹，容易操作

（5）防滑措施

6.兼容性

（1）杯子能夠容納果汁、白水霎槐、酒精、汽油等梦谜。

7.震動(dòng)測試

（1）杯子加包裝（有填充物）丘跌，六面震動(dòng)，檢查產(chǎn)品是否能應(yīng)對鐵路/公路/航空運(yùn)輸唁桩。

8.可移植性

（1）杯子在不同地方闭树、溫度環(huán)境下都可以正常使用。

27.請你來說一下購物車的測試用例參考回答：界面測試

? 界面布局荒澡、排版是否合理报辱；文字是否顯示清晰；不同賣家的商品是否區(qū)分明顯单山。

2.功能測試

未登錄時(shí)：

? 將商品加入購物車碍现，頁面跳轉(zhuǎn)到登錄頁面，登錄成功后購物車數(shù)量增加米奸；

? 點(diǎn)擊購物車菜單昼接，頁面跳轉(zhuǎn)到登錄頁面。

登錄后：

? 所有鏈接是否跳轉(zhuǎn)正確悴晰；

? 商品是否可以成功加入購物車慢睡；

? 購物車商品總數(shù)是否有限制；

? 商品總數(shù)是否正確铡溪；

? 全選功能是否好用漂辐；

? 刪除功能是否好用；

? 填寫委托單功能是否好用棕硫；

? 委托單中填寫的價(jià)格是否正確顯示髓涯；

? 價(jià)格總計(jì)是否正確；

? 商品文字太長時(shí)是否顯示完整饲帅；

? 店鋪名字太長時(shí)是否顯示完整复凳；

? 創(chuàng)新券商品是否打標(biāo)；

? 購物車中下架的商品是否有特殊標(biāo)識灶泵；

? 新加入購物車商品排序（添加購物車中存在店鋪的商品和購物車中不存在店鋪的商品）育八；

? 是否支持 TAB、ENTER 等快捷鍵赦邻；

? 商品刪除后商品總數(shù)是否減少髓棋；

? 購物車結(jié)算功能是否好用。

3.兼容性測試

? 不同瀏覽器測試。

4.易用性測試

? 刪除功能是否有提示按声；是否有回到頂部的功能膳犹；商品過多時(shí)結(jié)算按鈕是否可以浮動(dòng)顯示。

5.性能測試

? 壓力測試签则；并發(fā)測試须床。

28.請你進(jìn)行一下弱網(wǎng)模擬方法一：charles 弱網(wǎng)模擬

使用 chrome 的 webview 調(diào)試工具，缺點(diǎn)是只適用于 web 頁面的弱網(wǎng)模擬渐裂。

方法三：iOS 手機(jī)自帶 Network Link Conditioner 弱網(wǎng)模擬

iPhone 手機(jī)打開開發(fā)者選項(xiàng)豺旬，具體參考：

設(shè)置-開發(fā)者選項(xiàng) > Network Link Conditioner 入口。

系統(tǒng)已經(jīng)內(nèi)置常見網(wǎng)絡(luò)配置柒凉，也可以增加自定義配置族阅。

具體配置參數(shù)：

in Bandwidth 下行帶寬，即下行網(wǎng)絡(luò)速度

In packet loss 下行丟包率

in delay 下行延遲膝捞，單位 ms

out bandwidth 上行帶寬

out packet loss 上行丟包率

out delay 上行延遲

DNS delay DNS 解析延遲

protocol 支持 Any坦刀，IPV4、IPV6

interface 支持 Any蔬咬，WI-Fi鲤遥，cellular（蜂窩網(wǎng)）

總結(jié)：

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

這些資料北启，對于【軟件測試】的朋友來說應(yīng)該是最全面最完整的備戰(zhàn)倉庫卜朗，這個(gè)倉庫也陪伴上萬個(gè)測試工程師們走過最艱難的路程，希望也能幫助到你!

?既然都看到這里啦咕村，請你幫個(gè)忙：

1场钉、點(diǎn)贊，讓更多小伙伴看到懈涛；

2逛万、關(guān)注我，持續(xù)更新測試干貨批钠。