軟測基礎
軟體測試的目的與原則是什麼？
軟體測試的目的：
通過測試工作可以發現并修複軟體當中存在的缺陷，進而提高使用者對産品的使用信心。
軟體測試的原則：
1.證明軟體存在缺陷；
2.不能執行窮盡測試；
3.缺陷存在群集現象；
4.某些測試需要依賴特殊的環境；
5.測試應盡早介入；
6.殺蟲劑現象。
測試人員在測試中的任務是什麼？
1.盡可能早的找出系統中的bug；
2.避免軟體開發過程中缺陷的出現；
3.衡量軟體的品質，保證系統的品質；
4.關注使用者的需求，并保證系統符合使用者需求。
總的目标是：確定軟體的品質
測試用例評審的流程是什麼？
目的：主要是為了展開測試用例評審工作提供指引，規範測試用例管理工作。
流程：
1.測試用例是否按照公司定義的模闆進行編寫的；
2.測試用例的本身的描述是否清晰，是否存在二義性；
3.測試用例内容是否正确，是否與需求目标相一緻；
4.測試用例的期望結果是否确定、唯一的；
5.操作步驟應與描述是否相一緻；
6.測試用例是否覆寫了所有的需求；
7.測試設計是否存在備援性；
8.測試用例是否具有可執行性；
9.是否從使用者層面來設計使用者使用場景和業務流程的測試用例；
10.場景測試用例是否覆寫最負載的業務流程；
11.用例設計是否包含了正面、反面的用例；
12.對于由系統自動生成的輸出項是否注明了生成規則；
13.用例應包含對中間和背景資料的檢查；
14.測試用例應有正确的名稱和編号；
15.測試用例應标注有執行的優先級；
16.測試用例包含相關的配置資訊：測試環境、資料、前置測試用例、使用者授權等；
17.每個測試用例步驟應<=15 step；
18.自動化測試腳本必須帶有注釋（注釋應包括：目的、輸入、期望結果等）；
19.非功能測試需求或不可測試需求是否在用例中列出并說明。
缺陷報告内容包括什麼？
和bug産生對應的軟體版本；
開發的接口人員；
bug的優先級；
bug的嚴重程度；
bug可能屬于的子產品，如果不能确定，可以找開發人員來判斷；
bug标題，需要清晰的描述現象；
bug描述，需要盡量給出bug的步驟；
bug附件中能給出相關的日志和截圖。
請您描述一下測試的v模型。
bug不能複現怎麼辦？
1.首先考慮環境問題，看是否能夠還原原來的環境；
2.遇到問題就要提，不能放過任何一個bug，在送出的bug描述中加上一句話，那就是複現機率，交給開發，開發會根據bug的複現機率，調整bug的優先級；
3.盡量回想發生問題時的複現步驟，不要漏掉任何一個細節，按照步驟嘗試複現；
4.與開發人員配合，讓開發人員對相應的代碼檢查，看是否通過代碼層面檢查出問題；
5.保留發生bug時的log，附加到送出的bug中，希望可以通過log中找到一些蛛絲馬迹；
6.檢視代碼，也許是代碼變更引起的bug。
什麼是HTTP協定，請求方法是什麼？以及HTTP與HTTPS協定的差別？
http協定又叫做超文本傳輸協定，在做網絡請求的時候，我們基本上是使用http協定。
請求方式包括get請求和post請求。
http協定與https協定的差別：
1.http協定需要ca申請證書，一般免費證書較少，需要一定費用。
2.http的連結簡單，是無狀态的，而https協定是由SSL+http洗衣建構的可進行加密傳輸，身份認證的網絡協定要比http協定安全。
3.http協定是超文本協定，又叫明碼傳輸，而https是具有安全性的SSL加密傳輸協定。
4.http協定與https協定使用的連結方式不同，http用的端口是80，https用的端口是443。
get與post請求的差別？
get請求使用URL或cookie傳參，而post将資料放到body中；
get的URL會有長度上的限制，而post的資料則可以非常大；
post比get安全，因為資料在位址欄上不可見；
一般get請求用來擷取資料，post請求用來發送資料。
重載與重寫的差別？
重載是定義相同的方法名，參數不同，重寫是子類重寫父類的方法；
重載是在一個類中，重寫是在子類與父類之間；
重載是編譯時的多态性，重寫是運作時的多态性。
App測試與web測試的差別？
相同點：
同樣的測試用例設計方法；
同樣的測試方法：都會依據原型圖來檢查UI；
測試頁面載入和翻頁的速度、登陸時長、記憶體是否溢出等；
測試應用系統的穩定性。
不同點：
App的中斷測試：來電中斷、短信中斷、藍牙中斷、鬧鐘等；
App的安裝解除安裝：全部安裝、更新安裝、第三方工具安裝解除安裝、消息推送、前背景切換、網絡環境等；
相容性測試：web項目考慮不同浏覽器相容，App考慮不同作業系統、不同機型、不同螢幕等；
網絡測試：不同網絡與營運商，不同的網絡制式，如GSM，CDMA，3G等，在不好或無網絡的情況下的app行為；
web自動化測試工具較常用selenium，而手機自動化monkey、appium；
App測試平台：百度雲測、PerfDog、testin雲測
BS/CS架構的差別是什麼？
概念：
所謂的架構就是用來指導我們軟體開發的一種思維，目前最常見的就是BS/CS。
B——browser浏覽器
C——clent用戶端
S——server服務端
差別：
1.标準：相對于CS架構來說BS架構的兩端都是在使用現成的成熟産品，是以BS會顯示的标準一些。
2.效率：相對BS架構來說CS中的用戶端可以分擔一些資料的處理，是以執行效率會高一些。
3.安全：BS架構當中得到資料傳輸都是以http協定進行的輸出，而http協定又是明文輸出，可以被抓包，是以相對于CS架構來說BS就顯得不那麼安全（相對的）
4.更新：BS架構隻需要在伺服器端将資料進行更新，前台隻需要重新整理頁面就可以完成更新，而CS架構當中必須将兩端都進行更新。
5.開發成本：相對于BS架構來說，CS當中的用戶端需要自己開發，是以相對來說成本會高一些。
Android手機與iOS手機系統有什麼差別？
1.兩者運作機制不同：iOS采用的是沙盒機制，安卓采用的是虛拟機運作機制；
2.兩者背景機制不同：iOS中任何第三方程式都不能在背景運作，安卓任何程式都能在背景運作，直到沒有記憶體才會關閉；
3.iOS中用于UI指令權限最高，安卓中資料處理指令權限最高。
請說一下測試分類？
你以前工作時的測試流程是什麼？
需求分析——>設計用例——>評審用例——>配置環境——>執行用例——>回歸測試及缺陷跟蹤——>輸出測試報告——>測試結果
當你參加評審時，你的評審原則是什麼？
正确性：每一條需求都必須準确的陳述其要開發的功能；
一緻性：必須與其他軟體需求或高層需求不相沖突；
可行性：其每一項需求都必須是以系統和環境的權能和限制範圍可以來實施的；
必要性：每項需求都是用來授權你編寫文檔的“根源”，要使每項需求都能回溯至某項客戶的輸入；
可測試性：每項需求都能夠通過設計測試用例或其他的驗證方法來進行測試；
可修改性：每項需求隻應在SRS中出現一次，這樣更改會容易保持一緻性；
可跟蹤性：在每項軟體需求與它的根源與設計元素，源代碼，測試用例之間建立起連結，而這種可跟蹤性要求每項需求都必須以一種結構化的，粒度好的方式編寫并單獨标明，而不是大段大段的陳述；
配置設定優先級：應當對所有的需求配置設定優先級，如把所有需求都看作同樣重要，那麼項目管理者在開發或節省預算或排程中喪失控制自由度。
軟體測試的需求标準是什麼？
文檔版本資訊：包含文檔版本、作者、完成日期，如果是修訂版需要加上修訂記錄
目錄：目錄結構要清晰
産品架構：一般包括功能架構和資訊架構，可根據項目性質來确定
角色定義
功能摘要：列出一級功能——>二級功能。不需要細分
詳細功能描述（即産品特性）：包括功能清單、原型界面、詳細設計等
其他産品需求：依據公司産品要求來定，一般包含系統相容性要求、産品營運要求、性能要求等
請寫一下W模型圖？
跟開發人員因為bug産生分歧你是如何解決的？
1.問題确認與評估；
2.明确開發不修改該缺陷的确切原因；
3.具體問題具體分析；
4.發揮TM與PM的溝通職責
如何送出高品質的軟體缺陷報告（記錄）？
1.通用UI要統一、準确；
2.盡量使用業界慣用的表達術語和表達方法；
3.每條缺陷報告隻包括一個缺陷；
4.不可重制的缺陷也要報告；
5.明确指明缺陷類型；
6.明确指明缺陷嚴重等級和優先等級；
7.描述簡潔、準确、完整，揭示缺陷實質，記錄缺陷或缺陷出現的位置；
8.短行之間使用自動數字序号，使用相同的字型、字号、行間距，可以保證各條記錄格式一緻，做到規範專業；
9.沒一個步驟盡量隻記錄一個操作；
10.确認步驟完整，準确，簡短；
11.根據缺陷，可選擇是否進行圖像捕捉。
手機端測試的關注點有哪些？
ui測試、功能測試、性能測試、安裝解除安裝測試、軟體更新測試、登入測試、安全性測試、消息推送、前背景切換、相容性測試、網絡環境測試、monkey測試。
web測試的方法有哪些？
測試用例的方法有哪些以及包含的内容？
方法：等價類劃分法，邊界值，場景法，因果圖，正交表。
内容：
等價類：有效等價類，無效等價類；
邊界值：上點（邊界上的點），離點（離上點最近的點），内點（邊界有效範圍内的任意一點）
場景法：基本流，備選流，異常流
因果圖：輸入與輸入的關系（異：所有輸入條件中最多有一個産生，也可以一個沒有；或：所有輸入條件中，最少有一個産生、或者多個、或者沒有；唯一：有且隻有一個條件産生；要求：隻要有一個産生，其他跟着也會出現）
正交表：因子（所有參與試驗的影響試驗結果的條件），水準（影響試驗因子的取值或輸入）
軟體品質的特性是什麼？
1.功能性：軟體需要滿足使用者顯示或者隐式的功能；
2.易用性：軟體易于上手和學習；
3.可靠性：軟體必須實作需求文檔中指明的具體功能；
4.效率性：類似于軟體的性能；
5.可維護性：軟體具有将某一個功能修複之後繼續使用的功能；
6.可移植性：軟體具有從一個平台移植到另一個平台上去使用的能力。
測試計劃工作的目的是什麼？以及測試計劃文檔的内容包括什麼？
測試計劃工作的目的：借助軟體測試計劃，參與測試的項目成員，尤其是測試管理人員，可以明确測試任務和測試方法，保持測試實施過程中的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。
測試計劃文檔包括：測試背景、測試的目的、人員的安排、時間的配置設定、測試環境情況、風險評估等。
搭建過什麼環境，搭建工作環境是如何搭建的？
企業用的是Java開發的，搭建測試環境是用Linux+MySQL資料庫+Tomcat+war包。
還有持續內建，這個方式引入Jenkins，把手動的方式轉變成自動化部署
像安裝配置的時候就在網上找一份文檔，按照文檔進行配置
怎樣保證覆寫使用者需求？
項目開始前，我們會先熟悉需求，畫好流程圖，保證整個流程都覆寫全面，小組之間每個人都根據各自的流程圖，各個功能點有哪些限制條件來講解一下自己對測試點的了解，防止之後編寫測試用例時出現遺漏；
用例編寫完成之後，再進行用例的評審，看看測試點有沒有遺漏，對需求了解有沒有錯誤，測試場景是否覆寫完全。
開發環境與測試環境有什麼差別？
開發環境是程式員們專門用于開發的伺服器，配置可以比較随意，一般為了開發調試友善，一般打開全部錯誤報告。
測試環境一般是克隆一份生産環境的配置，一個程式在測試環境工作不正常，那麼肯定不能把它釋出到生産機上。
請說幾個常見的狀态碼？
200：請求發送成功；
302：代表重定向；
400：用戶端發送的請求文法錯誤；
401：請求的頁面沒有授權；
403：沒有權限通路這個頁面；
404：沒有這個頁面；
500：伺服器内部異常；
501：目前不能處理用戶端的請求；
504：伺服器端逾時，沒傳回結果。
壓力測試與負載測試的差別是什麼？
壓力測試通常是在高負載的情況下來對系統的穩定性進行測試，更有效地發現系統穩定性的隐患和系統在負載峰值的條件下功能隐患等。
負載測試是通過改變系統負載方式、增加負載等來發現系統中所存在的性能問題。
代碼的版本管理用什麼工具？
get和SVN都用過
get操作：get add . 添加所有檔案
get commit -m “描述” 送出
get push origin 分支名 上傳分支
SVN操作： Checkout（提取）
Commit（送出）
Update (更新)
你都做過什麼測試？
略
如果回歸測試不通過怎麼辦？
分析問題，明确為什麼沒通過；
如果不是明确送出的缺陷确實存在，缺陷報告傳回開發人員；
開發人員重新修改問題；
再次送出測試人員回歸測試。
測試報告包括哪些？
項目的概要描述；
測試過程缺陷的統計，一定程度反映項目的品質；
整個項目過程有需要改善的地方，提出建議；
給出結論，項目是否可以上線。
你在項目中最經典的bug是什麼？
1.相容性問題，在IE浏覽器送出按鈕可以點選，到了谷歌，火狐就不能了
2.字段的值顯示不是想要的結果，或沒有顯示。（開發從庫表取值有誤）
3.送出資料之後，狀态沒有轉變為已送出。（代碼沒有正确擷取庫表中記錄狀态改變的狀态碼）
4.修改密碼，新密碼與舊密碼一緻也能成功，沒有做新舊密碼的校驗。
你在工作中遇到最棘手的問題是什麼？
略
性能測試
性能測試關注的名額是什麼？
從外部看，性能測試主要關注如下三個名額：
吞吐量：每秒鐘系統能夠處理的請求數、任務數
響應時間：服務處理一個請求或一個任務的耗時
錯誤率：一批請求中結果出錯的請求所占比例
從伺服器的角度看，性能測試主要關注CPU、記憶體、伺服器負載、網絡、磁盤IO等。
性能測試怎麼做的？/ 如果你要進行性能測試，你是如何展開操作的？
1.确定關鍵業務，關鍵路徑；
2.确定測試的關鍵資料。比如并發量，響應時間，循環次數等；
3.準備測試環境，完成腳本錄制或腳本開發；
4.執行測試，觀察或監控輸出參數，比如吞吐量，響應時間，資源占有率等；
5.對執行結果進行分析，分析性能問題。
怎樣分析性能測試結果？
1.檢視聚合報告和伺服器的資源使用圖，檢查響應時間，事務成功率，CPU，記憶體和IO使用率是否達到要求，如果出錯率達到了總請求的3%，我們會檢查是什麼原因導緻的，修改好後，重新測試；
2.如果出現了性能瓶頸，比如響應時間，或者CPU使用率不達标，我們會從伺服器上導出日志，分析是哪個地方導緻響應時間過長，如果分析不出來，就叫上開發一起讨論，确定問題後，就提單給代發修複，修複好了就進行回歸測試。
你們項目最佳的并發使用者數是多少？
略
如何判斷網絡是否存在瓶頸？
檢視在整個性能測試過程中，網絡的吞吐量是多少，如果網絡的吞吐量占到了伺服器的70%以上，我們就認為網絡存在瓶頸，通常會增加帶寬或者壓縮傳輸資料。
如何判斷響應時間不達标？
根據性能測試結果先檢檢視下是否是伺服器帶寬存在問題，如果帶寬存在瓶頸，則會考慮增加帶寬或者壓縮傳輸資料，如果帶寬沒有問題的話，我們會從伺服器上導出日志，開發一起讨論分析是哪個地方導緻響應時間過長，确定問題後，就提單給開發修複，修複好了就進行回歸測試。
如何判斷CPU使用率不達标？
CPU使用率不達标，我們會從伺服器上導出日志，分析是哪個地方導緻CPU使用率不達标，如果分析不出來，就叫上開發一起讨論，确定問題後，就提單給開發修複，修複好了就進行回歸測試。
app的性能測試怎麼做的？
APP的性能測試分為伺服器端的性能和手機端的性能。
伺服器端的性能：jmeter工具進行測試的，和web端性能測試的方法一樣的。
手機端APP的穩定測試：使用monkey做。
用monkey做app測試，怎麼做的？如果有問題的話怎麼定位？
1.先使用 adb logcat -c 清空手機的logcat日志；
2.接下來使用 adb logcat -v time 擷取logcat 日志，并導入本地檔案使用 monkey 運作被測應用 adb shell monkey -p 包名 -v 3.100000 并将執行結果導入到本地測試；
4.如果中途失敗了就要去看monkey日志中有沒有crash或者anr的關鍵字；
5.如果還需要定位到是什麼原因導緻的anr或者crash的問題，将相關日志和logcat日志與程序号送出給開發定位；
6.如果是anr的問題，還需要從安卓中擷取/data/anr/traces.txt檔案送出給開發定位。
app出現ANR的原因？
線程阻塞，記憶體不足，CPU滿負荷（現在手機基本都是8核CPU，基本不會出現CPU滿負荷的情況）
app出現CRASH的原因？
空指針值，數組越界，記憶體不足，CPU滿負荷（現在手機基本都是8核CPU，基本不會出現CPU滿負荷的情況）
APP常見崩潰原因？
1.裝置碎片化：由于裝置極具多樣性，App在不同的裝置上可能有不同表現形式；
2.寬帶限制：寬帶不佳的網絡對App所需的快速響應時間不夠；
3.網絡的變化：不同網絡的切換可能會影響App的穩定性；
4.記憶體管理：可能記憶體過低，或者是授權的記憶體位置的使用可能會導緻App失敗；
5.使用者過多：連續數量過多可能會導緻App崩潰；
6.代碼錯誤：沒有經過測試的新功能，可能會導緻App在生産環境中失敗；
7.第三方服務：廣告或彈出螢幕可能會導緻App崩潰。
說幾個常用的adb指令？
adb install（apk的檔案路徑） 安裝軟體到手機或者模拟器
adb uninstall（包名） 解除安裝手機或模拟器上的某款軟體
adb devices 檢視與目前電腦連接配接的移動裝置
adb ,adb start-server 啟動
adb,adb kill-server 殺死
adb logcat 檢視日志
adb logcat -v time process >
軟體覆寫安裝的adb指令？
adb install -r xx.apk 覆寫低版本的
adb install -r -d 覆寫高版本的
性能測試的adb指令？
adb shell dumpsys cpuinfo 檢視手機cpu的使用情況
adb shell getprop|findstr dalvik 手機系統自己運作的記憶體使用
說幾個monkey指令？
Adb shell monkey -p 包名
Adb-shell–ignore-crashes 忽略崩潰
Adb-shell–ignore-timeouts 忽略延時
Adb-shell–ignore-throttle 延時毫秒值
Adb-shell–pct-touch–pct-motion 觸摸與滑動事件的比例
弱網情況下你是如何測試的？
1.2G的網速150kbps，折合下載下傳速度15-20k/s
2.3G的網速1-6mbps，折合下載下傳速度120k/s-600k/s
3.4G的網速10-100mbps，折合下載下傳速度1.5m/s-10m/s
4.使用真實的SIM卡，營運商網絡來進行測試
5.通過代理的方式模拟弱網環境下進行測試（Charles延遲）
6.連結模拟弱網的熱點進行測試（如360WiFi助手可以設定）
接口測試
接口測試流程？
1.後端完成開發，輸出接口文檔；
2.前端開發和後端開發進行前後端聯調，結束後後端開發人員提測接口；
3.測試人員進行接口測試；
4.進行驗收測試；
5.利用持續內建技術進行持續的校驗。
進行接口測試，你是如何進行去測試的？
1.通過性驗證：保證接口好使，能正常傳入且傳回正确的結果；
參數組合：有必傳項時檢查必傳項；
接口安全：①繞過驗證（比如商品價格不能被外部修改）②繞過身份授權（商品必須商家本人才能修改）③參數是否加密（使用者名密碼加密）④密碼複雜程度校驗
2.根據業務邏輯來設計用例
3.工具：postman和jmeter。一般用postman測接口，jmeter也能側，但一般不用。
舉例說一下你的接口測試是怎麼做的？
先看接口文檔，根據接口文檔進行測試，包含接口的URL，請求參數，響應結果。如果沒有接口文檔，就自己抓包。我們是用jmeter來做接口測試的，首先，要建立一個線程組，線上程組下面添加一個http請求，然後填寫好伺服器位址，接口路徑，請求方式，請求參數。如果需要參數化，先在本地建立一個TXT文檔，把參數填寫到文檔裡面，在jmeter中添加一個csv檔案設定，填寫好TXT文檔的路徑，然後在請求參數中使用json提取器把token值關聯出來，然後在下單接口中使用${參數名}的方式引用；接下來添加斷言，檢查伺服器傳回的結果和預期結果是不是一緻的。最後，添加檢視結果數檢視測試結果。
請描述下接口測試與UI測試是如何協同測試的？
1.有一部分是重疊的，UI測試是通過前端寫的界面，是來調用接口的，而接口測試是直接調用接口；
2.排除前端的處理邏輯與調用的正确性，在理論上接口測試是可以覆寫所有的UI測試，但實際中，如幾口層覆寫所有的業務流，在UI上隻測試前端的邏輯，而最終的結果會忽視很多原有的功能點，導緻了UI測試的不充分，那麼會存在人多分工且實踐充分的時候可以嘗試接口去做業務流的全覆寫，否則不要輕易地去嘗試。
為什麼要進行抓包？
1.有些公司沒有标準的接口文檔，隻能通過抓包擷取接口資訊；
2.通過抓包可以檢視整個請求過程以及相應過程，進而分辨是前台bug還是背景bug；
3.可以檢視是否有敏感資訊洩漏；
4.抓包進行測試，攔截請求，修改請求資料，檢視響應結果本來就是接口測試的一部分。
一般抓包用什麼工具，怎麼進行抓包？
Charles。
在工具設定http代理，設定端口号，在手機上設定同一網段，設定代理IP，設定代理端口，手機上的請求就可以抓取到了。
可以設定過濾，找到自己域名下的請求，通過分析請求位址，請求參數，響應結果來查找問題。
https，下載下傳證書就可以抓取到請求了。
jmeter
jmeter是如何進行測試的？/ 請您介紹一下jmeter是如何使用的？
1.打開jmeter；
2.建立線程組；
3.設定線程數和循環次數；
4.配置元件；
5.配置我們需要進行測試的程式協定、位址和端口；
6.構造http請求；
7.添加http請求頭；
8.添加斷言；
9.添加檢視結果樹；
10.添加Summary Report；
11.執行測試計劃，執行測試計劃不能用GUI，需要用指令來執行；
12.web報告。
jmeter連接配接資料庫？
1.在jmeter的線程組中分别添加JDBC Connection ConfigConfiguration 、JDBC Request 、 Debug Sampler 、 檢視結果數。
2.在測試計劃中将連接配接mysql需要的包加到classpath中。
3.在JDBC Connection Configuration 中添加JDBC的配置。
jmeter為什麼要參數化？
做壓力測試時，我們經常需要替換參數，在jmeter中，有多種參數化的形式。可以在測試計劃中設定全局參數，可以設定使用者參數，還可以在前置處理器中設定使用者參數。在進行多線程并發的時候，如果需要多個參數，可以使用csv配置元件。比如做登入操作，背景有可能會限制一個使用者不能重複登入多次，如果示範登入的并發操作，可以使用jmeter中的csv元件，将使用者資訊導出來，放到檔案中，就可以讓線程共享這些資料。另外，對于一些随機變化的參數，可以使用jmeter中的函數助手，生成随機函數，進行參數化測試。比如注冊這樣的操作，使用者名要求唯一的，那就可以使用随機函數模拟出來。
jmeter如何進行壓力測試？
當測試接口的時候，發現某個接口性能比較差，需要進一步判定問題的時候，會壓測資料庫。壓測資料庫需要配置驅動，設定連接配接池大小，需要使用sql去操作資料庫。具體的哪條sql問題需要問開發要具體的sql進行壓測。
postman
postman與jmeter的差別是什麼？
1.用例組織不同：jmeter的組織是比較偏扁平，首先它沒有工作空間的概念，直接就是測試計劃，而postman功能上更簡單，組織方式是輕量級，他主要針對的是單個的http請求。
2.支援接口的類型與測試的類型不同：jmeter的功能更強大，可以通過各種類型的接口，不支援的頁可以通過網上或者自己編寫的插件進行擴充，而postman更輕量級，定位不同，可用來測試rest接口。
3.配置不同：jmeter可以線上程組裡添加http，tcp，而postman隻支援rest接口。
postman做哪些操作？
用它來做接口測試。
檢視接口的傳回結果；
檢視接口是get請求還是post請求；
MySQL
MySQL資料庫查詢語言有哪些？會多表聯查嗎？
資料庫語言最常用的是SQL
多表聯查：select * from table1 t1,table2 t2 where tl.id=t2.id
這樣就是多表聯查。
left join
right join
inner join
MySQL資料庫的增删改查？
增：
alter table 資料表名 add birthday datetime;
删：
alter table 表名 drop 列名;
改：
1.修改字段，不重命名，用modify
alter table 資料表名 modify birthday date;
2.修改字段，重命名，用change
alter table 表名 change 原名 新名 類型及限制
alter table 資料表名 change birthday birth date；
查：
查詢表使用資料 select * from 表名;
部分查詢 select * from 表名 where 條件;
可以使用as 為清單指定别名
select 字段 as 别名,字段 as 别名 from 資料表名 where…;
SQL内關聯和外關聯的差別？
内關聯是求交集
外關聯是以主表為标準，去附表找需要的資訊
Linux
Linux上能不能直接進行性能測試？
不能，腳本需要通過Windows調試好之後，才能在Linux上運作，運作的時候，隻能通過non GUL的形式進行啟動jmeter，但需要注意的是，csv檔案在Windows上與Linux上要統一路徑，最好使用相對路徑，放到統一目錄下邊。
Linux系統操作的指令說一下：增加，删除，複制，移動等問題？
cd:進入目錄
cd app：切換到app目錄
cd… ：切換到上一層目錄
cd/: 切換到系統根目錄
tail -10 a.txt :檢視後10行資料
ifconfig :檢視ip
ll:檢視檔案及其屬性
vi: 編輯
rm-rf: 删除
car:解壓及壓縮指令
cp:複制
pwd:顯示目前路徑
mv:移動
cat:檢視檔案内容
touch:建立檔案
tail logcat:檢視日志
cat logcat:檢視日志
tomcat：日志
tail ：檢視日志記錄資訊，tail -f catinalia out
Linux系統日志檢視指令，壓縮，解壓指令等問題？
tar -xvf 檔案名 :解壓
tar -n logcat 檢視系統日志
tar -zcvf 檔案名：壓縮
Linux系統TOP指令介紹？
顯示，管理執行中的程式，就是任務管理器
自動化測試
自動化測試有了解嗎？自動化測試的工具有哪些？
通過腳本代替一些手動化測試的步驟。unittest， web端：selenium ； app端：appium
selenium元素定位的方法有哪些？
find_element_by_id()（常用）
find_element_by_name()（常用）
find_element_by_class_name()
find_element_by_tag_name()
find_element_by_link_text()
find_element_by_partial_link_text()
find_element_by_xpath()（常用）
find_element_by_css_selector()
appium的工作原理是什麼？
我們的電腦（c端）上運作自動化測試腳本，調用的是appium的webdriver的接口，appium伺服器（s端）接收到我們client上發送過來的指令後，它會将這些指令轉換為UIautomator認識的指令，然後由UIautomator來在裝置上執行自動化。
安全性測試
安全性測試包括哪些方面？
1.使用者程式安全；
2.系統網絡安全；
3.資料庫安全。
用例題
寫好測試用例的關鍵 / 寫好用例要關注的次元？
1.覆寫使用者的需求；
2.從使用者使用場景觸發，考慮使用者的各種正常和異常的使用場景；
3.用例的顆粒大小要均勻。通常，一個測試用例對應一個場景；
4.用例各個要素要齊全，步驟應該足夠詳細，容易被其它測試工程師讀懂，并能順利執行；
5.做好用例評審，及時更新測試用例。
如果給你購物商城網頁（京東，淘寶等）你會怎樣測試？測試那些主要功能？
1.首先進行需求分析，用XMind梳理測試點，再編寫案例，之後就進行案例評審，尋求他人意見。之後再完善案例，發出來給其他人檢查。
2.測試點，首先是UI方面，美觀度和易操作性，易了解性方面進行測試。
3.然後再考慮其他功能點，注冊登入，添加購物車，下單，付款，發貨，确認收貨，評價等。
4.性能方面：打開網頁，确認訂單，付款的響應時間等等
5.相容性：支援各種主流浏覽器，IE，360，火狐，谷歌等
微信發紅包的測試用例？
功能：
1.在紅包錢數和紅包個數的輸入框中隻能輸入數字；
2.紅包最多和最少的輸入錢數 200,0.01；
3.拼手氣紅包最多可以發多少個紅包；
4.超過最大拼手氣紅包是否有提醒；
5.當紅包錢數超過最大範圍是否有提醒；
6.餘額不足時，紅包發送失敗，或者會不會比對切換支付方式；
7.紅包描述裡是否可以輸入表情、漢字、英文、數字等；
8.紅包描述裡最多有多少個字元；
9.發送的紅包别人是否能正常領取；
10.發送的紅包自己可不可以領取；
11.24小時後别人沒有領取的紅包是否可以退回原來的賬戶，或者是否還可以領取；
12.使用者是否可以多次搶一個紅包；
13.使用者在多人群裡發紅包是否可以搶自己的紅包；
14.紅包餘額裡的小位數是否有限制；
15.傳回鍵可以正常取消發紅包嗎；
16.斷網時是否可以搶紅包；
17.收發紅包界面是否有自己以前收發紅包的記錄，以及和自己實際收發紅包是否比對；
18.支付時密碼支付和指紋支付是否正常；
19.支付成功是否正常傳回聊天界面；
20.是否可以連續發紅包。
性能：
1.網絡環境差，發紅包的時間；
2.不同網速時，搶紅包的時間；
3.收發紅包後跳轉時間；
4.收發紅包的耗電量；
5.退款到賬的時間。
相容：
1.蘋果，安卓系統；
2.電腦端是否可以搶紅包；
3.不同品牌的手機是否正常使用。
界面：
1.發紅包界面有沒有錯别字；
2.搶完紅包界面有沒有錯别字；
3.收發紅包界面排版美觀合理；
4.界面顔色搭配好。
安全：
1.發送紅包領取紅包後對應相關的金額是否會變化；
2.發送失敗銀行卡或者餘額會不會變；
3.發送成功後是否會收到微信支付的通知。
易用：
1.支援指紋，人臉識别支付碼；
2.紅包描述可以通過語音輸入嗎。
最後： 下方這份完整的軟體測試視訊學習教程已經整理上傳完成，朋友們如果需要可以自行免費領取
【保證100%免費】
這些資料，對于【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴上萬個測試工程師們走過最艱難的路程，希望也能幫助到你!