常見面試問題集

一、自我介紹？

參考答案：您好！我叫**，來自湖北黃岡，畢業於武漢理工大學，目前已有3年的工做經驗，以前負責了5個項目，在工做中我主要參與功能測試，自動化測試，接口測試以及性能測試。工做的內容大概是：需求分析和需求評審，協助上級完成測試計劃的編寫，編寫測試用例並評審，測試環境的搭建以及測試執行和編寫測試報告等工做。平時會去網上看一些軟件測試方面的知識，增強自身能力，好比CSDN，博客園等地方，除此以外，我比較喜歡打籃球，聽聽音樂等等，以上就是個人一個自我介紹。謝謝。

2、爲何離職？(有些學員會說工資小，離家太遠，這些理由都不行)

參考答案：項目組解散，待業工資過低了，等不了

公司晉升途徑少：公司框架，都是老員工，新人根本沒有機會晉升，看不到將來的但願，只能爲上班而上班，我更但願有一個有餅能夠看到的公司，這樣起碼會有奮鬥的動力！否則一直都是一個普通職員，不管是管理崗仍是技術崗，都沒有晉升的但願！這對我這麼一個有野心的人很是打擊。

 

#若是繼續問---咱們公司也比較小，沒有那麼順利晉升！

參考答案：可是能夠學到新技術啊！這對個人軟件測試人生也是一個很是好的確定！

三、你主要作哪些測試？

功能，接口，性能跟自動化都有一直在作，自動化就相對少一些，主要是功能穩定的模塊咱們纔會寫的，首先，咱們會先判斷這個系統能不能實現UI的自動化，若是能夠實現的話，咱們就會轉化成自動化，通常是優先把冒煙測試轉化成自動化，還有作迴歸測試的時候。

四、你會數據庫嗎？

數據庫咱們主要用的是增刪改查，好比：咱們在前臺下了一個訂單，除了在用戶中心和系統後臺查看這筆訂單是否正確，咱們也會到數據庫中查詢該訂單的數據是否正確。

5、tomcat的端口在哪設置？

找到tomcat的安裝路徑，進去conf目錄，打開server.xml文件,默認是8080端口，修改爲要改的端口

六、linux命令背一背？

咱們的服務器都是在linux上的，經常使用的linux命令都會，好比咱們會在linux搭建測試環境，tail -f 來查看日誌，top來查看資源等等

六、python熟不熟？

咱們python主要是用來寫自動化測試腳本的，在腳本中會用到變量的定義，代碼的封裝，模塊調用，if條件判斷，try...except異常處理等等。

七、自動化斷言？

assertEqual（兩個值相等）

assertNotEqual

assertTrue（判斷bool值）

assertFalse

assertIsNone

assertIsNotNone（存在）

8、產品上線流程是怎麼樣？

首先，由運維和開發進行代碼上傳以及各類配置，在環境配置好後，測試再介入，先進行冒煙測試，而後再根據當前上線的需求來進行功能點驗證，驗證經過就發郵件反饋驗證結果，驗證有問題先通知項目組內部成員進行復現和修復，能修復成功就不上報問題，不能修復成看問題嚴重程度進行上報，通常提示類問題可靈活變通，嚴重的短時沒法修復的就要上報。而後再發郵件反饋驗證結論。

 

七、迭代兩到三週的項目，需求分析要多久，用例寫多久，寫多少用例，執行多久，發現多少個bug，作了幾個版本，項目有沒有上線？你負責的模塊一共寫了多少用例？

1）、需求分析1到2天，用例也是寫兩天左右，包括用例評審；

2）、用例的個數看需求和顆粒度的大小，若是時間充足，咱們寫的用例細，用例數就多些，一個版本大概有100多條，執行花的時間長了，通常要4到5天；

3）、每一個版本發現的bug數量，要看需求和實現起來的難易程度，開發人員的水平和測試用例的質量，通常一個版本咱們能找50-60個bug，越到後面，系統愈來愈穩定，發現的bug就越少；

4）、咱們這個項目一共作了7個多月，每兩週一個迭代，一共下來有十來個版本；

5）、項目上線了，咱們在內部環境上測試完以後，產品經理會跟客戶對接，完成上線的事情，以後交付給用戶本身運營；

6）、每一個版本基本上會有將近200條用例，到如今爲止，xxx這個項目，我大概寫了又2000條左右的用例。

8、項目一作了多久？

這個項目到如今還一直在作，已經作了8個月了(多長時間，能夠靈活修改)，前期需求比較多，迭代的版本多一些，到後期項目基本穩定了，需求變化不大，咱們會被調去作其餘項目，這個項目後期若是需求發生變化，咱們仍是要負責測試。因此，在上家公司基本每一個人都會跟着幾個項目。

9、迭代了多少次？

這個我還真沒具體算過，咱們差很少2-3週一個迭代，十幾個迭代是有的

10、一個版本找多少bug？

兩個星期一個迭代，咱們一個版本的需求通常是5個左右。看需求的多少，基本每一個迭代都有100多條用例

十一、項目有沒有上線？

具體業務這塊的話，都是產品那邊跟需求方(客戶)對接的，我這塊就不是很清楚了，測試組的話就只管測。

11、bug的分佈通常都是怎樣的？那些模塊的bug比較多？

發現錯誤越多的模塊，殘留在模塊中的錯誤也越多

十二、哪些模塊的bug比較多？

功能性

13、經典bug，印象深入bug？

驗證碼沒有時間限制，獲取了一次驗證碼之後更換他人帳號能夠強制修改密碼。

14、測試環境怎麼部署的？

參考答案：搭建環境前，開發都會給到咱們一份系統發佈手冊，咱們會根據這個手冊來搭建。好比，我這個商城系統，是搭建在Liunx系統下的，web服務器用的是Tomcat8，MySQL版本是5.7，程序是JAVA編寫的，首先咱們向開發拿到編譯好的安裝包，而後CRT遠程鏈接上Liunx系統，把tomcat服務器停掉，把程序包(因爲java包的後綴是.war，因此咱們通常把java的安裝包叫 war包)放到webapps目錄下，而後再啓動tomcat服務器就能夠了

中止tomcat服務器的方法：

ps -ef | grep tomcat -- 查詢出tomcat的進程ID，而後，使用命令 kill -9 tomcat的進程ID

啓動tomcat服務器的方法：

進入tomcat的bin目錄，執行命令 ./catalina.sh start。

15、給你一個項目，怎麼開展？

在項目開始前，我會去熟悉這個項目的需求，業務流程，將測試功能點列出來，把不明白的地方提取出來，和開發、產品經理確認清楚，而後根據項目的迭代週期肯定一個測試計劃，接下來開始編寫測試用例並叫上開發、產品經理進行評審；在項目開發階段，開發人員把接口代碼編寫完成後，我會對接口進行測試，保證底層接口的質量；等全部代碼都編寫好了，開發轉測後，進行冒煙測試，冒煙測試經過了，接下來進行系統的功能，安全，兼容性，性能等類型的測試，發現bug就提交bug單給開發人員修改，跟蹤並作好迴歸測試；這些測試完成後，挑選一些級別高的測試用例，在UAT環境上進行驗收測試，驗收測試經過後，編寫測試報告，項目就能夠上線了。項目上線後，可能還會出現一些遺留的問題，因此還要分析研究怎樣作才能避免這類bug的遺漏。

16、測試，開發多少人

7個開發，2個測試

17、驗收測試怎麼作的？

在UAT測試以前，咱們會制定測試方案，選擇基線用例，即級別高的用例，在UAT測試環境上進行測試，若是測試經過，驗收測試就經過了

18、冒煙測試怎麼作的？

當開發寫完代碼，編譯好後，會提交到測試部進行測試時。測試人員搭建好環境，首先要對系統的基本功能進行測試，肯定主要流程的可否正常使用

19、迴歸測試怎麼作的？

首先，把bug單對應的用例執行一遍，還要檢查有數據交互的模塊會不會受影響，有沒有引入新的問題；項目上線前，還要把當前版本的重要功能以及冒煙測試的用例都回歸一遍，確保重要功能上線後不出問題

20、你以爲測試是一個什麼樣的職業？

自由發揮

2一、談談你對測試的理解

軟件測試就是使用軟件，站在用戶的角度，模擬各類正常的和異常的場景來使用軟件。

22、職業規劃怎麼樣的？是想往管理髮展仍是技術發展？

先熟悉公司的業務流程，作好本職工做，爭取早點成爲項目的骨幹成員；工做以外，會進階一下本身的自動化和性能方面的相關技術；

在公司裏面往那個方向發展，那要看公司的安排了。

23、講一下你作的app項目

講一下簡歷裏面的項目流程還有主要職責

24、大家用例怎麼寫的？

測試用例包括：用例ID、用例標題、用例級別、預置條件、測試步驟、預期結果，

2五、怎麼編寫測試用例？

覆蓋用戶的需求；

從用戶使用場景出發，考慮用戶的各類正常和異常的使用場景；

用例的顆粒大小要均勻。一般，一個測試用例對應一個場景；

用例各個要素要齊全，步驟應該足夠詳細，容易被其它測試工程師讀懂，並能順利執行；

作好用例評審，及時更新測試用例。

26、接口的狀態碼有哪些？？

接口狀態碼都是開發自定義的，0是操做成功，3001是非法請求，3002是系統類型爲空或不合法

27、搭建測試環境時有沒有遇到過什麼問題？

配置環境變量的時候漏了幾個字母，而後軟件就啓動不了了

28、python的第三方模塊有哪些？？

time、datetime 、unittest 、random、HTMLTestRunner、sys、selenium

29、測試環境的測試數據是怎麼管理的？

功能測試環境的數據，用完了就本身造；性能測試環境的數據，在測試前會先備份一下，迴歸時候再導進來

30、提交的bug，開發通常多久修復？

通常咱們提交了bug大概1-2個小時就會去看一下開發是否解決，沒有解決，就催促一下開發

31、什麼類型的bug會出現的多一些

功能性

32、怎麼向數據庫插入數據？插入10萬條呢？

插入數據使用insert into，可是要插入10萬條數據，則須要使用存儲過程來實現，存儲過程這個我之前沒有本身寫過，可是若是之後公司有須要，我會在工做以外的時間增強對這方面的學習

33、接口用例一個版本寫多少？依賴關係的接口怎麼處理？

通常大概50-60個接口用例左右

34、你以爲測試三年的收穫是怎樣的？

 

35、項目的開發模式是怎樣的？

敏捷開發

36、你的項目有什麼特色和特點，對比京東和淘寶？

有個貨到付款功能，付款方式除了直接關聯帳戶扣款、匯款外，還能夠選擇貨到付款，目的有兩個：一是爲了方便買家看到貨物後滿意再付款，省去退款環節，同時解決用戶對自營系統線上支付的疑慮，提升成交率；二是方便部分年長，不會使用網絡支付的的購買者付款。

37、項目一作了多久，上線了嗎，多少人開發的？

8個月，具體業務這塊的話，都是產品那邊跟需求方對接的，我這塊就不是很清楚了，測試組的話就只管測。開發有7個，測試2個

38、公司多少人？誰負責開發的？

公司人數40-60個，項目組2個，每一個項目組大概10我的左右

39、驗收測試誰作的？

正式的驗收測試

а測試，軟件開發公司組織內部人員模擬各種用戶行爲對即將上市的產品進行測試。

β測試，軟件開發公司組織各方面的的典型客戶在平常工做中實際使用，並要求用戶報告異常狀況、提出改進意見，而後公司再進行完善。

正式的驗收測試

在UAT測試以前，咱們會制定測試方案，選擇基線用例，即級別高的用例，在UAT測試環境上進行測試，若是測試經過，驗收測試就經過了。

40、產品發佈到線上，還測試嗎？

須要的，一般在上線以後，咱們還會進行基本功能的驗證

41、項目通常何時上線？

凌晨12點，晚上用戶少，出現問題能夠立刻去解決迴歸測試

42、訂單管理這個功能，怎麼測試？

訂單管理以前作的，如今記得不是很全面，也是從六大特性下手的，最近作的購物車的測試點我記得比較清楚，我拿這個做爲例子講一下吧，+購物車怎麼測

43、大家項目是怎麼分工的？

參考答案：

若是你回答的是app的項目，就說：咱們這個app是按機型分工的，我負責的是安卓設備的測試；

若是你回答的是WEB端的項目，就說：咱們這個項目是按模塊分工，我負責前臺的xxx模塊，後臺的xxx模塊。(至少說5個模塊以上)

44、app的測試流程，app項目介紹是怎麼的？

流程：app的性能分爲服務器端的性能和手機端的性能。

服務器端的性能，咱們用Jmeter工具進行測試的，和web的端性能測試方法同樣的。

 

咱們是用monkey作手機端App的穩定性測試的，使用monkey跑10萬次，看它會不會出問題，若是出了問題，咱們再定位緣由，具體的作法是這樣的：

一、在跑monkey前，先清空手機的logcat日誌：adb logcat -c

二、接下來，獲取logcat日誌：adb logcat -v time > E:\share\logcat.log

三、使用monkey運行被測應用：adb shell monkey -p your.package.name -v 100000 > E:\share\monkey.log

四、測試完成後查看monkey日誌,若是說它跑的次數跟我設的次數不同.就說明monkey中途跑失敗了。那我就要去看看logcat日誌有沒有null point，或anr in的關鍵字,若是有null point，就表示app在測試過程當中crash了，而後把null point先後的日誌截取下來，發給開發定位；若是有anr in，表示app在測試過程當中出現了ANR(程序無響應)，咱們要把/data/anr/traces.txt文件取下下來，再把ANR進程號對應的日誌發給開發定位問題。

45、web和app測試區別？

系統架構：web端系統，更新服務器，不須要更新客戶端；APP若是更新了服務端，客戶端也要更新並測試；

兼容性。Web端要考慮不一樣的瀏覽器內核進行測試（IE、chrome、Firefox），APP的兼容性要考慮選擇主流的機型，不一樣的分辨率、尺寸， 以及不一樣的操做系統；

App要考慮交叉事件測試，安裝，卸載，先後臺切換測試；

App還要考慮界面操做，如：橫豎屏切換，多點觸控，事件觸發區域

46、app兼容性怎麼測試？

1）主流手機的分辨率測試。好比（高*寬）：1280*800、1280*720、1920*1080等

2）不一樣操做系統的兼容性，是否適配。好比，安卓從7.0-9.0

3）不一樣手機品牌。好比，華爲，小米，oppo，vivo等等

Ps：iphone系統的APP也要考慮這些方面

47、測過那些機型？分辨率測試那些？

機型：安卓系統的機型，好比華爲，小米，oppo，vivo等等

分辨率：1280*800、1280*720、1920*1080等

48、測試和開發的時間比是怎樣的？

咱們公司大體是 3：1，咱們公司通常一個月迭代一次，不管需求多少，那麼測試通常就是一週。這致使測試那邊壓力很大，常常只測一輪。以前一個大版本升級，涉及到一部分重構，測試時間又少，致使不少關鍵業務沒測到，上線以後問題多多，一直處於修修補補狀態，一個星期才穩定。

49、你對從業這3年的測試生涯感覺是怎樣的？

發展＋技術＋將來方向＋自身能力幾個方面提升

50、有沒有要問個人？

1.若是我進來，我主要負責哪一塊測試；

2.公司項目組有多少人，開發和測試分別多少；

3.公司有哪些類型的項目在作；項目多長時間一個版本，項目作了多久；項目的測試流程是怎樣的

4.若是能夠進入貴公司，我須要在學習哪方面的知識？

51、何時入職，優缺點？

重複

52、講一下項目怎麼測的？

需求文檔開始。。。

5三、項目上線了？給客戶作的？給本身公司作的產品？

具體業務這塊的話，都是產品那邊跟需求方對接的，我這塊就不是很清楚了，測試組的話就只管測。咱們之前是外包公司，都是接到什麼項目就作什麼項目

54、app多久更新一次？如今還有在作嗎?

差很少2-3週一個迭代，通常產品給到需求都會作

55、負責那些方面的測試？

拿熟悉的點來說

56、怎樣才能覆蓋用戶的需求？

參考回答：項目開始前，咱們會先熟悉需求，畫好流程圖，保證整個流程都覆蓋全面，小組之間每一個人都要根據各自的流程圖，各個功能點有哪些限制條件，來說解一下本身對測試點的理解，防止以後編寫測試用例時出現遺漏；用例編寫完以後，再進行用例的評審，看看測試點有沒有用遺漏，對需求理解有沒有錯誤，測試場景是否覆蓋徹底。

57、接口測試怎麼作的？

參考答案：

一、拿到接口文檔熟悉：（服務端開發人員把接口文檔寫出來，咱們就能夠拿過來熟悉）：

 1）每一個接口對應要實現的功能是什麼

 2）服務器的地址、端口、接口地址（肯定訪問哪一個接口）

 3）請求方式，請求參數有哪些，參數的約束是什麼（工做當中瞭解請求參數的各類約束）

 4）熟悉響應數據：

 <1>響應的字段有哪些

 <2>正確和錯誤的響應碼(errcode)有哪些，對應的響應信息（message）是什麼。例如 ：errcode：4403 message：錯誤的請求信息

二、編寫接口測試用例（接口測試用跟功能相似，只多了一個請求報文，響應報文）

1）考慮正常異常的請求參數的請求報文

 2）考慮正常和異常請求後的響應報文（例如 ：異常的錯誤碼是什麼，對應的錯誤信息是否正確）

三、執行測試用例：

咱們是用jmeter執行測試用例，先創建一個線程組，再添加http請求，填寫好請求地址，端口，和請求參數，設置參數化，添加斷言等，最後添加查看結果樹再運行。運行完後，檢查接口是否經過，若是不經過，先定位下緣由，若是是請求的參數有問題，修改後再進行測試，若是是接口自己存在bug，就把服務器上的日誌取下來，提單給開發修改。

5八、禪道，會搭建不？

一、 把 xampp-win32-1.7.7-VC9.zip 拷貝到C盤下，並解壓到當前文件夾

二、 進入xampp文件夾，把xampp-control.exe發送到桌面快捷方式

三、 打開xampp-control.exe，並啓動MySql和Apache，（若是啓動不了，按所給的方案把修改下對應的端口便可把問題解決）。

四、 把ZenTaoPMS.8.0.1.zip 壓縮包拷貝到xampp\htdocs目錄下，並解壓到當前文件夾：

59、項目一作了多久，測試幾我的維護，開發投入了多少人？

8個月，維護2人，開發2人

60、開發語言是什麼？

APP：作安卓 java

網頁：是 H5

後臺：java ，具體不瞭解

61、html是什麼？

HTML稱爲超文本標記語言，是一種標識性的語言

62、http協議瞭解不？

參考答案：http協議是應用層的一個數據傳輸協議，由請求和響應構成，主要的請求方式有get和post兩種，get請求的請求數據在請求頭，post請求的請求數據在請求體；響應的數據也包含響應頭和響應體，常見的http響應碼有200,302,400,500等等。

63、講一下你最近作的app項目

重複

64、app測試點有哪些？

功能，兼容性，用戶體驗，安全性，安裝卸載升級測試，交叉事件，UI測試，性能測試

65、測試過程當中遇到怎麼辦？

 

66、Python操做隱藏元素？

用JS修改display屬性

67、xpath和css定位區別？

一、語法不同；

二、CSS定位比較穩定。

68、接口的壓力測試怎麼作的？

負載測試作法

69、點擊一個app軟件，沒有反應，怎麼去分析？

兼容性問題、這個功能自己不可用、考慮是否crash（軟件）或ANR（硬件）

70、app測試用的是真機？仍是什麼？

用的是真機，電腦配置太差了，不用模擬器

71、jmeter環境怎麼搭建的？

1）、由於JMeter是JAVA程序開發的，因此要先安裝JDK；

2）、配置JAVA環境變量，包括：JAVA_HOME，PATH，CLASSPATH；

3）、雙擊jmeter的bin目錄裏面的jmeter.bat文件，就能夠啓動Jmeter。

72、fiddler抓取https請求？

步驟：

一、安裝安全證書；

二、點擊fiddler的Tools-->options-->https

三、勾選上全部選項，更換證書，重啓fiddler

73、monkey跑掛了怎麼分析問題？

若是說它跑的次數跟我設的次數不同.就說明monkey中途跑失敗了，那我就要去看看logcat日誌有沒有null point，或anr in的關鍵字,若是有null point，就表示app在測試過程當中crash了，而後把null point先後的日誌截取下來，發給開發定位；若是有anr in，表示app在測試過程當中出現了ANR(程序無響應)，咱們要把/data/anr/traces.txt文件取下下來，再把ANR進程號對應的日誌發給開發定位問題。(日誌具體的信息，咱們看不懂)

74、你的優勢和缺點是什麼？

優勢：責任心強，工做細緻認真

缺點：測試作了幾年，發現本身可能得了職業病，遇到什麼都先懷疑一下，我朋友說我疑心有點重，在工做上是件好事，可是在生活上多少會有點影響吧，好比，作事有點猶豫，不夠果斷

75、學習能力強，有哪些提現？

我認爲一個接受完大學教育的人，他就具有了學習知識的能力，首先，具有學習能力的人比不具有的人更有學習意識，其次，具有學習能力的人擁有本身的一套學習新知識的邏輯和方法，最後，具有學習能力的人能對本身的學習結果進行評估，並對下次學習過程提供改善信息。

7六、你以爲測試的價值是什麼？

1.開發人員不可以徹底的發現本身的bug

2.開發人員和測試人員的立場不一樣，前者立足技術，後者立足需求，關注質量

3.測試人員可以更好的促進項目溝通與反饋

7七、有沒有作過提好測試效率，讓測試工做更有價值？

引入自動化測試，提升了測試效率

78、偶然性的bug怎麼處理？

在測試執行過程當中，一旦系統出現異常信息，咱們第一時間要作的是截圖，保存證 據；肯定是偶然性的bug以後，收集相關的日誌，連同截圖一塊兒提單給開發定位； 若是該缺陷的影響程度比較低，能夠提交問題單進行跟蹤，跟蹤三個版本，若是後三 個版本都沒法復現，就能夠關閉該缺陷； 若是這些不可復現的Bug是很嚴重的Bug，好比致使系統崩潰等，而且，實在沒有再 次出現，除了要及時反饋給上級以外，最後還要寫到測試報告中，說明出現了什麼現 象，但沒法再現！

79、大家的測試環境，服務器幾臺？

通常作功能的話，服務器就一臺，若是作性能的話，會多一些有兩臺web服務器，一臺DB服務器

80、app多久更新一次？

需求作完了一兩個月更新一次，若是沒有就算兩週一個版本

81、原本週五上線，白天加了一個需求，怎麼辦？

 

82、你瞭解咱們公司嗎？

提早看一下公司的主營內容等等

83、項目大概作了多久，*更新了多久？

 

84、本身公司作的仍是給別人作的產品？

給別人作

85、系統用戶數怎麼樣，*大概有多少？

app在友盟統計能夠看到日訪問量，網頁本身在後臺看

86、退貨流程怎麼測的？

退貨流程以前作的，如今記得不是很全面，也是從六大特性下手的，最近作的購物車的測試點我記得比較清楚，我拿這個做爲例子講一下吧，+購物車怎麼測

87、何時上線？版本發佈何時？

（晚上用戶少，出現問題能夠立刻去解決迴歸測試。）

8八、接口測試出錯了怎麼定位？

首先，我會先檢查一下請求參數啊，還有其餘的填入的數據是否有問題，若是這些都沒問題，我會ping一下網絡，看網絡通不通，若是網絡也沒問題的話，我會去看看系統服務器有沒有啓動，若是服務器也沒問題的話，那可能就要發給開發定位一下了。

8九、接口用例怎麼編寫？

咱們每一個版本都會有四五個接口需求，有的是新增的接口，有的是原來的接口作了一 些調整，咱們會查看這些接口有哪些參數，每一個參數有什麼約束條件，加密方式是什 麼，正常和異常的響應信息有哪些，而後編寫測試用例來覆蓋這些需求，一個版本下 來大概有五六十條接口測試用例。

90、你在項目有沒有作過什麼提升效率的事情？

引入自動化測試，提升了測試效率

9一、測試風險有哪些？怎麼迴避？ 

風險包括進度風險、質量風險、人員風險、需求變動、成本風險等

例：

一、測試人力不足致使測試進度滯後   規避風險：開發人員兼職測試

二、測試人員經驗不足致使測試結果分析不全面   規避風險：多組織培訓、多進行技術、經驗交流

三、用戶需求改變     規避風險：項目總體調整，項目組全員加班

92、bug的組成，bug狀態，開發不改bug怎麼辦？

一、組成：標題、所屬模塊、級別、操做步驟、預期結果、實際結果、相關日誌和截圖；

二、狀態：激活、已解決、已關閉；

三、先跟開發溝通，確認系統的實際結果是否是和需求有不一致的地方；有些地方可能需 求沒說起，可是用戶體檢很差，咱們也能夠認爲是bug。 若是開發以不影響用戶使用爲理由，拒絕修改，咱們能夠和產品經理，測試經理等人 員進行討論，肯定是否要修改，若是你們都一致認爲不用改，就不改。

93、Python數據類型有哪些？定義類的關鍵字是啥？

不可變數據：int (整型)、float (浮點型)、str（字符串）、Tuple（元組）、Sets（集合）；

可變數據：List（列表）、Dictionary（字典）。

定義類的關鍵字：class 類名：屬性

                          方法

94、自動化測試怎麼作的？

就拿簡歷上的xxx項目來講吧，在編寫腳本前，咱們會對系統進行評估，確認這個系統可不能夠實現UI自動化，若是能夠的話，就篩選出能實現自動化測試的用例，通常優先把冒煙測試用例的轉爲成腳本。咱們是用selenium工具來實現自動化，採用python腳本語言，基於unittest框架進行用例的編寫。好比，下單這個功能的腳本，咱們是這樣作的：首先，咱們會構建一個測試工程，測試工程包含public部分(這裏封裝腳本公共的內容，好比，打開瀏覽器，登錄等操做)，testCases（存放測試用例），reports（存放測試報告），runAllCases（用於運行項目自動化用例），腳本調試完後，咱們會用jenkins持續集成工具，設置腳本天天晚上8點跑一遍腳本，跑完後生成html格式的自動化測試報告。

9五、自動化腳本失敗的緣由？

1）、多是測試環境的網絡不穩定；

2）、開發修改了代碼沒通知到測試人員修改腳本；

3）、開發引入了新的問題

96、在工做期間，你對公司（項目）有什麼貢獻？

一、引入自動化測試，提升了測試效率

二、在作交叉測試時候，發現了我同事測了幾個版本都沒發現的問題，而且是比較嚴重的那種，我舉個例子吧：用戶修改密碼時，會接受一個手機驗證碼，因爲系統沒有對用戶名和手機號碼作綁定驗證，接收到驗證碼後，填入別人的用戶名能夠進入密碼修改頁面，把別人的密碼修改了

97、接口測試關注哪些內容？

1）、發送給服務器的請求數據是否正確；

2）、服務器返回給客戶端的信息是否和預期結果一致；

3）、進入數據庫，檢查接口是否實現的相應的功能；

4）、接口的響應時間是否符合需求。

98、爲何要作分佈式壓力測試？

由於當時咱們作性能測試，本身的電腦是帶不動那麼多用戶的，因此才須要分佈式的環境

99、測試用例評審會有哪些人蔘與？

產品、開發、測試和咱們組長都會參與

100、冒泡排序怎麼寫？

思路：大致思想就是經過與相鄰元素的比較和交換來把小的數交換到最前面。這個過程相似於水泡向上升同樣，所以而得名。舉個栗子，對5，3，8，6，4這個無序序列進行冒泡排序。首先從後向前冒泡，4和6比較，把4交換到前面，序列變成5，3，8，4，6.同理4和8交換，變成5，3，4，8，6，3和4無需交換。5和3交換，變成3，5，4，8，6，3.這樣一次冒泡就完了，把最小的數3排到最前面了。對剩下的序列依次冒泡就會獲得一個有序序列

101、你簡歷上的專業和你畢業證上的不同，什麼緣由？

 

102、你在xx項目中，有沒有學到什麼，對自身的成長有沒有幫助？

在個人XXX項目中，咱們是首次開始作了自動化，以前個人自動化都只是停留在本身私下作的一個階段，那一次是第一次在項目中使用經過這個項目首先是豐富了我自身的測試經驗，而後這個項目也是有作性能、接口、自動化等等，這讓個人測試能力更能全面的發展，同時經過項目也讓我對web端的測試更加熟悉，相信在之後的工做中我對web端的項目可以儘快上手的

103、工做中有沒有遇到什麼困難，是怎麼解決的？

太大的困難倒沒有，不過在上個項目我遇到過一個比較緊急的問題，當時咱們的測試環境有問題，在界面上構造不了數據，致使測試堵塞了，項目趕着上線，領導一直在催，爲了解決這個問題，當時我找到開發和運維的同事，讓他們幫忙從生產環境上把數據導到測試環境上來測試，由於要協調其餘部門的同事，因此印象比較深。

104、自動化的登錄腳本，若是我想一個腳本里面完成多個用戶登陸，怎麼作？

這個咱們之前工做中沒有接觸過，那若是是須要併發登陸，咱們可使用Jmeter實現

105、大家接口測試是一個個作，仍是系統作？

咱們是將這個系統的全部接口，都放在Jmeter的一個線程組下一塊兒執行。

 

106、若是一個模塊有不少條用例，我想跳過其中幾條，怎麼作？

不以test開頭，或者把不執行的用例註釋掉

107.頁面有個日期控件，我須要寫入一個開始時間和結束時間，有沒有遇到過

這種場景？

參考答案：

1）、若是能夠直接修改值，就用send_keys()輸入值；

2）、若是輸入日期的輸入框不能直接修改，通常來講，這個輸入框有一個readonly的屬性，調用js將這個屬性刪除，而後再用send_keys()輸入值；

108、怎麼驗證前端加密的信息是否是正確的？

參考答案：咱們在客戶端輸入好了信息，提交，而後用Fiddler抓包，看客戶端加密後的數據，與開發給到的加密腳本是否一致，若是一致就是沒有問題。其次，還要看返回的數據是否是正確的。

109、app版本升級具體應該怎麼作？

參考答案：app的升級，咱們能夠在後臺設置，只對指定的手機進行版本的推送，而後如今這幾臺手機上進行升級的測試，若是沒有問題，再去全量推送。

110、升級出現問題怎麼辦？

升級出現問題，就先修復問題，而後修復完成以後，再在測試機上進行測試，沒有問題，再全量推送了。

111、怎麼去找到難以復現的問題 ？

1）、查找日誌，看是那個環節出現了問題

2）、儘可能去重複操做出現問題的步驟，從不一樣角度去嘗試

112、爲何選擇作測試？

剛開始，在xxxx公司上班，作的是技術支持類的工做，咱們的系統問題比較多，客戶常常投訴，當時全公司只有一個測試，由於測試人手不夠，公司把我調過去作測試，後面就一直作軟件測試這個行業。

113、線上有沒有發現bug啊

這個我說沒有想必你也不相信，通常咱們發現了線上bug的話會先復現問題後，提交問題單進行跟蹤；而後評估該問題的嚴重程度，以及修復問題時的影響範圍，迴歸測試須要測試哪些功能；等待問題修復後，先在測試環境上回歸，經過後再在生產環境上打補丁，而後再進行迴歸測試；最後總結經驗，分析問題發生的緣由，避免下次出現一樣問題。

114、有沒有跟開發吵過架

沒有。不過，有時候討論問題會稍微激烈些，都是對事不對人的

115、怎麼看待加班呢？

我反正是沒有六點下過班，幹咱們這一行的，加班很正常，只要不是無理的加班都能接受，畢竟公司不賺錢哪有錢給我發工資呢，不少事情仍是要爲公司考慮考

116、當用戶需求變動時，你會怎麼作？

這個會常常遇到的，通常若是是小的需求變動，合理的話，能改的，經理會讓開發直接改，而後測試再測一下就行了，若是是涉及到比較大的改動的話，通常會建議放到下一個版本再修改，若是必需要改的話，開發就會改的，測試也會從新修改一下測試用例，把可能會影響到的模塊再測一遍。

117、對於用戶需求，你是怎麼理解的？

用戶需求，就是描述用戶但願把產品作成什麼樣的一個文檔，有些需求寫得很全面，什麼信息都有，很細；可是，不少時候咱們拿到的用戶需求都是比較粗的，不全面的，甚至是有問題的，這時候，咱們要及時和上級，還有產品經理反饋

118、若是項目很趕，經理安排一個項目要三週內完成，你知道你完成不了，你怎麼辦？

先和經理說明，時間過短，存在風險；而後，將任務劃分優先級，先完成優先級高的任務 ，保證項目的主要功能沒問題，而後，時間容許的話，再作優先級稍微低的；在這個時間段內，天天向 上級報告工做的進度，讓領導知道如今的工做進展和存在的風險

119、如何與開發溝通

1)、堅持原則；2)、對事不對人，拿證聽說話；3)、尊重對方的勞動成果，平時和開發人員打好關係，不要把關係搞僵。

120、項目版本更新，怎麼更新

1.關閉tomcat服務器

2.進入tomcat服務器下webapps目錄下，刪除須要替換的系統的老版本工程文件，把新的war包放到webapps

3.啓動tomcat服務器

4.先在測試環境上驗證新版本有沒有問題，沒有問題在上線，而後再到生產環境上驗證把主要功能驗證一遍。

121、怎麼打包？

咱們公司會有個專門的打包管理平臺(Jenkins)，開發把代碼上傳到這個平臺，咱們選擇須要打包的需求，按操做流程來作就行了

122、更新表結構發生變化，數據庫怎麼弄？

開發會寫DDL語句，咱們把以前的表數據備份，刪掉原來的表，而後執行開發寫的語句，導入入數據就能夠了。

123、一個項目是多個tomcat仍是一個tomcat下多個webapps？

一個tomcat下多個webapps

124、測試環境的測試數據是怎麼管理的？

功能測試環境的數據，用完了就本身造；性能測試環境的數據，在測試前會先備份一下，迴歸時候再導進來

12五、Jmeter作性能測試的工做原理是什麼？

主要就是以Jmeter來控制壓力機，來向服務器發送請求

12六、你可以把控的風險有哪些？

通常能夠把控的風險主要是進度風險、質量風險，進度風險咱們以前天天都會開一個晨會，瞭解一下你們的工做進度，若是有風險就會去幫助他，那質量風險咱們主要是經過需求評審和用例評審兩個階段來控制

12七、購物車涉及到的接口有哪些？

添加購物車接口、庫存查詢接口、下單接口等等

12八、項目在數據庫有哪些表？

12九、TPS測得多少？（20s）

130、JS的腳本怎麼調用？怎麼上傳文件？

13一、用戶支付完成，金額直接到達商家帳戶？（第三方支付）

13二、支付信息安全性怎麼保證？、

13三、優惠卷的類型？

13四、App的安裝怎麼測？

13五、自動化的元素屬性值是動態變化的怎麼定位？

13六、怎麼獲取元素的屬性值？

13七、怎麼上傳文件？

13八、字符串反轉輸出？

13九、Fiddler怎麼模擬2G/3G速度

140、Monkey測app的性能關注什麼性能指標？

14一、Selenium是什麼版本？

14二、Mysql和oracle區別？

14三、促銷活動有哪些？

14四、下單怎麼測？

14五、舉例說下場景法怎麼用的？

14六、Tomcat服務器怎麼重啓？ ./startup.sh

14七、相對併發和絕對併發的用戶比率是多少？10%

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1、給你一個杯子，你怎麼測試？

功能測試：

主要關注水杯基本功能

1.1 水杯是否能夠正常裝水

1.2 水杯是否能夠正常喝水

1.3 水杯是否有蓋子，蓋子是否能夠正常蓋住

1.4 水杯是否有保溫功能，保溫功能是否正常保溫

1.5 水杯是否會漏水，蓋住蓋子擰緊後是否會漏水

界面測試：

主要關注水杯外觀、顏色、設計等方面

2.1 外觀是否完整

2.2 外觀是否溫馨

2.3 顏色搭配及使用是否讓人感到溫馨

2.2 杯子外觀大小是否適中

2.3 杯子是否有圖案，圖案是否易磨損

易用性測試：

主要關注水杯使用是否方便

3.1 水杯喝水時否方便

3.2 水杯拿起放下是否方便，這裏會衍生到水杯形狀的測試

3.3 水杯裝水是否方便

3.4 水杯攜帶是否方方便

3.5 水杯是否有防滑功能

3.6 水杯裝有低溫或者高溫水時，是否會讓手感到不適

性能測試：

4.1 水杯裝滿水時，是否會露出來

4.2 水杯最大使用次數

4.3 水杯的保溫性是否達到要求

4.4 水杯的耐寒性是否達到要求

4.5 水杯的耐熱性是否達到要求

4.6 水杯掉落時時，是否能夠正常使用

4.7 水杯長時間放置時，是否會發生泄露

兼容性測試：

主要關注水杯是否能夠裝其餘液體，若是汁、汽油、酒精等

可移植性測試：

主要關注水杯放置環境等

6.1 將水杯放在常溫環境中，使用是否正常

6.2 將水杯放在零下的環境中，使用是否正常

6.3 將水杯放在高於正常溫度的環境中，使用是否正常

安全性測試：

主要關注水杯外觀和各類異常條件下是否釋放有毒物質等

7.1 當水杯裝滿熱水時，水杯是否會燙手

7.2 當水杯裝上水後，是否會產生有毒物質

7.3 把水杯放在零下環境時，是否會產生有毒物質

7.4 把水杯放在高溫環境時，是否會產生有毒物質

2、給你一個報表，你怎麼測？

報表測試的六大用例設計點

報表數據的正確性

一、數據來源是否正確。

二、數據範圍是否對應。

三、指標的特定條件是否知足。

四、明細與合計是否一致。

 

報表的權限控制

一、肯定報表是否有針對不一樣用戶角色，設置相應查看權限的需求；

二、不一樣的用戶角色，其查看權限是否正確；

報表格式的顯示

一、報表的標題或者表名是否正確；

二、報表的總體顯示格式是否符合客戶提供的表樣；

三、數據顯示格式或偏差是否與需求保持一致，如小位數、百分號、單位、匯率等；

四、報表頁面的時間段是否用戶選擇的時間段；

五、當輸出的內容過多時，分頁方式是否正確；翻頁時，是否有與上頁相同的樣式，第2頁輸出是否正確；

六、須要特別提醒的數據（一些異常數據）是否突出顯示；有些指標計

 

算方法特別或某些指標容易混淆的狀況下，頁面是否有加註釋；

報表功能的使用

一、各個指標的組合篩選查詢是否正常；

二、輸出功能，如導出PDF、excel等使用是否正常；

三、打印設置、打印效果等是否正常；

四、分頁，或分佈導出等是否如常；

五、導常狀況下的使用等。

 

性能

測試的前須要瞭解的信息：用戶訪問的頻率、使用習慣、數據範圍等。

一、數據範圍大小；

二、篩選查詢的響應時長；

三、QPS（即每秒的響應請求數）。

 

數據的有效性

一、當數據源有實時數據入庫時， 相關報表類的展現多久統計出來？

二、是實時仍是會有延緩？延緩多久？

三、數據延緩對指標有何影響？

 

3、針對百度首頁，怎麼去測試？

功能

百度首頁呈現的功能:新聞,網頁,貼吧,知道,音樂,圖片,視頻,地圖,這8個是最主要的;緊接着次要的百科,文庫,hao123,更多;除此以外就是把百度設爲主頁,安裝百度瀏覽器,加入百度推廣,關於百度等等;和用戶相關的還有登陸,註冊.

1.1網頁搜索

百度首頁8個主要功能,排除地圖部分的搜索其餘7個比較相似.這裏主要講網頁搜索,那麼測試的也就是輸入框,比較有效的方法就是邊界值測試和區間測試.

1.1.1邊界值測試

邊界值測試能夠測試一下輸入字符的數量:

a)不輸入文字,直接按搜索

b)輸入38個漢字後點擊搜索按鈕，成功跳轉到搜索結果頁面

c)輸入39個漢字，截取前面38個漢字

d)輸入100個漢字，截取前面38個漢字

e)嘗試輸入101個漢字，沒法成功輸入

f)英文符號的測試

g)空格的測試

複製粘貼38個漢字進入搜索文本框，並中間加入62個連續空格後按下搜索

1.1.2區間測試

a)有意義的關鍵詞作輸入值，預期能搜出結果

b)無心義的關鍵詞作輸入值（好比用臉滾鍵盤來輸入一些亂七八糟的關鍵字），預期搜不出任何結果

那麼對於搜索有個問題就是如何校驗搜索結果的正確性?這裏就再也不適用黑盒測試的方法，能夠嘗試白盒測試或者自動化測試，但是這個校驗算法自己就很難，用什麼規則去定義呢？用另外一套徹底不一樣的搜索邏輯去對比，好比谷歌和百度對比；或者設計一些通用的規則，而後去校驗

2.界面測試

圖片、字體、顏色、按鈕等

3.易用性測試

a)下拉框提示

b)搜索結果頁提示」要找的是否是xxxx「

c)搜索結果頁提示」關鍵字裏去掉引號能夠找到更多xxx「

d)搜索結果頁提示」您輸入的網址是否是xxx「

 

5一、購物車，怎麼測的？

1.功能測試

a）、未登陸時：

將商品加入購物車，頁面跳轉到登陸頁面，登陸成功後購物車數量增長。

b）、登陸後：

全部連接是否跳轉正確；

商品是否能夠成功加入購物車；

購物車商品總數是否有限制；

商品總數統計是否正確；

全選功能是否可用；

刪除功能是否可用；

價格總計是否正確；

商品文字太長時是否顯示完整；

購物車中下架的商品是否有標識，是否還能支付；

新加入購物車商品排序（添加購物車中存在的店鋪的商品和購物車中不存在的店鋪的商品）；

是否支持快TAB、ENTER等快捷鍵；

商品刪除後商品總數是否減小；

收藏功能是否可用；

購物車結算功能是否可用。

2.兼容性測試

BS架構：不一樣瀏覽器測試，好比：IE，火狐，谷歌，360這些。

APP：在主流的不一樣類型，不一樣分辨率，不一樣操做系統的手機上測試，華爲，vivo，oppo等

3.用戶體驗測試

刪除商品是否有提示；

是否支持快捷鍵功能；

是否有回到頂部的功能；

商品過多時結算按鈕是否能夠浮動顯示；

購物車有多個商品時，能不能只對單個商品結算；

界面佈局、排版是否合理；

文字是否顯示清晰；

不一樣賣家的商品是否區分明顯。

4.性能測試

打開購物車頁面要多長時間