軟件測試面試題匯總

軟件測試面試題匯總

一、面試基礎題

簡述測試流程：

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

1PRDUIo

2、參加需求評審會議。

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

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

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

6、開發(fā)提交代碼至SVN或者GIT,配管搭建測試環(huán)境。

7、執(zhí)行測試用例，記錄發(fā)現(xiàn)的問題。

8、驗證bug與回歸測試。

9、編寫測試報告。

10、產品上線。

補充測試用例設計過程：

根據(jù)需求得出測試需求

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

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

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

使用人工或自動手段，來運行或測試某個系統(tǒng)的過程。其目的在

于檢驗它是否滿足規(guī)定的需求或弄清預期結果與實際結果之間

的差別。

軟件測試的目的：

測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯誤。

一個成功的測試用例在于發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤。

一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。

確保產品完成了它所承諾或公布的功能，并且用戶可以訪問到的

功能都有明確的書面說明。

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

確保產品是健壯的和適應用戶環(huán)境的。

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

軟件生存周期是軟件開發(fā)全部過程、活動和任務的結構框架，是

從可行性研究到需求分析、軟件設計、編碼、測試、軟件發(fā)布維

護的過程。在經(jīng)歷需求、分析、設計、實現(xiàn)、部署后，軟件將被

使用并進入維護階段，直到最后由于缺少維護費用而逐漸消亡。

這樣的一個過程，稱為“生命周期模型"(

LifeCycleModel)o

什么是軟件質量？

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

力。

自動化測試腳本開發(fā)的主要步驟：

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

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

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

4、添加斷言操作

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

白盒測試：邏輯覆蓋、循環(huán)覆蓋、基本路徑覆蓋

黑盒測試：邊界值分析法、等價類劃分、錯誤猜測法、因果圖法、

狀態(tài)圖法、測試大綱法、隨機測試場景法

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

這些方法在測試用例設計工作中的應用

1）等價類劃分劃分

等價類是指某個輸入域的子集合。在該子集合中，各個輸入數(shù)據(jù)

對于揭露程序中的錯誤都是等效的。并合理地假定:測試某等價

類的代表值就等于對這一類其它值的測試。因此，可以把全部輸

入數(shù)據(jù)合理劃分為若干等價類，在每一個等價類中取一個數(shù)據(jù)作

為測試的輸入條件，就可以用少量代表性的測試數(shù)據(jù)。取得較好

的測試結果。等價類劃分可有兩種不同的情況:有效等價類和無

效等價類。

2）邊界值分析法

邊界值分析方法是對等價類劃分方法的補充。測試工作經(jīng)驗告訴

我，大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上，而不是發(fā)生

在輸入輸出范圍的內部。因此針對各種邊界情況設（面試題目：

什么樣的工作環(huán)境適合你&#from一個常見的軟件測試面試題

來自end#lt;結束）計測試用例，可以查出更多的錯誤。

使用邊界值分析方法設計測試用例，首先應確定邊界情況。通常

輸入和輸出等價類的邊界，就是應著重測試的邊界情況。應當選

取正好等于，剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù)，而不

是選取等價類中的典型值或任意值作為測試數(shù)據(jù)。

3）錯誤推測法

基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤，從而有針

對性的設計測試用例的方法。

錯誤推測方法的基本思想：列舉出程序中所有可能有的錯誤和容

易發(fā)生錯誤的特殊情況，根據(jù)他們選擇測試用例。例如，在單元

測試時曾列出的許多在模塊中常見的錯誤。以前產品測試中曾經(jīng)

發(fā)現(xiàn)的錯誤等，這些就是經(jīng)驗的總結。還有，輸入數(shù)據(jù)和輸出數(shù)

據(jù)為0的情況。輸入表格為空格或輸入表格只有一行。這些都是

容易發(fā)生錯誤的情況?？蛇x擇這些情況下的例子作為測試用例。

4）因果圖方法

前面介紹的等價類劃分方法和邊界值分析方法，都是著重考慮輸

入條件，但未考慮輸入條件之間的聯(lián)系，相互組合等?？紤]輸入

條件之間的相互組合，可能會產生一些新的情況。但要檢查輸入

條件的組合不是一件容易的事情，即使把所有輸入條件劃分成等

價類，他們之間的組合情況也相當多。因此必須考慮采用一種適

合于描述對于多種條件的組合，相應產生多個動作的形式來考慮

設計測試用例。這就需要利用因果圖（邏輯模型）。因果圖方法最

終生成的就是判定表。它適合于檢查程序輸入條件的各種組合情

況。

5）正交表分析法

有時候，可能因為大量的參數(shù)的組合而引起測試用例數(shù)量上的激

增，同時，這些測試用例并沒有明顯的優(yōu)先級上的差距，而測試

人員又無法完成這么多數(shù)量的測試，就可以通過正交表來進行縮

減一些用例，從而達到盡量少的用例覆蓋盡量大的范圍的可能性。

6）場景分析方法

指根據(jù)用戶場景來模擬用戶的操作步驟，這個比較類似因果圖，

但是可能執(zhí)行的深度和可行性更好。

測試的策略有哪些？

黑盒/白盒/灰盒，靜態(tài)/動態(tài)，手工/自動，冒煙測試，回歸測試，

公測（Beta測試的策略）

補充：公測是什么？還有沒有其他的測試策略？測試策略和測試

方法以及測試類型有什么區(qū)別？

按測試策略分類：

1、靜態(tài)與動態(tài)測試

2、黑盒與白盒測試

3、手工和自動測試

4、冒煙測試

5、回歸測試；

按測試階段分類：單元測試、集成測試、系統(tǒng)測試；

其他常見測試方法：1、功能測試2、性能測試3、壓力測

試4、負載測試5、易用性測試6、安裝測試7、界面測試8、

配置測試9、文檔測試10、兼容性測試11、安全性測12、恢

復測試

a測試是由一個用戶在開發(fā)環(huán)境下進行的測試，也可以是公司內

部的用戶在模擬實際操作環(huán)境下進行的受控測試，Alpha測試

不能由程序員或測試員完成。

防則試是軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進

行的測試。開發(fā)者通常不在測試現(xiàn)場，Beta測試不能由程序員

或測試員完成。

回歸測試（對軟件的新版本測試時，重復執(zhí)行上一個版本測試時

的用例，是為了驗證缺陷是否真正修復，確認修復后是否影響其

它功能）；

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

現(xiàn)，是否具備可測性。

單元測試的策略有哪些？

邏輯覆蓋、循環(huán)覆蓋、同行評審、桌前檢查、代碼走查、代碼評

審、景泰數(shù)據(jù)流分析

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

答：用最少的實驗覆蓋最多的操作，測試用例設計很少，效率高，

但是很復雜；對于基本的驗證功能，以及二次集成引起的缺陷，

一般都能找出來"旦是更深的缺陷，更復雜的缺陷，還是無能為

力的；具體的環(huán)境下，正交表一般都很難做的。大多數(shù)，只在系

統(tǒng)測試的時候使用此方法。

補充什么時候用系統(tǒng)測試，測試的每個階段是什么比如單元、

集成、系統(tǒng)、公測，每個階段需要什么技術，有什么要求

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

(1)用戶認證機制：如數(shù)據(jù)證書、智能卡、雙重認證、安全電子

交易協(xié)議

(2)加密機制

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

描

(4)數(shù)據(jù)備份與恢復手段：存儲設備、存儲優(yōu)化、存儲保護、存

儲管理

(5)防病毒系統(tǒng)

軟件安全性測試包括程序、數(shù)據(jù)庫安全性測試。根據(jù)系統(tǒng)安全指

標不同測試策略也不同。

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

明確區(qū)分系統(tǒng)中不同用戶權限

系統(tǒng)中會不會出現(xiàn)用戶沖突

系統(tǒng)會不會因用戶的權限的改變造成混亂

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

是否可以通過絕對途徑登陸系統(tǒng)(拷貝用戶登陸后的鏈接直接進

入系統(tǒng))

用戶退出系統(tǒng)后是否刪除了所有鑒權標記，是否可以使用后退鍵

而不通過輸入口令進入系統(tǒng)

系統(tǒng)網(wǎng)絡安全的測試要考慮問題

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

模擬非授權攻擊，看防護系統(tǒng)是否堅固

采用成熟的網(wǎng)絡漏洞檢查工具檢查系統(tǒng)相關漏洞（即用最專業(yè)的

黑客攻擊工具攻擊試一下，現(xiàn)在最常用的是NBSI系列和

IPhackerIP）

采用各種木馬檢查工具檢查系統(tǒng)木馬情況

采用各種防外掛工具檢查系統(tǒng)各組程序的外掛漏洞

數(shù)據(jù)庫安全考慮問題：

系統(tǒng)數(shù)據(jù)是否機密（比如對銀行系統(tǒng)，這一點就特別重要，一般

的網(wǎng)站就沒有太高要求）系統(tǒng)數(shù)據(jù)的完整性（我剛剛結束的企業(yè)

實名核查服務系統(tǒng)中就曾存在數(shù)據(jù)的不完整，對于這個系統(tǒng)的功

能實現(xiàn)有了障礙）

系統(tǒng)數(shù)據(jù)可管理性

系統(tǒng)數(shù)據(jù)的獨立性

系統(tǒng)數(shù)據(jù)可備份和恢復能力（數(shù)據(jù)備份是否完整，可否恢復，恢

復是否可以完整）

a測試是由一個用戶在開發(fā)環(huán)境下進行的測試，也可以是公司內

部的用戶在模擬實際操作環(huán)境下進行的受控測試，Alpha測試

不能由程序員或測試員完成。

B測試是軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進

行的測試。開發(fā)者通常不在測試現(xiàn)場，Beta測試不能由程序員

或測試員完成。

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

是否使用了公司的模板

文檔內容是否符合規(guī)范

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

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

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

需求可否用己知的約束來實現(xiàn)

需求是否足夠（即，可以把它送到一個規(guī)范的開發(fā)組織，并

有一個生產出所需要產品的合理的可能性）

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

用戶描述是否清楚

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

每個需求描述是否清楚沒有岐義，可以移交給一個獨立的組

去實現(xiàn)時也能理解

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

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

它需求

性能指標是否明確

非功能性需求是否得到充分表現(xiàn)

是否完整列出適用的標準或協(xié)議

標準和協(xié)議之間是否存在沖突

問：你在測試中發(fā)現(xiàn)了一個bug，但是開發(fā)經(jīng)理認為這不是一

介bug，你應該怎樣解決。

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

要獲取判斷的依據(jù)和標準：根據(jù)需求說明書、產品說明、設計

文檔等，確認實際結果是否與計劃有不一致的地方，提供缺陷是

否確認的直接依據(jù)；如果沒有文檔依據(jù)，可以根據(jù)類似軟件的

一般特性來說明是否存在不一致的地方，來確認是否是缺陷；根

據(jù)用戶的一般使用習慣，來確認是否是缺陷；

與設計人員、開發(fā)人員和客戶代表等相關人員探討，確認是否是

缺陷；

合理的論述，向測試經(jīng)理說明自己的判斷的理由，注意客觀、嚴

謹，不參雜個人情緒。

等待測試經(jīng)理做出最終決定，如果仍然存在爭議，可以通過公司

政策所提供的渠道，向上級反映，并有上級做出決定。

問：給你一個網(wǎng)站，你如何測試？

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

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

個部分：

功能性測試；界面測試；性能測試；數(shù)據(jù)庫測試；安全性測試；

兼容性測試

3、設計測試用例：

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

鏈接測試。鏈接是否正確跳轉，是否存在空頁面和無效頁面，是

否有不正確的出錯信息返回等。提交功能的測試。

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

顯示選擇的語言等。

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

頁面是否風格統(tǒng)一，美觀

文字檢查

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

控件是否正常使用

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

問：一臺客戶端有三百個客戶與三百個客戶端有三百個客戶對服

務器施壓，有什么區(qū)別？

300個用戶在一個客戶端上，會占用客戶機更多的資源，而影

響測試的結果。線程之間可能發(fā)生干擾，而產生一些異常。300

個用戶在一個客戶端上，需要更大的帶寬。IP地址的問題，可

能需要使用IPSpoof來繞過服務器對于單一IP地址最大連

接數(shù)的限制。所有用戶在一個客戶端上，不必考慮分布式管理的

問題；而用戶分布在不同的客戶端上，需要考慮使用控制器來整

體調配不同客戶機上的用戶。同時，還需要給予相應的權限配置

和防火墻設置。

你工作中遇到最具價值的bug,就是重大bug咯，例如app性

能測試測哪些，那你就看一看性能測試的視頻咯

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

軟件安全性測試包括程序、數(shù)據(jù)庫安全性測試。根據(jù)系統(tǒng)安全指

標不同測試策略也不同。

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

明確區(qū)分系統(tǒng)中不同用戶權限

系統(tǒng)中會不會出現(xiàn)用戶沖突

系統(tǒng)會不會因用戶的權限的改變造成混亂

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

是否可以通過絕對途徑登陸系統(tǒng)（拷貝用戶登陸后的鏈接直接進

入系統(tǒng)）

用戶退出系統(tǒng)后是否刪除了所有鑒權標記，是否可以使用后退鍵

而不通過輸入口令進入系統(tǒng)

系統(tǒng)網(wǎng)絡安全的測試要考慮問題

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

模擬非授權攻擊，看防護系統(tǒng)是否堅固

采用成熟的網(wǎng)絡漏洞檢查工具檢查系統(tǒng)相關漏洞（即用最專業(yè)的

黑客攻擊工具攻擊試一下.

現(xiàn)在最常用的是NBSI系列和IPhackerIP）

采用各種木馬檢查工具檢查系統(tǒng)木馬情況

采用各種防外掛工具檢查系統(tǒng)各組程序的外掛漏洞

數(shù)據(jù)庫安全考慮問題：

系統(tǒng)數(shù)據(jù)是否機密（比如對銀行系統(tǒng)，這一點就特別重要，一般

的網(wǎng)站就沒有太高要求）

系統(tǒng)數(shù)據(jù)的完整性（我剛剛結束的企業(yè)實名核查服務系統(tǒng)中就曾

存在數(shù)據(jù)的不完整，對于這個系統(tǒng)的功能實現(xiàn)有了障礙）

系統(tǒng)數(shù)據(jù)可管理性

系統(tǒng)數(shù)據(jù)的獨立性

系統(tǒng)數(shù)據(jù)可備份和恢復能力（數(shù)據(jù)備份是否完整，可否恢復，恢

復是否可以完整）

軟件質量保證體系是什么國家標準中與質量保證管理相關的幾

個標準是什么？？他們的編號和全稱是什么？？

SQA由一套軟件工程過程和方法組成，以保證（軟件的）質量。

SQA貫穿整個軟件開發(fā)過程，（它）應包括需求文檔評審、代碼

控制、代碼評審、變更管理、配置管理、版本管理和軟件測試。

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

1、尋找Bug;

2、避免軟件開發(fā)過程中的缺陷；

3、衡量軟件的品質；

4、關注用戶的需求。

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

在您以往的工作中，一條軟件缺陷（或者叫Bug）記錄都包含

了哪些內容？如何提交高質量的軟件缺陷（Bug）記錄？

一條Bug記錄最基本應包含：編號、Bug所屬模塊、Bug描

述、Bug級別、發(fā)現(xiàn)日期、發(fā)現(xiàn)人、修改日期、修改人、修改

方法、回歸結果等等；

要有效的發(fā)現(xiàn)Bug需參考需求以及詳細設計等前期文檔設計

出高效的測試用例，然后嚴格執(zhí)行測試用例，對發(fā)現(xiàn)的問題要充

分確認

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

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

自的優(yōu)點和缺點！

黑盒測試的優(yōu)點有：比較簡單，不需要了解程序內部的代碼及實

現(xiàn)；與軟件的內部實現(xiàn)無關；從用戶角度出發(fā)，能很容易的知道

用戶會用到哪些功能，會遇到哪些問題；基于軟件開發(fā)文檔，所

以也能知道軟件實現(xiàn)了文檔中的哪些功能；在做軟件自動化測試

時較為方便。

黑盒測試的缺點有：不可能覆蓋所有的代碼，覆蓋率較低，大概

只能達到總代碼量的30%;自動化測試的復用性較低。

白盒測試的優(yōu)點有：幫助軟件測試人員增大代碼的覆蓋率，提高

代碼的質量，發(fā)現(xiàn)代碼中隱藏的問題。

白盒測試的缺點有：程序運行會有很多不同的路徑，不可能測試

所有的運行路徑；測試基于代碼，只能測試開發(fā)人員做的對不對，

而不能知道設計的正確與否，可能會漏掉一些功能需求；系統(tǒng)龐

大時，測試開銷會非常大。

什么是系統(tǒng)瓶頸？

參考答案：

瓶頸主要是指整個軟硬件構成的軟件系統(tǒng)某一方面或者幾個方

面能力不能滿足用戶的特定業(yè)務要求，"特定”是指瓶頸會在某

些條件下會出現(xiàn)，因為畢竟大多數(shù)系統(tǒng)在投入前。

嚴格的從技術角度講，所有的系統(tǒng)都會有瓶頸，因為大多數(shù)系統(tǒng)

的資源配置不是協(xié)調的，例如CPU使用率剛好達到100%時，

內存也正好耗盡的系統(tǒng)不是很多見。因此我們討論系統(tǒng)瓶頸要從

應用的角度討論：關鍵是看系統(tǒng)能否滿足用戶需求。在用戶極限

使用系統(tǒng)的情況下，系統(tǒng)的響應仍然正常，我們可以認為改系統(tǒng)

沒有瓶頸或者瓶頸不會影響用戶工作。

因此我們測試系統(tǒng)瓶頸主要是實現(xiàn)下面兩個目的：

-發(fā)現(xiàn)"表面"的瓶頸。主要是模擬用戶的操作，找出用戶極限

使用系統(tǒng)時的瓶頸，然后解決瓶頸，這是性能測試的基本目標。

-發(fā)現(xiàn)潛在的瓶頸并解決，保證系統(tǒng)的長期穩(wěn)定性。主要是考慮

用戶在將來擴展系統(tǒng)或者業(yè)務發(fā)生變化時，系統(tǒng)能夠適應變化。

滿足用戶目前需求的系統(tǒng)不是最好的，我們設計系統(tǒng)的目標是在

保證系統(tǒng)整個軟件生命周期能夠不斷適應用戶的變化，或者通過

簡單擴展系統(tǒng)就可以適應新的變化。

手機APP測試

:主要包括功能、性能測試、穩(wěn)定性、兼容性、用戶測試。

性能測試：CPU占用/內存占用/耗電測試/流量消耗測試/安

裝包大小/加載時間測試/核心功能相應時間（①啟動時間檢

測：檢測App在終端上首次啟動時間。②內存、CPU耗用檢測：

檢測App在終端上運行時不同時段占用內存、CPU情況。③流

量耗用檢測：檢測App在終端上運行時的網(wǎng)絡流量消耗情況。

④電池溫度檢測：檢測App在終端上運行時，對終端的電池溫

度等性能指標的影響情況）

兼容性測試：屏幕分辨率/網(wǎng)絡狀態(tài)，狀態(tài)切換/android版本

/安裝卸載升級等/權限設置/與其他APP兼容性（①安裝卸載

測試：測試App在指定終端上是否可正常安裝、正常卸載，準

確定位錯誤原因。②遍歷測試：自動識別App可執(zhí)行的功能，

在一定時間內遍歷App的不同功能界面，通過截圖記錄操作路

徑并輸出日志、定位異常現(xiàn)象。③運行穩(wěn)定性測試：類似

Monkey的隨機性壓力測試，測試App運行期的穩(wěn)定性。④UI

適配測試：測試App的UI與目標終端的屏幕是否適配，記錄是

否存在渲染失敗、錯位、黑邊框、黑白屏等現(xiàn)象。）

穩(wěn)定性測試包括：服務器異常時穩(wěn)定性/外部事件影響（電話，

短信等）/內存是否有溢出或者泄漏/多線程問題。

什么是并發(fā)？在lordrunner中，如何進行并發(fā)的測試？集合點

失敗了會怎么樣？

參考答案：

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

LoadRunner中提供IP偽裝，集合點，配合虛擬用戶的設計，

以及在多臺電腦上設置，可以比較好的模擬真實的并發(fā)。

集合點，即是多個用戶在某個時刻，某個特定的環(huán)境下同時進行

虛擬用戶的操作的。集合點失敗，則集合點的才操作就會取消，

測試就不能進行。

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

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

項目經(jīng)理通過和客戶的交流，完成需求文檔，由開發(fā)人員和測試

人員共同完成需求文檔的評審，評審的內容包括：需求描述不清

楚的地方和可能有明顯沖突或者無法實現(xiàn)的功能的地方。項目經(jīng)

理通過綜合開發(fā)人員，測試人員以及客戶的意見，完成項目計劃。

然后SQA進入項目，開始進行統(tǒng)計和跟蹤開發(fā)人員根據(jù)需求文

檔完成需求分析文檔，測試人員進行評審，評審的主要內容包括

是否有遺漏或者雙方理解不同的地方。測試人員完成測試計劃文

檔，測試計劃包括的內容上面有描述。測試人員根據(jù)修改好的需

求分析文檔開始寫測試用例，同時開發(fā)人員完成概要設計文檔,

詳細設計文檔。此兩份文檔成為測試人員撰寫測試用例的補充材

料。測試用例完成后，測試和開發(fā)需要進行評審。測試人員搭建

環(huán)境開發(fā)人員提交第一個版本，可能存在未完成功能，需要說明。

測試人員進行測試，發(fā)現(xiàn)后提交給開發(fā)提交

BUGBugZillao

第二個版本，包括BugFix以及增加了部分功能，測試人員進

行測試。重復上面的工作，一般是3-4個版本后BUG數(shù)量減

少，達到出貨的要求。如果有客戶反饋的問題，需要測試人員協(xié)

助重現(xiàn)并重新測試。

在您以往的工作中，一條軟件缺陷（或者叫Bug）記錄都包含

了哪些內容？如何提交高質量的軟件缺陷（Bug）記錄？

在傳統(tǒng)的BugZilla中,BUG描述應該包括以下的信息和BUG

產生對應的軟件版本和模塊開發(fā)的接口人員BUG的優(yōu)先級

BUG的嚴重程度BUG可能屬于的模塊，如果不能確認，可以

用開發(fā)人員來判斷BUG標題，需要清晰的描述現(xiàn)象BUG描述,

需要盡量給出重新Bug的步驟BUG附件中能給出相關的日志

和截圖。高質量的BUG記錄就是指很容易理解的BUG記錄，

所以，對于描述的要求高，能提供的信息多且準確，很好的幫助

開發(fā)人員定位，因此提交高質量的軟件缺陷記錄需要注意對

BUG記錄的描述質量多且準確。

您認為在測試人員同開發(fā)人員的溝通過程中，如何提高溝通的效

率和改善溝通的效果？維持測試人員同開發(fā)團隊中其他成員良

好的人際關系的關鍵是什么？

盡量面對面的溝通，其次是能直接通過電話溝通，如果只能通過

Email等非及時溝通工具的話，強調必須對特性的理解深刻以及

能表達清楚。運用一些測試管理工具如TestDirector進行管理

也是較有效的方法，同時要注意在TestDirector中對BUG有

準確的描述。在團隊中建立測試人員與開發(fā)人員良好溝通中注意

以下幾點：一真誠二是團隊精神三是在專業(yè)上有共同語言四是要

對事不對人，工作至上當然也可以通過直接指出一些小問題，而

不是進入BUGTrackingSystem來增加對方的好感。

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

軟件測試應該在需求分析階段就介入，因為測試的對象不僅僅是

程序編碼，應該對軟件開發(fā)過程中產生的所有產品都測試，并且軟

件缺陷存在放大趨勢.缺陷發(fā)現(xiàn)的越晚，修復它所花費的成本就越

大.

測試結束的標準是什么？

從微觀上來說，在測試計劃中定義，比如系統(tǒng)在一定性能下平穩(wěn)

運行72小時，目前BugTrackingSystem中，本版本中沒有

一般嚴重的BUG,普通BUG的數(shù)量在3以下，BUG修復率

90%以上等等參數(shù)，然后由開發(fā)經(jīng)理，測試經(jīng)理，項目經(jīng)理共同

簽字認同版本Release。如果說宏觀的，則是當這個軟件徹底的

消失以后，測試就結束了。

您是否了解以往所工作的企業(yè)的軟件開發(fā)過程？如果了解，請試

述一個完整的開發(fā)過程需要完成哪些工作？分別由哪些不同的

角色來完成這些工作？您在以往的測試工作中都曾經(jīng)具體從事

過哪些工作？其中最擅長哪部分工作？

開發(fā)過程--需求調研（需求人員）、需求分析（需求人員）、

概要設計（設計人員）、詳細設計（設計人員）、編碼（開發(fā)人員）

測試過程---需求評審、系統(tǒng)測試設計、概要設計評審、集成測

試設計、詳細設計評審、單元測試設計、測試執(zhí)行測試工作的整

個過程都做過，擅長做測試設計過程決定質量，軟件的過程改進

正是為了提高軟件的質量，將過往的種種經(jīng)驗和教訓積累起來。

補充

1.明確測試的目標，增強測試計劃的實用性編寫軟件測試計劃得

重要目的就是使測試過程能夠發(fā)現(xiàn)更多的軟件缺陷，因此軟件測

試計劃的價值取決于它對幫助管理測試項目，并且找出軟件潛在

的缺陷。因此，軟件測試計劃中的測試范圍必須高度覆蓋功能需

求，測試方法必須切實可行，測試工具并且具有較高的實用性,

便于使用，生成的測試結果直觀、準確

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

測試計劃寫作完成后，如果沒有經(jīng)過評審，直接發(fā)送給測試團隊，

測試計劃內容的可能不準確或遺漏測試內容，或者軟件需求變更

引起測試范圍的增減，而測試計劃的內容沒有及時更新，誤導測

試執(zhí)行人員。分別創(chuàng)建測試計劃與測試詳細規(guī)格、測試用例，應

把詳細的測試技術指標包含到獨立創(chuàng)建的測試詳細規(guī)格文檔，把

用于指導測試小組執(zhí)行測試過程的測試用例放到獨立創(chuàng)建的測

試用例文檔或測試用例管理數(shù)據(jù)庫中。測試計劃和測試詳細規(guī)格、

測試用例之間是戰(zhàn)略和戰(zhàn)術的關系，測試計劃主要從宏觀上規(guī)劃

測試活動的范圍、方法和資源配置，而測試詳細規(guī)格、測試用例

是完成測試任務的具體戰(zhàn)術。

請你回答一下性能測試有哪些指標，對一個登錄功能做性能測試,

有哪些指標，怎么測出可同時處理的最大請求數(shù)量

參考回答：

性能測試常用指標：

從外部看，主要有

1、吞吐量：每秒鐘系統(tǒng)能夠處理的請求數(shù)，任務數(shù)

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

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

從服務器的角度看，性能測試關注CPU,內存，服務器負載，

網(wǎng)絡，磁盤工O

對登錄功能做性能測試

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

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

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

高并發(fā)場景下服務端的監(jiān)控指標是否符合預期

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

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

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

可以采用性能測試工具（WeTest服務器性能），該工具是騰訊

wetest團隊出品，使用起來很簡單方便，但測試功能相當強大，

能提供10w+以上的并發(fā)量，定位性能拐點，測出服務器模型最

大并發(fā)

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

兼容測試主要是檢查軟件在不同的硬件平臺、軟件平臺上是否可

以正常的運行，即是通常說的軟件的可移植性。兼容的類型，如

果細分的話，有平臺的兼容，網(wǎng)絡兼容，數(shù)據(jù)庫兼容，以及數(shù)據(jù)

格式的兼容。兼容測試的重點是，對兼容環(huán)境的分析。通常，是

在運行軟件的環(huán)境不是很確定的情況下，才需要做兼容。根據(jù)軟

件運行的需要，或者根據(jù)需求文檔，一般能夠得出用戶會在什么

環(huán)境下使用該軟件，把這些環(huán)境整理成表單，就得出做兼容測試

的兼容環(huán)境了

兼容和配置測試的區(qū)別在于，做配置測試通常不是在CleanOS

下做測試，而兼容測試多是在CleanOS環(huán)境下做的。

補充：做兼容測試的具體步驟：在列好的軟硬件環(huán)境清單做冒煙

測試，還是每一步都測試。測出不兼容，怎么和開發(fā)溝通，開發(fā)

面對這些不兼容需要做什么。如果修復成本很高，怎么和產品經(jīng)

理溝通。和誰確認表單

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

軟件測試應該在需求分析階段就介入，因為測試的對象不僅僅是

程序編碼，應該對軟件開發(fā)

過程中產生的所有產品都測試,并且軟件缺陷存在放大趨勢.缺陷

發(fā)現(xiàn)的越晚，修復它所花費的成本就越大.

二、測試實戰(zhàn)面試題

我現(xiàn)在有個程序，發(fā)現(xiàn)在Windows上運行的很慢，怎么判別是

程序存在問題還是軟硬件系統(tǒng)存在問題

1、檢查系統(tǒng)是否有中毒的特征

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

3、確認當前的系統(tǒng)是否獨立，即沒有對外提供什么消耗CPU資

源的服務

4、如果是C/S或者B/S結構的軟件，需要檢查是不是因為與服

務器的連接有問題，或者訪問有問題造成

5、在系統(tǒng)沒有任何負載的情況下，查看性能監(jiān)視器，確認應用

程序對CPU/內存的訪問情況

補充：每一步該怎么實現(xiàn)，需要用到什么技術

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

4n+l

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

1）功能

a）ATM所識別卡的類型;

b）密碼驗證（身份登陸、是否為掩碼、輸入錯誤密碼時是否提示，

連續(xù)三次錯誤吞卡等）；

C）取款功能：

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

額等）；

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

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

e）查詢功能是否正常；

f）轉賬功能是否正常；

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

2）性能

a）是否有自動吞卡：非法客戶'密碼錯誤客戶'規(guī)定時間內未完成

相關操作功能的客戶。（如果有，有無報警功能（保密報警））

b）平均無故障時間，平均故障修復時間，輸入密碼后驗證時間，

出鈔票時間，查詢余額等待時間。

3）易用性

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

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

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

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

功能；

如何測試一個紙杯？

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

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

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

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

用

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

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

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

細描述

疲勞測試：將杯子盛上水（案例一）放24小時檢查泄漏時間

和情況；盛上汽油（案例二）

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

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

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

首先我要測它的外觀、顏色是否符合要求、所占的空間是多大、

是否環(huán)保、接下來測它的質量、這支筆是否能夠寫字流暢、寫出

的自得顏色是否符合要求、能使用多長時間等

測試手機開機鍵

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

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

壓力測試：連續(xù)多次按下開機鍵，觀察屏幕是否能一直亮起，到

多久時間失靈

健壯性測試：給定一個中了病毒的手機或者是淘汰許久的老機子，

安歇開機鍵觀察屏幕能否亮起

可靠性測試：連續(xù)按下開機鍵有限次數(shù)，比如1萬次，記錄屏幕

未亮起的次數(shù)

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

手指，開機鍵的位置設計是否方便

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

濯8人手機號/郵箱

■記住用戶名和密碼忘記密碼

首先，進行界面測試。

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

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

驗證碼是否能夠顯示；

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

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

第二，進行功能測試。

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

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

密碼錯誤；

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

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

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

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

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

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

就是能不能跳轉）

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

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

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

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

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

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

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

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

用戶登錄過程中l(wèi)og中是否有個人信息明文打印；

是否支持第三方登陸；

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

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

不同級別的用戶，比如管理員用戶和普通用戶，登錄系統(tǒng)后的權

限是否正確；

第三、業(yè)務安全測試。

有沒有登陸錯誤次數(shù)的限制；

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

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

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

不登錄的情況下，在瀏覽器中直接輸入登錄后的URL地址，驗

證是否會重新定向到用戶登錄界面；

第四、兼容性測試。

在相同瀏覽器的不同版本上打開登錄頁面，效果是否一致；在不

同瀏覽器上打開登錄頁面，效果是否一致；在不同操作系統(tǒng)的不

同瀏覽器打開登錄頁面，效果是否一致；在不同的屏幕分辨率下

打開登錄頁面，效果是否一致；

第五、代碼安全性測試。

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

欄；

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

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

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

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

用戶名和密碼的輸入框中分別輸入典型的"SQL注入攻擊"字符

串，驗證系統(tǒng)的返回頁面；

用戶名和密碼的輸入框中分別輸入典型的"XSS跨站腳本攻擊"

字符串，驗證系統(tǒng)行為是否被篡改；

第六、頁面性能測試。

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

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

通過工具對登陸功能進行并發(fā)測試；通過工具向登錄頁發(fā)起大量

請求，查看頁面何時崩潰；

通過工具向登錄頁發(fā)起大量請求，查看頁面崩潰后有沒有良好的

提示信息；

通過工具向登錄頁發(fā)起大量請求，查看頁面崩潰后多長時間能夠

恢復服務；

弱網(wǎng)，不同網(wǎng)速時登陸的時間，網(wǎng)絡切換和網(wǎng)絡延遲時登陸界面

是否正常；

最后、易用性測試。

頁面是否美觀；

功能是否都可以使用；

頁面速度快不快；

頁面元素加載是否耗費網(wǎng)絡流量；

能不能第三方登陸；

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

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

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

G9

/J\/J\購物車

全部商益3H至.啟曲Shfl

O有里統(tǒng)亞窗小計小

Q怛及“的金（SQ）/食店?

員亮，駕8?字無餐女斛和男方更＞240g帆am熱雙.*79.00X.M79.00—

—五篁好日二包！麗內衣貨Xl/175（ttfWnil3O-.‘夜總版的關注

|2，百1%前可女曼接W星-uS3?K?

反理困一。/電9拒把m辦公室反.宣*39.901+￥39.90Mt

及由5—手JtS郵厘先期的■IV&~冬曲泄？

軍劭海給的，2件.取李堂拜玳》永賽9B?

國國三磊多苓15元茶—粵（￡，奈）:三灣注:*35,80￥71.60??

大餐一5一a公立■去^遷?景m15?-岬我的關w

已應151件題向人Y/9.00

□至日*2中愛品￥時關注JfiflHig14

=-*0.00

?用物生解你選

1.功能測試

a）、未登錄時：

將商品加入購物車，頁面跳轉到登錄頁面，登錄成功后購物車數(shù)

量增加。

b）、登錄后：

所有鏈接是否跳轉正確；

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

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

購物車商品總數(shù)是否有限制；

商品總數(shù)統(tǒng)計是否正確；

全選功能是否可用；

刪除功能是否可用；

刪除功能是否有提示；

價格總計是否正確；

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

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

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

車中不存在的店鋪的商品）；

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

商品刪除后商品總數(shù)是否減少；

收藏功能是否可用；

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

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

限購商品按照規(guī)則購買完成后，還能不能再次添加購物車并購買;

2.兼容性測試

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

APP:在主流的不同類型，不同分辨率，不同操作系統(tǒng)的手機上

測試，華為，vivo,oppo等

3.用戶體驗測試

刪除商品是否有提示；

是否支持快捷鍵功能；

是否有回到頂部的功能；

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

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

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

文字是否顯示清晰;

不同賣家的商品是否區(qū)分明顯。

4.性能測試

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

支付流程測試

功能測試。

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

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

支付方式是否支持掃碼支付，第三方平臺支付（支付包云網(wǎng)等）,

語音支付，指紋支付；

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

找他人代付；

用邊界值法有無支付額度限制，余額不足時有無提示，支付時是

否是動態(tài)加密支付；

待支付狀態(tài)：訂單是否可以正常支付；是否可以取消；有相同訂

單是否可以支付兩次；

是否可以掃碼支付，輸入錯誤的密碼會怎樣顯示，有無錯誤次數(shù)

限制；

若支持掃碼支付，二維碼是否支持支付包和微信掃碼，若兩人同

時掃描怎么處理；

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

理；

如果支付包含優(yōu)惠金額，該怎么處理優(yōu)惠額度；

性能測試

弱網(wǎng)，無網(wǎng)時是否可以支付；

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

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

統(tǒng)的用戶數(shù)量；

壓力測試

多人同時付款；

界面測試；

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

兼容性測試

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

安全性測試；

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

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

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

接口測試

第三方平臺支付

對于有系統(tǒng)大量并發(fā)訪問，你會如何做測試，有什么建議

參考回答：

如何做高并發(fā)系統(tǒng)的測試，一般而言，整體的測試策略是：先針

對部分系統(tǒng)進行性能測試及壓力測試，得到各部分的峰值處理性

能，再模擬整體流程測試，重點測試整體業(yè)務流程以及業(yè)務預期

負荷，著重測試以下幾點：

1、不同省份，不同運營商CDN節(jié)點性能，可采用典型壓力測

試方案

2、核心機房BGP網(wǎng)絡帶寬，此部分重點在于測試各運行商的

BGP網(wǎng)絡可靠性，實際速率，一般采用smokeping,IxChariot

等工具

3、各類硬件設備性能，一般采用專業(yè)的網(wǎng)絡設備測試工具

4、各類服務器并發(fā)性能，分布式處理能力，可采用壓力測試方

案工具

5、業(yè)務系統(tǒng)性能，采用業(yè)務系統(tǒng)壓力測試方案

6、數(shù)據(jù)庫處理性能，這部分需要結合業(yè)務系統(tǒng)進行測試，以獲

取核心業(yè)務場景下的數(shù)據(jù)庫的TPS/QPS,

7、如果有支付功能，需要進行支付渠道接口及分流測試，此部

分相對而言可能是最大的瓶頸所在，此外還涉及備份方案，容災

方案，業(yè)務降級方案的測試。

請對這個系統(tǒng)做出測試用例：一個系統(tǒng)，多個攝像頭抓拍車牌，

識別車牌，上傳網(wǎng)上，網(wǎng)上展示

參考回答：

功能：

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

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

3.系統(tǒng)能夠正確識別車牌；

4.系統(tǒng)能夠將識別出的車牌上傳；

5.上傳至網(wǎng)絡的車牌能夠正常展示出來；

一、功能測試

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

車牌；

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

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

能抓拍車牌；

4.在多種情況下檢查每個攝像頭抓拍到的車牌能否正常交給系

統(tǒng)處理，如臨時斷電、斷網(wǎng)后能否正常將數(shù)據(jù)交給系統(tǒng)；

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

車牌；

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

7.在多種情況下檢查系統(tǒng)能否將正常識別出的車牌進行上傳，如

臨時斷電、斷網(wǎng)后未上傳數(shù)據(jù)是否能繼續(xù)上傳；

8.構造非車牌的其他內容的數(shù)據(jù)，檢查系統(tǒng)能否將異常內容進行

上傳；

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

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

二、性能測試

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

到多個車牌；

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

否抓拍到多個車牌；

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

4.模擬大量抓拍照片同時交由系統(tǒng)處理，檢查一定壓力下系統(tǒng)能

否正常識別車牌；

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

三、安全性測試

1.檢查是否能夠通過給車牌加裝飾物等方法，使攝像頭無法抓拍

或抓拍后系統(tǒng)無法正常識別車牌。

請你說一說PC網(wǎng)絡故障，以及如何排除障礙

參考回答：

⑴首先是排除接觸故障，即確保你的網(wǎng)線是可以正常使用的。

然后禁用網(wǎng)卡后再啟用，排除偶然故障。打開網(wǎng)絡和共享中心窗

口，單擊窗口左上側"更改適配器設置"右擊其中的"本地連接

"或"無線網(wǎng)絡連接"，單擊快捷菜單中的"禁用"命令，即可

禁用所選網(wǎng)絡。接下來重啟網(wǎng)絡，只需右擊后單擊啟用即可。

(2)使用ipconfig查看計算機的上網(wǎng)參數(shù)

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

窗口

2、輸入ipconfig,按Enter確認，可以看到機器的配置信息，

輸入ipconfig/all,可以看至IJIP地址和網(wǎng)卡物理地址等相關網(wǎng)絡

詳細信息。

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

在命令提示符窗口中輸入"ping127.0.0.1,數(shù)據(jù)顯示本機分

別發(fā)送和接受了4個數(shù)據(jù)包，丟包率為零，可以判斷本機網(wǎng)絡協(xié)

議工作正常，如顯示"請求超時"，則表明本機網(wǎng)卡的安裝或

TCP/IP協(xié)議有問題，接下來就應該檢查網(wǎng)卡和TCP/IP協(xié)議，卸

載后重裝即可。

(4)ping本機IP

在確認127.0.0.1地址能被ping通的情況下，繼續(xù)使用ping命

令測試本機的IP地址能否被ping通，如不能，說明本機的網(wǎng)卡

驅動程序不正確，或者網(wǎng)卡與網(wǎng)線之間連接有故障，也有可能是

本地的路由表面收到了破壞，此時應檢查本機網(wǎng)卡的狀態(tài)是否為

已連接，網(wǎng)絡參數(shù)是否設置正確，如果正確可是不能ping通，

就應該重新安裝網(wǎng)卡驅動程序。丟失率為零，可以判斷網(wǎng)卡安裝

配置沒有問題，工作正常。

(5)ping網(wǎng)關

網(wǎng)關地址能被ping通的話，表明本機網(wǎng)絡連接以及正常，如果

命令不成功，可能是網(wǎng)關設備自身存在問題，也可能是本機上網(wǎng)

參數(shù)設置有誤，檢查網(wǎng)絡參數(shù)。

微信紅包

功能

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

2.紅包里最多和最少可以輸入的錢數(shù)2000.01

3.拼手氣紅包最多可以發(fā)多少個紅包100

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

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

5.當發(fā)送的紅包個數(shù)超過最大范圍是不是有提示

6.當余額不足時，紅包發(fā)送失敗

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

漢字英語符號，

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

8.輸入紅包錢數(shù)是不是只能輸入數(shù)字

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

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

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

13.發(fā)送的紅包別人是否可以領取

13.1發(fā)的紅包自己可不可以領取2人

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

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

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

16.發(fā)紅包的人是否還可以搶紅包多人

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

18.可以按返回鍵，取消發(fā)紅包

19.斷網(wǎng)時，無法搶紅包

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

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

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

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

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

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

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

27.發(fā)紅包金額和收到的紅包金額應該匹配

28.是否可以連續(xù)多次發(fā)紅包

29輸入錢數(shù)為0，"塞錢進紅包"置灰

性能

L弱網(wǎng)時搶紅包，發(fā)紅包時間

2.不同網(wǎng)速時搶紅包，發(fā)紅包的時間

3.發(fā)紅包和收紅包成功后的跳轉時間

4.收發(fā)紅包的耗電量

5.退款到賬的時間

兼容

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

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

界面

1.發(fā)紅包界面沒有錯別字

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

3.發(fā)紅包和收紅包界面排版合理，

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

安全

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

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

加

3.發(fā)送紅包失敗，余額和銀行卡里的錢數(shù)不會少

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

易用性（有點重復）

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

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

微信發(fā)朋友圈點贊

參考回答：

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

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

性能測試：點贊朋友圈，是否在規(guī)定時間顯示結果，是否在規(guī)定

時間在朋友手機上進行提示。

兼容性測試

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

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

參考回答：

一，功能測試

1.輸入關鍵字，查看：返回結果是否準確，返回的文本長度需

限制

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

鏈接正確性；

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

1.3輸入一些特殊的內容，如空、特殊符、標點符、極限值等，

可引入等價類劃分的方法等；

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

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

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

5.多選項搜索：關鍵字品牌產地價格區(qū)間是否天貓是否全

國購

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

7,網(wǎng)速慢的情況下的搜索

8.搜索結果為空的情況

9.未登錄情況和登錄情況下的搜索（登錄情況下存儲用戶搜索

的關鍵字/搜索習慣）

二.性能測試：

1壓力測試：在不同發(fā)用戶數(shù)壓力下的表現(xiàn)（評價指標如響應時

間等）

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

3穩(wěn)定性測試：常規(guī)壓力下能保持多久持續(xù)穩(wěn)定運行

4內存測試：有無內存泄漏現(xiàn)象

5大數(shù)據(jù)量測試：如模擬從龐大的海量數(shù)據(jù)中搜索結果、或搜索

出海量的結果后列示出來，看表現(xiàn)如何等等。

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

1依據(jù)不同的查詢結果會有相關的人性化提示，查不到時告知？

查到時統(tǒng)計條數(shù)并告知？有疑似輸入條件錯誤時提示可能正確

的輸入項等等處理；

2查詢出的結果羅列有序，如按點擊率或其他排序規(guī)則，確保每

次查詢出的結果位置按規(guī)則列示方便定位，顯示字體、字號、色

彩便于識別等等

3標題查詢、全文檢索、模糊查詢、容錯查詢、多關鍵字組織查

詢（空格間格開）等實用的檢索方式是否正常？

4輸入搜索條件的控件風格設計、位置擺放是否醒目便于使用者

注意到，有否快照等快捷查看方式等人性化設計？

四.兼容性

1WIND0WS/LINUX/UNIX等各類操作系統(tǒng)下及各版本條件下

的應用

2正/FIREFOX/GOOGLE/360/QQ等各類瀏覽器下及各版本條件

下、各種顯示分辨率條件下的應用

3SQL/ORACLE/DB2/MYSQL等各類數(shù)據(jù)庫存儲情況下的兼容

性測試

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

試

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

6與各相關的監(jiān)控程序的兼容性測試，如輸入法、殺毒、監(jiān)控、

防火墻等工具同時使用

五.安全性

1被刪除、加密、授權的數(shù)據(jù)，不允許被SQL注入等攻擊方式

查出來的，是否有安全控制設計；

2錄入一些數(shù)據(jù)庫查詢的保留字符，如單引號、％等等，造成查

詢SQL拼接出的語句產生漏洞，如可以查出所有數(shù)據(jù)等等，這

方面要有一些黑客攻擊的思想并引入一些工具和技術，如爬網(wǎng)等。

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

的隱患；

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

制；

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

功能

拷貝的文件

1）大?。篛k,lk,10k,100k,1000k...

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

2mp3avis

文件源目錄

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

2）目