1、你的測試職業發展是什么？
測試經驗越多，測試能力越高。所以我的職業發展是需要時間積累的，一步步向着高級測試工程師奔去。而且我也有初步的職業規划，前3年積累測試經驗，按如何做好測試工程師的要點去要求自己，不斷更新自己改正自己，做好測試任務。
優勢在於我對測試堅定不移的信心和熱情，雖然經驗還不夠，但測試需要的基本技能我有信心在工作中得以發揮。
2、你認為測試人員需要具備哪些素質
做測試應該要有一定的協調能力，因為測試人員經常要與開發接觸處理一些問題，如果處理不好的話會引起一些沖突，這樣的話工作上就會不好做。還有測試人員要有一定的耐心，有的時候做測試很枯燥乏味。除了耐心，測試人員不能放過每一個可能的錯誤。
3、你為什么能夠做測試這一行
雖然我的測試技術還不是很成熟，但是我覺得我還是可以勝任軟件測試這個工作的，因為做軟件測試不僅是要求技術好，還有有一定的溝通能力，耐心、細心等外在因素。綜合起來看我認為我是勝任這個工作的。
4、測試的目的是什么？
測試的目的是找出軟件產品中的錯誤，是軟件盡可能的符合用戶的要求。當然軟件測試是不可能找出全部錯誤的。
5、測試分為哪幾個階段？
一般來說分為5個階段：單元測試、集成測試、確認測試、系統測試、驗收測試
6、單元測試的測試對象、目的、測試依據、測試方法？
測試對象是模塊內部的程序錯誤，目的是消除局部模塊邏輯和功能上的錯誤和缺陷。測試依據是模塊的詳細設計，測試方法是采用白盒測試。
7、怎樣看待加班問題
加班的話我沒有太多意見，但是我還是覺得如果能夠合理安排時間的話，不會有太多時候加班的。
8、結合你以前的學習和工作經驗，你認為如何做好測試。
根據我以前的工作和學習經驗，我認為做好工作首先要有一個良好的溝通，只有溝通無障礙了，才會有好的協作，才會有更好的效率，再一個就是技術一定要過關，做測試要有足夠的耐心，和一個良好的工作習慣，不懂的就要問，實時與同事溝通這樣的話才能做好測試工作。
9、你為什么選擇軟件測試行業
因為之前了解軟件測試這個行業，覺得他的發展前景很好。
10、根據你以前的工作或學習經驗描述一下軟件開發、測試過程，由哪些角色負責，你做什么
要有架構師、開發經理、測試經理、程序員、測試員。我在里面主要是負責所分到的模塊執行測試用例。
11、根據你的經驗說說你對軟件測試/質量保證的理解
軟件質量保證與測試是根據軟件開發階段的規格說明和程序的內部結構而精心設計的一批測試用例(即輸入數據和預期的輸出結果)，並根據這些測試用例去運行程序，以發現錯誤的過程。它是對應用程序的各個方面進行測試以檢查其功能、語言有效性及其外觀排布。
12、軟件測試的流程是什么？
需求調查：全面了解系統概況、應用領域、軟件開發周期、軟件開發環境、開發組織、時間安排、功能需求、性能需求、質量需求及測試要求等。根據系統概況進行項目所需的人員、時間和工作量估計以及項目報價。
制定初步的項目計划。
測試准備：組織測試團隊、培訓、建立測試和管理環境等。
測試設計：按照測試要求進行每個測試項的測試設計，包括測試用例的設計和測試腳本的開發等。
測試實施：按照測試計划實施測試。
測試評估：根據測試的結果，出具測試評估報告。
13、你對SQA的職責和工作活動(如軟件度量)的理解?
SQA就是獨立於軟件開發的項目組，通過對軟件開發過程的監控，來保證軟件的開發流程按照指定的CMM規程(如果有相應的CMM規程),對於不符合項及時提出建議和改進方案，必要時可以向高層經理匯報以求問題的解決。通過這樣的途徑來預防缺陷的引入，從而減少后期軟件的維護成本。SQA主要的工作活動包括制定SQA工作計划，參與階段產物的評審，進行過程質量、功能配置及物理配置的審計等；對項目開發過程中產生的數據進行度量等等。
14、說說你對軟件配置管理的理解
項目在開發過程中要用相應的配置管理工具對配置項(包括各個階段的產物)進行變更控制，配置管理的使用取決於項目規模和復雜性及風險的水平。軟件的規模越大，配置管理就越顯得重要。還有在配置管理中，有一個很重要的概念，那就是基線，是在一定階段各個配置項的組合，一個基線就提供了一個正式的標准，隨后的工作便基於此標准，並只有經過授權后才能變更這個標准。配置管理工具主要有CC，VSS,CVS,SVN等。
15、怎樣寫測試計划和測試用例
簡單點，測試計划里應有詳細的測試策略和測試方法，合理詳盡的資源安排等，至於測試用例，那是依賴於需求(包括功能與非功能需求)是否細化到功能點，是否可測試等。
16、什么是兼容性測試？兼容性測試側重哪些方面？
兼容測試主要是檢查軟件在不同的硬件平台、軟件平台上是否可以正常的運行，即是通常說的軟件的可移植性。
兼容的類型，如果細分的話，有平台的兼容，網絡兼容，數據庫兼容，以及數據格式的兼容。
兼容測試的重點是，對兼容環境的分析。通常，是在運行軟件的環境不是很確定的情況下，才需要做兼容。根據軟件運行的需要，或者根據需求文檔，一般都能夠得出用戶會在什么環境下使用該軟件，把這些環境整理成表單，就得出做兼容測試的兼容環境了。
兼容和配置測試的區別在於，做配置測試通常不是Clean OS下做測試，而兼容測試多是在Clean OS的環境下做的。
17、我現在有個程序，發現在Windows上運行得很慢，怎么判別是程序存在問題還是軟硬件系統存在問題？
–1、檢查系統是否有中毒的特征；
–2、檢查軟件/硬件的配置是否符合軟件的推薦標准；
–3、確認當前的系統是否是獨立，即沒有對外提供什么消耗CPU資源的服務；
–4、如果是C/S或者B/S結構的軟件，需要檢查是不是因為與服務器的連接有問題，或者訪問有問題造成的；
–5、在系統沒有任何負載的情況下，查看性能監視器，確認應用程序對CPU/內存的訪問情況。
18、測試的策略有哪些？
黑盒/白盒，靜態/動態## 標題，手工/自動，冒煙測試，回歸測試，公測（Beta測試的策略）
19、你覺得bugzilla在使用的過程中，有什么問題？
–界面不穩定；
–根據需要配置它的不同的部分，過程很煩瑣。
–流程控制上，安全性不好界定，很容易對他人的Bug進行誤操作；
–沒有綜合的評分指標，不好確認修復的優先級別。
20、描述測試用例設計的完整過程？
–1、需求分析 + 需求變更的維護工作；
–2、根據需求得出測試需求；
–3、設計測試方案，評審測試方案；
–4、方案評審通過后，設計測試用例，再對測試用例進行評審；
21、單元測試的策略有哪些？
邏輯覆蓋、循環覆蓋、同行評審、桌前檢查、代碼走查、代碼評審、景泰數據流分析
22、LoadRunner分哪三部分？
用戶動作設計；場景設計； 測試數據分析；
23、LoadRunner進行測試的流程?
–1、 熟悉業務流程，測試規划
–2、 創建虛擬用戶腳本
–3、 創建運行場景
–4、 運行測試腳本
–5、 監視場景
–6、 分析測試的結果
以上，最好是結合一個案例，根據以上流程來介紹。
24、軟件的評審一般由哪些人參加？其目的是什么？
在正式的會議上將軟件項目的成果（包括各階段的文檔、產生的代碼等）提交給用戶、客戶或有關部門人員對軟件產品進行評審和批准。其目的是找出可能影響軟件產品質量、開發過程、維護工作的適用性和環境方面的設計缺陷，並采取補救措施，以及找出在性能、安全性和經濟方面的可能的改進。
人員：用戶、客戶或有關部門開發人員，測試人員，需求分析師都可以，就看處於評審那個階段
25、Beta測試與Alpha測試有什么區別？
–Beta testing(β測試),測試是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者通常不在測試現場
–Alpha testing (α測試),是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試
26、你認為做好測試計划工作的關鍵是什么？
軟件測試計划就是在軟件測試工作正式實施之前明確測試的對象，並且通過對資源、時間、風險、測試范圍和預算等方面的綜合分析和規划，保證有效的實施軟件測試；
做好測試計划工作的關鍵 ：目的，管理，規范
（1）、明確測試的目標，增強測試計划的實用性編寫軟件測試計划得重要目的就是使測試過程能夠發現更多的軟件缺陷，因此軟件測試計划的價值取決於它對幫助管理測試項目，並且找出軟件潛在的缺陷。因此，軟件測試計划中的測試范圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具並且具有較高的實用性，便於使用，生成的測試結果直觀、准確
（2）、堅持“5W”規則，明確內容與過程“5W”規則指的是“What（做什么）”、“Why（為什么做）”、“When（何時做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”規則創建軟件測試計划，可以幫助測試團隊理解測試的目的（Why），明確測試的范圍和內容（What），確定測試的開始和結束日期（When），指出測試的方法和工具（How），給出測試文檔和軟件的存放位置（Where）。
（3）、采用評審和更新機制，保證測試計划滿足實際需求測試計划寫作完成后，如果沒有經過評審，直接發送給測試團隊，測試計划內容的可能不准確或遺漏測試內容，或者軟件需求變更引起測試范圍的增減，而測試計划的內容沒有及時更新，誤導測試執行人員。
（4）、分別創建測試計划與測試詳細規格、測試用例應把詳細的測試技術指標包含到獨立創建的測試詳細規格文檔，把用於指導測試小組執行測試過程的測試用例放到獨立創建的測試用例文檔或測試用例管理數據庫中。測試計划和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計划主要從宏觀上規划測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。
27、你認為做好測試用例工作的關鍵是什么？
需求和設計文檔的理解程度，對系統的熟悉程度
28、簡述一下缺陷的生命周期？
提交->確認->分配->修復->驗證->關閉
29、軟件的安全性應從哪幾個方面去測試？
(1) 用戶認證機制：如數據證書、智能卡、雙重認證、安全電子交易協議
(2) 加密機制
(3) 安全防護策略：如安全日志、入侵檢測、隔離防護、漏洞掃描
(4) 數據備份與恢復手段：存儲設備、存儲優化、存儲保護、存儲管理
(5) 防病毒系統
30、你覺得軟件測試通過的標准應該是什么樣的？
缺陷密度值達到客戶的要求
31、一套完整的測試應該由哪些階段組成？
需求評審（有開發人員，產品經理，測試人員，項目經理）－>需求確定(出一份確定的需求文檔)－>開發設計文檔（開發人員在開始寫代碼前就能輸出設計文檔）－>想好測試策略，寫出測試用例－>發給開發人員和測試經理看看（非正式的評審用例）－>接到測試版本－>執行測試用例（中間可能會補充用例）－>提交bug（有些bug需要開發人員的確定（嚴重級別的，或突然發現的在測試用例范圍之外的，難以重現的），有些可以直接錄制進TD）－>開發人員修改（可以在測試過程中快速的修改）－>回歸測試（可能又會發現新問題，再按流程開始跑）
32、如何理解壓力、負載、性能測試測試？
性能測試是一個較大的范圍，實際上性能測試本身包含了性能、強度、壓力、負載等多方面的測試內容。
壓力測試是對服務器的穩定性以及負載能力等方面的測試，是一種很平常的測試。增大訪問系統的用戶數量、或者幾個用戶進行大數據量操作都是壓力測試。而負載測試是壓力相對較大的測試，主要是測試系統在一種或者集中極限條件下的相應能力，是性能測試的重要部分。100個用戶對系統進行連續半個小時的訪問可以看作壓力測試，那么連續訪問8個小時就可以認為負載測試，1000個用戶連續訪問系統1個小時也可以看作是負載測試。
實際上壓力測試和負載測試沒有明顯的區分。測試人員應該站在關注整體性能的高度上來對系統進行測試。
33、如何編寫提交給用戶的測試報告？
----根據內部測試報告進行編寫，一般可以摘錄；
----不可以向客戶報告嚴重缺陷，即使是已經修改的缺陷，開發中的缺陷也沒有必要讓客戶知道；
----報告上可以列出一些缺陷，但必須是中級的缺陷，而且這些缺陷必須是修復的； -報告上面的內容盡量要真實可靠；
----整個測試報告要仔細審閱，力爭不給項目帶來負面作用，尤其是性能測試報告。
34、您所熟悉的測試用例設計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設計工作中的應用。
1 ．等價類划分
划分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入數據對於揭露程序中的錯誤都是等效的.並合理地假定:測試某等價類的代表值就等於對這一類其它值的測試.因此,可以把全部輸入數據合理划分為若干等價類,在每一個等價類中取一個數據作為測試的輸入條件,就可以用少量代表性的測試數據.取得較好的測試結果.等價類划分可有兩種不同的情況:有效等價類和無效等價類.
2．邊界值分析法
邊界值分析方法是對等價類划分方法的補充。測試工作經驗告訴我,大量的錯誤是發生在輸入或輸出范圍的邊界上,而不是發生在輸入輸出范圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.
使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應着重測試的邊界情況.應當選取正好等於,剛剛大於或剛剛小於邊界的值作為測試數據,而不是選取等價類中的典型值或任意值作為測試數據.
3．錯誤推測法
基於經驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法.
錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模塊中常見的錯誤. 以前產品測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入數據和輸出數據為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作為測試用例.
4．因果圖方法
前面介紹的等價類划分方法和邊界值分析方法,都是着重考慮輸入條件,但未考慮輸入條件之間的聯系, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件划分成等價類,他們之間的組合情況也相當多. 因此必須考慮采用一種適合於描述對於多種條件的組合,相應產生多個動作的形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是判定表. 它適合於檢查程序輸入條件的各種組合情況.
35、你對測試最大的興趣在哪里？為什么？
最大的興趣就是測試有難度，有挑戰性！做測試越久越能感覺到做好測試有多難。做測試，有部分是和人的性格有關，有部分需要后天的努力。但除了性格有關的我沒有把握，其他點我都很有信心做好它。
36、當開發人員說不是BUG時，你如何應付？
開發人員說不是bug，有2種情況，一是需求沒有確定，所以我可以這么做，這個時候可以找來產品經理進行確認，需不需要改動，3方商量確定好后再看要不要改。二是這種情況不可能發生，所以不需要修改，這個時候，我可以先盡可能的說出是BUG的依據是什么？如果還是不行，那我可以給這個問題提出來,跟開發經理和測試經理進行確認,如果要修改就改,如果不要修改就不改。其實有些真的不是bug，我也只是建議的方式寫進TD中，如果開發人員不修改也沒有大問題。如果確定是bug的話，一定要堅持自己的立場，讓問題得到最后的確認。
37、寫出bug報告當中一些必備的內容。
硬件平台和操作系統
測試應用的硬件平台（Platform），通常選擇“PC”。
測試應用的操作系統平台（OS）。
a) 版本 提交缺陷報告時通過該字段標識此缺陷存在於被測試軟件的哪個版本。
b) Bug報告優先級
c) Bug狀態
d) Bug的編號
e) 發現人
f) 提交人
g) 指定處理人
h) 概述
i) 從屬關系
j) 詳細描述
k) 嚴重程度
l) 所屬模塊
m) 附件
n) 提交日期
38、開發人員老是犯一些低級錯誤怎么解決？
從兩個方面入手：
一方面從開發管理入手，也就是從根源來解決問題。可以制定規范的開發流程，甚至可以制定懲罰制度，還有就是軟件開發前做好規划設計。
另一方面就是加強測試，具體做法就是加強開發人員的自己測試，把這些問題“消滅”在開發階段，這是比較好的做法。
39、簡述一下c/s模式或者b/s模式？
C/S模式：客戶端/服務器模式。工作原理：Client向Server提交一個請求；Server則使用一些方法處理這個請求，並將效果返回給Client。
B/S結構，即Browser/Server(瀏覽器/服務器)結構，主要是利用了不斷成熟的WWW瀏覽器技術，結合瀏覽器的多種Script語言(VBScript、JavaScript…)和ActiveX技術，用通用瀏覽器就實現了原來需要復雜專用軟件才能實現的強大功能，並節約了開發成本，是一種全新的軟件系統構造技術。