先看后贊，養成習慣。點贊收藏，人生輝煌!

@TOC

1、簡單用戶界面登陸過程都需要做哪些分析。

參考回答：
一、功能測試
1.輸入正確的用戶名和密碼，點擊提交按鈕，驗證是否能正確登錄。 2.輸入錯誤的用戶名或者密碼,驗證登錄會失敗，并且提示相應的錯誤信息。
3.登錄成功后能否能否跳轉到正確的頁面
4.用戶名和密碼，如果太短或者太長，應該怎么處理
5.用戶名和密碼，中有特殊字符（比如空格），和其他非英文的情況 6.記住用戶名的功能
7.登陸失敗后，不能記錄密碼的功能
8.用戶名和密碼前后有空格的處理
9.密碼是否非明文顯示，使用星號圓點等符號代替。
10.牽扯到驗證碼的，還要考慮文字是否扭曲過度導致辨認難度大，考慮顏色（色盲使用者）， 刷新或換一個按鈕是否好用
11.登錄頁面中的注冊、忘記密碼，登出用另一帳號登陸等鏈接是否正確
12.輸入密碼的時候，大寫鍵盤開啟的時候要有提示信息。
13.什么都不輸入，點擊提交按鈕，檢查提示信息。
二、界面測試
1.布局是否合理，testbox 和按鈕是否整齊。
2.testbox 和按鈕的長度，高度是否復合要求。

• 界面的設計風格是否與 UI 的設計風格統一。
• 界面中的文字簡潔易懂，沒有錯別字。

三、性能測試
1.打開登錄頁面，需要的時間是否在需求要求的時間內。
2.輸入正確的用戶名和密碼后，檢查登錄成功跳轉到新頁面的時間是否在需求要求的時間內。
3.模擬大量用戶同時登陸，檢查一定壓力下能否正常登陸跳轉。 **
四、安全性測試
1.登錄成功后生成的 Cookie，是否是 httponly (否則容易被腳本盜取)。
2.用戶名和密碼是否通過加密的方式，發送給 Web 服務器。
3.用戶名和密碼的驗證，應該是用服務器端驗證，而不能單單是在客戶端用 javascript 驗證。
4.用戶名和密碼的輸入框，應該屏蔽 SQL 注入攻擊。
5.用戶名和密碼的的輸入框，應該禁止輸入腳本 （防止 XSS 攻擊）。
6.防止暴力破解，檢測是否有錯誤登陸的次數限制。

• 是否支持多用戶在同一機器上登錄。
• 同一用戶能否在多臺機器上登錄。

五、可用性測試
1、是否可以全用鍵盤操作，是否有快捷鍵。
2、輸入用戶名，密碼后按回車，是否可以登陸。
3、輸入框能否可以以 Tab 鍵切換。
六、兼容性測試
1.不同瀏覽器下能否顯示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari等）。
2.同種瀏覽器不同版本下能否顯示正常且功能正常。
2.不同的平臺是否能正常工作，比如 Windows, Mac。
3.移動設備上是否正常工作，比如 Iphone, Andriod。
4.不同的分辨率下顯示是否正常。
七、本地化測試
1、 不同語言環境下，頁面的顯示是否正確。

2、請對這個系統做出測試用例：一個系統，多個攝像頭，抓拍車牌，識別車牌，上傳網上， 網上展示。

參考回答：
功能：
1.每個攝像頭都能抓拍車牌；
2.每個攝像頭抓拍到的車牌能正常交給系統處理；
3.系統能夠正確識別車牌；
4.系統能夠將識別出的車牌上傳；
5.上傳至網絡的車牌能夠正常展示出來；
一、功能測試
1.使用正常的車牌，保持車牌靜止，檢查每個攝像頭是否能抓拍車牌；
2.使用類似非車牌的寫有字的紙板，檢查每個攝像頭是否抓拍；
3.使用正常的車牌，保持車牌較高速移動，檢查每個攝像頭是否能抓拍車牌；
4.在多種情況下檢查每個攝像頭抓拍到的車牌能否正常交給系統處理，如臨時斷電、斷網后能否正常將數據交給系統；
5.使用抓拍到的正常的車牌，交由系統處理，檢查系統能否識別車牌；
6.使用非車牌的其他圖片，交由系統處理，檢查系統能否識別；
7.在多種情況下檢查系統能否將正常識別出的車牌進行上傳，如臨時斷電、斷網后未上傳數據是否能繼續上傳；
8.構造非車牌的其他內容的數據，檢查系統能否將異常內容進行上傳；
9.檢查上傳至網絡的車牌能否正常展示出來；
10.上傳非車牌的其他內容的數據，檢查能否正常顯示出來。
二、性能測試
1.同時向一個攝像頭展示多個靜止的車牌，檢查攝像頭能否抓拍到多個車牌；
2.同時向一個攝像頭展示多個較高速運動的車牌，檢查攝像頭能否抓拍到多個車牌；
3.抓拍后，檢查系統識別車牌的時間是否在需求要求的時間內；
4.模擬大量抓拍照片同時交由系統處理，檢查一定壓力下系統能否正常識別車牌；
5.模擬大量車牌同時上傳，檢查一定壓力下能否上傳成功。
三、安全性測試
1.檢查是否能夠通過給車牌加裝飾物等方法，使攝像頭無法抓拍或抓拍后系統無法正常識別車牌。

3、 請你對吃雞游戲進行壓力測試。

參考回答：
一、首先明確需要測試壓力的內容:
1.游戲服務器硬件
a.硬盤 I/o
b.內存
c.CPU
2.網絡壓力
a.長連接
a1.最大連接數
a2.流量(內網、外網、進、出)
b.長連接短周期(類似 Http 的 TCP 應用，這個比較特殊的一個需求，專門針對 LoginAgent)
b1.每秒建立的連接數
b2.實際處理能力
3.數據庫
a.每秒事務數
b.每秒鎖等待數
c.平均延時(ms)
d.CPU 暫用
4.多線程的最優線程數
a.數據庫執行的多線程
b.多連接處理
二.Windows Server 環境測試方式
1.服務器性能監測
使用 Server 自帶的性能監測器設置各個進程的監測參數。Window 的這個自動工具做的相當強大。大家自己摸一摸基本就會用了。每個參數都由詳細的說明。
2.案例設計注意
a.對于數據庫的性能測試上，現在由于所有的游戲服務器構架在 DB 前面都有一個實現 DB 緩沖功能的進程，以減少數據庫頻繁的讀寫操作。所以其實數據庫的讀是一個輕量級的數量；而數據庫的寫操作是一個周期性能過程。案例設計一定要能夠驅動這種周期性能過程。比如我們游戲的戰斗，導致游戲玩家數據的改變，或驅動所有在線玩家數據的周期性存儲。
b.選擇具有代表性，并且最頻繁的游戲操作。用于進行最高用戶在線的各種性能指標采集。 如，開槍、道具拾取、道具使用、移動、聊天
c.聊天性能測試 廣播聊天是最為考驗游戲信息發送能力的功能。通過進行全局廣播的壓力測試。我們可以獲 取服務器進程發送信息到客戶端的最高承載量。進而可以對我們的各種廣播功能進行一個預估和 頻率限制。
d.同屏玩家的移動測試移動+廣播。這兩種信息，基本是網絡游戲流量的 70-80%左右。同屏玩家數量，將會增加各 種數據的廣播需求，非常影響游戲性能。所以同屏的移動測試也是廣播測試的一個必要環節。需 要根據實際結果進行適當的優化。
e.大量玩家同時登錄測試 玩家登錄時，有大量的信息需要進行分配和初始化；同時也有大量的數據需要下傳客戶端。 服務器需要進行大量的 TCP 連接建立。所以是一個比較關鍵的過程。這個測試案例是一個比較特 殊，但是運營是肯定會碰到的案例。
f.由于線程池處理事務，隨著事務的時耗，存在一個最優線程數的問題。過多的線程反而會 降低服務器效率
3.細節問題
a.進行測試需要仔細思考客戶端性能影響服務器最后表現的可能性。比如
a1.模擬客戶端的性能無法有效處理服務器返回信息,可能就導致服務器發送的信息緩存在 服務器系統緩存，從而表現出服務器內存不斷增加。表現為服務器發送能力不足，其實可能根本 就是客戶端的性能問題
a2.客戶端性能問題，導致發起的請求數過少，從而導致單位時間內服務器處理的請求過少。 表現為服務器性能不足，其實根本就是客戶端的請求能力不足。
b.網絡帶寬導致最后表現不足
b1.確認服務器的各個網卡，以及相互的帶寬。不然可能因為相互帶寬，導致服務器對于客 戶端請求的處理延時。表現為服務器卡機 b2.客戶端模擬多個玩家，比如 1000 個玩家。而客戶端的網卡或者客戶端與服務器之間的中 轉服務器帶寬過小，導致服務器數據發送不出，內存不斷增加。表現為服務器發送能力不足，其 實是中間帶寬問題。
c.debug i/o 導致服務器性能下降
c1.進行性能測試，一定要取消debug用的同步的i/o.比如我們服務器的debuginternalLog. 同步 i/o 是非常影響性能的，特別在壓力測試下可能導致每秒上千上萬甚至幾十萬次的執行。一 處的文件寫入操作就可以導致幾十萬次的處理能力變成幾千次的處理能力。
c2.客戶端避免進行阻塞操作導致模擬多用戶性能下降，導致服務器表現性能下降
d.流量需要區分內網網 內、外網流量在游戲正式運行時是完全分開的。價格也是完全不同的。一個千 M 的外網是一 個無法想象的運營成本，而 kmbps/s 現在已經是一個可以接受的代價。游戲進程需要進行不同網 卡的配置和綁定。確定內外網流量。

4、請你根據微信登錄界面設計測試用例

參考回答：
一、功能測試
1.輸入正確的用戶名和密碼，點擊提交按鈕，驗證是否能正確登錄。 2.輸入錯誤的用戶名或者密碼,驗證登錄會失敗，并且提示相應的錯誤信息。
3.登錄成功后能否能否跳轉到正確的頁面
4.檢查能否選擇不同登錄方式進行登錄，如使用手機號登錄、使用微信號登錄或掃碼登錄。
5.記住用戶名的功能
6.登陸失敗后，不能記錄密碼的功能
7.密碼是否非明文顯示顯示，使用星號圓點等符號代替。
8.有驗證碼時，還要考慮文字是否扭曲過度導致辨認難度大，考慮顏色、刷新或換一個按鈕是否好用
9.登錄頁面中的注冊、忘記密碼，登出用另一帳號登陸等鏈接是否正確
10.輸入密碼的時候，大寫鍵盤開啟的時候要有提示信息。
11.什么都不輸入，點擊提交按鈕，檢查提示信息。
二、界面測試
1.布局是否合理，testbox 和按鈕是否整齊。
2.testbox 和按鈕的長度，高度是否復合要求。

• 界面的設計風格是否與 UI 的設計風格統一。
• 界面中的文字簡潔易懂，沒有錯別字。

三、性能測試
1.打開登錄頁面，需要的時間是否在需求要求的時間內。
2.輸入正確的用戶名和密碼后，檢查登錄成功跳轉到新頁面的時間是否在需求要求的時間內。
3.模擬大量用戶同時登陸，檢查一定壓力下能否正常登陸跳轉。
四、安全性測試
1.登錄成功后生成的 Cookie，是否是 httponly (否則容易被腳本盜取)。
2.用戶名和密碼是否通過加密的方式，發送給 Web 服務器。
3.用戶名和密碼的驗證，應該是用服務器端驗證，而不能單單是在客戶端用 javascript 驗證。
4.用戶名和密碼的輸入框，應該屏蔽 SQL 注入攻擊。
5.用戶名和密碼的的輸入框，應該禁止輸入腳本防止 XSS 攻擊）。
6.防止暴力破解，檢測是否有錯誤登陸的次數限制。

• 是否支持多用戶在同一機器上登錄。
• 同一用戶能否在多臺機器上登錄。

五、兼容性測試
1.不同移動平臺或 PC 環境下下能否顯示正常且功能正常
2.同種平臺下不同微信版本下能否顯示正常且功能正常。
3.不同的分辨率下顯示是否正常。
七、本地化測試
1.不同語言環境下，頁面的顯示是否正確。

5、請你對朋友圈點贊功能進行測試

參考回答：
1.是否可以正常點贊和取消；
2.點贊的人是否在可見分組里；
3.點贊狀態是否能即時更新顯示；
4.點贊狀態，共同好友是否可見；
5.不同手機，系統顯示界面如何；
6.性能檢測，網速快慢對其影響；
7.點贊顯示的是否正確，一行幾個；
8.點贊是否按時間進行排序，頭像對應的是否正確；
9.是否能在消息列表中顯示點贊人的昵稱、
備注；
10.可擴展性測試，點贊后是否能發表評論；
11.是否在未登錄時可查看被點贊的信息。

6、如果做一個杯子的檢測，你如何測試

1.功能
（1）水倒水杯容量的一半
（2）水倒規定的安全線
（4）水杯容量刻度與其他水杯一致
（5）蓋子擰緊水倒不出來
（6）燙手驗證
2.性能
（1）使用最大次數或時間
（2）掉地上不易損壞
（3）蓋子擰到什么程度水倒不出來
（4）保溫時間長
（5）杯子的耐熱性
（6）杯子的耐寒性
（7）長時間放置水不會漏
（8）杯子上放置重物達到什么程度杯子會被損壞
3.界面
（1）外觀完整、美觀
（2）大小與設計一樣（高、寬、容量、直徑）
（3）拿著舒服
（4）材質與設計一樣
（5）杯子上的圖案掉落
（6）圖案遇水溶解
== 4.安全==
（1）杯子使用的材質毒或細菌的驗證
（2）高溫材質釋放毒性
（3）低溫材質釋放毒性
5.易用性
（1）倒水方便
（2）喝水方便
（3）攜帶方便
（4）使用簡單，容易操作
（5）防滑措施
6.兼容性
（1）杯子能夠容納果汁、白水、酒精、汽油等。
7.震動測試
（1）杯子加包裝（有填充物），六面震動，檢查產品是否能應對鐵路/公路/航空運輸。
8.可移植性
（1）杯子在不同地方、溫度環境下都可以正常使用。

7、 如何對一個頁面進行測試。

參考回答：
1、UI 測試：頁面布局、頁面樣式檢查、控件長度是否夠長；顯示時，是否會被截斷；支持的快捷鍵，Tab 鍵切換焦點順序正確性等。
2、功能測試：頁面上各類控件的測試范圍，測試點。結合控件的實際作用來補充檢查點： 比如，密碼框是否*顯示， 輸入是否做 trim 處理等。
3、安全測試：輸入特殊字符，sql 注入，腳本注入測試。后臺驗證測試，對于較重要的表單 ，繞過 js 檢驗后臺是否驗證；數據傳輸是否加密處理，比如， 直接請求轉發，地址欄直接顯示發送字符串？
4、兼容性測試
5、性能測試

8、如何對淘寶搜索框進行測試？

一, 功能測試
1、輸入關鍵字，查看: 返回結果是否準確，返回的文本長度需限制
1.1 輸入可查到結果的正常關鍵字、詞、語句，檢索到的內容、鏈接正確性；
1.2 輸入不可查到結果的關鍵字、詞、語句；
1.3 輸入一些特殊的內容，如空、特殊符、標點符、極限值等，可引入等價類劃分的方法等；
2.結果顯示：標題，賣家，銷售量，單行/多行，是否有圖片
3. 結果排序：價格 銷量 評價 綜合
4.返回結果龐大時，限制第一頁的現實量，需支持翻頁
4. 多選項搜索：關鍵字 品牌 產地 價格區間 是否天貓 是否全國購
5. 是否支持模糊搜索，支持通配符的查詢
6. 網速慢的情況下的搜索
7. 搜索結果為空的情況
8.未登錄情況和登錄情況下的搜索（登錄情況下存儲用戶搜索的關鍵字/搜索習慣）
二.性能測試：
1 、壓力測試：在不同發用戶數壓力下的表現（評價指標如響應時間等）
2 、負載測試：看極限能承載多大的用戶量同時正常使用
3 、穩定性測試：常規壓力下能保持多久持續穩定運行
4 、內存測試：有無內存泄漏現象
5 、大數據量測試：如模擬從龐大的海量數據中搜索結果、或搜索出海量的結果后列示出來， 看表現如何等等。
三.易用性：交互界面的設計是否便于、易于使用
1、 依據不同的查詢結果會有相關的人性化提示，查不到時告知？查到時統計條數并告知？有 疑似輸入條件錯誤時提示可能正確的輸入項等等處理；
2、查詢出的結果羅列有序，如按點擊率或其他排序規則，確保每次查詢出的結果位置按規則 列示方便定位，顯示字體、字號、色彩便于識別等等；
3、 標題查詢、全文檢索、模糊查詢、容錯查詢、多關鍵字組織查詢（空格間格開）等實用的 檢索方式是否正常？
4 輸入搜索條件的控件風格設計、位置擺放是否醒目便于使用者注意到，有否快照等快捷查 看方式等人性化設計？
四.兼容性
1、WINDOWS/LINUX/UNIX 等各類操作系統下及各版本條件下的應用
2、IE/FIREFOX/GOOGLE/360/QQ 等各類瀏覽器下及各版本條件下、各種顯示分辨率條件下的應用
3、SQL/ORACLE/DB2/MYSQL 等各類數據庫存儲情況下的兼容性測試
4、 簡體中文、繁體中文、英文等各類語種軟件平臺下的兼容性測試
5、IPHONE/IPAD、安卓等各類移動應用平臺下的兼容性測試
6 、與各相關的監控程序的兼容性測試，如輸入法、殺毒、監控、防火墻等工具同時使用
五.安全性
1、 被刪除、加密、授權的數據，不允許被 SQL 注入等攻擊方式查出來的，是否有安全控制設 計；
2、 錄入一些數據庫查詢的保留字符，如單引號、%等等，造成查詢 SQL 拼接出的語句產生漏 洞，如可以查出所有數據等等，這方面要有一些黑客攻擊的思想并引入一些工具和技術，如爬網 等。
3、 通過白盒測試技術，檢查一下在程序設計上是否存在安全方面的隱患；
4、 對涉及國家安全、法律禁止的內容是否進行了相關的過濾和控制；

9、如何對一瓶礦泉水進行測試

參考回答：
界面測試:查看外觀是否美觀
功能測試：查看水瓶漏不漏；瓶中水能不能被喝到
安全性：瓶子的材質有沒有毒或細菌（在低溫、高溫、正常）
可靠性：從不同高度落下的損壞程度
可移植性：再不同的地方、溫度等環境下是否都可以正常使用
兼容性：是否能夠容納果汁、白水、酒精、汽油等
易用性：是否燙手、是否有防滑措施、是否方便飲用
用戶文檔：使用手冊是否對的用法、限制、使用條件等有詳細描述
疲勞測試：將盛上水（案例一）放 24 小時檢查泄漏時間和情況；盛上汽油（案例二）放 24 小時檢查泄漏時間和情況等
壓力測試：用根針并在針上面不斷加重量，看壓強多大時會穿透
跌落測試:測試在何種高度跌落會破壞水瓶

10、請你來說一下購物車的測試用例

參考回答：
1.界面測試
? 界面布局、排版是否合理；文字是否顯示清晰；不同賣家的商品是否區分明顯。
** 2.功能測試 **
未登錄時：
? 將商品加入購物車，頁面跳轉到登錄頁面，登錄成功后購物車數量增加；
? 點擊購物車菜單，頁面跳轉到登錄頁面。
登錄后：
? 所有鏈接是否跳轉正確；
? 商品是否可以成功加入購物車；
? 購物車商品總數是否有限制；
? 商品總數是否正確；
? 全選功能是否好用；
? 刪除功能是否好用；
? 填寫委托單功能是否好用；
? 委托單中填寫的價格是否正確顯示；
? 價格總計是否正確；
? 商品文字太長時是否顯示完整；
? 店鋪名字太長時是否顯示完整；
? 創新券商品是否打標；
? 購物車中下架的商品是否有特殊標識；
? 新加入購物車商品排序（添加購物車中存在店鋪的商品和購物車中不存在店鋪的商品）；
? 是否支持 TAB、ENTER 等快捷鍵；
? 商品刪除后商品總數是否減少；
? 購物車結算功能是否好用。
3.兼容性測試
? 不同瀏覽器測試。
4.易用性測試
? 刪除功能是否有提示；是否有回到頂部的功能；商品過多時結算按鈕是否可以浮動顯示。
5.性能測試
? 壓力測試；并發測試。

11 、你寫的測試程序是怎么樣的，你寫過前端、后端程序嗎？

參考回答： 開發測試驅動程序一般分為 4 步：
1，指出需要的新特性。可以記錄下來，然后為其編寫一個測試。 2，編寫特性的概要代碼，這樣程序就可以運行而沒有任何語法等方面的錯誤，但是測試會失敗。看到測試失敗是很重要的，這樣就能確定測試可以失敗。如果測試代碼中出現了錯誤，那么就有可能出現任何情況，測試都會成功，這樣等于沒測試任何東西。再強調一遍：在試圖測試 成功之前，先要看到它失敗。
3，為特性的概要編寫虛設代碼，能滿足測試要求就行。不用準確的實現功能，只要保證測 試可以通過即可。這樣一來就可以保證在開發的時候總是通過測試了，（除了第一次測試的時候） 甚至在最初實現功能時亦是如此。
4，現在重寫（或者重構）代碼，這樣它就會做自己應該做的事，從而保證測試一直成功。 在編碼完成時，應該保證代碼處于健康狀態–不要遺留下任何測試失敗。
寫過前端測試

12、有沒有寫過測試腳本，怎么寫的？

參考回答：
然后，撰寫測試樁與驅動，白盒測試保證代碼邏輯中循環和分支都能夠走到，黑盒測試保證函數和首先，代碼走查結合動態單步跟蹤以及觀察日志與文件輸出，網絡、CPU 狀態。 功能腳本接口正確，輸入輸出符合設計預期。 對于異常處理，特別是變量的檢查需要特別關注，變量在使用前都需要進行檢查，是否為空？或者為 0？對于文件名和路徑必須檢查，確認文件是否存在，路徑是否可達之后再進行后續操作。 另外，需要考慮所依賴的其他功能腳本以及二進制工具，這些功能性單元應該如何使用，調用后 的返回會有哪些情況，對于正常和異常結果，腳本是否能夠捕捉到并且作出正確的判斷。

13、請問你 web 測試，怎么寫的？

參考回答：
Web 測試主要從下面幾個大方向考慮
功能測試，主要做鏈接測試，表單測試，cookies 測試，設計語言測試等

性能測試，考慮連接速度測試，以及負載測試，例如：Web 應用系統能允許多少個用戶同時 在線？如果超過了這個數量，會出現什么現象？Web 應用系統能否處理大量用戶對同一個頁面的請求？還有壓力測試 。

可用性測試，比如導航測試，圖形測試，內容測試，整體界面測試等

兼容性測試，市場上有很多不同的操作系統類型，最常見的有 Windows、Unix、Macintosh、 Linux 等。Web 應用系統的最終用戶究竟使用哪一種操作系統，取決于用戶系統的配置。這樣， 就可能會發生兼容性問題，同一個應用可能在某些操作系統下能正常運行，但在另外的操作系統 下可能會運行失敗。因此，在 Web 系統發布之前，需要在各種操作系統下對 Web 系統進行兼容性測試。

安全性測試
（1）現在的 Web 應用系統基本采用先注冊，后登陸的方式。因此，必須測試有效和無效的用 戶名和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個 頁面等。
（2）Web 應用系統是否有超時的限制，也就是說，用戶登陸后在一定時間內（例如 15 分鐘） 沒有點擊任何頁面，是否需要重新登陸才能正常使用。 （
3）為了保證 Web 應用系統的安全性，日志文件是至關重要的。需要測試相關信息是否寫進 了日志文件、是否可追蹤。
4）當使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。
5）服務器端的腳本常常構成安全漏洞，這些漏洞又常常被黑客利用。所以，還要測試沒有經過授權，就不能在服務器端放置和編輯腳本的問題。

14、請問測試路由器怎么測，用命令行還是界面？

參考回答：
可以采用 lperf 這個命令， Lperf 是一個網絡性能測試工具，可以測量最大 tcp 和 udp 帶寬，具有多種參數和特性，可 以記錄帶寬，延遲抖動，數據包丟失，通過這些信息可以發現網絡問題，檢查網絡質量，定位網 絡瓶頸。

iperf 的使用非常簡單，測試的原理是在 wan 口連接一臺 PC 機，在 LAN 口連接一臺 PC，兩 邊分別運行 iperf 服務端和客戶端模式，用來測量 LAN->WAN 和 WAN->LAN 性能。

具體命令如下：
服務端：iperf -s -w 1m
客戶端：iperf -c -w 1m -t 20 -P 10
含義是 TCP wndowsize 為 1MByte，測試時間是 20s，線程是 10。

15、請回答如何測試手機開機鍵？

參考回答：
功能測試： 按下開機鍵，屏幕能否亮起 。
性能測試： 按下開機鍵，屏幕能否在規定時間內亮起 。
壓力測試 連續多次按下開機鍵，觀察屏幕是否能一直亮起，到多久時間失靈 。
健壯性測試 給定一個中了病毒的手機或者是淘汰許久的老機子，安歇開機鍵觀察屏幕能否亮起 。
可靠性測試 連續按下開機鍵有限次數，比如 1 萬次，記錄屏幕未亮起的次數 。
可用性測試 開機鍵按下費不費力，開機鍵的形狀設計是否貼合手指，開機鍵的位置設計是否方便。

16、請問你遇到過哪些印象深刻的 bug，接口測試出現 bug 的原因有哪些？

面試官詢問遇到過哪些印象深刻的 bug，其實它并不關心你描述的這個 bug 是否真的有價值， 或有多曲折離奇？他只是：了解你平時工作中的測試能力。
所以，這就要求的你平時工作中遇到 bug 時試著自己去定位，定位 bug 的過程遠比你單純的執行測試用例有“價值”（自我技能提高的價值），在定位 bug 的過程中你需要掌握和運用更多知識。
另外，建議平時養成總結的好習慣，發現的 bug，開發解決了，最好問問他原因以及解決的方法，這樣再遇到類似問題時，自己也可以試著定位解決。遇到難解決的 bug，也可以把最的解決過程記錄下來。（這不是就有素材了） 所以，建議你平時可以主動要求去分享一些自己工作中用到或學習的技術。或者多去參加集體活動，加強自己的表達能力。
接口測試常見的 bug 有以下幾個:
1特殊值處理不當導致程序異常退出或者崩潰
2類型邊界溢出，導致數據獨處和寫入不一致
3取值邊界外未返回正確的錯誤信息
4權限未處理，可以訪問其他用戶的信息
5邏輯校驗不完善，可以利用漏洞獲取非正當利益
6狀態處理不當，導致邏輯出現錯誤
7q數組類型 item 個數為 0 或者 item 重復時程序異常退出

17、在做項目中有做過壓力測試嗎，怎么做。

1、首先對要測試的系統進行分析，明確需要對那一部分做壓力測試，比如秒殺，支付
2、如何對這些測試點進行施壓
第一種方式可以通過寫腳本產生壓力機器人對服務器進行發包收包操作
第二點借助一些壓力測試工具比如 Jmeter,LoadRunner
3、如何對這些測試點進行正確的施壓 需要用壓力測試工具或者其他方法錄制腳本，模擬用戶的操作
4、對測試點設計多大的壓力比較合適？ 需要明確壓力測試限制的數量，即用戶并發量
5、測試結束后如何通過這些數據來定位性能問題

通過測試可以得到吞吐量，平均響應時間等數據，這個數據的背后是整個后臺處理邏輯綜合作用的結果，這時候就可以先關注系統的 CPU，內存，然后對比吞吐量，平均響應時間達到瓶頸時這些數據的情況，然后就能確認性能問題是系統的哪一塊造成的。

18、請問你在項目中關于功能測試和接口測試是怎么做的。

參考回答
功能測試：
首先制定測試計劃，然后進行測試設計，將在測試計劃階段指定的測試活動分解，進而細化， 為若干個可執行程序的子測試過程，然后執行測試，按照測試計劃使用測試用例對待測項目進行逐一的，詳細的排查分析評估，最后對測試結果進行統計和分析，
接口測試：
什么是接口（API） API 全稱 Application Programming Interface，這里面我們其實不用去關注 AP，只需要I上就可以。一個 API 就是一個 Interface。我們無時不刻不在使用 interfaces。我們乘坐電梯里面的按鈕是一個 interface。我們開車一個踩油門它也是一個 interface。我們計算機操作系統也是有很多的接口。(這是目前個人找到比較好理解的一段解釋) 接口就是一個位于復雜系統之上并且能簡化你的任務，它就像一個中間人讓你不需要了解詳細的所有細節。那我們今天要講的 Web API 就是這么一類東西。像谷歌搜索系統，它提供了搜 索接口，簡化了你的搜索任務。再像用戶登錄頁面，我們只需要調用我們的登錄接口，我們就可以達到登錄系統的目的。 現在市面上有非常多種風格的 Web API，目前最流行的是也容易訪問的一種風格是 REST 或 者叫RESTful 風格的 API。從現在開始，以下我提到的所有 API 都是指 RESTful 風格的 API。
什么是接口測試和為什么要做接口測試
接口測試是測試系統組件間接口的一種測試。接口測試主要用于檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。 現在很多系統前后端架構是分離的，從安全層面來說，只依賴前端進行限制已經完全不能滿 足系統的安全要求（繞過前端太容易了）， 需要后端同樣進行控制，在這種情況下就需要從接 口層面進行驗證。 如今系統越來越復雜，傳統的靠前端測試已經大大降低了效率，而且現在我們都推崇測試前 移，希望測試能更早的介入測試，那接口測試就是一種及早介入的方式。例如傳統測試，你是不 是得等前后端都完成你才能進行測試，才能進行自動化代碼編寫。 而如果是接口測試，只需要 前后端定義好接口，那這時自動化就可以介入編寫接口自動化測試代碼，手工測試只需要后端代 碼完成就可以介入測試后端邏輯而不用等待前端工作完成。
接口測試的策略
接口測試也是屬于功能測試，所以跟我們以往的功能測試流程并沒有太大區別，測試流程依舊是：
1.測試接口文檔（需求文檔）
2.根據接口文檔編寫測試用例（用例編寫完全可以按照以往規則來編寫，例如等價類劃分，邊界值等設計方法）
3. 執行測試，查看不同的參數請求，接口的返回的數據是否達到預期。

19 、請問你有用過什么測試工具嗎，用過哪些？

自動化測試工具用過 selenium 和 appium
性能測試工具有用過 Jmeter

20、請你設計一個微信朋友圈點贊的測試用例？

功能測試
點贊某條朋友圈，驗證是否成功 。
接口測試
點贊朋友圈，驗證朋友能否收到提示信息 。
性能測試
點贊朋友圈，是否在規定時間顯示結果，是否在規定時間在朋友手機上進行提示 。
兼容性測試
在不同的終端比如 ipad手機上點贊朋友圈，驗證是否成功。

21、請問如果用戶點擊微博的關注圖標但是 app 上面沒有反應，應該怎么排查這個問題

參考回答：
首先 1.在 Eclipse Devices 窗口，選中 app 對應的包名，然后點擊 debug 圖標（綠色的小 蟲子），然后切換到 Debug 視圖。
2.切換視圖之后，可以看到 debug 下，app 的線程列表。
3.對于 main 線程（第一個線程），選中，并將其掛起 Suspend。
4.然后我們就可以看到，Suspend 之后，main 線程卡住的位置。

22、廣東用戶頭條 app 刷不出東西了，你應該怎么排查問題？

參考回答：
1、檢查網絡連接是否穩定，更換網絡嘗試
2、更新頭條版本嘗試
3、清除 app 緩存，應用數據

22、 請你說一下能不能用機器學習去進行自動化測試，如何監控異常流量，如果是脈沖呢， 如何和正常流量作區分。

如何用機器學習去進行自動化測試，就是讓自動化測試變得更加智能，在自動化測試過程中， 當測試功能模塊越來越多，沒有太多的時間去全部覆蓋，我們可以采用歸納學習的方式，基于自動化測試的執行結果或者手工測試執行的結果為數據輸入，然后基于一定的模型（例如：以通過率和模塊的重要率計算的平均值）得出測試推薦模塊，或者當要執行一個功能模塊時，基于歷史數據和模型（bug 出現的錯誤相關性，功能相關性等）計算出與該功能模塊相關性最大模塊，并推薦測試。
如何監控異常流量
1、抓包 tcpdump -i eth0 -w server.cap 對包文件使用第三方工具如：wireshark 做分析
2、iftop yum install iftop
3、iptraf yum install iptraf –y 或 yum install iptraf-ng -y 啟動命令 ifptraf-ng

23、請你說一說當前工作中涉及的測試問題(測試流程和測試性能)

參考回答：
在測試性能中，時常會出現腳本回訪卡住的問題，原因有以下幾種：
1、 runtimesetting 中的 continue error 沒有勾選
2、錄制的腳本中存在冗余的代碼部分，需要對腳本進行優化，去除冗余的部分（優化腳本）
例如：在用 FireFox 錄制腳本時，腳本中會產生一個叫” Url=http://download.cdn.mozilla.net/pub/firefox/releases/43.0.1/update/win32/zh-CN/ firefox-43.0.1.complete.mar",“Referer=”, ENDITEM,”這樣的代碼（該代碼出現的問題不止 一處，在查找時一定要注意。），這是因為采用 firefox 瀏覽器錄制時產生的壓縮文件，在腳本 回放時卡住的原因正是因為這個（建議：能采用 IE 錄制盡量用 IE 瀏覽器）
解決辦法：注釋掉或者刪除掉該段代碼即可， 關聯問題：在用 loadrunner 自帶對比工具 對比腳本后 找到需要關聯的動態值。在關聯后回放腳本時報錯 HTTP-status code 417 （exception failed）錯誤時，
產生的原因如下：
1、腳本中還存在沒有關聯或者關聯失敗的動態值，利用 lr 自帶對比工具仔細對比
2、腳本中的動態值被做了加密策略，仔細查看腳本中動態值的部分，看看動態值是否被做 了安全策略（隨機生成或者打亂動態值順序、在動態值中加入了特殊符號），由于在 tree-response 中的動態值是未被加密的狀態，在 client 向 server 發送請求時，client 的動態 值發給服務器，這時服務器的動態值已經被做了參數化，所以服務器不認準 client 向服務器發 送的動態值。 解決辦法：去掉動態值的安全策略即可（JVM 參數）。

24、性能測試有哪些指標，對一個登錄功能做性能測試，有哪些指標，怎么測 出可同時處理的最大請求數量。

參考回答
性能測試常用指標： 從外部看，主要有
1、吞吐量：每秒鐘系統能夠處理的請求數，任務數
2、響應時間：服務處理一個請求或一個任務的耗時
3、錯誤率：一批請求中結果出錯的請求所占比例
從服務器的角度看，性能測試關注 CPU，內存，服務器負載，網絡，磁盤ＩＯ
對登錄功能做性能測試
單用戶登陸的響應界面是否符合預期
單用戶登陸時后臺請求數量是否過多
高并發場景下用戶登錄的響應界面是否符合預期
高并發場景下服務端的監控指標是否符合預期
高集合點并發場景下是否存在資源死鎖和不合理的資源等待
長時間大量用戶連續登錄和登出，服務器端是否存在內存泄漏
怎么測出可同時處理的最大請求數量 可以采用性能測試工具(WeTest 服務器性能)，該工具是騰訊 wetest 團隊出品，使用起來很 簡單方便，但測試功能相當強大，能提供 10w+以上的并發量，定位性能拐點，測出服務器模型最大并發。

25、怎么進行單元測試，對一個沒有參數沒有返回值但可 能對全局變量有影響的怎么進行單元測試？

如何進行單元測試：
１、創建單元測試，該工具可以對任何類、接口、結構等實體中的字段、屬性、構造函數、 方法等進行單元測試。創建單元測試大致可以分為兩類：
整體測試，整體測試是在類名稱上右擊鼠標，在下拉菜單中點擊創建單元測試選項。這樣就可以為整個類創建單元測試了，這時他會為整個類可以被測試的內容全部添加測試方法。開發人員直接在這些自動生成的測試方法中添加單元測試代碼就可以了。

單獨測試，如果只想單獨對某個方法、屬性、字段進行測試，則可以將鼠標焦點放在這 個待測試的項目名稱之上，然后點擊鼠標右鍵，在右鍵菜單中選擇創建單元測試選項。這樣就可以單獨為某個方法創建單元測試了。
運行單元測試
查看測試結果
編寫單元測試代碼
測試沒有參數的函數，它可能還有別的輸入，例如全局變量，成員變量，或調用子函數獲得 的輸入（這個要使用工具才能做到），只要函數需讀取的，都應該設定初始值，如果完全沒有， 沒有輸入也是一種輸入，照樣測試就是了。同樣道理，輸出也不僅僅是返回值，沒有返回值還可 能修改了全局變量什么的，這些也是要判斷的輸出。

26、請問你有沒有做過壓力測試。

在軟件工程中，壓力測試是對系統不斷施加壓力的測試，是通過確定一個系統的瓶頸或者不能接收的性能點，來獲得系統能提供的最大服務級別的測試。例如測試一個 Web 站點在大量的負荷下，何時系統的響應會退化或失敗。

27、對于有系統大量并發訪問，你會如何做測試，有什么建議。

參考回答： 如何做高并發系統的測試，一般而言，整體的測試策略是：先針對部分系統進行性能測試及壓力測試，得到各部分的峰值處理性能，再模擬整體流程測試，重點測試整體業務流程以及業務預期負荷，著重測試以下幾點：
1、不同省份，不同運營商 CDN 節點性能，可采用典型壓力測試方案
2、核心機房 BGP 網絡帶寬，此部分重點在于測試各運行商的 BGP 網絡可靠性，實際速率， 一般采用 smokeping,lxChariot 等工具
3、各類硬件設備性能，一般采用專業的網絡設備測試工具
4、各類服務器并發性能，分布式處理能力，可采用壓力測試方案工具
5、業務系統性能，采用業務系統壓力測試方案
6、數據庫處理性能，這部分需要結合業務系統進行測試，以獲取核心業務場景下的數據庫 的 TPS/QPS，
7、如果有支付功能，需要進行支付渠道接口及分流測試，此部分相對而言可能是最大的瓶頸所在，此外還涉及備份方案，容災方案，業務降級方案的測試。

總結

以上是生活随笔為你收集整理的软件测试实例——总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。