1、自我介紹？

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

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

參考答案：專案組解散，待業工資太低了，等不了

公司晉升途徑少：公司框架，都是老員工，新人根本沒有機會晉升，看不到未來的希望，只能為上班而上班，我更希望有一個有餅可以看到的公司，這樣起碼會有奮鬥的動力！不然一直都是一個普通職員，無論是管理崗還是技術崗，都沒有晉升的希望！這對我這麼一個有野心的人非常打擊。

如果繼續問---我們公司也比較小，沒有那麼順利晉升！

參考答案：但是可以學到新技術啊！這對我的軟體測試人生也是一個非常好的肯定！

3、你主要做哪些測試？

功能，介面，效能跟自動化都有一直在做，自動化就相對少一些，主要是功能穩定的模組我們才會寫的，首先，我們會先判斷這個系統能不能實現UI的自動化，如果可以實現的話，我們就會轉化成自動化，一般是優先把冒煙測試轉化成自動化，還有做迴歸測試的時候。

4、你會資料庫嗎？

資料庫我們主要用的是增刪改查，比如：我們在前臺下了一個訂單，除了在使用者中心和系統後臺檢視這筆訂單是否正確，我們也會到資料庫中查詢該訂單的資料是否正確。

5、tomcat的埠在哪設定？

找到tomcat的安裝路徑，進去conf目錄，開啟server.xml檔案,預設是8080埠，修改成要改的埠

6、linux命令背一背？

我們的伺服器都是在linux上的，常用的linux命令都會，比如我們會在linux搭建測試環境，tail -f 來檢視日誌，top來檢視資源等等

6、python熟不熟？

我們python主要是用來寫自動化測試指令碼的，在指令碼中會用到變數的定義，程式碼的封裝，模組呼叫，if條件判斷，try...except異常處理等等。

7、自動化斷言？

assertEqual（兩個值相等）

assertNotEqual

assertTrue（判斷bool值）

assertFalse

assertIsNone

assertIsNotNone（存在）

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

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

7、迭代兩到三週的專案，需求分析要多久，用例寫多久，寫多少用例，執行多久，發現多少個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、專案有沒有上線？

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

11、bug的分佈一般都是怎樣的？那些模組的bug比較多？

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

12、哪些模組的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、你覺得測試是一個什麼樣的職業？

自由發揮

21、談談你對測試的理解

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

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

先熟悉公司的業務流程，做好本職工作，爭取早點成為專案的骨幹成員；工作之外，會進階一下自己的自動化和效能方面的相關技術；

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

23、講一下你做的app專案

講一下簡歷裡面的專案流程還有主要職責

24、你們用例怎麼寫的？

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

25、怎麼編寫測試用例？

覆蓋使用者的需求；

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

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

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

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

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萬次，看它會不會出問題，如果出了問題，我們再定位原因，具體的做法是這樣的：

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

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

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

4、測試完成後檢視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）主流手機的解析度測試。比如（高寬）：1280800、1280720、19201080等

2）不同作業系統的相容性，是否適配。比如，安卓從7.0-9.0

3）不同手機品牌。比如，華為，小米，oppo，vivo等等

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

47、測過那些機型？解析度測試那些？

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

解析度：1280800、1280720、1920*1080等

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

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

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

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

50、有沒有要問我的？

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

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

3.公司有哪些型別的專案在做；專案多長時間一個版本，專案做了多久；專案的測試流程是怎樣的

4.如果可以進入貴公司，我需要在學習哪方面的知識？

51、什麼時候入職，優缺點？

重複

52、講一下專案怎麼測的？

需求文件開始。。。

53、專案上線了？給客戶做的？給自己公司做的產品？

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

54、app多久更新一次？現在還有在做嗎?

差不多2-3週一個迭代，一般產品給到需求都會做

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

拿熟悉的點來講

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

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

57、介面測試怎麼做的？

參考答案：

1、拿到介面文件熟悉：（服務端開發人員把介面文件寫出來，我們就可以拿過來熟悉）：

1）每個介面對應要實現的功能是什麼

2）伺服器的地址、埠、介面地址（確定訪問哪個介面）

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

4）熟悉響應資料：

<1>響應的欄位有哪些

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

2、編寫介面測試用例（介面測試用跟功能類似，只多了一個請求報文，響應報文）

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

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

3、執行測試用例：

我們是用jmeter執行測試用例，先建立一個執行緒組，再新增http請求，填寫好請求地址，埠，和請求引數，設定引數化，新增斷言等，最後新增檢視結果樹再執行。執行完後，檢查介面是否通過，如果不通過，先定位下原因，如果是請求的引數有問題，修改後再進行測試，如果是介面本身存在bug，就把伺服器上的日誌取下來，提單給開發修改。

58、禪道，會搭建不？

1、 把 xampp-win32-1.7.7-VC9.zip 拷貝到C盤下，並解壓到當前資料夾

2、 進入xampp資料夾，把xampp-control.exe傳送到桌面快捷方式

3、 開啟xampp-control.exe，並啟動MySql和Apache，（如果啟動不了，按所給的方案把修改下對應的埠即可把問題解決）。

4、 把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定位區別？

1、語法不一樣；

2、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請求？

步驟：

1、安裝安全證書；

2、點選fiddler的Tools-->options-->https

3、勾選上所有選項，更換證書，重啟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、學習能力強，有哪些提現？

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

76、你覺得測試的價值是什麼？

1.開發人員不能夠完全的發現自己的bug

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

3.測試人員能夠更好的促進專案溝通與反饋

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

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

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

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

79、你們的測試環境，伺服器幾臺？

一般做功能的話，伺服器就一臺，如果做效能的話，會多一些有兩臺web伺服器，一臺DB伺服器

80、app多久更新一次？

需求做完了一兩個月更新一次，如果沒有就算兩週一個版本

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

82、你瞭解我們公司嗎？

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

83、專案大概做了多久，*更新了多久？

84、自己公司做的還是給別人做的產品？

給別人做

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

app在友盟統計可以看到日訪問量，網頁自己在後臺看

86、退貨流程怎麼測的？

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

87、什麼時候上線？版本釋出什麼時候？

（晚上使用者少，出現問題可以馬上去解決迴歸測試。）

88、介面測試出錯了怎麼定位？

首先，我會先檢查一下請求引數啊，還有其他的填入的資料是否有問題，如果這些都沒問題，我會ping一下網路，看網路通不通，如果網路也沒問題的話，我會去看看系統伺服器有沒有啟動，如果伺服器也沒問題的話，那可能就要發給開發定位一下了。

89、介面用例怎麼編寫？

我們每個版本都會有四五個介面需求，有的是新增的介面，有的是原來的介面做了一 些調整，我們會檢視這些介面有哪些引數，每個引數有什麼約束條件，加密方式是什 麼，正常和異常的響應資訊有哪些，然後編寫測試用例來覆蓋這些需求，一個版本下 來大概有五六十條介面測試用例。

90、你在專案有沒有做過什麼提高效率的事情？

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

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

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

例：

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

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

3、使用者需求改變 規避風險：專案整體調整，專案組全員加班

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

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

2、狀態：啟用、已解決、已關閉；

3、先跟開發溝通，確認系統的實際結果是不是和需求有不一致的地方；有些地方可能需 求沒提及，但是使用者體檢不好，我們也可以認為是bug。 如果開發以不影響使用者使用為理由，拒絕修改，我們可以和產品經理，測試經理等人 員進行討論，確定是否要修改，如果大家都一致認為不用改，就不改。

93、Python資料型別有哪些？定義類的關鍵字是啥？

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

可變資料：List（列表）、Dictionary（字典）。

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

                      方法

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

就拿簡歷上的xxx專案來說吧，在編寫指令碼前，我們會對系統進行評估，確認這個系統可不可以實現UI自動化，如果可以的話，就篩選出能實現自動化測試的用例，一般優先把冒煙測試用例的轉為成指令碼。我們是用selenium工具來實現自動化，採用python指令碼語言，基於unittest框架進行用例的編寫。比如，下單這個功能的指令碼，我們是這樣做的：首先，我們會構建一個測試工程，測試工程包含public部分(這裡封裝指令碼公共的內容，比如，開啟瀏覽器，登陸等操作)，testCases（存放測試用例），reports（存放測試報告），runAllCases（用於執行專案自動化用例），指令碼除錯完後，我們會用jenkins持續整合工具，設定指令碼每天晚上8點跑一遍指令碼，跑完後生成html格式的自動化測試報告。

95、自動化指令碼失敗的原因？

1）、可能是測試環境的網路不穩定；

2）、開發修改了程式碼沒通知到測試人員修改指令碼；

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

96、在工作期間，你對公司（專案）有什麼貢獻？

1、引入自動化測試，提高了測試效率

2、在做交叉測試時候，發現了我同事測了幾個版本都沒發現的問題，並且是比較嚴重的那種，我舉個例子吧：使用者修改密碼時，會接受一個手機驗證碼，由於系統沒有對使用者名稱和手機號碼做繫結驗證，接收到驗證碼後，填入別人的使用者名稱可以進入密碼修改頁面，把別人的密碼修改了

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、測試環境的測試資料是怎麼管理的？

功能測試環境的資料，用完了就自己造；效能測試環境的資料，在測試前會先備份一下，迴歸時候再導進來

125、Jmeter做效能測試的工作原理是什麼？

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

126、你能夠把控的風險有哪些？

一般可以把控的風險主要是進度風險、質量風險，進度風險我們之前每天都會開一個晨會，瞭解一下大家的工作進度，如果有風險就會去幫助他，那質量風險我們主要是通過需求評審和用例評審兩個階段來控制

127、購物車涉及到的介面有哪些？

新增購物車介面、庫存查詢介面、下單介面等等

128、專案在資料庫有哪些表？

129、TPS測得多少？（20s）

130、JS的指令碼怎麼呼叫？怎麼上傳檔案？

131、使用者支付完成，金額直接到達商家賬戶？（第三方支付）

132、支付資訊保安性怎麼保證？、

133、優惠卷的型別？

134、App的安裝怎麼測？

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

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

137、怎麼上傳檔案？

138、字串反轉輸出？

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

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

141、Selenium是什麼版本？

142、Mysql和oracle區別？

143、促銷活動有哪些？

144、下單怎麼測？

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

146、Tomcat伺服器怎麼重啟？ ./startup.sh

147、相對併發和絕對併發的使用者比率是多少？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、給你一個報表，你怎麼測？

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

報表資料的正確性

1、資料來源是否正確。

2、資料範圍是否對應。

3、指標的特定條件是否滿足。

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

報表的許可權控制

1、確定報表是否有針對不同使用者角色，設定相應檢視許可權的需求；

2、不同的使用者角色，其檢視許可權是否正確；

報表格式的顯示

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

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

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

4、報表頁面的時間段是否使用者選擇的時間段；

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

6、需要特別提醒的資料（一些異常資料）是否突出顯示；有些指標計

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

報表功能的使用

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

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

3、列印設定、列印效果等是否正常；

4、分頁，或分佈匯出等是否如常；

5、導常情況下的使用等。

效能

測試的前需要了解的資訊：使用者訪問的頻率、使用習慣、資料範圍等。

1、資料範圍大小；

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

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

資料的有效性

1、當資料來源有實時資料入庫時， 相關報表類的展示多久統計出來？

2、是實時還是會有延緩？延緩多久？

3、資料延緩對指標有何影響？

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“

51、購物車，怎麼測的？

1.功能測試

a）、未登入時：

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

b）、登入後：

所有連結是否跳轉正確；

商品是否可以成功加入購物車；

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

商品總數統計是否正確；

全選功能是否可用；

刪除功能是否可用；

價格總計是否正確；

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

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

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

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

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

收藏功能是否可用；

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

2.相容性測試

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

APP：在主流的不同型別，不同解析度，不同作業系統的手機上測試，華為，vivo，oppo等

3.使用者體驗測試

刪除商品是否有提示；

是否支援快捷鍵功能；

是否有回到頂部的功能；

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

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

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

文字是否顯示清晰；

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

4.效能測試

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