功能測試面試指南
功能測試求職者要想要取得面試成功，掌握面試指南很重要，下面陽光網小編已經為你們整理了功能測試面試指南,希望可以幫到你。
你將和誰交談?
在面試中，你通常會遇到三種角色。這些角色會是一個人或者多個人，取決于公司的大小：
軟件工程師
工程師經理(技術 leader，中級經理，總監)
高層領導(VP， CTO， CEO， 部門經理)
對每一個角色我都有不同的問題，我將在下面一一列出來。注意我有時會重復用同一個問題問不同的角色然后看看他們的回答有何不同。
這是一篇很長的文章，所以它的意義更多是作為參考，而不需要通篇細讀。如果我今天要去參加面試，我會帶著這篇文章并在面試期間參考一下。
這些問題中的多數都沒有一個“正確”或者“錯誤”的答案。它們是用來幫助你了解這家公司、以及其文化、流程和組織。它們通常也作為交談的開始，這在你面試中出現大腦短路時非常有用。
作為禮貌，我常常在面試一開始就告訴面試官我希望有一點時間來提問。這有助于他們合理安排時間。通常，他們會在面試的最后讓我提問，所以注意面試的時間安排，也讓他們提前意識到你的意圖。問完每一個問題，停頓一下，問一下面試官你是否可以繼續提問以及面試還剩余多長時間。
軟件功能測試工程師的問題
1、每天你怎么知道需要做什么事情?
這個問題的目的是確認功能缺失。我希望從2-3名工程師哪里獲得答案。如果公司的領導說他們遵循特定的流程，但是工程師卻不談這個流程，那是一個功能缺失的跡象。如果從不同的工程師那里得到不同的答案，那是另一個功能缺失的跡象。
在一個高質量的團隊中，這個問題我所得到的回答是一致的。每一個開發者都知道這個流程，并且這個流程足夠輕量級到對工程師提供幫助而不是壓制他們。
好的回答示例(還有許多其他的)：“我們會制定 N-星期的 sprint，在每一個 sprint 中工程師會提交一系列的功能和 bug 修復最終交付。每一天我們會相互匯報進度。我們有一位出色的產品經理負責和客戶交涉，以保證我們優先開發功能和修復 bug。”
不好的回答示例(還有很多其他的回答)：“我到辦公室然后看看哪里需要救火。大多數時候我都被緊急情況中斷。”
注意我沒有提到 “Scrum” 或者其他特定的方法。相比實際的日常開發怎么完成，我對公司在他們的過程中所使用的標簽沒什么興趣。
2、你用什么來做版本管理?
好的工具是好的團隊的一個指示。如果一個團隊在使用一個古老的版本控制系統，他們也許還在使用一堆其他過時的工具。而且，他們可能不重視良好工具投資所獲得的效率提升。
緊接著一個很好的問題是關于工作流。你使用分支嗎?你喜歡使用 rebasing 還是 merging(git 術語)?這些問題會告訴你他們所選的工具有多么專業，這將會告訴你很多他們的熟練程度，反過來告訴你如果你接受這項工作，將會有什么期待。例如，你將是“本地的 git 專家” 還是你將向名副其實的 Linus Torvalds 學習?
這個問題可以引發一場通用工具的討論，這通常會給你一些好的見解。
3、在這里工作你喜歡的是什么?
強回答：我從我的工作中獲得許多滿足。
強回答：在工作中我們有很多樂趣。
強回答：我喜歡和真正聰明、友好的合作者一起工作。
強回答：管理尊重工程師。
強回答越多越好。我不必獲得以上全部回答來給公司打高分。請記住，有些人不是自然而然的“裝腔作勢”，所以在這里你可能不會獲得精彩的反應，這可能是正常的。
但是如果我聽到了類似以下的回答，并且沒什么強回答，我會擔心：
弱回答：它付我工資。
弱回答：我不需要很努力的工作。
弱回答：這里交付沒有太大壓力。
弱回答：即使我犯了大的錯誤也不要緊。
弱回答：(沉默)
不要以為是我想象的這些回答。我在真實的面試中聽到過這些回答。
我不會聽到這些弱回答就自動將這家公司看成不好的公司，但是如果只有這些回答，我通常不會考慮這里。
4、你寫單元測試嗎?
在通過一個團隊的單元測試實踐對他們做出結論時要很小心。如果在我問道單元測試時一個團隊非常興奮，這通常是一個好的跡象。另一方面，如果他們不能解釋為什么要使用單元測試，或者說單元測試的缺陷時，這是盲羊教條的一個跡象。如果他們提供一些不好的理由來解釋為什么不寫單元測試，如“我們沒有時間”，那對我而言是一個不好的信號。
如果工程師告訴我他們會寫單元測試，并且他們嘗試告訴我單元測試的考量，比如需要多長時間來運行單元測試，他們有多少測試用例，以及代碼覆蓋率等，那對我是非常有吸引力的。這告訴我他們有很好的工具，并且他們知道怎么使用這些工具。另一方面，如果他們相信100%的代碼覆蓋率就能保證代碼中沒有 bug，我表示懷疑。
我想提前知道在這家公司我是否會在一套龐大、陳舊、無法測試的代碼上工作。這將幫助我管理自己的預期，并且決定是否接受這份工作。
后續問題：
你喜歡單元測試還是集成測試?
你們有驗收測試嗎?
你使用什么(哪些)測試框架?你喜歡嗎?
你的單元測試需要耗費多長時間?
5、你使用持續集成嗎?
我所知道的最好的軟件開發團隊使用 Jenkins， Travis， Buildbot 等工具。如果這個團隊沒有持續集成，我嘗試了解他們是否熟悉這個概念。如果他們不熟悉這個概念，以我的經驗這是一個不好的跡象。使用持續集成意味著這個團隊也許信奉自動化，以我的經驗這通常是一個很好的跡象。
對于有的團隊，這自然會引導到持續發布的討論，這是一個和持續集成相關但是又不同的概念。如果是一個 web 開發者職位，我希望這個團隊至少聽說過持續發布，強的團隊應該使用持續發布，至少有一部分在使用。
后續問題：
當 CI 報告失敗時，你們的團隊需要多長時間來修復?
你喜歡/不喜歡 CI 系統的哪一點?
你們的 CI 運行一次需要多長時間?你有讓它更快一些嗎?
6、你們怎么測量?
這是一個開放問題，主要是看看這個團隊是否花精力去測量他們的軟件。對于 web 開發團隊，答案傾向關注性能，如響應時間、請求吞吐量、用戶數量、客戶端反應靈敏度等。但是也可以討論使用不同語言的用戶數、瀏覽器故障、緩存命中率等無數其他的事情。如果一個團隊沒有花時間去測量，很有可能他們沒有根據真實數據來做決定。他們可能已經提前優化。我重視使用真實數據來做決定的團隊，尤其是有關性能方面，但是它適用于很多其他方面。
如果面試官知道這些問題中多數答案，那是一個很好的信號說明這是一個優質的團隊。如果他們對為什么要關注這些測量沒有任何主意，這是一個負面的信號。
再次聲明，教條主義同樣適用于此。如果一個團隊看起來已經鎖定了一些不會產出價值或者可操作信息的測量指標，并且不能對此給出滿意的解釋，這可能是一個警告信號。
后續問題：
你們產品最重要的測量指標是什么?
你們使用什么測量系統?(例如：MixPanel， statsd 等)
7、你們怎么發現并修復 bug?
強隊通常都有專用的測試人員，團隊的開發人員專注于質量。一個真正的強隊有強大的自動測試。有的團隊太小而沒有專用測試人員或者自動測試，但是并不意味著他們是一個不好的團隊。當我問這個問題的時候，我是想感受一下他們的流程。他們是否總是火燒眉毛?他們是否有清晰的流程用于發現 bug 并為 bug 排出優先級。他們是否依賴用戶發現 bug。
后續問題：
怎么為 bug 排優先級?
使用什么 bug 追蹤系統?(你討厭它的哪一點?)
你們使用 Excel 來跟蹤 bug 嗎?(不!!!)
在你的 bug 跟蹤系統中你有幾個 bug?
修復一個 bug 你需要多長時間(最少、最多、平均)?
8、你們使用什么合作工具?
以我的經驗，優質的團隊會使用許多合作工具。他們常常使用聊天服務(Slack，IRC，HipChat，Jabber)，代碼 Review 服務(Gerrit，GitHub，GitLab，Review Board)，當然還有電子郵件。我在尋找每個開發者知道其他開發者在做什么的信號。我不是在尋找瘋狂的細節，更多的是想了解一般意識。此外，我喜歡看到集成合作工具。最簡單的例子就是當自動編譯失敗時會自動發送一封郵件。web 開發團隊的另一個例子是當嚴重錯誤發生時或當關鍵指標跨越某個閾值時自動錯誤 log 服務發送通知到團隊的聊天室。
9、你們使用什么框架?
我個人偏愛框架兩個方面：
1、我喜歡現代的東西
2、我喜歡新(對我而言)東西
所以如果一個團隊在使用 Motif 開發一個 AIX 桌面應用，我可能不會感興趣。但是可能你會喜歡。這是一個深刻的個人喜好問題，你應該對自己的喜好有一個很好的了解。
不管你個人對框架的喜好是什么，了解他們為什么已經選擇了他們的框架非常重要。他們是跟風?他們頻繁的更換框架?他們的代碼庫就是一堆本月框架榜單中的代碼堆積?他們一直使用古老的版本?
在為什么這個主題上，我希望了解在選擇技術時開發者有多少自由。管理層是否授權技術選擇?管理層是否聽從開發者?為了了解這些問題，我通常會問“你們是怎么開始在項目中使用框架 X 的?”。如果開發者不知道答案，這也許是一個不好的跡象，也有可能他們在公司的時間不夠長還沒有參與做這個決定。
我喜歡看到團隊為他們使用的開源項目貢獻代碼。這說明他們不僅能夠使用開源代碼，同樣還足夠熟練到為它貢獻代碼。這是我喜歡共事的開發者。如果公司樂意為開源項目付費，那就更好了。這說明公司理解了成為開源公民意味著什么。
如果團隊重新造輪子而不是使用已有的工具來幫助他們開發項目，我會感到緊張不安。這條規則也有例外。例如，當 Facebook 也曾開發他們自己的框架，我不會反對他們那樣做的。
10、我們什么時候可以結對?
如果你真的想清楚了解與這個團隊共事是什么樣子，嘗試真正的和他們一起工作。我個人從未這么做過，但是我有一位朋友就這么做了。我覺得這是一個很棒的主意。如果你想了解這個團隊的每一件事情，去和他們一起工作半天。這可能需要簽署 NDA 協議。如果這個團隊愿意考慮這個建議，我覺得是一個很好的跡象。
你可能需要通過管理人員來安排，所以設計這個問題主要是想看看開發者的反應。他們可能會感到震驚，因為他們覺得不值得提到管理層。
11、你的下一個最后期限是什么時候?
(由 Evan Farrer 貢獻)
這個問題是希望更多的了解公司實際遵循的開發流程。單從這個問題不會獲得非常有用的`信息，但是當你添加上這些問題，事情就變得有趣得多：
誰來設置最后期限?
你的上一個任務在最后期限前完成了嗎?如果沒有，為什么沒有?
高質量的團隊會一致同意并承諾最后期限。隨意設置最后期限是功能缺失的跡象，或者至少說明工程師在設置最后期限時沒有發言權。
12、搭建一個全新的開發環境需要多長時間?
(由 Evan Farrer 貢獻)
這個問題幫助判斷公司花費了多少精力在開發者體驗上。一位新的開發者是需要數小時、數天還是數周才能擁有搭建好環境可用于開發的電腦?這個過程是自動的還是手動的?這將告訴你這個團隊在“支持活動”上的高效并不和開發工作直接相關，但是這種高效卻有助于他們的開發。團隊有認真對待這件事情嗎?
有的公司引以為傲的是：他們有開發環境搭建流程，可以快速的讓新的開發者在第一天就能提交代碼到生產環境。這說明公司很認真的對待為開發者提供無摩擦體驗。
問經理的問題
1、您上一次寫代碼是什么時候?
我喜歡有強技術背景的經理。無意冒犯我的 MBA 朋友，我發現我真正喜歡的經理就是那些已經做過我正在做的事情的人。
2、您是怎么成為經理的?
我喜歡選擇成為經理的“經理們”，因為他們是真的樂在其中并且他們天生就是那塊料。 而不是被迫處在那個位置。我同樣喜歡看到經理們專注于為他們的團隊服務。我最喜歡的經理是那些著眼于讓團隊成員的工作的更舒心，而不是想著“掌控”。他們將自己當成幫助者和團隊的守護者。他們有服務的態度，并且他們將“讓團隊成員工作的更舒心”作為其最重要的工作。
3、您的工程師怎么知道每天該做什么事情?
由于我已經問了工程師同樣的問題，我會將他的回答和經理的回答比較看他們是否一致。如果他們的說法不一致，也意味著功能缺失。最糟糕的功能缺失就是沒意識到的功能缺失。我相信去確認像這樣的懸殊差異并修復它是經理的工作。
4、目前您的團隊面臨的最大挑戰是什么?
他們通常會回答人員短缺。因為這是一個普通而明確的回答(畢竟他們正在招聘)，我會繼續問他們第二大的挑戰是什么。我在尋找進度安排脫節、產品質量問題、和人際關系問題等等紅色標記。你會知道這些紅色標記當你看見他們的時候。每一個團隊都有問題，所以你得到的回到依賴于幾個因素：
經理對問題的意識
經理愿意對你坦誠
這個團隊問題的嚴重程度
5、您怎樣衡量每一個員工的表現?
熟練的經理人對待這件事情有很好的技巧。最好的經理人在評估團隊成員的表現時會很細心的搜集整個團隊成員的反饋。糟糕的經理人會根據自己的觀察做出判斷，而不會咨詢團隊成員。
6、您會做正式的績效評估嗎?
我喜歡為重視反饋并且幫助團隊成員提高的經理人工作。績效評估會成為令人難受的或積極向上的體驗。根據我的觀察，我覺得大多數人都將他們看做令人難受的。一個真正出色的經理人當然了解這一點，他會采取一些方式使得績效考評出色的完成，使你影響深刻并且愿意為其工作。
后續問題：
您能分享一次幫助某位員工提高其績效的經驗嗎?
在考評中是怎么指導他們的?
7、您每年都會加薪嗎?
我知道為了和我對公司做出的貢獻匹配，會對我的補償做出調整，我也知道至少每年會做一次官方調查。對于適用的公司，我會詢問股權。您會給我股票期權嗎?您會每年給我更多的股票期權嗎?
有的工程師不習慣問像這樣的經濟問題。不要這樣。工程師通常花很少的時間思考這些問題，但是經理人總是在進行這樣的面談。這些問題對經理人都不會不自在：
您怎么預算加薪?
您團隊去年加薪的平均水平是多少(百分比)?
一年后我可以預期多少加薪?最好情況，最差情況?
我不會將這些問題作為簽署合同的一部分或者作為未來加薪的保證。我只是想了解公司時怎么運作的。我是必須要求為我加薪還是有標準的流程?
8、我可以將描述公司福利的材料帶回家嗎?
(由 Evan Farrer 貢獻)
我知道大多數人都知道問這個問題，但是為了完整性還是值得一提。大多數公司都會為你準備一堆材料或者一個網站為你描述公司的福利。了解這些非常的重要，因為這通常是你補償的很大一部分。這也許只適用于美國，我不確定在其他國家有多少公司為了刺激工作會提供醫療保險。
9、您會為您的員工排名嗎?
(由 Matt Ryan)
有的公司會將所有的員工按照最佳到最差的順序排序，然后強行將一定百分比的員工劃入“優秀”、“普通”和“差”的分類，并根據這個分類來決定其加薪和獎金(我沒有這樣做)。
我從未遇到喜歡這個排名的工程師。這在大公司中尤為常見。他會影響你和水平相當的同事之間的交流，因為你知道某一天你會因為錢和他們競爭。
當我遇到這種情況時，也許不會立即認為這家公司就是一個糟糕的工作場所。在這樣的公司里，通常會有一些不公開的可操作空間。問一問面試官他們怎么看待這個系統?有的經理人會非常坦率的說他們不喜歡這個系統，并且有的經理會告訴你他們為了整個團隊的利益，會采取一些策略來“對抗”這個系統。如果你遇到了這樣的經理人，你可以不用理會這個排名系統。
同時也請記住，不是每一個人都討厭這個系統。只是我沒有遇到過喜歡這個系統的人，并不代表他們就不存在。
后續問題：
您真的以為你的員工中的那 X% 是“不好”的?這對你的招聘過程有什么看法? (這是一個大膽的問題 - 謹慎對待)
您應用某種曲線來確定表現最佳的人嗎?
您使用什么標準來給員工排序?
您怎么知道這些指標搜集準確?
您怎么知道這些指標能夠辨別出表現最佳的人?
為了了解更多的信息，Matt Ryan 對此有一篇非常好的分析文章。
給高層領導的問題
我并不是總是和公司的高層領導交談，尤其是大公司，但是當我這樣做的時候，我把它作為評估公司財務 可行性 的機會。我沒有資格做這件事情，但是有一些明顯的問題我有時會在面試中發現。此外，我想知道自上而下的文化是什么樣的，因為這些信息會告訴我公司怎么看待員工，正面的和負面的都有。
1、你們是怎樣創立的?
我在努力了解公司背后的資金。我想了解他們是否由風險投資，私募股權，公共股票或通過自籌的資金創立。 通常我可以在面試前弄清楚這一點，但公司的領導層常常會增加通過 Google 或 CrunchBase 找不到的見解。
2、你們盈利嗎?
如果盈利，非常棒!如果尚未盈利，你們計劃盈利的目的計劃是什么?有的創業公司會有盈利的計劃，而其他的公司收購或者 IPO 尋找出路。
后續問題：
過去幾個季度/年的歷史收入。呈增長趨勢嗎?
影響利潤率的風險如競爭，意外開銷和意外的收入不足等。
跑道：在籌集更多資金前，公司可以運營多長時間。
3、您對外包的看法是什么?
我想了解我所申請的這份工作在未來是否可能被外包，或者這個職位變成外包管理工程師。
我這里說的不僅僅是離岸外包。承包商也算。
4、跟我講講公司文化吧
這是我用來調和工程師的觀點與領導層的觀點的另一個問題。 我正在尋找可以作為能障礙跡象的差異。 如果他們節奏一致，這表明了良好的自上而下的溝通。 我想知道高層領導是否與海內外員工脫節。 我也想看看領導層是否堅定的遠見并和員工進行了良好的溝通。 我最喜歡為有一個強大的，共同的愿景的公司工作。
一些公司非常重視文化，這可能是件好事。 至少你會清楚公司的價值觀。 對于其他公司，你必須通過隱含的，有時候是不言而喻的細微差別來了解。 公司文化是非常重要的。 有政治斗爭嗎? 尊重專業嗎?尊重誠信嗎?強調加班嗎?
5、你有什么來保障公司會成功?
這個問題我是在尋找真實的證據，而不僅僅是不實的市場宣傳。如果高層領導告訴我一些實際的數據如收入、市場規模和市值，這是一個好的跡象。同樣，如果我能通過其他渠道證實這些信息，那就是一個更好的跡象。另一方面，這些數字可能表示非常糟糕，還是在畫餅。
6、你們的匯報結構是什么樣的?
對我而言，這個問題最好的回答是一個簡單的回答。如果能夠繪制一個圖表來解釋匯報結構，我也會很滿意。我個人的喜好是是為小型，敏捷的公司工作，組織和交流開銷最小。您的個人喜好可能不同，沒有關系。不管你的喜好是什么，這個問題都是為了給你提供你所需要的信息，以便做出明智的決定。
【功能測試面試指南】相關文章：
功能測試面試題06-30
軟件功能測試面試題06-22
經典面試指南02-10
it經理面試指南02-05
文秘面試指南02-05
產品面試指南07-12
成功面試指南07-12
就業面試指南07-12
英語面試指南07-12