「純乾貨」軟體測試面試題（含答案），2022最強版！直通大廠

又是一波跳槽漲薪的時候到了，大家找工作的需求比較高，想找軟體測試工作，面試筆試你準備好了嗎，今天給大家分享這套包含很多大廠，比如阿里，百度，位元組，騰訊，京東這些大廠的面試真題（包含答案）

ps：文章篇幅較長，需要PDF版的朋友關注+私信【軟體測試】

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技術，用通用瀏覽器就實現了原來需要複雜專用軟體才能實現的強大功能，並節約了開發成本，是一種全新的軟體系統構造技術。

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記錄：

通用UI要統一、準確

缺陷報告的UI要與測試的軟體UI保持一致，便於查詢定位。

儘量使用業界慣用的表達術語和表達方法

使用業界慣用的表達術語和表達方法，保證表達準確，體現專業化。

每條缺陷報告只包括一個缺陷

每條缺陷報告只包括一個缺陷，可以使缺陷修正者迅速定位一個缺陷，集中精力每次只修正一個缺陷。校驗者每次只校驗一個缺陷是否已經正確修正。

不可重現的缺陷也要報告

首先缺陷報告必須展示重現缺陷的能力。不可重現的缺陷要盡力重現，若盡力之後仍不能重現，仍然要報告此缺陷，但在報告中要註明無法再現，缺陷出現的頻率。

明確指明缺陷型別

根據缺陷的現象，總結判斷缺陷的型別。例如，即功能缺陷、介面缺陷、資料缺陷，合理化建議。這是最常見的缺陷或缺陷型別，其他形式的缺陷或缺陷也從屬於其中某種形式。

明確指明缺陷嚴重等級和優先等級時刻明確嚴重等級和優先等級之間的差別。高嚴重問題可能

描述 （Description） ，簡潔、準確，完整，揭示缺陷實質，記錄缺陷或缺陷出現的位置描述要準確反映缺陷的本質內容，簡短明瞭。為了便於在軟體缺陷管理資料庫中尋找制定的測試缺陷，包含缺陷發生時的使用者介面（UI）是個良好的習慣。例如記錄對話方塊的標題、選單、按鈕等控制元件的名稱。

短行之間使用自動數字序號，使用相同的字型、字號、行間距

短行之間使用自動數字序號，使用相同的字型、字號、行間距，可以保證各條記錄格式一致，做到規範專業。

每一個步驟儘量只記錄一個操作保證簡潔、條理井然，容易重複操作步驟。

確認步驟完整，準確，簡短

保證快速準確的重複缺陷，“完整”即沒有缺漏，“準確”即步驟正確，“簡短”即沒有多餘的步驟。

根據缺陷，可選擇是否進行圖象捕捉

為了直觀的觀察缺陷或缺陷現象，通常需要附加缺陷或缺陷出現的介面，以圖片的形式作為附件附著在記錄的“附件”部分。為了節省空間，又能真實反映缺陷或缺陷本質，可以捕捉缺陷或缺陷產生時的全螢幕，活動視窗和區域性區域。為了迅速定位、修正缺陷或缺陷位置，通常要求附加中文對照圖。

附加必要的特殊文件和個人建議和註解如果開啟某個特殊的文件而產生的缺陷或缺陷，則必須附加該文件，從而可以迅速再現缺陷或缺陷。有時，為了使缺陷或缺陷修正者進一步明確缺陷或缺陷的表現，可以附加個人的修改建議或註解。

檢查拼寫和語法缺陷

在提交每條缺陷或缺陷之前，檢查拼寫和語法，確保內容正確，正確的描述缺陷。

儘量使用短語和短句，避免複雜句型句式軟體缺陷管理資料庫的目的是便於定位缺陷，因此，要求客觀的描述操作步驟，不需要修飾性的詞彙和複雜的句型，增強可讀性。

以上概括了報告測試缺陷的規範要求，隨著軟體的測試要求不同，測試者經過長期測試，積累了相應的測試經驗，將會逐漸養成良好的專業習慣，不斷補充新的規範書寫要求。此外，經常閱讀、學習其他測試工程師的測試缺陷報告，結合自己以前的測試缺陷報告進行對比和思考，可以不斷提高技巧。

缺陷描述內容

缺陷描述的內容可以包含缺陷操作步驟，實際結果和期望結果。操作步驟可以方便開發人員再現缺陷進行修正，有些開發的再現缺陷能力很差，雖然他明白你所指的缺陷，但就是無法再現特別是對系統不熟悉的新加入開發人員，介紹步驟可以方便他們再現。實際結果可以讓開發明白錯誤是什麼，期望結果可以讓開發瞭解正確的結果應該是如何。

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

金融軟體測試面試題目有哪些

網上銀行轉賬是怎麼測的，設計一下測試用例。

回答思路：

宏觀上可以從質量模型（萬能公式）來考慮，重點需要測試轉賬的功能、效能與安全性。設計測試用例可以使用場景法為主，先列出轉賬的基本流和備選流。然後設計場景，最後根據場景設計資料。實際面試中需要舉出具體的例子。

先檢查介面。

再測試功能：

驗證同行轉賬，跨行轉賬。

驗證轉賬限額。

驗證非法賬戶（掛失，凍結，鎖定的賬戶）的轉賬。

再測試效能方面的。

測試工作的流程？缺陷狀態有什麼？設計測試用例有幾種方法？

測試工程師的實際工作流程（以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點上線

缺陷狀態：缺陷管理的流程圖

在專案中找到的經典BUG是什麼？

相容性問題，在ie瀏覽器，提交訂單按鈕可以點選，到了谷歌，火狐就不能了。

查詢訂單頁面，根據條件篩選的結果不是想要的結果，還有某些欄位的值沒有顯示出來，或者顯示錯誤。（因為開發從庫表取值有誤）

付款成功後，訂單狀態一直不翻轉為交易成功。（因為程式碼沒有正確獲取庫表中付款成功記錄的狀態碼）

修改支付密碼，新密碼和原密碼一致，也通過了，系統沒有做新舊密碼的校驗。

付款時候的手機驗證碼，可以一直使用，沒有成功做有效期控制。

手機app斷開網路後，再去點選，沒有友好的錯誤頁面提示網路已斷開，只有undefined返回

定期存款到期自動轉存該怎麼測？

回答思路：到期肯定會有邊界，所以設計裡面可以考慮邊界值法。自動轉存（首先要搞清楚什麼是自動轉存。）

存錢該怎麼測，用什麼測試方法？

準備思路：存錢要分類：活期、零存整取等（具體規則百度下），然後根據每類的業務規則選擇合適的用例設計方法。譬如一次最少存入多少？最多一次能存入多少等。

你發現Bug後，應該怎麼辦？

首先諮詢一下開發是不是bug，讓他初步判斷一下。

如果不是bug，開發給到理由也比較充分，確實自己也搞錯了，也就算了。

如果開發也認為是bug，那就直接提了。

如果我懷疑開發的解答，我覺得是bug，開發堅持不是bug，我就要諮詢我們組長或者開發組長，讓他們判斷一下。

假如發現了一個BUG，跟開發本身沒什麼關係，涉及到理念，需求問題，如何解決？

把問題暴露給測試組長和開發組長，諮詢他們意見，組長們再知會開發分組經理和專案經理，然後大家和產品經理一起探討解決，需要改需求的地方就要改了。

測試非常緊急過程中，遇到阻塞性問題，對應的開發沒有時間解決，你如何推動問題解決？

首先判斷問題的嚴重性，向對應的開發瞭解問題的原因。

然後再彙報給自己的測試組長和開發組長，讓組長知情，諮詢他們的意見，再把問題彙報給開發分組經理，讓他們統一協調處理。安排經驗豐富的其他高階開發人員來協助此開發解決問題，然後透過加班來完成問題解決和測試。

功能測試的BUG級別你們怎麼劃分？

bug嚴重程度：一般提L4 和L3，L2很少提，除非影響流程。L1這個是非常致命的bug，基本上不會提。

執行別人的用例，如果發現用例有錯怎麼處理？

首先諮詢一下案例作者或者詢問測試組長，確認一下，如果確實有誤就要修正用例。

你們做過冒煙側嗎？冒煙測試是什麼（理論）？

冒煙測試也叫預測試，就是正式測試之前的一種測試，為了確保主流程能走通。

可以回答沒有冒煙測試，就說測試之前一般會要求開發自測，開發自測後（自測大概就是一天左右的時間），確保沒有大的問題，再通知測試開始測試。

你們專案做了多久，共寫了多少用例？專案多少人？

專案做了多久：（兩種回答，建議選擇第一種）

我進去的時候專案已經上線了，一直存在，然後就是版本的微小更新，小修改的話，大概半個月一個版本，中修改的話，大概一個月一個版本。每次版本更新，針對新的功能點或者修改點大概寫了60條案例左右（一個月一個版本的例子）。

我進去的時候，一開始就參與這個專案（也就是需求分析開始），專案從零到有進行了半年左右，六個月內大概整個專案組寫了900條案例左右。自己寫了200條左右（共5個測試，包括組長）。

PS:如果大家說自己是從零到有參與的專案，那麼6個月時間是從需求分析開始。需求書編寫完成前，產品經理他們是要做很多前期準備工作，可能要花費3個月左右的時間。

那麼測試6個月的實際工作時間內：

前期2個月：剛開始需求書的漏洞比較多，需求評審比較多，基本上每個星期一次評審。開發和測試都會參與，此時開發在進行程式碼設計，測試就在分析需求，看參考文件，用xmind梳理測試場景，提取測試點，開發經常和產品經理討論需求，測試經常問開發和產品經理有關需求的疑問。大家一直碰撞，一步一步得出比較完美的邏輯。

中間2個月：開發設計完後，進行編碼，我們測試就根據之前梳理的測試場景來編寫案例，進一步最佳化。這個期間，需求書基本穩定，不會再改了。要改也就是把細化需求，把籠統的地方，描述的更詳細，更讓人易懂，功能點的大方向不會改。開發和測試在此期間有疑問，都會郵件或者電話聯絡產品經理。測試也會經常去問開發有關功能點的邏輯問題。

後面2個月： 執行案例工作開始進行，一般分為兩輪st測試，第一輪1個月，第二輪半個月，迴歸測試半個月。Uat測試組在st測試第二輪時候，並行開始。Uat測試組有專門人負責，一般需要st測試組派一個人左右去支援，uat測試也有第一輪（半個月），第二輪（半個月）。

專案多少人：一個公司往往有很多專案，自己只是其中一個專案組的，我的P2P專案組大概20人，開發15個，測試5個。（大家把自己當成外包人員，在甲方工作，也叫駐場工作）

假如要你測試6個月期限的p2p借款產品，你應該怎麼設計案例，說出測試點

（回答思路：1站在使用者的角度測試，使用者怎麼用，你就怎麼測試。2 一個人扮演多種角色測試。 3多想出一些異常場景。）

借款產品投標結束日T+7時，滿標和不滿標的情況。

借款產品投標結束日T+7前，產品提前滿標情況

產品成立後，每個月還款日前，檢查系統有沒有發出郵件，簡訊，站內信通知借款人充值到平臺賬戶。

在每月還款日，借款人充值用來還款時，充值資金足夠、不足夠、不充值情況，檢視系統如何處理。充值資金不足或者沒有充值時，系統應該有罰息。

借款人提前還清餘款場景，有些產品不支援提前還款，有些產品要滿一定期限才可以提前還款（提前還款有一定手續費）。這些都是要關注的測試點。（自己要扮演借款使用者去操作提前還清餘款，然後扮演後臺管理員去稽核，然後又扮演投資人使用者去檢查虛擬賬戶的資金到賬情況）

最後一期借款人還清資金時，去後臺頁面檢視借款產品狀態，應該已正常結束。再去前臺頁面搜尋，應該無該借款產品了。 （或者補充說：去資料庫裡檢視此借款產品的狀態）

你們這個P2P上線了嗎？能查嗎？專案花了多久時間，預計多久完成？

回答：兩種方案：

還沒上線，查不了，這個是新專案，計劃半年時間完成，但是因為中途有出現一些問題沒有解決完畢，所以現在還沒有在預計時間內完成。

大家寫的專案名在網上確實能查出來，就說上線了，能查到的。（面試官其實不一定會去查）

實名認證你們是怎麼測得？調取什麼平臺的資料？

實名認證介面：

銀行卡實名認證（呼叫銀行介面，驗證卡號，姓名，身份證號碼，手機號碼。需要利用到手機接收到的驗證碼）

身份證實名認證（全國公民身份證號碼查詢服務中心，或者直接說公安介面）

註冊需要實名認證嗎？

註冊不需要實名認證：當購物時候需要實名認證。

P2P你們也測試後臺管理嗎？個人芝麻信用積分是調取哪裡的資料？

測試後臺管理：

後臺也測，但是我主要測試前臺，我的關注點是前臺，後臺只是拿來用，能配合前臺正常走完流程就行。

後臺主要對前臺進行管理，主要有貸款管理，資金管理。

貸款管理：可以檢視投資人的投資情況，也可以檢視借款人的借款產品，對借款產品進行管理。比如審批，每期的還款提醒，預警等。

資金管理：管理檢視使用者的充值，審批使用者的提現過程。

芝麻信用積分：呼叫的是支付寶的介面，芝麻信用：呼叫的是支付寶那邊的介面（支付寶提供這樣的芝麻信用服務，每查一次收取大概0。1元）

如果要測試後臺刪除使用者，就是使用者名稱後面一個刪除按鈕的情況，能寫出哪些測試用例

刪除一個使用者的場景：點選刪除按鈕，頁面自動重新整理，此使用者在該頁面已查詢不到。再去開啟另外一個瀏覽器，在前臺登入已刪除的使用者，頁面提示該使用者不存在。

同時刪除多個使用者的場景：利用複選框，測試多選，反選，全選刪除使用者的情況。刪除後，被刪使用者在該頁面已查詢不到，同樣要去前臺登入已刪除的使用者，頁面應該提示該使用者不存在。

如果京東有一個購物網頁給你，你要怎麼進行測試？測試哪些主要功能？

首先進行需求分析，用xmind梳理測試點，再編寫案例，之後就行案例評審，尋求他人意見。之後再完善案例，發出來給其他人檢查。

測試點，首先是UI方面：美觀度，和易操作型，易理解性型方面進行測試。

然後再考慮他的功能點，註冊登入，新增購物車，下單，付款，發貨，確認收貨，評價。還有支付時候的繫結銀行卡，實名認證

效能方面：開啟網頁，確認訂單、付款的響應時間等等。

相容性：支援各種主流瀏覽器，ie，360，火狐，谷歌等。

針對新增購物車這個測試點說一下你要怎麼測試“新增購物車”

（增刪改查的角度）

能否加入購物車，同一件商品能否再次新增到購物車。

購物車商品件數的上限限制（淘寶限制100件）

購物車是否可以正常移除商品，移除商品後，能否再添加回來。

新增的每種商品是否可以正常增減數量，數量大於0

退出購物車，再去查詢購物車，商品正常。

購物車的商品可以全選，取消全選，可以複選，選中的商品和數量可以正常下單。

商品新增到購物車以後，已下架。購物車會提示此寶貝已失效。

商品新增到購物車以後，降價了，購物車會有降價提示。

商品新增到購物車以後，庫存不足了。

P2P功能測試你們一般做幾輪？

答：

中型版本（大修改，一個月上線一次）：測試一般分2輪：第一輪：5天；第二輪：3天；迴歸測試2天；（共10個工作日）。（一個月工作日22天，需求分析評審，編寫測試用例等等一般佔用整個版本時間的一半，或者少個幾天）

小型版本（小修改，兩個星期一次）：一輪測試3天，迴歸測試2天。

你們每次開會討論的時候十幾個開發都去開會了嗎？

案例評審會：一般開發和測試、產品經理都會到場。（開發分組經理可能也會去）需求評審會：專案經理、開發分組經理、產品經理、測試、開發一般都會到。

如果是我們測試小組開會，一般都要到，各位測試同事報告自己的心得體會，彙報自己的進度和問題。

資料庫查詢兩個表

回答思路：

多表查詢，後面具體會學到：select 列1，列2 from 表1，表2 where 表1。列=表2。列 這樣的格式要能說出來。

熟悉資料庫嗎？平時資料庫用的多嗎？

熟悉資料庫嗎：比較熟，比如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條件去查詢資料。初步分析後，再把問題暴露給開發。（比如淘寶支付時，輸入支付密碼後，已經返回了支付成功的提示資訊，然後介面上的訂單查詢還是待付款，這個時候就要去查詢訂單表的資料，找到自己剛才做的交易的那一筆訂單，去分析一下錯誤，再暴露給開發）

linux檢視檔案用什麼命令，檢視程序用什麼命令

回答：

檢視檔案內容的命令有 more less head tail cat tac

檢視程序：ps -ef | grep 程序號

檢視日誌檔案常用：less、view

檢視日誌常用什麼命令，主要檢視什麼內容

檢視日誌常用less命令或者view命令。

主要檢視程式執行的記錄，比如支付失敗，後臺就有報錯資訊列印到。log日誌檔案中，就可以透過分析日誌資訊來初步定為問題。（補充：同時也去查詢資料庫，分析訂單資料，檢視支付狀態等等）

PS：日誌就是。log的文字檔案，和。txt一樣屬於文字檔案。vi或者vim編輯器屬於記事本軟體，一般不會用來檢視日誌。

如何查詢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

也可以結合搭建環境的過程說用到的命令。

你們測試用的測試環境是誰給的？linux怎麼搭建測試環境？

一般開發搭建，但是我也會，我之前自己搭建過一個小專案（松勤學員參考考試系統的搭建流程）

流程大概是：

首次搭建：

透過winscp上傳tomcat，MySQL安裝包，JDK（Java開發環境工具包）到linux下

利用tar -zxvf解壓縮包命令對jdk，tomcat，mysql進行解包、安裝，再配置jdk環境變數。

把war包（web程式）放到tomcate指定目錄webapps下，再啟動伺服器即可。（輸入startup。sh的路徑，直接回車即可執行）

非首次搭建：

把war包（web程式）放到tomcate指定目錄webapps下（已經存在web伺服器和資料庫伺服器的前提下），啟動伺服器即可。（輸入startup。sh的路徑，直接回車即可執行）

抓包工具使用：

就是開啟fiddler工具後，再去瀏覽器開啟網頁，fiddler會自動抓包，抓取請求響應資料。他會自動設定為本地代理，還可以設定抓取https協議的包。

如果要抓取手機訪問網際網路資料包，就要在手機上的網路設定裡，設定代理伺服器。就是把fiddler作為代理伺服器（fiddler自身要設定為支援遠端連線），手機連線fiddler工具，所以手機代理伺服器設定頁面要輸入開啟fiddler工具的電腦的ip地址和fiddler的埠號8888，好讓手機能連線fiddler，透過fiddler來訪問網際網路。

PS：瀏覽器都自帶抓包工具，F12快捷鍵可以呼叫此工具，開發經常利用此工具來分析頁面資料，透過分析頁面資料來定位程式問題。

金融行業知識你瞭解多少

把以下老師整理的理解記憶一下：

如果領導分配你的任務超出負荷，領導高估了你的能力，怎麼辦

回答思路：

首先表達態度，態度上願意透過加班來完成，還可以請求測試同事支援，讓組長協調。

高估了能力，能力可以在工作中透過自己的努力來達到領導的要求

總而言之基本的思路是態度要端正。

不能直接拒絕任務。但也同時表達萬一做不好還請領導包容。

假設你是組長，團隊中有一個員工無法按時完成交付的任務，你如何處理；

回答思路：

首先先檢討自己是否任務安排超過了這個員工的能力。

如果沒有超過，首先表示關心身體和狀態，瞭解未及時完成任務的原因，如果原因是客觀原因則一起加班跟員工來完成任務。

如果是態度原因，則指出利害關係，責令其透過加班來完成。

如果因為你的錯誤導致工作發生問題，你怎麼辦？

回答思路：

首先要表達在過去的工作中從未發生過類似事情，因為自己工作態度還是很端正的。

萬一因為自己的錯誤導致工作發生問題，首先應該把問題上報給領導，爭取把問題的影響降到最低程度。

給你一個模組測試，只有一個星期的時間你如何有效率地完成？

答：在有限的時間裡，明確需求的情況下，制定工作計劃，把每天任務細分，先保證重要功能，跟進修復情況，及時驗證bug。每天發工作日報，彙報進度，如果遇到風險，及時彙報領導。

如果給你一個沒有需求的app測試專案，你應該怎麼測

老師建議：根據APP的 11大測試點：

許可權測試

安裝、執行、解除安裝測試

UI測試

功能測試

效能測試

中斷測試

相容測試

安全測試

迴歸測試

升級更新測試

使用者體驗測試

補充：根據自己的經驗，制定測試計劃，每天彙報自己的進度，發出測試日報。

測試過程有問題，及時上報，及時跟進bug，多和開發交流溝通，明確需求。

如果你和開發的意見產生分歧，你怎麼處理？

回答思路：

大的原則是對事不對人。

另外我會首先嚐試站在開發的角度接受對方的意見和建議，同時控制好自己的情緒，在對方情緒可控的情況下表達自己的意見。

如果你組長的用例寫錯了，但他認為是對的，你怎麼處理？

回答：

通常情況下，領導看問題的角度會比我們更全面，所以我首先得確保領導的用例是否真的有考慮不到的地方。

我不會堅持自己的是對的，但會在合理的情況下表達自己的觀點。

你同時負責功能和效能，你怎麼做

先測成功能，保證功能的完成，再做效能，在提交bug後，開發還沒改好時，可以準備效能測試，在工作時間很緊的情況下會主動加班

我們公司自動化測試用的語言是Java，Java你不會，該怎麼辦？

回答思路

問到不會的標準思路：要麼說會一點相關的內容，要麼表達自己有不錯的學習能力和很好的學習意願和態度。

我們學了Java了就說會，知道面向物件的封裝，繼承，多型，知道多執行緒的兩種建立方式（自定義子類繼承Thread類，或者自定義子類實現Runable介面），還知道異常Throwable，Exception的格式，try catch finally。知道List， Set，Map集合。我可以很快的學會用Java做自動化。

以前的專案是怎麼管理的？

回答思路：

我們以前的專案是用禪道來做測試的需求管理、用例管理、缺陷管理的。另外版本管理工具使用的是SVN。

以前的專案每天需要執行多少用例

回答思路：

正常情況一般每天執行20個左右的用例，剛開始測試的時候，bug比較多，需要很多時間和開發交流溝通

案例執行會比較慢。越到後面就越快了。

你們做迴歸測試的時候是否全部都做呢？

看時間，如果時間比較充足，會全部迴歸，迴歸時候因為自己操作比較熟練，然後系統基本上也沒有bug。所以執行案例的速度會比較快。

如果時間比較緊，就會挑選重要模組來回歸測試了。

PS：自己組織好語言。

你們怎麼確保用例覆蓋率？確保不重複

利用判定表法的思想，先窮舉，再挑代表。

然後，案例評審時候產品經理、開發組長、測試組長，還有對應模組的開發負責人也會把關，可以諮詢他們意見，確保案例即覆蓋完全，又沒有多餘的重複案例。

你們案例是怎麼評審的

評審時候有產品經理（SR）、測試同事、開發同事，評審時候一般產品經理（SR）、測試組長、對應模組的開發同事會提出一點意見，評審完之後，回去修改、補充一下案例。

修改完以後，有兩種處理情況：

對大專案有時候要進行案例的第二次評審。

對小專案，在時間緊的時候，一般不會二審，但是要以郵件的形式把修改或者新增後的案例發出來，給領導看，並抄送給其他同事。（案例評審0。5天，修改案例0。5天，案例二審0。5天）。

檢視是什麼？

檢視記錄了一條SQL語句，當查詢時才有資料返回。表就是一張具體的表。檢視只能查詢資料，表可以增刪改查。

工作非常努力了，還是沒有完成上級交代的任務，怎麼辦？

回答思路：

其實領導最喜歡的員工是：能力強、態度好的。領導招聘我們的目的是幫助他解決問題。

你工作非常努力，還是沒有完成上級的任務，要分析原因，如果是能力不夠的原因，則要表示願意且一直在提高能力，希望領導能諒解。

如果是因為可能的領導安排的任務過多，則要委婉地表示自己的能力有限，不希望自己的能力影響專案的進度，另外也請領導多給點提高效率的建議。

你的職業規劃是什麼？

首先快速熟悉業務，熟悉環境，再主動研究，轉組長，經理（突出自己的努力和穩定）

（切忌在功能測試的面試說自己要往自動化，效能發展。

因為他怕你不穩定，以後會嫌棄他公司的功能測試。

除非該公司以後會考慮使用自動化或者效能測試技術）

平時週末不上班都做些什麼呢？

有空就會學習鞏固技術知識，比如自動化，效能，還自學python和selenium

從上家公司學到了些什麼？

從大家一起努力認真而有序的專案過程中，雖然辛苦，但是收穫良多。我獲得了測試的經驗，業務的熟悉，技能的提升，以及團隊配合協作的精神、堅持不懈的精神。

為什麼從上家工資離職

面試官可能會說：你就實在和我說吧，不要說什麼套話。

（還是選擇說套話吧）首先感謝上家公司提供的提升自我工作經驗的機會，之所以想離職是因為想積累不一樣的經驗，更進一步的學習，來提升自己。我覺得貴公司非常符合自己的要求。

你住哪裡？

因為很多人離職時候，往往會以住的地方太遠為藉口來申請離職，所以面試官可能會問你住哪裡，防止你以後入職不穩定。

回答：

住的比較遠的同學就說住哪裡哪裡，上班比較近。（住的地方建議說成和上班的地方在1個小時路程以內）

離職時候工資多少？

說比現在期望薪資少500元。

人力面試：

1、為什麼轉做測試

回答思路：

大學就透過網際網路瞭解軟體測試，瞭解IT，自己也比較喜歡，然後也選修了C語言或者Java語言來學。

在大四之前的暑假，在松勤培訓過軟體測試。

2、加班出差能接受嗎，加班能接受嗎？

回答思路：

通常如果這個問題被問題，是絕對不能直接說不接受的，能接受出差，還沒有男/女朋友。

搞IT一般都要加班，我以前也是這麼加的，沒問題。

站在自己的角度說：還年輕，希望能在短時間內提高自己的能力和積累更豐富的經驗，加班是沒有問題的。

3、說說你自己與眾不同的地方和性格上的缺陷以及你準備如何改善

回答思路：

其實這個問題就是回答優缺點。

性格本身是一種習慣，說以你應該表示透過最佳化自己的行為習慣來改變自己的缺點。

向身邊的榜樣學習，就是學最好的別人，做最完美的自己。

4、在學校時參加過社團嗎、當過最高的職位，會協調嗎？

回答：

如果有就更好，這個能夠體現自己的協調能力、組織能力、溝通能力。這些對於工作很重要。要講一兩件具體的事情，把能力透過事情體現出來。

5、領導和追隨者你認為自己適合哪個？

回答：

領導是帶領和指導，一般通用的回答要是領導，因為自己可以以身作則，技術上也能對下屬有一定的指導能力。

6、以往工作經驗；

回答：

在忙碌的工作當中，既充實，又有成就感。透過不斷的測試，我的溝通能力、協調能力得到了提高，同時還收穫了行業知識經驗等，深刻感受到了團體精神的重要性。

8、為什麼要從事軟體測試；

回答：

自己非常喜歡網際網路，喜歡it，我覺得這一行非常有前景，馬雲說現在已經世界已經進入第三次工業革命了，就是資訊科技革命。計算機發展速度很快，網際網路公司可以利用短短几年時間到達傳統行業過去要幾十年才能達到的境界。

9、過去工作中最有成就的事情是什麼；

回答思路：

基本原則是要謙卑，談不上最有成就的事情。

如果非得要說有的話從某一件事情上收穫頗多，克服了什麼樣的困哪等。

如果對軟體測試有興趣，想了解更多的測試知識，解決測試問題，以及入門指導，幫你解決測試中遇到的困惑，我們這裡有技術高手。如果你正在找工作或者剛剛學校出來，又或者已經工作但是經常覺得難點很多，覺得自己測試方面學的不夠精想要繼續學習的，想轉行怕學不會的， 都可以加入我們810119819，群內可領取最新軟體測試大廠面試資料和Python自動化、介面、框架搭建學習資料！

10、試用期、轉正期望工資多少；

回答思路：

首先要說其實工資不是最關鍵的，然後給一個500元範圍浮動的值

一線城市工資應屆生最低6000，畢業一年7000，畢業兩年8000，畢業三年9000以上。小編給的是最低標準，大家看根據自己學習情況，適當調整，比如學的不錯的同學，兩年工作經驗提10000沒有問題的。

如果問你上一家公司工資多少，就說出比你現在期望工資少個500元的值。

文末福利

整理了一些各大廠的面試題（含答案）和今年(2022)最新資料的收集，包含了：web測試、安全測試、測試管理&專案安全、測試模板、大資料、計算機原理、介面自動化、資料庫、效能測試面試題。

所有資料均已整合成文件，希望對大家有幫助。需要的朋友關注+私信【軟體測試】獲取