好不容易下定決心辭職之後，想去大廠試試。這段時間一直在準備去拼多多的第二次面試。一面是技術面，有一定的難度。按道理來說二面的通過率應該比較高才對，不過最近的二面通過率可能不到50%，一面的通過率一般比較穩定保持在30%以下，所以兩面全過的概率大概只有15%左右，可能更低。
那麼二面的通過率為什麼那麼低呢？我想舉幾個例子就可以說明了。
大概是給你一袋鹽，或者給你一件衣服，寫出一些測試用例。
大部分人可能會這麼想：假如是一袋鹽，那麼要看看裝鹽的袋子是不是會漏？
我可能會想，那應該是要漏還是不要漏？很多人可能會對我的想法愣住，完全意識不到我為什麼會這麼想。
我這麼想是因為我有個怪癖，那就是我希望測試用例都是可以執行的。可以執行的意思是，你要告訴我你究竟是希望袋子漏還是不漏。如果你希望袋子是不漏的，那麼袋子漏的時候測試用例就是不通過的，反之也成立。如果你告訴我看看袋子漏不漏，那麼因為我是很笨的，我不知道如何去執行這個用例，因為我不知道袋子究竟是需要漏呢還是不能漏。
與之類似的，在測試衣服的時候，有的候選人會回答要看衣服的尺碼是不是合適。那麼我會反問，對於l號，衣服多長是合適，多長又是不合適呢？這是因為合適不合適是沒有執行標準的，對於乙個身高不高的人——比如1公尺49家窮人醜的我——來說，l號是不合適的，太長了。而對於身材勻稱的其他人來說，l應該是合適的。所以合不合適沒法量化，加上又有模稜兩可的是不是這樣的詞語推波助瀾，這種用例執行起來是相當困難的。
所以寫用例，要想可執行，首先的第一條原則是，不要包含一些似是而非的詞語，比如是不是，要不要，有沒有之類的。換句話說，就是用例裡大概率要麼包含是，要麼包含不是這樣的詞。
裝鹽的袋子不能（不是）漏
衣服的顏色是紅的
衣服的材料是80%的棉，20%的滌綸
像這樣的是或者不是的句型，我們可以稱之為斷言。
上面是最基本的用例設計，主要考察的是思維的全面程度，以及設計用例的最基本要求——可以執行，沒有歧義。
另外還問了我一些有技術深度的問題。
因為我有效能測試的經驗，問了我關於被測系統的系統架構問題，架構圖起碼大致能畫出來。如果你不了解系統的架構，那麼測試環境搭建，測試策略的選擇都會難以下手，測試的結果也比較難有可信度。
1.為什麼mysql用主鍵去查詢會很快？
2.mysql的主鍵和資料都是怎麼儲存的？
3.能不能畫一下mysql的b+樹的大體結構？
4.什麼是聯合索引？
5.給你幾個真實的例子，概述索引命中的情況
這些問題其實做過mysql效能調優的朋友們應該大體都會，沒做過的話可能就是強人鎖男了。
諸如此類，在兼顧考察廣度的情況下順便考察深度。
其實不然。
我覺得更重要的是用例設計能力。要麼設計的不夠全面，要麼就是基本沒有可執行性。
技術不好的話其實是可以學的，用例設計的不好那麼入職以後可能還沒等到好好學習就出線上問題了。
寫好每一條用例，大概應該是很多測試人厚積薄發的第一步吧。
某東軟體測試工程師（二面） 用例設計
好不容易下定決心辭職之後，想去大廠試試。這段時間一直在準備去拼多多的第二次面試。一面是技術面，有一定的難度。按道理來說二面的通過率應該比較高才對，不過最近的二面通過率可能不到50 一面的通過率一般比較穩定保持在30 以下，所以兩面全過的概率大概只有15 左右，可能更低。那麼二面的通過率為什麼那麼低呢...
京東測試工程師面經分析
tcp ip是乙個協議簇，是乙個開放的協議標準，所有人都可以免費試用，並且是獨立於硬體和作業系統的。tcp ip協議是不區分網路硬體的，它在區域網，廣域網和網際網路中都被廣泛使用。tcp ip協議使用統一的網路位址分配的方案。網路中的每台電腦都具有唯一的ip位址。tcp ip協議是乙個標準的高層協議...
測試工程師面試題1 介面測試
介面 外部系統和系統，以及內部系統之間，通過一些規則 協議 來互動資料和資訊的互動點，本質上就是資料的傳輸和接收 介面測試 測試這些介面 1 越底層的bug，修復成本越低 2 檢查系統的安全性 穩定性。介面可以傳前端不能輸入的值，特別是對於前後端分離的架構，僅對前端做校驗是不夠的，可以通過介面對後端...