一、問答題

1、自動化代碼中，用到了哪些設計模式？

答：自動化代碼用到過的設計模式：

①單例設計模式

②工廠模式

③PO設計模式

④數據驅動模式

⑤面向接口編程設計模式

2、什么是Selenium

答：Selenium是一個開源的web自動化測試框架，支持多種編程語言開發自動化測試腳本，支持跨瀏覽器平臺進行測試

3、TestNG中注解有哪些？

答：@Test，@BeforeSuite,@AfterSuite,@BeforeTest,@AfterTest,@BeforeClass,@AfterClass,@BeforeMethod,@AfterMethod,@DataProvider

4、什么是斷言？

答：斷言Assert用于在代碼中驗證實際結果是不是符合預期結果，如果測試用例執行失敗會拋出異常并提供斷言日志

5、TestNG有哪些有點？

答：TestNG的注釋非常強大和方便，TestNG允許并行測試，并可以基于group的方式執行測試，還可以生成測試報表，并且報告展示多樣化，可在其基礎上自行開發測試報告插件以及測試監聽器

6、什么是web自動化測試？

答：web自動化測試指的是從UI（用戶界面）層面進行的自動化測試，測試人員通過編程自動化程度（測試用例腳本）來打開瀏覽器測試網站的業務邏輯

7、寫出Selenium中你最熟悉的接口或類？

答：webDriver、lnternetExplorerDriver、FirefoxDriver、ChromeDriver、WebElement、WebDriverWait、By

8、元素定位類型有哪些？

答：By類一共有8中元素定位方式，他們都是靜態方法：

By.id(),By.name(),By.tagName(),By.className(),By.cssSelector(),By.linkText(),By.partialLinText(),By.xpath()

9、登錄按鈕除了用click方法進行點擊以外還有其他方式么？

答：還可以使用submit（）方法，前提是input元素的type為submit

10、怎么對含有驗證碼的功能進行自動化測試的？

答：1）圖像識別，技術難度大，效果不佳，不推薦

2）屏蔽驗證，邀請開發處理，但在預生產環境或者生產環境不推薦

3）萬能驗證碼，使用一個負責的其他人無法猜到的驗證碼

11、怎么驗證復選按鈕是不是被選中？

答：可以使用元素的isSelected（）方法，如果返回的是true則說明被選中，否則表明未被選中

12、如何處理alert彈窗？

答：處理alert彈窗首先需要先跳轉到alert上，然后在點擊確定或者取消按鈕，

Alert alet=driver.switchTo().alert();//切換到alert

alert…accept();//確定

alert.dismiss();//取消

13、如何用webdriver進行鼠標右鍵點擊操作？

答：使用Actions類

Actions actions=new Actions(driver);

actions.moveToElement(element).perform();

actions.contextClick().perform();

14、舉一個webDriver中方法重載的例子？

答：frame(string nama),frame(int index),

frame(WebElement element)

15、下拉菜單中如何去選擇一個菜單項？

答：如果下拉菜單是select標簽，使用方法：

selectByValue()或者是selectBylndex()或者selectByVisibleText()即可

如果這個下拉菜單不是通過select標簽創建，則直接通過xpath定位元素然后去點擊選擇

16、你的自動化用例的執行策略是什么？

答：自動化測試與軟件開發本質上是一樣的，利用自動化測試工具，經過測試需求分析，設計出自動

化測試用例，從而搭建自動化測試的框架，設計與編寫自動化腳本，驗證測試腳本的正確性，最終完

成自動化測試測試腳本（即主要功能為測試的應用軟件）并輸出測試結果

自動化測試的時候是不是需要連接數據庫做數據校驗？

從數據庫層面來進行數據校驗可以更方便驗證系統的數據處理方面是否正確，數據處理邏輯正常后，

UI層面上的校驗也是需要做的。

17、id,name,class,xpath, css selector這些屬性，你最偏愛哪一種，為什么？

答：css 、xpath 幾乎所有的元素都可以定位到,但是它們的短處在于頁面上更改了元素后位置很容易

改變，所以首先使用的還是id或者name等。

18、APP 測試常見的嚴重問題有哪些？ 分別引起的原因有哪些？

答：常見的有 crash、ANR（應用無響應、卡死），一般由設備碎片化、網絡波動大、內存泄漏、代

碼編寫錯誤

19、app 測試有哪幾種環境？

答：本地環境： app 安裝的手機環境和電腦搭建的自動化測試環境（比如安卓 SDK 等等） 。

服務器環境： war 包部署的服務器， 服務器可以通過瀏覽器訪問， 也可以通過 app 去訪問。（訪問

的是 web 程序的接口）

20、簡單介紹一下 Android SDK 的安裝步驟：

答： 下載 jdk 和安卓 sdk

安裝 jdk， 配置環境變量（java_home、 classpath、 path）

21、當一個接口出現異常時候，你是如何分析異常的？

答：先抓包，用fiddler（charles）工具抓包，或者瀏覽器上F12調試工具；APP上的話，那就用

Fiddler做代理，通過手機設置代理去看請求和返回報文；

查看后端日志，如Linux系統通過xhell連上服務器，查看接口日志，查看是否有報錯信息（命令：tail -

f 日志文件）；

22、如何分析一個bug是前端還是后端的？

答：平常提bug的時候，前端開發和后端開發總是扯皮，不承認是對方的bug。

這種情況很容易判斷，先抓包看請求報文，對著接口文檔，看請求報文有沒問題，有問題就是前端發

的數據不對

以上資料我把它無償分享出來。關注微信公眾號：【傷心的辣條】，即可獲取~

二、面試基礎題

簡述測試流程:

1、閱讀相關技術文檔（如產品PRD、UI設計、產品流程圖等）。

2、參加需求評審會議。

3、根據最終確定的需求文檔編寫測試計劃。

4、編寫測試用例（等價類劃分法、邊界值分析法等）。

5、用例評審(主要參與人員：開發、測試、產品、測試leader)。

6、開發提交代碼至SVN或者GIT ，配管搭建測試環境。

7、執行測試用例，記錄發現的問題。

8、驗證bug與回歸測試。

9、編寫測試報告。

10、產品上線。

補充測試用例設計過程：

根據需求得出測試需求

設計測試方案，評審測試方案

方案評審通過后，設計測試用例，再對測試用例進行評審

什么是軟件測試？軟件測試的目的與原則

使用人工或自動手段，來運行或測試某個系統的過程。其目的在于檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別。

軟件測試的目的：

測試是程序的執行過程，目的在于發現錯誤。

一個成功的測試用例在于發現至今未發現的錯誤。

一個成功的測試是發現了至今未發現的錯誤的測試。

確保產品完成了它所承諾或公布的功能，并且用戶可以訪問到的功能都有明確的書面說明。

確保產品滿足性能和效率的要求。

確保產品是健壯的和適應用戶環境的。

問：軟件生存周期及其模型是什么？

軟件生存周期是軟件開發全部過程、活動和任務的結構框架，是從可行性研究到需求分析、軟件設計、編碼、測試、軟件發布維護的過程。在經歷需求、分析、設計、實現、部署后，軟件將被使用并進入維護階段，直到最后由于缺少維護費用而逐漸消亡。這樣的一個過程，稱為"生命周期模型"（Life Cycle Model）。

什么是軟件質量？

軟件質量：軟件產品的特性可以滿足用戶的功能、性能需求的能力。

自動化測試腳本開發的主要步驟:

1、通過某些方式定位到我們要執行的對象、目標( Target)

2、對這個對象進行什么操作(command)

3、通過操作對定位到的元素賦值(value)

4、添加斷言操作

目前主要的測試用例設計方法是什么？

白盒測試： 邏輯覆蓋、循環覆蓋、基本路徑覆蓋

黑盒測試： 邊界值分析法、等價類劃分、錯誤猜測法、因果圖法、狀態圖法、測試大綱法、隨機測試場景法

常見的測試用例設計方法都有哪些?請分別以具體的例子來說明這些方法在測試用例設計工作中的應用

1）等價類劃分劃分

等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對于揭露程序中的錯誤都是等效的。并合理地假定:測試某等價類的代表值就等于對這一類其它值的測試。因此，可以把全部輸入數據合理劃分為若干等價類，在每一個等價類中取一個數據作為測試的輸入條件，就可以用少量代表性的測試數據。取得較好的測試結果。等價類劃分可有兩種不同的情況:有效等價類和無效等價類。

2）邊界值分析法

邊界值分析方法是對等價類劃分方法的補充。測試工作經驗告訴我，大量的錯誤是發生在輸入或輸出范圍的邊界上，而不是發生在輸入輸出范圍的內部。因此針對各種邊界情況設（面試題目：什么樣的工作環境適合你&#from一個常見的軟件測試面試題來自end#lt；結束）計測試用例，可以查出更多的錯誤。

使用邊界值分析方法設計測試用例，首先應確定邊界情況。通常輸入和輸出等價類的邊界，就是應著重測試的邊界情況。應當選取正好等于，剛剛大于或剛剛小于邊界的值作為測試數據，而不是選取等價類中的典型值或任意值作為測試數據。

3）錯誤推測法

基于經驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法。

錯誤推測方法的基本思想：列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況，根據他們選擇測試用例。例如，在單元測試時曾列出的許多在模塊中常見的錯誤。以前產品測試中曾經發現的錯誤等，這些就是經驗的總結。還有，輸入數據和輸出數據為0的情況。輸入表格為空格或輸入表格只有一行。這些都是容易發生錯誤的情況。可選擇這些情況下的例子作為測試用例。

4）因果圖方法

前面介紹的等價類劃分方法和邊界值分析方法，都是著重考慮輸入條件，但未考慮輸入條件之間的聯系，相互組合等。考慮輸入條件之間的相互組合，可能會產生一些新的情況。但要檢查輸入條件的組合不是一件容易的事情，即使把所有輸入條件劃分成等價類，他們之間的組合情況也相當多。因此必須考慮采用一種適合于描述對于多種條件的組合，相應產生多個動作的形式來考慮設計測試用例。這就需要利用因果圖(邏輯模型)。因果圖方法最終生成的就是判定表。它適合于檢查程序輸入條件的各種組合情況。

5）正交表分析法

有時候，可能因為大量的參數的組合而引起測試用例數量上的激增，同時，這些測試用例并沒有明顯的優先級上的差距，而測試人員又無法完成這么多數量的測試，就可以通過正交表來進行縮減一些用例，從而達到盡量少的用例覆蓋盡量大的范圍的可能性。

6）場景分析方法

指根據用戶場景來模擬用戶的操作步驟，這個比較類似因果圖，但是可能執行的深度和可行性更好。

測試的策略有哪些?

黑盒/白盒/灰盒，靜態/動態，手工/自動，冒煙測試，回歸測試，公測（Beta測試的策略）

補充：公測是什么?還有沒有其他的測試策略？測試策略和測試方法以及測試類型有什么區別？

按測試 策略分類：

1、靜態與動態測試

2、黑盒與白盒測試

3、手工和自動測試

4、冒煙測試

5、回歸測試；

按測試階段分類：單元測試、集成測試、系統測試；

其他常見測試方法：1、功能測試 2、性能測試 3、壓力測試 4、負載測試 5、易用性測試 6、安裝測試 7、界面測試 8、配置測試 9、文檔測試 10、兼容性測試 11、安全性測12、恢復測試

α測試是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試，Alpha 測試不能由程序員或測試員完成。

β測試是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者通常不在測試現場，Beta 測試不能由程序員或測試員完成。

回歸測試（對軟件的新版本測試時，重復執行上一個版本測試時的用例，是為了驗證缺陷是否真正修復，確認修復后是否影響其它功能）；

冒煙測試：對新版本測試之前，先驗證下軟件的基本功能是否實現，是否具備可測性。

單元測試的策略有哪些？

邏輯覆蓋、循環覆蓋、同行評審、桌前檢查、代碼走查、代碼評審、景泰數據流分析

正交表測試用例設計方法的特點是什么？

答：用最少的實驗覆蓋最多的操作，測試用例設計很少，效率高，但是很復雜；對于基本的驗證功能，以及二次集成引起的缺陷，一般都能找出來；但是更深的缺陷，更復雜的缺陷，還是無能為力的；具體的環境下，正交表一般都很難做的。大多數，只在系統測試的時候使用此方法。

補充：什么時候用系統測試，測試的每個階段是什么，比如單元、集成、系統、公測，每個階段需要什么技術，有什么要求

軟件的安全性應從哪幾個方面去測試？

(1) 用戶認證機制：如數據證書、智能卡、雙重認證、安全電子交易協議

(2) 加密機制

(3) 安全防護策略：如安全日志、入侵檢測、隔離防護、漏洞掃描

(4) 數據備份與恢復手段：存儲設備、存儲優化、存儲保護、存儲管理

(5) 防病毒系統

軟件安全性測試包括程序、數據庫安全性測試。根據系統安全指標不同測試策略也不同。

用戶認證安全的測試要考慮問題：

明確區分系統中不同用戶權限

系統中會不會出現用戶沖突

系統會不會因用戶的權限的改變造成混亂

用戶登陸密碼是否是可見、可復制

是否可以通過絕對途徑登陸系統（拷貝用戶登陸后的鏈接直接進入系統）

用戶退出系統后是否刪除了所有鑒權標記，是否可以使用后退鍵而不通過輸入口令進入系統

系統網絡安全的測試要考慮問題

測試采取的防護措施是否正確裝配好，有關系統的補丁是否打上

模擬非授權攻擊，看防護系統是否堅固

采用成熟的網絡漏洞檢查工具檢查系統相關漏洞（即用最專業的黑客攻擊工具攻擊試一下，現在最常用的是 NBSI 系列和 IPhacker IP ）

采用各種木馬檢查工具檢查系統木馬情況

采用各種防外掛工具檢查系統各組程序的外掛漏洞

數據庫安全考慮問題：

系統數據是否機密（比如對銀行系統，這一點就特別重要，一般的網站就沒有太高要求）系統數據的完整性（我剛剛結束的企業實名核查服務系統中就曾存在數據的不完整，對于這個系統的功能實現有了障礙）

系統數據可管理性

系統數據的獨立性

系統數據可備份和恢復能力（數據備份是否完整，可否恢復，恢復是否可以完整）

α測試是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試，Alpha 測試不能由程序員或測試員完成。

β測試是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者通常不在測試現場，Beta 測試不能由程序員或測試員完成。

需求測試的注意事項有哪些？

是否使用了公司的模板

文檔內容是否符合規范

所有的需求是分級是否清析適當？

所有的需求是否具有一致性

需求是否可行（即，該需求組合有解決方案）

需求可否用己知的約束來實現

需求是否足夠（即，可以把它送到一個規范的開發組織，并有一個生產出所需要產品的合理的可能性）

所有的其它需求是交叉引用是否正確

用戶描述是否清楚

是否用客戶的語言來描述需求

每個需求描述是否清楚沒有岐義，可以移交給一個獨立的組去實現時也能理解

是否所有的需求都是可驗證的

是否每條需求都具有獨立性，即使發生了變化也不會影響其它需求

性能指標是否明確

非功能性需求是否得到充分表現

是否完整列出適用的標準或協議

標準和協議之間是否存在沖突

問：你在測試中發現了一個 bug ，但是開發經理認為這不是一個 bug ，你應該怎樣解決。

將問題提交到缺陷管理庫里面進行備案。

要獲取判斷的依據和標準： 根據需求說明書、產品說明、設計文檔等，確認實際結果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據； 如果沒有文檔依據，可以根據類似軟件的一般特性來說明是否存在不一致的地方，來確認是否是缺陷； 根據用戶的一般使用習慣，來確認是否是缺陷；

與設計人員、開發人員和客戶代表等相關人員探討，確認是否是缺陷；

合理的論述，向測試經理說明自己的判斷的理由，注意客觀、嚴謹，不參雜個人情緒。

等待測試經理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反映，并有上級做出決定。

問：給你一個網站，你如何測試？

1、查找需求說明、網站設計 m 等相關文檔，分析測試需求。

2、制定測試計劃，確定測試范圍和測試策略，一般包括以下幾個部分：

功能性測試；界面測試；性能測試；數據庫測試；安全性測試；兼容性測試

3、設計測試用例：

功能性測試可以包括，但不限于以下幾個方面：

鏈接測試。鏈接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯信息返回等。提交功能的測試。

多媒體元素是否可以正確加載和顯示。多語言支持是否能夠正確顯示選擇的語言等。

界面測試可以包括但不限于一下幾個方面：

頁面是否風格統一，美觀

文字檢查

對于必須但為安裝的空間，是否提供自動下載并安裝的功能

控件是否正常使用

頁面布局是否合理，重點內容和熱點內容是否突出

問：一臺客戶端有三百個客戶與三百個客戶端有三百個客戶對服務器施壓，有什么區別?

300 個用戶在一個客戶端上，會占用客戶機更多的資源，而影響測試的結果。線程之間可能發生干擾，而產生一些異常。300 個用戶在一個客戶端上，需要更大的帶寬。IP 地址的問題，可能需要使用 IP Spoof 來繞過服務器對于單一 IP 地址最大連接數的限制。所有用戶在一個客戶端上，不必考慮分布式管理的問題；而用戶分布在不同的客戶端上，需要考慮使用控制器來整體調配不同客戶機上的用戶。同時，還需要給予相應的權限配置和防火墻設置。

你工作中遇到最具價值的bug，就是重大bug咯，例如app性能測試測哪些，那你就看一看性能測試的視頻咯

軟件的安全性應從哪幾個方面 去測試？

軟件安全性測試包括程序、數據庫安全性測試。根據系統安全指標不同測試策略也不同。

用戶認證安全的測試要考慮問題：

明確區分系統中不同用戶權限

系統中會不會出現用戶沖突

系統會不會因用戶的權限的改變造成混亂

用戶登陸密碼是否是可見、可復制

是否可以通過絕對途徑登陸系統（拷貝用戶登陸后的鏈接直接進入系統）

用戶退出系統后是否刪除了所有鑒權標記，是否可以使用后退鍵而不通過輸入口令進入系統

系統網絡安全的測試要考慮問題

測試采取的防護措施是否正確裝配好，有關系統的補丁是否打上

模擬非授權攻擊，看防護系統是否堅固

采用成熟的網絡漏洞檢查工具檢查系統相關漏洞（即用最專業的黑客攻擊工具攻擊試一下，

現在最常用的是 NBSI 系列和 IPhacker IP ）

采用各種木馬檢查工具檢查系統木馬情況

采用各種防外掛工具檢查系統各組程序的外掛漏洞

數據庫安全考慮問題：

系統數據是否機密（比如對銀行系統，這一點就特別重要，一般的網站就沒有太高要求）

系統數據的完整性（我剛剛結束的企業實名核查服務系統中就曾存在數據的不完整，對于這個系統的功能實現有了障礙）

系統數據可管理性

系統數據的獨立性

系統數據可備份和恢復能力（數據備份是否完整，可否恢復，恢復是否可以完整）

軟件質量保證體系是什么 國家標準中與質量保證管理相關的幾個標準是什么? ? 他們的編號和全稱是什么? ?

SQA 由一套軟件工程過程和方法組成，以保證（軟件的）質量。SQA 貫穿整個軟件開發過程，(它)應包括需求文檔評審、代碼控制、代碼評審、變更管理、配置管理、版本管理和軟件測試。

測試人員在軟件開發過程中的任務是什么？

1、尋找 Bug；

2、避免軟件開發過程中的缺陷；

3、衡量軟件的品質；

4、關注用戶的需求。

總的目標是：確保軟件的質量。

在您以往的工作中，一條軟件缺陷（或者叫 Bug）記錄都包含了哪些內容？如何提交高質量的軟件缺陷（Bug）記錄？

一條 Bug 記錄最基本應包含：編號、Bug 所屬模塊、Bug 描述、Bug 級別、發現日期、發現人、修改日期、修改人、修改方法、回歸結果等等；

要有效的發現 Bug 需參考需求以及詳細設計等前期文檔設計出高效的測試用例，然后嚴格執行測試用例，對發現的問題要充分確認

肯定，然后再向外發布如此才能提高提交 Bug 的質量。

黑盒測試和白盒測試是軟件測試的兩種基本方法，請分別說明各自的優點和缺點！

黑盒測試的優點有：比較簡單，不需要了解程序內部的代碼及實現；與軟件的內部實現無關；從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；基于軟件開發文檔，所以也能知道軟件實現了文檔中的哪些功能；在做軟件自動化測試時較為方便。

黑盒測試的缺點有：不可能覆蓋所有的代碼，覆蓋率較低，大概只能達到總代碼量的 30%；自動化測試的復用性較低。

白盒測試的優點有：幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質量，發現代碼中隱藏的問題。

白盒測試的缺點有：程序運行會有很多不同的路徑，不可能測試所有的運行路徑；測試基于代碼，只能測試開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；系統龐大時，測試開銷會非常大。

什么是系統瓶頸？

參考答案：

瓶頸主要是指整個軟硬件構成的軟件系統某一方面或者幾個方面能力不能滿足用戶的特定業務要求，“特定”是指瓶頸會在某些條件下會出現，因為畢竟大多數系統在投入前。

嚴格的從技術角度講，所有的系統都會有瓶頸，因為大多數系統的資源配置不是協調的，例如CPU使用率剛好達到100％時，內存也正好耗盡的系統不是很多見。因此我們討論系統瓶頸要從應用的角度討論：關鍵是看系統能否滿足用戶需求。在用戶極限使用系統的情況下，系統的響應仍然正常，我們可以認為改系統沒有瓶頸或者瓶頸不會影響用戶工作。

因此我們測試系統瓶頸主要是實現下面兩個目的：

-發現“表面”的瓶頸。主要是模擬用戶的操作，找出用戶極限使用系統時的瓶頸，然后解決瓶頸，這是性能測試的基本目標。

-發現潛在的瓶頸并解決，保證系統的長期穩定性。主要是考慮用戶在將來擴展系統或者業務發生變化時，系統能夠適應變化。滿足用戶目前需求的系統不是最好的，我們設計系統的目標是在保證系統整個軟件生命周期能夠不斷適應用戶的變化，或者通過簡單擴展系統就可以適應新的變化。

手機APP測試

主要包括功能、性能測試、穩定性、兼容性、用戶測試。

性能測試： CPU占用/內存占用 /耗電測試 /流量消耗測試 /安裝包大小 /加載時間測試 /核心功能相應時間 (①啟動時間檢測：檢測App在終端上首次啟動時間。②內存、CPU耗用檢測：檢測App在終端上運行時不同時段占用內存、CPU情況。③流量耗用檢測：檢測App在終端上運行時的網絡流量消耗情況。④電池溫度檢測：檢測App在終端上運行時，對終端的電池溫度等性能指標的影響情況 )

兼容性測試： 屏幕分辨率 /網絡狀態，狀態切換 /android版本 /安裝卸載升級等 /權限設置 /與其他APP兼容性 (①安裝卸載測試：測試App在指定終端上是否可正常安裝、正常卸載，準確定位錯誤原因。②遍歷測試：自動識別App可執行的功能，在一定時間內遍歷App的不同功能界面，通過截圖記錄操作路徑 并輸出日志、定位異常現象。③運行穩定性測試：類似Monkey的隨機性壓力測試，測試App運行期的穩定性。④UI適配測試：測試App的UI與目標終端的屏幕是否適配，記錄是否存在渲染失敗、錯位、黑邊框、黑白屏等現象。)

穩定性測試包括：服務器異常時穩定性 /外部事件影響（電話，短信等） /內存是否有溢出或者泄漏 /多線程問題 。

什么是并發？在lordrunner中，如何進行并發的測試？集合點失敗了會怎么樣？

參考答案：

在同一時間點，支持多個不同的操作。

LoadRunner中提供IP偽裝，集合點，配合虛擬用戶的設計，以及在多臺電腦上設置，可以比較好的模擬真實的并發。

集合點，即是多個用戶在某個時刻，某個特定的環境下同時進行虛擬用戶的操作的。集合點失敗，則集合點的才操作就會取消，測試就不能進行。

詳細的描述一個測試活動完整的過程。

答案：（供參考，本答案主要是瀑布模型的做法）

項目經理通過和客戶的交流，完成需求文檔，由開發人員和測試人員共同完成需求文檔的評審，評審的內容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實現的功能的地方。項目經理通過綜合開發人員，測試人員以及客戶的意見，完成項目計劃。然后 SQA 進入項目，開始進行統計和跟蹤開發人員根據需求文檔完成需求分析文檔，測試人員進行評審，評審的主要內容包括是否有遺漏或者雙方理解不同的地方。測試人員完成測試計劃文檔，測試計劃包括的內容上面有描述。測試人員根據修改好的需求分析文檔開始寫測試用例，同時開發人員完成概要設計文檔，詳細設計文檔。此兩份文檔成為測試人員撰寫測試用例的補充材料。測試用例完成后，測試和開發需要進行評審。測試人員搭建環境開發人員提交第一個版本，可能存在未完成功能，需要說明。測試人員進行測試，發現 BUG后提交給 BugZilla。開發提交第二個版本，包括 Bug Fix 以及增加了部分功能，測試人員進行測試。重復上面的工作，一般是 3-4 個版本后 BUG 數量減少，達到出貨的要求。如果有客戶反饋的問題，需要測試人員協助重現并重新測試。

在您以往的工作中，一條軟件缺陷（或者叫 Bug ）記錄都包含了哪些內容？如何提交高質量的軟件缺陷（ Bug ）記錄？

在傳統的 BugZilla 中，BUG 描述應該包括以下的信息和 BUG 產生對應的軟件版本和模塊開發的接口人員BUG 的優先級BUG 的嚴重程度BUG 可能屬于的模塊，如果不能確認，可以用開發人員來判斷BUG 標題，需要清晰的描述現象BUG 描述，需要盡量給出重新 Bug 的步驟BUG 附件中能給出相關的日志和截圖。高質量的 BUG 記錄就是指很容易理解的 BUG 記錄，所以，對于描述的要求高，能提供的信息多且準確，很好的幫助開發人員定位，因此提交高質量的軟件缺陷記錄需要注意對 BUG 記錄的描述質量多且準確。

您認為在測試人員同開發人員的溝通過程中，如何提高溝通的效率和改善溝通的效果？維持測試人員同開發團隊中其他成員 良好的人際關系的關鍵是什么？

盡量面對面的溝通，其次是能直接通過電話溝通，如果只能通過 Email 等非及時溝通工具的話，強調必須對特性的理解深刻以及能表達清楚。運用一些測試管理工具如 TestDirector 進行管理也是較有效的方法，同時要注意在TestDirector 中對 BUG 有準確的描述。在團隊中建立測試人員與開發人員良好溝通中注意以下幾點：一真誠二是團隊精神三是在專業上有共同語言四是要對事不對人，工作至上當然也可以通過直接指出一些小問題，而不是進入 BUG Tracking System 來增加對方的好感。

軟件測試項目從什么時候開始？為什么？

軟件測試應該在需求分析階段就介入,因為測試的對象不僅僅是程序編碼,應該對軟件開發過程中產生的所有產品都測試,并且軟件缺陷存在放大趨勢.缺陷發現的越晚,修復它所花費的成本就越大.

測試結束的標準是什么？

從微觀上來說，在測試計劃中定義，比如系統在一定性能下平穩運行 72 小時，目前 BugTracking System 中，本版本中沒有一般嚴重的 BUG，普通 BUG 的數量在 3 以下，BUG 修復率 90%以上等等參數，然后由開發經理，測試經理，項目經理共同簽字認同版本 Release。如果說宏觀的，則是當這個軟件徹底的消失以后，測試就結束了。

您是否了解以往所工作的企業的軟件開發過程？如果了解，請試述一個完整的開發過程需要完成哪些工作？分別由哪些不同的角色來完成這些工作？您在以往的測試工作中都曾經具體從事過哪些工作？其中最擅長哪部分工作？

開發過程—需求調研（需求人員）、需求分析（需求人員）、概要設計（設計人員）、詳細設計(設計人員)、編碼（開發人員）測試過程—需求評審、系統測試設計、概要設計評審、集成測試設計、詳細設計評審、單元測試設計、測試執行測試工作的整個過程都做過，擅長做測試設計過程決定質量，軟件的過程改進正是為了提高軟件的質量，將過往的種種經驗和教訓積累起來。

補充

1.明確測試的目標，增強測試計劃的實用性編寫軟件測試計劃得重要目的就是使測試過程能夠發現更多的軟件缺陷，因此軟件測試計劃的價值取決于它對幫助管理測試項目，并且找出軟件潛在的缺陷。因此，軟件測試計劃中的測試范圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具并且具有較高的實用性，便于使用，生成的測試結果直觀、準確

2．采用評審和更新機制，保證測試計劃滿足實際需求

測試計劃寫作完成后，如果沒有經過評審，直接發送給測試團隊，測試計劃內容的可能不準確或遺漏測試內容，或者軟件需求變更引起測試范圍的增減，而測試計劃的內容沒有及時更新，誤導測試執行人員。分別創建測試計劃與測試詳細規格、測試用例,應把詳細的測試技術指標包含到獨立創建的測試詳細規格文檔，把用于指導測試小組執行測試過程的測試用例放到獨立創建的測試用例文檔或測試用例管理數據庫中。測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計劃主要從宏觀上規劃測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。

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

參考回答：

性能測試常用指標：

從外部看，主要有

1、吞吐量：每秒鐘系統能夠處理的請求數，任務數

2、響應時間：服務處理一個請求或一個任務的耗時

3、錯誤率：一批請求中結果出錯的請求所占比例

從服務器的角度看，性能測試關注CPU，內存，服務器負載，網絡，磁盤ＩＯ

對登錄功能做性能測試

單用戶登陸的響應界面是否符合預期

單用戶登陸時后臺請求數量是否過多

高并發場景下用戶登錄的響應界面是否符合預期

高并發場景下服務端的監控指標是否符合預期

高集合點并發場景下是否存在資源死鎖和不合理的資源等待

長時間大量用戶連續登錄和登出，服務器端是否存在內存泄漏

怎么測出可同時處理的最大請求數量

可以采用性能測試工具(WeTest服務器性能)，該工具是騰訊wetest團隊出品，使用起來很簡單方便，但測試功能相當強大，能提供10w+以上的并發量，定位性能拐點，測出服務器模型最大并發

什么是兼容型測試？兼容性測試側重哪些方面？

兼容測試主要是檢查軟件在不同的硬件平臺、軟件平臺上是否可以正常的運行，即是通常說的軟件的可移植性。兼容的類型，如果細分的話，有平臺的兼容，網絡兼容，數據庫兼容，以及數據格式的兼容。兼容測試的重點是，對兼容環境的分析。通常，是在運行軟件的環境不是很確定的情況下，才需要做兼容。根據軟件運行的需要，或者根據需求文檔，一般能夠得出用戶會在什么環境下使用該軟件，把這些環境整理成表單，就得出做兼容測試的兼容環境了

兼容和配置測試的區別在于，做配置測試通常不是在Clean OS下做測試，而兼容測試多是在Clean OS環境下做的。

補充：做兼容測試的具體步驟：在列好的軟硬件環境清單做冒煙測試，還是每一步都測試。測出不兼容，怎么和開發溝通，開發面對這些不兼容需要做什么。如果修復成本很高，怎么和產品經理溝通。和誰確認表單

軟件測試項目從什么時候開始，？為什么？

軟件測試應該在需求分析階段就介入,因為測試的對象不僅僅是程序編碼,應該對軟件開發

過程中產生的所有產品都測試,并且軟件缺陷存在放大趨勢.缺陷發現的越晚,修復它所花費的成本就越大.

三、測試實戰面試題

我現在有個程序，發現在Windows上運行的很慢，怎么判別是程序存在問題還是軟硬件系統存在問題

1、檢查系統是否有中毒的特征

2、檢查軟件/硬件的配置是否符合軟件的推薦標準

3、確認當前的系統是否獨立，即沒有對外提供什么消耗CPU資源的服務

4、如果是C/S或者B/S結構的軟件，需要檢查是不是因為與服務器的連接有問題，或者訪問有問題造成

5、在系統沒有任何負載的情況下，查看性能監視器，確認應用程序對CPU/內存的訪問情況

補充：每一步該怎么實現，需要用到什么技術

一個程序有n個變量采用邊界值分析可以產生幾個測試用例

4n+1

請設計一個關于ATM自動取款機的測試用例。

1）功能

a)ATM所識別卡的類型；

b)密碼驗證(身份登陸、是否為掩碼、輸入錯誤密碼時是否提示，連續三次錯誤吞卡等)；

c)取款功能：

i、金額多少的限制，單次最大最小提取金額、每天最大提取金額等）；

Ii、取款幣種的不同，如人民幣、美元、歐元等。

d)是否提示客戶操作完成后，打印相關操作信息；

e)查詢功能是否正常；

f)轉賬功能是否正常；

g)是否提示客戶操作完成后，取回客戶卡；

2）性能

a)是否有自動吞卡：非法客戶\密碼錯誤客戶\規定時間內未完成相關操作功能的客戶。（如果有，有無報警功能(保密報警)）

b)平均無故障時間，平均故障修復時間，輸入密碼后驗證時間，出鈔票時間，查詢余額等待時間。

3）易用性

a)ATM各個操作功能(硬件)是否正常、易懂；

b)ATM的界面顯示是否友好；

c)ATM是否支持英文操作；

d)ATM是否存在異常（斷電、黑客入侵）有自動保護（報警）功能；

如何測試一個 紙杯？

功能度：用水杯裝水看漏不漏；水能不能被喝到

安全性：杯子有沒有毒或細菌

可靠性：杯子從不同高度落下的損壞程度

可移植性：杯子在不同的地方、溫度等環境下是否都可以正常使用

兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等

易用性：杯子是否燙手、是否有防滑措施、是否方便飲用

用戶文檔：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述

疲勞測試：將杯子盛上水（案例一）放 24 小時檢查泄漏時間和情況；盛上汽油（案例二）

放 24 小時檢查泄漏時間和情況等

壓力測試：用根針并在針上面不斷加重量，看壓強多大時會穿透

我手上這支筆，請你根據這支筆設計測試用例

首先我要測它的外觀、顏色是否符合要求、所占的空間是多大、是否環保、接下來測它的質量、這支筆是否能夠寫字流暢、寫出的自得顏色是否符合要求、能使用多長時間等

測試手機開機鍵

功能測試：按下開機鍵，屏幕能否亮起

性能測試：按下開機鍵，屏幕能否在規定時間內亮起

壓力測試：連續多次按下開機鍵，觀察屏幕是否能一直亮起，到多久時間失靈

健壯性測試：給定一個中了病毒的手機或者是淘汰許久的老機子，安歇開機鍵觀察屏幕能否亮起

可靠性測試：連續按下開機鍵有限次數，比如1萬次，記錄屏幕未亮起的次數

可用性測試：開機鍵按下費不費力，開機鍵的形狀設計是否貼合手指，開機鍵的位置設計是否方便

如何回答登錄功能怎么進行測試？

首先，進行界面測試。

查看界面上的所有元素是否齊全；

沒有輸入內容時，是否有相應的提示語；

驗證碼是否能夠顯示；

移動鼠標，【登陸】按鈕默認不能點擊；

【忘記密碼】是否有個小問號“？”（其他都有）；

第二，進行功能測試。

輸入正確的用戶名、密碼、驗證碼，點【登陸】能登陸；

輸入正確的用戶名、錯誤的密碼、正確的驗證碼，提示用戶名或密碼錯誤；

輸入錯誤的用戶名、正確的驗證碼，提示用戶名或密碼錯誤；

輸入正確的用戶名、密碼，錯誤的驗證碼，提示驗證碼錯誤；

輸入不符合規則的手機號或者郵箱應該提示錯誤；

頁面長時間不登陸和操作，驗證碼會不會過期；

點【記住密碼】，登錄后退出，再次登陸是不是可以不輸入密碼；

點【忘記密碼】能夠跳轉到密碼設置頁面（至于是什么不用管，就是能不能跳轉）

只點擊驗證碼圖案，驗證碼能不能刷新；

頁面刷新，驗證碼圖案能不能刷新；

輸入欄是否設置快速刪除按鈕；

用戶名和密碼是否大小寫敏感；

用戶名和密碼前后有空格的處理；

登陸成功，是否有記住密碼功能；

登陸失敗后，不能記錄密碼的功能；

新用戶第一次登陸成功，是否有修改密碼提示；

用戶登錄過程中log中是否有個人信息明文打印；

是否支持第三方登陸；

刷新頁面時是否會刷新驗證碼；

輸入密碼的時候，大寫鍵盤開啟的時候要有提示信息 ；

不同級別的用戶，比如管理員用戶和普通用戶，登錄系統后的權限是否正確；

第三、業務安全測試。

有沒有登陸錯誤次數的限制；

每次登陸錯誤之后有沒有限制再次登陸的時間間隔；

是否支持一個賬號多地登陸；

不同機型登陸，異地登陸是否有提醒 ；

不登錄的情況下，在瀏覽器中直接輸入登錄后的URL地址，驗證是否會重新定向到用戶登錄界面；

第四、兼容性測試。

在相同瀏覽器的不同版本上打開登錄頁面，效果是否一致；在不同瀏覽器上打開登錄頁面，效果是否一致；在不同操作系統的不同瀏覽器打開登錄頁面，效果是否一致；在不同的屏幕分辨率下打開登錄頁面，效果是否一致；

第五、代碼安全性測試。

用戶輸入登錄信息登陸時，個人信息是不是會顯示在瀏覽器地址欄；

用戶登陸的時候，通過抓包工具抓數據，密碼是否加密；

查看頁面源代碼，驗證碼是否直接顯示在代碼中；

密碼在后臺儲存時是否加密；

是否可以使用登錄的API發送登錄請求，并繞開驗證碼校驗；

用戶名和密碼的輸入框中分別輸入典型的“SQL注入攻擊”字符串，驗證系統的返回頁面；

用戶名和密碼的輸入框中分別輸入典型的“XSS跨站腳本攻擊”字符串，驗證系統行為是否被篡改；

第六、頁面性能測試。

單用戶登錄的響應時間是否小于3秒；

通過工具向登錄頁發起大量請求，查看頁面響應時間的變化；

通過工具對登陸功能進行并發測試；通過工具向登錄頁發起大量請求，查看頁面何時崩潰；

通過工具向登錄頁發起大量請求，查看頁面崩潰后有沒有良好的提示信息；

通過工具向登錄頁發起大量請求，查看頁面崩潰后多長時間能夠恢復服務；

弱網，不同網速時登陸的時間，網絡切換和網絡延遲時登陸界面是否正常；

最后、易用性測試。

頁面是否美觀；

功能是否都可以使用；

頁面速度快不快；

頁面元素加載是否耗費網絡流量；

能不能第三方登陸；

為什么不使用手機驗證碼登陸；

輸入框能否可以以Tab鍵切換。

如何回答京東購物車功能怎么進行測試？

1.功能測試

a）、未登錄時：

將商品加入購物車，頁面跳轉到登錄頁面，登錄成功后購物車數量增加。

b）、登錄后：

所有鏈接是否跳轉正確；

商品是否可以成功加入購物車；

沒有限購要求的商品，添加數量能不能超過庫存數；

購物車商品總數是否有限制；

商品總數統計是否正確；

全選功能是否可用；

刪除功能是否可用；

刪除功能是否有提示；

價格總計是否正確；

商品文字太長時是否顯示完整；

購物車中下架的商品是否有標識，是否還能支付；

新加入購物車商品排序（添加購物車中存在的店鋪的商品和購物車中不存在的店鋪的商品）；

是否支持快TAB、ENTER等快捷鍵；

商品刪除后商品總數是否減少；

收藏功能是否可用；

賬號退出后，購物車添加的內容是否還在；

購物車結算功能是否可用。

限購商品按照規則購買完成后，還能不能再次添加購物車并購買；

2.兼容性測試

BS架構：不同瀏覽器測試，比如：IE，火狐，谷歌，360這些。

APP：在主流的不同類型，不同分辨率，不同操作系統的手機上測試，華為，vivo，oppo等

3.用戶體驗測試

刪除商品是否有提示；

是否支持快捷鍵功能；

是否有回到頂部的功能；

商品過多時結算按鈕是否可以浮動顯示；

購物車有多個商品時，能不能只對單個商品結算；

界面布局、排版是否合理；

文字是否顯示清晰；

不同賣家的商品是否區分明顯。

4.性能測試

打開購物車頁面要多長時間

支付流程測試

功能測試。

用等價類和邊界值，判斷支付的金額

如果沒有登陸能否支付，支付成功后是否可以正常跳轉；

支付方式是否支持掃碼支付，第三方平臺支付（支付包，云網等），語音支付，指紋支付；

支付時是否需要身份驗證，支付后有無手機短信提示，是否可以找他人代付；

用邊界值法有無支付額度限制，余額不足時有無提示，支付時是否是動態加密支付；

待支付狀態：訂單是否可以正常支付；是否可以取消；有相同訂單是否可以支付兩次；

是否可以掃碼支付，輸入錯誤的密碼會怎樣顯示，有無錯誤次數限制；

若支持掃碼支付，二維碼是否支持支付包和微信掃碼，若兩人同時掃描怎么處理；

有無最小支付金額限制，無意義的支付金額0，重復支付如何處理；

如果支付包含優惠金額，該怎么處理優惠額度；

性能測試

弱網，無網時是否可以支付；

退款到賬時間，耗電量的多少；

帶負載情況下的響應時間和吞吐率，在某個時間段內同時訪問系統的用戶數量 ；

壓力測試

多人同時付款；

界面測試；

支付界面有無錯別字，排版是否合理，顏色搭配是否合理；

兼容性測試

是否可以跨平臺，不同電腦機型下顯示有無區別；

安全性測試；

若支付不成功是否原路退款，若支付成功，有無支付信息提示；

用fiddler抓包嘗試修改價格，對訂單金額有無效驗；

直接輸入需要權限的頁面地址可用訪問；

接口測試

第三方平臺支付

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

參考回答：

如何做高并發系統的測試，一般而言，整體的測試策略是：先針對部分系統進行性能測試及壓力測試，得到各部分的峰值處理性能，再模擬整體流程測試，重點測試整體業務流程以及業務預期負荷，著重測試以下幾點：

1、不同省份，不同運營商CDN節點性能，可采用典型壓力測試方案

2、核心機房BGP網絡帶寬，此部分重點在于測試各運行商的BGP網絡可靠性，實際速率，一般采用smokeping,lxChariot等工具

3、各類硬件設備性能，一般采用專業的網絡設備測試工具

4、各類服務器并發性能，分布式處理能力，可采用壓力測試方案工具

5、業務系統性能，采用業務系統壓力測試方案

6、數據庫處理性能，這部分需要結合業務系統進行測試，以獲取核心業務場景下的數據庫的TPS/QPS，

7、如果有支付功能，需要進行支付渠道接口及分流測試，此部分相對而言可能是最大的瓶頸所在，此外還涉及備份方案，容災方案，業務降級方案的測試。

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

參考回答：

功能：

1.每個攝像頭都能抓拍車牌；

2.每個攝像頭抓拍到的車牌能正常交給系統處理；

3.系統能夠正確識別車牌；

4.系統能夠將識別出的車牌上傳；

5.上傳至網絡的車牌能夠正常展示出來；

一、功能測試

1.使用正常的車牌，保持車牌靜止，檢查每個攝像頭是否能抓拍車牌；

2.使用類似非車牌的寫有字的紙板，檢查每個攝像頭是否抓拍；

3.使用正常的車牌，保持車牌較高速移動，檢查每個攝像頭是否能抓拍車牌；

4.在多種情況下檢查每個攝像頭抓拍到的車牌能否正常交給系統處理，如臨時斷電、斷網后能否正常將數據交給系統；

5.使用抓拍到的正常的車牌，交由系統處理，檢查系統能否識別車牌；

6.使用非車牌的其他圖片，交由系統處理，檢查系統能否識別；

7.在多種情況下檢查系統能否將正常識別出的車牌進行上傳，如臨時斷電、斷網后未上傳數據是否能繼續上傳；

8.構造非車牌的其他內容的數據，檢查系統能否將異常內容進行上傳；

9.檢查上傳至網絡的車牌能否正常展示出來；

10.上傳非車牌的其他內容的數據，檢查能否正常顯示出來。

二、性能測試

1.同時向一個攝像頭展示多個靜止的車牌，檢查攝像頭能否抓拍到多個車牌；

2.同時向一個攝像頭展示多個較高速運動的車牌，檢查攝像頭能否抓拍到多個車牌；

3.抓拍后，檢查系統識別車牌的時間是否在需求要求的時間內；

4.模擬大量抓拍照片同時交由系統處理，檢查一定壓力下系統能否正常識別車牌；

5.模擬大量車牌同時上傳，檢查一定壓力下能否上傳成功。

三、安全性測試

1.檢查是否能夠通過給車牌加裝飾物等方法，使攝像頭無法抓拍或抓拍后系統無法正常識別車牌。

請你說一說PC網絡故障，以及如何排除障礙

參考回答：

(1)首先是排除接觸故障，即確保你的網線是可以正常使用的。然后禁用網卡后再啟用，排除偶然故障。打開網絡和共享中心窗口，單擊窗口左上側“更改適配器設置”右擊其中的“本地連接“或”無線網絡連接”，單擊快捷菜單中的“禁用”命令，即可禁用所選網絡。接下來重啟網絡，只需右擊后單擊啟用即可。

(2)使用ipconfig查看計算機的上網參數

1、單擊“開始|所有程序|附件|命令提示符“，打開命令提示符窗口

2、輸入ipconfig，按Enter確認，可以看到機器的配置信息，輸入ipconfig/all,可以看到IP地址和網卡物理地址等相關網絡詳細信息。

(3)使用ping命令測試網絡的連通性，定位故障范圍

在命令提示符窗口中輸入”ping 127.0.0.1“，數據顯示本機分別發送和接受了4個數據包，丟包率為零，可以判斷本機網絡協議工作正常，如顯示”請求超時“，則表明本機網卡的安裝或TCP/IP協議有問題，接下來就應該檢查網卡和TCP/IP協議，卸載后重裝即可。

(4)ping本機IP

在確認127.0.0.1地址能被ping通的情況下，繼續使用ping命令測試本機的IP地址能否被ping通，如不能，說明本機的網卡驅動程序不正確，或者網卡與網線之間連接有故障，也有可能是本地的路由表面收到了破壞，此時應檢查本機網卡的狀態是否為已連接，網絡參數是否設置正確，如果正確可是不能ping通，就應該重新安裝網卡驅動程序。丟失率為零，可以判斷網卡安裝配置沒有問題，工作正常。

(5)ping網關

網關地址能被ping通的話，表明本機網絡連接以及正常，如果命令不成功，可能是網關設備自身存在問題，也可能是本機上網參數設置有誤，檢查網絡參數。

微信紅包

功能

1.在紅包錢數，和紅包個數的輸入框中只能輸入數字

2.紅包里最多和最少可以輸入的錢數 200 0.01

3.拼手氣紅包最多可以發多少個紅包 100

3.1超過最大拼手氣紅包的個數是否有提醒

4.當紅包錢數超過最大范圍是不是有對應的提

5.當發送的紅包個數超過最大范圍是不是有提示

6.當余額不足時，紅包發送失敗

7.在紅包描述里是否可以輸入漢字，英文，符號，表情，純數字，漢字英語符號，

7.1是否可以輸入它們的混合搭配

8.輸入紅包錢數是不是只能輸入數字

9.紅包描述里許多能有多少個字符 10個

10.紅包描述，金額，紅包個數框里是否支持復制粘貼操作

12.紅包描述里的表情可以刪除

13.發送的紅包別人是否可以領取

13.1發的紅包自己可不可以領取 2人

24小時內沒有領取的紅包是否可以退回到原來的賬戶

14.1 超過24小時沒有領取的紅包，是否還可以領取

15.用戶是否可以多次搶一個紅包

16.發紅包的人是否還可以搶紅包 多人

17.紅包的金額里的小數位數是否有限制

18.可以按返回鍵，取消發紅包

斷網時，無法搶紅包

20.可不可以自己選擇支付方式

21.余額不足時，會不會自動匹配支付方式

22.在發紅包界面能否看到以前的收發紅包的記錄

23.紅包記錄里的信息與實際收發紅包記錄是否匹配

24.支付時可以密碼支付也可以指紋支付

25.如果直接輸入小數點，那么小數點之前應該有個0

26.支付成功后，退回聊天界面

27.發紅包金額和收到的紅包金額應該匹配

28.是否可以連續多次發紅包

29.輸入錢數為0，"塞錢進紅包"置灰

性能

1.弱網時搶紅包，發紅包時間

2.不同網速時搶紅包，發紅包的時間

3.發紅包和收紅包成功后的跳轉時間

4.收發紅包的耗電量

5.退款到賬的時間

兼容

1.蘋果，安卓是否都可以發送紅包

2.電腦端可以搶微信紅包

界面

1.發紅包界面沒有錯別字

2.搶完紅包界面沒有錯別字

3.發紅包和收紅包界面排版合理，

4.發紅包和收到紅包界面顏色搭配合理

安全

1.對方微信號異地登錄，是否會有提醒 2人

2.紅包被領取以后，發送紅包人的金額會減少，收紅包金額會增加

3.發送紅包失敗，余額和銀行卡里的錢數不會少

4.紅包發送成功，是否會收到微信支付的通知

易用性(有點重復)

1.紅包描述，可以通過語音輸入

2.可以指紋支付也可以密碼支付

微信發朋友圈點贊

參考回答：

功能測試：點贊某條朋友圈，驗證是否成功

接口測試：點贊朋友圈，驗證朋友能否收到提示信息

性能測試：點贊朋友圈，是否在規定時間顯示結果，是否在規定時間在朋友手機上進行提示。

兼容性測試

在不同的終端比如ipad,手機上點贊朋友圈，驗證是否成功

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

參考回答：

一, 功能測試

輸入關鍵字，查看: 返回結果是否準確，返回的文本長度需限制

1.1輸入可查到結果的正常關鍵字、詞、語句，檢索到的內容、鏈接正確性；

1.2輸入不可查到結果的關鍵字、詞、語句；

1.3輸入一些特殊的內容，如空、特殊符、標點符、極限值等，可引入等價類劃分的方法等；

結果顯示：標題，賣家，銷售量，單行/多行，是否有圖片

結果排序：價格 銷量 評價 綜合

4.返回結果龐大時，限制第一頁的現實量，需支持翻頁

多選項搜索：關鍵字 品牌 產地 價格區間 是否天貓 是否全國購

是否支持模糊搜索，支持通配符的查詢

7, 網速慢的情況下的搜索

搜索結果為空的情況

未登錄情況和登錄情況下的搜索（登錄情況下 存儲用戶搜索的關鍵字/搜索習慣）

二.性能測試：

1壓力測試：在不同發用戶數壓力下的表現（評價指標如響應時間等）

2負載測試：看極限能承載多大的用戶量同時正常使用

3穩定性測試：常規壓力下能保持多久持續穩定運行

4內存測試：有無內存泄漏現象

5大數據量測試：如模擬從龐大的海量數據中搜索結果、或搜索出海量的結果后列示出來，看表現如何等等。

三. 易用性：交互界面的設計是否便于、易于使用

1依據不同的查詢結果會有相關的人性化提示，查不到時告知？查到時統計條數并告知？有疑似輸入條件錯誤時提示可能正確的輸入項等等處理；

2查詢出的結果羅列有序，如按點擊率或其他排序規則，確保每次查詢出的結果位置按規則列示方便定位，顯示字體、字號、色彩便于識別等等

3標題查詢、全文檢索、模糊查詢、容錯查詢、多關鍵字組織查詢（空格間格開）等實用的檢索方式是否正常？

4輸入搜索條件的控件風格設計、位置擺放是否醒目便于使用者注意到，有否快照等快捷查看方式等人性化設計？

四. 兼容性

1WINDOWS/LINUX/UNIX等各類操作系統下及各版本條件下的應用

2IE/FIREFOX/GOOGLE/360/QQ等各類瀏覽器下及各版本條件下、各種顯示分辨率條件下的應用

3SQL/ORACLE/DB2/MYSQL等各類數據庫存儲情況下的兼容性測試

4簡體中文、繁體中文、英文等各類語種軟件平臺下的兼容性測試

5IPHONE/IPAD、安卓等各類移動應用平臺下的兼容性測試

6與各相關的監控程序的兼容性測試，如輸入法、殺毒、監控、防火墻等工具同時使用

五. 安全性

1被刪除、加密、授權的數據，不允許被SQL注入等攻擊方式查出來的，是否有安全控制設計；

2錄入一些數據庫查詢的保留字符，如單引號、%等等，造成查詢SQL拼接出的語句產生漏洞，如可以查出所有數據等等，這方面要有一些黑客攻擊的思想并引入一些工具和技術，如爬網等。

3通過白盒測試技術，檢查一下在程序設計上是否存在安全方面的隱患；

4對涉及國家安全、法律禁止的內容是否進行了相關的過濾和控制；

就linux下的CP命令設計測試用例。

功能

拷貝的文件

1）大小：0k, 1k, 10k, 100k, 1000k…

2）類型：二進制文件、文本文件、mp3、avi、壓縮文件…

文件源目錄

1）文件中包含各種類型的文件

2）目錄深度為0，1，2，3…

文件目標目錄

1）目標目錄中存在與源文件同名同類型的文件

2）目標目錄中存在與源文件同名不同類型的文件

3）目標目錄中存在與源文件不同名同類型的文件

4）目標目錄中存在與源文件不同名不同類型的文件

異常

參數異常

1）包含特殊字符

2）參數長度超過限制

3）源目錄不存在

4）目標目錄不存在

文件異常

1）文件沒有拷貝權限

2）非法的文件格式和內容

存儲介質異常

1）存儲介質由損壞

2）拷貝前存儲介質已滿

3）拷貝中存儲介質存滿

執行過程異常

1）拷貝過程中刪除源文件

2）拷貝過程中刪除目標文件

性能

1）拷貝大文件

2）拷貝源目錄中存在大量小文件

3）跨文件系統拷貝

4）跨存儲介質拷貝

5）并發執行拷貝

關注性能點：拷貝完成時間，CPU，內存，磁盤IO

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

是否手機出現故障，是否手機緩存過多造成內存不夠用

是否手機網絡連接不穩定（弱網/無網），若是，有無網絡差提示

是否手機內存溢出（關注人數達上限否）

是否是版本問題或者是安裝包問題（更新系統，重新安裝安裝包）

現有一個學生標準化考試批閱試卷,產生成績報告的程序。其規格說明如下:程序的輸入文件由一些有80個字符的記錄組成,如右圖所示，所有記錄分為3組：

標題：這一組只有一個記錄，其內容為輸出成績報告的名字。

試卷各題標準答案記錄：每個記錄均在第80個字符處標以數字"2"。該組的第一個記錄的第1至第3個字符為題目編號（取值為1一999）。第10至第59個字符給出第1至第50題的答案（每個合法字符表示一個答案）。該組的第2，第3……個記錄相應為第51至第100，第101至第150，…題的答案。

每個學生的答卷描述：該組中每個記錄的第80個字符均為數字"3"。每個學生的答卷在若干個記錄中給出。如甲的首記錄第1至第9字符給出學生姓名及學號，第10至第59字符列出的是甲所做的第1至第50題的答案。若試題數超過50，則第2，第3……紀錄分別給出他的第51至第100，第101至第150……題的解答。然后是學生乙的答卷記錄。

學生人數不超過200，試題數不超過999。

程序的輸出有4個報告：

a)按學號排列的成績單，列出每個學生的成績、名次。b)按學生成績排序的成績單。c)平均分數及標準偏差的報告。d)試題分析報告。按試題號排序，列出各題學生答對的百分比。

分別考慮輸入條件和輸出條件，以及邊界條件。給出右表所示的輸入條件及相應的測試用例。

四、基礎知識點

什么是樁模塊？什么是驅動模塊？

樁模塊：被測模塊調用模塊

驅動模塊 調用被測模塊

什么是扇入？什么是扇出？

扇入：被調次數，扇出：調其它模塊數目

8020原則： 在需求分析開始到集成測試階段引入測試手段，能發現所有缺陷的80%，系統測試階段發現16%，在運行維護階段經過長時間大量運行軟件后，能夠發現4%。起源于經濟學。

什么是耦合？什么是內聚？

耦合：對一個軟件結構內各個模塊之間互連程度的度量。

內聚：一個模塊內各個元素彼此結合的緊密程度。強內聚，松耦合。

缺陷嚴重程度：

致命（Fatal）、嚴重（Critical）、一般（Major）、較小（Minor）。

缺陷優先級：

立即解決P1、高優先級P2、正常排隊P3、低優先級P4。

缺陷狀態：

打開（open）、修正（fixed）、重新打開（reopen）、關閉（closed）、重復（Duplicate）、推遲（Deferred）、保留（On hold）、不修復（wontfix）。

簡單的軟件缺陷生命周期：

發現（new）-打開-修復-關閉。

復雜的軟件缺陷生命周期：

新建-打開-Bug審查（設計需要修改/延期/關閉）-關閉。

新建-打開-是否清楚，可再現（不能再現缺少信息返回到打開狀態）-修正-關閉。

什么是在線用戶數？什么是并發用戶數？

在線用戶數：

用戶同時在一定時間段的在線數量

并發用戶數：

某一時刻同時向服務器發送請求的用戶數

分布式軟件架構分為：

B/S架構（瀏覽器、web版） C/S架構：客戶端（先進行安裝）

測試人員的能力：

搭建環境的能力（配置JDK、數據庫、Tomcat/Apace、程序放相應路徑下、檢查配置是否成功?數據庫管理和設置?程序設計C++④測試方法論⑤工具的使用能力（QC\QTP\LR\Bugfree）

簡述負載測試與壓力測試的區別。

參考答案：

壓力測試（Stress Testing）

壓力測試的主要任務就是獲取系統正確運行的極限，檢查系統在瞬間峰值負荷下正確執行的能力。例如，對服務器做壓力測試時就可以增加并發操作的用戶數量；或者不停地向服務器發送請求；或一次性向服務器發送特別大的數據等。看看服務器保持正常運行所能達到的最大狀態。人們通常使用測試工具來完成壓力測試，如模擬上萬個用戶從終端同時登錄，這是壓力測試中常常使用的方法。

負載測試（Volume Testing）

用于檢查系統在使用大量數據的時候正確工作的能力，即檢驗系統的能力最高能達到什么程度。例如，對于信息檢索系統，讓它使用頻率達到最大；對于多個終端的分時系統，讓它所有的終端都開動。在使整個系統的全部資源達到“滿負荷”的情形下，測試系統的承受能力。

軟件缺陷管理工具有哪些

答： QC ALM BugFree jira Mantis 禪道

弱網測試

四、智力題

一，5只貓 五分鐘捉5只老鼠 請問100分鐘捉100只老鼠需要多少只貓？

答案：5只

二，圓桌，兩個人，輪流放硬幣，不能重疊，半徑為1，某一方不能放下去，則為輸。問先手贏 后手贏

答案：先手贏，圓桌對稱，先手先放，后手都可以找對稱位置，除了圓心

三，3升的杯子一個，5升的杯子一個，杯子不規則形狀 問怎么得到4升的水 水無限多

答案：略

四，晚上有四個人過橋，一次只能過兩個人，但是只有一只手電筒，四個人過橋時間分別是1，2，5，8，求最短過橋時間

答案：甲乙，甲回，丙丁，乙回，甲乙，15分鐘

五，有十張撲克牌，每次可以只出一張，也可以只出兩張，要出完有多少種出法

答案：89 F(9)=N F(8)=P F(10)=F(8)+F(9) F(1)=1 F(2)=2

六，井蓋為什么是圓的

答案：用料少，受壓均勻，成本低

七，兩個盲人各買了一白一黑兩雙襪子，不小心弄混了，問他們自己怎么分成剛好每人一白一黑

答案：襪子是連在一起的

八， 燒一根不均勻的繩子，從頭燒到尾總共需要1個小時，問如何用燒繩子的方法來確定15分鐘?

答案：燒兩根，一根點兩頭，一根點一頭，燒完，剩下的把另一投點了，燒完，看重合點

九，海盜分金，五人，過半同意，否則喂魚，問1方案？

答案：45，5反對，4喂魚，所3（100，0，0），故2（98，0，1，1），故1（97，0，1，2，0）

十，岔路口，通往1，2，兩人，一人必說謊，一人永真話，怎么去1

答案：問一人，另一人會回答那條路去1，回答答案必假

十一，果凍，有黃色、綠色、紅色三種，閉眼抓同種顏色兩個，抓取多少個，可確定有兩個同色果凍？

答案：根據抽屜原理，4個

十二，下水道為什么是圓的

答案：方便人員進出，井蓋不容易掉落，不易如棱角磨損節約材料，保護車輛 和行人的安全

十三，一共100個球，兩人輪流拿，每人每次最多拿5個，最后一個拿的人贏；如果我先拿，怎么拿一定會贏？

答案：每次拿的球總數控制為6；第一次拿4個；

十四，有120g面粉，現有一個天平和一個2g的砝碼以及一個7g的砝碼，最少稱幾次可以將面粉分為70g與50g

答案：4次，第一次120g=111g+9g 第二次111g=93g+18g 第三次93g=57g+36g 第四次50g=57g-7g 70g=7g+36g+18g+9g

十五，扔雞蛋不碎問題（騰訊校招面試題）？

答案：14次

十六，智力題：一千瓶中有一瓶毒藥 十只小白鼠找出這瓶毒藥

答案：2^10=1024，小白鼠編號1-10，瓶子編號1-1000，把瓶子的編號轉變為二進制數，第幾位1，就給第幾個小白鼠喝

五、你還有什么想問的嗎（必答）

我非常希望能夠加入公司，所以想請問您覺得我還有哪些地方比較不足，能否給一些建議？以及是否有復試時間呢？

六、簡歷模板

可在公眾號(傷心的辣條)回復‘簡歷模板’獲取

關于我準備后的面試經歷、面試題匯總、面試結果

有興趣請繼續關注~

最后

如果對python自動化測試、web自動化、接口自動化、移動端自動化、面試經驗交流等等感興趣的測試人，可以關注微信公眾號：【傷心的辣條】，獲取軟件測試工程師大廠面試資料！

我的測試學習交流群：902061117 群里有技術大牛一起交流分享~

如果文章對你有感興趣，麻煩伸出發財小手點個贊，感謝您的支持，你的點贊是我持續更新的動力。

推薦好文：

包裝成1年工作經驗的測試工程師，我給他的面試前的建議如下

自動化測試到底要學什么？

為何跳槽不考慮騰訊？聊聊我和鵝廠的一點往事

自動化測試和手動測試哪個更高級？

新手必看：怎么寫一個合格的測試用例？

python登錄接口測試問題記錄與解決 ( 干 貨 )

總結

以上是生活随笔為你收集整理的知乎万赞：熬夜整理出的软件测试面试题大全（2021最新）的全部內容，希望文章能夠幫你解決所遇到的問題。

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