https://drive.wps.cn/view/l/stbv5rz
第一課項目<軟件>
一、 項目
a) 項目經理
b) 開發
c) 測試
d) 需求
e) 客戶
f) 產品經理
需求人員
開發人員 測試人員
（開發經理） （測試經理）
公司的部門:產品部、開發部、測試部、運維部、運營部
說明：產品經理負責---產品走向，需求來源
開發經理—開發技術
項目經理—對重大問題決策、溝通、協調進度、支付
a) 需求來自客戶
b) 客戶需求稱為原始需求
c) 客戶的需求一般比較模糊、簡單
d) 客戶的需求，需要提交給產品經理，由產品經理整理成完善的《軟件需求規格說明書》的文檔。
第2課 軟件需求規格說明書
軟件需求規格說明書
開發 測試
干嗎？
需求、開發、測試三方評審
形成一個標准，統一需求規格文檔
開發 測試
根據需求文檔編寫 根據需求文檔和項目設計計划編寫測試計划
形成人員需要把需求文檔
轉化成開發人員自己看的
懂的文字 根據需求文檔編寫測試的用例
a) 概要設計文檔 測試用例評審
b) 詳細設計文檔
編碼(寫程序) 程序
執行用例 BUG流程 測試報告 上線、發布
說明：
a) 測試工作在需求文檔一出來的時候就開始了。
b) 需求評審是我們測試人員非常重要的工作。
第3課、如何對軟件規格說明書進行評審
一般情況下，我們會以幾個方面進行評審、測試：
1、 正確性，對照客戶的原始需求，檢查我們的軟件需求功能是否描述正確。
2、 明確性，指的是軟件需求規格里面不能有含糊其辭的詞匯（例如、應該、也許等）。
3、 完整性，指的是有沒有遺漏客戶所描述的功能以及必要的信息。
4、 優先性，指的是那些功能比較重要，哪些功能比較次要，且要做一個標記。
5、 可修改性和可測性，是指需求功能的結構易於修改和調整且每一點都是可以驗證的。
備注：80%的缺陷都是來自於前期的需求沒有評審好，確認好。另外，需求的頻繁變更也是造成BUG出現的主要原因。產品經理是把握需求、方向。
第4課、軟件測試的概念
1、軟件質量的定義：
- 符合客戶的要求。
- 針對客戶的滿意度，如果客戶滿意則質量好，反之則不好。
2、軟件測試的定義：
為了尋找軟件中的錯誤而執行的軟件的過程。
3、軟件錯誤（BUG）：
我們在運行軟件的過程中實際結果跟預期結果不符（軟件規格）不符，這些問題都統稱為BUG
4、8/2原則：
80%的錯誤是集中在20%模塊里，經常出錯誤的模塊，經修復后還是容易出錯。
5、 從是否針對軟件的內部結構和算法可分為白盒測試和黑盒測試。
白盒測試：主要針對軟件內部結構和算法的測試（針對代碼）
黑盒測試：不關注軟件的內部結構和算法，只關注軟件外部功能特點的測試（針對功能）
6、 從軟件不同階段可分為：單元測試、集成測試、系統測試、驗收測試。
1) 單元測試：開發人員測試自己開發出來的單元模塊，利用白盒測試 方法由程序員自己來做。
2) 集成測試：將軟件的一些物件（或單元模塊）集成在一起測試，主要對接口、路徑、功能、性能進行測試，通常以白盒測試為主，黑盒測試為輔。（即由程序員自己為主，測試人員為輔）
3) 系統測試：測試軟件是否符合需求規格，測試工作由獨立的測試人員進行，主要采用黑盒測試。
4) 驗收測試：與系統測試相似，但測試工作由客戶進行，主要驗收軟件系統是否符合要求，通常采用黑盒測試方法。
備注：單元測試和集成測試主要由開發人員進行，從測試原理來分，分為白盒測試和黑盒測試，說白了白盒測試就是軟件內部的代碼測試，黑盒測試就是軟件所表現的功能點的測試。
系統測試主要由測試人員進行（以QQ郵箱為例）
界面測試 功能測試 性能測試 兼容性測試 易用性測試 安全性測試
采用黑盒 采用黑盒 采用黑盒 采用黑盒 采用黑盒 采用黑盒
1、 QQ郵箱是一個項目
2、 測試人員要求對這個項目進行系統測試
3、 例如我們有5個測試人員都會做不同的測試，有的做功能，有的做性能，有的做安全性
說明：所有軟件測試時一般都基於以上6個方法進行測試。
問：功能測試，系統測試、黑盒測試有什么關系。
答：功能測試是系統測試的一部分，系統測試包括功能測試。功能測試和系統測試都是以黑盒測試為主。
7、 回歸測試：BUG經開發人員修復后，重新由測試人員進行驗證。這個測試稱為回歸測試。
8、 功能測試：驗證功能是否符合軟件的功能要求。
9、 壓力測試：（負載測試）測試軟件的最大極限也稱為極限測試。
10、性能測試：測試軟件在不用情況下的性能，其中它的一個重要的指標就是系統的響應時間。
11、易用性測試：站在用戶的角度評價軟件好不好用，並提出意見。
12、兼容性測試：主要測試軟件與操作系統、瀏覽器或其他軟件（例如和殺毒軟件） 的兼容，有時候也會涉及到硬件兼容。例如顯示像素配置，網絡配置。
13、Alpha測試：系統剛開發完后給用戶測試一下（體驗一下）一種先期的用戶測試。
14、Boca測試：一種后期的用戶測試，此時系統已經通過我們的內部測試，並即將要發行的時候，給客戶看一下。
測試人員具備哪些素質：1、學習能力 2、溝通能力 3、團隊精神，自我督促、觀察力、技術能力的信心、懷疑精神 4、不怕重復性工作 5、熱愛測試工作，創新。外交能力。
| 測試名稱 |
測試方法 |
測試人員 |
測試依據 |
測試內容 |
| 單元測試 |
白盒測試 |
開發人員 |
軟件需求規格說明書 |
代碼 |
| 集成測試 |
白盒測試為主 黑盒測試為輔 |
開發人員為主 測試人員為輔 |
軟件需求規格說明書 |
測試軟件之間接口、路徑、性能、功能 |
| 系統測試 |
黑盒測試 |
測試人員 |
需求規格文檔；概要設計文檔；詳細設計文檔 |
測試軟件功能界面、性能、兼容性、易用、安全性 |
| 驗收測試 |
黑盒測試 |
客戶 |
需求規格文檔 |
測試軟件界面、功能、性能、兼容性、易用、安全性 |
第5課軟件測試計划
1、 什么叫軟件測試計划《定義》
它是一份描述軟件測試的目標、范圍、方法和時間的進度的文檔。
2、 軟件測試計划文檔具體包括哪些內容：
a) 測試的策略：指的是總體的測試范圍，系統測試進入的標准，測試工具的選擇，測試文檔的選擇，測試方法的選擇。
b) 測試的環境：軟件平台環境和硬件平台環境。
c) 測試管理：測試時間和人員的安排，溝通、協作方式以及工作量的安排。
d) 測試風險：若沒有按時間完成測試，所造成的風險和對應策略。
備注：系統進入的標准是指開發人員將版本提交給我們測試的時候，我們首先要對於軟件版本做基本的功能測試，如果基本的測試沒有問題方能進入系統測試，反之打回給開發人員修改，這里的基本測試稱為冒煙測試。
例：我們系統有200個用例，我們從中抽出40個基本功能進行測試，稱為冒煙測試。
問：你之前寫過測試計划么？
答：有寫過，不過我們的測試計划是自己負責模塊工作量、時間的測試計划，但一般總體的測試計划中測試經理來寫。
第6課測試用例
郵箱登錄的例子：
用戶名 （1~6英文）
密碼 （1~6字母）
1、測試用例的屬性
| 序號 |
測試標題 |
操作步驟 |
預期結果 |
實際結果 |
是否通過 |
備注 |
| 1 |
登錄郵箱 |
1、 打開QQ郵箱 2、 輸入正確的用戶名和密碼 3、 點擊登陸，查看是否登陸成功 |
1、 郵箱界面可以打開 2、 用戶登陸成功 |
|
|
|
| 2 |
登錄郵箱 |
1、 打開QQ郵箱 2、 用戶名為空密碼為空 3、 點擊登陸查看是否登陸成功 |
1、 登陸成功 2、 系統給出提示用戶密碼不能空 |
|
|
|
備注：嚴格來講不操作步驟都應該有一不預期結果，操作步驟中具體使用了什么數據一定要寫清楚，測試用例一般不包括前置條件等屬性。一般情況下測試用例包括測試序號、測試標題、前置條件、操作步驟、預期結果、實際結果是否通過、備注等屬性，每個公司的規范可能都不一樣，測試人員、時間、測試項目，功能模塊（很少用）
2、測試用例的作用：它作為測試的標准，指導測試人員進行測試工作，以發現問題，並提交BUG，最終提高軟件質量。
3、好的測試用例應具備哪些特征？
a) 好的測試用例應該可以發現以往發現不了的錯誤，其測試點分的很細。
b) 好的測試用例沒有多余的，冗余的用例。
c) 測試用例必須定義一個或多個預期結果。
第十課黑盒測試用例設計方法
1、 等價類划分法:就是把所有可能輸入的數據，划分為若干區域，然后從每個區域中取有代表性的數據進行測試。
1—10 1 5 10
10-100 10 50 100
100-1000 101 500 1000
例：運行輸入（1~10000） 1000-10000 1001 5000 10000
輸入框
2、 等價類划分可分為有效等價、無效等價。
a) 有效等價：輸入的數據符合程序的要求，也就是說符合軟件需求規格說明書。
b) 無效等價：輸入的數據對程序來說是無效的。也就是說，不符合軟件需求規格說明書。
1、＜1 6、空格 11、空的
例：運行輸入（1~10000） 2、＞10000 7、標點符號
輸入框 3、英文字母 8、全角/半角
4、中文字符 9、負數
5、特殊字符 10、各種字符混合
備注：我們在測試任何一個功能點的時候，我們的硬件需求規格對每一個功能點都有詳細的輸入輸出說明，也就是規格限制。如果沒有限制，開發人員將無法開發程序，測試人員將無法設計用例，也就無法開展測試工作。
說明：測試用例是根據軟件需求規格說明書來寫的。
3、 邊界值分析法：
取稍高於和稍低於邊界值的一些數據，這種方法稱為邊界值分析法。
例：n它的邊界值 n-1 n n+1
輸入框 (1~10000)邊界值為0 1 2 9999 10000 10001
4、 錯誤推測法：
根據自己以前的測試經驗和直覺未判斷程序中的錯誤
例：輸入框 （1-1000）
比方說程序在處理一些超長字符，空格字符和邊界值時容易出錯，那么我們可以拿這些數據來試一試。
測試用例設計案例
用戶名 （1-6位數字字符）
密碼 （1-6位數字字符）
登陸按鈕
| 有效等價 |
無效等價 |
邊界值 |
錯誤推測 |
異常 |
| 1、1位英文字符用戶 2、2位英文字符用戶 3、3位英文字符用戶 4、4位英文字符用戶 5、5位英文字符用戶 6、6位英文字符用戶 |
1、空的 2、＞6位 3、數字 4、中文 5、空格 6、標點符號 7、全角/半角 8、特殊字符 9、混合字符 10、不存在的用戶 11、大於寫敏感正確的用戶名錯誤的密碼 |
|
超長字符 空格 復制、粘貼 |
網絡中斷、數據庫中斷、異常 |
場景法：
用戶可能只給到一個場景或簡單的業務流程或一段簡單的文字需求描述，此時測試人員需要根據自己的業務流程或已有的場景和需求，充分發揮對用戶實際業務場景的想象。
場景法舉例：
比如：ATM取款機
這個時候我們需要根據業務流程充分發揮
實際業務場景的各種操作
插卡→輸入密碼→查閱→取款 → 業務流程
基本流：無任何差錯，從程序開始直接執行到結束只經過最簡單的路徑。
備選流：指在特定條件下可能發生的過程。
注明：例如有時候面試官會讓你寫，請設計ATM測試用例
這很明顯，我們要使用場景法進行用例設計，首先我們會想ATM機包括查詢功能、取款、存款功能、轉賬功能，隨后我們一一對這些功能進行用例設計就好，以上是一個類型的使用場景法進行用例設計的過程。
因果圖判定表法：
我們輸入的條件可能有多種，每一種條件之間的組合都可能形成一種新的結果，我們把其中的條件和結果通過圖形的方式表現出來，最后通過判定表進行展示。
例：高考加分軟件，加分的政策是：如果考生是少數名族。則加5分。如果考生是體育特長生，加5分。如果考生具備前兩項加分條件，則加8分。
少數名族 少數名族
加分 體育特長生 加分
體育特長生 特殊照顧
判定表
| 需要測試的情況 |
情況1 |
情況2 |
情況3 |
情況4 |
情況5 |
| 少數名族 |
是 |
是 |
否 |
否 |
|
| 體育特長生 |
是 |
否 |
是 |
否 |
|
| 其他照顧 |
|
|
|
|
|
| 加5分 |
|
加5分 |
加5分 |
|
|
| 加8分 |
加8分 |
|
|
|
|
| 加10分其他優惠 |
|
|
|
|
|
| 需要測試的情況 |
情況1 |
情況2 |
情況3 |
情況4 |
情況5 |
情況6 |
~~7 |
~~8 |
| 少數名族 |
是 |
是 |
是 |
否 |
否 |
否 |
是 |
否 |
| 體育特長 |
|
是 |
是 |
否 |
是 |
否 |
否 |
否 |
| 奧賽生 |
|
是 |
否 |
是 |
是 |
是 |
否 |
否 |
| 加5分 |
|
|
|
|
加5分 |
加5分 |
加5分 |
|
| 加8分 |
|
加8分 |
加8分 |
加8分 |
|
|
|
|
| 加10分 |
加10分 |
|
|
|
|
|
|
|
正交表法
正交表法：是一種有效減少用例個數的設計方法。
1、 如何減少用例個數，我們需要根據實際的業務情景和組合特點，進行有效設計，必要時我們需要咨詢開發的意見，最終的目的是我們需要選擇一些典型的用例進行測試。
2、 如果我們把所有組合，組合在一起，我們的時間是不夠的，人力也不夠的，況且也沒必要，當中會產生很多冗余的用例。一般的做法是測試一個條件時，我們會默認其他條件都是正確的。
正交表法舉例：
論壇注冊的例子，比方說我們注冊論壇時，需要輸入多個輸入框的內容，如果我們把每個輸入框組合起來（假設我們）的輸入框有30個呢，那么這種組合的測試用例可能高達幾千個，那么這種組合太多了，對於測試和開發都是不現實的，我們只能按上面說的一個條件。一個條件的測試然后有時間的話再找出少量的有代表性的組合測試即可。
但有一點大家要注意，正交表法的核心是：有效的減少用例個數，並選取一些有代表性的典型的組合進行測試。
總結：用例設計的完整度：
任何用例寫完之后不是100%完美，一方面我們需要測試內部評審，以便更加完善。另一方面，我們設計出來的用例和開發出來的功能，不可能達到高度統一，也就是說，我們在測試軟件的時候也存在修改用例的可能。
備注：六種黑盒用例設計方法都要能說出概念，並且能舉例子出來。
第8課用例評審
一般情況下，從以下幾個方面對我們的用例進行評審：
a) 測試用例是否完全針對需求規格說明書中列出的功能
b) 有沒有冗余的用例
c) 是否每個步驟都清楚的描述了預期的結果。
d) 必須測試什么功能
e) 如果一些功能不測試會導致什么樣的結果。
黑盒測試用例設計方法有哪些（包括每種方法的概念和舉例）
1) 等價類划分法（可分為有效等價和無效等價）
2) 邊界值分析法
3) 錯誤推測法
4) 因果圖判定表法
5) 場景法
6) 正交表法
用例設計的案例
寫信模塊
收件人地址：＿＿＿＿＿＿＿＿＿（1-20個郵件地址）
標題：＿＿＿＿＿＿＿＿＿（0-100個字符）
附件：＿＿＿＿＿＿＿＿＿（可發送doc、txt、ppt、tpg四種格式的附件，單個附件發送容量不能超過2G，多個附件發送時，不能超過5G
異常最多發送4個附件）
收件人地址用例：
| 有效 |
無效 |
邊界 |
錯誤推斷 |
異常 |
| 1、1個郵件地址 2/20個郵件地址 |
1、 空的 2、 空格 3、 純數字 4、 純中文 5、 標點符號 6、 全角/半角 7、 大小寫敏感 8、 大於20個郵件 9、 不存在的郵件 10、混合字符 11、錯誤的格式 12、正確的郵件加錯誤的格式 |
|
1、 超長字符 2、 超長郵件地址 3、 空格 4、 復制粘貼大量字符 |
1、 網絡中斷 2、 數據庫異常 3、 郵件服務器異常 |
標題用例：
| 有效 |
無效 |
邊界 |
錯誤判斷 |
異常 |
| 1、 空的 2、 100個中文 3、 100個數字 4、 100個標點符號（含特殊字符） 5、 100個中英文混合（含字符） |
大於100個字符 |
1、 空的 2、 1個字符 3、 99個字符 4、 100個字符 5、 101個字符 |
1、 復制粘貼大量字符 2、 超長混合字符 3、 空格 |
1、 網絡中斷 2、 數據庫異常 |
附件的用例
| 有效 |
無效 |
邊界 |
錯誤推斷 |
異常 |
| 1、單個doc附件 且附件小於2G 3、 單個txt附件且附件小於2G 4、 單個PPT附件且附件小於2G 5、 單個JPG附件且附件小於2G 6、 一個附件都不變 7、 兩個附件且附件小於4G 8、 三個附件且附件小於5G 9、 四個附件且附件小於5G
|
1、 單個DOC小於2G 2、 單個TXT小於2G 3、 單個PPT小於2G 4、 單個JPG小於2G 5、 二個附件大於4G 6、 二個附件大於5G 7、 三個附件大於5G 8、 四個附件大於5G 9、 附件數為5個 10、其他常用的格式（例：JIF、EXE） 11、可以上傳的格式加非法格式 12、損壞的文件格式 |
1、 空的 2、 單個附件為1G 3、 單個附件為2G 4、 單個附件為3G 5、 單個附件為4G 6、 單個附件為5G 7、 多個附件為6G 8、 3個附件一起發 9、 4個附件一起發 10、5個附件一起發 |
1、 超大附件 2、 超多附件 3、 特殊格式 |
1、 網絡中斷 2、 數據庫異常 3、 帶有病毒的附件 |
測試一個紙杯
分析：外觀、功能、性能易用、安全
| 外觀測試 |
功能測試 |
性能測試 |
易用性測試 |
安全性測試 |
| 1、 形狀是否方便使用 2、 是否美觀 3、 杯子外壁的圖案是否合適 4、 需要光澤么 5、 高度、直徑是否符合要求 6、 杯子的材質是否符合要求 |
1、 驗證杯子是否能裝水 2、 驗證杯子灌注的容量正確 3、 驗證杯子能裝冰水 4、 驗證杯子能裝油、水之外的液體 5、 驗證杯子能裝固體、沙子等 |
1、 杯子使用多少次 2、 容易摔碎么 3、 抗擠壓么 |
1、 杯子容易被洗干凈么 2、 是否方便用戶拿着 3、 容易燙手么 4、 度過濾茶葉的附加功能么 |
1、材質是否環保 |
購票場景：
a) 一張25元的車票
b) 一張30元的車票
c) 一張35元的車票
d) 兩張25元的車票
e) 兩張30元的車票
f) 兩張35元的車票
g) 三張25元的車票
h) 三張30元的車票
i) 三張35元的車票
j) 買兩張不同時間的車票
k) 買三張不同時間的車票
l) 入一張100元面額紙幣
m) 買一張25元的車票看是否會找零75元
n) 操作出錯，是否會有提示
安全性：
- 向使用界面潑水
- 雷雨、高壓情況下是否有保護措施或提醒、報警
- 車票打印出來的油墨是否含有有害物質
- 取票時，查看是否有警戒線
- 查看是否有裸露的電線
- 系統無法操作時，是否有叫維修人員的按鈕和電話
異常場景：
a、 數據庫中斷異常
b、 購票時中斷
c、 投入破損的鈔票
d、 投入非100的鈔票。如：白紙、外幣、銀行卡
e、 打印時沒墨水
f、 投入其他面額的鈔票
g、 頻繁的取消、返回
h、 沒有打印紙
i、 連續快速多次投入100元鈔票
題目6：三角形程序的測試用例
有一個程序，能判斷用戶輸入的三個是否能構成一個三角形。如果能構成三角形，程序還能判斷三角形的類型。例如：等腰、等邊、直角三角形等。
分析：這是一個很經典的問題，很多軟件測試的教材中都引用了這個例子，它也多次出現在筆試的試卷中。曾經參加過微軟公司的內部培訓，這道題也在其中，它重點考察的是等價類划分這個知識點。下面是幾點提示。
a) 把關於三角形的數學知識都考慮到，例如：只有任意兩邊之和大於第三邊才能構成三角形。例如:三角形的種類有普通三角形、等腰三角形、等邊三角形、直角三角形、等腰直角三角形（銳角、直角、鈍角三角形也是另一種分法）這些類型在測試中都要考慮到的。
b) 邊長不要局限在正整數、小數、零、負數等都要考慮到
c) 不要局限在功能測試上，有的題給出了題中描述的程序界面測試、兼容性測試、性能測試等。即使沒有給出程序界面，我們也可以列出這些測試題，盡可能的多想一些，考慮的周到一些，是我們測試人員應當做的事情。
功能 異常
1、 取款100元（卡內含有3000元） 網絡中斷
2、 取款2000元（卡內含有3000元） 數據庫中斷異常
3、 取款60元（卡內含有3000元） 插入銀行卡后或取錢突然停電
4、 選擇美元查詢余額 插入非銀行卡（白紙、購物卡）
5、 選擇港幣查詢余額 ATM機沒錢時，連續使用取款
6、 使用語言選擇英文（外文） 輸入錯誤密碼（含小於6位數密碼）
7、 插入銀行卡之外的卡片（公交卡） 連續輸入3次密碼錯誤
8、 把銀行卡的方向（前后上下）交替插入 取款一次超過3000元
9、 取款時查看是否有操作指引 當天取款超過20000元
10、向使用界面潑水 轉賬時輸入錯誤賬號
11、頻繁取款 取消 轉賬一次超過銀行限額
12、取300元，並打印憑條 沒有墨水
13、驗證對外轉賬功能 沒有打印紙
14、驗證卡內轉賬功能 取款時，取小於100的金額
15、驗證手機號轉賬 一次取超過3000外幣（港幣、美元）
16、驗證查詢養老金功能 一天取超過20000外幣（港幣、美元）
17、驗證退卡功能
18、驗證其他賬號功能
19、取款時，使用“其他金額”輸入600
20、驗證改密碼的功能
21、點擊修改密碼輸入兩次不一樣的密碼
22、輸入錯誤的密碼
23、輸入錯誤的密碼然后更正
24、輸入三次錯誤的密碼
25、驗證緊急按鈕和應急電話
26、查看取款機是否有棱角
27、一次取款6000元。
28、在同一台取款機上，多次取款，金額總數達30000元
29、轉賬輸入錯誤賬號
30、轉賬金額為0.3元
31、取款時，查看是否有警戒線
32、查詢人民幣余額
三角形案例
對非法輸入的檢查
1、 有一邊為非數值的字符
2、 有兩邊為非數值的字符
3、 有三邊為非數值的字符
4、 有一邊為0
5、 有兩邊為0
6、 有三邊為0
7、 有一邊為負值
8、 有兩邊為負值
9、 三邊皆為負值
10、考慮一些可導致錯誤的符號。例如：“1”、“&”、“！”等等。
不能構成三角形的情況：
1、 兩邊之和等於第三邊的情況a+b=c、a+c=b、b+c=a。
2、 兩邊之和小於等於第三邊的情況a+b<c、a+c<b、b+c<a。
3、
能構成三角形的情況：
1、 驗證對普通三角形的判斷
2、 驗證對直角三角形的判斷。ab是直角邊、bc是直角邊、ac是直角邊
驗證等腰直角三角形的判斷
a、 b為直角邊且a=b。 b、c為直角邊且b=c。 a、c為直角邊且a=c。
b、
界面測試
1、 驗證控件是否正確
2、 驗證控件的擺放是否正確
3、 驗證字體，顏色是否正確
4、 驗證界面在縮放的時候變化是否正確。
易用性測試
a) 驗證默認焦點是否正確
b) 驗證焦點順序是否符合讀者習慣
c) 驗證輸入a、b、c完畢后，用戶能否通過回車來直接觸發判斷功能。
兼容性測試
1) 驗證這個軟件是否能運行在預期支持的各種操作系統。‘
性能測試
a、 驗證程序響應速度。
BUG的概念
作為測試人員，我們一個很重要的任務就是發現問題，並提交問題單。不管是建議性的問題，還是明顯的錯誤，我們都可以當作BUG提出來，不管需求文檔有沒有提到。
1、 軟件錯誤的等級
a) 致命錯誤（比方說：死機、系統奔潰等）
b) 嚴重錯誤（比方說：功能有沒有實現或產生錯誤的結果）
c) 一般錯誤（不影響業務功能的一些錯誤，比如提示性的錯誤）
d) 輕微錯誤（字體太小、顏色等）
e) 改進性錯誤
2、 錯誤軟件的優先級
a、 立即解決（致命、嚴重的要求立即解決）
b、 高優先級（一般的，嚴重的可以高優先級）
c、 正常排隊（提示的，一般性的選擇正常排隊）
d、 低優先級（改進建議的要求低優先級）
3、 一個完整的BUG包括哪些內容？（非常重要）
- 錯誤編號
- 軟件名稱及版本號
- 錯誤的嚴重程度
- 錯誤的概要
- 報告人（發現人）
- 錯誤發現的時間
- 承辦人（錯誤處理人）
- 錯誤的優先級
- 錯誤的狀態
- 錯誤的具體推進
- 備注
- 測試環境的描述
- 附件（圖片、日志）
注明：錯誤的具體描述是要把整個錯誤的發生，從開始到結果的每一個步驟都清晰的寫出來。
錯誤的概要：主要指的是錯誤的中心思想不要太簡單，也不要太復雜，一句話即可。
最后，有截圖和日志的我們一定要附上去。
錯誤的狀態：open（開放）
Closed(關閉)
Keep on（重新打開）
具體描述，把使用的數據寫上去。
點擊139郵箱，其他頁面顯示，唯收件箱頁面為亂碼。
錯誤編號：01
軟件名稱、版本：139郵箱v202
錯誤的嚴重程度：嚴重錯誤
錯誤的概要：打開139郵箱，點擊登陸成功，其他頁面都能正常顯示，只有收件箱頁面顯示為亂碼。
報告人： 曾愛蓮
錯誤發現的時間：2013/09/23
錯誤處理人：江楚
錯誤的狀態：開發
錯誤的優先級：立即解決
錯誤的具體描述：
a) 打開139郵箱，輸入正確的用戶名zengailian。密碼為123456。點擊登陸。
b) 顯示登陸成功，點擊寫信箱、通訊錄、草稿箱等所有頁面都可以正常的顯示出來，只有在點擊收件箱頁面的時候，顯示的都是亂碼。
備注：無
測試環境的描述：windows xp IE6
附件：上傳圖片、日志等。
日志的照片上傳后，我自己可以看到，但我的好友看不到，我也沒有做任何的限制。
編號：0
名稱、版本：騰訊QQ、V1.01
錯誤的概要：在QQ空間內上傳照片，上傳成功后，沒有任何設置，但我的好友看不到。
錯誤報告人：伍琳
錯誤發現時間：2013/09/23
錯誤經辦人：江楚
錯誤的優先級：高優先級
錯誤的妝容：（OPEN）開發
錯誤的具體描述：
a) 登陸賬號為：123456 密碼為：123456 的QQ
b) 進入QQ空間，選擇001gif 容量為1GB的圖片
c) 上傳0.001gif至我的空間相冊
d) 提示上傳成功
e) 沒有設置任何的限制，但只有我自己可以看到，我的好友看不到。
備注： 無
錯誤測試環境的描述：軟件環境：Windows XP IE6 360殺毒
上傳圖片、日志等
BUG流程
1、 系統測試BUG的走向
| 狀態 |
開放 |
| 提交人 |
自己 |
| 處理人 |
測試經理 |
| 狀態 |
已修復 |
| 提交人 |
開發人員 |
| 處理人 |
測試經理 |
| 狀態 |
已分配 |
| 提交人 |
測試經理 |
| 處理人 |
開發人員 |
| 狀態 |
已修復 |
| 提交人 |
測試經理 |
| 處理人 |
需求人員 |
| 狀態 |
關閉 |
| 提交人 |
測試人員 |
| 處理人 |
測試人員 |
注明：系統測試期間，測試人員提交的BUG時候，需要測試經理或項目經理審核。
測試人員
拒絕
忽略 測試經理 拒絕
接受 忽略
掛起 開發人員
接受 關閉
重新打開 測試人員
注意：系統測試期間，測試人員一般要將BUG提交給測試經理或項目經理進行審核，然后由他們將BUG指派給相關的開發人員。如果他們拒絕、忽略、掛起BUG的時候，一定要寫明原因。當測試人員和開發人員對BUG起爭議的時候，如果一方認為此BUG不重要或認為此不算是個BUG，而另一方認為這是一個BUG，而且很重要。那么作為測試人員首先要檢查自己的BUG是否寫清楚了，是否屬實。如果屬實的話，開發人員還是不承認，那就提交給測試經理去解決，如果對方還是不認、不願意修改。則由測試經理召開BUG的評審大會，由項目組的全體人員評審定奪。
集成測試期間，我們直接提交BUG給開發人員即可，不需要提交給測試經理審核。
性能測試
一、 定義：在一定負載的情況下，系統響應時間、吞吐量、服務器占用資源等特征是否滿足軟件的性能需求。
二、 性能測試的指標：
1、 系統響應時間
響應時間反應完成某個業務所需要的時間。
例如：從單擊登陸按鈕到登陸完成，返回登陸成功頁面！需要耗1秒，那么說這個操作系統的響應時間就是1秒。
例：1千萬人同時登陸QQ，系統響應時間不能超過30秒。
100萬人同時登陸QQ，系統響應時間不能超過10秒。
10萬人同時登陸QQ，系統響應時間不能超過5秒。
1萬人同時登陸QQ，系統響應時間不能超過1秒。
2、 吞吐量
吞吐量反映單位時間內能夠處理的事務數量。（每秒事務數：DPS）
例如：對於系統來說，1個用戶登陸需要一秒，如果系統同時有10個用戶登陸，且響應時間也是1秒鍾，那么就稱這個系統的吞吐量為每秒10個。
吞吐量也稱TPS，每秒事務數。
3、 服務器資源占用
它是反映不同負載下，系統的CPU內存占用率，占用率越低說明系統越優秀。
注明：一般的性能指標都是由產品經理，項目中的領導來定義的，測試人員根據需求的定義進行測試即可。
常用的性能工具為load runner。簡稱 LR
系統測試報告
1、 你之前有寫過測試報告么?
答：寫過，不過我們寫的是我們自己負責的模塊測試報告，一般整個系統的測試報告都是由測試經理來寫的。
2、 系統測試報告包括哪些內容？
a) 測試過程描述
b) 測試結果的分析
c) 系統存在風險
d) 測試結論與評論
測試報告其他的要素：例如編寫目的，測試環境描述，參考資料等。每個公司的格式都不一樣。
3、 測試過程的描述主要指：測試時間、方法、范圍、協作方式、版本等。
4、 測試結果分析：
a、 指的是發現BUG總數量、致命性、嚴重性的以及一般性的問題的功能模塊的分布情況。（致命、嚴重的用附在后面）
b、 指的是用例的通過率。通過多少，沒通過多少，半通過多少。一般致命錯誤、嚴重錯誤都要放到報告中去。
c、 覆蓋率80%
5、系統風險分析：
我們發現的問題單會對我們系統和模塊造成什么樣的風險、影響。
6、測試結論與評論：
通俗來說就是指能否上線、發布，如果上線會有什么后果。
執行行數
需求覆蓋率= ×100%
總代碼行數
1、完整的測試過程包括哪些階段：
一般情況下，它包括需求評審、測試計划、測試用例的設計、測試用例的評審、測試環境的搭建，測試執行，提交問題單，回歸測試，提交測試報告。
2、軟件測試的目的：
其目的是發現軟件中存在的缺陷，檢驗軟件是否符合客戶需求規格要求。
3、軟件測試能否發現所有的BUG？
軟件測試不能發現所有的BUG，因為測試時，測試資源是有限的，而且有些BUG只有長期作用和特定的環境才會出現。
4、軟件測試工作在項目的什么階段開始的?
軟件測試應該盡早的開展，最好能在需求階段就進行測試。
1、 軟件測試人員在測試時應遵循什么原則？
軟件測試應遵循82原則。
2、 如果讓你來我們的測試團隊，你如何更快的進入工作狀態？
首先，我會盡快閱讀相關的項目文檔和幫助手冊，技術文檔等。以盡快熟悉業務功能。其次，我會多參加項目的各種會議，以熟悉項目的進度和后續的計划。
最后，我會盡快熟悉項目的測試用例，以及BUG庫里面的BUG，以幫助自己盡快的進入工作狀態。基本上，我會從以上幾個方面，讓自己更快的進入工作狀態。
B/S與C/S兩種軟件架構的區別：
1、 C/S結構軟件的特點:
a) 面對業務型的系統軟件
b) 要在電腦上安裝應用程序（例如客戶端）
c) 簡單的CLS架構只有兩層，就是客戶端認識數據庫。
d) 其前台（客戶端）能處理一般性的業務，能減輕后台的負擔。
2、 C/S結構軟件用例的特點:
a、 易用性測試
b、 安全性測試（尤其要注意SQL注入）（跨腳本點擊）
c、 性能測試（大量用戶並發）
d、 功能測試
e、 安裝部署測試
3、 B/S結構軟件的特點:
1) 面向的是互聯網用戶
2) 通過瀏覽器訪問后台
3) B/S軟件前台（瀏覽器）只能處理為瀏覽器查詢，數據的輸入等簡單功能。大部分工作由后台服務器承擔
4) 采用cookies儲存用戶信息。
5) 以網頁（表單）形式展示界面。
4、 B/S結構軟件的測試重點。
a) 功能測試
b) 鏈接測試
c) 兼容性測試
d) Cookies測試
e) 並發訪問測試（性能測試）
f) 安全性測試（注意SQL注入）（跨站腳本點擊）
注明：B/S結構軟件是未來的趨勢
B/S＞WEB測試（網頁測試）
問題：
問：你之前有搭建過測試環境么？
答：有搭建過一些。
如果對方問這么搭建。可以說，一般情況下，我們會從以下幾個方面搭建：
1、 有時候我們測試需要使用大批量的數據，比如說容量測試，壓力測試等。我們就可能要准備一些大容量的文件或者數據庫中插入大量數據。
2、 有時候我們測試的產品，支持多種操作系統，那么要我們在做兼容性測試時，就要准備好各種操作系統的計算機或使用虛擬計算機。
3、 有時候我們在安裝程序包的時候，需要配置各種參數，那我們在測試之前就要按照開發的要求設置。
4、 有時候我們還需要用到網絡，比方說IP設置、路由設置等。
一般情況下，我們都是按照以上幾個步驟進行的。
一、Web兼容性測試主要包括以下三個方面：
1、 系統平台的測試
最常見的系統平台有window、Unix、Linux操作系統等，同一個應用可能在某些操作系統那可以正常運行，但在另外的操作系統不能運行。因此，Web系統平台需要在各種操作系統下對Web系統進行系統平台兼容性測試。
2、 瀏覽器測試
瀏覽器是Web客戶端最核心的構件，不同廠商的瀏覽器又打java、html規格有不同的支持框架和層次結構風格在不同的瀏覽器中也有不同的顯示，瀏覽器需要測試兼容性。
3、分辨率測試
頁面版本在640×400/600×800或1024×768的分辨率模式下是否顯示正常，字體太小或者太大，以至於無法瀏覽？文件和圖片是否對齊？
4、操作系統與瀏覽器的兼容性如何配置？
| 瀏覽器 操作系統 |
IE6 |
IE7 |
IE8 |
IE9 |
IE10 |
火狐 |
遨游 |
360 |
| XP |
√ |
√ |
|
|
|
√ |
√ |
√ |
| Vista |
|
√ |
|
|
|
|
|
√ |
| Win7 |
|
√ |
√ |
|
|
|
|
√ |
| Win8 |
|
|
√ |
√ |
√ |
|
|
√ |
| Linux |
× |
|
|
|
|
√ |
|
|
注意點：我們在選擇瀏覽器版本的時候，一定要選擇正式版本的瀏覽器進行測試，非正式版本瀏覽器本身可能存在不穩定性，有可能對我們測試結果造成影響。
問題單：3000個用例在8款瀏覽器上進行測試，時間不夠怎么測試？
a) 根據已有的業務場景和組合特點進行有效設計，必要時咨詢開發的意見，選取一些典型的用例。
b) 加班，盡量測相似的用例
c) 如果一些功能點未測時，我會和我們的測試經理溝通，建議延遲上線，因為這是對客戶與產品不負責任的。
d) 根據市場的調查，來對8款瀏覽器和操作系統有效互配，減少一些冗余的用例。
Web測試的類型
引言
同樣的產品，同樣的項目，讓不同的測試人員來測可能效果不一樣，能發現的問題並不一樣多……，這是為什么？怎么能盡可能多的發現產品的問題？需要掌握更多的測試方法，需要會做多種類型的測試，需要考慮的角度更多樣化，更全面。下面我們總結一些常見的測試方法和類型。
Web系統測試與傳統測試的區別
基於web的系統測試與傳統的軟件測試既有相同之處，也有不同的地方，對軟件測試提出了新的挑戰。基於web的系統測試不但需要檢查和驗證是否按照設計的要求運行，而且還要評價系統在不同用戶瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。
Web測試類型：
一、 功能測試
1、 鏈接測試
鏈接是web應用系統的一個主要特征，它是頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。鏈接測試可分為三個方面。首先，測試所有鏈接是否按指示的 那樣確實鏈接到了該鏈接的頁面；其次，測試所鏈接的頁面是否存在；最后，保證web應用系統上孤立的頁面，所謂孤立頁面是指沒有鏈接指向該頁面，只有正確的URL地址才能訪問。
鏈接測試可以自動進行，現在已經有許多工具可以采用。鏈接測試必須在集成測試階段完成，也就是說，在整個web應用系統的所有頁面開發完成之后進行鏈接測試。
2、 表單測試
當用戶給web應用系統管理員提交信息時，就需要使用表單操作，例如用戶注冊、登陸、信息提交等。在這種情況下，我們必須測試提交操作的完整性，以校驗交給服務器的信息的正確性。例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。如果使用了默認值，還要檢驗默認值的正確性。如果 表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字符，測試時可以跳過這些字符，看系統是否會報錯。
3、 cookies測試
cookies通常用來存儲用戶信息和用戶在某應用系統的操作，當一個用戶使用
cookies訪問了某一個應用系統時，web服務器將發送關於用戶的信息，把該信息以cookies的形式存儲在客戶端計算機上，這可用來創建動態和自定義頁面或者存儲登陸等信息。
如果web應用系統使用了cookies，就必須檢查cookies是否正常工作。測試的內容可包括cookies是否起作用，是否按預定時間進行保存，刷新對cookies有什么影響等。
4、數據庫測試
在web應用技術中，數據庫起着重要的作用，數據庫為web應用系統的管理、運行、查詢和實現用戶對數據庫存儲的請求等提供空間。在web應用中，最常用的數據庫類型是關系型數據庫，可以使用SQL對信息進行處理。
在使用了數據庫的web應用系統中，一般情況下，可能發生兩張錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是由於用戶提交的表單信息不正確而造成的，而輸出錯誤主要由於網絡速度或程序設計問題等引起的，針對這兩種情況，可分別進行測試。
二、 可用性測試（易用性）
1、 導航測試
導航描述了用戶在一個頁面內操作的方式，在不同的用戶接口控制之間，例如按鈕、對話框、列表和窗口等；或在不同的鏈接頁面之間。通過考慮下列問題，可以決定一個web應用系統是否易於導航；導航是否美觀？web系統的主要部分是否可通過主頁存取？web系統是否需要站點地圖、搜索引擎或其他的導航幫助？
在一個頁面上放太多的信息往往起到與預期相反的效果。Web應用系統的用戶趨向於目的驅動，很快地掃描一個web應用系統，看是否有滿足自己需要的信息，如果沒有，就很快地離開。很少有用戶願意花時間去熟悉web應用系統的結構。因此，web應用系統導航要盡可能地准確。
導航的另一個重要方面是web應用系統的頁面結構、導航、菜單、連接的風格是否一致。確保用戶憑直覺就知道web應用系統是否還有內容，內容在什么地方。
Web應用系統的層次一旦決定，就要着手測試用戶導航功能，讓最終用戶參與這種測試，效果將更加明顯。
2、 圖形測試
在web應用系統中，適當的圖片和動畫既能起到廣告宣傳作用，又能起到美化頁面的功能。一個web應用系統的圖形可以包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。圖形測試的內容有：
a) 要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一起，以免浪費傳輸時間。Web應用系統的圖片尺寸要盡量地小，並且要能清楚地說明某件事情，一般都鏈接到某個具體的頁面。
b) 驗證所有頁面字體的風格是否一致。
c) 背景顏色應該與字體顏色和前景顏色相搭配。
d) 圖片的大小和質量也是一個很重要的因素，一般采用JPG和DIF壓縮。
3、 內容測試
內容測試用來檢驗web應用系統提供信息的正確性、准確性和相關性。
信息的正確性是指信息可靠的還是誤傳的。例如，在商品價格列表中，錯誤的價格可能引起財政問題甚至導致法律糾紛；信息的准確性是指是否有語法或拼寫錯誤。這種測試通常使用一些文字處理軟件來進行，例如使用Microsoft word的拼音與語法檢查功能；信息的相關性是指是否在當前頁面可以找到與當前瀏覽信息相關的信息列表或入口，也就是一般web站點中的所謂相關文章列表。
4、 整體界面測試
整體界面是指整個web應用系統的頁面結構設計，是給用戶一個整體感。例如：當用戶瀏覽web應用系統時是否感覺舒適，是否憑直覺就知道要找的信息在什么地方？整個web應用系統的設計風格是否一致？
對整體界面的測試過程，其實是一個對最終用戶進行調查的過程。一般web應用系統采取在主頁上做一個調查問卷的形式，得到最終用戶的反饋信息。
對所有的可用性測試來說，都需要有外部人員（與web應用系統開發沒有聯系或聯系很少的人員）參與，最好是最終用戶的參與。
三、 兼容性測試
1、 平台測試
市面上有很多不同的操作系統類型，最常見的有windows、Unix、Macintosh、Linux、等。Web應用系統的最終用戶究竟使用哪一種操作系統，取決於用戶系統的配置。這樣，就可能會發生兼容性問題，同一個應用可能在某些系統下能正常運行，但在另外的操作系統下可能會運行失敗。
因此，在web系統發布之前，需要在各種操作系統下對web系統進行兼容性測試。
2、 瀏覽器測試
瀏覽器是web客戶端最核心的構件，來自不同廠商的瀏覽器對java、JavaScript、ActiveX、plug-ins或不同的HTML規格有不同的支持。例如，ActiveX是Microsoft的產品，是為了Internet explorer而設計的，JavaScript是Netscape的產品，Java是Sun的產品等等。另外，框架和層次結構風格在不同的瀏覽器中也有不同的顯示，甚至根本不顯示。不同的瀏覽器對安全性和Java的設置也不一樣。
測試瀏覽器兼容性的一個方法是創建一個兼容性矩陣。在這個矩陣中，測試不同廠商、不同版本的瀏覽器對某些構件和設置的適應性。
四、性能測試
1、鏈接速度測試
用戶連接到web應用系統的速度根據上網的變化而變化，他們或許是電話撥號，或是寬帶上網。當下載一個程序時，用戶可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果web系統響應時間太長（例如超過5秒鍾），用戶就會因沒有耐心等待而離開。
另外，有些頁面有超時的限制，連接速度太慢，還可能引起數據丟失，使用戶得不到真實的頁面。
2、負載測試
負載測試應該安排在web系統發布以后，在實際額網絡環境中進行測試。因為一個企業內部員工，特別是項目組人員總是有限的，而一個web系統能同時處理的請求數量將遠遠超出這個限度，所以，只有放在Internet上，接受負載測試，其效果才是正確可惜的。
進行壓力測試是指實際破壞一個web應用系統，測試系統的反映。壓力測試時測試系統的限制和故障恢復能力，也就是測試web引用系統會不會奔潰，在什么情況下會奔潰。黑客常常提供錯誤的數據負載，直到web應用系統奔潰，接着當系統重新啟動時獲取存取權。
壓力測試的區域包括表單、登陸和其他信息傳輸頁面等。
五、安全測試
Web應用系統的安全性測試區域主要有：
a) 現在的web應用系統基本采用先注冊，后登陸的方式。因此，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。
b) Web應用系統是否有超時的限制，也就是說，用戶登陸后在一定時間內（例如15分鍾）沒有點擊任何頁面，是否需要重新登陸才能正常使用。
c) 為了保證web應用系統的安全性，日志文件是至關重要的。需要測試相關的信息是否寫進了日志文件、是否可追蹤。
d) 當使用了安全套接字時，還要測試加密是否正確，，檢查信息的完整性。
e) 服務器端的腳本常常構成安全漏洞，這些漏洞又常常被黑客利用。所以，還要測試沒有經過授權，就不能再服務器端放置和編輯腳本的問題。
六、接口測試
1，瀏覽器通常指 IE Fire Fox等，客戶端使用的程序
2，每台連接互聯網的機器都有一個唯一的IP地址，IP地址是由4個0到256的數組成的，比如：222.131.0.229，127.0.0.1，由於每台聯網的機器的IP地址都是獨立的，因此可以通過IP判斷一台機器。
網站所在的服務器通常有一個固定的IP地址，而我們瀏覽者每次上網的IP地址通常都不一樣，IP地址是由ISP分配的。
域名服務器(domain name server)的簡稱為DNS，它存儲了域名與IP地址對應的列表。
3，瀏覽器得到域名指向的IP后，瀏覽器會把我們輸入的域名轉化為HTTP的服務請求，例如，輸入 www.dreamdu.com，可以轉化為 http://www.dreamdu.com/，通過這種方式瀏覽器向服務器發出了請求。
由於輸入的是域名，因此服務器接收到請求后，會查找域名下的默認網頁(通常為default.php或default.html)，如果直接輸入http://www.dreamdu.com/default.php就直接查找這個頁面。
4，返回的請求通常是一些文件，包括文字信息(.html .css .asp文件等)，圖片，flash等(每個文件都要有一個唯一的網址，比如 http://www.dreamdu.com/xhtml/)
5，瀏覽器將這些信息組織成用戶可以查看的網頁
Sql注入
用戶在輸入界面輸入特殊的字符串，提交到web服務器，web服務器的程序可能會使用sql拼接的方式，導致拼接后的sql語句出現恆真條件；把不該查詢出來的數據查詢出來了，把不該刪除的數據刪除了，把不該修改的數據修改了；
select * from wp_users where user_name=''
and password =' '
select * from wp_users where user_name='zhoup'
and password =' a' or '1'='1'
zhoup
a' or '1'='1
輸入的時候，限制輸入特殊字符 ‘ % ? 要轉義
腳本注入
在用戶輸入的地方，輸入了一段腳本字符，保存到了數據庫中；
在用戶查詢數據的時候，瀏覽器會執行腳本；
防止，對< >進行轉義； < < > >
一、iOS和android的區別
Android 是谷歌公司開發的開源、免費的移動操作系統；
iOS是蘋果開發的不開源、不免費的移動操作系統；
目前流行的版本 Android : 4.4 5.0 6.0 7.0
iOS : 10、9 、8
android的主要廠商三星、華為、oppo、vivo、魅族、小米、一加
移動設備：電話(phone) 平板(pad) 電視(TV) 眼睛(class) 手表（watch） 汽車（car）
系統的區別
第一、Android 基於linux內核的，android apk 是 java 虛擬機機制實現的；
iOS的app 是基於沙盒機制實現的；
第二、兩者后台制度不同：IOS中任何第三方程序都不能在后台運行（地圖、音樂可以在后台運行，但是必須要通過蘋果公司的審核）；安卓中任何程序都能在后台運行，直到沒有內存才會關閉。
第三、iOS中用於UI指令權限最高，安卓中數據處理指令權限最高。
交互的區別
1、 應用程序的返回
2、 多任務之間的切換 ios 雙擊home android 左邊的按鍵
Android 存儲支持sd卡擴展，iOS不支持存儲擴展
二、android 測試 adb 命令
adb（android debug bridge）通過pc向 android 設備發送命令；
在開發者模式中，打開USB調試
1、 adb devices 查看連接到pc的所有的手機設備
2、 adb logcat 查看手機上面的日志命令
3、 adb的默認端口5037
4、 adb shell 然后 輸入top命令 可以查看手機的cpu 內存 io 的使用情況
5、 adb install buypiao.apk
6、 adb uninstall com.gewara 卸載應用
7、 adb shell ps 查看手機里面的進行信息
8、 adb push v.txt /sdcard 把當前目錄的文件v.txt上傳到手機的sdcard目錄
9、 adb pull /sdcard/v.txt v.txt 把sdcard目錄下的v.txt下載當前目錄
10.adb shell pm list packages：列出所有的包名。
11、adb shell dumpsys package：列出所有的安裝應用的信息
12、dumpsys package com.android.XXX：查看某個包的具體信息
Android中使用的是UTF-8字符，而CMD默認字符集是ANSI，中文環境下即為GBK，代碼頁為936。查詢當前代碼頁的方法為在CMD下直接輸入“chcp”命令，並會返回“活動的代碼頁：936”字樣
三、monkey 命令
adb shell monkey -p com.gewara -s 500 --pct-motion 20 –appswitch 30 -v 10000 > monkey_log.txt
觸摸
移動
界面切換
四、移動測試功能點(web app之間的區別)
測試業務功能；基本流
| 移動場景 |
wifi／3G／4G／GPRS 飛行模式 （無網絡、弱網絡app奔潰） |
| 網絡切換（視頻、音頻、下載） |
|
| 多任務場景 |
來電 |
| 填寫地址，從其他應用獲取 |
|
| 打開分享 |
|
| 啟動其他應用 |
|
| 視頻、音頻 |
|
| 避免手勢沖突 |
屏幕左側邊緣向右滑動 |
| 在屏幕上向左滑動 |
|
| 從屏幕頂部向下滑動 |
|
| 從屏幕底部向上滑動 |
|
| 按住屏幕向下滑動 |
|
| 在圖片上面雙擊 |
|
| 兩根手指的捏合與分開 |
|
| 搖晃設備 |
|
| 長按屏幕 |
|
| 關注用戶體驗 |
橫豎屏測試 |
| 通知與消息 |
app在用戶使用過程中是否有合適的通知和消息提示（智能家具） |
| 測試app安裝時是否明確聲明在用戶使用需要的權限 |
|
| app在后台運行是否有合適的通知和消息 |
|
| app出錯是否有通知和消息顯示（網絡異常 網速慢） |
|
| 支持多語言 |
每一種環境都需要測試 |
| 流量和電量測試 |
下載app 在Wi-Fi情況下 app最大2G |
| 測試app占用的存儲空間 |
|
| 測試app消耗的電量 |
|
| 測試app 的流量 |
|
| 升級卸載測試 |
升級前的數據 升級后可以使用 |
| app內部購買，升級后可以使用 |
|
| 刪除app 是否有緩存文件 |
|
| 刪除app 再次安裝 是否有影響 自動登陸 |
|
| 測試app 的數據的清除 |
|
| 調用第三方 |
app 的輸入和輸入法的關聯 |
| app顯示外部鏈接 |
|
| 分享功能 |
|
|
|
app 的請求是否加密 |
使用fiddler 來抓手機上面的包
面試：fiddler 名稱 代理原理
設置過濾器
session 和 cookie 的本質
session (會話) 是web服務器保存在內存中的對象，
cookie 是否web服務器寫在客戶端的小數據；
瀏覽器第一次訪問web服務器，web 服務器會生成一個sid（唯一的）；
Web服務器把sid作為cookie返回給瀏覽器；
瀏覽器第二次訪問web服務器，瀏覽器就會把sid作為cookie上傳給web服務器；
瀏覽器第三次訪問web服務器，瀏覽器就會把sid作為cookie上傳給web服務器；
瀏覽器和web服務器之間的多次對話，都是使用的相同的sid，這多次對話，稱為會話；
Sesssion 有過期，web服務器默認的過期時間是30分鍾；
| 第一次 |
請求 請求沒有任何cookie信息
|
|
|
響應中包括set-cookie: 服務器告訴瀏覽器，把ECS_ID數據寫入本地硬盤這個數據稱為cookies數據 |
| 第二次 |
請求把第一次服務器寫入本地硬盤的cookies數據重新傳給服務器； Cookie：
|
|
|
第二次響應 就寫過的cookie信息不用再寫入了 第二 |
第三次訪問和第二次一樣；
Session與cookie的區別
Session是保存在服務器端的數據
Cookie 是保存在本地硬盤的小數據；
Session的有效期一般是30分鍾；
Cookie的有效期，是服務器寫cookie數據的時候決定的，它可以設置的很長；
Session的數據安全性更高；
Cookie的數據的安全性差，可以被其他用戶竊取；
Jmeter做接口測試
1、測試計划
2、增加一個線程組，1個線程代表要給用戶；
3、增加要給http取樣器（sampler），填寫參數
3.1、增加一個斷言，判斷發送的請求業務對不對；
4、增加一個聚合報告，查看性能
4、增加要給查看結果樹
5、點擊運行，點擊查看結果樹
接口的4個要是
1、請求地址
2、請求方式 POST GET
3、請求參數
4、響應數據格式