1.Web 測試和App測試的相同點和區(qū)別

相同點

（1）設(shè)計測試用例時依然是根據(jù)邊界值、有效等價類和無效等價類、場景法、因果圖法、錯誤推測法來設(shè)計用例。

（2）多數(shù)依然是采用黑盒測試方法來驗證業(yè)務(wù)功能是否得到正確的應(yīng)用。

（3）測試方向依然是：ui界面布局是否合理，風(fēng)格按鈕是否簡潔美觀、功能測試、穩(wěn)定性測試、頁面載入和翻頁的速度，登錄時長，內(nèi)存是否溢出、安全測試、性能測試。

不同點

（1）手機(jī)作為通信工具，來電、去電、接收短信等操作都會對app應(yīng)用程序產(chǎn)生影響，所以app測試第一個要考慮的屬性特征是：中斷測試。

中斷測試有人為中斷、新任務(wù)中斷以及意外中斷等幾種情況，主要從以下幾個方面進(jìn)行驗證：

來電中斷：呼叫掛斷、被呼叫掛斷、通話掛斷、通話被掛斷

短信中斷：接收短信、查看短信

其他中斷：藍(lán)牙、鬧鐘、插拔數(shù)據(jù)線、手機(jī)鎖定、手機(jī)斷電、手機(jī)問題（系統(tǒng)死機(jī)、重啟）

（2）手機(jī)用戶對app產(chǎn)品的安裝卸載操作：從上一個版本/上兩個版本直接升級到最新版本。

全新安裝新版本

新版本覆蓋舊版本安裝

卸載舊版本，安裝新版本

卸載新版本，安裝新版本

（3）兼容性的區(qū)別

web測試主要考慮瀏覽器內(nèi)核以及瀏覽器版本的兼容，操作系統(tǒng)的兼容性，分辨率的兼容。

APP兼容性主要考慮不同廠家的不同手機(jī)型號、系統(tǒng)版本、屏幕分辨率、屏幕大小、內(nèi)存大小。

4)APP橫豎屏測試，不同方向屏幕顯示以及操作。

5)APP測試還需要考慮網(wǎng)絡(luò)2G3G4G5G ?WIFI ? 弱網(wǎng)環(huán)境。

2.如何測定一個app的登陸場景

1、頁面基本元素的操作。

2、大量字符，特殊字符，邊界值，必填項校驗。

3、注冊手機(jī)號的特殊性驗證，注冊郵箱的格式驗證。

4、密碼大小寫是否敏感，密碼是否加密展示，密碼是否有可見按鈕功能，密碼框能否使用復(fù)制粘貼。

5、驗證碼校驗：必填項，過期，錯誤，無網(wǎng)絡(luò)時獲取驗證碼，多次獲取，超過獲取次數(shù)，輸入驗證碼后，修改手機(jī)號。

6、登陸時與系統(tǒng)的交互：鎖屏，藍(lán)牙，home，后退，橫豎屏，修改字體字號。

7、逆向思維：已注冊賬號注冊，未注冊賬號忘記密碼，未注冊賬號登陸，注冊過程中退出再次注冊。

8、輸入法交互，切換輸入法，切換輸入輸入模式，手寫/九宮格。

9、登陸賬號的多樣性：多個賬號輪流登陸，同一個賬號多角色登陸。

10、第三方登錄驗證：賬號授權(quán)，信息正確，取消授權(quán)。

11、登陸頁面跳轉(zhuǎn)，返回，登陸成功及其他頁面跳轉(zhuǎn)。

12、手機(jī)兼容性測試：分辨率兼容，系統(tǒng)兼容，系統(tǒng)版本兼容，App版本兼容。

13、網(wǎng)絡(luò)切換，網(wǎng)絡(luò)斷開，弱網(wǎng)

3.push推送消息如何測試

消息推送對象

消息推送一般可以自定義推送對象，有全部推送，精確推送，及安卓和IOS渠道推送，注意推送對象是否正確，推送之前確認(rèn)自己是否在測試環(huán)境操作，以免造成生產(chǎn)問題。

消息簡介

客戶端收到消息推送有兩種形式，客戶端后臺運行一般推送顯示在通知欄，客戶端前臺運行一般彈出彈框，簡介內(nèi)容注意字?jǐn)?shù)過多溢出情況。

消息詳情

注意詳情所支持的內(nèi)容，包括文字、圖片、表情包、換行以及鏈接跳轉(zhuǎn)。

消息推送場景（支持定時推送）

（1）消息推送時間：

a)設(shè)置過去時間

b)未推送之前修改消息內(nèi)容

c)刪除消息，查看是否還會推送

（2）客戶端運行狀態(tài)

a)前臺運行

b)后臺運行

c)進(jìn)程關(guān)閉狀態(tài)

（2）特殊場景

a)多個提醒沖突

b)當(dāng)天設(shè)置當(dāng)天推送

c)當(dāng)天設(shè)置隔幾天起效

4.app閃退是由那些原因造成的

帶寬限制：帶寬不佳的網(wǎng)絡(luò)對App所需的快速響應(yīng)時間可能不夠。

網(wǎng)絡(luò)的變化：不同網(wǎng)絡(luò)間的切換可能會影響App的穩(wěn)定性。

內(nèi)存管理：可用內(nèi)存過低，或非授權(quán)的內(nèi)存位置的使用可能會導(dǎo)致App失敗。

用戶過多：連接數(shù)量過多可能會導(dǎo)致App崩潰。

代碼錯誤：沒有經(jīng)過測試的新功能，可能會導(dǎo)致App在生產(chǎn)環(huán)境中失敗。

第三方服務(wù)：廣告或彈出屏幕可能會導(dǎo)致App崩潰。

6.如何查看移動端日志以及出現(xiàn)哪些異常

7.app測試如何展開主要測試哪些

1. 功能

? 首先設(shè)計的功能必須是10Z0%的測試，而且是最基本的測試。

? 2. 安裝卸載

? App可以正常安裝啟動，各大應(yīng)用市場下載安裝，升級安裝，跨版本升級安裝，手機(jī)存儲滿時安裝。安裝時的權(quán)限也是很重要的。

? App的卸載應(yīng)該很容易，直接系統(tǒng)自帶卸載。

? 3. 流暢度

? App的流暢度最能考驗一款軟件的易用性。如果一個軟件打開就卡，隨便滑動幾下頁面就卡死，誰還會用第二次？

? 4. 兼容性

? 對于兼容性，因為公司不可能給你所有市場上的安卓機(jī)，所以盡量在自己有的機(jī)子上測試通過的條件下，去各大網(wǎng)站遠(yuǎn)程真機(jī)測試，有很多都是免費的。

? 對于iOS，可以在電腦上模擬真機(jī)測試跑跑smoke。

? 5. 網(wǎng)絡(luò)

? 弱網(wǎng)，2g，2.5g，3g，4g，wifi情況下的使用。網(wǎng)絡(luò)切換時的使用，模擬地鐵，停車場等的測試都是很有必要的。

? 6. 流量消耗

? 偷偷盜用流量的手機(jī)app，只要發(fā)現(xiàn)我就會刪除，所以流量消耗的測試一定要多測試。主要看看斷開wifi情況下會不會偷跑流量。

? 7. 低配手機(jī)

? 低配手機(jī)一般都指安卓4.4.0以下版本的手機(jī)，運行內(nèi)存不大，很容易卡住?？梢钥纯吹团涫謾C(jī)下是否能正常運行app，該顯示的都能正常顯示。

8.App、的性能測試關(guān)注點有哪些

1.響應(yīng)

2.內(nèi)存

3.cpu

4.FPS（app使用的流暢度）

5.GPU多度

6.耗電

7.耗流

9.如何對App進(jìn)行弱網(wǎng)測試

fiddler 模擬網(wǎng)絡(luò)延遲

1、使用真實的SIM卡、運營商網(wǎng)絡(luò)來進(jìn)行測試(移動無線測試中存在一些特別的BU6必須在特定的真實的運營商網(wǎng)絡(luò)下才會發(fā)現(xiàn))

2、通過代理的方式模擬弱網(wǎng)環(huán)境進(jìn)行測試(charles硬延遲)在fiddler和 charles中可以設(shè)置網(wǎng)絡(luò)，fiddler可以在rule中調(diào)，charles可以在proxy中延遲設(shè)置中設(shè)置網(wǎng)染速度。

3、連接模擬弱網(wǎng)的熱點進(jìn)行測試 比如360wifi助手可以設(shè)置

10.常見的ADB命令 monkey命令

1、adb devices：查看已連接的設(shè)備

? 2、adb version：查看adb的版本序列號

? 3、adb -s <設(shè)備名字>：指定某設(shè)備做什么（設(shè)備名字用1的方法可以查看）

? 4、adb install <安裝包.apk>：安裝應(yīng)用（寫清楚apk的完整路徑）adb -s <設(shè)備名字> install <安裝包.apk>：指定設(shè)備安裝應(yīng)用

? 5、adb shell：通過遠(yuǎn)程shell命令來控制模擬器/設(shè)備

? 6、exit：退出shell遠(yuǎn)程連接，回到原路徑。（Ctrl+d，退出shell，回到默認(rèn)路徑）

? 7、adb pull <設(shè)備端路徑> <pc端路徑>：將指定的文件從設(shè)備/模擬器上拷貝到pc端（后面的pc端路徑可以不指定，默認(rèn)存儲在當(dāng)前路徑下）。

? 例： adb pull /sdcard/log.txt c:/monkey

? 8、adb push <pc端路徑> <設(shè)備端路徑>：將指定的文件從pc端拷貝到設(shè)備/模擬器上

? 9、adb shell pm list packages：列出電腦端所有apk的包名

? 10、adb logcat：查看pc端的日志輸出。adb shell界面只需輸入logcat，查看設(shè)備端日志輸出（退出Ctrl+c）

? Monkey命令擴(kuò)展

? 1、最簡單的monkey執(zhí)行語句：（adb shell）monkey –p com.jianjiexuan.na –v 500 (對com.jianjiexuan.na 這個程序包單獨進(jìn)行一次500次的monkey測試)

? ? ? 名詞解釋：-p：用于約束限制，用此參數(shù)指定一個或多個包。指定包之后，Monkey將只允許系統(tǒng)啟動指定的APP。

? 如果不指定包，Monkey將允許系統(tǒng)啟動設(shè)備中的所有APP。指定多個包：monkey -p –p -p -v 500-v：用于指定反饋信息級別（信息級別就是日志的詳細(xì)程度），總共分3個級別，分別對應(yīng)的參數(shù)如下表所示：

? ? ? 日志級別 Level 0

? ? ? 例 monkey –p com.jianjiexuan.na –v 500說明：缺省值，僅提供啟動提示、測試完成和最終結(jié)果等少量信息

? ? ? 日志級別 Level 1

? ? ? 例 monkey –p com.jianjiexuan.na –v -v 500說明：提供較為詳細(xì)的日志，包括每個發(fā)送到Activity的事件信息

? ? ? 日志級別 Level 2

? ? ? 例 monkey –p com.jianjiexuan.na –v -v -v 500

? ? ? 說明：最詳細(xì)的日志，包括了測試中選中/未選中的Activity信息

? 2、延時及固定序列（adb shell）monkey -s 100 -p com.jianjiexuan.na – -throttle 1000 -v 500 （每次執(zhí)行一次有效的事件后休眠1000毫秒）

? ? （adb shell）monkey -p com.jianjiexuan.na – -throttle 1000 – -randomize-throttle -v 500 （每次執(zhí)行一次有效事件后隨機(jī)延時0-200毫秒）

名詞解釋：-s：用于指定偽隨機(jī)數(shù)生成器的seed值，如果seed相同，則兩次Monkey測試所產(chǎn)生的事件序列也相同的。

出現(xiàn)問題下次可以重復(fù)同樣的系列進(jìn)行排錯。–throttle：固定延時，用于指定用戶操作（即事件）間的時延，單位是毫秒；

? –randomize-throttle：隨機(jī)延時，用于指定用戶操作（即事件）間的時延，單位是毫秒。

? 3、保存monkey運行結(jié)果1）保存在PC中adb shell monkey –p com.jianjiexuan.na –v 500 > d:\monkey\log.txt 2)保存在手機(jī)中手機(jī)端進(jìn)入shell模式：

? ? ? adb shell monkey –p com.jianjiexuan.na –v 500 > /mnt/sdcard/monkey/log.txt

? 4、monkey事件百分比的調(diào)整（adb shell）monkey -p com.jianjiexuan.na -v – -pct-anyevent 100 500指定多個類型事件的百分比：

? ? ? monkey -p com.jianjiexuan.na -v –pct-anyevent 50 –pct-appswitch 20 500

? ? ? 名詞解釋：–pct-****：

? ? ? monkeygai01.png

? ? ? 設(shè)置某個事件的百分比。后面接數(shù)字（0-100），100即100%的概率執(zhí)行該事件注意：各事件類型的百分比總數(shù)不能超過100%。

? 如果不進(jìn)行設(shè)置則顯示默認(rèn)百分比。

? 5、正在運行的monkey如何終止如在命令窗口端直接打印結(jié)果，想要停止monkey的運行，那么就再打開一個cmd命令窗口查看monkey的進(jìn)程：

? ? ? adb shell ps | find “monkey”kill掉該進(jìn)程就可以adb shell kill + 進(jìn)程編號 ，

11.Ios和android測試的側(cè)重點是？

1、Android多分辨率測試，20多種，IOS較少。

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

3、Android操作習(xí)慣，Back鍵是否被重寫，應(yīng)用數(shù)據(jù)從內(nèi)存移動到SD卡能否正常運行。

4、安裝卸載測試：Android的下載和安裝平臺較多，IOS主要是AppStore，iTunes，TestFlight。

5、Push測試：Android點擊home鍵，程序后臺運行，此時點擊Push消息，喚醒后臺應(yīng)用；iOS點擊home鍵關(guān)閉程序和屏幕鎖屏的情況。

6、單條item的操作：Android中分為點擊和長按，點擊一般進(jìn)入一個新的頁面，長按進(jìn)入編輯模式。IOS中分為點擊和滑動，點擊一般進(jìn)入一個新的頁面，滑動會出現(xiàn)對item的常用操作。

7、懸浮窗：Android中可以有各種懸浮窗，IOS并不支持。

12.常見的接口協(xié)議/類型

1.HTTP類型/協(xié)議：

通過GET或POST來獲取數(shù)據(jù)，在數(shù)據(jù)處理上效率比較高 == 概念

2.Webservice 類型/協(xié)議：

通過soap協(xié)議來獲取數(shù)據(jù),比起 http 來說能處理更加復(fù)雜的數(shù)據(jù)類型。本質(zhì)上也是 http 協(xié)議。

13.常見的接口請求方式是什么？

post 、get? 、 put、delete、 options、patch、 copy、? head

14.接口測試的原理是什么?

接口測試包括內(nèi)部接口測試和外部接口測試。服務(wù)器接口測試這種接口是后端開發(fā)與前端/移動端頁面進(jìn)行數(shù)據(jù)交互的。在還沒有前端界面的時候，進(jìn)行接口測試，會提前發(fā)現(xiàn)一些bug。

原理：模擬客戶端向服務(wù)器發(fā)送請求報文，服務(wù)器接收請求報文后對相應(yīng)的報文做處理并向客戶端返回應(yīng)答，客戶端接收應(yīng)答的一個過程。

15.后臺接口測試了一遍前端也測試一遍是不是重復(fù)測試?

從后端角度出發(fā)：后端測試自己開發(fā)的接口，更多在于單測層面，好的開發(fā)會從接口業(yè)務(wù)調(diào)用場景出發(fā)，覆蓋一些功能case，但是開發(fā)測試自己的代碼，他往往覺得自己的代碼已經(jīng)很完美了，所以開發(fā)測試自己的代碼往往是覆蓋不全面的。

從前端角度出發(fā)：前端開發(fā)要和后端聯(lián)調(diào)，所以前端的關(guān)注點是你接口返回給我的數(shù)據(jù)結(jié)構(gòu)是不是嚴(yán)格按照技術(shù)方案上契約來設(shè)計的，你讓我傳給接口的參數(shù)是不是按照契約約定的，，所以前端開發(fā)不太關(guān)注接口邏輯對不對，只關(guān)心我只要入?yún)⒔o的對，返回的數(shù)據(jù)結(jié)構(gòu)對就行了。

從測試角度出發(fā)：測試是保證質(zhì)量最重要的一環(huán)，接口測試我們不僅僅只考慮功能層面用例，還要從非功能層面出發(fā)，比如接口性能，穩(wěn)定性，安全性。我們還要結(jié)合業(yè)務(wù)場景，去思考一些反向的異常case，和其他服務(wù)相互調(diào)用過程的異常場景怎么兜底，依賴服務(wù)響應(yīng)超時怎么兜底，系統(tǒng)異常怎么兜底等。

綜上，因為前后端對同一個接口的關(guān)注點是不同的，所以不能說是重復(fù)測試。保證質(zhì)量，更多依賴測試人員。三者相互協(xié)調(diào)能得到質(zhì)量最優(yōu)解。

16.接口測試的流程/步驟(你的接口測試怎么做的)？

實際上我們做接口測試，還是“輸入—處理—輸出”這樣的模式。用戶輸入一串?dāng)?shù)據(jù)，然后讓這個接口或者讓這個后臺功能來處理，然后檢查輸出結(jié)果跟期望是否一致。

這個其實也就是我們所說的黑盒測試。也是我們做測試的一個常規(guī)的思路。用戶輸入一串?dāng)?shù)據(jù)，然后讓系統(tǒng)去處理，然后我們再去檢查結(jié)果跟期望是否一致。功能測試是這么做的，接口測試實際上還是這么做。

但是相對功能測試而言，接口測試有一個比較明顯的區(qū)別，就是輸入不再是界面的，而是一個基于HTTP的請求；輸出也不再是界面，而是基于HTTP的響應(yīng)。所以需要通過請求和響應(yīng)分別來輸入我們的數(shù)據(jù)以及檢查我們的結(jié)果。

第一步，設(shè)計操作步驟。

操作步驟就是請求，有一些請求是是單獨的，有些請求是多個請求前后有聯(lián)系的，這種情況就需要創(chuàng)建關(guān)聯(lián)，。那么我們需要了解請求的格式，規(guī)范以及如何做關(guān)聯(lián)。soapUI，postman，jmeter里，都有關(guān)聯(lián)。

第二步，設(shè)計數(shù)據(jù)用例。

建議將數(shù)據(jù)用例寫到Excel文檔里，然后讓工具讀取Excel。Excel里有幾組數(shù)據(jù)用例，就執(zhí)行幾次。循環(huán)執(zhí)行（自動化），就可以讓每一個用例被執(zhí)行一次，那么每一個測試場景也就被運行到了。

第三步：斷言。

也就是提前將預(yù)期結(jié)果寫入到工具中，讓工具自動化判斷結(jié)果是否正確。不同的工具叫法不同，soapUI和Jmeter中叫做斷言，postman中叫做tests。

第四步：執(zhí)行并檢查測試結(jié)果。

執(zhí)行很簡單，對測試結(jié)果進(jìn)行分析的話就需要了解協(xié)議。知道發(fā)出去了什么，返回了什么，才能夠知道，到底哪個環(huán)節(jié)出了問題。

對應(yīng)上面的四個步驟，如何用jmeter做接口測試？

1、 設(shè)計操作步驟：這里我們創(chuàng)建HTTP請求即可

添加——取樣器——HTTP請求

2、 設(shè)計數(shù)據(jù)用例：由于jmeter只支持CSV文件，所以設(shè)計測試用例時記得生成CSV格式的，將CSV導(dǎo)入到j(luò)meter中（這部分在性能測試?yán)锩娼凶鰆meter的參數(shù)化）

添加——配置元件——CSV數(shù)據(jù)文件設(shè)置

3、 斷言，添加一個響應(yīng)斷言即可（也可以加別的）

添加——斷言——響應(yīng)斷言

4、 執(zhí)行，添加一個結(jié)果樹

添加——監(jiān)聽器——查看結(jié)果樹

17.get/post 的區(qū)別？

觀點：本質(zhì)上沒有區(qū)別

GET和POST是什么？HTTP協(xié)議中的兩種發(fā)送請求的方法。

HTTP是什么？HTTP是基于TCP/IP的關(guān)于數(shù)據(jù)如何在萬維網(wǎng)中如何通信的協(xié)議。

HTTP的底層是TCP/IP。所以GET和POST的底層也是TCP/IP，也就是說，GET/POST都是TCP鏈接。GET和POST能做的事情是一樣一樣的。你要給GET加上request body，給POST帶上url參數(shù)，技術(shù)上是完全行的通的，HTTP只是個行為準(zhǔn)則，而TCP才是GET和POST怎么實現(xiàn)的基本。

那往常get/post大大小小的限制是怎么來的呢？

互聯(lián)網(wǎng)上，有著不同的瀏覽器（發(fā)起http請求）和服務(wù)器（接受http請求）， 雖然理論上，你可以在url中無限加參數(shù)。但是瀏覽器不能接受，加減數(shù)據(jù)也有著很大的成本，他們會限制單次運輸量來控制風(fēng)險，數(shù)據(jù)量太大對瀏覽器和服務(wù)器都是很大負(fù)擔(dān)，（大多數(shù)）瀏覽器通常都會限制url長度在2K個字節(jié)，而（大多數(shù)）服務(wù)器最多處理64K大小的url。超過的部分，恕不處理。如果你用GET服務(wù)，在request body偷偷藏了數(shù)據(jù)，不同服務(wù)器的處理方式也是不同的，有些服務(wù)器會幫你處理，讀出數(shù)據(jù)，有些服務(wù)器直接忽略，所以，雖然GET可以帶request body，也不能保證一定能被接收到哦。

GET和POST本質(zhì)上就是TCP鏈接，并無差別。但是由于HTTP的規(guī)定和瀏覽器/服務(wù)器的限制，導(dǎo)致他們在應(yīng)用過程中體現(xiàn)出一些不同。?

GET和POST還有一個重大區(qū)別，簡單的說：

GET產(chǎn)生一個TCP數(shù)據(jù)包；POST產(chǎn)生兩個TCP數(shù)據(jù)包。

長的說：

對于GET方式的請求，瀏覽器會把http header和data一并發(fā)送出去，服務(wù)器響應(yīng)200（返回數(shù)據(jù)）；

而對于POST，瀏覽器先發(fā)送header，服務(wù)器響應(yīng)100 continue，瀏覽器再發(fā)送data，服務(wù)器響應(yīng)200 ok（返回數(shù)據(jù)）。

也就是說，GET只需要汽車跑一趟就把貨送到了，而POST得跑兩趟，第一趟，先去和服務(wù)器打個招呼“嗨，我等下要送一批貨來，你們打開門迎接我”，然后再回頭把貨送過去。

因為POST需要兩步，時間上消耗的要多一點，看起來GET比POST更有效。因此Yahoo團(tuán)隊有推薦用GET替換POST來優(yōu)化網(wǎng)站性能。但這是一個坑！跳入需謹(jǐn)慎。為什么？

1. GET與POST都有自己的語義，不能隨便混用。

2. 在網(wǎng)絡(luò)環(huán)境好的情況下，發(fā)一次包的時間和發(fā)兩次包的時間差別基本可以無視。而在網(wǎng)絡(luò)環(huán)境差的情況下，兩次包的TCP在驗證數(shù)據(jù)包完整性上，有非常大的優(yōu)點。

3. 并不是所有瀏覽器都會在POST中發(fā)送兩次包，F(xiàn)irefox就只發(fā)送一次。

18.如何編寫接口測試用例？

接口測試，首先需要開發(fā)提供接口文檔。最重要的有一下幾點：

被測接口的地址

接口參數(shù)，以及各個參數(shù)的說明

必要的http頭與http體 ( http頭是可以自定義的，可以用來校驗是否是自己人訪問 )

接口返回什么值，以及各個返回值的說明

接口是干什么的、

接口測試用例

功能測試：測試這個接口的功能是否實現(xiàn)，并且測試這個接口是否按照接口文檔來進(jìn)行開發(fā)的（比如說接口文檔規(guī)定了一些關(guān)鍵字，而開發(fā)的時候把關(guān)鍵字改成了其他的關(guān)鍵字，因為在整個項目周期，并不只有一個開發(fā)而是有多個，所以可能因為在開發(fā)過程中因為關(guān)鍵字不一樣導(dǎo)致某些開發(fā)的功能異常，還有自動化腳本也會發(fā)生異常）

邏輯業(yè)務(wù)，主要指的是一些邏輯業(yè)務(wù)依賴關(guān)系（比如支付寶提交訂單的時候要保證你是在登錄的情況下，如果你沒有登錄而提交成功了，這就是異常，可以修改請求的cookie來測試）

異常測試：參數(shù)異常：關(guān)鍵字參數(shù)（應(yīng)用其他的關(guān)鍵字替換進(jìn)行測試）、參數(shù)為空、參數(shù)多少（通過添加參數(shù)增添個數(shù)），參數(shù)錯誤。數(shù)據(jù)異常：關(guān)鍵字?jǐn)?shù)據(jù)（填入的數(shù)據(jù)用其他的數(shù)據(jù)語言的數(shù)據(jù)替用）、數(shù)據(jù)長度、數(shù)據(jù)為空、數(shù)據(jù)錯誤。

19.性能測試都包含了哪些？（負(fù)載測試壓力測試容量測試）

性能測試：主要是在壓力測試下收集系統(tǒng)的各項性能指標(biāo)，與預(yù)期的指標(biāo)進(jìn)行對比，如關(guān)注并發(fā)用戶數(shù)，cpu、內(nèi)存，響應(yīng)時間；

負(fù)載測試：性能測試的一種，對系統(tǒng)不斷增加壓力，或增加一定壓力下的持續(xù)時間，知道系統(tǒng)的性能指標(biāo)達(dá)到極限，如響應(yīng)時間超過預(yù)定指標(biāo)，強(qiáng)調(diào)壓力持續(xù)時間。

強(qiáng)度或壓力測試：通過增加系統(tǒng)負(fù)載，確定系統(tǒng)在什么條件下失效，來獲得系統(tǒng)性能下降拐點，側(cè)重壓力大小。

容量測試：是系統(tǒng)承受超額的數(shù)據(jù)容量，測試系統(tǒng)是否能夠正常處理，通常和數(shù)據(jù)庫有關(guān)。

20.? 什么時候執(zhí)行性能測試？

在系統(tǒng)第一輪冒煙測試后就應(yīng)該介入性能測試，不管功能實現(xiàn)中有多少bug都不影響性能測試的初步階段，我們可以先進(jìn)行簡單的性能測試。盡量排除功能缺陷的干擾，盡早發(fā)現(xiàn)性能上的瓶頸。即時修改方案

21.請解釋下? 常用的性能測試指標(biāo)的含義?

壓力測試：強(qiáng)調(diào)極端暴力?

穩(wěn)定性測試：在一定壓力下，長時間運行的情況?

基準(zhǔn)測試：在特定條件下的性能測試?

負(fù)載測試：不同負(fù)載下的表現(xiàn)?

容量測試：最優(yōu)容量

22.響應(yīng)時間?? 并發(fā)用戶數(shù)????? 吞吐量? 性能計數(shù)器? TPS? HPS??QPS?

并發(fā)數(shù)

并發(fā)數(shù)是指系統(tǒng)同時能處理的請求數(shù)量，這個也是反應(yīng)了系統(tǒng)的負(fù)載能力。

響應(yīng)時間

響應(yīng)時間是一個系統(tǒng)最重要的指標(biāo)之一，它的數(shù)值大小直接反應(yīng)了系統(tǒng)的快慢。響應(yīng)時間是指執(zhí)行一個請求從開始到最后收到響應(yīng)數(shù)據(jù)所花費的總體時間。

吞吐量

吞吐量是指單位時間內(nèi)系統(tǒng)能處理的請求數(shù)量，體現(xiàn)系統(tǒng)處理請求的能力，這是目前最常用的性能測試指標(biāo)。

QPS（每秒查詢數(shù)）、TPS（每秒事務(wù)數(shù)）是吞吐量的常用量化指標(biāo)，另外還有HPS（每秒HTTP請求數(shù)）。

跟吞吐量有關(guān)的幾個重要是：并發(fā)數(shù)、響應(yīng)時間。

QPS（TPS），并發(fā)數(shù)、響應(yīng)時間它們?nèi)咧g的關(guān)系是：

QPS（TPS）= 并發(fā)數(shù)/平均響應(yīng)時間

性能計數(shù)器

性能計數(shù)器是描述服務(wù)器或操作系統(tǒng)性能的一些數(shù)據(jù)指標(biāo)，如使用內(nèi)存數(shù)、進(jìn)程時間，在性能測試中發(fā)揮著“監(jiān)控和分析”的作用，尤其是在分析統(tǒng)統(tǒng)可擴(kuò)展性、進(jìn)行新能瓶頸定位時有著非常關(guān)鍵的作用。

Linux中可以使用top或者uptime命令看到當(dāng)前系統(tǒng)的負(fù)載及資源利用率情況。?

23.如何判斷一個bug是前端bug還是后臺bug?

前端是用戶看得見摸得著的東西，主要體現(xiàn)在頁面的視覺效果以及交互設(shè)計上。比如說一個網(wǎng)站的頁面風(fēng)格、頁面跳轉(zhuǎn)等，最簡單的例子就是一個注冊界面：前端設(shè)計界面風(fēng)格，約束輸入的字符類型、長度以及合法性校驗等，不涉及到與數(shù)據(jù)庫之間的信息交流。

后臺則側(cè)重于更深層面的東西，關(guān)于邏輯，關(guān)于數(shù)據(jù)，關(guān)于平臺的穩(wěn)定性與性能。后臺主要負(fù)責(zé)實現(xiàn)具體的功能，舉個例子，還是那個注冊界面，前端寫好了界面，規(guī)定了你能輸入哪些數(shù)據(jù)，不能輸入哪些數(shù)據(jù)，而后臺則會把你輸入的信息與數(shù)據(jù)庫進(jìn)行比對，如果是新用戶，則順勢在數(shù)據(jù)庫中插入一條信息。

24.Python 數(shù)據(jù)類型有哪些？

1）int(整型)

? ? ? ? 所有整數(shù)對應(yīng)的數(shù)據(jù)類型。在python2.x還有l(wèi)ong

2）float(浮點型)

? ? ? ?所有的小數(shù)對應(yīng)的類型都是浮點型。（浮點型支持科學(xué)計數(shù)法）

3）str(字符串)

? ? ? 所有的文本數(shù)據(jù)對應(yīng)的數(shù)據(jù)類型。

4）bool(布爾)

? ? ? True 和 False 對應(yīng)的數(shù)據(jù)類型。

5）其他數(shù)據(jù)類型

? ? ?比如：list(列表)，tuple(元組)，dict(字典)，迭代器，生成器，函數(shù)自定義類型。

25.給你一個網(wǎng)站，你如何測試?給你一個app程序你要怎么做？

(1) 功能測試

每項開發(fā)的新功能都需要進(jìn)行測試。app測試中功能測試是一個重要方面。測試人員應(yīng)該要進(jìn)行手動測試和后期的自動化測試維護(hù)。剛開始測試時，測試員必須把a(bǔ)pp當(dāng)做"黑盒"一樣進(jìn)行手動測試，看看提供的功能是否正確并如設(shè)計的一樣正常運作。除了經(jīng)典軟件測試，像點擊按鈕、提交訂單看看會發(fā)生什么，測試員還必須執(zhí)行更多功能的app測試。

除了整個手動測試過程，測試自動化對移動app也很重要。每個代碼變化或新功能都可能影響現(xiàn)存功能及它們的狀態(tài)。通常手動回歸測試時間不夠，所以測試員不得不找一個工具去進(jìn)行自動化回歸測試?，F(xiàn)在市面上有很多自動化測試工具，有商業(yè)的也有開源的，面向各個不同平臺，如Android，iPhone，WindowsPhone7，BlackBerry以及移動Webapp。根據(jù)開發(fā)策略和結(jié)構(gòu)，品質(zhì)管理測試專家需找出最適合他們環(huán)境的自動化工具。

(2) 客戶端性能測試

一個App做的好不好，不僅僅只反應(yīng)在功能上。被測的app在中低端機(jī)上的性能表現(xiàn)也很重要。比如：一個很好玩的游戲或應(yīng)用，只能在高端機(jī)上流暢運行，在中低端機(jī)上卡的不行，也不會取得好的口碑。

關(guān)于App的性能測試，我們比較關(guān)注的參數(shù)有：CPU，內(nèi)存，耗電量，流量，F(xiàn)PS。同時也需關(guān)注一下App的安裝耗時和啟動耗時。

目前大家可能比較困惑的一個問題，多高的CPU，內(nèi)存，耗電量，流量，F(xiàn)PS才算是符合發(fā)布的值呢？這里可以告訴大家，可以參考精品游戲的一些數(shù)值，將自己研發(fā)的app與業(yè)內(nèi)精品的app數(shù)據(jù)做對比。

(3) 適配兼容測試

App在經(jīng)過功能測試后，也需對其進(jìn)行適配兼容測試需要檢查的項主要有以下幾點：

(a) 在不同平牌的機(jī)型上的安裝、拉起、點擊和卸載是否正常；

(b) 在不同的操作系統(tǒng)上的安裝、拉起、點擊和卸載是否正常；

我們在實際測試中，常常會遇到下列問題：

(a) 在某個平牌某個系統(tǒng)上，app安裝不上；

(b) 在某個平牌某個系統(tǒng)上，app無法拉起；

(c) 在某個平牌某個系統(tǒng)上，app拉起后無響應(yīng)或拉起后黑屏、花屏；

(d) 在某個平牌某個系統(tǒng)上，app無法順利卸載；

(4) 安全測試

App在上線前，都需要做詳細(xì)的安全測試。安全測試主要為了檢測應(yīng)用是否容易被外界破解；是否存在被惡意代碼注入的風(fēng)險；上線后外掛的風(fēng)險高不高等。

(5) 服務(wù)器性能測試

服務(wù)器性能測試，主要包含單機(jī)容量測試和24小時穩(wěn)定性測試。單機(jī)容量測試，可以檢測到單機(jī)服務(wù)器在90%的響應(yīng)時間和成功率都達(dá)標(biāo)的前提下，能夠承載多少用戶量。使用特定游戲模型壓測24小時，服務(wù)無重啟，內(nèi)存無泄漏，并且各事務(wù)成功率達(dá)標(biāo)。

26.什么是測試用例?什么是測試腳本?兩者關(guān)系?

測試用例為實施測試而向被測試系統(tǒng)提供的輸入數(shù)據(jù)、操作或各種環(huán)境設(shè)置以及期望結(jié)果的一個特定的集合。

測試腳本是為了進(jìn)行自動化測試而編寫的腳本。

測試腳本的編寫必須對應(yīng)相應(yīng)的測試用例

27.簡述：靜態(tài)測試、動態(tài)測試、黑盒測試、白盒測試、α測試 、β測試分別是什么？

靜態(tài)測試（ui界面 業(yè)務(wù)邏輯 ）是不運行程序本身而尋找程序代碼中可能存在的錯誤或評估程序代碼的過程。

動態(tài)測試（鏈接數(shù)據(jù)之后 ）是實際運行被測程序，輸入相應(yīng)的測試實例，檢查運行結(jié)果與預(yù)期結(jié)果的差異，判定執(zhí)行結(jié)果是否符合要求，從而檢驗程序的正確性、可靠性和有效性，并分析系統(tǒng)運行效率和健壯性等性能。

黑盒測試一般用來確認(rèn)軟件功能的正確性和可操作性,目的是檢測軟件的各個功能是否能得以實現(xiàn),把被測試的程序當(dāng)作一個黑盒,不考慮其內(nèi)部結(jié)構(gòu),在知道該程序的輸入和輸出之間的關(guān)系或程序功能的情況下,依靠軟件規(guī)格說明書來確定測試用例和推斷測試結(jié)果的正確性。

白盒測試根據(jù)軟件內(nèi)部的邏輯結(jié)構(gòu)分析來進(jìn)行測試,是基于代碼的測試，測試人員通過閱讀程序代碼或者通過使用開發(fā)工具中的單步調(diào)試來判斷軟件的質(zhì)量，一般黑盒測試由項目經(jīng)理在程序員開發(fā)中來實現(xiàn)。（白盒測試 ： 使用編程腳本進(jìn)行測試 實現(xiàn)自動化）

α測試：是由一個用戶在開發(fā)環(huán)境下進(jìn)行的測試，也可以是公司內(nèi)部的用戶在模擬實際操作環(huán)境下進(jìn)行的受控測試，Alpha測試不能由程序員或測試員完成。

β測試：是軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進(jìn)行的測試。開發(fā)者通常不在測試現(xiàn)場，Beta測試不能由程序員或測試員完成。

28.在您以往的工作中，一條軟件缺陷（或者叫Bug）記錄都包含了哪些內(nèi)容？如何提交高質(zhì)量的軟件缺陷（Bug）記錄？

一條Bug記錄最基本應(yīng)包含：

bug編號；

bug嚴(yán)重級別，優(yōu)先級；

bug產(chǎn)生的模塊；

首先要有bug摘要，闡述bug大體的內(nèi)容；

bug對應(yīng)的版本；

bug詳細(xì)現(xiàn)象描述，包括一些截圖、錄像…等等；

bug出現(xiàn)時的測試環(huán)境，產(chǎn)生的條件即對應(yīng)操作步驟；

高質(zhì)量的Bug記錄：

1）通用UI要統(tǒng)一、準(zhǔn)確

缺陷報告的UI要與測試的軟件UI保持一致，便于查找定位。

2）盡量使用業(yè)界慣用的表達(dá)術(shù)語和表達(dá)方法

使用業(yè)界慣用的表達(dá)術(shù)語和表達(dá)方法，保證表達(dá)準(zhǔn)確，體現(xiàn)專業(yè)化。

3）每條缺陷報告只包括一個缺陷

每條缺陷報告只包括一個缺陷，可以使缺陷修正者迅速定位一個缺陷，集中精力每次只修正一個缺陷。校驗者每次只校驗一個缺陷是否已經(jīng)正確修正。

4）不可重現(xiàn)的缺陷也要報告

首先缺陷報告必須展示重現(xiàn)缺陷的能力。不可重現(xiàn)的缺陷要盡力重現(xiàn)，若盡力之后仍不能重現(xiàn)，仍然要報告此缺陷，但在報告中要注明無法再現(xiàn)，缺陷出現(xiàn)的頻率。

5）明確指明缺陷類型

根據(jù)缺陷的現(xiàn)象，總結(jié)判斷缺陷的類型。例如，即功能缺陷、界面缺陷、數(shù)據(jù)缺陷，合理化建議這是最常見的缺陷或缺陷類型，其他形式的缺陷或缺陷也從屬于其中某種形式。

6）明確指明缺陷嚴(yán)重等級和優(yōu)先等級

時刻明確嚴(yán)重等級和優(yōu)先等級之間的差別。高嚴(yán)重問題可能不值得解決，小裝飾性問題可能被當(dāng)作高優(yōu)先級。

7）描述 (Description) ，簡潔、準(zhǔn)確，完整，揭示缺陷實質(zhì)，記錄缺陷或缺陷出現(xiàn)的位置

描述要準(zhǔn)確反映缺陷的本質(zhì)內(nèi)容，簡短明了。為了便于在軟件缺陷管理數(shù)據(jù)庫中尋找制定的測試缺陷，包含缺陷發(fā)生時的用戶界面（UI）是個良好的習(xí)慣。例如記錄對話框的標(biāo)題、菜單、按鈕等控件的名稱。

8）短行之間使用自動數(shù)字序號，使用相同的字體、字號、行間距

短行之間使用自動數(shù)字序號，使用相同的字體、字號、行間距，可以保證各條記錄格式一致，做到規(guī)范專業(yè)。

9）每一個步驟盡量只記錄一個操作

保證簡潔、條理井然，容易重復(fù)操作步驟。

10）確認(rèn)步驟完整，準(zhǔn)確，簡短

保證快速準(zhǔn)確的重復(fù)缺陷，“完整”即沒有缺漏，“準(zhǔn)確”即步驟正確，“簡短”即沒有多余的步驟。

11）根據(jù)缺陷，可選擇是否進(jìn)行圖象捕捉

為了直觀的觀察缺陷或缺陷現(xiàn)象，通常需要附加缺陷或缺陷出現(xiàn)的界面，以圖片的形式作為附件附著在記錄的“附件”部分。為了節(jié)省空間，又能真實反映缺陷或缺陷本質(zhì)，可以捕捉缺陷或缺陷產(chǎn)生時的全屏幕，活動窗口和局部區(qū)域。為了迅速定位、修正缺陷或缺陷位置，通常要求附加中文對照圖。

? 附加必要的特殊文檔和個人建議和注解

如果打開某個特殊的文檔而產(chǎn)生的缺陷或缺陷，則必須附加該文檔，從而可以迅速再現(xiàn)缺陷或缺陷。有時，為了使缺陷或缺陷修正者進(jìn)一步明確缺陷或缺陷的表現(xiàn)，可以附加個人的修改建議或注解。

12）檢查拼寫和語法缺陷

在提交每條缺陷或缺陷之前，檢查拼寫和語法，確保內(nèi)容正確，正確的描述缺陷。

13）盡量使用短語和短句，避免復(fù)雜句型句式

軟件缺陷管理數(shù)據(jù)庫的目的是便于定位缺陷，因此，要求客觀的描述操作步驟，不需要修飾性的詞匯和復(fù)雜的句型，增強(qiáng)可讀性。

15）缺陷描述內(nèi)容

缺陷描述的內(nèi)容可以包含缺陷操作步驟，實際結(jié)果和期望結(jié)果。操作步驟可以方便開發(fā)人員再現(xiàn)缺陷進(jìn)行修正，有些開發(fā)的再現(xiàn)缺陷能力很差，雖然他明白你所指的缺陷，但就是無法再現(xiàn)特別是對系統(tǒng)不熟悉的新加入開發(fā)人員，介紹步驟可以方便他們再現(xiàn)。實際結(jié)果可以讓開發(fā)明白錯誤是什么，期望結(jié)果可以讓開發(fā)了解正確的結(jié)果應(yīng)該是如何。

29.在你的項目中詳細(xì)的描述一個測試活動完整的過程？

https://wenku.baidu.com/view/5020f1a767ec102de3bd890a.html

1. 項目經(jīng)理通過和客戶的交流，完成需求文檔，由開發(fā)人員和測試人員共同完成需求文檔的評審，評審的內(nèi)容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實現(xiàn)的功能的地方。項目經(jīng)理通過綜合開發(fā)人員，測試人員以及客戶的意見，完成項目計劃。然后進(jìn)入項目，開始進(jìn)行統(tǒng)計和跟蹤

2. 開發(fā)人員根據(jù)需求文檔完成需求分析文檔，測試人員進(jìn)行評審，評審的主要內(nèi)容包括是否有遺漏或者雙方理解不同的地方。測試人員完成測試計劃文檔，測試計劃包括的內(nèi)容上面有描述。

3. 測試人員根據(jù)修改好的需求分析文檔開始寫測試用例，同時開發(fā)人員完成概要設(shè)計文檔，詳細(xì)設(shè)計文檔。此兩份文檔成為測試人員撰寫測試用例的補(bǔ)充材料。

4. 測試用例完成后，測試和開發(fā)需要進(jìn)行評審。

5. 測試人員搭建環(huán)境

6. 開發(fā)人員提交第一個版本，可能存在未完成功能，需要說明。測試人員進(jìn)行測試，發(fā)現(xiàn)bug后提交給bugzilla。

7. 開發(fā)提交第二個版本，包括bug fix以及增加了部分功能，測試人員進(jìn)行測試。

8. 重復(fù)上面的工作，一般是3-4個版本后bug數(shù)量減少，達(dá)到出貨的要求。

9. 如果有客戶反饋的問題，需要測試人員協(xié)助重現(xiàn)以及回歸測試。

30.如果項目周期很短，測試人力匱乏，你是怎么協(xié)調(diào)的？

依據(jù)代碼review的結(jié)果和影響范圍，對測試內(nèi)容進(jìn)行適當(dāng)?shù)牟眉簟?/p>

借助自動化工具的支持，提高測試案例的執(zhí)行效率。

調(diào)整組內(nèi)任務(wù)的優(yōu)先級，進(jìn)行人力協(xié)調(diào)，優(yōu)先投入最緊要的項目。

必要的情況下加班

31.描述下你團(tuán)隊的測試分工？

https://blog.csdn.net/ljyfree/article/details/105402178

一個測試經(jīng)理，3個測試組長，每個組有5個測試人員：包括自動化測試、，功能測試、性能測試等的測試工程師。

我們往往都是根據(jù)接到的項目來組成測試團(tuán)隊。當(dāng)然人手不夠的時候，可以請幾位開發(fā)人員參與到測試工作中。

**32.你做移動端的應(yīng)用和web的程序應(yīng)用都是如何的兼容性測試的？**

https://blog.csdn.net/weixin_46183674/article/details/113914319

移動端

1、適配系統(tǒng)版本：

去二手平臺找到低版本的設(shè)備

2、 適配不同機(jī)型：

選擇世面上的主流機(jī)型

3、適配尺寸：

4、適配分辨率：

分辨率常見的720p(720×1280),1080p(1080×1920),2k(2560×1440)

5、適配網(wǎng)絡(luò)：

三大運營商 、信號：2G、3G、4G、5G、WiFi

6、適配異形屏

現(xiàn)在手機(jī)花里胡哨的，全面屏、曲面屏、3D屏、劉海屏、挖孔屏、越來越多，所以我們也需要測試一下系統(tǒng)狀態(tài)欄

7、涉及到藍(lán)牙、耳機(jī)，看對應(yīng)功能需要了

web端

1.操作系統(tǒng)兼容性

市場上有很多不同的操作系統(tǒng)，Windows 、Mac、Linux等操作系統(tǒng)。同一個應(yīng)用在不同的操作系統(tǒng)下，可能會有兼容性問題，可能有些系統(tǒng)正常，有些系統(tǒng)不正常。

2.瀏覽器兼容性

國內(nèi)主流的瀏覽器內(nèi)核主要有3種：IE內(nèi)核、Firefox內(nèi)核和Chrome內(nèi)核；

（1）IE內(nèi)核常見的瀏覽器有：360安全瀏覽器（兼容模式）、360極速瀏覽器（兼容模式）、搜狗瀏覽器（兼容模式）、QQ瀏覽器；

（2）Firefox內(nèi)核常見的瀏覽器即火狐瀏覽器（Firefox）；

（3）Chrome內(nèi)核常見的瀏覽器有

3.分辨率兼容性

同一個頁面在不同分辨率下，顯示的樣式可能會不一樣?？梢酝ㄟ^對瀏覽器的縮放的比例進(jìn)行不同分辨率的測試。

臺式機(jī)分辨率：：1024×768、1280×1024、1440×900

筆記本電腦分辨率：1024X768 、1280X800、1440X900、 1600X9000

4.網(wǎng)速測試

項目在不同的網(wǎng)絡(luò)環(huán)境中是否正常的運行，通過Charles、Fiddler等工具進(jìn)行弱網(wǎng)測試。

33.移動應(yīng)用的灰度是怎么做的？

1.開黑白名單（白名單的人下載后可使用，黑名單的人及時可下載但也不可使用）

2.開灰度環(huán)境（直接在后臺控制，可有一級灰度發(fā)布、二級灰度發(fā)布、三級灰度發(fā)布、全量發(fā)布等，每個灰度針對不同的人群）

3.iOS版本可以使用testflight灰度發(fā)布，讓加入的人群提前體驗

4.Android可以使用第三方平臺（如：蒲公英，可設(shè)置下載密碼，提供給特定的人群體驗）?；蛘呱上螺d連接發(fā)給對應(yīng)的人

34.移動應(yīng)用在升級安裝時候應(yīng)該考慮的場景？

1.APP有新版本時，打開APP是否有更新提示。

2.當(dāng)版本為非強(qiáng)制升級版時，用戶可以取消更新，老版本能正常使用。用戶在下次啟動app時，仍能出現(xiàn)更新提示。

3.當(dāng)版本為強(qiáng)制升級版時，當(dāng)給出強(qiáng)制更新后用戶沒有做更新時，退出APP。下次啟動app時，仍出現(xiàn)強(qiáng)制升級提示。

4.不刪除APP直接更新，檢查是否能正常更新，更新后能否正常工作。

5.刪除老的APP，重新下載APP，能不能正常工作。

6.不刪除APP直接更新，檢查更新后的APP和新安裝的APP提供的功能一樣。

7.檢查在線跨版本升級能否成功，版本過老是否提示用戶重裝。

8.更新成功后，用戶數(shù)據(jù)有沒有丟失，各個配置項是否還原。

35.如果讓你來測試掃碼支付，你會考慮哪些場景？

功能測試用例

卡的類型（

一類戶：借記卡、信用卡、各個開戶行

二類戶：虛擬賬戶如微信里的零錢賬戶、支付寶的余額寶、電子賬戶

二維碼的商戶類型（微信、支付寶、匯宜、銀聯(lián)）

支付限額（單筆限額、累計限額、日累計、月累計、支付筆數(shù)）

退款（退款入口、退款進(jìn)度、退款結(jié)果）

對賬

資金流動（我方扣款數(shù)額正確，對方收款數(shù)額正確）數(shù)額及時效

支付結(jié)果展示、交易明細(xì)

連續(xù)掃碼支付，每天的掃碼支付次數(shù)限制及數(shù)額限制

二維碼有效期

有無相機(jī)權(quán)限

前后置攝像頭

像素低端的手機(jī)能否掃碼成功

兼容性

兼容性（不同手機(jī)廠商自帶相機(jī)功能實現(xiàn)不一致）

安全性：

1.是否有超時超次限制

2.測試用戶操作時相關(guān)信息是否寫入了日志文件、是否可追蹤等

3.如果使用了安全套字，需要測試加密是否正確，加密前后的信息完整性，正確性

性能

1.用戶操作的響應(yīng)時間

2.系統(tǒng)的吞吐量（TPS）

3.系統(tǒng)的硬件資源情況（CPU、硬盤、磁盤）

4.網(wǎng)絡(luò)資源占用情況等。

異常場景

異常情況（卡異常、余額不足）

36.一臺客戶端有三百個客戶與三百個客戶端有三百個客戶對服務(wù)器施壓，有什么區(qū)別?

1.)300個用戶在一個客戶端上，會占用客戶機(jī)更多的資源，而影響測試的結(jié)果。線程之間可能發(fā)生干擾，而產(chǎn)生一些異常。

2.)300個用戶在一個客戶端上，需要更大的帶寬。

3.)IP地址的問題，可能需要使用IP Spoof來繞過服務(wù)器對于單一IP地址最大連接數(shù)的限制。

所有用戶在一個客戶端上，不必考慮分布式管理的問題；而用戶分布在不同的客戶端上，需要考慮使用控制器來整體調(diào)配不同客戶機(jī)上的用戶。同時，還需要給予相應(yīng)的權(quán)限配置和防火墻設(shè)置。

37.測試人員同開發(fā)人員的溝通過程中，如何提高溝通的效率和改善溝通的效果？維持測試人員同開發(fā)團(tuán)隊中其他成員良好的人際關(guān)系的關(guān)鍵是什么？

盡量面對面的溝通，其次是能直接通過電話溝通，如果只能通過Email等非及時溝通工具的話，強(qiáng)調(diào)必須對特性的理解深刻以及能表達(dá)清楚。

運用一些測試管理工具如TestDirector進(jìn)行管理也是較有效的方法，同時要注意在TestDirector中對BUG有準(zhǔn)確的描述。

在團(tuán)隊中建立測試人員與開發(fā)人員良好溝通中注意以下幾點：

一真誠、二是團(tuán)隊精神、三是在專業(yè)上有共同語言、四是要對事不對人，工作至上

當(dāng)然也可以通過直接指出一些小問題，而不是進(jìn)入BUG Tracking System來增加對方的好感。

38.簡述你在以前的工作中做過哪些事情，比較熟悉什么？

我過去的主要工作是系統(tǒng)測試和自動化測試。在系統(tǒng)測試中，主要是對BOSS系統(tǒng)的業(yè)務(wù)邏輯功能，以及軟交換系統(tǒng)的Class 5特性進(jìn)行測試。性能測試中，主要是進(jìn)行的壓力測試，在各個不同數(shù)量請求的情況下，獲取系統(tǒng)響應(yīng)時間以及系統(tǒng)資源消耗情況。自動化測試主要是通過自己寫腳本以及一些第三方工具的結(jié)合來測試軟交換的特性測試。

在測試中，我感覺對用戶需求的完全準(zhǔn)確的理解非常重要。另外，就是對BUG的管理，要以需求為依據(jù)，并不是所有BUG均需要修改。

測試工作需要耐心和細(xì)致，因為在新版本中，雖然多數(shù)原來發(fā)現(xiàn)的BUG得到了修復(fù)，但原來正確的功能也可能變得不正確。因此要注重迭代測試和回歸測試。

39.請說出這些測試最好由那些人員完成，測試的是什么？

代碼、函數(shù)級測試一般由白盒測試人員完成，他們針對每段代碼或函數(shù)進(jìn)行正確性檢驗，檢查其是否正確的實現(xiàn)了規(guī)定的功能。

模塊、組件級測試主要依據(jù)是程序結(jié)構(gòu)設(shè)計測試模塊間的集成和調(diào)用關(guān)系，一般由測試人員完成。

系統(tǒng)測試在于模塊測試與單元測試的基礎(chǔ)上進(jìn)行測試。了解系統(tǒng)功能與性能，根據(jù)測試用例進(jìn)行全面的測試。

40.在windows下保存一個文本文件時會彈出保存對話框，如果為文件名建立測試用例，等價類應(yīng)該怎樣劃分？

10. 單字節(jié)，如A；

11. 雙字節(jié)， AA、我我；

12. 特殊字符 /‘?！?；、=-等；

13. 保留字，如com；

14. 文件格式為8.3格式的；

15. 文件名格式為非8.3格式的；

16. /,\,*等九個特殊字符。

17. 空字符串；

18. 數(shù)字字母組合；

19. 單字節(jié)雙字節(jié)組合；

20. 字符與特殊字符組合

41.假設(shè)有一個文本框要求輸入10個字符的郵政編碼，對于該文本框應(yīng)該怎樣劃分等價類？

特殊字符，如10個*或￥；英文字母，如ABCDefghik；小于十個字符，如123；大于十個字符，如11111111111；數(shù)字和其他混合，如123AAAAAAA；空字符；保留字符

42.您以往的工作中是否曾開展過測試用例的評審工作?如果有，請描述測試用例評審的過程和評審的內(nèi)容。？

評審計劃->預(yù)審->評審;

評審內(nèi)容主要是測試用例對軟件需求的覆蓋程度，對于相關(guān)邊界是否考慮，是否針對復(fù)雜流程準(zhǔn)備多套測試數(shù)據(jù)，是否有專門針對非功能性需求的測試。

43.在你測試的過程中如果發(fā)生時間上不允許進(jìn)行全部測試，你應(yīng)該怎么做？

軟件測試初學(xué)者可能認(rèn)為拿到軟件后需要進(jìn)行完全測試，找到全部的軟件缺陷，使軟件“零缺陷”發(fā)布。實際上完全測試是不可能的。主要有以下一個原因：

-完全測試比較耗時，時間上不允許；

-完全測試通常意味著較多資源投入，這在現(xiàn)實中往往是行不通的

-輸入量太大，不能一一進(jìn)行測試；

-輸出結(jié)果太多，只能分類進(jìn)行驗證；

-軟件實現(xiàn)途徑太多；

-軟件產(chǎn)品說明書沒有客觀標(biāo)準(zhǔn)，從不同的角度看，軟件缺陷的標(biāo)準(zhǔn)不同；

因此測試的程度要根據(jù)實際情況確定。

44.列舉web自動化中常見的元素定位方式是？

1）通過class屬性定位

driver.findElement(By.className("spread")).sendKeys("你好");

2）通過id屬性定位

driver.findElement(By.id("username")).sendKeys("你好");

3）通過name屬性定位

driver.findElement(By.name("username")).sendKeys("你好");

4）通過link屬性定位

driver.findElement(By.linkText("海賊王")).click();

5）通過partialLink定位

driver.findElement(By.partialLinkText("賊")).click();

6）通過標(biāo)簽tabname定位

driver.findElement(By.tagName("a")).click();

7）通過css定位

driver.findElement(By.cssSelector("input[type=‘button‘]")).click();

8）通過xapth定位

driver.findElement(By.xpath("/html/body/div[1]/input[2]")).click();

//通過xpath絕對路徑的方式定位

driver.findElement(By.xpath("http://input[@value=‘查詢‘]")).click();

//通過相對路徑的方式定位

driver.findElement(By.xpath("http://a[text()=‘百度一下‘]")).click();

//相對路徑方式，元素是可點擊的鏈接文字

45.簡述你知道的延時等待的方式?

硬性等待，也叫線程等待，通過休眠的方式完成等待如等待5秒Thead.sleep(5000)

隱式等待，通過imlicitlyWait完成延時等待，這種事針對全局設(shè)置的等待，如設(shè)置超市10秒，使用imlicitlyWait后，如果第一次沒有找到元素，會在10秒之內(nèi)不斷循環(huán)查找元素，如果超時間10秒還沒有找到，則拋出異常

顯式等待，智能等待，針對指定元素定位指定等待時間，指定的范圍內(nèi)進(jìn)行元素查找，找到元素則直接返回，超時沒有找到元素則拋出異常

46.完整運行一次自動化用例需要多久時間？

主要跑的是業(yè)務(wù)流，所以跑一次需要半個小時左右

47.什么是分層自動化？

金字塔結(jié)構(gòu)， 最底層UnitTest，往上接口API/集成起來的service， 最上面UI自動化

48.你的測試數(shù)據(jù)是怎么準(zhǔn)備的？

? ? ? ? 小型系統(tǒng)的測試，業(yè)務(wù)數(shù)據(jù)一般可以直接獲取以前版本的數(shù)據(jù)，通過SQL數(shù)據(jù)或某些命令操作，取得當(dāng)前需要使用的數(shù)據(jù)。

? ? ? ? 對于復(fù)雜系統(tǒng)，測試數(shù)據(jù)準(zhǔn)備可能需要封裝一系列的API函數(shù)，例如一種策略就是先封裝出一個完全API調(diào)用函數(shù)，里面有各種常規(guī)默認(rèn)值，然后再這個基礎(chǔ)上針對業(yè)務(wù)進(jìn)行封裝，面向該操作只需要設(shè)定某個特定值的，可以調(diào)用該特定封裝函數(shù)。極個別的，可以直接調(diào)原始的完全封裝。當(dāng)然，考慮到一些大公司的情況，可能還需要考慮跨平臺測試架構(gòu)的情況，有些人提出進(jìn)一步封裝，提供RestFul的調(diào)用接口來屏蔽開發(fā)工具特性。其實，都只有一個目的，盡量把測試數(shù)據(jù)和產(chǎn)生方法隔離，而只側(cè)重測試的業(yè)務(wù)屬性。

? 大量需要業(yè)務(wù)累積才能形成的測試數(shù)據(jù)，一般只有一個辦法，就是通過大量實際數(shù)據(jù)脫敏。但如果涉及面向公眾業(yè)務(wù)或國防業(yè)務(wù)之類，考慮到安全策略限制，就只能用笨辦法就通過自動化操作來逐步實施模擬，但是這個方法就是太慢，并且不見得好用。

? ? ? ? 對測試數(shù)據(jù)準(zhǔn)備都需要有專人專責(zé)的一段時間來做的，就是很大系統(tǒng)很大業(yè)務(wù)了，這時很有必要對測試數(shù)據(jù)采取嚴(yán)格的版本管理和配置部署管理。用戶需要首先注冊數(shù)據(jù)，注明對應(yīng)版本。測試運行時，平臺會有統(tǒng)一生成的腳手架，對應(yīng)腳本需要使用的數(shù)據(jù)必須標(biāo)明版本。

? ? ? ? 而考慮到自動化和靈活性，一般比較通用的方法還是先考慮實際數(shù)據(jù)脫敏，然后通過SQL腳本為基礎(chǔ)，結(jié)合API調(diào)用，需要靈活配置的部分放到配置文件中，再加上配置管理來保證。這一般只在大型網(wǎng)站、大型系統(tǒng)有這個必要。

? ? ? ? 實際測試時，針對測試數(shù)據(jù)，可能有以下一些策略：1、檢索：只允許從現(xiàn)在系統(tǒng)中或已使用的數(shù)據(jù)中檢索，沒有的話直接生成數(shù)據(jù)失??；2、新創(chuàng)建：有些時候需要全新創(chuàng)建數(shù)據(jù)；3、智能：無所謂，只要有符合要求 ；4、out-of-box：使用緩沖池預(yù)先準(zhǔn)備的數(shù)據(jù)。

49.請簡述Appium和selenium的原理？

selenium的原理

我們使用Selenium實現(xiàn)自動化測試，主要需要3個東西

1.測試腳本，可以是python，java編寫的腳本程序（也可以叫做client端）

2.瀏覽器驅(qū)動, 這個驅(qū)動是根據(jù)不同的瀏覽器開發(fā)的，不同的瀏覽器使用不同的webdriver驅(qū)動程序且需要對應(yīng)相應(yīng)的瀏覽器版本，比如：geckodriver.exe(chrome)

3.瀏覽器，目前selenium支持市面上大多數(shù)瀏覽器，如：火狐，谷歌，IE等

appium工作原理

當(dāng)開啟appium服務(wù)器的同時就開啟了監(jiān)聽端口；我們運行腳本的時候，調(diào)用任何的appiumAPI，都會向Appium Server端post一條HTTP請求，請求內(nèi)容就是根據(jù)webdriver wire protocol協(xié)議規(guī)定的一條JSON格式的數(shù)據(jù)；Appium Server端接收到請求后，解析出JSON數(shù)據(jù)并發(fā)送到手機(jī)端；手機(jī)端上已經(jīng)由BootStrap.jar(iOS為BootStrip.js)開啟的socket服務(wù)器監(jiān)聽相應(yīng)的端口，BootStrap.jar在appium每個session第一次訪問手機(jī)端的時候會自動安裝；手機(jī)端接收到對應(yīng)的請求后，通過BootStrap.jar翻譯成UIAutomator能執(zhí)行的命令，然后通過UIAutomator處理并操作APP完成測試。

50.Charles如惡化抓取app端的htpps接口的？

1，下載charles

https://www.charlesproxy.com/download/

2.跟著提示一直下一步安裝即可

3.啟動charles安裝證書? 點擊charles中的help->SSL Proxying->install charles Root certificate

? 安裝時注意 選擇將所有證書存儲到第三方根證書頒發(fā)機(jī)構(gòu)

? 最后點擊證書路徑 看證書狀態(tài) 顯示改證書沒有問題即可

4.手機(jī)端配置網(wǎng)絡(luò)代理 需要和電腦端在同一個局域網(wǎng)

win+R 輸入cmd 輸入ipconfig查看ip地址

點擊Proxy -》Proxy Settings查看端口號

5.蘋果手機(jī) 在safari瀏覽器中輸入： http://chls.pro/ssl

　安卓手機(jī) 在自帶的瀏覽器中輸入 http://chls.pro/ssl

　會自動提示下載 安裝證書后 有彈窗選擇Allow

6.如果瀏覽器輸入http://chls.pro/ssl? 沒有網(wǎng)絡(luò) 需要在pc端設(shè)置下網(wǎng)絡(luò)防火墻允許charles應(yīng)用通過

7.此時抓包charles會顯示unknown

? 需要配置抓取https請求

? 點擊Proxy -> SSL Proxying Settings

? Host輸入框輸入*

? Port輸入框輸入*

8.以上就配置好了? 如果不行請重啟charles

51.如何實現(xiàn)jenkins實現(xiàn)自動自動化打包發(fā)布和啟動？

1.下載jenkins安裝包并安裝

本例使用jenkins-2.86的windows版本

2.安裝常用插件

如PUBLISH OVER SSH、Subversion Plug-in、Credentials Binding Plugin、Maven Integration plugin

3.配置svn賬號，用于拉取源碼

4.配置maven、JDK

5.配置SSH服務(wù)器

6.構(gòu)建一個maven工程

7.構(gòu)建完成后把war包發(fā)布到遠(yuǎn)程tomcat，并執(zhí)行腳本重啟tomcat

8.需要修改腳本為可執(zhí)行腳本，否則jenkins權(quán)限不夠執(zhí)行shell腳本

9.jenkins控制臺亂碼

52.請寫出冒泡排序

public static int[] buddleSort(int[] arr){

? ? for(int i=1;i<arr.length;i++){

? ? ? ? for(int j=0; j<arr.length-i; j++){

? ? ? ? ? ? if(arr[j] < arr[j+1]){

? ? ? ? ? ? ? ? int temp = arr[j];

? ? ? ? ? ? ? ? arr[j] = arr[j+1];

? ? ? ? ? ? ? ? arr[j+1] = temp;

? ? ? ? ? ? }

? ? ? ? }

? ? }

? ? return arr;

}

53.數(shù)據(jù)庫的中的左連接右連接和全連接內(nèi)連接的區(qū)別？

1、內(nèi)聯(lián)接（典型的聯(lián)接運算，使用像 = ?或 <> 之類的比較運算符）。包括相等聯(lián)接和自然聯(lián)接。

內(nèi)聯(lián)接使用比較運算符根據(jù)每個表共有的列的值匹配兩個表中的行。例如，檢索 students和courses表中學(xué)生標(biāo)識號相同的所有行。

2、外聯(lián)接。外聯(lián)接可以是左向外聯(lián)接、右向外聯(lián)接或完整外部聯(lián)接。

在 FROM子句中指定外聯(lián)接時，可以由下列幾組關(guān)鍵字中的一組指定：

1）LEFT ?JOIN或LEFT OUTER JOIN

左向外聯(lián)接的結(jié)果集包括 ?LEFT OUTER子句中指定的左表的所有行，而不僅僅是聯(lián)接列所匹配的行。如果左表的某行在右表中沒有匹配行，則在相關(guān)聯(lián)的結(jié)果集行中右表的所有選擇列表列均為空值。

2）RIGHT ?JOIN 或 RIGHT ?OUTER ?JOIN

右向外聯(lián)接是左向外聯(lián)接的反向聯(lián)接。將返回右表的所有行。如果右表的某行在左表中沒有匹配行，則將為左表返回空值。

3）FULL ?JOIN 或 FULL OUTER JOIN

完整外部聯(lián)接返回左表和右表中的所有行。當(dāng)某行在另一個表中沒有匹配行時，則另一個表的選擇列表列包含空值。如果表之間有匹配行，則整個結(jié)果集行包含基表的數(shù)據(jù)值。

54.測試結(jié)束的標(biāo)準(zhǔn)是什么？

單元測試退出標(biāo)準(zhǔn)

1) 單元測試用例設(shè)計已經(jīng)通過評審

2) 核心代碼100％ 經(jīng)過Code Review

3) 單元測試功能覆蓋率達(dá)到100％

4) 單元測試代碼行覆蓋率不低于80％

5) 所有發(fā)現(xiàn)缺陷至少60％都納入缺陷追蹤系統(tǒng)且各級缺陷修復(fù)率達(dá)到標(biāo)準(zhǔn)

6) 不存在A、B類缺陷

7) C、D、E類缺陷允許存在

8) 按照單元測試用例完成了所有規(guī)定單元的測試

9) 軟件單元功能與設(shè)計一致

集成測試退出標(biāo)準(zhǔn)

1) 集成測試用例設(shè)計已經(jīng)通過評審

2) 所有源代碼和可執(zhí)行代碼已經(jīng)建立受控基線，納入配置管理受控庫，不經(jīng)過審批不能隨意更改

3) 按照集成構(gòu)件計劃及增量集成策略完成了整個系統(tǒng)的集成測試

4) 達(dá)到了測試計劃中關(guān)于集成測試所規(guī)定的覆蓋率的要求

5) 集成工作版本滿足設(shè)計定義的各項功能、性能要求

6) 在集成測試中發(fā)現(xiàn)的錯誤已經(jīng)得到修改，各級缺陷修復(fù)率達(dá)到標(biāo)準(zhǔn)

7) A、B類BUG不能存在

8) C、D類BUG允許存在,但不能超過單元測試總BUG的50％。

9) E類BUG允許存在

系統(tǒng)測試退出標(biāo)準(zhǔn)

1) 系統(tǒng)測試用例設(shè)計已經(jīng)通過評審

2) 按照系統(tǒng)測試計劃完成了系統(tǒng)測試

3) 系統(tǒng)測試的功能覆蓋率達(dá)100％

4) 系統(tǒng)的功能和性能滿足產(chǎn)品需求規(guī)格說明書的要求

5) 在系統(tǒng)測試中發(fā)現(xiàn)的錯誤已經(jīng)得到修改并且各級缺陷修復(fù)率達(dá)到標(biāo)準(zhǔn)

6) 系統(tǒng)測試后不存在A、B、C類缺陷

7) D類缺陷允許存在，不超過總?cè)毕莸?％

8) E類缺陷允許存在，不超過總?cè)毕莸?0％

注：這只是一套比較理想化的退出標(biāo)準(zhǔn)，但在實際工作中不可能達(dá)到這種程度，尤其是測試覆蓋率和缺陷解決率不可能是100%。現(xiàn)在的軍方標(biāo)準(zhǔn)是達(dá)到99%。對于通用軟件來說就要根據(jù)公司實際情況了。