金融行業軟體測試面試題（含答案）

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

回答思路：

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

先檢查界面。

再測試功能：

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

驗證轉賬限額。

驗證非法賬戶（挂失，當機，鎖定的賬戶）的轉賬。

再測試性能方面的。

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

測試工程師的實際工作流程（以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:自己組織好語言。

你們怎麼確定用例覆寫率？確定不重複？

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

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

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

你們案例是怎麼評審的

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

對小項目，在時間緊的時候，一般不會二審，但是要以郵件的形式把修改或者新增後的案例發出來，給上司看，并抄送給其他同僚。（案例評審0.5天，修改案例0.5天，案例二審0.5天）。

視圖是什麼?

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

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

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

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

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

你的職業規劃是什麼？

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

（切忌在功能測試的面試說自己要往自動化，性能發展。因為他怕你不穩定，以後會嫌棄他公司的功能測試。除非該公司以後會考慮使用自動化或者性能測試技術）

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

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

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

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

為什麼從上家工資離職

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

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

你住哪裡？

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

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

離職時候工資多少？

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

主攻測開及接口自動化方向，分享爬蟲擷取的稀缺精品資源，歡迎關注微信擷取。