避免大量實現類bug的可行性辦法：研發質量保證前置

摘要：在實際專案中，拋開產品需求的質量不說，但就研發質量保證而言，測試人員在測試階段發現大量的實現類bug,每天拉著開發人員修bug；要麼在臨近上線的時候，發現了一個重大問題，導致修復驗證時間不夠，但又只能“硬著頭皮”上線。解決這些問題的方法或許多種多樣，但這裡來聊聊如何使用研發質量保證前置來儘可能避開這些問題。

關鍵詞：研發質量，質量保證前置，儘早暴露問題，上線風險

　　背景

　　在實際專案中，拋開產品需求的質量不說，但在研發質量保證上面，測試人員往往需要時不時的面對不少頭痛的情況：

　　開發團隊來了一個新人，本來需求量不大，但測試人員在測試時發現連主流程都跑不通，無法走下去；

　　這次有一個從零起步的大專案，涉及多個模組的互動，但QA在測試時發現，實現與需求不一致，不得不重新拉產品同學、開發同學重新對需求；

　　需要要重構一個核心需求，結果由於排期緊張，導致提測後不僅改壞了很多老功能，新功能也各種不通；

　　改動了一個各種互動場景十分複雜的業務，由於開發耗時，測試周期本來就被壓縮了，外加上大部分場景模擬、測試很耗時，臨到上線勉勉強強測完，雖然不是很有信心，但由於專案緊急只能硬著頭皮上線了；

　　要改一個與第三方業務互動十分複雜的業務，由於需要第三方配合才能100%覆蓋場景，但由於環境問題、第三方人員時間問題導致測試被block住很久；

　　無論這些問題你是都遇到過，還是遇到過其中的幾個，這些問題可能都給上線質量帶來了或多或少的影響，甚至直接帶來了線上故障。這些問題都有一個共同的特徵：大部分問題的暴露都集中到了測試階段。這裡拋開需求方面問題，就自己的專案經驗，聊聊與實現相關的研發質量保證前置方面的心得與體會。

　　什麼是研發質量保證前置

　　質量保證想必大家都不陌生了，就是透過各種手段保證產品保質保量上線，說白了就是線上儘量少出故障，最好不出故障。研發質量保證是指程式碼實現層面的質量了，研發質量對應的bug是實現類bug，換句話說是實現與需求不符合導致的bug了。而研發質量保證前置是指將實現類bug的暴露時間點提前。

　　實現類bug的暴露階段通常為：技術設計、技術評審、程式碼實現、提測時的冒煙測試、測試階段、線上。研發質量保證前置就是讓實現類bug的暴露更加提前，最好在技術設計階段就發現。

研發質量保證前置的幾種手段

　　前面說過實現類bug暴露有不同的階段，但就其中的技術設計而言，目前還是開發人員為絕對主導的階段，而且極其依賴開發人員的經驗，就目前接觸的眾多實際專案而言，測試人員直接參與技術設計的階段的機會還比較少，因而技術設計質量這裡暫時不做過多討論了。下面就其餘的幾個階段聊聊自己的一些經驗，歡迎大家補充。

　一、在技術評審中確認各種場景的實現

　　這裡的技術評審推薦開發人員主導，測試人員參加的評審會。站在測試人員的角度，雖然評審會的具體形式不限，但應該達到如下的目的：

　　業務需求中的各種場景都覆蓋了

　　涉及的原有業務都覆蓋了

　　各種異常場景處理符合需求或產品公共處理

　　當然了，技術評審本身需要測試人員對產品業務、技術實現都非常熟悉，否則即使參與評審，恐怕效果也微乎其微了。這裡為了讓開發人員積極配合技術評審，可以考慮以下實踐：

　　將技術評審加入到專案流程中，具體形式可以依據專案大小而定；

　　為了鼓勵大家參與的積極性，不妨想些針對性的鼓勵方法；

　　每次評審，可以總結最佳化點、修改點 ，並做周知，讓團隊成員認可評審的價值所在；

　二、在程式碼實現階段鼓勵微服務測試

　　眾所周知，單元測試主要是為了從底層程式碼更快發現問題，儘量避免直接測試一個大的模組，這樣排查問題會比較耗時。不記得有多少次，開發人員為了排查一個問題不得不打個斷點，debug幾次才能真正定位到問題程式碼了。出現此問題除了log日誌不太全外，就是組裝成模組的更小模組、方法缺少必要的關鍵單測了。當然了，實際專案大家對單元測試的態度往往是：儘管愛，但很難真正行動。就自己接觸的眾多專案而言，開發人員可能透過日誌自檢，或者就針對某一些方法簡單跑下測試，把單元測試當成工作的團隊還真沒有接觸過。於是乎，在實際專案中，透過和開發人員達成共識，在程式碼實現階段，針對某個獨立服務測試自檢。

　　適合微服務測試的業務大致有以下幾個特點：

　　業務除了API介面外，更底層實現是透過若干微服務搭建起來的

　　涉及的微服務邏輯複雜，整合測試很難100%覆蓋

　　涉及的微服務頻繁業務修改，並且需要獨立上線

　　微服務測試實現最好使用自動化。自己在實際的業務中，已經將微服務的測試完全透過自動化的手段實現，測試用例的維護由測試人員維護，在需要測試時，開發人員只需要點選一鍵執行，幾分鐘後就可以直接檢視結果了。當然了，除了自動化手段外，如果某個服務不易100%自動化，可以結合自己的業務特點考慮有無輔助方案。

三、在提測時做好冒煙測試

　　想必無論是開發人員，還是測試人員，在針對同一個測試用例執行結果時，往往都會有類似的體會：開發人員認真執行了沒有發現問題，但測試人員隨便試用兩下卻發現問題了。當然這排除掉開發人員，測試人員執行測試時的視角不同外，恐怕就是對同一個測試用例的執行步驟理解不一致了。

　　這裡有幾個自己的一些實踐經驗：

　　QA將核心主流程用例，指派給具體的開發人員執行；

　　QA人員提供類似一鍵自測的自動化工具，供開發人員執行；

　　複雜的需要創造場景的用例，QA輔助開發人員一起執行

　　具體哪種方式，依據各自業務特點、需要而定，但要切記：不可把冒煙測試當做一種流程對待，執行是隻是走個過場。

　四、在測試時快速發現問題

　　快速發現問題是問題的暴露儘可能在測試周期前半段時間，避開諸如在測試周期快結束的1天突然發現了很多問題，導致bug 修復、迴歸驗證的時間都不夠了。因而，快速發現問題最核心的目標是儘可能早的暴露問題。

　　要想讓問題提前暴露，當然除了測試方案的完備性、人員經驗等因素外，還可以從測試效率提升入手做些事情：

　　自動化覆蓋。這是效率提升常用的一種技術手段，只要自動化用例覆蓋全面，外加上一鍵執行，問題幾分鐘可以暴露出來。

　　提前準備好測試需要的“一切”。這裡的“一切”，不僅僅包括測試資料、測試裝置，還包括當存在與第三方互動時，需要對方做的一些事情，需要提前打好招呼，約定時間等等。力求達到不會因為前期準備不足而耽誤測試執行。

　　儘可能讓更多人參與測試。看到這裡，你可能會說: 測試除了測試人員外，還有其他人需要參與，更何況其他人也不想參與啊。對，確實有這方面的問題。但這裡是說，質量保證涉及方方面面的事情，不是測試人員一個人的事情；而且測試人員也有經驗、視角的侷限性，很可能很明顯的問題恰恰漏掉了。因而測試人員不妨引導團隊其他人員 參與測試，比如讓產品人員/開發人員參與主功能的驗收，設計人員參與UI/UE校對等等。在自己實際的專案中，感受最深的一點是，團隊人員的參與，可以以“小白使用者”心態來看待產品，因而更能發現一些體驗方面的問題，而這恰恰因為測試人員接觸產品過多而容易漏掉的。

　寫在最後

　　研發質量的保證需要開發人員、測試人員齊心協力、共同努力，需要二者對質量保證都謹慎對待。有時在想，如果開發人員寫的程式碼沒有實現問題，那麼測試人員的工作就可以大大減少了，少了問題排查、修復、驗證的耗時，驗證幾遍就可以上線釋出了。但這種顯然在實際專案中不太可能實現了：越來越複雜的產品設計，產品迭代速度越來越快，產品需求量有增無減...

　　認清了研發質量保證的各種阻礙之後，不妨擺正心態，認真做些事情，來把研發質量保證前置，以求儘可能減少產品釋出風險吧！

歡迎加入  51軟體測試大家庭，在這裡你將獲得【最新行業資訊】，【免費測試工具安裝包】，【軟體測試技術乾貨】，【面試求職技巧】... 51與你共同學習，一起成長！期待你的加入： QQ                     群：                    755431660