請以您以往的實際工做爲例，詳細的描述一次測試用例設計的完整的過程。
回答技巧:這個問題是考驗你在工做前半段是否真的針對你業務進行過測試用例設計,因此回答的時候必定要仔細,而且要從開頭講,也就是從立項會開始講
答案:
首先做爲測試人員,當咱們開完立項會後,須要拿到接下來測試項目的需求文檔,(以及原型圖)進行熟悉的工做,在熟悉完成以後按照需求文檔功能點的順序編寫測試用例(業務比較複雜的建議用x-mind把業務流程畫下來,方便本身往後理解),若是是電商網站或者其它旅遊網站,能夠按照場景法的順序編寫測試用例
若是你的項目是電商,在登陸頁面用戶名,密碼框,能夠用到邊界值測法,等價類劃分法,錯誤推斷法,若是涉及到用戶支付了,能夠使用場景法.說一套具體支付流程,還有就是涉及到帳號,密碼的情況.一旦登陸成功以後,要考慮登陸以後的網址複製到其它瀏覽器或者PC上,是否仍是顯示登陸以後的頁面,這塊開發人員是否有處理.
在測試登陸頁面還要考慮到環境狀況,若是是登陸瞬間沒有網絡以後該怎麼顯示頁面,點擊登陸以後,頁面跳轉時間也要進行測試
因此總結一點,測試項目要考慮到功能,性能,安全等因素
就說最近的此次網站功能的測試吧
首先：獲得相關文檔（需求文檔和設計文檔），理解需求和設計設計思想後，想好測試策略（測試計劃簡單點就OK了），考慮到測試環境，測試用例，測試時間等問題。
第二步：設計測試用例，測試策略是：把網站部分的功能點測試完，而後在進行系統測試（另外個模塊呢有另外一個測試人員負責，能夠進行聯調測試），網站模塊的測試基本是功能測試和界面測試（用戶併發的可能性很小，因此不考慮）：此次的網站的輸入數據呢是使用數據庫中的某張表記錄，若是表中某一數據記錄中新加進來的（尚未被處理的，有個標誌位），網站啓動後會馬上去刷那張表，獲得多條數據，而後在進行處理。處理過程當中，會經歷3個步驟，網站纔算完成了它的任務。有3個步驟呢，就能夠分別對 這3個步驟進行測試用例的設計,儘可能覆蓋到各類輸入狀況（包括數據庫中的數據，用戶的輸入等），得出了差很少50個用例。界面測試，也就是用戶看的到的地方，包括髮送的郵件和用戶填寫資料的頁面展現。
第三步：搭建測試環境（爲何這個時候考慮測試環境呢？由於我對網站環境已經很熟了，只有有機器能空於下來作該功能測試就能夠作了），由於網站自己的環境搭建和其餘的系統有點不一樣，它須要的測試環境比較麻煩，須要web服務器（Apache,tomcat），不過此次需求呢，網站部分只用到了tomcat，因此只要有tomcat便可
第四步：執行測試html
怎樣估計測試工做量？
回答技巧:面試官問這個問題,能夠說在你寫測試計劃的時候,工做量就會考慮到,工做量直接影響到你的測試周期
答案:
需求分析: 分析該項目測試所用到的技術(功能,安全,接口)
效率假設：即測試隊伍的工做效率。對於功能測試，這主要依賴於應用的複雜度，
窗口的個數，每一個窗口中的動做數目。對容量測試，主要依賴於創建測試 所需數據的工做量大小。是否須要進行數據庫表的數據比對
測試假設：爲了驗證一個測試需求所需測試動做數目。
應用的維數：應用的複雜度指標。例如要加入一個記錄，測試需求的維數就是這個
記錄中域的數目。
開發人員認知:好比你負責的開發人員的水平問題,開發人員技術好,業務能力強的BUG就少,技術通常的業務差的要適當延長,總之項目開發人員的水平也會影響到你的工做量
是否須要其它人員配合測試:例如手機註冊,有可能會用到公司其它員工的手機號
所處測試周期的階段：有些階段主要工做都在設計，有些階段主要是測試執行。
其實這個工做主要由測試組長來考慮,若是公司公司就你一個測試,那就要本身也懂才行前端
進行測試時產生了哪些文檔或記錄？
技巧:這個也是判斷面試人員是否真的工做過,要對每一個文檔有深刻的理解,不能光說有哪些就好了,而是要把這些文檔存在的意義講出來才專業
答：測試的整個過程有系統測試計劃(主要代表接下來測試的具體分工,時長,環境,所用到的軟硬件,預估測試環境,預發佈環境,正式環境的時間安排,測試所用到的技術)、系統測試用例、系統測試報告(分日報,階段報告,這2個我會着重講)、缺陷報告、產品發佈說明,產品使用手冊
在執行測試的過程當中 只有缺陷報告，這個仍是用在缺陷管理工具中進行的，最後在工具中導出缺陷報告.python
fiddler工具怎麼使用？https如何抓包？會不會用postman，主要是用來測試什麼的？
技巧:Fiddler不只能夠在web端進行抓包,也能夠在移動端進行抓包工做
Fiddler是一個很好用的抓包工具，能夠將網絡傳輸發送與接收的數據包進行截獲、重發、編輯等操做。也能夠用來檢測流量。
Fiddler安裝後，設置的端口默認爲8888，當Fiddler啓動後，默認將IE的代理設爲了127.0.0.1:8888，而其餘如火狐瀏覽器須要手動設置代理後才能夠抓包。設置內容如圖：
1）要使用Fiddler進行抓包，首先須要確保Capture Traffic是開啓的 （安裝後是默認開啓的），勾選File->Capture Traffic，也能夠直接 點擊Fiddler界面左下角的圖標開啓和關閉抓包。
2）因此基本上不須要作什麼配置，安裝後就能夠進行抓包了。那麼咱們 怎麼分析抓到的這些數據包呢？如圖所示的區域爲數據包列表，要分析 這些數據包，首先要了解各字段的含義。
3）每一個Fiddler抓取到的數據包都會在該列表中展現，點擊具體的一條 數據包能夠在右側菜單點擊Insepector查看詳細內容。主要分爲請求 （即客戶端發出的數據）和響應（服務器返回的數據）兩部分
5.接口自動化怎麼測的?遇到問題怎麼分析的
1.在熟悉業務基礎上,要測試接口,開發會先給api文檔,一個URL對應了不少json字段或者xml字段,要清楚請求發送的字段和響應的字段的意思,若是響應的數據與api文檔一致,則證實該接口首先是通的,再者接收數據正確,那麼這個接口經過
自動化接口測試,就是先將這些接口單個測通以後,再完整的串起來測試,若是沒有問題,就能夠編寫自動化測試腳本了git
6.場景題：給你一個自行車，你怎麼測試？
技巧:面試官問你XXX怎麼測,那基本都會從兼容性,性能,安全,自動化等角度去闡述
測自行車……最好的方法就是親自去騎了。
由於只有親自去騎，才知道舒不舒服，看是看不出來的——這叫友好性測試。
讓矮子騎完高個騎，山地騎完公路騎，看看是否能勝任——這叫兼容性測試。
蹬蹬輪子、剎剎閘，調調座椅和車把，看看是否性能佳——這叫功能性測試。
你自己就不瘦，後座還要馱一個胖子，看看是否不爆胎——這叫壓力測試。
毎當結構有變更，加個螺絲填個冒兒，大家就得從新測——這叫迭代測試。
自行車還沒造好呢，你就開始騎了，bug你也沒少提啊——這叫敏捷測試。
你發明了個機器人在軌道上騎自行車，看看有沒有問題——這叫自動化測試。（機器人是封裝好的類庫，騎是調用類庫中的方法，軌道是框架）
自行車在出場以前,重量,尺寸,材料強度等是否達標 —這叫功能測試程序員
7.你對軟件週期瞭解嗎,你是怎樣看待軟件週期的？常見的軟件生命週期模型有哪些？
技巧:這個問題通常從在於你以前對工做中的軟件開發流程有沒有深入的認知,軟件從無到有的一系列過程是否說的詳細,因此個人建議是要從工做的角度去談,這樣更讓人可以信服.儘可能能夠結合本身的項目去講(從無到有)
軟件生命週期是指一個計算機軟件從功能肯定、設計，到開發成功投入使用，並在使用中不斷地修改、增補和完善，直到中止該軟件的使用的全過程（從醞釀到廢棄的過程）
生命週期從收到應用軟件開始算起，到該軟件再也不使用爲止。它有以下各方面的內容：初始構思、需求分析、功能設計、內部設計、文檔計劃、測試計劃、文檔準備、集成、測 試、維護、升級、再測試、逐步淘汰 (phase-out)、等等
瀑布模型，迭代式模型，快速原型模型，螺旋模型web
8.什麼是版本控制，經常使用的版本控制系統有哪些？(git後期咱們會學習)
技巧:版本控制說白了就是無論是開發,測試,UI,運維,產品這些崗位,你們都會在項目的同一個版本進行各方面的工做,保證每一個項目在更新迭代以前,你們的業務以及工做文檔都處在同一節點上,避免版本不一致所形成的項目混亂,拖延項目總體的進度面試
版本控制（Revisioncontrol）是一種軟體工程技巧，籍以在開發的過程當中，確保由不一樣人所編輯的同一檔案都獲得更新。
Git(讀音爲/g?t/。)是一個開源的分佈式版本控制系統，能夠有效、高速的處理從很小到很是大的項目版本管理。Git 是 Linus Torvalds 爲了幫助管理 Linux 內核開發而開發的一個開放源碼的版本控制軟件。https://git-scm.com/doc
SVN是Subversion的簡稱，是一個開放源代碼的版本控制系統，相較於RCS、CVS，它採用了分支管理系統，它的設計目標就是取代CVS。互聯網上不少版本控制服務已從CVS遷移到Subversion。https://tortoisesvn.net/support.html數據庫
9.APP 測試的內容主要包括哪些，如何開展?
技巧:能夠從功能,性能,兼容性,安全角度去講,若是本身的項目是APP項目,不只要講APP上的測試,還要講跟APP對標的後臺也要進行測試,一般後臺會操縱APP,無論是功能仍是數據,都會有關聯.注意一點,APP項目前端後端都要說.json
如何開展:和正常的項目基本一致,商務談好合做項目,拿到需求.UI先作原型圖,產品寫需求文檔,接下來開立項會,開完以後,移動端開發,後臺開發,測試寫用例,開發提測後,測試人員介入,進行測試,測試版本OK,提交到正式版本,迴歸測試完成就能夠上線了後端
注意:正式環境的數據不能亂造,還有就是開發改完BUG以後,須要在測試機上從新打包,測試才能複測.
安卓端,APP通常上線的地方(騰訊應用寶,豌豆莢市場,華爲市場等),可是APP上線以前須要這些提供平臺的商家要進行審覈,審覈經過才能上線
IOS端,APP上線的地方(appstore) 由美國蘋果公司進行對APP的審覈,經過以後才能上線
功能測試:
1.業務邏輯正確性測試:依據:產品文檔+原型圖->測試用例編寫
兼容性測試: 1.系統版本:Android:官方版本,定製版本;IOS:官方提供版本 2.分辨率:720 * 1280 1080* 1920
3.網絡狀況:2g 3g 4g 5g Wi-Fi
異常測試 1.熱啓動應用:應用在後臺長時間待機;應用在後臺待機過程當中，手機重啓 2.網絡切換和中斷恢復:網絡切換;中斷恢復:
3.電話信息中斷恢復
升級，安裝，卸載測試 1.升級測試:臨近版本升級(1.0->1.1);跨版本(1.0->…->2.2) 2.安裝測試:首次安裝;覆蓋安裝(同版本，不一樣版本覆蓋);卸載後安裝 3.卸載測試:首次卸載;卸載安裝後在卸載
健壯性測試
1.手機資源消耗:cpu，內存
2.流量消耗:圖片，數據，視頻
3.電量測試
4.崩潰恢復
在項目的系統測試過程當中，測試負責人要及時瞭解測試進度，跟蹤BUG提交、修復及驗證狀況以及系統的拷機狀況。
在開發初期階段，測試組在構建功能模塊時，不少模塊、功能點的開發完成進度和原計劃會存在必定的誤差，就須要測試負責人動態的刷新計劃表，根據實際的開發進度調整測試計劃。
在開發階段，存在版本編譯不出來致使沒法測試，開發人員修復代碼太隨意致使版本穩定性反覆，需求變動過大致使後端測試開發變動嚴重等現象，會致使測試工做沒法正常進行。就須要測試負責人及時反饋出來，根據項目自己的特色進行對應的處理。
當測試進度出現延期時，要及時確認問題緣由，若是是問題協查致使，則需及時與研發人員進行溝通協商，看問題是否必須在測試環境進行排查，若爲必現問題可與研發協商要求其在本身環境進行排查，若必須佔用測試環境，則需及時調整測試計劃，若所以可能影響版本的發佈，則應及時與SE確認。
若發現有較多BUG未解決，則應主動聯繫SE(項目負責人)及研發人員召開BUG會肯定問題的解決時間。若發現有較多BUG未驗證，則應提醒項目組的測試人員及時進行驗證，對於一些拷機或非必現的BUG，建議測試人員在此BUG上現作拷機標記，連續拷機一週未再復現的作關閉處理，若再次復現則繼續進行排查。
疑難問題的跟控：比較難復現的問題，怎麼去嘗試復現。比較難定位的問題，怎麼驅動、反饋給SE，協調開發人員定位問題。比較難處理的問題，怎麼跟控反饋進度等。
天天下班前需確認拷機內容，天天上班第一件事需確認拷機結果，只有這樣才能保證拷機的效果，實現拷機的真正意義。
你遇到過哪些狀況可能到時漏測,後來大家又是如何改進的呢？
漏測的緣由分析有如下的幾個方面：
1.需求評審質量低，或參評人員能力不足，或過程不規範嚴謹
2.需求變動頻繁，測試用例無及時更新
3.用例設計的過於粗獷，測試步驟不清晰
4.測試用例對需求的覆蓋面不全，考慮不足
5.測試人員測試思惟侷限，無思考全面
6.需求文檔和原型圖有出入,而且沒有及時找產品和UI進行確認,按照本身的想法去測
防止漏測或改進措施:
1.測試人員測試思惟和測試意識的提升
2.測試環境要儘可能貼近生產環境
3.測試執行過程的規範性、嚴謹性和策略性
4.需求評審質量的提升
5.測試用例質量的提升
6.若是是有大規模的客戶羣體,測試更多的要站在用戶的角度去思考,而不光侷限於需求文檔
12.一個有廣告的紙杯子，請問你會如何設計測試用例？
技巧:這種問題在面試中很容易被問到,因此就按照下方的答案去說就能夠了,面試官主要考驗你的基本功.
首先，問問面試官是否有需求，若是沒有需求就從界面測試，功能性，安全性，可移植性，兼容性等等方面去測試。如下是測試內容範例：
測試項目：杯子
需求測試：查看杯子使用說明書
界面測試：查看杯子外觀
功能度：用水杯裝水看漏不漏；水能不能被喝到, 既然是廣告被子,也要測試廣告印刷是否清晰,印刷圖案或字體是否會掉色的狀況
安全性：杯子有沒有毒或細菌
可靠性：杯子從不一樣高度落下的損壞程度
可移植性：杯子再不一樣的地方、溫度等環境下是否均可以正常使用
兼容性：杯子是否可以容納果汁、白水、酒精、汽油等
易用性：杯子是否燙手、是否有防滑措施、是否方便飲用
用戶文檔：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述
疲勞測試：將杯子盛上水（案例一）放24小時檢查泄漏時間和狀況；盛上汽油（案例二）放24小時檢查泄漏時間和狀況等
壓力測試：用根針並在針上面不斷加劇量，看壓強多大時會穿透
跌落測試: 杯子加包裝(有填充物),在多高的狀況摔下不破損
震動測試: 杯子加包裝(有填充物),六面震動,檢查產品是否能應對惡劣的鐵路\公路\航空運輸
13.一個身份證號碼輸入框，怎麼設計用例？
技巧:測試基本功,能夠用邊界值,等價類劃分的狀況去考慮
校驗身份證號規則的有效性（包括地址碼、生日期碼、順序碼和校驗碼）
校驗15位身份證號和18位身份正好都是可用的
校驗末位是X的狀況
校驗不足15位、16-17位和大於18位的狀況
若是是必輸項，校驗不輸入的時候會不會有正確的提示
若是不是必輸項，則要校驗不輸入的時候流程可否正常進行
校驗輸入非數字的狀況，是否會有正確提示信息（包括大小寫字母、漢字、特殊字符和標點符號）
校驗輸入全角的數字的時候，系統是否會識別（這個得根據需求肯定是否能夠使用全角的數字）
14.你能說一下你瞭解的軟件缺陷的生命週期嗎？
技巧:這個問題簡單來講BUG從無到有,再到close的過程
測試人員提交新的 Bug 入庫，錯誤狀態爲 New。 高級測試人員驗證錯誤，若是確 認是錯誤，分配給相應的開發人員，設置狀態爲 Open。若是不是錯誤，則拒絕，設置爲 Declined(拒絕)狀態。 開發人員查詢狀態爲 Open 的 Bug，若是不是錯誤，則置狀態爲 Declined；若是是 Bug 則修復並置狀態爲 Fixed。不能解決的 Bug，要留下文字說明及保持 Bug 爲 Open 狀態。對於不能解決和延期解決的 Bug，不能由開發人員本身決定，通常要通 過某種會議（評審會）經過才能承認。 測試人員查詢狀態爲 Fixed 的 Bug，而後驗證 Bug 是否已解決，如解決置 Bug 的狀態爲 Closed，如沒有解決置狀態爲 Reopen。
有些狀況,項目爲了上線,一些不重要的BUG 會推到下個版本去解決,因此軟件缺陷生命週期會被延長
15.若是一個缺陷被提交後，開發人員認爲不是問題，怎麼處理？
技巧:說白了就是怎麼處理BUG在測試和開發意見不一致的狀況下,測試如何解決問題
a)首先，將問題提交到缺陷管理庫裏面進行備案。
b)而後，要獲取判斷的依據和標準：
v.根據需求說明書、產品說明、設計文檔等，確認實際結果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據；
vi.若是沒有文檔依據，能夠根據相似軟件的通常特性來講明是否存在不一致的地方，來確認是不是缺陷；
vii.根據用戶的通常使用習慣，來確認是不是缺陷；
viii.與設計人員、開發人員和客戶表明等相關人員探討，確認是不是缺陷；
c)合理的論述，向測試經理說明本身的判斷的理由，注意客觀、嚴謹，不參雜我的情緒。
d)等待測試經理作出最終決定，若是仍然存在爭議，能夠經過公司政策所提供的渠道，向上級反映，並有上級作出決定。
17：軟件測試在產品的各個階段都作什麼？
技巧:這個問題直接能夠判斷你是否真正的工做過,若是工做過這些都是脫口而出的,因此按照下方的答案就差不了多少.
一、規劃階段：
測試人員從一個更高的角度對產品的規劃提出本身的想法，來更好的幫助產品取得成功。
還要考慮從以往工做經驗,如何更高效,更精準的對產品進行測試
二、需求階段：
測試人員開始作需求階段的缺陷預防，保證需求是可以知足用戶的原始需求，而且整個需求都是很是清晰和合理的，版本後期沒有需求不合理或者需求不清晰的問題。並且根據產品提供的需求要考慮到,部分功能它的深度和覆蓋率狀況
三、設計階段：
測試人員開始作設計階段的缺陷預防，可以對於研發的整個設計方案很是清楚，可以根據研發設計文檔裏面的業務邏輯圖本身可以站在測試的角度來畫出一份讓測試人員更加容易理解的業務邏輯圖，而且可以發現研發在設計方案上存在的一些問題，而且指導研發進行修改。
四、測試階段：
測試人員開始制定測試策略和測試計劃、執行測試用例、發現和定位bug、跟蹤和迴歸bug，質量分析，有效的探索性測試等等，目的是花更短的時間來更好的保證質量。而且在項目上線事後或者以前,有可能還要作性能和壓力測試
五、編碼階段：
測試人員開始編寫單元測試、接口測試用例、測試工具或者自動化測試用例，而且開始思考後面如何去更好的測試（更高的效率，更好的保證質量），而且幫助研發提早作好編碼階段的缺陷預防，甚至作得測試驅動開發。
18.描述一下訪問網頁的過程
23.你認爲怎樣纔算是一位好的測試人員？
良好的溝通、責任心、持續的努力、積極主動、對本身有信心淡定的心、與時俱進
還有一點就是通過你手的產品,上線以後客戶滿意度高,反饋差評幾乎沒有的,纔是對你測試工做最好的認證
24.BUG的等級分爲哪些？請依照等級舉例
技巧:能夠說從嚴重到普通(P0,P1,P2,P3或者S0,S1,S2,S3) ,這個能夠按照本身想的說,可是嚴重等級通常最多分爲4級足夠了
舉例:P0(系統奔潰,閃退,軟件沒法打開,有關於金錢,利息的BUG均可以) P1(部分功能目前沒法正常運行) P2(頁面跳轉錯誤,一些輸入框沒有經驗校驗等) P3(UI顯示有問題,排版,錯別字,地址錯誤等)
（1）最高優先級，例如，軟件的主要功能錯誤或者形成軟件崩潰，數據 丟失的缺陷。
（2）較高優先級，例如，影響軟件功能和性能的通常缺陷；
（3）通常優先級，例如，本地化軟件的某些字符沒有翻譯或者翻譯不 準確的缺陷；
（4）低優先級，例如，對軟件的質量影響很是輕微或出現概率很低的 缺陷。
1.在完成某項工做時，你認爲領導要求的方式不是最好的，本身還有更好的方法，你應該怎麼作？
回答提示：①.原則上我會尊重和服從領導的工做安排，同時私底下找機會以請教的口吻，婉轉地表達本身的想法，看看領導是否能改變想法。②若是領導沒有采納個人建議，我也一樣會按領導的要求認真地去完成這項工做。③.還有一種狀況，假如領導要求的方式違背原則，我會堅定提出反對意見，如領導仍執拗己見，我會絕不猶豫地再向上級領導反映
2.你對薪資的要求？
技巧:談薪資的話能夠根據你面試的狀況來講,若是面試的比較好能夠在他們給出薪資空間的中上等,若是面的很差能夠給出中下等(前提是你想要進入這家公司)
若是你對薪酬的要求過低，那顯然貶低本身的能力；若是你對薪酬的要求過高，那又會顯得你份量太重，公司受用不起。一些僱主一般都事先對求職的職位定下開支預算，於是他們第一次提出的價錢每每是他們所能給予的最高價錢，他們問你只不過想證明一下這筆錢是否足以引發你對該工做的興趣。
3.若是公司錄用你，你將怎樣開展工做？
若是是測試崗位:進公司先安裝公司的軟件或者環境,再熟悉項目,熟悉完項目就能夠作領導分配的工做內容了.
不少企業在招聘開發人員時很看重是否可以儘快上手，因此回答這個問題時要「實打實」的回答，在回答中最好強調可以「儘快」投入開發工做中，這樣領導就放心了，會以爲你不是一個只會盲目工做的人，而是一個循序漸進，穩打穩紮的人。
4. 你將來3-5年的職業規劃是怎樣的？
技巧:從技術角度講,來貴公司工做,一個是掌握公司的業務,另一方面會提高我的技術,把本身的技術運用到公司項目上,將來幾年,本身會朝着測試開發工程師,高級測試工程師的方向發展.
大部分面試官司都會問你是否有職業規劃，這個問題的背後是瞭解你的求職動機和對本身中長期職業發展的思考。在回答這個問題以前，要對本身有個清晰的認識，知道本身想往哪一個方向發展以及將來有什麼計劃，要給面試官一種積極向上，好學上進，有追求，有規劃的感受，面試官喜歡有規劃的求職者。
5：你爲何離職？
回答提示：
回答這個問題時必定要當心，就算在前一個工做受到再大的委屈，對公司有多少的怨言，都千萬不要表現出來，尤爲要避免對公司自己主管的批評，避免面試官的負面情緒及印象。建議此時最好的回答方式是將問題歸咎在本身身上，例如以爲工做沒有學習發展的空間，本身想在面試工做的相關產業中多加學習，或是前一份工做與本身的生涯規劃不合等等，回答的答案最好是積極正面的。
回答參考：
我但願能得到一份更好的工做，若是機會來臨，我會抓住。我以爲目前的工做，已經達到頂峯，即沒有升遷機會。
還能夠說因爲家庭緣由離職,家裏的親人的工做變更影響到你等,或者公司搬家
6：若是你在此次面試中沒有被錄用，你怎麼打算？
技巧:要常常自我總結,本身之因此沒面試上,問題是出在哪一個環節了,彌補本身的不足爭取在下一次面試中改掉這些問題.
還有一個就是調整本身的心態,不要氣餒,要敢於面對,有一個積極的心態找工做纔是你能面試上的最大保障
回答提示：
如今的社會是一個競爭的社會，從此次面試中也可看出這一點，有競爭就必然有優劣，有成功一定就會有失敗。每每成功的背後有許多的困難和挫折，若是此次失敗了也僅僅是一次而已，只有通過經驗經歷的積累才能塑造出一個徹底的成功者。我會從如下幾個方面來正確看待此次失敗：①要勇於面對，面對此次失敗不氣餒，接受已經失去了此次機會就不會回頭這個現實，從心理意志和精神上體現出對此次失敗的抵抗力。要有自信，相信本身經歷了此次以後通過努力必定能行，可以超越自我。②善於反思，對於此次面試經驗要認真總結，思考剖析，可以從自身的角度找差距。正確對待本身，實事求是地評價本身，辯證的看待本身的長短得失，作一個明白人。③走出陰影，要克服這一次失敗帶給本身的心理壓力，時刻牢記本身弱點，防患於未然，增強學習，提升自身素質。④認真工做，回到原單位崗位上後，要實實在在、踏踏實實地工做，三十六行、行行出狀元，爭取在本崗位上作出必定的成績。⑤再接再礪，成爲國家公務員一直是個人夢想，之後若是有機會我仍而後再次參加競爭。
7：如何安排本身的時間？會不會排斥加班？
技巧:若是被問到加班狀況,要拿出高配合度才行,通常都會說能夠接受加班
但實際有些面試官這樣問你,只是想看你對加班的態度是怎樣的,但有些是真的須要加班了.因此在面試以前能夠經過網絡瞭解下你去面試的公司
回答提示：基本上，若是上班工做有效率，工做量合理的話，應該不太須要加班。但是我也知道有時候很難避免加班，加上如今工做都採用責任制，因此我會調配本身的時間，全力配合。
分析：雖然不會有人心甘情願的加班，但依舊要表現出高配合度的誠意
8：在五年的時間內，你的職業規劃？
回答提示：這是每個應聘者都不但願被問到的問題，可是幾乎每一個人都會被問到，比較多的答案是「管理者」。可是近幾年來，許多公司都已經創建了專門的技術途徑。這些工做地位每每被稱做「顧問」、「參議技師」或「高級軟件工程師」等等。固然，說出其餘一些你感興趣的職位也是能夠的，好比產品銷售部經理，生產部經理等一些與你的專業有相關背景的工做。要知道，考官老是喜歡有進取心的應聘者，此時若是說「不知道」，或許就會使你喪失一個好機會。最普通的回答應該是「我準備在技術領域有所做爲」或「我但願能按照公司的管理思路發展」。
9.請介紹一下你本身
個人模板:
我叫XX，今年X歲，XXXX年畢業於XX大學(這個可說可不說)。有3年的測試工做經驗，在這3年裏面我從事了哪幾家公司,作了哪些項目(只須要說名字就能夠了),我日常空餘時間喜歡看看技術類文章,與朋友一塊兒交流,今天很是高興來到貴公司面試,謝謝!
這是面試官100%會問的問題，通常人回答這個問題過於日常，只說姓名、年齡、愛好、所學專業等，若是你用一分鐘來重複你的簡歷，那麼，你的印象加分沒有了！
不妨坦誠自信地展示自我，重點突出與應聘職位相吻合的優點。你的相關能力和素質是企業最感興趣的信息。由於，在許多狀況下，在聽取你的介紹時，面試官也會抓住他感興趣的點深刻詢問。因此，在進行表述時，要力求以真實爲基礎，顧及表達的邏輯性和條理性，避免冗長而沒有重點的敘述。必定要在最短的時間內激發起面試官對你的好感。
回答範例：我叫XX，今年X歲，XXXX年畢業於XX大學。有3年的開發工做經驗，我對技術有深厚的興趣，專業知識面寬，責任心強，思路清晰，溝通力能好，精通.Net技術體系，熟悉MVC。日常有時間看看博客，而且本身也喜歡在CSDN上寫技術類的文章，與博友一塊兒討論。謝謝！
10.談談你對跳槽的見解？
回答提示：①正常的「跳槽」能促進人才合理流動，應該支持。②頻繁的跳槽對單位和我的雙方都不利，應該反對。
十一、最能歸納你本身的三個詞是什麼？
回答提示：我常常用的三個詞是：適應能力強，有責任心和作事有始終，結合具體例子向主考官解釋，
若是是問我:直接會說五個字:程序員終結師
十二、你的業餘愛好是什麼？
回答提示：找一些富於團體合做精神的，這裏有一個真實的故事：有人被否決掉，由於他的愛好是深海潛水。主考官說：由於這是一項單人活動，我不敢確定他可否適應團體工做。
1三、說說你對行業、技術發展趨勢的見解？
技巧:這個問題首先須要你瞭解你面試的公司他在哪一個領域,而後根據這個領域來講該公司之後發展好的狀況下會是什麼樣的等等.爲了公司的將來,我會努力工做,提高業務水平以及我的技術
回答提示：企業對這個問題很感興趣，只有有備而來的求職者可以過關。求職者能夠直接在網上查找對你所申請的行業部門的信息，只有深刻了解才能產生獨特的看法。企業認爲最聰明的求職者是對所面試的公司預先了解不少，包括公司各個部門，發展狀況，在面試回答問題的時候能夠提到所瞭解的狀況，企業歡迎進入企業的人是「知己」，而不是「盲人」。
1四、你一般如何處理別人的批評？
回答提示：①沈默是金，沒必要說什麼，不然狀況更糟，不過我會接受建設性的批評。②我會等你們冷靜下來再討論。
1五、談談如何適應辦公室工做的新環境？
回答提示：①辦公室裏每一個人有各自的崗位與職責，不得擅離崗位。②根據領導指示和工做安排，制定工做計劃，提早預備，並按計劃完成。③多請示並及時彙報，遇到不明白的要虛心請教。④抓間隙時間，多學習，努力提升本身的政治素質和業務水平。
1六、你怎麼理解你應聘的職位？
技巧:首先我是個專業的測試工程師,因此看到這個測試崗位,我認爲如下幾點是必須掌握的
1熟知測試基本理論, 掌握經常使用測試工具、軟件測試流程及各項規範，能進行測試需求分析，編寫測試用例
2熟悉python,對於不管是UI自動化仍是接口自動化我均可以勝任
3邏輯能力強、思惟活躍，接受新事物能力強
4具備WEB/APP應用測試經驗，熟悉經常使用的測試工具和Bug管理跟蹤軟件，版本控制軟件
還有一點就是要體現本身溝通能力強,工做認真細緻等
回答提示：把崗位職責和任務及工做態度闡述一下。
工做流程: 咱們公司接到新項目以後,由產品經理組織開需求評審會,主要講了這個項目的功能,咱們在進行討論(測試討論的內容針對這個模塊測試的覆蓋面和深度等問題),當需求評審 會開完以後,編寫測試計劃,並熟悉項目,熟悉完成以後接下來就開始編寫測試用例,測試用例寫完以後,開一個測試用例評審會,主要由開發產品測試,UI人員參加,主要講個人測試用例,再開發提測以後我就介入進來,先執行冒煙測試,再執行測試用例對產品進行總體測試,發現BUG,提交缺陷報告,開發改完以後再複測,走完以後,在進行迴歸測試,迴歸測試經過以後上線到正式環境,在這之中要編寫階段測試報告(不懂的百度查),上到正式環境以後,再執行幾輪的迴歸測試,迴歸事後OK,撰寫上線報告,而後就能夠上線了 注意:這個上線有多是內部更新迭代,也有多是真的上線了