面試測試總結

標籤：如何   nts   架構   add   加密   自動   info   ajax跨域   ios   

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 部落格 ，全文地址請點擊：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是超文字傳輸通訊協定 (HTTP)，資訊是明文傳輸，https則是具有安全性的ssl加密傳輸協議。

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

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

--------------------- 本文來自 xh15 的CSDN 部落格 ，全文地址請點擊：68569282?utm_source=copy 

 

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

　　GET：發送請求來獲得伺服器上的資源，請求體中不會包含請求資料，請求資料放在協議頭中。另外get支援快取、緩衝、可保留書籤等。等冪

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

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

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

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

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

　　OPTIONS：擷取http伺服器支援的http要求方法，允許用戶端查看伺服器的效能，比如ajax跨域時的預檢等。

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

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

　　

 

	GET	POST
點擊返回/重新整理按鈕	沒有影響	資料會重新提交
緩衝/添加書籤	可以	不可以
記錄	有	沒有
編碼類別型	application/x-www-form-urlencoded	application/x-www-form-urlencoded  或 multipart/form-data。為位元據使用 多重編碼
是否等冪	等冪	非等冪
長度限制	http協議沒有限制，但是實際瀏覽器或服務 器有(最大2048)	理論上沒有，可能會收到伺服器配置或記憶體限制
資料類型限制	只能ASCII，非ascii都要編碼傳輸	沒有限制，允許位元據
安全性	資料全部展示在url中，不安全	相比get，通過request body傳遞資料，比較安全
可見效	可見	不可見

 

注意：以上只是一種規範，如果非要給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比如用什麼樣的人來執行這樣的任務比較合適？要考慮這個現象是暫時還是常態，是否需要/可以最佳化？

面試測試總結