網上銀行轉賬是怎么測的，設計一下測試用例。
回答思路：
宏觀上可以從質量模型（萬能公式）來考慮，重點需要測試轉賬的功能、性能與安全性。設計測試用例可以使用場景法為主，先列出轉賬的基本流和備選流。然后設計場景，最后根據場景設計數據。實際面試中需要舉出具體的例子。
先檢查界面。
再測試功能：
驗證同行轉賬，跨行轉賬。
驗證轉賬限額。
驗證非法賬戶（掛失，凍結，鎖定的賬戶）的轉賬。
再測試性能方面的。
測試工作的流程?缺陷狀態有什么?設計測試用例有幾種方法？
測試工程師的實際工作流程（以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元。