1、給你一個APP，你該如何進行測試？

　　（1）功能測試-----主要測試APP的流程和業務要求是否達標（手動和自動化結合測試）

　　（2）性能測試------關註APP的性能參數：CPU、FPS、內存、耗電量、流量，同時關註APP的安裝和啟動耗時

　　（3）接口測試------關註數據的傳送，數據的安全加密

　　（4）安全測試------APP內涉及到用戶的信息是否加密，XSS攻擊、sql註入來測試

　　（5）兼容測試------平臺/系統（ios、android）、不同機型、相同機型的不同系統版本、分辨率、版本之間的兼容等

2、Appium 的工作原理？

Appium啟動時會創建一個http：127.0.0.1:4723/wd/hub服務端（相當於一個中轉站），腳本會告訴服務器我要做什麽，服務端再去跟設備打交道，服務端完成了腳本交給他的任務之後

服務端和設備如何通訊？

服務端和設備默認使用4723端口進行通訊的，底層調用uiautomator工具，在測試的時候服務端會給設備扔一個jar包就是appiumbootstrap.jar，會啟動這個包，啟動之後會在手機上創建一個socket服務，暴露的就是4723的端口；相對於socket服務來說，appium服務端又是一個客戶端；

服務端的4723可以修改，設備上的不可以；服務端收到腳本傳遞過來的命令之後，通過電腦上的4723端口，想設備上的4723端口發送指令，appiumbootstrap.jar收到指令後回去完成點擊，滑動其他的操作，完成之後再通過服務給服務端一個相應。服務端收到之後再去相應腳本

--------------------- 本文來自 jffhy2017 的CSDN 博客 ，全文地址請點擊：https://blog.csdn.net/jffhy2017/article/details/69220719?utm_source=copy

Appium工作原理

2.1 Android

在Android端，appium基於WebDriver協議，利用Bootstrap.jar，最後通過調?用UiAutomator的命令，實現App的自動化測試。

UiAutomator測試框架是Android SDK自帶的App UI自動化測試Java庫。

另外由於UiAutomator對H5的支持有限，appium引入了chromedriver以及safaridriver等來實現基於H5的自動化。

appium 在android端工作流

1. client端也就是我們 test script是我們的webdriver測試腳本。

2. 中間是起的Appium的服務，Appium在服務端起了一個Server（4723端口），跟seleniumWebdriver測試框架類似， Appium?持標準的WebDriverJSONWireProtocol。在這裏提供它提供了一套REST的接口,Appium Server接收web driverclient標準rest請求，解析請求內容，調?用對應的框架響應操作。

3. appium server會把請求轉發給中間件Bootstrap.jar，它是用java寫的，安裝在手機上.Bootstrap監聽4724端口並接收appium的命令，最終通過調?用UiAutomator的命令來實現。

4. 最後Bootstrap將執行的結果返回給appium server。

5. appium server再將結果返回給 appium client。

2.2 ios

在IOS端，appium同樣使?WebDriver的一套協議。

與Android端測試框架不同的是，appium ios封裝了apple的Instruments框架，主要用了Instrument裏的UIAutomation（Apple的?自動化測試框架），然後在設備中註?入bootstrap.js進?行監聽。

appium 在ios端工作流

1. client端 依然是 test script是我們的webdriver測試腳本。

2. 中間是起的Appium的服務，Appium在服務端起了一個Server（4723端口），跟seleniumWebdriver測試框架類似， Appium?持標準的WebDriverJSONWireProtocol。在這裏提供它提供了一套REST的接口,Appium Server接收web driverclient標準rest請求，解析請求內容，調?用對應的框架響應操作。

3. appium server調用instruments.js 啟動?一個socketserver，同時分出一個?子進程運?instruments.app，將bootstrap.js（一個UIAutomation腳本）註?入到device?於和外界進行交互

4. 最後Bootstrap.js將執行的結果返回給appium server

5. appium server再將結果返回給 appium client。

所以我們可以看到android與ios區別在於appium將請求轉發到bootstrap.js或者bootstrap.jar.然後由bootstrap驅動UIAutomation和UiAutomator去devices上完成具體的動作。

3、接口測試用例的設計？

　　　1) 優先級--針對所有接口

　　　　1、暴露在外面的接口，因為通常該接口會給第三方調用；

　　　　2、供系統內部調用的核心功能接口；

　　　　3、供系統內部調用非核心功能接口；

　　　2) 優先級--針對單個接口

　　　　1、正向用例優先測試,逆向用例次之(通常情況，非絕對)；

　　　　2、是否滿足前提條件 > 是否攜帶默認參值參數 > 參數是否必填 > 參數之間是否存在關聯 > 參數數據類型限制 > 參數數據類型自身的數據範圍值限制

　 　 　3、無網絡，接口的響應時間和返回值

4、接口測試用例過多時，如何簡化用例？

　　（1）根據接口的使用對象(外部，系統內部)，有選擇的去、留部分用例

（2）根據接口的是否核心接口，有選擇的去、留部分用例

（3）根據參數說明，及實際情況，有選擇的去、留部分用例

5、接口測試的輸入值如何考慮設計？

　　（1）覆蓋所有的必選參數

　　（2）組合可選參數

　　（3）參數有、無或為null

　　（4）參數的順序、個數、類型

　　（5）參數類型的數值大小，輸入的數值的範圍

　　（6）參數字符串的長短

　　（7）參數包含特殊字符

6、接口測試質量評估標準：

　　a) 業務功能覆蓋是否完整

　　b) 業務規則覆蓋是否完整

　　c) 參數驗證是否達到要求（邊界、業務規則）

　　d) 接口異常場景覆蓋是否完整

　　e) 接口覆蓋率是否達到要求

　　f) 代碼覆蓋率是否達到要求

　　g) 性能指標是否滿足要求

　　h) 安全指標是否滿足要求

7、軟件測試用例設計

　　推薦一篇博客，學習鏈接：https://www.cnblogs.com/sunshine2016/category/840159.html

8、接口測試一遍，功能測試一遍，是不是測試重復了？

　　不會，可以設置2個測試的關註點不同，推薦一篇博客，學習鏈接：http://www.cnblogs.com/puresoul/p/5388586.html

9、http和https的區別？

1、https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。

2、http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議。

3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，後者是443。

4、http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。

--------------------- 本文來自 xh15 的CSDN 博客 ，全文地址請點擊：https://blog.csdn.net/xionghuixionghui/article/details/68569282?utm_source=copy

10、請求方式是否有所了解？分別說明

　　GET：發送請求來獲得服務器上的資源，請求體中不會包含請求數據，請求數據放在協議頭中。另外get支持快取、緩存、可保留書簽等。冪等

　　POST：和get一樣很常見，向服務器提交資源讓服務器處理，比如提交表單、上傳文件等，可能導致建立新的資源或者對原有資源的修改。提交的資源放在請求體中。不支持快取。非冪等

　　HEAD：本質和get一樣，但是響應中沒有呈現數據，而是http的頭信息，主要用來檢查資源或超鏈接的有效性或是否可以可達、檢查網頁是否被串改或更新，獲取頭信息等，特別適用在有限的速度和帶寬下。

　　PUT：和post類似，html表單不支持，發送資源與服務器，並存儲在服務器指定位置，要求客戶端事先知道該位置；比如post是在一個集合上（/province），而put是具體某一個資源上（/province/123）。所以put是安全的，無論請求多少次，都是在123上更改，而post可能請求幾次創建了幾次資源。冪等

　　DELETE：請求服務器刪除某資源。和put都具有破壞性，可能被防火墻攔截。如果是https協議，則無需擔心。冪等

　　CONNECT：HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。就是把服務器作為跳板，去訪問其他網頁然後把數據返回回來，連接成功後，就可以正常的get、post了。

　　OPTIONS：獲取http服務器支持的http請求方法，允許客戶端查看服務器的性能，比如ajax跨域時的預檢等。

　　TRACE：回顯服務器收到的請求，主要用於測試或診斷。一般禁用，防止被惡意攻擊或盜取信息。

11、get請求和post請求的區別？

註意：以上只是一種規範，如果非要給get加上request body，或者給post的url上帶上參數，技術上沒有任何問題。

12、如何確定性能測試的指標？標準如何定？如何推動性能的優化？

　　（1）基於現有的業務確定

　　（2）現有的行業標準

　　（3）個人之前的工作經驗等

　　性能的優化：

　　　　內存使用優化，程序架構優化，降低模塊間耦合，要不就是網絡性能優化咯

一、開發不認可你的bug怎麽辦？

1、可以先分析哪些類型的bug會出現這個情況，然後根據每種情況進行針對性說明，分別從bug本身、環境因素、人等方面回答，這樣可以體現自己的分析能力和處事方式

2、開發不認同的bug一般是：數據問題導致的bug、環境問題導致（偶發）、優化體驗類的bug

3、如果是應聘鋼，也可以回答說出這個情況的“人”的原因，比如一種可能是測試人員和開發人員之間有矛盾等導致

4、工作中遇到這個情況後，不要輕易認同開發給的籠統模糊的觀點，多緯度驗證（排查法），明確bug出現的條件，定位bug的真正原因，測試實際上就是提供信息，比如app出現閃退的問題，我們就同一手機上驗證不同的版本，或者不同手機驗證同一個版本，或同一款手機，不同的操作系統版本上，驗證同一個app版本。

二、給的測試時間特別短，怎麽安排寫用例和執行測試的時間？

　　考察做事時是否靈活，是否會註意區分輕重緩急，以及解決問題的能力，（面試官往往通過應聘者表現出來的分析能力，歸納總結能力來判斷其解決問題的能力），回答時可以根據具體的情況具體分析，然後結合具體的實例：

思考範圍：

是否為新需求/舊某塊的變更優化、此次變更影響的模塊範圍、此次任務的優先級、此次變更的總開發周期、當前的測試人員數量、當前的測試人員其他任務的排期、項目經理是否存在對此次變更的排期不合理、根據實際情況考慮後，與項目經理等人溝通排期時間，

說白了就是質量和時間的問題，這個時間我可以完成，但不保證質量，質量保證的情況下一定的時間是不可以被忽略的，魚和熊掌不能兼得

　　1、是否需要寫很多的用例？或者是否需要做大量的測試分析？這是不一定的，比如bug修復對應的回歸時間都是不能明確給出時間的。

　　2、用例是否可以從用例庫中篩選？

　　3、是需求，沒有用例的情況下，考慮用xmind

　　4、加班可以追趕進度的話，適當的加班追趕（但這不是長久之計）

　　5、管理層對項目質量的態度（這個基本上都是不用 說的）

　　6、如果是面試管理崗，需要考慮到：i比如用什麽樣的人來執行這樣的任務比較合適？要考慮這個現象是暫時還是常態，是否需要/可以優化？

面試測試總結