避免大量實現(xiàn)類bug的可行性辦法：研發(fā)質(zhì)量保證前置

摘要：在實際項目中，拋開產(chǎn)品需求的質(zhì)量不說，但就研發(fā)質(zhì)量保證而言，測試人員在測試階段發(fā)現(xiàn)大量的實現(xiàn)類bug,每天拉著開發(fā)人員修bug；要么在臨近上線的時候，發(fā)現(xiàn)了一個重大問題，導(dǎo)致修復(fù)驗證時間不夠，但又只能“硬著頭皮”上線。解決這些問題的方法或許多種多樣，但這里來聊聊如何使用研發(fā)質(zhì)量保證前置來盡可能避開這些問題。

關(guān)鍵詞：研發(fā)質(zhì)量，質(zhì)量保證前置，盡早暴露問題，上線風(fēng)險

　　背景

　　在實際項目中，拋開產(chǎn)品需求的質(zhì)量不說，但在研發(fā)質(zhì)量保證上面，測試人員往往需要時不時的面對不少頭痛的情況：

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

　　這次有一個從零起步的大項目，涉及多個模塊的交互，但QA在測試時發(fā)現(xiàn)，實現(xiàn)與需求不一致，不得不重新拉產(chǎn)品同學(xué)、開發(fā)同學(xué)重新對需求；

　　需要要重構(gòu)一個核心需求，結(jié)果由于排期緊張，導(dǎo)致提測后不僅改壞了很多老功能，新功能也各種不通；

　　改動了一個各種交互場景十分復(fù)雜的業(yè)務(wù)，由于開發(fā)耗時，測試周期本來就被壓縮了，外加上大部分場景模擬、測試很耗時，臨到上線勉勉強(qiáng)強(qiáng)測完，雖然不是很有信心，但由于項目緊急只能硬著頭皮上線了；

　　要改一個與第三方業(yè)務(wù)交互十分復(fù)雜的業(yè)務(wù)，由于需要第三方配合才能100%覆蓋場景，但由于環(huán)境問題、第三方人員時間問題導(dǎo)致測試被block住很久；

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

　　什么是研發(fā)質(zhì)量保證前置

　　質(zhì)量保證想必大家都不陌生了，就是通過各種手段保證產(chǎn)品保質(zhì)保量上線，說白了就是線上盡量少出故障，最好不出故障。研發(fā)質(zhì)量保證是指代碼實現(xiàn)層面的質(zhì)量了，研發(fā)質(zhì)量對應(yīng)的bug是實現(xiàn)類bug，換句話說是實現(xiàn)與需求不符合導(dǎo)致的bug了。而研發(fā)質(zhì)量保證前置是指將實現(xiàn)類bug的暴露時間點提前。

　　實現(xiàn)類bug的暴露階段通常為：技術(shù)設(shè)計、技術(shù)評審、代碼實現(xiàn)、提測時的冒煙測試、測試階段、線上。研發(fā)質(zhì)量保證前置就是讓實現(xiàn)類bug的暴露更加提前，最好在技術(shù)設(shè)計階段就發(fā)現(xiàn)。

研發(fā)質(zhì)量保證前置的幾種手段

　　前面說過實現(xiàn)類bug暴露有不同的階段，但就其中的技術(shù)設(shè)計而言，目前還是開發(fā)人員為絕對主導(dǎo)的階段，而且極其依賴開發(fā)人員的經(jīng)驗，就目前接觸的眾多實際項目而言，測試人員直接參與技術(shù)設(shè)計的階段的機(jī)會還比較少，因而技術(shù)設(shè)計質(zhì)量這里暫時不做過多討論了。下面就其余的幾個階段聊聊自己的一些經(jīng)驗，歡迎大家補(bǔ)充。

　一、在技術(shù)評審中確認(rèn)各種場景的實現(xiàn)

　　這里的技術(shù)評審?fù)扑]開發(fā)人員主導(dǎo)，測試人員參加的評審會。站在測試人員的角度，雖然評審會的具體形式不限，但應(yīng)該達(dá)到如下的目的：

　　業(yè)務(wù)需求中的各種場景都覆蓋了

　　涉及的原有業(yè)務(wù)都覆蓋了

　　各種異常場景處理符合需求或產(chǎn)品公共處理

　　當(dāng)然了，技術(shù)評審本身需要測試人員對產(chǎn)品業(yè)務(wù)、技術(shù)實現(xiàn)都非常熟悉，否則即使參與評審，恐怕效果也微乎其微了。這里為了讓開發(fā)人員積極配合技術(shù)評審，可以考慮以下實踐：

　　將技術(shù)評審加入到項目流程中，具體形式可以依據(jù)項目大小而定；

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

　　每次評審，可以總結(jié)優(yōu)化點、修改點 ，并做周知，讓團(tuán)隊成員認(rèn)可評審的價值所在；

　二、在代碼實現(xiàn)階段鼓勵微服務(wù)測試

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

　　適合微服務(wù)測試的業(yè)務(wù)大致有以下幾個特點：

　　業(yè)務(wù)除了API接口外，更底層實現(xiàn)是通過若干微服務(wù)搭建起來的

　　涉及的微服務(wù)邏輯復(fù)雜，集成測試很難100%覆蓋

　　涉及的微服務(wù)頻繁業(yè)務(wù)修改，并且需要獨立上線

　　微服務(wù)測試實現(xiàn)最好使用自動化。自己在實際的業(yè)務(wù)中，已經(jīng)將微服務(wù)的測試完全通過自動化的手段實現(xiàn)，測試用例的維護(hù)由測試人員維護(hù)，在需要測試時，開發(fā)人員只需要點擊一鍵執(zhí)行，幾分鐘后就可以直接查看結(jié)果了。當(dāng)然了，除了自動化手段外，如果某個服務(wù)不易100%自動化，可以結(jié)合自己的業(yè)務(wù)特點考慮有無輔助方案。

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

　　想必?zé)o論是開發(fā)人員，還是測試人員，在針對同一個測試用例執(zhí)行結(jié)果時，往往都會有類似的體會：開發(fā)人員認(rèn)真執(zhí)行了沒有發(fā)現(xiàn)問題，但測試人員隨便試用兩下卻發(fā)現(xiàn)問題了。當(dāng)然這排除掉開發(fā)人員，測試人員執(zhí)行測試時的視角不同外，恐怕就是對同一個測試用例的執(zhí)行步驟理解不一致了。

　　這里有幾個自己的一些實踐經(jīng)驗：

　　QA將核心主流程用例，指派給具體的開發(fā)人員執(zhí)行；

　　QA人員提供類似一鍵自測的自動化工具，供開發(fā)人員執(zhí)行；

　　復(fù)雜的需要創(chuàng)造場景的用例，QA輔助開發(fā)人員一起執(zhí)行

　　具體哪種方式，依據(jù)各自業(yè)務(wù)特點、需要而定，但要切記：不可把冒煙測試當(dāng)做一種流程對待，執(zhí)行是只是走個過場。

　四、在測試時快速發(fā)現(xiàn)問題

　　快速發(fā)現(xiàn)問題是問題的暴露盡可能在測試周期前半段時間，避開諸如在測試周期快結(jié)束的1天突然發(fā)現(xiàn)了很多問題，導(dǎo)致bug 修復(fù)、回歸驗證的時間都不夠了。因而，快速發(fā)現(xiàn)問題最核心的目標(biāo)是盡可能早的暴露問題。

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

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

　　提前準(zhǔn)備好測試需要的“一切”。這里的“一切”，不僅僅包括測試數(shù)據(jù)、測試設(shè)備，還包括當(dāng)存在與第三方交互時，需要對方做的一些事情，需要提前打好招呼，約定時間等等。力求達(dá)到不會因為前期準(zhǔn)備不足而耽誤測試執(zhí)行。

　　盡可能讓更多人參與測試。看到這里，你可能會說: 測試除了測試人員外，還有其他人需要參與，更何況其他人也不想?yún)⑴c啊。對，確實有這方面的問題。但這里是說，質(zhì)量保證涉及方方面面的事情，不是測試人員一個人的事情；而且測試人員也有經(jīng)驗、視角的局限性，很可能很明顯的問題恰恰漏掉了。因而測試人員不妨引導(dǎo)團(tuán)隊其他人員 參與測試，比如讓產(chǎn)品人員/開發(fā)人員參與主功能的驗收，設(shè)計人員參與UI/UE校對等等。在自己實際的項目中，感受最深的一點是，團(tuán)隊人員的參與，可以以“小白用戶”心態(tài)來看待產(chǎn)品，因而更能發(fā)現(xiàn)一些體驗方面的問題，而這恰恰因為測試人員接觸產(chǎn)品過多而容易漏掉的。

　寫在最后

　　研發(fā)質(zhì)量的保證需要開發(fā)人員、測試人員齊心協(xié)力、共同努力，需要二者對質(zhì)量保證都謹(jǐn)慎對待。有時在想，如果開發(fā)人員寫的代碼沒有實現(xiàn)問題，那么測試人員的工作就可以大大減少了，少了問題排查、修復(fù)、驗證的耗時，驗證幾遍就可以上線發(fā)布了。但這種顯然在實際項目中不太可能實現(xiàn)了：越來越復(fù)雜的產(chǎn)品設(shè)計，產(chǎn)品迭代速度越來越快，產(chǎn)品需求量有增無減...

　　認(rèn)清了研發(fā)質(zhì)量保證的各種阻礙之后，不妨擺正心態(tài)，認(rèn)真做些事情，來把研發(fā)質(zhì)量保證前置，以求盡可能減少產(chǎn)品發(fā)布風(fēng)險吧！

歡迎加入  51軟件測試大家庭，在這里你將獲得【最新行業(yè)資訊】，【免費測試工具安裝包】，【軟件測試技術(shù)干貨】，【面試求職技巧】... 51與你共同學(xué)習(xí)，一起成長！期待你的加入： QQ                     群：                    755431660