软件测试实例整理
軟件測試實例整理
- 1、給你一個字符串，你怎么判斷是不是ip地址？手寫這段代碼，并寫出測試用例
- 2、請進行測試用例設計：一串數字，閏年的判別
- 3、請你說一說簡單用戶界面登陸過程都需要做哪些分析
- 4、請對這個系統做出測試用例：一個系統，多個攝像頭，抓拍車牌，識別車牌，上傳網上，網上展示
- 5、請你對吃雞游戲進行壓力測試
- 6、請你根據微信登錄界面設計測試用例
- 7、請你對朋友圈點贊功能進行測試
- 8.如果做一個杯子的檢測，你如何測試
- 9.如何對一個頁面進行測試
- 10.如何對水壺進行測試
- 11.如何對淘寶搜索框進行測試
- 12.如何對一瓶礦泉水進行測試
- 13、如何測試登陸界面
- 14.請你說一下jmeter
- 15.請你進行測試：前端下拉框實現，測試下拉框定位方式
- 16.請你來聊一聊appium斷言
- 17.請你來說一下購物車的測試用例
- 18.請你進行一下弱網模擬
- 19、你寫的測試程序是怎么樣的，你寫過前端、后端程序嗎？
- 20、請問你有沒有寫過測試腳本，怎么寫的？
- 21、請問你有沒有寫過web測試，怎么寫的？
- 23、請你回答一下如何測試手機開機鍵？
- 24、請問你遇到過哪些印象深刻的bug，接口測試出現bug的原因有哪些？
- 25、你在做項目中有做過壓力測試嗎，怎么做
- 26、請問你在項目中關于功能測試和接口測試是怎么做的
- 27、請問你有用過什么測試工具嗎，用過哪些？
- 28、請你設計一個微信朋友圈點贊的測試用例
- 29、請問如果用戶點擊微博的關注圖標但是app上面沒有反應，應該怎么排查這個問題
- 30、在做測試的過程中，假如前端和后端吵起來了都在踢皮球覺得對方該改代碼，你怎么辦？
- 31、如果廣東用戶頭條app刷不出東西了，你應該怎么排查問題
- 32、請你說一下能不能用機器學習去進行自動化測試，如何監控異常流量，如果是脈沖呢，如何和正常流量作區分
- 33、請問如何將大量日志的異常記錄或錯誤揪出來
- 34、請問如何對登錄界面進行測試
- 35、請你說一說當前工作中涉及的測試問題(測試流程和測試性能)
- 36、請你說一說洗牌問題的思路并手寫代碼，并設計測試用例
- 37、請你測試一下游戲中英雄的技能
- 38、請你回答一下性能測試有哪些指標，對一個登錄功能做性能測試，有哪些指標，怎么測出可同時處理的最大請求數量？
- 39、請問你有沒有做過什么單元測試，怎么進行單元測試，對一個沒有參數沒有返回值但可能對全局變量有影響的怎么進行單元測試
- 40、請問你有沒有做過壓力測試
- 41、對于有系統大量并發訪問，你會如何做測試，有什么建議
1、給你一個字符串，你怎么判斷是不是ip地址？手寫這段代碼，并寫出測試用例
鏈接: Python
鏈接: Java
2、請進行測試用例設計：一串數字，閏年的判別
鏈接: Python
鏈接: Java
3、請你說一說簡單用戶界面登陸過程都需要做哪些分析
答：一、功能測試
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.防止暴力破解，檢測是否有錯誤登陸的次數限制。
是否支持多用戶在同一機器上登錄。
同一用戶能否在多臺機器上登錄。
五、可用性測試
是否可以全用鍵盤操作，是否有快捷鍵。
輸入用戶名，密碼后按回車，是否可以登陸。
輸入框能否可以以Tab鍵切換。
六、兼容性測試
1.不同瀏覽器下能否顯示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）。
2.同種瀏覽器不同版本下能否顯示正常且功能正常。
2.不同的平臺是否能正常工作，比如Windows, Mac。
3.移動設備上是否正常工作，比如Iphone, Andriod。
4.不同的分辨率下顯示是否正常。
七、本地化測試
不同語言環境下，頁面的顯示是否正確。
4、請對這個系統做出測試用例：一個系統，多個攝像頭，抓拍車牌，識別車牌，上傳網上，網上展示
答：功能分析：
1.每個攝像頭都能抓拍車牌；
2.每個攝像頭抓拍到的車牌能正常交給系統處理；
3.系統能夠正確識別車牌；
4.系統能夠將識別出的車牌上傳；
5.上傳至網絡的車牌能夠正常展示出來；
一、功能測試
1.使用正常的車牌，保持車牌靜止，檢查每個攝像頭是否能抓拍車牌；
2.使用類似非車牌的寫有字的紙板，檢查每個攝像頭是否抓拍；
3.使用正常的車牌，保持車牌較高速移動，檢查每個攝像頭是否能抓拍車牌；
4.在多種情況下檢查每個攝像頭抓拍到的車牌能否正常交給系統處理，如臨時斷電、斷網后能否正常將數據交給系統；
5.使用抓拍到的正常的車牌，交由系統處理，檢查系統能否識別車牌；
6.使用非車牌的其他圖片，交由系統處理，檢查系統能否識別；
7.在多種情況下檢查系統能否將正常識別出的車牌進行上傳，如臨時斷電、斷網后未上傳數據是否能繼續上傳；
8.構造非車牌的其他內容的數據，檢查系統能否將異常內容進行上傳；
9.檢查上傳至網絡的車牌能否正常展示出來；
10.上傳非車牌的其他內容的數據，檢查能否正常顯示出來。
二、性能測試
1.同時向一個攝像頭展示多個靜止的車牌，檢查攝像頭能否抓拍到多個車牌；
2.同時向一個攝像頭展示多個較高速運動的車牌，檢查攝像頭能否抓拍到多個車牌；
3.抓拍后，檢查系統識別車牌的時間是否在需求要求的時間內；
4.模擬大量抓拍照片同時交由系統處理，檢查一定壓力下系統能否正常識別車牌；
5.模擬大量車牌同時上傳，檢查一定壓力下能否上傳成功。
三、安全性測試
1.檢查是否能夠通過給車牌加裝飾物等方法，使攝像頭無法抓拍或抓拍后系統無法正常識別車牌。
5、請你對吃雞游戲進行壓力測試
答：一.首先明確需要測試壓力的內容:
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現在已經是一個可以接受的代價。游戲進程需要進行不同網卡的配置和綁定。確定內外網流量。
6、請你根據微信登錄界面設計測試用例
答：一、功能測試
1.輸入正確的用戶名和密碼，點擊提交按鈕，驗證是否能正確登錄。 2.輸入錯誤的用戶名或者密碼,驗證登錄會失敗，并且提示相應的錯誤信息。 3.登錄成功后能否能否跳轉到正確的頁面 4.檢查能否選擇不同登錄方式進行登錄，如使用手機號登錄、使用微信號登錄或掃碼登錄。 5.記住用戶名的功能 6.登陸失敗后，不能記錄密碼的功能 7.密碼是否非明文顯示顯示，使用星號圓點等符號代替。 8.有驗證碼時，還要考慮文字是否扭曲過度導致辨認難度大，考慮顏色、刷新或換一個按鈕是否好用 9.登錄頁面中的注冊、忘記密碼，登出用另一帳號登陸等鏈接是否正確 10.輸入密碼的時候，大寫鍵盤開啟的時候要有提示信息。 11.什么都不輸入，點擊提交按鈕，檢查提示信息。
二、界面測試
1.布局是否合理，testbox和按鈕是否整齊。 2.testbox和按鈕的長度，高度是否復合要求。 3. 界面的設計風格是否與UI的設計風格統一。 4. 界面中的文字簡潔易懂，沒有錯別字。
三、性能測試
1.打開登錄頁面，需要的時間是否在需求要求的時間內。 2.輸入正確的用戶名和密碼后，檢查登錄成功跳轉到新頁面的時間是否在需求要求的時間內。 3.模擬大量用戶同時登陸，檢查一定壓力下能否正常登陸跳轉。
四、安全性測試
1.登錄成功后生成的Cookie，是否是httponly (否則容易被腳本盜取)。 2.用戶名和密碼是否通過加密的方式，發送給Web服務器。 3.用戶名和密碼的驗證，應該是用服務器端驗證， 而不能單單是在客戶端用javascript 驗證。 4.用戶名和密碼的輸入框，應該屏蔽SQL注入攻擊。 5.用戶名和密碼的的輸入框，應該禁止輸入腳本 （防止XSS攻擊）。 6.防止暴力破解，檢測是否有錯誤登陸的次數限制。 7. 是否支持多用戶在同一機器上登錄。 8. 同一用戶能否在多臺機器上登錄。
五、兼容性測試
1.不同移動平臺或PC環境下下能否顯示正常且功能正常 2.同種平臺下不同微信版本下能否顯示正常且功能正常。 3.不同的分辨率下顯示是否正常。
六、本地化測試
不同語言環境下，頁面的顯示是否正確。
7、請你對朋友圈點贊功能進行測試
答：1.功能測試
是否可以點贊
取消點贊
多次點贊會出現什么情況
多人點贊時的順序是否按照時間順序進行排列
點贊是否顯示頭像和名稱
點贊之后能否進行評論
點贊之后退出該頁面，再次進入朋友圈點贊消息是否還存在
多用戶點贊，再次打開朋友圈是是否可以按照順序看到是誰誰誰贊了我
2.接口測試
點贊之后相同好友是否收到提示信息
相同好友處的提示信息是否按照時間順序
相同好友處的點贊是否顯示頭像和名稱
3.兼容測試
電腦端和手機端是否都可以進行點贊和取消點贊功能
不同的移動端是否都可以行點贊和取消點贊功能（包括蘋果，安卓）
4.可用性測試
弱網的時候進行點贊是什么情況
網絡斷開時是否可以點贊
用戶點擊點贊幾秒后可以看到點贊成功，取消同理
多用戶同時給我點贊時，我是否可以全部接收到提示消息
5.安全性測試
點贊是否會泄漏微信用戶相關信息
8.如果做一個杯子的檢測，你如何測試
答：需求測試：查看杯子的使用說明書，安全說明書等。
功能測試：
1、杯子能否裝水；
2、可以裝多少L的水；
3、杯子是否可以放冰箱；
4、水可不可以被喝到。
安全性測試：
1、杯子有沒有毒和細菌；
2、杯子從高處墜落，是否已破；
3、杯子是否有缺口，容易滑倒嘴巴；
4、將杯子放入微波爐中，是否爆炸或融化；
性能測試：
1、看杯子能夠容納的最大體積和最高溫度；
2、將杯子盛上水，經過24小時后查看杯子的泄露情況和時間(可分別使用水和汽油做測試)；
3、將杯子裝上填充物，看不會摔破的最高度；
4、用根針并在針上面不斷加重量，看壓強多大時會穿透；
可用性測試：杯子是否好拿，是否燙手，是否防滑，是否方便飲用。
兼容性測試：除了裝水，是否還可以裝其它的液體，比如果汁，汽油等。
界面測試：查看杯子的外觀：杯子是什么材質的，顏色，外形，重量，圖案是否合理，是否有異味。
用戶文檔：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述。
9.如何對一個頁面進行測試
答：第一個方法：分類法
界面控件功能按鈕類：
1.比如搜索控件、單程、往返、多程的單選控件
2.選擇單程、往返、多程的單選控件，是否會先在界面上顯示
3.勾選帶兒童、帶嬰兒的界面顯示，以及點擊搜索后，界面跳轉情況
界面檢查類：
界面上有沒有顯示模糊，或者被遮擋的，影響用戶體驗，界面的檢查，注意從兼容性（瀏覽器的兼容性，比如常用的IE、谷歌、360、火狐等），還要從瀏覽器全屏和縮小的使用場景進行測試。
界面跳轉鏈接類：
界面上經常會有跳轉鏈接的功能，這時候我們需要進行測試，這個界面比如“兒童/嬰兒票”
查詢條件或者搜索條件的檢查：
比如下拉框選擇、手動輸入內容進行檢查。輸入框的檢查，需要注意前端界面對輸入框輸入規范的控制，比如：這個輸入框的限制長度，只允許輸入什么類型的字符，當輸入不規范的時候，提示語是否符合用戶體驗
查詢條件
時間的檢查（一般時間的檢查包括：日期+時間：時分秒）
這里日期有出發日期和返回日期，且做了可選擇的操作，同時用戶可以自己輸入，注意一個細節，這個界面在還沒有選擇出發日期前，這個返回日期是置灰的，但是選擇返回日期是可選的。這個時間需要考慮的場景如下：
1：選擇單程的情況下，返回日期小于/大于/等于出發日期
返回日期小于出發日期，是否會友好提示
返回日期大于出發日期，是否能正常跳轉到相應的機票界面
返回日期等于出發日期，是否能正常跳轉到相應的機票界面
2：選擇往返的情況下，返回日期小于/大于/等于出發日期
同上考慮
3：選擇多程的情況下，返回日期小于/大于/等于出發日期
同上考慮
注:
這里還需要考慮今天以前的日期是否可選，站在用戶思維的角度，出行只有正在進行時和將來時，沒有過去時。
第二種方法：探索性測試
站在用戶的角度去使用該界面，隨意操作
界面的功能測試完畢，我們還需要或者還可以做什么？
一個界面，直接面對的是用戶，所以界面的適用性和可用性，對用戶體驗來說是特別重要的。我們可以參考市場上，同類型的產品，進行親身體驗操作，對我們目前的界面提一些建設性的意見。
10.如何對水壺進行測試
答：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）壺在不同地方、溫度環境下都可以正常使用。
11.如何對淘寶搜索框進行測試
答：功能測試
1 輸入關鍵字，查看: 返回結果是否準確，返回的文本長度需限制
1.1輸入可查到結果的正常關鍵字、詞、語句，檢索到的內容、鏈接正確性；
1.2輸入不可查到結果的關鍵字、詞、語句；
1.3輸入一些特殊的內容，如空、特殊符、標點符、極限值等，可引入等價類劃分的方法等；
2 結果顯示：標題，賣家，銷售量，單行/多行，是否有圖片
3 結果排序：價格 銷量 評價 綜合
4 返回結果龐大時，限制第一頁的現實量，需支持翻頁
5 多選項搜索：關鍵字 品牌 產地 價格區間 是否天貓 是否全國購
6 是否支持模糊搜索，支持通配符的查詢
7 網速慢的情況下的搜索
8 搜索結果為空的情況
9 未登錄情況和登錄情況下的搜索（登錄情況下 存儲用戶搜索的關鍵字/搜索習慣）
性能測試
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 對涉及國家安全、法律禁止的內容是否進行了相關的過濾和控制；
12.如何對一瓶礦泉水進行測試
答：測試項目：礦泉水
需求測試:查看使用說明書
界面測試:查看外觀
功能度：用水杯裝水看漏不漏；水能不能被喝到
安全性：瓶子的材質有沒有毒或細菌
可靠性：從不同高度落下的損壞程度
可移植性：再不同的地方、溫度等環境下是否都可以正常使用
兼容性：是否能夠容納果汁、白水、酒精、汽油等
易用性：是否燙手、是否有防滑措施、是否方便飲用
用戶文檔：使用手冊是否對的用法、限制、使用條件等有詳細描述
疲勞測試：將盛上水（案例一）放24小時檢查泄漏時間和情況；盛上汽油（案例二）放24小時檢查泄漏時間和情況等
壓力測試：用根針并在針上面不斷加重量，看壓強多大時會穿透
跌落測試:高度
13、如何測試登陸界面
答：具體需求： 有一個登陸頁面， （假如上面有2個textbox, 一個提交(登陸)按鈕。 請針對這個頁面設計30個以上的TestCase.）
首先，你要了解用戶的需求，比如這個登錄界面應該是彈出窗口式的，還是直接在網頁里面。對用戶名的長度，和密碼的強度（就是是不是必須多少位，大小寫，特殊字符混搭）等。還有比如用戶對界面的美觀是不是有特殊的要求？（即是否要進行UI測試）。剩下的就是設計用例了 ，等價類，邊界值等等。
請你記住一點，任何測試，不管測什么都是從了解需求開始的。
功能測試(Function test)
0. 什么都不輸入，點擊提交按鈕，看提示信息。（非空檢查）
1.輸入正確的用戶名和密碼，點擊提交按鈕，驗證是否能正確登錄。（正常輸入）
2.輸入錯誤的用戶名或者密碼, 驗證登錄會失敗，并且提示相應的錯誤信息。（錯誤校驗）
3.登錄成功后能否能否跳轉到正確的頁面（低）
4.用戶名和密碼，如果太短或者太長，應該怎么處理（安全性，密碼太短時是否有提示）
5.用戶名和密碼，中有特殊字符（比如空格），和其他非英文的情況（是否做了過濾）
6.記住用戶名的功能
7.登陸失敗后，不能記錄密碼的功能
8.用戶名和密碼前后有空格的處理
9.密碼是否加密顯示（星號圓點等）
10.牽扯到驗證碼的，還要考慮文字是否扭曲過度導致辨認難度大，考慮顏色（色盲使用者），刷新或換一個按鈕是否好用
11.登錄頁面中的注冊、忘記密碼，登出用另一帳號登陸等鏈接是否正確
12.輸入密碼的時候，大寫鍵盤開啟的時候要有提示信息。
界面測試(UI Test)
1.布局是否合理，2個testbox 和一個按鈕是否對齊
2.testbox和按鈕的長度，高度是否復合要求
3. 界面的設計風格是否與UI的設計風格統一
4. 界面中的文字簡潔易懂，沒有錯別字。
性能測試(performance test)
1.打開登錄頁面，需要幾秒
2.輸入正確的用戶名和密碼后，登錄成功跳轉到新頁面，不超過5秒
安全性測試(Security test)
1.登錄成功后生成的Cookie，是否是httponly (否則容易被腳本盜取)
2.用戶名和密碼是否通過加密的方式，發送給Web服務器
3.用戶名和密碼的驗證，應該是用服務器端驗證， 而不能單單是在客戶端用javascript驗證
4.用戶名和密碼的輸入框，應該屏蔽SQL注入攻擊
5.用戶名和密碼的的輸入框，應該禁止輸入腳本 （防止XSS攻擊）
6.錯誤登陸的次數限制（防止暴力破解）
7. 考慮是否支持多用戶在同一機器上登錄；
8. 考慮一用戶在多臺機器上登錄
可用性測試(Usability Test)
1. 是否可以全用鍵盤操作，是否有快捷鍵
2. 輸入用戶名，密碼后按回車，是否可以登陸
3. 輸入框能否可以以Tab鍵切換
兼容性測試（Compatibility Test）
1.主流的瀏覽器下能否顯示正常已經功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）
2.不同的平臺是否能正常工作，比如Windows, Mac
3.移動設備上是否正常工作，比如Iphone, Andriod
4.不同的分辨率
本地化測試（Localization test）
1. 不同語言環境下，頁面的顯示是否正確。
軟件輔助性測試 （Accessibility test）
軟件輔助功能測試是指測試軟件是否向殘疾用戶提供足夠的輔助功能
2. 高對比度下能否顯示正常 （視力不好的人使用）
14.請你說一下jmeter
Jmeter：Apache JMeter是Apache組織開發的基于Java的壓力測試工具。用于對軟件做壓力測試，它最初被設計用于Web應用測試，但后來擴展到其他測試領域。 它可以用于測試靜態和動態資源，例如靜態文件、Java 小服務程序、CGI 腳本、Java 對象、數據庫、FTP 服務器， 等等。JMeter 可以用于對服務器、網絡或對象模擬巨大的負載，來自不同壓力類別下測試它們的強度和分析整體性能。另外，JMeter能夠對應用程序做功能/回歸測試，通過創建帶有斷言的腳本來驗證你的程序返回了你期望的結果。為了最大限度的靈活性，JMeter允許使用正則表達式創建斷言。
為什么使用Jmeter：
? 開源免費，基于Java編寫，可集成到其他系統可拓展各個功能插件
? 支持接口測試，壓力測試等多種功能，支持錄制回放，入門簡單
? 相較于自己編寫框架或其他開源工具，有較為完善的UI界面，便于接口調試
? 多平臺支持，可在Linux，Windows，Mac上運行
用例生成與導出：
Jmeter的用例格式為jmx文件，實際為xml格式，感興趣可以學習下自己定制生成想要的jmx文件。
生成原則：
每個功能模塊為一個獨立的jmx文件。增加可維護性。（盡量不要將一個jmx文件放入太多功能，后期維護成本會很高。）
模塊的私有變量保存在模塊中，多模塊共有的（例如服務器ip端口等）可以考慮存在單獨的文件中讀取。
接口測試不要放太多線程，畢竟不是做壓力測試，意義也不大。
導出方法：
編寫測試用例
文件——保存為——確定：
Jmeter運行模式及參數
GUI模式
打開已有的jmx文件（文件——打開）
點擊啟動按鈕運行
命令行模式
依賴：
配置jmeter環境變量（windows下為將${jmeterhome}/bin加入Path變量）
如果未加入環境變量，在執行的時候可以直接給出全路徑或在${jmeterhome}/bin下執行
命令：
jmeter -n -t -l
參數：
-h 幫助 -> 打印出有用的信息并退出
-n 非 GUI 模式 -> 在非 GUI 模式下運行 JMeter
-t 測試文件 -> 要運行的 JMeter 測試腳本文件
-l jtl文件 -> 記錄結果的文件
-r 遠程執行 -> 啟動遠程服務
-H 代理主機 -> 設置 JMeter 使用的代理主機
-P 代理端口 -> 設置 JMeter 使用的代理主機的端口號
-j 日志文件->設置JMeter日志文件的名稱
實例：
JMeter -n -t my_test.jmx -l log.jtl -H my.proxy.server -P 8000
執行步驟：
JMeter 默認去當前目錄尋找腳本文件，并把日志記錄在當前目錄。比如你在 C:\tools\apache-jmeter-2.11\bin 目錄下執行以上命令，JMeter 會去該目錄下尋找 test.jmx 腳本并把執行結果放在該目錄。如果你的腳本在其他目錄，而且想要把執行結果放在另外文件夾，可以使用絕對路徑告訴 JMeter。
執行結果查看：
GUI界面打開聚合報告
在GUI界面創建一個聚合報告
聚合報告界面點擊瀏覽，選中生成的.jtl文件，打開
Jmeter使用
Jmeter創建接口測試計劃實例：
測試用例應該作為測試的基礎內容，而用例的結構可能劃分，則是用例的基礎（忽然在這里想說一下，用例僅僅是一項測試活動的綱要，有最好，沒有的話能保證質量也OK。更不用說用例的格式問題，無論是表格還是導圖，其實都無所謂！本文的用例是指jmx文件中的控件結構）。
? 模塊名稱（測試計劃）：每個模塊獨立劃分為一個jmx文件（例如登陸模塊），最好與接口類一一對應。對應的服務器信息，數據庫信息等可存在這里。
? 數據準備：用于測試數據的準備（例如賬號信息）。
? 結果查看：用于放置需要查看結果的控件（例如結果樹）。
? 線程組：所有的接口測試用例放在線程組下，集中定義線程等信息
? 獲取線程對應測試數據：用于獲取針對獨立線程的測試數據，例如在數據準備里面獲得了賬號信息，在這里根據賬號信息去數據庫獲取對應的名稱，ID等信息。
? 請求名稱：用簡單控制器為文件夾，內有不同的請求。簡單控制器為一個獨立的接口，不同請求對應不同的代碼路徑（例如成功請求，失敗請求等）。建議請求名稱最好用英文形式，否則后期持續集成或許會出現問題（no zuo no die！）。
? 在每條請求內放置正則匹配（用于應對需要返回值作為下次請求的參數的情況）以及斷言。
15.請你進行測試：前端下拉框實現，測試下拉框定位方式
鏈接: Selenium+Python自動化測試對下拉菜單的定位
鏈接: 【Selenium自動化測試】多種下拉框定位及選擇
16.請你來聊一聊appium斷言
17.請你來說一下購物車的測試用例
答：界面測試
界面布局、排版是否合理
文字是否顯示清晰
不同賣家的商品是否區分明顯
功能測試
未登錄時
將商品加入購物車，頁面跳轉到登錄頁面，登陸成功后購物車數量增加
點擊購物車菜單，頁面跳轉到登陸頁面
登錄后
所有連接是否跳轉正確
商品是否可以成功加入購物車
購物車總數是否有限制
商品總數是否正確
全選功能是否好用
刪除功能是否好用
價格總計是否正確
商品文字太長時是否顯示完整
店鋪名字太長時是否顯示完整
購物車中下架的商品是否有標注
新加入購物車商品排序（添加購物車中存在店鋪的商品和購物車中不存在店鋪的商品）
是否支持TAB/ENTER等快捷鍵
商品刪除后商品總數是否減少
購物車結算功能是否好用
將商品移入收藏夾功能是否好用
兼容性測試
不同瀏覽器測試
pc端和移動端
ios和安卓
易用性測試
刪除功能是否有提示
是否有回到頂部功能
性能測試
壓力測試
并發測試
18.請你進行一下弱網模擬
答：方法一：charles弱網模擬
配置參數解析：
bandwidth —— 帶寬，即上行、下行數據傳輸速度
utilisation —— 帶寬可用率，大部分modern是100%
round-trip latency —— 第一個請求的時延，單位是ms。
MTU —— 最大傳輸單元，即TCP包的最大size，可以更真實模擬TCP層，每次傳輸的分包情況。
Releability —— 指連接的可靠性。這里指的是10kb的可靠率。用于模擬網絡不穩定。
Stability —— 連接穩定性，也會影響帶寬可用性。用于模擬移動網絡，移動網絡連接一般不可靠。
使用chrome的webview調試工具，缺點是只適用于web頁面的弱網模擬。
方法二：chrome的webview調試工具弱網模擬
使用chrome的webview調試工具，缺點是只適用于web頁面的弱網模擬。
具體步驟：
（1）應用打開webview調試功能，具體如下：
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
（2）手機鏈接電腦，運行APP，進入具體H5頁面；
（3）chrome的DevTools中打開Webview：進入chrome://inspect/#devices，會顯示已經連接設備，選中待調試webview的inspect
network頁面，No throttling下拉框，可以進行網絡模擬。
方法三：iOS手機自帶Network Link Conditioner 弱網模擬
iPhone手機打開開發者選項，具體參考：
設置-開發者選項 > Network Link Conditioner 入口。
系統已經內置常見網絡配置，也可以增加自定義配置。
具體配置參數：
in Bandwidth 下行帶寬，即下行網絡速度
In packet loss 下行丟包率
in delay 下行延遲，單位ms
out bandwidth 上行帶寬
out packet loss 上行丟包率
out delay 上行延遲
DNS delay DNS解析延遲
protocol 支持Any，IPV4、IPV6
interface 支持Any，WI-Fi，cellular（蜂窩網）
19、你寫的測試程序是怎么樣的，你寫過前端、后端程序嗎？
答：我寫的測試程序是用Java語言的Junit測試框架實現的
比如：
前端和后端不同開發工具需要編寫程序進行跨域處理，然后前端程序才能通過Ajax從后端獲取文本數據，后端程序是通過連接數據庫編寫sql語句來操作數據的。
20、請問你有沒有寫過測試腳本，怎么寫的？
答：寫過性能測試-用戶登錄測試腳本
#!/bin/sh # 用戶登錄信息監控測試 # 能夠顯示最近幾次、截止某一日期用戶登錄情況： # 能夠現實當前系統最近重啟情況 # #步驟1 test_title="用戶登錄信息監控測試 " expect_result1=" 預期結果：能夠顯示最近幾次、截止某一日期用戶登錄情況" result_path=./ echo -e "\n" >> ${result_path}test_102_result.txt date >> ${result_path}test_102_result.txt echo ${test_title} >> ${result_path}test_102_result.txt echo -e >> ${result_path}test_102_result.txt echo ${ecpect_result1} >> ${result_path}test_102_result.txt(who /var/log/wtmp) >> ${result_path}test_102_result.txt 2>&1#步驟2 expect_result2="預期結果：能夠顯示當前系統最近重啟的情況" echo -e >> ${result_path}test_102_result.txt echo ${expect_result2} >> ${result_path}test_102_result.txt echo -e >> ${result_path}test_102_result.txt (last | grep reboot) >> ${result_path}test_102_result.txt 2>&1 echo -e "\n" >> ${result_path}test_102_result.txt21、請問你有沒有寫過web測試，怎么寫的？
答：Web測試主要從下面幾個大方向考慮
功能測試，主要做鏈接測試，表單測試，cookies測試，設計語言測試等
性能測試，考慮連接速度測試，以及負載測試，例如：Web應用系統能允許多少個用戶同時在線？如果超過了這個數量，會出現什么現象？Web應用系統能否處理大量用戶對同一個頁面的請求？還有壓力測試
可用性測試，比如導航測試，圖形測試，內容測試，整體界面測試等
兼容性測試，市場上有很多不同的操作系統類型，最常見的有Windows、Unix、Macintosh、Linux等。Web應用系統的最終用戶究竟使用哪一種操作系統，取決于用戶系統的配置。這樣，就可能會發生兼容性問題，同一個應用可能在某些操作系統下能正常運行，但在另外的操作系統下可能會運行失敗。因此，在Web系統發布之前，需要在各種操作系統下對Web系統進行兼容性測試。
安全性測試，
（1）現在的Web應用系統基本采用先注冊，后登陸的方式。因此，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。
（2）Web應用系統是否有超時的限制，也就是說，用戶登陸后在一定時間內（例如15分鐘）沒有點擊任何頁面，是否需要重新登陸才能正常使用。
（3）為了保證Web應用系統的安全性，日志文件是至關重要的。需要測試相關信息是否寫進了日志文件、是否可追蹤。
（4）當使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。
（5）服務器端的腳本常常構成安全漏洞，這些漏洞又常常被黑客利用。所以，還要測試沒有經過授權，就不能在服務器端放置和編輯腳本的問題。
23、請你回答一下如何測試手機開機鍵？
答：功能測試：
按下開機鍵，屏幕能否亮起
性能測試：
按下開機鍵，屏幕能否在規定時間內亮起
壓力測試
連續多次按下開機鍵，觀察屏幕是否能一直亮起，到多久時間失靈
健壯性測試
給定一個中了病毒的手機或者是淘汰許久的老機子，安歇開機鍵觀察屏幕能否亮起
可靠性測試
連續按下開機鍵有限次數，比如1萬次，記錄屏幕未亮起的次數
可用性測試
開機鍵按下費不費力，開機鍵的形狀設計是否貼合手指，開機鍵的位置設計是否方便
24、請問你遇到過哪些印象深刻的bug，接口測試出現bug的原因有哪些？
答：WEB測試常見BUG：
1、翻頁
翻頁時，沒有加載數據為空，第二頁數據沒有請求
翻頁時，重復請求第一頁的數據
翻頁時，沒有圖片的內容有時候會引用有圖片的內容
2、圖片數據為空
圖片數據為空時，會保留為空的圖片數據位置
3、鏈接為空
鏈接為空時，點擊圖片，會刷新頁面
4、服務端部分字段為空
整個頁面出現空白
5、session過期
session過期后，可能整個頁面的數據就會丟失，頁面呈現空白6、文字內容過多
文字內容過多時，頁面排版錯亂
7、不同平臺的瀏覽器，功能、樣式問題
PC與手機瀏覽器，同段代碼會展示不同的樣式
同個功能在不同的瀏覽器上面，功能會出現失效的現象
8、彈窗，針對圖片彈窗
不同的手機，彈窗處理機制會不一樣，導致有些手機點擊彈窗按鈕，彈窗不會出現
9、第三方應用，訪問網頁
會偶爾出現，HTML+CSS樣式不起任何作用，頁面呈現空白（遇見過，無復現）
第三方應用登錄網頁后，登錄賬戶錯亂
第三方應用分享，微信、QQ、微博三種分享渠道，有三種不一樣的分享機制
10、音頻網頁
不同手機、不同的系統版本，有些手機進入網頁后，音頻效果會自動播放，相反有些手機需要點擊播放按鈕，才能播放
11、自動檢測是否安裝應用
有些手機上是安裝過應用的，通過手機瀏覽器打開此應用的任何頁面，頁面頂部會不會自動判斷是否安裝此應用，有些手機可以自動檢測，但部分手機是不可以檢測的，安卓手機偏多，iPhone手機也不少
12、cookie過期
WEB系統基本上會用到cookie，如果cookie未在預定的時間內進行保存，刷新頁面，會對cookie有影響
13、鏈接正確性
鏈接未按指定的跳轉
所跳轉的鏈接不存在
鏈接不正確跳轉
14、導航測試
WEB基本上每個頁面頂部都會有導航，看下導航是否為死導航、亂導航等
15、分辨率
頁面文字及樣式，應支持常見的分辨率
16、文本字符
簡單的文本字符判斷，像手機號不能輸入非數字以外的字符
17、性能測試
請求數據時的響應，會不會很久才會請求到數據
18、圖片測試
正常的圖片展示，是否會模糊
圖片是否會截斷及壓縮
圖片格式的處理，JPG、PNG、GIF
19、客戶端兼容性
平臺兼容性，第三方客戶端應用內引用web頁面，主要是Android與IOS系統
瀏覽器兼容性
20、整體界面測試
整體界面的樣式、文字排列、圖片展示等
PS：
session與cookie的區別：
session是保存在服務器上面的，cookie是保存在本地的，本地cookie向服務端請求時，會在coolie中帶一個session id向服務端發出數據請求，而服務端會根據這個session id去找到這個session文件，然后進行數據處理。
接口測試
一、接口參數數據類型：
二、接口測試常見bug：
例如:無權限可以訪問，或者 一般用戶可以訪問管理員權限）
例如：某網站兌換1塊錢需要100幣，當小于100幣時調用后臺 接口是否可以兌換
例如：購物結算時為100元，調用 后臺接口設為0元，哈哈
25、你在做項目中有做過壓力測試嗎，怎么做
答：1、首先對要測試的系統進行分析，明確需要對那一部分做壓力測試，比如秒殺，支付
2、如何對這些測試點進行施壓
第一種方式可以通過寫腳本產生壓力機器人對服務器進行發包收報操作
第二點借助一些壓力測試工具比如Jmeter,LoadRunner
3、如何對這些測試點進行正確的施壓
需要用壓力測試工具或者其他方法錄制腳本，模擬用戶的操作
4、對測試點設計多大的壓力比較合適？
需要明確壓力測試限制的數量，即用戶并發量
5、測試結束后如何通過這些數據來定位性能問題
通過測試可以得到吞吐量，平均響應時間等數據，這個數據的背后是整個后臺處理邏輯綜合作用的結果，這時候就可以先關注系統的CPU，內存，然后對比吞吐量，平均響應時間達到瓶頸時這些數據的情況，然后就能確認性能問題是系統的哪一塊造成的
26、請問你在項目中關于功能測試和接口測試是怎么做的
答：功能測試：
首先制定測試計劃，然后進行測試設計，將在測試計劃階段指定的測試活動分解，進而細化，為若干個可執行程序的子測試過程，然后執行測試，按照測試計劃使用測試用例對待測項目進行逐一的，詳細的排查分析評估，最后對測試結果進行統計和分析，
接口測試：
什么是接口（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. 執行測試，查看不同的參數請求，接口的返回的數據是否達到預期。
27、請問你有用過什么測試工具嗎，用過哪些？
答： AppUI自動化測試
Appium 是一個移動端自動化測試開源工具，支持iOS 和Android 平臺，支持Python、Java 等語言，即同一套Java 或Python 腳本可以同時運行在iOS 和Android平臺，Appium 是一個C/S 架構，核心是一個 Web 服務器，它提供了一套 REST 的接口。當收到客戶端的連接后，就會監聽到命令，然后在移動設備上執行這些命令，最后將執行結果放在 HTTP 響應中返還給客戶端。
WebUI自動化測試
Selenium是一個用于Web應用程序測試的工具。Selenium測試直接運行在瀏覽器中，就像真正的用戶在操作一樣。支持的瀏覽器包括IE(7、8、9)、Mozilla Firefox、Mozilla Suite等。這個工具的主要功能包括：測試與瀏覽器的兼容性——測試你的應用程序看是否能夠很好得工作在不同瀏覽器和操作系統之上。測試系統功能——創建回歸測試檢驗軟件功能和用戶需求。支持自動錄制動作和自動生成 .Net、Java、Perl等不同語言的測試腳本。Selenium 是ThoughtWorks專門為Web應用程序編寫的一個驗收測試工具。其升級版本為Webdriver。
Jmeter接口測試，性能測試
JMeter是Apache組織的開放源代碼項目，它是功能和性能測試的工具，100%的用java實現；
JMeter可以用于測試靜態或者動態資源的性能（文件、Servlets、Perl腳本、java對象、數據庫和查詢、ftp服務器或者其他的資源）。JMeter用于模擬在服務器、網絡或者其他對象上附加高負載以測試他們提供服務的受壓能力，或者分析他們提供的服務在不同負載條件下的總性能情況。你可以用JMeter提供的圖形化界面分析性能指標或者在高負載情況下測試服務器/腳本/對象的行為。
接口測試
Postman 提供功能強大的 Web API 和 HTTP 請求的調試，它能夠發送任何類型的HTTP 請求 (GET, POST, PUT, DELETE…)，并且能附帶任何數量的參數和 Headers。不僅如此，它還提供測試數據和環境配置數據的導入導出，付費的 Post Cloud 用戶還能夠創建自己的 Team Library 用來團隊協作式的測試，并能夠將自己的測試收藏夾和用例數據分享給團隊。
Jenkins持續集成
自動化構建 編譯，部署，任務執行，測試報告，郵件通知等。
28、請你設計一個微信朋友圈點贊的測試用例
答：功能測試：
點贊某條朋友圈，驗證是否成功
接口測試：
點贊朋友圈，驗證朋友能否收到提示信息
性能測試
點贊朋友圈，是否在規定時間顯示結果，是否在規定時間在朋友手機上進行提示
兼容性測試
在不同的終端比如ipad,手機上點贊朋友圈，驗證是否成功
29、請問如果用戶點擊微博的關注圖標但是app上面沒有反應，應該怎么排查這個問題
答：先排除手機是否出現故障
在排除手機網絡是否穩定，換一個穩定的網絡再試一次，因為在弱網或者沒網的情況下也會出現該類問題
若手機網絡環境差或者無網絡連接，還要驗證是否有關于網絡差的提示。
判斷是否手機內存溢出
看該用戶關注人數是否已達上線，普通用戶上限2000，會員用戶最高上限可3000
若達到上限，可能返回提示信息出錯
可能是版本問題或者是安裝包問題
更新應用
重新安裝
在debug模式下，查看app的線程列表，看線程是否卡主。
30、在做測試的過程中，假如前端和后端吵起來了都在踢皮球覺得對方該改代碼，你怎么辦？
答：找技術領導或者leader們基于安全性、性能、可測性、可維護性討論敲定一個解決方案，做到開發環境方便開發，線上環境少配置、少依賴、少出錯機會。
31、如果廣東用戶頭條app刷不出東西了，你應該怎么排查問題
答：先排除手機是否出現故障
在排除手機網絡是否穩定，換一個穩定的網絡再試一次，因為在弱網或者沒網的情況下也會出現該類問題
若手機網絡環境差或者無網絡連接，還要驗證是否有關于網絡差的提示。
判斷是否手機內存溢出
看該用戶關注人數是否已達上線，普通用戶上限2000，會員用戶最高上限可3000
若達到上限，可能返回提示信息出錯
可能是版本問題或者是安裝包問題
更新應用
重新安裝
在debug模式下，查看app的線程列表，看線程是否卡主。
32、請你說一下能不能用機器學習去進行自動化測試，如何監控異常流量，如果是脈沖呢，如何和正常流量作區分
答：如何用機器學習去進行自動化測試，就是讓自動化測試變得更加智能，在自動化測試過程中，當測試功能模塊越來越多，沒有太多的時間去全部覆蓋，我們可以采用歸納學習的方式，基于自動化測試的執行結果或者手工測試執行的結果為數據輸入，然后基于一定的模型（例如：以通過率和模塊的重要率計算的平均值）得出測試推薦模塊，或者當要執行一個功能模塊時，基于歷史數據和模型（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
33、請問如何將大量日志的異常記錄或錯誤揪出來
鏈接: 為了方便查找服務器的運行原因，最好對錯誤日志進行記錄，那么該如何記錄日志呢？
按Ctrl+F 查找error和exception關鍵字
34、請問如何對登錄界面進行測試
35、請你說一說當前工作中涉及的測試問題(測試流程和測試性能)
答：需求分析，測試計劃，測試設計，測試環境搭建，測試執行，測試記錄，缺陷管理，軟件評估，測試總結，測試維護
36、請你說一說洗牌問題的思路并手寫代碼，并設計測試用例
答：洗牌問題：有個長度為2n的數組{a1,a2,a3,…,an,b1,b2,b3,…,bn}，希望排序后{a1,b1,a2,b2,….,an,bn}，請考慮有無時間復雜度o(n)，空間復雜度0(1)的解法。
void PerfectShuffle(int A,int n){
if(n <= 1){
return;
}//if
//
int size = 2n;
int index,count;
for(int i = n;i < size;++i){
// 交換個數
count = n - (i - n) - 1;
// 待交換
index = i;
for(int j = 1;j <= count;++j){
swap(A[index],A[i-j]);
index = i - j;
}//for
}//for
}
};
可以就數組的類型，可以是int型的，浮點型的，還可以是大數類型，負數，進行測試。
37、請你測試一下游戲中英雄的技能
答：去實戰模擬測試，技能效果：生成的buff與debuff，造成傷害，作用范圍，造成傷害時間點與動畫匹配。 特殊：沖突性檢測，該角色該技能的釋放，能否取消后搖，能否隱藏掩蓋前搖，釋放過程自身的硬直時間段。從動畫哪一段開始生效，buff與傷害的同時性。buff與其他buff的沖突問題。多段傷害生效先后問題。 最終，角色技能的設計預期是否匹配是最重要的，如果沒有這樣的預期，就需要考慮整體平衡性問題。
38、請你回答一下性能測試有哪些指標，對一個登錄功能做性能測試，有哪些指標，怎么測出可同時處理的最大請求數量？
答：性能測試常用指標：
從外部看，主要有
1、吞吐量：每秒鐘系統能夠處理的請求數，任務數
2、響應時間：服務處理一個請求或一個任務的耗時
3、錯誤率：一批請求中結果出錯的請求所占比例
從服務器的角度看，性能測試關注CPU，內存，服務器負載，網絡，磁盤ＩＯ
對登錄功能做性能測試
單用戶登陸的響應界面是否符合預期
單用戶登陸時后臺請求數量是否過多
高并發場景下用戶登錄的響應界面是否符合預期
高并發場景下服務端的監控指標是否符合預期
高集合點并發場景下是否存在資源死鎖和不合理的資源等待
長時間大量用戶連續登錄和登出，服務器端是否存在內存泄漏
怎么測出可同時處理的最大請求數量
可以采用性能測試工具(WeTest服務器性能)，該工具是騰訊wetest團隊出品，使用起來很簡單方便，但測試功能相當強大，能提供10w+以上的并發量，定位性能拐點，測出服務器模型最大并發
39、請問你有沒有做過什么單元測試，怎么進行單元測試，對一個沒有參數沒有返回值但可能對全局變量有影響的怎么進行單元測試
答：如何進行單元測試：
１、創建單元測試，該工具可以對任何類、接口、結構等實體中的字段、屬性、構造函數、方法等進行單元測試。創建單元測試大致可以分為兩類：
整體測試，整體測試是在類名稱上右擊鼠標，在下拉菜單中點擊創建單元測試選項。這樣就可以為整個類創建單元測試了，這時他會為整個類可以被測試的內容全部添加測試方法。開發人員直接在這些自動生成的測試方法中添加單元測試代碼就可以了。
單獨測試，如果只想單獨對某個方法、屬性、字段進行測試，則可以將鼠標焦點放在這個待測試的項目名稱之上，然后點擊鼠標右鍵，在右鍵菜單中選擇創建單元測試選項。這樣就可以單獨為某個方法創建單元測試了。
運行單元測試
查看測試結果
編寫單元測試代碼
測試沒有參數的函數，它可能還有別的輸入，例如全局變量，成員變量，或調用子函數獲得的輸入（這個要使用工具才能做到），只要函數需讀取的，都應該設定初始值，如果完全沒有，沒有輸入也是一種輸入，照樣測試就是了。同樣道理，輸出也不僅僅是返回值，沒有返回值還可能修改了全局變量什么的，這些也是要判斷的輸出。
40、請問你有沒有做過壓力測試
答：1、首先對要測試的系統進行分析，明確需要對那一部分做壓力測試，比如秒殺，支付
2、如何對這些測試點進行施壓 第一種方式可以通過寫腳本產生壓力機器人對服務器進行發包收報操作 第二點借助一些壓力測試工具比如Jmeter,LoadRunner
3、如何對這些測試點進行正確的施壓 需要用壓力測試工具或者其他方法錄制腳本，模擬用戶的操作
4、對測試點設計多大的壓力比較合適？ 需要明確壓力測試限制的數量，即用戶并發量
5、測試結束后如何通過這些數據來定位性能問題 通過測試可以得到吞吐量，平均響應時間等數據，這個數據的背后是整個后臺處理邏輯綜合作用的結果，這時候就可以先關注系統的CPU，內存，然后對比吞吐量，平均響應時間達到瓶頸時這些數據的情況，然后就能確認性能問題是系統的哪一塊造成的
41、對于有系統大量并發訪問，你會如何做測試，有什么建議
答：如何做高并發系統的測試，一般而言，整體的測試策略是：先針對部分系統進行性能測試及壓力測試，得到各部分的峰值處理性能，再模擬整體流程測試，重點測試整體業務流程以及業務預期負荷，著重測試以下幾點：
1、不同省份，不同運營商CDN節點性能，可采用典型壓力測試方案
2、核心機房BGP網絡帶寬，此部分重點在于測試各運行商的BGP網絡可靠性，實際速率，一般采用smokeping,lxChariot等工具
3、各類硬件設備性能，一般采用專業的網絡設備測試工具
4、各類服務器并發性能，分布式處理能力，可采用壓力測試方案工具
5、業務系統性能，采用業務系統壓力測試方案
6、數據庫處理性能，這部分需要結合業務系統進行測試，以獲取核心業務場景下的數據庫的TPS/QPS，
7、如果有支付功能，需要進行支付渠道接口及分流測試，此部分相對而言可能是最大的瓶頸所在，此外還涉及備份方案，容災方案，業務降級方案的測試。
總結
- 上一篇： LeetCode20——Valid Pa
- 下一篇： Keras 中文文档地址