本文為霍格沃茲測試學院優秀學員關於測試測試效能平臺開發（國際化商城智能物料平臺）的最佳實踐經驗分享。
測試效能平臺開發的難點是什麼？
關於測試效能平臺開發，從技術上提供指導的文章網上比比皆是，但從 0 到 1 全面闡述測試平臺開發實戰經驗的文章就相對較少。
而且，即使對於不那麼擅於寫代碼的測試同學而言，在平臺開發過程中，技術其實也沒什麼難點。
最難的點在於你要利用最少的資源，在最快的時間內，選擇最合適的實現方案來解決團隊中特定的問題。
本文就記錄分享一下我在公司國際化商城項目中，作為智能物料項目 PO，從零搭建一個快速創建測試物料的工具平臺的一些心得和經驗。該項目在四個月中，迭代了 5 個版本，服務了近 200 多個用戶，幫助團隊快速創建了兩千多個物料，粗略估計相當於節省了一個員工一年多的工時。
以下是項目經驗總結，拋磚引玉，期待與大家一起探討。
一、為什麼要做這個測試平臺？
國際化商城的物料創建（如商品、優惠券、促銷和下單等），一直是項目中多個角色最頭疼的事情。部分站點是找業務創建，部分站點是找負責相應模塊的測試同學創建。無論哪種方式，這一來二去的溝通成本是極其高昂的。最極端情況下，物料準備的時間能佔到整個測試時間的三分之一到四分之一。所以解決測試物料創建的問題，可以突破商城相關測試人力佔用瓶頸。
二、從 0 到 1 構建平臺
項目 BRD
在接到這個任務的時候，是沒有任何詳細的需求，只有一個問題場景。所以要根據這個問題場景，梳理出平臺最核心的價值是什麼，要解決什麼樣的問題。從而延伸出需要解決的問題涉及的範圍是多大。我根據自己的理解編寫了 BRD，這個 BRD 包括以下內容：
① 功能列表和描述
顆粒度可以很粗，這是對平臺初期的一個定位。在開始沒有demo出來之前，一定不要規劃大而全的東西。實現出來的功能，一定是大家可能都會用到的功能，比如我們第一期做的就是通過選擇模板創建測試商品，因為一切的物料都是以商品為基礎。
② 項目計劃及排期
整個平臺規劃做多久，第一期做什麼，做多久，用到的人力是多少。大概示意是這樣的：
| 版本號 | 計劃時間 | 功能列表 | 投入人力 |
|---|---|---|---|
| v 0.8 | 1.1 - 1.15 | 1. 功能A；2.功能B 3.功能C | 前端15天/人；後臺15天/人 |
| v 1.0 | 1.16 - 1.31 | 1. 功能D; 2.功能E；3.功能F | 前端15天/人；後臺20天/人 |
| v 0.9 | 2.1 - 2.15 | 1.功能G；2.功能H；3.優化功能A | 前端20天/人；後臺25天/人 |
這個項目除了我從頭至尾是全職投入，其他同事都或多或少有其他的事。所以一份包含人力投入的項目計劃極為關鍵，這是向領導申請人力支援的憑證。如果有同事做到一半，業務纏身去做別的事情，領導一看這期要實現什麼功能，幾號就要上線，缺口了多少人力，一目瞭然。在還沒開始之前，不知道具體的功能會遇到什麼阻礙，具體需要多少人力投入，估個大概就行，實際在項目開發中，再動態調整。
③ 產品原型
作為內部的工具平臺，不會有多少設計和產品資源支持。而且產品也不太瞭解你要做一個什麼樣的東西，你的流程你的期望你的訴求，產品都沒你清楚。自己要思路清晰，理出個框架，如果條件允許，可以找產品同事幫你畫出大家日常工作中熟悉的產品原型，當然你自己也可以照貓畫虎的畫出來，只要方便其他參與者更好理解和協作就行。至於功能細節及詳細的交互，在今後可以自己慢慢填充和完善。這時開始就不需要產品再次介入了。
④ UI 設計
這是一個看臉的時代，好看的界面會叫人願意多停留幾秒，挽留下來的這幾秒，會幫你爭取到寶貴的注意力。也許他這個激活用戶就看到了他感興趣的東西了。得不到業務需求那樣的設計資源，讓設計同學幫你出一套頁面樣式規範還是可以爭取到的。做前端頁面時儘量遵照這套樣式規範做，不會醜到哪裡。看的人覺得賞心悅目，自然也願意多用。
⑤ 需求
首先你要清晰且明確的知道你們的平臺工具它的核心價值是什麼？它要解決的核心問題是什麼？圍繞這兩個問題，產品形態就會有個大概的輪廓，基於這個輪廓自己就可以往裡填充功能了。
一個人或幾個人的角度畢竟有限，可以找以後的用戶做一下需求收集，聽聽他們的痛點和訴求。獲取到這些東西后一定要做過濾。從用戶側收集到的需求是有噪音的， 他們會根據自己的立場和角度，可能給你一個小眾需求，只能解決少數幾個用戶的問題。這時 要回過頭來審視之前那兩個問題：核心價值是什麼？解決的核心問題是什麼？
舉個例子：商城中商品的創建會涉及到非常非常多的字段，有普通屬性、銷售屬性、品牌、類目、運費模板等等。那在做商品物料創建的時候，是不是要給用戶塞很多輸入框或下拉框，這樣不就可以滿足很多不同場景的測試需求了。NO!商品的創建界面，我們只給用戶一個下拉框選擇平臺定義好的最常用的幾個商品模板，兩個輸入框一個輸價格一個輸入庫存，就沒有了，簡單易用，完全是傻瓜式創建。
為什麼這麼做？多數人對於商品這些琳琅滿目的繁雜字段是不敏感的，他們也不清楚那些到底有啥含義。給他那麼多輸入項，反而造成了困擾，不知道如何入手。他們的訴求很簡單，就是要一個某個類型測試商品，能用就行。我們挑選一些最最常用的幾種類型的商品（不同字段的組合），通過模板事先定義好，供用戶選擇。對於商品某些字段有高要求的用戶，他們本身已經明白這些字段的含義，完全可以在運營端自己去操作。即使滿足了多字段選擇的需求，他們後面也有可能不用。因為你再全也沒有運營端全。
這麼做有兩個好處：
- 大降低使用者的上手成本；
- 實現起來也比較簡單，不用處理太多的邏輯判斷，節省寶貴的開發時間；
⑥ 減法藝術
做平臺工具也是做產品。做產品就要做減法。可有可無的功能能不做就不做，交互和功能都要從減少用戶上手成本出發。比如攝影中畫面元素越少，越能凸顯主題，讓觀者一下抓住畫面的核心。
工具平臺的價值是提升工作和生產效率，如果用戶使用工具還要看很長的文檔，研究半天，我個人覺得它已經失敗一半了。有時候我們思維慣性，想把能呈現的功能能滿足的需求，都儘可能的交付給用戶，沒有考慮用戶能消化多少真正用多少。
要將用戶的使用場景代入進來，幫他恰到好處的解決了平臺能幫他解決的問題，沒有多餘的操作、選擇、輸入。斷舍離很難，但很重要。
三、跨團隊協作
做工具平臺免不了其他團隊的支持和協助，比如物料平臺需要涉及多個研發團隊和部門，有的甚至是跨地域的部門。在此特別感謝一下在平臺建設過程中曾經幫助過我們的同事們。在他們百忙的工作中，抽空幫忙處理和解決與他們業務以及績效毫無相關的事情。
後來接觸的部門和人多了以後，也逐漸有了一點點自己尋求幫助的方式和心得。
- 表明來意
在尋求不認識的同事協助的時候，要清晰明確言語簡潔的表達清楚目的和意圖。 - 找到利益共同點
比如我們搭建了物料平臺後，對於某些模塊的研發同事來說。測試同事可以擠出更多的時間，好好測試他們的開發的需求，同時物料平臺解決了因測試物料創建不當而引發的事故，就再沒有人找他們緊急處理事故了。最後他們自己在調試功能時，再不需要找測試同學幫忙創建物料了。 - 風險規避，解除戒心
物料平臺會調很多模塊的接口，輕者入參錯誤觸發報警，重者接口暴露使用不當會有一定事故風險。本來是想著幫你，但一不小心，給自己添了麻煩。這就要我們事先幫他解除顧慮。我會事先和他們講出我想到的風險，並告訴我的風險規避方案。比如我在調接口的時候先撈線上的 log 模擬入參，再在測試環境調接口，調沒問題了，再切預發或線上。又比如我在調商品創建的接口時，硬編碼寫死某個商品的屬性，來和線上正式商品做隔離，避免用戶使用不當或誤操作引發的事故。 - 名單感謝
平臺上線後，在開發者人員名單中，一一感謝曾經幫助和提供協助的同事們，這本來就供內部使用的平臺，名單再長也無礙。雖然他們不一定會看，有一天一旦在這個名單中搜索到自己的名字時，看到你如此珍視他們哪怕一點點的付出，也是讓人心悅的。
四. 做平臺，作為測試，需要做哪些技術準備?
我的答案是，用什麼學什麼。
我個人以前只寫過 Python 自動化腳本，測 iOS 客戶端時學過一些 OC 和 Swift。物料平臺的後臺技術棧選擇的是 Spring，當時對於 Java 怎麼使用，Spring 具體怎麼用，完全是懵的。在架構師幫我們設計好架構後，買了一本 Spring 的書結合網上的教學視頻，學了依賴注入和切片就 clone 了一個公司內的 Spring 項目。
看裡面的結構，啟動一個項目必備的配置文件有啥。一個簡單的 HTTP 請求從 contorller 到數據庫，需要經過哪幾層，分別做哪些處理。剛開始是十分痛苦的，都是陌生的概念和名詞，在寫通一兩個接口後，後面雖然還是有很多不會，但知道在 Google 和百度上通過哪些關鍵字搜索了。後因前端開發資源緊缺，又利用之前的套路，快速上手了 Vue.js，通過先解 bug 學習 Vue.js 的使用，再逐漸熟悉就可以慢慢的開發功能了。
技術的革新很快，行業變革的也很快。不論研發還是測試，我們所面對的是日新月異的測試框架、技術和工具。在這個快速變化的行業裡，掌握一招吃一輩子的情況越來越少見了。有了紮實的基礎技術儲備，比如熟練掌握一門編程語言，知道計算機和網絡傳輸的原理，程序的幾種常見設計模式等等，就能快速掌握和駕馭新框架、技術和工具。上層東西是不斷變化的，向下走，他們底層原理都是大同小異，就像建築造型無論怎麼改變，他都是需要有地基和承重的。
以上，希望這些對於大家在測試平臺的搭建上有一些思路上的幫助。