導讀#01在項目中如何保證軟件質量？?參考點1、考察對測試工作的理解2、考察求職者有沒有對測試工作有一些自己的思考和認識?面試命中率90%?參考答案項目質量不僅....

#01

在項目中如何保證軟件質量？

?

參考點

1、考察對測試工作的理解

2、考察求職者有沒有對測試工作有一些自己的思考和認識

?

面試命中率

90%

?

參考答案

項目質量不僅僅是某個人或某個團隊來保障的，而是整個團隊一起努力的結果，在公司級別需要有一個規范的項目流程

• 產品，保證迭代過程中的產品邏輯，對于可能的兼容，升級做出預判，并給出方案
• 設計，滿足產品表達的同時，保證設計的延續性
• 開發，產品細節的保證，技術方案選擇要嚴謹，考慮兼容，性能，開發完成后要充分自測，嚴格遵循開發規范操作
• 測試，驗證產品邏輯，站在用戶角度對交互設計進行系統驗證，盡可能多的使用技術手段保證測試質量

#02

如何制定測試計劃？

?

參考點

1、是否擁有測試計劃的制定經驗

2、是否具備合理安排測試的能力

3、是否具備文檔輸出的能力

?

面試命中率

95%

?

參考答案

測試計劃包括測試目標、測試范圍、測試環境的說明、測試類型的說明（功能，安全，性能，穩定性）、測試工具、模塊的劃分、測試負責人、測試執行輪次的時間安排、相關文檔在文檔管理庫中的位置、測試的風險 。

其中模塊劃分需要根據測試人員對于業務的熟悉程度及個人能力進行分配，工作量的估算需要根據以往測試時的經驗，結合本次需求的修改，可以大致估算出測試量

#03

功能測試用例一般包含哪些內容？

?

參考點

1、考察測試用例編寫包含的要素

2、考察測試用例要素的核心要素

?

面試命中率

99%

?

參考答案

• 要素一般包括：用例編號、用例優先級、測試目的、所屬模塊、前提條件、測試環境、輸入數據、測試步驟、預期結果、測試腳本等
• 核心要素：用例優先級、測試目的、預期結果

#04

發現一個bug，怎么定位是APP端還是服務端的問題？

?

參考點

1、考察對測試基礎的理解

2、考察實際工作中問題排查的能力

?

面試命中率

80%

?

參考答案

• 抓包分析通過對客戶端進行抓包，分析服務端返回的數據是否符合預期，如果服務端數據是正確的，那就是客戶端的問題
• 日志分析可以通過查看客戶端/服務端的日志，分析有沒有異常的日志信息，從而確定具體原因

#05

當開發人員說不是bug時，你如何應對？

?

參考點

溝通，人際關系

?

面試命中率

99%

?

參考答案

開發人員說不是bug，有2種情況：

• 一是需求沒有確定，所以這個時候可以找來產品經理進行確認，需不需要改動，商量確定好后再看要不要改。
• 二是這種情況不可能發生，所以不需要修改

這個時候可以先盡可能的說出是BUG的依據是什么？如果被用戶發現或出了問題，會有什么不良結果？程序員可能會給你很多理由，你可以對他的解釋進行反駁。如果還是不行，那可以給這個問題提出來,跟開發經理和測試經理進行確認,如果要修改就改,如果不要修改就不改。如果最終bug被確定不改，那么就要在測試報告里面記錄一下，以便以后查閱。

#06

APP測試和WEB測試有什么區別？

?

參考點

1、對各種測試類型的掌握程度

2、對測試理論知識的掌握程度

?

面試命中率

80%

?

參考答案

Web端測試和移動端測試類型基本相似，都需要進行功能測試、性能測試、安全性測試，他們主要區分web端一般都是b/s架構，基于瀏覽器的，app是c/s架構，是有客戶端的。

• 從系統架構來看的話：web測試只要更新了服務器端，客戶端就會同步更新；而如果是app端下修改了服務端，意味著客戶端用戶所有使用的核心版本都需要進行回歸測試一遍。
• 客戶端性能方面：Web端可能只會關注響應時間；App則還要關心流量、電量、cpu、等；
• 兼容方面：Web是基于瀏覽器的，所以更傾向于瀏覽器（IE、Chrome、firefox）和電腦硬件，電腦系統方向的兼容；App測試則必須依賴于手機或者pad，不僅要看分辨率、頻目尺寸、重要看設備系統。

#07

講一下你們的測試流程

?

參考點

關于軟件測試流程的理解

?

面試命中率

95%

?

參考答案

• 需求評審和分析
• 制定測試計劃
• 根據需求文檔編寫測試用例
• 測試用例評審
• 提測后執行冒煙測試
• 執行第一輪測試，找bug
• 執行回歸測試，驗證bug
• 執行第二輪測試
• 部署項目到預生產環境
• 預生產環境測試
• 發測試報告
• 項目上線
• 線上驗證和監控（主流程、主功能點的驗證）

#08

如何與開發溝通？

?

參考點

溝通技巧

?

面試命中率

85%

?

參考答案

1、就事論事，跟開發溝通時不要攜帶任何情緒，客觀真實的進行溝通

2、不要過渡依賴開發，遇到問題先自己嘗試分析下，有一個基本判斷后，再去找開發

3、描述問題要簡潔、清晰，比如現在在做什么事情，遇到了什么問題，需要開發提供什么幫助

4、測試要有自己的原則和立場，自己認為是正確的事情，要堅定立場和自我判斷，不能完全聽信開發

5、盡量集中式溝通問題，避免碎片化溝通，導致開發工作頻頻被中斷

6、提升自己的技術能力和認知，用更專業的語言和開發溝通

7、遇到非常難溝通的開發，有必要時，要及時向上反饋，尋求幫助

#09

如何把自動化在公司實施并推廣起來？

?

參考點

自動化測試實際經驗

?

面試命中率

95%

?

參考答案

分析面試題：想了解自動化測試的實施和落地，考察你的參與度還是項目的主導人，你是負責的是整個項目還是一個簡單的demo

• 工具的選型，舉例 selenium or appium，組織會議，準備好demo來執行，看下需求的匹配程度 以及項目的推薦程度
• 自動化測試框架的搭建 -- 項目組別擴展補充測試用例
• 將項目的自動化流程，已經框架固化成文檔，方便歸納整理
• 等自動化在項目組內有一定的成果，將框架推廣到其他項目組，提升公司內部口碑

#10

自動化測試用例如何編寫？

?

參考點

1、考察測試用例設計基本功2、考察對于用例設計的理解

?

面試命中率

95%

?

參考答案

分析面試題：不管是手工還是自動化，測試用例就是一組按部就班的指令，以驗證某些功能是否符合的需求。

我們可以從以下幾個角度來思考 -- 你如何設計自動化測試用例？

• 測試環境的準備 -- 測試代碼需要頻繁的執行，異常處理的能力比較差，需要單獨準備環境
• 測試數據準備 -- 數據選擇自動生成的方式
• 測試業務 -- 根據業務邏輯關系構建測試用例
• 檢查點/測試手段 -- 斷言
• 測試環境清理 -- 執行頻繁 產生垃圾數據，需要采用環境清理 定期清理數據庫

#11

什么是PO模式，為什么要使用它？

?

參考點

1、PO模式理論2、PO模式分層思路

?

面試命中率

99%

?

參考答案

頁面對象模型(PageObject)是一種設計模式，用來編寫和維護自動化測試

Po模式的優點：

• PO提供了一種業務流程與頁面元素操作分離的模式，這使得測試代碼變得更加清晰。
• 頁面對象與用例分離，使得我們更好的復用對象。
• 可復用的頁面方法代碼會變得更加優化
• 更加有效的命名方式使得我們更加清晰的知道方法所操作的UI元素

如何編寫PO模式

• 抽象每一個頁面
• 頁面中元素不暴露,僅報錯操作元素的方法
• 頁面不應該有繁瑣的繼承關系
• 頁面中不是所有元素都需要涉及到,核型業務元素做建模使用
• 把頁面劃分功能模塊,在Page中實現這些功能方法

#12

WEB自動化中有哪些場景需要特殊處理？

?

參考點

項目的測試思維

?

面試命中率

90%

?

參考答案

• iframe元素，當要操作的元素在iframe中是需要先將driver切換至該iframe才能操作，切換方式有四種，通過id、name、索引、iframe元素對象，并且在多iframe切換時還需要進行各種轉換
• 新窗口打開，當要操作的元素在一個新窗口打開的頁面上時，就需要先將driver切換至新窗口上才能進行操作
• 時間控件，通常時間控件只能選擇無法輸入，那么可以采用js的方式修改時間控件的只讀屬性然后再進行輸入，或者用js直接修改時間控件的value值
• 元素不在當前視野需要滾動才會出現，可以采用js的方式滾動，但是有時候界面中有多個滾動條js就會無效，則需要先將光標置入到滾動條區域然后模擬鍵盤的上下左右鍵來操作

#13

在上一家公司做自動化測試用的什么框架呢？

?

參考點

項目的測試思維

?

面試命中率

85%

?

參考答案

自動化方向：

主要分為ui自動化 和 接口自動化

• ui自動化分為兩個方向：web端和app端 web端框架的構成：Python slenium pytest allure 報告APP段框架構成：Python appium pytest allure報告
• 接口自動化：Python requests pytest allure報告

#14

你是怎么測試接口的？

?

參考點

是否具備接口測試實際經驗

是否熟悉接口測試的流程

是否熟悉接口測試的具體步驟

是否熟悉接口測試用例設計

?

面試命中率

90%

?

參考答案

先了解接口的業務功能、入參出參以及接口對應的數據存儲，再依據接口測試用例設計方法完成接口測試的設計，用例設計先業務場景再參數判斷；

比如參數的邊界值、格式、組合等等，最后依據測試用例使用接口測試工具完成接口測試，并在測試過程中查看日志及數據以確保接口測試結果的正確性

#15

怎么根據線下環境評估線上環境的性能？

?

參考點

項目的測試思維

?

面試命中率

85%

?

參考答案

• 首先線下必須要有專門的性能測試環境
• 線下環境單臺機器配置和線上不能相差很大，可以通過單臺的機器性能推算出多臺機器性能（需考慮一定的性能損耗）
• 如果線下機器配置很差，只能測試出程序有無性能問題，這樣線下測試出來的數據對線上沒有太大參考意義
• 如果想獲取比較準確的線上性能情況，建議最好做線上的性能測試

#16

BUG優先級和嚴重程度怎么劃分？

?

參考點

對于優先級和嚴重程度的理解

?

面試命中率

95%

?

參考答案

Priority(優先級)和Severity(嚴重程度)是提交bug的兩個重要屬性。

通常，測試人員在提交Bug時，只定義Bug的Severity, 即該Bug的嚴重程度，而將Priority交給Project Leader 或Team Leader來定義，由他們來決定該Bug被修復的優先等級。某種意義上來說，Priority的定義要依賴于Severity，在大多數情況下，Severity越嚴重，那這個Bug的Priority就越高。

Severity（嚴重程度）如下：

• Blocker（有妨礙的）: 即系統無法執行、崩潰或嚴重資源不足、應用模塊無法啟動或異常退出、無法測試、造成系統不穩定
• Critical（緊要的）：即影響系統功能或操作，主要功能存在嚴重缺陷，但不會影響到系統穩定性
• Major（嚴重的）：即界面、性能缺陷、兼容性。
• Minor/Trivial（次要的/不嚴重的）:即易用性及建議性問題。

Priority（優先級）：Immediate（立刻）、Urgent（緊要、優先）、High（高度重視）、

Normal（正常）、Low（稍緩）

#17

常見的性能指標有哪些，分別有什么含義？

?

參考點

項目的測試思維

?

面試命中率

95%

?

參考答案

• tps：每秒事務量，代表了系統的處理能力，tps越高，性能越好
• 響應時間：從發出請求到接受到系統響應數據所花費的時間，響應時間越短，性能越好
• 吞吐量：網絡上行和下行流量的總和，吞吐量是網絡瓶頸定位的重要指標
• 錯誤率：在壓測過程中系統出現錯誤的比例

#18

使用Jmeter如何做接口之間的關聯？

?

參考點

是否熟悉jmeter

是否熟悉關聯的業務場景

是否熟練關聯所用到的組件

?

面試命中率

85%

?

參考答案

接口關聯指的就是一個接口要使用另一個接口的返回值作為參數，在jmeter中針對不同的響應數據格式都有不同的處理組件，json格式的采用json提取器，xml或者html格式的采用xpath提取器，其他格式的可以采用正則表達式提取器，BeanShell后置處理器也可以從響應結果中提取響應內容，通過這些組件提取所需內容后，在需要關聯的接口中引用變量即可完成關聯

#19

同步和異步的區別？

?

參考點

考察對企業中接口通信機制的認識

考察同步通信和異步通信的原理

?

面試命中率

90%

?

參考答案

同步和異步是一種通訊方式

• 同步：執行一個操作時，需要等待其處理完成，然后再進行下一個操作
• 異步：執行一個操作時，不需要等待返回，就進行下一個操作，一般需要使用消息中間件

舉例：

• 下單接口中，需要調用庫存接口做庫存判斷，所以必須等待庫存接口返回數據才能進行下一步操作，這是同步；
• 下單接口中，下單成功后需要調用郵件通知接口，不用等待接口返回成功，就可以直接進行下一步操作，這是異步

#20

性能測試中，TPS比較低，可能是哪方面的原因？

?

參考點

考察在工作中是否做過性能測試

考察是否具備一定性能分析能力

考察對于性能分析是否具備清晰的思路

?

面試命中率

85%

?

參考答案

• 壓力機本身性能瓶頸
• 網絡IO瓶頸
• 中間件（tomcat/nginx/mysql）連接數限制
• Java線程的阻塞、等待
• 本系統資源的瓶頸（cpu、內存、磁盤、網絡等）
• 其他外部系統響應時間過長，造成本系統的time-wait

#21

性能測試過程中如何對瓶頸進行分析？

?

參考點

考察性能測試分析思路

考察性能瓶頸的理解

?

面試命中率

90%

?

參考答案

性能瓶頸分析參考準則：排除法，從上至下、從局部到整體！

針對不同的瓶頸采用不同的分析方法，一般分為：內存分析方法、處理器分析法、磁盤I/O分析方法、進程分析方法、網絡分析方法等等。

• 內存分析方法：內存分析用于判斷系統有無內存瓶頸，是否需要通過增加內存等手段提高系統性能表現。
• 處理器分析法：通過處理器性能計數器的值體現服務器整體處理器利用率，判斷是否存在處理器瓶頸。
• 磁盤I/O分析方法：通過磁盤I/O性能計數器的值體現服務器整體磁盤I/O使用情況，判斷是否存在處理器瓶頸。
• 進程分析方法：通過進程性能指標數據，判斷是否存在進程瓶頸。
• 網絡分析方法：通過網絡性能指標數據，判斷是否存在網絡瓶頸。