测试问题汇总
一、面試基礎題
簡述測試流程:
1、閱讀相關技術文檔（如產品PRD、UI設計、產品流程圖等）。
2、參加需求評審會議
3、根據(jù)最終確定的需求文檔編寫測試計劃。
4、編寫測試用例（等價類劃分法、邊界值分析法等）。
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ā)布維護的過程。在經歷需求、分析、設計、實現(xiàn)、部署后，軟件將被使用并進入維護階段，直到最后由于缺少維護費用而逐漸消亡。這樣的一個過程，稱為"生命周期模型"（Life Cycle Model）。
什么是軟件質量？
軟件質量：軟件產品的特性可以滿足用戶的功能、性能需求的能力。
自動化測試腳本開發(fā)的主要步驟:
1、通過某些方式定位到我們要執(zhí)行的對象、目標( Target)
2、對這個對象進行什么操作(command)
3、通過操作對定位到的元素賦值(value)
4、添加斷言操作
目前主要的測試用例設計方法是什么？
白盒測試：邏輯覆蓋、循環(huán)覆蓋、基本路徑覆蓋
黑盒測試：邊界值分析法、等價類劃分、錯誤猜測法、因果圖法、狀態(tài)圖法、測試大綱法、隨機測試場景法
常見的測試用例設計方法都有哪些?請分別以具體的例子來說明這些方法在測試用例設計工作中的應用
1）等價類劃分劃分
等價類是指某個輸入域的子集合。在該子集合中，各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的。并合理地假定:測試某等價類的代表值就等于對這一類其它值的測試。因此，可以把全部輸入數(shù)據(jù)合理劃分為若干等價類，在每一個等價類中取一個數(shù)據(jù)作為測試的輸入條件，就可以用少量代表性的測試數(shù)據(jù)。取得較好的測試結果。等價類劃分可有兩種不同的情況:有效等價類和無效等價類。
2）邊界值分析法
邊界值分析方法是對等價類劃分方法的補充。測試工作經驗告訴我，大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上，而不是發(fā)生在輸入輸出范圍的內部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。
使用邊界值分析方法設計測試用例，首先應確定邊界情況。通常輸入和輸出等價類的邊界，就是應著重測試的邊界情況。應當選取正好等于，剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù)，而不是選取等價類中的典型值或任意值作為測試數(shù)據(jù)。
3）錯誤推測法
基于經驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法。
錯誤推測方法的基本思想：列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況，根據(jù)他們選擇測試用例。例如，在單元測試時曾列出的許多在模塊中常見的錯誤。以前產品測試中曾經發(fā)現(xiàn)的錯誤等，這些就是經驗的總結。還有，輸入數(shù)據(jù)和輸出數(shù)據(jù)為0的情況。輸入表格為空格或輸入表格只有一行。這些都是容易發(fā)生錯誤的情況。可選擇這些情況下的例子作為測試用例。
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、恢復測試
α測試是由一個用戶在開發(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)安全指標不同測試策略也不同。
1.用戶認證安全的測試要考慮問題：
? 明確區(qū)分系統(tǒng)中不同用戶權限
? 系統(tǒng)中會不會出現(xiàn)用戶沖突
? 系統(tǒng)會不會因用戶的權限的改變造成混亂
? 用戶登陸密碼是否是可見、可復制
? 是否可以通過絕對途徑登陸系統(tǒng)（拷貝用戶登陸后的鏈接直接進入系統(tǒng)）
? 用戶退出系統(tǒng)后是否刪除了所有鑒權標記，是否可以使用后退鍵而不通過輸入口令進入系統(tǒng)
2.系統(tǒng)網絡安全的測試要考慮問題
? ?測試采取的防護措施是否正確裝配好，有關系統(tǒng)的補丁是否打上
? ?模擬非授權攻擊，看防護系統(tǒng)是否堅固
? ?采用成熟的網絡漏洞檢查工具檢查系統(tǒng)相關漏洞（即用最專業(yè)的黑客攻擊工具攻擊試一下，現(xiàn)在? ? ?最常用的是 NBSI 系列和 IPhacker IP ）
? ?采用各種木馬檢查工具檢查系統(tǒng)木馬情況
? ?采用各種防外掛工具檢查系統(tǒng)各組程序的外掛漏洞
3.數(shù)據(jù)庫安全考慮問題：
? ?系統(tǒng)數(shù)據(jù)是否機密（比如對銀行系統(tǒ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ù)備份是否完整，可否恢復，恢復是否可以完整）
? ? α測試是由一個用戶在開發(fā)環(huán)境下進行的測試，也可以是公司內部的用戶在模擬實際操作環(huán)境下? ? ? ?進行的受控測試，Alpha 測試不能由程序員或測試員完成。
? ? ?β測試是軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進行的測試。開發(fā)者通常不在測? ? ? ? ?試現(xiàn)場，Beta 測試不能由程序員或測試員完成。
需求測試的注意事項有哪些？
? ? ? ?是否使用了公司的模
? ? ? ?文檔內容是否符合規(guī)范
所有的需求是分級是否清晰適當？
所有的需求是否具有一致性
需求是否可行（即，該需求組合有解決方案）
需求可否用己知的約束來實現(xiàn)
需求是否足夠（即，可以把它送到一個規(guī)范的開發(fā)組織，并有一個生產出所需要產品的合理的可能性）
所有的其它需求是交叉引用是否正確
用戶描述是否清楚
是否用客戶的語言來描述需求
每個需求描述是否清楚沒有岐義，可以移交給一個獨立的組去實現(xiàn)時也能理解
是否所有的需求都是可驗證的
是否每條需求都具有獨立性，即使發(fā)生了變化也不會影響其它需求
性能指標是否明確
非功能性需求是否得到充分表現(xiàn)
是否完整列出適用的標準或協(xié)議
標準和協(xié)議之間是否存在沖突
問：你在測試中發(fā)現(xiàn)了一個 bug ，但是開發(fā)經理認為這不是一個 bug ，你應該怎樣解決。
將問題提交到缺陷管理庫里面進行備案。
要獲取判斷的依據(jù)和標準： 根據(jù)需求說明書、產品說明、設計文檔等，確認實際結果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據(jù)； 如果沒有文檔依據(jù)，可以根據(jù)類似軟件的一般特性來說明是否存在不一致的地方，來確認是否是缺陷； 根據(jù)用戶的一般使用習慣，來確認是否是缺陷；
與設計人員、開發(fā)人員和客戶代表等相關人員探討，確認是否是缺陷；
合理的論述，向測試經理說明自己的判斷的理由，注意客觀、嚴謹，不參雜個人情緒。
等待測試經理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反映，并有上級做出決定。
問：給你一個網站，你如何測試？
1、查找需求說明、網站設計 等相關文檔，分析測試需求。
2、制定測試計劃，確定測試范圍和測試策略，一般包括以下幾個部分：
功能性測試；界面測試；性能測試；數(shù)據(jù)庫測試；安全性測試；兼容性測試
3、設計測試用例：
功能性測試可以包括，但不限于以下幾個方面：
鏈接測試。鏈接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯信息返回等。提交功能的測試。
多媒體元素是否可以正確加載和顯示。多語言支持是否能夠正確顯示選擇的語言等。
界面測試可以包括但不限于一下幾個方面：
頁面是否風格統(tǒng)一，美觀
文字檢查
對于必須但為安裝的空間，是否提供自動下載并安裝的功能
控件是否正常使
頁面布局是否合理，重點內容和熱點內容是否突出
問：一臺客戶端有三百個客戶與三百個客戶端有三百個客戶對服務器施壓，有什么區(qū)別?
300 個用戶在一個客戶端上，會占用客戶機更多的資源，而影響測試的結果。線程之間可能發(fā)生干擾，而產生一些異常。300 個用戶在一個客戶端上，需要更大的帶寬。IP 地址的問題，可能需要使用 IP Spoof 來繞過服務器對于單一 IP 地址最大連接數(shù)的限制。所有用戶在一個客戶端上，不必考慮分布式管理的問題；而用戶分布在不同的客戶端上，需要考慮使用控制器來整體調配不同客戶機上的用戶。同時，還需要給予相應的權限配置和防火墻設置。
軟件的安全性應從哪幾個方面 去測試？
軟件安全性測試包括程序、數(shù)據(jù)庫安全性測試。根據(jù)系統(tǒng)安全指標不同測試策略也不同。
用戶認證安全的測試要考慮問題：
明確區(qū)分系統(tǒng)中不同用戶權限
系統(tǒng)中會不會出現(xiàn)用戶沖突
系統(tǒng)會不會因用戶的權限的改變造成混亂
用戶登陸密碼是否是可見、可復制
是否可以通過絕對途徑登陸系統(tǒng)（拷貝用戶登陸后的鏈接直接進入系統(tǒng)）
用戶退出系統(tǒng)后是否刪除了所有鑒權標記，是否可以使用后退鍵而不通過輸入口令進入系統(tǒng)
系統(tǒng)網絡安全的測試要考慮問題
測試采取的防護措施是否正確裝配好，有關系統(tǒng)的補丁是否打上
模擬非授權攻擊，看防護系統(tǒng)是否堅固
采用成熟的網絡漏洞檢查工具檢查系統(tǒng)相關漏洞（即用最專業(yè)的黑客攻擊工具攻擊試一下，
現(xiàn)在最常用的是 NBSI 系列和 IPhacker IP ）
采用各種木馬檢查工具檢查系統(tǒng)木馬情況
采用各種防外掛工具檢查系統(tǒng)各組程序的外掛漏洞
數(shù)據(jù)庫安全考慮問題：
系統(tǒng)數(shù)據(jù)是否機密（比如對銀行系統(tǒ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在終端上運行時的網絡流量消耗情況。④電池溫度檢測：檢測App在終端上運行時，對終端的電池溫度等性能指標的影響情況 )
兼容性測試：屏幕分辨率 /網絡狀態(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)境下同時進行虛擬用戶的操作的。集合點失敗，則集合點的才操作就會取消，測試就不能進行。
詳細的描述一個測試活動完整的過程。
答案：（供參考，本答案主要是瀑布模型的做法）
項目經理通過和客戶的交流，完成需求文檔，由開發(fā)人員和測試人員共同完成需求文檔的評審，評審的內容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實現(xiàn)的功能的地方。項目經理通過綜合開發(fā)人員，測試人員以及客戶的意見，完成項目計劃。然后 SQA 進入項目，開始進行統(tǒng)計和跟蹤開發(fā)人員根據(jù)需求文檔完成需求分析文檔，測試人員進行評審，評審的主要內容包括是否有遺漏或者雙方理解不同的地方。測試人員完成測試計劃文檔，測試計劃包括的內容上面有描述。測試人員根據(jù)修改好的需求分析文檔開始寫測試用例，同時開發(fā)人員完成概要設計文檔，詳細設計文檔。此兩份文檔成為測試人員撰寫測試用例的補充材料。測試用例完成后，測試和開發(fā)需要進行評審。測試人員搭建環(huán)境開發(fā)人員提交第一個版本，可能存在未完成功能，需要說明。測試人員進行測試，發(fā)現(xiàn) BUG后提交給 BugZilla。開發(fā)提交第二個版本，包括 Bug Fix 以及增加了部分功能，測試人員進行測試。重復上面的工作，一般是 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è)上有共同語言四是要對事不對人，工作至上當然也可以通過直接指出一些小問題，而不是進入 BUG Tracking System 來增加對方的好感。
軟件測試項目從什么時候開始？為什么？
軟件測試應該在需求分析階段就介入,因為測試的對象不僅僅是程序編碼,應該對軟件開發(fā)過程中產生的所有產品都測試,并且軟件缺陷存在放大趨勢.缺陷發(fā)現(xiàn)的越晚,修復它所花費的成本就越大.
測試結束的標準是什么？
從微觀上來說，在測試計劃中定義，比如系統(tǒng)在一定性能下平穩(wěn)運行 72 小時，目前 BugTracking System 中，本版本中沒有一般嚴重的 BUG，普通 BUG 的數(shù)量在 3 以下，BUG 修復率 90%以上等等參數(shù)，然后由開發(fā)經理，測試經理，項目經理共同簽字認同版本 Release。如果說宏觀的，則是當這個軟件徹底的消失以后，測試就結束了。
您是否了解以往所工作的企業(yè)的軟件開發(fā)過程？如果了解，請試述一個完整的開發(fā)過程需要完成哪些工作？分別由哪些不同的角色來完成這些工作？您在以往的測試工作中都曾經具體從事過哪些工作？其中最擅長哪部分工作？
開發(fā)過程---需求調研（需求人員）、需求分析（需求人員）、概要設計（設計人員）、詳細設計(設計人員)、編碼（開發(fā)人員）測試過程---需求評審、系統(tǒng)測試設計、概要設計評審、集成測試設計、詳細設計評審、單元測試設計、測試執(zhí)行測試工作的整個過程都做過，擅長做測試設計過程決定質量，軟件的過程改進正是為了提高軟件的質量，將過往的種種經驗和教訓積累起來。
補充
1.明確測試的目標，增強測試計劃的實用性編寫軟件測試計劃得重要目的就是使測試過程能夠發(fā)現(xiàn)更多的軟件缺陷，因此軟件測試計劃的價值取決于它對幫助管理測試項目，并且找出軟件潛在的缺陷。因此，軟件測試計劃中的測試范圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具并且具有較高的實用性，便于使用，生成的測試結果直觀、準確
2．采用評審和更新機制，保證測試計劃滿足實際需求
測試計劃寫作完成后，如果沒有經過評審，直接發(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，內存，服務器負載，網絡，磁盤ＩＯ
對登錄功能做性能測試
單用戶登陸的響應界面是否符合預期
單用戶登陸時后臺請求數(shù)量是否過多
高并發(fā)場景下用戶登錄的響應界面是否符合預期
高并發(fā)場景下服務端的監(jiān)控指標是否符合預期
高集合點并發(fā)場景下是否存在資源死鎖和不合理的資源等待
長時間大量用戶連續(xù)登錄和登出，服務器端是否存在內存泄漏
怎么測出可同時處理的最大請求數(shù)量
可以采用性能測試工具(WeTest服務器性能)，該工具是騰訊wetest團隊出品，使用起來很簡單方便，但測試功能相當強大，能提供10w+以上的并發(fā)量，定位性能拐點，測出服務器模型最大并發(fā)
什么是兼容性測試？兼容性測試側重哪些方面？
兼容測試主要是檢查軟件在不同的硬件平臺、軟件平臺上是否可以正常的運行，即是通常說的軟件的可移植性。兼容的類型，如果細分的話，有平臺的兼容，網絡兼容，數(shù)據(jù)庫兼容，以及數(shù)據(jù)格式的兼容。兼容測試的重點是，對兼容環(huán)境的分析。通常，是在運行軟件的環(huán)境不是很確定的情況下，才需要做兼容。根據(jù)軟件運行的需要，或者根據(jù)需求文檔，一般能夠得出用戶會在什么環(huán)境下使用該軟件，把這些環(huán)境整理成表單，就得出做兼容測試的兼容環(huán)境了
兼容和配置測試的區(qū)別在于，做配置測試通常不是在Clean OS下做測試，而兼容測試多是在Clean OS環(huán)境下做的。
補充：做兼容測試的具體步驟：在列好的軟硬件環(huán)境清單做冒煙測試，還是每一步都測試。測出不兼容，怎么和開發(fā)溝通，開發(fā)面對這些不兼容需要做什么。如果修復成本很高，怎么和產品經理溝通。和誰確認表單
軟件測試項目從什么時候開始，？為什么？
軟件測試應該在需求分析階段就介入,因為測試的對象不僅僅是程序編碼,應該對軟件開發(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+1
請設計一個關于ATM自動取款機的測試用例。
1）功能
a)ATM所識別卡的類型；
b)密碼驗證(身份登陸、是否為掩碼、輸入錯誤密碼時是否提示，連續(xù)三次錯誤吞卡等)；
c)取款功能：
i、金額多少的限制，單次最大最小提取金額、每天最大提取金額等）；
Ii、取款幣種的不同，如人民幣、美元、歐元等。
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ù)
可用性測試：開機鍵按下費不費力，開機鍵的形狀設計是否貼合手指，開機鍵的位置設計是否方便
如何回答登錄功能怎么進行測試？
首先，進行界面測試。
查看界面上的所有元素是否齊全；
沒有輸入內容時，是否有相應的提示語；
驗證碼是否能夠顯示；
移動鼠標，【登陸】按鈕默認不能點擊；
【忘記密碼】是否有個小問號“？”（其他都有）；
第二，進行功能測試。
輸入正確的用戶名、密碼、驗證碼，點【登陸】能登陸；
輸入正確的用戶名、錯誤的密碼、正確的驗證碼，提示用戶名或密碼錯誤；
輸入錯誤的用戶名、正確的驗證碼，提示用戶名或密碼錯誤；
輸入正確的用戶名、密碼，錯誤的驗證碼，提示驗證碼錯誤；
輸入不符合規(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ā)起大量請求，查看頁面崩潰后多長時間能夠恢復服務；
弱網，不同網速時登陸的時間，網絡切換和網絡延遲時登陸界面是否正常；
最后、易用性測試。
頁面是否美觀；
功能是否都可以使用；
頁面速度快不快；
頁面元素加載是否耗費網絡流量；
能不能第三方登陸；
為什么不使用手機驗證碼登陸；
輸入框能否可以以Tab鍵切換。
如何回答京東購物車功能怎么進行測試？
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.性能測試
打開購物車頁面要多長時間
支付流程測試
功能測試。
用等價類和邊界值，判斷支付的金額
如果沒有登陸能否支付，支付成功后是否可以正常跳轉；
支付方式是否支持掃碼支付，第三方平臺支付（支付包，云網等），語音支付，指紋支付；
支付時是否需要身份驗證，支付后有無手機短信提示，是否可以找他人代付；
用邊界值法有無支付額度限制，余額不足時有無提示，支付時是否是動態(tài)加密支付；
待支付狀態(tài)：訂單是否可以正常支付；是否可以取消；有相同訂單是否可以支付兩次；
是否可以掃碼支付，輸入錯誤的密碼會怎樣顯示，有無錯誤次數(shù)限制；
若支持掃碼支付，二維碼是否支持支付包和微信掃碼，若兩人同時掃描怎么處理；
有無最小支付金額限制，無意義的支付金額0，重復支付如何處理；
如果支付包含優(yōu)惠金額，該怎么處理優(yōu)惠額度；
性能測試
弱網，無網時是否可以支付；
退款到賬時間，耗電量的多少；
帶負載情況下的響應時間和吞吐率，在某個時間段內同時訪問系統(tǒng)的用戶數(shù)量 ；
壓力測試
多人同時付款；
界面測試；
支付界面有無錯別字，排版是否合理，顏色搭配是否合理；
兼容性測試
是否可以跨平臺，不同電腦機型下顯示有無區(qū)別；
安全性測試；
若支付不成功是否原路退款，若支付成功，有無支付信息提示；
用fiddler抓包嘗試修改價格，對訂單金額有無效驗；
直接輸入需要權限的頁面地址可用訪問；
接口測試
第三方平臺支付
對于有系統(tǒng)大量并發(fā)訪問，你會如何做測試，有什么建議
參考回答：
如何做高并發(fā)系統(tǒng)的測試，一般而言，整體的測試策略是：先針對部分系統(tǒng)進行性能測試及壓力測試，得到各部分的峰值處理性能，再模擬整體流程測試，重點測試整體業(yè)務流程以及業(yè)務預期負荷，著重測試以下幾點：
1、不同省份，不同運營商CDN節(jié)點性能，可采用典型壓力測試方案
2、核心機房BGP網絡帶寬，此部分重點在于測試各運行商的BGP網絡可靠性，實際速率，一般采用smokeping,lxChariot等工具
3、各類硬件設備性能，一般采用專業(yè)的網絡設備測試工具
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)，多個攝像頭，抓拍車牌，識別車牌，上傳網上，網上展示
參考回答：
功能：
1.每個攝像頭都能抓拍車牌；
2.每個攝像頭抓拍到的車牌能正常交給系統(tǒng)處理；
3.系統(tǒng)能夠正確識別車牌；
4.系統(tǒng)能夠將識別出的車牌上傳；
5.上傳至網絡的車牌能夠正常展示出來；
一、功能測試
1.使用正常的車牌，保持車牌靜止，檢查每個攝像頭是否能抓拍車牌；
2.使用類似非車牌的寫有字的紙板，檢查每個攝像頭是否抓拍；
3.使用正常的車牌，保持車牌較高速移動，檢查每個攝像頭是否能抓拍車牌；
4.在多種情況下檢查每個攝像頭抓拍到的車牌能否正常交給系統(tǒng)處理，如臨時斷電、斷網后能否正常將數(shù)據(jù)交給系統(tǒng)；
5.使用抓拍到的正常的車牌，交由系統(tǒng)處理，檢查系統(tǒng)能否識別車牌；
6.使用非車牌的其他圖片，交由系統(tǒng)處理，檢查系統(tǒng)能否識別；
7.在多種情況下檢查系統(tǒng)能否將正常識別出的車牌進行上傳，如臨時斷電、斷網后未上傳數(shù)據(jù)是否能繼續(xù)上傳；
8.構造非車牌的其他內容的數(shù)據(jù)，檢查系統(tǒng)能否將異常內容進行上傳；
9.檢查上傳至網絡的車牌能否正常展示出來；
10.上傳非車牌的其他內容的數(shù)據(jù)，檢查能否正常顯示出來。
二、性能測試
1.同時向一個攝像頭展示多個靜止的車牌，檢查攝像頭能否抓拍到多個車牌；
2.同時向一個攝像頭展示多個較高速運動的車牌，檢查攝像頭能否抓拍到多個車牌；
3.抓拍后，檢查系統(tǒng)識別車牌的時間是否在需求要求的時間內；
4.模擬大量抓拍照片同時交由系統(tǒng)處理，檢查一定壓力下系統(tǒng)能否正常識別車牌；
5.模擬大量車牌同時上傳，檢查一定壓力下能否上傳成功。
三、安全性測試
1.檢查是否能夠通過給車牌加裝飾物等方法，使攝像頭無法抓拍或抓拍后系統(tǒng)無法正常識別車牌。
請你說一說PC網絡故障，以及如何排除障礙
參考回答：
(1)首先是排除接觸故障，即確保你的網線是可以正常使用的。然后禁用網卡后再啟用，排除偶然故障。打開網絡和共享中心窗口，單擊窗口左上側“更改適配器設置”右擊其中的“本地連接“或”無線網絡連接”，單擊快捷菜單中的“禁用”命令，即可禁用所選網絡。接下來重啟網絡，只需右擊后單擊啟用即可。
(2)使用ipconfig查看計算機的上網參數(shù)
1、單擊“開始|所有程序|附件|命令提示符“，打開命令提示符窗口
2、輸入ipconfig，按Enter確認，可以看到機器的配置信息，輸入ipconfig/all,可以看到IP地址和網卡物理地址等相關網絡詳細信息。
(3)使用ping命令測試網絡的連通性，定位故障范圍
在命令提示符窗口中輸入”ping 127.0.0.1“，數(shù)據(jù)顯示本機分別發(fā)送和接受了4個數(shù)據(jù)包，丟包率為零，可以判斷本機網絡協(xié)議工作正常，如顯示”請求超時“，則表明本機網卡的安裝或TCP/IP協(xié)議有問題，接下來就應該檢查網卡和TCP/IP協(xié)議，卸載后重裝即可。
(4)ping本機IP
在確認127.0.0.1地址能被ping通的情況下，繼續(xù)使用ping命令測試本機的IP地址能否被ping通，如不能，說明本機的網卡驅動程序不正確，或者網卡與網線之間連接有故障，也有可能是本地的路由表面收到了破壞，此時應檢查本機網卡的狀態(tài)是否為已連接，網絡參數(shù)是否設置正確，如果正確可是不能ping通，就應該重新安裝網卡驅動程序。丟失率為零，可以判斷網卡安裝配置沒有問題，工作正常。
(5)ping網關
網關地址能被ping通的話，表明本機網絡連接以及正常，如果命令不成功，可能是網關設備自身存在問題，也可能是本機上網參數(shù)設置有誤，檢查網絡參數(shù)。
微信紅包
功能
1.在紅包錢數(shù)，和紅包個數(shù)的輸入框中只能輸入數(shù)字
2.紅包里最多和最少可以輸入的錢數(shù) 200 0.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. 斷網時，無法搶紅包
20.可不可以自己選擇支付方式
21.余額不足時，會不會自動匹配支付方式
22.在發(fā)紅包界面能否看到以前的收發(fā)紅包的記錄
23.紅包記錄里的信息與實際收發(fā)紅包記錄是否匹配
24.支付時可以密碼支付也可以指紋支付
25.如果直接輸入小數(shù)點，那么小數(shù)點之前應該有個0
26.支付成功后，退回聊天界面
27.發(fā)紅包金額和收到的紅包金額應該匹配
28.是否可以連續(xù)多次發(fā)紅包
29.輸入錢數(shù)為0，"塞錢進紅包"置灰
性能
1.弱網時搶紅包，發(fā)紅包時間
2.不同網速時搶紅包，發(fā)紅包的時間
3.發(fā)紅包和收紅包成功后的跳轉時間
4.收發(fā)紅包的耗電量
5.退款到賬的時間
兼容
1.蘋果，安卓是否都可以發(fā)送紅包
2.電腦端可以搶微信紅包
界面
1.發(fā)紅包界面沒有錯別字
2.搶完紅包界面沒有錯別字
3.發(fā)紅包和收紅包界面排版合理，
4.發(fā)紅包和收到紅包界面顏色搭配合理
安全
1.對方微信號異地登錄，是否會有提醒 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, 網速慢的情況下的搜索
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輸入搜索條件的控件風格設計、位置擺放是否醒目便于使用者注意到，有否快照等快捷查看方式等人性化設計？
四. 兼容性
1WINDOWS/LINUX/UNIX等各類操作系統(tǒng)下及各版本條件下的應用
2IE/FIREFOX/GOOGLE/360/QQ等各類瀏覽器下及各版本條件下、各種顯示分辨率條件下的應用
3SQL/ORACLE/DB2/MYSQL等各類數(shù)據(jù)庫存儲情況下的兼容性測試
4簡體中文、繁體中文、英文等各類語種軟件平臺下的兼容性測試
5IPHONE/IPAD、安卓等各類移動應用平臺下的兼容性測試
6與各相關的監(jiān)控程序的兼容性測試，如輸入法、殺毒、監(jiān)控、防火墻等工具同時使用
五. 安全性
1被刪除、加密、授權的數(shù)據(jù)，不允許被SQL注入等攻擊方式查出來的，是否有安全控制設計；
2錄入一些數(shù)據(jù)庫查詢的保留字符，如單引號、%等等，造成查詢SQL拼接出的語句產生漏洞，如可以查出所有數(shù)據(jù)等等，這方面要有一些黑客攻擊的思想并引入一些工具和技術，如爬網等。
3通過白盒測試技術，檢查一下在程序設計上是否存在安全方面的隱患；
4對涉及國家安全、法律禁止的內容是否進行了相關的過濾和控制；
就linux下的CP命令設計測試用例。
功能
拷貝的文件
1）大小：0k, 1k, 10k, 100k, 1000k…
2）類型：二進制文件、文本文件、mp3、avi、壓縮文件…
文件源目錄
1）文件中包含各種類型的文件
2）目錄深度為0，1，2，3…
文件目標目錄
1）目標目錄中存在與源文件同名同類型的文件
2）目標目錄中存在與源文件同名不同類型的文件
3）目標目錄中存在與源文件不同名同類型的文件
4）目標目錄中存在與源文件不同名不同類型的文件
異常
參數(shù)異常
1）包含特殊字符
2）參數(shù)長度超過限制
3）源目錄不存在
4）目標目錄不存在
文件異常
1）文件沒有拷貝權限
2）非法的文件格式和內容
存儲介質異常
1）存儲介質由損壞
2）拷貝前存儲介質已滿
3）拷貝中存儲介質存滿
執(zhí)行過程異常
1）拷貝過程中刪除源文件
2）拷貝過程中刪除目標文件
性能
1）拷貝大文件
2）拷貝源目錄中存在大量小文件
3）跨文件系統(tǒng)拷貝
4）跨存儲介質拷貝
5）并發(fā)執(zhí)行拷貝
關注性能點：拷貝完成時間，CPU，內存，磁盤IO
是否手機出現(xiàn)故障，是否手機緩存過多造成內存不夠用
是否手機網絡連接不穩(wěn)定（弱網/無網），若是，有無網絡差提示
是否手機內存溢出（關注人數(shù)達上限否）
是否是版本問題或者是安裝包問題（更新系統(tǒng)，重新安裝安裝包）
現(xiàn)有一個學生標準化考試批閱試卷,產生成績報告的程序。其規(guī)格說明如下:程序的輸入文件由一些有80個字符的記錄組成,如右圖所示，所有記錄分為3組：
標題：這一組只有一個記錄，其內容為輸出成績報告的名字。
試卷各題標準答案記錄：每個記錄均在第80個字符處標以數(shù)字"2"。該組的第一個記錄的第1至第3個字符為題目編號（取值為1一999）。第10至第59個字符給出第1至第50題的答案（每個合法字符表示一個答案）。該組的第2，第3……個記錄相應為第51至第100，第101至第150，…題的答案。
每個學生的答卷描述：該組中每個記錄的第80個字符均為數(shù)字"3"。每個學生的答卷在若干個記錄中給出。如甲的首記錄第1至第9字符給出學生姓名及學號，第10至第59字符列出的是甲所做的第1至第50題的答案。若試題數(shù)超過50，則第2，第3……紀錄分別給出他的第51至第100，第101至第150……題的解答。然后是學生乙的答卷記錄。
學生人數(shù)不超過200，試題數(shù)不超過999。
程序的輸出有4個報告：
a)按學號排列的成績單，列出每個學生的成績、名次。
b)按學生成績排序的成績單。
c)平均分數(shù)及標準偏差的報告。
d)試題分析報告。按試題號排序，列出各題學生答對的百分比。
分別考慮輸入條件和輸出條件，以及邊界條件。給出右表所示的輸入條件及相應的測試用例。
三、基礎知識點
什么是樁模塊？什么是驅動模塊？
樁模塊：被測模塊調用模塊
驅動模塊 調用被測模塊
什么是扇入？什么是扇出？
扇入：被調次數(shù)，扇出：調其它模塊數(shù)目
8020原則：在需求分析開始到集成測試階段引入測試手段，能發(fā)現(xiàn)所有缺陷的80%，系統(tǒng)測試階段發(fā)現(xiàn)16%，在運行維護階段經過長時間大量運行軟件后，能夠發(fā)現(xiàn)4%。起源于經濟學。
什么是耦合？什么是內聚？
耦合：對一個軟件結構內各個模塊之間互連程度的度量。
內聚：一個模塊內各個元素彼此結合的緊密程度。強內聚，松耦合。
缺陷嚴重程度：
致命（Fatal）、嚴重（Critical）、一般（Major）、較小（Minor）。
缺陷優(yōu)先級：
立即解決P1、高優(yōu)先級P2、正常排隊P3、低優(yōu)先級P4。
缺陷狀態(tài)：
打開（open）、修正（fixed）、重新打開（reopen）、關閉（closed）、重復（Duplicate）、推遲（Deferred）、保留（On hold）、不修復（wontfix）。
簡單的軟件缺陷生命周期：
發(fā)現(xiàn)（new）-打開-修復-關閉。
復雜的軟件缺陷生命周期：
新建-打開-Bug審查（設計需要修改/延期/關閉）-關閉。
新建-打開-是否清楚，可再現(xiàn)（不能再現(xiàn)缺少信息返回到打開狀態(tài)）-修正-關閉。
什么是在線用戶數(shù)？什么是并發(fā)用戶數(shù)？
在線用戶數(shù)：
用戶同時在一定時間段的在線數(shù)量
并發(fā)用戶數(shù)：
某一時刻同時向服務器發(fā)送請求的用戶數(shù)
分布式軟件架構分為：
B/S架構（瀏覽器、web版） C/S架構：客戶端（先進行安裝）
測試人員的能力：
搭建環(huán)境的能力（配置JDK、數(shù)據(jù)庫、Tomcat/Apace、程序放相應路徑下、檢查配置是否成功數(shù)據(jù)庫管理和設置程序設計C++④測試方法論⑤工具的使用能力（QC\QTP\LR\Bugfree）
簡述負載測試與壓力測試的區(qū)別。
參考答案：
壓力測試（Stress Testing）
壓力測試的主要任務就是獲取系統(tǒng)正確運行的極限，檢查系統(tǒng)在瞬間峰值負荷下正確執(zhí)行的能力。例如，對服務器做壓力測試時就可以增加并發(fā)操作的用戶數(shù)量；或者不停地向服務器發(fā)送請求；或一次性向服務器發(fā)送特別大的數(shù)據(jù)等。看看服務器保持正常運行所能達到的最大狀態(tài)。人們通常使用測試工具來完成壓力測試，如模擬上萬個用戶從終端同時登錄，這是壓力測試中常常使用的方法。
負載測試（Volume Testing）
用于檢查系統(tǒng)在使用大量數(shù)據(jù)的時候正確工作的能力，即檢驗系統(tǒng)的能力最高能達到什么程度。例如，對于信息檢索系統(tǒng)，讓它使用頻率達到最大；對于多個終端的分時系統(tǒng)，讓它所有的終端都開動。在使整個系統(tǒng)的全部資源達到“滿負荷”的情形下，測試系統(tǒng)的承受能力。
軟件缺陷管理工具有哪些
答： QC ALM BugFree jira Mantis 禪道
弱網測試
四、智力題
一，5只貓 五分鐘捉5只老鼠 請問100分鐘捉100只老鼠需要多少只貓？
答案：5只
二，圓桌，兩個人，輪流放硬幣，不能重疊，半徑為1，某一方不能放下去，則為輸。問先手贏 后手贏
答案：先手贏，圓桌對稱，先手先放，后手都可以找對稱位置，除了圓心
三，3升的杯子一個，5升的杯子一個，杯子不規(guī)則形狀 問怎么得到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，回答答案必假
十一，果凍，有黃色、綠色、紅色三種，閉眼抓同種顏色兩個，抓取多少個，可確定有兩個同色果凍？
答案：根據(jù)抽屜原理，4個
十二，下水道為什么是圓的
答案：方便人員進出，井蓋不容易掉落，不易如棱角磨損節(jié)約材料，保護車輛 和行人的安全
十三，一共100個球，兩人輪流拿，每人每次最多拿5個，最后一個拿的人贏；如果我先拿，怎么拿一定會贏
答案：每次拿的球總數(shù)控制為6；第一次拿4個；
十四，有120g面粉，現(xiàn)有一個天平和一個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，把瓶子的編號轉變?yōu)槎M制數(shù)，第幾位1，就給第幾個小白鼠喝。
總結
- 上一篇： Python爬虫入门教程24：下载某网站
- 下一篇： Latex符号表