測試基礎知識篇
一、app測試相關
1、android與ios的app測試的區別：
1）Android長按home鍵呼出應用列表和切換應用，然後右滑則終止應用；
2）多分辨率測試，Android端20多種，ios較少；
3）手機操作系統，Android較多，ios較少且不能降級，只能單向升級，新的ios系統中的資源庫不能完全兼容低版本中的ios系統中的應用，低版本ios系統中的應用調用了新的資源庫，會直接導致閃退；
4）操作習慣：測試Android，Back鍵是否被重寫，測試點擊Back鍵後的反饋是否正確，應用數據從內存移動到SD卡後能否正常運行等；
5）push測試：Android，點擊home鍵，程序後臺運行時，此時接收到push，點擊後喚醒應用，此時是否可以正確跳轉，ios，點擊home鍵關閉程序和屏幕鎖屏的情況；
6）安裝卸載測試：Android的下載和安裝的平臺和工具和渠道比較多，ios主要有appstore，iTunes和testflight下載。
2、app測試和web測試的重點：
app測試：
1）安裝卸載測試；2）運行測試；3）更新測試；4）兼容測試；5）弱網環境測試；6）中斷衝突測試（app運行時撥打電話或者接電話、發信息、接收郵件、啓動相機等有和提示；app運行是突然斷網、斷電、不斷點擊、不斷刷新、切換前後臺是否崩潰（變態測試））
7）壓力測試（安裝用monkey，不斷點擊、滑動屏幕，看軟件是否崩潰）
8）應用的前後臺切換；9）消息推送開關測試；10）跨app跳轉/分享
web測試：
1）功能測試；2）界面測試；3）鏈接測試；4）性能測試；5）兼容性測試；6）安全性測試
3、性能測試考量的指標：
系統指標：用戶場景/需求直接體現
1）併發用戶數；2）響應時間；3）事務成功率；4）超時錯誤率；
資源指標：硬件資源消耗
1）CPU中央處理器；2）內存；3）I/O；4）帶寬；
4、app的性能測試，需要重點關注哪些方面？
1）內存；2）CPU；3）流量；4）電量；5）啓動速度
6）滑動速度、界面切換速度；7）與服務器交互的網絡速度
APP性能測試要點：一般性能測試、負載測試、壓力測試、穩定性測試
①性能測試：
1.資源消耗：
cpu的佔用、內存的佔用、流量的耗用、電量的耗用
2.響應能力測試：
App安裝、卸載的響應時間，啓動消耗時間的測試（熱啓、冷啓），頁面加載時間的測試
3.負載測試：
進行負載測試是否有異常
4.壓力測試：
進行壓力測試是否有異常，進行壓力測試看APP能承受的最大性能指標
5.穩定性測試：
穩定性測試的時候常會用monkey進行。主要通過monkey的僞隨機事件流進行大量的點擊、滑動等操作，這是爲了檢測出產品中隱藏的crash、anr等缺陷，確保沒有問題。
②壓力測試與負載測試兩者區別
• 相同點：
都是性能測試
• 不同點：
1.負載測試強調系統正常工作情況下的性能指標
2.壓力測試的目的是發現在什麼條件下系統的性能變得不可接受，發現應用程序性能下降的拐點。
5、站在測試工程師角度考慮app測試
(1)、連接超時
這個是App關閉的首要問題，而在移動應用中網絡錯誤數據比例報錯中最高的就是連接超時錯誤。
(2)、崩潰
APP的崩潰，就是用戶的崩潰。當用戶使用你的App出現閃退或崩潰時，他們很有可能跑去App Store贈送你一個“一星”差評。
(3)、系統交互（電話短信干擾，低電量提醒，push提醒，usb數據線插拔提醒，充電提醒等）
在APP使用過程中，可能會遇到各種中斷場景，那麼一旦發生這些場景，APP就卡死或者閃退，想必也沒有多少用戶願意持續使用你的APP。
(4)、弱網下的運行情況
電梯裏、地鐵上，網絡信號差時，APP頁面的菊花轉不停，界面卡死，同時錯誤提示一堆，這樣的情況怎能不讓用戶抓狂。
(5) 、CPU使用問題
CPU頻率設置過高時會導致過熱,過熱導致耗電更嚴重, CPU頻率設置過低導致手機滯後,應用處理緩慢同樣會導致耗電。更多時候，用戶解決CPU超載問題只能關閉甚至卸載App，App就被Kill了!
6、app直播/視頻播放測試
1）視頻播放的狀況十分依賴於網絡環境，所以在不同的網絡環境（WIFI、2G、3G、4G、弱網、無網絡）下都需要測試視頻在客戶端運行的效果。針對不同網絡的模擬，我們選用的是測試網絡延遲和丟包工具Network-Emulator-Toolkit-x64。
2）測試時除常規需要驗證項：播放模式（橫屏、豎屏、橫屏豎屏切換），播放制式（WIFI、2G、3G、4G），播放鍵位（返回、關閉、播放/暫停、最大化/最小化、音量），播放機制（首次進入、開始播放、暫停播放、繼續播放、連續播放）等，還需設計一套測試異常類的用例集。
二、測試基礎知識
7、敏捷開發DevOps建設流程
通過對容器雲方案和微服務架構的整體考慮，DevOps分成以下過程
持續集成：開發人員研發的代碼向軟件整體部分交付，頻繁進行集成以便快速發現問題。
持續交付：在已完成集成的代碼上面將完成測試的代碼部署到“類生產環境”中。
持續部署：已交付的代碼在通過評審之後，自動部署到生產環境中。
持續監控：通過專業的監控軟件（如Prometheus等），按事先設置的監控策略，監控業務應用以及系統平臺的運行情況，形成監控報告和監控展示。
持續反饋：基於監控的結果作數據分析，提供建議方案，如針對應用的監控，實現應用的彈性伸縮等能力。
持續改進：基於反饋的意見，啓動新的改進計劃流程。
8、小程序測試的重點：
(1)、測試環境搭建
微信Web開發者工具安裝、授權測試用的微信號可預覽和調試小程序
(2)、測試範圍
1.權限測試
需要檢查以下幾種情況下微信用戶訪問的權限
1）未授權微信登錄小程序
未授權時，一般使用一些業務功能的時候，都會彈出提醒：先授權再操作對應功能。or在提交數據到後臺的時候，會提示補充相關身份信息才能提交成功
2）已授權微信登錄小程序
授權微信訪問小程序，意味着自己的微信賬號可被小程序管理方所獲取，自動以微信的身份行使業務操作權限，比如諮詢、支付、數據查詢等
3）同一微信號在不同手機端登錄授權查看數據權限
同一微信號在不同手機微信端授權登錄同一小程序之後，所能查看的數據和操作的權限都應該是同步一致的
2.功能測試
1）按功能模塊測試
根據設計好的各個大類功能模塊劃分，然後再逐級細化，覆蓋到每個功能儘可能全面的測試點
2）按業務流程測試
小程序的業務，比如諮詢、支付、播放、查詢、下載。把各個功能點串聯起來形成完整的業務流程來檢查；同一個業務，可能有不能的路徑來實現，每個路徑都需要覆蓋檢查
3）按數據流向測試
根據數據從某一端操作輸入和輸出流向，設計基於數據流的測試用例，輸出的數據也可能成爲另外一端的輸入，檢查輸入的數據是否按照代碼邏輯執行正確的輸出，是否數據發生異常（無法輸入；有輸入卻無任何輸出；輸出不正確；多餘的輸出其他信息…）
4）同一功能不同的入口有效性的檢查
小程序中在首頁、列表頁、詳細頁、其他的業務功能相關頁面，都有可能存在同一個功能的入口，如付費諮詢、免費諮詢業務中，可以直接從首頁進入付費諮詢入口，也可以通過免費諮詢入口再切換到付費諮詢入口。每一個入口路徑都需要覆蓋檢查
5）交互性檢查
一般而言，產生數據和功能交互變化的情況主要有這幾個分類：前臺<–>前臺、後臺<–>後臺、前臺<–>後臺。前臺從A1頁面提交的數據，可能需要在前臺A2頁面查看到，也會在對應後臺的B頁面查到記錄；後臺B1頁面修改or添加的數據，對應到前臺的A頁面產生交互變化，後臺本身的不同頁面之間也可能存在同一個數據的輸出值
3.版本配置測試
有時候小程序一次性做了幾套不相同的模板，在前端程序代碼中修改配置參數，保存後重新編譯，即可從一個版本切換到另一版本，同時也需要在管理後臺作相應的切換，以保證前端進行數據調用
對於非公用的部分：不同版本直接的切換，需要保證彼此的功能模塊和數據獨立性不受干擾影響，即不同版本的管理後臺所添加的數據只應該調用到各自對應模板的前臺小程序中，不同版本的小程序從前臺提交的數據也只會提交到各自管理後臺，不應該有交差重疊
對於公用的部分：切換不同的模板，都會顯示相同的內容
4.兼容性測試
1）手機操作系統
常規的手機端OS爲：Android（7.x/6.x/4.x/2.x…）、IOS（11.x/10.x/9.x…）
2）微信版本
對於已上線的小程序，有可能會因爲微信版本升級之後導致對部分小程序的組件支持產生衝突，手機端微信上查看的小程序頁面出現樣式有異常，比如出現少部分區域的黑屏，這種情況需要同步在小程序的程序包中修改一些組件再次更新
5.易用性測試
1）導航
定位到頁面某個模塊所在位置，回到頂部or底部，導航條的收展，導航標籤的文字是否容易理解
2）功能入口
重要且常用業務的功能入口，是否在比較顯眼的位置，業務操作過程是否便於大多數用戶使用和查看
3）上下層級進入&返回
首頁<–>列表頁、列表頁<–>詳細頁 、首頁<–>詳細頁。不同層級之間的進入和返回實現是否有相應按鍵易操作
4）字體、圖片、動態交互效果
字體：標籤、標題、內容、動態播放字體…
圖片：輪播圖、背景圖、封面圖、觸屏產生的交互圖…
9、設計測試用例的方法（黑盒測試）：
1）等價類劃分法；
2）邊界值分析法；
3）因果圖法；4）功能分析法；5)場景設計法；6）錯誤推斷法；
7）決策表 8）正交實驗法
10、開展性能測試工作，前提準備包括哪些內容？
1）性能測試的需求分析：客戶需求、新系統性能嚴重、舊系統擴容、優化系統瓶頸等
2）性能測試工具的選型：商業loadrunner，開源工具Jmeter、Locust或自主研發
3）性能測試環境準備：軟件環境、測試環境、網絡環境
4）性能測試業務分析：針對哪些業務做性能測試（穩定的測試點、變動較少的頁面）
5）性能測試數據準備：準備基
礎數據
6）性能測試執行策略：不同業務的用戶分配比例、運行時長、思考時間 、集合點的設置等。
7）性能測試監控：中間件的監控、數據庫服務器的監控、系統服務器的監控。
8）性能測試分析與調優：分析整個系統哥哥部分的監控結果；對程序處理過程優化，程序算法優化，中間件各個部分配置參數的調整，數據庫SQL語句、索引、表結構的優化。
11、自動化方案，一般怎麼做？
自動化測試要引入的話，首先要系統或者平臺的功能達到基本穩定後才能開始，那首先要規劃定位主要做哪些功能的自動化纔有意義？是爲了後續更新保證以前的功能不受影響，更新後正常使用。按照我們平臺的話，就是那些最基本的功能，比如登錄功能，搜索功能，下單流程。這幾個功能使用頻率最高，所以對於電商平臺，首先做自動化的就是針對這些基礎功能開展。
三、計算機基礎知識
12、https和http的區別如下：
HTTP的全稱是Hypertext Transfer Protocol Vertion （超文本傳輸協議），說通俗點就是用網絡鏈接傳輸文本信息的協議； HTTPS（Secure Hypertext Transfer Protocol）安HTTP全超文本傳輸協議。
1）https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
2）http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議。
3）http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，後者是443。
4）http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。
13、響應狀態碼對應說明
200 OK：請求成功。一般用與GET與POST請求。
302 Fund：請求重定向。臨時移動，資源知識六十被移動，客戶端應繼續使用原有URL
304 ：請求資源沒有改變，訪問本地緩存。
400 Bad Request：客戶端請求有語法錯誤，不能被服務器所理解。
401 Unauthorized：請求要求用戶的身份認證。
403 Forbidden：服務器理解客戶端的請求，但是拒絕執行此請求。
404 Not found：請求資源不存在。通常是用戶路徑編寫錯誤，也可能是服務器資源已刪除。
500 Server Unavailable：服務器內部錯誤。通常程序拋異常。
狀態信息：狀態信息是根據狀態碼變化而變化的
14、cookies和session的認識
Cookie和session區別：
1.cookie數據是存在客戶瀏覽器上，session數據存放在服務器上。
2.Cookie不是很安全，別人可以分析存放在本地的cookie並進行cookie欺騙(使用用戶的cookies獲取相關信息。)
3.Session比較安全，會存放在一定時間內保存在服務器上。當訪問增多，會比較佔用服務器的性能
4.單個cookie保存的數據不能超過4k， 很多瀏覽器都限制一個站點最多保存20個cookie。
Cookie session的利弊：
帶上cookie、session的好處：很多網站必須登錄之後(或者獲取某種權限之後)才能夠請求到相關數據。
帶上cookie、session的弊端：一套cookie、session往往和一個用戶對應。
請求太快，請求次數太多，容易被服務器識別爲爬蟲。從而是賬號受到損害
使用建議：
1.不需要cookie的時候儘量不需要使用cookie
2.爲獲取登錄之後的頁面，我們必須發送帶有cookie的請求，此時爲了確保賬號安全應該儘量降低數據採集速度。
15、TCP和UDP、IP的區別：
1）進程/應用程協議
常見協議有：Telnet、FTP、SMTP、HTTP、DNS等。由客程序和服務程序兩部分組成，程序通過服務器與客戶機交互。
2）主機—主機層協議
建立並且維護連接，用於保證主機間數據傳輸的安全性。這一層主要有兩個協議：
TCP（Transmission Control Protocol：傳輸控制協議；面向連接，可靠傳輸
UDP（User Datagram Protocol）：用戶數據包協議；面向無連接，不可靠傳輸
3）Internet層協議
負責數據的傳輸，在不同網絡和系統間尋找路由，分段和重組數據報文，另外還有設備尋址。些層包括如下協議：
IP（Internet Protocol）:Internet協議，負責TCP/IP主機間提供數據報服務，進行數據封裝併產生協議頭，TCP與UDP協議的基礎。
ICMP（Internet Control Message Protocol）：Internet控制報文協議。ICMP協議其實是IP協議的的附屬協議，IP協議用它來與其它主機或路由器交換錯誤報文和其它的一些網絡情況，在ICMP包中攜帶了控制信息和故障恢復信息。
ARP（Address Resolution Protocol）協議：地址解析協議。
RARP（Reverse Address Resolution Protocol）：逆向地址解析協議。
16、tcp怎麼保證可靠傳輸
TCP協議保證傳輸可靠的方法主要有：校驗和，序列號，確認應答，超時重傳，連接管理，流量控制，擁塞控制。
17、TCP這麼好爲什麼還要UDP
1.先說一下TCP的優缺點吧。優點呢，TCP是可靠的連接，由於有基本的重傳確認機制，可以保證把一個數據塊完完整整的從A傳到B；缺點也是因優點而生，因爲有三次握手，所以會傳輸更多的包，浪費一些帶寬；因爲需要可靠地連接進行通信，則需要雙方都必須持續在線，所以在通信過程中server需要維持非常大的併發連接，浪費了系統資源，甚至會出現宕機；再者就是因爲有重傳確認，則會浪費一部分的帶寬，且在不好的網絡中，會因爲不斷地連接斷開連接，嚴重降低了傳輸效率。
2.相對於TCP來說，UDP是非面向連接的不可靠的協議，其優點也因爲缺點而生。首先，因爲沒有三次握手，所以會起步比較快，延時小；另外，由於不需要雙方持續在線，所以server不用維護巨量的併發連接，節省了系統資源；三，因爲沒有重傳確認，雖然到達的數據可能會有所缺失，但在不影響使用的情況下，能更高效的利用網絡帶寬。
基於前面的說法，總結一下本文的問題答案。TCP適合實時性要求不高，但要求內容要完整傳輸的應用。相比而言，UDP由於無連接、無重傳確認，所以傳輸效率高、延時小，適合實時性要求高的應用，如遊戲服務器，音頻，視頻等；另外，由於不用維持大的併發量，所以適合巨量服務的server，加上合適的時間控制，可以用來設計更大的併發服務器；再者就是，UDP可以更高效的利用網絡帶寬。