1.?測試流程
開始測試前準備-->需求分析-->測試設計（測試計劃，測試用例）-->執(zhí)行測試--> 提交BUG-->測試總結。
2.?測試計劃的編寫要素
why——為什么要進行這些測試
what—測試哪些方面，不同階段的工作內容
when—測試不同階段的起止時間
where—相應文檔，缺陷的存放位置，測試環(huán)境等
who—項目有關人員組成，安排哪些測試人員進行測試
how—如何去做，使用哪些測試工具以及測試方法進行測試。
3.?測試原則
1.測試證明軟件存在缺陷??2.不可能執(zhí)行窮盡測試、??3.測試應盡早啟動、盡早介入??4.缺陷存在群集現象(二八定律)
5.殺蟲劑悖論??6.不同的測試活動依賴不同的測試背景??7.不存在缺陷的謬論
4.?測試方法
1、等價類劃分法??2、邊界值分析法??3、錯誤推測方法??4、因果圖法??5、判定表驅動分析方法??6、正交實驗設計方法
5.?測試分類
1、按開發(fā)階段：單元測試、集成測試、系統(tǒng)測試、驗收測試
2、按測試實施組織：α、β、第三方
3、按測試執(zhí)行方式：靜態(tài)測試、動態(tài)測試
4、按是否查看代碼：黑盒測試、白盒測試、灰盒測試
5、按是否手工執(zhí)行劃分：手工測試、自動化測試
6、按測試對象劃分：性能測試、安全測試、兼容性測試、文檔測試、易用性測試（用戶體驗測試）、業(yè)務測試、界面測試、安裝測試
7、按測試地域劃分：本地化測試、國際化測試
6.?測試模型
7.?開發(fā)流程
8.?黑盒和白盒的區(qū)別
黑盒測試：把測試對象當成一個黑盒子，測試人員完全不考慮邏輯結構和內部特性， 只依據程式的需求說明書
來檢查程式的功能是否滿足它的功能說明。
白盒測試：把測試對象當成一個透明的盒子，允許測試人員利用程序內部邏輯結構及 相關信息，設計或選擇測
試用例，對程式所有邏輯路徑進行測試。
9.?測試計劃中有哪些
1. 概述?1.1 編寫目的? 1.2 項目背景? ?1.3 項目質量目標? 1.4 預期讀者? 1.5 參考資料
2. 測試環(huán)境? 2.1 系統(tǒng)架構? 2.2 軟硬件環(huán)境要求? ?2.3 測試環(huán)境部署圖
3. 測試規(guī)劃? 3.1 測試范圍? 3.2 測試工具? ?3.3 人員、角色及職責
4. 測試策略? 4.1 系統(tǒng)框測試? 4.2 業(yè)務流程測試? 4.3 功能點測試? 4.4 UI界面測試? 4.5 性能測試? 4.6 兼容性測試? 4.7 安全測試
5. 測試進度安排
6. 工作匯報
10.?測試用例包含哪些
項目名稱,軟件版本,測試環(huán)境,設計人,最新更新日期
序號,模塊,子模塊,用例分類,用例標題,前提條件,操作步驟(輸入值),期望結果,實際結果,備注,更新日期,用例級別,評審人
11.?測試用例需要詳細到什么程度才是合格的
首先根據需求文檔，概要設計，測試計劃，測試方案細分出功能模塊的測試項，再根據各種測試項，概要設計，詳細設計以及測試方案中測試的覆蓋率細分出測試子項，最后根據測試用例的設計方案來寫測試方法
12.?缺陷報告包含哪些
（1）摘要：也就是缺陷的概要描述，要求簡潔清晰；
（2）測試環(huán)境和測試數據信息，如果缺陷在特定的環(huán)境比如操作系統(tǒng)，瀏覽器才發(fā)生，或者使用特定的測試數據才發(fā)生，需要提供這些信息；
（3）測試步驟，重現這個缺陷的步驟
（4）預期結果，執(zhí)行這些操作步驟時，系統(tǒng)預期的表現；
（5）實際結果，執(zhí)行這些操作步驟時，系統(tǒng)實際的表現；
（6）可添加附件，如屏幕截圖
13.?測試評審：（評審分類 ?評審內容 ?評審結束）
1、評審分類
測試組內部的評審：測試部門成員參與
項目組內部的評審：項目經理、產品人員、開發(fā)人員和測試人員參與
2、評審內容
用例設計的結構安排是否清晰、合理，是否利于高效對需求進行覆蓋。
優(yōu)先級安排是否合理。
是否覆蓋測試需求上的所有功能點
用例是否具有很好可執(zhí)行性。例如用例的前提條件、執(zhí)行步驟、輸入數據和期待結果是否清晰、正確；期待結果是否有明顯的驗證方法
是否已經刪除了冗余的用例
是否包含充分的負面測試用例。充分的定義，如果在這里使用2&8法則，那就是4倍于正面用例的量，畢竟一個健壯的軟件，其中80%的代碼都是在“保護”20%的功能實現
是否從用戶層面來設計用戶使用場景和使用流程的測試用例
是否簡潔，復用性強。例如，可將重復度高的步驟或過程抽取出來定義為一些可復用標準步驟。
3、評審結束標準
1）評審過程中收集相關人員的反饋信息（即問題記錄清單），并在此基礎上進行測試用例更新，直到評審通過；
附：測試用例評審檢查項：
1）測試用例是否按照公司定義的模板進行編寫的；
2）測試用例的本身的描述是否清晰，是否存在二義性；
3）測試用例內容是否正確，是否與需求目標相一致；
4）測試用例的期望結果是否確定、唯一的；
5）操作步驟應與描述是否相一致；
6）測試用例是否覆蓋了所有的需求；
7）測試設計是否存在冗余性；
8）測試用例是否具有可執(zhí)行性；
9）是否從用戶層面來設計用戶使用場景和業(yè)務流程的測試用例；
10）場景測試用例是否覆蓋最復雜的業(yè)務流程；
11）用例設計是否包含了正面、反面的用例；
12）對于由系統(tǒng)自動生成的輸出項是否注明了生成規(guī)則；
13）測試用例應包含對中間和后臺數據的檢查；
14）測試用例應有正確的名稱和編號；
15）測試用例應標注有執(zhí)行的優(yōu)先級；
16）測試用例包含相關的配置信息：測試環(huán)境、數據、前置測試用例、用戶權限等；
17）每個測試用例步驟應<=15 Step。
14.?水杯 ?電梯 朋友圈點贊 ?視頻播放 ?支付的測試用例的設計點有哪些
詳情請看：http://www.lxweimin.com/p/8f4ae0498fbc
15.?測試發(fā)現bug開發(fā)不認為是bug的時候
1、將問題提交到缺陷管理庫里面進行備案。
2、要獲取判斷的依據和標準：
根據需求說明書、產品說明、設計文檔等，確認實際結果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據；
如果沒有文檔依據，可以根據類似軟件的一般特性來說明是否存在不一致的地方，來確認是否是缺陷；
根據用戶的一般使用習慣，來確認是否是缺陷；
3、與設計人員、開發(fā)人員和客戶代表等相關人員探討，確認是否是缺陷；
4、合理的論述，向測試經理說明自己的判斷的理由，注意客觀、嚴謹，不參雜個人情緒。
等待測試經理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反映，并有上級做出決定。
16.?Linux命令?
shutdown -h now 關閉系統(tǒng)? ?init 0 關閉系統(tǒng)? ?telinit 0 關閉系統(tǒng)? ?shutdown -h hours:minutes & 按預定時間關閉系統(tǒng)?
shutdown -c 取消按預定時間關閉系統(tǒng)? ?shutdown -r now 重啟? reboot 重啟? logout 注銷?
文件和目錄?
cd /home 進入 '/ home' 目錄'? ?cd .. 返回上一級目錄? ?cd ../.. 返回上兩級目錄? ?cd 進入個人的主目錄? ?cd ~user1 進入個人的主目錄?
cd - 返回上次所在的目錄? ?pwd 顯示工作路徑? ?ls 查看目錄中的文件? ?ls -F 查看目錄中的文件? ?ls -l 顯示文件和目錄的詳細資料?
ls -a 顯示隱藏文件? ?ls *[0-9]* 顯示包含數字的文件名和目錄名? ?tree 顯示文件和目錄由根目錄開始的樹形結構
lstree 顯示文件和目錄由根目錄開始的樹形結構? mkdir dir1 創(chuàng)建一個叫做 'dir1' 的目錄'? ?mkdir dir1 dir2 同時創(chuàng)建兩個目錄?
mkdir -p /tmp/dir1/dir2 創(chuàng)建一個目錄樹? ?rm -f file1 刪除一個叫做 'file1' 的文件'? ?rmdir dir1 刪除一個叫做 'dir1' 的目錄'?
rm -rf dir1 刪除一個叫做 'dir1' 的目錄并同時刪除其內容? ?rm -rf dir1 dir2 同時刪除兩個目錄及它們的內容?
mv dir1 new_dir 重命名/移動 一個目錄? ?cp file1 file2 復制一個文件? ?cp dir/* . 復制一個目錄下的所有文件到當前工作目錄?
cp -a /tmp/dir1 . 復制一個目錄到當前工作目錄? ?cp -a dir1 dir2 復制一個目錄? ?cp -r?dir1 dir2 復制一個目錄及子目錄
ln -s file1 lnk1 創(chuàng)建一個指向文件或目錄的軟鏈接? ?ln file1 lnk1 創(chuàng)建一個指向文件或目錄的物理鏈接? touch -t 0712250000 file1 修改一個文件或目錄的時間戳 - (YYMMDDhhmm)?
file file1 outputs the mime type of the file as text? ?iconv -l 列出已知的編碼?
17.?Adb命令? ? 查看日志 ?（日志級別）
adb root? 獲取 root 權限。? adb sideload? adb shell ps 打印進程狀態(tài)。
adb shell top 展現上層 CPU 進程信息。? adb shell getprop 獲取 Android 系統(tǒng)服務屬性
adb shell setprop 設置服務屬性。? adb shell dumpsys? 獲取系統(tǒng)數據。
adb logcat? 打印日志文件? adb shell ip? 主要用于顯示一些數據
adb shell netstat 主要用于網絡統(tǒng)計。? adb shell ping 沒啥好說的，和 PC 的 ping 命令一樣的。
adb shell netcfg 通過配置文件配置和管理網絡連接。? adb shell cp 字面意思，很好理解，復制。
adb shell pwd 定位當前的操作位置? adb shell mv 移動或者更名文件
adb shell mkdir 創(chuàng)建一個文件夾? adb shell rm 刪除文件或者目錄
adb shell ls 列出目錄內容。? adb shell pm clear 清除應用緩存。
adb shell pm path 打印 apk 的路徑。? adb usb 設置設備以 USB 形式連接 PC
adb kill-server 終止 adb 進程。? adb forward 端口映射，將 PC 端的某端口數據重定向到手機端的一個端口。
adb devices 主要是用于打印當前連接的所有模擬器或者設備
18.?Monkey命令 ?和日志區(qū)別
adb? shell monkey -v 10 執(zhí)行monkey測試10次? adb?shell?monkey?-p 用此參數指定一個或多個包
adb?shell?monkey?100?>c:/log/b.txt? 將log信息寫到文檔中
adb?shell?monkey?-p?com.example.login?--throttle?300?100? 表示執(zhí)行100個偽隨機用戶事件流，事件間隔為300毫秒
--pct-touch? 觸摸事件? ?adb shell monkey -f? 后接測試腳本名
adb shell monkey -s? 隨機運行? ? adb shell monkey --throttle??固定時間間隔
19.?查看日志的前10行后5行的命令
# head -n 10 /etc/profile? ?# tail -n 5 /etc/profile
20.?Bug生命周期
提交缺陷：測試人員提交新的缺陷，并對該缺陷進行描述，分級。操作，預期結果。
分派缺陷：開發(fā)人員打開缺陷，但是該模塊并不是自身開發(fā)，可以將缺陷重現指派給對應模塊開發(fā)人員。
確認缺陷：開發(fā)人員根據缺陷描述進行重現，分析缺陷。確認是否為軟件缺陷。
不予解決：開發(fā)人員認為不是缺陷，標記為不予解決。指派給產品進行分析是否為缺陷。
處理缺陷：開發(fā)人員對缺陷進行處理，解決缺陷所出現的問題。
回歸缺陷：當缺陷被解決時，由測試人員對缺陷進行回歸測試，確認該缺陷被解決。
關閉缺陷：缺陷被解決，已進行回歸測試且結果為PASS。
21.?Bug的狀態(tài)和優(yōu)先級
嚴重等級：
第一級（blocker）: 引起喜歡作系統(tǒng)“掛起”或“崩潰”的錯誤；
第二級（critical）: 引起軟件本身“掛起”或“崩潰”的錯誤；
第三級（major）: 不能完成軟件說明書定義的功能的錯誤；
第四級（normal）: 程序所完成的功能與軟件說明書定義不符的錯誤；
第五級（minor） : 顯示方面的錯誤；
第六級（trivial） : 其它“輕微”的錯誤（如文本差錯）；
第七級（enhancement）：增強或者改進。
優(yōu)先級：
1.立即解決（Resolve Immediately）缺陷必須被立即解決。
2.正常排隊（Normal Queue）缺陷需要正常排隊等待修復或列入軟件發(fā)布清單。
3.不緊急（Not Urgent）缺陷可以在方便時被糾正。
22.?Bug的分類
1、代碼錯誤??2、設計缺陷? 3、界面優(yōu)化? 4、性能問題? 5、配置相關
6、安裝部署? 7、安全相關? 8、標準規(guī)范? 9、測試腳本
10、其他劃分：功能類、界面類、性能類、易用性類、兼容性類、其他
23.?Chareles的弱網測試
上方工具欄的代理—限流設置—啟用限流
24.?Chareles的斷點替換（request response）
1.選擇你要設置的斷點接口??2.右擊接口，選擇斷點? 3.點擊代理->斷點設置
4.雙擊鏈接，進行配置? 5.把參數刪掉，換成*，可修改請求可修改返回
6.修改我們需要的數據，修改完成后點擊執(zhí)行即可
25.?chareles的對app端抓包的步驟
設置代理
（1）查看默認端口：Proxy->Proxy Settings ?在這個頁面會看到HTTP Proxy的默認端口是8888
（2）查看當前電腦的IP：Help->Local IP Address，在這個頁面會看到本機IP
（3）手機上設置代理（記住手機跟電腦要在同一個網絡）
手機連接到Charles時會彈出提示框是否連接，點擊Allow允許即可
完成后就可以看到已經能抓到http請求的數據了
26.?Jmeter的接口測試
1測試計劃中添加線程租?
2在線程租中添加http請求?在http請求中需要填入?
3在線程中添加查看結果樹
27.?Jmeter的壓力測試 打壓 1000
1測試計劃中添加線程租?
2在線程租中添加http請求?在http請求中需要填入?
3. 在線程租中進行修改?并發(fā)數量?（修改線程數量?修改循環(huán)次數?）
4.在線程組添加聚合報告
28.?Web端的性能指標
響應時間（客戶端向服務端的請求時間，服務端對數據庫的請求時間，服務端將結果展現到頁面的時間）
響應時間2?5?8原則???
吞吐量：指的是在一次性能測試過程中網絡上傳輸的數據量的總和.吞吐量/傳輸時間,就是吞吐率.
TPS：每秒處理事務能力
并發(fā)數： 單用戶的多次操作
多用戶的單次操作
點擊率:每秒鐘用戶向WEB服務器提?交的HTTP請求數.
資源使用率：cpu??<80%??內存??<80%??io?<40????網絡?<30%
29.?App端的性能指標
Cpu內存??流量??電量?啟動時間??幀率? ? ?cpu??<80%內存??<80%?
電量的損耗：? ? 流量的損耗：
30.?Jmeter的負載測試
1測試計劃中添加線程租?
2在線程租中添加http請求?在http請求中需要填入?
3. 在線程租中進行修改?并發(fā)數量?（修改線程數量?修改循環(huán)次數?）
4.在線程組添加聚合報告
31.?Jmeter的腳本錄制（web /app）
通過Badboy來錄制腳本（pc）
1.打開badboy ,點擊紅色按鈕，在地址欄輸入被測項目地址。
錄制完后，點擊旁邊的黑色按鈕結束錄制。
2.選擇文件，Export to Jmeter 保存.jmx類型文件
3.打開Jmter,打開“文件”->‘打開’選擇剛保存的.jmx類型文件。
1.打開jmeter，創(chuàng)建一個線程（移動端）
2.添加代理服務器，點擊 “工作臺”，然后右鍵，根據如下圖步驟，添加一個代理服務器。
3.設置端口以及錄制地址? ??4.通過模擬機配置端口號就可以完成鏈接
32.?TPS和qps區(qū)別
tps可以理解為是每秒對事務的處理的能力??qps是每秒對服務器的查詢能力
性能測試web端和app端測試
33.?負載和壓力區(qū)別
負載測試是從并發(fā)量維度出發(fā)，不斷增加并發(fā)量的情況下，系統(tǒng)的性能指標；
壓力測試是從訪問時間維度出發(fā)，在并發(fā)量一定的情況下，不斷增加連續(xù)訪問的時間，系統(tǒng)的性能指標；
34.?Mysql的 inner join ?left join right join ?full join ?區(qū)別
左連接:LEFT JOIN? ?左連接：表emp是主表，因此查詢結果是顯示emp（主表）的全部信息和sal（附表）與emp相關的信息。
右連接:RIGHT JOIN? ?右連接：表sal是主表，因此查詢結果顯示sal（主表）的全部信息和emp(附表)與sal想關的信息。
內連接:INNER JOIN? ?內連接：顯示的是連個表相關的信息
全連接:FULL JOIN??全連接：顯示兩個表所有的信息。
35.?MySQL的數據庫優(yōu)化
1.優(yōu)化索引、SQL 語句、分析慢查詢；
2.設計表的時候嚴格根據數據庫的設計范式來設計數據庫；
3.使用緩存，把經常訪問到的數據而且不需要經常變化的數據放在緩存中，能節(jié)約磁盤 IO
4.優(yōu)化硬件；采用 SSD，使用磁盤隊列技術(RAID0,RAID1,RDID5)等
5.采用 MySQL 內部自帶的表分區(qū)技術，把數據分層不同的文件，能夠提高磁盤的讀取效率；
6.垂直分表；把一些不經常讀的數據放在一張表里，節(jié)約磁盤 I/O；
7.主從分離讀寫；采用主從復制把數據庫的讀操作和寫入操作分離開來；
8.分庫分表分機器（數據量特別大），主要的的原理就是數據路由；
9.選擇合適的表引擎，參數上的優(yōu)化
10.進行架構級別的緩存，靜態(tài)化和分布式；
11.不采用全文索引；
12.采用更快的存儲方式，例如 NoSQL 存儲經常訪問的數據。
36.?Mysql的存儲原理
1、存儲過程能實現較快的執(zhí)行速度
2、存儲過程允許標準組件是編程。
3、存儲過程可以用流程控制語句編寫，有很強的靈活性，可以完成復雜的判斷和較復雜的運算。
4、存儲過程可被作為一種安全機制來充分利用。
5、存儲過程能夠減少網絡流量
37.?編寫http接口的性能測試，和測試過程中的關注點 流程
性能測試流程
1.業(yè)務知識理解
2.工具的選擇（jmeter）
3.設計性能測試場景（由需求或測試經理設計）
3.指定測試方案并評審
4.性能測試環(huán)境準備（注：獨立于功能測試環(huán)境，使用局域網排除網絡影響）
5.編寫和調優(yōu)性能測試腳本(有接口測試文檔)//（無接口測試文檔：fiddle抓包、badboy、jmeter代理錄制---關聯(lián)（把上一個請求的結果送給下一個請求））
6.執(zhí)行性能測試，收集測試結果
7.分析測試結果-----系統(tǒng)的性能優(yōu)化
38.?http和https的區(qū)別
1、https協(xié)議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
2、http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議。
3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
4、http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構建的可進行加密傳輸、身份認證的網絡協(xié)議，比http協(xié)議安全。
39.?OSI和tcp/IP的區(qū)別
（1）OSI和TCP/IP的相同點是二者均采bai用層次結構du，而且都是按功能分層。
OSI和TCP/IP的不同點：
（1）.OSI分七層，自下而上分為物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層和應用層，而TCP/IP分四層：網絡接口層、網際層、傳輸層和應用層。
（2）.OSI先有模型，再有協(xié)議，比較適合理論上探討。TCP/IP先有協(xié)議，再有模型，已得到廣泛的實際應用。
40.?TCP 和UDP 的區(qū)別
1、連接方bai面區(qū)別
TCP面向連接（如du打電話要先撥號建立連接）。
UDP是無連接的zhi，即發(fā)送數據dao之前不需要建立連接。
2、安全方面的區(qū)別
TCP提供可靠的服務，通過TCP連接傳送的數據，無差錯，不丟失，不重復，且按序到達。
UDP盡最大努力交付，即不保證可靠交付。
3、傳輸效率的區(qū)別
TCP傳輸效率相對較低。
UDP傳輸效率高，適用于對高速傳輸和實時性有較高的通信或廣播通信。
4、連接對象數量的區(qū)別
TCP連接只能是點到點、一對一的。
UDP支持一對一，一對多，多對一和多對多的交互通信。
41.?Get/post的區(qū)別
“1.Get是不安全的，因為在傳輸過程，數據被放在請求的URL中；Post的所有操作對用戶來說都是不可見的。2.Get傳送的數據量較小，這主要是因為受URL長度限制；Post傳送的數據量較大，一般被默認為不受限制。
1、GET使用URL或Cookie傳參。而POST將數據放在BODY中。
2、GET的URL會有長度上的限制，2kb，則POST的數據則可以非常大。
3、POST比GET安全，因為數據在地址欄上不可見。
4、一般get請求用來獲取數據，post請求用來發(fā)送數據。
42.?Web測試和app測試的區(qū)別
43.?給你一個網站你如何張開測試
性能測試
（1）連dao接速度測dao試：用戶連接到電子商務網版的速度與上權網方式有關，他們或許是電話撥號，或是寬帶上網，打開速度越快的網站，越受用戶喜愛。
（2）負載測試：負載測試是在某一負載級別下，檢測電子商務系統(tǒng)的實際性能。允許多少個用戶同時在線，可以通過相應的軟件在一臺客戶機上模擬多個用戶來測試負載。
（3）壓力測試：壓力測試是測試系統(tǒng)的限制和故障恢復能力，也就是測試電子商務系統(tǒng)會不會崩潰。
安全性測試
對網站的安全性（服務器安全，腳本安全）可能有的漏洞測試，攻擊性測試，錯誤性測試。對電子商務的客戶服務器應用程序、數據、服務器、網絡、防火墻等進行測試。用相對應的軟件進行測試。
基本測試
包括色彩的搭配，連接的正確性，導航的方便和正確，CSS應用的統(tǒng)一性。
網站優(yōu)化測試
（1）引擎優(yōu)化測試：好的網站是看它是否經過搜索引擎優(yōu)化了，網站的架構、網頁的欄目與靜態(tài)情況等。
（2）用戶優(yōu)化測試：用戶來到網站能能夠在3-5次，找到其需要的內容。方便用戶的網站倍受用戶的親昵。
功能實現：網站現有版本，需求是否完全實現。滿足需求的網站才是有用的網站。
44.?支付模塊的測試如何展開
1、單元測試要寫好
2、自己真實支付測試
3、接口自動化測試，由于要真實支付只能發(fā)起預支付，但不能付款。（測試環(huán)境可以自己寫套假支付回調接口來改變支付結果來方便接口自動化測試）
