軟體測試就是利用測試工具按照測試方案和流程對產品進行功能和效能測試，以下是本站小編整理提供的相關面試題內容，快來閱讀看看吧。
軟體測試面試題
問題是：怎麼測電梯
前提條件是：這是一道軟體測試工程師面試題，而非真正的電梯測試人員的面試題
第二個前提：我沒有需求文件，但我瞭解電梯的基本業務功能
思路：把電梯當作一個我瞭解基本業務功能，卻沒有需求文件的軟體來進行測試。也就是說這裡考察兩點:
第一，你能不能測沒有需求文件，或者需求文件不完整的東西
第二，你能不能把測試用例設計方法應用到實際工作上去
還隱含第三點，你的測試思維是否完整，測試範圍能想得比較全面嗎。
2確定測試範圍
以下是黑盒角度的
功能：關注電梯的基本功能是否實現
效能：關注電梯的效能指標，如負重多少kg
安全性：關注電梯的安全性，如超重報警，下墜制動
使用者體驗：關注電梯的舒適性
以下是白盒角度的或其他的
效率：關注電梯控制邏輯的內部演算法
介面：電梯和電梯控制器，電梯和大樓，電梯和攝像頭，電梯和對講機(報警裝置)的介面測試
零件：電梯的零件的單元測試
相容性：電梯和其他東西的相容性
3具體測試用例的設計
3.1功能測試：
思路一：基於使用者介面，如按鈕，分電梯內的按鈕和電梯外的按鈕;電梯內分樓層鍵、開關門鍵、報警鍵。然後對這些鍵，一個一個測過來。同時關注顯示屏，電梯內外的顯示屏均顯示電梯當前所在樓層和執行方向。
思路一就是典型的單元測試。
思路二：單個功能測好之後，再把單個的功能組合起來進行測試(整合測試)，整合測試時可以根據電梯當前狀態是上行、下行還是停止(狀態機)來設計測試用例，以保證覆蓋率。
比如上行時按XX按鈕會怎麼樣。此時可以向面試官提出等價類劃分思想，為何我要測這些按鈕，如何劃分等價類。
思路三：整合測試完畢後，開始測試真實使用者場景(確認測試/驗收測試/工作流測試)，此時可以設計常見的使用者場景(場景設計)並進行測試。如大量使用者從1樓進入，並去不同樓層。又或者大量使用者從不同樓層下到1樓。
思路四：不同品牌電梯的比較，電梯和電梯國際標準的比較，電梯和安裝電梯的大樓使用者需求的比較等等
思路五：特殊需求的測試，如摩天大樓可能要求高速電梯。百貨大樓可能要求觀光電梯。
3.2效能測試：
思路一：測試電梯負載單人時的執行情況(基準測試)、多人時的執行情況(負載測試)、一定人數下較長時間的運作(穩定性測試)、更長時間運作時的執行情況(疲勞測試)、不斷增加人數導致電梯報警(拐點壓力測試)
思路二：不同層次的效能，如零部件效能等
3.3安全性測試：
軟體的安全性測試我也不瞭解。只能瞎說了。比如，暴力破壞電梯，下墜制動測試，超重警報、超時警報的測試，報警功能的測試，監控攝像頭測試，火災時應該不讓使用者使用，但又要讓裡面的人能出來等等。
3.4使用者體驗：
電梯是否有地毯，夏天是否有空調，通風條件，照明條件。等等
3.5效率：排程演算法是否合理，是否最優，按錯鍵是否可以取消
3.6零件：零部件是否合格
3.7介面：電梯和其他裝置的互動，如報警裝置、中央空調、監控室等等如何互動，是否工作正常
3.8相容性：電梯的整體和其他裝置的相容性
以上，是我考慮的答案。一般把整體思路說一下，再把3.1功能測試部分重點講一講就ok了，面試官應該會滿意的。
如果把電梯換成電話，測試思路還是這個，頂多就是換一些具體用例。或者電梯換成其他任何東西都一樣的，關鍵是，把它當作軟體，展示測試思維。
常見軟體測試面試題
以往是否曾經從事過效能測試工作?請儘可能的詳細描述您以往的效能測試工作的完整過程。
曾經做過一套網管系統的效能測試，主要測試該軟體在同時管理大量終端的情況下，在響應時間，CPU/磁碟/記憶體等引數是否滿足要求。
也曾經做過軟交換系統的呼叫效能測試，主要是測試軟交換系統在有大量呼叫的情況下，響應時間，呼叫成功率，CPU/磁碟/記憶體等引數是否滿足設計要求。
您在從事效能測試工作時，是否使用過一些測試工具?如果有，請試述該工具的工作原理，並以一個具體的工作中的例子描述該工具是如何在實際工作中應用的。
測試網管系統中，使用的Mimic來模擬終端，能夠大量的節省成本。
測試軟交換系統的時候，使用的Prolab來模擬終端併發送呼叫軟交換，他完成了同時數百人才能完成的摘機撥號工作，主要工作原理是產生一些符合要求的IP包併發送給軟交換系統，同時對軟交換系統的迴應進行處理，決定下一步動作。
您認為效能測試工作的目的是什麼?做好效能測試工作的關鍵是什麼?
主要是保障在大量使用者的情況下，服務能正常使用。
在您以往的工作中，一條軟體缺陷(或者叫Bug)記錄都包含了哪些內容?如何提交高質量的軟體缺陷(Bug)記錄?
1.在傳統的BugZilla中，BUG描述應該包括以下的資訊
2.和BUG產生對應的軟體版本
3.開發的介面人員
的優先順序
的'嚴重程度
可能屬於的模組，如果不能確認，可以用開發人員來判斷
標題，需要清晰的描述現象
描述，需要儘量給出重新Bug的步驟
附件中能給出相關的日誌和截圖。
高質量的BUG記錄就是指很容易理解的BUG記錄，所以，對於描述的要求高，能提供的資訊多且準確，很好的幫助開發人員定位。
BUG管理工具的跟蹤過程
用BugZilla為例子
測試人員發現了BUG，提交到Bugzilla中，狀態為new，BUG的接受者為開發介面人員
開發介面將BUG分配給相關的模組的開發人員，狀態修改為已分配
開發人員和測試確認BUG，如果是本人的BUG，則設定為接收;如果是別的開發人員的問題，則轉發出去，由下一個開發人員來進行此行為;如果認為不是問題，則需要大家討論並確認後，拒絕這個BUG，然後測試人員關閉此問題。
如果開發人員接受了BUG，並修改好以後，將BUG狀態修改為已修復，並告知測試在哪個版本中可以測試。
測試人員在新版本中測試，如果發現問題依然存在，則拒絕修改;如果已經修復，則關閉BUG。
您認為在測試人員同開發人員的溝通過程中，如何提高溝通的效率和改善溝通的效果?維持測試人員同開發團隊中其他成員良好的人際關係的關鍵是什麼?
儘量能有面對面的溝通，如果做不到，那麼儘量能直接通過電話溝通，如果只能通過Email等非及時溝通工具的話，強調必須對特性的理解深刻以及能表達清楚。
一是真誠，二是團隊精神，三是在專業上有共同語言，當然也可以通過直接指出一些小問題，而不是進入BUG Tracking System來增加對方的好感。
在您以往的測試工作中，最讓您感到不滿意或者不堪回首的事情是什麼?您是如何來對待這些事情的?
某次效能測試覆蓋不足，造成系統崩潰。
你對測試最大的興趣在哪裡?為什麼?
最大的興趣就是測試有難度，有挑戰性!做測試越久越能感覺到做好測試有多難。曾經在無憂測試網上看到一篇文章，是關於如何做好一名測試工程師。一共羅列了11，12點，有部分是和人的性格有關，有部分需要後天的努力。但除了性格有關的1，2點我沒有把握，其他點我都很有信心做好它。
剛開始進入測試行業時，對測試的認識是從無憂測試網上了解到的一些資料，當時是衝著做測試需要很多技能才能做的好，雖然入門容易，但做好很難，比開發更難，雖然當時我很想做開發(學校專業課我基本上不缺席，因為我喜歡我的專業)，但看到測試比開發更難更有挑戰性，想做好測試的意志就更堅定了。
我覺得做測試整個過程中有2點讓我覺得很有難度(對我來說，有難度的東西我就非常感興趣)，第一是測試用例的設計，因為測試的精華就在測試用例的設計上了，要在版本出來之前，把用例寫好，用什麼測試方法寫?(也就是測試計劃或測試策略)，如果你剛測試一個新任務時，你得花一定的時間去消化業務需求和技術基礎，業務需求很好理解(多和產品經理和開發人員溝通就能達到目的)，而技術基礎可就沒那麼簡單了，這需要你自覺的學習能力，比如說網站吧，最基本的技術知識你要知道網站內部是怎麼運作的的，後臺是怎麼響應使用者請求的?測試環境如何搭建?這些都需要最早的學好。至少在開始測試之前能做好基本的準備，可能會遇到什麼難題?需求細節是不是沒有確定好?這些問題都能在設計用例的時候發現。
第二是發現BUG的時候了，這應該是測試人員最基本的任務了，一般按測試用例開始測試就能發現大部分的bug，還有一部分bug需要測試的過程中更瞭解所測版本的情況獲得更多資訊，補充測試用例，測試出bug。還有如何發現bug?這就需要在測試用例有效的情況下，通過細心和耐心去發現bug了，每個用例都有可能發現bug，每個地方都有可能出錯，所以測試過程中思維要清晰(測試過程資料流及結果都得看仔細了，bug都在裡面發現的)。如何描述bug也很有講究，bug在什麼情況下會產生，如果條件變化一點點，就不會有這個bug，以哪些最少的操作步驟就能重現這個bug，這個bug產生的規律是什麼?如果你夠厲害的話，可以幫開發人員初步定位問題。