Part1
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在使用的過程中，有什么問題？
1、界面不穩定；
2、根據需要配置它的不同的部分，過程很煩瑣。
3、流程控制上，安全性不好界定，很容易對他人的Bug進行誤操作；
4、沒有綜合的評分指標，不好確認修復的優先級別。
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技術，用通用瀏覽器就實現了原來需要復雜專用軟件才能實現的強大功能，并節約了開發成本，是一種全新的軟件系統構造技術。
Part2
1、什么是兼容性測試？兼容性測試側重哪些方面？
參考答案：
兼容測試主要是檢查軟件在不同的硬件平臺、軟件平臺上是否可以正常的運行，即是通常說的軟件的可移植性。
兼容的類型，如果細分的話，有平臺的兼容，網絡兼容，數據庫兼容，以及數據格式的兼容。
兼容測試的重點是，對兼容環境的分析。通常，是在運行軟件的環境不是很確定的情況下，才需要做兼容。根據軟件運行的需要，或者根據需求文檔，一般都能夠得出用戶會在什么環境下使用該軟件，把這些環境整理成表單，就得出做兼容測試的兼容環境了。
兼容和配置測試的區別在于，做配置測試通常不是Clean OS下做測試，而兼容測試多是在Clean OS的環境下做的。
2、我現在有個程序，發現在Windows上運行得很慢，怎么判別是程序存在問題還是軟硬件系統存在問題？
參考答案：
1、檢查系統是否有中毒的特征；
2、檢查軟件/硬件的配置是否符合軟件的推薦標準；
3、確認當前的系統是否是獨立，即沒有對外提供什么消耗CPU資源的服務；
4、如果是C/S或者B/S結構的軟件，需要檢查是不是因為與服務器的連接有問題，或者訪問有問題造成的；
5、在系統沒有任何負載的情況下，查看性能監視器，確認應用程序對CPU/內存的訪問情況。
3、測試的策略有哪些？
參考答案：
黑盒/白盒，靜態/動態，手工/自動，冒煙測試，回歸測試，公測（Beta測試的策略）
4、正交表測試用例設計方法的特點是什么？
參考答案：
用最少的實驗覆蓋最多的操作，測試用例設計很少，效率高，但是很復雜；
對于基本的驗證功能，以及二次集成引起的缺陷，一般都能找出來；但是更深的缺陷，更復雜的缺陷，還是無能為力的；
具體的環境下，正交表一般都很難做的。大多數，只在系統測試的時候使用此方法。
5、描述使用bugzilla缺陷管理工具對軟件缺陷（BUG）跟蹤的管理的流程？
參考答案：
就是Bugzilla的狀態轉換圖。
6、你覺得bugzilla在使用的過程中，有什么問題？
參考答案：
界面不穩定；
根據需要配置它的不同的部分，過程很煩瑣。
流程控制上，安全性不好界定，很容易對他人的Bug進行誤操作；
沒有綜合的評分指標，不好確認修復的優先級別。
7、描述測試用例設計的完整過程？
參考答案：
需求分析 + 需求變更的維護工作；
根據需求 得出測試需求；
設計測試方案，評審測試方案；
方案評審通過后，設計測試用例，再對測試用例進行評審；
8、單元測試的策略有哪些？
參考答案：
邏輯覆蓋、循環覆蓋、同行評審、桌前檢查、代碼走查、代碼評審、景泰數據流分析
9、LoadRunner分哪三部分？
參考答案：
用戶動作設計；
場景設計；
測試數據分析；
10、LoadRunner進行測試的流程?
參考答案：
1、 計劃負載測試
2、 創建虛擬用戶腳本
3、 創建運行場景
4、 運行測試腳本
5、 監視場景
6、 分析測試的結果
以上，最好是結合一個案例，根據以上流程來介紹。
part3
1、軟件的生命周期（prdctrm）
計劃階段（planning）-〉需求分析（requirement）-〉設計階段（design）-〉編碼（coding）->測試（testing）->運行與維護（running maintrnacne）
2、你在測試中發現了一個bug，但是開發經理認為這不是一個bug，你應該怎樣解決？
首先，將問題提交到缺陷管理庫里面進行備案。
然后，要獲取判斷的依據和標準：根據需求說明書、產品說明、原型圖、設計文檔等，確認實際結果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據；
如果沒有文檔依據，
1）可以根據同行或類似軟件的一般特性來說明是否存在不一致的地方，來確認是否是缺陷；
2）根據用戶的一般使用習慣，來確認是否是缺陷；
3）與設計人員、開發人員和客戶代表等相關人員探討，確認是否是缺陷；
合理的論述，向測試經理說明自己的判斷的理由，等待測試經理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反映，并有上級做出決定。
3、給你一個網站，你如何測試？
首先，查找需求說明、網站設計等相關文檔，分析測試需求。
制定測試計劃，確定測試范圍和測試策略，一般包括以下幾個部分：功能性測試；界面測試；性能測試；數據庫測試；安全性測試；兼容性測試
設計測試用例：
功能性測試可以包括，但不限于以下幾個方面：
鏈接測試。鏈接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯信息返回。
提交功能的測試。
多媒體元素是否可以正確加載和顯示。
多語言支持是否能夠正確顯示選擇的語言等。
界面測試可以包括但不限于一下幾個方面：
頁面是否風格統一，美觀
頁面布局是否合理，重點內容和熱點內容是否突出
控件是否正常使用
對于必須但未安裝的控件，是否提供自動下載并安裝的功能
文字檢查
性能測試一般從以下兩個方面考慮：
壓力測試；負載測試；強度測試
數據庫測試要具體決定是否需要開展。數據庫一般需要考慮連結性，對數據的存取操作，數據內容的驗證等方面。
安全性測試：
基本的登錄功能的檢查
是否存在溢出錯誤，導致系統崩潰或者權限泄露
相關開發語言的常見安全性問題檢查，例如SQL注入等
如果需要高級的安全性測試，確定獲得專業安全公司的幫助，外包測試，或者獲取支持兼容性測試，
根據需求說明的內容，確定支持的平臺組合：
瀏覽器的兼容性；
操作系統的兼容性；
軟件平臺的兼容性；
數據庫的兼容性
開展測試，并記錄缺陷。合理的安排調整測試進度，提前獲取測試所需的資源，建立管理體系（
例如，需求變更、風險、配置、測試文檔、缺陷報告、人力資源等內容）。
定期評審，對測試進行評估和總結，調整測試的內容。
4、一臺客戶端有三百個客戶與三百個客戶端有三百個客戶對服務器施壓，有什么區別?
300個用戶在一個客戶端上，會占用客戶機更多的資源，而影響測試的結果。線程之間可能發生干擾，而產生一些異常。
300個用戶在一個客戶端上，需要更大的帶寬。
IP地址的問題，可能需要使用IP Spoof來繞過服務器對于單一IP地址最大連接數的限制。
所有用戶在一個客戶端上，不必考慮分布式管理的問題；
而用戶分布在不同的客戶端上，需要考慮使用控制器來整體調配不同客戶機上的用戶。同時，還需要給予相應的權限配置和防火墻設置。
5、軟件生存周期及其模型是什么？
軟件生存周期（Software life cycle）又稱為軟件生命期，生存期。是指從形成開發軟件概念起，所開發的軟件使用以后，直到失去使用價值消亡為止的整個過程。一般來說，整個生存周期包括 ：問題的定義及規劃、需求分析/評審、軟件設計、軟件編碼、測試階段、運行維護 六個時期，每個時期又劃分為若干個階段。每個階段有明確的任務。
周期模型（典型的幾種）：
1）瀑布模型
2）快速原型模型：快速原型模型允許在需求分析階段對軟件的需求進行初步而非完全的分析和定義，快速設計開發出軟件系統的原型，該原型向用戶展示待開發軟件的全部或部分功能和性能；用戶對該原型進行測試評定，給出具體改進意見以豐富細化軟件需求；開發人員據此對軟件進行修改完善，直至用戶滿意認可之后，進行軟件的完整實現及測試、維護。
3）迭代模型：迭代包括產生產品發布（穩定、可執行的產品版本）的全部開發活動和要使用該發布必需的所有其他外圍元素。在某種程度上，開發迭代是一次 完整地經過所有工作流程的過程：需求分析、設計、實施和測試工作流程。實質上，它類似小型的瀑布式項目。RUP認為，所有的階段都可以細分為迭代。每一次 的迭代都會產生一個可以發布的產品，這個產品是最終產品的一個子集。
生命周期階段：
軟件計劃與可行性分析
需求分析
軟件設計
編碼
軟件測試
運行與維護
6、什么是軟件測試？軟件測試的目的與原則
定義：
在規定的條件下對程序進行操作，以發現程序錯誤，衡量軟件質量，并對其是否能滿足設計要求進行評估的過程。
目的：
測試是程序的執行過程，目的在于發現錯誤
軟件測試為了發現程序中存在的代碼或業務邏輯錯誤
軟件測試為了檢驗產品是否符合用戶的需求
軟件測試為了提高用戶體驗
軟件測試的原則：
測試應盡早啟動、介入（需求分析階段），所有的測試應追溯到用戶需求，測試證明軟件存在缺陷，不可能執行窮盡測試，完全測試是不可能的，測試需要終止。
二八原則，測試發現的錯誤中80%很可能的起源于20%的模塊中。（缺陷存在群集現象）
對錯誤結果要進行一個確認的過程（測試的詳細數據，截圖，前置條件等），制定嚴格的測試計劃；妥善保管測試過程中的所有文檔；程序員盡量避免自己的檢查程序；設計測試用例是應該考慮到合法的輸入和不合法的輸入
7、什么是軟件質量？
概括地說，軟件質量就是“軟件與明確的和隱含的定義的需求相一致的程度”。具體地說，軟件質量是軟件符合明確敘述的功能和性能需求、文檔中明確描述 的開發標準、以及所有專業開發的軟件都應具有的隱含特征的程度。 影響軟件質量的主要因素，這些因素是從管理角度對軟件質量的度量。可劃分為三組，分別反應用戶在使用軟件產品時的三種觀點。正確性、健壯性、效率、完整性、可用性、風險（產品運行）；可理解性、可維修性、靈活性、可測試性（產品修改）；可移植性、可再用性、互運行性（產品轉移）。
8、目前主要的測試用例設計方法是什么？
白盒測試：邏輯覆蓋、循環覆蓋、基本路徑覆蓋
黑盒測試：邊界值分析法、等價類劃分、錯誤猜測法、因果圖法、狀態圖法、測試大綱法、隨機測試、場景法
9、軟件的安全性應從哪幾個方面去測試？
軟件安全性測試包括程序、數據庫安全性測試。根據系統安全指標不同測試策略也不同。
用戶認證安全的測試要考慮問題：
1）明確區分系統中不同用戶權限 、系統中會不會出現用戶沖突 、系統會不會因用戶的權限的改變造成混亂
2）用戶登陸密碼是否是可見、可復制 、是否可以通過絕對途徑登陸系統（拷貝用戶登陸后的鏈接直接進入系統）
3）用戶退出系統后是否刪除了所有鑒權標記，是否可以使用后退鍵而不通過輸入口令進入 系統
系統網絡安全的測試要考慮問題 ：
1）測試采取的防護措施是否正確裝配好
2）有關系統的補丁是否打上
3）模擬非授權***
4）看防護系統是否堅固
5）采用成熟的網絡漏洞檢查工具檢查系統相關漏洞（即用最專業的******工具***試一下，現在最常用的是 NBSI 系列和 IPhacker IP ）
6)采用各種***檢查工具檢查系統***情況
7)采用各種防外掛工具檢查系統各組程序的外掛漏洞
數據庫安全考慮問題：
1）系統數據是否機密（比如對銀行系統，這一點就特別重要，一般的網站就沒有太高要求）
2）系統數據的完整性（我剛剛結束的企業實名核查服務系統中就曾存在數據 的不
3）完整，對于這個系統的功能實現有了障礙） 、系
4）統數據可管理性 、
5）系統數據的獨立性 、
6）系統數據可備份和恢復能力（數據備份是否完整，可否恢復，恢復是否可以完整）
10、什么是測試用例 什么是測試腳本 兩者的關系是什么？
用例：
未實施測試而編制的一組測試輸入、執行條件、各種環境設置以及預期結果以及期望結果的一個特定的集合。
腳本：
測試腳本是為了進行自動化測試而編寫的腳本。
測試腳本的編寫必須對應相應的測試用例
11、簡述什么是靜態測試、動態測試、黑盒測試、白盒測試、α測試 β測試
靜態測試：是不運行程序本身而尋找程序代碼中可能存在的錯誤或評估程序代碼的過程。
動態測試：是實際運行被測程序，輸入相應的測試實例，檢查運行結果與預期結果的差異，判定執行結果是否符合要求，從而檢驗程序的正確性、可靠性和有效性，并分析系統運行效率和健壯性等性能。
黑盒測試：一般用來確認軟件功能的正確性和可操作性,目的是檢測軟件的各個功能是否能得以實現,把被測試的程序當作一個黑盒,不考慮其內部結構,在知道該程序的輸入和輸出之間的關系或程序功能的情況下,依靠軟件規格說明書來確定測試用例和推斷測試結果的正確性。
白盒測試：根據軟件內部的邏輯結構分析來進行測試,是基于代碼的測試，測試人員通過閱讀程序代碼或者通
過使用開發工具中的單步調試來判斷軟件的質量，一般黑盒測試由項目經理在程序員開發中來實現。
α測試：是由用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試，Alpha測試不能由程序員或測試員完成。
β測試：由軟件的一個或多個用戶在實際使用環境下進行的測試， 開發者通常不在測試現場，Beta測試不能由程序員或測試員完成。
12、軟件產品質量特性是什么?
功能性：適應性、準確性、互操作性、依從性、安全性。
可靠性：成熟性、容錯性、易恢復性。
可使用性：易理解性、易學習性、易操作性。
效率：時間特性、資源特性。
可維護性：易分析性、易變更性、穩定性、易測試性。
可移植性： 適應性、易安裝性、遵循性、易替換性
13、軟件測試的策略是什么?
軟件測試策略：在一定的軟件測試標準、測試規范的指導下，依據測試項目的特定環境約束而規定的軟件測試的原則、方式、方法的集合。
14、軟件測試分為幾個階段 各階段的測試策略和要求是什么?
測試過程會依次經歷單元測試、集成測試、系統測試、驗收測試四個主要階段
單元測試：是針對軟件設計的最小單位––程序模塊甚至代碼段進行正確性檢驗的測試工作，通常由開發人員進行。
集成測試：是將模塊按照設計要求組裝起來進行測試，主要目的是發現與接口有關的問題。由于在產品提交到測試部門前，產品開發小組都要進行聯合調試，因此在大部分企業中集成測試是由開發人員來完成的。
系統測試：是在集成測試通過后進行的，目的是充分運行系統，驗證各子系統是否都能正常工作并完成設計的要求。它主要由測試部門進行，是測試部門最大最重要的一個測試，對產品的質量有重大的影響。
驗收測試：以需求階段的《需求規格說明書》為驗收標準，測試時要求模擬實際用戶的運行環境。對于實際項
目可以和客戶共同進行，對于產品來說就是最后一次的系統測試。測試內容為對功能模塊的全面測試，尤其要進行文檔測試。
單元測試測試策略：
自頂向下的單元測試策略：比孤立單元測試的成本高很多，不是單元測試的一個好的選擇。
自底向上的單元測試策略：比較合理的單元測試策略，但測試周期較長。
孤立單元測試策略：最好的單元測試策略。
集成測試的測試策略：
大爆炸集成：適應于一個維護型項目或被測試系統較小
自頂向下集成：適應于產品控制結構比較清晰和穩定；高層接口變化較小；底層接口未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要盡早被驗證；希望盡早能看到產品的系統功能行為。
自底向上集成：適應于底層接口比較穩定；高層接口變化比較頻繁；底層組件較早被完成。
基于進度的集成
優點：具有較高的并行度；能夠有效縮短項目的開發進度。
缺點：樁和驅動工作量較大；有些接口測試不充分；有些測試重復和浪費。
系統測試的測試策略：
數據和數據庫完整性測試；功能測試；用戶界面測試；性能評測；負載測試；強度測試；容量測試；安全性和訪問控制測試；故障轉移和恢復測試；配置測試；安裝測試；加密測試；可用性測試；版本驗證測試；文檔測試
15、軟件測試各個階段通常完成什么工作？各個階段的結果文件是什么？包括什么內容？
單元測試階段：
各獨立單元模塊在與系統地其他部分相隔離的情況下進行測試，單元測試針對每一個程序模塊進行正確性校驗，檢查各個程序模塊是否正確地實現了規定的功能。生成單元測試報告，提交缺陷報告。
集成測試階段：
集成測試是在單元測試的基礎上，測試在將所有的軟件單元按照概要設計規格說明的要求組裝成模塊、子系統或系統的過程中各部分工作是否達到或實現相應技術指標及要求的活動。該階段生成集成測試報告，提交缺陷報告。
系統測試階段：
將通過確認測試的軟件，作為整個給予計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其他系統元素結合在一起，在實際運行環境下，對計算機系統進行全面的功能覆蓋。該階段需要提交測試總結和缺陷報告。
16、測試人員在軟件開發過程中的任務是什么？
1、盡可能早的找出系統中的Bug；
2、避免軟件開發過程中缺陷的出現；
3、衡量軟件的品質，保證系統的質量；
4、關注用戶的需求，并保證系統符合用戶需求。
總的目標是：確保軟件的質量。
17、在您以往的工作中，一條軟件缺陷（或者叫Bug）記錄都包含了哪些內容？如何提交高質量的軟件缺陷（Bug）記錄？
一條Bug記錄最基本應包含：
bug編號；
bug嚴重級別，優先級；
bug產生的模塊；
首先要有bug摘要，闡述bug大體的內容；
bug對應的版本；
bug詳細現象描述，包括一些截圖、錄像…等等；
bug出現時的測試環境，產生的條件即對應操作步驟；
高質量的Bug記錄：
1.通用UI要統一、準確
缺陷報告的UI要與測試的軟件UI保持一致，便于查找定位。
2.盡量使用業界慣用的表達術語和表達方法
使用業界慣用的表達術語和表達方法，保證表達準確，體現專業化。
3.每條缺陷報告只包括一個缺陷
每條缺陷報告只包括一個缺陷，可以使缺陷修正者迅速定位一個缺陷，集中精力每次只修正一個缺陷。校驗者每次只校驗一個缺陷是否已經正確修正。
4.不可重現的缺陷也要報告
首先缺陷報告必須展示重現缺陷的能力。不可重現的缺陷要盡力重現，若盡力之后仍不能重現，仍然要報告此缺陷，但在報告中要注明無法再現，缺陷出現的頻率。
5.明確指明缺陷類型
根據缺陷的現象，總結判斷缺陷的類型。例如，即功能缺陷、界面缺陷、數據缺陷，合理化建議。這是最常見的缺陷或缺陷類型，其他形式的缺陷或缺陷也從屬于其中某種形式。
6.明確指明缺陷嚴重等級和優先等級時刻明確嚴重等級和優先等級之間的差別。高嚴重問題可能
7.描述 (Description) ，簡潔、準確，完整，揭示缺陷實質，記錄缺陷或缺陷出現的位置描述要準確反映缺陷的本質內容，簡短明了。為了便于在軟件缺陷管理數據庫中尋找制定的測試缺陷，包含缺陷發生時的用戶界面（UI）是個良好的習慣。例如記錄對話框的標題、菜單、按鈕等控件的名稱。
8.短行之間使用自動數字序號，使用相同的字體、字號、行間距
短行之間使用自動數字序號，使用相同的字體、字號、行間距，可以保證各條記錄格式一致，做到規范專業。
9.每一個步驟盡量只記錄一個操作保證簡潔、條理井然，容易重復操作步驟。
10.確認步驟完整，準確，簡短
保證快速準確的重復缺陷，“完整”即沒有缺漏，“準確”即步驟正確，“簡短”即沒有多余的步驟。
11.根據缺陷，可選擇是否進行圖象捕捉
為了直觀的觀察缺陷或缺陷現象，通常需要附加缺陷或缺陷出現的界面，以圖片的形式作為附件附著在記錄的“附件”部分。為了節省空間，又能真實反映缺陷或缺陷本質，可以捕捉缺陷或缺陷產生時的全屏幕，活動窗口和局部區域。為了迅速定位、修正缺陷或缺陷位置，通常要求附加中文對照圖。
?附加必要的特殊文檔和個人建議和注解如果打開某個特殊的文檔而產生的缺陷或缺陷，則必須附加該文檔，從而可以迅速再現缺陷或缺陷。有時，為了使缺陷或缺陷修正者進一步明確缺陷或缺陷的表現，可以附加個人的修改建議或注解。
12.檢查拼寫和語法缺陷
在提交每條缺陷或缺陷之前，檢查拼寫和語法，確保內容正確，正確的描述缺陷。
13.盡量使用短語和短句，避免復雜句型句式軟件缺陷管理數據庫的目的是便于定位缺陷，因此，要求客觀的描述操作步驟，不需要修飾性的詞匯和復雜的句型，增強可讀性。
以上概括了報告測試缺陷的規范要求，隨著軟件的測試要求不同，測試者經過長期測試，積累了相應的測試經驗，將會逐漸養成良好的專業習慣，不斷補充新的規范書寫要求。此外，經常閱讀、學習其他測試工程師的測試缺陷報告，結合自己以前的測試缺陷報告進行對比和思考，可以不斷提高技巧。
14.缺陷描述內容
缺陷描述的內容可以包含缺陷操作步驟，實際結果和期望結果。操作步驟可以方便開發人員再現缺陷進行修正，有些開發的再現缺陷能力很差，雖然他明白你所指的缺陷，但就是無法再現特別是對系統不熟悉的新加入開發人員，介紹步驟可以方便他們再現。實際結果可以讓開發明白錯誤是什么，期望結果可以讓開發了解正確的結果應該是如何。
18、黑盒測試和白盒測試是軟件測試的兩種基本方法，請分別說明各自的優點和缺點？
黑盒測試的優點有：
比較簡單，不需要了解程序內部的代碼及實現；
與軟件的內部實現無關；
從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；
基于軟件開發文檔，所以也能知道軟件實現了文檔中的哪些功能；在做軟件自動化測試時較為方便。
黑盒測試的缺點有：
不可能覆蓋所有的代碼，覆蓋率較低，大概只能達到總代碼量的30%；自動化測試的復用性較低。
白盒測試的優點有：
幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質量，發現代碼中隱 藏的問題。
白盒測試的缺點有：
程序運行會有很多不同的路徑，不可能測試所有的運行路徑；
測試基于代碼，只能測試開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；系統龐大時，測試開銷會非常大。
19、如何測試一個紙杯？
功能度：用水杯裝水看漏不漏；水能不能被喝到
安全性：杯子有沒有毒或細菌
可靠性：杯子從不同高度落下的損壞程度
可移植性：杯子在不同的地方、溫度等環境下是否都可以正常使用
兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等
易用性：杯子是否燙手、是否有防滑措施、是否方便飲用
用戶文檔：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述
疲勞測試：將杯子盛上水（案例一）放24小時檢查泄漏時間和情況；盛上汽油（案例二）放24小時檢查泄漏時間和情況等
壓力測試：用根針并在針上面不斷加重量，看壓強多大時會穿透
20、黑盒測試的測試用例常見設計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設計工作中的應用。
1）等價類劃分：
等價類是指某個輸入域的子集合.在該子集合中,各個輸入數據對于揭露程序中的錯誤都是等效的.并合理地假定:測試某等價類的代表值就等于對這一類其它值的測試.因此,可以把全部輸入數據合理劃分為若干等價類,在每一個等價類中取一個數據作為測試的輸入條件,就可以用少量代表性的測試數據.取得較好的測試結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.
2）邊界值分析法：
是對等價類劃分方法的補充。測試工作經驗告訴我,大量的錯誤是發生在輸入或輸出范圍的邊界上,而不是發生在輸入輸出范圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測試的邊界情況.應當選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數據,而不是選取等價類中的典型值或任意值作為測試數據。
3）錯誤猜測法：
基于經驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法。錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模塊中常見的錯誤. 以前產品測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入數據和輸出數據為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作為測試用例。
4）因果圖方法：
前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯系, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多. 因此必須考慮采用一種適合于描述對于多種條件的組合,相應產生多個動作的形式來考慮設計測試用例。這就需要利用因果圖（邏輯模型）。因果圖方法最終生成的就是判定表.它適合于檢查程序輸入條件的各種組合情況。
5）正交表分析法：
可能因為大量的參數的組合而引起測試用例數量上的激增，同時，這些測試用例并沒有明顯的優先級上的差距，而測試人員又無法完成這么多數量的測試，就可以通過正交表來進行縮減一些用例，從而達到盡量少的用例覆蓋盡量大的范圍的可能性。
6）場景分析方法：
指根據用戶場景來模擬用戶的操作步驟，這個比較類似因果圖，但是可能執行的深度和可行性更好。
7）狀態圖法：
通過輸入條件和系統需求說明得到被測系統的所有狀態，通過輸入條件和狀態得出輸出條件；通過輸入條件、輸出條件和狀態得出被測系統的測試用例。
8）大綱法：
大綱法是一種著眼于需求的方法，為了列出各種測試條件，就將需求轉換為大綱的形式。大綱表示為樹狀結構，在根和每個葉子結點之間存在唯一的路徑。大綱中的每條路徑定義了一個特定的輸入條件集合，用于定義測試用例。樹中葉子的數目或大綱中的路徑給出了測試所有功能所需測試用例的大致數量。
part4
探討測試用例設計的六大思路
有這樣一個面試題：在一個Web測試頁面上，有一個輸入框，一個計數器（count）按鈕，用于計算一個文本字符串中字母a出現的個數。請設計一系列測試用例用以測試這個Web頁面。
有經驗的測試人員可能會問面試官，字母a區分大小寫嗎？只統計英文字母的a嗎？最長輸入字符是多少，最少輸入字符是多少？對輸入的字符類型是否有限制，是否會自動清除不符合要求的字符？
-
所以第一步應該是明確需求，然后我們才開始進行思考如何設計測試用例。 -
通常說來，我們考慮一個測試對象的時候至少從以下六方面來考慮： -
1.功能性 -
2.兼容性 -
3.易用性 -
4.可靠性 -
5.性能 -
6.安全 -
1.從功能方面考慮： -
輸入：" "（思路：什么都不輸入） -
輸入："null"（思路：特殊值） -
輸入："Aa"（思路：輸入字符既含大寫字符也有小寫） -
輸入："abc"（思路：以a開頭） -
輸入："cac"（思路：a在中間） -
輸入："aba"（思路：以a開頭，以a結尾） -
輸入：" ba"（思路：以空格開頭含a） -
輸入："中ba"（思路：以中文或者其他字符開頭含a） -
輸入："AAaa"（思路：輸入字符僅僅只有大寫A和小寫a） -
輸入："全角和半角a"（思路：考慮半角和全角符號） -
2.從兼容性方面考慮： -
1.各個瀏覽器 顯示是否正確，點擊按鈕是否有效； -
2.瀏覽器各個版本顯示是否正確，點擊按鈕是否有效； -
3.是否支持手機端和平板端。 -
3.從易用性方面考慮： -
1.web界面外觀，風格是否合適； -
2.文本輸入框長度是否合適，是否應該默認提示如何輸入； -
3.輸入錯誤時提示是否友好； -
4.考慮該應用是否支持其他語言。 -
4.從可靠性和性能方面考慮： -
1.輸入HTML和JavaScript相關標簽字符，計算是否正確，是否會破壞頁面； -
2.這個應用能否在同一臺服務器上運行多個實例，多個用戶同時使用是否會有問題； -
3.在大并發下使用，計算速度是否滿足要求。 -
5.從安全性方面考慮： -
1.輸入的數據是否會被保存，輸入字符串可能包含敏感信息； -
2.嘗試復制/粘貼字符串； -
3.嘗試快速點擊多次計算按鈕； -
4.考慮是否有安全漏洞，點擊計算按鈕，請求是否會被截取，導致返回失敗。
part5
1、金融軟件測試面試題目有哪些？
網上銀行轉賬是怎么測的，設計一下測試用例。
回答思路：
宏觀上可以從質量模型（萬能公式）來考慮，重點需要測試轉賬的功能、性能與安全性。設計測試用例可以使用場景法為主，先列出轉賬的基本流和備選流。然后設計場景，最后根據場景設計數據。實際面試中需要舉出具體的例子。
先檢查界面。
再測試功能，
驗證同行轉賬，跨行轉賬。
驗證轉賬限額。
驗證非法賬戶（掛失，凍結，鎖定的賬戶）的轉賬。
再測試性能方面的。
測試工作的流程?缺陷狀態有什么?設計測試用例有幾種方法？
測試工程師的實際工作流程（以P2P中型版本為例，一個月一個版本）：
產品經理或者SR把需求書發下來給開發和測試
測試先看一遍，進行需求分析。測試組長編寫測試計劃，并且分配測試任務給測試人員（2天時間）（此時開發也在進行需求分析）
過了2天，產品經理再把測試和開發召集在一起，進行需求講解（或者說需求評審），有問題可以直接問，如果發現需求有問題，也可以提出來，SR回去會修改。（需求講解時間0.5天）
講完需求后，測試同事要進行測試場景的梳理和案例的編寫了（xmind和Excel就要用上了），一共5個工作日。（此時開發在編寫代碼）
之后就要進行案例評審了，評審時候有SR、測試同事、開發同事，評審時候一般SR、測試組長、對應模塊的開發同事會提出一點意見，評審完之后，回去修改、補充一下案例。（案例評審0.5天）
修改完以后，有兩種處理情況：
對大項目有時候要進行案例的第二次評審。
對小項目，在時間緊的時候，一般不會二審，但是要以郵件的形式把修改或者新增后的案例發出來，給領導看，并抄送給其他同事。（案例評審0.5天，修改案例0.5天，案例二審0.5天）
案例評審完就要開始測試了，一般測試環境開發搭建好（要說自己也會搭建，搭建流程背老師總結的）：
中型版本的測試一般分2輪：第一輪：5天；第二輪：3天；回歸測試2天；（共10個工作日）。
回歸測試完后，達到了上線標準，就會如期上線，一般當天晚上12點上線
缺陷狀態：缺陷管理的流程圖
2、在項目中找到的經典BUG是什么？
兼容性問題，在ie瀏覽器，提交訂單按鈕可以點擊，到了谷歌，火狐就不能了。
查詢訂單頁面，根據條件篩選的結果不是想要的結果，還有某些字段的值沒有顯示出來，或者顯示錯誤。（因為開發從庫表取值有誤）
付款成功后，訂單狀態一直不翻轉為交易成功。（因為代碼沒有正確獲取庫表中付款成功記錄的狀態碼）
修改支付密碼，新密碼和原密碼一致，也通過了，系統沒有做新舊密碼的校驗。
付款時候的手機驗證碼，可以一直使用，沒有成功做有效期控制。
手機app斷開網絡后，再去點擊，沒有友好的錯誤頁面提示網絡已斷開，只有undefined返回
3、定期存款到期自動轉存該怎么測？
回答思路：到期肯定會有邊界，所以設計里面可以考慮邊界值法。自動轉存（首先要搞清楚什么是自動轉存。）
4、存錢該怎么測，用什么測試方法？
準備思路：存錢要分類：活期、零存整取等（具體規則百度下），然后根據每類的業務規則選擇合適的用例設計方法。譬如一次最少存入多少？最多一次能存入多少等。
5、你發現Bug后，應該怎么辦？
首先咨詢一下開發是不是bug，讓他初步判斷一下。
如果不是bug，開發給到理由也比較充分，確實自己也搞錯了，也就算了。
如果開發也認為是bug，那就直接提了。
如果我懷疑開發的解答，我覺得是bug，開發堅持不是bug，我就要咨詢我們組長或者開發組長，讓他們判斷一下。
6、假如發現了一個BUG，跟開發本身沒什么關系，涉及到理念，需求問題，如何解決？
把問題暴露給測試組長和開發組長，咨詢他們意見，組長們再知會開發分組經理和項目經理，然后大家和產品經理一起探討解決，需要改需求的地方就要改了。
7、測試非常緊急過程中，遇到阻塞性問題，對應的開發沒有時間解決，你如何推動問題解決？
首先判斷問題的嚴重性，向對應的開發了解問題的原因。
然后再匯報給自己的測試組長和開發組長，讓組長知情，咨詢他們的意見，再把問題匯報給開發分組經理，讓他們統一協調處理。安排經驗豐富的其他高級開發人員來協助此開發解決問題，然后通過加班來完成問題解決和測試。
8、功能測試的BUG級別你們怎么劃分？
bug嚴重程度：一般提L4 和L3，L2很少提，除非影響流程。L1這個是非常致命的bug，基本上不會提。
9、執行別人的用例，如果發現用例有錯怎么處理？
首先咨詢一下案例作者或者詢問測試組長，確認一下，如果確實有誤就要修正用例。
10、你們做過冒煙側嗎？冒煙測試是什么（理論）？
冒煙測試也叫預測試，就是正式測試之前的一種測試，為了確保主流程能走通。
可以回答沒有冒煙測試，就說測試之前一般會要求開發自測，開發自測后（自測大概就是一天左右的時間），確保沒有大的問題，再通知測試開始測試。
11、你們項目做了多久，共寫了多少用例？項目多少人？
項目做了多久：（兩種回答，建議選擇第一種）
我進去的時候項目已經上線了，一直存在，然后就是版本的微小更新，小修改的話，大概半個月一個版本，中修改的話，大概一個月一個版本。每次版本更新，針對新的功能點或者修改點大概寫了60條案例左右（一個月一個版本的例子）。
我進去的時候，一開始就參與這個項目（也就是需求分析開始），項目從零到有進行了半年左右，六個月內大概整個項目組寫了900條案例左右。自己寫了200條左右(共5個測試，包括組長)。
PS:如果大家說自己是從零到有參與的項目，那么6個月時間是從需求分析開始。需求書編寫完成前，產品經理他們是要做很多前期準備工作，可能要花費3個月左右的時間。
那么測試6個月的實際工作時間內：
前期2個月：剛開始需求書的漏洞比較多，需求評審比較多，基本上每個星期一次評審。開發和測試都會參與，此時開發在進行代碼設計，測試就在分析需求，看參考文檔，用xmind梳理測試場景，提取測試點，開發經常和產品經理討論需求，測試經常問開發和產品經理有關需求的疑問。大家一直碰撞，一步一步得出比較完美的邏輯。
中間2個月：開發設計完后，進行編碼，我們測試就根據之前梳理的測試場景來編寫案例，進一步優化。這個期間，需求書基本穩定，不會再改了。要改也就是把細化需求，把籠統的地方，描述的更詳細，更讓人易懂，功能點的大方向不會改。開發和測試在此期間有疑問，都會郵件或者電話聯系產品經理。測試也會經常去問開發有關功能點的邏輯問題。
后面2個月： 執行案例工作開始進行，一般分為兩輪st測試，第一輪1個月，第二輪半個月，回歸測試半個月。Uat測試組在st測試第二輪時候，并行開始。Uat測試組有專門人負責，一般需要st測試組派一個人左右去支持，uat測試也有第一輪（半個月），第二輪（半個月）。
項目多少人：一個公司往往有很多項目，自己只是其中一個項目組的，我的P2P項目組大概20人，開發15個，測試5個。（大家把自己當成外包人員，在甲方工作，也叫駐場工作）
12、假如要你測試6個月期限的p2p借款產品，你應該怎么設計案例，說出測試點
（回答思路：1站在用戶的角度測試，用戶怎么用，你就怎么測試。2 一個人扮演多種角色測試。 3多想出一些異常場景。）
借款產品投標結束日T+7時，滿標和不滿標的情況。
借款產品投標結束日T+7前，產品提前滿標情況
產品成立后，每個月還款日前，檢查系統有沒有發出郵件，短信，站內信通知借款人充值到平臺賬戶。
在每月還款日，借款人充值用來還款時，充值資金足夠、不足夠、不充值情況，查看系統如何處理。充值資金不足或者沒有充值時，系統應該有罰息。
借款人提前還清余款場景，有些產品不支持提前還款，有些產品要滿一定期限才可以提前還款（提前還款有一定手續費）。這些都是要關注的測試點。（自己要扮演借款用戶去操作提前還清余款，然后扮演后臺管理員去審核，然后又扮演投資人用戶去檢查虛擬賬戶的資金到賬情況）
最后一期借款人還清資金時，去后臺頁面查看借款產品狀態，應該已正常結束。再去前臺頁面搜索，應該無該借款產品了。 （或者補充說：去數據庫里查看此借款產品的狀態）
13、你們這個P2P上線了嗎？能查嗎？項目花了多久時間，預計多久完成？
回答：兩種方案：
還沒上線，查不了，這個是新項目，計劃半年時間完成，但是因為中途有出現一些問題沒有解決完畢，所以現在還沒有在預計時間內完成。
大家寫的項目名在網上確實能查出來，就說上線了，能查到的。（面試官其實不一定會去查）
14、實名認證你們是怎么測得？調取什么平臺的資料？
實名認證接口：
銀行卡實名認證（調用銀行接口，驗證卡號，姓名，身份證號碼，手機號碼。需要利用到手機接收到的驗證碼）
身份證實名認證（全國公民身份證號碼查詢服務中心，或者直接說公安接口）
15、注冊需要實名認證嗎？
注冊不需要實名認證：當購物時候需要實名認證。
16、P2P你們也測試后臺管理嗎？個人芝麻信用積分是調取哪里的資料？
測試后臺管理：
后臺也測，但是我主要測試前臺，我的關注點是前臺，后臺只是拿來用，能配合前臺正常走完流程就行。后臺主要對前臺進行管理，主要有貸款管理，資金管理。
貸款管理：
可以查看投資人的投資情況，也可以查看借款人的借款產品，對借款產品進行管理。比如審批，每期的還款提醒，預警等。
資金管理：
管理查看用戶的充值，審批用戶的提現過程。
芝麻信用積分：
調用的是支付寶的接口，芝麻信用：調用的是支付寶那邊的接口（支付寶提供這樣的芝麻信用服務，每查一次收取大概0.1元）
17、如果要測試后臺刪除用戶，就是用戶名后面一個刪除按鈕的情況，能寫出哪些測試用例？
刪除一個用戶的場景：點擊刪除按鈕，頁面自動刷新，此用戶在該頁面已查詢不到。再去打開另外一個瀏覽器，在前臺登錄已刪除的用戶，頁面提示該用戶不存在。
同時刪除多個用戶的場景：利用復選框，測試多選，反選，全選刪除用戶的情況。刪除后，被刪用戶在該頁面已查詢不到，同樣要去前臺登錄已刪除的用戶，頁面應該提示該用戶不存在。
18、如果京東有一個購物網頁給你，你要怎么進行測試？測試哪些主要功能？
首先進行需求分析，用xmind梳理測試點，再編寫案例，之后就行案例評審，尋求他人意見。之后再完善案例，發出來給其他人檢查。
測試點，首先是UI方面：美觀度，和易操作型，易理解性型方面進行測試。
然后再考慮他的功能點，注冊登錄，添加購物車，下單，付款，發貨，確認收貨，評價。還有支付時候的綁定銀行卡，實名認證
性能方面：打開網頁，確認訂單、付款的響應時間等等。
兼容性：支持各種主流瀏覽器，ie，360，火狐，谷歌等。
19、針對添加購物車這個測試點說一下你要怎么測試“添加購物車”
（增刪改查的角度）
能否加入購物車，同一件商品能否再次添加到購物車。
購物車商品件數的上限限制（淘寶限制100件）
購物車是否可以正常移除商品，移除商品后，能否再添加回來。
添加的每種商品是否可以正常增減數量，數量大于0
退出購物車，再去查詢購物車，商品正常。
購物車的商品可以全選，取消全選，可以復選，選中的商品和數量可以正常下單。
商品添加到購物車以后，已下架。購物車會提示此寶貝已失效。
商品添加到購物車以后，降價了，購物車會有降價提示。
商品添加到購物車以后，庫存不足了。
20、P2P功能測試你們一般做幾輪？
中型版本（大修改，一個月上線一次）：測試一般分2輪：第一輪：5天；第二輪：3天；回歸測試2天；（共10個工作日）。（一個月工作日22天，需求分析評審，編寫測試用例等等一般占用整個版本時間的一半，或者少個幾天）
小型版本（小修改，兩個星期一次）：一輪測試3天，回歸測試2天。
21、你們每次開會討論的時候十幾個開發都去開會了嗎？
案例評審會：一般開發和測試、產品經理都會到場。（開發分組經理可能也會去）需求評審會：項目經理、開發分組經理、產品經理、測試、開發一般都會到。
如果是我們測試小組開會，一般都要到，各位測試同事報告自己的心得體會，匯報自己的進度和問題。
22、數據庫查找兩個表
回答思路：
多表查詢，后面具體會學到：select 列1，列2 from 表1,表2 where 表1.列=表2.列 這樣的格式要能說出來。
23、熟悉數據庫嗎？平時數據庫用的多嗎？
熟悉數據庫嗎：比較熟，比如DML語句有增刪改查：（有序思維說出來）
1 insert into 表名 values（值1，值2，值3，…）
2 delete from 表名 where 條件
3 update 表名 set 列名 = 新值
4 select * from 表名
查詢語句最長的是 select * from 表名 where 條件 group by 分組列名 having 分組后的條件 order by 列名。
平時數據庫用的多嗎（大概測試過程的1/4時間在查數據庫）：還行，一般出現問題，遇到bug，就要去查詢數據庫，初步定為問題。開發會給到我們一個庫表設計的excel（數據字典），里面有描述表名和表中的字段，我把交易過程的一些唯一標識，把他作為where條件去查詢數據。初步分析后，再把問題暴露給開發。（比如淘寶支付時，輸入支付密碼后，已經返回了支付成功的提示信息，然后界面上的訂單查詢還是待付款，這個時候就要去查詢訂單表的數據，找到自己剛才做的交易的那一筆訂單，去分析一下錯誤，再暴露給開發）
24、linux查看文件用什么命令，查看進程用什么命令？
回答：
查看文件內容的命令有 more less head tail cat tac
查看進程：ps -ef | grep 進程號
查看日志文件常用:less、view
查看日志常用什么命令，主要查看什么內容
查看日志常用less命令或者view命令。
主要查看程序運行的記錄，比如支付失敗，后臺就有報錯信息打印到.log日志文件中，就可以通過分析日志信息來初步定為問題。（補充：同時也去查詢數據庫，分析訂單數據，查看支付狀態等等）
PS:日志就是.log的文本文件，和.txt一樣屬于文本文件。vi或者vim編輯器屬于記事本軟件，一般不會用來查看日志。
25、如何查找a.log日志文件的error字符串？
第一種方式：（建議說第一種方式）
cat a.log | grep error;
第二種方式：
1 less a.log;
2 /error;
你所熟悉的linux命令
linux：cat,more,less,head -n，tail -n，find ,| grep,ps -ef,tar,gzip,mv,cp,touch,mkdir，vi,top
也可以結合搭建環境的過程說用到的命令。
26、如果領導分配你的任務超出負荷，領導高估了你的能力，怎么辦？
回答思路：
首先表達態度，態度上愿意通過加班來完成，還可以請求測試同事支援，讓組長協調。
高估了能力，能力可以在工作中通過自己的努力來達到領導的要求
總而言之基本的思路是態度要端正。
不能直接拒絕任務。但也同時表達萬一做不好還請領導包容。
27、假設你是組長，團隊中有一個員工無法按時完成交付的任務，你如何處理？
回答思路：
首先先檢討自己是否任務安排超過了這個員工的能力。
如果沒有超過，首先表示關心身體和狀態，了解未及時完成任務的原因，如果原因是客觀原因則一起加班跟員工來完成任務。
如果是態度原因，則指出利害關系，責令其通過加班來完成。
28、如果因為你的錯誤導致工作發生問題，你怎么辦？
回答思路：
首先要表達在過去的工作中從未發生過類似事情，因為自己工作態度還是很端正的。
萬一因為自己的錯誤導致工作發生問題，首先應該把問題上報給領導，爭取把問題的影響降到最低程度。
29、給你一個模塊測試，只有一個星期的時間你如何有效率地完成？
答：在有限的時間里，明確需求的情況下，制定工作計劃，把每天任務細分，先保證重要功能，跟進修復情況，及時驗證bug。每天發工作日報，匯報進度，如果遇到風險，及時匯報領導。
30、如果給你一個沒有需求的app測試項目，你應該怎么測？
建議：根據APP的 11大測試點；
權限測試
安裝、運行、卸載測試
UI測試
功能測試
性能測試
中斷測試
兼容測試
安全測試
回歸測試
升級更新測試
用戶體驗測試
補充：根據自己的經驗，制定測試計劃，每天匯報自己的進度，發出測試日報。
測試過程有問題，及時上報，及時跟進bug，多和開發交流溝通，明確需求。
21、如果你和開發的意見產生分歧，你怎么處理？
回答思路：
大的原則是對事不對人。
另外我會首先嘗試站在開發的角度接受對方的意見和建議，同時控制好自己的情緒，在對方情緒可控的情況下表達自己的意見。
32、如果你組長的用例寫錯了，但他認為是對的，你怎么處理？
回答：
通常情況下，領導看問題的角度會比我們更全面，所以我首先得確保領導的用例是否真的有考慮不到的地方。
我不會堅持自己的是對的，但會在合理的情況下表達自己的觀點。
33、你同時負責功能和性能，你怎么做？
先測成功能，保證功能的完成，再做性能，在提交bug后，開發還沒改好時，可以準備性能測試，在工作時間很緊的情況下會主動加班
34、我們公司自動化測試用的語言是Java，Java你不會，該怎么辦？
回答思路：
問到不會的標準思路：要么說會一點相關的內容，要么表達自己有不錯的學習能力和很好的學習意愿和態度。
我們學了Java了就說會，知道面向對象的封裝，繼承，多態，知道多線程的兩種創建方式（自定義子類繼承Thread類，或者自定義子類實現Runable接口），還知道異常Throwable，Exception的格式，try catch finally。知道List， Set，Map集合。我可以很快的學會用Java做自動化。
35、以前的項目是怎么管理的？
回答思路：
我們以前的項目是用禪道來做測試的需求管理、用例管理、缺陷管理的。另外版本管理工具使用的是SVN。
36、以前的項目每天需要執行多少用例？
回答思路：
正常情況一般每天執行20個左右的用例，剛開始測試的時候，bug比較多，需要很多時間和開發交流溝通
案例執行會比較慢。越到后面就越快了。
37、你們做回歸測試的時候是否全部都做呢？
看時間，如果時間比較充足，會全部回歸，回歸時候因為自己操作比較熟練，然后系統基本上也沒有bug。所以執行案例的速度會比較快。
如果時間比較緊，就會挑選重要模塊來回歸測試了。
PS:自己組織好語言。
38、你們怎么確保用例覆蓋率？確保不重復？
利用判定表法的思想，先窮舉，再挑代表。
然后，案例評審時候產品經理、開發組長、測試組長，還有對應模塊的開發負責人也會把關，可以咨詢他們意見，確保案例即覆蓋完全，又沒有多余的重復案例。
我整理了一波之前發布的軟件測試資源【點擊文末小卡片免費領取】，無套路領取！
基本涵蓋了軟件測試 的全部核心技術點：測試理論，Linux 基礎，MySQL 基礎，Web 測試，接口測試，App 測試，管理工具，Selenium 相關，性能測試，計算機網絡，組成原理，數據結構與算法，邏輯題，人力資源，技術腦圖等等…質量非常高！！！應對技術面試綽綽有余！
39、你們案例是怎么評審的？
評審時候有產品經理（SR）、測試同事、開發同事，評審時候一般產品經理（SR）、測試組長、對應模塊的開發同事會提出一點意見，評審完之后，回去修改、補充一下案例。
修改完以后，有兩種處理情況：
對大項目有時候要進行案例的第二次評審。
對小項目，在時間緊的時候，一般不會二審，但是要以郵件的形式把修改或者新增后的案例發出來，給領導看，并抄送給其他同事。（案例評審0.5天，修改案例0.5天，案例二審0.5天）。
40、視圖是什么?
視圖記錄了一條SQL語句，當查詢時才有數據返回。表就是一張具體的表。視圖只能查詢數據，表可以增刪改查。
人力面試
1、為什么轉做測試
回答思路：
大學就通過互聯網了解軟件測試，了解IT，自己也比較喜歡，然后也選修了C語言或者Java語言來學。
在大四之前的暑假，在松勤培訓過軟件測試。
2、加班出差能接受嗎，加班能接受嗎?
回答思路：
通常如果這個問題被問題，是絕對不能直接說不接受的，能接受出差，還沒有男/女朋友。
搞IT一般都要加班，我以前也是這么加的，沒問題。
站在自己的角度說：還年輕，希望能在短時間內提高自己的能力和積累更豐富的經驗，加班是沒有問題的。
3、說說你自己與眾不同的地方和性格上的缺陷以及你準備如何改善？
回答思路：
其實這個問題就是回答優缺點。
性格本身是一種習慣，說以你應該表示通過優化自己的行為習慣來改變自己的缺點。
向身邊的榜樣學習，就是學最好的別人，做最完美的自己。
4、在學校時參加過社團嗎、當過最高的職位，會協調嗎？
回答：
如果有就更好，這個能夠體現自己的協調能力、組織能力、溝通能力。這些對于工作很重要。要講一兩件具體的事情，把能力通過事情體現出來。
5、領導和追隨者你認為自己適合哪個？
回答：
領導是帶領和指導，一般通用的回答要是領導，因為自己可以以身作則，技術上也能對下屬有一定的指導能力。
6、以往工作經驗
回答：
在忙碌的工作當中，既充實，又有成就感。通過不斷的測試，我的溝通能力、協調能力得到了提高，同時還收獲了行業知識經驗等，深刻感受到了團體精神的重要性。
8、為什么要從事軟件測試？
回答：
自己非常喜歡互聯網，喜歡it，我覺得這一行非常有前景，馬云說現在已經世界已經進入第三次工業革命了，就是信息技術革命。計算機發展速度很快，互聯網公司可以利用短短幾年時間到達傳統行業過去要幾十年才能達到的境界。
9、過去工作中最有成就的事情是什么？
回答思路：
基本原則是要謙卑，談不上最有成就的事情。
如果非得要說有的話從某一件事情上收獲頗多，克服了什么樣的困哪等。
10、試用期、轉正期望工資多少？
回答思路：
首先要說其實工資不是最關鍵的，然后給一個500元范圍浮動的值
一線城市工資應屆生最低6000，畢業一年7000，畢業兩年8000，畢業三年9000以上。小編給的是最低標準，大家看根據自己學習情況，適當調整，比如學的不錯的同學，兩年工作經驗提10000沒有問題的。
如果問你上一家公司工資多少，就說出比你現在期望工資少個500元的值。
總結：
感謝每一個認真閱讀我文章的人！！！
作為一位過來人也是希望大家少走一些彎路，如果你不想再體驗一次學習時找不到資料，沒人解答問題，堅持幾天便放棄的感受的話，在這里我給大家分享一些自動化測試的學習資源，希望能給你前進的路上帶來幫助。
軟件測試面試文檔
我們學習必然是為了找到高薪的工作，下面這些面試題是來自阿里、騰訊、字節等一線互聯網大廠最新的面試資料，并且有字節大佬給出了權威的解答，刷完這一套面試資料相信大家都能找到滿意的工作。
?
? ? ? ? ? 視頻文檔獲取方式：
這份文檔和視頻資料，對于想從事【軟件測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！以上均可以分享，點下方小卡片即可自行領取。
