有時 方法 回收權限 生產 用例 微服務 dea 界定 抽象

前言

2017年我有幸負責公司DevOps治理和落地項目，在整個DevOps落地工作中，深感測試環節在持續交付工作中的弱態及重要。實踐是檢驗真理的唯一標準，沒有實踐就沒有發言權。為求深入理解，我親身投入了測試崗位的一線工作。從測試用例的編寫、宣講、測試、復測、上線、回歸等一些列實際工作，再到帶領測試團隊、提煉測試經驗，推動測試變化的一系列行為，讓我對測試工作有了深刻的認識。在測試崗位一年多的工作經驗中，補全了我Devops治理工作中測試環節的內容，為我Devops的工作提供了豐富的經驗。我也借這次拼多多事件與大家分享一下我的測試工作體驗。

線上的測試券

這幾天拼多多被薅羊毛的事刷爆了朋友圈，作為經歷了生產刪庫、用戶數據泄露等諸多互聯網安全新聞的圈內互聯網從業人員，早已內心淡定、波瀾不驚了。昨天朋友圈發了一篇關於拼多多事件技術復盤的文章，我匆撩一眼便覺得有必要給這位小編科普一下為什麽測試券可以發布到生產環境。

小編在文章中提到了拼多多事件是由測試券引發的生產漏洞。他確實闡述了一個在互聯網企業客觀存在的現象，就是生產環境中，測試商品的存在。記得去年某東也曾出現過測試商品被用戶下單的問題。
我在剛做測試的時候，我們項目團隊也存在同樣的問題，如我們開發了新的支付功能，在漆黑的深夜（12點左右吧），項目組的同事們（開發、測試、產品、運營）相約起床（有時也會約在公司熬夜到此時的），將代碼發布上線，然後開始線上回歸測試。這時的測試工作是個主流程的回歸測試，測試人員在代碼發布上線後，要通知產品經理和運營人員配置上線測試商品，然後通過新版本進行下單、購買、退款等可覆蓋新功能的主要閉環流程的測試工作。順利的話，很快結束，大家開心安穩睡覺，不順利的話，在許可的條件下開發同事會反復定位，最後完成上線工作，否則超過發布時間窗口的話，就回滾代碼等著下次吧。
以前測試人員或產品經理有著很大的權限，有著超級管理員的權限。後來運管中心進行了權限管控，回收權限，但這也直接導致了發布生產後，被管控權限功能無法進行線上回歸測試。因此每次上線也會因為功能的不同，帶上相關的運營的同事。

我的測試實踐

線上測試環境

客觀問題既然存在，並不表示放任他的存在而不管，我覺得我們同樣需要根據客觀事實去實施一種管理策略，既可以完成線上環境的測試工作，又可以不影響實際的商戶運營。
我在負責廣場優惠券小程序的項目測試工作時，為了提高測試能力同時避免生產事故，我聯合開發、運營同事，共同在生產環境開通了一個虛擬廣場的商戶，對這個虛擬廣場，我們測試人員有完全管理權限，可實現廣場商戶的全功能測試覆蓋。對於實際用戶，即便切換到該廣場，看到的也全是測試商品和測試說明（這也未嘗不是一種彩蛋），但無法領用，因為這裏的券只有被指定的測試人員的會員才可以領用。利用這個虛擬廣場，我們在後續的測試工作中獲得極大的便利。

舉個例子，當時我們要上線一個類似大轉盤，點擊後抽獎的活動功能。經過項目組同事的努力，快速的完成了代碼的開發和測試工作，我們提前幾天就把代碼發到了生產環境，並在虛擬廣場中進行了活動的上線，為了得到更充分的測試，我們發動了公司同事共同的參與了內測活動，得到了充分的測試和很好的用戶反饋。這樣我們即提升了測試的覆蓋能力，又沒有影響到實際的商戶，高效的完成了代碼上線及測試工作。

這個解決方案有他的特殊性，虛擬廣場是可獨立存在的，所以並沒有開發同事深入的介入，只是在運營同事方面開通相應的權限就實現了。但這個測試實踐，也為在生產環境進行測試工作提供了一種可實用的方法，就是在生產環境上進行灰度隔離，創建一個可測試的真實環境。依照現在的技術，實現起來也不是存在很大難度的，不同場景更因其實際情況的復雜程度要區別對待，可能測試人員、產品經理和運營同事就可以把方案實現並落實，也可能要依賴產品經理、開發同事、測試人員、運維同事、運營同事等諸多同事共同設計來完成此事。

在最初我帶隊Devops落地項目的時候，也曾自動的忽略了測試崗位的存在。在很多情況下，測試人員只是需要時才被想起來的角色。當經過測試工作的實際參與，我覺得在目前開發團隊裏，應該給測試人員更重要的定位和更多的賦能。如何發揮測試人員在開發團隊中的作用，在思考的同時，我也切身在工作中進行了如下實踐：

測試驅動產品

我的測試團隊，在接到產品經理的需求文檔後，會主動與產品經理進行溝通，開始進行測試用例的編寫，並與產品經理反復確認產品設計中的每個細節，力求充分理解產品需求，使得測試用例可以覆蓋到產品設計的每個細節，此時產品經理也在和測試的溝通中彌補了產品設計細節的不足。在測試用例設計後，會組織在測試團隊進行內部宣講，用團隊的力量彌補個人思考的不足。然後負責測試的同事再組織開發同事與產品經理進行測試用例宣講，待到項目小組內都明確測試目的後，測試用例就定稿了。測試用例是測試工作的基礎，是一個非常明確的待辦事項列表，為了清晰內容，明確目的，我把測試用例拆分成功能用例和流程用例。在與開發同事和產品經理宣講時，只講流程用例，既明確了產品目的和需求，又有效的控制了宣講會的節奏和提升了會議的效率。

測試驅動開發

此處的測試驅動開發，不同於TDD的概念，而是讓測試人員來驅動開發工作。開發工作與測試用例的設計往往是並行進行的，測試用例定稿後，有部分測試工作已經可以開始了，這不單包括測試人員進行的測試工作，也包括測試用例分享給開發同事後，他們的自測試工作。每日站會時，測試人員會根據測試用例的內容梳理出的待辦事項列表與ScrumMaster 共同與開發同事明確開發目標和deadline。會後測試人員也會針對當日目標配合開發同事完成相關的測試工作，推動開發完成目標。

業務故障處理

經過上述一系列的工作，雖然測試人員沒有參與編寫代碼，但是產品功能、業務流程、接口參數更甚至版本叠代歷史，測試人員都是最熟悉的，所以在業務故障出現時，測試人員將會更清晰是哪個環節導致了該問題的發生。因我們在測試用例設計時，就把業務流程單列出來作為獨立的用例進行編寫，並作內部宣講，所以組內同事都能夠清晰的把線上業務的主流程、分支流程、逆流程說清楚。在出現業務故障時，我們組的測試人員，可以根據所熟悉的業務流程，很快的分析出問題方向，並根據問題界定好用戶操作、運營配置、接口服務、代碼問題等業務故障類型，並進行直接答復解決或聯系該部分代碼的開發同事深入排查。該工作，在實際的業務故障處理時也給我們帶來的有益的效果，極大的縮短了業務故障的處理時間。

後續的思考

互聯網企業管理，傳統思維要不得

每次企業的生產事故，都會有人說要加強管理，於是就頒布了諸多的管理規定和操作流程，然後就期盼著大家共同去遵守。對於傳統型企業，這是很常規的做法。但在互聯網企業更應該將管理規定和操作流程進行工具化的落地。制度是規則，管理是約束，工具才是更人性化管理落地的體現。不是在事後的抱怨和懲罰，而是事前做好每個人的保護才是根本管理之道。

普通人視角，客觀看待問題

每次看到優秀的產品或優秀嚴謹的代碼，我們都會為之贊嘆。但我們更應客觀的認識到世界是由80%的普通人構成的，如何讓普通的人做成優秀的事，才是真正需要去思考的問題。我認為devops 裏提倡的pipeline 的精髓就是，復雜的事情簡單做，一個人只專註做一個完整的流程，讓普通人更容易的去完成一件事。開發流行的各種框架結構、微服務等手段都在不斷的降低開發人員能力的需求。這都是不斷的在追求讓普通的人做更優秀的事的先進實踐。

用戶的需求就像一副抽象畫，他模糊、復雜、易變且不確定，互聯網產品為滿足用戶的需求，就必須可以具有敏捷的特性去反復的試探用戶的體驗。產品從設計、開發、測試、上線、運營、再次叠代的過程中，測試人員更應該把團隊中的各個角色貫穿起來，只有給予測試人員正確的定位和足夠的賦能，才可真正的將敏捷開發的理念更好融入到實際工作中，快速應對用戶需求的各種變化。

拼多多“薅羊毛”事件引發測試工作的思考