好不容易下定決心辭職之後，想去大廠試試。這段時間一直在準備去拼多多的第二次面試。一面是技術面，有一定的難度。按道理來說二面的通過率應該比較高才對，不過最近的二面通過率可能不到50%，一面的通過率一般比較穩定保持在30%以下，所以兩面全過的概率大概只有15%左右，可能更低。
那麼二面的通過率為什麼那麼低呢？我想舉幾個例子就可以說明了。
大概是給你一袋鹽，或者給你一件衣服，寫出一些測試用例。
大部分人可能會這麼想：假如是一袋鹽，那麼要看看裝鹽的袋子是不是會漏？
我可能會想，那應該是要漏還是不要漏？很多人可能會對我的想法愣住，完全意識不到我為什麼會這麼想。
我這麼想是因為我有個怪癖，那就是我希望測試用例都是可以執行的。可以執行的意思是，你要告訴我你究竟是希望袋子漏還是不漏。如果你希望袋子是不漏的，那麼袋子漏的時候測試用例就是不通過的，反之也成立。如果你告訴我看看袋子漏不漏，那麼因為我是很笨的，我不知道如何去執行這個用例，因為我不知道袋子究竟是需要漏呢還是不能漏。
與之類似的，在測試衣服的時候，有的候選人會回答要看衣服的尺碼是不是合適。那麼我會反問，對於l號，衣服多長是合適，多長又是不合適呢？這是因為合適不合適是沒有執行標準的，對於乙個身高不高的人——比如1公尺49家窮人醜的我——來說，l號是不合適的，太長了。而對於身材勻稱的其他人來說，l應該是合適的。所以合不合適沒法量化，加上又有模稜兩可的是不是這樣的詞語推波助瀾，這種用例執行起來是相當困難的。
所以寫用例，要想可執行，首先的第一條原則是，不要包含一些似是而非的詞語，比如是不是，要不要，有沒有之類的。換句話說，就是用例裡大概率要麼包含是，要麼包含不是這樣的詞。
裝鹽的袋子不能（不是）漏
衣服的顏色是紅的
衣服的材料是80%的棉，20%的滌綸
像這樣的是或者不是的句型，我們可以稱之為斷言。
上面是最基本的用例設計，主要考察的是思維的全面程度，以及設計用例的最基本要求——可以執行，沒有歧義。
另外還問了我一些有技術深度的問題。
因為我有效能測試的經驗，問了我關於被測系統的系統架構問題，架構圖起碼大致能畫出來。如果你不了解系統的架構，那麼測試環境搭建，測試策略的選擇都會難以下手，測試的結果也比較難有可信度。
1.為什麼mysql用主鍵去查詢會很快？
2.mysql的主鍵和資料都是怎麼儲存的？
3.能不能畫一下mysql的b+樹的大體結構？
4.什麼是聯合索引？
5.給你幾個真實的例子，概述索引命中的情況
這些問題其實做過mysql效能調優的朋友們應該大體都會，沒做過的話可能就是強人鎖男了。
諸如此類，在兼顧考察廣度的情況下順便考察深度。
其實不然。
我覺得更重要的是用例設計能力。要麼設計的不夠全面，要麼就是基本沒有可執行性。
技術不好的話其實是可以學的，用例設計的不好那麼入職以後可能還沒等到好好學習就出線上問題了。
寫好每一條用例，大概應該是很多測試人厚積薄發的第一步吧。
有人喜歡創造世界，他們做了開發者；有的人喜歡開發者，他們做了測試員。什麼是軟體測試？軟體測試就是一場本該在使用者面前發生的災難提前在自己面前發生了，這會讓他們生出一種救世主的感覺，拯救了使用者，也就拯救者這個軟體，避免了他們被解除安裝的命運。
拼多多測試工程師（二面） 用例設計
好不容易下定決心辭職之後，想去大廠試試。這段時間一直在準備去拼多多的第二次面試。一面是技術面，有一定的難度。按道理來說二面的通過率應該比較高才對，不過最近的二面通過率可能不到50 一面的通過率一般比較穩定保持在30 以下，所以兩面全過的概率大概只有15 左右，可能更低。那麼二面的通過率為什麼那麼低呢...
軟體測試工程師
首先，最根本的還是要看企業自身的需要，綜合自己的測試團隊力量，自己公司的研發狀況，當然還有公司的資金 到底到測試這塊公司願意投入多少money呢?另外要搞清楚自己公司招聘測試人員的目的是什麼?比如，如果公司暫時還沒有測試團隊，這個時候公司剛好有財力，同時研發力量比較大的時候，因為發展的需要，必須要組...
軟體測試工程師
理解產品的功能要求，並對其進行測試，檢查軟體有沒有缺陷，測試軟體是否具有穩定性 安全性 易操作性等效能，寫出相應的測試規範和測試用例的專門工作人員。最重要的客戶是軟體的使用者。測試工程師需要站在客戶的使用和需求角度測試軟體，報告問題。軟體測試只能證明軟體存在錯誤，不能保證軟體沒有錯誤，不可能找出全部...