全軟件測試面試題匯總

軟件測試面試題匯總一、面試基礎題簡述測試流程:1、閱讀相關技術文檔（如產(chǎn)品PRD、UI設計、產(chǎn)品流程圖等）。2、參加需求評審會議。3、根據(jù)最終確定的需求文檔編寫測試計劃。4、編寫測試用例（等價類劃分法、邊界值分析法等）。5、用例評審(主要參與人員：開發(fā)、測試、產(chǎn)品、測試leader)。6、開發(fā)提交代碼至SVN或者GIT，配管搭建測試環(huán)境。7、執(zhí)行測試用例，記錄發(fā)現(xiàn)的問題。8、驗證bug與回歸測試。9、編寫測試報告。10、產(chǎn)品上線。補充測試用例設計過程：根據(jù)需求得出測試需求設計測試方案，評審測試方案方案評審通過后，設計測試用例，再對測試用例進行評審什么是軟件測試？軟件測試的目的與原則使用人工或自動手段，來運行或測試某個系統(tǒng)的過程。其目的在于檢驗它是否滿足規(guī)定的需求或弄清預期結果與實際結果之間的差別。軟件測試的目的：測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯誤。一個成功的測試用例在于發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤。一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。確保產(chǎn)品完成了它所承諾或公布的功能，并且用戶可以訪問到的功能都有明確的書面說明。確保產(chǎn)品滿足性能和效率的要求。確保產(chǎn)品是健壯的和適應用戶環(huán)境的。問：軟件生存周期及其模型是什么？軟件生存周期是軟件開發(fā)全部過程、活動和任務的結構框架，是從可行性研究到需求分析、軟件設計、編碼、測試、軟件發(fā)布維護的過程。在經(jīng)歷需求、分析、設計、實現(xiàn)、部署后，軟件將被使用并進入維護階段，直到最后由于缺少維護費用而逐漸消亡。這樣的一個過程，稱為"生命周期模型"（LifeCycleModel）。什么是軟件質量？軟件質量：軟件產(chǎn)品的特性可以滿足用戶的功能、性能需求的能力。自動化測試腳本開發(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ù)他們選擇測試用例。例如，在單元測試時曾列出的許多在模塊中常見的錯誤。以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯誤等，這些就是經(jīng)驗的總結。還有，輸入數(shù)據(jù)和輸出數(shù)據(jù)為0的情況。輸入表格為空格或輸入表格只有一行。這些都是容易發(fā)生錯誤的情況?？蛇x擇這些情況下的例子作為測試用例。4）因果圖方法前面介紹的等價類劃分方法和邊界值分析方法，都是著重考慮輸入條件，但未考慮輸入條件之間的聯(lián)系，相互組合等?？紤]輸入條件之間的相互組合，可能會產(chǎn)生一些新的情況。但要檢查輸入條件的組合不是一件容易的事情，即使把所有輸入條件劃分成等價類，他們之間的組合情況也相當多。因此必須考慮采用一種適合于描述對于多種條件的組合，相應產(chǎ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測試不能由程序員或測試員完成?；貧w測試（對軟件的新版本測試時，重復執(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ù)備份是否完整，可否恢復，恢復是否可以完整）α測試是由一個用戶在開發(fā)環(huán)境下進行的測試，也可以是公司內部的用戶在模擬實際操作環(huán)境下進行的受控測試，Alpha測試不能由程序員或測試員完成。β測試是軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進行的測試。開發(fā)者通常不在測試現(xiàn)場，Beta測試不能由程序員或測試員完成。需求測試的注意事項有哪些？是否使用了公司的模板文檔內容是否符合規(guī)范所有的需求是分級是否清晰適當？所有的需求是否具有一致性需求是否可行（即，該需求組合有解決方案）需求可否用己知的約束來實現(xiàn)需求是否足夠（即，可以把它送到一個規(guī)范的開發(fā)組織，并有一個生產(chǎn)出所需要產(chǎn)品的合理的可能性）所有的其它需求是交叉引用是否正確用戶描述是否清楚是否用客戶的語言來描述需求每個需求描述是否清楚沒有岐義，可以移交給一個獨立的組去實現(xiàn)時也能理解是否所有的需求都是可驗證的是否每條需求都具有獨立性，即使發(fā)生了變化也不會影響其它需求性能指標是否明確非功能性需求是否得到充分表現(xiàn)是否完整列出適用的標準或協(xié)議標準和協(xié)議之間是否存在沖突問：你在測試中發(fā)現(xiàn)了一個bug，但是開發(fā)經(jīng)理認為這不是一個bug，你應該怎樣解決。將問題提交到缺陷管理庫里面進行備案。要獲取判斷的依據(jù)和標準：根據(jù)需求說明書、產(chǎn)品說明、設計文檔等，確認實際結果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據(jù)；如果沒有文檔依據(jù)，可以根據(jù)類似軟件的一般特性來說明是否存在不一致的地方，來確認是否是缺陷；根據(jù)用戶的一般使用習慣，來確認是否是缺陷；與設計人員、開發(fā)人員和客戶代表等相關人員探討，確認是否是缺陷；合理的論述，向測試經(jīng)理說明自己的判斷的理由，注意客觀、嚴謹，不參雜個人情緒。等待測試經(jīng)理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反映，并有上級做出決定。問：給你一個網(wǎng)站，你如何測試？1、查找需求說明、網(wǎng)站設計m等相關文檔，分析測試需求。2、制定測試計劃，確定測試范圍和測試策略，一般包括以下幾個部分：功能性測試；界面測試；性能測試；數(shù)據(jù)庫測試；安全性測試；兼容性測試3、設計測試用例：功能性測試可以包括，但不限于以下幾個方面：鏈接測試。鏈接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯信息返回等。提交功能的測試。多媒體元素是否可以正確加載和顯示。多語言支持是否能夠正確顯示選擇的語言等。界面測試可以包括但不限于一下幾個方面：頁面是否風格統(tǒng)一，美觀文字檢查對于必須但為安裝的空間，是否提供自動下載并安裝的功能控件是否正常使用頁面布局是否合理，重點內容和熱點內容是否突出問：一臺客戶端有三百個客戶與三百個客戶端有三百個客戶對服務器施壓，有什么區(qū)別?300個用戶在一個客戶端上，會占用客戶機更多的資源，而影響測試的結果。線程之間可能發(fā)生干擾，而產(chǎn)生一些異常。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)BUG后提交給BugZilla。開發(fā)提交第二個版本，包括BugFix以及增加了部分功能，測試人員進行測試。重復上面的工作，一般是3-4個版本后BUG數(shù)量減少，達到出貨的要求。如果有客戶反饋的問題，需要測試人員協(xié)助重現(xiàn)并重新測試。在您以往的工作中，一條軟件缺陷（或者叫Bug）記錄都包含了哪些內容？如何提交高質量的軟件缺陷（Bug）記錄？在傳統(tǒng)的BugZilla中，BUG描述應該包括以下的信息和BUG產(chǎn)生對應的軟件版本和模塊開發(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ā)過程中產(chǎn)生的所有產(chǎn)品都測試,并且軟件缺陷存在放大趨勢.缺陷發(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)絡，磁盤ＩＯ對登錄功能做性能測試單用戶登陸的響應界面是否符合預期單用戶登陸時后臺請求數(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ā)面對這些不兼容需要做什么。如果修復成本很高，怎么和產(chǎn)品經(jīng)理溝通。和誰確認表單軟件測試項目從什么時候開始，？為什么？軟件測試應該在需求分析階段就介入,因為測試的對象不僅僅是程序編碼,應該對軟件開發(fā)過程中產(chǎn)生的所有產(chǎn)品都測試,并且軟件缺陷存在放大趨勢.缺陷發(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個變量采用邊界值分析可以產(chǎ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ā)起大量請求，查看頁面崩潰后多長時間能夠恢復服務；弱網(wǎng)，不同網(wǎng)速時登陸的時間，網(wǎng)絡切換和網(wǎng)絡延遲時登陸界面是否正常；最后、易用性測試。頁面是否美觀；功能是否都可以使用；頁面速度快不快；頁面元素加載是否耗費網(wǎng)絡流量；能不能第三方登陸；為什么不使用手機驗證碼登陸；輸入框能否可以以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.性能測試打開購物車頁面要多長時間支付流程測試功能測試。用等價類和邊界值，判斷支付的金額如果沒有登陸能否支付，支付成功后是否可以正常跳轉；支付方式是否支持掃碼支付，第三方平臺支付（支付包，云網(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,lxChariot等工具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)絡故障，以及如何排除障礙參考回答：(1)首先是排除接觸故障，即確保你的網(wǎng)線是可以正常使用的。然后禁用網(wǎng)卡后再啟用，排除偶然故障。打開網(wǎng)絡和共享中心窗口，單擊窗口左上側“更改適配器設置”右擊其中的“本地連接“或”無線網(wǎng)絡連接”，單擊快捷菜單中的“禁用”命令，即可禁用所選網(wǎng)絡。接下來重啟網(wǎng)絡，只需右擊后單擊啟用即可。(2)使用ipconfig查看計算機的上網(wǎng)參數(shù)1、單擊“開始|所有程序|附件|命令提示符“，打開命令提示符窗口2、輸入ipconfig，按Enter確認，可以看到機器的配置信息，輸入ipconfig/all,可以看到IP地址和網(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.013.拼手氣紅包最多可以發(fā)多少個紅包1003.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ù)點之前應該有個026.支付成功后，退回聊天界面27.發(fā)紅包金額和收到的紅包金額應該匹配28.是否可以連續(xù)多次發(fā)紅包29.輸入錢數(shù)為0，"塞錢進紅包"置灰性能1.弱網(wǎng)時搶紅包，發(fā)紅包時間2.不同網(wǎng)速時搶紅包，發(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.多選項搜索：關鍵字品牌產(chǎn)地價格區(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輸入搜索條件的控件風格設計、位置擺放是否醒目便于使用者注意到，有否快照等快捷查看方式等人性化設計？四.兼容性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拼接出的語句產(chǎn)生漏洞，如可以查出所有數(shù)據(jù)等等，這方面要有一些黑客攻擊的思想并引入一些工具和技術，如爬網(wǎng)等。3通過白盒測試技術，檢查一下在程序設計上是否存在安全方面的隱患；4對涉及國家安全、法律禁止的內容是否進行了相關的過濾和控制；就linux下的CP命令設計測試用例。功能拷貝的文件1）大?。?k,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請問如果用戶點擊微博的關注圖標但是app上面沒有反應，應該怎么排查這個問題是否手機出現(xiàn)故障，是否手機緩存過多造成內存不夠用是否手機網(wǎng)絡連接不穩(wěn)定（弱網(wǎng)/無網(wǎng)），若是，有無網(wǎng)絡差提示是否手機內存溢出（關注人數(shù)達上限否）是否是版本問題或者是安裝包問題（更新系統(tǒng)，重新安裝安裝包）現(xiàn)有一個學生標準化考試批閱試卷,產(chǎ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)試題分析報告。按試題號排序，列出各題學生答對的百分比。分別考慮輸入條件和輸出條件，以及邊界條件。給出右表所示的輸入條件及相應的測試用例。三、基礎知識點什么是樁模塊？什么是驅動模塊？樁模塊：被測模塊調用模塊驅動模塊調用被測模塊什么是扇入？什么是扇出