软件测试面试常见问题（2）
21、請試著比較一下黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收測試的區別與聯系。
黑盒測試：已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要求。
白盒測試：已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查。
軟件的黑盒測試意味著測試要在軟件的接口處進行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數據驅動測試。
黑盒測試主要是為了發現以下幾類錯誤：
1、是否有不正確或遺漏的功能？
2、在接口上，輸入是否能正確的接受？能否輸出正確的結果？
3、是否有數據結構錯誤或外部信息（例如數據文件）訪問錯誤？
4、性能上是否能夠滿足要求？
5、是否有初始化或終止性錯誤？
軟件的白盒測試是對軟件的過程性細節做細致的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序狀態，確定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。
白盒測試主要是想對程序模塊進行如下檢查：
1、對程序模塊的所有獨立的執行路徑至少測試一遍。
2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。
3、在循環的邊界和運行的界限內執行循環體。
4、測試內部數據結構的有效性，等等。
1、 單元測試（模塊測試）是開發者編寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數的行為。
單元測試是由程序員自己來完成，最終受益的也是程序員自己。可以這么說，程序員有責任編寫功能代碼，同時也就有責任為自己的代碼編寫單元測試。執行單元測試，就是為了證明這段代碼的行為和我們期望的一致。
2、集成測試（也叫組裝測試，聯合測試）是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經測試過的單元組合成一個組件，并且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，并最終擴展進程，將您的模塊與其他組的模塊一起測試。最后，將構成進程的所有模塊一起測試。
3、系統測試是將經過測試的子系統裝配成一個完整系統來測試。它是檢驗系統是否確實能提供系統方案說明書中指定功能的有效方法。（常見的聯調測試）。系統測試的目的是對最終軟件系統進行全面的測試，確保最終軟件系統滿足產品需求并且遵循系統設計。
4、驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是確保軟件準備就緒，并且可以讓最終用戶將其用于執行軟件的既定功能和任務。
驗收測試是向未來的用戶表明系統能夠像預定要求那樣工作。經集成測試后，已經按照設計把所有的模塊組裝成一個完整的軟件系統，接口錯誤也已經基本排除了，接著就應該進一步驗證軟件的有效性，這就是驗收測試的任務，即軟件的功能性能如同用戶所合理期待的那樣。
22、當開發人員說不是BUG時，你如何應付？
開發人員說不是bug，有2種情況，一是需求沒有確定，所以我可以這么做，這個時候可以找來產品經理進行確認，需不需要改動，3方商量確定好后再看要不要改。二是這種情況不可能發生，所以不需要修改，這個時候，我可以先盡可能的說出是BUG的依據是什么？如果被用戶發現或出了問題，會有什么不良結果？程序員可能會給你很多理由，你可以對他的解釋進行反駁。如果還是不行，那我可以給這個問題提出來,跟開發經理和測試經理進行確認,如果要修改就改,如果不要修改就不改。其實有些真的不是bug，我也只是建議的方式寫進TD中，如果開發人員不修改也沒有大問題。如果確定是bug的話，一定要堅持自己的立場，讓問題得到最后的確認。
23、為什么要在一個團隊中開展軟件測試工作？
因為沒有經過測試的軟件很難在發布之前知道該軟件的質量，就好比ISO質量認證一樣，測試同樣也需要質量的保證，這個時候就需要在團隊中開展軟件測試的工作。在測試的過程發現軟件中存在的問題，及時讓開發人員得知并修改問題，在即將發布時，從測試報告中得出軟件的質量情況。
24、一份測試計劃應該包括哪些內容？
背景、項目簡介、目的、測試范圍、測試策略、人員分工、資源要求、進度計劃、參考文檔、常用術語、提交文檔、風險分析。
25、軟件測試項目從什么時候開始？
軟件測試應該在需求分析階段就介入,因為測試的對象不僅僅是程序編碼,應該對軟件開發過程中產生的所有產品都測試,并且軟件缺陷存在放大趨勢.缺陷發現的越晚,修復它所花費的成本就越大.
26、什么是回歸測試?
回歸測試: (regression testing): 回歸測試有兩類：用例回歸和錯誤回歸；用例回歸是過一段時間以后再回頭對以前使用過的用例在重新進行測試，看看會重新發現問題。錯誤回歸，就是在新版本中，對以前版本中出現并修復的缺陷進行再次驗證，并以缺陷為核心，對相關修改的部分進行測試的方法。
27、單元測試、集成測試、系統測試的側重點是什么？
單元測試針對的是軟件設計的最小單元–程序模塊（面向過程中是函數、過程；面向對象中是類。）,進行正確性檢驗的測試工作,在于發現每個程序模塊內部可能存在的差錯.一般有兩個步驟:人工靜態檢查\動態執行跟蹤
集成測試針對的是通過了單元測試的各個模塊所集成起來的組件進行檢驗,其主要內容是各個單元模塊之間的接口,以及各個模塊集成后所實現的功能.
系統測試針對的是集成好的軟件系統，作為整個計算機系統的一個元素,與計算機硬件\外設\某些支持軟件\數據和人員等其他系統元素結合在一起,要在實際的運行環境中,對計算機系統進行一系列的集成測試和確認測試.
28、什么是軟件測試？目的和原則？
在規定的條件下對程序進行操作，以發現程序錯誤，衡量軟件質量，并對其是否能滿足設計要求進行評估的過程
軟件測試的目的：
測試是程序的執行過程，目的在于發現錯誤
一個成功的測試用例在于發現至今未發現的錯誤
一個成功測試是發現了至今未發現的錯誤的測試
確保產品完成了她所承受或公布的功能，并且用戶可以訪問到的功能都有明確的書面說明
確保產品滿足性能和效率的要求
確保產品是健壯的和適應用戶環境的
軟件測試的原則：
測試用例中一個必須部分是對預期輸出或接過進行定義
程序員應避免測試自己編寫的程序
編寫軟件的組織不應當測試自己編寫的軟件
應當徹底檢查每個測試的執行結果
測試用例的編寫不僅應當根據有效和預料到的輸入情況，而且也應當根據無效和未預料到的輸入情況
檢擦程序是否“未做其應該做的”僅是測試的一半，測試的另一半是檢查程序是否“做了其不應該做的”
應避免測試用例用后即棄，除非軟件本身就是個一次性的軟件
計劃測試工作時不應默許假定不會發現錯誤
程序某部分存在更多錯誤的可能性，與該部分已經發現錯誤的數量成正比
軟件測試是一項極富創造性，極具智力的挑戰性的工作
20、軟件質量保證體系是什么 國家標準中與質量保證管理相關的幾個標準是什么?他們的編號和全稱是什么?
SQA由一套軟件工程過程和方法組成，以保證（軟件的）質量。SQA貫穿整個軟件開發過程，(它)應包括需求文檔評審、代碼控制、代碼評審、變更管理、配置管理、版本管理和軟件測試。
軟件質量保證（SQA-Software Quality Assurance）是建立一套有計劃，有系統的方法，來向管理層保證擬定出的標準、步驟、實踐和方法能夠正確地被所有項目所采用。軟件質量保證的目的是使軟件過程對于管理人員來說是可見的。它通過對軟件產品和活動進行評審和審計來驗證軟件是合乎標準的。軟件質量保證組在項目開始時就一起參與建立計劃、標準和過程。這些將使軟件項目滿足機構方針的要求。
29、在搜索引擎中輸入漢字就可以解析到對應的域名，請問如何使用LoadRunner進行測試
30、軟件測安全性從哪幾個方面測試？
軟件安全性測試包括：程序、數據庫安全測試
a. 用戶認證安全的測試要考慮問題： 明確區分系統中不同用戶權限 、系統中會不會出現用戶沖突 、系統會不會因用戶的權限的改變造成混亂 、用戶登陸密碼是否是可見、可復制 、是否可以通過絕對途徑登陸系統（拷貝用戶登陸后的鏈接直接進入系統）、用戶退出系統后是否刪除了所有鑒權標記，是否可以使用后退鍵而不通過輸入口令進入 系統 、系統網絡安全的測試要考慮問題 、測試采取的防護措施是否正確裝配好，有關系統的補丁是否打上 、模擬非授權攻擊，看防護系統是否堅固 、采用成熟的網絡漏洞檢查工具檢查系統相關漏洞（即用最專業的黑客攻擊工具攻擊試一下，現在最常用的是 NBSI 系列和 IPhacker IP ） 、采用各種木馬檢查工具檢查系統木馬情況 、采用各種防外掛工具檢查系統各組程序的外掛漏洞
b. 數據庫安全考慮問題： 系統數據是否機密、系統數據的完整性 、系統數據可管理性 、系統數據的獨立性 、系統數據可備份和恢復能力（數據備份是否完整，可否恢復，恢復是否可以完整）
31、如何測試一個紙杯？
32、BUG管理工具的跟蹤過程（用BugZilla為例子）
測試人員發現了BUG，提交到Bugzilla中，狀態為new，BUG的接受者為開發接口人員
開發接口將BUG分配給相關的模塊的開發人員，狀態修改為已分配，開發人員和測試確認BUG，如果是本人的BUG，則設置為接收；如果是別的開發人員的問題，則轉發出去，由下一個開發人員來進行此行為；如果認為不是問題，則需要大家討論并確認后，拒絕這個BUG，然后測試人員關閉此問題。
如果開發人員接受了BUG，并修改好以后，將BUG狀態修改為已修復，并告知測試在哪個版本中可以測試。
測試人員在新版本中測試，如果發現問題依然存在，則拒絕驗證；如果已經修復，則關閉BUG。
33、軟件產品質量特性是什么?
功能性：適應性、準確性、互操作性、依從性、安全性。
可靠性：成熟性、容錯性、易恢復性。
可使用性：易理解性、易學習性、易操作性。
效率：時間特性、資源特性。
可維護性：易分析性、易變更性、穩定性、易測試性。
可移植性： 適應性、易安裝性、遵循性、易替換性
34、一臺客戶端有三百個客戶與三百個客戶端有三百個客戶對服務器施壓，有什么區別?
300個用戶在一個客戶端上，會占用客戶機更多的資源，而影響測試的結果。線程之間可能發生干擾，而產生一些異常。
300個用戶在一個客戶端上，需要更大的帶寬。
IP地址的問題，可能需要使用IP Spoof來繞過服務器對于單一IP地址最大連接數的限制。
所有用戶在一個客戶端上，不必考慮分布式管理的問題；而用戶分布在不同的客戶端上，需要考慮使用控制器來整體調配不同客戶機上的用戶。同時，還需要給予相應的權限配置和防火墻設置。
35、試述軟件的概念和特點？軟件復用的含義？構件包括哪些？
軟件是計算機系統中與硬件相互依存的另一部分，與計算機系統操作有關的計算機程序、規程、規則，以及可能有的文件、文檔及數據。
軟件復用(SoftWare Reuse)是將已有軟件的各種有關知識用于建立新的軟件，以縮減軟件開發和維護的花費。軟件復用是提高軟件生產力和質量的一種重要技術。早期的軟件復用主要是代碼級復用，被復用的知識專指程序，后來擴大到包括領域知識、開發經驗、設計決定、體系結構、需求、設計、代碼和文檔等一切有關方面。
可以被復用的軟件成分一般稱作可復用構件
36、您認為在測試人員同開發人員的溝通過程中，如何提高溝通的效率和改善溝通的效果？維持測試人員同開發團隊中其他成員良好的人際關系的關鍵是什么？
盡量面對面的溝通，其次是能直接通過電話溝通，如果只能通過Email等非及時溝通工具的話，強調必須對特性的理解深刻以及能表達清楚。
運用一些測試管理工具如TestDirector進行管理也是較有效的方法，同時要注意在TestDirector中對BUG有準確的描述。
在團隊中建立測試人員與開發人員良好溝通中注意以下幾點：
一真誠、二是團隊精神、三是在專業上有共同語言、四是要對事不對人，工作至上
當然也可以通過直接指出一些小問題，而不是進入BUG Tracking System來增加對方的好感。
37、你對測試最大的興趣在哪里？為什么？
最大的興趣，感覺這是一個有挑戰性的工作；測試是一個經驗行業，工作越久越能感覺到做好測試的難度和樂趣。通過自己的工作，能使軟件產品越來越完善，從中體會到樂趣。
38、你自認為測試的優勢在哪里？
有韌性、有耐心、做事有條理性、喜歡面對挑戰、有信心做好每一件事情、較強的溝通能力、從以前的經理處都得到了很好的評價表明我做的很好
39、簡述你在以前的工作中做過哪些事情，比較熟悉什么。參考答案如下。
我過去的主要工作是系統測試和自動化測試。在系統測試中，主要是對BOSS系統的業務邏輯功能，以及軟交換系統的Class 5特性進行測試。性能測試中，主要是進行的壓力測試，在各個不同數量請求的情況下，獲取系統響應時間以及系統資源消耗情況。自動化測試主要是通過自己寫腳本以及一些第三方工具的結合來測試軟交換的特性測試。
在測試中，我感覺對用戶需求的完全準確的理解非常重要。另外，就是對BUG的管理，要以需求為依據，并不是所有BUG均需要修改。
測試工作需要耐心和細致，因為在新版本中，雖然多數原來發現的BUG得到了修復，但原來正確的功能也可能變得不正確。因此要注重迭代測試和回歸測試。
40、在C/C++中static有什么用途？（請至少說明兩種）
1)在函數體，一個被聲明為靜態的變量在這一函數被調用過程中維持其值不變。
2) 在模塊內（但在函數體外），一個被聲明為靜態的變量可以被模塊內所用函數訪問，但不能被模塊外其它函數訪問。它是一個本地的全局變量。
3) 在模塊內，一個被聲明為靜態的函數只可被這一模塊內的其它函數調用。那就是，這個函數被限制在聲明它的模塊的本地范圍內使用
41、引用與指針有什么區別？
42、Internet采用哪種網絡協議？該協議的主要層次結構？Internet物理地址和IP地址轉換采用什么協議？
TCP/IP協議主要層次結構為： 應用層/傳輸層/網絡層/數鏈路層。
ARP (Address Resolution Protocol)（地據址解析協議）
43、說說你對集成測試中自頂向下集成和自底向上集成兩個策略的理解，要談出它們各自的優缺點和主要適應于哪種類型測試；
自頂向下集成
優點：較早地驗證了主要控制和判斷點；按深度優先可以首先實現和驗證一個完整的軟件功能；功能較早證實，帶來信心；只需一個驅動，減少驅動器開發的費用；支持故障隔離。
缺點：柱的開發量大；底層驗證被推遲；底層組件測試不充分。
適應于產品控制結構比較清晰和穩定；高層接口變化較小；底層接口未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要盡早被驗證；希望盡早能看到產品的系統功能行為。
自底向上集成
優點：對底層組件行為較早驗證；工作最初可以并行集成，比自頂向下效率高；減少了樁的工作量；支持故障隔離。
缺點：驅動的開發工作量大；對高層的驗證被推遲，設計上的錯誤不能被及時發現。
適應于底層接口比較穩定；高層接口變化比較頻繁；底層組件較早被完成。
44、系統測試的策略有哪些？
性能測試、負載測試、強度測試、易用性測試、安全測試、配置測試、安裝測試、文檔測試、故障恢復測試、用戶界面測試、恢復測試、分布測試、可用性測試。
45、設計系統測試計劃需要參考的項目文檔有軟件測試計劃、軟件需求工件、和迭代計劃
46、通過畫因果圖來寫測試用例的步驟為___、、、___及把因果圖轉換為狀態圖共五個步驟。 利用因果圖生成測試用例的基本步驟是：
§ 分析軟件規格說明描述中，哪些是原因（即輸入條件或輸入條件的等價類），哪些是結果（即輸出條件），并給每個原因和結果賦予一個標識符。
§ 分析軟件規格說明描述中的語義，找出原因與結果之間，原因與原因之間對應的是什么關系? 根據這些關系，畫出因果圖。
§ 由于語法或環境限制，有些原因與原因之間，原因與結果之間的組合情況不可能出現。為表明這些特殊情況，在因果圖上用一些記號標明約束或限制條件。 § 把因果圖轉換成判定表。
§ 把判定表的每一列拿出來作為依據，設計測試用例。
47、請說出這些測試最好由那些人員完成，測試的是什么？
代碼、函數級測試一般由白盒測試人員完成，他們針對每段代碼或函數進行正確性檢驗，檢查其是否正確的實現了規定的功能。
模塊、組件級測試主要依據是程序結構設計測試模塊間的集成和調用關系，一般由測試人員完成。
系統測試在于模塊測試與單元測試的基礎上進行測試。了解系統功能與性能，根據測試用例進行全面的測試。
49、 設計測試用例時應該考慮哪些方面，即不同的測試用例針對那些方面進行測試？
設計測試用例時需要注意的是，除了對整體流程及功能注意外，還要注意強度測試、性能測試、壓力測試、邊界值測試、穩定性測試、安全性測試等多方面。（測試用例需要考慮的四個基本要素是輸入、輸出、操作和測試環境；另外，測試用例需要考慮的是測試類型（功能、性能、安全……），這部分可以參照TP做答。此外，還需要考慮用例的重要性和優先級）
50、在windows下保存一個文本文件時會彈出保存對話框，如果為文件名建立測試用例，等價類應該怎樣劃分？
單字節，如A；雙字節， AA、我我；特殊字符 /‘。‘；、=-等；保留字，如com；文件格式為8.3格式的；文件名格式為非8.3格式的；/,,*等九個特殊字符。
51、假設有一個文本框要求輸入10個字符的郵政編碼，對于該文本框應該怎樣劃分等價類？
特殊字符，如10個*或￥；英文字母，如ABCDefghik；小于十個字符，如123；大于十個字符，如11111111111；數字和其他混合，如123AAAAAAA；空字符；保留字符
52、一個測試工程師應具備那些素質？
1、責任心2、溝通能力3、團隊合作精神4、耐心、細心、信心5、時時保持懷疑態度，并且有缺陷預防的意識6、具備一定的編程經驗
53、你認為做好測試計劃工作的關鍵是什么？
明確測試的目標，增強測試計劃的實用性
編寫軟件測試計劃得重要目的就是使測試過程能夠發現更多的軟件缺陷，因此軟件測試計劃的價值取決于它對幫助管理測試項目，并且找出軟件潛在的缺陷。因此，軟件測試計劃中的測試范圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具并且具有較高的實用性，便于使用，生成的測試結果直觀、準確
堅持“5W”規則，明確內容與過程
“5W”規則指的是“What（做什么）”、“Why（為什么做）”、“When（何時做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”規則創建軟件測試計劃，可以幫助測試團隊理解測試的目的（Why），明確測試的范圍和內容（What），確定測試的開始和結束日期（When），指出測試的方法和工具（How），給出測試文檔和軟件的存放位置（Where）。
采用評審和更新機制，保證測試計劃滿足實際需求
測試計劃寫作完成后，如果沒有經過評審，直接發送給測試團隊，測試計劃內容的可能不準確或遺漏測試內容，或者軟件需求變更引起測試范圍的增減，而測試計劃的內容沒有及時更新，誤導測試執行人員。
分別創建測試計劃與測試詳細規格、測試用例
應把詳細的測試技術指標包含到獨立創建的測試詳細規格文檔，把用于指導測試小組執行測試過程的測試用例放到獨立創建的測試用例文檔或測試用例管理數據庫中。測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計劃主要從宏觀上規劃測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。
54、您認為做好測試用例設計工作的關鍵是什么？
白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程序邏輯結果
黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時間內發現最多的問題
55、你的測試職業發展目標是什么？
測試經驗越多，測試能力越高。所以我的職業發展是需要時間累積的，一步步向著高級測試工程師奔去。而且我也有初步的職業規劃，前3年累積測試經驗，不斷的更新自己改正自己，做好測試任務。
56、測試結束的標準是什么？
從微觀上來說，在測試計劃中定義，比如系統在一定性能下平穩運行72小時，目前Bug Tracking System中，本版本中沒有一般嚴重的BUG，普通BUG的數量在3以下，BUG修復率90%以上等等參數，然后由開發經理，測試經理，項目經理共同簽字認同版本Release。
如果說宏觀的，則是當這個軟件徹底的消失以后，測試就結束了。
57、一套完整的測試應該由哪些階段組成？
可行性分析、需求分析、概要設計、詳細設計、編碼、單元測試、集成測試、系統測試、驗收測試
58、您是否了解以往所工作的企業的軟件開發過程？如果了解，請試述一個完整的開發過程需要完成哪些工作？分別由哪些不同的角色來完成這些工作？您在以往的測試工作中都曾經具體從事過哪些工作？其中最擅長哪部分工作？
開發過程—需求調研（需求人員）、需求分析（需求人員）、概要設計（設計人員）、詳細設計(設計人員)、編碼（開發人員）
測試過程—需求評審、系統測試設計、概要設計評審、集成測試設計、詳細設計評審、單元測試設計、測試執行
測試工作的整個過程都做過，擅長做測試設計
過程決定質量，軟件的過程改進正是為了提高軟件的質量，將過往的種種經驗教訓積累起來。
59、測試用例設計的原則是什么？目前主要的測試用例設計方法有哪些？
代表性：能夠代表并覆蓋各種合理的和不合理、合法的和非法的、邊界的和越界的、以及極限的輸入數據、操作和環境設置等.
可判定性：即測試執行結果的正確性是可判定的，每一個測試用例都應有相應的期望結果.
可再現性：即對同樣的測試用例，系統的執行結果應當是相同的。
方法有等價類、邊界值、因果圖、狀態圖、正交法、大綱法
60、面向對象的測試用例設計有幾種方法？如何實現？
給類中的每個構造函數設計一組測試用例
組合類中的類變量、實例變量
組合類中的各種方法
根據前置條件和后置條件設計測試用例
根據代碼設計測試用例
61、LoadRunner分為哪三個模塊？請簡述各模塊的主要功能。
Virtual User Generator：用于錄制腳步
Mercury LoadRunner Controller：用于創建、運行和監控場景
Mercury LoadRunner Analysis：用于分析測試結果
62、你對測試最大的興趣在哪里？為什么？
最大的興趣就是測試有難度，有挑戰性！做測試越久越能感覺到做好測試有多難。曾經在無憂測試網上看到一篇文章，是關于如何做好一名測試工程師。一共羅列了11，12點，有部分是和人的性格有關，有部分需要后天的努力。但除了性格有關的1，2點我沒有把握，其他點我都很有信心做好它。
剛開始進入測試行業時，對測試的認識是從無憂測試網上了解到的一些資料，當時是沖著做測試需要很多技能才能做的好，雖然入門容易，但做好很難，比開發更難，雖然當時我很想做開發（學校專業課我基本上不缺席，因為我喜歡我的專業），但看到測試比開發更難更有挑戰性，想做好測試的意志就更堅定了。
我覺得做測試整個過程中有2點讓我覺得很有難度（對我來說，有難度的東西我就非常感興趣），第一是測試用例的設計，因為測試的精華就在測試用例的設計上了，要在版本出來之前，把用例寫好，用什么測試方法寫？（也就是測試計劃或測試策略），如果你剛測試一個新任務時，你得花一定的時間去消化業務需求和技術基礎，業務需求很好理解（多和產品經理和開發人員溝通就能達到目的），而技術基礎可就沒那么簡單了，這需要你自覺的學習能力，比如說網站吧，最基本的技術知識你要知道網站內部是怎么運作的的，后臺是怎么響應用戶請求的？測試環境如何搭建？這些都需要最早的學好。至少在開始測試之前能做好基本的準備，可能會遇到什么難題？需求細節是不是沒有確定好？這些問題都能在設計用例的時候發現。
第二是發現BUG的時候了，這應該是測試人員最基本的任務了，一般按測試用例開始測試就能發現大部分的bug，還有一部分bug需要測試的過程中更了解所測版本的情況獲得更多信息，補充測試用例，測試出bug。還有如何發現bug？這就需要在測試用例有效的情況下，通過細心和耐心去發現bug了，每個用例都有可能發現bug，每個地方都有可能出錯，所以測試過程中思維要清晰（測試過程數據流及結果都得看仔細了，bug都在里面發現的）。如何描述bug也很有講究，bug在什么情況下會產生，如果條件變化一點點，就不會有這個bug，以哪些最少的操作步驟就能重現這個bug，這個bug產生的規律是什么？如果你夠厲害的話，可以幫開發人員初步定位問題。
63、您所熟悉的軟件測試類型都有哪些？請試著分別比較這些不同的測試類型的區別與聯系（如功能測試、性能測試……）
測試類型有：功能測試，性能測試，界面測試。
功能測試在測試工作中占的比例最大，功能測試也叫黑盒測試。是把測試對象看作一個黑盒子。利用黑盒測試法進行動態測試時，需要測試軟件產品的功能，不需測試軟件產品的內部結構和處理過程。采用黑盒技術設計測試用例的方法有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略。
性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬于性能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下系統的性能，目標是測試當負載逐漸增加時，系統各項性能指標的變化情況。壓力測試是通過確定一個系統的瓶頸或者不能接收的性能點，來獲得系統能提供的最大服務級別的測試。
界面測試，界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印象。而且設計良好的界面能夠引導用戶自己完成相應的操作，起到向導的作用。同時界面如同人的面孔，具有吸引用戶的直接優勢。設計合理的界面能給用戶帶來輕松愉悅的感受和成功的感覺，相反由于界面設計的失敗，讓用戶有挫敗感，再實用強大的功能都可能在用戶的畏懼與放棄中付諸東流。
區別在于，功能測試關注產品的所有功能上，要考慮到每個細節功能，每個可能存在的功能問題。性能測試主要關注于產品整體的多用戶并發下的穩定性和健壯性。界面測試更關注于用戶體驗上，用戶使用該產品的時候是否易用，是否易懂，是否規范（快捷鍵之類的），是否美觀（能否吸引用戶的注意力），是否安全（盡量在前臺避免用戶無意輸入無效的數據，當然考慮到體驗性，不能太粗魯的彈出警告）？做某個性能測試的時候，首先它可能是個功能點，首先要保證它的功能是沒問題的，然后再考慮該功能點的性能測試
64、針對于軟件的行業背景，你如何理解軟件的業務？
閱讀用戶手冊了解軟件的功能和操作流程；看一些業務的專業書籍補充業務知識；如果有用戶實際的數據，可以拿實際的數據進行參考；參考以前的用例和BUG報告；在使用軟件的過程中多思考；多與產品經理交流。
65、什么是兼容性測試？請舉例說明如何利用兼容性測試列表進行測試。
主要驗證軟件產品在不同版本之間的兼容性。包括向下兼容和交錯兼容，向下兼容是測試軟件新版本保留它早期版本功能的情況，交錯兼容是驗證共同存在的兩個相關但不相同的產品之間的兼容性。
66、對某軟件進行測試，發現在WIN98上運行得很慢，怎么判別是該軟件存在問題還是其軟硬件運行環境存在問題？
看軟件的運行環境要求。如果符合要求則是程序存在問題，若不符合要求則是硬件系統存在問題
67、需求測試的注意事項有哪些？
是否使用了公司的模板、文檔內容是否符合規范、所有的需求是分級是否清析適當、所有的需求是否具有一致性、需求是否可行（即，該需求組合有解決方案）、需求可否用己知的約束來實現、需求是否足夠（即，可以把它送到一個規范的開發組織，并有一個生產出所需要產品的合理的可能性）、所有的其它需求是交叉引用是否正確、用戶描述是否清楚、是否用客戶的語言來描述需求、每個需求描述是否清楚沒有岐義，可以移交給一個獨立的組去實現時也能理解、是否所有的需求都是可驗證的、是否每條需求都具有獨立性，即使發生了變化也不會影響其它需求、性能指標是否明確、非功能性需求是否得到充分表現、是否完整列出適用的標準或協議、標準和協議之間是否存在沖突
68、主鍵、外鍵的作用，索引的優點與不足?
1、主鍵：是表中的唯一標示鍵。作用：保證實體的完整性;加快數據庫的操作速度;增加新的表記錄時，數據庫會自動檢索新記錄的主鍵值，不允許該值與其他表中記錄的主鍵重復;數據庫會按主鍵值的順序顯示記錄，如果沒有設定主鍵，則按輸入的順序顯示記錄。
2、外鍵：是主鍵的從屬，表示了兩個表之間的聯系。作用：使用外鍵可以避免冗余。
索引
優點：
1、通過創建唯一性的索引，可以保證表中數據的唯一性;
2、加速數據的檢索速度;
3、加快表與表之間的連接;
4、在使用分組與排序數據檢索時，可以顯著檢索分組與排序的時間;
5、在查詢的過程中使用優化隱藏器，提供系統性能。
缺點：
1、創建索引需要時間，且隨著數據量的增加而增加;
2、索引需要占用物理空間;
3、當對表中數據進行修改時，索引也要動態維護，降低了數據的維護速度。
69、性能測試的流程?
1.測試需求分析
2.測試計劃制定與評審
3.測試用例設計與開發
4.測試執行與監控
5.分析測試結果
6.編寫性能測試報告
7.測試經驗總結
70、簡述bug的生命周期?
1、有效地記錄BUG
2、使用BUG模板
3、評價BUG優先級和嚴重性
4、BUG的生命
5、維護BUG數據庫
71、缺陷記錄應包含的內容?
缺陷標識、缺陷類型、缺陷嚴重程度、缺陷產生可能性、缺陷優先級、缺陷狀態、缺陷起源、缺陷來源、缺陷原因;
72、您所熟悉的軟件測試類型都有哪些?請試著分別比較這些不同的測試類型的區別與聯系(如功能測試、性能測試……)
易用性測試-界面的友好性，操作方便性等。
功能測試-系統中功能性需求的滿足
安全性測試-系統是否存在安全隱患和漏洞
性能測試-系統在大并發下的響應速度和健壯性
73、您認為做好測試計劃工作的關鍵是什么?
了解項目或系統的業務需求
和項目經理協調好，了解項目的進度計劃安排情況
74、.您以往的工作中是否曾開展過測試用例的評審工作?如果有，請描述測試用例評審的過程和評審的內容。
評審計劃->預審->評審;
評審內容主要是測試用例對軟件需求的覆蓋程度，對于相關邊界是否考慮，是否針對復雜流程準備多套測試數據，是否有專門針對非功能性需求的測試。
75、您認為性能測試工作的目的是什么?做好性能測試工作的關鍵是什么?
關鍵是測試腳本的錄制，測試時候測試環境的干凈。
76、.您如何看待軟件過程改進?在您曾經工作過的企業中，是否有一些需要改進的東西呢?您期望的理想的測試人員的工作環境是怎樣的?
將先進的經驗或思想固化到過程中，通過過程改進和能力提高來改進軟件質量。
總結
以上是生活随笔為你收集整理的软件测试面试常见问题（2）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Github Student Devel
- 下一篇： 看图学中文版VS2010 Workflo