關於用例優化：
當測試項目越來越多，測試用例必然也越來越多。看着幾千條用例還有那些測了又測的服務器，完整的執行一次全覆蓋是多麼可怕的事情。但是在測試覆蓋率上我們又不能鬆懈，質量保證是測試的根本。
其實我們內心是抗拒的，原因無非有以下幾點：
（1）重複率很高的用例，反反覆覆的執行
（2）需求又變更了，用例改起來很麻煩
（3）內心的浮躁
當前國內的測試環境是混亂而複雜的，個人感覺可以用浮躁來形容，原因很多。企業對測試的重視程度不夠、測試入門門檻低、薪資普遍比開發低、做測試沒幾年就匆匆的往測試開發或管理髮展、走到後面看不到出路，等等。如果有更好的出路，感覺做測試是在混日子，真的建議改行。因爲測試發展到後面其實和開發差不多，甚至比開發的涉及面還要廣，這是一次苦修。
說上面這些是爲了冷靜，這樣才能讓自己思考。回到用例上面來，無論是後期做自動化、做性能、做接口，好的測試用例都能讓你事半功倍。不要以爲設計用例是很低端和簡單的事情。其實它是基石，是很能體現測試技術高低的。
這裏我就不去說那些老生常談的什麼優先級、什麼粒度、什麼邊界值等價類了。
（1）關於爽。設計是一門藝術，從測試點的分析，到通過語言描述來實現，甚至到執行，每個環節都有優化空間，應該多想想怎麼寫起來更爽，讀起來更爽，執行起來更爽，這些都是成長點。雖然無績效或者領導不care，但是爲了自己還是做起來吧。
（2）關於公共用例，在細化測試點的時候，我們會發現其實有些模塊是共用的，比如不同頁面彈出的相同窗口，我們可以把類似這樣的部分提煉爲公共用例，在其他頁面遇到這個相同的窗口時，點到即可，沒必要再把裏面的內容輪一遍。當然，求同存異，提煉共同點也要發現差異點，差異點的用例要單獨體現出來。
（3）關於新技術，隨着測試技術的發展，現在已不只限制於邊界值、等價類這些最常用的設計方法了，在一些特殊場景二叉樹、對偶、遺傳等方法也得到了應用。但是個人感覺這方面的技術發展還是太慢了，適合項目的，既能節約成本又能提高效率的技術纔是好技術
，通過學習新技術然後到項目中去提煉這纔是自己的。
（4）關於維護，維護用例是一個review的過程，靜下心來看看以前寫的用例，你會想到一些新的思路。可以從全局上對用例進行一個把控，可以對整體的業務流程進行更好的梳理，比如一些通用屬性，比如一些特殊場景。可以通過當前的bug來進化你的用例，提高準確性。可以變換角色，從客戶從產品的角度發現新的大陸。甚至可以從市場上同類產品進行比較而發現新的測試點。
還是那句話，測試用例能提現你的思維模式和你的測試能力，也是自動化、性能、接口的基礎。
關於BUG提交：
提交bug是個既愉快又痛苦的過程。因爲有時候bug會很多（特別是前期），項目週期又很忙。但是好的bug能避免很多麻煩。比如避免了開發讓你重現的情況（不絕對，有些開發確實自身有問題），避免了開發看不懂又找你麻煩的情況，避免了時間久了自己都看不懂的情況。
什麼樣的bug纔是好bug。曾經有人面試過我這個問題，我忘了怎麼回答的了，但是他提到一點，有圖的bug是好bug。這印證了有圖有真相的那句話。確實能夠用圖表說明的bug確實比純文字描述的bug好理解的多，久了之後，也不至於開發不認賬。
至於bug不重複、嚴重等級、優先級這些問題這裏就不談了，這是基本的東西，而且每個公司不一樣。
（1）關於截圖，要有截圖（如果有日誌更好），這很有說明性，可以說明絕大部分情況，開發也能一目瞭然。也便於跟蹤
（2）關於標題，語言描述始終是個難題，如果bug的標題能讓開發猜對80%應該算是成功的。所以至少要有‘在哪裏’，‘做了什麼’，‘導致出現了什麼問題’，這幾點要清晰。關於做了什麼做好找到最短路徑，否則就在詳情中說清楚。
（3）關於跟蹤，有時候提交bug會忘記一些信息，這些信息最好在發現的時候補上，重新修改自己的bug不丟臉。即使是錯誤的bug，及時去修改也避免了浪費時間，因爲大家始終會發現的，所以沒必要刻意隱瞞人都會犯錯。
（4）關於偶現，偶現的bug經常遇到，發現了就先提交吧，有時候死磕也不容易復現的。如果上線後或者幾個版本都沒有出現再關閉總比在線上發現好。
（5）關於迴歸，迴歸環境、版本、結果（通過、不通過、變相通過、場景不存在...）、步驟，應該要有，方便回溯。
（6）關於項目週期很緊，很多情況是因爲bug太多，提交bug會佔據很多時間，所以很多同事就簡單幾句，就把bug提交了，爲後面埋了很多坑。其實截個圖，把標題的要素習慣養起來，提交bug也會很快的。