對於Tester來說，測試過程中trouble無數，今天就來說一個典型的項目研發過程問題。
不管你是剛入門小白，還是像我一樣入行1~3年的菜鳥，還是中高階段位（咳咳，對於中高階段位來說，這個應該不是啥問題），讀了此篇文章，要么守得雲開見月明，要么柳暗花明又一村，或者就鞏固一下技能吧。
好了，回到主題。
小菜鳥：大神，請教您一個問題，這幾天困擾的我夜不能寐！
大神：還夜不能寐，誇張了啊，以我的了解，你只有餓的時候才會睡不着覺吧。
小菜鳥：就是打個比喻嘛，嘻嘻~
小菜鳥：大神，那我描述下問題。我在測一款web產品，都渾渾噩噩測3個月了，因為是反反復復提bug。通測第一輪，很多bug關了之后，開發又改了幾個問題，不僅提過的bug重現，還新發現了很多嚴重缺陷。我們幾個同事，氣不打一處來，質問開發，為什么質量這么爛？然而，不懂代碼，都判斷不來開發是否在糊弄我們。開發A說“我改代碼之前評估過啊，認為沒有問題才會下手改的，誰能想到會引發bug呢”，開發B說“可能是思維慣性吧，我對這模塊太熟悉了，所以肯定是這么改，非讓跳脫出來，那反倒不會了。”開發經理說“我一直知道這是個大問題，但是研發人手不夠，新功能堆了幾十個還沒做，項目的售后問題都排着隊等處理，改bug難免有疏漏嘛，測試多擔待一下。”
小菜鳥：於是，問題在一次又一次討論之后，仍然得不到解決。幸好我們部門有兩三個經驗較豐富的同事，我趕緊向人家取經。給出的可行性解決方案有3條。1.問開發，修改代碼后，會引發啥問題，還需測試啥模塊（但開發經常說不全，導致漏測）；2.分析產生bug的這個功能的關聯功能都有什么，重點回歸業務相關的；3.根據以往測試經驗，測功能A時，引發過功能B的bug，如果A再有問題，那就重點測B。
大神：你們不是有測試經理和品質總監嘛，請教過領導沒？
小菜鳥：哎呀，我把老領導的建議漏掉了。他希望我們具備跟研發一樣的代碼能力，通過拉代碼，查看改動點，判斷出會影響X個頁面，X個功能、X個元素組件，有重點地測試。
大神：你能收集到這些可行性方案，非常好！而且問題描述得也清楚，為表達力贊一個。
大神：我按照可行性由高到低，給出個人經驗吧，供你參考。
1.測試團隊，自己拉代碼（完全可以用上Jekins等持續集成/持續部署/持續發布服務），看此版本具體代碼改動點，所以這條只適用於懂代碼的Tester。對於一些有疑問的代碼改動，找開發確認。
2.引入核心業務流的自動化測試（測試團隊自己推進），結合第1點，每次提交代碼，編譯后，進行常規業務的自動化，如跑失敗，版本打回（這里牽扯測試准入標准、測試通過標准、上線標准）
3.開發團隊控制代碼提交權限（得研發Leader推進），未經過code review的代碼，不允許提交
4.引入開發人員每周/每月/每迭代Bug排名考核（得Leader推進），以及Bug Reopen數據考核；而且考核數據，每周全團隊公示（目的是為了讓開發同學重視自己代碼質量）
小菜鳥：真是感謝大神！！！自動化回歸測試我們團隊搭過框架，但是沒推起來。代碼能力是我一直想提高的，總找借口忙忙忙，現在看在避不開了，不然根本做不好測試。另外兩條，看我們領導和開發團隊情況了。一定要做個行動派，我要重新出發，合理規划，把代碼能力和自動化，包括Jekins搞起來！
大神：建議很好給，做到卻很難。加油，讓我看到你的行動力。